Événements radar DFS sur Cisco Meraki, HPE Aruba et Ruckus : liste de contrôle de diagnostic pour les changements de canal

Pour diagnostiquer et résoudre les événements de radar DFS sur les réseaux WiFi Cisco Meraki, HPE Aruba ou Ruckus fonctionnant sous la norme IEEE 802.11h, analysez les journaux de votre contrôleur à la recherche de détections de radar. Une fois détecté, le point d'accès doit libérer le canal 5 GHz dans les 10 secondes et ne plus l'utiliser pendant 30 minutes.

À quoi ressemble un événement de radar DFS sur votre réseau 5 GHz ?

La sélection dynamique de fréquence (DFS) permet au WiFi de partager des parties de la bande 5 GHz avec les radars. La norme IEEE 802.11h définit ce mécanisme. Les organismes de réglementation fixent les délais : la FCC en vertu de la norme 47 CFR Part 15.407 aux États-Unis, et l'ETSI EN 301 893 dans toute l'Europe. Dans les régions ETSI, les canaux 52 à 64 et 100 à 140 sont des canaux DFS. Les règles de la FCC y ajoutent le canal 144.

Lorsqu'un point d'accès (AP) détecte un radar, la séquence est fixe :

1. Détection. La radio associe un motif d'impulsion sur son canal de fonctionnement à une signature radar.
2. Annonce de changement de canal (CSA). L'AP ajoute un élément CSA à ses balises (beacons), indiquant aux clients le nouveau canal et le compte à rebours avant le déplacement.
3. Changement de canal. La radio doit cesser d'émettre sur ce canal dans les 10 secondes.
4. Période de non-occupation. Le canal est interdit d'accès pendant au moins 30 minutes.
5. Vérification de la disponibilité du canal (CAC). Avant qu'un canal DFS ne soit mis en service, la radio écoute pendant au moins 60 secondes. Dans les régions ETSI, les canaux 120, 124 et 128 (5600 - 5650 MHz) sont partagés avec les radars météorologiques, et la vérification y dure 10 minutes.

Ce que les utilisateurs invités constatent dépend de leurs appareils. Les clients qui respectent la CSA suivent l'AP après une courte pause. Les clients qui l'ignorent perdent la connexion, effectuent un nouveau balayage et se réassocient, souvent sur la bande 2.4 GHz ou sur un AP voisin. Si l'AP se déplace vers un canal DFS qui n'a pas encore passé sa vérification, la radio 5 GHz peut rester silencieuse pendant une minute ou plus.

Le comportement type à surveiller :

• Tous les clients connectés à un AP, ou à un groupe d'AP voisins, se déconnectent au même moment.
• L'AP revient sur un canal différent, souvent un canal non DFS situé entre 36 et 48.
• Le changement se produit en dehors de votre fenêtre d'optimisation des canaux planifiée.
• Les mêmes AP répètent ce comportement, parfois à des heures similaires de la journée.
• La charge sur la bande 2.4 GHz augmente brusquement alors que les clients 5 GHz disparaissent.

Qu'est-ce qui cause généralement les changements de canaux DFS ?

Radars réels

Les radars météorologiques dans la plage 5600 - 5650 MHz sont une source réelle courante en Europe. Aux États-Unis, le radar météorologique Doppler terminal (TDWR) des grands aéroports utilise la même plage. La ligne de mire importe plus que la distance. Les AP extérieurs, les étages supérieurs et les façades vitrées détectent des radars que les AP du rez-de-chaussée ne verront jamais.

La simple proximité physique ne permet rien de prédire. De nombreux radars de surveillance aéroportuaire et de navigation maritime fonctionnent sur d'autres bandes, bien en dehors de la bande 5 GHz. Un site situé à côté d'un port peut ne jamais enregistrer le moindre événement radar. Votre journal d'événements constitue la seule preuve, pas la carte géographique.

Fausses alertes

Une fausse alerte DFS est une détection de radar alors qu'aucun radar n'est présent. La radio interprète une impulsion d'énergie comme un motif d'impulsion radar. Les déclencheurs typiques comprennent :

• les interférences pulsées non-WiFi provenant de liaisons vidéo sans fil ou d'équipements défectueux ;
• les transmissions puissantes d'un AP proche ou d'une liaison point à point sur un canal adjacent ;
• les défauts radio ou de firmware, que les constructeurs corrigent dans les mises à jour logicielles.

L'indice clé est l'isolement. Un AP enregistre des événements répétés sur différents canaux alors que ses voisins ayant la même visibilité sur l'environnement n'en enregistrent aucun.

