36 Wi-Fi Access: Scanning and Deployment

36.1 Start With the Situation

A link budget predicts coverage, but the site has competing networks and changing users. The team must scan the real channels, test airtime and security, and record whether the deployment remains supportable.

36.2 Overview

This route turns site scans, case evidence, and deployment checks into a Wi-Fi fit decision.

This is part 2 of 2. Review Wi-Fi Access: Standards and Link Budget when you need the first route.

36.3 Learning Objectives

By the end of this chapter, you will be able to:

• scan and interpret nearby Wi-Fi networks
• test capacity and security constraints
• record a supportable Wi-Fi deployment decision

36.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

36.5 ESP32 Wi-Fi Scanning Lab

Once the scan gives local evidence, the case study shows how those same checks scale to thousands of devices.

36.6 Knowledge Check

36.7 Wi-Fi 6 at Denver Airport

Denver International Airport (DEN) deployed Wi-Fi 6 in 2022 to support both passenger connectivity and 4,200 IoT devices across its terminal complex — making it one of the largest Wi-Fi 6 IoT deployments in a public venue.

The Challenge: The existing Wi-Fi 5 (802.11ac) network served passengers well but could not handle the growing IoT fleet: 1,800 environmental sensors (HVAC, air quality), 900 asset tracking tags (wheelchairs, carts), 800 digital signage displays, and 700 security cameras. During peak hours (6-9 AM, 4-7 PM), the access points experienced 40% channel utilization, causing sensor data delays of 500 ms-2s that triggered false HVAC alarms.

Why Wi-Fi 5 Failed for IoT:

Wi-Fi 6 Solution — OFDMA and TWT:

The airport deployed 340 Wi-Fi 6 access points (Cisco Catalyst 9136) with two critical configurations:

1. OFDMA for sensor data: Each 20 MHz channel was subdivided into 9 Resource Units (RUs), allowing 9 IoT devices to transmit simultaneously. This reduced per-device wait time from 450 ms to under 50 ms.

2. TWT for asset tracking tags: The 900 tracking tags negotiated TWT schedules — waking every 30 seconds to transmit a 12-byte location update, then sleeping. Battery life increased from 6 months (Wi-Fi 5, constant beacon listening) to 28 months (Wi-Fi 6 TWT).

Quantitative Results:

Key Insight: Wi-Fi 6’s value for IoT is not about higher speeds — the sensors only need kilobits per second. The transformative features are OFDMA (simultaneous multi-device access, eliminating queuing delays) and TWT (scheduled sleep, extending battery life). For any deployment mixing high-bandwidth clients (passengers, cameras) with low-bandwidth IoT devices (sensors, tags), Wi-Fi 6 eliminates the contention that made Wi-Fi 5 unreliable for IoT at scale.

36.8 Match Wi-Fi Standards

36.9 Wi-Fi Deployment Sequence

36.10 Wi-Fi Fit Record

Wi-Fi is not just a range or speed choice. It is a shared-airtime system where every access point, client, retry, management frame, and neighboring network competes for time on the channel.

An IoT design that says “use Wi-Fi” is incomplete until it explains how much airtime the devices need, how they authenticate, how they sleep, and how the access points will keep coverage and contention inside the deployment budget.

The design question is therefore not “does the signal reach the device?” A device can show acceptable RSSI and still lose useful service when the channel is busy, when the modulation rate falls, when hidden nodes trigger retries, or when neighboring networks reuse the same channel. Each retransmission spends more airtime before the application receives a single useful payload.

IoT makes this sharper because many devices send small messages, wake briefly, or reconnect after long sleeps. A temperature sensor, badge reader, camera, and commissioning laptop may all be “low bandwidth” in application terms, but each association, DHCP lease, TLS handshake, multicast burst, and acknowledgment still consumes channel time. The Wi-Fi decision must include the access point, channel width, band, security method, client power behavior, and backhaul path as one service contract.

A good fit record separates coverage, capacity, and operations evidence. Coverage proves the client can hear and be heard. Capacity proves the channel has enough airtime during busy periods. Operations evidence proves the design can survive firmware updates, credential rotation, AP replacement, and site changes without forcing a truck roll for every sleeping device.

Before wi-fi fit record, inspect Figure 36.1: Wi-Fi Fit must be considered with Evidence Record. That visual pairing grounds wi-fi fit evidence record linking device role, infrastructure, traffic, power, security, provisioning, operations, and next review areas in named evidence.

