64 lines
4.8 KiB
Markdown
64 lines
4.8 KiB
Markdown
# 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)
|
||
1. **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**.
|
||
2. **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.
|
||
3. **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.
|
||
4. **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.
|
||
5. **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).
|
||
6. **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.
|
||
7. **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](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.
|