Presentation is loading. Please wait.

Presentation is loading. Please wait.

TPC, Operating Classes, and Channel Switching

Similar presentations


Presentation on theme: "TPC, Operating Classes, and Channel Switching"— Presentation transcript:

1 TPC, Operating Classes, and Channel Switching
Month Year Month Year doc.: IEEE /0297r0 TPC, Operating Classes, and Channel Switching Date: Slide 1 Brian Hart, Cisco Systems Page 1 John Doe, Some Company John Doe, Some Company

2 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 Brian Hart, Cisco Systems

3 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 Brian Hart, Cisco Systems

4 Case Study: TPC is a broad UNII requirement in FCC Part 15
Part 15 has a subpart for UNII i.e. TPC adv- Ised party = manu ised 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. Which defines TX power, etc 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 1 Which in turn refer us to more regulations in subpart A And further regulations in subpart C And which also refers us to other subparts 2 See also KDB Brian Hart, Cisco Systems

5 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. Brian Hart, Cisco Systems

6 Transmit Power Units (2/5) Existing Headache
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 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.” Brian Hart, Cisco Systems

8 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 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 Id Units Conducted 1 EIRP 2 Conducted/MHz 3 EIRP/MHz 4-7 or 4-255 Reserved Insert new IE just for units. D2.0 compatible but very inefficient Insert new octet for units. Efficient, not D2.0 compatible Brian Hart, Cisco Systems

9 Month Year doc.: IEEE /0297r0 Transmit Power Units (5/5) Solution Address other ambiguous uses of “transmit power” Field/element/frame Problem Proposed 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? 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 Brian Hart, Cisco Systems John Doe, Some Company

10 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 Brian Hart, Cisco Systems

11 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” Brian Hart, Cisco Systems

12 Solution: Channel number identification (1/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (1/7) Field/element/frame Problem Proposed fix Notify Channel Width frame Single octet for channel width Disallow 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 request One 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 report One 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 report Ditto Brian Hart, Cisco Systems John Doe, Some Company

13 Solution: Channel number identification (2/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (2/7) Field/element/frame Problem Proposed 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/80+80. 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 Ditto. Measurement is for the whole bandwidth. Noise histogram request Noise histogram report Brian Hart, Cisco Systems John Doe, Some Company

14 Solution: Channel number identification (3/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (3/7) Field/element/frame Problem Proposed 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 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) Frame request OpClass+Ch# only, no primary channel indication for >40MHz, no semantics. Frame report Ditto (includes all received frames irrespective of bandwidth) Brian Hart, Cisco Systems John Doe, Some Company

15 Solution: Channel number identification (4/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (4/7) Field/element/frame Problem Proposed 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 etc Upgrade 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 John Doe, Some Company

16 Solution: Channel number identification (5/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (5/7) Field/element/frame Problem Proposed 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 80+80 Supported Operating Classes element No semantics. Define a new “+80” OpClass so 80,80, +80 can indicate 80,80+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 change. Specific to 2.4 GHz Peer-to-peer Link event request Define a new “+80” OpClass so two subelements 80, +80 can indicate Peer-to-peer Link event report To VHT STAs only, allow Wide Bandwidth Channel Switch element as an optional subelement to indicate the peer channel for 80/160/ Slide 16 Brian Hart, Cisco Systems John Doe, Some Company

17 Solution: Channel number identification (6/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (6/7) Field/element/frame Problem Proposed 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 John Doe, Some Company

18 Solution: Channel number identification (7/7)
Month Year doc.: IEEE /0297r0 Solution: Channel number identification (7/7) Field/element/frame Problem Proposed 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 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 Allow Wide Bandwidth Channel Switch element as an optional subelement , as is already addressed by 11acD2.0 Brian Hart, Cisco Systems John Doe, Some Company

19 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 Brian Hart, Cisco Systems

20 Country element format
11h – very old Multiple instances of these, implicitly for a 20 MHz operating class Country String N SubbandTriplets Element ID Length Country Code Operating Table Index First channel Number of Channels Max Transmit Power Level Pad Octets 1 2 0/1 11j/n/p/y /mb… more modern Multiple instances of these, one per Operating Triplet Country String 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 Octets 1 2 0/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

21 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 160 MHz BSS 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 or MHz BSS 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 80+80 MHz BSS with TPC Brian Hart, Cisco Systems

22 How to use the Country element to express multiple Operating Classes
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 Idle thought: Reserve “Coverage Class” in new operating classes?
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) 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 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 Brian Hart, Cisco Systems

25 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) Brian Hart, Cisco Systems

26 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. Brian Hart, Cisco Systems

27 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 Brian Hart, Cisco Systems

28 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: (Wide Bandwidth Channel Switch element could be moved inside this wrapper element) Brian Hart, Cisco Systems

29 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 Brian Hart, Cisco Systems

30 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) Brian Hart, Cisco Systems

31 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 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 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 Description Values USA: 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 Country 1-80 ~33/80 ~17/80 ~61/80 0/80 Global 81-191 ~50/111 in use Vendor Specific ? Reserved 0, 255 - 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 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 Brian Hart, Cisco Systems

34 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 Brian Hart, Cisco Systems

35 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 Brian Hart, Cisco Systems

36 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 ) 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 B1 B2:B4 B5: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 Reserved 7 (i.e. +224) Brian Hart, Cisco Systems

37 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 Brian Hart, Cisco Systems

38 Open Discussion Brian Hart, Cisco Systems

39 Backup Slides Brian Hart, Cisco Systems

40 Month Year doc.: IEEE /0297r0 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. It is generally regarded as a career-limiting 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 Interference happens, regulators come calling. If shortly thereafter the interference is still happening, then oftentimes a consent decree is negotiated between lawyers. The *manufacturer* is the responsible party in part 15, and any operator can cause trouble for the manufacturer. Re-engineering; and/or restricted orderability of products (fewer sales channels) Expensive personnel down-time Brian Hart, Cisco Systems John Doe, Some Company

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 WISPA Links Are you near TDWR? If so, register here
// starting to list two frequencies per TDWR If so, register here “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” Brian Hart, Cisco Systems

43 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 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 Brian Hart, Cisco Systems


Download ppt "TPC, Operating Classes, and Channel Switching"

Similar presentations


Ads by Google