LoRa ist ein drahtloses Übertragungsverfahren mit einer besonders hohen Energieeffizienz und Reichweite. Diese Technologie eignet sich besonders für energieautarke Sensoren, die mit einer Batterie über mehrere Jahre auskommen müssen. LoRaWAN selbst ist ein Netzwerk-Protokoll, also eine Software, die auf der Basis von LoRa Daten überträgt.

LoRaWAN ist ein riesiges und leider oft auch nicht besonders einsteigerfreundliches Themengebiet. Dieser Artikel richtet sich daher speziell an jene Personen, die mit LoRa starten wollen und ihre ersten Sensoren in ein LoRaWAN-Netzwerk wie TTN integrieren wollen.

Wie funktioniert LoRaWAN?

Ein Sensor (zum Beispiel eine Wetterstation) erfasst Daten und sendet diese in einem bestimmten Intervall zu einem LoRaWAN-Gateway. Wird das Datenpaket von mindestens einem Gateway empfangen, so leitet dieses Gateway das Datenpaket an den Netzwerk-Server weiter. Der Netzwerk-Server bildet das eigentliche LoRaWAN-Netzwerk wie TTN, was für den Transport der Sensordaten zuständig ist. Im LoRaWAN-Netzwerk selbst wird dann mindestens eine Schnittstelle zu einem Datenbankserver oder Dienst hinterlegt, an den die empfangenen Daten weitergeleitet werden. Erst der eingerichte Dienst speichert die Daten und kann diese dann auch visualisiert darstellen. Das LoRaWAN-Netzwerk selbst speichert nämlich keine Nutzdaten und ist lediglich für den Transport zuständig. Die Nutzdaten werden im Sensor zu einer Payload encodiert, welche nach der Übertragung in der Regel vom LoRaWAN-Netzwerk selbst wieder decodiert wird. Das Thema Payload wird in weiterer folge noch ausführlicher behandelt.

LoRaWAN ist mit einer 128-Bit AES Verschlüsselung gesichert. Die Verschlüsselung der Payload erfolgt direkt im Sensor und wird erst vom LoRaWAN-Netzwerk (bei TTN in der Application) wieder entschlüsselt. Ein Mitlesen der Datensätze ist weder per Funk noch von einem Gateway-Besitzer möglich. Nach der Entschlüsselung vom Netzwerk-Server werden die Daten an den jeweils angeschlossenen Dienst/Server weitergesendet. Auch hier kommt in der Regel eine Verschlüsselung (beispielsweise HTTPS) zum Einsatz.

Grundsätzlich sind in allen Netzbereichen bidirektionale Verbindungen möglich. Das bedeutet, dass auch von einer Anwendung oder dem LoRaWAN-Netzwerk aus Daten an einen Sensor gesendet werden können. Allerdings funktioniert das nicht in Echtzeit, sondern zeitversetzt, sobald der Sensor ein Empfangsfenster öffnet. Je nach LoRaWAN-Klasse gibt es dafür bestimmte Zeitfenster, wo ein Sensor empfangsbereit ist. Bei der Klasse A gibt zum Beispiel nach einem Uplink zwei Zeitfenster für einen Downlink, wo Daten vom LORaWAN-Netzwerk an den Sensor gesendet werden können.

Was brauche ich für LoRaWAN?

Damit man überhaupt Daten in das LoRaWAN-Netzwerk senden kann, wird ein Endgerät benötigt. Das Endgerät wird meistens als Node oder Sensor bezeichnet. Hier gibt es bereits Tausende fertige Sensoren von vielen verschiedenen Herstellern am Markt. Versierte Bastler, die heutzutage auch als Maker bezeichnet werden, können sich auch ihre eigenen Sensoren mit einem Arduino oder ESP-Board bauen. Nachdem man sich für einen Sensor entschieden hat, stellt sich nun die Frage, in welches Netzwerk man diesen Sensor integrieren will. Grundsätzlich ist jeder handelsübliche Sensor auch mit jedem LoRaWAN-Netzwerk kompatibel, man muss ich also hier keine Sorgen machen, dass der Sensor nicht mit einem bestimmten Netzwerk kompatibel ist. Wichtig ist nur, dass der Frequenzbereich stimmt. In ganz Europa wird dafür das 868 MHz-Band verwendet.

Die verschiedenen LoRaWAN-Netzwerke

