Schonmal was von LoRaWAN gehört?

Klassische Funktechnologien wie beispielsweise WLAN oder Bluetooth bieten eine zu geringe Reichweite oder sind nicht ausreichend energieeffizient, um batteriebetriebene Sensoren mit einem Netz zu verbinden. Aus diesem Grund wurde vor ca. 10 Jahren von Semtech das LoRa-Protokoll entwickelt, welches in LoRaWAN-Netzen genutzt wird.

In den letzten zwei Jahren beobachten wir, dass das Interesse an LoRaWAN stetig zunimmt, da die Anwendungsbereiche sehr vielfältig sind. So eignet es sich beispielsweise gut für die Digitalisierung von Gebäuden. Ein beliebter Use Case ist dabei eine Raumüberwachung. Mit ihr werden neben der Temperatur auch CO²-Daten gesammelt und ausgewertet, um die Mitarbeiter anschließend darauf hinzuweisen, dass die Luftqualität ungenügend ist und gelüftet werden sollte. Dieser Use Case ist besonders durch Corona häufig umgesetzt worden. Neben der Digitalisierung von Gebäuden werden für LoRaWAN immer mehr Anwendungsfälle in der Industrie entwickelt. Zwei häufige Use Cases sind zum einen die Installation von Wippen in Lagern, um den Lagerbestand auszuwerten und automatisiert durch beispielsweise fahrerlose Transportsysteme aufzufüllen sowie zum anderen die Digitalisierung von Bestelllisten in Form von ePapern, um eine große Menge an Papier zu sparen.

Neben diesen beispielhaften Anwendungsfällen gibt es noch deutlich mehrere, die den Rahmen dieses Artikels sprengen würden. Daher beschäftigen wir uns nun erst einmal damit, was genau LoRaWAN ist, wie die Infrastruktur aufgebaut werden kann, welche anderen Funktechniken in diesem Bereich existieren und wie ein Planungsprozess in Form von Simulation und Messungen aussehen kann.

Was ist LoRaWAN?

LoRaWAN beruht, wie der Name schon vermuten lässt, auf dem LoRa-Protokoll. Dieses Protokoll ist eine von Semtech entwickelte Low-Power-Wide-Area-Network-Technologie (LPWAN) und basiert grundlegend auf der „Chirp Spread Spectrum“-Modulation. Ziel dieser Technologie ist es, über möglichst weite Distanzen mit einem möglichst geringen Energiebedarf Daten zu übertragen.

Gefördert wird diese Technologie durch die LoRa-Alliance. Diese gemeinnützige Organisation wurde im Jahr 2015 von den Unternehmen Belgacom, Bouygues Telecom, Cisco, Fastnet, IBM, KPN, MircoChip, Semtech, Singtel und Swisscom gegründet und hat sich zum Ziel gesetzt, durch Standardisierung der LPWAN-Technologie das Wachstum dieser zu fördern. Im Laufe der Jahre sind ca. 500 über den Globus verteilte Unternehmen der LoRa-Alliance beigetreten, und damit zählt die Gruppe zu den am schnellsten wachsenden Technologie-Bündnissen weltweit. Neben der Standardisierung der Technologie wird auch der Aufbau öffentlicher Infrastrukturen gefördert, was zur Folge hat, dass LoRaWAN zu einer der meistverbreiteten Technologien unter den LPWAN-Lösungen aufgestiegen ist.

