4.8 KiB
High-density UniFi RF tuning — methodology
Synthesized from a multi-model pass (Grok 4.3 + Gemini 3.1 Pro, which converged strongly) plus live recon of Cascades. The governing principle in a congested environment: conserve airtime and shrink 2.4GHz participation — you cannot out-tune ambient interference (Cascades sees ~33k neighbor BSSIDs on 2.4 ch6), so the win is moving capable clients onto smaller 5/6GHz cells and using 2.4 for legacy coverage only. Applies to any UOS site; thresholds below are starting points to tune from each site's data.
Fix order (do in this sequence — earlier steps de-risk later ones)
- Prune 2.4GHz radios. Disable the 2.4 radio on ~40–60% of APs in dense clusters; keep 2.4 only where needed for coverage/legacy (perimeter, stairwells, elevators, rooms with 2.4-only medical pendants/tablets). 77 APs all on 2.4 in this density is catastrophic self-interference. Target ≤15–25 STAs per active 2.4 radio.
- Power + width. 2.4 → Low / custom ~6–11 dBm (smallest cells so a client hears 2–3 BSSIDs, not 20). 5GHz → Medium / ~12–15 dBm, 40MHz (avoid 80/160 in density — wide channels destroy spatial reuse). 6GHz → 80MHz, higher power ~18–20 dBm as a "staircase" that pulls 6E-capable clients up into the clean lane.
- Minimum data rates. Disable 1–11 Mbps; set 2.4 minimum to 12 or 24 Mbps. Kills the management-frame overhead from distant/legacy stations and effectively shrinks cells.
- Channel plan (manual). Strict 1/6/11, 20MHz on 2.4; assign per-zone so adjacent APs differ, weighting toward the channel where our APs dominate vs neighbor density. 5GHz: spread across UNII-1 + DFS (UNII-2/2e) for more non-overlapping channels; U7-Pro DFS filtering is good. 6GHz: PSC channels. Do NOT use nightly/auto channel optimization in ultra-dense — it can't model intermittent neighbor interference; pin a manual plan.
- min-RSSI + roaming. 2.4 min-RSSI −75/−76, 5GHz −70/−72 (start −72, tighten only if satisfaction stays high). Enable 802.11r (fast roaming) + 802.11v (BSS transition) — but test legacy medical/IoT devices first; if pendants drop, scope 802.11r to a separate SSID or disable. Senior users pause mid-hallway — don't over-aggress (−65 causes drops).
- Steering. Band steering prefer 5GHz globally; enable 6GHz for capable clients. Consider a separate legacy SSID for fragile 2.4-only devices so the main SSID can be tuned aggressively.
- Monitor + iterate (needs live-stats plane). Re-audit neighbor density monthly — external interference won't go away; the job is to keep shrinking 2.4 participation and packing capable clients onto small 5/6GHz cells.
Metrics → action thresholds (drive every change from data, not vibes)
| Signal (source) | Threshold | Action |
|---|---|---|
cu_total (channel utilization) |
> 50–60% sustained | reduce width, disable a 2.4 radio, or move AP off that band |
cu_self_rx/cu_self_tx vs cu_total |
self low but total high | neighbors eating airtime → raise min data rates, shrink cell, change channel |
tx_retries per radio/client |
> 15–20% | co-channel/hidden-node or power too high or sticky client; try a DFS channel |
satisfaction (AP/client) |
< 80–90% | investigate that AP/zone |
num_sta per radio |
> 40 on a 5GHz radio / > 25 on 2.4 | add steering pressure or another AP; prune nearby 2.4 |
neighbor BSSIDs per channel (rogue) |
>> 500 on a channel | don't site critical 2.4 there; consider disabling 2.4 in that wing |
| roam quality | edge RSSI −68..−72, SNR ≥ 20 dB | healthy handoff target |
Plane 1 (Mongo) gives: config audit, the neighbor-density (rogue) map, channel plan, num_sta
(last-reported), min_rssi state. Plane 2 (live Network API, not yet wired) gives: live cu_total,
tx_retries, satisfaction, per-client RSSI/SNR. See data-access.md.
30-day success criteria
Median client satisfaction > 90%; 2.4 cu_total < 40% on active radios; 5/6GHz carrying > 75% of
associations; tx-retry < 10% on the primary SSID.
Cascades-specific (the hard case)
77 U7-Pro APs / ~550 clients / 6 of 77 APs currently have 2.4 min-RSSI OFF. 2.4 is saturated on 1/6/11 (16k–33k neighbors each) → aggressive pruning is mandatory, not optional. 6GHz is nearly empty (ch69: 86 neighbors) → the biggest untapped win is steering 6E-capable clients to 6GHz. 5GHz upper (149/157) is busier than UNII-1/DFS lower → bias the 5GHz plan toward 36–48 + DFS.
Caveat: these are independent-model recommendations + config-plane recon. Validate against live
cu_total/satisfaction before/after each change (Plane 2), and roll out per-zone, not site-wide at once, so a bad assumption is contained.