[STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi everyone,

To Guogang: your proposal on M-BA for Dl Drain period termination is not precluded in any way in 26/0170. Perhaps you could consider submitting your original contribution for this? I am not sure why this is becoming the centerpoint of the discussion on 26/0170.

On the actual centerpoint of this discussion, which is on State 4b and disallowing UL to current during execution: to me it is clear that the assumption is in distributed SMD (multiple MAC SAP) the DS mapping change is already allowed to start as soon as ST execution request is received, see below:

Therefore mandating UL to current AP MLD to be interrupted when ST execution request is issued is just an exercise of closing spec and removing bugs at this point.

The DS mapping change occurring at a flexible time and as soon as ST execution request reception has been in TGbn spec for long time (see blue highlights).

Now considering that spec already allows a flexible timing for DS mapping update, not clarifying the UL stop in this case is setting a very dangerous precedent: the client may keep enqueueing UL MPDUs that cannot be delivered to the DS! This means loosing more MSDUs, which shall be avoided.

On the other hand 26/0170 in single MAC SAP Ul to current is allowed since the MAC SAP is single. Let’s stick with the already specified design principles and avoid flipping an already quite complex feature on its head.

Best,

Giovanni

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, March 5, 2026 8:39 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Duncan,

I would like to add another point.

The main reason for that ‘should’ requirement is we cannot mandate the non-AP MLD to send the UHR Link Reconfiguration Notify frame. Because the link between the current AP MLD and the non-AP MLD may be disconnected suddenly due to the non-AP MLD’s moving or the blockage. As long as the link is reachable, the non-AP MLD is better to notify the termination of the DL draining period by sending the UHR Link Reconfiguration Notify frame or the M-BA frame with the feedback of the DL draining termination, rather than roam to the target AP MLD without any notification to the current AP MLD. Otherwise, to reduce or avoid the packet loss, the current AP MLD shall forward lots of MSDUs or A-MSDUs which are needed to the target AP MLD and the target AP MLD shall retransmit these MSDUs or A-MSDUs in the same manner (i.e. same aggregation manner, same SN, same PN) as the current AP MLD. As I mentioned before, the A-MSDU forwarding is hard to realize. If the current AP MLD doesn’t support the A-MSDU forwarding, then lots of packets are lost during the SMD BSS transition.

Anyway, if we don’t allow the non-AP MLD as a TXOP holder to terminate the DL draining by using the M-BA, then the non-AP MLD cannot timely terminate the DL draining according to the DL link quality. This will also cause lots of MSDUs or A-MSDUs are needed for retransmission. What’s worse, the A-MSDU forwarding is hard to realize.

Regards

Guogang Huang

发件人: huangguogang
发送时间: 2026年3月6日 6:57
收件人: 'Duncan Ho' <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: 回复: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

Correct a typo.

Hi Duncan,

Thanks for your response. Please find my response inline.

Regards

Guogang Huang

发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
发送时间: 2026年3月6日 3:23
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

Hi Guogang,

Thanks for your feedback.

State 4b is to allow the DS mapping update to be performed by the network as soon as possible to avoid further DL data from the DS directed to the current AP MLD whose links are likely deteriorating. Any UL data to the current AP MLD after the ST execution request will delay and undo the DS mapping update, which will delay the whole ST execution. Therefore the UL data shall be suspended after the ST execution request.

[HGG]In my mind, there is no big difference between the following two cases, as shown in the below figure. They have the same time point to change the DS mapping.

Re 5017, the design of the non-AP MLD to send a UHR Reconfig Notify frame has always been a best-effort “goodbye” from the non-AP MLD to the current AP MLD. That allows the current AP MLD to clean up its states earlier (than an implementation timeout or backhaul indication from the target AP MLD). Given that the links to the current AP MLD are likely deteriorating at this stage, we do not want to mandate the non-AP MLD to stay with the current AP MLD just to send this Notify frame, which will delay roaming to the target. That’s why we ended up with a “should” requirement to leave it up to non-AP MLD’s discretion whether to send this Notify frame.

Given that this is a best-effort frame to begin with and given we already have defined this Notify frame, I do not see a need for defining yet another way to indicate the same in a best-effort manner.

[HGG]What I proposed is also NOT mandatory. Even this is a best-effort requirement or behavior, we still can improve it. I totally cannot agree your logic. Just consider the following scenario. The non-AP MLD as a TXOP holder directly roams to the target AP MLD without sending the termination indication. Then the current AP MLD continues to transmit the DL data to the non-AP MLD and fails to receive the BA frame. In this case, the current AP MLD shall forward these MSDUs/A-MSDUs which are needed for retransmission to the target AP MLD based on the current draft text. As we explained, the A-MSDU forwarding is hard to realize. We should avoid the A-MSDU forwarding as much as possible. The non-AP MLD should notify the current AP MLD the termination of the DL draining period. So I don’t agree there is no need to allow the non-AP MLD as a TXOP holder to terminate the DL draining period.

Thanks,

Duncan

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, March 5, 2026 2:57 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Duncan and all,

Thanks for preparing this CR document. For this CR document, I have two main concerns.

Firstly, we don’t think it’s over-designed to introduce State 4b, which will complicate the state machine and the benefit is very limited. The non-AP MLD can take the time needed for the DS mapping change into account and initiate the transmission of the ST execution request a little bit in advance. I’m not convinced of the argument the current AP MLD shall immediately initiate the DS mapping change when it receives the ST execution request, otherwise the DL data keep going to the current AP MLD and the current AP MLD cannot accurately estimate the Nominal Maximum DL Draining Period Duration. This estimation is hard to implementation which depends on many factors, e.g. client’s moving speed, channel contention and so on. So I suggest to keep the state machine simple and the non-AP MLD suspends the UL data transmission only when it receives the ST execution response with SUCCESS. After the UL data is totally delivered to the DS, then the current AP MLD initiates the DS mapping change.

Secondly, for the resolution to CID 5017, we should allow the non-AP MLD as a TXOP responder can timely terminate the DL draining period through a new feedback type carried within the M-BA frame even it is participating the DL reception. Please find the details attached. It can effectively avoid the following case: the current AP MLD forwards A-MSDUs which are needed for retransmission resulted from the poor link quality of the current AP MLD. As I mentioned in my contribution, The A-MSDU forwarding is hard to realize. Then lots of data packets will be lost during the SMD BSS transition. In this case, how can we call it as seamless roaming? So the non-AP MLD tends to terminate the DL draining period when there is no “hole” in the reordering buffer if the data forwarding is supported.

All - please review changes proposed in the attached and I would like to discuss integrating these changes in one combined doc.

Regards

Guogang Huang

发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
发送时间: 2026年1月15日 1:33
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

Hi Gougang and seamless roaming TTT members,

Guogang, let’s discuss in person and I’ll explain further. In the meantime, I’ve updated Figure 11-23 per your request.

Seamless roaming TTT members, any feedback on the attached is welcome. I’m in Victoria and I’ll be happy to discuss with you in person as well.

Thanks,

Duncan

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, January 13, 2026 11:05 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Duncan,

Thanks for your response. Please find my response inline.

Regards

Guogang Huang

发件人: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2026年1月14日 13:20
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

Hi Guogang,

Thanks for your comment. Please see my responses inline below.

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Tuesday, January 13, 2026 12:06 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Duncan,

Thanks for preparing this CR document. One question regarding when to suspend the UL data transmission, I think the following two sentences are conflicted or misaligned with each other. We should define that the non-AP MLD shall not transmit any Data frames to the current AP MLD upon successful reception of the ST execution response with the Status Code field set to SUCCESS if the SMD Type field in the SMD Capabilities field in the SMD Information element (see 9.4.2.356 (SMD Information element)) is equal to 0.

[DH] If we follow the above, the UL suspension would be too late. Since the DS mapping may be updated anytime between the ST execution request and ST execution response, if we allow UL to the current AP MLD this time, any UL packets forwarded to the DS from the current AP MLD will undo the DS mapping update and the DS will point back to the current AP MLD.

[HGG]I agree that the UL transmission shall be suspended first. After that, the current AP MLD informs the target AP MLD to update the DS mapping and initiates the dynamic context transfer. For simplicity, we should define as the above mentioned. I don’t see any issue.

(#5017)Upon successful transmission of the ST execution request, the non-AP MLD shall not transmit any Class 3 frames to the current AP MLD if the SMD Type field in the SMD Capabilities field in the SMD Information element (see 9.4.2.356 (SMD Information element)) is equal to 0.

[DH] This condition should be correct, per my explanation above.

[HGG]It’s a little over-design. Before receiving ST execution response with SUCCESS, the non-AP MLD keeps in state 4 with the current AP MLD. Considering this, the non-AP MLD should be allowed to exchange data with the current AP MLD, regardless of the DL data or the UP link. Please update Figure 11-23―Relationship between state and services between a given pair of nonmesh STAs to accommodate SMD transition.

(#5017)Upon reception of an ST execution response frame with the Status Code field not set to SUCCESS from the target AP MLD, all Class 3 frames shall be allowed between the current AP MLD and the non-AP MLD.

[DH] This is the case when the non-AP MLD receives an ST execution response with some kind of failure (i.e., ST failed), we allow the non-AP MLD to resume UL tx with its current AP MLD.

Thanks,

Duncan

Regards

Guogang Huang

发件人: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2026年1月12日 0:30
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes

Dear Seamless Roaming TTT members,

I’ve drafted this CR to address the UL data suspension and MLD state change. Could you please review it and let me know if you have any feedback?

Hope to see you in Victoria!

BR,

Duncan

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

[STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] CR for seamless roaming UL suspension and state changes