| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ming, Thank you for revising the text based on our inputs. The updates look good. I have a comment related to CUF being set to 1 in DTIM beacon. Current text in the spec: “An AP shall provide this indication in the Beacon frame(s)
until (and including) the next DTIM Beacon frame on the link that the AP is operating on.” Proposed text: “Set the Critical Update Flag subfield of the Capability Information
field to 1 in the Beacon frame(s)
until right after the next DTIM Beacon frame on the link on which
the AP is operating if there ” The Capability Information field is carried in a Beacon frame; therefore we can refer to a particular Beacon frame – rather than say ‘right after’ In the past, the group had debated the text for this paragraph and what appears in the current spec is a result of that discussion so that the intended meaning is unambiguous.
Why not keep the existing text from D0.4? Regards, Abhi From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
CAUTION:
This email originated from outside of the organization. Thanks Abhi, Gaurang and Laurent Please take a look at the update version for 621 and please see my response inline Best wishes Ming Gan 发件人:
Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
Hi Ming, Laurent, Please find my comments in the attached files.
In summary:
-
Suggest using a name that is more representative of the feature [Ming] adopted
-
Like the idea of setting the CUF flag when the counter for the Tx-ing AP is incremented [Ming] good
-
Suggest keeping the original text for advertisement of CUF frame (i.e., replace after with “until (and including)” [Ming] how about “until right after…”? just make this clear.
Doc 622:
-
Strongly against mandating non-AP to wake-up on the affected at the next TBTT
o
Putting such requirement will have adverse effect on client power-save
o
In favor of uniform rules for single radio and multi-radio devices
o
There can be cases where the client is not be interested in operating on the affected link
§
So forcing it to wake-up on the affected link is unproductive
-
Suggest to go with the approach where the reporting AP transmits an unsolicited broadcast probe response frame carrying the updated parameters
of the affected link
o
This approach will satisfy all requirements:
§
Aids non-AP power-save operation
§
Prevent beacon bloating
§
Present probe storm
§
Works for both single and multi-radio clients [Ming] since the critical update is not frequent and the minor power consumption for beacon reception , I
hardly buy the argument related to power consumption. Since Multi-radio MLD and single radio MLD have different Capabilities, it is reasonable to discuss them separately. Otherwise, it is not clear and may result in some issue. Regarding unsolicited broadcast
probe response (periodic? ), I would like to say it is worse than carrying the critical update parameters directly in the Beacon frame. Otherwise, it wastes the medium. I suggest to follow the baseline such that to receive the corresponding beacon frame. Regards, From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
CAUTION:
This email originated from outside of the organization. Thanks See attached. Btw, new comment on 621. Thanks Laurent From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Hello Laurent Thanks for your comments, please see the attached response. Best wishes Ming Gan 发件人:
Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
Hi Ming, Thanks for the docs. See attached some comments and suggestions. Thanks Laurent From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Hello Alfred Please kindly add the following contributions into the agenda, thanks. 11-21-0621-00-00be-TBD and CR for BSS parameter critical update procedure 11-21-0622-00-00be-TBD and CR for critical update for non-AP STA best wishes Ming Gan 发件人:
Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
Hello all, I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday,
March 29 (MAC/PHY), 19:00-22:00 ET and Wednesday, March 31 (JOINT), 10:00-12:00 ET. The agendas can be found here: DIAL IN DETAILS FOR MONDAY: Join the MAC meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=mbd4d14147200be961d4e3116e31014cd Meeting number: 129 198
8903 Meeting password: wireless (94735377 from phones and video systems) Join the PHY meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=mb06c29f2edb965c7eda50ba5297ab35f Meeting number: 129 838 2049 Meeting password: wireless (94735377 from phones and video systems) DIAL IN DETAILS FOR WEDNESDAY: Join the JOINT meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m36eaaf5c7ffd0992351cc1300198e104 Meeting number: 129 280 7580 Meeting password: wireless (94735377 from phones and video systems)
Notice: Please note that by now all authors of the submissions for PDTs and CRs (especially MAC) should have sent requests for feedback to the IEEE TGbe reflector. Members are invited
to provide feedback for these contributions prior to the conference call via e-mail so that the time in the conf calls is used efficiently. Best Regards, Alfred -- Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 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
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 |