LoRaWAN erklärt: So funktionieren LoRa-Netzwerke mit Gateways & TTN

LoRaWAN gehört zu den spannendsten Technologien im Bereich des Internet of Things (IoT): Mit energieeffizienten Endgeräten und einer großen Funkreichweite lassen sich Sensordaten über mehrere Kilometer hinweg zuverlässig übertragen. In diesem Beitrag erfährst du, wie LoRaWAN funktioniert, welche technischen Grundlagen dahinterstecken und für welche Anwendungen sich das Netzwerk besonders eignet.

Dies ist der zweite Teil unserer Blog Reihe zum Thema LoRa und Meshtastic. In dieser Reihe behandeln wir alle verschiedene Aspekte von Hardware, über Software, bis hin zum Einsatz. Sollte das Thema LoRa neu für dich sein, dann schau am besten erst in unserem ersten Beitrag “Was ist LoRa?” vorbei. Dort findest du eine vollumfänglichen Einstieg mit LoRa.

Was ist LoRaWAN?

LoRaWAN (Long Range Wide Area Network) ist ein offenes Netzwerkprotokoll, das von der LoRa Alliance entwickelt wurde und auf der LoRa-Funktechnologie basiert. Es wurde speziell für die drahtlose Kommunikation von IoT-Geräten (Internet of Things) über große Entfernungen bei geringem Energieverbrauch konzipiert.
Das Protokoll definiert die sogenannte MAC-Schicht (Medium Access Control) und legt fest, wie Endgeräte mit Gateways und Netzwerkservern kommunizieren. Darüber hinaus regelt LoRaWAN die Authentifizierung von Geräten sowie die sichere Übertragung und Verschlüsselung von Daten.

Wie funktioniert LoRaWAN?

LoRaWAN basiert auf einer mehrstufigen Netzwerkarchitektur, die speziell für die drahtlose Kommunikation von IoT-Geräten entwickelt wurde. Dabei erfassen Sensoren oder andere Endgeräte Daten und übertragen diese über das LoRa-Funkverfahren an ein oder mehrere Gateways in ihrer Reichweite. Dabei bestehen die Netzwerke aus den folgenden vier zentralen Elementen:

• Endgeräte (End Nodes): Sensoren, Aktoren oder Messgeräte, die Daten erfassen und über Funk übertragen.
• Gateways: Empfangsstationen, die die Funksignale der Endgeräte aufnehmen und über eine IP-Verbindung weiterleiten.
• Network Server: Die zentrale Instanz zur Verwaltung des Netzwerks. Sie filtert doppelt empfangene Nachrichten, verwaltet die Gerätekommunikation und sorgt für die Weiterleitung der Daten.
• Application Server: Hier werden die Nutzdaten verarbeitet, visualisiert oder in bestehende IT-Systeme integriert.

Die Gateways fungieren als Brücke zwischen der Funkwelt und der IT-Infrastruktur. Sie empfangen die von den Endgeräten gesendeten Datenpakete und leiten diese über eine Internetverbindung an einen zentralen Network Server weiter. Die Kommunikation erfolgt dabei in einer sogenannten Stern-Topologie, bei der die Endgeräte nicht direkt miteinander kommunizieren, sondern ihre Daten immer über die Gateways an das Netzwerk senden.
Da ein Funksignal häufig von mehreren Gateways gleichzeitig empfangen wird, erkennt der Network Server doppelte Nachrichten und verarbeitet jede Übertragung nur einmal. Anschließend überprüft er die Integrität der Daten und leitet die Nutzinformationen an den zuständigen Application Server weiter.

Auf dem Application Server werden die Daten schließlich ausgewertet, gespeichert oder in andere Systeme integriert. So können beispielsweise Temperaturwerte visualisiert, Maschinenzustände überwacht oder automatische Prozesse ausgelöst werden.

Neben der eigentlichen Datenübertragung bietet LoRaWAN verschiedene Funktionen, die einen zuverlässigen und effizienten Netzbetrieb ermöglichen. Eine zentrale Rolle spielt dabei die Adaptive Data Rate (ADR). Diese Funktion optimiert die Kommunikationsparameter eines Endgeräts automatisch anhand der aktuellen Funkbedingungen. Geräte mit guter Verbindung können ihre Daten mit höheren Datenraten und kürzeren Sendezeiten übertragen, wodurch Energie gespart und die Netzwerkkapazität erhöht wird. Geräte in größerer Entfernung zu einem Gateway nutzen hingegen robustere Übertragungsparameter, um eine zuverlässige Kommunikation sicherzustellen.

Darüber hinaus verfügt LoRaWAN über umfassende Sicherheitsmechanismen. Sämtliche Datenpakete werden standardmäßig mittels AES-128-Verschlüsselung abgesichert. Dabei werden Netzwerk- und Anwendungsdaten durch separate Schlüssel geschützt. Ergänzend sorgen Authentifizierungsverfahren und Integritätsprüfungen dafür, dass nur berechtigte Geräte am Netzwerk teilnehmen können und Manipulationsversuche erkannt werden.

Warum hat LoRaWAN Vorteile?

LoRaWAN hat sich als eine der führenden Kommunikationstechnologien für das Internet of Things (IoT) etabliert, da es mehrere entscheidende Vorteile gegenüber klassischen Funk- und Mobilfunktechnologien bietet. Einer der größten Vorteile ist die hohe Reichweite. Abhängig von den Umgebungsbedingungen können Endgeräte in städtischen Gebieten mehrere Kilometer und in ländlichen Regionen sogar Entfernungen von über zehn Kilometern überbrücken. Dadurch lässt sich eine große Fläche mit vergleichsweise wenigen Gateways abdecken, was die Infrastrukturkosten reduziert.

Ein weiterer wesentlicher Vorteil ist der äußerst geringe Energieverbrauch. LoRaWAN wurde speziell für Anwendungen entwickelt, bei denen Sensoren nur in regelmäßigen Abständen kleine Datenmengen übertragen. Da die Geräte die meiste Zeit im Energiesparmodus verbleiben und nur kurzzeitig aktiv werden, sind Batterielaufzeiten von mehreren Jahren möglich. Dies reduziert den Wartungsaufwand erheblich und ermöglicht den Einsatz auch an schwer zugänglichen Standorten.

Darüber hinaus bietet LoRaWAN eine hohe Skalierbarkeit. Ein einzelnes Gateway kann mit Tausenden von Endgeräten kommunizieren und große Mengen an Sensordaten verarbeiten. Funktionen wie die Adaptive Data Rate (ADR) sorgen dabei für eine effiziente Nutzung der verfügbaren Funkressourcen und unterstützen einen stabilen Netzbetrieb auch bei steigender Anzahl von Geräten.

Was kann ich mit LoRaWAN tun?

Typische Anwendungsfälle umfassen die Erfassung und Übertragung von Temperaturwerten, GPS-Positionen, Füllständen, Erschütterungen, Luftqualitätsdaten oder Energieverbräuchen. Durch die hohe Reichweite und die langen Batterielaufzeiten kann, mit minimaler Infrastruktur, ein großes Netz an Sensoren aufgebaut werden.

Die erfassten Daten werden über das LoRaWAN-Netzwerk an eine zentrale Plattform übertragen und können anschließend in Cloud-Dienste wie AWS IoT Core, Microsoft Azure IoT Hub oder auf unternehmenseigene Server weitergeleitet werden. Dort lassen sich die Informationen speichern, analysieren und mit weiteren Datenquellen verknüpfen. Auf dieser Grundlage können Dashboards zur Visualisierung von Messwerten erstellt, automatisierte Prozesse ausgelöst oder Alarmsysteme eingerichtet werden, die bei definierten Grenzwerten sofort Benachrichtigungen versenden.

Dadurch eignet sich LoRaWAN für eine Vielzahl von Anwendungen in Industrie, Logistik, Smart Buildings, Smart Cities und der Landwirtschaft. Unternehmen erhalten die Möglichkeit, physische Prozesse in Echtzeit zu überwachen, Wartungsbedarfe frühzeitig zu erkennen und datenbasierte Entscheidungen zu treffen.

Wie weit reicht ein LoRaWAN-Gateway?

Die Reichweite eines LoRaWAN-Gateways hängt maßgeblich von den Umgebungsbedingungen, der Antennenposition sowie den eingesetzten Funkparametern ab. In städtischen Gebieten mit dichter Bebauung und zahlreichen Hindernissen liegt die typische Reichweite eines Gateways in der Regel zwischen 1 und 5 Kilometern. In ländlichen Regionen oder offenen Freiflächen sind aufgrund der geringeren Dämpfung deutlich größere Entfernungen von 5 bis 15 Kilometern erreichbar.

Durch eine professionelle Installation mit erhöht montierten Antennen, beispielsweise auf Gebäudedächern, Masten oder Türmen, lässt sich die Funkabdeckung zusätzlich verbessern. Unter günstigen Bedingungen können so Reichweiten von mehr als 20 Kilometern erzielt werden. Für eine zuverlässige und flächendeckende Versorgung größerer Gebiete empfiehlt sich jedoch der Einsatz mehrerer Gateways. Dadurch können Funklöcher vermieden, die Netzstabilität erhöht und die Ausfallsicherheit des Gesamtnetzwerks verbessert werden.

Auf welcher Grundlage basiert LoRaWAN?

LoRaWAN basiert auf zwei zentralen Komponenten: der LoRa-Physikschicht (Physical Layer) und dem offenen LoRaWAN-Protokollstandard. Während LoRa die eigentliche Funkübertragung ermöglicht, definiert LoRaWAN die Regeln für die Kommunikation zwischen Endgeräten, Gateways und Netzwerkservern. Die LoRa-Funktechnologie wurde ursprünglich von Semtech entwickelt und nutzt das Chirp Spread Spectrum (CSS)-Verfahren, das eine robuste und energieeffiziente Datenübertragung über große Entfernungen ermöglicht. (Für eine ausführliche Einleitung, mit technischen Erklärungen zu LoRa und CSS, siehe unseren Beitrag “Was ist LoRa? Die Funktechnologie für IoT, Maker & Meshtastic einfach erklärt“)

Der darüberliegende LoRaWAN-Standard wird von der LoRa Alliance gepflegt und kontinuierlich weiterentwickelt. Aktuelle Implementierungen basieren typischerweise auf den Spezifikationen LoRaWAN 1.0.4 oder LoRaWAN 1.1. Die LoRa Alliance definiert dabei unter anderem die Sicherheitsmechanismen, Kommunikationsabläufe und technischen Rahmenbedingungen für interoperable LoRaWAN-Netzwerke.

Netzwerkarchitektur im Detail

Was ist ein LoRaWAN End Node (Endgerät)?

Ein LoRaWAN End Node, auch Endgerät genannt, ist ein Sensor oder Aktor, der mit einem LoRa-Funkmodul ausgestattet ist und die eigentliche Datenquelle innerhalb eines LoRaWAN-Netzwerks darstellt. Sensoren erfassen beispielsweise Temperatur, Füllstände, GPS-Positionen, Luftfeuchtigkeit oder Erschütterungen und übertragen diese Informationen über das Netzwerk. Aktoren können umgekehrt Befehle aus dem Netzwerk empfangen und beispielsweise Schalter, Ventile oder andere technische Systeme steuern.

Endgeräte sind in den meisten Anwendungsfällen batteriebetrieben und auf einen besonders energieeffizienten Betrieb ausgelegt. Um die Batterielaufzeit zu maximieren, befinden sie sich die meiste Zeit im Energiesparmodus und werden nur für Messungen und Datenübertragungen aktiv. Die Kommunikation erfolgt häufig in festgelegten Intervallen, beispielsweise alle 10 Minuten, kann aber auch ereignisgesteuert erfolgen.

Jedes LoRaWAN-Endgerät verfügt über eine weltweit eindeutige Kennung, die sogenannte DevEUI (Device Extended Unique Identifier). Sie dient der eindeutigen Identifikation des Geräts im Netzwerk und ist vergleichbar mit einer MAC-Adresse in klassischen Netzwerken. Zusammen mit weiteren Sicherheitsinformationen ermöglicht die DevEUI eine sichere Authentifizierung und Zuordnung der übertragenen Daten innerhalb des LoRaWAN-Netzwerks.

Was ist ein LoRaWAN Gateway?

Ein LoRaWAN-Gateway bildet die Schnittstelle zwischen der LoRa-Funkwelt und dem Internet. Es empfängt die von Endgeräten gesendeten LoRa-Funksignale und leitet diese an einen zentralen Netzwerkserver weiter. Dabei fungiert das Gateway als Brücke zwischen den Funkteilnehmern und der dahinter liegenden Netzwerk- und Anwendungsinfrastruktur.

Moderne LoRaWAN-Gateways können mehrere Funkkanäle gleichzeitig überwachen und empfangen. In der Praxis unterstützen viele Geräte acht oder mehr Kanäle parallel, sodass sie Datenübertragungen zahlreicher Endgeräte gleichzeitig verarbeiten können. Die empfangenen LoRa-Nachrichten werden vom Gateway in Netzwerkpakete umgewandelt und über eine Internetverbindung an den LoRaWAN Network Server übertragen. Die Kommunikation erfolgt dabei typischerweise über LNS-Protokolle (LoRa Network Server).

