LoRaWAN ist ein verschlüsseltes, energieeffizientes Funkprotokoll, welches für die Datenübertragung von Sensoren verwendet wird. Eine LoRaWAN Nachricht (Telegramm) besteht aus mehren Headern, einer verschlüsselten Payload und vier weiteren Bytes, welche als MIC (Message Integrity Code) zur Verifizierung des Absenders verwendet werden. In diesem Artikel wird der Aufbau eines LoRaWAN Uplink Telegramms mit allen zugehörigen Bestandteilen beschrieben und eine FRM-Payload erstellt, wie sich auch in der Praxis von einem Endgerät generiert wird.

Physiches LoRaWAN Telegramm

Die LoRaWAN Physical Payload besteht aus mehreren Komponenten, welche zur Übertragung von Daten auf der physischen Ebene dienen. Zuerst signalisiert eine Preamble dem Empfänger, dass ein LoRa Telegramm gesendet wird. Dadurch wird eine Synchronisation zwischen Sender und Empfänger hergestellt. Anschließend folgt ein PHDR (Physical Header), welcher Metadaten zur Übertragung, wie beispielsweise die Modulationseinstellungen enthält. Der PHDR_CRC stellt die Integrität des Headers sicher. Die eigentliche PHYPayload beinhaltet die verschlüsselte LoRaWAN Nachricht und Steuerinformationen. Abschließend sichert beim Uplink und fallweise auch beim Downlink die CRC (Cyclic Redundancy Check) die Integrität der gesamten Nachricht. Während einige dieser Teile, wie der Preamble, PHDR und die CRCs direkt vom LoRa-Chip generiert werden, muss die PHYPayload einschließlich Verschlüsselung und Formatierung von der Anwendung bereitgestellt werden. Zusammengefasst sieht ein LoRaWAN Telegramm, wie es per Funk übertragen wird, wie folgt aus:

Übersicht PHYPayload

Die Physical Payload (PHYPayload) besteht aus drei Segmenten (MHDR, MACPayload oder JOIN Request/Response und einem MIC). Der MHDR besteht aus einem Byte, der MIC aus vier Byte. Die Größe der MACPayload ist abhängig von der Größe der eigentlichen Payload und von möglichen zusätzlichen Optionen, welche auf maximal 15 Bytes limitiert sind. Join Request und Join Response besitzen eine feste Größe, werden aber in einem zukünftigen Artikel erklärt und daher nicht weiter erläutert.

MHDR - MAC Header

Der MHDR (MAC Header) ist der erste Teil der PHYPayload in einer LoRaWAN-Nachricht und besteht aus einem einzigen Byte. Er enthält wichtige Informationen zur Nachrichtentypisierung und Protokollversion. Das Byte ist in drei Felder unterteilt:
MType (Message Type): Gibt den Typ der Nachricht an, z. B. Join-Request, Unconfirmed Uplink uvm.
RFU (Reserved for Future Use): Reserviert für zukünftige Erweiterungen.
Major: Gibt die Version des LoRaWAN-Protokolls an. Der Wert ist in aktuellen Versionen üblicherweise 00 (LoRaWAN 1.0.x).

Der MHDR legt somit die grundlegenden Rahmenbedingungen der Kommunikation fest und wird bei der Entschlüsselung und Verarbeitung der Nachricht berücksichtigt.

Praxisbeispiel: Im restlichen Verlauf von diesem Artikel wird eine Payload anhand der verfügbaren Informationen gebildet. In der Praxis würde ein Unconfirmed Uplink Telegramm die ersten drei Bits auf 010 setzen. Die nächsten drei Bits sind RFU, also 000. Die letzten zwei Bits definieren die LoRaWAN-Version (00=R1). Daraus ergibt sich eine Binärzahl von 01000000, welche umgerechnet in Hexadezimal 0x40 ergibt. Das erste Byte in Hexadezimal ist 40.

MACPayload

Die MACPayload ist der zentrale Teil einer LoRaWAN-Nachricht und enthält die eigentlichen Daten sowie Steuerinformationen und besteht aus drei Komponenten:

Device Address: Die ersten vier Byte im Frame Header (FHDR) stellen die Device Address (DevAddr) dar. Sensoren in ABP-Mode haben eine fixe Adresse, Sensoren im OTAA-Mode bekommen diese vom Netzwerkserver mit dem JOIN-Response zugewiesen. Bei der DevAddr werden die Bytes im Little-Endian-Format übertragen, was bedeutet, dass das Least Significant Byte (LSB) zuerst kommt und das Most Significant Byte (MSB) zuletzt. Dieses Format ist typisch für die meisten LoRaWAN-Protokollfelder, um die Verarbeitung für Mikrocontroller zu vereinfachen. Viele Netzwerkserver verwenden bestimmte Adressbereiche, so beginnt die Adresse jeder Node mit TTN mit 26 oder 27.

In der Praxis wird die gewünschte Bytefolge vertauscht. Aus 0xAA .. 0xDD wird 0xDD .. 0xAA. Die Payload mit MHDR (40) lautet jetzt: 40 DD CC BB AA.

FCTRL: Der Frame Control enthält Steuerinformationen für Netzwerkserver und Endgerät:

Bei der Bitaufteilung gibt es Unterschiede zwischen Downlink und Uplink Telegrammen. Die folgende Tabelle beschreibt die einzelnen Segmente vom FCTRL Byte:

Unterstützt das Endgerät ADR und es handelt sich bei der Nachricht um ein Uplink Telegramm, würde die Binärzahl dieses Bytes wie folgt aussehen: 1000000. In Hexadezimal ergibt das folgende Zahl: 0x80. Die vollständige PHYPayload würde wie folgt aussehen: 40 DD CC BB AA 80

FCNT: Der Frame Counter wird mit jeder Nachricht um eine Ziffer erhöht. Uplink und Downlink Telegramme haben jeweils einen eigenen Zähler. Der Frame Counter besteht aus 2 Byte:

Der Frame Counter wird bei der Verschlüsselung berücksichtigt und dient dazu, Nachrichten eindeutig zu machen. Der Netzwerkserver überprüft, ob der empfangene Zählerwert größer als der vorherige, gespeicherte Wert ist, um sicherzustellen, dass es sich nicht um eine alte Nachricht handelt. Wenn der Zähler den Maximalwert (65.535) erreicht, beginnt er mit 0 wieder von vorne. In der Praxis sorgt der FCnt für die Integrität und Sicherheit der Kommunikation und schützt vor Wiederholungsangriffen (Replay-Angriffen).
Für das Praxisbeispiel wird ein Uplink Telegramm angenommen und der Zähler soll den Stand 1 haben. Der Frame Counter besteht aus zwei Bytes, was bei dieser Annahme eine Hexadezimalzahl von 0x00 und 0x01 darstellt. Gleich wie bei der DevAddr werden auch beim Frame Counter die Bytes vertauscht und die zwei Bytes setzten sich aus 0x01 und 0x00 zusammen. Die vollständige PHYPaylod sieht wie folgt aus: 40 DD CC BB AA 80 01 00

Frame Options: Das FOpts-Feld ist ein optionaler Bestandteil des Frame Headers (FHDR) in einer LoRaWAN-Nachricht und kann bis zu 15 Byte umfassen. Es dient dazu, MAC-Kommandos zwischen dem Endgerät und dem Netzwerk auszutauschen, beispielsweise zur Optimierung der Verbindung oder Anpassung von Parametern. Ein praktisches Beispiel ist die Synchronisation der Uhrzeit: Das Netzwerk kann über das FOpts-Feld ein Kommando senden, um dem Endgerät eine neue Systemzeit mitzuteilen. Ebenso können Steuerbefehle wie Frequenzwechsel, Aktivierung von ADR oder eine Aufforderung zur Bestätigung gesendet werden. Die Länge des Feldes wird durch das FOptsLen-Feld im FCtrl angegeben. Da sich das FOpts-Feld vor der verschlüsselten Nutzlast befindet, beeinflusst es nicht die Datenintegrität der eigentlichen Nutzdaten. Es ermöglicht eine effiziente Übertragung von Steuerinformationen, ohne zusätzliche Nachrichten senden zu müssen. Die Uplink Nachricht vom begleitenden Praxisbeispiel umfasst keine Options, daher bleibt die PHYPayload vorerst unverändert.

