| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Arik, At the risk of opening up the PS queuing discussion here, I’ll respond to your text in red, that the reason we have group addressed MPDUs destined to non-AP MLDs in the MLD upper MAC sublayer of the affiliated APs, is exactly because we think/thought (are debating) whether these frames must be PS queued, assigned numbers, and encrypted, in the affiliated AP’s upper MAC. If that is required (due to reasons such as are being discussed in the other thread), then we end up with the affiliated AP’s upper MAC handling some of the processing of these group addressed frames, and that is why the label in Figure 4-30c is that way. So, we need to settle that discussion, and then we can go back and update the high-level descriptions in 4-30c to match. Mark From: Arik Klein <arik.klein@xxxxxxxxxx> Hi Mark, Thanks for the response. Please see my further inline response. Regards, Arik From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx> Arik, Please see separate email threads for the Block Ack description, and for the placement/ordering of the PS queuing. I have responses on the rest of your comments, below. 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:
[[MAH]] I’ll note that this is not changed from the D1.5 text – just redrawn to separate the TX and RX directions. However, I am fine with this change, if nobody has any objection.
[[MAH]] This is a side-effect of the discussion (in the other email thread) about the placement of PS queuing, SN/PN assignment and encryption. The discussion had been that these functions needed to be in the upper MAC sublayer, and hence for group addressed frames the MLD upper MAC sublayer can only process the frames (which it receives from the DS, as you correctly noted) to a certain point, and then it needs to “pass” those frames to the affiliated AP’s upper MAC sublayers for the PS/PN/SN/encryption steps. Let’s let that discussion resolve, and then decide this point. [Arik Klein] I do not see it as a side effect of the PS Queuing discussion on other thread. The point is that upper MAC of the affiliated AP only deals with the MSDUs that are transmitted to the non-MLD non-AP STAs (as either individually addressed MPDUs or as group addressed MPDUs). Therefore, IMHO, the group addressed MPDUs that are destined to the non-AP MLDs shall be handled only through the upper MAC Layer of the AP MLD.
[[MAH]] I have no idea! I’d need someone with expertise in mobile AP to provide a proposal. I believe this goes beyond the scope of the CIDs I am trying to resolve. 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 |