„Chirp“ steht für „Compressed High Intensive Radar Pulse“, hat seinen Ursprung in der Radartechnik und beschreibt in der Signalverarbeitung ein Signal, welches über Zeit die Frequenz linear ändert. Genau genommen wird dabei zwischen “Upchirp” und “Downchirp” unterschieden. Ein „Upchirp“ ist ein Chirp, der über eine bestimmte Zeit die Frequenz linear erhöht. Ein „Downchirp“ verhält sich umgekehrt und verringert die Frequenz über eine bestimmte Zeit. Je länger ein Chirp gestreckt wird, umso größer wird die Reichweite. Wie stark sich letztendlich ein Signal strecken lässt, wird bei der LoRaWAN-Technologie mithilfe eines sogenannten “Spreading Factor (SF)” von SF7 bis SF12 festgelegt. SF7 beschreibt dabei die geringste Streckung des Signals aufsteigend bis SF12. Bei SF7 sind theoretische Reichweiten von bis zu 5 km möglich, und bei SF12 von bis zu 16 km. Diese Werte sind jedoch mit Vorsicht zu genießen. Der produktive Einsatz hat gezeigt, dass im städtischen Umfeld je nach SF Reichweiten zwischen 2 und 6 km realistischere Werte sind. Ein zu hoch eingestellter SF birgt jedoch Nachteile. Während er sich positiv auf die Reichweite auswirkt, wirkt er sich zeitgleich negativ auf den Stromverbrauch möglicher Sender aus, was besonders für batteriebetriebene Sender von großer Bedeutung ist. Je stärker die Frequenz gestreckt wird, umso mehr Zeit braucht ein Sender zur Übertragung der Daten und muss dementsprechend länger aktiv senden. Durch die Streckung des Signals kann man somit schnell an die regulatorischen Grenzen der Bundesnetzagentur stoßen. Diese gibt vor, dass in dem für LoRaWAN genutzten lizenzfreien Bereich zwischen 863 und 870 MHz und bei einer maximalen Sendeleistung von 25 mW ein Sender das Frequenzband nur zu einem Prozent der Zeit belegen darf. Auf eine Stunde gerechnet ergibt sich eine maximale Sendezeit von 36 Sekunden. Bei SF7 benötigt der Sender für eine Übertragung ca. 60 ms, während bei SF12 ganze 1,5 s nötig werden, um eine einzige Übertragung durchzuführen. Somit wird bei SF12 schon bei 24 Übertragungen pro Stunde die maximal erlaubte Anzahl an Übertragungen erreicht, während bei einem SF7 600 Übertragungen pro Stunde möglich werden. Analog verhält es sich bei den Datenraten. Je höher ein Signal gestreckt wird bzw. der SF eingestellt wird, umso weniger Daten könnten pro Sekunde übertragen werden. Eine Übersicht ist in Tabelle 1 dargestellt.

Vorteile der LPWAN-Technologie sind die vergleichsweise hohen Reichweiten bei einem sehr geringen Energieverbrauch, wodurch batteriebetriebene Sensoren abhängig von der Senderhäufigkeit eine mögliche Akkulaufzeit von bis zu zehn Jahren aufweisen können. [1]

Aufbau einer LoRaWAN-Infrastruktur

Für den Aufbau einer LoRaWAN-Infrastruktur werden End Nodes/Sensoren, Gateways, ein Network Server und ein Application Server benötigt. Die allgemeine Architektur einer LoRaWAN-Infrastruktur ist in Abbildung 1 dargestellt. Im Folgenden werden die einzelnen Komponenten erläutert.

End Nodes/Sensoren:

Aktuell gibt es ca. 300 von der LoRaWAN-Alliance zertifizierte Endgerätetypen. End Nodes bzw. Sensoren werden benötigt, um die gewünschten Informationen zu sammeln und über das LoRa-Protokoll zu verschicken. Die Sendehäufigkeit kann je nach Endgerätklasse unterschiedlich sein. Die Endgeräte sind in drei Kategorien aufgeteilt und in Abbildung 2 dargestellt.

Abbildung 2: Übersicht der verfügbaren LoRaWAN-Endgeräteklassen

• „Class A“-Geräte sind die energiesparendsten, da sie nur dann aktiv sind, wenn ein Interrupt wie z. B. ein intern abgelaufener Timer oder ein Event eines Sensors eintritt. Sobald das Endgerät aus dem Tiefschlaf in den Aktiv-Modus wechselt, werden die Daten vom Sensor versendet. Abschließend wartet das Gerät eine konfigurierbare Zeit (RX Delay) lang, um Daten vom Gateway zu empfangen. Befehle, die an ein Endgerät übertragen werden sollen, können nur dann versendet werden, wenn das Endgerät sich im aktiven Modus befindet.
• „Class B“-Geräte funktionieren ähnlich wie „Class A“-Geräte, jedoch sind geplante Downlink-Zeiten konfiguriert, in denen das Endgerät aktiv ist und auf Nachrichten vom Gateway wartet. In diesem Modus wird das Endgerät auch als „Beacon“ bezeichnet. Nach Ablauf eines konfigurierten Timers innerhalb der Hardware wird die Empfangseinheit des Endgerätes aktiviert und auf ein Beacon-Signal vom Gateway gewartet. Dies dient zum einen zur Zeitsynchronisation, zum anderen können hiermit Daten vom Endgerät angefordert bzw. Befehle gesendet werden.
• „Class C“-Geräte sind durchgängig aktiv und entsprechend immer erreichbar, abgesehen von den Sendephasen. Geräte dieser Klasse sind nur sinnvoll, wenn eine externe Stromversorgung vorhanden ist oder der Akku regelmäßig aufgeladen werden kann, wie beispielsweise in Straßenlaternen oder Drucksensoren in Wasserleitungen. Diese Klasse ist dann interessant, wenn Zustände in Echtzeit überwacht und gesteuert werden sollen oder eine sehr geringe Latenz erreicht werden muss, wie z.B. bei steuerbaren Ventilen.

