Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Duncan,
Thanks. Please find my response inline. Regards Guogang Huang 发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
HI Guogang, Thanks for your comments. Please see my responses inline below. From: huangguogang <huangguogang1@xxxxxxxxxx>
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.
[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.
[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.
[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.
[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.
[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!
[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>
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 |