Executive Summary
Coming off the Room 325 Bluebook work, the school's wireless still had several zones running on default or stale RF profiles — including the gym complex, the 500 academic wing, and the Commons (lunchroom). The Commons in particular handles roughly 1,140 concurrent client devices at lunch on a single weekday — denser than any classroom load — and 8 of 14 APs there were parked on DFS channels, which puts them one weather-radar event away from a mid-meal blackout.
In a single afternoon session, Cora (the platform's AI ops console) pulled live RF state across all four zones, built tuned RF profiles in Meraki Dashboard via the API, held them unbound for operator review, then applied them on signal — 47 APs in total. Along the way, 7 orphaned RF profiles from prior consultants were renamed and deleted. The same workflow was used to measure the impact during second lunch on the same day: 2.4 GHz utilization was cut roughly in half at every Commons AP.
The pattern at work
- AI-assisted live diagnosis, human-confirmed writes — repeated across multiple zones in one session.
- Idle baselines aren't enough — production wireless changes get validated against peak real-traffic windows whenever the schedule allows.
The Environment
- Private K-12 School — 47-AP Cisco Meraki MR52 wireless deployment across academic wings, gymnasium complex, athletics hall, commons, and the Student Union.
- Meraki Dashboard managed via the platform's least-privileged read tools (Observer-role API key) and a separate write path requiring explicit operator confirmation.
- Confirmed live density: 1,140 active wireless clients across the 14 Commons APs during first lunch on a regular weekday.
- NEXRAD geography (Las Vegas) — weather-radar bleed routinely lights up the upper DFS band with non-WiFi noise.
The Four Zones
1. Gym Complex (9 APs)
Pulled live utilization and radio status for 9 APs in one Cora query:
- 2 in the Main Gym itself: NE, SE
- 7 in the surrounding spaces: Foyer, ATC Gym West/East/Center, Aux Gym, Boys Locker, Girls Locker
Two profiles built (event-area density vs. corridor/spectator density), held unbound for review, then applied on signal. Result:
| Profile | APs bound |
|---|---|
| Main Gym RF profile | Main Gym NE, Main Gym SE |
| Gym Surroundings RF profile | Foyer + ATC Gym W/E/C + Aux Gym + both Lockers |
2. 500 Wing (19 APs)
Largest single-zone migration of the session. Inventory:
- 16× MR52 indoor (classrooms 500-PREP, 501–506, 508–515, plus Campus Ministry)
- 3× additional MR-series APs in the adjacent corridor / common areas
New "500 Wing" RF profile built, verified unbound, held for the operator's post-class apply signal, then applied across all 19 APs once class periods cleared.
3. Athletics Hall
A discovery rather than a planned zone — Cora flagged it mid-session: 49 unique clients in 30 minutes on a corridor AP was higher than expected, and the existing profile binding was wrong for the actual usage pattern. The operator's call: bind to an existing tuned profile rather than build a fourth new one. Applied same session.
4. Commons / Lunchroom (14 APs)
This is the dense zone — 14 APs (12 named COMMONS_* plus 2 adjacent Student Union Cafe APs), and the live snapshot during first lunch showed 1,140 concurrent clients. Per-AP snapshot examples:
| AP | Clients | 2.4 GHz | 5 GHz |
|---|---|---|---|
| COMMONS_N1 | 65 | ch 11 | (DFS — see below) |
| COMMONS_N7 | 177 | — | ch 100 @ 80 MHz (DFS) |
| COMMONS_S3 | (high) | — | ch 60 (DFS) |
| COMMONS_N4 | (high) | — | ch 64 (DFS) |
8 of 14 APs were sitting on DFS channels at lunch peak. The largest single-AP exposure was COMMONS_N7 — 177 active clients on ch 100 @ 80 MHz, the single channel most exposed to local NEXRAD weather-radar interference. A single radar hit there drops 177 clients mid-meal.
The Remediation — Commons Profile, In Place
Rather than create yet another profile, the existing Commons profile was edited in place, so all 11 live APs (excluding the dormant N8 — see below) inherited the change immediately without a re-bind:
| Setting | Before | After |
|---|---|---|
| 2.4 GHz max power | 27 dBm | 5 dBm |
| 2.4 GHz min bitrate | 18 | 12 |
| 5 GHz max power | 30 dBm | 17 dBm |
| 5 GHz min bitrate | 18 | 12 |
| 5 GHz valid channels | DFS-inclusive | non-DFS (excludes ch 52–144) |
Then — separately — six DFS-occupied APs got per-AP channel overrides to force them off DFS immediately, because of the lesson learned in this same session (next section).
The Lesson — Meraki RRM Is Sticky on DFS
When the Commons profile was first updated to exclude DFS channels, Cora confirmed the profile change went live — but the APs already on DFS channels stayed there. Meraki RRM does not force-migrate APs when a profile's channel pool changes mid-flight; it treats the existing channel as still "valid for now" and only re-evaluates on the next routine RRM tick. With 177 active clients on N7, that was an unacceptable wait window.
Force-pin per AP with a temporary radio override gets them off DFS in seconds. The per-AP channel migrations that followed:
| AP | Before | After | Result |
|---|---|---|---|
| COMMONS_N7 | DFS ch 100 @ 80 MHz | ch 149 | 177-client NEXRAD risk eliminated |
| COMMONS_S3 | DFS ch 60 | ch 165 | Clean |
| COMMONS_N4 | DFS ch 64 | ch 157 | Clean |
| COMMONS_N2 | DFS | ch 48 | Mid-transition; landed on first poll |
| COMMONS_N6, N9 | DFS | non-DFS | Clean |
The Measurement — Lunch 1 vs Lunch 2
An apples-to-apples comparison: the first-lunch baseline was snapshotted before the profile change. The same 30-minute per-AP data was pulled during second lunch — same density, same demographics, same wired backhaul.
The big win — 2.4 GHz utilization roughly halved
| AP | 2.4 GHz utilization (Lunch 1 → Lunch 2) |
|---|---|
| COMMONS_N4 | 30.4% → 13.9% (-54%) |
| COMMONS_N3 | 23.1% → 11.0% (-52%) |
| COMMONS_N1 | 22.3% → 10.7% (-52%) |
The 2.4 GHz power drop (27 dBm → 5 dBm) plus the band-steering combination did exactly what it was supposed to: capable clients moved to 5 GHz, and the 2.4 band stopped being congested.
Side Effect — Orphan-Profile Cleanup
Mid-session, Cora flagged 7 RF profiles in the wireless network that weren't bound to any APs — leftovers from previous consultants and one-off tests. The operator's call: rename them with an ORPHANED - prefix first (as a safety pause), confirm none were silently in use, then delete. All 7 deleted clean. Network reduced to 14 custom profiles + 2 system defaults. Pre-delete settings archived for rollback (never needed).
The Hidden Find — One AP Had Been Dead 21 Months
Pulling the deep diagnostic on COMMONS_N8 revealed the device wasn't just RF-misconfigured — it was dormant:
| Signal | Reading |
|---|---|
| Meraki status | dormant (not online, not offline — abandoned) |
| Last reported to Dashboard | 2024-08-17 — 21 months ago |
| Switch-port status | Up/Up, but no traffic |
This is not a tuning problem — it's a hands-on hardware/cable issue. Captured and triaged out of the RF workstream into a separate, scheduled site-visit work item.
Outcomes Recap
- 9 APs in the gym complex bound to one of two purpose-built profiles
- 19 APs in the 500 Wing moved to the new tuned profile (held + then applied on the operator's signal)
- 1 AP in Athletics Hall rebound to a better-fit existing profile
- 11 APs in the Commons silently benefited from the in-place profile edit; 6 of them also got force-channel overrides to escape DFS
- 7 orphan RF profiles removed
- Commons 2.4 GHz utilization halved at peak lunch load, measured against a same-day baseline
- NEXRAD-DFS exposure on the busiest Commons AP eliminated (177 clients moved off the vulnerable channel)
- One dormant AP identified and triaged out of the RF workstream into a hands-on workstream
- One reusable lesson captured (Meraki RRM sticky DFS) — the next profile-tweak session won't lose 30 minutes to it
All of this in a single afternoon, with a clean rollback trail and zero unintended user impact during a live lunch period.