Für das Einbinden von End Nodes in eine LoRaWAN-Infrastruktur gibt es zwei verschiedene Join-Verfahren, welche im Folgenden erläutert werden:

• ABP (Activation By Personalization): Bei der ABP-Aktivierung werden eine feste DevAddr und ein Sitzungsschlüssel für ein vorausgewähltes Netz in das Endgerät fest eincodiert und bleiben während der gesamten Lebensdauer eines ABP-Endgerätes gleich. Mit diesem Modus überspringt ein Endgerät das Beitrittsverfahren, welches einfach zu sein scheint. Doch gibt es einige Einschränkungen bei der Verwendung von ABP. Nachteil dieser Methode ist, dass jeder, der Zugriff auf das Endgerät hat, den Quellcode auslesen, anschließend Übertragungen mitlesen oder sogar manipulieren kann. Des Weiteren können die Geräte über ABP keine Konfigurationsdateien vom Netz erhalten.
• OTAA (Over The Air Activation): OTAA-Endgeräte werden mit Root-Schlüsseln ausgestattet. Bei der OTAA-Aktivierung führt ein Endgerät eine Verbindungsprozedur mit einem LoRaWAN-Netz durch, bei der einem Endgerät eine dynamische DevAddr zugewiesen und der Root-Schlüssel zur Ableitung von Sitzungsschlüsseln verwendet wird. Daher ändern sich die DevAddr und Sitzungsschlüssel bei jedem Aufbau einer neuen Sitzung. Da bei dieser Aktivierungsmethode der Root-Schlüssel nie übertragen wird, ist die Verbindung deutlich sicherer im Vergleich zur ABP-Methode. Ein weiterer Vorteil liegt darin, dass OTAA-Geräte Konfigurationsdateien aus dem Netz erhalten können und somit die Möglichkeit besteht, diese aus der Ferne zu warten.

Gateways:

Für den Empfang der Daten muss mindestens ein Gateway vorhanden sein. Das Gateway nutzt je nach Einsatzgebiet unterschiedliche Hardware, die abweichende Eigenschaften besitzt. Neben diversen Frequenzen können mehrere Spreading Factors bedient werden, da die Endgeräte aufgrund ihrer variierenden Positionen und Entfernungen nicht alle mit demselben Spreading Factor genutzt werden sollten. Das Gateway verschickt die erhaltenen Daten weiter an den Network Server. Die Datenübertragungen zwischen End Node, Gateway und Network Server erfolgen verschlüsselt (AES 128).

Network Server:

Die Verarbeitung der empfangenen Daten übernimmt anschließend der Network Server. Dieser empfängt und verarbeitet die weitergeleiteten Pakete der Gateways. Zusätzlich führt er die Nachrichtenplanung durch, falls Informationen an die Endgeräte weitergegeben werden sollen. Aufgrund der Überschneidung der Empfangsbereiche mehrerer Gateways werden Nachrichten möglicherweise von mehreren Gateways empfangen und an den Network Server weitergeleitet. Dieser erkennt und entfernt mehrfach empfangene Datensätze und koordiniert den Weitertransport der Daten an die entsprechenden Application Servers. Zudem verschlüsselt und entschlüsselt dieser die gesamte Kommunikation.

Application Server:

Der Application Server ist die Brücke zwischen dem LoRaWAN-Netz und den eigentlichen Anwendungen, da hier die Daten ausgelesen und Befehle an die Endgeräte gesendet werden können. Der Application Server stellt unterschiedliche Schnittstellen bereit, damit die Daten an die eigentliche Anwendung weitergeleitet werden können. Als Schnittstellen werden beispielsweise das viel verwendete Protokoll MQTT oder auch solche der typischen Clouds wie AWS zur Verfügung gestellt. Die Daten können anschließend mithilfe von Dashboards visualisiert oder über weitere Techniken wie beispielsweise maschinelles Lernen verarbeitet werden. Zudem ist dieser Dienst für die Ver- und Entschlüsselung der Nutzdaten zuständig und erhöht somit die Sicherheit der Übertragung. Ein LoRaWAN-Netzwerk kann mit mehr als einem Application Server bestückt sein.

