Wi-Fi Deployment Reference - Channel Planning, AP Density, RRM | 802.11 Protocol Library

Channel Planning

Channel planning is the single most impactful decision in any Wi-Fi deployment. Get it wrong and no amount of AP placement, power adjustment, or firmware tuning will fix co-channel interference. The goal is maximum separation - adjacent APs on different channels, co-channel APs separated by enough distance that they cannot hear each other above the noise floor.

2.4 GHz - 3 non-overlapping channels

Only channels 1, 6, and 11 are non-overlapping in 2.4 GHz (in the US). Use only these three. Never use channels 2-5 or 7-10 - they overlap with adjacent channels and create interference without providing additional spectrum. 40 MHz bonding in 2.4 GHz is almost never appropriate - it consumes all usable 2.4 GHz spectrum for one AP.

Channel	Centre freq	Overlaps with	Use?
1	2412 MHz	2–5	✓ Non-overlapping
6	2437 MHz	2–10	✓ Non-overlapping
11	2462 MHz	7–11	✓ Non-overlapping
2-5, 7-10	Various	Multiple channels	✗ Never use

5 GHz - non-overlapping channels (US)

5 GHz has far more usable spectrum. Non-DFS channels (UNII-1 and UNII-3) are preferred for client devices. DFS channels (UNII-2A and UNII-2C) require 60-second CAC before use and may be cleared by radar detection. 80 MHz is the practical deployment width - 160 MHz creates only 2 non-overlapping channels in 5 GHz.

Band	Channels	DFS required?	20 MHz channels	Notes
UNII-1	36, 40, 44, 48	No	4	Indoor only in most regions. Preferred for high-density.
UNII-2A	52, 56, 60, 64	Yes	4	60s CAC. Radar detection can clear channel mid-operation.
UNII-2C	100–144	Yes	12	Most channels. Outdoor-capable. Same DFS caveat.
UNII-3	149, 153, 157, 161, 165	No	5	No DFS. Outdoor-capable. High power allowed.

6 GHz - Wi-Fi 6E / Wi-Fi 7 (US)

The 6 GHz band (5.925–7.125 GHz) provides 1200 MHz of new spectrum - 59 non-overlapping 20 MHz channels, 29 × 40 MHz, 14 × 80 MHz, or 7 × 160 MHz. No DFS. No legacy devices. Clean band - the biggest deployment advantage. Wi-Fi 7 adds 320 MHz (2 non-overlapping in 6 GHz). Requires Wi-Fi 6E or Wi-Fi 7 hardware on both AP and client.

Channel width	Non-overlapping channels	DFS?	Best for
20 MHz	59	No	Dense IoT, legacy compatibility mode
40 MHz	29	No	Mixed client environments
80 MHz	14	No	Standard enterprise - best balance
160 MHz	7	No	Low-density, high-throughput applications
320 MHz	2 (Wi-Fi 7 only)	No	Point-to-point or very low density

Field note: The most common 5 GHz deployment mistake I see is using 80 MHz channels in high-density environments with many APs. At 80 MHz you have only 6 non-overlapping channels in UNII-1+3 (no DFS). With 20 APs per floor, co-channel interference is guaranteed. Drop to 40 MHz or 20 MHz in high-density deployments - you lose peak throughput but gain capacity. The PCAP tells you when this is the problem: FCS errors with good RSSI = co-channel interference, not coverage.

AP Density and Coverage

AP placement is a coverage problem, not a distance problem. The question is not "how far can the signal reach?" but "at what RSSI does the client need to be for the application to work?" Design to the minimum RSSI for your worst client device and highest-priority application.

RSSI targets by application

Application	Minimum RSSI	Minimum SNR	Why
Data / web browsing	-70 dBm	20 dB	Low MCS acceptable. High retry tolerance.
Video streaming (1080p)	-67 dBm	23 dB	Needs sustained MCS 4+. Buffer hides brief drops.
VoIP / Zoom / Teams audio	-67 dBm	25 dB	Jitter-sensitive. Packet loss >2% = audible.
VoWiFi (Wi-Fi calling)	-65 dBm	25 dB	Handover timing critical. Roam latency <50ms needed.
Real-time video (telepresence)	-65 dBm	28 dB	Highest demand. Jitter and loss both critical.
IoT / sensor data	-75 dBm	15 dB	Low data rate. High retry tolerance. Battery-limited.

AP density guidelines by environment

