10-26-2010 06:36 AM - edited 11-18-2020 02:51 AM
802.11h was meant to bring two main features : DFS and TPC. DFS, Dynamic Frequency Selection as spectrum management (mainly to co-operate with radars) and TPC, Transmit Power Control, to limit the overall RF “pollution” of wireless devices.
DFS is all about radar detection and avoidance. Radar stands for “Radio detection and ranging”. In the past, the radars used to operate in frequency ranges where they were the only type of device operating there. Now that regulatory agencies are opening those frequencies for other uses (like wireless LAN), there is a need for those devices to operate in accordance of the radars.
The general behavior of a device complying with the DFS protocol is to be able to detect when a radar is occupying the channel, stop using that occupied channel, monitor another channel and jump on it if it is ok. (i.e. no radar there as well).
The process for a radio to detect a radar is a complicated task that is actually not part of the standard. Hence, wrong radar detections can occur.
DFS is required for ETSI devices working in the European Union in the ETSI 5ghz band. It can be not mandatory in other parts of the world.
DFS operations use different ways of exchanging information between stations. Information can be put in specific elements in the beacon or probe response but a specific frame can also be used to report information: the action frame. We will introduce that after we explain when they come into play.
Radars may be fixed (often civilian airport or military base, but also weather radar) or mobile (ships). A radar station will transmit a set of powerful pulses periodically and observe the reflections. Because the energy reflected back to the radar is much weaker than the original signal, the radar has to transmit a very powerful signal. Also, because the energy reflected back to the radar is very weak, it could confuse it with other radio signals (like a wireless LAN to give an example).
Because the 2.4Ghz band is free of radar, the DFS rules only apply to the 5.250 ->5.725 Ghz band.
When the radio detects a radar, it must stop using the channel for 30 minutes at least to protect that service. It then monitors another channel and can start using it after at least 1 minute if no radar was detected.
The following topic are more related to troubleshooting in a Cisco environment rather than explanation about the standard. However, some points might be of interest for everyone and are short enough to be briefly explained here below.
Unless you are using a dual-backhaul, all your RAP and MAPs operate on the same channel. Thus it can happen that only a MAP detects the radar. It will then be the only one to change channel and will be unavailable to talk to the other APs for at least 30 minutes (time to come back). If you want you whole backhaul to move as soon as one AP detects a radar, then you can enable the “channel announcement” feature and the AP detecting the radar will tell the others before switching channel. They will then all scan another channel for 1 minute.
There is a delicate balance between being sensitive enough to meet DFS requirements (detecting radars) and not being to sensitive in order to avoid false detection. The most common cause of incorrect detection is, for cost reasons, putting another AP co-located (on the same pole for example). Even if that AP is using another channel, if that channel is close, some pulse can occur off-band for this other AP but will be seen as in-band pulses and incorrectly taken as a radar. Best solution is careful channel planning and AP placement.
Another cause is a radar that has some dirty off-channel signal transmission or is so powerful on its channel that it has sideband transmission on adjacent channels.. So even if the AP is on the channel next to the radar, the radar is sending some side signals on the AP channel causing the AP to believe a radar is operating on the channel, though it is not. Solution here is still to change AP channel and AP placement.
You mainly spot DFS events with traplogs, but alternatives are :
sh int d1 dfs (on AP)
sh mesh dfs h (on AP)
AP will remember those until next reboot.
For VxWorks based APs (10xx, 1510) :
printRadar()
Customers deploying outdoor APs in EU or regions with similar regulations should enable this option.
> config advanced 802.11a channel outdoor-ap-dca enable
When enabled Controller will not perform check for non-DFS channels in DCA list. Default status is Off (existing behaviour).
More details on CSCsl90630.
Have you heard about TPC (Transmit Power Control), DTPC (Dynamic Transmit Power Control), and World Mode? They look the same, but do not actually do the same things... let's have a quick look at each of them:
- World Mode is probably the oldest one. It is a feature you can configure on the Autonomous (OIS) access points, and by which a client in World Mode receives its " radio parameters" from the access point. If you look a bit closer, you might read that "parameters" are actually channels and power levels. But don't take it wrong. "Channels" has an "s". It is not the channel on which the client should be! To hear the access point, the client has ANYWAY to be on the right channel. So what World Mode is about is "the list of allowed channels in this country" and "the power level ranges allowed in this country".
World mode is actually a Cisco implementation of the 802.11d protocol... but wait, why do we need that stuff? You are already on the right channel anyway! Well, for 2 reasons:
. Your client is going to scan for other APs offering the same SSID. You do not want your client to scan channel 13 if there is no AP on that channel because this channel is not allowed in your country... and you do not want your client to send a probe request on that channel if using it is forbidden...
. Your client power level might be too high for the country, thus creating issues for the other clients around it... what issues? Well, if you client is too powerful, it is going to associate at high speeds in areas where it should not even be able to associate, thus creating interference and hidden nodes issues for the other clients...
So the 802.11d protocol allows you to send the regulatory domain information to you client, which is going to adapt to them. Cool isn't it? The 802.11d protocol was integrated into the 802.11-2007 standard, thus allowing the possibility to send this information, without stating exactly how it could be sent. In a Cisco network, this can be contained in the Vendor Specific fields of the beacons. So where is that feature in the Autonomous APs? In the radio (802.11b / 802.11a) configuration page.
And in the Unified solution? Nowhere... what? did they forget it? Naahh, can't believe that... read further....
-TPC, Transmit Power Control, is actually a feature of 802.11h... You know 802.11h? This protocol that prevents your APs working outdoor on the 5 Ghz spectrum from interfering with airport radars... this protocol has two sides:
. DFS, Dynamic Frequency Selection, that makes that if your AP hears a radar blast on its current frequency, it sends a "changing channel" 802.11h message and jumps to another channel.
. TPC, Transmit Power Control, by which 2 devices initiating a communication in the 5 Ghz spectrum will negotiate so that their respective power level is as low as possible, just loud enough to hear each other (so that your noisy 50 mW access point does not disturb the poor 60 WATTS radar sitting next door!!).
Where do you configure TPC? Well, you don't really configure it. It is part of 802.11h, and your 802.11a device has to be compliant with it, and implements it automatically.
-DTPC, that's Dynamic Transmit Power Control, looks close to TPC hey? But this is Cisco stuff, not 802.11 something anymore. With DTPC, your Cisco access point transmits to your Cisco CCX compliant client information about which power level to use... looks somehow close to World mode, don't you think?
Yes, it's close... but do you know what caused the death of World mode and why you don't find this feature in a controller? Think about it... what does it exactly do? If (yes, "if"), you enable it, your clients will receive a pack of allowed channels and power levels from your AP. This information format is proprietary, so your client needs to be a CCX guy to understand it. And what does it do with that information? You don't know... your client may use it, if it is also configured for World mode. It may understand it but not use it, if it is CCX but not configured for World mode, it may not be able to use it if its drivers is not per-set for this regulatory domain, or it may not even understand it if the client CCX version is too old or if the client is not CCX... Whoa, what a result... so let's think about another approach.
If your client is CCX, you can actually do more: influence it. very often, your AP has a good 9 dBi patch antenna and your client has a poor rubber duck 2.2 dBi antenna. Your client hears the AP well, but the client signal is lost in the surrounding noise and your AP does not hear it well. Your client should increase its power level, but it does not know that the AP does not hear it well... all it knows is that it (the client) hears the AP well, and from this received signal deduces its own power level. If you client is CCX, the AP can tell to your client "I don't hear you well, increase your power to 20 mW", or "hey no need to shout! reduce your power to 5 mW, that will save your battery". In this information, the AP can communicate maximums ("increase your power again, but don't go beyond 50 mW"). Isn't that better than World mode? That's what DTPC is about. You can enable it in your controller from the Main radio menu (Wireless > 802.11a > Network, in the General field).
But what about the channels? Well, there is also another CCX feature by which an AP can tell a CCX client "don't scan, you are in my cell in a comfort zone, stay quiet and save battery". Or "your signal strength is decreasing, you should start scanning", and there are a lot of variation from there, from "scan channels 1,6,11" or "check channel 6, Ap aa:bb:cc:dd:ee:ff should be there"... isn't that even better?
Yes, but what about the non-CCX clients? Well, they would not have understood the World mode messages anyway, this is why CCX is cool...
The document above about 802.11h DFS explained to you that when an AP hears a radar, it has to change channel. 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 (the AP has to make sure that the new channel is quiet)! To make the all process smoother, you can check the Channel Announcement box in "802.11h" menu under "802.11 a" in the "wireless" tab. 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.
This is also benefiting mesh APs. If the Root AP hears a radar and changes channel, not all Mesh APs will hear the radar so those might be disconnected. With this channel annoucenement they change channel along with the root.
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. It is the case for this feature. The controller can reduce the 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 AP is allowed to be. Keep in mind that - 3 dB is half the power, so every 3 dB allows the AP to reduce its power by half. A common value is 9 dB, allowing the AP 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).
Good one Nico
-Srini
thank you Nicolas for all the shared details
This is valuable information. I really need to change these settings in our hospital. I'm just starting to appreciate that we get maybe 30 radar DFS events across our site daily and we currently have Channel Announcement unticked, and SmartDFS on. D'oh!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: