LoRaWAN-Roaming: Passive Roaming, Handover und Backend-Schnittstellen

LoRaWAN-Roaming ermöglicht, dass ein Endgerät Funkabdeckung eines anderen Netzes nutzt. Technisch klingt das ähnlich wie Mobilfunk-Roaming, organisatorisch ist es jedoch ein eigener Mechanismus aus NetIDs, Backend-Rollen, Richtlinien und Vereinbarungen. Zwei Netze werden nicht allein deshalb zu Roamingpartnern, weil ihre Gateways denselben LoRaWAN-Frame empfangen können.

Auch die bekannte LoRaWAN-Makrodiversität ist noch kein Roaming. Wenn mehrere Gateways desselben Network Servers einen Uplink empfangen, dedupliziert dieser die Kopien innerhalb seines eigenen Netzes. Roaming beginnt dort, wo Gateways und Network Server unterschiedlicher Betreiber oder administrativer Domänen zusammenarbeiten.

Kurz zusammengefasst: Beim passiven Roaming bleibt der bisherige Serving Network Server für MAC und Sitzung verantwortlich; das besuchte Netz leitet Frames weiter. Beim Handover-Roaming wechselt die Serving-Rolle. Beide Varianten brauchen Backend-Schnittstellen, NetID-basierte Zuordnung, Sicherheitskontext, Richtlinien und eine belastbare Betreibervereinbarung.

Die Rollen im Roaming-Backend

Die LoRaWAN Backend Interfaces Specification 1.1 trennt mehrere Serverrollen. Der Home Network Server hNS kennt die Heimzuordnung des Geräts. Der Serving Network Server sNS kontrolliert die MAC-Schicht einer aktiven Sitzung. Ein Forwarding Network Server fNS transportiert Funkframes über seine Gateways. Der Visited Network Server vNS bezeichnet allgemein das besuchte Netz und kann je nach Verfahren Forwarding- oder Serving-Aufgaben übernehmen.

Join Server und Application Server bleiben eigene Rollen. Der Join Server verwaltet Root-Key-bezogene Aktivierung und liefert Sitzungsschlüssel an die berechtigten Parteien. Der Application Server verarbeitet die Anwendungsnutzlast. In einem kleinen privaten Netz können mehrere Rollen in derselben Software laufen; für das Roamingmodell bleiben ihre Zuständigkeiten trotzdem getrennt.

Rolle	Abkürzung	Aufgabe im Roaming
Home Network Server	hNS	kennt Heimnetz und bleibt Bezugspunkt des Geräts
Serving Network Server	sNS	führt MAC-Kontrolle und LoRaWAN-Sitzung
Forwarding Network Server	fNS	stellt fremde Gateways bereit und leitet Frames
Visited Network Server	vNS	Sammelbegriff für das besuchte Netz
Join Server	JS	unterstützt Aktivierung und Schlüsselableitung
Application Server	AS	entschlüsselt und verarbeitet Anwendungsdaten

NetID und DevAddr weisen den Weg

Die LoRa Alliance beschreibt auf ihrer NetID- und Network-Coverage-Seite die NetID als 24-Bit-Netzwerkkennung. Sie wird von der Alliance zugewiesen und dient unter anderem dazu, netzspezifische DevAddr-Bereiche zu bilden. Ein besuchter Network Server kann aus dem NwkID-Anteil der DevAddr mögliche Heimnetze ableiten und die Roamingrichtlinie prüfen.

DevAddr ist nur 32 Bit lang, und abhängig vom NetID-Typ können mehrere NetIDs auf denselben NwkID-Wert abgebildet werden. Das Backend muss deshalb gegebenenfalls mehrere Kandidaten prüfen. NetID und DevAddr liefern Routinginformation; die MIC-Prüfung und der Sicherheitskontext entscheiden anschließend, ob der Frame wirklich zu der behaupteten Sitzung gehört.

Passives Roaming: Das Heimnetz behält die Kontrolle

Beim passiven Roaming empfängt ein Gateway des besuchten Netzes den Uplink. Dessen fNS erkennt, dass kein lokaler Gerätekontext vorliegt, ermittelt das mögliche Heimnetz und sendet eine PRStartReq. Akzeptiert das Heimnetz die Anfrage und ist die MIC-Prüfung erfolgreich, leitet der fNS weitere Up- und Downlinks für diese Sitzung weiter.

Der bisherige sNS bleibt zuständig für MAC-Schicht, Datenrate, Kanalparameter und Sitzung. Das fremde Netz stellt im Wesentlichen Radiozugang und Transport bereit. Dadurch kann passives Roaming auch für LoRaWAN-1.0-Endgeräte funktionieren. Das Gerät selbst muss keinen besonderen Handover ausführen; aus seiner Sicht sendet es weiterhin einen normalen Uplink.

Stateful und stateless Passive Roaming

Ein stateful fNS legt beim Start des passiven Roamings einen Gerätekontext an und verwendet ihn für folgende Frames. Ein stateless fNS behandelt jeden Frame ohne dauerhaften Sitzungskontext. Beide Varianten sind in den Backend-Spezifikationen vorgesehen, stellen aber unterschiedliche Anforderungen an Nachrichtenfluss, Fehlerbehandlung und Betreiberkonfiguration.

Die Roaming Configuration Guidelines TR009 konzentrieren sich auf die Parameter für Stateless Passive Roaming. Dazu gehören Partner-URLs, NetIDs, Richtlinien, Schlüsseltransportoptionen und Geräteeigenschaften. Eine einzige Schaltfläche Roaming an bildet diese Abhängigkeiten nicht vollständig ab.

Handover-Roaming: Die Serving-Rolle wechselt

Beim Handover-Roaming übernimmt der Network Server des besuchten Netzes die Serving-Rolle. Er kann damit die Funkparameter des Geräts steuern und Downlinks flexibler planen. Der Home Network Server bleibt weiterhin Heimatbezug und hält die Verbindung zu Join Server und Application Server.

Der Wechsel stützt sich bei LoRaWAN 1.1 auf einen Rejoin-Request Typ 0 und die HRStart-Nachrichten des Backends. Das Verfahren muss alten und neuen Sitzungskontext sauber übergeben. Der Vergleich LoRaWAN 1.0.x und 1.1 erklärt, warum die zusätzlichen Network Session Keys und Rejoin-Typen dafür relevant sind.

Roaming-basierte Aktivierung

Ein Gerät kann sich auch erstmals über ein besuchtes Netz aktivieren. Die Backend Interfaces beschreiben passive und Handover-basierte Activation-Verfahren. Der vNS leitet die Join-Information zum zuständigen Join beziehungsweise Home Network Server, der Geräteprofil, Richtlinie und Schlüsselkontext prüft.

Das ist nicht dasselbe wie das Roaming einer bereits aktiven Sitzung. Aktivierung muss DevEUI, JoinEUI, MAC-Version, Regionalprofil und Schlüsselableitung korrekt zusammenführen. Ein Fehler an dieser Stelle erzeugt keinen teilweise funktionierenden Datenpfad, sondern verhindert den Aufbau der Sitzung.

Welche Backend-Nachrichten ausgetauscht werden

Die Spezifikation definiert Nachrichtenpaare wie PRStartReq/Ans, PRStopReq/Ans, HRStartReq/Ans, HRStopReq/Ans, HomeNSReq/Ans, ProfileReq/Ans und XmitDataReq/Ans. JoinReq/Ans und RejoinReq/Ans binden den Join Server ein. Die Nachrichten werden als Backend-Objekte zwischen den Rollen transportiert, nicht über den LoRa-Funkkanal zum Endgerät.

XmitDataReq transportiert Up- oder Downlinkdaten zwischen den beteiligten Network Servern. Die Antwort kann unter anderem melden, ob eine Übertragung erfolgreich geplant oder ausgeführt wurde. Ein Betreiber braucht dafür korrelierbare Transaktions-IDs, Zeitstempel und Fehlercodes; sonst lässt sich ein verlorener Downlink nicht einer Funk-, Partner- oder Backendursache zuordnen.

Roaming Hubs reduzieren Punkt-zu-Punkt-Komplexität

Bei vielen Partnern wächst die Zahl bilateraler technischer Verbindungen schnell. Die Technical Recommendation TR010 zum LoRaWAN Roaming Hub beschreibt einen transparenten, zustandslosen Proxy zwischen Network und Join Servern. Der Hub führt keine neuen LoRaWAN-Nachrichtentypen ein, sondern leitet die standardisierten Backend-Nachrichten nach hinterlegten Vereinbarungen weiter.

Zusätzlich kann der Hub Nutzungsdatensätze für die beteiligten Partner erfassen. Er ersetzt aber weder Roamingpolitik noch Verantwortung für Schlüssel und Servicequalität. Ein zentraler Vermittler ist eine weitere kritische Betriebsabhängigkeit und braucht Verfügbarkeit, Monitoring, Mandantentrennung und nachvollziehbare Abrechnung.

Roaming braucht vier Ebenen

Funk: überlappende, regional kompatible Kanäle und erreichbare Gateways

Protokoll: passende LoRaWAN-Version, DevAddr, MIC und Sitzungskontext

Backend: standardisierte Schnittstellen, Routing und erreichbare Partnerendpunkte

Betrieb: Vereinbarung, Richtlinie, Abrechnung, Support und Datenschutz

Regionale Kompatibilität ist eine harte Voraussetzung

Ein EU868-Gerät kann nicht allein durch Roaming in einem US915-Netz arbeiten. Frequenzbereiche, Kanalpläne, Datenraten und regulatorische Grenzen unterscheiden sich. Ein globales Produkt benötigt passende Radiohardware und ein korrekt ausgewähltes Regionalprofil; häufig kommt ein anderer Gerätesku oder eine explizite Regionsumschaltung zum Einsatz.

Auch innerhalb kompatibler Regionen müssen die vom Gerät verwendeten Kanäle mit dem besuchten Netz überlappen. Die Regional Parameters RP002-1.0.5 definieren die Funkpläne, nicht jedoch die kommerzielle Verfügbarkeit eines Roamingpartners.

Downlinks sind im Roaming anspruchsvoller

Der Uplink kann von mehreren fremden Gateways eintreffen und relativ einfach weitergeleitet werden. Für einen Downlink muss das Backend rechtzeitig ein geeignetes Gateway, Frequenz, Datenrate und Empfangsfenster kennen. Bei Klasse A sind RX1 und RX2 eng an den vorherigen Uplink gebunden. Jede zusätzliche Backend-Latenz verkürzt den Planungszeitraum.

Klasse B und C bieten weitere Empfangsmöglichkeiten, verlangen aber aktuellen Routingkontext und ein ausreichendes Downlinkbudget im besuchten Netz. Der Artikel zu den LoRaWAN-Geräteklassen A, B und C zeigt, warum eine höhere Klasse allein keine erfolgreiche Zustellung garantiert.

Sicherheit und Schlüsselzuständigkeit

Das besuchte Netz sollte nur die Schlüssel oder Prüfinformationen erhalten, die es für seine Rolle benötigt. Bei passivem Roaming kann je nach Vereinbarung der fNS die Uplink-MIC selbst prüfen oder Frames zur Prüfung weiterleiten. LoRaWAN 1.1 trennt Serving-, Forwarding- und Encryption-Keys genauer als die 1.0-Linie.

Backend-Verbindungen benötigen zusätzlich Transportabsicherung, Gegenstellenauthentisierung, Zertifikatswechsel und Zugriffsprotokolle. Funkverschlüsselung ersetzt diese Maßnahmen nicht. Auch personenbezogene oder standortbezogene Nutzdaten bleiben durch Roaming denselben Datenschutz- und Zweckbindungsregeln unterworfen wie im Heimnetz.

Roamingrichtlinien entscheiden pro Partner und Gerät

Die Backend-Spezifikation verlangt Richtlinien, die passives Roaming, Handover sowie beide Activation-Varianten erlauben oder ablehnen können. Entscheidungen lassen sich unter anderem nach Partner-NetID und DevEUI treffen. So kann ein Betreiber nur bestimmte Flotten oder Serviceprofile freigeben.

Die European Roaming Guidelines TR008 ergänzen technische Empfehlungen zur Dienstqualität beim passiven Roaming. Solche Leitlinien sind wichtig, weil ein formal erfolgreicher PRStart noch keine Aussage über Latenz, Downlinkquote, Supportzeiten oder Abrechnung trifft.

Private und öffentliche Netze kombinieren

Ein Unternehmen kann auf dem Werksgelände ein privates Netz betreiben und außerhalb öffentliche Abdeckung nutzen. Umgekehrt kann ein öffentlich provisioniertes Gerät auf einem privaten Campus zusätzliche Gateways verwenden. Beide Modelle sind möglich, sofern NetIDs, Adressbereiche, Backendrollen und Vereinbarungen zusammenpassen.

Die Seite zu Anbietern von LoRa-Netzwerken gibt einen allgemeinen Überblick über verschiedene Netzmodelle. Für ein konkretes Roamingprojekt müssen Betreiber danach technisch prüfen, welche Backend-Version, Roamingart, Region und Servicevereinbarung der jeweilige Partner tatsächlich unterstützt.

Roaming ist kein Ersatz für Netzplanung

Fremde Abdeckung kann Lücken schließen, aber sie ist nicht automatisch an jedem kritischen Messpunkt verfügbar. Indoor-Bereiche, Keller, Metallgehäuse und bewegte Assets brauchen weiterhin Funkmessungen. Auch der Ausfall eines Partnernetzes oder Roaming Hubs muss als eigener Zustand sichtbar werden.

Für garantierte betriebliche Abläufe kann eine Kombination aus eigenen Gateways, mehreren Partnernetzen oder einem alternativen Mobilfunkkanal nötig sein. Roaming erweitert die Architektur; es hebt physikalische und regulatorische Grenzen nicht auf.

End-to-End-Test statt reiner Vertragsprüfung

NetIDs, DevAddr-Bereiche, Partnerrollen und zulässige Geräte festlegen
Regionalprofil und Funkkanäle an realen Übergangsgebieten prüfen
aktive Sitzung und roaming-basierte Aktivierung getrennt testen
PRStart, Datenweiterleitung, Downlink und PRStop vollständig protokollieren
bei 1.1 zusätzlich Handover und Rejoin mit Paketverlust verifizieren
Schlüsselzugriff, Zertifikatswechsel und abgelehnte Richtlinienfälle testen
Nutzungsdaten, Abrechnung, Support und Rückkehr ins Heimnetz abgleichen

Ein guter Abnahmetest fährt nicht nur vom Heimnetz in die Fremdabdeckung. Er prüft auch Rückweg, überlappende Gateways, doppelte Uplinks, verspätete Downlinks, Partnerausfall und einen erneuten Join. Erst dann ist sichtbar, ob Funk, Protokoll und Betrieb dieselbe Roamingvorstellung teilen.

Kennzahlen für den laufenden Betrieb

Roamingstarts und Ablehnungen je Partner-NetID und Ergebniscode
Anteil weitergeleiteter Uplinks sowie erkannter Duplikate
Downlink-Erfolgsquote getrennt nach RX1, RX2, B und C
Backend-Latenz vom fNS zum sNS und zurück
aktive Roamingkontexte, Laufzeiten und ungeplante Abbrüche
Nutzungsdatensätze, Abrechnungsdifferenzen und Supportfälle

Diese Kennzahlen müssen mit dem LoRaWAN-Frame-Aufbau und den Serverrollen korrelierbar sein. Sonst bleibt bei einer Störung unklar, ob ein Frame nie gefunkt, vom fNS abgelehnt, im Backend verspätet oder vom sNS wegen MIC beziehungsweise Counter verworfen wurde.

Häufige Fragen

Funktioniert LoRaWAN-Roaming automatisch zwischen allen Netzen?

Nein. Benötigt werden kompatible Funkparameter, eindeutige NetIDs, unterstützte Backend-Schnittstellen, passende Richtlinien und eine Vereinbarung zwischen den Betreibern.

Was ist passives LoRaWAN-Roaming?

Das besuchte Netz stellt Gateways und Frame-Weiterleitung bereit, während der bisherige Serving Network Server die MAC-Schicht und Sitzung kontrolliert.

Was unterscheidet Handover-Roaming?

Beim Handover übernimmt der Network Server des besuchten Netzes die Serving-Rolle. LoRaWAN 1.1 unterstützt den Wechsel mit Rejoin- und Backend-Verfahren.

Braucht LoRaWAN-Roaming eine NetID?

Für netzübergreifende Zusammenarbeit ist eine global zugewiesene NetID wesentlich. Sie unterstützt die Zuordnung der DevAddr und das Routing zum möglichen Heimnetz.

Ist der Empfang durch mehrere Gateways bereits Roaming?

Nicht unbedingt. Mehrere Gateways desselben Network Servers sind normale Makrodiversität. Roaming beginnt bei der Zusammenarbeit unterschiedlicher Network-Server-Domänen.