The Things Network:

Neben dem Aufbau einer eigenen privaten LoRaWAN-Infrastruktur gibt es als Alternative öffentlich zugängliche Netze, wie z.B. das weitverbreitete Netz „The Things Network“.  The Things Network, allgemein bekannt als TTN, ist eine Open-Source-Infrastruktur und dient dazu, mithilfe der Community die LoRaWAN-Technologie für jeden zugänglich zu machen. Dieses Projekt wird von einer wachsenden Gemeinschaft weltweit entwickelt und über freiwillige Spenden aus der Community finanziert. Beispielsweise wurden bisher 13 Gateways im Aachener Stadtgebiet platziert, welche bereits einen Großteil des Stadtgebiets flächendeckend mit einem LoRaWAN-Netz versorgen. Daher bietet dieses Netzwerk eine gute Möglichkeit, Geräte, Anwendungen und Integrationen zu testen und sich mit der Technologie vertraut zu machen, bevor man sich entscheidet, eine eigene Infrastruktur zu betreiben. Ein Grund, warum man überlegen sollte, eine eigene Infrastruktur zu betreiben, ist, dass The Things Network die Kommunikationshäufigkeit der Endgeräte noch weiter, als von der Bundesnetzagentur vorgegeben, drosselt.

LoRaWAN vs. andere Funktechnologien

Auch wenn es in diesem Artikel in erster Linie um LoRaWAN geht, lohnt es sich dennoch, einen Blick auf weitere LPWAN-Technologien zu werfen.

Eine dieser Technologien ist Sigfox, welche vom gleichnamigen Unternehmen “SIGFOX S.A.” ins Leben gerufen wurde. Sigfox verfolgt ebenfalls das Ziel, ein globales Funknetzwerk zur Anbindung von Low-Energy-Endgeräten aufzubauen. Sigfox nutzt das SRD-Band bei zz. Die Reichweite ist bei einer Datenrate von ungefähr 100 Bytes/s mit 30 bis 50 km in freiem Gelände und 3 bis 10 km in Städten angegeben. Ein großer Nachteil bei Sigfox liegt jedoch darin, dass ein Aufbau einer privaten Sigfox-Infrastruktur nicht möglich ist und nur die von der SIGFOX S. A. zur Verfügung gestellten Cloud-Dienste verwendet werden können. Dies ist aktuell besonders kritisch zu betrachten, da sich das Unternehmen in einem Insolvenzverfahren befindet und die Situation von Sigfox somit ungewiss ist. Daher können im Moment keine neuen Verträge mit der SIGFOX S. A. geschlossen werden. Derzeit wird nur noch der Betrieb für bestehende Kunden aufrechterhalten. Wie lange das so bleibt, gilt abzuwarten.

Eine weitere LPWAN-Technologie ist NB-IoT. NB-IoT steht für Narrowband IoT und nutzt die bekannten Mobilfunkstandards 5G und LTE-M. Gegenüber der Mobilfunktechnologie wurde bei NB-IoT der Stromverbrauch stark optimiert, um einen energiesparenden Betrieb zu ermöglichen. Entwickelt und eingeführt wurde diese Technologie von der 3GPP, welche maßgeblich an der Standardisierung der aktuellen Mobilfunktechniken (LTE, 5G, etc.) beteiligt war. Die Reichweite wird mit maximal 15 km bei einer ungefähren Datenrate von 50 kBit/s angegeben. NB-IoT soll Endgeräte ohne komplexe Hardware an das Internet anbinden können. Der Vorteil dieses Standards liegt darin, dass vorhandene Mobilfunkmasten, welche bereits mit LTE-Antennen ausgestattet sind, von den Mobilfunkanbietern genutzt werden können, um NB-IoT anzubieten. Der Zugriff erfolgt ähnlich wie beim Mobiltelefon über eine SIM- beziehungsweise eSim-Karte. Somit muss in der eingesetzten Sensorik eine SIM-Schnittstelle zur Verfügung stehen. Der größte Nachteil dieser Technologie sind jedoch die Kosten. Da NB-IoT die Infrastruktur und Technologie der Mobilfunknetzbetreiber nutzt, werden spezielle Verträge bei den Providern benötigt. Dies hat zur Folge, dass die laufenden Kosten bei NB-IoT deutlich höher ausfallen als bei anderen LPWAN-Technologien.

