Juniper Mist Radio Resource Management

1. Lernziele

RRM als lernenden, geschlossenen Optimierungsregelkreis erklären,
Scan-Radio-, Client-, Capacity-SLE- und Verlaufsdaten einordnen,
RF Template, Device Profile und AP-Override korrekt auflösen,
Kanal-, Sendeleistungs- und Kanalbreitenentscheidungen bewerten,
Auto-Cancellation, Auto-Conversion und Dual 5 GHz unterscheiden,
6-GHz-PSC- sowie DFS-Punishment-Logik erklären,
geplante Cloudoptimierung und lokale Sofortreaktion trennen,
RRM-Änderungen mit SLEs, Events und Clientdaten validieren.

Leitfrage: Welche Messung löste welche RRM-Entscheidung innerhalb welcher Konfigurationsgrenzen aus – und wurde das Benutzererlebnis danach tatsächlich besser?

2. Was ist Mist RRM?

Juniper Mist Radio Resource Management ist ein cloudbasiertes System, das die Funkumgebung kontinuierlich beobachtet und Einstellungen so optimiert, dass die Benutzererfahrung verbessert wird.

Beobachten

Dedizierte Scan-Radios erfassen Nachbarzellen, Interferenz, Nutzung und Umgebungsereignisse.

Entscheiden

Cloudalgorithmen verbinden aktuelle Messungen, historische Muster, User Minutes und Capacity SLE.

Validieren

Nach einer Änderung überwacht Mist weiter, ob Kapazität und Nutzererfahrung messbar besser werden.

RRM ≠ statischer Kanalplan | RRM = Messen → Entscheiden → Ändern → Wirkung messen

RRM bewegt sich innerhalb der vom Betreiber definierten Constraints. Automatik bedeutet daher nicht unbeschränkte Freiheit, sondern Optimierung innerhalb erlaubter Bänder, Kanäle, Leistungen, Breiten und Radiomodi.

3. Der geschlossene RRM-Regelkreis

1. Telemetrie
APs senden RF-Ereignisse, Clientnutzung und Umweltmesswerte an die Mist Cloud.

2. Normalisierung
Messungen werden Site-, AP-, Band- und User-Minute-bezogen eingeordnet.

3. Baseline
Bis zu 30 Tage Verlaufsdaten helfen, wiederkehrende Muster und problematische Kanäle zu erkennen.

4. Zielgröße
Capacity SLE und Benutzererfahrung bilden wesentliche Bewertungsgrößen.

5. Aktion
RRM kann Kanal, Power, Breite, Band/Radiomodus oder BSS Color anpassen.

6. Umsetzung
APs übernehmen die Entscheidung innerhalb der effektiven Konfigurationsgrenzen.

7. Feedback
SLEs, User Minutes und RF-Daten zeigen, ob die Änderung positiv wirkte.

Die Verstärkungslernlogik wählt Aktionen anhand erwarteter zukünftiger Vorteile. Das Ziel ist nicht maximale Aktivität, sondern eine bessere langfristige Nutzererfahrung.

Keine Änderung kann korrekt sein: Ist die Capacity SLE bereits sehr gut – Juniper nennt 90 Prozent oder mehr als Beispiel – oder existiert keine voraussichtlich positive Aktion, lässt RRM die Umgebung unverändert.

4. Messdaten und Bewertungsgrundlagen

Datenquelle	Beispiele	Nutzen
Dedicated Scan Radio	Nachbar-APs, Kanäle, Wi‑Fi-/Non-Wi‑Fi-Interferenz	unabhängige RF-Beobachtung
Client Telemetry	RSSI, Datenrate, Retries, Nutzung, Roaming	reale Nutzererfahrung
Capacity SLE	freie RF-Kapazität und Classifier	Bewertung von Engpässen
AP Events	Radar, Kanalwechsel, Power-/Breitenänderung	Ursachen- und Wirkungskorrelation
Historical Baseline	wiederkehrende Interferenz und Tagesmuster	verhindert rein momentane Fehloptimierung
Site Traffic	aktive Client-Minuten, TX-/RX-Bytes	Vorhersage verkehrsarmer Wartungsstunden

