Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Yanjun Thanks for hold on the following new added text for a while.
To indicate a puncturing pattern change for the current BSS operating channel, an EHT AP shall use an EHT Operation element or a Channel Switch Wrapper element
(see 35.15.3 (Channel switching methods for an EHT BSS)).
NOTE—The Channel Switch Count field in a Channel Switch Announcement element or an Extended Channel Switch Announcement element sent together with the Channel Switch
Wrapper element allows the AP to notify the associated non-AP STAs in advance about the upcoming puncturing pattern, so it is recommended to use the Channel Switch Wrapper element to indicate the puncturing pattern change.
Usually for important parameters change, it is covered by critical update procedure . Note that Modification of the EHT Operation element is a critical update event. Not sure why
we need “shall” requirement here, especially for Channel Switch Wrapper element. The new added note also looks weird, why do you use (recommend) “channel switch” procedure to notify puncturing pattern change?
Best wishes Ming Gan 发件人: Yanjun Sun [mailto:yanjuns@xxxxxxxxxxxxxxxx]
Hi Guogang, I haven’t got time to read 691r4 yet, but our proposal is on AP behavior and doesn’t seem contradicting with non-AP STA’s own choice that you mentioned. I’m not very clear about your comment on TPE. Option 1 below for EIRP is not using reserved bits due to back forward compatibility issue. Are you referring to the PSD related text? Let’s clarify during the call. Thanks Yanjun From: huangguogang <huangguogang1@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. For the Channel Switch Wrapper element, I still don’t think it is really needed. The simple way is to let non-AP STA to receive a new Beacon frame as mentioned in 691r4. It is late
to add additional signal given this current stage. For TPE, Initially, I chose option 1 by using reserved bits, let me think about which option should be selected given that there are multiple options. Regards Guogang Huang 发件人: huangguogang
Hi Yanjun, Could you defer this CR document and arrange a call to have more discussion on it? Please let me know which time is good for you. Regards Guogang Huang 发件人: Yanjun Sun [mailto:yanjuns@xxxxxxxxxxxxxxxx]
Hi Alfred and all, I’ve updated the CR to
23/728r2 based on two constructive feedbacks received offline:
If there is no other comment/concern on the CR, I’d like to queue the SP for this CR in the joint queue. Thanks Yanjun From: Yanjun Sun <yanjuns@xxxxxxxxxxxxxxxx>
Hi folks, During today’s joint session, we’ve recapped the issue, candidate solutions and prior spec text in
23/728r1 as in the highlighted summary below.
It’ll help the group make progress if you could share any suggestion on alternative solutions or any change to the proposed spec text in the CR.
Discussion for CID 18183:
Issue: for TPE indicating an EIRP, there is no normative text on how to interpret reserved values for the Maximum Transmit Power Count subfield,
so the behavior of a legacy STA is unknown if any value between 4-7 is used
To avoid interop issues with the legacy STAs deployed in the field, the group has discussed two options in the past:
The text in 728r1 is copied from
22/1482r7
based on option1. Thanks Yanjun 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 |