Voice Roams That Fall Back to Full 802.1X
A 310,000 sq ft distribution centre runs 140 APs on 5 GHz at 40 MHz with WPA2-Enterprise (EAP-TLS), serving 250 VoWiFi handsets and 900 handheld barcode scanners. Handsets are configured for 802.11r in adaptive mode and 802.11k; scanners use FT-PSK on an IoT SSID. About 4% of calls drop when workers cross aisle boundaries and scanner sessions reset during aisle transitions. A capture at an aisle boundary shows roam times of 1.2 to 1.8 seconds on affected roams, with a full EAP exchange after the Reassociation Request. The affected roams cluster on a group of 20 older APs added in a warehouse expansion; the WNMS shows those APs in a different mobility domain and with FT disabled.
1. Confirm the diagnosis from the capture and explain precisely why the roam is slow.
Read the worked answer
Look at the Reassociation Request and the RSNE inside it:
- FT capability is advertised in the Mobility Domain element and in the RSNE AKM suite. For FT-802.1X the AKM is 00-0F-AC:3. If the client's Reassociation Request carries no MDIE/FTIE and lists only AKM 1, the client is not doing FT at all on that roam, regardless of what the handset menu says.
- A full EAP exchange after reassociation is the signature of a PMKSA miss. Either the cached PMK was not available at the target AP (different mobility domain, so no PMK-R1 was derived and no PMK-R0 key holder relationship exists), or the client did not include a PMKID.
The 20 expansion APs have FT disabled and sit in a different mobility domain, so any roam that lands on one of them cannot use the fast transition path and must run a complete 802.1X exchange: EAP round trips plus RADIUS, which on a loaded network is 1-2 seconds and longer if the RADIUS response is slow. The clustering on aisle boundaries adjacent to those APs is the confirmation.
Before changing anything, capture an affected roam and a good roam side by side; the presence or absence of the FTIE and the EAP exchange distinguishes a configuration fault from a client-side problem immediately.
2. Describe the configuration changes needed and the trade-offs between FT-over-DS and FT-over-Air for this environment.
Read the worked answer
Configuration: put all 140 APs in one mobility domain (identical MDID) and enable FT consistently - a partially enabled FT deployment is worse than none, because clients will attempt FT and time out on the APs that cannot complete it. Ensure both the R0 key holder and R1 key holders are configured consistently, and that the same PMK cache/key-holder pair is reachable from every AP the client may roam to.
FT-over-DS vs FT-over-Air:
- Over-the-Air has the client send the FT Authentication frame directly to the target AP, which pulls the PMK-R1 from the R0 key holder over the DS. Fewer frames on the air from the client, and it tolerates a target AP that is only reachable by the client.
- Over-the-DS has the client send the FT request through its current AP, which relays it over the distribution system. This is generally faster when the DS is fast and the target AP is weakly heard by the client at the decision point - a real risk here, because a handset at an aisle boundary may barely hear the AP it is about to join.
With a well-switched DS and 140 APs, FT-over-DS usually wins for voice. Whichever is chosen, verify that the key holders can reach each other across the network segmentation between the expansion and original buildings; a firewall rule blocking inter-AP key requests will silently convert every roam back to full authentication.
Also confirm the scanners' FT-PSK AKM (00-0F-AC:4) is enabled consistently, since they show the same symptom.
3. Channel width and cell design are also implicated. What would you change, and what is the risk to throughput?
Read the worked answer
40 MHz channels on 5 GHz halve the number of available non-overlapping channels and make each cell wider, so the client's roam decision point moves closer to the AP and the overlap region between cells shrinks. Handsets then hold on until the signal is poor, which produces late roams and failed transitions - the same symptom the customer blames on 802.11r.
Recommended changes:
- Move the high-density picking areas to 20 MHz. The throughput loss per client is real but mostly irrelevant for voice (a voice call needs under 200 kbps) and for scanners; the gain is that channel reuse and cell overlap both improve.
- Reduce transmit power on the dense APs so that cells overlap by roughly 15-20% rather than blanketing aisles. Lower power with more cells is what makes roaming work.
- Keep 40 MHz only where a genuinely high-throughput client population needs it.
Also confirm the 802.11k neighbour report is being consumed - the handset should be choosing from a supplied list rather than scanning blindly, which is what causes the multi-second scan phase in some of these roams. If handsets support 802.11v, enable BSS Transition Management so the infrastructure can steer a client that is holding on too long.
The trade-off statement to the business: fewer MHz per client, more predictable roam behaviour and better voice, with a measurable per-client peak throughput reduction that must be checked against the scanner application's actual requirement.