Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.:IEEE 802.11-12/0297r0 Submission Mar. 2012 Brian Hart, Cisco SystemsSlide 1 TPC, Operating Classes, and Channel Switching Date: 2012-03-04.

Similar presentations


Presentation on theme: "Doc.:IEEE 802.11-12/0297r0 Submission Mar. 2012 Brian Hart, Cisco SystemsSlide 1 TPC, Operating Classes, and Channel Switching Date: 2012-03-04."— Presentation transcript:

1 doc.:IEEE /0297r0 Submission Mar Brian Hart, Cisco SystemsSlide 1 TPC, Operating Classes, and Channel Switching Date:

2 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 2Brian Hart, Cisco Systems

3 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 3Brian Hart, Cisco Systems

4 doc.:IEEE /0297r0 Submission Mar And further regulations in subpart C i.e. TPC adv- Ised party = manu i.e. TPC adv- ised i.e. 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. The AP has the right and the responsibility to select the channels and the max TX power of the clients Which in turn refer us to more regulations Which in turn refer us to more regulations in subpart A And which also refers us to other subparts Which defines TX power, etc Part 15 has a subpart for UNII Case Study: TPC is a broad UNII requirement in FCC Part 15 Slide See also KDB Brian Hart, Cisco Systems

5 doc.:IEEE /0297r0 Submission Mar Transmit Power Units (1/5) Background The 5 GHz 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) 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” But regulators use a mixture of units FCC 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 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. Slide 5Brian Hart, Cisco Systems

6 doc.:IEEE /0297r0 Submission Mar Transmit Power Units (2/5) Existing Headache Slide 6 Specifically for and 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 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 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 language Brian Hart, Cisco Systems

7 doc.:IEEE /0297r0 Submission Mar 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: : 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 , “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: : “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.” Slide 7Brian Hart, Cisco Systems

8 doc.:IEEE /0297r0 Submission Mar Transmit Power Units (4/5) Solution Include units for VHT Transmit Power Envelope element Slide 8 Insert new octet for units. Efficient, not D2.0 compatible Insert new IE just for units. D2.0 compatible but very inefficient Add a final tuple with channel center frequency segment = 201, and with units in Segment Channel Width field. Inefficient, not D2.0 compatible 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 Units IdUnits 0Conducted 1EIRP 2Conducted/MHz 3EIRP/MHz 4-7 or Reserved 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 Brian Hart, Cisco Systems

9 doc.:IEEE /0297r0 Submission Mar Transmit Power Units (5/5) Solution Address other ambiguous uses of “transmit power” Slide 9 Field/element/frameProblemProposed fix 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” 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 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 Radio Information subelement Definition is incomplete (radiated or conducted?) Since this is for location, clarify that it is total radiated power 3.2: transmit powerDefinition is too narrow to be usefulIndicate that it is conducted or radiated according to context. Or delete Brian Hart, Cisco Systems

10 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 10Brian Hart, Cisco Systems

11 doc.:IEEE /0297r0 Submission Mar 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” Slide 11Brian Hart, Cisco Systems

12 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (1/7) Slide 12 Field/element/frameProblemProposed fix Notify Channel Width frame Single octet for channel widthDisallow Notify Channel Width frame being sent VHT to VHT 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 Basic requestOne channel number only, no operating class or semantics. Europe is allowing clients to be homologated to detect and report radar. Add Extended Basic Request also containing Operating Class, and for allow an optional subelement containing OpClass=“+80”, channel # Basic reportOne channel number only, no operating class or 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 CCA request One channel number only, no operating class or 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 CCA reportDitto Brian Hart, Cisco Systems

13 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (2/7) Slide 13 Field/element/frameProblemProposed fix RPI histogram request One channel number only, no operating class or 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/ RPI histogram report Ditto Channel load request OpClass+Ch# only, no primary channel indication for >40MHz (needed to specify which virtual carrier sense is used), no 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/ Channel load report DittoDitto. Measurement is for the whole bandwidth Noise histogram request OpClass+Ch# only, no primary channel indication for >40MHz (needed to specify which virtual carrier sense is used), no 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/ Noise histogram report Ditto Brian Hart, Cisco Systems

14 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (3/7) Slide 14 Field/element/frameProblemProposed fix Beacon request OpClass+Ch# only, no primary channel indication for >40MHz, no semantics. Only one operating class. Beacons should only be sent at 20 MHz, but rogues could do anything 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/ Beacon report DittoDitto (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) Frame request OpClass+Ch# only, no primary channel indication for >40MHz, no 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/ Frame reportDittoDitto (includes all received frames irrespective of bandwidth) Brian Hart, Cisco Systems