Frame Port: Der Frame Port (FPort) ist ein 1-Byte-Feld in einer LoRaWAN-Nachricht, das den Zweck der Nachricht definiert und festlegt, ob diese Anwendungsdaten oder MAC-Kommandos enthält. Ein FPort von 0 signalisiert, dass die FRMPayload ausschließlich MAC-Kommandos enthält, die mit dem NwkSKey verschlüsselt werden. Bei einem FPort von 1 bis 223 enthält die FRMPayload hingegen Anwendungsdaten, die mit dem AppSKey verschlüsselt sind. Der Port ermöglicht die Zuordnung von Nachrichten zu spezifischen Diensten oder Anwendungen, wie etwa der Übertragung von Sensordaten oder Steuerbefehlen.

Für das Praxisbeispiel soll die Nachricht den FPort 01 verwenden. Die PHYPayload setzt sich damit wie folgt zusammen: 40 DD CC BB AA 80 01 00 01

FRMPayload: Die FRMPayload ist der Teil einer LoRaWAN-Nachricht, der die eigentlichen Nutzdaten enthält. Sie kann entweder Anwendungsdaten oder, falls der Frame Port (FPort) auf 0 gesetzt ist, MAC-Kommandos enthalten. Die Nutzlast wird immer verschlüsselt übertragen, um die Vertraulichkeit und Sicherheit der Daten zu gewährleisten.

Im Uplink enthält die FRMPayload typischerweise die von einem Sensor oder Endgerät generierten Daten wie z. B. Temperatur- oder Standortinformationen. Im Downlink kann sie Steuerdaten oder Konfigurationsanweisungen vom Netzwerk zum Endgerät übertragen. .

Die Verschlüsselung der FRMPayload erfolgt mit dem AppSKey, sofern Anwendungsdaten übertragen werden, oder mit dem NwkSKey, wenn MAC-Kommandos enthalten sind. Dadurch wird sichergestellt, dass nur autorisierte Parteien die Nutzdaten entschlüsseln und verarbeiten können. Der genaue Inhalt und Zweck der FRMPayload hängt vom jeweiligen Anwendungsfall ab und wird durch das Protokoll flexibel gestaltet.

Die obere Grafik zeigt zuerst die unverschlüsselte Payload (01 23 AB CD F0) an. Mit dem App Session Key (AppSKey) wird die Payload verschlüsselt und lautet jetzt: B4 3D 27 16 23. Die PHYPayload für dieses Beispiel wird um 5 Byte erweitert und setzt sich wie folgt zusammen: 40 DD CC BB AA 80 01 00 01 B4 3D 27 16 23

MIC

MIC (Message Integrity Code) ist ein 4-Byte-Feld am Ende der LoRaWAN-Nachricht, welches die Integrität und Authentizität der Nachricht sicherstellt. Sie wird basierend auf einem AES Algorithmus berechnet, der den NwkSKey (Network Session Key) verwendet. Die MIC schützt die Nachricht vor unbefugten Veränderungen und hilft dem Empfänger, zu prüfen, ob die Nachricht von einer vertrauenswürdigen Quelle stammt.

Die MIC wird über die gesamte Nachricht berechnet, einschließlich MHDR, FHDR, FPort und der FRMPayload. Wenn die berechnete MIC am Netzwerkserver nicht mit der empfangenen übereinstimmt, wird die Nachricht verworfen.

Daraus ergeben sich die letzten vier Bytes für die PHYPayload: 16 6C 98 13. Die vollständige Payload mit allen Headern, der Payload und dem MIC lautet in Hexadezimal: 40 DD CC BB AA 80 01 00 01 B4 3D 27 16 23 16 6C 98 13