At Wi-Fi Fit in Figure 36.1, compare the diagram with Evidence Record; then locate Decision, limits, review. That labelled check bounds wi-fi fit evidence record linking device role, infrastructure, traffic, power, security, provisioning, operations, and next review areas. For wi-fi fit record, retain Decision, limits, review as evidence for the resulting choice.

Complete the record by naming the device role, infrastructure owner, traffic envelope, power source, security boundary, provisioning path, and operational review trigger.

36.11 Wi-Fi Capacity Record

A useful Wi-Fi record turns radio assumptions into field checks. It should show what each device sends, how often it wakes, which access point serves it, what minimum signal quality is acceptable, and what happens when the channel is busy.

Build the record from measured evidence, not vendor coverage claims. For each device class, record the band, channel width, SSID, authentication method, VLAN, expected packet size and cadence, peak burst behavior, firmware-update path, and battery sleep pattern. Then attach site evidence: AP placement, survey readings at installed height, noise floor, channel utilization, retry percentage, client MCS rates, roaming results, and backhaul utilization during the busiest period you can reproduce.

AP placement follows a few practical rules of thumb, not just a coverage heat map. Keeping one SSID across every AP in a coverage area lets client radios roam to the strongest AP on their own, instead of a person choosing between differently named networks by hand. Two APs assigned the same channel should sit as far apart as the site allows, because co-channel APs compete for the same airtime instead of adding capacity. Overlapping AP cells by roughly 15-25% avoids both extremes: too little overlap leaves dead zones between APs, and too much wastes channels on redundant coverage. Assigning channels across a dense AP layout is really a graph-coloring problem — treat each AP as a node, connect APs that can hear each other, and assign the fewest channels (“colors”) so no two connected APs share one — which is part of why the same three 2.4 GHz channels (1, 6, 11) keep reappearing in this chapter’s examples even as AP count grows.

The record should also document what the design will not support. A 2.4 GHz-only sensor may be acceptable for low-rate telemetry, but it competes with legacy clients and neighboring networks. A high-resolution camera may need 5 GHz or 6 GHz capacity, but it may lose range faster through walls. A battery device may support long sleep intervals, but failed joins, certificate renewal, or captive provisioning can dominate energy use if the network path is unreliable.

The fit record turns selection into operations: it says what to measure after installation, not just what standard to buy.

36.12 OFDMA and TWT Schedule Contention

Wi-Fi 6 improves dense IoT service by giving the access point better tools for scheduling. OFDMA divides a channel into resource units so multiple clients can send in a coordinated transmission window. Target Wake Time lets clients agree on sleep and wake schedules instead of listening constantly.

Those tools do not remove the shared medium. Beacons, probe traffic, acknowledgments, retransmissions, hidden nodes, low modulation rates, and neighboring networks still consume airtime. A slow or distant device can reduce usable capacity because each frame takes longer to deliver.

Classic Wi-Fi access is contention-based. A station listens before transmitting, waits through interframe spacing, chooses a random backoff when the medium is busy, and expects an acknowledgment for unicast frames. If the acknowledgment is missed, the frame is retried at additional airtime cost. This is why retry rate and airtime utilization often explain user-visible stalls better than headline PHY rate.

OFDMA changes the scheduling granularity, not the need for planning. In Wi-Fi 6, the access point can divide a channel into resource units and coordinate multiple clients during a transmission opportunity, including trigger-based uplink traffic when clients and the AP support it. That helps dense small-packet workloads, but it depends on compatible clients, firmware behavior, AP scheduler policy, channel conditions, and whether the traffic arrives in patterns the scheduler can combine.

Target Wake Time is also a contract. The AP and client agree when the client can wake for service, so the device spends less energy listening between events. It works best when sensor deadlines, AP buffering, beacon/DTIM behavior, IP lease timing, and security renewal all fit the wake plan. If a device wakes outside its agreed window, roams unexpectedly, or must reauthenticate after sleep, the power saving can disappear into repeated join and retry work.

36.13 Summary

Wi-Fi provides high-bandwidth wireless connectivity for IoT, with recent standards specifically designed for IoT applications.

36.14 What’s Next?

Continue to Low-Power Networks: 802.15.4, LPWAN, and Cellular to explore IEEE 802.15.4 (Zigbee, Thread), LPWAN technologies (LoRaWAN, Sigfox, NB-IoT), and cellular IoT from 2G to 5G.