LoRa und LoRaWAN: Energieeffiziente, sichere und reichweitenstarke Datenübertragung

LoRa (Long Range) ist eine von SEMTECH entwickelte Funktechnologie, die heutzutage immer mehr zur Übertragung von Daten in unterschiedlichen IT- und Industriebereichen angewandt wird. Während LoRa eine physikalische Schicht der Kommunikation darstellt, bezeichnet LoRaWAN (Long Range Wide Area Network) den gesamten Netzwerkaufbau. In dieser Entwicklernotiz möchte ich gerne einen Blick auf die Bestandteile des LoRa-Netzwerkes, das Arbeitsprinzip der LoRa-Funktechnologie, den Kommunikationsverlauf und Anwendungsbeispiele werfen.

LoRa-Funktechnologie

Als erstes ist es sinnvoll, die physikalische Schicht der LoRaWAN-Kommunikation, wofür die LoRa-Funktechnologie zuständig ist, näher zu untersuchen. LoRa wurde von Semtech entwickelt und basiert auf der Chirp Spread Spectrum-Modulationstechnik. Den Begriff kann man in "Chirp" und "Spread Spectrum" aufteilen und genauer betrachten.

CHIRP - Compressed High Intensity Radiated Pulse

Ein Chirp (zu Deutsch "Zirpe", ein Synonym zu "Zikade") bezeichnet ein Signal mit zeitlich veränderlicher Frequenz. Dabei wird zwischen positiven Chirps (oder "Up-Chirps") - Signalen mit zunehmender Frequenz - und negativen Chirps (oder "Down-Chirps") - Signalen mit abnehmender Frequenz - unterschieden (Abb. 1, 2).

Abb. 1: Chirp-Impuls gegen Zeit für jeweils positive (links) und negative (rechts) Chirps.

Chirps besitzen einige Eigenschaften, die die physikalische Schicht der Kommunikation innerhalb des LoRaWAN-Netzwerks festlegen. Grundlegende Charakteristiken sind Bandbreite und Spreading Factor (SF). Bandbreite ist prinzipiell die Signalfrequenzänderung, wobei der Spreading Factor die Zeit ist, während der diese Änderung geschieht. Bei einer LoRa-Übertragung kann der Spreading Factor entprechend eingestellt werden, was zusätzliche Flexibilität bei Anpassung an unterschiedliche Situationen und Umgebungen bietet. Beispielsweise ermöglicht ein höherer SF eine höhere Datenrate, gleichzeitig verliert aber das Signal seinen process gain und damit seine Robustheit gegen äußere Störungen. Unter process gain versteht man das Verhältnis von Spread Bandwith (bzw. Radio Frequency-Bandbreite) zu Unspread (oder Baseband) Bandwith. Ein Signal mit niedrigerem SF ist robuster gegen Störungen und besitzt eine höhere Reichweite, geht aber mit verminderter Datenrate bei der Datenübertragung einher.

Spread Spectrum (Frequenzspreizung)

Der zweite Teil des Begriffs CSS-Modulationstechnik ist Spread Spectrum oder Frequenzspreizung. Damit wird ein Vorgang bezeichnet, bei dem ein Signal mit schmälerer Bandbreite zu einem Signal mit größerer Bandbreite umgewandelt wird. Dieses Verfahren hat eine verringerte spektrale Dichte des Signals zur Folge, was als erster Vorteil Störungen des LoRa-Signals durch andere Funkquellen vermindert.

Der zweite Vorteil dieses Verfahrens ist erhöhte Vertraulichkeit. Für den unbefugten Mithörer ist es nicht nur fast unmöglich, die übertragenden Daten auszulesen, sondern auch schwierig überhaupt zu erkennen, ob eine Übertragung stattfindet. Andererseits erhöht sich bei einer solchen Methode die Komplexität des Datenempfangs. Unter anderem kann das Verfahren bei niedrigen Sendefrequenzen unter Umständen nicht anwendbar sein, obwohl dieses Problem für die LoRa-Übertragung üblicherweise nicht relevant ist, da die Übertragung mit hohen Frequenzen geschieht.

Abb. 2: Dreidimensionale Abbildung von negativen und positiven Chirps.

LoRaWAN - Long Range Wide Area Network

