LoRaWAN 1.0.x vs. 1.1: Unterschiede bei Sicherheit, Join und Roaming

LoRaWAN 1.0.x und LoRaWAN 1.1 werden oft wie zwei aufeinanderfolgende Softwareversionen behandelt. Das führt schnell zu einer falschen Entscheidung. LoRaWAN 1.1 erschien zwar später als die frühen 1.0-Versionen, doch die 1.0-Linie wurde anschließend bis 1.0.4 weiterentwickelt. Heute stehen deshalb eine konsolidierte 1.0.4-Spezifikation und die funktional weitergehende 1.1-Spezifikation nebeneinander. Welche Variante passt, hängt von Endgerät, Netzwerkserver, Join Server, Sicherheitsmodell und Roamingbedarf ab.

Auf der Funkseite bleiben beide Varianten eng verwandt. Unterschiede liegen vor allem in Aktivierung, Schlüsselaufteilung, Zählern, Integritätsschutz und Rejoin-Verfahren. Ein Gerät wird also nicht allein durch eine andere Modulation oder größere Reichweite zu einem LoRaWAN-1.1-Gerät. Die Protokollversion betrifft die Zustände, die Gerät und Backend gemeinsam führen müssen.

Kurz zusammengefasst: LoRaWAN 1.0.4 ist nicht einfach eine veraltete Vorstufe von 1.1. Version 1.1 trennt Sicherheitsrollen feiner und ergänzt Rejoin sowie Handover-Roaming. Version 1.0.4 konsolidiert die verbreitete 1.0-Linie und bleibt für viele Geräteflotten relevant. Entscheidend ist die durchgängig unterstützte Kombination, nicht die höchste Versionsnummer auf einem Datenblatt.

Die Versionslinie richtig lesen

Die offizielle LoRaWAN-L2-Spezifikation 1.0.4 trägt den Freigabestand Oktober 2020. Ihr Revisionsverzeichnis nennt unter anderem klarere Empfangsfenster, dauerhaft 32 Bit breite Frame Counter, einen inkrementierenden DevNonce, überarbeitete ADR-Regeln und die Einordnung von Klasse B und C als Ergänzungen zu Klasse A. Sie ist damit weit mehr als der ursprüngliche Stand 1.0 von 2015.

Die LoRaWAN-Spezifikation 1.1 wurde 2017 veröffentlicht. Sie führt unter anderem getrennte Root Keys, mehrere Network Session Keys, Rejoin-Nachrichten und zusätzliche Mechanismen für Roaming und Zustandswiederherstellung ein. Dass 1.0.4 kalendarisch jünger ist, macht 1.0.4 nicht zu 1.2. Beide Dokumente gehören zu unterschiedlichen Entwicklungslinien innerhalb derselben R1-Framefamilie.

Bereich	LoRaWAN 1.0.4	LoRaWAN 1.1	Praktische Folge
Root Keys bei OTAA	ein AppKey	NwkKey und AppKey	Provisionierung und Zuständigkeiten unterscheiden sich
Network Session Keys	NwkSKey	FNwkSIntKey, SNwkSIntKey, NwkSEncKey	Integrität und MAC-Verschlüsselung sind feiner getrennt
Downlink Counter	ein FCntDown	NFCntDown und AFCntDown	Netzwerk- und Anwendungsdownlinks haben getrennte Zähler
Rejoin	erneuter Join nach 1.0.x-Regeln	Rejoin-Request Typ 0, 1 und 2	Roaming, Recovery und Rekeying werden gezielter unterstützt
Roaming	passives Roaming über Backend möglich	zusätzlich Handover-Unterstützung	Netzwerkrollen können anders verteilt werden
Class B	vollständig in 1.0.4 enthalten	enthalten	Klasse B ist kein exklusives 1.1-Merkmal

Warum das Major-Bit die Minor-Version nicht verrät

Im MAC Header belegen die Major-Bits nur zwei Stellen. Sowohl 1.0.x als auch 1.1 verwenden dort den Wert 00 für LoRaWAN R1. Die genaue Minor-Version wird dem Network Server außerhalb des Funkframes über ein Geräteprofil oder die Bereitstellung bekannt gemacht. Ein Paketmitschnitt kann daher nicht allein aus dem Major-Feld zuverlässig ableiten, ob das Gerät als 1.0.4 oder 1.1 betrieben wird.

