

Friday, August 14, 2009

802.11h Parameters

If you are used to exploring your controller features and pages, you probably know this page, under Wireless > 802.11a > DFS (802.11h). It is probably the page that generates most questions when I teach the Cisco Wireless Mesh classes, as 802.11h is often not well understood.

802.11h is part of the 802.11-2007 specification. Many airport radars use the UNII-2 and UNII-2 frequency ranges (channels 52 to 140). Any 802.11 equipment operating in this frequency range is supposed to be able to detect these airport radar signals and move away so that the radars can operate safely without our APs interference. This process is called DFS, Dynamic Frequency Selection.

I have never seen any airport radar actually using these frequencies to land planes. They have plenty of other frequencies for that. The UNII-2 and UNII-2 extended are more commonly used for weather reporting. The worst I saw was a radar reporting snow in a hot summer due to an AP interference... but the AP had an amplifier, a directional antenna and was pointing directly at the radar. This was experimental more than anything else. In most cases, your AP is too weak to disturb a radar. The 802.11h still rules that if your AP detects a radar blast, it has to move to another frequency. The process is as follows:
- Your AP, operating on any of the UNII-2 or UNII-2 extended channels, receives a blast from a radar. The AP recognizes this signal as a blast, because the AP is used to performing Radar Detection Measurements, through which it can recognize several typical "radar blast patterns", such as "pulses of identical power, 1 microsecond wide, with a frequency of 700 pulses per second, with blasts of 26 milliseconds each". This description is just an example. The 802.11h protocol actually states that has to be considered as a radar blast any signal in these frequencies stronger than -61 dBm at the Ap level, and that the AP "cannot prove not to be radar blasts". In other words, if you don't know what it is, it's a radar blast.
- From this instant, your AP has 10 seconds to move to another channel. This is called the channel move time.
- During these 10 seconds, your AP has a lot to do! It must find another channel to jump to. In a controller based solution, the controller picks up a random new channel (among the list of allowed channels) and sends it to the AP.
- The AP jumps to the new channel, and silently listens for 60 seconds. Its aim is to detect any radar blast on this new frequency (in which case the AP changes channel again). If the new frequency is quiet, the AP resumes its conversations after this 60 second period. This is called the Channel Availability Check Time.
- Radars do not always use the same frequencies. They try to detect a certain weather pattern at a certain distance, for which a specific frequency is more efficient. As the weather usually does not change every minutes, radars typically use a frequency for a little while (until they get a clear picture of the weather trends reported in this frequency), then leave the frequency. For this reason, when your AP leaves a channel, it blacklists the channel for 30 minutes. This is called Channel non-occupancy Period. After 30 minutes, if the AP has to change channel again, the previously blacklisted channel re-becomes part of the list of potential channels.

All this is well, but what about the clients? If the AP suddenly moves to another channel, clients will be disconnected!... and 60 seconds of Channel Availability Check Time? This is going to kill all sessions!
Well, there is another solution. The AP could check new channels... before blasts occur. In this mode, the AP leaves the main channel every now and then, and scan new channels. To avoid losing client frames while the AP is away, the AP can send a Channel Quiet 802.11 "action message", which is a beacon telling the clients in the cell not to send anything for a while (the while is defined in another beacon) while the AP is away. With this method, the AP would know about the new channels when the problem occurs, could jump to a new channel and immediately resume its conversations. This was the original mechanism, called In Service Monitoring (the AP scans while serving an active channel). But if you think about it, this may not be the most efficient method. First of all, the AP still needs to scan any new channel for a total of 60 seconds before being able to use it. How many times would this AP have to jump from its original channel to get 60 seconds worth of information on any new channel? Secondly, what guarantee does this mechanism offer? Even if a channel was seen as "free", a blast could occur any time (the channel on which the AP was previously transmitting was also "free" until it got a sudden blast). So this method might not be that better after all.

