DFS Radar-Ereignisse auf Cisco Meraki, HPE Aruba und Ruckus: Eine Diagnose-Checkliste für Kanalwechsel

Um DFS-Radarereignisse in Cisco Meraki, HPE Aruba oder Ruckus WiFi-Netzwerken zu diagnostizieren und zu beheben, die unter dem IEEE 802.11h-Standard betrieben werden, analysieren Sie Ihre Controller-Protokolle auf Radarsignaturen. Sobald ein Radar erkannt wird, muss der Access Point den 5GHz-Kanal innerhalb von 10 Sekunden verlassen und für 30 Minuten meiden.

Wie sieht ein DFS-Radarereignis auf Ihrem 5GHz-Netzwerk aus?

Dynamic Frequency Selection (DFS) ermöglicht es WiFi-Netzwerken, Teile des 5GHz-Bands mit Radarsystemen zu teilen. Der Standard IEEE 802.11h definiert diesen Mechanismus. Die Regulierungsbehörden legen die Zeitvorgaben fest: die FCC unter 47 CFR Part 15.407 in den USA und ETSI EN 301 893 in Europa. In ETSI-Regionen sind die Kanäle 52 bis 64 und 100 to 140 DFS-Kanäle. Die FCC-Regeln fügen Kanal 144 hinzu.

Wenn ein Access Point (AP) ein Radar erkennt, ist der Ablauf fest vorgegeben:

1. Erkennung. Das Funkmodul gleicht ein Impulsmuster auf seinem Betriebskanal mit einer Radarsignatur ab.
2. Kanalwechsel-Ankündigung (CSA). Der AP fügt seinen Beacons ein CSA-Element hinzu, das den Clients den neuen Kanal und den Countdown bis zum Wechsel mitteilt.
3. Kanalwechsel. Das Funkmodul muss die Übertragung auf diesem Kanal innerhalb von 10 Sekunden einstellen.
4. Sperrzeit (Non-occupancy period). Der Kanal ist für mindestens 30 Minuten gesperrt.
5. Kanalverfügbarkeitsprüfung (CAC). Bevor ein DFS-Kanal in Betrieb geht, lauscht das Funkmodul mindestens 60 Sekunden lang. In ETSI-Regionen werden die Kanäle 120, 124 und 128 (5600 - 5650 MHz) gemeinsam mit Wetterradaren genutzt, weshalb die Prüfung dort 10 Minuten dauert.

Was Gäste erleben, hängt von ihren Geräten ab. Clients, die das CSA-Signal berücksichtigen, folgen dem AP nach einer kurzen Pause. Clients, die es ignorieren, verlieren die Verbindung, scannen erneut und verbinden sich neu - oft im 2.4GHz-Band oder mit einem benachbarten AP. Wenn der AP auf einen DFS-Kanal wechselt, der seine Prüfung noch nicht bestanden hat, kann das 5GHz-Funkmodul für eine Minute oder länger stumm bleiben.

Das typische Muster, auf das Sie achten sollten:

• Alle Clients an einem AP oder an einer Gruppe benachbarter APs verlieren im selben Moment die Verbindung.
• Der AP kehrt auf einem anderen Kanal zurück, oft einem Nicht-DFS-Kanal zwischen 36 und 48.
• Die Änderung erfolgt außerhalb Ihres geplanten Fensters für die Kanaloptimierung.
• Dieselben APs wiederholen das Muster, manchmal zu ähnlichen Tageszeiten.
• Die Last auf 2.4GHz steigt sprunghaft an, während 5GHz-Clients verschwinden.

Was verursacht normalerweise DFS-Kanalwechsel?

Echtes Radar

Wetterradare im Bereich von 5600 - 5650 MHz sind in Europa eine häufige echte Quelle. In den USA nutzt das Terminal Doppler Weather Radar (TDWR) an großen Flughäfen denselben Bereich. Sichtverbindung ist hierbei wichtiger als die Entfernung. Outdoor-APs, obere Stockwerke und Glasfassaden erkennen Radarsignale, die APs im Erdgeschoss niemals erfassen.

Die reine Nähe sagt wenig aus. Viele Flughafen- und Seeüberwachungsradare arbeiten in anderen Bändern, weit außerhalb von 5GHz. Ein Standort direkt neben einem Hafen verzeichnet unter Umständen kein einziges Radarereignis. Ihr Ereignisprotokoll liefert den Beweis, nicht die Landkarte.