Ein dediziertes Scan-Radio reduziert die Notwendigkeit, Client-Radios für Off-Channel-Messungen zu unterbrechen. Fähigkeiten und Bandabdeckung werden dennoch modellgenau geprüft.

5. Konfigurationshierarchie und Constraints

RF Template→ überschrieben durch →Device Profile→ überschrieben durch →direkte AP-Konfiguration

Ebene	Scope	Priorität
RF Template	Organization-Objekt, einer Site zugewiesen; modellbezogene Defaults möglich	breitester Grundrahmen
Device Profile	ausgewählte APs oder Gerätegruppen	überschreibt RF Template pro Band
AP Settings	ein einzelner AP	höchste Priorität

Direkte AP-Werte zeigen entweder Use site setting, konkrete Werte oder Overriding Profile. Nicht überschriebene Felder bleiben aus RF Template beziehungsweise Device Profile wirksam.

Auto-Vererbung

Wenn RF Template bei 2,4-GHz-Band, Dual-Band- oder Tri-Band-Einstellung nicht Auto erlaubt, kann diese Automatik auf Device-Profile- oder AP-Ebene nicht nachträglich ausgewählt werden.

Effektive Konfiguration prüfen: Ein korrektes RF Template beweist nicht, dass ein AP es vollständig verwendet. Profile und Geräte-Overrides werden vor jeder RRM-Diagnose aufgelöst.

6. Automatic Channel Selection

RRM wählt Kanäle nicht nur anhand einer Momentaufnahme. Historische Co-Channel-Interferenz, Radarereignisse, Nachbarn und Capacity SLE beeinflussen die Priorität.

Allowed Channels+aktuelle RF-Lage+historische Probleme+Capacity→Kanalzuweisung

Designparameter	Wirkung
Automatic	RRM wählt aus regulatorisch und durch Template erlaubten Kanälen
Allowed Channel List	begrenzt Auswahl; eine zu kleine Liste erhöht Co-Channel-Konkurrenz
Channel Width	bestimmt Anzahl nutzbarer Primärkanäle und Interferenzfläche
DFS Policy	beeinflusst verfügbare 5-GHz-Kapazität und Radar-Risiko
AP Placement	Nachbarschaften und Wiederverwendung entstehen physisch, nicht im Portal

Ein Kanalwechsel unterbricht laufende Clientkommunikation zumindest kurzzeitig und kann Roams oder Reconnects auslösen. Deshalb werden Änderungen nach Nutzerwirkung und nicht nur nach neuem Kanalbild bewertet.

7. Sendeleistungssteuerung

RRM kann Radioleistung erhöhen oder senken. Bei Ausfall eines Nachbar-APs kann Leistung benachbarter APs steigen. Eine Reduktion erfolgt laut Juniper nur, wenn die Coverage dadurch nicht beeinträchtigt wird.

Ziel: ausreichende bidirektionale Coverage + kontrollierte Zellgröße + geringe unnötige Konkurrenz

Modus	Verhalten	Einsatz
Automatic	RRM wählt innerhalb Minimum/Maximum	Standard für dynamische Umgebungen
Automatic mit Range	Betreiber begrenzt Optimierungsraum	Designvorgaben, Clientlinkbudget und regulatorische Grenzen
Set Power	fester Wert	begründeter Sonderfall, Survey oder kontrollierte Spezialfläche

Die Mist-GUI und API stellen Transmit Power pro Tx Chain dar. Dieser Wert ist nicht automatisch die gesamte EIRP. Antennengewinn, Kabelverlust, Chain-Anzahl und regulatorische Leistungsdichte müssen im Link-Budget korrekt behandelt werden.

Mehr Power ist nicht automatisch besser: Zu große Zellen erhöhen Co-Channel Contention, Sticky Clients und Uplink-/Downlink-Asymmetrie.

8. Dynamische Kanalbreite

Band	von RRM nutzbare Breiten laut aktueller Dokumentation	Planungsaspekt
2,4 GHz	20 MHz	maximale Wiederverwendung bei knappem Spektrum
5 GHz	20, 40 oder 80 MHz	Kapazität gegen Peak-Durchsatz abwägen
6 GHz	20, 40, 80, 160 oder 320 MHz, landabhängig	Spektrum, Clientmix und regulatorische Domäne

