Disclaimer

I am currently studying for my CWNA & CCNA Wireless, and intend this blog as a platform where I can learn and relay information back to the community. I, by no means, have the same level of expertise as some of the potential readers – wherever you spot a mistake please, let me know; it will help myself and hopefully others learn.

Subscribe!

Find Me On…

The Big DFS Debate – Real Life Findings

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:

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

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.

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.

4 thoughts on “The Big DFS Debate – Real Life Findings”

I really LOVE your empirical evidence logical reaction to this. Though you have some persuasive data, there is still the idea of many of your iOS devices might have taken a longer TIME to find the DFS AP’s… perhaps a follow up blog answering that aspect?

Great thought provoking write up. I am surprised there is not more of a difference but you’re right that regular scanning, even when stationary, will allow devices to eventually find DFS AP’s and move to them if they provide a better service. Any decent client operating in the channel-rich environment of 5GHz has to keep a cache of the AP’s around it. As you mention though, Roaming is where DFS channels can really hurt a device, particularly those with time sensitive data. But is 11k changing this? It would appear so.

I recently had a discussion on Wi-Fi design/survey with Peter Mackenzie and he was very keen on ensuring that APs were not deployed in such a way as the signal would ever drop sharply for a client. This blog post highlights the why of that nicely.