Fehlalarme (False Positives)

Ein DFS-Fehlalarm ist eine Radarekennung, obwohl kein Radar vorhanden ist. Das Funkmodul interpretiert einen plötzlichen Energiestoß als Radarimpulsmuster. Typische Auslöser sind:

• gepulste Nicht-WiFi Interferenzen durch drahtlose Videoverbindungen oder defekte Geräte;
• starke Übertragungen von einem nahegelegenen AP oder einer Point-to-Point-Verbindung auf einem Nachbarkanall;
• Funk- oder Firmware-Defekte, die von den Herstellern in Software-Releases behoben werden.

Das Erkennungsmerkmal ist die Isolation. Ein AP protokolliert wiederholte Ereignisse auf verschiedenen Kanälen, während benachbarte Geräte mit derselben Sichtlinie zum Himmel keine protokollieren.

Breite Kanäle erhöhen das Risiko sowohl für echte als auch für falsche Erkennungen. Ein 80 MHz-Kanal umfasst vier 20 MHz-Subkanäle, und eine Erkennung auf einem dieser Kanäle verschiebt den gesamten Kanal.

Änderungen ohne Radarbezug, die identisch aussehen

Kanalplaner verschieben Funkmodule aufgrund von Interferenzen und Auslastung. Meraki Auto RF, Aruba ARM und AirMatch sowie Ruckus ChannelFly und BackgroundScanning ändern Kanäle alle ohne Radar. Auch AP-Neustarts und Leistungsänderungen führen dazu, dass Clients die Verbindung verlieren. Diese Fehler erfordern unterschiedliche Lösungen. Bestätigen Sie daher den Grund, bevor Sie etwas ausschließen.

Wie stellen Sie fest, ob Radar den Ausfall verursacht hat?

Gehen Sie diese Checkliste der Reihe nach durch:

1. Die Beschwerde genau verorten. Ermitteln Sie die minute genaue Uhrzeit sowie den Raum, die Etage oder den Bereich.
2. Kanalwechsel-Ereignisse abrufen für die APs, die diesen Bereich versorgen, jeweils eine Stunde vor und nach dem Vorfall.
3. Den protokollierten Grund auslesen. Ein Radar- oder DFS-Grund bestätigt die Ursache. Ein Grund wie Interferenz, Rauschen oder Optimierung schließt sie aus.
4. Den Kanal notieren. Ereignisse, die sich auf den Kanälen 120, 124 und 128 häufen, deuten auf Wetterradar hin.
5. Die betroffenen APs zählen. Mehrere benachbarte Geräte zusammen deuten auf echtes Radar hin. Ein einzelner AP spricht für ein falsch positives Ergebnis.
6. Nach einem wöchentlichen Muster suchen. Regelmäßige Wiederholungen deuten auf ein Radar mit einem festen Zeitplan oder Suchlauf hin.
7. Kanalbreite prüfen. Ereignisse, die nur auf 80 oder 160 MHz-Kanälen auftreten, machen die Kanalbreite zu einem Teil des Problems.
8. Die Firmware-Release-Notes lesen, um nach DFS-Erkennungs-Fixes für Ihr AP-Modell zu suchen.

Wenn Sie Purple Guest WiFi nutzen, bieten Ihnen die Login-Volumina pro Standort eine Gegenprüfung. Ein starker Einbruch an einem Standort, der zeitlich mit einem Radarereignis zusammenfällt, bestätigt die Auswirkungen auf die Gäste.

Wie beheben Sie DFS-Ereignisse auf Meraki, Aruba und Ruckus?

Hersteller	Wo Radarereignisse angezeigt werden	Kanalplaner	Wo Sie Kanäle einschränken
Cisco Meraki	Nach DFS-Ereignissen gefiltertes Wireless-Ereignisprotokoll; RF-Spektrumseite pro AP	Auto RF	RF-Profil-Kanalliste, angewendet auf betroffene APs
HPE Aruba	ARM-Verlauf auf dem Controller oder Instant-Cluster; AirMatch-Ereignisse in AOS 8 und Aruba Central	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	Zulässige Kanalliste im Funkprofil für eine AP-Gruppe
Ruckus	SmartZone-Ereignisse und -Alarme für die Radarerkennung	ChannelFly oder BackgroundScanning	Funkeinstellungen für eine dedizierte Zone oder AP-Gruppe