Wie oben erläutert ist LoRa eine von Semtech entwickelte Funktechnologie und etabliert damit die physikalische Schicht der LoRa-Kommunikation. Dagegen beschreibt LoRaWAN den gesamten Netzwerkaufbau sowie die Kommunikation der einzelnen Elemente untereinander. Genauer gesagt geschieht die Kommunikation laut der LoRaWAN-Spezifikationen, die von LoRa Alliance festgelegt sind. Folgende Abbildung 3 veranschaulicht die Struktur des LoRa-Netzwerkes:

Abb. 3: Aufbau des LoRaWAN-Netzwerkes.

Jedes Netzwerk besteht mindestens aus 3 Elementen:

• Endgerät
• Gateway
• Server

In den nachfolgenden Kapiteln werden alle drei oben genannten Elemente im Detail beschrieben.

Endgeräte

LoRaWAN-Endgeräte dienen verschiedensten Einsatzzwecken. Typisches Beispiel eines LoRaWAN-Endgeräts ist ein Sensor, der die gesammelten Sensordaten mit LoRa an den Gateway weiterleitet. Endgeräte können sich stark in ihren Anforderungen unterscheiden, deswegen nutzt LoRaWAN verschiedene Geräteklassen.

Endgeräte der Klasse A

Die Kommunikation mit den Geräten der Klasse A (Abb. 4) wird immer von dem Gerät selbst initiiert. Nachdem das Endgerät ein Uplink-Paket absendet, öffnet sich nach einer kleinen Verzögerung ("RX1 Delay") das erste Empfangsfenster, innherhalb dessen das Gerät die Downlink-Pakete erhalten kann. Falls innerhalb dieses Fensters nichts angekommen ist, öffnet sich nach einer kurzen Verzögerung ("RX2 Delay") das zweite Empfangsfenster. Dieses Verhalten bedeutet, dass das Endgerät sich meistens im Schlafmodus befindet, was den Energieverbrauch drastisch verringert. Das bedeutet, dass die Geräte dieser Klasse sehr lange ohne direkten Stromanschluss arbeiten können. Andererseits passt diese Geräteklasse nicht besonders gut für zeitkritische Anwendungen, bei denen das Endgerät schnell ansprechbar sein soll. Der Grund dafür ist oben beschrieben: Die Empfangsfenster öffnen sich nur für kurze Zeit, nachdem das Gerät ein Paket abgeschickt hat. Wenn der Gateway mehrere Pakete abschicken soll, müssen diese warten, bis das Gerät wieder Daten sendet und die Empfangsfenster sich öffnen. Typische Anwendungsbeispiele sind unterschiedliche Sensoren wie Feuchtigkeitssensor, Temperatursensor, Lichtsensor usw.

Abb. 4: Schematische Darstellung der Kommunikationsstruktur von Endgeräten der Klasse A.

Endgeräte der Klasse B

Die Geräte der Klasse B (Abb. 5) implementieren die Arbeitsweise der Geräte der Klasse A mit zusätzlichen Funktionalitäten, und zwar:

• Periodisch öffnet sich ein zusätzliches Empfangsfenster ("Ping Slot"), innerhalb dessen das Endgerät vom Gateway angesprochen werden kann.
• Um das Endgerät und Gateway zeitlich zu synchronisieren, sodass das Gateway genau weiß, zu welchem Zeitpunkt das Gerät angeprochen werden kann, wird periodisch ein Beacon-Signal vom Endgerät zum Gateway gesendet (Beacon Period).

Die Geräte diese Klasse haben einen höheren Energieverbrauch wegen der zusätzlichen Empfangsfenster und des periodischen Versands von Beacon-Signalen, bieten aber die Möglichkeit, die Kommunikation mit dem Endgerät vom Gateway zu initiieren. Ein typisches Anwendungsbeispiel ist die Fernwartung einer Maschine.

Abb. 5: Schematische Darstellung der Kommunikationsstruktur von Endgeräten der Klasse B.

Endgeräte der Klasse C

Die Geräte der Klasse C (Abb. 6) besitzen den höchsten Energieverbrauch unter allen Klassen, da sie sich praktisch nie im Schlafmodus befinden: Die Geräte dieser Klasse können die Pakete immer empfangen, außer wenn sie selbst am Senden sind. Solche Geräte besitzen die niedrigste Latenz für die Downlink-Pakete, deswegen passen sie gut für zeitkritische Anwendungen. Ein typisches Anwendungsbeipiel sind elektronische Anzeigetafeln an Bushaltestellen.