Environment	Users/AP	AP spacing	Primary concern
Open office (data)	20–30	15–20m	Coverage. Capacity secondary.
Open office (VoIP)	10–15	12–15m	Roam latency. -65 dBm floor.
Classroom / lecture hall	30–40 devices	One AP per room	OFDMA efficiency. Band steering.
High-density (conference)	50–100 per AP	Per-row or per-table APs	Capacity. Directional antennas. Low power.
Warehouse / industrial	5–10 (handheld)	30–50m (open)	Coverage. Forklift mounted scanners need fast roam.
Healthcare	5–8 (critical devices)	10–15m	Roaming reliability. No gaps. Redundancy.

Co-channel separation - the key design rule

Two APs on the same channel should not be able to hear each other above -82 dBm (the CCA threshold). If they can, they will defer to each other - halving effective throughput. Design so that co-channel APs are separated by enough distance or attenuation that neither hears the other above the CCA threshold. This is the "Don't Want" zone from Keith Parsons' design framework - same-channel AP frames below the Want threshold but above the Don't Care threshold are the most damaging interference.

Field note: The most expensive deployment mistake I see is too many APs deployed for coverage with no regard for co-channel interference. A floor with 20 APs all using the same 3 channels (2.4 GHz) creates catastrophic CCI. The PCAP signature: FCS errors despite -55 dBm RSSI, retry rate above 20%, throughput far below what RSSI should support. The fix is almost always reducing AP count, reducing TX power, and ensuring proper channel reuse distance - not adding more APs.

Roaming Design

Good AP placement is the foundation of good roaming. Clients roam because they need to - their current AP signal has degraded below the point where it can sustain the application. Design so that a client always has a -67 dBm or better candidate within range before their current AP drops below -72 dBm.

Roaming design checklist

Design element	Target	PCAP validation
Overlap between adjacent APs	-67 dBm overlap zone 15–20% of cell	Client should see candidate AP at -67 dBm before current AP drops to -72 dBm
802.11k neighbor list accuracy	3–6 candidates, all on correct channels	Neighbor Report Response IE list - channels must match actual AP channels
802.11v BTM enabled	Disassociation Imminent = on	BTM Request with DI bit set. Client Response status=0.
802.11r FT enabled	AKM type 3 or 4 in beacons	FT Auth frames visible. No EAPOL M1-M4 after Reassoc.
Same Mobility Domain across all APs	MDE IE consistent	MDE IE (id=54) MDID field identical across all BSSID beacons
Roam latency target (VoIP)	<50ms total	Timestamp delta: last data frame on old AP → first data frame on new AP

Common roaming design failures

Failure	Symptom	Root cause	Fix
Coverage gaps between APs	Client drops connection mid-roam, re-associates from scratch	No -67 dBm overlap between cells	Add AP or increase TX power in gap area
Empty neighbor list	Client scans blind, 300-500ms roam latency	RF group misconfigured, APs not sharing neighbor data	Verify controller RF group membership
Mixed Mobility Domains	FT status 53 on some APs, not others	APs upgraded in phases, different MDID values	Ensure all APs use same MDID
Sticky clients	Client at -80 dBm, not roaming	No BTM or BTM with DI=0, no minimum RSSI policy	Enable BTM with Disassociation Imminent
DHCP delay on roam	Roam completes fast but connectivity resumes slowly	Client requesting new DHCP lease instead of reusing	Reduce DHCP lease time or enable DHCP proxy on controller

Field note: The DHCP delay is the most underdiagnosed roaming problem. 802.11r completes in 20ms. The client is on the new AP. But the user sees a 2-3 second reconnection. The PCAP shows: FT Reassoc complete at T=0, then 2.5 seconds of silence, then DHCP Discover at T=2.5s. The Wi-Fi roam was perfect - the client needlessly requested a new IP. Fix: enable DHCP proxy on the controller so the client gets its existing IP immediately on reassociation, or reduce DHCP lease to force reuse detection.

RRM - Radio Resource Management

RRM is the automated system that adjusts channel and power assignments across APs in response to RF environment changes. Done well, it reduces co-channel interference and adapts to new sources of interference. Done poorly, it creates instability - APs changing channels every few minutes, disrupting clients mid-session.

What RRM controls

Parameter	RRM adjustment	PCAP signature	Risk if misconfigured
TX Power	Reduces power when neighbours are too close. Increases when coverage gap detected.	TPC Report action frames. Power Constraint IE (id=32) value changes in beacons.	Cell too small = coverage gaps. Cell too large = CCI.
Channel assignment	Moves AP to less congested channel when CCI detected above threshold.	CSA IE (id=37) in beacons before switch. Channel switch visible in radiotap after.	Frequent channel changes disrupt roaming. Neighbour lists go stale.
Channel width	Some systems reduce from 80→40 MHz under load to free spectrum for neighbours.	HT/VHT Operation IE channel width field changes in beacons.	Unexpected width reduction reduces throughput.