Weltweit existieren bereits Hunderte verschiedene LoRaWAN-Netzwerke. Diese werden wiederum in öffentliche und private LoraWAN-Netzwerke aufgeteilt. Bei den öffentlichen LoRaWAN-Netzwerken gibt es kostenlose und kostenpflichtige Netzwerke. Außerdem kann auch jede Person oder jedes Unternehmen ein eigenes LoRaWAN-Netzwerk aufbauen und betreiben. Folgende LoRaWAN-Netzwerke sollte man kennen:

TTN - The Tings Network
TTN ist ein globales LoRaWAN Netzwerk, welches sowohl von Privatpersonen als auch von Firmen betrieben wird. Mit Ausnahme vom Enterprise-Bereich steht dieses Netzwerk jedem frei zur Verfügung. Für Einsteiger und Maker ist dieses Netzwerk die erste Adresse, auch weil man hier die meisten Tutorials, die größte Community und somit auch die meiste Unterstützung findet. Übrigens sind mehr als 90 Prozent aller LoRaWAN-Tutorials auf diesem Blog auch für TTN bestimmt.

Helium Netzwerk
Das Helium-LoRaWAN ist ebenfalls ein globales Netzwerk, welches vor allem von Privatpersonen aufgebaut wird. Das Netzwerk ist sehr beliebt, da spezielle Gateways neben LoRaWAN auch als Miner für die Crypto-Währung HNT verwendet werden. Jeder der ein Gateway bzw. einen Hotspot betreibt, verdient sowohl durch das Mining als auch an der Übertragung von LoRaWAN-Paketen Geld. Im Gegensatz zu TTN, wo die Datenübertragung kostenlos ist, wird im Helium-Netzwerk die Datenübertragung verrechnet. Weitere Informationen über dieses Netzwerk gibt es in diesem Artikel: So funktioniert das Helium LoRaWAN.

ChirpStack
ChirpStack ist kein öffentliches LoRaWAN-Netzwerk, aber ein Open Source LoRaWAN-Server. Mit dieser Software kann man sich ein eigenes LoRaWAN-Netzwerk aufbauen. Eine Firma kann zum Beispiel alle Sensoren auf dem Firmenareal mit diesem Netzwerk verbinden und ist damit unabhängig von Internet bzw. einen öffentlichen Anbieter. Mit dieser Software ist man zwar unabhängig, aber man trägt auch nicht zum öffentlichen Ausbau von LoRaWAN-Netzwerken bei.

Private LoRaWAN-Netzwerke
Viele Firmen betreiben lokale oder regionale LoRaWAN-Netzwerke. Immer mehr Mobilfunk-Netzbetreiber rüsten auf den bestehenden Mobilfunkmasten ein LoRaWAN-Gateway nach. Als bekanntes Beispiel kann man hier die Swisscom nennen, welche mittlerweile ein flächendeckendes LoRaWAN-Netzwerk in der Schweiz betreibt. Diese Netzwerke richten sich vor allem an Geschäftskunden und sind daher auch kostenpflichtig.

Das LoRaWAN Gateway

Das Gateway ist die Brücke zwischen Sensor und dem Internet. Empfängt das Gateway ein LoRa-Datenpaket wird dieses umgehend an den vorkonfigurierten Netzwerk-Server weitergeleitet. Aber auch umgekehrt kann der Netzwerk-Server Datenpakete an das Gateway weiterleiten, die anschließend vom Gateway aus zum Sensor gesendet werden. Früher waren die teuren Gateways das große Hindernis für den Ausbau von LoRaWAN-Netzwerken. Heutzutage sind Gateways bereits ab 100 Euro erhältlich. Im Jahr 2015 kostete ein Gateway rund 500 Euro. Eine Ausnahme dabei sind die Gateways für das Helium-Netzwerk, denn diese sind vermutlich wegen der Mining-Funktion erst ab etwa 400 Euro erhältlich.

Braucht man ein eigenes Gateway?

Grundsätzlich nicht, sofern andere Gateways in Reichweite sind. Ein eigenes Gateway ist jedoch sehr zu empfehlen, da:

man zum Ausbau vom öffentlichen LoRaWAN-Netzwerk beiträgt

und man dadurch ein sehr wertvolles Diagnose-Tool für die Fehlersuche erwirbt.

Der zweite Punkt ist insbesondere für Anfänger wichtig, da man nur so feststellen kann, ob der eigene Sensor auch richtig funktioniert. Oft stimmen die Schlüssel oder die Frequenzeinstellung nicht. Beides kann man nur herausfinden, wenn man ein eigenes Gateway hat, wo man auch Zugriff auf das LOG-Protokoll hat. In der Praxis erspart man sich dadurch unzählige Stunden an unnötiger Fehlersuche.

Outdoor vs. Indoor Gateway