Breiterer Kanal = höhere mögliche Peak-Rate, aber weniger unabhängige Kanäle und größere Störfläche

RRM kann Breiten zur Verbesserung der Nutzererfahrung erhöhen oder reduzieren. Ein 160-/320-MHz-fähiger AP rechtfertigt diese Breite nicht automatisch in dichter Umgebung.

9. 2,4 GHz: Auto-Cancellation und Auto-Conversion

Auto-Cancellation

Deaktiviert ausgewählte 2,4-GHz-Radios, um Co-Channel-Interferenz zu reduzieren. Das Radio wird nicht anderweitig als Clientradio genutzt.

Auto-Conversion

Verschiebt ein dual-bandfähiges Radio von 2,4 auf 5 GHz und erzeugt dadurch zusätzliche 5-GHz-Kapazität.

Eigenschaft	Cancellation	Conversion
Ziel	weniger 2,4-GHz-Zellen	weniger 2,4 GHz plus zusätzliches 5-GHz-Radio
Coverage-Schutz	nur wenn Entfernung keine Powerkompensation der Nachbarn erzwingt	gleiche Grundbedingung
maximale Entfernung	nie mehr als 50 % der 2,4-GHz-Radios einer Site	nie mehr als 50 %
typischer Wert laut Juniper	ungefähr 40 %	ungefähr 40 %
Plattform	alle Juniper Mist APs	laut aktueller RRM-Seite AP43, AP45 und AP63

Geeignet sind dichte, überwiegend 5-GHz-orientierte Netze mit bekannten Clients. Bei geringer AP-Dichte oder missionskritischen 2,4-GHz-only-Geräten kann die Automatik ungeeignet sein.

Inventar vor Automatik: IoT-, Scanner-, Voice- und Legacy-Geräte werden nach Bandfähigkeit und tatsächlichen Standorten erfasst, bevor 2,4-GHz-Radios automatisch reduziert werden.

10. Dual-5-GHz-Betrieb

Bei unterstützten APs teilen sich die beiden 5-GHz-Radios feste Kanalbereiche, damit sie sich nicht auf demselben Teilband überlagern.

Modellgruppe	konvertiertes Dual-Band-Radio	dediziertes 5-GHz-Radio
AP43 / AP63	Kanäle 100–165	Kanäle 36–64
AP45 / AP47	Kanäle 36–64	Kanäle 100–165

Juniper empfiehlt bei Auto-Conversion oder Dual 5 GHz eine Kanalbreite von 20 MHz. So steigt die Zahl wiederverwendbarer 5-GHz-Radios und Co-Channel-Interferenz bleibt kontrollierbarer.

Wann sinnvoll?

hohe 5-GHz-Clientdichte und Airtime-Nachfrage
ausreichend viele verfügbare Kanäle je Teilband
2,4-GHz-Coverage bleibt durch andere APs erhalten
AP-Uplink und PoE tragen zusätzliche Kapazität
DFS- und regionale Kanalliste passen zum Modell

11. RRM im 6-GHz-Band

20/40 MHz
alle erlaubten Primärkanäle

80/160 MHz
PSC als Primärkanal

320 MHz
land-/clientabhängig

RRM verwendet bei 20 und 40 MHz sowohl Preferred Scanning Channels als auch Non-PSC als Primärkanäle. Bei 80 und 160 MHz werden PSCs als Primärkanäle eingesetzt. Clients können Non-PSC-Zellen über Out-of-Band-Mechanismen wie Reduced Neighbor Reports oder 802.11k Neighbor Reports entdecken.

Entscheidung	Prüfung
Band aktivieren	WLAN, Security, AP-/Clientfähigkeit und Region
Breite	verfügbares Spektrum, Dichte und Peak-Anforderung
Allowed Channels	PSC/Non-PSC, lokale Regulierung und Clienttests
Power	PSD/EIRP, Indoor-/Outdoor-Modus und Antenne
Fallback	5 GHz im Multiband-WLAN für Discovery-/Clientprobleme

