Wi-Fi can be crippled by too many devices competing for airtime, creating a slower experience for all users.
One way to reduce the number of devices competing for airtime is to increase the number of channels in use.
How do the Dynamic Frequency Selection (DFS) Channels fit into this picture?
Some of the 5GHz channels can interfere with radar, so Wi-Fi networks have the capability to remove these channels from service dynamically - hence the term Dynamic Frequency Selection (DFS).
These extra channels can be used as part of the 5GHz channel plan, and more channel diversity results in less contention, meaning more available throughput for each end user.
Improper use of DFS channels can cause unexpected dropouts, however when implemented correctly, can more than double the number of channels available.
There are eight 5GHz Wi-Fi channels that are relatively unrestricted for their use indoors, this means that once your deployment extends beyond eight access points, you need to re-use channels, which leads to an increase in the number of devices competing for airtime on a given channel.
This number decreases quickly if you use channel bonding to create 40MHz (four) or 80MHz (two) channels.
- Cisco RX-SOP: Turn down the noise
- Wi-Fi Predictive Designs
- Wi-Fi Design Technical Requirements
- Wi-Fi Design Business Requirements
What's the Problem with Channel Utilisation?
The one thing you can't adjust in Wi-Fi is how much airtime (channel utilisation) is available.
Unfortunately, you are at the mercy of the universe's laws of physics.
Generally, depending on the application, you want to keep the airtime utilisation below 30-40%, however once you get up around 70%, the Wi-Fi will become unusable.
While you can't create more airtime on a given channel, you can reduce the number of devices competing for airtime by diversifying the channels used by your wireless access points.
All access points on one channel means every device is competing with every other device for airtime. Each AP on its own channel means each device is competing only with other devices associated to the same AP.
What's the Solution to Reducing Channel Utilisation?
Unfortunately, DFS Channels are not recommended where VoIP over Wi-Fi is critical.
Client devices require extra time to scan for APs on DFS channels, which can result in dropped packets during a voice call; but if VoIP over Wi-Fi is not a critical service, utilising DFS channels can add an extra twelve channels to an Australian indoor WLAN!
When a radar event is detected by an access point, if the AP's transmission would cause interference with the radar signal, the AP will immediately change channels, often without notifying any client devices, causing unexpected dropouts. At this point, you're probably thinking "That sounds like a nightmare!"
Hang in there, the payoff is coming: Any radar devices in the vicinity of your WLAN will use a consistent part of the spectrum, and may knock out one or two Wi-Fi channels.
That's it! If you can properly plan around nearby radar interferers, you may end up with ten or eleven of those twelve extra channels available to you to increase your channel diversity, increasing your available airtime, increasing the available data throughput per client device. How do you plan around nearby radar interferers? The simplest answer is: you don't - at least not initially, anyway.
Enabling all DFS channels will increase your channel count to 20 and possibly enable some channels that overlap with a nearby radar device and so are unusable. Cisco's Prime Infrastructure can be configured to alert you any time a DFS event occurs. Getting DFS events that are kicking APs off channel 112? Disable channel 112. It's as simple as that. If you get lucky you may experience no DFS events at all leaving you with all channels to play with.
Dynamic Frequency Selection: Summary
Don't be afraid to use DFS channels in your WLAN!
By ignoring them you're ignoring over half of the potential channels that you have available. If we can assist you with implementing these channels and configuring the event logging to reduce your risk of unexpected dropouts, drop us a line at email@example.com