VoWiFi Roaming Gaps in a Two-Controller Hospital
A 620-AP, eight-floor hospital runs two Catalyst 9800-40 controllers in one mobility group. Nursing staff carry VoWiFi handsets using 802.1X PEAP that support 802.11r, 11k, and 11v. The WLAN is WPA2-Enterprise with 802.11r disabled, because two legacy handset batches that could not associate with it have since been retired. CCKM is disabled and band steering is off. Nurses report 4-8 second audio gaps when walking between floors and wings; the controller shows roam times of 800-1,500 ms, and many roams cross controllers. The team has already confirmed coverage is above -67 dBm along every corridor and that both controllers have identical WLAN configuration.
1. Decompose where the 800-1,500 ms is going and state what a voice-grade roam target looks like.
Read the worked answer
The roam is not one event; it is a chain, and without fast transition most of the time is spent in the security exchange:
- Client scanning and decision: 100s of ms to seconds. The client must hear a better AP and decide to leave; with its roam threshold low, it searches late.
- Full 802.1X/EAP re-authentication on the new AP: 300-1,000 ms typical, because the entire EAP exchange plus 4-way handshake replays.
- Reassociation and key installation, plus DHCP if the client changes subnet. A cross-subnet roam can add seconds for a client that re-DHCPs.
- Cross-controller roams add PMK distribution over the mobility tunnel plus a data-path switch, which is why those are worst.
Target: under 150 ms total for voice, ideally under 50 ms with fast transition. Anything above 200-300 ms is audible as a gap with most handsets. The reported 800-1,500 ms is consistent with a full EAP re-auth plus a late client decision, not with coverage problems.
2. Choose between OKC/PMK caching, CCKM, and 802.11r, given the current mixed fleet, and give the configuration and verification points.
Read the worked answer
The fleet supports 802.11r, so use it. CCKM is a legacy Cisco mechanism that needs explicit client support and adds nothing here; PMK caching alone (sticky key caching, and OKC across controllers) avoids the full EAP exchange but still requires the reassociation and key exchange, and OKC support is client-dependent.
Configuration on the 9800:
- Enable 802.11r FT and enable adaptive mode so clients that do not advertise FT still associate with normal 802.1X rather than failing. This matters because the SSID serves laptops and infusion pumps as well as handsets.
- Keep PMK caching and OKC enabled as a fallback for clients that do not do FT.
- Confirm both controllers are in the same mobility group with data tunneling and that the mobility tunnels are up and keepalives healthy; FT key holders must be reachable across the group, and a stale tunnel is a classic source of cross-controller roam failures.
- Verify WLAN IDs and security policy are identical on both controllers.
Verification: client debug for the roaming history showing the reassociation and key exchange timings, and a packet capture across a roam showing the FT authentication and reassociation exchange. Test with the actual handset models, not a laptop.
3. Fast transition fixes the security delay. What else do you change to shrink the client's decision time and keep cells from overlapping excessively?
Read the worked answer
Attack the decision and the cell geometry:
- 11k neighbor reports give the handset a list of candidate APs so it does not have to scan every channel; 11v BSS transition management lets the infrastructure suggest a better AP before the client is in trouble. Confirm the handsets actually honor both, since support is inconsistent.
- Minimum RSSI per WLAN around -70 dBm so a client clinging to a distant AP is politely evicted while an alternative exists.
- Disable 6/9/12 Mbps to tighten the usable cell edge; this physically shrinks cells so overlaps are smaller and roam decisions happen earlier.
- Reduce transmit power in dense corridor areas; with 620 APs the risk is overlapping coverage, not coverage holes.
- Band steering on, and consider a 5 GHz-only policy for the voice handsets so they never land on a congested 2.4 GHz channel and then have to band-steer mid-call.
Verify with the client's roaming history after the change, comparing roam counts, roam duration, and retry counts on the voice WLAN before and after, per floor.