36 Wi-Fi Access: Scanning and Deployment

36.1 Start With the Situation

This section: Start With the Situation — A link budget estimates whether a radio signal can reach each device.

A link budget estimates whether a radio signal can reach each device. That predicts coverage, the places where the link should work, but other networks and moving users may change it. Scan the real channels, the slices of radio spectrum devices share. Test airtime, the time they occupy those channels, and security. Record whether the site can still support the deployment.

36.2 Overview

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

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

This section: 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 ESP32 Wi-Fi Scanning Lab

This section: ESP32 Wi-Fi Scanning Lab — Once the scan gives local evidence, the case study shows how those same checks scale to thousands of devices.

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

36.5 Knowledge Check

This section: Knowledge Check

36.6 Illustrative Airport Wi-Fi 6 Case

This section: Illustrative Airport Wi-Fi 6 Case — The following hypothetical airport case is a worked planning scenario, not a report of a Denver International Airport deployment.

The following hypothetical airport case is a worked planning scenario, not a report of a Denver International Airport deployment. Its 4,200 devices, 340 access points, delays, battery results, and costs are illustrative assumptions to test with site evidence.

The Challenge: In this hypothetical case, an existing Wi-Fi 5 (802.11ac) network serves passengers and a growing IoT fleet: 1,800 environmental sensors (HVAC, air quality), 900 asset tracking tags (wheelchairs, carts), 800 digital signage displays, and 700 security cameras. Assume that during peak hours (6-9 AM, 4-7 PM), busy access points show 40% channel utilization and sensor data delays of 500 ms-2 s. Utilization alone does not prove the cause of delay; a real investigation would also inspect airtime, retries, queues, and application timing.

Why Wi-Fi 5 Failed for IoT:

Wi-Fi 6 Solution — OFDMA and TWT:

The scenario compares a proposed deployment of 340 Wi-Fi 6 access points with two configurations:

1. OFDMA for sensor data: A 20 MHz channel can be divided into nine 26-tone Resource Units (RUs), allowing up to nine scheduled transmissions in one OFDMA exchange when client and AP support it. Assume measured wait time falls from 450 ms to under 50 ms in this scenario; neither rate is a standard guarantee.

2. TWT for asset tracking tags: Assume 900 compatible tags negotiate wake periods every 30 seconds to transmit 12-byte updates. The model compares six months of battery life under an older power-save policy with 28 months under TWT. Actual power draw must be measured; Wi-Fi 5 clients can also sleep.

Illustrative Results (assumptions, not field measurements):

Key Insight: Sensors may need only kilobits per second, so OFDMA’s scheduled multi-device access and TWT’s coordinated sleep can matter more than peak PHY speed. These features can reduce contention and power use when supported and configured, but they do not eliminate queues or replace measurements in a mixed passenger and IoT network.

36.7 Match Wi-Fi Standards

This section: Match Wi-Fi Standards

36.8 Wi-Fi Deployment Sequence

This section: Wi-Fi Deployment Sequence

36.9 Wi-Fi Fit Record

This section: Wi-Fi Fit Record — Wi-Fi is not just a range or speed choice.

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.

Work through Figure 36.1 in its three numbered stages to see why a signal reading on its own cannot close a Wi-Fi decision.

+

Stage one names the service: device role, infrastructure owner, traffic envelope, power source, security boundary, provisioning path and review trigger. Nothing is measured yet. Stage two collects field evidence against three claims, and the split matters. Coverage proves the client can be heard. Capacity proves the channel has time to hear it. Operations proves the design survives updates and site changes. Stage three writes the decision, the limits and the retest trigger. The escalation rule at the foot of Figure 36.1 is the one to memorise. An acceptable average with high retries is a capacity or contention problem, so do not raise transmit power first.

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

36.10 Wi-Fi Capacity Record

This section: Wi-Fi Capacity Record — A useful Wi-Fi record turns radio assumptions into field checks.

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. In one Cisco WLAN design guide, 10–15% overlapping coverage is a starting point for general roaming, and 15–20% for voice; verify cell edges and interference with a site survey rather than applying one universal overlap range. Cisco guide 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.11 OFDMA and TWT Schedule Contention

This section: OFDMA and TWT Schedule Contention — Wi-Fi 6 improves dense IoT service by giving the access point better tools for scheduling.

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.12 Summary

This section: Summary — Wi-Fi provides high-bandwidth wireless connectivity for IoT, with recent standards specifically designed for IoT applications.

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

36.13 What’s Next?

This section: 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.

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.