Arik, That sentence is following the sentence describing how the MLD lower MAC sublayer participates in BA Scoreboarding, so it is meant to be further clarification of the MLD lower MAC sublayer, and not additional statements about other blocks. So, two possibilities (and perhaps we could do both): - Move the sentence, so it is together with other sentences about the MLD upper MAC sublayer (and here, I am assuming that is what you meant: the MLD upper MAC, and not an affiliated AP’s upper MAC). In which case I think we need to clarify what “convey Block Ack status” means. I had meant that to mean that it put this information into actual Block Ack frames, but I now see that this was perhaps not clear. If we want this sentence to be talking about the MLD upper MAC, then I think we’re talking “sharing” the Block Ack status between the links/between the MLD lower MAC sublayers, right? With some rewording, I’m okay to add this concept to the MLD upper MAC sentences.
- For the purposes of the actual Block Ack frames and their information, there are proponents that each MLD lower MAC sublayer _may_ include information from other links’ status in their Block Ack frames. This is the intent of the sentence as it is now. And, I left it vague intentionally about how the MLD lower MAC gets this information about other links’ status, just that is has to “obtain such info from the other link” somehow. I don’t see a need to be specific about how this (by definition, implementation-specific) behavior works. So, I believe the sentence as worded in the latest draft is correct: “The MLD lower MAC sublayer may convey Block Ack status of the MPDUs received on another link if it obtained such info from the other link.” Would it help if “convey” was reworded to be clear that I am talking about the contents of the actual Block Ack frames?
Mark From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Friday, May 13, 2022 8:22 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion Hi Mark, I agree that the BA Scoreboarding in the lower MAC layer delivers the bitmap refers to all MPDUs received on this specific link. I also understand that the collection of all bitmaps transferred by each link is collected by the BA Scoreboarding element in the upper MAC layer (to have a full picture of all received MPDUs). What I do not understand is why the BA Scoreboarding in the lower MAC layer need to know the BA bitmaps collected on other links?! And even if it needs – this should be transferred through the BA Scoreboarding element in the upper MAC layer. Therefore the correct sentence is as I’ve suggested:” “The upper MAC layer may convey Block Ack status of the MPDUs received on another link if…” Please clarify of I’m missing something here…. Arik, So, I’m not sure if we are aligned or not. I agree that the sentence you quote could be ambiguous. However, my intention is that this sentence should be clear that it applies to the MLD lower MAC sublayer (not the MLD upper MAC layer). Note that an earlier sentence says that the MLD upper MAC sublayer can manage all the links, or that the overall status management can be distributed. So, the next couple of sentences are talking about the MLD lower MAC sublayer managing the status for all the MPDUs received over its link, and can optionally also signal status for other links if it gets information about those links’ MPDUs. So, I suggest the sentence you cited should be The MLD lower MAC layer may convey Block Ack status of the MPDUs received on another link if… OK? Mark Hi Mark, all I’m fine with the text suggested by Tomo, with one small modification/clarification:
Modify the sentence starts with “It may convey Block Ack status of the MPDUs received on another link if…” with the following: “The upper MAC layer may convey Block Ack status of the MPDUs received on another link if…” (so it will be clear who is the subject of this sentence..) Thanks for your cooperation. Hi Mark, These changes look good to me too. Thanks, Duncan WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. That seems okay to me, as well. Thanks! Mark I'm OK with Tomo's proposed text. Given that there are already requirements for Scoreboarding behavior, I don't believe we need much more detail. Hi Mark, Do we need the part that I highlighted in green below? It is covered by It may convey Block Ack status of the MPDUs received on another link if it obtained such info from the other link via the MLD upper MAC sublayer. Isn’t it? So my suggestion will be as follows (also removed “Note that”): When MLO is being used, the “Block Ack Scoreboarding” block in the MLD upper MAC sublayer manages the overall Block Ack status of the MPDUs (of this Block Ack sessions established between two MLDs) that are received on any (all) setup links. In an implementation, this function may be distributed into the MLD lower MAC sublayers for the links. The “Block Ack Scoreboarding” block in the MLD lower MAC sublayer manages at least the Block Ack status of the MPDUs (of this Block Ack session) that are received on this link. It may convey Block Ack status of the MPDUs received on another link if it obtained such info from the other link via the MLD upper MAC sublayer. The “Block Ack Scoreboarding” block in the affiliated AP upper MAC sublayer manages the Block Ack status of the MPDUs received over corresponding non-MLO links. In an implementation, this function may be distributed into the MLD lower MAC sublayer. Best regards, tomo All, It seems there are a number of “optional” ways Scoreboarding can be done. The result of all these options ends up that all the Scoreboarding blocks are optional – but of course at least one of them must be present. My suggestion is that we simply call all the blocks “Block Ack Scoreboarding” in the figure, and rely on the text below the figure to explain further. For that text, we already have these short descriptions in the bullet lists: - For the MLD upper MAC sublayer: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD lower MAC sublayer). Optionally, the MLD upper MAC sublayer delivers the BA record on one link to the MLD lower MAC sublayer of other links) - For the MLD lower MAC sublayer: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD upper MAC sublayer). Optionally, the MLD lower MAC sublayer receives from the the BA record on the other links from the MLD upper MAC sublayer) As these descriptions are the same, it seems that they are flexible enough to cover the implementation options. I suggest to change the more specific explanation text, in the paragraph after the bullets as shown: When MLO is being used, the “Block Ack Scoreboarding” block in the MLD upper MAC sublayer manages the overall Block Ack status of the MPDUs (of this Block Ack sessions established between two MLDs) that are received on any (all) setup links. Note that in an implementation, this function may be distributed into the MLD lower MAC sublayers for the links, by sharing the overall Block Ack status between all those scoreboarding blocks. The “Block Ack Scoreboarding” block in the MLD lower MAC sublayer manages at least the Block Ack status of the MPDUs (of this Block Ack session) that are received on this link. It may convey Block Ack status of the MPDUs received on another link if it obtained such info from the other link via the MLD upper MAC sublayer. The “Block Ack Scoreboarding” block in the affiliated AP upper MAC sublayer manages the Block Ack status of the MPDUs received over corresponding non-MLO links. In an implementation, this function may be distributed into the MLD lower MAC sublayer. And, as mentioned above, in the figures change all the blocks to simply say “Block Ack Scoreboarding”. Can we have agreement on this? Mark Hi Mark, Thanks for sharing the doc and for this further discussion. Several comments for further discussion: - I agree with Duncan argument that “ML BACK Scoreboarding” term in the upper MAC layer is misleading. I would suggest to designate it as “Optional: Block ACK Scoreboarding (merging)”. Are you OK with that?
- The “Merging” functional block in the “MSDU flow Receiving side” is vague/unclear. I would suggest to use “Link Merging” term that better explains what is merged here (as opposed to the TID-To-Link mapping functionality on the “MSDU flow Transmitting side”)
- I echo Stephen’s comment regarding the “PS Defer Queuing” functionality - I think that this should be placed only in the lower MAC layer (i.e. per each link).
Furthermore – I do not see any problem with assigning an SN to the individually addressed MPDU (in the upper MAC layer) and then queuing it in a specific buffer (per the link it is going to be sent) only if both conditions occur: (1)the non-AP STA affiliated with the associated non-AP MLD and operating on that link is in PS (2) and due to TID-To-Link mapping the MPDU can’t be transmitted on any other link. Otherwise – there is no PS queuing for that MPDU…. - According to Figure 4-30c, the upper MAC layer of the affiliated AP handles the group addressed MLD traffic. I think this is incorrect, since upper MAC layer of the AP MLD receives all the MLD data frames (from the DS) to include both those that will be sent as individually addressed MPDUs and those that will be sent as group addressed MPDUs. Then, once the upper MAC layer processes the group addressed frames it delivers them to the lower MAC layer of each link (to be authenticated with GTK/IGTK/BIGTK per that link) and then these MPDUs are further processed and passed to the PHY (per link) to be sent following transmission of DTIM Beacon frames.
(Note: this also applicable to MMPDUs sent as group addressed frames)
Consequently, the upper MAC layer of the affiliated AP processes only the individually addressed frames sent to the non-MLD non-AP STAs associated with that affiliated APs (and these frames are delivered from the DS to the affiliated AP directly).
Please revise the Figure 4-30c. - Does the NSTR mobile AP MLD architecture follow the Figure 4-30c or that of Figure 4-30d?
Could you add a note to clarify that point in the corresponding figure?
Thanks for your cooperation. Regards, Arik From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 12:36
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion Thanks for this discussion. Regarding the "PS Defer buffering", what does this have to do with SN/PN assignment? If an MPDU is deferred for PS reasons, this implies that the MPDU is assigned to a link in the upper MAC and is then buffered until the PS state of that link is ok to transmit the MPDU. This seems to break the MLO concept? Hi Mark, I echo Duncan and Po-Kai’s comment on the scoreboarding terminology. Full state is to keep all the statuses within the reception window from an initiator, while the record can be temporal in partial state. Best regards, tomo Hi, Alfred, If we can have just a few minutes (5-10) to discuss these topics on the morning call, I can get the document updated with any agreement, for consideration at a future call. Thanks. Mark [re-sending from gmail account] Thanks Mark, and all for working on these resolutions.
I scheduled the doc for SP/discussion tomorrow evening (MAC call) however if the preference is to have the discussion on the morning call we can try to find some time on that call.
Let me know. Regards,
Alfred
All, As there does not appear to be consensus on how to describe the Block Ack blocks (based on the comments on the call this morning, and now these comments on my proposed update), can I suggest that we have a quick discussion on this on the call tomorrow morning (U.S. time). Also, I am having a hard time figuring out how to sequence the SN and PN assignment versus PS queueing, for group addressed frames. In particular, we have existing text in D1.5 that says the AP MLD’s upper MAC sublayer will do the SN assignment, and then pass the frame to the affiliated AP(s) to be buffered and then do further processing/transmission. I think that causes issues with SN and PN ordering. Has this been covered in some other power save presentations/agreements (that perhaps I missed)? Does anyone have a clear view of how this is planned to work and/or is there agreement in the group? (I don’t think this is a significant change to my document, but there are details discussing this that need to be aligned to the correct operation). Perhaps this can be discussed quickly tomorrow morning, also? @Alfred Asterjadhi, I’ll look to your direction on how to proceed most efficiently for the group’s time. Thanks. Mark Hi all, I agree with Duncan that we do not need to create term like ML BA Scoreboarding and we also do not need say lower MAC is always partial state. Partial and full is just about whether your record is temporary or not, which is an implementation choice. The following text also seems to be enough, so do we really need to add more? · The MLD Upper MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links” · The MLD Lower MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer” Best, Po-Kai Hi Mark, Thanks for the updates. I do not think the BA scoreboarding changes are needed because D1.5 section 4.9.5 already describes the following: · The MLD Upper MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links” · The MLD Lower MAC sublayer functions: “Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer” The spec also has a NOTE saying “NOTE 2—The Block Ack scoreboarding maintenance collaborated between the MLD Upper MAC sublayer and MLD Lower MAC sublayer is implementation dependent.” So it’s clear how the MLD upper and lower layer collaborate is implementation dependent. Besides, the new term “ML BA Scoreboarding” could be misleading because a reader may try to find a section in the spec that describes how scoreboarding is done in the MLD while the Scoreboard Context procedures are well defined in REVme sections 10.25.6.3 (Full state) and 10.25.6.3 (Partial state) at the link level (not MLD level). Also whether to do Full or Partial state is a choice of the receiver (per REVme) so we should not mandate Partial BA Scoreboarding in the lower MAC. I believe the scoareboarding functionalities are mandatory for the lower MAC due to immediate BA but the BA scoreboarding-related functionalities in the Upper MAC should be optional. Thanks, Duncan WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. All, Here is some status update, and request for ongoing discussion on the architecture presentation from this morning (document 11-21/1111): · I removed the word “physical” from “physical links” in the text · I corrected the typo “the use of” · In Figure 4-30c, I am renaming “MLD lower MAC sublayer (MLD and legacy)” to just “MLD lower MAC sublayer”. This removes the “legacy” as correctly pointed on the call. However, this leaves the “MLD lower MAC sublayer” as the term for the shared component which is doing both MLD support and affiliated AP support. I note that this term is already in many locations in the draft, in clauses 4 and 5, so I proposed to keep it in the new figures to remain aligned. If there is concern with this use of the term, that can be a comment (on all the occurrences), on the next LB. Any disagreement? · I am taking the suggestions in the chat, and proposing to change the “Block Ack Scoreboarding” boxes in the figures, as follows: o For the upper MAC, in the MLD, it will say “ML BA Scoreboarding” o For the lower MAC, it will say “Partial BA Scoreboarding” o For the upper MAC, in the affiliated AP, it seems this is an implementation choice (is that right?), so how about “BA Scoreboarding (optional)”? o There was a request to add some clarification about these Scoreboarding blocks to the text. I suggest that would go just below Figure 5-2b, and I’ll work on that and remit shortly. Suggestions/contributions would be helpful! · For PS Defer buffering: o I think the conclusion/agreement on the call was that this is correct to be in the upper MAC (and above the SN assignment). Any disagreement? o Clearly, the label in the affiliated AP that says “AP MLD only” is just wrong. However, my latest understanding of how frame generation and routing needs to happen resulted in frames (such as Management frames, and group addressed Data frames) will need to be routed from the MLD upper MAC over to the affiliated upper MAC for SN/PN assignment and encryption, so the buffering for these frames needs to be merged with the buffering for “legacy” data frames, and it all needs to happen high in the affiliated AP stack. If this is agreed, then we need this block (in that location) in the affiliated AP upper MAC. I think that means just removing the “(AP MLD only)” text in all copies of this block, in the affiliated AP and the AP MLD. Agreed? o There was a request to add some more text to better clarify this PS Defer buffering. I think that goes just below Figure 5-2b, and I’ll work on that and remit shortly. · Figure 5-2b should be clarified with labels for the AP MLD and affiliated APs. The figure is already too complicated, so I do not want to add the outlines shapes, like Figure 4-30c. I suggest maybe just braces across the top of the figure, saying “Affiliated AP” and “AP MLD”? That is slightly misleading in that it is really only correct for the upper MAC sublayers, but would imply it carries into the lower MAC, also. But, I think it’s the best alternative. Comments or other thoughts? Thanks. Mark
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
-- Qualcomm Technologies Inc. Office #: +1 858 658 5302
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
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
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 |