Wichtig ist, dass ein Gateway selbst keine Entscheidungslogik besitzt. Es entschlüsselt die Nutzdaten nicht, verwaltet keine Geräte und trifft keine Routing- oder Anwendungsentscheidungen. Seine Aufgabe besteht ausschließlich darin, empfangene Funksignale zuverlässig an den Netzwerkserver weiterzuleiten und umgekehrt Nachrichten vom Netzwerkserver an die entsprechenden Endgeräte zu übertragen. Die eigentliche Verarbeitung, Authentifizierung und Verwaltung der Geräte erfolgt erst auf Ebene des LoRaWAN-Netzwerkservers.

Was ist ein LoRaWAN Network Server (LNS)?

Der LoRaWAN Network Server (LNS) ist die zentrale Steuerungsinstanz eines LoRaWAN-Netzwerks und übernimmt wesentliche Aufgaben für den zuverlässigen Betrieb der Infrastruktur. Er bildet die Verbindung zwischen den Gateways und den darüberliegenden Anwendungen und kann als das „Gehirn“ des Netzwerks betrachtet werden.

Da LoRaWAN-Nachrichten häufig von mehreren Gateways gleichzeitig empfangen werden, ist eine der wichtigsten Aufgaben des Network Servers die sogenannte Paketentduplizierung. Dabei erkennt der Server identische Nachrichten, die von verschiedenen Gateways weitergeleitet wurden, und verarbeitet diese nur einmal. Dadurch wird sichergestellt, dass Daten nicht mehrfach an Anwendungen übertragen werden.

Darüber hinaus verwaltet der Network Server die Adaptive Data Rate (ADR), mit der die Übertragungsparameter der Endgeräte automatisch an die jeweiligen Funkbedingungen angepasst werden. Dies optimiert sowohl die Reichweite als auch den Energieverbrauch der Geräte und verbessert die Gesamtkapazität des Netzwerks.
Eine weitere zentrale Aufgabe ist die Verwaltung von Geräteanmeldungen über das Over-the-Air Activation (OTAA)-Verfahren. Dabei authentifiziert der Network Server neue Endgeräte, verwaltet Sicherheitsschlüssel und stellt sicher, dass nur autorisierte Geräte am Netzwerk teilnehmen können.

Nach der Verarbeitung leitet der Network Server die eigentlichen Nutzdaten an den Application Server weiter, wo diese gespeichert, analysiert oder in andere Systeme integriert werden.

Was ist ein Application Server?

Der Application Server ist die Komponente eines LoRaWAN-Systems, die für die Verarbeitung und Nutzung der übertragenen Sensordaten zuständig ist. Nachdem der Network Server die LoRaWAN-Nachrichten empfangen, geprüft und die Nutzdaten extrahiert hat, werden diese an den Application Server weitergeleitet. Dort werden die Daten entschlüsselt, dekodiert und für Anwendungen nutzbar gemacht.

Zu den typischen Aufgaben eines Application Servers gehören die Visualisierung von Messwerten in Dashboards, die Speicherung von Daten in Datenbanken sowie die Integration in bestehende IT-Systeme. Darüber hinaus können auf Basis der empfangenen Daten automatisierte Prozesse ausgelöst werden. Beispielsweise kann bei der Überschreitung eines Temperaturgrenzwertes eine Benachrichtigung versendet oder bei einem kritischen Füllstand automatisch ein Wartungsauftrag erstellt werden.
Der Application Server stellt die Schnittstelle zwischen der LoRaWAN-Infrastruktur und den eigentlichen Geschäftsanwendungen dar.

Warum ist LoRaWAN ein Stern-von-Sternen-System?

LoRaWAN verwendet eine sogenannte Stern-von-Sternen-Architektur (Star-of-Stars), um eine einfache, skalierbare und energieeffiziente Kommunikation zwischen Endgeräten und Anwendungen zu ermöglichen. Anders als in vermaschten Netzwerken (Mesh-Netzwerken), bei denen Geräte Daten untereinander weiterleiten, kommunizieren LoRaWAN-Endgeräte ausschließlich mit den Gateways in ihrer Reichweite.

Der Begriff „Stern-von-Sternen“ ergibt sich aus dieser Struktur: Auf der ersten Ebene bilden die Endgeräte jeweils eine Stern-Topologie zu den Gateways. Auf der zweiten Ebene sind die Gateways wiederum sternförmig mit dem zentralen Network Server verbunden. Dadurch entsteht eine hierarchische Architektur, die große Netzwerke mit tausenden Endgeräten unterstützt, ohne die Komplexität oder den Energieverbrauch der Endgeräte zu erhöhen.

Dieses Konzept bietet mehrere Vorteile. Endgeräte benötigen keine Kenntnisse über die Netzwerktopologie, müssen keine Nachrichten anderer Geräte weiterleiten und können daher besonders energieeffizient arbeiten. Gleichzeitig erhöht der Empfang einer Nachricht durch mehrere Gateways die Zuverlässigkeit der Kommunikation und verbessert die Netzabdeckung, da der Network Server automatisch die beste Empfangsquelle auswählen kann.

LoRaWAN Device Classes: A, B und C

Was ist LoRaWAN Class A?

LoRaWAN Class A ist die standardmäßige und energieeffizienteste Geräteklasse innerhalb eines LoRaWAN-Netzwerks. Jedes LoRaWAN-Endgerät muss mindestens Class A unterstützen. Diese Geräteklasse wurde speziell für batteriebetriebene Sensoren entwickelt, bei denen ein möglichst geringer Energieverbrauch im Vordergrund steht.

Bei Class A bestimmt ausschließlich das Endgerät, wann eine Kommunikation stattfindet. Das Gerät sendet seine Daten zu einem selbst gewählten Zeitpunkt an das Netzwerk (Uplink). Direkt nach jeder Übertragung öffnet es zwei kurze Empfangsfenster, in denen der Network Server gegebenenfalls Antworten oder Steuerbefehle senden kann. Das erste Empfangsfenster (RX1) wird typischerweise etwa eine Sekunde nach dem Uplink geöffnet, das zweite (RX2) etwa zwei Sekunden nach der Übertragung.