6 GHz ist kein isoliertes Optimierungsprojekt: Security, Discovery, Power, Kanalbreite, Clientmix und 5-GHz-Fallback werden gemeinsam geplant.

12. DFS, Radar und DFS Punishment

Erkennt ein AP Radar auf einem DFS-Kanal, wechselt er unmittelbar den Kanal. Dieser gesetzlich beziehungsweise regulatorisch geprägte Sofortwechsel ist für Clients disruptiv und kann Ausweichkanäle belasten.

Radar erkannt→lokaler Kanalwechsel→Event zur Cloud→historische Bewertung→DFS-optimierte Verteilung

RRM speichert, welche APs auf welchen Kanälen wiederholt Radar sehen, und reduziert dort künftig die Kanalpriorität. Juniper bezeichnet dies als DFS Punishment. Eine weniger gleichmäßige Kanalverteilung kann dabei bewusst akzeptiert werden.

Capacity Constraint

Situation	RRM-Reaktion
hoher Kapazitätsengpass	DFS-Nutzung bleibt trotz Radar eher erhalten, wenn Ausweichen Leistung verschlechtern würde
mittlerer Engpass	stärkst betroffene DFS-Kanäle meiden, andere weiter nutzen
geringer/kein Engpass	größerer Teil der Radios kann zu stabileren Non-DFS-Kanälen wechseln

Zusätzliche Kapazität, insbesondere 6 GHz, gibt RRM mehr Freiheit, radarbelastete DFS-Kanäle zu vermeiden.

13. Cloudoptimierung und lokale Sofortreaktionen

Mechanismus	Zeitverhalten	Beispiel
Cloud-RRM	historisch und siteweit bewertet	Kanalplan, Power, Breite, Radio-Conversion
lokale AP-Reaktion	unmittelbar bei akutem Ereignis	Radarwechsel, akute Interferenz oder Nachbar-AP-Ausfall
manuell getriggertes RRM	durch Administrator ausgelöst	Site/Band oder ausgewählte APs optimieren

Lokale Änderungen werden ebenfalls als Ereignisse an die Cloud gemeldet und fließen in die langfristige Bewertung ein. Damit bleibt die zentrale Analyse über kurzfristige AP-Reaktionen informiert.

Kein Widerspruch: „Cloudbasiert“ bedeutet nicht, dass jeder akute Kanalwechsel erst auf eine Cloudentscheidung warten muss.

14. Wireless Site Maintenance Aggregator

Der Aggregator sagt pro Site die verkehrsärmste lokale Stunde voraus. Grundlage ist ein gleitendes Fenster von 14 Tagen mit aktiven Client-Minuten sowie übertragenen und empfangenen Bytes.

Schritt	Funktion
historische Daten	14-Tage-Fenster erfasst wiederkehrende Tagesmuster
Normalisierung	Sitegrößen und unterschiedliche Trafficprofile vergleichbar machen
gewichteter Activity Score	Client-Minuten und TX/RX-Mengen zusammenführen
Lowest Activity Hour	geeignete lokale Stunde bestimmen
Confidence Score	Verlässlichkeit der Vorhersage nach Seasonality bewerten

Damit können wartungs- oder policyrelevante Aktionen an reale Site-Nutzungsmuster angepasst werden, statt für jede Site dieselbe starre Uhrzeit anzunehmen.

15. Manuelle und selektive Optimierung

Gesamte Site beziehungsweise Band

Unter Site → Radio Management kann die ausgewählte 2,4-, 5- oder 6-GHz-Umgebung sofort optimiert werden.

Ausgewählte APs

Unter Access Points → Auswahl → More → Optimize Radios können seit Ende 2025 gezielt APs und Bänder optimiert werden. Optional wird nur die Sendeleistung optimiert, damit kein Kanalwechsel ausgelöst wird.

Anlass	Geeignete Variante
neue APs eingebaut	selektierte neue und direkt benachbarte APs
kleine Außenfläche verändert	betroffene APs und Band
Power-Balance testen	Transmit Power Only
Siteweite RF-Änderung	Bandoptimierung im Wartungsfenster

Optimize Now ist ein Change: Scope, aktive Clients, Kanalwirkung, Kommunikationsplan und Vorher-/Nachher-Messung werden festgelegt.

