| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, Thanks for your respond. Please see my inline further comments. Regards, Arik From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
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).
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.
Mark From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Mark, Thanks for sharing the doc and for this further discussion. Several comments for further discussion:
Thanks for your cooperation. Regards, Arik From: Stephen McCann <mccann.stephen@xxxxxxxxx>
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:
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 |