| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Abhi, Thanks for your response. In some case, e.g. enterprise WLAN with the deployment of the timing protocol (802.1 AS), it is possible to provide the accurate TSF
value of the neighboring AP MLD. The network can provide a bit indication to tell the non-AP MLD whether the AP MLDs in the SMD have the same timestamp or not. For example, we can add a bit within the SMD Information element to signal it. This will help the
non-AP MLD to know the exact time point when these updates (e.g. link disablement or AP PUO) take effect.
Regards Guogang Huang 发件人: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi All, Thank you to the members who have provided offline feedback on 1826. I am working on incorporating your inputs. In the meantime, I want to respond to a couple of comments that were made during the call regarding timing accuracy and the actions taken by the non-AP MLD: The purpose of the proposal is to define a framework that allows a current AP MLD to inform the non-AP MLD about important updates occurring at a prepared target AP MLD. Since the AP MLDs are
not collocated and the information is exchanged over a backhaul network, the timing of these updates cannot be exact. The mechanism is therefore best effort and is not intended to provide precise timing guarantees. The goal is simply to ensure that the non-AP
MLD is aware that a significant change has happened or will happen at the target AP MLD so that it can make informed roaming decisions. The specification should not define required behavior for the non-AP MLD. It should be left to the device implementation.
For example, if the serving AP MLD reports that a link at the target MLD will be changing channel in a certain number of beacon intervals, the non AP MLD can choose to avoid executing on that link (i.e., select a different link), pick a different target, or
wait longer before executing on the same link. Regards, Abhi From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Hi All, Thank you for the discussion during today’s call regarding critical updates occurring after preparation. I am initiating this email thread to continue the conversation and track the open items from today’s call in
1826. When providing feedback or updates, please refer to the latest version of the document: Please feel free to add comments directly in the doc or reply to this thread. Regards, From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Roaming TTT members, I have revised the resolutions for the pending CIDs in doc 1826 to include a procedure for handling critical updates at a target AP MLD after ST preparation and before ST execution. The proposed
procedure reflects the discussions from the Nov f2f meeting. Could you please review the proposed resolutions (starting on page 9) and let me know if you have any additional comments or suggestions? Hi
@Alfred Asterjadhi, can you please help add the above doc to the TGbn MAC agenda for running SP on the pending CIDs?
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 |