Außerhalb dieser kurzen Empfangsfenster befindet sich das Endgerät im Energiesparmodus und ist für eingehende Nachrichten nicht erreichbar. Dadurch wird der Stromverbrauch auf ein Minimum reduziert, was Batterielaufzeiten von mehreren Jahren ermöglicht. Der Nachteil besteht darin, dass Downlink-Nachrichten nur unmittelbar nach einer Übertragung des Endgeräts zugestellt werden können und nicht zu beliebigen Zeitpunkten.

Aufgrund dieser Eigenschaften eignet sich LoRaWAN Class A besonders für Sensoranwendungen wie Temperaturmessungen, Füllstandsüberwachung, Energiezähler oder Umweltsensorik, bei denen regelmäßig Messwerte übertragen werden, das Gerät jedoch nur selten auf Befehle aus dem Netzwerk reagieren muss.

Was ist LoRaWAN Class B?

LoRaWAN Class B erweitert die Funktionen von Class A um zusätzliche, regelmäßig geplante Empfangsfenster. Dadurch können Endgeräte nicht nur nach eigenen Datenübertragungen Nachrichten vom Netzwerk empfangen, sondern auch zu vorhersehbaren Zeitpunkten für Downlink-Kommunikation erreichbar sein.

Die Synchronisation erfolgt über spezielle Beacon-Signale, die von den Gateways ausgesendet werden. Diese Beacons sind zeitlich präzise synchronisiert und ermöglichen es den Endgeräten, ihre zusätzlichen Empfangsfenster exakt zu planen.
Durch dieses Verfahren lassen sich Downlink-Nachrichten mit deutlich geringerer und besser vorhersagbarer Latenz übertragen als bei Class A. Anwendungen können somit zuverlässiger Befehle an Endgeräte senden, ohne auf den nächsten Uplink warten zu müssen. Dies ist insbesondere für Steuerungs- und Überwachungsanwendungen von Vorteil, bei denen eine schnellere Reaktionszeit erforderlich ist.

Der zusätzliche Empfangsbetrieb führt jedoch zu einem höheren Energieverbrauch als bei Class A, da das Endgerät häufiger aktiv sein muss. Class B stellt daher einen Kompromiss zwischen Energieeffizienz und Erreichbarkeit dar und eignet sich für Anwendungen, bei denen regelmäßige Downlinks benötigt werden, die Batterielaufzeit jedoch weiterhin eine wichtige Rolle spielt.

Was ist LoRaWAN Class C?

LoRaWAN Class C ist die Geräteklasse mit der höchsten Erreichbarkeit für Downlink-Kommunikation. Im Gegensatz zu Class A und Class B halten Class-C-Geräte ihre Empfangsfenster nahezu dauerhaft geöffnet. Lediglich während einer eigenen Datenübertragung (Uplink) wird der Empfänger kurzzeitig deaktiviert. Dadurch können Nachrichten vom Netzwerkserver nahezu jederzeit an das Endgerät zugestellt werden.

Durch die permanente Empfangsbereitschaft werden sehr geringe Latenzzeiten für Downlinks erreicht. Dies macht Class C besonders geeignet für Anwendungen, bei denen schnelle Reaktionszeiten erforderlich sind, beispielsweise in der Industrieautomatisierung, Gebäudeleittechnik oder bei Fernsteuerungs- und Schaltanwendungen.

Der kontinuierlich aktive Empfänger führt jedoch zu einem deutlich höheren Energieverbrauch als bei Class A oder Class B. Daher werden Class-C-Geräte in der Regel nicht batteriebetrieben, sondern über eine dauerhafte Stromversorgung betrieben. Die Geräteklasse stellt somit einen Kompromiss zugunsten maximaler Erreichbarkeit und minimaler Reaktionszeiten dar.

Welche Class sollte ich wählen?

Die Wahl der passenden LoRaWAN-Geräteklasse hängt in erster Linie von den Anforderungen an Energieverbrauch, Erreichbarkeit und Reaktionszeit ab. In den meisten IoT-Anwendungen ist Class A die beste Wahl. Da Endgeräte nur nach eigenen Datenübertragungen kurzzeitig auf Nachrichten vom Netzwerk warten, wird der Energieverbrauch auf ein Minimum reduziert. Dadurch sind Batterielaufzeiten von mehreren Jahren möglich, weshalb Class A für die meisten batteriebetriebenen Sensoren wie Temperatur-, Füllstands- oder Umweltsensoren ideal geeignet ist.

Class B empfiehlt sich, wenn Endgeräte regelmäßiger erreichbar sein müssen und eine vorhersehbare Downlink-Latenz erforderlich ist. Durch zusätzliche, zeitgesteuerte Empfangsfenster können Befehle zuverlässiger und mit geringerer Verzögerung zugestellt werden. Typische Anwendungsfälle sind beispielsweise intelligente Ventile, Schaltsysteme oder Steuerungen, bei denen eine Reaktion innerhalb definierter Zeitfenster erforderlich ist.

Class C eignet sich für Anwendungen, bei denen Nachrichten vom Server nahezu jederzeit empfangen werden müssen. Da der Empfänger permanent aktiv ist, können Steuerbefehle mit minimaler Verzögerung zugestellt werden. Aufgrund des deutlich höheren Energieverbrauchs wird Class C in der Regel nur für Geräte mit permanenter Stromversorgung eingesetzt. Typische Beispiele sind industrielle Steuerungen, Gebäudeautomationssysteme oder andere Aktoren, die jederzeit auf Befehle reagieren müssen.

Für die meisten LoRaWAN-Projekte gilt daher: Class A ist fast immer die richtige Wahl für batteriebetriebene Sensoren, während Class B und Class C vor allem dann sinnvoll sind, wenn die Kommunikation vom Netzwerk zum Endgerät eine größere Rolle spielt.

Gerät-Aktivierung mit OTAA und ABP

Was ist OTAA (Over-the-Air Activation)?

OTAA (Over-the-Air Activation) ist das empfohlene Aktivierungsverfahren in LoRaWAN, mit dem sich ein Endgerät sicher und dynamisch an einem Netzwerk anmeldet. Beim ersten Start oder nach einer erneuten Aktivierung sendet das Endgerät eine sogenannte Join-Request an den LoRaWAN Network Server. Diese Anfrage enthält unter anderem die eindeutige Gerätekennung (DevEUI) sowie weitere Identifikations- und Sicherheitsinformationen.

Der Network Server überprüft daraufhin die übermittelten Daten und authentifiziert das Gerät anhand der hinterlegten Schlüssel und Kennungen. Ist die Authentifizierung erfolgreich, antwortet der Server mit einer Join-Accept-Nachricht. Diese enthält die Netzwerkadresse (DevAddr) sowie die für die Kommunikation benötigten Sitzungsschlüssel.

