Blog
Während im ersten Teil unserer Artikelserie die Technologie NB-IoT im Vordergrund stand, soll es in diesem zweiten Teil um die technischen Aspekte der Nutzung gehen. Denn die Vorteile der Datenübertragung via Narrowband-IoT sind nur allzu schnell verspielt, wenn diese falsch eingesetzt wird.
„Klassische“ im IoT-Kontext eingesetzte Protokolle wie MQTT oder AMQP basieren auf dem Netzwerkprotokoll TCP (Transmission Control Protocol). Als Besonderheit von TCP ist, im Gegensatz zum verbindungslosen Pendant UDP (User Datagram Protocol), zu nennen, dass dieses Protokoll – neben der fehlenden Unterstützung für Broad- und Multicast-Messages – eine Quittierung der einzelnen TCP-Pakete vorsieht.
Die einzelnen vom Sender übertragenen Pakete werden vom Empfänger bestätigt, was zur Übertragung zusätzlicher Nachrichten führt. Erhält der Sender keine entsprechende Empfangsbestätigung für ein Paket, wird dieses erneut übermittelt. Das Grundprinzip von UDP lässt sich dagegen mit „fire and forget“ beschreiben: Daten werden an den Empfänger übermittelt, die erfolgreiche Zustellung ist für den Sender allerdings irrelevant.
Doch nicht nur beim Senden von Daten, sondern bereits beim Verbindungsaufbau entsteht bei TCP ein Overhead im Vergleich zu UDP. Dieser kommt durch den sogenannten TCP-Handshake zustande.
TCP-basierte Verbindungen führen also bereits auf der Ebene des Übertragungsprotokolls zu einem unerwünschten Overhead. Negativ verstärkt wird dieser Effekt noch durch die bei Narrowband-IoT zu erwartenden höheren Latenzen. Diese können dazu führen, dass Handshakes oder die Übertragung von Paketen in Timeouts laufen. Durch unwirtliche Umgebungen, wie beispielsweise Keller oder Tiefgaragen, wird dieser Effekt zusätzlich verstärkt.
Die aufgrund dieser Faktoren notwendigen, zusätzlichen Übertragungsversuche führen bei batteriebetriebenen Geräten zu einem erhöhten Energieverbrauch.
Zwar versprechen einige Hersteller eine Batterielebenszeit von bis zu zehn Jahren für Narrowband-IoT-Geräte. Durch unsachgemäßen Einsatz wird diese allerdings auf wenige Tage reduziert.
Die daraus resultierenden häufigeren Wartungsarbeiten, für die gegebenenfalls Techniker ins Feld geschickt werden müssen, führen schließlich zu einer weiteren Erhöhung der Betriebskosten.
Aus diesem Grund sollte die Kommunikation mit der Cloud nicht über TCP, sondern UDP erfolgen. UDP ist allerdings ein verbindungsloses Protokoll und verfügt über keine protokollseitige Garantie der Zustellung. Ein Sender erhält vom Empfänger also kein ACK-Paket, das den Empfang bestätigt (Acknowlegement). Abhilfe schaffen hier spezielle, auf UDP basierende, Kommunikationsprotokolle wie MQTT-SN oder CoAP. Da wir als com2m mit MQTT-SN in diesem Bereich bereits sehr gute Erfahrungen gemacht haben, soll dieses Protokoll im Folgenden genauer vorgestellt werden.
Bei MQTT-SN (MQTT for Sensor Networks) handelt es sich um eine Abwandlung des verbreiteten MQTT-Protokolls, bei dem üblicherweise auf ein MQTT-SN-Gateway gesetzt wird. Dieses Gateway fungiert als Proxy zwischen einem MQTT-SN-Client sowie dem jeweiligen MQTT-Broker, und “übersetzt” MQTT-SN in MQTT (und umgekehrt). Gateways stehen dabei in aggregierender oder transparenter Form zur Verfügung. Im Fall aggregierender Gateways wird für sämtliche verbundene MQTT-SN-Clients eine MQTT-Verbindung zum Broker unterhalten. Transparente Gateways hingegen pflegen je Client eine eigenständige Verbindung in Richtung des Brokers und sind somit für diesen nicht von „normalen“ Clients zu unterscheiden.
Das Protokoll MQTT-SN bietet, wie auch MQTT, verschiedene Mechanismen, um den Erhalt bzw. die Zustellung von Nachrichten zu quittieren. Relevant sind hier vor allem die Quality-of-Service-Level (kurz: QoS) 1 und 2. Mit ihnen kann die Zustellung mittels Quittierung durch den Empfänger sichergestellt werden.
Das Protokoll MQTT bietet die Möglichkeit, Nachrichten auf Topics zu veröffentlichen (Publish), die von anderen Clients abonniert (Subscribe) werden können. Für NB-IoT-Use-Cases ist das zunächst allerdings keine gute Option, da die häufige Übertragung langer Topics in den jeweiligen Nachrichten zu einem erhöhten Verbrauch sowohl von Energie als auch von Datenvolumen führt. MQTT-SN bietet hier als zusätzliche Möglichkeit sogenannte REGISTER-Messages. Diese können genutzt werden, um für ein konkretes Topic vom Gateway ein Short Topic zu beantragen. Dieses kann im weiteren Verlauf der Kommunikation von Client und Gateway genutzt werden, um die zu übertragenden Nachrichten möglichst kurz zu halten.
Wie auch bei MQTT besteht bei MQTT-SN keine Einschränkung hinsichtlich der eigentlichen „Payload“ der PUBLISH-Messages. Als Payload versteht man die Nutzlast einer Nachricht, also den eigentlichen Inhalt ohne protokollspezifische Meta-Informationen wie das Topic, auf dem eine Nachricht veröffentlicht werden soll, oder den Nachrichtentyp. Während die Übertragung von JSON-Objekten möglich ist, kann es gerade in diesem konkreten Fall sinnvoll sein, die zu übermittelnden Daten in einem Byte-Format zu kodieren, um die Message und den durch Konstanten aufkommenden Overhead zu reduzieren.
Im Folgenden ein Beispiel zur Visualisierung dieses Effekts:
Länge | Msg-Type | Flags | Topic-ID | Msg-ID | Payload |
23 | 0c | 22 | 00 03 | 00 2a | 7b 22 74 65 6d 70 65 72 61 74 75 72 65 22 3a 32 33 2c 22 68 75 6d 69 64 69 74 79 22 3a 35 35 7d |
09 | 0c | 22 | 00 03 | 00 2a | 17 37 |
Die obige Tabelle zeigt eine PUBLISH-Nachricht auf eine registrierte Topic-ID. Die erste Zeile enthält die folgende JSON-Payload:
{„temperature“:23,“humidity“:55}
Die zweite Zeile enthält die gleichen Messwerte, also die Zahlen 23 sowie 55. Cloudseitig muss ein entsprechender Protocol-Handler eingesetzt werden, der daraus die jeweiligen Messwerte parst, um diese als Temperatur- beziehungsweise Luftfeuchtigkeitswert zu speichern.
Es handelt sich hierbei um eine Reduktion der Nachrichtengröße um 74 %. So kann sowohl die Batterielebensdauer verlängert als auch das benötigte Datenvolumen drastisch reduziert werden.
Ein weiterer, wesentlicher Vorteil von MQTT-SN ist, dass Clients die Möglichkeit haben, sich temporär vom Gateway abzumelden und in den Sleep-State überzugehen. Der Client kündigt mit einer DISCONNECT-Message und einem frei wählbaren zeitlichen Intervall, das in dieser enthalten ist, an, sich bis zu einem gewissen Zeitpunkt zurückzumelden. Sofern dies nicht eintritt, wird die Session des Clients invalidiert, da die Verbindung verloren wurde.
Sollten sich in der Zwischenzeit Nachrichten aus der Cloud, die für den Client bestimmt sind, am Gateway angestaut haben, werden diese, sobald sich der Client zurückmeldet, zugestellt.
Um die Verfügbarkeit aktiver Clients zu überprüfen, werden im Active-State periodisch Pings, genauer PINGREQ- (Ping Request) und PINGRESP-Messages (Ping Response), zwischen Client und Gateway hin- und hergesendet. Das Ausbleiben dieser Nachrichten führt zu einem Abriss der Verbindung. Durch die Nutzung des Sleep-States kann sowohl die Verbindung zum Gateway aufrechterhalten als auch die Zahl der zu übertragenden Nachrichten reduziert werden, was wiederum der Batterielebensdauer zuträglich ist.
Eine durchgehend bestehende, aktive Verbindung, die mit dem häufigen Austausch von PINGREQ- sowie PINGRESP-Messages einhergeht, ist somit nicht notwendig.
Eine weitere Herausforderung beim Einsatz von Narrowband-IoT, vor allem im Hinblick auf batteriebetriebene Geräte, ist die Implementierung von Sicherheitsmechanismen. Dies gilt sowohl für die Authentifizierung der Geräte als auch die Ende-zu-Ende-Verschlüsselung des Datenverkehrs, die es ausschließlich Sender und Empfänger ermöglicht, die übermittelten Daten zu interpretieren.
Diesen Aspekt von NB-IoT werden wir im dritten und letzten Teil unserer Artikelserie im Detail beleuchten.
Dieser letzte Teil unserer Blogreihe zum Thema Narrowband-IoT beschäftigt sich mit dem für das Internet of Things so wichtige Thema Sicherheit.
Der Mobilfunkstandard Narrowband-IoT, kurz NB-IoT, ist 2021 in Deutschland flächendeckend verfügbar und trägt das Suffix „IoT“ vollkommen zurecht in seinem Namen: Mit Hilfe dieser Technologie lassen sich im Feld befindliche Geräte kostengünstig und selbst aus unwirtlichen, schlecht zugänglichen Umgebungen heraus mit der Cloud verbinden.
+49 (0) 231 7000 7020
info@com2m.de
Adessoplatz 1
44269 Dortmund
© com2m 2022. Alle Rechte vorbehalten.