15 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (4/7) Slide 15 Field/element/frameProblemProposed fix AP Channel Report element No 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) Neighbor Report element OpClass+Ch# only, no primary channel indication for >40MHz, no 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/ Multiple BSSID element Contains Supported Operating Classes element etcUpgrade to reflect any changes to Supported Operating Classes element etc DSE Registered Location element OpClass+Ch# only, no primary channel indication for >40MHz, no semantics; no optional subelements - not marked as extensible. Yet, no 80/160 MHz spectrum with DSE (yet?) No change. 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, Cisco Systems

16 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (5/7) Slide 16 Field/element/frameProblemProposed fix Extended Channel Switch Announcement element Only one operating class (inadequate for mixed clients), no 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 Supported Operating Classes element No semantics.Define a new “+80” OpClass so 80,80, +80 can indicate 80, 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 /40 Intolerant Channel report element No semantics.No change. Specific to 2.4 GHz Peer-to-peer Link event request No semantics.Define a new “+80” OpClass so two subelements 80, +80 can indicate Peer-to-peer Link event report No semantics.To VHT STAs only, allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the peer channel for 80/160/ Brian Hart, Cisco Systems

17 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (6/7) Slide 17 Field/element/frameProblemProposed fix Diagnostic information subelement descriptions (AP Descriptor subelement format) Only one operating class (inadequate for mixed recipients), no 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 Location Indication Channels subelement No semantics, but 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 Channel Usage element No semantics.Define a new “+80” OpClass so 80, +80 can indicate Measurement Pilot frame format OpClass+Ch# only, no primary channel indication for >40MHz, no 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/ Extended Channel Switch Announcement frame format OpClass+Ch# only, no primary channel indication for >40MHz, no 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/ Country element also be optionally allowed Brian Hart, Cisco Systems

18 doc.:IEEE /0297r0 Submission Mar Solution: Channel number identification (7/7) Slide 18 Field/element/frameProblemProposed fix DSE Measurement Request frame format OpClass+Ch# only, no primary channel indication for >40MHz, no semantics; no optional subelements. Yet, no 80/160 MHz spectrum with DSE (yet?) No change. 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) DSE Measurement Report frame format OpClass+Ch# only, no primary channel indication for >40MHz, no semantics; no optional subelements. Yet, no 80/160 MHz spectrum with DSE (yet?) 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” TDLS Channel Switch Request Action field format OpClass+Ch# only, no primary channel indication for >40MHz, no semantics; no optional subelements. Allow Wide Bandwidth Channel Switch element as an optional subelement, as is already addressed by 11acD2.0 Brian Hart, Cisco Systems

19 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 19Brian Hart, Cisco Systems

20 doc.:IEEE /0297r0 Submission Mar Country element format Slide 20 11h – very oldMultiple instances of these, implicitly for a 20 MHz operating class Country StringN SubbandTriplets Element ID LengthCountry Code Operating Table IndexFirst channelNumber of Channels Max Transmit Power Level Pad Octets /1 Country element in Beacons and Probe Responses is the only 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 Brian Hart, Cisco Systems 11j/n/p/y /mb… more modernMultiple instances of these, one per Operating Triplet Country String1 Operating TripletN SubbandTriplets Element ID LengthCountry Code Operating Table Index 201Operating Class Coverage Class First channel Number of Channels Max Transmit Power Level PadPad Octets /10/1

21 doc.:IEEE /0297r0 Submission Mar 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) Slide 21 20/40 MHz operating triplet for P20 and P40 80 MHz operating triplet for P80160 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 160 MHz BSS 160 or MHz BSS 20/40 MHz operating triplet for P20 and P40 Subband triplet for 20/4080 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 MHz BSS with TPC Brian Hart, Cisco Systems

22 doc.:IEEE /0297r0 Submission Mar How to use the Country element to express multiple Operating Classes Slide 22 20/40 MHz UNII operating triplet for P20 and P40 20/40 MHz operating triplet for P20 and P40 80 MHz UNII operating triplet for P80 80 MHz operating triplet for P80 Note 1: Allowed today; this is an “OR” relationship 80 MHz BSS on ch155 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 , how can we express these both – given that this is now an “AND” relationship? Solution: define First Channel = 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 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 operating triplet for P20 and P40 (225)” 80 MHz BSS on ch138 Brian Hart, Cisco Systems

23 doc.:IEEE /0297r0 Submission Mar How to use the Country element to deal with wide spectrum crossing multiple regulations Slide 23 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) 160 MHz BSS on ch155 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? Brian Hart, Cisco Systems