Cisco Meraki

Meraki protokolliert die Radarerkennung im Ereignisprotokoll als DFS-Ereignisse und nennt dabei den AP und den Kanal. Filtern Sie nach Ereignistyp und dem betroffenen Zeitraum. Die HF-Spektrumsseite für jeden AP zeigt die Auslastung und Interferenzen, was Radar von einer Netzüberlastung unterscheidet. Um ein erneutes Auftreten zu verhindern, entfernen Sie die problematischen Kanäle aus Auto RF in einem HF-Profil. Wenden Sie dieses Profil nur auf die betroffenen APs an. Die DFS-Dokumentation von Meraki beschreibt die genauen Schritte.

HPE Aruba

Der ARM-Verlauf listet jeden Kanalwechsel mit Angabe des Grundes auf, wobei die Radarerkennung als eindeutiger Grund angezeigt wird. AirMatch erstellt den Kanalplan zentral, aber ein Radar-Ereignis zwingt den AP zu einem sofortigen Wechsel. Ein unvorhergesehener Wechsel am Nachmittag auf einem DFS-Kanal ist daher ein starker Hinweis. Schränken Sie die Kanäle im Funkprofil für eine AP-Gruppe ein, die nur die betroffenen APs enthält. Wenn Gäste nach dem erneuten Verbinden wieder auf eine Anmeldeseite geleitet werden, handelt es sich um einen separaten Fehler: Siehe die HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist.

Ruckus

SmartZone löst ein Ereignis aus, wenn ein AP Radar erkennt, und nennt dabei den AP und den Kanal. Überprüfen Sie Ereignisse und Alarme für das Zeitfenster und vergleichen Sie diese dann mit der Aktivität von ChannelFly oder BackgroundScanning. Ein Ruckus DFS-Kanalwechsel ohne ein dahinterstehendes Radar-Ereignis ist eine Entscheidung des Planers, kein DFS. Entfernen Sie problematische Kanäle in den Funkeinstellungen für eine dedizierte Zone oder AP-Gruppe.

Ändern Sie auf allen drei Plattformen nur die betroffenen APs. Ein standortweiter Ausschluss kostet Kapazität auf APs, die nie Radar erfasst haben.

Sollten Sie DFS-Kanäle in der Nähe eines Flughafens, Hafens oder Wetterradars deaktivieren?

Nicht standardmäßig. Der Ausschluss aller DFS-Kanäle in einer ETSI-Region hinterlässt nur vier 20-MHz-Kanäle: 36, 40, 44 und 48. Die FCC-Regeln belassen neun und fügen 149 bis 165 hinzu. In einer Umgebung mit hoher Dichte zwingen vier Kanäle die APs, sich die Sendezeit zu teilen, was jeden Client verlangsamt. Lassen Sie die Protokolle entscheiden.

Was Ihre Protokolle zeigen	Wahrscheinliche Ursache	Empfehlung	Verbleibende 20-MHz-Kanäle (ETSI / FCC)
Ereignisse auf mehreren benachbarten APs, gehäuft auf 120-128	Wetterradar	120, 124 und 128 auf betroffenen APs ausschließen	16 / 22
Täglich Ereignisse auf den meisten DFS-Kanälen über viele APs hinweg	Starkes Radar in der Nähe	DFS nur auf betroffenen APs ausschließen; andernorts beibehalten	4 / 9 auf betroffenen APs
Wiederholte Ereignisse auf einem AP, unterschiedliche Kanäle	Falsch-positiv	Firmware aktualisieren, das Funkmodul testen oder austauschen, DFS beibehalten	19 / 25
Ereignisse nur auf 80- oder 160-MHz-Kanälen	Bandbreiten-Exposition	Auf 40 oder 20 MHz reduzieren, DFS beibehalten	19 / 25
Kanalwechsel, aber keine Radareinträge	Planer oder Interferenz	Interferenzen und Leistung korrigieren, DFS beibehalten	19 / 25

Praxisbeispiel: Ein Hotel in der Nähe eines Regionalflughafens

