Auditorium High-Density Capacity Crunch
A 900-seat auditorium hosts a 45-minute product launch. Six Aruba APs are ceiling-mounted, all on 5 GHz with 80 MHz channels; 2.4 GHz is disabled. At 600 associated clients, users report stalls and disconnects. Aruba Central shows AP CPU around 80%, channel utilization 85%, retry rate 40%, and average SNR 18 dB. The presenter uses a wireless microphone and a video stream on the same SSID as the audience. Switches provide 1 Gbps uplinks, and there is no budget to pull new cable. The venue wants 800 concurrent clients on one SSID, mostly smartphones, with acceptable web and video use. You must improve capacity and stability using the existing AP locations and cabling. The APs are Wi-Fi 6 models with 2.4 and 5 GHz radios.
1. What are the primary causes of the poor experience, and which three configuration changes would you make before the event?
Read the worked answer
The 80 MHz channels are the main capacity mistake. In 5 GHz, 80 MHz leaves very few non-overlapping channels, so six APs create heavy co-channel contention; 85% utilization and 40% retries follow. Disabling 2.4 GHz also throws away capacity for smartphones that can use it.
Before the event: move 5 GHz to 20 MHz (or 40 MHz only if the survey proves enough channels), enable 2.4 GHz at 20 MHz, and lower 2.4/5 GHz power so cells are smaller and spectrum is reused. Enable band steering/ClientMatch and airtime fairness, disable low basic rates, and cap clients per radio if the AP supports it. Limit SSIDs and multicast/broadcast. Verify the presenter's wireless mic is not sharing the same congested SSID; if it is Wi-Fi, give it a dedicated SSID/role or wired alternative.
2. Why is 18 dB SNR not automatically the main problem, and what else would you check?
Read the worked answer
An 18 dB SNR is not good, but it is usually enough for lower MCS rates; the 40% retry and 85% utilization point more to airtime contention and excessive channel width than to pure coverage. Check the distribution of client RSSI, not the average. Also check per-radio client counts, retry rates by AP, AP CPU, management-frame overhead, multicast/broadcast, sticky clients, and DHCP/AAA latency. A high CPU may be from management or crypto load. If most clients are at -70 dBm but a few are at -85 dBm, those few can consume airtime and drag down the cell. Use the data to decide whether to reduce power, add client limits, or move the presenter to a dedicated SSID.
3. What monitoring would you run during the event, and what thresholds would trigger a rollback or further change?
Read the worked answer
During the event, watch per-radio channel utilization, retry rate, AP CPU, client count per radio, and the 25th/75th percentile client SNR, plus DHCP and AAA success. Reasonable triggers: utilization above 80%, retries above 30%, AP CPU above 85%, or DHCP success below 99% for 5 minutes. If those occur after the changes, first reduce client load or disable the lowest rates; do not immediately restore 80 MHz, because that would increase contention. Roll back a specific change only if it causes a new coverage hole or the presenter's stream fails. Capture a before/after Central report to distinguish a real regression from normal event burstiness.