Das ist bei Fehlersuche und Migration wichtig. Ein Server muss die passende Zählerlogik, Schlüsselableitung und MIC-Prüfung anwenden. Eine falsche Profilversion kann wie ein Funkproblem aussehen, obwohl der Gateway das Paket korrekt empfangen hat. Der vertiefende Beitrag zum LoRaWAN MAC Layer und zur Frame-Struktur zeigt, welche Felder tatsächlich übertragen werden.

Schlüsselmodell in LoRaWAN 1.0.4

Bei OTAA besitzt ein 1.0.4-Gerät einen individuellen AppKey. Aus ihm entstehen nach einem erfolgreichen Join der Network Session Key NwkSKey und der Application Session Key AppSKey. Der NwkSKey sichert unter anderem die Integrität von Datenframes und verschlüsselt MAC-Kommandos, wenn sie im FRMPayload auf Port 0 transportiert werden. Der AppSKey schützt die eigentliche Anwendungsnutzlast.

Das Modell trennt Netzwerk- und Anwendungsdaten grundsätzlich, bündelt aber mehrere Netzwerkaufgaben in einem NwkSKey. Für viele private Netze ist das handhabbar. In geteilten oder netzübergreifenden Architekturen entstehen daraus jedoch weiter reichende Schlüsselzuständigkeiten, weil derjenige mit dem NwkSKey mehrere Netzwerkfunktionen ausführen kann.

Schlüsselmodell in LoRaWAN 1.1

LoRaWAN 1.1 teilt die Root- und Session-Schlüssel feiner auf. Der NwkKey dient zur Ableitung von FNwkSIntKey, SNwkSIntKey und NwkSEncKey. Der separate AppKey leitet den AppSKey ab. Damit kann die Anwendungshoheit deutlicher von Netzwerkfunktionen getrennt werden: Der Netzwerkbetreiber muss den AppKey nicht kennen, um den Join auf Netzwerkseite zu unterstützen.

Die vier Session Keys von LoRaWAN 1.1

• FNwkSIntKey: Integritätsanteil für Uplinks auf der Forwarding-Seite
• SNwkSIntKey: Integritätsfunktionen des Serving Network Servers
• NwkSEncKey: Verschlüsselung von MAC-Kommandos und FOpts
• AppSKey: Ende-zu-Ende-Schutz der Anwendungsnutzlast

Diese Trennung erhöht nicht automatisch die Sicherheit eines schlecht betriebenen Systems. Root Keys müssen weiterhin individuell erzeugt, geschützt bereitgestellt und bei Verlust eines Geräts beherrscht werden. Secure Elements oder HSMs können dabei helfen, sind aber eine Implementierungsentscheidung außerhalb der reinen Funkdefinition.

Join, OptNeg und Abwärtskompatibilität

Ein 1.1-fähiges Endgerät kann mit einem älteren Network Server in einen 1.0-kompatiblen Modus fallen. Das OptNeg-Bit im DLSettings-Feld des Join-Accept signalisiert, welches Verfahren verwendet wird. Bei OptNeg gleich null leitet das Gerät die Schlüssel nach dem 1.0-Schema ab und setzt die zusätzlichen Network Session Keys effektiv auf denselben Wert. Bei OptNeg gleich eins wird der 1.1-Sicherheitskontext aufgebaut.

Abwärtskompatibilität ist damit im Standard vorgesehen, muss aber als konkrete Gerätekombination getestet werden. Join Server, Network Server, Gerätestack und Provisionierungsdaten müssen dieselbe Erwartung teilen. Auch ein formal dualer Stack kann scheitern, wenn etwa der falsche Root Key hinterlegt, eine Minor-Version im Geräteprofil falsch gesetzt oder der JoinNonce-Zustand verloren wurde.

Nonces und Zustandskonsistenz

Ein Join darf keine alte Sitzung unbemerkt wiederbeleben. LoRaWAN 1.0.4 verlangt deshalb einen mit jedem Join-Request inkrementierenden DevNonce; der Server muss bereits verwendete Werte erkennen. Die technische Empfehlung der LoRa Alliance zu Synchronisationsproblemen beim 1.0.x-Join erläutert, warum nichtflüchtige Zustände auf Gerät und Backend sorgfältig behandelt werden müssen. Ein Zurücksetzen auf einen alten DevNonce-Stand kann reguläre Joins blockieren oder Sicherheitsannahmen verletzen.

LoRaWAN 1.1 definiert zusätzliche Rejoin-Zähler und macht Nonces zu geordneten Zählern. Das verbessert die Protokollkontrolle, erhöht aber die Anforderungen an persistente Speicherung. Ein Firmwaretausch, Werkreset oder Geräteersatz braucht daher ein klares Verfahren für Schlüssel und Zähler. Einfach nur die Anwendungskonfiguration zu kopieren reicht nicht.

