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

Thanks. Please find some comments inline below

On Mar 21, 2022 at 11:24:19 PM, Andrew Myles (amyles) <00000b706269bb8b-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

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

G’day Thomas

I have been thinking about the options to resolve both CID2323 and CID2120 in relation to Table E-12, and various associated pros/cons?

Maintain status quo, ie keep existing Table E-12 and all associated text

Con: values in Table E-12 not generalised sufficiently to cover reasonable regulatory outcomes, including ability to signal disabling of C2C in some locations or regulatory domains

Con: no “escape” value

[Thomas] Please could you provide evidence/references that a reasonable/expected regulatory outcome is that C2C operation must be “policed” (my choice of wording, but I believe that’s your intent) by infrastructure networks; I am not aware of such.

Even if such requirement is indeed anticipated based on reasonable evidence, as mentioned in my previous mail I do not believe the proposed approach of adding more values in RegInfo is the right technical solution, I referred to some existing features in baseline that I think are more suited as a basis.

Pro: includes C2C signalling

[Thomas] It is unclear to me what is meant by “C2C signaling”, please clarify

Con: overloading maintained

[Thomas] Similarly, what is meant by “overloading”?

Pro: aligned with implementations that have already been developed

Makes changes suggested by CID2323

Con: values in Table E-12 not generalised sufficiently to cover reasonable regulatory outcomes, including ability to signal disabling of C2C in some locations or regulatory domains

Con: no “escape” value
Pro: includes C2C signalling

Pro: overloading removed
Pro: aligned with implementations that have already been developed

Simplify Table E-12 to only have four values suggested by Thomas in e-mail below

Con: values in Table E-12 not generalised sufficiently to cover reasonable regulatory outcomes, including ability to signal disabling of C2C in some locations or regulatory domains

Con: makes implicit assumptions about future VLP and C2C rules

[Thomas] I don’t think it makes any such assumptions.

Pro: defines an “escape” value
Pro: includes C2C signalling

[Thomas] I don’t think it does either of these.

Pro: overloading removed
Con: not aligned with implementations that have already been developed

[Thomas] Agree. For clarity, this is not my “proposal”; I mentioned it because there seemed to be confusion about what signaling is required to “enable” C2C. To enable C2C it is not necessary that a C2C AP advertises itself as such, it’s only necessary that indoor APs identify themselves as such. This is one of the reasons the meaning of the term “C2C signaling” in this thread is unclear to me.

Extend Table E-12 as suggested by 0350r2

Pro: values in Table E-12 generalised to cover more reasonable regulatory outcomes, including ability to signal disabling of C2C in some locations or regulatory domains

Pro: defines an “escape” value
Pro: includes C2C signalling

Pro: overloading removed
Pro: aligned with implementations that have already been developed

[Thomas] I disagree it aligns with existing implementations, but first (as previously mentioned) I think it needs to be clarified what problem this is intended to solve (see comment on regulatory aspects above)

Remove Table E-12 (and rest of Annex E) as suggested in CID2120

Con: no C2C signalling
Con: not aligned with implementations that have already been developed
Pro: less is more???

[Thomas] Well, given Table E-12 is used by existing 6 GHz implementations (i.e. nothing to do with C2C, but in order to identify LPI/SP APs for purpose of abiding by client power limits), I think there is no possibility that these definitions are completely removed from the standard - possibly the intent of the CID is to move the table into another subclause or express the definitions in a different way. I don’t think this has much to do with this CID so it’s better discussed separately.

Have I missed any pros/cons?

Mark Rison, can you provide some additional background to your comment CID2120?

Andrew

From: Andrew Myles (amyles) <00000b706269bb8b-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, 21 March 2022 7:07 PM
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 ---

G’day Thomas

Apologies for not replying earlier, but I did missed your quick response in the sea 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

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

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