16. Radio Management und RRM Events

Die Radio-Management-Ansicht zeigt Zustand, Band, APs und Ereignisse. Radio Events können für die letzten 24 Stunden oder sieben Tage betrachtet werden.

Eventinformation	Nutzen
alter/neuer Kanal	ACS- oder DFS-Wirkung nachvollziehen
alte/neue Breite	Kapazitäts-/Durchsatzentscheidung bewerten
alte/neue Power	Zell- und Coverage-Reaktion prüfen
Trigger	Scheduled Site RRM, Triggered Site RRM, Radar oder Co-Channel Interference
wirksames RF Template	Constraint-Quelle erkennen

Vorher-/Nachher-Kennzahlen

Capacity SLE und Classifier
Coverage SLE und Weak-Signal-User-Minutes
Throughput SLE
Channel Utilization und Interferenz
Retries, MCS und Datenraten
Roamingqualität und Clientverteilung
Helpdesk-/Anwendungswirkung

17. Dynamic Capacity Optimization und DFS Optimization

Marvis kann neben dem regulären RRM zusätzliche Actions für Kapazitäts- und DFS-Probleme bereitstellen. Die Verfügbarkeit hängt von Subscription, Modell, Firmware und aktivierten Self-Driving-Funktionen ab.

Dynamic Capacity Optimization

Reagiert auf mehrere APs mit unzureichender Kapazität oder einen dauerhaft überlasteten AP. Kann Radiomodus und Kanalbreite anpassen, um Kapazität zu erhöhen.

DFS Optimization

Bewertet Radarbelastung gegenüber vorhandener Sitekapazität und zeigt, wie weit DFS-Nutzung ohne Leistungsverschlechterung reduziert werden kann.

Self-Driving bedeutet, dass eine freigegebene Aktion automatisch umgesetzt werden kann. Vor Aktivierung werden Scope, Change-Grenzen, Ausfallwirkung, Review und Rollback organisatorisch geregelt.

Automatisierung mit Guardrails: Eine plausible Empfehlung wird nicht allein wegen des Labels „AI“ freigegeben. Erwartete Änderung und messbares Erfolgskriterium müssen nachvollziehbar sein.

18. RRM-gerechtes RF-Design

Designbereich	RRM benötigt
AP Placement	ausreichende, aber nicht übermäßige Überlappung und korrekte Montage
Allowed Channels	genug Auswahl für Wiederverwendung und regionale Konformität
Power Range	realistischer Min-/Max-Rahmen nach Clientlinkbudget
Channel Width	Kapazitätsziel statt maximaler Datenblattrate
2,4-GHz-Strategie	bekannte Legacy-/IoT-Anforderungen und ausreichende Restcoverage
6-GHz-Strategie	Security, Clientmix, PSC/Non-PSC und Fallback
Map Placement	korrekte AP-Position, Höhe und Orientierung für Analyse

Gutes RRM kann ein tragfähiges Design laufend optimieren – es kann falsche AP-Positionen nicht wegkonfigurieren

Post-Deployment Survey und reale Anwendungstests bleiben notwendig. RRM reagiert auf eine sich ändernde Umgebung, ersetzt aber weder Requirements noch bauliche und regulatorische Planung.

19. Systematische Fehlersuche

1. Symptom und Scope
Site, AP, Band, WLAN, Client, Zeit und Anwendung erfassen.

2. Effektive Konfiguration
RF Template, Modell-Defaults, Device Profile und AP-Overrides auflösen.

3. Radio Event
Trigger, alter/neuer Kanal, Breite und Power im Zeitfenster prüfen.

4. Capacity/Coverage SLE
User Minutes und Classifier vor und nach Änderung vergleichen.

5. RF-Messwerte
Channel Utilization, Wi‑Fi-/Non-Wi‑Fi-Interferenz, Noise und Retries prüfen.

6. Clientverhalten
RSSI/SNR, MCS, Band, Roaming und Capability korrelieren.

7. Physische Ebene
AP-Position, Antenne, Hindernisse, neue Störquelle und Nachbarn prüfen.

8. Kontrollierter Test
kleinste Änderung pilotieren und dieselben Kennzahlen erneut messen.

