Channel 6 at 84 Percent: Finding the Real Airtime Consumer
A 400-person insurance office has 60 APs. 2.4 GHz users report slow file saves and video stalls; 5 GHz users are fine. A 10-minute monitor-mode capture on channel 6 shows: 68% of airtime consumed by management and control frames, each AP advertising 9 SSIDs with a 100 ms beacon interval, a heavy volume of CTS-to-self and RTS/CTS exchanges, and 14% of data frames sent at 1 and 2 Mbps. Overall retry rate is 9%. The WNMS reports 84% channel utilization at the busiest AP and 31% at a neighbouring AP on channel 1. Spectrum analysis shows no non-Wi-Fi interferer above -85 dBm. The customer's first request is to add two more APs near the affected desks.
1. Quantify roughly where the airtime is going and rank the fixes. Address the customer's request to add APs.
Read the worked answer
Estimate contributors per second on channel 6 rather than per frame count:
- Beacons. Beacons per second = audible APs on the channel x SSIDs per AP x 10. Management frames go out at the lowest basic rate, so each beacon costs roughly 2 ms of airtime at 1 Mbps including preamble and interframe spacing. Collapsing 9 SSIDs to 2-3 cuts this proportionally; raising the basic rate cuts it again.
- Legacy-rate data frames. 14% of data frames at 1-2 Mbps can easily be a third or more of data airtime, because a 1 Mbps frame occupies 12 times the channel of a 12 Mbps frame of the same size.
- Protection overhead. The CTS-to-self and RTS/CTS volume is an artefact of 802.11b rates being enabled: ERP protection is triggered by the presence of low-rate capable stations, and every protection exchange steals airtime from data.
Ranked fixes: (1) reduce SSIDs to the minimum the business needs, (2) disable 1/2/5.5/11 Mbps after verifying no legacy-only clients, (3) re-plan channel and power so the busy AP is not sharing channel 6 with strong neighbours.
Adding APs makes this worse: more APs means more beacons and more co-channel contention at 84% utilization. The request should be declined until the airtime budget is reduced.
2. The customer argues a 9% retry rate proves interference and wants a spectrum analysis escalation. How do you test that claim with the capture you already have?
Read the worked answer
A 9% retry rate is elevated but is a symptom, not a diagnosis, and it is consistent with congestion rather than an external interferer. The spectrum data already rules out a strong non-Wi-Fi source above -85 dBm.
Tests to run on the existing capture and WNMS data:
- Retry distribution by client and by rate. If retries cluster on a handful of clients at low SNR or long distance, the cause is cell-edge design; if retries are spread evenly across all clients including strong ones, the cause is contention.
- Retry direction. High retries on frames the AP transmits to many different clients points to hidden nodes or excessive cell size; high retries in one direction only points to a weak client radio (common with embedded or low-power devices).
- Airtime per client, not frame count. Look for a small number of clients consuming a large share of airtime at low rates - these are the real cost drivers and are invisible in a frame-count report.
- Correlation window. Compare utilization spikes to retry spikes: simultaneous rise indicates contention; retries without utilization rise indicate interference.
Only if those tests show a pattern inconsistent with contention should the investigation escalate to a dedicated spectrum monitor.
3. What is the operational risk of disabling the 1, 2, 5.5, and 11 Mbps rates, and how would you validate before making the change?
Read the worked answer
Disabling low rates strands any client that cannot associate at the new basic rate. In practice the offenders are exactly the devices nobody inventories: label printers, barcode scanners, older VoIP handsets, building-control gateways, and guest devices from the 2000s. If a device is stranded it will not merely perform badly - it will disappear from the network and may generate a support incident during business hours.
Validation approach:
- Pull 14 days of association statistics from the WNMS and list every client whose highest or only observed data rate is 11 Mbps or below. Identify each one by owner.
- Cross-check the monitor-mode capture for probe requests and association requests carrying only 802.11b rate sets; these are the devices that will break.
- For each identified device, choose: replace it, pin it to a dedicated SSID on a small AP group that keeps legacy rates, or accept the outage with a signed risk acceptance.
- Change one floor or one AP group first, watch for 48 hours, then roll out.
Also note that raising the basic rate changes beacon and management airtime for the better, so the change usually pays for itself immediately - which is why it should be validated rather than skipped.