Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Guogang, Thank you for your email. >> [Guogang Huang] What do you think the following option: “A STA that receives a Neighbor AP Information field with a Channel Number field set to 0 or other unrecognized value shall ignore
that Neighbor AP Information field, and continue to process the subsequent Neighbor AP Information fields” >> This is a better since it explicitly covers the case of the field being set to 0. As you pointed out there are other elements where the transmitting AP is allowed to set channel number to 0. However, that should not be allowed for RNR since
element is expected to provide the exact channel of the reported AP. Along with the above text, please keep the NOTE from your original text: Note—An unrecognized Channel Number field means the channel Number value which does not fit with any of the values defined in any of the Tables in Annex E for a specific Operating class
value that is set in the Neighbor AP Information field.” Regards, 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. Hi Abhi, Sorry, I didn’t notice your email. Please find my response inline. Regards Guogang Huang Huawei Technologies Co.,Ltd. 发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi All, I couldn’t attend today’s REVme call as I had to attend another meeting during the same time. I noticed that doc 11-22/238 was discussed during today’s meeting. The document is resolving CID 1178 (shown below).
The proposed resolution is adding a new paragraph which put a mandatory requirement on the receiver side when it receives a Reduced Neighbor Report element containing an unknown channel number. I have concerns with the ‘shall’ requirement
and the NOTE. I have copied the proposed additions from doc 11-22/238 below: “A STA that receives a Neighbor AP Information field with an unrecognized Channel Number field
shall ignore that Neighbor AP Information field, and continue to process the subsequent Neighbor AP Information fields. Note—An unrecognized Channel Number field means the channel Number value which does not fit with any of the values defined in any of the Tables in Annex E for a specific Operating class
value that is set in the Neighbor AP Information field.” My reasons for disagreeing with the above changes: The Reduced Neighbor Report element has been in use for many years and there are non-AP STAs that are already deployed in the field that use this element to discover APs in the neighborhood (or collocated with the transmitting AP).
[Guogang Huang]If your argument holds, we don’t need TGm group to polish the 802.11 standard. I think you have already observed the following similar changes has been already added in REVme.
Why do you say we cannot add this rule? Since the Channel Number field indicates the primary channel of the BSSs of the APs in the Neighbor AP Information field (see 9.4.2.170.2), this field must be a nonzero value and matching one of the values listed in the tables in Annex
E. Therefore, the proposed NOTE is incorrect. [Guogang Huang] There is no text “this field must be a nonzero value and matching one of the values listed in the tables in Annex E”. As I
previously mentioned to you, in the Multi-band element, the Channel Number field is allowed to be set to 0. Hence, your statement must be set to a nonzero value is not true.
The proposed change provides a blank check to an AP to set the Channel Number field to any value it pleases with the expectation that a receiving STA will handle it correctly. This is a risky assumption [Guogang Huang] Why do you have this concern that the AP will arbitrarily set the Channel Number to any value? Is there any motivation for the AP to do it? – especially considering STAs that are already deployed, whose behavior can’t be modified. Adding in such requirements will lead to unexpected behavior at a legacy non-AP STA or lead to inter-op issues (if the AP sets the Channel Number
field to an unexpected value – e.g., sets it to 0). We have a couple of options to resolve CID 1178: Option 1: Reject the CID. Reasoning: Clause 9.4.2.170.2 requires that the Channel Number field is set to a nonzero value matching one of the values listed in tables from Annex E. IEEE 802.11ax defined new (nonzero) channel values for 6 GHz
operation and pre-11ax STAs seem to have handled them correct. Therefore, no new rules are needed. Option 2: Clarify that AP sets the channel number to a nonzero value listed in tables in Annex E. Change
shall to a should so that it is a recommendation for future amendments (we can’t enforce a shall requirement for STAs that are already in the field).
“An AP shall set the Channel Number subfield of the Neighbor AP Information field to a nonzero value as defined in Annex E.
A STA that receives a Neighbor AP Information field with a Channel Number field
that is not known to it should ignore that Neighbor AP Information field, and
should continue to process the subsequent Neighbor AP Information fields.” [Guogang Huang] What do you think the following option: “A STA that receives a Neighbor AP Information field with a Channel Number field set to 0 or other unrecognized value shall ignore
that Neighbor AP Information field, and continue to process the subsequent Neighbor AP Information fields” I am leaning towards option 1 (rejection). Regards, To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |