Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>
Mark Rison, can you provide some additional background to your comment CID2120? Operating classes are a complete mess.
Every time we find some regulatory or other issue we say "ah, we can hack operating classes to handle this", forgetting what operating classes have previously been said to provide. So does an operating class specify: - the set of channels that can be used and/or must be supported?
No, we've added channels to operating classes in the past (and maybe removed them too?) - the behaviour limits?
No, we've added and removed them in the past - the channel spacing?
Maybe … except when instead it's deemed to specify the BSS bandwidth.
Or maybe the operating bandwidth? - the "phase" of valid channels within the band (e.g. are valid channels always at channel number 4n?)?
No, e.g. US OC 130 has centre frequency indices 42, 58, 106, 122, 138, 155 - etc. I think we should stop pretending that an operating class specifies anything other than the so-called channel starting frequency, i.e. the frequency corresponding to channel 0.
If we want it to specify anything else, e.g. some kind of bandwidth, then we need in each case state explicitly whether it's the BSS bandwidth or the operating bandwidth or the channel spacing or what. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Andrew Myles (amyles)
<00000b706269bb8b-dmarc-request@xxxxxxxxxxxxxxxxx> --- 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?
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>
--- 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>
--- 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:
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.
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:
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 |