Why I dislike DFS channels, and you might too

As many of you know, I’m a voice guy. And in voice every millisecond counts. That is the main reason why I dislike DFS channels, because they introduce significant delay, which is lost time. But how bad can the lost time really be? And why do you care if you’re not running voice? Well folks, flick the lights on, pull the cover close and read on… it gets scary (yes, scarier than Ghost Frames™).

In the 5GHz spectrum some of the channels used by 802.11 are subject to Dynamic Frequency Selection (DFS) requirements. This is due to our clients coexistence with other RF technologies such as Maritime, Aviation and Weather RADAR. This post is not going to cover what DFS is, but focuses on how it impacts 802.11 clients.

Note: These channels tend to be referred to as “DFS channels” by the industry and I will refer to them this way forthwith from now on.

A lot of WLAN engineers have accepted and adopted DFS channels as part of their standard channel planning process. After all, the more non-overlapping channels you can use the lower your co-channel contention (CCI) will be. But there are drawbacks to these DFS channels that are rarely discussed.

So what are the rules? Over to you IEEE…

Ahem, you get that? Nope? Let me translate.

Simply put, this means a client device must wait to hear a Beacon or a Probe Response from an Access Point on any ‘DFS channel’ it wants to send traffic on (including Probing) before it can do so. Just hearing traffic from any device (e.g. another client) is not acceptable, it must be a Beacon or Probe Response which only AP’s transmit in an infrastructure WLAN.

So what does this mean in real life?

Slooooow roaming (Imagine internet meme’s of kittens crying!)

To understand the full scale of this let’s look at how a client behaves on a “normal” (i.e. non-DFS) channel.

When a client wants to look for any suitable AP’s to join it just has to wait for its Carrier Sensing to report the frequency is free before it can send out a Probe Request. Any AP’s that can support the client then reply with Probe Responses. We call this Active Scanning because the client is actively requesting responses from the infrastructure.

When the client needs to Probe channels other than the one it is currently associated to this process can interrupt the clients transmission’s.

Here is a screenshot of an iPhone 7 scanning on my lab setup using just channels 40 and 48, both of which are non-DFS channels in the UK. As I always like to do I have included the filter used to show this data in case you want to replicate it with your own captures.

Let’s walk through what is happening here. I’ve set the Time Reference point of zero to that first Probe Request on Channel 40. That means that the second column (Time) shows milliseconds since that first line containing *REF*.

1. The iPhone wants to roam. It is currently associated on channel 40.
2. It starts by sending a Probe Request on channel 40. Almost instantaneously (less than 1ms) the current Access Point sends a Probe Response.
3. The iPhone then takes the opportunity to send a data frame because it is in a voice conversation with time sensitive data.
4. The iPhone waits 10ms for all responses to come back then sends another probe on channel 40. Clients normally probe twice per channel for redundancy. After all, probes are not Acknowledged so the client does not know if its probe had a collision.
   All this (2x Probe Requests, 2 x Probe Responses, 1x Data frame) took just 20ms because on a non-DFS channel the iPhones gain immediate access to the medium and waits 10ms per probe for responses.
5. Now the iPhone wants to probe channel 48 but it is currently associated to channel 40. So the iPhone tells the AP it is going to sleep, so the AP will buffer any data for it while the phone is ‘off channel’.
   
6. Once on channel 48 the iPhone waits 10ms before sending its first probe. I’m guessing this is it listening for any Beacons it might hear as that could save it the trouble of having to Probe. We call this type of scanning ‘Passive’, because the client is sitting there passively listening to what is going on.
   
7. After that 10ms wait the iPhone sends a Probe Request and again you see the AP on that channel Respond instantaneously. The iPhone waits the same 10ms for any more Probe Responses to come back before sending its 2nd Request out. 10ms more of “Dwelling” for Responses to come back and then back it goes to channel 40 and announces it is now awake (aka ready for data).
   

This whole process of robustly scanning 2 non-DFS channels AND sending some data takes no more than 55ms. This breaks down to 20ms for the currently associated channel and 35ms for other non-DFS channels. So, if you had your network configured for all 9 non-DFS channels supported in the US and many other regions, the client could scan the whole channel plan in (1 x 20ms) + (8 x 35ms) = 300ms.

Now, let’s look at the process for DFS channels. Here is a reminder of the rules:

A client must wait to hear a Beacon or Probe Response from an Access Point on any 'DFS channel' it wants to send traffic on, before it may do so.

How often do Beacons get sent in a WLAN?

102.4ms
(unless some cowboy “engineer” has messed with something they don’t understand).

So what do you think would be a safe dwell period on a DFS channel to ensure robust scanning and to avoid abandoning the channel because the client missed hearing the required Beacon? Probably around 105ms, because Beacons can be delayed due to channel congestion too remember.

