DFS channels and why to avoid them (even though you say you cannot)

DFS channels and why to avoid them (even though you say you cannot)


These days most wireless guys say they cannot stick to only 8 channels. Most people agree that you should use all 26 channels (including all the DFS channels). The truth is you can use an 8-channel plan if you use 20 MHz wide channels exclusively. I know …I know every marketing person, every manager and every user just lost their collective minds. Everyone wants to use 80 and 160 MHz wide channels and most people (even Wi-Fi people) want to use 40 MHz channels everywhere. If you use wide channels then you cannot stick to an 8-channel plan. On the other hand, if you agree that using 20 MHz channels is a more efficient use of the channels and spectrum, then you can very easily get away with using only 8 channels.


There are 9 non-DFS channels but when you use channel 165 (the highest channel in UNII-3) you may run into issues since there is not enough separation between Channel 165 and UNII-4 band channels. This has been known to cause issues, especially with voice clients. I always recommend staying away from channel 165 which leaves us with an 8-channel plan (36, 40, 44, 48, 149, 153, 157, and 161).


Back in the day when we used 2.4 GHz only networks, you were limited to only 3 channels, and despite this people more clever than, I got it to work with very few issues. Yes, there was always co-channel interference, but the better engineers would work to minimize it. In 5 GHz, suddenly using 8 channels is big a hassle for most people. Have we gotten lazy, or have we bought into the lie that wider channels are better? I will save my arguments for why 40MHz channels are highly inefficient for another blog. If you do not want to wait, you can look at Devin Akin’s blog at https://divdyn.com/wi-fi-throughput/  he does an amazing job diving into this point.


DFS Channels

What is a DFS channel? These channels share the spectrum with Weather Radar and Radar systems. For the FCC and IEEE to approve the use of these channels in WIFI, a mechanism had to be in place where these channels could co-exist. A mechanism called DFS (Dynamic Frequency Selection) was created to have the WIFI devices listen for radar events and either stop using the channels or automatically move off these channels. When RRM/ARM is used, and an AP hears a radar event it must pick a new channel and inform its clients to move to this new channel. If RRM/ARM is not used, then AP after hearing a radar event must stop transmitting for 30 minutes.






Why are DFS channels so bad?


There are 16 DFS channels in the UNII-2 and UNII-2e space (52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144). These channels have two major drawbacks, especially for voice clients. These drawbacks are 1.) The length of time it takes for a client to scan DFS channels. 2.) When radar events are heard the APs and device must move off that channel. The rest of this blog I will talk about these two issues.


The first issue is how long it takes a client to scan the DFS channels. This changes a bit with different clients but since I know the Vocera devices I will use them as an example. When the Vocera badge scans non-DFS channels, it immediately sends a probe request and gets back a probe response this takes roughly 15 – 20ms per channel. The device must return to its original channel for 50ms to do any TX/RX it may need. The total time to scan each channel is 65ms. When you multiply 65ms by 8 channels you get a total scan time of 520ms. When the badge scans a DFS channel it cannot send a probe right away. It must make sure there is no radar on this channel. It does this by listening for a beacon (100 – 104ms). The device will then send a Probe Request and receive a Probe Response only after it hears a beacon. Since it has stayed off its channel so long it needs to return to its original channel for 150ms for any Tx/Rx. The round trip time for every channel is roughly 250ms. When you multiply 250ms by 16 channels you get a total scan time of 4000ms (4 seconds). Four seconds may seem like a short time but, for a voice client that has a jitter buffer of 120ms, a 4-second delay can seem like a lifetime. When the device is in the middle of a call and needs to find another AP to roam to a delay beyond 120ms will cause choppy audio. It will take even longer if you hide the SSID since the badge must take an extra step of sending a Probe Request with the wildcard in it so all APs will respond.


This improves greatly when you have 802.11k enabled. When using 802.11k after the device connects to the AP it will request a Neighbor list. This neighbor list will (normally…if everything is working right) contain a list of APs that are its closest neighbors. This will cut down the number of channels the device has to scan. If the device happens to move away from all the APs in the neighbor list it will need to do a full scan.