Verifying the new channel availability when needing to jump is probably more efficient, even if UDP connections might probably drop. TCP connections will probably just have their window slide down while asking for missing packets retransmission. This if the stations know that the AP is jumping, and to which channel! This is where the screenshot above plays its role. During the channel move time (the 10 second window), the AP is supposed to stop all communications, but this is not realistic. What about beacons, client frames, probes, etc.? The 802.11h mechanism allow a certain number of transmissions: 260 milliseconds. In other words, whatever the AP transmits during these 10 seconds, the total duration all these frames added together must not exceed 260 milliseconds worth of channel utilization. This is called the Channel Closing Transmission Time. Don't get it wrong. It is not one long message. The AP can send a few milliseconds worth of traffic, then stop, then send something else, etc. At the end of the 10 second window, the transmitted amount must be less than 260 milliseconds worth of channel utilization. So the AP is going to look carefully at what it can send. It is actually going to continue sending beacons (so that clients still detect the AP), and also answer probe requests (with probe responses). All other transmission is stopped: no data packet, no ACK. All wireless packets reaching the AP are silently dropped.
Wow, that's rough: clients send packets, never get any ACK, and after 10 seconds the AP disappears to a new, unknown, channel... and when they scan to find the AP, they won't hear anything from this AP for another 60 seconds! To make the all process smoother, you can check the Channel Announcement box. This makes that when the AP jumps to the new channel, it first sends an 802.11h Channel Announcement message, telling its client that it is jumping to another channel, and giving them the channel frequency. This allows the clients to jump along with the AP. They know that the AP has to stay silent for 60 seconds when getting to the new channel, but they can jump and wait (to a new, silent channel) for the AP to resume its communications. At least they know where the AP is, even if they do not hear it.
To be even nicer, you can check the Channel Quiet Mode box. This makes that the AP, upon entering the Channel Move Time window, sends a "Quiet Message" to its clients, in which it says "do not communicate". The clients know that they don't have the right to communicate, so you avoid this situation where they send packets that are never acknowledged (therefore retransmitted again and again in vain).

