Re: [STDS-802-11-TGBN] Request to defer SP on 26/1704

["Kerstin Johnsson (Nokia)" <000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx>]

Hi Guogang,

Thanks for getting back to me on this. I think we may be talking about slightly different things...

I agree that the target AP MLD should not transmit on TID x or TID y until:

1. the non-AP MLD has passed the buffered MSDUs/A-MSDUs for those TIDs to the next MAC processing, and 
2. the non-AP MLD has indicated termination of the DL draining period.

My question was about the corresponding normative requirement on the non-AP MLD. In other words, I think the normative text should capture the following logical sequence:

non-AP MLD: pass buffered MSDUs/A-MSDUs onward → send DL Draining Completed = 1

target AP MLD: receive DL Draining Completed = 1 → may transmit TID x/y

As I read the current proposal, it specifies the target AP MLD behavior, but not the corresponding non-AP MLD behavior. So, in §37.16.10, p. 408, line 33, I would propose adding the first bullet below:

When the DL draining period terminates:

• The non-AP MLD shall pass all MSDUs or A-MSDUs buffered in the receive reordering buffers for all TIDs to the next MAC processing.
• The non-AP MLD shall send a UHR Link Reconfiguration Notify frame to the target AP MLD with the Type field set to 2 and the DL Draining Completed field set to 1 to indicate termination of the DL draining period (see 9.6.43.4 (UHR Link Reconfiguration Notify frame format)).
• The non-AP MLD should send a UHR Link Reconfiguration Notify frame (as an Action frame or as an Action No Ack frame) to the current AP MLD with the Message Type field set to 2 and the DL Draining Completed field set to 1 to indicate termination of the DL draining period (see 9.6.43.4 (UHR Link Reconfiguration Notify frame format)) if the non-AP MLD has not received from the current AP MLD a UHR Link Reconfiguration Notify frame with the Message Type field set to 2 and the DL Draining Completed field set to 1.

I also agree with your simplified solution of using all TIDs rather than only TID x and TID y.

Hope this clarifies what I meant.

Best regards,
Kerstin

From: huangguogang <huangguogang1@xxxxxxxxxx>
Date: Tuesday, October 6, 2026 at 06:15
To: Kerstin Johnsson (Nokia) <kerstin.johnsson@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: 答复: [STDS-802-11-TGBN] Request to defer SP on 26/1704

Hi Kerstin,

 

Thanks for your discussion. Please find my response inline.

 

 

Regards

Guogang Huang

发件人: Kerstin Johnsson (Nokia) [mailto:kerstin.johnsson@xxxxxxxxx]
发送时间: 2026年10月1日 9:29
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Request to defer SP on 26/1704

 

Hi Guogang,

 

This is the last one, CID 19891:

 

In the SCS-remapping case, the proposed text says the target AP MLD has to wait until the non-AP MLD has passed the buffered MSDUs/A-MSDUs for TID x and TID y to the next MAC processing and indicated DL draining completion. But in D2.0 §37.16.10, when the DL draining period terminates, the non-AP MLD is required to send the completion indication; I don’t see a requirement for it to first pass all buffered MSDUs/A-MSDUs for those TIDs onward. 

 

Do we need to add that requirement before the non-AP MLD sends DL Draining Completed = 1, or is it covered somewhere else?

[HGG]This requirement is needed. When the non-AP MLD indicates the DL draining completion, it doesn’t mean all the MSDU or A-MSDUs buffered at the receive reordering buffer has been passed to the next MAC processing. In some case, it still will cause the out-of-order delivery. That’s why I add this requirement, i.e. before sending the indication of the DL draining completion, the non-AP MLD shall pass the buffered MSDUs/A-MSDUs for TID x and TID y to the next MAC processing. BTW, a simplified solution is to say the non-AP MLD shall pass the buffered MSDUs/A-MSDUs for all the TIDs to the next MAC processing.

 

 

BR,

Kerstin

 

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, September 29, 2026 at 05:00
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] Request to defer SP on 26/1704

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Hi Binita and Kerstin,

 

Yes, I can defer my SP.  Could you please let me know when you want to defer it to? Hope you can share your comments as soon as possible. I plan to run the SP before October 15. Thanks!

 

 

Regards

Guogang Huang

发件人: Kerstin Johnsson (Nokia) [mailto:000039130cefe96b-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2026年9月29日 7:34
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Request to defer SP on 26/1704

 

Ditto.  Thanks!

 

From: Binita Gupta <bingupta.ieee@xxxxxxxxx>
Date: Monday, September 28, 2026 at 16:33
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] Request to defer SP on 26/1704

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Hi Guogang,

Could you please defer any SP on 26/1704 (if planned).

 

Need more time to review the document, and I won't be able to dial into the TGbn meeting today.

 

Thanks,

Binita

---

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

---

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

---

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

---

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1