Das LoRaWAN-Ökosystem wächst schneller als jede andere funkbasierte Systemlandschaft. Die Technologie eröffnet enorme Möglichkeiten, um Tausende physikalische und technische Messgrößen zu erfassen, die bisher wirtschaftlich nicht umsetzbar waren. Viele Unternehmen haben diese Erfahrung bereits erfolgreich gemacht.

Die vermeintliche Einfachheit von LoRaWAN veranlasst jedoch viele Unternehmen dazu, darüber nachzudenken, ihr eigenes privates Netzwerk zu entwickeln und bereitzustellen. Mit Open-Source-Software wie ChirpStack oder The Things Stack lässt sich ein solches Netzwerk schnell verwalten, ohne dass tiefgreifendes nachrichtentechnisches Fachwissen erforderlich ist. Solange die Netzwerklast innerhalb eines bestimmten Rahmens bleibt, funktioniert auch alles reibungslos. Doch sobald die Netzgröße zunimmt und die Anzahl der Pakete pro Sekunde steigt, stoßen die Standard-Einstellungen an ihre Grenzen. Dies führt zu Problemen wie hoher Paketfehlerrate (PER),zyklischem oder resonierendem Verhalten bis hin zu unerwarteten Neustarts der Endgeräte.

Was passiert, wenn diese Probleme auftreten? Herausforderungen, die bei der Nutzung eines Drittanbieters oder einer schlüsselfertigen Cloud-Lösung oft verborgen bleiben, könnten erhebliche Schwierigkeiten bereiten, wenn man sie in einem selbstverwalteten Netzwerk nicht vollständig versteht. Die Notwendigkeit, Tausende von Sensoren aufgrund einer falschen Konfiguration manuell wieder zu verbinden, ist ein Albtraum, den kein Unternehmen erleben möchte.

Um solche Probleme nachträglich in den Griff zu bekommen, muss man sich eingehend mit den MAC-Protokollen befassen. Insbesondere die RX-Verhaltensparameter,die Adaptive-Data-Rate(ADR)-Logik (sowohl auf Endgeräte- als auch auf Serverseite) sowie die globalen, lokalen und gerätespezifischen Einstellungen müssen auf Basis der Netzqualität und der Profilanforderungen der verwendeten Geräte sorgfältig angepasst werden.

Im Folgenden sind fünf fundamentale Aspekte aufgeführt, die bei der Implementierung eines LoRaWAN-Netzwerks im großen Maßstab berücksichtigt werden müssen.

Standardmäßig hat das System nur eine Sekunde Zeit, nachdem ein Endgerät eine Uplink-Nachricht gesendet hat, um eine Downlink-Nachricht zurückzusenden. Diese sogenannte RX1-Verzögerung ist kritisch.

Innerhalb dieser Sekunde muss Folgendes geschehen:

1. Der Uplink vom Endgerät muss über das Gateway empfangen werden.
2. Der Uplink wird dekodiert, verarbeitet und eine Downlink-Nachricht wird erstellt.
3. Die Downlink-Nachricht wird vom Netzwerkserver zum Gateway gesendet.
4. Das Gateway sendet die Downlink-Nachricht an das Endgerät.

In einem internen Gigabit-Netzwerk könnte dies funktionieren. Aber bei Gateways, die über 4G verbunden sind, oder bei Servern, die komplexe Rechenoperationen durchführen, wird diese Zeitspanne häufig überschritten. Ändern Sie diese Verzögerung nach der Join-Phase Ihrer Endgeräte, müssen diese erneut verbunden werden, da sie sonst keine Downlink-Nachrichten mehr empfangen.

Die genutzten ISM-Band-Frequenzen unterscheiden sich nach Duty Cycle (0,1 %, 1 % und 10 %) sowie der maximalen Sendeleistung (14 dBm, 27 dBm). In vielen geografischen Umgebungen existieren zudem bereits andere Sender, die möglicherweise Störungen verursachen oder signifikant interferieren. Da Gateways während des Sendens nicht empfangen können, ist es wichtig, hohe Spreizfaktoren zu vermeiden. Um unter diesen Bedingungen eine stetige Parameteroptimierung für RX1 und RX2 zu gewährleisten, ist ein skalierbarer Ansatz erforderlich, der an die lokalen Netzsegmente angepasst ist. Dabei sollte ebenfalls darauf geachtet werden, unter welchen Aspekten sich der Netzwerkserver für die Verwendung von RX1 oder RX2 entscheidet.

Duty Cycle im 868 MHz ISM-Band:

• 863,0-868,0 MHz: 1 %
• 868,0-868,6 MHz: 1 %
• 868,7-869,2 MHz: 0,1 %
• 869,4-869,65 MHz: 10 %
• 869,7-870,0 MHz: 1 %

