Nightly Scanner Disconnects in a Metal-Rack Warehouse
A distribution center has 60 APs on 5 GHz and 2.4 GHz, 1,500 handheld scanners, and racks 12 m high. Scanners roam constantly and are used for 24-hour operations. Every night at 02:00, many scanners disconnect for 5-10 minutes; during the day, scanners near aisle ends report retries of 30-45% and some associate to APs two aisles away. The 5 GHz plan includes DFS channels. ARM is enabled with default settings, and logs show radar detection events on several APs at 02:05.
1. Analyze the likely causes of both the nightly disconnects and the daytime retry problem. Distinguish what the logs prove from what remains a hypothesis.
Read the worked answer
The 02:05 radar events are strong evidence that DFS channel changes are triggering the nightly disconnects. When an AP detects radar, it must vacate the channel; clients on that AP are forced to reassociate, and ARM may then move other APs, extending the disruption. The 5-10 minute duration is consistent with channel-change and client-reassociation storms, not a complete controller outage.
The daytime retries are a separate RF problem. A 30-45% retry rate near aisle ends suggests coverage holes or co-channel interference, and scanners associating two aisles away suggests sticky-client behavior or overly high AP transmit power. High racks block and reflect 5 GHz signals, creating aisles with strong signal in one spot and deep nulls nearby. The logs do not by themselves prove the daytime cause, so validate with per-AP channel utilization, retry counts, client SNR, and a spectrum survey in the aisles.
2. Recommend remediation for the DFS disruption and the RF coverage problem. Prioritize changes that reduce operational risk.
Read the worked answer
First, remove the scanner SSID from DFS channels in this facility. Restrict the scanner-serving APs to non-DFS 5 GHz channels and use 20 MHz width; keep DFS available only for non-critical SSIDs if the spectrum plan requires it. Set ARM to avoid changing channels unnecessarily, and schedule any permitted changes outside operating hours. Verify that the scanner SSID has a fixed, known channel plan rather than relying on default ARM behavior.
Second, fix coverage at the aisle ends. Lower excessively high transmit power so scanners associate with the nearest AP, add APs or antennas where the survey shows a coverage hole, and adjust the minimum RSSI or roaming threshold if the scanner firmware supports it. Consider directional antennas along aisles rather than ceiling-mounted omnidirectional APs above high racks. Test with actual scanners, because their antenna orientation and roaming aggressiveness differ from a laptop survey client.
3. What monitoring would you put in place to catch recurrence before operations notices?
Read the worked answer
Monitor radar events and channel changes per AP, and alert when a scanner-serving AP leaves its planned channel. Track retry rate, channel utilization, client SNR, and association failures per AP and per aisle; set thresholds based on the post-remediation baseline rather than generic vendor defaults. Monitor scanner disconnect counts by AP and by time of day, with a specific alert for the 01:30-03:00 window. Correlate disconnect spikes with radar logs and ARM channel-change events.
Also monitor sticky-client behavior: count clients associated to an AP more than two aisles away and clients with high retry but strong RSSI. Review the alerts weekly, and repeat a spectrum survey after any rack layout or AP change. The goal is to detect a channel change or coverage regression before a shift supervisor reports scanners offline.