I want people to be clear what this means so let me spell this out for you:

A client is likely to dwell (i.e do nothing) for 105ms before it starts to Probe.

We have seen that iPhones take 20 – 35ms to Probe and Dwell for Responses. In fact, here is an extract from the same capture file as above filtered to just show when the iPhone goes to sleep (off-channel scanning) and then wakes up again. It shows a run of sequential off-channel scanning with a very consistent 125ms of lost transmission opportunity. The iPhone 7 then goes back ‘on channel’ for ~45ms of normal Tx/Rx.

WOW. That is 125ms per DFS channel. An iPhone can scan 4 non-DFS (yay!) channels in that time. And this is typical of most clients, not just iPhones.

If you add in the normal Tx/Rx time it takes to ensure the smoothest experience possible it is 170ms scan “cycle” per DFS channel. If you have 15 DFS channels in your channel plan and the client has to scan them all that is 2.5 seconds of just scanning, before the client can even make a decision about where it is going to attempt to roam to and begin the reassociation process (which can take hundreds of milliseconds more). How far can a mobile user move away from your AP’s in that time, and what is that doing to the signal strength of the Tx/Rx interludes it is trying to maintain between scanning?

Ok. That’s a pretty grim picture, right? Well scan time is just one of the negatives of DFS channels. Let me throw some more fuel onto that fire for you!

• The most common argument I hear for using DFS channels is capacity. The more channels you use the more capacity you have by lowering average throughput per channel. But did you know that Apple iOS devices are programmed to only scan UNII-2 Extended channels every 6th cycle?! That means any AP’s operating on UNII-2e channels are INVISIBLE to iPhones and iPads FIVE TIMES OUT OF SIX.

Sure you design so that any AP using a DFS channel is bordered by a non-DFS channel AP, but you are significantly reducing your coverage for 5 out of 6 scans. What do you think that will do for your Capacity? Where do you think most clients will bunch? On the non-DFS AP’s!

Yes, you can turn on 11k, but 11k is not perfect. It is the access points view of nearby AP’s, so it could have your client scanning for channels on the opposite side of the cell and direction of travel. Plus a lot of clients still don’t support 11k.

• I talked about this in my presentation “Why are Clients sticky” at WLPC Prague which you can review here, but basically clients are almost always battery powered and they want to sleep A LOT to conserve that power. If they are scanning they are not sleeping. So all that extended scanning time required for DFS channels not only slows down roams but consumes a LOT more power too.

• Not all clients support DFS channels. This post has clearly shown that DFS channels are a lot more complicated. All these rules and regulations, and changing/optimising of scanning has to be programmed by someone. Often this complication just isn’t wanted or needed by the client manufacturer. So they just don’t bother supporting DFS channels.

• Oh, and in all this doom and gloom I forgot to mention actual RADAR! If you are in an area prone to RADAR then your radios using DFS channels can be jumping around as they detects pulses, blocking out entire DFS channels for 30+ minutes (depending on regulations), and screwing up the channel plan you Ekahau expertly crafted. Even if you’re not in an area susceptible to RADAR what I hear is that many manufacturers detection algorithms suffer regular False Positive readings, causing this effect even without RADAR being present.

• [Correction] The channel quietening (revalidation) requirement I mention below does not apply to Radio LAN (RLAN) devices which are covered by ETSI standard EN 301 893. It turns out it was something I read about in the Broadband transmitters standard EN 302 502. Another little DFS “feature” for you is that AP’s have to quieten DFS channels periodically to scan for RADAR. ETSI specify that this must happen at least once every 24hrs and for a minimum of 60s. During these periods no one can transmit on that channel in that area. Every radio using a DFS channel goes dark once a day and evicts or silences associated clients. Good luck troubleshooting the intermittent coverage or delay issues your users report because of this.

Obviously there are times when we need to use a large channel plan. Typically Very High Density (VHD) or Multi-Tenant Building (MTB) deployments. But the use case in these environments isn’t normally a mobile one. The fans/residents are wanting a good connection in one place (their seats/sofas) and aren’t too worried when they’re on the move (although this is rapidly changing for stadium deployments with people streaming sport or making VoIP/Video calls).

When I see people using channel plans with 21+ channels in mobile or VoIP intensive verticals it reminds me of greedy little children eating all of the chocolate on Christmas morning, and suffering later when they feel sick (FYI – this is me every year!). I clearly remember the days when I had just 3 channels available to me and I had to tweak everything possible to keep Duty Cycles below 40%. So I consider us lucky that we can use 8 non-DFS channels (in the US) and keep our Duty Cycle well below that today.

Yes, your WLAN could be even more efficient if you used more channels, but at what cost to the quality of the connection and the roams, and the risk of phantom issues later? This is why I dislike DFS channels.