Expertenbeitrag

 David Hoffmann

David Hoffmann

Business Development IoT, adesso SE

Internet of Things Mobilfunkstandard NB-IoT: Warum die Wahl des richtigen Protokollstacks so wichtig ist

Von David Hoffmann

Anbieter zum Thema

Wo konventioneller Mobilfunk im IoT an seine Grenzen stößt, kommt das sogenannte Schmalbandnetz ins Spiel. Die Funktechnologie Narrowband-IoT ist ein global akzeptierter Standard und ermöglicht die effiziente und stabile Vernetzung tausender Sensoren und Geräte.

Der Einsatz von NB-IoT-Lösungen lohnt sich – wenn man den richtigen Protokollstack nutzt.
Der Einsatz von NB-IoT-Lösungen lohnt sich – wenn man den richtigen Protokollstack nutzt.
(Bild: gemeinfrei / Pixabay)

Der Mobilfunkstandard Narrowband-IoT, kurz NB-IoT, ist in Deutschland schon seit einiger Zeit flächendeckend verfügbar. Das Suffix „IoT“ trägt er dabei vollkommen zurecht: Mit Hilfe dieser Technologie lassen sich beispielsweise Geräte wie Gas-, Wasser- und Stromzähler oder auch Parksensoren kostengünstig und selbst aus unwirtlichen, schlecht zugänglichen Umgebungen heraus mit der Cloud verbinden – zumindest sofern initiale Hürden überwunden wurden.

Use Cases für den Einsatz von NB-IoT

Narrowband-IoT gehört zu den sogenannten LPWAN-Technologien – kurz für Low-Power Wide-Area Network – und findet in den letzten Jahren immer größere Verbreitung.

Klassische NB-IoT-Use-Cases liegen in den Bereichen des Smart Meterings, der Gebäudeautomatisierung und des Objekt-Trackings, bei denen weder die Übertragung großer Datenmengen noch die schnelle Übertragung von Daten eine übergeordnete Rolle spielen. Wichtiger ist eine gute Gebäudedurchdringung, die herkömmliche Mobilfunktechnologien wie LTE aufgrund ihrer hohen Frequenz nicht mitbringen.

Weitere klassische Use Cases liegen außerdem in den Bereichen Smart City und Logistik – also in Anwendungsfällen, für die Geräte an schwer oder nicht öffentlich zugänglichen Orten ohne externe Stromversorgung installiert werden müssen. NB-IoT-Lösungen punkten in diesen Fällen neben der guten Gebäudedurchdringung mit einem niedrigen Energiebedarf. Der Aufwand durch regelmäßige Wartung oder den Batterietausch durch den Techniker vor Ort ist für einige wenige Geräte vielleicht noch vertretbar, handelt es sich um mehrere hundert oder tausend Geräte, skaliert dieser Ansatz nicht mehr.

Um Narrowband-IoT sinnvoll zum Einsatz bringen zu können – sei es in Hinblick auf das limitierte Datenkontingent der Mobilfunkverträge oder den sparsamen Umgang mit batteriebetriebenen Endgeräten – gilt es, verschiedene weitere Faktoren zu berücksichtigen. Denn die Vorteile der Datenübertragung via Narrowband-IoT, vor allen Dingen der niedrige Energiebedarf, sind nur allzu schnell verspielt, wenn die Technologie falsch eingesdaetzt wird.

TCP oder UDP: Die Wahl des Kommunikationsprotokolls

Um Daten via NB-IoT nicht nur an Ort und Stelle zu erheben, sondern diese auch entsprechend zu verarbeiten und an die Cloud zu senden, braucht es den Einsatz eines geeigneten Kommunikationsprotokolls. Klassische im IoT-Kontext eingesetzte Protokolle sind MQTT oder AMQP, die auf dem Netzwerkprotokoll TCP, was für Transmission Control Protocol steht, basieren. Im Gegensatz zum verbindungslosen Pendant UDP, also dem User Datagram Protocol, sieht dieses Protokoll eine Quittierung der einzelnen TCP-Pakete vor.

Die einzelnen vom Sender via TCP ü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 Nachrichtenaufkommen kann so gegebenenfalls sehr hoch sein.

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.

TCP-basierte Verbindungen führen also bereits auf der Ebene des Übertragungsprotokolls zu einem unerwünschten Overhead. Gemeint sind damit Informationen, die keine Nutzdaten, sondern Zusatzinformation sind, die, wie geschildert, bei Übermittlung oder Speicherung anfallen. Dieser Effekt verstärkt sich negativ 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 und für ein enormes Nachrichtenaufkommen sorgen. Unwirtliche Umgebungen, wie beispielsweise Keller oder Tiefgaragen, verstärken diesen Effekt zusätzlich.

Zwar versprechen einige Hersteller eine Batterielebenszeit von bis zu zehn Jahren für Narrowband-IoT-Geräte. Die aufgrund der genannten Faktoren notwendigen zusätzlichen Übertragungsversuche führen bei batteriebetriebenen Geräten jedoch zu einem erhöhten Energieverbrauch, sodass der Einsatz von TCP die Batterielaufzeit im schlimmsten Fall auf wenige Tage reduziert.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Für die Kommunikation mit der Cloud eignet sich daher der Einsatz von UDP besser. Da es sich bei UDP jedoch um ein verbindungsloses Protokoll handelt, verfügt es, wie oben beschrieben, über keine protokollseitige Garantie der Zustellung. Ein Sender erhält vom Empfänger keine Bestätigung über den Empfang. 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.

Mit MQTT-SN den Empfang von Nachrichten bestätigen

Das Protokoll MQTT-SN bietet, wie auch das weit verbreitete MQTT-Protokoll, verschiedene Mechanismen, um den Erhalt beziehungsweise die Zustellung von Nachrichten zu quittieren. Relevant sind hier vor allem die Quality-of-Service-Level 1 und 2. Mit ihnen kann man die Zustellung mittels Quittierung durch den Empfänger sicherstellen. Der Einsatz von MQTT-SN kann die Lücke, die UDP in der Kommunikation öffnet, entsprechend schließen.

Das Protokoll MQTT bietet die Möglichkeit, Nachrichten auf Topics zu veröffentlichen, die von anderen Clients abonniert 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 kann man nutzen, 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.

Hinsichtlich der eigentlichen Payload der PUBLISH-Messages besteht bei MQTT-SN keine Einschränkung. 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. 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 in dieser enthaltenen, frei wählbaren zeitlichen Intervall 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 am Gateway angestaut haben, werden diese zugestellt, sobald sich der Client zurückmeldet.

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 her gesendet. 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 dem Energiebedarf zuträglich ist.

Eine durchgehend bestehende, aktive Verbindung, die mit dem häufigen Austausch von PINGREQ- sowie PINGRESP-Messages einhergeht, ist somit nicht notwendig.

Vorteile sichern durch die Wahl des passenden Protokollstacks

Besonders in den Bereichen Smart City und Smart Metering hält der Einsatz von NB-IoT-Lösungen Vorteile bereit: eine gute Gebäudedurchdringung, trifft auf den geringen Verbrauch von Datenvolumen und Energie. Diese sind jedoch keine Selbstverständlichkeit. Die Wahl des richtigen Kommunikationsprotokolls – zum Beispiel in der Kombination aus UDP und MQTT-SN – ist eine essenzielle Voraussetzung für den erfolgreichen Einsatz von NB-IoT, um das benötigte Datenvolumen klein zu halten und die Batterielaufzeit auszureizen.

Eine weitere Herausforderung, 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 zweiten Teil dieser Artikelserie im Detail beleuchten.

(ID:48220790)