Im Rahmen dieses Prozesses werden die Session Keys, darunter der Network Session Key (NwkSKey) und der Application Session Key (AppSKey), neu erzeugt. Diese Schlüssel sind nur für die aktuelle Sitzung gültig und werden bei jeder erneuten Anmeldung des Geräts neu generiert. Dadurch erhöht OTAA die Sicherheit des Netzwerks erheblich, da keine dauerhaft verwendeten Kommunikationsschlüssel existieren.

Durch die automatische Schlüsselerzeugung, die sichere Authentifizierung und die flexible Geräteverwaltung gilt OTAA heute als Standardverfahren für die Inbetriebnahme von LoRaWAN-Endgeräten und wird gegenüber statischen Aktivierungsmethoden wie ABP (Activation By Personalization) ausdrücklich empfohlen.

Was ist ABP (Activation by Personalization)?

ABP (Activation by Personalization) ist ein Verfahren zur Aktivierung von LoRaWAN-Endgeräten, bei dem die für die Kommunikation benötigten Netzwerkparameter bereits vorab fest im Gerät hinterlegt werden. Im Gegensatz zu OTAA (Over-the-Air Activation) erfolgt keine dynamische Anmeldung am Netzwerk. Das Endgerät besitzt bereits eine zugewiesene DevAddr sowie die erforderlichen Session Keys und kann daher unmittelbar nach dem Einschalten Daten senden.

Der Vorteil von ABP liegt in seiner Einfachheit. Da kein Join-Handshake mit dem Network Server erforderlich ist, können Geräte sofort mit der Datenübertragung beginnen. Dies kann in bestimmten Spezialanwendungen oder Testumgebungen von Vorteil sein.

Warum ist OTAA besser als ABP?

Dieses Verfahren erhöht die Sicherheit erheblich. Da bei jeder erfolgreichen Anmeldung eines Geräts neue, temporäre Session Keys erzeugt werden, bleibt der Schaden im Falle eines kompromittierten Session Keys auf die jeweilige Sitzung begrenzt – frühere oder zukünftige Kommunikationssitzungen sind davon nicht betroffen. Zu beachten ist dabei, dass die Session Keys aus dem statischen Root Key (AppKey) abgeleitet werden. Wird dieser AppKey selbst kompromittiert, lassen sich auch zurückliegende Sitzungen rekonstruieren – eine echte „Perfect Forward Secrecy” im kryptografischen Sinn bietet OTAA also nicht. Der entscheidende Vorteil liegt vielmehr darin, dass kompromittierte Sitzungsschlüssel isoliert bleiben und nicht das gesamte Gerät dauerhaft betreffen, wie es bei den statischen Schlüsseln von ABP der Fall wäre.

Welche Schlüssel brauche ich für OTAA?

Für die Aktivierung eines LoRaWAN-Endgeräts über OTAA (Over-the-Air Activation) werden mehrere Identifikations- und Sicherheitsparameter benötigt. Diese Informationen müssen sowohl im Endgerät als auch im LoRaWAN Network Server, beispielsweise in The Things Stack (TTN) oder ChirpStack, hinterlegt werden.

Die wichtigste Gerätekennung ist die DevEUI (Device Extended Unique Identifier). Dabei handelt es sich um eine weltweit eindeutige 8-Byte-Kennung, die das Endgerät eindeutig identifiziert. Sie wird in der Regel vom Gerätehersteller vergeben und ist häufig auf dem Gehäuse oder dem Typenschild des Sensors aufgedruckt.

Zusätzlich wird eine JoinEUI (früher AppEUI genannt) benötigt. Diese ebenfalls 8 Byte lange Kennung identifiziert die Anwendung oder Organisation, zu der das Gerät gehört. Sie dient dem Network Server dazu, die Join-Anfrage dem richtigen Anwendungsbereich zuzuordnen.

Der wichtigste Sicherheitsparameter ist der AppKey. Dabei handelt es sich um einen geheimen 16-Byte-Schlüssel, der sowohl im Endgerät als auch im Netzwerkserver gespeichert wird. Der AppKey wird während des Join-Prozesses verwendet, um die Identität des Geräts zu überprüfen und die für die Kommunikation benötigten Session Keys sicher abzuleiten.

Während des OTAA-Join-Prozesses werden auf Basis dieser Informationen automatisch neue Sitzungsschlüssel erzeugt.

Das globale Community-Netzwerk The Things Network (TTN)

Was ist The Things Network (TTN)?

The Things Network (TTN) ist ein weltweit verfügbares, gemeinschaftlich betriebenes LoRaWAN-Netzwerk. Die Netzabdeckung wird von der Community aufgebaut und erweitert, indem Nutzer eigene Gateways bereitstellen. Entwickler können ihre Geräte im Rahmen der Fair-Use-Richtlinien kostenlos registrieren und Daten über das Netzwerk übertragen. Die aktuelle Version, TTN V3, basiert auf der Open-Source-Plattform The Things Stack.

Wer betreibt TTN?

TTN wurde 2015 als offene Community-Initiative in Amsterdam ins Leben gerufen und wird seitdem von einer weltweiten Community kontinuierlich weiterentwickelt. Die zugrunde liegende Plattform The Things Stack wird heute von The Things Industries entwickelt und betrieben – dem Unternehmen, das 2017 aus dem Projekt hervorgegangen ist und die kommerzielle Weiterentwicklung übernommen hat. Die eigentliche Netzabdeckung entsteht weiterhin durch freiwillig betriebene Gateways, die von Nutzern und Organisationen bereitgestellt werden. Darüber hinaus haben Unternehmen die Möglichkeit, auf Basis der Open-Source-Lösung The Things Stack eine eigene, unabhängige LoRaWAN-Infrastruktur aufzubauen und zu betreiben.

Wie viele Gateways hat TTN?

The Things Network (TTN) ist eines der größten öffentlichen LoRaWAN-Netzwerke weltweit. Nach aktuellen Angaben umfasst das Netzwerk mehr als 21.000 aktive Gateways, die von einer globalen Community betrieben werden. Die Gateways sind über mehr als 150 Länder verteilt und bilden eine offene Infrastruktur für IoT-Anwendungen auf Basis von LoRaWAN.

In Deutschland ist die Netzabdeckung insbesondere in Ballungsräumen und Großstädten wie Berlin, Hamburg, München, Köln und Frankfurt sehr gut ausgebaut. Dort stehen häufig mehrere Gateways zur Verfügung, wodurch eine hohe Netzverfügbarkeit und Redundanz erreicht wird. In ländlichen Regionen kann die Abdeckung dagegen deutlich geringer ausfallen, sodass für professionelle Anwendungen oft eigene Gateways installiert werden.

