doc.:IEEE 802.11-12/0297r0 Mar. 2012 TPC, Operating Classes,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 TPC, Operating Classes, and Channel Switching Date: 2012-03-04 Name Company Address Phone 170 W Tasman Dr, San Jose, CA 95134, USA email Brian Hart Cisco Systems Peter Ecclesine Cisco Systems [email protected] Reza Hedayat Cisco Systems [email protected] Submission Slide 1 [email protected] Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 2 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 3 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Case Study: TPC is a broad UNII requirement in FCC Part 15 This is the clause that lets you know that the FBI can knock on the end-user’s door. For the manufacturer, the products had better be in compliance with Part 15 . For the end-user, hopefully there is a channel and/or a TPC level that avoids harmful interference , else no operation. i.e. TPC advIsed Part 15 has a subpart for UNII party manu The AP has the right and the responsibility to select the channels and the max TX power of the clients i.e. TPC advised 1 Which defines TX power, etc i.e. And which also refers us to other subparts Submission Which in turn refer us to more regulations in Which in turn refer us to more regulations subpart A Slide 4 2 And further regulations in subpart C See also KDB 789033 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Transmit Power Units (1/5) Background The 5 GHz 802.11 protocol to report the rules from AP to client is contained in a mixture of Country string, Operating class table, Operating Class, Max TX power in Country element, VHT Transmit Power Envelope element, Power Constraint element and Extended Power Constraint element All these fields and elements contain one value, so assume one set of units (conducted or EIRP or EIRP/MHz, etc) But regulators use a mixture of units Since Japan is EIRP/MHz, and USA tends to be conducted, etc, 11d defined the units of the Max TX power in the Subband Triplet in the Country element as “interpreted according to the regulations applicable for the domain identified by the Country string” FCC 15.247 2.4 GHz rules: conductedPower 30 dBm AND EIRP 36 dBm; this rule is labeled “conducted output power” FCC UNII-2 TX Power rules: conductedPower min(24,11 10logB)dBm AND EIRP min(30,17 10logB)dBm AND conductedPSD 11dBm/MHz AND eirpPSD 17dBm/MHz (where the rule text refers first to “conducted output power” but the eirpPSD rule is actually the most stringent) ; versus the FCC UNII-2 TPC rules which are plainly: EIRP 27 dBm FCC 15.247 2.4 GHz point-to-point rules: conductedPower (antennaGain-6)/3 36 Even if the AP ignores its general TPC requirements, sometimes the regulators impose specific TPC requirements on the AP, as master, and thence the BSS. Submission Slide 5 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Transmit Power Units (2/5) Existing Headache Specifically for 5.25-5.35 and 5.47-5.725 GHz: FCC’s max power is generally written in terms of conducted power (to promote the use of smarter antennas), but the FCC’s TPC rules are written in terms of EIRP. The 802.11 protocol puts the max power in the Country element (“interpreted according to the regulations applicable for the domain” so is conducted power) then subtracts away a power constraint. So, in the USA in these bands, an 802.11 AP is advertising a conducted power, to enforce an EIRP constraint. Worked example: – – – Say an AP chooses to advertize a 27 dBm EIRP. The AP has clients associated that are capable of high conducted power and EIRP. The AP could assume all clients are 0 dBi and advertize say 27 dBm, but then a 27 dBm client with a 6 dBi antenna can pick a power that is actually 6 dB higher than the AP thought it was requesting! Or the AP assumes all clients are 6 dBi and advertizes say 21 dBm, but then a 27 dBm client with a 0 dBi antenna is unnecessarily limited to 21 dBm! And can never know. And still a 9 dBi client is actually 3 dB higher than the AP thought it was requesting! The Power Constraint really only “works” if a) a client can never exceed the lowest TPC limit on EIRP or maybe b) it interprets the power constraint as a reduction from its homologated limit – which is very different to the 802.11 language Submission Slide 6 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Transmit Power Units (3/5) VHT Extensions In VHT, we add VHT Transmit Power Envelope element and Extended Power Constraint, but are silent on their units (not even “interpreted according to the regulations applicable for the domain identified by the Country string”). We do have: 8.4.2.164: The Maximum Transmit Power field defines the maximum transmit power limit of the transmission bandwidth defined by the VHT Transmit Power Envelope element. The Maximum Transmit Power field is an 8-bit 2's complement signed integer in the range of -64 dBm to 63.5 dBm with a 0.5 dB step. 3.2: transmit power: The effective isotropic radiated power (EIRP) when referring to the operation of an orthogonal frequency division multiplexing (OFDM) physical layer (PHY) in a country where so regulated. From the original author, “where so regulated” is intended to bind to country and so indicate “TX Power EIRP in a country if the country regulates via EIRP”, so transmit power is undefined in a country that doesn’t regulate as EIRP. And many countries regulate using a variety of units (e.g. from the earlier slide, FCC uses a mixture of conducted, EIRP, conducted/MHz, EIRP/MHz) even in the same subpart. In fact, in almost every usage of transmit power in 802.11, “transmit power” is followed by explanatory text: conducted/EIRP/interpreted according to the regs. BTW, the Extended Power Constraint element does fulfill a regulatory role: 10.8.4: “The Local Power Constraint field of any transmitted Power Constraint element and Extended Power Constraint element shall be set to a value that allows the mitigation requirements to be satisfied in the current channel.” Submission Slide 7 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Transmit Power Units (4/5) Solution Include units for VHT Transmit Power Envelope element Where to put the units - open for discussion To express a mixture of units – e.g. “conducted X and EIRP Y” – send 4 elements: VHT Transmit Power Envelope [conducted], Extended Power Constraint, VHT Transmit Power Envelope [EIRP], Extended Power Constraint – Which would be cleaner if we merged VHT Transmit Power Envelope and Extended Power Constraint into a single element Add a final tuple with channel center frequency segment 201, and with units in Segment Channel Width field. Inefficient, not D2.0 compatible Insert new IE just for units. D2.0 compatible but very inefficient Submission Insert new octet for units. Efficient, not D2.0 compatible Slide 8 Units Id Units 0 Conducted 1 EIRP 2 Conducted/MHz 3 EIRP/MHz 4-7 or 4-255 Reserved Partition into a 5 bit table for Segment Channel Width (with 0, 3, 5-31 reserved for future use) and 3 bits for units. Second segment is reserved. Efficient, not D2.0 compatible Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Transmit Power Units (5/5) Solution Address other ambiguous uses of “transmit power” Field/element/frame Problem Proposed fix 8.4.2.17 Power Capability element Definition is incomplete (radiated or conducted?). No hint that it is “interpreted according to the regulations applicable for the domain identified by the Country string”. Or it could refer to the transmit power definition. But, either way, this is problematic as discussed on earlier slides. Since sent in (Re)Assoc Requests, VHT STAs send this using the first-listed units identified in the VHT Power Envelope elements from the Beacon/Probe Response if present, otherwise silence. 11mc could add “interpreted according to the regulations of the country and band” 8.4.2.70.4 Peer-to-Peer Link event report “target transmit power at the antenna” but is this TX antenna input or output? Clarify that it is total radiated power Figure 8-307in 8.4.2.71.5 Diagnostic Information subelement descriptions “target transmit power level(s) at the antenna(s)” but a) is this TX antenna input or output, and b) is this total transmit power or per antenna power? Clarify that it is total radiated power 8.4.2.73.5 Radio Information subelement Definition is incomplete (radiated or conducted?) Since this is for location, clarify that it is total radiated power 3.2: transmit power Definition is too narrow to be useful Indicate that it is conducted or radiated according to context. Or delete Submission Slide 9 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 10 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 80 80 affects a lot of 11d/11h/11k/11v fields/elements/frames We created the problem, so we ought to fix it We could pick the fields/elements/frames that we care about and only update them – Leads to a drawn out discussion Simpler for a volunteer to just try to fix “everything” Submission Slide 11 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (1/7) Field/element/frame Problem Proposed fix 8.5.12.2 Notify Channel Width frame Single octet for channel width Disallow Notify Channel Width frame being sent VHT to VHT 8.4.2.10 Country element Many folk are not clear that Country element can contain multiple operating classes for the same bandwidth; no “ 80” semantics; units of max TX power not defined; rules followed by AP (vs BSS) are not clear See later slides for a more involved discussion 8.4.2.23.2 Basic request One channel number only, no operating class or 80 80 semantics. Europe is allowing clients to be homologated to detect and report radar. Add Extended Basic Request also containing Operating Class , and for 80 80 allow an optional subelement containing OpClass “ 80”, channel # 8.4.2.24.2 Basic report One channel number only, no operating class or 80 80 semantics. Europe is allowing clients to be homologated to report radar. Map for one channel only Add Extended Basic Request with one Map per 20 MHz and “I am homologated for radar detection as a client” indication. And capability bit for this too. 8.4.2.23.3 CCA request One channel number only, no operating class or 80 80 semantics. Report refers to channel busy %, but modern CCA reports busy-ness on P20, S20, S40 and S80 Clarify that the operating class is implicitly a 20 MHz operating class. 8.4.2.24.3 CCA report Ditto Ditto Submission Slide 12 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (2/7) Field/element/frame Problem Proposed fix 8.4.2.23.4 RPI histogram request One channel number only, no operating class or 80 80 semantics. No optional subelements allowed for pre-VHT. Use the channel number to indicate the P20. When sent unicast to VHT only, allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the desired measurement spectrum for 40/80/160/80 80. 8.4.2.24.4 RPI histogram report Ditto Ditto 8.4.2.23.5 Channel load request OpClass Ch# only, no primary channel indication for 40MHz (needed to specify which virtual carrier sense is used), no 80 80 semantics. Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the desired measurement spectrum for 80/160/80 80 . 8.4.2.24.5 Channel load report Ditto Ditto. Measurement is for the whole bandwidth. 8.4.2.23.6 Noise histogram request OpClass Ch# only, no primary channel indication for 40MHz (needed to specify which virtual carrier sense is used), no 80 80 semantics. Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the desired measurement spectrum for 80/160/80 80 . 8.4.2.24.6 Noise histogram report Ditto Ditto Submission Slide 13 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (3/7) Field/element/frame Problem Proposed fix 8.4.2.23.7 Beacon request OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics. Only one operating class. Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the desired measurement channel for 80/160/80 80 . Beacons should only be sent at 20 MHz, but rogues could do anything 8.4.2.24.7 Beacon report Ditto Ditto (includes all received beacons irrespective of bandwidth; specifies the beacon OpClass Ch# and, if 40MHz, then include the optional subelement too; not the measurement channel) 8.4.2.23.8 Frame request OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics. Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the desired measurement channel for 80/160/80 80 . 8.4.2.24.8 Frame report Ditto Ditto (includes all received frames irrespective of bandwidth) Submission Slide 14 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (4/7) Field/element/frame Problem Proposed fix 8.4.2.38 AP Channel Report element No 80 80 semantics. Clarify that the operating class can only be a 20 MHz operating class (since a STA will find an AP via its 20 MHz beacon) 8.4.2.39 Neighbor Report element OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics. Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the BSS operating channel for 80/160/80 80 . 8.4.2.48 Multiple BSSID element Contains Supported Operating Classes element etc Upgrade to reflect any changes to Supported Operating Classes element etc 8.4.2.54 DSE Registered Location element OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; no optional subelements - not marked as extensible. No change. Yet, no 80/160 MHz spectrum with DSE (yet?) Submission Slide 15 When and if this is needed by a new “XHT” TG, use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the BSS operating channel for 80/160/80 80 (sent to a XHT STA only). Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (5/7) Field/element/frame Problem Proposed fix 8.4.2.55 Extended Channel Switch Announcement element Only one operating class (inadequate for mixed clients), no 80 80 semantics. Allow multiple ECSA elements to be included in containing frames. Define a new “ 80” OpClass so ECSA elements for 20,40,80,80 and 80 indicate 20, 40, 80 and 80 80 8.4.2.56 Supported Operating Classes element No 80 80 semantics. Define a new “ 80” OpClass so 80,80, 80 can indicate 80,80 80. 8.4.2.58.2 HT Capabilities Information field “Supported Channel Width Set” is reserved if operating class isn’t a 40 MHz operating class Flip this around – reserved only for 10/20 MHz operating classes 8.4.2.60 20/40 Intolerant Channel report element No 80 80 semantics. No change. 8.4.2.69.4 Peer-to-peer Link event request No 80 80 semantics. Define a new “ 80” OpClass so two subelements 80, 80 can indicate 80 80. 8.4.2.70.4 Peer-to-peer Link event report No 80 80 semantics. To VHT STAs only, allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the peer channel for 80/160/80 80 . Submission Specific to 2.4 GHz Slide 16 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (6/7) Field/element/frame Problem Proposed fix 8.4.2.71.5 Diagnostic information subelement descriptions (AP Descriptor subelement format) Only one operating class (inadequate for mixed recipients), no 80 80 semantics. Since this seems to be just a terse indication of identity of the associated AP (e.g. no HT capabilities/operation elements), it suffices to just report the P20 or P20/40 MHz operating class and channel. 8.4.2.73.3 Location Indication Channels subelement No 80 80 semantics, but 80 80 is really interesting from a location perspective. Define a new “ 80” OpClass so a 80 OpClass,ch# pair then a , 80 OpClass,ch# pair can indicate 80 80. 8.4.2.88 Channel Usage element No 80 80 semantics. Define a new “ 80” OpClass so 80, 80 can indicate 80 80. 8.5.8.3 Measurement Pilot frame format OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; only one operating class (inadequate for mixed clients). Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the BSS operating channel for 80/160/80 80 . 8.5.8.7 Extended Channel Switch Announcement frame format OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; only one operating class (inadequate for mixed clients) Use existing OpClass Ch# to indicate the P20 or P20/40. Allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the new BSS operating channel for 80/160/80 80. Country element also be optionally allowed Submission Slide 17 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Solution: Channel number identification (7/7) Field/element/frame Problem Proposed fix 8.5.8.8 DSE Measurement Request frame format OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; no optional subelements. No change. Yet, no 80/160 MHz spectrum with DSE (yet?) 8.5.8.9 DSE Measurement Report frame format OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; no optional subelements. Yet, no 80/160 MHz spectrum with DSE (yet?) 8.5.13.TDLS Channel Switch Request Action field format Submission OpClass Ch# only, no primary channel indication for 40MHz, no 80 80 semantics; no optional subelements. Slide 18 When and if this is needed by a new “XHT” TG, use existing OpClass Ch# to indicate the P20 or P20/40. Define an optional subelement formatted as EID,L, VHT Operation Information field to indicate the BSS operating channel for 80/160/80 80 (sent to a XHT STA only). No change. When and if this is needed by a new “XHT” TG, I have no idea how to extend this except via a new “Extended DSE Measurement Report frame format” Allow Wide Bandwidth Channel Switch element as an optional subelement , as is already addressed by 11acD2.0 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 19 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Country element format 11h – very old Multiple instances of these, implicitly for a 20 MHz operating class Country String Octets N SubbandTriplets Element ID Length Country Code Operating Table Index First channel Number of Channels Max Transmit Power Level Pad 1 1 2 1 1 1 1 0/1 11j/n/p/y /mb more modern Multiple instances of these, one per Operating Triplet Country String Octets 1 Operating Triplet N SubbandTriplets Element ID Length Country Code Operating Table Index 201 Operating Class Coverage Class First channel Number of Channels Max Transmit Power Level P a d 1 1 2 1 1 1 1 1 1 1 0 / 1 Country element in Beacons and Probe Responses is the only 802.11 mechanism by which an AP can alert clients to time/location/AP-state-dependent regulatory permissions that clients couldn’t be aware of otherwise (i.e. structured information that cannot be known at manufacturing time) Need to keep this mechanism in our back pocket for future spectrum around the world update As we see above, Country element is pretty powerful already Let look at how it works by example, and look for holes Submission Slide 20 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 80 80 MHz BSS with TPC 160 or 80 80 MHz BSS 160 MHz BSS How to use the Country element to express Operating Classes (if AP needs to specify time/loc/AP-state dependent rules that the client cannot know otherwise) 20/40 MHz operating triplet for P20 and P40 80 MHz operating triplet for P80 160 MHz operating triplet Note 1: Allowed today Note 2: No need for a 20 MHz operating class since regulations don’t change at that level, and 11a clients aren’t expected to understand operating triplets Note 3: All a column to Annex E indicating the chGroup in which the operating classes were defined (11j vs 11k vs 11n ); beacons must send in increasing group order 20/40 MHz operating triplet for P20 and P40 80 MHz operating triplet for P80 “ 80” MHz operating triplet for S80 Note 1: Need to add an operating class for the secondary 80 MHz segment; otherwise allowed today Note 2: Allowing 160 MHz via 80 and “ 80” is helpful as we will see later 20/40 MHz operating triplet for P20 and P40 Subband triplet for 20/40 80 MHz operating triplet for P80 “ 80” MHz operating triplet Note 1: Need to add an operating class for the secondary 80 MHz segment; otherwise allowed today Note 2: Also can send a Power Constraint element to lower the power further., which reduces the Maximum Transmit Power Level in each Subband triplet by the same amount Note 3: BTW, we probably could have avoided VHT Transmit Power Envelope, by instead using subband triplets for 80 and 160 MHz. Water under the bridge Submission Slide 21 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 80 MHz BSS on ch155 How to use the Country element to express multiple Operating Classes 80 MHz BSS on ch138 20/40 MHz UNII operating triplet for P20 and P40 20/40 MHz 15.247 operating triplet for P20 and P40 80 MHz UNII operating triplet for P80 80 MHz 15.247 operating triplet for P80 Note 1: Allowed today; this is an “OR” relationship But, ch138 is a new problem. If there were time/location/AP-state dependent rules for ch138, some arising from UNII and some arising from 15.247, how can we express these both – given that this is now an “AND” relationship? Solution: define First Channel 224 1 to indicate that the permissions of the Operating Class are ANDed with the following operating triplet (versus “ 80”, which denotes a frequency-domain bonding). The 225 operating triplet is sent first so legacy can’t interpret the earlier triplet as unANDed See more details on this encoding in a later slide 20/40 MHz UNII operating triplet for P20 and P40 (201) 80 MHz UNII operating triplet for P80 (225) 80 MHz 15.247 operating triplet for P80 (201) Note 1: If the primary is on ch144 then we also need to prepend this list with “20/40 MHz 15.247 operating triplet for P20 and P40 (225)” Submission Slide 22 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 160 MHz BSS on ch155 How to use the Country element to deal with wide spectrum crossing multiple regulations 20/40 MHz UNII operating triplet for P20 and P40 (201) 80 MHz UNII operating triplet for P80 (201) 80 MHz UNII operating triplet for S80 (225) 80 MHz NEW-REG operating triplet for S80 (201) Note 1: i.e. Express 160 MHz as 80 80, and allow for multiple regulations within each 80 MHz (just S80 in this example) Similarly if there was a 160 MHz made up of a first 80 MHz of spectrum subject to one regulation and a second 80 MHz of spectrum subject to a second regulation (or the second 80 MHz of spectrum is subject to both regulations), then we should allow 160 MHz to be represented as “80” and “ 80” (since an 80 MHz-only client would not be subject to any additional S80 rules Idle thought: Reserve “Coverage Class” in new operating classes? Submission Slide 23 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 24 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Channel Switch (1/4) In VHT, we only allow the Wide Bandwidth Channel Switch element in the Channel Switch Announcement frame Many devices sleep as much as possible - only wake up to send or to check the TIM element If so, they will never see the Channel Switch Announcement frames Solution: allow this element in Beacons, Probe Responses and the Extended Channel Switch Announcement frame (and more, as we shall see) Submission Slide 25 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Channel Switch (2/4) From earlier slides, the AP has a right and a responsibility to perform TPC 802.11 has had some off-channel TPC, via regulatory triplets in the Country element (first channel, number of channels and a lowered maximum transmit power level). But we’re leading with the VHT Transmit Power Envelope element in 11ac rather than regulatory triplets, so 11acD2.0 APs have less off-channel transmit power control than they’re used to. i.e. 11ac doesn’t have a way for the AP to change channel and power at the same time And the regulatory triplet mechanism is painfully inefficient – the AP sends a lot of octets in the beacon on the off-chance that it might switch to one of the channels a long time in the future. And it doesn’t express TX power units Much better to associate the TPC with the channel switch (11af model also). The (Extended) Channel Switch Announcement frames/elements (or Beacon or Probe Response) do not include any TPC elements that refer to the next channel A client doesn’t know the new permissions until it has reached the new channel and heard a Beacon or Probe Response from its AP BUT, the Beacon is coming too late – high-power PPDUs could be transmitted for up to 1 beacon interval, and longer if the Beacon is lost to collisions. Submission Slide 26 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Channel Switch (3/4) As well, 11ac doesn’t have a way for the AP to change channel and operating class(es) at the same time In Japan, a channel switch from say 5.15-5.25 GHz (using the Global Operating Class Table) to say 4.94-4.99 GHz (using the Japan Operating Class Table) is not possible, since the Operating Table identifier is present in the Country element but the Country element is not transmitted in the (Extended) Channel Switch Announcement frames/elements E.g. to move a BSS from UNII ch36 to ch149, and ensure that all capable clients adopt 15.247 not UNII rules at ch149 (for more power) Work needed to allow for a Operating Class Table change, or avoid this altogether An AP on a school-bus making daily trips between Ciudad Juarez and El Paso (5000 students daily cross the border with Wi-Fi) should perform a Country switch and advertise reduced transmit powers in the Subband triplet – but the AP cannot include the Country element in any (Extended) Channel Switch Announcement frame/element Submission Slide 27 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Channel Switch (4/4) Solution In CSA and ECSA, optionally allow: Wide Bandwidth Channel Switch element (already allowed in CSA) VHT Transmit Power Envelope element Extended Power Constraint element Country element All for the next channel To Beacon and Probe Response, if a CSA or ECSA element is also present, allow a new optional wrapper element “Extended Extended Channel Switch Announcement” that optionally contains: VHT Transmit Power Envelope element Extended Power Constraint element Country element All for the next channel (Wide Bandwidth Channel Switch element could be moved inside this wrapper element) Submission Slide 28 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 29 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Operating Class Tables (1/4) Sharing Operating Class Tables 11mb keeps the US/Europe/Japan countries tables and adds the global operating table The selected Country table is indicated by the third octet of the Country string i.e. “One table at a time” But, the example in Annex E.1 actually reports operating classes from both the US and the global operating tables. And 11mb keeps the operating class numbers in the country and global operating classes separate. Let’s put a lot of weight on these two observations. So explicitly selecting and reporting an operating table doesn’t seem to be as important. As long as we parsimoniously assign operating classes and aggressively deprecate unused redundant classes, then we can keep this that simple. Proposal: for VHT, the global operating classes suffice for US, Europe and Japan since there is no time/location/AP-state dependence in the client permissions that cannot be expressed by one or more of the country string, a nearby AP actually operating on this channel (or not), and the separate TPC protocol. That is, delete new US operating classes 35, 36; Europe operating classes 19, 20; Japan operating classes 60, 61. Just use the global numbers instead (128, 129) Submission Slide 30 Brian Hart,

