Whether to use DFS channels or not is an increasing topic of debate, with a vocal few (yes, I mean you, Andrew McHale) choosing to recommend the banishment of these borrowed channels when you’re running time critical traffic over your network, such as Voice.

As a recap, DFS means Dynamic Frequency Selection, and to cut a long story short 802.11 borrows  5GHz channels which have a primary use elsewhere, mainly RADAR.
There are a few rules, I won’t go into it in detail, but the main ones are:

1. If an AP operates on a DFS channel and detects a DFS event, it isn’t welcome and must change channels. This isn’t great, but something we all have to cope with
2. A client cannot probe on a DFS channel unless it hears a beacon or probe response on that channel – this is very important in Andrew’s anti-DFS mantra.

In the UK, we have just 4 non-DFS channels, the US has more. Wikipedia may help: https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac/ax)

Using iOS as an example, it is widely understood that iOS devices only scan DFS channels in UNII-2e/Band B every 6 scans. Andrew goes into this in detail, but the point is that DFS channels are invisible to iOS devices on 5/6 scans, which got me thinking; does this mean only 1/6 iOS devices are using these channels? Logically, the answer would be yes. If you had 2 access points at a minimum of -67dBm, then 5/6 of the clients would end up on a non-DFS AP, but as with anything Wi-Fi… it’s not that straight forward.

At work, we are big iOS users – and big DFS users, every bit of frequency helps when you service 500k unique clients a month. So, I put this theory to the test, expecting to find a DFS shaped coverage hole.

I decided to export a list of all Apple iOS devices and their channels, and work out how many clients we see on each channel.

My first thought was to simply look at the ratio of Non-DFS to DFS clients:

I quickly realised that this was pointless, we have far more access points on Non-DFS channels so naturally they will attract more clients. I also realised that in some of our sites, due to size, we may not have any access points on DFS channels – so they were filtered out as I needed to ensure the client actually had a decision to make. Similarly, I also removed DFS only sites (of which there were 3 or 4, damn you RRM).
I decided it was probably worth looking at the average number of clients per AP on DFS vs Non-DFS, as this will remove any bias formed from the number of APs per channel, what I found was pretty surprising.

Theres barely any difference, certainly not enough difference to cause me to take any action. For clarity, we do not have 802.11k/v enabled to influence the results.

What does this tell me?

Well, the obvious answer is that iOS devices have no bias to DFS. One thing that is often overlooked which I cover in my blog Ping Really Does Pong is that devices periodically scan – even when not looking to roam. Whilst in the midst of a panic roam (where a device signal drops off a cliff and it has to find another AP to roam to quickly) it would take a while to pick up DFS, if your device roams naturally due to a gradual degradation of its favourite metrics (RSSI, MCS, SNR, whatever – see green diamond), it probably already has a good idea of the world around it.
No vendor documents roaming algorithms in detail, so this is just hypothesising, but if a device already knows the world around it, I would assume it doesn’t scan through the entire channel list at a natural roam point.

The other possibility is that our sites have coverage issues and clients are forced to DFS because they have a limited choice in non-DFS – we have nearly 2000 sites so it’s more than likely, and we don’t run voice so it’s probably not a big issue!

I don’t have all the answers, and I would be open to any other suggestions, but from the data I have on my own network, DFS channels aren’t causing any issue.

It’s a DF-Yes from this corner of the UK!