Ein Protokoll-Stack für Narrowband-IoT (Teil 2)

Während im ersten Teil meiner Blog-Serie die Technologie des NB-IoT im Vordergrund stand, geht es im zweiten Teil um die technischen Aspekte der Nutzung. Denn die Vorteile der Datenübertragung via Narrowband-IoT sind bei falscher Anwendung schnell verspielt.

TCP oder UDP: die Wahl des Kommunikationsprotokolls

Klassische Kommunikationsprotokolle im IoT-Kontext wie MQTT oder AMQP basieren auf dem Netzwerkprotokoll Transmission Control Protocol (TCP). Eine Besonderheit von TCP ist, dass es im Gegensatz zu seinem verbindungslosen Pendant, dem User Datagram Protocol (UDP), neben der fehlenden Unterstützung von 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 weiterer Nachrichten führt. Erhält der Sender für ein Paket keine entsprechende Bestätigung, wird es erneut gesendet. 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 jedoch irrelevant.

Im Gegensatz zu UDP entsteht bei TCP-basierten Verbindungen bereits auf der Ebene des Übertragungsprotokolls durch den TCP-Handshake ein unerwünschter Overhead. Dieser Effekt wird durch die im Narrowband-IoT zu erwartenden höheren Latenzen noch negativ verstärkt. Diese können dazu führen, dass Handshakes oder Paketübertragungen in Timeouts laufen. Ungünstige Betriebsumgebungen wie Keller oder Tiefgaragen verstärken diesen Effekt zusätzlich.

Die daraus resultierenden zusätzlichen Übertragungsversuche führen bei batteriebetriebenen Geräten zu einem erhöhten Energieverbrauch. Zwar versprechen einige Hersteller für Narrowband-IoT-Geräte eine Batterielebensdauer von bis zu zehn Jahren, doch reduziert sich diese bei unsachgemäßer Nutzung auf wenige Tage. Die daraus resultierenden häufigeren Wartungsarbeiten, für die gegebenenfalls Technikerinnen und Techniker ins Feld geschickt werden müssen, führen letztlich zu einem weiteren Anstieg der Betriebskosten.

Aus diesem Grund sollte die Kommunikation mit der Cloud nicht über TCP, sondern über UDP erfolgen. UDP ist jedoch ein verbindungsloses Protokoll und verfügt über keine protokollseitige Zustellgarantie. Ein Sender erhält also vom Empfänger kein ACK-Paket, das den Empfang bestätigt (Acknowledgement). Abhilfe schaffen hier spezielle, auf UDP basierende Kommunikationsprotokolle wie MQTT for Sensor Networks (MQTT-SN) oder auch CoAP. Da wir in diesem Bereich bereits sehr gute Erfahrungen mit MQTT-SN gemacht haben, soll dieses Protokoll im Folgenden näher vorgestellt werden.

Dank MQTT-SN den Empfang von Nachrichten bestätigen

Bei MQTT-SN 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. Es ü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 MQTT-SN-Protokoll verfügt, wie auch MQTT, über verschiedene Mechanismen, um den Erhalt beziehungsweise die Zustellung von Nachrichten zu quittieren. Relevant sind hier vor allem die Quality-of-Service-Level (QoS) 1 und 2. Mit ihnen kann die Zustellung mittels Quittierung durch den Empfänger sichergestellt werden.

Das MQTT-Protokoll 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. Es 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:

Die oben dargestellte 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 Luftfeuchtigkeitswerte zu speichern.

Es handelt sich hierbei um eine Reduktion der Nachrichtengröße um 74 Prozent. So kann sowohl die Batterielebensdauer verlängert als auch das benötigte Datenvolumen drastisch reduziert werden.

Ein weiterer wesentlicher Vorteil von MQTT-SN ist die Möglichkeit für Clients, sich temporär vom Gateway abzumelden und in den Sleep State zu gehen. Der Client kündigt mit einer DISCONNECT-Nachricht und einem darin enthaltenen frei wählbaren Zeitintervall an, sich bis zu einem bestimmten Zeitpunkt wieder anzumelden. Geschieht dies nicht, wird die Session des Clients invalidiert, da die Verbindung verloren gegangen ist.

Sollten sich in der Zwischenzeit Nachrichten aus der Cloud, die für den Client bestimmt sind, am Gateway angesammelt haben, werden diese zugestellt, sobald der Client zurückmeldet.

Um die Verfügbarkeit aktiver Clients zu überprüfen, werden im Active State periodisch Pings – genauer gesagt PINGREQ- (Ping Request) und PINGRESP-Messages (Ping Response) – zwischen Client und Gateway hin- und hergeschickt. Das Ausbleiben dieser Nachrichten führt zu einem Abriss der Verbindung. Durch die Nutzung des Sleep State 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, insbesondere bei batteriebetriebenen Geräten, ist die Implementierung von Sicherheitsmechanismen. Dies gilt sowohl für die Authentifizierung der Geräte als auch für die Ende-zu-Ende-Verschlüsselung des Datenverkehrs, die es nur Sendern und Empfängern erlaubt, die übertragenen Daten zu interpretieren.

Diesen Aspekt von NB-IoT werde ich im dritten und letzten Teil meiner Artikelserie näher beleuchten.

Ihr wollt eure Produktion datenbasiert optimieren, aber die Daten nicht aus unterschiedlichen Softwaresystemen und Datenbanken zusammensuchen müssen? Ihr möchtet nicht für jede Datenabfrage eine Fachkraft fragen müssen? Dann werft einen Blick auf unsere Website und erfahrt, wie Industrial-Internet-of-Things-Plattformen – kurz IIoT-Plattformen – dabei unterstützen können.