The upper section of the screen is about the second feature, TPC, Transmit Power Control. The 802.11h protocol states that the AP (and the wireless clients!) must be able to reduce its power level to the minimum value needed for its operation. In other words, if you are an access point, do not shout! You may disturb a neighboring radar. Reduce your power to be just loud enough to be heard by your clients, no more. The fine line is that the 802.11h protocol states that the AP must “be able to” reduce its power, not that it “has to” reduce its power. So most vendors implement the ability without forcing the behavior. But Cisco APs do implement it. The AP sends in its beacons a 802.11d value that sets the max power value for the local regulatory domain, and the 802.11h Power Constraint value tells the client (the other mesh APs in this case) by how much they should try to reduce their power below the local regulatory max. The controller can reduce the client -mesh-AP power with 802.11h (this is called Transmit Power Control, TPC, not to get mixed with Dynamic Transmit Power Control, which is a CCX feature by which an AP can as a client to be louder or quieter to improve the communication quality). To actually use the TPC, check the Power Constraint box. A new field allows you to set “how quieter” the client is expected to try to be. Keep in mind that - 3 dB is half the power, so every 3 dB allows the AP-client to reduce its power by half. A common value is 9 dB, allowing the AP-client to divide its power level by a factor of 8 (3 dB + 3 dB + 3 dB, which is power level divided by 2, then divided by 2 again, and divided by 2 another time). This starts from the local regulatory domain max value (not from the AP max value), and any value below the target is okay. So for example, if regulatory max is 30 dBm, and you set 9 dB in this field, your AP tells its clients to not go above 21 dBm, even if (still 'for example') your AP max power is 24 dBm.


  1. J,

    Is the first sentence supposed to read unii-2 and unii2 extended?

  2. Thanks a lot. There was no documentation for "quite channel mode" in cisco documents. Thanks a lot for explaining it.

  3. Hey Jerome,

    Please pardon my ignorance, but I wanted to ask a general wireless question. Didn't find any link ot post random wireless question. Hence posting it here.

    Suppose we have 3 wireless clients. A,B and C. C is sending packets on the wireless channel.As soon as it receives the last ACK from the AP with a NAV of 0, the DIFS starts ticking. NOW, after the end of DIFS the CW sarts off. Suppose client A randomly selects a slot time of 2 and B selects a slot time of 4. I would like to understand the process of traffic transmission after this.

    Many thanks in advance.

  4. Hey Manish,
    Thanks for asking. B and C would count down in parallel (and each would ignore that the other one picked a CW and is counting down). At each number down (3 for B and 1 for A), both would listen to the channel to check if there is any signal detected (the signal has to be a certain strength, defined as 20 dBM above the minimum sensitivity defined by the 802.11 standard for that band, most of the time we say that the signal should be about -65 dBm to be read, but it is a bit more complicated than that). If there is a signal, each detecting station would try to see if it can detect an 802.11 header that would tell them the duration of the transmission (Duration field in the header). If that field can be read, then each detecting station adds this duration to its CW and restarts counting down from the new number. If the duration field is not read but the signal is strong enough, each detecting station stops counting down and listens to the air at each slot time (as if the station was counting down, but the CW does not decrease) until the signal is gone. The stations then resume their countdown. A funny aspect is that if one station hears the signal above the threshold (say -65 dBm) it will stop counting down for the duration of the signal, but if the other station is farther away from the signal source, it may hear it way below the threshold and simply ignore it (continuing to count down).
    If both stations heard the signal the same way, A will get down to 0, listen to the medium, find it silent, and will start sending its frame. At this point B (still left at 2 in the countdown) would hear A signal, would try to read the duration field, and would restart counting down from 2+duration field...
    Does that make sense? :-)

  5. Thanks for the excellent explanation Jerome..and apologies for reading it so late...It definitely clarifies my doubt. One more relevant question : Do all the wireless clients (irrespective of the supplicant) implement the same algorithm to grab the slot during the CW ?

    Thanks in advance.

    1. Hi Manish,

      Yes, if the clients are 802.11 certified, they have that same behaviour...

  6. Hi Jerome,

    The article written above is about DFS (802.11h). I understood that the PA actually sends a channel switch announcement for the clients before changing the channel and the clients stop sending traffic for the specified period. However, in the case of Off-channel scanning done on both 802.11b/g or 11a radio, when the Cisco AP goes off-channel after every 16 seconds for a period of 50ms , what happens to the client traffic ?


  7. Okk...so just going once again through the above article I assume that my question is related to in-service monitoring. So, during in-service monitoring, does the AP always send the channel quiet message to the clients to let them know that "I am going to jump to some other channel to scan it for 50 ms". The clients will not expect any ACK form the AP during this period.


    1. Hi Manish,
      Sadly no... the 802.11h mechanism is reserved for radar ("valid emitter") avoidance operations. So the APs can't use it (also, 802.11h is only valid in UNII-2 and UNII-2, so a 802.11b/g client would not understand it anyway.
      When the AP has buffered traffic for some configurable queues, it defers its jump to another channel (it understand that there is active communication in the cell). It only jumps away if there is no active traffic. It is always possible that a client would wake up during the time the AP is away and would send a frame. It would not get Acked, so the client would wait an EIFS, pickup a new number and resend. Most likely, the AP will be back by then...

  8. Hi Jerome,

    If we select 9dBm at the power constraint value, does that mean AP cannot go below 1/8th of its max power ? Is this is the place where we control AP power cannot go down certain value in Unified Wireless environment ?


    1. This comment has been removed by the author.

    2. Hi Rasika,
      the dBm start from the AP max power (level 1, which is the max power allowed in the AP country of operation, of course the exact value depends on the country - the AP specifies the max value in the beacon 802.11d field), then each chunk of 3 dB is one power level less.
      So: level 1 is max power (0 dBm)
      -3 dB is power level 2 (local regulatory domain max power - 3dBm)
      -6 dB is power level 3 (local max - 6 dBm)
      -9 dB is power level 4 (local max - 9 dBm)
      Selecting 9 dB means that your AP tells its clients (the mesh APs down the line) to try to be at level 4, but not higher than 4. This is the place where you control how low the AP can go when dynamically negotiating its power with TPC/802.11h, typically on a mesh backhaul. The reason is to avoid overloading in the links. Suppose the following structure:


      Suppose that RAP and MAP1 figure out that they can lower their power by 15 dBm (from level 1 to level 6)... they do it, but MAP2 is a bit far from MAP1, and now MAP2 and MAP1 would be more comfortable speaking louder (to loud is not a problem for us :-)), this would be an issue. Of course, MAP2 would scream at MAP1, and they would renegotiate together and now MAP1 is back to super loud. But this makes the structure unbalanced (MAP1 will go down again next time RAP asks it to do so). This is why the config allows you, the admin, to set up a tentative ceiling value, above which you know that your APs should not go.
      Now, this is for mesh and TPC. For normal operations, there is a wireless / 802.11a|802.11bg page with a DCA tab, where you can decide how high or how low your normal APs can go (as far as power is concerned). You can also statically set the power at the AP level.
      Please also keep in mind that the max is based on the country max, not on the AP max. SO I use power 1 as a general reference, but if you have local regulatory max = 30 dBm, and local AP max = 24 dBm, saying "power constraing = 9 dB" means that you allow going down 9 dB from 30 dBm (not from 24), so you allow powers from 21 dBm and down, which means power levels 2 and less (3,4,5 etc).

    is that mean all 802.11 certified clinets can do that? and is this for UNII2 and UNII2e?

  10. Hi Ehsan,
    all 802.11 clients operating in the UNII-2 and UNII-2e bands must be able to do that. This is not very difficult (just an exchange of frames with the AP). What is more complicated is that they must also be able to detect radar blasts (just like an AP). For this reason, quite a few clients on the market simply do not support those 2 bands...

  11. Thank You for the reply,
    Unfortunately most datasheets for these devices “Clients” doesn’t mention anything about which channels or which frequencies they support for their 5GHz products. Example Apple Devices, new iPAD and new iPhone they mentioned in the device datasheet that they support 5GHz but they didn’t list which channels or which frequencies they supported, I had to check “WiFi Alliance” web site for these certified clients. If someone interested this is how:
    Go to http://www.wi-fi.org/certified-products-search and click “Advanced Search” and put any parameters you want then under “Spectrum & Regulatory Features” check 802.11h checkbox
    I had to search these categories to find all WiFi clients: Phones/SmartPones/Tables/Laptops/other
    What I found is almost all new products (2012-2013) including iPAD, iPAD2, iPADmini, iPhone5, Microsoft tablet, etc...supporting 802.11h but still a lot of old devices doesn’t…

  12. Thanks Ehsan,
    Yep, 100% agree, the WFA site is best to check details. I also like the FCC and ETSI sites (not super user friendly, but full of info). Most vendors only advertize the shinny parts, and keep silent the less glorious parts. For example, Iphone 5 does support most channels in the 5 GHz band (shinny), and therefore has to support 802.11h (normal and cool, so far). But they do not advertize loud that the PIFA antenna they use allows for 16 dBm average in the 2.4 GHz, but only about 12 to 13 dBm (depending on channels) in the 5 Ghz range... 3 dBm is twice, so this is 2 times less signal in 5 Ghz than in 2.4 Ghz, in a band that already has less coverage (not shinny :-))

  13. Could someone please tell me where I can find the power levels for any smartphone or any WLAN NIC card. I tried to search everything in manufacture’s documents and didn’t find anything related as the above dBm power levels for IPhone 5.

  14. You will not find it easily, as vendors do not publish them, and they also sometimes vary with theaters and local regulations. A nice place to fish is the FCC site (https://apps.fcc.gov/oetcf/eas/reports/GenericSearch.cfm), if you know the device code (usually easy to find through web search). For example, Iphone 5 is BCG grantee, and product -E2599A. By digging through thre sults, you will see the max power, but you also need to see that it uses a PIFA antenna that adds up to -1.86 dBm loss to your phone, resulting in total EIRP of 12 dBm in most bands...

  15. Thank You Jerome, you’re truly gift from God to all of us…much appreciated…

    1. Ehsan,
      Not sure whose God (Christian, Muslim, Jew, yada yada,...) you're referring to, but as a borderline agnostic atheist, who often outruns his guardian angel, and right leaning liberal with conservative redneck tendencies (e.g., Volvo should manufacture a 4x4 pickup truck for the U.S. market) that enjoys an occasional slice of quiche (with bacon and beef), is it OK, using the Duality of Man functions and features, if I thank Jerome's mother and father for raising a great kid?

  16. Hello everybody,
    regarding to 802.11h addendum to 802.11 and EN301893. EN301893 said, that IEEE802.11 standard is nessesary for apply EN301893 itselfs. Must be 802.11h implemented or may be. I am little bit confused, because some manufacturer (ie. UBNT - AirOs latest version) contain in management packets 802.11h headers (ie. Spectrum management enabled information, Country code and available channels) and other (ie.Mikrotik - RouterOS latest version) this function doesn't have implemented yet.
    Can somebody explain it for me, please...

  17. Hello,

    1) What is the difference between 'Quiet element' and 'Quiet period'? Are they both related to DFS?

    2) The software release notes with our access point (see below) says that the 'Quiet element' is not supported. Does this device support DFS?

    3) We used the Wireshark application to monitor to 802.11 traffic. There are no apparent fields in the beacon frame, association management frame, probe request management frame, or the action management frame which describe the specifications of a quiet time or a coordinated sensing gap. There was no evidence of using a ‘fake’ client to force a sensing gap. Should we be seeing some type of DFS related coordinated sensing gap messages?



    802.11r, 802.11k, and 802.11w Deployment Guide, Cisco IOS-XE Release 3.3
    Last Modified: January 25, 2014

    •In this release the following features are not supported:
    ◦TSF Offset
    ◦TPC request/response
    ◦Beacon request/response
    ◦Quiet element with hardware beacon

  18. Hello,

    Do all DFS manufacturers implement the Quiet Time period (Quieting the current channel so it can be tested for the presence of radar with less interference from other STAs.)? Is there a reason not to use this feature?


  19. There is shocking news in the sports betting industry.

    It has been said that any bettor must watch this,

    Watch this now or stop betting on sports...

    Sports Cash System - Advanced Sports Betting Software.
