| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Jay, Thanks for your comments. Your proposal looks good to me and I’ve added it (except with “traffics” replaced by “traffic”). BR, Duncan From: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Ducan , Thanks for incorporating my suggestion. I think we need some text for the further clarification. See below proposed changed in red font, let me know your thought on this. - [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the next SN for existing DL BA agreement of all
TIDs (see 37.9.8 (Context)), the target AP MLD and non-AP MLD shall reset the SN to 0 for all the DL TIDs
before DL traffics delivery from the target AP MLD to the non-AP MLD . - [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the latest SN that has been passed up for existing
UL BA agreement of all TIDs (see 37.9.8 (Context)), the target AP MLD and non-AP MLD shall reset the SN to 0 for all the TIDs
before UL traffics delivery from non-AP MLD to the target AP MLD . Thanks Best Regards Jay Yang (杨志杰)
Original From: DuncanHo <dho@xxxxxxxxxxxxxxxx> To: 杨志杰10343608;00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx
<00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>; Date: 2025年04月19日
09:13 Subject: RE: [STDS-802-11-TGBN] Seamless roaming PDT + CR Part 1 - please review Hi Jay, Thanks for your comments and suggestions. Yes, the changes to the SN reset look good to me. Regarding the DLDrainTimer question, I added “…before the DLDrainTimer ends.” as a condition so if the DLDrainTimer is 0, that bullet cannot happen. I’ll add these changes to the next revision of the doc. Please let me know if you have any further comments. BR, Duncan From:
yang.zhijie@xxxxxxxxxx <yang.zhijie@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 the clarification in the attachment,but I still have the following two questions: - [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the next SN for existing DL BA agreement of all TIDs
(see 37.8.8 (Context)), the target AP MLD shall reset the SN to 0 for all the DL TIDs . [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the latest SN that has been passed up for existing UL BA agreement of all TIDs (see 37.8.8 (Context)),
the target AP MLD shall reset the SN to 0 for all the UL TIDs . For either DL TID or UL TIDs , both the target AP MLD and non-AP MLD shall reset the SN to 0 for either DL TIDs or UL TIDs . Precisely, the target AP MLD reset the SN to 0 for all the
DL TIDs , and the non-AP MLD reset the scoreboard to 0 for all the DL TIDs . Similarly, the non-AP MLD shall reset the SN to 0 for all the UL TIDs , and the target AP MLD reset the scoreboard to 0 for all the UL TIDs . Otherwise, there will be some synchronization issue on SN. How about the following change? [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the next SN for existing DL BA agreement of all TIDs (see 37.8.8 (Context)), the target AP MLD
and non-AP MLD shall reset the SN to 0 for all the DL TIDs . [M#351] If the non-AP MLD had requested its current AP MLD not to transfer the latest SN that has been passed up for existing UL BA agreement of all TIDs (see 37.8.8 (Context)), the target
AP MLD and non-AP MLD
shall reset the SN to 0 for all the UL TIDs . - [M#349] The non-AP MLD may provide an indication to the target AP MLD to indicate that the period of DLDrainTime is to be
terminated early. Whether the DLDrainTime can be equal to 0 in the ML reconfiguration request frame to indicate the immediately terminated after roaming successfully? Thanks Best Regards Jay Yang (杨志杰)
Original From: DuncanHo <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2025年04月17日
06:39 Subject: Re: [STDS-802-11-TGBN] Seamless roaming PDT + CR Part 1 - please review Hi Jay, Thanks for your comments and questions. I’ve addressed them in the attached and the changes are reflected in the latest -0566r1
here. BR, Duncan From:
yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Ducan , Thanks for your efforts, see my comments in the attachment. Thanks Best Regards Jay Yang (杨志杰)
Original From: DuncanHo <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2025年04月05日
10:10 Subject: [STDS-802-11-TGBN] Seamless roaming PDT + CR Part 1 - please review Dear Seamless Roaming TTT members, I’ve prepared
this PDT-CR Part 1 draft to address all the latest SR motions since D0.1 (i.e., all the SR Motions from Atlanta and Kobe) and 54 CIDs . I selected these CIDs because they are trivial or they are already covered by the passing motions. My hope is if we can get this Part 1 stabilized, it would be a good basis for addressing the rest of the CIDs in Part 2 and Part 3, etc. Could you please kindly review it and send me any feedback on or before 4/13? Thanks for your help! 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 |