Floor 6 Outages: Radar Events and Clients That Will Not Roam
Riverside HQ runs a 5 GHz-only WLAN for 900 laptops across 40 APs on six floors, with automatic channel and power selection scheduled nightly at 03:00 and 40 MHz channel width. Since a neighbouring building was re-tenanted, users on floor 6 report outages of 40–90 seconds at unpredictable times, mostly in the afternoon. The AC event log shows repeated radar detections on channels 52 and 60, after which the radios move to channel 149 and resume. Separately, helpdesk sees a daily pattern: users who walk from floor 6 to floor 5 keep their session on the floor 6 AP at around −78 dBm, get 2–5 Mbps, and only recover after disabling and re-enabling Wi-Fi. Floor 6 has 8 APs; the stairwell has one AP per floor. Capacity is otherwise adequate.
1. Explain the 40–90 second outage mechanism and evaluate the options for eliminating it without halving capacity.
Read the worked answer
Mechanism: channels 52–64 sit in the 5.25–5.35 GHz range, which is subject to DFS. On detecting a radar pulse the AP must vacate the channel immediately: it stops transmitting, which disassociates clients, then performs a Channel Availability Check (typically 60 s) on the candidate new channel before it may radiate. Clients see a hard drop and reassociate only after the radio returns - matching the observed 40–90 s. This is not a bug and not a coverage problem; it is regulatory behaviour.
Options, with trade-offs:
- Restrict the channel set to non-DFS channels. In the CN regulatory domain the non-DFS 5 GHz ranges are 5150–5250 MHz (36–48) and 5725–5850 MHz (149–165). Excluding 52–64 removes radar events entirely.
- Consequence: fewer channels means more co-channel reuse across 40 APs. Mitigate by dropping from 40 MHz to 20 MHz on the busiest floors (more non-overlapping channels, lower per-AP peak but better reuse and less CCI), and by tightening power so cells do not overlap excessively.
- Keep DFS but reduce exposure: pin floor 6 to 36–48 and the upper floors to 149–165; accept that radar may still force a move in the DFS band elsewhere.
- Do not simply set a fixed channel inside the DFS band - a fixed DFS channel is still legally vacated on radar detection.
Also verify the detections are genuine: nearby weather or aviation radar can cause legitimate hits, but so can a misconfigured or faulty radio. Check whether detections correlate with the neighbour's new equipment before removing an entire band from the plan. Finally, moving the 03:00 calibration is irrelevant - these events happen in the afternoon, so the nightly schedule is not the cause.
2. Diagnose the floor 6 → floor 5 roaming problem and specify the configuration and validation steps.
Read the worked answer
Diagnosis: this is a sticky client. The laptop stays on the floor 6 AP at −78 dBm because the client's own roaming decision is conservative and it sees no better candidate with sufficient margin. At −78 dBm the client falls to a low MCS with heavy retries, so throughput collapses to 2–5 Mbps even though the floor 5 AP is close and lightly loaded. Disabling and re-enabling Wi-Fi forces a fresh scan, which is why that works.
What to change:
- Enable smart roaming on the AC (RRM profile:
smart-roam enable) with an SNR-based trigger, for example roam when SNR drops below ~20 dB. This lets the infrastructure steer the client rather than waiting for the client's firmware. - Enable 802.11k/v where supported: neighbour reports give the client a candidate list, and BSS Transition Management frames actively push it to the better AP. Clients that do not support these still benefit from the SNR trigger.
- Rebalance power. If the floor 6 APs radiate too far down the stairwell, the client hears them strongly enough not to roam. Reduce 5 GHz power on floor 6 and confirm the stairwell AP covers the transition zone with ≥ 6 dB hysteresis over the floor above.
- Remove low rates so a client on a dying link degrades quickly instead of lingering at 6–12 Mbps.
Validation: reproduce the walk with display station all and the station roam record; confirm the station moves to the floor 5 AP before RSSI falls below about −72 dBm, throughput stays above 50 Mbps during the walk, and no disassociation occurs. Repeat 10 times - a single successful walk proves nothing.
3. An operations manager argues "the floor 6 problem is just poor coverage, so add APs". What evidence would you collect to accept or reject that, and what would change your mind?
Read the worked answer
Reject or accept on evidence, not opinion. The radar event log already explains the 40–90 s outages and is unrelated to coverage; but the sticky-client symptom could in principle come from a genuine coverage hole in the stairwell, so both must be separated.
Evidence to collect:
- Per-station RF data on floor 6 and the stairwell: RSSI, SNR, retry rate, and negotiated rate, sampled during the walk. Clients at −78 dBm with high retries but an available neighbour at −60 dBm indicate roaming logic, not coverage.
- Coverage survey at the stairwell landing and along the floor 5/6 transition: if no AP delivers ≥ −67 dBm with ≥ 25 dB SNR anywhere in the path, a hole exists and an AP is justified.
- Channel utilisation and interference on floor 6: high utilisation with low client count points to co-channel interference or a non-Wi-Fi interferer, not missing coverage.
- Roaming records with timestamps, correlated against the radar events - if the two symptom sets never overlap, they are independent faults.
- Client model breakdown: if stickiness concentrates on one chipset, the fix is steering/threshold tuning rather than hardware.
What would change my mind: a survey showing the stairwell or floor 5 corridor below −72 dBm from every AP, plus failure to roam even when a strong candidate is present. In that case add or re-site an AP.
What would not: a single user complaint, a floor plan annotation, or an AP count comparison against another building.