Hi, Dick, I can see two scenarios: - A non-AP STA (MLD) with only one radio, and it is using “Single-radio MLD” to switch between 5 GHz and 6 GHz with its one radio. This is not FST, just a feature of MLD.
- A non-AP STA (MLD) with more than one radio, and enabling one while disabling the other (say, between 5 GHz and 6 GHz). This is again MLD (as I understand it), and just enabling/disabling links dynamically, which is also being discussed/planned as a feature of MLD.
Now, you raise an interesting point, perhaps, of why bother doing single-radio MLD, when FST accomplishes (nearly?) the same thing. That’s a question I can’t answer, but I am assuming there is something that single-radio MLD accomplishes beyond what FST can do, of which I am just not familiar. Mark From: Dick Roy <dickroy@xxxxxxxxxxxx>
Sent: Wednesday, May 5, 2021 1:41 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577 Mike/Mark, FWIW … another thought on FST and MLO. I’m not sure they are “mutually exclusive features”. I can imagine a non-AP MLD wanting to, for example, change from a set of channels in the 5GHz band to an obviously different set of channels in the 6GHz band, and do so “quickly” using FST functionality. From the point of view of FST functionality, it’s a “single (MLD) MAC” that wants a fast session transfer. I might be missing something here, and if I am, I am confident you can help me out :^)))) Cheers, RR Thanks for the comments. I believe this contribution gives a response to your comments on TGbe with respect to MLO architecture. I believe this is a really good starting point and will likely evolve through the progress of P802.11be. My recommendation at this point is to get this text for MLO operation into the draft and then add to it to provide more information on mixed legacy AP/MLD operation. My responses to your comments below: Hi, Duncan, Thanks for this. Good progress! A few mostly minor (I think) comments: - As I think you know, I struggle with the Reference model figure (Figure 4-xxx), just stylistically – I think it is hard to understand/visualize. I’d be happy to work more with you off-line, to see if we can find an alternative. And, whatever we end up doing with this Figure, we may want to consider a contribution to REVme to do something similar to Figure 4-28 (REVme D0.0), and maybe Figure 4-29. (If nothing else, the NOTEs you have in 4.9.5 would be good to add in the baseline 4.9.4.)
[MM] We can take this one offline. If there is something to be contributed to REVme, my preference is to leave this as is in TGbe for now and then adjust once the change in REVme is complete. -
- I also think Figure 4-xxx and the text in 4.9.5 is a bit confusing because it doesn’t show/describe that many (most, in fact) of these components are actually shared with the legacy operation STA(s). What is “shared” and what is not is left to the reader to figure out, and I think that could lead to interoperability problems due to differing assumptions. Also, for example, the text is clear about the link-specific operations, including SAs for GTK/IGTK/BIGTK, but the figure implies there is only one Authenticator/Supplicant and RSNA Key manager.
[MM] In my opinion the current text in 4.9.5 is complete and clear for MLO. It could be that we add separate text and perhaps a separate figure to cover MLO where the affiliated APs perform legacy operations. I think this could be added after this text is accepted. -
- 4.9.5, 6th paragraph (counting the NOTEs), I don’t think the MLD MAC address can identify the SME. That doesn’t fit the MAC addressing model from IEEE Std 802. The MLD MAC address is actually identifying the (single) MAC SAP (or the entity(ies) supporting that MAC SAP, if you’d prefer), which you have described in a later paragraph.
[MM] My recommendation is to change "The SME is identified by" to "The IEEE 802.1X Authenticator of the AP MLD is identified by" -
- 5.1.5.1, in the new paragraph that starts “During reception, …”: if we’re mentioning the multiplexing, we probably also need to mention the split between the MLD stack processing and the legacy stack(s) processing, based on stored knowledge of the peer device/association type.
[MM] Similar to my earlier comment response. I believe concurrent legacy/MLO operation should be covered by a separate text in a separate submission. I believe this text is complete for MLO. -
- Also in that same paragraph, it is not MSDUs from the PHY SAPs that do the multiplexing, but the _MPDUs_ (they haven’t been decrypted/unpacked yet) from the _top of the Lower MACs_ that do this.
[MM] Yes, MSDU should be replaced by MPDU. -
- I’m not sure why you have changed the order of the functional blocks in Figure 5-3 (compared to the baseline Figure 5-1). We should discuss this re-ordering, and if agreed, update Figures 5-1 and 5-2 to match. Also, why were some blocks left out completely?
[MM] The only blocks that are missing are fragmentation/defragmentation and PS Defer Queuing. TGbe has agreed not to support fragmentation/defragmentation in release 1. I think I know what PS Defer Queuing is, but its only used in Figure 5-1 and Figure 5-2 and not defined anywhere in IEEE 802.11-2020 (sounds like a REVme issue) so I believe its OK to leave it out of the proposed Figure 5-3 for now. -
- Comparing the new text to the baseline, I am now realizing that I have no idea what to think of a combination of FST and MLO. I’m not sure that is even useful. Has that been discussed? Can we just rule it out?
[MM] I believe FST and MLO are mutually exclusive features. I don't have an idea how or why someone would combine them. -
- A nit, but should we really add new subclauses for 5.1.5.10 and 5.1.5.11, or just “fix up” the language in 5.1.5.2 and 5.1.5.3?
[MM] I think its good to have new subclauses given these are separate entities at this point. -
- Those subclauses (just above) point out a question I hadn’t tried to think about yet – is there any reason we can’t do GLK with MLD, or is the plan to support GLK MLD?
[MM] It seems that you could support GLK on an MLD. Would need someone to figure out what the text changes were. -
- The DA address filtering (and other discussion about MAC addresses) makes me realize that we need to say somewhere that when an MSDU is directed to/from an AP MLD or non-AP MLD, the DA/SA (respectively) are the MLD address for the AP MLD or non-AP MLD. Do we say that anywhere? That is, to external devices, it is the “MLD address” that is visible on the broader 802 network (I think).
[MM] That is currently covered in 35.3.3 but the text could be cleaned up to be clearer. -
- For the diagram in 7.1 (new Figure 7-1), this is another spot where I find it confusing that the AP MLD does not have any indication of how the legacy operation works. Especially in this figure, where the legacy APs also have access to the DS (separately from the MLD AP) I think that really needs to be shown in the figure. I don’t know if you’ve seen the figure I did in 11-21/0396r2 slide 6? I think adding that figure (as a new 7-1a, rather than making Figure 7-1 any more complicated) would be a better approach.
[MM] If we want to show mixed MLO/legacy operation, we should create separate text and a separate featuree. -
- At the end of subclause 7.1, do we need to add “Accept non-AP-MLD-to-AP-MLD mapping updates from the AP MLDs.”? Similarly, in the paragraph above, “mapping of STAs _and non-AP MLDs_ to APs, _AP MLDs_, or to mesh gates.”\\
[MM] See my earlier comments on mixed operation.
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |