Voice Roaming in a 5 GHz-Only Distribution Center
Northline Logistics operates a 180 m × 90 m distribution center with 42 indoor APs. The WLAN is 5 GHz only; 2.4 GHz is disabled. 260 handheld barcode terminals and 40 forklift-mounted voice terminals move continuously. 802.11r is enabled in a single mobility domain, but OKC is disabled and the PMK-R0 key holder is the local AC. Voice logs show 1.2–1.8 s gaps during roaming between aisles. About 30 terminals remain associated with an AP 55 m away even when a closer AP is at −48 dBm. The 5 GHz plan uses 80 MHz on UNII-1 and UNII-3 and 20 MHz on UNII-2; 12 non-overlapping 20 MHz channels are available but only 6 are used. AP transmit power is fixed at maximum. The AC is a single AC6805 running V200R019C10. The customer refuses a location appliance and wants sub-50 ms roaming.
1. The customer says 802.11r is enabled, so roaming should be fast. Identify the most likely reasons the voice terminals still see 1.2–1.8 s gaps, and state which checks you would perform first. Explain how each check changes your diagnosis.
Read the worked answer
802.11r only shortens the key-exchange part; it does not fix discovery, scanning, or a client that does not support FT. First checks:
- Client capability: capture the association/authentication frames. If the voice terminal never sets the FT flag in the RSN IE and uses ordinary WPA2-PSK authentication, 802.11r is irrelevant. Many legacy scanners and voice handsets do not support FT.
- Mobility domain and key holder: all APs and the AC must agree on the MDID and PMK-R0 key holder. If the key holder is the local AC but the APs cannot reach the AC for FT over DS, the fast exchange fails. Check the CAPWAP path and whether FT is over DS or over air.
- Channel width: 80 MHz on UNII-1/UNII-3 reduces the number of clean channels; a client scanning 80 MHz channels spends longer off-channel and can miss beacons. A 1.2–1.8 s gap is too long for FT alone and suggests scanning/reassociation delay.
- Sticky client: maximum power creates large cells. Check the AP's received RSSI from the sticky terminal and the roaming threshold. If the terminal stays at about −70 dBm on the far AP, this is a client roaming-decision problem, not an FT problem.
2. Propose a concrete channel/power and roaming-feature plan to get below 50 ms and remove the sticky clients. Include tradeoffs and what you would not enable.
Read the worked answer
Plan:
- Change 5 GHz to 20 MHz in the aisle area and use the 12 available channels with a reuse pattern. Keep 80 MHz only if a dedicated high-throughput overlay is needed, which it is not here.
- Reduce AP power so the cell edge is around −67 dBm and adjacent APs have 15–20 dB overlap; lower power shrinks the sticky-client problem.
- Enable 802.11k neighbor reports and 802.11v BSS transition on the SSID; configure a sticky-client RSSI threshold (for example −70 dBm) and let the AC steer.
- Keep 802.11r only after confirming client support; if supported, use FT over DS with a consistent mobility domain and set the PMK-R0 holder to a reachable AC/HSB pair.
- Do not enable band steering because 2.4 GHz is disabled. Do not enable 80 MHz in the aisle grid.
Verify with a roaming test: capture authentication, reassociation, and first data frame; target under 50 ms and no retries. Tradeoff: 20 MHz lowers peak rate per AP but increases reuse and deterministic roaming, which matters more for 260 scanners and 40 voice terminals.