Ein Hotel mit 180 Zimmern in einer ETSI-Region lag 3 km von einem Flugplatz mit einem Wetterradar entfernt. Gäste in den nach Westen ausgerichteten oberen Etagen meldeten an den meisten Nachmittagen Verbindungsabbrüche. Das Ereignisprotokoll verzeichnete in einer Woche 63 Radarereignisse auf 11 von 46 APs, alle auf den Kanälen 120 bis 128. Das Team verschob diese 11 APs in ein Profil, das die Wetterkanäle ausschloss, und stellte eine Kanalbreite von 40 MHz ein. In den folgenden vier Wochen verzeichnete das Hotel null Radarereignisse. Die Beschwerden über das WiFi an der Rezeption sanken von 14 auf zwei pro Woche. Die anderen 35 APs behielten alle DFS-Kanäle bei. Weitere Informationen zu Hotel-Bereitstellungen finden Sie unter Hotels.

Praxisbeispiel: Eine Einzelhandelskette mit einem störenden AP

Eine Einzelhandelskette mit 120 Filialen verzeichnete in einer Filiale innerhalb von zwei Wochen 30 Radarereignisse auf den Kanälen 52, 100 und 116. Benachbarte APs in derselben Filiale verzeichneten keine Ereignisse, was auf ein falsch positives Ergebnis hindeutete. Die Versionshinweise für das AP-Modell enthielten eine Behebung für die DFS-Erkennung, weshalb das Team die Firmware aktualisierte. Die Ereignisse hielten an, und der AP wurde im Rahmen der Garantie ausgetauscht. Die Radarereignisse in der Filiale sanken auf null, und die Kunden verloren im Kassenbereich keine Verbindung mehr. Die gesamte Flotte behielt alle 19 Kanäle. Siehe Retail für Gastzugänge an mehreren Standorten.

Praxisbeispiel: Kommunalverwaltung neben einem Hafen

Ein IT-Team der Kommunalverwaltung plante, DFS in Büros neben einem Handelshafen zu deaktivieren. Die Protokolle von 30 Tagen zeigten jedoch keinerlei Radarereignisse. Die Kanalwechsel resultierten daraus, dass der Planer auf das Netzwerk eines benachbarten Mieters reagierte. Das Team behielt DFS bei, senkte die Sendeleistung und korrigierte den Kanalplan. Die wöchentlichen Berichte über Verbindungsabbrüche sanken von neun auf einen.

Wie verhindern Sie, dass DFS-Ereignisse Ihre Gäste erneut stören?

• Nutzen Sie Kanäle mit 20 oder 40 MHz in stark frequentierten Bereichen. Schmalere Kanäle reduzieren die Störanfälligkeit und erhöhen die Wiederverwendbarkeit.
• Schließen Sie Wetterkanäle gezielt aus, wenn sich Ereignisse auf den Kanälen 120 bis 128 häufen - und zwar nur auf den betroffenen APs.
• Halten Sie die Firmware auf dem neuesten Stand und lesen Sie die DFS-Korrekturen in den jeweiligen Versionshinweisen.
• Überprüfen Sie die DFS-Ereignisse monatlich und richten Sie Alarme für jeden AP ein, der mehr als eine Handvoll Ereignisse pro Woche protokolliert.
• Planen Sie für 6GHz. Das 6GHz-Band erfordert kein DFS, sodass WiFi 6E und WiFi 7 Clients Radar-Kanalwechsel komplett vermeiden.
• Trennen Sie HF vom Gastzugang. Purple läuft als hardwareunabhängiges Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Ihr Controller steuert den Kanalplan, und Purple steuert das Gäste-Login. Purple verzeichnete im Jahr 2024 über 440 Millionen Logins an mehr als 80.000 aktiven Standorten (Purple-Daten).

Häufig gestellte Fragen

Funktioniert Purple Guest WiFi auf unseren vorhandenen Meraki-, Aruba- oder Ruckus-Access-Points?

Ja. Purple Guest WiFi ist ein hardwareunabhängiges Cloud-Overlay, das auf Cisco Meraki, HPE Aruba und Ruckus sowie auf Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet läuft. Sie behalten Ihre Access Points, Controller und Ihre HF-Konfiguration. Purple fügt lediglich das Gäste-Login, die bewusste Einwilligung der Nutzer und die Erfassung von First-Party-Daten hinzu. Ein Austausch der Hardware ist nicht erforderlich, und Ihre DFS-Einstellungen bleiben unter Ihrer Kontrolle.