RRM stability settings - what to configure

Setting	Recommended value	Why
Channel change threshold	20-25 dB CCI before triggering	Prevents channel bouncing from transient interference
RRM scan interval	5–10 minutes minimum between changes	Frequent changes disrupt roaming and neighbor lists
TX power minimum	8–11 dBm floor	Prevents cell shrinkage that creates coverage gaps
TX power maximum	17–20 dBm ceiling	Prevents over-powering that causes CCI
DFS channels in RRM pool	Include with caution	Radar hit triggers immediate channel change - verify client roaming handles the transition

Field note: RRM channel changes are the most disruptive events in an enterprise Wi-Fi network. When an AP changes channel, every associated client loses connectivity until it discovers the new channel. With 802.11h CSA, the AP announces the change 10 DTIM intervals in advance - clients should roam before the switch. In practice, many clients wait and experience a brief disconnect. In a PCAP: CSA IE appears in beacons with a countdown, then all clients show a brief gap in traffic, then reassociate on the new channel. The countdown-to-switch duration is configurable - increase it in high-stakes environments (hospitals, warehouses with scanners).

Capacity Estimation

Coverage determines where clients can connect. Capacity determines how many can connect simultaneously and at what throughput. These are different problems - a building with perfect coverage can still be capacity-limited. Capacity planning requires knowing your client device mix, application bandwidth requirements, and the impact of overhead on usable throughput.

Throughput reality - what you actually get vs theoretical max

Standard	Theoretical max	Realistic single client	Multi-client efficiency
802.11n (Wi-Fi 4)	600 Mbps	150–200 Mbps	~50% with 4 clients
802.11ac (Wi-Fi 5)	6.93 Gbps	400–600 Mbps	~60% with MU-MIMO
802.11ax (Wi-Fi 6)	9.6 Gbps	600–900 Mbps	~80% with OFDMA
802.11be (Wi-Fi 7)	46 Gbps	2–4 Gbps (MLO)	~85% with MLO+OFDMA

Overhead that reduces usable capacity

Overhead source	Typical impact	PCAP identification	Mitigation
Management frame overhead	5–15% of airtime	wlan.fc.type == 0	Reduce beacon interval. Reduce SSID count. Enable probe suppression.
Legacy client protection (802.11b/g)	20–40% throughput reduction	CTS-to-self frames: wlan.fc.type_subtype == 0x1c	Disable 802.11b rates. Set minimum rate to 12 or 24 Mbps.
High retry rate	Direct throughput reduction	wlan.fc.retry == 1	Fix RF - retries are a symptom of CCI or coverage gaps, not a cause.
Multicast/broadcast storms	5–25% of airtime	wlan.da == ff:ff:ff:ff:ff:ff	Enable multicast-to-unicast conversion. Rate-limit broadcast.
SSID proliferation	2–5% per additional SSID	Count BSSIDs per radio in beacon frames	Consolidate SSIDs. Maximum 3–4 per radio in production.

Quick capacity estimate

Simple formula for capacity planning:

Usable throughput per AP = (PHY rate at design RSSI) × (1 − overhead) × (OFDMA efficiency)

Example - Wi-Fi 6 AP, 80 MHz, 4SS, -67 dBm design RSSI:
PHY rate at -67 dBm ≈ MCS 8 (800 Mbps). Overhead 20% (management + retries). OFDMA efficiency 80%.
Usable ≈ 800 × 0.8 × 0.8 = 512 Mbps usable per AP

With 30 clients each needing 10 Mbps average: 300 Mbps needed vs 512 Mbps available. Capacity sufficient.
With 60 clients: 600 Mbps needed vs 512 Mbps available. AP is capacity-limited - add AP or reduce client load.

Field note: Capacity problems in a PCAP look like this: high channel utilization (BSS Load IE showing >70% channel busy), high retry rate even from clients with good RSSI, low MCS despite good signal. The BSS Load IE (id=11) in beacons shows the AP's own measurement of channel utilization and station count. Filter wlan_mgt.bss_load and watch the channel utilisation percentage over time. Above 50% sustained = AP is capacity-limited. Above 70% = significant degradation. WiFi Analyser parses this automatically.