Optimizing WiFi Channels in a Mixed Environment

Sometimes you find that a user’s “Brand X” device doesn’t

work reliably, or even at all, with your shiny new enterprise-grade, dual-band WiFi. Troubleshooting these kinds of issues can be a challenge, but the process always starts with “make sure the user’s device has the most current WiFi adapter drivers”. So, you’ve done that, and they’re still having problems. What next?

You’ve done your research and are eager to move to a new dual-band 802.11ac WiFi systems because the 5 GHz band gives you a lot more channels. Even better? You and your clients can move away from the congested 2.4 GHz band which has only three non-overlapping channels (1, 6, and 11), and which must compete with RF noise from wireless cameras, baby monitors, and microwave ovens. With more channels comes the added ability to bond channels together to double or even quadruple the data rate between the user device and the Access Point.

But not all WiFi devices can use all the 5 GHz channels, and FCC regulations occasionally add new channels or restrict existing ones, so designing WiFi equipment is a bit of a moving target! Sometimes this can be remedied by a driver or firmware upgrade. But sometimes it is simply a
limitation of the hardware.

The band we think of as “5 GHz” is actually 3 (well, 4) bands. Channels 36 through 48 are in the U-NII-1 band (U-NII stands for Unlicensed National Information Infrastructure in case you’re curious). Channels 52 through 140 are in the U-NII-2 band, and channels 149 through 165
are in the U-NII-3 band.

But the U-NII-2 band has a problem: it interferes with military and weather radar. The solution adopted by the WiFi industry was DFS (Dynamic Frequency Selection). A WiFi AP that wants to use a particular channel in this band must first listen for radar in its environment. If radar is detected, the AP must back off and select a different channel.

Some manufacturers of WiFi client equipment choose to interpret DFS as meaning those channels are “optional” and therefore they do not build support for them into their devices. The TV in one of our conference rooms has a built-in ROKU streaming device. If the AP nearby happens to choose to operate on one of the U-NII-2 channels, the ROKU can’t see the AP, because the ROKU hardware does not support U-NII-2 channels. The ROKU might see an AP
farther away, at a weaker signal level, if that AP has selected a non-DFS
channel.

Fortunately, the solution to this problem is straightforward. Just re-configure your AP so that channels 52 through 140 are not available for the APs to use. Of course, this eliminates a large range of useable channels and limits the number of “wide” channels we can create, but
sometimes when supporting a user environment consisting of an unpredictable mix
of legacy equipment, compromise is the name of the game.