Da TTN ein communitybasiertes Netzwerk ist, verändert sich die Anzahl der aktiven Gateways kontinuierlich. Neue Gateways kommen regelmäßig hinzu, während andere vorübergehend oder dauerhaft offline gehen können. Für eine aktuelle Übersicht der Netzabdeckung und der verfügbaren Gateways empfiehlt sich ein Blick auf die Karten von TTN Mapper oder die offizielle TTN-Netzwerkkarte. Diese zeigen die tatsächliche Netzabdeckung und die Standorte aktiver Gateways in Echtzeit.

Was ist die Fair Use Policy von TTN?

Die Fair Use Policy (FUP) von The Things Network (TTN) begrenzt die kostenlose Nutzung des öffentlichen LoRaWAN-Netzwerks pro Endgerät auf durchschnittlich 30 Sekunden Uplink-Airtime pro Tag und maximal 10 Downlink-Nachrichten pro Tag. Sie stellt sicher, dass die gemeinschaftlich betriebene Infrastruktur für alle Teilnehmer fair und stabil nutzbar bleibt.

Das öffentliche Community-Netz läuft inzwischen offiziell als „The Things Stack Sandbox”, die Fair-Use-Grenzen gelten dort unverändert. Die beiden zentralen Limits im Überblick:

Uplink: durchschnittlich 30 Sekunden Sendezeit (Airtime) pro Gerät und Tag
Downlink: höchstens 10 Nachrichten pro Gerät und Tag (inklusive Bestätigungen/ACKs)

Entscheidend ist dabei die Airtime, also die tatsächliche Sendezeit eines Geräts im Funkkanal und nicht die reine Anzahl der Nachrichten. Wie viele Nachrichten innerhalb der erlaubten 30 Sekunden möglich sind, hängt von Datenrate, Spreading Factor (SF) und Payload-Größe ab. Bei einer typischen Konfiguration mit SF7 und 50 Byte Payload liegt die Time on Air bei rund 100 Millisekunden pro Nachricht – das entspricht etwa 300 Nachrichten pro Tag. Bei höheren Spreading Factors steigt die Airtime deutlich, wodurch entsprechend weniger Nachrichten möglich sind.

Wie registriere ich ein Gerät bei TTN?

• 1. Account bei The Things Network erstellen
• 2. Application anlegen
• 3. Gerät hinzufügen (OTAA: DevEUI, AppEUI, AppKey eintragen).
• 4. Im Gerät dieselben Keys konfigurieren.
• 5. Gerät sendet Join-Request → TTN akzeptiert → Daten erscheinen in der Console.

Welche Alternativen zu TTN gibt es?

Neben The Things Network (TTN) existieren zahlreiche weitere LoRaWAN-Plattformen und Netzwerkserver, die je nach Anwendungsfall unterschiedliche Vorteile bieten. Die Auswahl reicht von vollständig selbst gehosteten Open-Source-Lösungen bis hin zu professionellen Enterprise-Plattformen und Cloud-Diensten großer Anbieter.

Eine der bekanntesten Alternativen ist ChirpStack, ein Open-Source-LoRaWAN-Network-Server, der auf eigener Hardware oder in der eigenen Cloud betrieben werden kann. ChirpStack bietet die volle Kontrolle über Daten, Infrastruktur und Sicherheitsrichtlinien und eignet sich besonders für Unternehmen, die eine unabhängige LoRaWAN-Lösung aufbauen möchten. Für kleinere Installationen kann ChirpStack sogar auf einem Raspberry Pi betrieben werden, während größere Umgebungen typischerweise auf dedizierten Servern oder virtuellen Maschinen laufen.

Das Helium Network verfolgt einen anderen Ansatz und basiert auf einem globalen, community betriebenen Netzwerk. Die Infrastruktur wird von privaten Betreibern bereitgestellt und über Blockchain-Technologien organisiert. Dadurch steht in vielen Regionen bereits eine umfangreiche LoRaWAN-Abdeckung zur Verfügung, ohne dass eigene Gateways Helium Networkinstalliert werden müssen.

Auch große Cloud-Anbieter bieten inzwischen native LoRaWAN-Integrationen an. AWS IoT Core for LoRaWAN ermöglicht die direkte Anbindung von LoRaWAN-Geräten an die AWS-Cloud, während Microsoft Azure IoT Hub entsprechende Integrationsmöglichkeiten für Azure-basierte IoT-Anwendungen bereitstellt. Diese Lösungen eignen sich insbesondere für Unternehmen, die ihre IoT-Infrastruktur bereits in der jeweiligen Cloud betreiben.

Für lokale Installationen ohne Abhängigkeit von externen Cloud-Diensten ist ChirpStack häufig die bevorzugte Wahl, während TTN, Helium und die Cloud-Plattformen von AWS oder Microsoft vor allem dann interessant sind, wenn eine bestehende Infrastruktur oder eine öffentliche Netzabdeckung genutzt werden soll.

Payload, Duty Cycle & Limits

Wie groß darf ein LoRaWAN-Payload sein?

Die maximal zulässige Größe eines LoRaWAN-Payloads hängt von den verwendeten Funkparametern ab, insbesondere vom Spreading Factor (SF) und der Bandbreite. Mit zunehmendem Spreading Factor steigt die Reichweite und Empfangsrobustheit, gleichzeitig reduziert sich jedoch die maximal mögliche Nutzlastgröße.

Für das in Europa häufig verwendete Frequenzband mit 125 kHz Bandbreite (BW125) gelten typischerweise folgende maximale Payload-Größen:

Spreading Factor	Maximale Payload-Größe
SF7	222 Byte
SF8	222 Byte
SF9	115 Byte
SF10	51 Byte
SF11	51 Byte
SF12	51 Byte

Obwohl diese Werte technisch möglich sind, sollten LoRaWAN-Nachrichten in der Praxis möglichst klein gehalten werden. Größere Payloads erhöhen die Airtime, belasten die Netzkapazität und steigern das Risiko von Paketverlusten durch Kollisionen. Für die meisten IoT-Anwendungen reichen daher 20 bis 50 Byte Nutzdaten pro Nachricht vollkommen aus.

Da LoRaWAN primär für die Übertragung kleiner Sensordatenpakete entwickelt wurde, empfiehlt es sich, Messwerte effizient zu kodieren und nur die tatsächlich benötigten Informationen zu übertragen. Dadurch werden Reichweite, Energieeffizienz und Skalierbarkeit des Netzwerks optimal genutzt.