24 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 24Brian Hart, Cisco Systems

25 doc.:IEEE /0297r0 Submission Mar 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) Slide 25Brian Hart, Cisco Systems

26 doc.:IEEE /0297r0 Submission Mar Channel Switch (2/4) From earlier slides, the AP has a right and a responsibility to perform TPC 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. 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). i.e. 11ac doesn’t have a way for the AP to change channel and power at the same time 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. Slide 26Brian Hart, Cisco Systems

27 doc.:IEEE /0297r0 Submission Mar 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 E.g. to move a BSS from UNII ch36 to ch149, and ensure that all capable clients adopt not UNII rules at ch149 (for more power) In Japan, a channel switch from say GHz (using the Global Operating Class Table) to say 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 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 Slide 27Brian Hart, Cisco Systems

28 doc.:IEEE /0297r0 Submission Mar 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) Slide 28Brian Hart, Cisco Systems

29 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 29Brian Hart, Cisco Systems

30 doc.:IEEE /0297r0 Submission Mar 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) Slide 30Brian Hart, Cisco Systems

31 doc.:IEEE /0297r0 Submission Mar Operating Class Tables (2/4) Is a standalone Global Operating Table better? Usually not. Slide 31 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 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 – not advised) Brian Hart, Cisco Systems

32 doc.:IEEE /0297r0 Submission Mar Operating Class Tables (3/4) Solution Details Differentiate Operating Classes purely by 2-octet Country code and Operating Class: 1-80 is country-dependent, is Global (and country-independent), 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 Slide 32 DescriptionValuesUSA: US? (“?” = wildcard) Europe: DE?, FR?, … Japan: JP? Additional countries with time/location/AP-state dependence not expressed by TX power limits that deviates from international defaults Country1-80~33/80~17/80~61/800/80 Global81-191~50/111 in use Vendor Specific ???0 Reserved0, Aggressively deprecate redundant Country Operating Classes to create room for future growth (Japan can be lowered to ~22/80 i.e. The same values are used worldwide Brian Hart, Cisco Systems

33 doc.:IEEE /0297r0 Submission Mar 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 and 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 Slide 33Brian Hart, Cisco Systems

34 doc.:IEEE /0297r0 Submission Mar 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 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 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 Slide 34Brian Hart, Cisco Systems

35 doc.:IEEE /0297r0 Submission Mar Shared Spectrum (1/3) Background BTW, to 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 AP or vice versa, as long as each individually meets its regulatory requirements Slide 35Brian Hart, Cisco Systems

36 doc.:IEEE /0297r0 Submission Mar Brian Hart, Cisco Systems 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 ) 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-promulgated- regulation-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 ) Slide 36 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: B0B1B2:B4B5:B7 0 = OR with next operating triplet 1 = AND with next operating triplet (See earlier slides) 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 Reserved7 (i.e. +224)

37 doc.:IEEE /0297r0 Submission Mar 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/AP- state 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 Slide 37Brian Hart, Cisco Systems

38 doc.:IEEE /0297r0 Submission Mar Open Discussion Slide 38Brian Hart, Cisco Systems

39 doc.:IEEE /0297r0 Submission Mar Backup Slides Slide 39Brian Hart, Cisco Systems

40 doc.:IEEE /0297r0 Submission Mar 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 It is generally regarded as a career- limiting maneuver to depend on a senior exec to clean up your mess 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: 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. Slide 40Brian Hart, Cisco Systems

41 doc.:IEEE /0297r0 Submission Mar Slide 41 More regulatory background Each client’s manufacturer is responsible for ensuring that the client meets the regulations for which it was homologated Obvious … but also incomplete 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: 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 Brian Hart, Cisco Systems

42 doc.:IEEE /0297r0 Submission Mar 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” Slide 42Brian Hart, Cisco Systems

43 doc.:IEEE /0297r0 Submission Mar 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 –11a/11h clients only had to understand the CSA element to get switched –CSA element is marked as not extensible by 11mb CSA frame contains CSA element + Secondary Channel Offset element –11a/11h clients only had to understand the CSA element in the frame to get switched ECSA element contains Operating Class and Ch# –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# –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) 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 was like <2004 –Operating triplets are little used Slide 43Brian Hart, Cisco Systems


Download ppt "Doc.:IEEE 802.11-12/0297r0 Submission Mar. 2012 Brian Hart, Cisco SystemsSlide 1 TPC, Operating Classes, and Channel Switching Date: 2012-03-04."

Similar presentations


Ads by Google