LoRaWAN – Device Activation Call Flow (Join-Verfahren) mit OTAA und ABP

Wenn zu einem LoRaWAN-Netzwerk ein LoRaWAN Endgerät hinzugefügt wird, muss dieses einen Aktivierungsprozess durchlaufen, um mit dem LoRaWAN-Netzwerkserver zu kommunizieren. Die beiden, für die Kommunikation notwendigen Sitzungsschlüssel, werden während des Aktivierungsprozesses zwischen dem Endgerät und dem Netzwerkserver geteilt.

Es gibt zwei Arten von Aktivierungsmethoden:

  • 1. OTAA – Over-The-Air-Aktivierung
  • 2. ABP – Activation by Personalization

1. OTAA – Over-The-Air-Aktivierung

Beim OTAA-Modus wird vor der Aktivierung der Applikationsschlüssel (AppKey) im LoRaWAN-Netzwerkserver hinterlegt. Mit Hilfe dieser gemeinsamen kryptografischen Basis generiert der LNS die notwendigen Schlüssel und tauscht sie sicher mit dem Endgerät aus. Der AppKey wird dabei niemals per LoRaWAN übertragen, um ihn nicht zu kompromittieren. Die folgende Abbildung zeigt die Join-Prozedur.

Aufbau Join Procedure per OTAA

Schritt 1: Join Request

Das Endgerät startet den Join-Vorgang, indem es eine Join-Request-Nachricht sendet. Diese enthält DevEUI, AppEUI und DevNonce. DevEUI und AppEUI beziehen sich auf den Global End Device bzw. Application Identifier und folgen dem IEEE EUI-64 Adressraumformat.

Die DevNonce ist eine Zufallszahl, die mit jedem Join-Vorgang größer wird. Dazu muss die DevNonce in einem nichtflüchtigen Speicher gespeichert werden. Das Zurücksetzen von DevNonce ohne Änderung von AppEUI führt dazu, dass der Netzwerkserver die Join-Anforderungen des Geräts verwirft. Für jedes Endgerät verfolgt der Netzwerkserver den letzten DevNonce-Wert, der vom Endgerät verwendet wird und ignoriert Join-Anfragen, wenn DevNonce nicht erhöht wurde.

Ein MIC-Wert der Join-Anforderung wird vom Endgerät berechnet. Die Join-Request-Nachricht ist nicht verschlüsselt. Sie kann mit beliebiger Datenrate und nach einer zufälligen Frequency-Hopping-Sequenz über die angegebenen Join-Kanäle übertragen werden.

 

Was steckt in einem Join Request?

Inhalt eines Join Request

Schritt 2: Authentifizierung des Endgeräts

Bei der Authentifizierung und Generierung von Sitzungsschlüsseln führt der Netzwerkserver nach der Join-Anforderung ein Replay-Angriffsverhinderungsprozess auf Basis des DevNonce durch. Wenn die DevNonce in der Join-Anforderung bereits verwendet wurde, schlägt der Join-Prozess fehl und der Netzwerkserver entscheidet, dass die Nachricht ungültig ist. Ist die Nachricht gültig, überprüft der Netzwerkserver das Endgerät mit dem MIC-Wert. War die Prüfung erfolgreich, generiert der Netzwerkserver einen Nwk_SKey und einen App_SKey.

 

Schritt 3: Join Accept

Eine Join-Accept Message enthält neben AppNonce, NetID und DevAddr verschiedene Parameter zur Kommunikation des Endgeräts mit dem Server. Die DevAddr ist eine 32-Bit-Kennung des Endgeräts im aktuellen Netzwerk. Die 7 ersten Bits der DevAddr werden als NwkID bezeichnet. Die anderen Bits können vom Netzwerkserver beliebig gewählt werden. Die DLSettings enthalten mehrere Werte, die sich auf die Downlink-Konfiguration beziehen. RxDelay ist eine Verzögerung zwischen dem Sende- und Empfangsprozess und CFList ist ein optionales Feld, das sich mit Kanalfrequenzen beschäftigt. Schließlich wird die gesamte Join-Annahme-Nachricht mit dem AppKey verschlüsselt.

 

Was steckt in einem Join Accept?

Inhalt Join Accept

Schritt 4: App_SKey Austausch

Da der App_SKey für die sichere End-to-End-Kommunikation zwischen dem Endgerät und dem Anwendungsserver entwickelt wurde, sollte er vom Netzwerkserver zum Anwendungsserver übertragen werden. Wann und wie der App_SKey mit dem Anwendungsserver ausgetauscht wird, gibt die LoRa-Spezifikation nicht an. So kann auf die spezifische Implementierung eingegangen werden. Dies kann ein wesentlicher Bestandteil sein und kann daher in das Join-Verfahren einbezogen werden.

 

Schritt 5: Erzeugung der Sitzungsschlüssel

Nach dem Empfangen der Join-Accept-Nachricht, entschlüsselt das Endgerät diese und erzeugt Sitzungsschlüssel unter Verwendung extrahierter Parameter. Damit ist der Join-Prozess abgeschlossen.

2. ABP – Activation by Personalization

ABP ist die Art und Weise, wie ein Endgerät zu einem bestimmten LoRa-Netzwerk gehören kann, ohne unter bestimmten Bedingungen einen Join-Vorgang durchzuführen. Im ABP-Modus verfügt das Endgerät nicht über DevEUI, AppEUI und AppKey, die für das Join-Verfahren unerlässlich sind. Die Aktivierung eines Endgeräts durch Personalisierung bedeutet, dass der DevAddr und die zwei Sitzungsschlüssel Nwk_SKey und App_SKey direkt im Endgerät gespeichert werden, anstatt während des Join-Vorgangs von DevEUI, AppEUI, AppKey und NwkKey abgeleitet zu werden.

Das Endgerät ist bereits beim Start mit den notwendigen Informationen zur Teilnahme an einem bestimmten LoRa-Netzwerk ausgestattet. Jedes Gerät muss einen eindeutigen Satz von Nwk_SKey und App_SKey haben. Der Prozess zur Erstellung der Schlüssel muss so ablaufen, dass die Schlüssel in keiner Weise aus öffentlich zugänglichen Informationen (wie beispielsweise der Knotenadresse oder der DevEUI des Endgeräts) abgeleitet werden können.

Wenn ein personalisiertes Endgerät zum ersten Mal oder nach einer Neuinitialisierung auf das Netzwerk zugreift, muss es den Befehl Reset Ind MAC im Feld FOpt aller Uplink-Nachrichten senden, bis es einen Reset-Konferenzbefehl vom Netzwerk erhält. Nach einer Neuinitialisierung muss das Endgerät seine Standardkonfiguration verwenden (die Konfiguration, die bei der ersten Verbindung des Geräts mit dem Netzwerk verwendet wurde).

Join Verfahren nach APB

Sie haben mehr Fragen?

Beratung anfordern