All,
Two comments, then:
- It seems that the TID-to-link mapping (and re-mapping when things change) and the PS queuing are tightly integrated. That is, neither really happens before or after, or independently of, the other. So, maybe we need to combine these (or somehow otherwise show them as tightly integrated).
- All this (this whole email thread) makes me agree with Mike that I don’t think we have agreement on the technical details for this.
Hence, I am inclined to not try to resolve exactly how PS Queuing works as part of resolving the CIDs in 11-22/1111. Given that the “baseline” for 11-22/1111 is really TGbe D1.5, I propose that what is in D1.5 is considered “correct” for the purposes of applying changes to resolve the CIDs. D1.5 shows PS Queuing in the MLD upper MAC sublayer, and near the top of that sublayer’s stack up. I suggest 11-22/1111 continue this, and mirror it in the affiliated APs. Those who have comments on this (and clearly there are several members that have such comments), can comment on the LB.
This is how I will proceed, for the sake of getting to a SP, unless anyone has a much better idea very quickly.
Mark
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 12:54 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
Hi Mike, Mark, All,
The buffering would occur at the MLD level. Let me try to explain: if all the STAs of the non-AP MLD, that are operating on the link to which a certain TID is mapped to, are in PS mode, then the AP MLD would need to buffer the MPDUs belonging to that TID. The traffic indication on all the links reflect the buffer status at the MLD. Therefore the TIM bit in the beacons on all the links will indicate BUs for that non-AP MLD (this is covered in the current spec).
I propose moving the PS Queuing block below the T2LM block (as shown below). This can address some of the concerns expressed in previous emails. Operation wise, the transmit side would decide to buffer after T2LM block if all the link to which the TID is mapped to are in doze state. If any link wakes-up, the packets belonging to that TID are flushed on that link.
Please let me know your thoughts.
Regards,
Abhi
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, May 12, 2022 10:22 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thanks Arik,
So Mark,
So based on Arik's comment, I'm wondering whether we should move the PS Deferral Queuing to the lower MAC, but I think it's important to add some text to describe that PS state transitions and link selection is managed in the upper MAC, but queuing is done in the lower MAC (or something like that).
At this point, I suspect the PS discussion will continue into the next round of comment resolution.
Cheers,
Mike
On Thu, May 12, 2022 at 1:04 PM Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Mark,
Thanks for your respond.
Please see my inline further comments.
Regards,
Arik
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 17:55
To: Arik Klein <arik.klein@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion
Arik, Stephen, and all,
I believe the current architecture view (in D1.5) was derived to support the ability to retry frames on any link. That is, an MPDU is prepared for transmission (SN assignment, PN assignment, and encryption) in the upper MAC sublayer, so that the resulting frame can be “moved” between links if a transmission on one link fails and an alternate link is selected for the retry. Further, the upper MLD sublayer is the holder of the PTKSA, which also puts the encryption block into the upper MAC sublayer, and therefore the SN and PN assignment (which are before encryption) are in the upper MAC sublayer.
Any disagreement on this point?
If we are good with that, then the question remaining is about where the PS queuing can happen. Since different links (with the same peer MLD) can change power save state independently, and the MLD is expected to send (individually addressed) MPDUs over any link that is not in PS mode, don’t we have to have the PS queuing happen at the MLD level (and only happens when all links to the given peer MLD are in PS mode)?
[Arik Klein] This is not the only case of PS queuing. Please note that the TID-To-Link mapping function can also impose limitation to send an MPDU on specific link which is not in PS mode, so in this case you also have to buffer that MPDU (For Instance: AP MLD has 2 links. The non-AP STA affiliated with non-AP MLD and operating on link 1 is in PS mode and according to TID-TO-Link mapping TID1-TID6 are mapped only to Link 1. That means that an MPDU corresponding to TID1-TID6 can’t be sent to this non-AP MLD as long as the non-AP STA operating on link 1 is in PS mode and hence these MPDUs shall be buffered).
Anyway – this decision must happen after the TID-To-Link mapping block which simply means that it is done per link, once the Transmitting side has decided that the MPDUs can’t be sent on any other link than the current link.
An aside: traditionally (since at least 2007) we have described PS queuing as happening before (above in the stack) SN and PN assignment and encryption – I believe there is some case where the SN or PN will get out of order if we don’t do that, but I’ve lost track of the details on this discussion (from 15 years ago!). Does anyone remember?
[Arik Klein] When you have a single link – this is correct, but in MLD case we want to avoid the PS queuing as much as possible – by sending the MPDU through any of the link as long as it is possible (one of the main benefits of MLO feature!!). So, there is distinction in functionality between upper MAC layer and lower MAC layer and in this case the consideration should be different.
As to your concern of SN/PN order – please note that this issue already exists in MLD case even if none of the affiliated non-AP STAs is in PS mode and the Transmitter sends subsequent MPDUs on different links - the order of their reception on each link is independent in the order they were transmitted…..I see no big issue in the PS queuing in that sense.
Mark
From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 4:41 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
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
Mark,
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?
Kind regards
Stephen
On Thu, 12 May 2022 at 03:44, Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx> wrote:
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
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, May 12, 2022 7:51 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
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
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 4:36 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: TGBE <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
[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
On Wed, May 11, 2022 at 3:31 PM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
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
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 2:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
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
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Wednesday, May 11, 2022 12:13 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion
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
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 10:46 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-21/1111 further discussion
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
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
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