Résoudre les problèmes d'itinérance dans les WLAN d'entreprise
Ce guide fournit aux architectes réseau et aux responsables informatiques une référence technique définitive pour diagnostiquer et résoudre les problèmes d'itinérance WiFi dans les WLAN d'entreprise. Il couvre les mécanismes de la transition rapide BSS IEEE 802.11r, de la mesure des ressources radio 802.11k et de la gestion de la transition BSS 802.11v, avec des conseils de configuration neutres vis-à-vis des fournisseurs pour les déploiements VoIP et de personnel mobile. Des scénarios de mise en œuvre réels issus des secteurs de l'hôtellerie, du commerce de détail et du secteur public démontrent des résultats mesurables et la justification commerciale d'investir dans une infrastructure d'itinérance rapide.
Écouter ce guide
Voir la transcription du podcast
Résumé Exécutif
Les problèmes d'itinérance WiFi sont l'un des problèmes les plus dommageables sur le plan opérationnel et les plus fréquemment mal diagnostiqués dans les réseaux sans fil d'entreprise. Lorsqu'un appareil mobile passe d'un point d'accès à l'autre — qu'il s'agisse d'un client d'hôtel en appel Wi-Fi, d'une infirmière transportant une tablette entre les services, ou d'un opérateur d'entrepôt sur un véhicule motorisé — la qualité de ce transfert détermine si l'application reste active ou échoue. L'itinérance 802.11 standard, même avec l'authentification WPA2-Enterprise et 802.1X, introduit une latence de transfert de 500 ms à plus de 1 000 ms. C'est catastrophique pour la voix en temps réel et inacceptable pour les applications opérationnelles sensibles à la latence.
La suite d'amendements IEEE 802.11 — spécifiquement 802.11r (Fast BSS Transition), 802.11k (Radio Resource Measurement) et 802.11v (BSS Transition Management) — a été conçue pour y remédier directement. Déployés comme une « Triple Pile » coordonnée, ces trois protocoles réduisent la latence de transfert à moins de 50 ms, accélèrent la découverte des points d'accès et permettent l'orientation des clients dirigée par le réseau. Ce guide présente l'architecture, la configuration et les implications opérationnelles de chaque protocole, avec des conseils de mise en œuvre pour les environnements de l'hôtellerie, du commerce de détail et du secteur public où le Guest WiFi et la connectivité de la main-d'œuvre mobile sont essentiels à l'activité.
Approfondissement Technique
La Cause Profonde des Problèmes d'Itinérance WiFi
Avant d'aborder la solution, il convient d'être précis sur le problème. Dans un WLAN 802.11 standard, la décision d'itinérance est entièrement pilotée par le client. L'infrastructure n'a aucun mécanisme pour ordonner à un appareil de se déplacer vers un meilleur point d'accès. Le client conserve son association actuelle jusqu'à ce que l'indicateur de force du signal reçu (RSSI) se dégrade à un point où l'algorithme d'itinérance interne de l'appareil décide de chercher une alternative. Cela entraîne deux modes de défaillance bien documentés.
Le premier est le problème du client « collant » : un appareil reste associé à un point d'accès distant et dégradé plutôt que de passer à un point d'accès plus proche et plus fort. C'est particulièrement courant avec les anciens systèmes d'exploitation et les combinés d'entreprise qui ont des seuils d'itinérance conservateurs. Le second est la latence de transfert : même lorsque le client décide de s'itinérer, le processus de réauthentification dans un environnement 802.1X nécessite un échange EAP complet avec le serveur RADIUS, ce qui introduit la latence qui interrompt les applications en temps réel.
Comprendre les fréquences Wi-Fi est un prérequis pour la conception de l'itinérance — les bandes 5 GHz et 6 GHz offrent plus de canaux non superposés et moins d'interférences de co-canal, ce qui en fait les bandes préférées pour la voix et le trafic sensible à la latence, mais leur portée de propagation plus courte signifie que plus de points d'accès sont nécessaires, ce qui augmente à son tour la fréquence des événements d'itinérance.
802.11r — Transition Rapide BSS (FT)
802.11r, ratifié en 2008 et incorporé dans la norme consolidée 802.11-2012, résout le problème de la latence de réauthentification en introduisant une hiérarchie de mise en cache des clés. Lors de l'authentification 802.1X initiale, le serveur RADIUS dérive une clé de session maître (MSK). Dans un déploiement standard, cette clé est utilisée pour dériver la clé maître par paire (PMK), qui est ensuite utilisée dans un échange en quatre étapes pour dériver la clé transitoire par paire (PTK) pour la session.
Avec 802.11r, la PMK est utilisée pour dériver une clé PMK-R0 (clé racine), qui est détenue par le contrôleur WLAN ou l'ancre de domaine de mobilité. À partir de là, les clés PMK-R1 sont pré-distribuées aux points d'accès voisins au sein du même domaine de mobilité. Lorsque le client s'itinère, il présente son identité de détenteur de PMK-R1 au point d'accès cible, qui détient déjà le matériel de clé pertinent. L'échange en quatre étapes est remplacé par un échange de transition rapide à deux messages, réduisant la surcharge cryptographique à quasi zéro.
Le résultat est un temps de transfert de moins de 50 ms — dans la recommandation ITU-T G.114 de 150 ms de délai unidirectionnel pour la qualité vocale, et bien en deçà du seuil pour maintenir une session SIP active sans perte de paquets.
802.11r prend en charge deux modes de transition :
| Mode | Mécanisme | Cas d'utilisation |
|---|---|---|
| FT par voie hertzienne | Le client communique directement avec le point d'accès cible pendant la transition | Déploiements standards avec communication directe de point d'accès à point d'accès |
| FT via le système de distribution | Le client communique avec le point d'accès cible via le point d'accès actuel et le système de distribution | Déploiements où les points d'accès ne peuvent pas communiquer directement ; plus dépendants du contrôleur |
Le FT via le système de distribution est généralement préféré dans les architectures basées sur un contrôleur car il permet au contrôleur WLAN de gérer la distribution des clés de manière centralisée.
802.11k — Mesure des Ressources Radio
Alors que 802.11r accélère la transition elle-même, 802.11k aborde le problème de la découverte des points d'accès. Sans 802.11k, un client cherchant un nouveau point d'accès doit effectuer un balayage actif ou passif sur tous les canaux pris en charge. Dans un environnement d'entreprise dense fonctionnant sur les bandes 2,4 GHz, 5 GHz et potentiellement 6 GHz, cela peut prendre 200 à 400 ms — ajoutant une latence significative avant même le début de la transition 802.11r.
802.11k permet aux points d'accès de fournir aux clients un rapport de voisinage : une liste structurée des BSSID à proximité, de leurs canaux de fonctionnement et des informations de capacité. Lorsqu'un client demande un rapport de voisinage (ou en reçoit un non sollicité), il peut cibler son balayage uniquement sur les canaux et BSSID listés, réduisant le temps de découverte jusqu'à 60 % dans les déploiements d'entreprise typiques.
De plus, 802.11k prend en charge les rapports de balise, où le point d'accès demande au client de mesurer et de signaler les niveaux de signal des points d'accès environnants. Cela donne au contrôleur WLAN une visibilité en temps réel de l'environnement RF du point de vue du client — inestimable pour l'optimisation RF et la résolution des problèmes persistants de roaming.
Pour les environnements de santé où les infirmières et les cliniciens transportent des appareils compatibles Wi-Fi entre les services, la capacité du 802.11k à réduire le temps de balayage est opérationnellement significative. Un délai de balayage de 400 ms sur un système de notification d'alarme clinique n'est pas acceptable ; un balayage ciblé de 40 ms l'est.
802.11v — Gestion de la transition BSS
Le 802.11v inverse le modèle de roaming traditionnel en donnant à l'infrastructure une voix dans la décision de roaming. Le protocole définit une trame de requête de gestion de transition BSS (BTM) que l'AP ou le contrôleur WLAN peut envoyer à un client pour suggérer — ou fortement recommander — qu'il transite vers un AP cible spécifique.
C'est le mécanisme qui permet l'équilibrage de charge dirigé par l'AP. Si un AP particulier approche de son seuil de capacité client (généralement 25 à 30 clients par radio pour les déploiements de qualité vocale), le contrôleur peut envoyer des requêtes BTM aux clients ayant le RSSI le plus bas sur cet AP, les dirigeant vers des voisins moins chargés. Cela évite l'expérience dégradée qui se produit lorsqu'un seul AP devient un point d'accès saturé — courant dans les salles de conférence, les halls d'hôtel et les zones de caisse de commerce de détail.
Le 802.11v prend également en charge les notifications de dissociation imminente, où l'AP informe un client qu'il sera dissocié dans un délai spécifié, donnant au client le temps de transiter en douceur plutôt que de subir une déconnexion abrupte. Ceci est particulièrement utile lors des fenêtres de maintenance planifiées ou lorsqu'un AP détecte une défaillance matérielle.
Il est important de noter que le 802.11v est consultatif, et non obligatoire. Le périphérique client prend la décision finale de roaming. Les appareils Apple iOS (iOS 11 et versions ultérieures) répondent de manière fiable aux requêtes BTM. Le comportement d'Android varie considérablement selon le fabricant et la version du système d'exploitation, et certains combinés d'entreprise nécessitent des configurations de firmware spécifiques pour respecter les requêtes BTM de manière cohérente.
La triple pile en pratique
Les trois protocoles sont complémentaires et doivent être déployés ensemble pour un effet maximal. Le flux opérationnel est le suivant : le 802.11k fournit au client une liste organisée d'AP candidats, éliminant le besoin d'un balayage complet des canaux. Le 802.11v permet à l'infrastructure de diriger proactivement le client vers le candidat optimal en fonction de la charge et de la qualité du signal. Le 802.11r garantit que lorsque le client exécute la transition, l'authentification cryptographique s'achève en moins de 50 ms.
Déployé isolément, chaque protocole offre un avantage partiel. Déployés ensemble, ils offrent une expérience de roaming qui est effectivement transparente pour la couche application — ce qui est l'objectif opérationnel pour la voix, les outils de collaboration en temps réel et les applications d'entreprise mobiles.
Guide d'implémentation
Phase 1 : Conception RF et validation de la couverture
Aucune quantité de configuration de protocole ne compense une conception RF inadéquate. Avant d'activer les protocoles de roaming rapide, vérifiez que votre couche physique répond aux critères suivants.
Pour les déploiements de qualité vocale, concevez pour une force de signal reçue minimale de -65 dBm en bordure de cellule, avec un chevauchement de cellule minimal de 15 à 20 % entre les AP adjacents. Ce chevauchement est la fenêtre physique pendant laquelle l'événement de roaming se produit ; un chevauchement insuffisant signifie que le client est déjà dans un état de signal dégradé avant d'initier la transition. Utilisez un outil d'étude RF professionnel — et non un calculateur de planification de fournisseur — pour valider la couverture réelle, en particulier dans les environnements avec des matériaux de construction denses tels que le béton armé, les étagères métalliques ou les cloisons en verre courantes dans les lieux de commerce de détail et d' hôtellerie .
La gestion de la puissance de transmission est tout aussi critique. Les AP diffusant à puissance maximale créent de grandes cellules qui se chevauchent et encouragent un comportement de client « collant ». Activez le contrôle automatique de la puissance de transmission (TPC) sur votre contrôleur WLAN, en ciblant un RSSI en bordure de cellule de -65 à -67 dBm. Cela crée des cellules de taille appropriée qui encouragent un roaming opportun sans créer de lacunes de couverture.
Phase 2 : Configuration du SSID et du domaine de mobilité
Tous les AP participant au roaming rapide doivent partager le même identifiant de domaine de mobilité (MDID) — une valeur de deux octets configurée sur le contrôleur WLAN qui regroupe les AP dans un seul domaine de transition rapide. Les clients qui se sont authentifiés au sein d'un domaine de mobilité peuvent effectuer des transitions rapides entre n'importe quel AP de ce domaine sans se réauthentifier auprès du serveur RADIUS.
Pour les environnements avec plusieurs SSIDs (par exemple, un SSID d'entreprise, un SSID guest WiFi et un SSID IoT), configurez des domaines de mobilité séparés par SSID, le cas échéant. Le réseau invité ne doit pas partager un domaine de mobilité avec le réseau d'entreprise, à la fois pour l'isolation de sécurité et pour empêcher la distribution de matériel clé aux AP qui servent des clients non fiables.
Activez l'Adaptive 802.11r (également appelé FT en mode mixte) sur tous les SSIDs où la compatibilité avec les appareils hérités est une préoccupation. Cette configuration fait en sorte que l'AP inclut à la fois les éléments d'information RSN standard et FT dans ses trames de balise, permettant aux clients compatibles 802.11r d'utiliser la transition rapide tandis que les clients hérités reviennent à l'association standard. C'est le paramètre par défaut recommandé pour la plupart des déploiements d'entreprise.
Phase 3 : Direction du client et seuils de roaming
Configurez des seuils RSSI minimum sur votre contrôleur WLAN pour résoudre le problème du client « collant ». La plupart des plateformes d'entreprise prennent en charge un RSSI d'association minimum (empêchant les clients de s'associer en dessous d'un seuil, généralement -80 dBm) et un RSSI opérationnel minimum (déclenchant une requête BTM ou une dissociation lorsque le signal d'un client tombe en dessous d'un seuil, généralement -75 à -80 dBm pour les données, -70 dBm pour la voix).
Pour les SSIDs spécifiques à la VoIP, configurez des politiques QoS pour marquer le trafic vocal avec DSCP EF (Expedited Forwarding, DSCP 46) et assurez-vous que votre contrôleur WLAN le mappe à WMM AC_VO (Catégorie d'Accès Voix). Cela garantit que les paquets vocaux reçoivent une mise en file d'attente prioritaire au niveau radio de l'AP, réduisant la gigue pendant la brève période de charge accrue qui peut survenir lors d'un événement de roaming.
Activez le Band Steering pour encourager les clients bi-bande à s'associer sur la bande 5 GHz plutôt que 2,4 GHz. La portée plus courte de la bande 5 GHz crée naturellement des cellules plus petites, ce qui signifie des événements de roaming plus fréquents mais plus rapides — un meilleur résultat pour la qualité vocale que les grandes cellules sujettes aux interférences de la bande 2,4 GHz. Pour les environnements déployant du matériel Wi-Fi 6E ou Wi-Fi 7, la bande 6 GHz devrait être la bande principale pour la voix et les applications sensibles à la latence.
Phase 4 : Infrastructure 802.1X et RADIUS
Dans les déploiements 802.1X, assurez-vous que votre infrastructure RADIUS est dimensionnée pour la charge d'authentification. Même avec le 802.11r réduisant les événements de réauthentification pendant le roaming, l'authentification initiale et toute réauthentification complète (par exemple, après qu'un appareil se reconnecte après une mise en veille) doivent s'achever rapidement. Des temps de réponse RADIUS supérieurs à 100 ms auront un impact notable sur l'expérience utilisateur au moment de l'association.
Pour les déploiements à grande échelle, envisagez de déployer des serveurs RADIUS dans un cluster actif-actif avec mise en cache locale des données de session. La mise en cache PMK (OKC — Opportunistic Key Caching) est un mécanisme complémentaire au 802.11r qui met en cache le PMK au niveau de l'AP, permettant une réassociation rapide lorsqu'un client retourne à un AP précédemment visité sans nécessiter un échange 802.1X complet. OKC et 802.11r ne sont pas mutuellement exclusifs et devraient tous deux être activés.
Pour les environnements où la segmentation du réseau est une exigence de conformité — en particulier ceux soumis aux exigences PCI DSS pour les environnements de données de titulaires de carte ou aux exigences NHS DSPT dans le secteur de la santé — assurez-vous que les limites de votre domaine de mobilité s'alignent sur les limites de votre VLAN et de votre zone de sécurité. Reportez-vous au guide Bonnes pratiques de micro-segmentation pour les réseaux WiFi partagés pour des recommandations détaillées sur l'architecture VLAN et de segmentation.
Bonnes pratiques
Les recommandations suivantes, indépendantes des fournisseurs, représentent le consensus actuel de l'industrie pour les déploiements de roaming rapide en entreprise, alignées sur les normes IEEE 802.11 et les exigences de certification Wi-Fi Alliance.
Déployez la Triple Pile par défaut pour tout SSID critique pour la voix ou la mobilité. Les protocoles 802.11r, 802.11k et 802.11v sont pris en charge par tous les principaux fournisseurs de WLAN d'entreprise depuis 2015 et par les systèmes d'exploitation clients grand public (iOS, Android, Windows 10+, macOS) depuis 2017. Il n'y a plus de raison valable de laisser ces protocoles désactivés sur une infrastructure moderne.
Utilisez le 802.11r adaptatif universellement. Le risque d'incompatibilité des appareils hérités avec le 802.11r strict est réel, en particulier dans les environnements d'appareils mixtes. Le mode adaptatif élimine ce risque sans pénalité de performance pour les clients compatibles.
Validez les performances de roaming avec un analyseur de protocole, pas seulement un test de vitesse. Des outils tels que Wireshark avec un adaptateur de capture sans fil, ou des outils spécifiques aux fournisseurs comme Ekahau Sidekick, vous permettent de mesurer la latence réelle du transfert et d'identifier les échecs d'authentification qui seraient invisibles pour un test de connectivité standard. Visez un temps de transfert mesuré inférieur à 50 ms pour les déploiements vocaux.
Alignez vos seuils de roaming avec les SLA de vos applications. Un seuil de roaming de -70 dBm est approprié pour la voix. Un SSID de données uniquement peut tolérer un seuil de -75 dBm. Les appareils IoT avec de faibles exigences de mobilité peuvent ne pas nécessiter de pilotage client du tout. L'application d'un seuil unique à tous les SSID est une erreur de configuration courante.
Documentez les limites de votre domaine de mobilité et révisez-les après tout changement d'infrastructure. L'ajout d'un nouvel AP au mauvais domaine de mobilité, ou l'omission de l'ajouter, est une cause fréquente de défaillances de roaming inattendues dans les déploiements en expansion. Pour les environnements de transport tels que les aéroports et les gares où les changements d'infrastructure sont fréquents, cela est particulièrement important.
Dépannage et atténuation des risques
Mode de défaillance courant 1 : Les appareils hérités ne parviennent pas à s'associer après l'activation du 802.11r
Symptôme : Après l'activation du 802.11r sur un SSID, un sous-ensemble d'appareils — généralement des combinés Android plus anciens, des combinés VoIP hérités ou des scanners industriels — ne peuvent plus se connecter.
Cause première : Ces appareils n'incluent pas l'élément d'information FT RSN dans leurs requêtes d'association, ce qui indique qu'ils ne prennent pas en charge le 802.11r. En mode 802.11r strict, certaines implémentations d'AP rejettent les associations des clients non-FT.
Résolution : Passez au 802.11r adaptatif. Si votre fournisseur ne prend pas en charge le mode adaptatif, créez un SSID parallèle sans 802.11r pour les appareils hérités, et appliquez une attribution de SSID basée sur le type d'appareil via des attributs RADIUS ou un filtrage MAC OUI.
Mode de défaillance courant 2 : Les clients "collants" persistent malgré les requêtes BTM 802.11v
Symptôme : Les journaux du contrôleur WLAN montrent que des requêtes BTM sont envoyées aux clients, mais les clients ne se déplacent pas. Les utilisateurs de ces appareils signalent des performances médiocres.
Cause première : Le système d'exploitation client ignore les requêtes BTM. Ceci est courant avec certaines versions de firmware OEM Android et certaines configurations Windows 10.
Résolution : Activez Disassociation Imminent dans votre configuration de requête BTM. Cela définit un minuteur après lequel l'AP dissociera de force le client, le forçant à se réassocier à un meilleur AP. Utilisez cette option en dernier recours, car une dissociation forcée interrompra brièvement la connexion. Pour les appareils Windows, vérifiez que le service WLAN AutoConfig n'est pas configuré avec une préférence AP statique.
Mode de défaillance courant 3 : Boucles de roaming
Symptôme : Un client se déplace de manière répétée entre deux AP adjacents en succession rapide, provoquant des déconnexions brèves et répétées.
Cause première : La différence de RSSI entre les deux AP se situe dans la marge d'hystérésis, ce qui fait osciller le client. Cela est souvent dû à une puissance de transmission mal configurée entraînant un chevauchement excessif des cellules, ou par une obstruction physique créant un nul RF entre deux AP.
Résolution : Réduisez la puissance de transmission sur les AP affectés pour créer des limites de cellule plus distinctes. Augmentez le seuil d'hystérésis de roaming sur votre contrôleur WLAN (une marge d'hystérésis de 5 à 10 dBm est généralement recommandée). Effectuez une étude RF pour identifier toute obstruction physique ou surface réfléchissante causant des interférences multipath.
Atténuation des risques : Gestion du changement
Les modifications du protocole de fast roaming doivent être testées dans un environnement de laboratoire représentatif avant le déploiement en production. Créez un plan de retour arrière qui inclut la possibilité de restaurer les configurations SSID en 15 minutes. Dans les environnements soumis à des cadres de conformité tels que PCI DSS ou ISO 27001, documentez toutes les modifications de configuration WLAN dans votre système de gestion du changement et obtenez l'approbation de l'équipe de sécurité de l'information avant le déploiement. Les modifications des limites du domaine de mobilité ou de la configuration RADIUS doivent être traitées comme des changements significatifs avec des fenêtres de test appropriées.
ROI et impact commercial
Quantification du coût d'un mauvais roaming
L'analyse de rentabilisation pour l'investissement dans une infrastructure de fast roaming est simple lorsque le coût de l'échec est quantifié. Dans un hôtel de 300 chambres, si 10 % des clients subissent un appel Wi-Fi interrompu pendant leur séjour et que 5 % de ces clients laissent un avis négatif citant la connectivité, l'impact sur la réputation et les revenus est mesurable. Dans un centre de distribution où les opérateurs d'entrepôt utilisent des terminaux mobiles connectés au Wi-Fi pour les opérations de prélèvement et d'emballage, un délai de roaming de 500 ms multiplié par des milliers d'événements de scan par jour se traduit directement par une réduction du débit et une augmentation des coûts de main-d'œuvre.
Pour les opérateurs hôteliers , l'expérience Wi-Fi est désormais un facteur primordial dans les scores de satisfaction des clients. Les établissements qui investissent dans une infrastructure WLAN de qualité entreprise avec un fast roaming correctement configuré surpassent constamment leurs concurrents sur les métriques d'avis liées à la connectivité.
Mesure du succès
Établissez des métriques de référence avant de mettre en œuvre les optimisations de fast roaming, et mesurez-les après le déploiement. Les indicateurs clés de performance devraient inclure :
| KPI | Référence (Pré-optimisation) | Cible (Post-optimisation) |
|---|---|---|
| Latence moyenne de transfert de roaming | 500–1 200 ms | < 50 ms |
| Score MOS VoIP (Mean Opinion Score) | 2,5–3,0 | > 4,0 |
| Incidents de client « collant » par jour | 15–30 | < 5 |
| Tickets de support : connectivité WiFi | Nombre de référence | Réduction de 40 à 60 % |
| Score de satisfaction WiFi client/personnel | NPS de référence | +15–25 points |
Pour les organisations utilisant des plateformes WiFi Analytics , les données d'événements de roaming et les métriques d'association client peuvent être affichées en temps réel, permettant l'identification proactive des zones problématiques avant qu'elles ne génèrent des tickets de support. La capacité à corréler les événements d'échec de roaming avec des emplacements d'AP spécifiques, l'heure de la journée et les types d'appareils est un avantage opérationnel significatif par rapport au dépannage réactif.
Coût total de possession
Le coût incrémental de l'activation des protocoles de fast roaming sur une infrastructure de qualité entreprise existante est pratiquement nul — il s'agit de modifications de configuration logicielle. L'investissement réside dans l'étude RF, le travail de validation de l'analyseur de protocole et le temps d'ingénierie pour configurer et tester. Pour un déploiement d'entreprise typique de 50 AP, prévoyez 3 à 5 jours de temps d'ingénieur sans fil senior pour un engagement complet d'optimisation du fast roaming. La période de récupération du ROI, mesurée par rapport à la réduction de la charge du support technique et à l'amélioration de l'efficacité opérationnelle, est généralement inférieure à six mois.
Définitions clés
Fast BSS Transition (FT / 802.11r)
An IEEE 802.11 amendment that pre-distributes cryptographic key material to neighbouring access points within a Mobility Domain, allowing a client device to complete a roaming handoff in under 50ms by bypassing the full 802.1X RADIUS re-authentication process.
Essential for any deployment supporting VoIP, Wi-Fi calling, or real-time collaboration applications. Without 802.11r, 802.1X re-authentication during a roam can take 500ms–1,200ms, which is sufficient to drop a voice call.
Mobility Domain
A logical grouping of access points, identified by a two-byte Mobility Domain Identifier (MDID), within which a client device can perform fast BSS transitions without re-authenticating with the RADIUS server. All APs sharing a MDID must be managed by the same WLAN controller or mobility anchor.
Network architects must define Mobility Domain boundaries carefully. A Mobility Domain should align with a single security zone — do not span guest and corporate SSIDs across the same Mobility Domain.
Neighbour Report (802.11k)
A structured data frame provided by an access point to a client device, listing nearby BSSIDs, their operating channels, and capability information. Enables the client to perform a targeted scan of only the listed channels rather than a full channel sweep, reducing AP discovery time by up to 60%.
Neighbour Reports are the 802.11k feature most directly relevant to roaming performance. They are typically requested by the client after association and can also be sent unsolicited by the AP when the client's RSSI begins to degrade.
BSS Transition Management Request (802.11v)
A management frame sent by an access point or WLAN controller to a client device, suggesting or directing the client to transition to a specified target AP. Can include a list of candidate APs ranked by preference, and optionally a Disassociation Imminent flag that sets a timer after which the AP will forcibly disassociate the client.
The primary mechanism for AP-directed load balancing in enterprise WLANs. Effectiveness depends on client OS support — iOS responds reliably; Android behaviour varies by manufacturer and firmware version.
Sticky Client
A client device that remains associated with a distant or degraded access point rather than roaming to a closer, stronger AP. Caused by conservative client-side roaming algorithms and excessively large AP cells created by high transmit power.
One of the most common causes of poor Wi-Fi performance in enterprise environments. Addressed through a combination of transmit power reduction, minimum RSSI thresholds, and 802.11v BTM Requests.
Opportunistic Key Caching (OKC)
A mechanism complementary to 802.11r that caches the Pairwise Master Key (PMK) at the access point level. When a client returns to a previously visited AP, it can re-associate using the cached PMK without a full 802.1X exchange. Unlike 802.11r, OKC does not pre-distribute keys to neighbouring APs.
Useful in environments where clients frequently return to the same APs (e.g., retail store staff following regular routes). Should be enabled alongside 802.11r, not as a replacement for it.
RSSI Threshold
A configurable signal strength value (expressed in dBm) at which the WLAN controller takes action — either preventing new associations below the threshold (minimum association RSSI) or triggering a BTM Request or disassociation for existing clients (minimum operational RSSI).
Critical for addressing sticky client behaviour. For voice deployments, a minimum operational RSSI of -70 dBm is the standard recommendation. Setting this threshold too aggressively (e.g., -60 dBm) can cause excessive roaming events; too conservatively (e.g., -80 dBm) allows clients to degrade before roaming.
WMM AC_VO (Wi-Fi Multimedia Access Category Voice)
A QoS access category defined in the IEEE 802.11e amendment and Wi-Fi Alliance WMM certification that provides the highest priority queuing for voice traffic at the AP radio level. Maps to DSCP EF (Expedited Forwarding, DSCP 46) in the wired network.
Must be enabled on any SSID carrying VoIP traffic. Without WMM AC_VO, voice packets compete equally with data traffic at the AP radio queue, resulting in jitter and packet loss during periods of high network utilisation — including the brief period of increased overhead during a roaming event.
Adaptive 802.11r (Mixed-Mode FT)
A vendor-specific implementation of 802.11r that includes both standard RSN and FT Information Elements in AP beacon frames, allowing 802.11r-capable clients to use fast transition while legacy clients that do not support 802.11r can still associate using standard authentication.
The recommended default configuration for any enterprise SSID with a mixed device fleet. Eliminates the risk of legacy device incompatibility without any performance penalty for capable clients.
Exemples concrets
A 400-room full-service hotel has deployed a new WLAN using 802.11ax (Wi-Fi 6) APs throughout all guest floors, conference facilities, and public areas. The hotel uses a cloud-managed WLAN controller. Staff use Wi-Fi calling on iOS and Android devices for internal communications, and guests frequently report dropped calls when moving between the lobby and restaurant areas. The existing SSID configuration has WPA3-Personal for guests and WPA2-Enterprise with 802.1X for staff. Neither SSID has fast roaming protocols enabled. How should the network architect approach this?
Step 1 — RF Validation: Before any protocol changes, conduct a post-installation RF survey to validate coverage. Target -65 dBm at all cell edges with 15–20% overlap. Verify that transmit power is not set to maximum — in a dense hotel environment, this almost certainly creates excessively large cells and sticky client conditions. Enable TPC targeting -67 dBm cell edge.
Step 2 — Staff SSID (WPA2-Enterprise / 802.1X): This is the highest priority. Enable 802.11r in Adaptive (Mixed) mode on the staff SSID. Configure the Mobility Domain to include all APs across the property. Enable 802.11k Neighbour Reports and 802.11v BTM Requests. Set a minimum operational RSSI of -70 dBm for voice, with Disassociation Imminent enabled at -75 dBm. Verify RADIUS server response times are under 100ms.
Step 3 — Guest SSID (WPA3-Personal): WPA3 with SAE (Simultaneous Authentication of Equals) supports fast transition via SAE-FT. Enable 802.11r Adaptive, 802.11k, and 802.11v on the guest SSID. Note that WPA3-Personal with 802.11r requires SAE-FT support on both the AP and client — verify this is supported on your cloud controller platform.
Step 4 — QoS: Configure DSCP EF marking for voice traffic on the staff SSID and ensure WMM AC_VO prioritisation is enabled. This is critical for maintaining voice quality during the brief transition period.
Step 5 — Validation: Use a Wi-Fi protocol analyser to capture a roaming event on both iOS and Android staff devices. Measure the actual handoff time. Target under 50ms. If handoff times are 50–150ms, investigate RADIUS latency. If over 150ms, check that 802.11r is actually being used (look for FT Authentication frames in the capture).
A large retail chain operates 120 stores, each with 8–12 APs managed by a centralised cloud WLAN controller. Each store uses a single SSID for both staff mobile devices (modern Android handsets running a warehouse management application) and legacy barcode scanners (Zebra TC51 series, approximately 40% of the device fleet, running Android 8.1). The WMS application is latency-sensitive but not voice. The scanners frequently lose connectivity when staff move between the stockroom and the shop floor, causing WMS session timeouts. How should fast roaming be configured?
Step 1 — Device Audit: Confirm 802.11r support on the Zebra TC51 running Android 8.1. Zebra's LifeGuard security update for Android 8.1 includes 802.11r support, but it must be explicitly enabled via Zebra's StageNow MDM tool or via the WLAN configuration profile. Do not assume it is enabled by default.
Step 2 — SSID Strategy: Given the mixed device fleet, enable Adaptive 802.11r on the existing SSID. This protects any devices that do not support 802.11r while enabling fast transition for capable devices. If the Zebra TC51 devices are confirmed to support 802.11r after the firmware audit, they will benefit from fast transition automatically.
Step 3 — Roaming Thresholds: For a WMS application (not voice), a roaming threshold of -72 to -75 dBm is appropriate. Set a minimum association RSSI of -80 dBm to prevent devices from associating with distant APs. Enable 802.11v BTM Requests to steer devices proactively.
Step 4 — Channel Planning: In a retail environment with metal shelving, RF propagation is highly directional and attenuated. Ensure that the stockroom-to-shop-floor transition area has adequate AP coverage with proper overlap. A common mistake is placing APs only in the sales floor and relying on signal bleed into the stockroom — this creates exactly the coverage gap that causes the observed session timeouts.
Step 5 — OKC: Enable Opportunistic Key Caching as a complement to 802.11r. If a device returns to a previously visited AP (common in store environments where staff follow regular routes), OKC allows fast re-association without a full 802.1X exchange, even for devices that do not support 802.11r.
Step 6 — WMS Session Timeout: Review the WMS application's TCP keepalive and session timeout settings. Even with fast roaming, a brief connectivity interruption during a roaming event can cause a TCP session to time out if the application's timeout is set too aggressively. Work with the WMS vendor to increase the session timeout to at least 30 seconds.
Questions d'entraînement
Q1. A conference centre hosts events with up to 5,000 attendees. During a recent large event, the event coordinator reported that staff using Wi-Fi calling on iOS devices experienced dropped calls when moving between the main hall and the breakout rooms. The WLAN uses WPA2-Enterprise with 802.1X. 802.11r is enabled in strict mode. Post-event logs show that 23% of client associations during the event were on 2.4 GHz. What are the three most likely contributing factors to the dropped calls, and what specific changes would you make?
Conseil : Consider the interaction between strict 802.11r mode, 2.4 GHz band characteristics, and high-density event environments. Think about what happens to cell boundaries when hundreds of devices are competing for airtime.
Voir la réponse type
The three most likely contributing factors are: (1) Strict 802.11r mode causing legacy device failures — if any iOS devices are running older firmware that does not fully support FT, strict mode may cause association failures or fallback to slower authentication paths. Switch to Adaptive 802.11r immediately. (2) 23% of clients on 2.4 GHz — in a high-density event environment, 2.4 GHz cells are large and heavily congested. The limited non-overlapping channels (1, 6, 11) mean significant co-channel interference, which degrades RSSI readings and makes roaming decisions unreliable. Enable aggressive band steering to push capable clients to 5 GHz, and consider disabling 2.4 GHz radios entirely for event SSIDs if all staff devices support 5 GHz. (3) Cell boundary distortion under high load — in a 5,000-person event, the RF environment changes dramatically compared to an empty venue. High client density increases airtime utilisation and interference, effectively shrinking usable cell sizes. The roaming thresholds configured during the initial deployment may be too conservative for event conditions. Reduce AP transmit power to create tighter cells, and lower the minimum operational RSSI threshold to -68 dBm for event SSIDs to encourage earlier roaming. Additionally, verify that QoS with WMM AC_VO is enabled for the staff SSID to protect voice traffic from data congestion.
Q2. You are advising a 600-bed NHS hospital trust on upgrading their WLAN to support clinical mobility — nurses and doctors carrying iOS and Android devices running a clinical communications platform (similar to Vocera or Ascom). The trust's information security team has mandated that all clinical devices must use 802.1X with certificate-based EAP-TLS authentication. The trust also has a significant fleet of legacy nurse call handsets that do not support 802.11r. How do you architect the SSID and fast roaming configuration to meet both the clinical performance requirements and the security mandate?
Conseil : Consider how to segment the device fleet across SSIDs while maintaining security compliance. Think about the RADIUS infrastructure requirements for EAP-TLS at scale, and how Mobility Domain boundaries interact with VLAN segmentation.
Voir la réponse type
The correct architecture separates the device fleet into two SSIDs on the same physical infrastructure: (1) Clinical SSID (WPA2-Enterprise / EAP-TLS): For all modern iOS and Android clinical devices. Enable Adaptive 802.11r with FT-EAP, 802.11k Neighbour Reports, and 802.11v BTM Requests. Configure a dedicated Mobility Domain covering all clinical floor APs. Set minimum operational RSSI at -70 dBm with Disassociation Imminent at -75 dBm. Ensure the RADIUS infrastructure (Microsoft NPS or FreeRADIUS in an active-active cluster) is sized for EAP-TLS certificate validation — this is more computationally intensive than PEAP-MSCHAPv2. Target RADIUS response times under 80ms. (2) Legacy Nurse Call SSID: For legacy handsets that do not support 802.11r. Use WPA2-Personal with a complex PSK (or WPA2-Enterprise with PEAP if the handsets support it), with 802.11r disabled. Enable OKC to provide some key caching benefit. Keep this SSID on a separate VLAN from the clinical SSID. The Mobility Domain for the clinical SSID must not include APs serving the legacy SSID — this is both a security and a compatibility requirement. From a compliance perspective, this architecture satisfies NHS DSPT requirements by maintaining network segmentation between clinical and non-clinical traffic, and aligns with the principle of least privilege by ensuring legacy devices cannot access clinical data VLANs. Refer to the micro-segmentation guidance for detailed VLAN architecture recommendations.
Q3. A retail chain's IT director reports that since upgrading their WLAN controller firmware last month, warehouse staff using Android-based mobile terminals are experiencing 2–3 second connectivity gaps when crossing between the warehouse and the dispatch bay. Before the firmware upgrade, roaming was seamless. The WLAN configuration has not changed. 802.11r Adaptive, 802.11k, and 802.11v are all enabled. What is your diagnostic approach?
Conseil : The firmware upgrade is the most significant recent change. Consider what aspects of the WLAN controller firmware could affect roaming behaviour without a configuration change. Think about Mobility Domain key distribution and PMK-R1 pre-distribution mechanisms.
Voir la réponse type
The firmware upgrade is almost certainly the root cause, even though the configuration has not changed. The diagnostic approach is: (1) Check vendor release notes for the firmware version applied, specifically looking for changes to 802.11r key distribution, Mobility Domain handling, or PMK-R1 pre-distribution behaviour. Many firmware updates include changes to fast roaming implementation that are not prominently documented. (2) Capture a roaming event using a Wi-Fi protocol analyser. Determine whether FT Authentication frames are present in the capture. If they are absent, the Android devices are falling back to full 802.1X re-authentication — this would explain the 2–3 second gap. (3) Check the Mobility Domain configuration in the controller post-upgrade. Some firmware updates reset MDID values or change the default Mobility Domain scope. Verify that all APs in the warehouse and dispatch bay are in the same Mobility Domain. (4) Test with a known-good device: If an iOS device roams seamlessly between the same APs, the issue is Android-specific. Check whether the firmware update changed the BTM Request format or the Neighbour Report structure in a way that is incompatible with the Android OEM firmware on the mobile terminals. (5) Rollback test: If the above steps do not identify the cause, arrange a maintenance window to roll back the firmware to the previous version and test. If roaming is restored, raise a support case with the WLAN vendor with the protocol capture as evidence.