Als letztes richten wir unseren Blick auf den Newcomer Mioty. Mioty ist eine LPWAN-Technologie, welche im Jahr 2020 vom Fraunhofer IIS entwickelt worden ist, und den Frequenzbereich zwischen 133 MHz und 966 MHz nutzt. In der Regel wird jedoch, analog zu LoRaWAN, der lizenzfreie Bereich bei 868 MHz verwendet. Doch nicht nur beim Frequenzspektrum sind sich LoRaWAN und Mioty ähnlich. Laut offiziellen Angaben soll bei dieser Technologie eine Reichweite von bis zu 15 km möglich sein, und Endgeräte sollen je nach Konfiguration eine Akkulaufzeit von bis zu 20 Jahren ermöglichen. Damit bietet Mioty diesen Angaben zufolge eine leicht höhere Reichweite und Effizienz im Vergleich zu LoRaWAN. Diese Verbesserung wird durch das vom Fraunhofer-Institut patentierte Telegram-Splitting-Verfahren erreicht und ist in Abbildung 3 dargestellt. Bei dem Verfahren werden Datenpakete auf sogenannte Unterpakete und anschließend über Zeit und Frequenz aufgeteilt. Der Clou hierbei ist, dass jedes Unterpaket einen Teil eines anderen Unterpaktes enthält. Daher kann eine erfolgreiche Datenübertragung sogar noch bei einem Paketverlust von 50% stattfinden.

Durch dieses Verfahren soll der Einfluss von Störungen in dem genutzten Frequenzbereich minimiert werden. Ein weiterer Vorteil liegt darin, dass diese Technologie softwarebasiert ist und somit kommerzielle und kostengünstige Funkchips für die Endgeräte genutzt werden können. All die genannten Vorteile zeigen auf, dass Mioty die LoRaWAN-Technologie zukünftig ersetzen könnte. Aktuell hat Mioty noch einen entscheidenden Nachteil gegenüber LoRaWAN. Da sich LoRaWAN seit über 10 Jahren in der IoT-Welt etabliert hat, gibt es für diese Technologie Sensoren und Gateways zu nahezu jedem Einsatzzweck. Währenddessen befindet sich Mioty trotz Förderung durch die Mioty-Alliance noch in den Kinderschuhen, und das Angebot an End Nodes und Gateways ist im Vergleich zu LoRaWAN bislang sehr begrenzt. Mioty verfolgt einige gute Ansätze. Ob diese Technologie sich jedoch durchsetzen wird, gilt abzuwarten.

Lohnt sich das Simulieren eines LoRaWAN-Netzes?

Das ist eine Frage, die uns in einigen Projekten von unseren Kunden bereits gestellt wurde. Die Antwort darauf ist ein klares „Jein“. Es hängt stark vom einzelnen Projekt und vor allem der Größe des Gebäudes bzw. Gebiets ab. Wenn man beispielsweise ein mehrstöckiges Bürogebäude oder eine große Fabrik betrachtet, kann es sinnvoll sein, eine Simulation durchzuführen, um eine flächendeckende Versorgung sicherzustellen. Besonders in der Industrie kann eine Funkplanung komplex werden, da wir hier auf besondere Herausforderungen wie bewegliche Objekte in Form von Robotern stoßen. Des Weiteren existieren in vielen Fabrikhallen große metallische Objekte wie Heizöfen, verschachtelte Montagelinien oder auch automatisierte Lager, die komplett umzäunt sind. All diese Dinge behindern eine Funkwellenausbreitung und erschweren somit die Planung von Funknetzen. Dies gilt selbstverständlich nicht nur für LoRaWAN-Netze. Daher lautet gerade für solch komplexe Umgebungen die Empfehlung, eine Simulation durchzuführen und anschließend mit einer Messung zu verifizieren. Vergleicht man dies nun mit kleineren Bürogebäuden oder Fabriken mit einer weniger komplexen Umgebung, reicht in den meisten Fällen die Erfahrung aus, um ein LoRaWAN-Netz zu planen. Hierfür wird nicht immer zwingend eine Simulation benötigt. Sie kann jedoch hilfreich sein, besonders dann, wenn eine Dokumentation für die Planung benötigt wird.