Wenn die Möglichkeit besteht, sollte man das Gateway immer an einem hohen Standort im Außenbereich platzieren. Outdoor-Gateways sind robuster und witterungsbeständig und deshalb auch etwas teurer als Indoor-Gateways. Sollte am Gateway eine externe Antenne angeschlossen werden, sollte das Antennenkabel qualitativ hochwertig und so kurz wie nur möglich gehalten werden, um die Verluste zu minimieren. Für den Einstieg reicht aber ein Indoor-Gateway auch aus.

Wie wird ein Gateway eingerichtet?

Diese Einstellungen sind von Hersteller zu Hersteller unterschiedlich. Viele Gateways arbeiten mit einem UPD-Packet-Forwarder. Grundsätzlich muss im Gateway nur die Serveradresse und der Port vom Netzwerkserver hinterleget werden. Beim LoRaWAN-Netzwerk wird in der Regel nur die Gateway-ID angegeben. Weitere Tutorials über die Einrichtung von Gateways gibt es hier:

Das MikroTIK LR8 Gateway & Einrichtung bei TTN V3

Das Dragino LG02 Gateway & Einrichtung bei TTN V2

Fertige Sensoren oder Selbstbau?

Als Anfänger sollte man sich vorerst eher mit fertigen Sensoren beschäftigen, anstatt mit Development-Boards wie dem Arduino oder ESP32. Es gibt zwar für diese Boards und Shields fertige Bibliotheken und viele Beispielcodes, aber diese sind oft nicht besonders einsteigerfreundlich und erfordern mindestens mittlere Programmierkenntnisse in C/C++. Fertige Sensoren bekommt man bereits ab etwa 35 Euro wie zum Beispiel den Dragino LHT65.

Alternativ gibt es das LoRIS-System von ELV. Die LoRIS-Base ist ein Entwicklungsboard auf Basis von STM32 mit vielen Shields. ELV entwickelt hierfür bereits verschiedene fertige Programme, die über USB auf das Board hochgeladen werden. Der Quellcode ist ebenfalls frei erhältlich und kann für eigene Anwendungen angepasst werden. Weitere Informationen zur LoRIS-Base gibt es in diesem Video.

Application bei TTN erstellen

Bevor man überhaupt einen Sensor registrieren kann, muss eine Application angelegt werden. In der Application wird anschließend der Sensor inklusive aller notwendigen Schlüssel gespeichert. Die Application beinhaltet aber nicht nur die Sensoren, sondern auch einen Payload Decoder und die Schnittstellen zu den Diensten und Servern, wo anschließend die Daten abgelegt werden sollen. In einer Application können auch mehrere, insbesondere baugleiche Sensoren registriert werden. Weitere Informationen zur Application gibt es im Artikel über die LoRaWAN Application bei TTN.

Hinweis: Die Application gibt es bei vielen verschiedenen LoRaWAN-Netzwerken. Es gibt aber auch Netzwerke, die als Basis nicht mit einer Application arbeiten, sondern jedem Sensor eine bestimmte Konfiguration zuweisen.

OTTA und ABP

Hierbei handelt es sich um die Art, wie sich der Sensor mit dem LoRaWAN-Netzwerk verbindet. Beide Arten haben dabei ihre Vor- und Nachteile. Während fertige Sensoren in der Regel beide Arten unterstützen, gibt es bei OTTA mit einigen wenigen Gateway-Typen Probleme, die hier in weiterer Folge noch genauer erläutert werden.

ABP (Activation by Personalization)
Bei ABP werden alle Keys (NetworkSessionKey, AppSessionKey & DeviceAddress), welche für die Verschlüsslung und Datenübertragung notwendig sind, statisch im Sensor gespeichert und bleiben immer gleich. Der Sensor verpackt die erfassten Messwerte in eine Payload und verschlüsselt diese mittels AppSessionKey und NetworkSessionKey. Anschließend wird das Datenpaket abgesendet zu TTN oder einem anderen LoRaWAN-Netzwerk und dort wieder entschlüsselt und decodiert. Zusätzlich läuft im Hintergrund sowohl am Server als auch im Endgerät ein Zähler, der mit jeder Aussendung um den Wert 1 erhöht wird. Dieser Zähler wird als Frame Counter bezeichnet und dient zur Sicherheit. Dadurch ist es nicht möglich, ein aufgezeichnetes LoRaWAN-Paket erneut abzusenden (Replay-Attacke). Trotzdem ist ABP aufgrund der statischen Schlüssel weniger sicher als OTTA und wird daher nicht empfohlen.