Les canaux larges augmentent l'exposition aux détections réelles et fausses. Un canal de 80 MHz couvre quatre sous-canaux de 20 MHz, et une détection sur l'un d'eux déplace l'ensemble du canal.

Changements hors radar d'apparence similaire

Les planificateurs de canaux déplacent les radios en fonction des interférences et de la charge. Meraki Auto RF, Aruba ARM et AirMatch, ainsi que Ruckus ChannelFly et BackgroundScanning changent tous de canal sans intervention radar. Les redémarrages d'AP et les variations de puissance déconnectent également les clients. Ces pannes nécessitent des solutions différentes - confirmez donc la cause avant d'exclure quoi que ce soit.

Comment déterminer si un radar est à l'origine de l'interruption ?

Suivez cette liste de contrôle dans l'ordre :

1. Ciblez la plainte. Obtenez l'heure exacte à la minute près ainsi que la salle, l'étage ou la zone.
2. Extrayez les événements de changement de canal pour les AP couvrant cette zone, une heure avant et après.
3. Lisez le motif enregistré. Un motif lié au radar ou au DFS confirme la cause. Un motif d'interférence, de bruit ou d'optimisation l'exclut.
4. Notez le canal. Des événements regroupés sur les canaux 120, 124 et 128 indiquent un radar météorologique.
5. Comptez les AP affectés. Plusieurs voisins touchés simultanément suggèrent un vrai radar. Un seul AP isolé suggère un faux positif.
6. Recherchez un modèle hebdomadaire. Des répétitions régulières suggèrent un radar avec un calendrier ou un balayage fixe.
7. Vérifiez la largeur du canal. Les événements qui apparaissent uniquement sur des canaux de 80 ou 160 MHz font de la largeur une partie du problème.
8. Lisez les notes de version du firmware pour identifier les correctifs de détection DFS sur votre modèle d'AP.

Si vous utilisez Purple Guest WiFi, les volumes de connexion par site vous permettent d'effectuer une double vérification. Une baisse soudaine sur un site qui coïncide avec un événement radar confirme l'impact sur les visiteurs.

Comment corriger les événements DFS sur Meraki, Aruba et Ruckus ?

Constructeur	Où apparaissent les événements radar	Planificateur de canaux	Où restreindre les canaux
Cisco Meraki	Journal des événements sans fil filtré pour les événements DFS ; page du spectre RF par AP	Auto RF	Liste de canaux du profil RF, appliquée aux AP affectés
HPE Aruba	Historique ARM sur le contrôleur ou le cluster Instant ; événements AirMatch dans AOS 8 et Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Liste des canaux autorisés dans le profil radio pour un groupe d'AP
Ruckus	Événements et alarmes SmartZone pour la détection radar	ChannelFly ou BackgroundScanning	Paramètres radio pour une zone dédiée ou un groupe d'AP

Cisco Meraki

Meraki enregistre la détection de radar dans le journal des événements sous forme d'événements DFS, en nommant l'AP et le canal. Filtrez par type d'événement et selon la période de réclamation. La page du spectre RF pour chaque AP montre l'utilisation et les interférences, ce qui permet de distinguer le radar de la congestion. Pour éviter que cela ne se reproduise, supprimez les canaux problématiques de la fonction Auto RF dans un profil RF. Appliquez ce profil uniquement aux AP concernés. La documentation DFS propre à Meraki décrit les étapes exactes.

HPE Aruba

L'historique ARM répertorie chaque changement de canal avec son motif, et la détection de radar apparaît comme une cause distincte. AirMatch élabore le plan de canaux de manière centralisée, mais une détection de radar force l'AP à changer immédiatement. Un changement imprévu en milieu d'après-midi sur un canal DFS est donc un indice fort. Restreignez les canaux dans le profil radio pour un groupe d'AP contenant uniquement les AP concernés. Si les invités sont renvoyés vers une page de connexion après s'être reconnectés, il s'agit d'un problème distinct : consultez le HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

SmartZone génère un événement lorsqu'un AP détecte un radar, en nommant l'AP et le canal. Vérifiez les événements et les alarmes pour la période concernée, puis comparez-les avec l'activité ChannelFly ou BackgroundScanning. Un changement de canal DFS Ruckus sans événement de radar associé est une décision du planificateur, et non du DFS. Supprimez les canaux problématiques dans les paramètres radio d'une zone dédiée ou d'un groupe d'AP.

Sur les trois plateformes, modifiez uniquement les AP concernés. Une exclusion à l'échelle du site réduit la capacité sur des AP qui n'ont jamais détecté de radar.