Darüber hinaus ist zu beachten, dass LoRaWAN kein symmetrisches Netzwerk ist und die Up- und Downlink-Kapazitäten voneinander abhängen. Wenn das Gateway damit beschäftigtist, einen Downlink zu senden, werden alle eingehenden Uplinks verpasst. Der ADR-Algorithmus legt die Uplink-Frequenz und -Datenrate fest, aber der Downlink-Spreizfaktor für RX2 wird getrennt verwaltet. Wählen Sie einen Downlink-Spreizfaktor von SF12, maximieren Sie zwar die Reichweite, doch gleichzeitig sinkt die Gesamtleistung des Netzwerks. Deshalb empfiehlt zum Beispiel The Things Network (TTN) für das EU863-870-Band die Verwendung von SF9 statt SF7 – SF12 im RX2. Dennoch gibt es keine universell gültige Antwort. Sie müssen die Leistung Ihres Netzwerks kontinuierlich überwachen und individuell entscheiden, welche Einstellung am besten passt.

Der ADR-Mechanismus ist ein Schlüssel zur Skalierung von LoRaWAN-Netzwerken. Allerdings birgt er auch erhebliche Risiken. Wenn die serverseitige ADR-Logik ein Endgerät dazu bringt, die Spreizfaktoren zu stark zu reduzieren, kann die Verbindung abbrechen. Je nach verwendetem Netzwerkserver können Sie Ihre eigene ADR-Logik implementieren. Zur Umsetzung muss ein individueller ADR-Algorithmus implementiert und als Plug-in auf dem Server deployt werden.

Sie sollten zumindest die ADR-Marge für jede Geräteklasse genau prüfen, um ein Gleichgewicht zwischen Effizienz und Zuverlässigkeit zu finden. Änderungen dieses Parameters sollten auf fundierten Kenntnissen beruhen, da aufgrund aggressiver Einstellungen Endgeräte nicht mehr erreichbar sind.

Bei LoRaWAN wird reiner Uplink-Verkehr von Endgeräten zu Gateways stark bevorzugt. Bei größeren Netzen führt dies zu Problemen im Downlink-Traffic. Durch mehrere technische Einschränkungen kann die Netzwerkleistung erheblich beeinträchtigt werden.

Erstens führt die beschränkte Duty-Cycle-Regulierung, insbesondere in hochfrequentierten Subbändern, zu einer schnellen Sättigung der verfügbaren Kapazitäten. Diese Sättigung schränkt die Anzahl an möglichen Downlink-Übertragungen ein, sodass Gateways oft nicht in der Lage sind, rechtzeitig Rückmeldungen an Endgeräte zu senden, was wiederum die Zuverlässigkeit des Netzwerks reduziert.

Hinzu kommt, dass LoRaWAN-Gateways im Halbduplexmodus arbeiten, also nur entweder senden oder empfangen können. Wenn ein Gateway einen Downlink sendet, kann es keine Uplinks empfangen, was zu einer erhöhten Anzahl an Datenverlusten führt.

Zusätzlich wird das Problem durch die sequenzielle Verarbeitung von Downlink-Paketen verschärft, da nur ein Downlink zur gleichen Zeit versendet werden kann. Zusammengefasst führen diese Faktoren dazu, dass das LoRaWAN-Netzwerk bei zunehmendem Downlink-Traffic in seiner Skalierbarkeit und Zuverlässigkeit stark eingeschränkt wird.

Zur Verbesserung der Downlink-Skalierbarkeit in LoRaWAN-Netzwerken wird im ersten Schritt eine Multi-Gateway-Architektur empfohlen, bei der mehrere Gateways den Empfang von Uplink-Nachrichten auch während einer Downlink-Übertragung sicherstellen. Dies vermindert Datenverluste, die durch die Halfduplexeinschränkung der Gateways entstehen.

Zweitens wird ein ausgewogenes Gateway-Auswahlverfahren vorgeschlagen, das die Belastung gleichmäßig auf die verfügbaren Gateways verteilt und somit eine vorzeitige Sättigung der Gateways verhindert. Drittens wird die parallele Downlink-Übertragung diskutiert, bei der mehrere Downlink-Frames gleichzeitig auf verschiedenen Kanälen oder mit unterschiedlichen Spreizfaktoren gesendet werden, um die Empfangsfenster zu optimieren und die Gesamteffizienz zu steigern. Diese Ansätze bieten signifikante Verbesserungen hinsichtlich der Zuverlässigkeit und Kapazität von LoRaWAN-Netzwerken unter hoher Downlink-Belastung.

Dieser Artikel verdeutlicht, wie einfach es ist, Fehler zu machen, die nahezu katastrophale Folgen haben könnten, wenn Sie ein LoRaWAN-Netzwerk ohne tiefgehendes Verständnis der Technologie implementieren. In Wirklichkeit gibt es jedoch weit mehr als nur diese fünf Punkte zu beachten. Zudem sind beispielsweise beim ChirpStack für viele oben genannte Parametrisierungen Programmierkenntnisse sowie Zugriff auf das Serverdeployment erforderlich.

Wenn Sie sich unsicher sind oder keine Zeit für eine umfassende Einarbeitung haben, sollten Sie in Betracht ziehen, professionelle Unterstützung in Anspruch zu nehmen, um kostspielige Fehler zu vermeiden. Hierfür steht Ihnen das LoRaWAN-Team bei PHYSEC gerne zur Seite.

Jetzt kostenlosen Beratungstermin vereinbaren!