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
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