Frame Counter und Integritätsschutz

LoRaWAN 1.0.4 führt einen Uplink Counter FCntUp und einen gemeinsamen Downlink Counter FCntDown. Die Zähler sind 32 Bit breit, auch wenn im Frame nur die unteren 16 Bit stehen. Der Empfänger rekonstruiert die oberen Bits aus seinem Sitzungszustand. Wiederverwendung mit denselben Session Keys ist außerhalb definierter Wiederholungen verboten.

LoRaWAN 1.1 trennt Downlinks in NFCntDown für Netzwerkkommunikation und AFCntDown für Anwendungsports. Außerdem fließen bei der Uplink-MIC-Berechnung zusätzliche Informationen wie Sendedatenrate, Kanalindex und gegebenenfalls der bestätigte Frame Counter ein. Der MIC wird aus Anteilen berechnet, die mit Serving- und Forwarding-Schlüsseln geschützt sind. Diese Aufteilung unterstützt die getrennten Rollen im Backend und erschwert bestimmte Manipulationen an bestätigten Frames.

FOpts: sichtbar in 1.0.4, verschlüsselt in 1.1

MAC-Kommandos können in den bis zu 15 Byte langen FOpts eines Datenframes mitgeführt werden. In LoRaWAN 1.0.4 sind diese piggyback übertragenen Optionen nicht verschlüsselt; vertrauliche MAC-Kommandos gehören stattdessen in ein mit NwkSKey verschlüsseltes FRMPayload auf FPort 0. LoRaWAN 1.1 verschlüsselt FOpts mit dem NwkSEncKey.

Für 1.1 muss zusätzlich die offizielle Errata zur FOpts-Verschlüsselung und FCntDwn-Nutzung berücksichtigt werden. Genau solche Korrekturdokumente zeigen, weshalb eine Implementierung nicht nur nach einer Versionsbezeichnung ausgewählt werden sollte. Entscheidend sind der konkrete Stackstand, bekannte Errata, Zertifizierung und Interoperabilitätstests.

Rejoin und Wiederherstellung in LoRaWAN 1.1

LoRaWAN 1.1 kennt Rejoin-Request Typ 0, 1 und 2. Typ 0 unterstützt den Wechsel des Serving Network Servers beim Handover-Roaming. Typ 1 hilft bei der Wiederherstellung des Backend-Zustands, und Typ 2 kann eine Erneuerung der Session Keys anstoßen. Der Rejoin wird vom Endgerät initiiert; ein Network Server kann ihn über MAC-Kommandos beeinflussen oder anfordern.

Ein Rejoin ist kein beliebiger Neustart. Während des Übergangs müssen alter und neuer Sicherheitskontext so lange koordiniert werden, dass ein Join-Accept sicher zugestellt werden kann. Dafür braucht das Backend einen Join Server und klar definierte Rollen. Im einfachen privaten 1.0.4-Netz ist diese zusätzliche Komplexität oft nicht erforderlich; bei mobilen, organisationsübergreifenden Geräten kann sie dagegen entscheidend sein.

Roaming ist mehr als eine Protokollversion

Passives Roaming lässt sich laut LoRaWAN Backend Interfaces 1.1 sowohl mit 1.0- als auch mit 1.1-Endgeräten abbilden. Das fremde Netz leitet Funkframes weiter, während der Serving Network Server der Heimatorganisation die MAC-Kontrolle behält. Handover-Roaming nutzt dagegen 1.1-Funktionen, um die Serving-Rolle an ein anderes Netz zu übertragen.

Dazu kommen NetIDs, Backend-Schnittstellen, Verträge, Routing, Abrechnung und kompatible regionale Funkparameter. Der ausführliche Beitrag zu den LoRaWAN-Roaming-Funktionalitäten trennt diese Rollen. Ein Gerät mit Versionsangabe 1.1 roamt nicht automatisch in jedem erreichbaren LoRaWAN-Netz.

Class B und ADR sind kein einfacher Versionsfilter

Frühe 1.0-Stände hatten bei Klasse B Lücken. LoRaWAN 1.0.3 übernahm die Class-B-Kapitel aus 1.1, und 1.0.4 enthält Klasse B vollständig. Wer geplante Empfangsfenster benötigt, muss daher nicht allein deshalb 1.1 wählen. Die Detailanalyse der Geräteklassen A, B und C betrachtet Energie, Latenz und Netzinfrastruktur unabhängig von der Versionsentscheidung.