Faut-il désactiver les canaux DFS à proximité d'un aéroport, d'un port ou d'un radar météo ?

Pas par défaut. Exclure tous les canaux DFS dans une région ETSI ne laisse que quatre canaux de 20 MHz : 36, 40, 44 et 48. Les règles de la FCC en laissent neuf, en ajoutant les canaux 149 à 165. Dans un lieu à forte densité, quatre canaux obligent les AP à partager le temps d'antenne et ralentissent chaque client. Laissez les journaux décider.

Ce que vos journaux affichent	Cause probable	Recommandation	Canaux 20 MHz restants (ETSI / FCC)
Événements sur plusieurs AP voisins, regroupés sur 120 - 128	Radar météo	Exclure 120, 124 et 128 sur les AP concernés	16 / 22
Événements sur la plupart des canaux DFS sur plusieurs AP, quotidiennement	Radar puissant à proximité	Exclure le DFS uniquement sur les AP concernés ; le conserver ailleurs	4 / 9 sur les AP concernés
Événements répétés sur un seul AP, canaux variés	Faux positif	Mettre à jour le firmware, tester ou remplacer la radio, conserver le DFS	19 / 25
Événements uniquement sur les canaux de 80 ou 160 MHz	Exposition liée à la largeur de bande	Passer à 40 ou 20 MHz, conserver le DFS	19 / 25
Changements de canaux mais aucune entrée radar	Planificateur ou interférences	Corriger les interférences et la puissance, conserver le DFS	19 / 25

Scénario pratique : un hôtel près d'un aéroport régional

Un hôtel de 180 chambres dans une région ETSI était situé à 3 km d'un aérodrome équipé d'un radar météorologique. Les clients des étages supérieurs orientés à l'ouest signalaient des déconnexions la plupart des après-midi. Le journal d'événements a révélé 63 détections de radars en une semaine sur 11 des 46 AP, toutes sur les canaux 120 à 128. L'équipe a déplacé ces 11 AP vers un profil excluant les canaux météo et a configuré une largeur de bande de 40 MHz. Au cours des quatre semaines suivantes, l'hôtel a enregistré zéro événement radar. Les plaintes liées au WiFi à la réception sont passées de 14 à deux par semaine. Les 35 autres AP ont conservé tous les canaux DFS. Pour en savoir plus sur les déploiements hôteliers, consultez Hôtels.

Cas pratique : une chaîne de magasins avec un AP perturbateur

Une chaîne de 120 magasins de détail a constaté qu'un de ses points de vente enregistrait 30 événements radar en deux semaines sur les canaux 52, 100 et 116. Les AP voisins du même magasin n'en enregistraient aucun, ce qui laissait supposer un faux positif. Les notes de version du modèle d'AP mentionnant un correctif de détection DFS, l'équipe a mis à jour le firmware. Les événements ayant persisté, l'AP a été remplacé sous garantie. Les détections de radars dans le magasin sont tombées à zéro et les clients ont cessé de perdre leur connexion au niveau des caisses. Le reste du parc a conservé l'intégralité des 19 canaux. Consultez Retail pour l'accès invité multi-sites.

Cas pratique : des bureaux municipaux à côté d'un port

L'équipe informatique d'une municipalité prévoyait de désactiver le DFS dans des bureaux situés à côté d'un port de commerce. Trente jours de journaux n'ont révélé aucun événement radar. Les changements de canaux provenaient d'une réaction du planificateur au réseau d'un locataire voisin. L'équipe a conservé le DFS, réduit la puissance de transmission et corrigé le plan de fréquences. Les rapports hebdomadaires de déconnexion sont passés de neuf à un.

Comment éviter que les événements DFS ne perturbent à nouveau vos clients ?

• Utilisez des canaux de 20 ou 40 MHz dans les espaces denses. Des canaux plus étroits réduisent l'exposition et facilitent la réutilisation des fréquences.
• Excluez les canaux météo de manière ciblée uniquement sur les AP concernés, là où les détections se concentrent sur les canaux 120 à 128.
• Gardez vos firmwares à jour et lisez les correctifs DFS dans chaque note de version.
• Examinez les événements DFS mensuellement et configurez des alertes pour tout AP enregistrant plus de quelques détections par semaine.
• Planifiez le passage au 6GHz. La bande 6GHz n'est soumise à aucune obligation DFS, ce qui permet aux clients WiFi 6E et WiFi 7 d'éviter totalement les changements de canaux liés aux radars.
• Séparez la gestion radio de l'accès invité. Purple fonctionne comme une surcouche cloud indépendante du matériel (hardware-agnostic) compatible avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Votre contrôleur gère le plan de fréquences, et Purple gère la connexion des invités. Purple a traité 440 millions de connexions à travers plus de 80 000 sites actifs en 2024 (données Purple).