Symptom	Wahrscheinliche Ursache	Erster Beweis
AP bleibt auf manuellem Kanal	AP-/Profile-Override begrenzt RRM	effektive Radio Settings
2,4-GHz-Radios werden nicht reduziert	Coverage, Template nicht Auto oder kritische Dichte	RF Template und Cancellation Events
viele Kanalwechsel tagsüber	Radar, Triggered RRM oder akute Interferenz	Radio Events mit Trigger
starker RSSI, schlechter Throughput	Kapazität, Retries, Clientfähigkeit oder Wired Path	Throughput-/Capacity-Classifier
nach Power-Reduktion Coverage schlecht	Client-Uplink/Umgebung anders als Modell	Coverage User Minutes und Standort
DFS bleibt trotz Radar aktiv	Capacity Constraint verhindert stärkeres Ausweichen	DFS Optimization Classification
Non-PSC-Clientproblem	Discovery-/Treiberproblem	OTA Scan/Association und 5-GHz-Fallback

Korrelation statt Vermutung: Ein Kanalwechsel kurz vor einer Störung kann Ursache, Reaktion auf dieselbe Störquelle oder Zufall sein. Eventtrigger und Clienttimeline entscheiden.

20. Design- und Abnahmecheckliste

Vor Aktivierung

RF Template jeder Site zugewiesen
modellbezogene Radiomodi geprüft
Allowed Channels ausreichend
Power Range nach Linkbudget
Breiten nach Kapazitätsziel
2,4-GHz-only-Clients inventarisiert
Overrides dokumentiert

Nach Optimierung

Radio Events und Trigger geprüft
Capacity SLE verbessert/stabil
Coverage nicht verschlechtert
Throughput und Retries plausibel
Roaming mit realen Clients getestet
DFS-/6-GHz-Verhalten geprüft
Ergebnis und Rollback dokumentiert

Häufige Fehlannahmen

Behauptung	Bewertung	Fachliche Einordnung
„RRM ändert ständig irgendetwas.“	Falsch	Ohne erwartete Verbesserung oder bei guter Capacity SLE kann keine Änderung sinnvoll sein.
„Cloud-RRM reagiert nicht sofort auf Radar.“	Falsch	Der AP führt den regulatorischen DFS-Wechsel lokal sofort aus.
„Mehr Sendeleistung verbessert immer Coverage.“	Falsch	Sie kann Zellen vergrößern, Asymmetrie und Co-Channel-Konkurrenz erhöhen.
„Breitere Kanäle erhöhen immer Kapazität.“	Falsch	Sie erhöhen Peak-Rate, reduzieren aber Kanalwiederverwendung.
„RF Template ist immer der effektive Wert.“	Falsch	Device Profiles und direkte AP-Settings können es überschreiben.
„Auto-Cancellation schaltet beliebig viele 2,4-GHz-Radios aus.“	Falsch	Juniper begrenzt die Entfernung auf maximal 50 Prozent pro Site.
„RRM ersetzt den Post-Deployment Survey.“	Falsch	Physisches Design und reale Abnahme bleiben erforderlich.

Merksätze

RRM ist ein geschlossener Regelkreis aus Messung, Aktion und Wirkungskontrolle.
Historie schützt vor rein momentaner Kanaloptimierung.
Constraints definieren den zulässigen Automatikraum.
Direkte AP-Settings überstimmen Profile und RF Templates.
Power wird pro Tx Chain angezeigt, nicht automatisch als Gesamt-EIRP.
Breitere Kanäle erhöhen Peak-Rate, nicht zwingend Gesamtkapazität.
Auto-Cancellation und Auto-Conversion sind verschiedene Aktionen.
DFS-Sofortreaktion ist lokal; historische Optimierung erfolgt cloudgestützt.
Keine Änderung kann die beste RRM-Entscheidung sein.
RRM optimiert ein gutes Design, ersetzt es aber nicht.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. RRM-Aktionen, unterstützte Radiomodi, Modelllisten, Kanalregeln und Marvis-Funktionen können sich ändern; für produktive Entscheidungen gelten die aktuelle Juniper-Dokumentation, AP-Firmware, regulatorische Domäne und konkrete Subscription.