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.