Erstes Konzept für allgemeine LoRa-Nutzung im S³I-Kontext
Grundlagen und Motivation
Im Rahmen verschiedener Forschungsprojekte kam die Frage nach der Nutzung von LoRa (Long Range) Kommunikation auf. LoRa ist eine neuere Funktechnologie, welche es ermöglicht (batteriebetriebene) Geräte (vor allem Sensoren) über lange Distanzen verbinden. Die Reichweite und der kleine Energieverbrauch werden durch Nutzung von geringen Bandbreiten und geringen Bitraten (und den schlauen Funkansatz selber) ermöglicht. Da das S³I eine möglichst flexible IoT-Plattform sein soll und bereits gängige Kommunikationsprotokolle wie OPC-UA, MQTT, HTTP oder AMQP unterstützt, liegt es nahe, auch solche sich im IoT-Bereich immer mehr verbreitende Technologie zu integrieren.
Hierbei gibt es einige Besonderheiten bei der Nutzung von LoRa, welche nicht aus den Augen gelassen werden dürfen:
-
Niedrige Übertragungsraten: Durch die besondere Übertragungsart erreicht LoRa je nach benötigter Reichweite/Signal-to-Noise Ratio eine theoretische Übertragungsrate im Kilobit Bereich. Dies wird durch rechtliche Bestimmungen in Deustchland noch mehr geschmälert, da man auf den erlaubten Funkbändern nur 1% der Sendezeit (z.B. insgesamt 14,4min pro 24h) nutzen kann - in anderen Worten sprechen wir von Übertragungsraten im dreistelligem Bitbereich.
-
Sendeverhalten der Geräte: LoRa-Geräte werden in drei Klassen nach ihrem Sende- und Empfangsverhalten eingeteilt:
- Class A: Diese Geräte können nur in einem kurzen Zeitfenster empfangen nachdem sie selber gesendet haben. Danach können diese bis zum nächsten Senden nicht angesprochen werden.
- Class B: Diese Geräte haben regelmäßige kurze Zeitfenster für Empfang von Nachrichten. Verbraucht mehr Energie als Class A.
- Class C: Diese Geräte sind durchgänging auf Empfang (außer sie senden selber). Verbraucht am meisten Energie und sollte am besten nicht Batteriebetrieben laufen.
Je nach Klasse kann es somit zu großen Latenzen in der Kommunikation zu einem LoRa-Gerät hin kommen, wenn es nicht kontinuierlich auf Empfang ist.
-
Abhängigkeit von Gateways: Durch die besondere Funktechnologie muss es besondere Gateways geben, welche LoRa-Funk empfangen können und in andere Formate übersetzen können.
-
Management eines LoRaWANs: Sobald man für eine größere Abdeckung mit LoRa mehrere Gateways benutzt, welche verschiedene Geräte empfangen, braucht man einen Network Server um das LoRaWAN Protokoll umsetzten zu können, welches das entstandene Netzwerk verwaltet.
Eine "klassische" LoRaWAN-Architektur sieht somit folgendermaßen aus:
Mehrere Gateways können verschiedene Endgeräte empfangen, übersetzen die Nachrichten und leiten diese über bekannte TCP/IP basierte Kommunikation an einen zentralen Network Server. Zu seinen Aufgaben gehören:
- Entschlüsselung von Nachrichten
- Deduplikation von Nachrichten
- Empfangen von Downlink-Nachrichten an seine Endgeräte
- Routing von Downstream-Nachrichten
- Adaptive Einstellung der Datenraten der Geräte
- Überwachung des Gerätestatus
- Überprüfung neuer Geräteanmeldungen
- Loggen von Nachrichten
- Weiterleiten von Nachrichten an entsprechende Application Servers
Es gibt verschiedene (meist kommerzielle) Anbieter von solchen Network Servern, jedoch um den Open Source Grundgedanken des S³Is zu erhalten ist Chirpstack der aktuelle Kandidat um LoRa an das S³I anzubinden. Dieser ist eine Open Source Implementierung des Network Servers, welcher verschiedene Gateway-Typen unterstützt und APIs zur Integration gängiger Kommunikationsprotokolle ermöglicht. Die Chirpstack-Architektur sieht folgerndermaßen aus:
Für unsere Anwendung der interessanteste Aspekt ist die Unterstützung von HTTP und MQTT (in der nächsten Version auch AMQP) Integrationen der Application Server, in unserem Fall das S³I und dessen Teilnehmer. Wir sehen somit, dass die eigentliche LoRa-Kommunikation eigentlich nur am Ende zwischen den Endgeräten und Gateways stattfindet und der Network Server und die folgenden Application Servers über "normale" TCP/IP basierte Protokolle reden.
Integrationskonzept mit LoRa-Adapter
Das Konzept basiert auf einem neuen LoRa-Adapter der Zugriff auf das Repository hat und per MQTT zum Chirpstack vermittelt. Er ist eine Art "Übersetzer" zwischen Strukturen und Funktionalitäten von S³I und deren Varianten in der LoRa-Welt. Das Konzept soll anhand von mehreren Szenarios erläutert werden um die funktionsweise des Adapters besser nachvollziehen zu können.
Szenario 1: Thing mit Eigenschaften welche über LoRa empfangen werden:
In diesem Szenario gibt es ein im Directory (und ggf. Repositiory) gewohnt definiertes Thing, welches ein Temperatursensor repräsentiert. Dessen aktueller Wert wird über einen per LoRa angebundenen echten Temperatursensor gesetzt.
Jedes LoRa Endgerät hat eine eindeutige devEUI, das Thing hat seine thingId. Es muss somit eine Komponente geben, welche die Zuordnung von der devEUI zur Thing-ID kennt. Wenn der Sensor zum LoRaWAN hinzugefügt wird, muss also dessen devEUI an den Adapter weitergegeben werden. Ein Nutzer müsste dann die Zuordnung beim Erstellen des Things definieren. Gleichzeitig wird von Chirpstack ein MQTT Topic für das neue Endgerät erstellt auf welches der Adapter hört. Wenn nun ein neuer Messwert gesendet wird, sendet Chirpstack diesen als Event unter dem entsprechenden Topic. Der Adapter filtert nach dem Eventtyp und wenn der Uplink registriert wurde, sucht der Adapter die passende thingId zu dem devEUI des Uplinks aus, authentifiziert sich regulär, findet die Endpoints des Things im Repository und stellt einen SetValueRequest mit dem empfangenen Messwert.
Die Konfiguration zu Beginn würde folgendermaßen aussehen:
- Erstellen eines Device-Profils im Chirpstack mit entsprechendem Codec. Dieser wird entweder vom Hersteller bereitgestellt oder muss bei eigenen Sensoren selber erstellt werden. --> Binäres Payload wird in definiertes JSON-Objekt übersetzt. Beispielhaftes Ergebnis:
- Der Sensor meldet sich im LoRa-Netzwerk an --> Join-Event wird im Join-Topic
application/APPLICATION_ID/device/DEV_EUI/event/join
mit seiner devEUI gesendet. Beispiel Join-Event: - Der LoRa-Adapter merkt sich die devEUI und das Device-Profil als "offene Devices". Alle eingesetzten Device-Profile müssen zuvor im LoRa-Adapter aufgelistet und ihre Codecs bekannt sein.
- Der Nutzer registriert das Thing und es bekommt seine thingId im Directory.
- Der LoRa-Adapter präsentiert dem Nutzer seine offene Devices und der Nutzer weist die richtige thingId zu.
- Der LoRa-Adapter kann nun das Thing und seine Attribute in der Directory nachsehen. Durch das bekannte Device-Profil, weiß der Adapter welche JSON-Felder mit Daten er erwarten kann. Diese müssen als letztes vom Nutzer den gefundenen Attributen des Things zugeordnet werden. --> Abbildung von LoRa-Nachrichteninhalten auf entsprechende attributePaths des Things um bei neuen LoRa-Nachrichten die korrekten SetValueRequests stellen zu können.
Szenario 2: Kommunikation mit einem Thing über LoRa
In diesem Szenario soll ein Thing auf der "Edge" exsitieren und nur per LoRa erreichbar sein. Er bietet einen Dienst an und ein anderer Teilnehmer möchte den Dienst nutzen.
Für ein Thing, dass über LoRa erreicht werden soll, muss ein besonderer Endpoint im Directory angegeben werden. Da man den Umweg über den LoRa-Adapter + Chirpstack nehmen muss, haben wir keine direkte Adresse wie in S³I-B, OPC-UA oder ähnlichem. Sattdessen ist seine Adresse so etwas wie lora://[thingId]. Wenn wir nun ein ServiceRequest an etwas mit lora://[thingId] senden, sollen diese automatisch an den LoRa-Adapter gesendet werden. Dieser kann die mitgelieferte thingId einer devEUI zuordnen (Die Korresondenz wurde beim Hinzufügen des jeweiligen LoRa-Knotens ja von einem Nutzer definiert). Dieser kann nun auf dem korrekten Topic einen Downlink posten, welcher von Chirpstack an die jeweilige Adresse bei der nächsten Möglichkeit gesendet wird. (Durch die verschiedenen Geräteklassen kann es jedoch zu großen Latenzen kommen) Dabei muss sich der LoRa-Adapter merken welche Adresse auf welche ServiceReply wartet, damit die Senderadresse nicht per LoRa "rumgeschleppt" werden muss. Im Payload des Downlinks müssen deswegen möglichst kompakt (Base64 encoding z.B.) die Art des Requests und ggf. die übergebenen KeyValues gelistet werden.
Aktuell gibt es mit GetValue, SetValue, DeleteAttribute, CreateAttribute vier vordefinierte Requests und individuell gestaltbare ServiceRequests. Falls ein Service angeboten wird muss dies neben der devEUI Zuordnung ebenfalls vom LoRa-Adapter festgehalten werden und einer Nummer zugeordnet werden. Somit kann die Art der Nachricht z.B. im ersten Byte des Payloads definiert werden (4 Arten AttributeValueMessages + bis zu 251 mögliche angebotene Services pro Thing). Wird dann per LoRa an den Service Provider gesendet, dieser decodiert sie und erkennt die Anfrage und Parameter. Daraus wird eine Antwort gestaltet, welche durch den entsprechenden Codec des Device-Profils. Diese wird ähnlich wie der Downlink (Nachrichtenart + Werte) formuliert und wie in Szenario 1 als Uplink gesendet. Wenn die Antwort dann auf dem jeweiligen Topic veröffentlicht wird, kann der LoRa-Adapter die vorher festgehaltenen offenen ServiceRequests auflösen und die entsprechenden ServiceReplies formulieren.
Szenario 3: Edge Thing fragt Informationen ab
Tbd
Szenario 4: User Interaktion per HMI
Tbd