Wie kodiert man Payload effizient?

Da LoRaWAN für die Übertragung kleiner Datenmengen optimiert ist und die verfügbare Payload-Größe begrenzt ist, sollten Daten möglichst kompakt kodiert werden. Textbasierte Formate wie JSON sind für LoRaWAN in den meisten Fällen ungeeignet, da sie viele zusätzliche Zeichen für Feldnamen, Klammern und Formatierungen enthalten. Dadurch steigt die Airtime unnötig an und die verfügbare Netzwerkkapazität wird belastet.

Stattdessen werden in LoRaWAN-Anwendungen häufig binäre Datenformate verwendet. Dabei werden Messwerte direkt als Bytes übertragen, wodurch sich der Platzbedarf erheblich reduziert. Ein Temperaturwert von 23,5 °C kann beispielsweise als Ganzzahl mit dem Wert 235 gespeichert und mit einem Skalierungsfaktor von 0,1 interpretiert werden. Für die Übertragung werden lediglich 2 Byte benötigt, anstatt mehrere Zeichen eines JSON-Strings zu senden.

Für standardisierte Sensordaten wird häufig Cayenne Low Power Payload (LPP) eingesetzt. Dieses Format definiert feste Datentypen für Sensorwerte wie Temperatur, Luftfeuchtigkeit, GPS-Positionen oder Füllstände und erleichtert die automatische Dekodierung auf dem Application Server.

Eine weitere Möglichkeit ist CBOR (Concise Binary Object Representation). CBOR kann als kompaktes Binärformat für strukturierte Daten betrachtet werden und bietet ähnliche Funktionen wie JSON, benötigt jedoch deutlich weniger Speicherplatz (siehe Beispiel Codierung). Dadurch eignet es sich besonders für Anwendungen, die mehrere unterschiedliche Datenwerte in einer Nachricht übertragen müssen.

Grundsätzlich gilt: Je kleiner die Payload, desto kürzer die Airtime und desto effizienter arbeitet das LoRaWAN-Netzwerk. Daher sollten Messwerte möglichst kompakt kodiert und unnötige Daten vermieden werden.

Was ist ADR (Adaptive Data Rate)?

ADR (Adaptive Data Rate) ist ein Optimierungsmechanismus innerhalb von LoRaWAN, der die Funkparameter eines Endgeräts automatisch an die aktuellen Empfangsbedingungen anpasst. Ziel ist es, die Netzwerkkapazität effizient zu nutzen, die Airtime zu reduzieren und gleichzeitig den Energieverbrauch der Endgeräte zu minimieren.

Hierfür analysiert der LoRaWAN Network Server die Qualität der empfangenen Funksignale und ermittelt die optimalen Übertragungsparameter für jedes einzelne Gerät. Dazu gehören insbesondere der Spreading Factor (SF) und die Sendeleistung. Befindet sich ein Endgerät in guter Reichweite eines Gateways, kann der Network Server einen niedrigeren Spreading Factor zuweisen. Dadurch werden Daten schneller übertragen, die Airtime sinkt und der Energieverbrauch des Geräts reduziert sich.

Befindet sich ein Gerät hingegen weiter entfernt oder verschlechtern sich die Funkbedingungen, kann der Network Server den Spreading Factor erhöhen oder die Sendeleistung anpassen. Dadurch wird die Übertragung robuster und die Wahrscheinlichkeit eines erfolgreichen Empfangs steigt, auch wenn dies mit einer längeren Übertragungsdauer verbunden ist.

ADR ist insbesondere für stationäre Geräte wie Temperatur-, Füllstands- oder Energiezähler-Sensoren geeignet, da deren Funkumgebung meist konstant bleibt. Durch die automatische Optimierung der Übertragungsparameter trägt ADR wesentlich dazu bei, die Skalierbarkeit von LoRaWAN-Netzwerken zu verbessern und gleichzeitig die Batterielaufzeit der Endgeräte zu verlängern.

Wie viele Pakete kann ich pro Stunde senden?

Die Anzahl der möglichen LoRaWAN-Nachrichten pro Stunde hängt von mehreren Faktoren ab, insbesondere vom verwendeten Spreading Factor (SF), der Payload-Größe und den gesetzlichen Duty-Cycle-Beschränkungen. In Europa gilt für viele LoRaWAN-Frequenzen ein Duty Cycle von 1 %, was bedeutet, dass ein Gerät pro Stunde maximal 36 Sekunden senden darf.

Bei einer typischen Konfiguration mit SF7, 125 kHz Bandbreite und einer Payload von 13 Byte beträgt die sogenannte Time on Air (ToA) einer Nachricht etwa 46 Millisekunden. Unter Ausnutzung des gesamten 1%-Duty-Cycles wären damit theoretisch rund 782 Pakete pro Stunde möglich.

Mit steigenden Spreading Factors erhöht sich die Übertragungsdauer jedoch deutlich. Ein Paket mit SF12 und einer Payload von 51 Byte benötigt beispielsweise rund 2,5 Sekunden Airtime (mit aktivierter Low Data Rate Optimization). Unter denselben Duty-Cycle-Bedingungen können daher nur noch etwa 14 Pakete pro Stunde übertragen werden.

Dieser Zusammenhang zwischen ToA and der Bitrate ist hier zur Veranschaulichung illustriert. Mit steigender Distanz, und daraus folgendem höheren SF, steigt die Time on Air drastisch von Millisekunden auf Sekunden. Zur gleichen Zeit fällt die Übertragungsrate (Bitrate) drastisch.

In der Praxis sollte die Anzahl der Nachrichten jedoch deutlich unter diesen theoretischen Grenzwerten liegen. LoRaWAN wurde für die Übertragung kleiner Datenmengen in größeren Intervallen entwickelt. Zu häufige Übertragungen erhöhen die Netzlast, reduzieren die Batterielaufzeit und können die Zuverlässigkeit des Netzwerks beeinträchtigen. Für typische Sensoranwendungen sind daher Übertragungsintervalle von einigen Minuten bis hin zu mehreren Stunden üblich.

Häufige Fragen zu LoRaWAN

Brauche ich für LoRaWAN ein eigenen Gateway?

Nicht unbedingt. Wenn in deiner Region bereits eine ausreichende LoRaWAN-Abdeckung vorhanden ist, kannst du viele Endgeräte direkt über bestehende Netzwerke wie The Things Network (TTN) betreiben. In diesem Fall ist kein eigener Gateway erforderlich und du kannst unmittelbar mit der Entwicklung und dem Testen deiner Anwendung beginnen. Ob an deinem Standort bereits eine ausreichende Abdeckung vorhanden ist, lässt sich beispielsweise über Dienste wie TTN Mapper überprüfen.

