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]
发送时间: 2022年3月1日
15:20
收件人: STDS-802-11@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11] REVme resolution for CID 1178 (doc 11-22/238)
--- 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).
|
1178 |
3079.21 |
11.49 |
Please add some text to describe the behavior when a STA receives a Neighbor AP Information field with a recognized TBTT Information Field Type
subfield and a recognized TBTT Information Length subfield but an unrecognized Channel Number field. |
Please add the following paragraph after the third paragraph ('If the unrecognized TBTT Information Length value is less than or equal to 13').
A STA that receives a Neighbor AP Information field with a recognized TBTT Information Field Type subfield and a recognized TBTT Information Length
subfield but an unrecognized Channel Number field shall follow alternative a). |
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,
Abhi
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