Mar. 2012 doc.:IEEE 802.11-12/0297r0 Operating Class Tables (2/4) Is a standalone Global Operating Table better? Usually not. How would an AP use only the Global Operating Table? Consider an AP that supports multiple bandwidths (and so multiple Operating Classes) and wishes to support legacy clients that only understand older country-table-specific operating classes Country-table-specific operating classes are the default expectation for 11k/s/v devices Practically the AP would be stuck with its local Country Operating Class Table, and the 802.11 would have to continue to maintain this table, even for regulations that did not deviate from international norms It doesn’t get better elsewhere - domains other than US/Europe/Japan with just one highly specific regulation would have their own table created Then, to get most use out of the ECSA and Supported Operating Classes elements etc, all global classes would have to be replicated in that country’s table too Thus a separate Global operating table is only useful for 100% vanilla countries. (Or, two Country elements could be sent: country-specific first, global second High risk that clients of erratic behavior Slide – not31advised) Submission Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Operating Class Tables (3/4) Solution Details Differentiate Operating Classes purely by 2-octet Country code and Operating Class: 1-80 is country-dependent, 81-191 is Global (and country-independent), 192-254 is Vendor Specific (e.g. 254 is used by the Bluetooth SIG), 0,255 are reserved Aggressively deprecate Operating Classes made redundant by 11mb changes to maximize room for future growth. Start this at VHT APs: disallow them from using operating classes identified as redundant Description Values USA: US? Europe: DE?, FR?, 192-254 ? ? Additional countries with time/location/AP-state dependence not expressed by TX power limits that deviates from international Aggressively deprecate defaults redundant Country Operating Classes to 61/80 0/80 create room for future 50/111 in use growth (Japan can be lowered to 22/80 ? 0 0, 255 - - - (“?” wildcard) Country Global Vendor Specific Reserved Submission 1-80 33/80 17/80 81-191 Japan: JP? - Slide 32 i.e. The same values are used worldwide Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Operating Class Tables (4/4) Supported Operating Classes Element The Supported Operating Classes element advertises the operating classes that a STA is capable of operating “within this country” No Table is specified, so must be wrt the Table indicated in the Country element by the AP i.e. no ability to report the support of Operating Classes in a different table E.g. consider a client associated to Japan 4.94-4.99 and 5.03-5.091 GHz. Due to the specific regulatory features in this band and country, the AP needs to advertise an operating class from the Japan table. – – Therefore client’s supported operating classes must be reported using the values from the Japan table Note that a legacy 11j STA knows about 3x the number of operating classes as are now defined in the Global Operating Table. (It is believe that there is limited field support for these Operating Classes, and so most can be aggressively deprecated then reclaimed at a later time, with little impact) But, if we adopt the thinking of the earlier slide, no change is needed to the Supported Operating Classes element – in a given country, the operating classes that can be reported are the union of the country table and the global table Submission Slide 33 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Executive Summary This document considers a range of issues related to transmit power, channel identification and operating classes – Regulations are getting more complicated with mixtures of units. VHT Transmit Power Envelope does not even define units add – Operating classes can be used to indicate band and bandwidth in 11k/s/v update Expressing 80 80 is especially problematic for 11k/s/v protocols – Operating classes can be used to indicate time/location/AP-state-dependent regulatory permissions that clients wouldn’t be aware of otherwise. Need to keep this mechanism in our back pocket for future spectrum around the world update – VHT weakens channel switching and next-channel TPC refresh – 11mb uses the Global Operating Table in two inconsistent modes, and there are arguments towards 802.11 rallying around the less well recognized mode pick a winner – A few other related matters fix A high level description of proposed changes is provided for discussion and to sanity-check the direction of the normative text Submission Slide 34 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Shared Spectrum (1/3) Background BTW, 5.725 to 5.825 GHz is shared spectrum (15.247, UNII): your device can be homologated under one or both of two sets of regulations – “shared spectrum” But this is mostly OK: a UNII client can be associated to a 15.247 AP or vice versa, as long as each individually meets its regulatory requirements Submission Slide 35 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Shared Spectrum (2/3) AP declaration of its rules Currently the Operating Class is overloaded with two sets of semantics: a) the permissions of the BSS: i.e. AP indicates permissions to clients so that they can follow them, and b) the regulations under which the AP is presently operating (e.g. UNII or 15.247) If clients can join an AP under one of multiple regulations, and if the AP is homologated under several regulations then the AP should be able to advertise multiple operating classes per BSS ( for clients) for the same bandwidth But which one is the AP adopting for its own transmissions? The simplest idea is “the first transmitted regulations”. But, if the advertising order is first-promulgatedregulation-transmitted-first (to avoid disconcerting legacy STAs) then the AP cannot take advantage of newer regulations Solution: Redefine First Channel according to the following table (First Channel is now defined as 1-200, 201 or 224-227) If this operating triplet is ORed with other operating triplets and either there is only one operating triplet for this bandwidth or the AP is adopting the first-listed operating class for its own transmissions at this bandwidth, then First Channel 201, Else: B0 0 OR with next operating triplet 1 AND with next operating triplet (See earlier slides) Submission B1 B2:B4 B5:B7 0: the AP is adopting another operating class for the AP’s transmissions at this bandwidth 1: the AP is adopting this operating class for the AP’s transmissions at this bandwidth // Within ANDed operating triplets, this field is set to the same value Reserved 7 (i.e. 224) Slide 36 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Shared Spectrum (3/3) Client Association to AP If an AP is homologated under one set of regulations and the client is homologated under a different set, and the client’s set of regulations is time/location*/AP-state dependent, then the AP cannot help the client be compliant, so there are several possibilities for manufacturers in order that their products can get homologated: Client must not associate to the AP, or Client must configure itself to be compliant regardless of the time/location/APstate dependence of the regulations (if such a configuration even exists) *Where the location dependence is finer grained than the Country, since an AP can help to this extent Solution: Add a Note that client homologated for one regulatory class may associate to an AP not homologated for that regulatory class only if the client is able to ensure compliance without help from the AP Submission Slide 37 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Open Discussion Submission Slide 38 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Backup Slides Submission Slide 39 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 Some non-Wi-Fi product vendors have not maintained our level of care – and we want to continue avoiding their path E.g. FCC enforcement: 15 companies named, shamed and/or fined at: http://www.fcc.gov/encyclopedia/weather-radar-interference-enforcement For one large corporation, the Consent Decree included: a. Compliance Officer. LargeCorp will designate a senior corporate manager ("Compliance Officer") who is responsible for administering the Compliance Plan. c. Compliance Reports. LargeCorp will file compliance reports with the Commission 90 days after the Effective Date, 12 months after the Effective Date, and 24 months after the Effective Date. Each report shall include a compliance certificate from the Compliance Officer stating that the Compliance Officer has personal knowledge that LargeCorp has established operating procedures intended to ensure compliance with this Consent Decree, together with an accompanying statement explaining the basis for the Compliance Officer's compliance certification. b. Training. LargeCorp will train and provide materials concerning Section 302(b) of the Act and Parts 2 and 15 of the Rules pertaining to U-NII devices and the requirements of the Consent Decree to those of its employees who are involved directly in the development and marketing of U-NII devices imported, marketed and sold by LargeCorp in the United States. Submission Slide 40 It is generally regarded as a careerlimiting maneuver to depend on a senior exec to clean up your mess i.e. the exec can now be subject to jail time if the mess doesn’t get cleaned up - and promptly: actions have consequences Re-engineering; and/or restricted orderability of products (fewer sales channels) Expensive personnel down-time Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 More regulatory background Each client’s manufacturer is responsible for ensuring that the client meets the regulations for which it was homologated More importantly, the default unlicensed radio frequency device regulatory approval is as a master device; to be approved as a client device the manufacturer must show that the frequencies and transmit powers the client device uses conform to regulations: Obvious but also incomplete client devices have the obligation to emit equal or less than what masters permit them to using exactly the same mechanisms that masters and clients were documented to use when working together when masters and clients were presented by manufacturer for homologation (see next slide) Especially if the local regulations could be location/time/AP-state dependent, but – by the previous bullet – actually anyhow, then the client also needs to hear the client permissions from its AP The client needs to get enough current-channel permissions from the Beacon that it can transmit to the AP (bootstrap) and preferably select one AP over another The client needs to get all current-channel permissions from the Probe/(Re)Assoc Response that it can participate fully in the BSS The client needs to get the next-channel permissions before/inside the channel switch Submission Slide 41 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 WISPA Links Are you near TDWR? – – http://wispa.cms.memberfuse.com/tdwr-locations-and-frequencies // starting to list two frequencies per TDWR If so, register here – – http://www.spectrumbridge.com/udia/home.aspx “This tool allows a user (network operator or installer) to: Search and confirm if their device is operating within 35 km proximity of TDWR site(s) Voluntarily register certain technical information into the online database” Submission Slide 42 Brian Hart,