Für größere Anwendungen oder Standorte mit schwacher Netzabdeckung kann ein eigener Gateway jedoch sinnvoll sein. Insbesondere in Gebäuden mit starker Abschirmung, Industrieanlagen oder ländlichen Regionen verbessert ein eigener Gateway die Empfangsqualität, erhöht die Zuverlässigkeit und ermöglicht die vollständige Kontrolle über die Netzwerkinfrastruktur. Zudem bist du nicht von der Verfügbarkeit öffentlicher Community-Netzwerke abhängig.

Was kostet ein LoRaWAN-Gateway?

Die Kosten für ein LoRaWAN-Gateway hängen vom Einsatzzweck, der Reichweite und den Anforderungen an Zuverlässigkeit und Wetterbeständigkeit ab. Für Entwickler, Maker und kleinere Pilotprojekte sind bereits kostengünstige Indoor-Gateways erhältlich, die einen einfachen Einstieg in die LoRaWAN-Welt ermöglichen.

Zu den beliebten Einsteigermodellen gehören beispielsweise das Seeed SenseCAP. Dieses eignet sich besonders für Testumgebungen, Smart-Home-Anwendungen oder kleinere IoT-Projekte. Diese Gateways, welche ideal sind zum Einstieg, starten durchschnittlichen Preisen ab 120 Euro.

Für professionelle Anwendungen kommen häufig leistungsfähigere Outdoor-Gateways zum Einsatz. Diese verfügen über robustere Gehäuse, bessere Antennensysteme, erweiterte Managementfunktionen und sind für den dauerhaften Betrieb im Außenbereich ausgelegt. Die Preise liegen hier typischerweise zwischen 300 und 1.000 Euro, abhängig von Ausstattung, Kanalanzahl und Zertifizierungen.

Neben den Hardwarekosten sollten auch mögliche Betriebskosten berücksichtigt werden. Wer einen eigenen LoRaWAN Network Server wie ChirpStack betreibt, benötigt entsprechende Serverressourcen. Alternativ können kommerzielle LoRaWAN-Plattformen und LNS-Anbieter genutzt werden, bei denen zusätzliche Cloud- oder Hosting-Kosten anfallen. Die Gesamtkosten eines LoRaWAN-Systems setzen sich daher aus Gateway-Hardware, Netzwerkbetrieb und gegebenenfalls Plattform- oder Cloud-Diensten zusammen.

Kann ein LoRaWAN-Gerät roamen?

Ja, LoRaWAN unterstützt Roaming zwischen verschiedenen Netzwerken. Insbesondere mit LoRaWAN 1.1 wurden standardisierte Roaming-Funktionen eingeführt, die es Geräten ermöglichen, auch außerhalb ihres ursprünglichen Heimnetzwerks zu kommunizieren. Dadurch können Endgeräte Daten über fremde LoRaWAN-Infrastrukturen übertragen, ohne dass eine erneute Registrierung oder Konfiguration erforderlich ist.

Ein praktisches Beispiel ist The Things Network (TTN): Ein Gerät, das in Deutschland registriert wurde, kann grundsätzlich auch in anderen Ländern über dort verfügbare TTN-Gateways kommunizieren. Die Authentifizierung und Datenweiterleitung erfolgen dabei weiterhin über das Heimnetzwerk des Geräts, während die lokale Infrastruktur lediglich die Funkverbindung bereitstellt.

Voraussetzung für ein erfolgreiches Roaming ist jedoch die Kompatibilität der verwendeten Frequenzbänder. In Europa wird LoRaWAN überwiegend im 868-MHz-Band betrieben, während beispielsweise in Nordamerika das 915-MHz-Band verwendet wird. Ein für Europa ausgelegtes Gerät kann daher nicht automatisch in allen Regionen der Welt eingesetzt werden. Für internationale Anwendungen sollten deshalb Geräte gewählt werden, die die jeweils benötigten regionalen Frequenzbänder unterstützen.

Roaming ist besonders interessant für mobile Anwendungen wie Asset Tracking, Logistik oder internationale IoT-Lösungen, bei denen Geräte regelmäßig zwischen verschiedenen Standorten, Regionen oder Ländern wechseln.

Ist LoRaWAN sicher?

Ja, LoRaWAN wurde von Grund auf mit umfangreichen Sicherheitsmechanismen entwickelt und gilt bei korrekter Konfiguration als sehr sichere IoT-Kommunikationstechnologie. Die Sicherheit basiert auf einer AES-128-Verschlüsselung, die auf zwei Ebenen umgesetzt wird: der Netzwerkebene und der Anwendungsebene.

Für die Sicherheit des Netzwerks ist der Network Session Key (NwkSKey) verantwortlich. Dieser wird verwendet, um die Integrität und Authentizität der Nachrichten sicherzustellen. Der Network Server kann damit prüfen, ob eine Nachricht tatsächlich von einem autorisierten Gerät stammt und während der Übertragung nicht verändert wurde.

Die eigentlichen Nutzdaten werden hingegen mit dem Application Session Key (AppSKey) verschlüsselt. Dadurch können nur autorisierte Anwendungen die übertragenen Sensordaten entschlüsseln und auswerten. Selbst der Network Server hat in vielen Implementierungen keinen direkten Zugriff auf die eigentlichen Nutzdaten, sondern verarbeitet lediglich die verschlüsselten Nachrichten.

Zusätzlich schützt LoRaWAN vor sogenannten Replay-Angriffen. Hierbei versucht ein Angreifer, bereits aufgezeichnete Nachrichten erneut in das Netzwerk einzuspeisen. Um dies zu verhindern, verwendet LoRaWAN fortlaufende Frame Counter, die jede Nachricht eindeutig kennzeichnen. Nachrichten mit ungültigen oder bereits verwendeten Zählerständen werden vom Netzwerk automatisch verworfen.

Eine bekannte Schwachstelle entsteht vor allem bei der Verwendung von ABP (Activation by Personalization). Da hierbei statische Sitzungsschlüssel dauerhaft im Gerät hinterlegt werden, fehlt die regelmäßige Erneuerung der Schlüssel, wie sie bei OTAA erfolgt. Aus diesem Grund empfiehlt die LoRa Alliance für produktive Systeme die Nutzung von OTAA (Over-the-Air Activation), bei dem bei jeder Anmeldung neue Session Keys generiert werden und ein deutlich höheres Sicherheitsniveau erreicht wird.