Abb. 6: Schematische Darstellung der Kommunikationsstruktur von Endgeräten der Klasse C.

Gateways

Im LoRa-Netzwerk spielen Gateways eine Rolle von der Schnittstelle zwischen den Endgeräten und einem LoRa-Server. Hardwaretechnisch sind Gateways mit einem LoRa-Konzentrator ausgestattet, damit sie LoRa-Pakete empfangen können. Nach dem Empfang leiten die Gateways mittels einer Paketweiterleitungs-Software die erhaltenen Pakete an den LoRa-Server weiter, wo sie entsprechend ausgelesen und verarbeitet werden. Es gibt einige schon existierende Paketweiterleitungs-Softwaren:

• Semtech UDP Packet Forwarder: kommuniziert mit dem Server über einen UDP-Port.
• LoRa Basics Station: Sie benutzt sichere WebSockets zur Kommunikation mit dem Server, was die Datenverschlüsselung auf dem Weg vom Gateway zum Server ermöglicht.

Im nachfolgenden Kapitel wird die Kommunikation zwischen Gateway und Server und die allgemeine Struktur eines LoRa-Servers genauer diskutiert.

LoRa-Server

Der LoRa-Server kommuniziert mit dem Gateway (Abb. 7) und verarbeitet die Uplink- und Downlink-Pakete. Der LoRa-Server kann unterschiedlich ausgestattet werden; typischerweise kommuniziert der Gateway mit dem Netzwerk-Server, der für Netzwerkaufgaben wie die Bestätigung der Integrität einer Nachricht anhand MIC (Message Intergrity Code) zuständig ist. Dafür nutzt der Netzwerk-Server einen Network Session Key. Weiter werden die Daten gewöhnlich zum Applikationsserver weitergeleitet, wo die Daten anschließend mit einem App Session Key entschlüsselt und verarbeitet werden können.

Außer dieser typischen Ausstattung, bei der Netzwerk- und Anwendungsserver getrennt sind, können beide Server auch zusammengefasst werden, sodass ein gemeinsamer Server die Aufgaben von beiden übernimmt. Außerdem gibt es manchmal einen zusätzlichen Join-Server, der die Join-Requests verarbeitet.

Abb. 7: Illustration der Kommunikation zwischen den Elementen des LoRaWAN_Netzwerkes.

Kommunikation zwischen dem Server und Gateway

Nun lass uns genauer untersuchen, wie die Kommunikation zwischen dem Server und Gateway implementiert ist.

Upstream-Protokoll

Ein Teil des Upstream-Protokolls sind die Daten, die vom Gateway am Server ankommen (Abb. 8). Um die Daten an den Server weiterzuleiten, wird ein Pakettyp PUSH_DATA benutzt. Das erste Byte aller Pakete ist eine Protokoll-Version. Danach folgen zwei Bytes mit zwei Tokens, die zur Überprüfung der Integrität der Nachricht bei der Kommunikation zwischen dem Server und Gateway dient. Das viertes Byte ist immer der Identifier des Pakettypes.

Tab. 1: Pakettypen und ihre Identifier

Nach dem Gateway-Identifier (die folgenden 8 Bytes) kommt ein JSON-Objekt, das die Daten und Information über das Paket enthält.

Das JSON-Objekt kann eine Liste "rxpk" beinhalten, wenn der Gateway die Pakete vom Endgerät erhalten hat:

{
    "rxpk": [{...}, ...]
}

Diese Liste soll mindestens ein RF (Radio Frequency)-Paket beinhalten. Jedes Element der Liste ist ein Dictionary mit folgenden Keys:

Tab. 2: Keys der Elemente, die in einem RF-Paket in "rxpk" gelistet sind

Das JSON-Objekt enthält auch optional ein "stat"-Dictionary, das die Information und Statistik des Gateway enthält:

{
    "rxpk": [{...}, ...],
    "stat":{...}
}

Die möglichen Felder sind in Tab. 3 aufgeführt.

Tab. 3: Mögliche Felder des Dictionary "stat"

Nachdem das PUSH_DATA-Paket vom Server anerkannt wurde, sendet der Server ein "PUSH_ACK"-Paket an den Gateway.

