Die Backend-Systeme von The Things Network sind für die Weiterleitung von Internet of Things-Daten zwischen Geräten und Anwendungen verantwortlich. Ein typisches Internet of Things-Netzwerk erfordert Gateways als Brücke zwischen bestimmten Funkprotokollen und dem Internet. In Fällen, in denen die Geräte selbst den IP-Stack unterstützen, müssen diese Gateways nur Pakete an das Internet weiterleiten. Nicht-IP-Protokolle wie LoRaWAN erfordern eine Art Routing und Verarbeitung, bevor Nachrichten an eine Anwendung übermittelt werden können. Das Things Network befindet sich zwischen den Gateways und den Anwendungen (siehe Abbildung unten) und übernimmt diese Routing- und Verarbeitungsschritte.
Die Vision des Things Network ist es, alle diese Routing-Funktionen dezentral und verteilt auszuführen. Jeder Interessent sollte in der Lage sein, ein eigenes Netzwerk und einen eigenen Teil des Backends einzurichten, um am globalen Community-Netzwerk teilnehmen zu können. Um das Netzwerk zu dezentralisieren, wurde es in eine Reihe von Komponenten aufgeteilt, die in der folgenden Abbildung dargestellt sind. Der Einfachheit halber werden Komponenten nur einmal angezeigt, obwohl es möglich ist, eine-zu-viele- oder eine-zu-viele-Beziehung zwischen Komponenten herzustellen.
Knoten senden LoRaWAN-Nachrichten über das LoRa-Funkprotokoll. Diese Nachrichten werden von mehreren Gateways empfangen. Das Gateway ist eine Hardware, die Funkübertragungen an das Backend weiterleitet. Es ist mit einem Router verbunden. Der Router ist für die Verwaltung des Gateway-Status und die Planung von Übertragungen verantwortlich. Jeder Router ist mit einem oder mehreren Brokers verbunden. Makler sind der zentrale Teil des Things Network. Sie sind dafür verantwortlich, ein Gerät einer Anwendung zuzuordnen, Uplink-Nachrichten an die richtige Anwendung weiterzuleiten und Downlink-Nachrichten an den richtigen Router weiterzuleiten (der sie an ein Gateway weiterleitet). Der Netzwerkserver ist für die Funktionen verantwortlich, die für LoRaWAN spezifisch sind. Ein Handler ist für die Verarbeitung der Daten einer oder mehrerer Anwendungen verantwortlich. Zu diesem Zweck wird eine Verbindung zu einem Broker hergestellt, in dem Anwendungen und Geräte registriert werden. Der Handler ist auch der Punkt, an dem Daten verschlüsselt oder entschlüsselt werden.
Das Ziel von The Things Network ist es, hinsichtlich der Bereitstellungsoptionen sehr flexibel zu sein. Die bevorzugte Option besteht darin, eine Verbindung zum öffentlichen Community-Netzwerk herzustellen, das von The Things Network Foundation oder seinen Partnern gehostet wird. In diesem Fall stellt die Anwendung eine Verbindung zu einem Public Community Network Handler her, wobei normalerweise die MQTT-API verwendet wird.
Es ist auch möglich, private Netzwerke bereitzustellen, indem alle diese Komponenten in einer privaten Umgebung ausgeführt werden. Auf diese Weise bleiben alle Daten in der privaten Umgebung, Sie können jedoch weiterhin den von TTN gehosteten Kontoserver für die Authentifizierung und Autorisierung verwenden.
Hybridbereitstellungen werden in Zukunft möglich sein. Die einfachste Möglichkeit besteht darin, dass jemand seinen eigenen Handler ausführt, mit dem er die Verschlüsselung und Entschlüsselung von Nachrichten handhaben kann. Eine kompliziertere Option ist ein privates Netzwerk, das Daten mit dem öffentlichen Netzwerk austauscht. Damit dies funktioniert, müssen sich private Router mit öffentlichen Brokern verbinden und umgekehrt. In diesem Fall kann das private Netzwerk öffentlichen Datenverkehr in das Community-Netzwerk verlagern und das öffentliche Community-Netzwerk als Backup verwenden. Letzteres ist mit der aktuellen Implementierung des Backends noch nicht möglich.
Das Things Network bietet einen LoRaWAN-Netzwerkserver. LoRaWAN ist ein „netzwerkintensives“ Protokoll, und zwar in dem Sinne, dass aufgrund des einfachen und minimalistischen Ansatzes für Geräte die Back-End-Systeme (auch als Netzwerkserver bezeichnet) für den größten Teil der Logik verantwortlich sind. LoRaWAN wurde für die zentrale Architektur von Telekommunikationsbetreibern entwickelt. Um auf einer verteilten Infrastruktur wie The Things Network ausgeführt zu werden, mussten einige Schritte hinzugefügt werden. Im Backend von The Things Network werden nun verschiedene Kernfunktionen unterschieden.
Erstens gibt es Gateway-bezogene Funktionen wie das Planen und Verwalten der Nutzung der Gateways. Die Planung ist erforderlich, da ein Gateway zur gleichen Zeit nur eine Übertragung durchführen kann. Die Nutzungsinformationen werden verwendet, um die Last gleichmäßig auf verschiedene Gateways zu verteilen und die europäischen Arbeitszyklen einzuhalten.
Zweitens benötigen wir gerätebezogene Funktionen, die den Status von Geräten im Netzwerk verwalten. Da die Geräteadressen nicht eindeutig sind, muss das Netzwerk nachverfolgen, welche Adressen von welchen Geräten verwendet werden, um eine Nachricht dem richtigen Gerät und der richtigen Anwendung zuzuordnen. Andere Dinge, die das Netzwerk im Auge behalten muss, sind die Sicherheitsschlüssel und Frame-Zähler. In Zukunft werden wir auch damit beginnen, die Netzwerkauslastung jedes Knotens zu verfolgen.
Drittens gibt es einige Funktionen in Bezug auf Anwendungen. Beispielsweise müssen die Brokers und Handler wissen, an welchen Server Datenverkehr für eine bestimmte Anwendung weitergeleitet werden muss. Die Handler müssen wissen, wie man Binärdaten interpretiert und Protokolle höherer Ebenen wie AMQP und MQTT überbrückt.
Schließlich und vor allem, da The Things Network ein verteiltes Netzwerk ist, muss es Funktionen geben, die diese Verteilung unterstützen. Mithilfe der Diensterkennungsfunktion können Komponenten bestimmen, wohin der Datenverkehr geleitet werden soll. Derzeit ist dies als zentraler Discovery-Server implementiert, der The Things Network Foundation die Kontrolle darüber gibt, welche Komponenten bestimmte Dienste ankündigen dürfen.
Hybridbereitstellungen werden in Zukunft möglich sein. Die einfachste Möglichkeit besteht darin, dass jemand seinen eigenen Handler ausführt, mit dem er die Verschlüsselung und Entschlüsselung von Nachrichten handhaben kann. Eine kompliziertere Option ist ein privates Netzwerk, das Daten mit dem öffentlichen Netzwerk austauscht. Damit dies funktioniert, müssen sich private Router mit öffentlichen Brokern verbinden und umgekehrt. In diesem Fall kann das private Netzwerk öffentlichen Datenverkehr in das Community-Netzwerk verlagern und das öffentliche Community-Netzwerk als Backup verwenden. Letzteres ist mit der aktuellen Implementierung des Backends noch nicht möglich.
Ausgehend von dieser Trennung der Anliegen haben wir das Backend von The Things Network implementiert. Da jede Komponentenkomponente übergeordnete Verantwortlichkeiten hat, muss sie beim Verarbeiten von Uplink- und Downlink-Nachrichten eine Reihe von Aufgaben ausführen. Eine Übersicht über diesen Ablauf ist in der folgenden Abbildung dargestellt und wird im Rest dieses Abschnitts ausführlich erläutert.
Wenn ein Gateway eine Nachricht empfängt, die über LoRa übertragen wurde, wird sie gekapselt und über das Internet an The Things Network weitergeleitet (siehe Abbildung unten). Viele Gateways verwenden dasselbe Referenz-Gateway-Protokoll, es wurden jedoch alternative Protokolle für bestimmte Backends entwickelt. Das Things Network entwickelt auch ein eigenes Gateway-Protokoll, das in Bezug auf Sicherheit und Zugriffskontrolle besser für das Things Network als für das Referenzprotokoll geeignet ist.
Die meisten Gateway-Protokolle haben dieselbe Struktur. Wenn eine oder mehrere Nachrichten empfangen werden, werden ihre binären Nutzdaten zusammen mit Metadaten wie der Signalstärke (RSSI) und dem Signal-Rausch-Verhältnis (SNR) an das Backend weitergeleitet. In regelmäßigen Abständen sendet das Gateway auch einige Statusinformationen über das Gateway selbst, z. B. GPS-Koordinaten, Anzahl der empfangenen und gesendeten Pakete und andere Messdaten.
Wir erwarten, dass Gateways von verschiedenen Anbietern mit unterschiedlichen Protokollen verbunden werden. Um das Backend von The Things Network so allgemein wie möglich zu halten, implementieren wir eine Reihe von Bridges, die von jedem herstellerspezifischen Gateway-Protokoll in das Protokoll übersetzt werden, das intern im Backend von The Things Network verwendet wird.
Die GPS-Koordinaten eines Gateways können insbesondere für die Anwendung relevant sein. Daher speichert das Backend die letzte vom Gateway gesendete Statusnachricht und fügt die GPS-Informationen in die Metadaten jeder Uplink-Nachricht ein
In LoRaWAN hängt die Downlink-Antwort auf eine Uplink-Nachricht stark von der geografischen Region des Gateways ab und wird in der Spezifikation „LoRaWAN Regional Parameters“ beschrieben. Da der Router für alle Gateway-bezogenen und regionenspezifischen Details verantwortlich ist, muss er bestimmen, wie eine Downlink-Antwort an ein Gerät gesendet werden kann. Nach jeder Uplink-Nachricht erhalten zwei Fenster, eines genau 1 Sekunde nach dem Uplink und das andere nach 2 Sekunden. Daher erstellt ein Router für jedes Gateway, das die Uplink-Nachricht empfangen hat, zwei Downlink-Konfigurationen.
Um später die beste Option auszuwählen, muss der Router zusätzlich eine Punktzahl für jede Option berechnen. Diese Bewertung wird von einer Reihe von Faktoren beeinflusst. Im Moment berücksichtigen wir Sendezeit, Signalstärke, Gateway-Auslastung und bereits geplante Übertragungen. Letzteres liegt auf der Hand, da ein Gateway nicht zwei Übertragungen gleichzeitig durchführen kann. Durch das Planen einer Downlink-Nachricht auf einem Gateway mit einer besseren Signalstärke (Signal-Rausch-Verhältnis) ist es auch wahrscheinlicher, dass ein Knoten den Downlink korrekt empfängt.
Die Kombination aus der Sendezeit einer Nachricht und der Nutzung eines Gateways wird zur Optimierung des gesamten Netzwerks verwendet. Da bei jeder Übertragung die Empfänger eines Gateways für einige Zeit blockiert werden, ist es besser, Nachrichten in kürzerer Zeit zu senden. Daher werden Downlink-Nachrichten mit einer höheren Datenrate Nachrichten mit einer niedrigeren Datenrate vorgezogen. Die Nutzung eines Gateways gibt an, wie viel Prozent der Zeit ein Gateway Nachrichten empfängt. Gateways mit einer höheren Auslastung (da sie an einem guten Standort positioniert sind) sind daher für das Netzwerk wertvoller als Gateways mit einer geringeren Auslastung. Daher sollte Letzteres für Downlink-Nachrichten bevorzugt werden, damit Ersteres weiterhin Uplink-Nachrichten empfangen kann.
Der erste Schritt beim Weiterleiten eines Pakets basiert auf der Geräteadresse. Dieser DevAddr ist eine nicht eindeutige 32-Bit-Adresse, von der 25 Bit vom Netzbetreiber zugewiesen werden können. Das Things Network hat beschlossen, den Datenverkehr basierend auf dem Präfix der Geräteadresse zu verteilen. Jeder Broker kündigt eine Reihe von Geräteadressenpräfixen mit einem Erkennungsdienst an. Diese Präfixe ähneln der Ankündigung von IP-Adressbereichen in BGP. Netzwerkkomponenten können die Liste der Broker und ihre angekündigten Präfixe regelmäßig abrufen. Nachrichten werden an alle Broker weitergeleitet, die ein Präfix ankündigen, das mit der Geräteadresse der Nachricht übereinstimmt.
LoRaWAN ist ein Langstrecken-Funkprotokoll, bei dem es wahrscheinlich ist, dass die Nachricht von mehr als einem Gateway empfangen wird. Dies bedeutet, dass das Backend eine Art Deduplizierung durchführen muss, um der Anwendung eine Nachricht nur einmal zuzustellen. Dies bedeutet nicht, dass die Duplikate unwichtig sind. Die Metadaten dieser Nachrichten können ebenfalls wertvoll sein. Wenn Sie beispielsweise die Standorte der Gateways, die die Nachricht empfangen haben, mit der Empfangszeit und der Signalstärke kombinieren, können Sie möglicherweise den Standort des Geräts ermitteln, von dem die Nachricht gesendet wurde.
Die Deduplizierung ist in einem verteilten System nicht einfach, kann jedoch sehr einfach sein, wenn nur ein Server vorhanden ist. Aus diesem Grund haben wir beschlossen, zusätzlich zur Implementierung der Deduplizierung eine Abstraktion zu erstellen. Dies macht es einfach, die eigentliche Implementierung durch eine für den Anwendungsfall am besten geeignete zu ersetzen und dabei die gleiche Schnittstelle beizubehalten:
type Deduplicator interface {
// Deduplicate a value based on a given key
Deduplicate(key string, value interface{}) []interface{}
}
Die derzeitige Implementierung des Backends desupliziert Uplink-Nachrichten lokal auf der Basis der MD5-Summe der Nutzdaten. Die Nutzlast der Nachricht ist für alle Duplikate gleich, und die Wahrscheinlichkeit, dass während des Deduplizierungszeitraums (normalerweise einige Sekunden) eine andere Nachricht mit demselben Hash-Wert eintrifft, ist äußerst gering.
Gateways können mit jedem Zugangsnetzwerk verbunden werden. Einige sind mit einem kabelgebundenen Ethernet verbunden, andere verwenden WLAN- oder sogar GPRS-Verbindungen zum Internet. Obwohl sich Funkwellen mit Lichtgeschwindigkeit ausbreiten, gehen aufgrund der Netzwerkverzögerung keine doppelten Nachrichten gleichzeitig beim Broker ein. Um die von jedem Gateway zur Nachricht hinzugefügten Metadaten zu erfassen, muss der Broker für einige Zeit Duplikate puffern. Diese Zeit sollte lang genug sein, um so viele Duplikate wie möglich zu sammeln, aber kurz genug, um der Anwendung genügend Zeit zu geben, um auf eine Nachricht im Empfangsfenster zu antworten, die 1 Sekunde nach der Übertragung geöffnet wird.
Unsere Messungen im aktuellen Einsatz von The Things Network haben gezeigt, dass die durchschnittliche Verzögerung zwischen dem ersten und letzten Duplikat knapp 100 ms beträgt, wobei die maximale Verzögerung bei etwa 300 ms liegt. Wir stellen fest, dass diese Messungen in einem Netzwerk durchgeführt werden, in dem Gateways noch nicht dicht eingesetzt sind. Daher benötigen wir mehr Daten, um Schlussfolgerungen zu ziehen. Diese Werte geben jedoch einen guten Hinweis auf die erforderliche Deduplizierungszeit, die derzeit auf 200 ms eingestellt ist. Wenn mehr Daten gesammelt werden, kann diese Zeit weiter optimiert werden.
Da die Geräteadressen nicht eindeutig sind, müssen das genaue Gerät, von dem die Nachricht gesendet wurde, und die Anwendung, zu der sie gehört, ermittelt werden. Dazu muss das Backend eine Reihe von MIC-Überprüfungen (Cryptographic Message Integrity Code) für jedes Gerät durchführen, das dieselbe Geräteadresse verwendet. Dazu fordert der Broker eine Liste der Geräte mit der angegebenen Geräteadresse vom Netzwerkserver an und prüft, ob die MIC mithilfe des Netzwerksitzungsschlüssels überprüft werden kann. Wird keine Übereinstimmung gefunden, wird die Nachricht gelöscht.
Der Frame-Zähler in LoRaWAN-Nachrichten ist eine Sicherheitsmaßnahme zur Erkennung von Wiederholungsangriffen. Nach der Validierung des MIC prüft der Broker, ob der Frame-Zähler gültig ist. Da die Frame-Zähler nur ansteigen können, sollte eine Nachricht mit einem Frame-Zähler, der niedriger als der letzte bekannte Frame-Zähler ist, verworfen werden. Darüber hinaus muss der Broker sicherstellen, dass die Lücke zwischen dem letzten bekannten Frame-Zähler und dem Zähler in der Nachricht nicht zu groß ist. Gemäß der LoRaWAN-Spezifikation beträgt die maximale Lücke 16384.
LoRaWAN unterstützt sowohl 16-Bit- als auch 32-Bit-Frame-Zähler. Der Nachrichtenkopf enthält jedoch nur die 16 niedrigstwertigen Bits des Zählers. Daher muss das Backend den vollständigen 32-Bit-Frame-Zähler verfolgen und diesen anstelle des 16-Bit-Zählers verwenden, der in der Nachricht enthalten ist.
Wenn alle Prüfungen erfolgreich waren, kann der Broker die Nachricht weiter verarbeiten. Zunächst werden die von allen verschiedenen Routern und Gateways empfangenen Duplikate zusammengeführt. In diesem Schritt ist es wichtig, zwischen Metadaten, die für jedes Gateway, das die Nachricht empfangen hat, gleich sind, und Metadaten, die für jeden Empfang spezifisch sind, zu unterscheiden. Zum Beispiel sind Frequenz, Modulation und Datenrate für alle Gateways gleich und müssen nur einmal weitergeleitet werden. Andererseits sollten die Signalstärke, die Empfangszeit und die GPS-Koordinaten jedes Gateways bei der Weiterleitung der Nachricht berücksichtigt werden. In diesem Schritt werden auch die verschiedenen Downlink-Konfigurationen gesammelt, um im nächsten Schritt die beste Option auszuwählen.
Der Broker muss die beste Option für eine Downlink-Antwort auf eine Nachricht auswählen. Da der Broker keine Informationen über das Gateway hat, das eine Nachricht erhalten hat, ist dies sehr schwierig. Daher hat der Router bereits eine Punktzahl für jede Downlink-Konfiguration berechnet. Wenn diese Punktzahlberechnung auf standardmäßige Weise erfolgt, muss der Broker nur noch alle möglichen Downlink-Optionen sortieren und die beste Option verwenden.
Bevor die Uplink-Nachricht an den Handler weitergeleitet wird, wird sie zuerst an den Netzwerkserver gesendet, damit der Status des Geräts aktualisiert werden kann. Der Netzwerkserver fügt der Nachricht auch eine Downlink-Vorlage hinzu. Diese Vorlage kann vom Handler verwendet werden, um eine Downlink-Nachricht an das Gerät zurückzusenden. Es enthält alle erforderlichen Werte (z. B. Frame-Zähler, Nachrichtentyp und Optionsflags), sodass der Handler der Nachricht nur die Anwendungsnutzdaten hinzufügen muss. Darüber hinaus bietet dies dem Netzwerkserver die Möglichkeit, der Nachricht MAC-Befehle hinzuzufügen. Zum Beispiel kann der Netzwerkserver basierend auf der Anzahl der Gateways, die eine Nachricht empfangen haben, und ihrer Signalstärke MAC-Befehle hinzufügen, die das Gerät anweisen, mit einer höheren Datenrate zu senden.
Da Nachrichten durchgehend verschlüsselt werden, ist das Backend auch für die Entschlüsselung der Nachrichten verantwortlich. Der Anwendungsinhaber möchte jedoch möglicherweise nicht in allen Fällen, dass The Things Network dafür verantwortlich ist. Daher wird die Nachrichtenentschlüsselung in einer separaten Komponente (dem Handler) abgelegt, sodass ein Anwendungseigner diesen Handler in seiner eigenen privaten Umgebung ausführen kann.
Nach dem Entschlüsseln der Nachrichtennutzdaten kann der Handler die Nachricht an die Anwendung weiterleiten. Für viele Anwendungen ist jedoch eine einfache Dekodierung und Konvertierung erforderlich.
Nach der Entschlüsselung kann der Handler die Nutzdaten entschlüsseln und in ein Format konvertieren, auf das die Anwendung problemlos zugreifen kann. Die Implementierung des Default Handlers beinhaltet daher sogenannte Payload-Funktionen. Diese Funktionen sind einfache JavaScript-Funktionen, mit denen Daten dekodiert, konvertiert und validiert werden können. Der Decoder wird verwendet, um die binären Nutzdaten in ein geeigneteres Format zu decodieren. Die folgende Funktion dekodiert beispielsweise einen Temperaturwert, der als zwei Bytes an ein JSON-Objekt gesendet wird:
function (bytes) {
var data = (bytes[0] << 8) | bytes[1];
return { temperature: data /
100.0 };
}
Der optionale Konverter kann Werte im dekodierten JSON-Objekt konvertieren. Dies kann beispielsweise eine Umrechnung von einer Spannung in einen Istwert oder von einer Temperatur in Celsius in eine Temperatur in Fahrenheit sein. Mit dem optionalen Validator können Sie die Gültigkeit der Daten überprüfen und Ausreißer ausschließen. Zukünftig können diese Payload-Funktionen ihr Verhalten an das FPort-Feld der Nachricht anpassen, sodass die Community Standarddatencodierungsformate für jedes FPort definieren kann. Ein Beispiel könnte ein Standardformat zum Senden von Wetterstationsdaten sein. MQTT (Handler)
Die Standard-Handler-Implementierung veröffentlicht einfach eine JSON-Darstellung von Uplink-Nachrichten in einem Topic
<app_id>/devices/<dev_id>/up
auf einem MQTT-Broker. Auf diese Weise können Anwendungen einfach dasselbe MQTT-Thema abonnieren und die Daten auf beliebige Weise verarbeiten.
Nach dem Veröffentlichen der Uplink-Nachricht in MQTT bestimmt der Handler, ob eine Downlink-Nachricht an das Gerät gesendet werden muss. Es gibt drei Situationen, in denen eine Downlink-Nachricht gesendet werden muss. Die erste und offensichtlichste Möglichkeit besteht darin, dass der Anwendung eine Nutzlast zum Senden an das Gerät zur Verfügung steht. In diesem Fall wird die Nutzlast der vom Netzwerkserver generierten Antwortvorlage hinzugefügt. Der zweite Fall ist, wenn die Uplink-Nachricht eine Bestätigung erfordert. Unabhängig davon, ob eine Downlink-Nutzlast verfügbar ist oder nicht, muss eine Bestätigung gesendet werden. Die dritte Situation ist, wenn der Netzwerkserver MAC-Befehle an das Gerät senden muss. Wenn dies erkannt wird, kann der Handler entscheiden, ob er dem Netzwerkserver gehorcht oder nicht, obwohl die aktuelle Implementierung immer der Anforderung des Netzwerkservers folgt.
Ähnlich wie bei Uplink-Nachrichten ist der Handler für die Verschlüsselung der Nutzdaten der Nachricht verantwortlich.
Wenn keine Downlink-Nutzdaten verfügbar sind, kann der Handler eine kurze Wartezeit festlegen, damit die Anwendung eine Downlink-Nachricht basierend auf der gerade empfangenen Uplink-Nachricht erstellt. Nach Ablauf dieser Frist muss der Handler die Downlink-Nachricht an den Broker zurücksenden.
Nachdem der Broker eine Downlink-Nachricht von einem Handler erhalten hat, sendet er die Nachricht an den Netzwerkserver, der den Status des Geräts (insbesondere die Frame-Zähler) in der Datenbank aktualisiert und die MIC der Nachricht generiert. Danach leitet der Broker die Downlink-Nachricht an den Router weiter, der für das Gateway verantwortlich ist, das die Downlink-Nachricht senden muss.
Wie zu Beginn dieses Kapitels erwähnt, ist der Router für die Verwaltung des Zeitplans des Gateways verantwortlich. Da die meisten Gateways nur einen Puffer mit 1 Downlink-Nachricht haben, muss der Router geplante Nachrichten bis zum letzten Moment puffern und dann jede Nachricht just in time an das Gateway senden.