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

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?

 

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 sieben 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?

 

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.

Over-The-Air-Activation per QR-Code

Die LoRa-Alliance hat das Ziel gesetzt, das Onboarding von Sensoren zu vereinfachen und schlägt als eine gut umsetzbare Methode die Nutzung von QR-Codes vor. Viele Hersteller nutzen diese bereits und machen LoRaWAN damit langfristig zu einer Technik, die nicht nur von Personen mit Fachkenntnissen genutzt werden kann. Die QR-Codes übertragen die notwendingen Informationen und ggf. zusätzliche Elemente wie die Seriennummer des Sensors weiter in einer vereinheitlichten Form.

1.  Schema ID  D0

2.  JoinEUI (ehemals AppEUI):  11-22-33-44-55-66-77-88

3.  DevEUI:  AA-BB-CC-DD-EE-FF-00-11

4.  Profile ID:  AABB-1122

5.  Owner Token:  AABBCCDDEEFF

6.  Seriennummer:  YYWWNNNNNN

7.  Proprietary:  FOOBAR

8.  CheckSum:  AF2C

Das ergibt in dem Beispiel: 

LW: D0 : 1122334455667788 : AABBCCDDEEFF0011 : AABB1122 :O AABBCCDDEEFF :S YYWWNNNNNN :P FOOBAR :C AF2C

Die Schema ID, JoinEUI, DevEUI und Profil ID muss nach dem Standard immer mitgegeben werden, die anderen Angaben sind optional. 

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).