Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Philip, Thanks for your questions and please see my responses inline below. From:
杨云朋 <yangyunpeng@xxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Dear Duncan: Thank you for preparing these Drafts. Please find my comments as below: In PDT part4: 1.Before the ST preparation request,
The network prepares these AP MLDs with minimal context such as security keys and expected TA.
Why can't the preparation procedure and execution procedure be combined? This approach seems to be more efficient. [DH] Please check my previous email reply to Haorui, which answered this very same question. 2.
For emergency roaming, can we handle different TID data differently? For instance, high-priority data can be routed through Target AP MLD for roaming, while low-priority
data can continue to be transmitted through Current AP MLD. [DH] My assumption is if a non-AP MLD performs emergency roaming, it means its link with the current AP MLD is not good and that’s the reason I do
not allow DL data drain through the current AP MLD in emergency case. The non-AP MLD should just focus on communicating with the target AP MLD asap. If the link with the current AP MLD is good, we already support TWO ways (via the current AP MLD and via the
target). In PDT part 5:
[DH] The AID is optional exactly because of the reason you mentioned. It shall NOT be included if the ST prep resp failed, right?
[DH] That is correct. The DL data status is an FYI from the current AP MLD to the non-AP MLD. The early termination decision is still up to the non-AP
MLD. Of course if the current AP MLD indicates all DL data is completed, it is likely the non-AP MLD will early terminate the DLDrainTime.
[DH] The ST prep response already includes the accepted SCS, anything SCS Not listed are not set up. Do you expect BA status will fail during preparation? Thanks, Duncan 祝工作顺利! =========================================================== Philip Yang
杨云朋 Mail:
yangyunpeng@xxxxxxxxxxxxxx Tel: 15620949838 发件人:
Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Dear Seamless Roaming TTT, I’ve prepared these documents for the ad-hoc meeting next week. Could you please let me know if you have any comments or questions? 25/753r2
PDT MAC on Seamless Roaming Part 3 (Security) – the r1 was presented before so this is an updated version 25/1020r0
PDT-CR MAC on Seamless Roaming Part 4 (Emergency roaming) – not presented before 25/1101r0
PDT-CR MAC on Seamless Roaming Part 5 (Detailed frame formats and signaling)
– not presented before 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 |