doc.:IEEE 802.11-12/0297r0 Mar. 2012 5 GHz reality – – 11a/11h: CSA frame contains CSA element/CSA element in Bea/PrResp; takes you to anywhere within 5 GHz 11n: CSA element Secondary Channel Offset element in Bea/PrResp – – CSA frame contains CSA element Secondary Channel Offset element – – – – Operating class encodes location of primary channel within 40 MHz Neither ECSA nor Operating Class understood by 11a/11h clients Have to also send CSA frame for 11a/11h clients to get switched Shall send CSA optionally-ECSA or ECSA optionally-CSA if dot11ExtendedChannelSwitchActivated is false or true respectively CSA – freq only; no AP-state; ECSA – includes operating class to report AP state dot11ExtendedChannelSwitchActivated must be true for 3.65 GHz, 11v, or mesh (but not for 11n nor 11ac) – Have to also send the CSA element for 11a/11h clients to get switched ECSA element is marked as not extensible by 11mb ECSA frame contains Operating Class and Ch# – – – 11a/11h clients only had to understand the CSA element in the frame to get switched ECSA element contains Operating Class and Ch# – – 11a/11h clients only had to understand the CSA element to get switched CSA element is marked as not extensible by 11mb So we must allow for a mix of dot11ExtendedChannelSwitchActivated true and false No CSA 2004, rules came in 2005 for ChAvCheck; and then CSA start to be required practically; so 20042005 was like 2004 Operating triplets are little used Submission Slide 43 Brian Hart,