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 |
Cisco Systems Limited |
|
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