The second issue with DFS channels is when a DFS event occurs (or even a false positive happens) the AP must send out a channel change announcement which tells the devices that it must move. Most clients will treat this as a new roaming event without the benefit of pre-scanning the channels before the move. They will have to rescan all the channels instead of just the one where the AP is moving to. If you are a laptop surfing the internet or reading email you may never notice the delay but if you are a voice client in the middle of a call you will experience choppy audio during the forced roam.



In conclusion, stick with 20 MHz channels and use only the 8 Non-DFS channels. By doing this you will avoid all the issues that come along with the DFS channels. If your devices or applications need to move massive amounts of data, either stick a cable in it or switch over to Wi-Fi 6e and you can have all the bonded channels you want. You will not have to worry about the fact you are running highly inefficient bonded channels until you start using 320 MHz bonded channels and Wi-Fi 6e will be down to 4 channels and this will restart the discussion all over bonded channels again.


Cisco’s Flexible Radio Assignment (FRA)


I have heard about Cisco FRA for a while but I am only starting to see this out in the field. This technology offers great advancements over statically assigned Radios.

There are two modes of operation in FRA Macro/Macro cell and Macro/Micro cell. I will only be discussing the Macro/Micro mode in this blog. The Macro/Micro cell will have a large cell and a smaller cell inside which will increase capacity on your 5 GHz network.

The theory behind FRA is if you design a network for 5 GHz then you will more than likely have too much 2.4 GHz coverage. This is why FRA is only run against the 2.4 GHz radios.

There are only two AP models that work with FRA. They are the 2800/3800. When the AP creates a Micro cell, the power will always be set to the minimum power of the AP. In the case of the 3802, this would be 2 dBm.


How it Works

FRA uses the Neighbor Discovery Protocol (NDP) from RRM to figure out if there is too much coverage on the 2.4 GHz band. The output of this calculation is called Coverage Overlap Factor (COF). You can set the threshold for the COF at Low 100%, Medium 95% and High 90%. When FRA sees too much coverage based on these thresholds values, it will mark the radio as redundant. Once it is marked redundant it can be assigned another role. There are three states (roles) these radios can be in 2.4GHz/5GHz/Monitor Mode. Depending on the COF the controller will either leave it at 2.4GHz, change it to 5 GHz or put it in Monitor Mode. When the controller puts an AP in Monitor mode the only way to fix this is to reset the AP.


Probe Suppression

The AP can suppress Probe responses from one of the radios. When the APs receives Probe requests on both the Macro and Micro cells within a short period of time from a client who is not associated, the AP can suppress the Probe Responses on the radio which it doesn’t want the device to join. When a client is associated to either radio on the AP, the AP will suppress the Probe Response from the other radio. This should help prevent the client from roaming between radios. The Probe Suppression option is disabled by default on the controller.


FRA will monitor the cells and keep devices that are similar on the same radio. This will help improve throughput. FRA will use 802.11v, 802.k and Probe Suppression to keep the same type of clients on the same radio.




Pros and Cons of FRA


      • FRA will give you more capacity in the 5 GHz band.
      • FRA eliminates of fixes the balance between 5 GHz and 2.4 GHz radios on your wireless network.
      • The controller will limit how many devices can be on the Micro cell.



  • If your device authenticates to the Micro Cell and moves away from the Micro cell area. This could force it to roam to the Macro cell, which would increase roaming. These additional roaming events force the device to stay awake more which will affect battery life. Cisco has safeguards against this but just like RRM, it doesn’t always work.
  • If you have 2.4 GHz clients your network, the coverage area after FRA runs could change dramatically. Depending on how often you have FRA run, this can lead to a less stable network. I know Devin Akin (@DevinAkin) would say that 2.4 GHz is dead and probably should be at this point especially for voice clients, but I just did a job last week where they insisted using 2.4 GHz for voice.