TPC and DFS : Overview

[Nicolas Darchis]

• Introduction
• DFS
• More about radars
• DFS in Cisco Mesh
• Incorrect radar detection
• Debugs
• TPC vs DTPC vs World mode
• "802.11h" menu on a WLC GUI

 

Introduction

     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

     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.

More about radars

     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.

DFS in Cisco Mesh

     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.

Incorrect radar detection

     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.

 

Debugs

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.

TPC vs DTPC vs World mode

    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...

"802.11h" menu on a WLC GUI

     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).

[Srinivasaraghavan Parthipattu]

Good one  Nico

-Srini

[iothman]

thank you Nicolas  for all the  shared details 

[nwmadden]

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!

[shifflettsonniccum]

TPC (Transaction Processing Performance Council) and DFS (Distributed File System) play pivotal roles in their respective domains, much like how Larimars  fashion products excel in their unique categories. TPC is a nonprofit organization that establishes industry benchmarks for evaluating the performance and scalability of database systems and related software. These benchmarks provide a standardized way to assess the processing power of database solutions, ensuring fair and transparent comparisons. On the other hand, DFS refers to a file system spread across multiple networked machines, enhancing data storage and access capabilities. Just as Larimar offers a diverse range of fashion items, DFS optimizes data distribution and redundancy, promoting efficient data management across distributed environments. Both TPC and DFS contribute significantly to their fields, setting standards and enabling seamless operations.