Um ein LoRaWAN-Netz simulieren zu können, wird entsprechende Software benötigt. Die zwei am weitesten verbreiteten Simulationstools für IoT-Funkprotokolle, also auch LoRa, nennen sich iBwave und Ranplan Wireless. Bei beiden Simulationstools handelt es sich um sehr mächtige Tools, die neben IoT-Funkprotokollen weitere Funkprotokolle wie Mobilfunk, WLAN oder BOS/TETRA simulieren können. In einem früheren Artikel haben wir bereits das Tool von iBwave mit dem Tool von Ekahau für eine WLAN-Simulation verglichen [4]. Grund genug, uns das Tool von iBwave weiter im Detail anzuschauen und ein LoRaWAN-Netz für das Gebäude der ComConsult zu simulieren.

Abbildung 4 zeigt eine 3D-Heatmap-Darstellung des Firmengebäudes der ComConsult für ein LoRaWAN-Netz. Für die Simulation wurde das Sentrius RG191 LoRaWAN-Gateway vom Hersteller Laird genutzt. Gemäß der Simulation wird lediglich ein Gateway benötigt, welches zentral im 1. OG platziert worden ist, um eine ausreichende Funkversorgung im Gebäude zu gewährleisten. Auf der rechten Seite der Abbildung ist die dazugehörige Legende zu sehen. Sie stellt die Empfangsfeldstärke (Received Signal Strength Indication, RSSI) der erzeugten LoRaWAN-Zelle in dBm dar. Die Grenze der Zelle bestimmt die Empfängerempfindlichkeit der LoRaWAN-Endgeräte, welche im Durchschnitt bei -120 dBm liegt. Betrachtet man die Legende näher, so fällt auf, dass sich diese nur bis -120 dBm erstreckt. Hierbei handelt es sich um das Maximum, welches in iBwave für LoRaWAN derzeit dargestellt werden kann. Dies ist leider nicht ganz optimal, da für die Planung der Empfang oberhalb der Zellgrenze interessant ist. iBwave wurde bereits über diese Limitierung informiert und wird ein entsprechendes Update veröffentlichen.

Simulation vs. Messung

Wie bereits erwähnt sollte in den meisten Fällen die Simulation durch eine Funkmessung verifiziert werden, um sicherzugehen, dass das simulierte Ergebnis auch der Realität entspricht. Des Weiteren kann eine Funkmessung dazu genutzt werden, um bei einem bestehenden LoRaWAN-Netz Unterversorgungen zu identifizieren oder eine geeignete Position von Sensoren und Gateways zu bestimmen.

Für die Durchführung einer LoRaWAN-Funkmessung wird ein entsprechendes Messgerät benötigt, welches das LoRa-Signal im 868-MHz-Bereich decodieren kann. Hierfür nutzt die ComConsult den LoRaWAN-Feldtester vom Hersteller Adeunis, welcher von der LoRa Alliance freigegeben ist. Bei dem Feldtester handelt es sich um ein LoRaWAN-Endgerät gemäß der Endgeräteklasse A, das eine Empfangsempfindlichkeit von -140 dBm bei SF12 hat.

Damit eine Messung durchgeführt werden kann, muss der Feldtester mit dem zu messenden LoRaWAN-Netz verbunden werden. Hierbei wird entweder das Join-Verfahren Over The Air Activation (OTAA) oder Activation by Personalization (ABP) genutzt. Anschließend misst der Feldtester die folgenden Daten im Uplink und Downlink. Die Daten vom Uplink werden vom Gateway vorgegeben, und Downlink-Informationen beziehen sich auf einen Downlink-Frame, der von dem LoRaWAN-Netz gesendet wurde.

• Uplink
  • Frequenz
  • Genutzter Spreading Factor (SF)
  • Verwendete Leistung in dBm
  • Signal-Rausch-Verhältnis (SNR) vom Uplink in dB
• Downlink
  • Frequenz
  • Genutzter Spreading Factor (SF)
  • RSSI in dBm
  • SNR vom Download in dB