Beim ADR ergänzt 1.1 das Kommando ADRParamSetupReq, mit dem ADR_ACK_LIMIT und ADR_ACK_DELAY verändert werden können. 1.0.4 präzisiert dagegen den Backoff der 1.0-Linie. Die eigentliche Netzwerkstrategie zur Auswahl von Datenrate und Sendeleistung bleibt in beiden Fällen eine Implementierungsfrage. Mehr dazu erklärt der ADR-Mechanismus im Detail.

Welche Version für ein neues Projekt passt

Für ein geschlossenes Netz mit etablierten 1.0.4-Geräten, überschaubarem Backend und ohne Handover-Roaming kann 1.0.4 die pragmatische Wahl sein. Die größere Geräteauswahl oder ein bereits zertifizierter Stack kann wichtiger sein als zusätzliche Funktionen, die nicht genutzt werden. Eine saubere OTAA-Provisionierung und persistente Counter bleiben trotzdem Pflicht.

LoRaWAN 1.1 ist interessant, wenn getrennte Netzwerkrollen, Rejoin, Handover-Roaming oder das feinere Schlüsselmodell konkret gebraucht und von allen Komponenten unterstützt werden. Die Beschaffung sollte nicht nur die Funkversion abfragen, sondern den vollständigen Satz aus L2-Version, Regional Parameters, Geräteklasse, Aktivierungsart, unterstützten MAC-Kommandos, Errata und Backendprofil. Die aktuellen Regional Parameters RP002-1.0.5 sind ein eigenes Begleitdokument und nicht mit der L2-Version zu verwechseln.

Vor der Freigabe gemeinsam testen

• OTAA mit korrektem OptNeg-Verhalten und individuellen Root Keys
• Neustart, Stromverlust und persistente Nonces beziehungsweise Frame Counter
• bestätigte und unbestätigte Up- und Downlinks mit Wiederholungen
• MAC-Kommandos in FOpts und auf FPort 0 einschließlich Errata
• Geräteprofil, Join Server und Network Server in exakt der geplanten Kombination
• Roaming- oder Rejoin-Abläufe unter Paketverlust, falls sie tatsächlich benötigt werden

Migration ohne Versionsetikett-Falle

Eine bestehende Flotte wird selten in einem Schritt umgestellt. Sinnvoll ist eine Kompatibilitätsmatrix pro Gerätetyp und Firmware: Welche Version wird nativ gesprochen, welcher Fallback ist implementiert, welche Schlüssel sind provisioniert und welche Serverfunktionen wurden nachgewiesen? Danach folgt eine kleine Canary-Gruppe im realen Netz.

Der Erfolg zeigt sich nicht daran, dass Pakete im Gateway-Log auftauchen. Join-Erfolg, Counter-Konsistenz, MIC-Fehler, Downlinkzustellung, Batterieverhalten und Wiederanlauf nach Störungen müssen zusammen stimmen. Erst dann ist aus einer Versionsangabe ein betreibbares System geworden.

Häufige Fragen

Ist LoRaWAN 1.1 automatisch die bessere Wahl?

Nein. LoRaWAN 1.1 bietet zusätzliche Sicherheits- und Rejoin-Funktionen, benötigt dafür aber durchgängige Unterstützung in Gerät und Backend. Für viele etablierte Flotten ist 1.0.4 weiterhin eine passende und gut unterstützte Variante.

Ist LoRaWAN 1.0.4 älter als LoRaWAN 1.1?

Die 1.1-Spezifikation erschien 2017, die konsolidierte 1.0.4-Spezifikation 2020. Funktional gehört 1.1 dennoch zur weitergehenden Protokolllinie; die Versionsnummern sind nicht als einfache chronologische Reihe zu lesen.

Kann ein LoRaWAN-1.1-Gerät in einem 1.0-Netz arbeiten?

Die Spezifikation sieht einen 1.0-kompatiblen Fallback über das OptNeg-Bit im Join-Accept vor. Ob er praktisch funktioniert, hängt vom Gerätestack, den hinterlegten Keys und dem Serverprofil ab und muss getestet werden.

Was ist der wichtigste Sicherheitsunterschied?

LoRaWAN 1.1 trennt NwkKey und AppKey sowie mehrere Network Session Keys. Dadurch lassen sich Netzwerkrollen, Integrität und MAC-Verschlüsselung feiner voneinander abgrenzen.

Braucht Class B zwingend LoRaWAN 1.1?

Nein. LoRaWAN 1.0.3 übernahm die Class-B-Spezifikation, und LoRaWAN 1.0.4 enthält die vollständigen Class-B-Funktionen.