OTTA (Over The Air Activation)
Bei OTTA stellt der Sensor mittels DevEUI und AppEUI eine Beitrittsanfrage (JOIN-Request) an das LoRaWAN-Netzwerk. Der Server überprüft dabei MIC-Wert und die DevNonce und kann somit die Echtheit des Endgerätes verifizieren. Stimmen alle Parameter, so sendet der Server ein JOIN-Accept mit entsprechender Konfiguration an das Endgerät zurück. Erst dann wird dem Sensor eine Device-Address und alle notwendigen Keys zugewiesen, mit der anschließend die Nutzdaten übertragen werden können. Der JOIN-Request wird über verschiedene zufällig gewählte Kanäle und SF-Werte gestellt. Das Gateway muss daher alle SFs (Spreading Factor) und alle acht Kanäle unterstützen.

ABP bietet die höchste Kompatibilität, da der Datentransfer nur auf einer Frequenz und einem Spreading Factor stattfinden kann. Bei Single-Channel-Gateways ist dies oft die einzige Wahl. Außerdem muss das Gateway keine JOIN-Daten an den Sensor senden, was bei einer schlechten Empfangslage wiederum vorteilhaft sein kann. Abgesehen von der Sicherheit ist der Nachteil bei ABP, dass bei den meisten Sensoren nach einem Batteriewechsel der Frame Counter verloren geht und das LoRaWAN-Netzwerk anschließend alle Datenpakete abweist. Man muss sich in diesem Fall in der TTN-Console einloggen und den FrameCounter dort ebenfalls zurücksetzen.

Der Spreading Faktor (SF)

LoRa verwendet als Modulationstechnik Chirp Spread Spectrum (CSS), zu Deutsch ein Frequenzspreizverfahren. Ein einzelner Chirp-Impuls lässt die Frequenz mit der Zeit ansteigen. Bei einem niedrigen SF ist der Frequenzanstieg im gleichen Zeitfenster schneller als bei einem hohen SF. Der SF-Wert wird in der Regel automatisch vom Sensor gewählt, kann aber auch manuell eingestellt werden. Grundsätzlich gilt: Je höher der SF-Wert ist, desto mehr Reichweite ist möglich. Allerdings dauert auch die Datenübertragung deutlich länger und die Übertragungsgeschwindigkeit sinkt somit. Der SF-Wert kann zwischen 7 und 12 gewählt werden. Grundsätzlich sollte wenn möglich, immer der niedrigste SF-Faktor, also 7 gewählt werden, damit man die Airtime so gering wie möglich hält. Außerdem ist ein niedriger SF-Wert energiesparender, da die Sendezeit kürzer ist. Standardmäßig wird als Bandbreite 125 Kilohertz gewählt.

Die Payload

LoRaWAN ist sehr energiesparend und man versucht deshalb auch die Sendezeit so kurz als möglich zu halten. Dies wird aber nur erreicht, wenn man so viel wie nur möglich an unnötigen Bytes bei der Übertragung einspart.

Ein Beispiel: Möchte man einen Temperatur-Wert übertragen, so hat man möglicherweise ein negatives Vorzeichen, den Temperaturwert mit zwei Nachkommastellen und zum Schluss noch die Einheit wie zum Beispiel Celsius. Überträgt man dies im Klartext werden dafür etwa 7 Bytes benötigt. Nimmt man die Einheit weg, spart man bereits ein Byte ein. Als Nächstes könnte man das Vorzeichen entfernen, wenn man die Temperatur mit einem bestimmten Wert addiert, sodass keine negativen Zahlen kommen können. Damit fällt ein weiteres Byte weg. In weiterer Folge kann man den Temperaturwert mit 100 Multiplizieren um die Kommastelle zu entfernen. Wandelt man jetzt den Wert noch in ein Zahlenformat wie Integer um, so kommt man auf zwei Bytes, die jetzt noch für den gleichen Temperatur-Wert benötigt werden. Der Payload-Decoder im LoRaWAN-Netzwerk dividiert den zuvor multiplizierten Temperaturwert durch 100 und subtrahiert die im Sensor durchgeführte Addition. Zuletzt wird noch die Einheit angefügt und man bekommt den ursprünglichen Messwert wieder im Klartext angezeigt.

Die Payload ist eine hexadezimale Zahlenkette, die im Sensor encodiert wird und im LoRaWAN-Netzwerk durch den Decoder wieder umgewandelt wird. Bei fertigen Sensoren liefert der Hersteller bereits einen passenden Decoder, sodass dieser nur noch im LoRaWAN-Netzwerk eingefügt werden muss. Weitere Informationen über die Payload gibt es in diesem Artikel: So funktioniert die LoRaWAN Payload.