Re: [STDS-802-11-TGM] Thread related to Table E-12 discussion

[Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>]

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi Andrew, all

Thanks for this contribution. I believe CID 2323 has been assigned to me, but of course inputs are always welcome!

I believe your discussion and proposal relates to two separate aspects:

• (1) definition of Regulatory Info field for non-US operation (which is what the CID is about)
• (2) a new feature by which an indoor AP could somehow â??blockâ?? C2C operation (which is outside the scope of the CID)

Allow me to comment on each of those separately.

Regarding (1), despite the (repeated) assertions in 0350r2, the premise of the CID is valid because Annex E.2.7 - including the interpretation of Regulatory Info subfield in Table E-12 - has already been generalized (compared to the baseline text in 11ax-2021) to operation outside the US as per REVme D1.0. The CID is pointing out that, when that generalization was made, the corresponding definition in Clause 9 was not properly updated. 

Slide 8 of 0350r2 talks about â??convergence of regulationsâ?? across countries, however whether or not regulatory domains harmonize on regulatory rules is unrelated to whether or not the field in 802.11 standard is defined for operation in those countries. Note this generalization is not specific to C2C - for example VLP operation is allowed in various countries outside the US and so the REVme D1.0 definition applies to those devices too.

I disagree with a number of other assertions in 0350r2, but in the interests of simplicity will focus on the proposed changes. 

• I agree with the notes below that our standard should not infer new normative requirements from regulatory rules, it should simply provide a framework by which compliance with regulatory rules can be achieved. I donâ??t have a strong feeling on whether a â??noteâ?? is needed, but if it is added then maybe it should be limited to simply pointing out that values 0 and 4 indicate the AP is â??indoorâ?? and other values do not imply such (without referring to C2C operation explicitly)
• In principle, a framework to enable regulatory compliance (at least, based on currently defined and/or proposed regulatory rules) could be achieved with just four Regulatory Info values:
• (a) Indoor AP
• (b) Standard Power AP
• (c) Indoor Standard Power AP (hybrid of the above)
• (d) None of the above
• The differentiation between (a), (b) and (c) helps STAs validate the advertised TPE values it uses when operating an an LPI/SP client device. The differentation between a/b/c and (d) allows the STA to determine whether it is allowed to operate as a (regulatory) client device or not (i.e. whether it is authorized to use client powers advertised in TPE). The differentiation between (a)/(c) and (b)/(d) allows a device to determine C2C enablement.
• I think there is no â??needâ?? (from a regulatory perspective) for a peer device (or other observer) to distinguish between the different variants of (d) - e.g. â??Iâ??m a C2C APâ?? (value 3) vs â??Iâ??m a VLP APâ?? (value 2).
• *However*, given these values are defined in REVme D1.0 (in a way that is somewhat unwieldy but was intended to not use regulatory-specific language) and implementations are starting to use them, I think the bar to justify making changes at this time should be quite high. Currently I am not seeing any issue that needs to be fixed

Regarding (2), as mentioned above that is a new feature outside the scope of the CID. 

I am not convinced of the justification for such feature, but even if there is such, I think it should be specified on a channel-specific basis, and there is existing features in the standard (e.g. 11.21.15 Channel Usage procedures) that could be used.

Thanks

Thomas

On Mar 10, 2022 at 5:07:30 PM, Andrew Myles (amyles) <00000b706269bb8b-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Gâ??day all

 

Thank you for listening to my submission (11-22-0350-01) related is CID2323 today. I fixed a few typos in 11-22-0350-02.

 

During the subsequent discussion, I heard various suggestions and concerns. I was asked to start a discussion thread on these topics:

• C2C needs definition

·       I agree

·       We can probably constrain the definition to E.2.7, similar to what we do for automatic frequency coordination (AFC)

• Ie just define it as â??client to client (C2C)â??

·       Aside: AFC is defined in 3.4 as automatic frequency control and in E.2.7 as automatic frequency coordination

• The proposed language â??Receipt of this value shall not used as an enabling signal for C2C operationâ?? is troubling
• I struggled with this language too
• Technically it is correct, but the authority for the â??shall notâ?? is really the regulatory authority
• Maybe alternatives are:
• â??Receipt of this value is not intended to be used as an enabling signal for C2C operationâ??
• â??Receipt of this value should not be used as an enabling signal for C2C operationâ??
• Using all the values (0-7) means we will have no scope to make future changes
• This is true
• However, there seems to be some confidence the basic structure in Table E-12 is correct given the lack of objection in the LB, and so the risk seems low (especially after the addition of values 5-6)
• If it turns out the descriptions need changes in the future then we can use â??none of the aboveâ?? (value 7) as an escape to something else
• Do we need any of Table E-12?
• It appears we partially need Table E-12 to enable appropriate signalling for C2C operations
• Are there other reasons for Table E-12?
• We could decide to not support C2C in 802.11
• This will make no immediate difference
• C2C is not allowed in the US and has been delayed in Europe
• But could impact how quickly C2C can be deployed when it is allowed
• My personal preference is to support C2C, but in a manner that can be managed by the infrastructure when required, resulting in:
• More use  of 6 GHz from enabling C2C
• More controlled use comes from enabling infrastructure management

 

I was also asked to look at CID2120, which suggests deleting all of Annex E

• The comment is from Mark Rison
• Comment: What an "operating class" does and does not specify seems to depend on the subclause the term is used in
• Proposed Change: Delete Annex E
• IMHO this might or might not be a good idea, but it is difficult to see the justification for such a change in the comment
• Mark, perhaps you could explain your reasoning in more detail?
• All, could everyone highlight any problems that might occur if we adopt Markâ??s proposal?

 

Andrew Myles Manager, Cisco Standards
Andrew Myles Manager, Enterprise Standards amyles@xxxxxxxxx Phone: +61 2 8446 1010 Mobile: +61 418 656587	Cisco Systems Limited The Forum 201 Pacific Highway St Leonards 2065 AUSTRALIA Cisco.com

 

 

---

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

---

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature