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

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

G’day Thomas

Apologies for not replying earlier, but I did missed your quick response in the see of e-mails ...

A key question is whether Table E-12 has indeed been generalised to cover a range of reasonable regulatory outcomes globally, including the US. One of the outcomes is in relation to C2C, which is explicitly enabled (if not called out by name) in the current version of Table E-12. One likely regulatory outcome is that C2C is enabled in at least some countries, and I believe it is important to allow for that in Table E-12. Other possible regulatory outcomes are that C2C is not enabled or is only enabled when permitted by the infrastructure. The last option is my personal preference.

The current version of Table E-12 is NOT generalised as asserted by CID2323 because it does not envisage all of these possible outcomes (although it is more generalised than previously, as you correctly note). Your comments below suggest you are attempting to enable C2C, which I am not objecting to. My objection is that you are attempting to do so in a way that does not allow for other options for C2C regulation, particularly in an environment where C2C is not actually defined anywhere (including the US and Europe).

You commented that Slide 8 of 0350r2 talks about “convergence of regulations” across countries. While convergence would be nice it is not actually necessary. What we need is that Table E-12 is sufficiently flexible to handle a variety of regulations globally. My proposal does that better than the status quo because it enables the status quo, but it also enables other reasonable alternatives that may be imposed in various regulatory domains. It does so in a way that does not impact any vendors who may have already implemented the status quo, and it avoids the overloading issue altogether.

Maybe the best way forward is for us to have a phone chat about the issues and options. I am sure we can find a good compromise solution without e-mails backwards and forwards.

Andrew

PS It doesn’t really matter who the assignee is because we need to come to a consensus, but I believe I have been assigned CID2323 (as per 11-21-0793-16).

From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, 12 March 2022 4:48 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Thread related to Table E-12 discussion

--- 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