Wird Purple unsere DFS- oder Kanaleinstellungen ändern?

Nein. Purple konfiguriert keine Funkkanäle, Kanalbreiten oder Sendeleistungen. Diese verbleiben in Meraki Auto RF, Aruba ARM oder AirMatch sowie Ruckus ChannelFly oder BackgroundScanning. Purple übernimmt die Authentifizierung von Gästen und die Datenerfassung oberhalb der Funkschicht. Diese Trennung ermöglicht es Ihnen, ein DFS-Problem in Ihrem Anbieter-Dashboard zu beheben, ohne das Anmeldeerlebnis für Gäste zu beeinträchtigen, und die Anmeldeeinstellungen zu ändern, ohne die RF-Einstellungen anzupassen.

Ist es regelkonform, DFS-Kanäle zu deaktivieren?

Ja. ETSI EN 301 893 und FCC Part 15.407 erfordern eine Radarerkennung auf jedem von Ihnen genutzten DFS-Kanal. Keine dieser Richtlinien schreibt die Nutzung von DFS-Kanälen vor. Der Ausschluss von DFS-Kanälen ist immer konform. Was Sie niemals tun dürfen, ist, auf einem DFS-Kanal mit deaktivierter Erkennung zu arbeiten. Die tatsächlichen Kosten des Ausschlusses liegen in der Kapazität: In ETSI-Regionen bleiben nach dem Entfernen aller DFS-Kanäle nur noch vier statt 19 Kanäle mit 20 MHz übrig.

Benötigen wir neue Access Points, um DFS-Probleme zu vermeiden?

Normalerweise nicht. Die meisten DFS-Probleme lassen sich durch die Konfiguration beheben: durch den Ausschluss von Wetterkanälen auf betroffenen APs, das Verringern der Kanalbreite oder durch ein Firmware-Update. Ein Austausch ist dann sinnvoll, wenn ein Funkmodul nach einem Firmware-Update weiterhin Fehlalarme meldet oder wenn Sie 6-GHz-Kapazitäten hinzufügen. Das 6-GHz-Band erfordert kein DFS, sodass WiFi 6E und WiFi 7 Access Points Kanalwechsel aufgrund von Radar für Clients, die dies unterstützen, überflüssig machen.

Beeinträchtigt der Ausschluss von DFS-Kanälen das Gäste-WiFi an gut besuchten Standorten?

Ja, wenn Sie diese standortweit ausschließen. In einer ETSI-Region können vier 20-MHz-Kanäle nicht Dutzende von APs in einem Stadion, einem Konferenzzentrum oder einem großen Hotel voneinander trennen. Die APs müssen sich die Sendezeit teilen, wodurch der Durchsatz für jeden Gast sinkt. Schließen Sie Kanäle nur auf den APs aus, die Radarereignisse protokollieren, und behalten Sie DFS überall sonst bei. Dieser Ansatz grenzt das Problem ein, ohne auf Kapazität zu verzichten.

Unterscheiden sich die DFS-Regeln zwischen Großbritannien, Europa und den USA?

Ja. Großbritannien und die EU folgen ETSI EN 301 893, was DFS für die Kanäle 52 bis 64 und 100 bis 140 vorschreibt. Zudem ist eine 10-minütige Verfügbarkeitsprüfung auf den Wetterkanälen 120, 124 und 128 erforderlich. Die USA folgen FCC Part 15.407, was den Kanal 144 einschließt und neun Nicht-DFS-Kanäle übrig lässt. Beide Richtlinien verlangen nach einer Erkennung eine Sperrzeit von mindestens 30 Minuten.

Kann ein MSP DFS-Ereignisse über eine herstellergemischte Infrastruktur hinweg diagnostizieren?

Ja, aber die Radarereignisse verbleiben in den Tools des jeweiligen Herstellers: im Meraki-Ereignisprotokoll, in der Aruba ARM-Historie oder den AirMatch-Ereignissen sowie in den SmartZone-Ereignissen und -Alarmen. Ein MSP sollte eher die Checkliste als das Tool standardisieren und für jeden Vorfall Zeit, Kanal, Anzahl der APs und Grund dokumentieren. Purple bietet Ihnen eine einzige Plattform für den Gastzugang über alle diese Anbieter hinweg, während die RF-Diagnose im jeweiligen Controller verbleibt.