| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ming, TIM broadcast (11.2.3.15) is an existing (legacy) power-save operation. A STA_1 of a non-AP MLD can (independently) negotiate TIM broadcast operation with the AP_1 on its link. In such case, STA_1 is not monitoring the Beacons on its link as defined in 11.2.3.15. The
other STAs of the non-AP MLD can be in doze state (independently). The 11be spec needs to provide a mechanism for the AP_1 to indicate (via Check Beacon field) if the STA_1 needs to listen to the next beacon. Therefore, modification to the ML IE would qualify as
a critical update to increment the Check Beacon field. Without this, the baseline broadcast TIM operation would be broken. Let me provide an example: A non-AP MLD performs ML setup with the AP MLD for two links. The STA_2 on link 2 is in doze state for a prolong period of time. STA_1 on link 1 is performing broadcast TIM operation with AP_1 and
not monitoring the beacons on link 1. If there is a change to the ML IE (e.g., link 2 is advertising Quiet IE), how would the non-AP MLD come to know about the change?
>> Note per STA profile carries lots of normal parameters, not critical ones. Per-STA profile can carry critical parameters as covered in 35.3.9 (eCSA/Quiet). This is where the increment to Check Beacon field will trigger the STA to check the Beacon on its link and receive
the update for another link. NOTE, as I mentioned in my email below, modification to ML IE must not cause the CSN to increment. Regards, Abhi From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx> Thanks Abhi I can not the follow the below part The MLO spec allows a non-AP MLD to monitor a single link and perform existing power-save operations such as negotiating TIM broadcast. Therefore, if there is an update
to the ML IE, a STA of a non-AP MLD must be prompted to go look for changes in the Beacon frame. Therefore, modifications to the Basic variant of ML IE must be added to clause 11.2.3.15 as a qualifier to increment Check Beacon field You know, ML IE contains the repeated info carried in the beacon sent by each AP. Why could you classify this modification as a qualifier to increment Check Beacon field? For legacy STA？Does
legacy STA care about the change of the other AP. Note per STA profile carries lots of normal parameters, not critical ones. Best wishes Ming Gan 发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
Hi All, During yesterday’s 11be MAC call, while discussing doc 11-21/0252, a few members had expressed concerns on the inclusion of the Basic variant Multi-Link element in the list
of events that qualify as critical updates (clause 11.2.3.15). I am initiating this thread to provide more details on the motive and answer any questions on the topic. Broadcast TIM is a legacy feature meant to facilitate power-save operation on client devices. An interested clients can negotiate with the AP to broadcast TIM frames. The
client is not required to monitor the beacon frames when operating in this mode (aids power-save). Furthermore, the client receives traffic indication and TSF information via the TIM frames. The TIM frame carries a Check Beacon field, which increments if there
is a BSS parameter update. An updated value of Check Beacon is an indication to the client to listen to the next the beacon frame to receive the new parameter. The MLO spec allows a non-AP MLD to monitor a single link and perform existing power-save operations such as negotiating TIM broadcast. Therefore, if there is an update
to the ML IE, a STA of a non-AP MLD must be prompted to go look for changes in the Beacon frame. Therefore, modifications to the Basic variant of ML IE must be added to clause 11.2.3.15 as a qualifier to increment Check Beacon field With respect to MLO operation, since the contents of the common portion of the ML IE are same across all links, a change to the Common Info field must not qualify as a criteria
for incrementing the CSN for the reporting AP. If CSN were to be incremented, all links would report an update – which is undesirable.
Similarly, a change to the per-STA portion of the ML IE must not cause the CSN to increment since the content in the per-STA profile applies to another AP of the AP MLD.
In this case too, the CSN for the reporting AP must not be incremented. Therefore, modification to Basic variant ML IE must qualify as a critical update in clause 11.2.3.15 (which results in Check Beacon field being incremented). However it
must not qualify as a criteria for incrementing the CSN for the reporting AP. Please let me know if you have a different view on the topic.
Happy to discuss further. Regards, Abhi To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |