Anwendungsfälle und Überlegungen für LoRaWAN

Wichtiger Hinweis: Link Labs ist der Hersteller von Symphony Link, einem alternativen Protokoll für LoRa, das sich auf hochzuverlässige Anwendungsfälle in Industrie und Unternehmen konzentriert. Mehr unten.

Wenn Sie LoRaWAN und seine idealen Anwendungsfälle und Einschränkungen verstehen möchten, ist es wichtig, ein wenig die Geschichte zu verstehen. LoRaWAN (damals LoRaMAC genannt) wurde von Semtech (dem alleinigen Eigentümer der LoRa PHY IP) in Zusammenarbeit mit IBM Research (sie verließen das Projekt später) entwickelt. Die Annahmen bei der Entwicklung des Protokolls waren:

• Zu verwenden von Mobilfunknetzen
• In einem einzigen koordinierten Netzwerk
• Im nicht lizenzierten 868-MHz-Frequenzband

Dies sind wichtige Annahmen, denn das resultierende Protokoll hat:

• 1 % Duty Cycle Limit (für alle Sender UND das Gateway)
• Gemeinsame Frequenzkanalkarte
• MAC (Layer 2) Verarbeitung nur in der Cloud

Um insbesondere die Einschaltdauer von 1 % für das Gateway zu unterstützen, sind viele Kompromisse erforderlich:

• Fast alle Uplink-Nachrichten werden nicht bestätigt
• Alle Gateways in Reichweite sehen den gesamten Uplink-Traffic
• Die gesamte Verschlüsselung erfolgt mit statischen Schlüsseln

Da alle Uplink-Nachrichten unbestätigt und unkoordiniert sind, gilt LoRaWAN als „reines Aloha“-Schema. Ein solches Netzwerk hat einen Wirkungsgrad von etwa 18%. Dies bedeutet, dass 82 % der Pakete verloren gehen, wenn ein LoRaWAN-Netzwerk vollständig ausgelastet ist. Da die meisten Nachrichten unbestätigt sind, weiß der Endknoten nicht, dass seine Nachricht verpasst wurde. Um dies zu verhindern, senden einige Benutzer möglicherweise häufiger, was das Problem verschlimmert. Lesen Sie diesen leicht verständlichen Beitrag über Aloha Networks.

Werden diesem System Quittungen hinzugefügt, versagt die Effizienz noch mehr. Dies liegt daran, dass die Basisstation immer dann nicht mithören kann, wenn sie sendet. Die Endknoten wissen nicht, dass das Gateway sie nicht hören kann. Da das Gateway nur 1 % der Zeit übertragen kann, führt dies nur zu etwa 1,65 % zusätzlichem Paketverlust.

Wenn jemand anderes ein LoRaWAN-Netzwerk verwendet, wird außerdem der gesamte Datenverkehr auf Ihre Kapazität angerechnet. Dies liegt daran, dass alle Gateways auf die gleichen gemeinsamen Frequenzen abgestimmt sind.

Eine weitere wichtige Überlegung für LoRaWAN ist das Nah-/Fernproblem. Da LoRa nur 20-30 dB des Gleichkanal-Dynamikbereichs hat, übertönen Knoten, die sich in der Nähe des Gateways befinden, weit entfernte Knoten. Dies ist in großen MNO-Netzen weniger von Bedeutung, da idealerweise mehrere Gateways in Reichweite sind.

Unsere Freunde von The Things Network haben auch diesen Artikel zu LoRaWAN-Beschränkungen zusammengestellt.

Alles in allem ist der ideale Anwendungsfall für LoRaWAN:

• Einfache Sensoren, die selten senden müssen
• Manchmal 5–85 % der Daten zu fehlen, ist in Ordnung
• Keine Möglichkeit, dieses Gerät zu steuern
• Keine Möglichkeit, die Gerätefirmware drahtlos zu aktualisieren
• Zu Dutzenden bis Hunderten bereitgestellt
• Kann mehrere Gateways bereitstellen, um jeden Knoten abzudecken

Einige automatische Zählerstände sind ein großartiges Beispiel für einen guten Anwendungsfall für LoRaWAN. Bei Zählern, die den Messwert aktualisieren, beispielsweise einmal pro Stunde, spielt es keine Rolle, ob einige Messwerte verpasst werden, solange einige es schaffen.

Symphony Link löst viele dieser Probleme. So geht es kurz:

1. Rahmen: Das Gateway sendet alle 2 Sekunden einen Frame-Header, der Informationen darüber enthält, welche Uplink-Kanäle verfügbar sind und wann sich das Uplink-Fenster öffnet.

2. Komprimierte Bestätigungen: In Symphony Link werden standardmäßig alle Uplink-Nachrichten bestätigt. Um dies zu erreichen, werden alle Bestätigungen zu einer komprimierten Nachricht zusammengemischt, die alle Knoten (die gerade gesendet haben) empfangen.

3. Variables Uplink-/Downlink-Zeitfenster: Das Gateway entscheidet basierend auf dem in der Warteschlange befindlichen Downlink-Verkehr, wie lange es zum Senden benötigt. Es teilt den Knoten mit, wann das Downlink-Fenster abgeschlossen ist, sodass die Knoten niemals senden, wenn das Gateway nicht zuhört

4. Uplink-Zeitfenster: Aufgrund des synchronen Framings sind die Uplink-Fenster geschlitzt, was etwa 100 % mehr Kapazität hinzufügt. Dies wird weiter erhöht, indem vor jeder Übertragung ein variables CSMA-Fenster hinzugefügt wird.

5. Variable Leistung und Streufaktor: Der Endknoten empfängt die RSSI der Framing-Nachricht des Gateways und passt seine Leistung und seinen Spreizfaktor dynamisch an, um mit der Verbindung plus einem einstellbaren Randfaktor übereinzustimmen. Dies maximiert die Kapazität, mildert schnelles Fading und verhindert das oben erwähnte Nah/Fern-Problem.

6. Servicequalität: Knoten registrieren einen QOS-Faktor (0-15) beim Gateway, und dies begrenzt ihre Fähigkeit, auf Kanäle in jedem Frame zuzugreifen. Es bietet dem Gateway auch die Möglichkeit, den Uplink in Stauzeiten zu begrenzen.

7. Multicasting: Durch die Zuweisung von Knotengruppen zu Multicast-Gruppen wird die für die Steuerung und das Dateistreaming erforderliche Downlink-Menge begrenzt.

8. Feste 256-Byte-MTU: 12 Byte sind für die meisten Anwendungen zu klein. Symphony Link bietet eine feste 256-Byte-MTU und verarbeitet die gesamte Unterpaketierung (durch SF) und Wiederholungen auf der MAC-Schicht.

9. Firmware drahtlos: Aufgrund der leistungsstarken Multicast-Funktionen in Symphony Link können Firmware-Dateien an Knoten gesendet werden.

10. PKI-basierte Sitzungs-AES-Schlüssel: Symphony Link verwendet keine Verschlüsselung mit festem Schlüssel. Jeder Knoten hat mit Diffie-Helmann eine sichere AES-Sitzung aufgebaut, wobei der öffentliche Schlüssel des Knotens vom Server bereitgestellt wird. Dies ist branchenweit als das sicherste Kanalverschlüsselungsschema bekannt.

Möchten Sie mehr erfahren? Nehmen Sie Kontakt mit uns auf.