Questions fréquentes

Est-ce que Purple Guest WiFi fonctionne sur nos points d'accès existants Meraki, Aruba ou Ruckus ?

Oui. Purple Guest WiFi est une surcouche cloud indépendante du matériel (hardware-agnostic) qui fonctionne sur Cisco Meraki, HPE Aruba et Ruckus, ainsi que sur Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous conservez vos points d'accès, vos contrôleurs et votre configuration radio. Purple ajoute par-dessus la connexion invité, les consentements explicites et la collecte de données de première main. Aucun remplacement de matériel n'est nécessaire, et vos paramètres DFS restent sous votre contrôle.

Est-ce que Purple va modifier nos paramètres DFS ou de canaux ?

Non. Purple ne définit pas les canaux radio, la largeur de canal ou la puissance de transmission. Ces éléments restent gérés par Meraki Auto RF, Aruba ARM ou AirMatch, et Ruckus ChannelFly ou BackgroundScanning. Purple gère l'authentification des invités et la capture de données au-dessus de la couche radio. Cette séparation vous permet de résoudre un problème DFS dans votre tableau de bord fournisseur sans affecter l'expérience de connexion des invités, et de modifier les paramètres de connexion sans toucher à la RF.

Est-il conforme de désactiver les canaux DFS ?

Oui. Les normes ETSI EN 301 893 et FCC Part 15.407 imposent la détection des radars sur tous les canaux DFS utilisés. Aucune d'elles ne vous oblige à utiliser les canaux DFS. Les exclure est donc toujours conforme. Ce qu'il ne faut jamais faire, c'est exploiter un canal DFS avec la détection désactivée. Le véritable coût de l'exclusion réside dans la capacité : dans les régions ETSI, la suppression de tous les canaux DFS ne laisse que quatre canaux de 20 MHz au lieu de 19.

Devons-nous acheter de nouveaux points d'accès pour éviter les problèmes DFS ?

Pas nécessairement. La plupart des problèmes DFS se résolvent par la configuration : exclusion des canaux météo sur les points d'accès concernés, réduction de la largeur de canal ou mise à jour du firmware. Le remplacement d'un équipement est judicieux lorsqu'une radio continue de générer de faux positifs après une mise à jour du firmware, ou lorsque vous ajoutez de la capacité en 6GHz. La bande 6GHz n'étant pas soumise aux exigences DFS, les points d'accès WiFi 6E et WiFi 7 éliminent les changements de canal liés aux radars pour les clients compatibles.

L'exclusion des canaux DFS nuit-elle au WiFi invité dans un lieu très fréquenté ?

Oui, si vous les excluez sur l'ensemble du site. Dans une région ETSI, quatre canaux de 20 MHz ne permettent pas de séparer correctement des dizaines de points d'accès dans un stade, un centre de conférence ou un grand hôtel. Les points d'accès finissent par partager le temps d'antenne et le débit chute pour chaque invité. N'excluez les canaux que sur les points d'accès qui signalent des détections de radars, et conservez le DFS partout ailleurs. Cette approche permet de contenir le problème sans sacrifier la capacité.

Les règles DFS diffèrent-elles entre le Royaume-Uni, l'Europe et les États-Unis ?

Oui. Le Royaume-Uni et l'Union Européenne suivent la norme ETSI EN 301 893, qui applique le DFS aux canaux 52 à 64 et 100 à 140. Elle impose également une vérification de disponibilité de 10 minutes sur les canaux météo 120, 124 et 128. Les États-Unis suivent la réglementation FCC Part 15.407, qui ajoute le canal 144 et laisse neuf canaux non-DFS. Les deux réglementations exigent au moins 30 minutes de non-occupation après une détection.

Un MSP peut-il diagnostiquer les événements DFS sur un parc multi-constructeurs ?

Oui, mais les événements liés aux radars restent visibles dans les outils propres à chaque constructeur : le journal d'événements Meraki, l'historique Aruba ARM ou les événements AirMatch, et les événements et alarmes SmartZone. Un MSP doit standardiser la liste de contrôle plutôt que l'outil, et enregistrer l'heure, le canal, le nombre de points d'accès concernés et la cause de chaque incident. Purple vous offre une plateforme unique pour l'accès invité sur l'ensemble de ces constructeurs, tandis que le diagnostic RF s'effectue dans chaque contrôleur.