Abb. 8: Upstream-Kommunikationsverlauf zwischen einem Gateway und einem Server: Weiterleitung des Upstream-Paketes an den Server.

Downstream-Protokoll

Das Downstream-Protokoll regelt den Empfang von Paketen vom Server beim Gateway. Einmal pro einer bestimmten Periode ("keepalive time") sendet der Gateway ein "PULL_DATA"-Paket an den Server. Damit fragt der Gateway prinzipiell nach, ob es Pakete gibt, die der Gateway emittieren soll. Wenn ein PULL_DATA-Paket vom Server anerkannt wird (Abb. 9), sendet der Server dem Gateway ein "PULL_ACK"-Paket. Dieser Mechanismus dient außerdem dafür, dass die Kommunikation zwischen dem Server und Gateway überprüft werden kann: Basierend auf der Rate von anerkannten Datenpaketen zu empfangenen Datenpaketen kann man die Verbindungsqualität abschätzen. Diese Statistik wird vom Gatewayserver in bestimmten Intervallen abgeschickt; die Bottomline dieser Statistik muss man selbst ziehen.

Jedes Mal nach dem PULL_DATA-Paket vom Gateway kann ein "PULL_RESP"-Paket vom Server am Gateway ankommen, wenn es Pakete gibt, die vom Gateway an ein Endgerät emittiert werden sollen. Das "PULL_RESP"-Paket enthält ein JSON-Objekt mit einem "txpk"-Dictionary, das die Information und Daten des zu emittierenden Paketes beinhält (Abb. 10):

{
 "txpk": {...}
}

Die Informationen und Metadaten, die das Objekt beinhaltet, werden in Tabelle 4 gezeigt.

Tab. 4: Informationen und Metadaten in dem "txpk"-Dictionary, das in dem JSON-Objekt des "PULL_RESP"-Pakets enthalten ist.

Der Gateway antwortet auf das "PULL_RESP"-Paket mit einem "TX_ACK"-Paket. Damit wird mitgeteilt, ob das Paket erfolgreich emittiert werden kann. Wenn das nicht der Fall ist, enthält das "TX_ACK"-Paket ein JSON-Objekt mit dem Fehleridentifier.

Abb. 9: Downstream-Kommunikationsverlauf zwischen einem Gateway und einem Server: Datenabfrage und Paket-Anerkennung

Abb. 10: Downstream-Kommunikationsverlauf zwischen einem Gateway und einem Server: Übermittlung des zu emittierenden Datenpaketes

Zusammenfassung

Dank den zahlreichen Vorteilen wie eine höhere Energieeffizienz, die Robustheit gegen äußere Störungen und Angriffe, die sichere Datenübertragung und eine größe Reichweite verbreitet sich die LoRa-Funktechnologie immer mehr in unterschiedlichen Anwendungsbereichen. Die LoRaWAN-basierten Sensoren können z.B. im meteorologischen Bereich Daten über Luftqualität, Lärmbelastung, Temperatur, Wetterbedingungen, Feuchtigkeit, usw. erfassen, was für das Städte- und Gebäudemanagement sowie Landwirtschaft und Gesundheitswesen angewandt werden kann. Außerdem werden heutzutage LoRaWAN-Netzwerke immer mehr für IoT-Systeme verwendet. Unter anderem sind die Netzwerke für Geräte- und Objektverfolgung einsetzbar, was sie immer populärer in solchen Bereichen wie Logistik, Produktion usw. macht.

Quellenangaben

Alle Abbildungen sind von mir nach folgenden Quellen umgezeichnet:

• Abb. 1 & 2: Enriko, I Ketut & Gustiyana, Fikri & Kurnianingsih, Kurnianingsih & Sari, Erika. (2023). LoRaWAN for Smart Street Lighting Solution in Pangandaran Regency. JOIV : International Journal on Informatics Visualization. 7. 10.30630/joiv.7.4.1198
• Abb. 3: https://lora-alliance.org/wp-content/uploads/2021/10/LA-TC-Stack-01-1024x472.png
• Abb. 4, 5 & 6: https://www.thethingsnetwork.org/docs/lorawan/classes/
• Abb. 7: https://www.mihsv.com/blog/2021/7/26/iot-tektelic-gateway-sensor-setup
• Abb. 8, 9 & 10 sowie Tabellen 1 bis 3: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT