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

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

 

A quick response before I head off for a week of mountain cycling … 😊

  • You asked for evidence that a reasonable/expected regulatory outcome is that C2C operation must be “policed”. I am not asserting the C2C must be policed, rather I am asserting that it is a desirable option for regulators and infrastructure owners, to enable better audit and control of interference to incumbents and to provide better control in environments that might benefit from spectrum management (eg industrial IoT). This at least makes the extension to Table E-12 reasonable (and more generalised than the status quo). I would agree that the proposed concept has not been accepted as an option by any regulator at this point. However, I would point out that C2C has also not been accepted by most regulators and is not much more expected. Indeed, by providing more control of C2C, one could make the argument that it will make the acceptance of C2C by regulators more attractive and so more likely.
  • You asked what was meant by C2C signalling. Where I indicated that a proposal includes C2C signalling, I was asserting that the signalling defined by the proposal is sufficient to signal when an AP can enable or cannot enable C2C operation in at least the form you proposed.
  • You asked what I meant by overloading. It is intended to refer the part of the problem in CID2323 dealing with the overlap in the interpretation of the value 0 in Table E-12. The proposed change in CID2323 solves this problem, but in a manner that conflicts with the assertion in CID 2323 that the Regulatory Info subfield definition has been generalized to apply to all countries (it hasn’t!). The proposed change in 350r2 solves the problem in a more generalised way (although I will concede it is also not a fully generalised solution).
  • You challenged whether the proposal in 350r2 is aligned with existing implementations.  I believe it is aligned because the semantics of the existing values are exactly the same, and these existing implementations can ignore the additional values in the same way they have to ignore Reserved values. Of course, these existing implementations may need to be updated to take advantage of the new values, but that it always true when new functionality is introduced.
  • You asserted we should not discuss CID2120 in the context if CID 2323. I am not a fan of removing Table E-12 , as suggested by CID2120, but if we did remove Table E-12 then we would clearly need to consider such a resolution in the context of CID 2323.

Andrew

 

PS I am available to discuss this on your Wednesday afternoon

 

From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, 23 March 2022 6:30 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

 

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?

  1. Maintain status quo, ie keep existing Table E-12 and all associated text
    1. 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
      1. 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.

 

      1.  
      2. Pro: includes C2C signalling

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

 

      1.  
    1. Con: overloading maintained

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

 

    1.  
    2. Pro: aligned with implementations that have already been developed
  1. Makes changes suggested by CID2323
    1. 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
      1. Con: no  “escape” value
      2. Pro: includes C2C signalling
    1. Pro: overloading removed
    2. Pro: aligned with implementations that have already been developed
  1. Simplify Table E-12 to only have four values suggested by Thomas in e-mail below
    1. 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
      1. Con: makes implicit assumptions about future VLP and C2C rules

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



      1.  
      2. Pro: defines an “escape” value
      3. Pro: includes C2C signalling

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



      1.  
    1. Pro: overloading removed
    2. 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.



    1.  
  1. Extend Table E-12 as suggested by 0350r2
    1. 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
      1. Pro: defines an “escape” value
      2. Pro: includes C2C signalling
    1. Pro: overloading removed
    2. 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)



    1.  
  1. Remove Table E-12 (and rest of Annex E) as suggested in CID2120
    1. Con: no C2C signalling
    2. Con: not aligned with implementations that have already been developed
    3. 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.

 



    1.  

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. (1) definition of Regulatory Info field for non-US operation (which is what the CID is about)
  2. (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. 

  1. 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)
  2. 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:
    1. (a) Indoor AP
    2. (b) Standard Power AP
    3. (c) Indoor Standard Power AP (hybrid of the above)
    4. (d) None of the above
  1. 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.
  2. 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).
  3. *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:

  1. 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)

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

  1. The proposed language “Receipt of this value shall not used as an enabling signal for C2C operation” is troubling
    1. I struggled with this language too
    2. Technically it is correct, but the authority for the “shall not” is really the regulatory authority
    3. Maybe alternatives are:
      1. “Receipt of this value is not intended to be used as an enabling signal for C2C operation”
      2. “Receipt of this value should not be used as an enabling signal for C2C operation”
  1. Using all the values (0-7) means we will have no scope to make future changes
    1. This is true
    2. 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)
    3. 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
  1. Do we need any of Table E-12?
    1. It appears we partially need Table E-12 to enable appropriate signalling for C2C operations
      1. Are there other reasons for Table E-12?
    1. We could decide to not support C2C in 802.11
      1. This will make no immediate difference
        1. C2C is not allowed in the US and has been delayed in Europe
      1. But could impact how quickly C2C can be deployed when it is allowed
    1. My personal preference is to support C2C, but in a manner that can be managed by the infrastructure when required, resulting in:
      1. More use  of 6 GHz from enabling C2C
      2. More controlled use comes from enabling infrastructure management

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

  1. The comment is from Mark Rison
    1. Comment: What an "operating class" does and does not specify seems to depend on the subclause the term is used in
    2. Proposed Change: Delete Annex E
  1. 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
    1. Mark, perhaps you could explain your reasoning in more detail?
    2. All, could everyone highlight any problems that might occur if we adopt Mark’s proposal?

 Andrew Myles

Manager, Cisco Standards

http://www.cisco.com/web/europe/images/email/signature/logo05.jpg

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

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