Voice handsets on a city council WLAN drop briefly during walks between APs. Controllers have 802.11k/v/r assists enabled, but several older laptops and phones lack those client features. What is the issue?
Select an answer to reveal the explanation.
Short Explanation
Network-side k/v/r doesn’t help a handset that never implemented those IEs. That’s feature incompatibility on the roam path. Expect uneven roam quality until clients support the assists—or design for the lowest common capability.
Full Explanation
Voice handsets on a city council WLAN that drop briefly during walks between APs, with controllers enabling 802.11k/v/r assists but several older laptops and phones lacking those client features, present feature incompatibility: clients without 802.11r/k/v support cannot benefit from those roaming assists the network expects. Infrastructure checkboxes do not implant missing client capabilities. Mixed fleets show uneven roam quality on the same SSID.
Every 802.11 client automatically supporting 802.11r/k/v as soon as the controller enables checkboxes fails because client support is required. Missing client roam features always meaning the fiber uplink to the core is down fails by concept: uplink failure is a different symptom class. Disabling SSIDs on 2.4 GHz as the only remedy when clients lack fast-transition support fails as an overly narrow and often wrong sole fix.
Exam caveat: roam assists need client support; enabling features on the controller alone is incomplete.
Operational check: inventory which council devices support 802.11k/v/r; prioritize upgrades for voice clients; keep standards-based assists enabled per design; validate roam with both capable and incapable devices and set expectations.