11 Wi-Fi Bands: Channels, DFS, and 6 GHz

11.5 Three Bands, Many Channels, Several Widths

Wi-Fi operates across three unlicensed bands, and each behaves differently for IoT. 2.4 GHz reaches farthest and penetrates walls best but is crowded and offers only three non-overlapping 20 MHz channels (1, 6, 11). 5 GHz has far more channels and less congestion but shorter range. 6 GHz (Wi-Fi 6E/7) adds ~1200 MHz of clean spectrum with the most wide-channel room, at the shortest range.

On top of the band sits channel width: Wi-Fi can use 20, 40, 80, or 160 MHz (and 320 MHz in 6 GHz with Wi-Fi 7) by bonding adjacent channels. Before choosing among them, inspect Figure 11.1 to connect peak throughput with reuse and interference exposure.

Read Figure 11.1 as evidence that a band decision is not a speed ranking. A 2.4 GHz plan may be the right answer for fixed sensors because the radios are common and the link reaches farther, but the limited channel set means adjacent cells must be planned carefully. A 5 GHz plan may be better for powered tools or cameras because it offers more reuse options, yet final mounting points and DFS recovery still need proof. A 6 GHz plan can give the cleanest spectrum only for clients and sites that actually support it.

Channel width is the second half of the decision. A narrow 20 MHz channel often gives a dense IoT site more predictable reuse than a wide channel that looks faster in a single-link test. Wide channels belong in the approval only when the traffic needs the throughput, the AP layout can still reuse spectrum, and the support team knows which device classes are excluded. The approval record should name the band, width, client group, AP profile, and retest trigger together.

11.6 The 5 GHz UNII Sub-Bands and Channel Count

The 5 GHz band is organised into UNII sub-bands, each with its own rules. Knowing them explains why an AP offers the channels it does:

Channel width consumes these channels fast. A 20 MHz plan yields many non-overlapping channels for reuse; an 80 MHz plan bonds four 20 MHz channels into one, so the same spectrum yields only a quarter as many independent channels. In a dense site that means far less reuse and more co-channel contention.

Worked example. An installer wants maximum per-link speed and sets every AP to 80 MHz — then finds only two or three non-DFS 80 MHz channels exist, so adjacent APs collide. Dropping to 40 MHz (or enabling vetted DFS channels) roughly doubles the independent-channel count, restoring reuse. The lesson: choose width for channel reuse in dense areas, and reserve 80/160 MHz for sparse, high-throughput links.

For IoT reviews, turn that trade-off into a channel evidence record. Start with the actual traffic class: low-rate sensors, cameras, support phones, gateways, and moving tools should not automatically share one width. Then record the channel list available under local rules, which channels the AP profile is allowed to use, which channels neighbouring APs already occupy, and whether a DFS event would interrupt service. The best width is the narrowest one that meets the service objective while leaving enough clean reuse for the installed cell pattern.

A useful field test has two views. The spectrum view shows neighbouring Wi-Fi, partial overlap, non-Wi-Fi interference, and channel changes over time. The service view shows association, retries, missing telemetry, video stalls, command latency, and update success for the client class. If the spectrum view looks clean but the service view fails, the record should keep investigating AP load, roaming, firmware, and backhaul instead of declaring the band solved.

11.7 DFS Mechanics and the 6 GHz Power Classes

The DFS-governed UNII-2 channels (52–144) are shared with radar, so an AP that wants them must obey a strict protocol: perform a channel-availability check (about 60 seconds of listening, longer on some weather-radar channels) before transmitting, then keep monitoring; on detecting a radar pattern it must stop transmitting on that channel within seconds and move. This unlocks many extra channels but risks a mid-service channel change.

The 6 GHz band manages coexistence differently, through power classes rather than DFS. Low-Power Indoor (LPI) devices may operate indoors at reduced power without coordination; Standard-Power outdoor devices must consult an Automated Frequency Coordination (AFC) service that tells them which channels are free of incumbent users at their location. This is why many 6 GHz IoT devices are indoor-only LPI.

Worked example. A campus wants dependable 5 GHz channels for outdoor cameras. UNII-2C offers many channels but they are DFS, so a passing weather radar could force a camera’s AP to vacate mid-stream. The planner reserves non-DFS UNII-1/UNII-3 channels for the cameras’ critical links and uses DFS channels for tolerant bulk traffic — a design driven directly by the band’s regulatory mechanics.

The hidden implementation detail is that a channel move is not just a radio event. Clients must hear the change, reassociate or follow the AP, refresh security state if needed, and rebuild the application path before the service timeout expires. That is why a DFS review should include recovery evidence, not only a list of allowed channels. For a moving tool or camera stream, record whether the application buffered through the move, whether telemetry was delayed or lost, and whether the support team can see the event in logs.

For 6 GHz, the equivalent review is compatibility and operating scope. LPI can be attractive indoors, but old clients, setup phones, gateways, and battery sensors may not support the band. Standard-power operation adds a location-aware coordination dependency. A bounded approval therefore names the client hardware, AP profile, indoor or outdoor scope, fallback SSID, and retest trigger for region, antenna, firmware, or mounting changes. Without those limits, a clean spectrum label can turn into an operations problem.