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.