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

[STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] Seamless roaming PDT Part 5 r1 (signaling format details)



Hi Duncan,

 

Thanks. Please find my response inline.

 

 

Regards

Guogang Huang

发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
发送时间: 2025729 5:26
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBN] Seamless roaming PDT Part 5 r1 (signaling format details)

 

HI Guogang,

 

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

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Monday, July 28, 2025 12:44 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject:
回复: [STDS-802-11-TGBN] Seamless roaming PDT Part 5 r1 (signaling format details)

 

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 PDT. I have several comments.

 

  1. Also need to define a SCS negotiation method by using ST preparation request/response to address the following case, e.g. the current AP MLD doesnt support the SCS mechanism, but the target AP MLD support the SCS mechanism.

[DH] In this case, the non-AP MLD should set up SCS with the target AP MLD using baseline SCS mechanism once ST is completed. No new mechanisms are needed.

[HGG]No. Why does the non-AP MLD need to set up SCS with the target AP MLD after the ST? The purpose of the roaming preparation is to set up the context with the target AP MLD. In addition, based on the following motion text, the SCS context should be renegotiated during the roaming preparation phase.

  1. There is no normative behavior when the DL BA Parameters Info is received by the non-AP MLD. It doesnt make sense to let the transmitter to decide the reordering buffer size of the receiver.

[DH] This may be a misunderstanding? There are baseline ADDBA requirements that requires the transmitter to adjust its own tx window so it does not to transmit more than what the receiver’s buffer size can hold. We just apply the same rules here. Since the non-AP MLD sends its rx buffer size to the current AP MLD (via the ADDBA response) and such info is context transferred to the target AP MLD during ST prep, the target AP MLD will have this info.

[HGG] I don’t see the need to tell the receiver that the transmitter’s TX window. And for the UL BA Parameters, the spec. should allow the non-AP MLD can indicate the expected UL BA parameters within the ST preparation request.

  1. For the following DL TID bitmap field, there is no text to describe the behavior of the current AP MLD for the TID with the corresponding bit equal to 0, especially when the data forwarding is supported.

[DH] This may be a misunderstanding?  If a bit position is set to 0, the non-AP MLD is not interested in that TID. For bits that are set to 1 the current AP MLD provides a binary info (complete or not complete) (complete means no more buffered traffic).

[HGG] What you said is the literal meaning. For the TID the non-AP MLD is not interested, should add the text to clarify, e.g. the current AP MLD forwards the corresponding data to the target AP MLD if the data forwarding is supported.

  1. Add the text to clarify the current AP MLD also can send a UHR Link Reconfiguration Notify frame to the non-AP MLD to terminate the DL data retrieval and indicate the reason code

[DH] This may be something that can be added later? The case most people care about is the AP MLD provides info and the non-AP MLD decides if it wants to early terminate the drain time.

[HGG] Should be addressed in this PDT. They are strongly correlated.  

  1. There is no need to do the context transfer and stop the UL data transmission when initiating the ST execution, or there is no roaming execution at all for the centralized SMD. Should signal the SMD Type within the SMD Information element.

[DH] This is part of the UL data tx TBD that I’m still trying to find convergence with others.

[HGG] Please include me for the discussion. Thanks!

  1. Should define DL Data Drain Info as an element and indicate the buffer size for each TID, rather than using a bit indication. This will help the non-AP MLD estimate whether to terminate the DL data retrieval.  

[DH] This idea was discussed before but there was not much momentum due to the complexity and it’s not clear whether any benefits justify the complexity.

[HGG] I didn’t involve this discussion at least. The benefit is the non-AP MLD can know how much data it needs to retrieve and make a better decision on whether to terminate the retrieval.  

 

Thanks,

Duncan

 

Regards

Guogang Huang

发件人: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2025729 0:27
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBN] Seamless roaming PDT Part 5 r1 (signaling format details)

 

Hi all,

 

I’ve updated the PDT Part 5 based on the comments I received during the MAC ad-hoc last week. The revision history in the doc gives a high level summary of the changes.

 

https://mentor.ieee.org/802.11/dcn/25/11-25-1101-01-00bn-pdt-cr-mac-on-seamless-roaming-part-5.docx

 

Could you please let me know if you have any questions or comments?

 

Thanks,

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