Neben diesen Informationen lässt sich auch die Qualität der Funkverbindung zwischen dem Feldtester und dem LoRaWAN-Netz bewerten. Hierfür gibt es ein Menü, welches die Anzahl der gesendeten Frames (einschließlich Wiederholungen), die Anzahl der empfangenen Frames sowie eine kalkulierte Paketfehlerrate (PER) in Prozent darstellt. Die PER wird berechnet, indem die Anzahl der gesendeten Frames mit der Anzahl der empfangenen Frames verglichen wird.

Nachdem wir eine LoRaWAN-Simulation durchgeführt haben, haben wir uns entschieden, ein LoRaWAN-Testnetz aufzubauen, um die besagte Simulation mit der Realität zu vergleichen. Abbildung 5 zeigt die durchgeführte Messung im Untergeschoss (UG) des Firmengebäudes der ComConsult. Nur noch mal zur Erinnerung: Das Sentrius Gateway befindet sich im 1. OG des Gebäudes. Es ist gut zu erkennen, dass selbst im UG noch eine ausreichend starke LoRaWAN-Versorgung gegeben ist. Lediglich im oberen rechten Teil des UGs nähern wir uns der Zellgrenze von -120 dBm. Hier möchten wir jedoch nochmals betonen, dass die Empfangsempfindlichkeit von den eingesetzten Endgeräten abhängig ist.

Zum Vergleich der Messergebnisse stellt Abbildung 6 die Simulation im UG dar. Hier sieht man, dass diese besonders im unteren Teil der Fläche nicht mit den gemessenen Werten übereinstimmt. Das Signal ist in Realität deutlich besser, im Schnitt um ca. 15 dBm. Im oberen rechten Teil der Fläche hingegen nähert sich die Simulation der Realität deutlich besser an.

Dieser kurze Vergleich zeigt schon deutlich, dass eine Referenzmessung zu empfehlen ist, bevor sämtliche Gateways gemäß einer Simulation montiert und installiert werden.

Fazit

Zusammengefasst kann festgehalten werden, dass LoRaWAN im Markt mittlerweile eine gewisse Verbreitung gefunden hat und immer häufiger für unterschiedliche Szenarien eingesetzt wird. Neben anderen LPWAN-Funktechniken geht der Trend vor allem in der Industrie zu LoRaWAN hin. Dies ist wahrscheinlich damit zu begründen, dass der Aufwand zum Aufbau der Infrastruktur sehr überschaubar ist. Eine Implementation in bestehende Netzwerke ist in der Regel auch keine wirklich große Herausforderung, da die meisten üblicherweise genutzten Protokolle, wie beispielsweise SNMP für den Managementverkehr, unterstützt werden.

Wie dargestellt, ist eine Simulation von LoRaWAN nicht immer notwendig. Meistens lohnt sie sich erst bei größeren oder komplexeren Umgebungen. Doch hier gilt zu erwähnen, dass bei komplexeren Umgebungen die Simulation meist recht umfangreich ist, wenn diese der Realität entsprechen soll, wie z. B. bei bewegbaren metallischen Objekten in einer Fabrik. Daher ist es immer zu empfehlen, eine Testmessung durchzuführen, um gute Positionen für die Gateways und End Nodes festzulegen.

Nichtsdestotrotz entwickelt sich der Markt weiter, was am neuem Protokoll Mioty zu erkennen ist. Es ist jedoch noch viel zu früh, um erkennen zu können, wohin die Reise mit diesem Protokoll gehen wird. Ob diese neue Technologie daher LoRaWAN irgendwann ersetzen kann, gilt abzuwarten.

Verweise

[1]  Dr. Bouguera, T., Diouris, J.-F., Chaillout, J.-J., Jaouadi, R., & Dr. Andrieux, G. (2018). Energy Consumption Model for Sensor Nodes Based on LoRa and LoRaWAN. Retrieved from https://doi.org/10.3390/s18072104

[2] LoRa Alliance. (2022, Juli 11). Retrieved from LoRaWAN Certified Devices: https://lora-alliance.org/showcase/search/?_sfm_lorawan_certified_device=certified&sf_paged=7

[3] Mioty Alliance. (2022, Juli 10). Retrieved from The mioty technology: https://mioty-alliance.com/miotytechnology/

[4] Feuser, D., & Schneiders, M. (01. Dezember 2021). ComConsult GmbH. Von WLAN-Planungstools im Vergleich – Ekahau Pro versus iBwave Design: https://www.comconsult.com/wlan-planungstools-im-vergleich-ekahau-pro-versus-ibwave-design/ abgerufen