18 Wi-Fi Planning: Scenario Reviews and Failure Checks

18.14 Coverage and Capacity Are Different Goals

Planning a Wi-Fi deployment means balancing two goals that pull apart. Coverage asks “is there enough signal everywhere devices live?” — a common target is RSSI around −67 dBm for reliable real-time traffic. Capacity asks “can all the devices in one area actually get airtime?” A single high-power AP can cover a floor yet collapse under the load of hundreds of clients.

Good designs favour more APs at lower power on well-planned channels over a few loud APs. That shrinks each cell, raises reuse of the 1/6/11 and 5/6 GHz channels, and gives each client a stronger, faster link. IoT adds a twist: many sensors are cheap single-antenna radios that cannot use the fastest modes, so they occupy airtime disproportionately. Before treating coverage as sufficient, inspect Figure 18.1 to see the access point as a shared airtime scheduler serving different client workloads.

Read Figure 18.1 across client classes, traffic timing, and the shared access point, then compare their service requirements. The diagram connects capacity and contention evidence to placement decisions that a signal-strength map alone cannot justify.

Use the picture as a planning reminder. A mains-powered speaker may send larger audio bursts, a thermostat may wake rarely but need dependable room coverage, a sensor may spend most of its life asleep, and a wearable may roam at the edge of a cell. They can all show “connected” while still stressing the deployment in different ways. The plan therefore records the client mix, location, traffic pattern, and busy period for each group before it assigns APs or channels.

The useful design question is not “how far does this AP reach?” It is “which clients share this airtime pool, at what rates, during which windows, and with what service consequence if they retry?” If the answer is unknown, the deployment is still a hypothesis. Smaller cells, cleaner channel reuse, and scheduled telemetry usually beat stronger transmit power because they reduce contention instead of hiding it behind a larger signal footprint.

18.14.1 Overview Knowledge Check

Phoebe’s Field Notes: Why Gain Cannot Buy Coverage, Only Trade It

The mathematical gist. With 20 dBm transmit power, 3 dBi gain gives 23 dBm EIRP and an idealised 315 m free-space distance to the chapter’s −67 dBm target. Raising gain to 8 dBi gives 28 dBm EIRP and 559 m, a 1.78× range ratio. The same beamwidth approximation narrows a symmetric beam from about 144° to 81°: gain redirects power and trades angular coverage for range.

Math Bridge · guided foundationsWhy does antenna gain buy range by spending coverage angle?Let Eddie connect dBi, EIRP, beamwidth, path loss, and the −67 dBm target. Learn the maths

18.15 Spatial Streams, MU-MIMO, and Beamforming

Modern APs use multiple antennas to raise capacity in three related ways:

• Spatial streams (MIMO): multiple antennas send independent data streams at once over multipath, multiplying one client’s throughput (e.g. a 4-stream AP to a 2-stream client uses 2 streams).
• MU-MIMO: the AP forms beams to serve several clients simultaneously on the same channel, each on its own spatial stream — introduced downlink in 802.11ac and extended in ax.
• Beamforming: the AP sounds the channel, learns each client’s channel state, and shapes its antenna phases to focus energy toward that client — improving signal and rate without more power.

Those numbers grew generation by generation. 802.11n (Wi-Fi 4) introduced channel bonding to 40 MHz, up to 4 spatial streams, 64-QAM, and frame aggregation (A-MPDU/A-MSDU) to amortize per-frame overhead across a batch. 802.11ac (Wi-Fi 5) raised the ceiling to 160 MHz of bonded channel (two 80 MHz segments), up to 8 spatial streams, 256-QAM, and the downlink MU-MIMO named above. A fleet audit should use those numbers as a floor, not a guess: an AP advertising 8 streams and 256-QAM is making an 802.11ac-or-later claim, and any client built on 802.11n silicon caps out at 4 streams and 64-QAM no matter what the AP supports.

The IoT reality check: most sensors are single-stream devices. They cannot use multi-stream throughput, and their low rates make each transmission occupy more airtime. Beamforming still helps their link quality, but capacity planning must assume many slow single-stream clients, not a few fast laptops.

Worked example. An AP advertising 4 spatial streams shares a channel with 30 single-stream sensors and 3 laptops. MU-MIMO and multiple streams accelerate the laptops, but the sensors still transmit one slow stream each; if they all report on a schedule, their combined airtime, not the laptops’, sets the ceiling. The fix is OFDMA (pack the small sensor frames), band-steering laptops to 5/6 GHz, and staggering sensor reports — classic capacity engineering.

For deployment reviews, translate radio features into acceptance evidence. If the plan claims MU-MIMO capacity, confirm that the AP profile, client capabilities, and observed traffic actually use simultaneous downlink groups. If it claims beamforming margin, test the final mounting points and enclosures, not only open-air bench joins. If it claims OFDMA gains, validate the mix of small uplink frames and scheduling behavior during the period when sensors report together. Vendor feature checklists are not enough because an IoT fleet often contains old radios, single-stream modules, sleepy firmware, and support phones on the same SSID.

A practical evidence sheet should separate client capability from cell behavior. Client capability records band support, channel width, stream count, security method, roaming support, sleep state, and firmware release. Cell behavior records airtime, retries, association load, AP resource use, and the backhaul or service path. When those two records disagree, the lower one controls the deployment approval.

18.16 Fast Roaming with 802.11k/v/r

In a multi-AP design a moving client must hand off between APs, and a naive handoff is slow: the client scans every channel, re-authenticates, and re-runs the full key exchange — enough to drop a voice call or stall a moving robot. Three amendments fix this:

• 802.11k (neighbour reports): the AP tells the client which nearby APs and channels exist, so it can skip a full scan and target the right AP.
• 802.11v (BSS transition management): the network can steer a client toward a better AP (or off a congested one).
• 802.11r (fast BSS transition): keys are pre-derived and cached so re-association skips the full 802.1X/4-way handshake, cutting roam time to tens of milliseconds.

Worked example. An AGV crossing a warehouse roams every few seconds. Without 11k/v/r each handoff triggers a full scan plus a fresh WPA2 handshake — hundreds of milliseconds during which its control link stalls. With 11k the AGV already knows the next AP and channel, 11v steers it before the link gets weak, and 11r re-associates with cached keys in ~30 ms — short enough that the control loop never notices. Roaming quality, not raw coverage, is what makes mobile Wi-Fi IoT usable.

The hard part is compatibility. Some clients ignore 802.11v steering requests, some embedded stacks support 802.11k neighbour reports but not 802.11r, and some security profiles make fast transition unavailable. The deployment plan should therefore name the exact client firmware, identity method, AP profile, and roam policy being approved. A route test should record the starting BSSID, target BSSID, RSSI before roam, retry burst, service interruption, and recovery time so the approval is based on measured handoff behavior.

Roaming also interacts with capacity. If the network waits too long to steer a client, the client may cling to a weak AP and consume excessive airtime with low-rate retries. If the network steers too aggressively, the client can bounce between APs and create avoidable authentication and application pauses. The best deployment evidence combines RF survey points with live movement traces, because the route tells you whether the design works while the device is doing its real job.