Vergleich von Konnektivitäts-Protokollen Der IP-Stack – Herausforderung für IoT-Anwendungen

Die Ausdehnung des Internet der Dinge (IoT) auf kleine Geräte wird bis 2020 voraussichtlich zur Vernetzung einer im zweistelligen Milliardenbereich liegenden Zahl von Geräten führen. Jedes einzelne dieser »Dinge« fungiert dabei als Erzeuger oder Konsument großer Datenmengen.

Neben Smart-Metern wird es Thermostate, Überwachungskameras, Verkehrsampeln und all die anderen Dinge geben, die Daten erfassen und zur weiteren Auswertung und Verarbeitung in die Cloud schicken, um den Anforderungen der Konsumenten besser gerecht zu werden.

So reizvoll diese Chancen auch sein mögen, steht doch außer Zweifel, dass das Internet mit seinen nur 32 Bit für Geräteadressen nicht für derart viele Knoten gemacht ist. Glücklicherweise erkannte die Internet Engineering Task Force (IETF) den Bedarf an zusätzlichen IP-Adressen schon 1994 und leitete die Entwicklung einer Reihe von Protokollen und Standards ein, die man inzwischen als Internet-Protokoll Version 6 (IPv6) kennt. IPv6 nutzt im Gegensatz zum 32-Bit-System von IPv4 eine Adressbreite von 128 Bit und unterstützt damit rund 3,4∙1038 mögliche Adressen. Die Erweiterung des IoT und die neuen kleinen Geräte, die diese Ausdehnung vorantreiben, verlangen jedoch nach mehr als nur nach Adressierbarkeit. Viele der besagten Geräte besitzen wenig Speicher und kostengünstige CPUs, sind batteriebetrieben und setzen dennoch Echtzeitfähigkeit voraus. Heutzutage verfügen wir über die nötige Hardwaretechnologie zur Herstellung solcher Geräte und über platzsparende Echtzeit-Betriebssysteme (RTOS) zum Management ihrer internen Systemfunktionen. Die üblichen TCP/IP-Netzwerkprotokolle aber haben es schwer, diese Geräte zu unterstützen.

Um diese Einschränkungen zu beseitigen, wurde eine Reihe neuer Konnektivitäts-Protokolle entwickelt. Diese sind eigens für den Einsatz in diesen durch knappe Ressourcen, einfache Mikrocontroller und Batteriebetrieb gekennzeichneten IoT-Geräten konzipiert. Ziel ist es, diesen ›Dingen‹ die Kommunikation untereinander, mit dem Internet und mit der Cloud zu ermöglichen. In einigen Fällen stehen für ähnliche Funktionalitäten mehrere Protokolle zur Auswahl, und es hängt von der einzelnen Applikation ab, welches das beste ist. Positiv zu vermelden ist, dass es von verschiedenen Software- und Systemanbietern mehrere Protokolle gibt. Die schlechte Nachricht ist dagegen, dass nicht alle dieser Implementierungen industrietauglich sind. ›Industrietauglich‹ heißt im Klartext: geeignet für die massenweise Distribution auf dem Markt, entwickelt für zuverlässige Langzeit-IoT-Performanz und implementiert in einem Format, das anspruchsvollen Designanforderungen entspricht. Hierin liegt die Herausforderung im Zusammenhang mit den IP-Stacks, die IoT-Entwickler verstehen und berücksichtigen müssen, um für jedes Produktdesign die richtige Protokollentscheidung zu treffen.

Verschiedene Konnektivitäts-Protokolle im Vergleich

MQTT, CoAP, LWM2M und 6LoWPAN sind die populärsten neuen Konnektivitäts-Protokolle für kleine Geräte. Diese Protokolle werden im Folgenden vorgestellt, um anschließend ihre Unterschiede und relativen Vorzüge zu beleuchten. MQTT (MQ Telemetry Transport) ist ein nach dem Publish/Subscribe-Prinzip funktionierendes Messaging-Protokoll für schlanke M2M-Verbindungen (Machine-to-Machine), bei denen ein kleiner Code-Footprint verlangt wird oder die Netzwerkbandbreite begrenzt ist. Ursprünglich von IBM entwickelt, ist es inzwischen ein offener Standard.

MQTT nutzt ein Client/Server-Modell. Darin fungiert jeder Sensor-Endknoten als Client und ist per TCP über routing-fähige Knoten und/oder ein Gateway mit einem als Broker bezeichneten Server verbunden (Bild 1). Bei dem Broker kann es sich beispielsweise um einen von einem Fahrzeughersteller oder einem allgemeinen Anbieter wie Amazon zur Verfügung gestellten Cloud-Service handeln. Dank des Publish/Subscribe-Modells können MQTT-Clouds nach dem One-to-One-, One-to-Many- und Many-to-One-Prinzip kommunizieren. MQTT ist zwar schlank konzipiert, bringt aber für Geräte mit sehr knappen Ressourcen zwei Nachteile mit sich:

Jeder MQTT-Client muss TCP unterstützen und in der Regel ständig eine Verbindung zum Broker offenhalten. In einigen Umgebungen, in denen die Paketverlustrate hoch ist oder die Rechenressourcen knapp bemessen sind, ist dies ein Problem.

Bei den MQTT-Topic-Namen handelt es sich oft um lange Strings, die damit unpraktikabel für 802.15.4 sind (stromsparende Funkübertragung mit geringer Datenrate). 

Beiden Mängeln wird mit dem Protokoll MQTT-SN Rechnung getragen, das ein UDP-Mapping von MQTT definiert und die Broker-Unterstützung für die Indizierung von Topic-Namen einführt.

CoAP: Constrained Application Protocol

CoAP befähigt ressourcenbeschränkte Geräte zur Kommunikation mit dem Internet unter Verwendung ähnlicher Protokolle (Bild 2). CoAP ist für die Verwendung zwischen Geräten im selben ressourcenbeschränkten Netzwerk, zwischen Geräten und allgemeinen Knoten im Internet sowie zwischen Geräten in verschiedenen ressourcenbeschränkten, per Internet verbundenen Netzwerken vorgesehen. CoAP ist einerseits für die einfache Übersetzung in HTTP ausgelegt, um die Integration in das Internet zu erleichtern, erfüllt aber andererseits spezielle Forderungen beispielsweise nach Multicast-Unterstützung, wenig Overhead und Einfachheit. Im Unterschied zu MQTT, das TCP voraussetzt, nutzt CoAP das kleinere und einfachere UDP, was für ressourcenbeschränkte IoT-Geräte extrem wichtig ist. Tabelle 1 zeigt einen Vergleich beider Protokolle.

Vergleich MQTT/CoAP
MQTT


Erfordert TCP, das umfangreicher ist als UDP, sodass MQTT nicht so schlank ist wie CoAP.

CoAP

 Arbeitet mit UDP und ist damit auch in extrem ressourcenbeschränkten Umgebungen lauffähig.

Dank Publish/Subscribe-Semantik (im selben Socket) ist es auf Seiten des IoT-Geräts einfacher zu programmieren.

IoT-Cloud-Service-Providers wie AWS IoT und Everything und andere bieten MQTT-basierte Geräte-Konnektivität an.

Guter Mechanismus für die Kommunikation in lokalen Netzwerken, speziell wenn ein Ökosystem aus weiteren CoAP-Geräten vorhanden ist.


Erfordert für seine Funktion einen Message Broker (Server). Hierdurch ist es eine gute Option für die Remote/Cloud-Kommunikation, denn der Cloud-Server fungiert als Message Broker zwischen dem IoT-Gerät und weiteren Apps/Services.

Gleichzeitig ist es hierdurch keine gute Wahl für die lokale Netzwerk-Kommunikation zwischen Geräten, denn es verlangt vom Endanwender die Einrichtung eines zusätzlichen Brokers im System.

 

 

Tabelle 1: Vergleich der Protokolle MQTT/CoAP.

LWM2M: Lightweight M2M 

LWM2M ist ein offenes Industrieprotokoll der Open Mobile Alliance (OMA) und wurde als schlanke, kostengünstige Möglichkeit für das Fernservice-Enablement und -Applikationsmanagement für eingebettete IoT-Geräte und vernetzte Geräte über drahtlose Verbindungen konzipiert (Bild 3). Es ist ein Kommunikationsprotokoll für den Einsatz zwischen Client-Software auf einem M2M-Geräte und Server-Software auf einer M2M-Management- und -Serverplattform. LWM2M wurde entwickelt, um Problemen infolge technischer Fragmentierung aus dem Weg zu gehen, einen geeigneten Mechanismus zur Erfüllung der Anforderungen ressourcenbeschränkter M2M-Geräte zu finden und Vorteile aus der Entkopplung von Systemkomponenten mithilfe standardisierter Schnittstellen zu ziehen.

Hier die vier Hauptmerkmale des LWM2M-Protokolls: 

  • Das Design seiner Architektur basiert auf einer Schnittstelle für das Representational-State-Transfer-Applikationsprotokoll.
  • Es definiert ein Ressourcen- und Datenmodell.
  • Es wurde mit Blick auf Performance und die Restriktionen von M2M-Geräten entwickelt.
  • Es nutzt den Constrained-Application Protocol-Secure-Data-Transfer-Standard, der vom IETF als Abwandlung des im Internet genutzten HTTP-Protokolls standardisiert wurde (geeignet für den Datentransfer von und nach kostengünstigen, vernetzten IoT-Geräten). 

 

6LoWPAN

    6LoWPAN ist ein Akronym für ›IPv6 over Low Power Wireless Personal Area Network‹. Ursprung des 6LoWPAN-Konzepts war die Idee, das Internet-Protokoll selbst für kleinste Geräte zu nutzen und auch stromsparenden Geräten mit knappen Rechen-Ressourcen die Nutzung des IoT zu erlauben.

    6LoWPAN ist ein Maschennetzwerk-Protokoll (Bild 4), das das Versenden von IPv6-Datagrammen mit stromsparenden Kurzstrecken-Funkverbindungen wie etwa IEEE 802.15.4 erlauben sollte. Eine Low-Power-Funkverbindung hat typisch eine Reichweite von rund 10 Metern, bei einer geringen Bandbreite von einigen Kilobit pro Sekunde und kleiner Paketgröße (128 Bit). 6LoWPAN überbrückt IPv6 und das stromsparende Funknetzwerk. 6LoWPAN bietet folgende Merkmale:

    • offene Standards wie TCP, UDP, HTTP, COAP, MQTT und Websockets,
    • von Ende-zu-Ende per IPv6 adressierbare Knoten,
    • kein Gateway oder Proxy erforderlich (ein 6LoWPAN-Border-Router verbindet das 6LoWPAN-Netzwerk mit dem Internet),
    • One-to-Many- und Many-to-One-Routing,
    • Robustheit und Skalierbarkeit und
    • Einsatzfähigkeit auf mehreren Kommunikationsplattformen (z. B. Ethernet und Wi-Fi, 802.15.4, Sub-Gigahertz ISM) Interoperabilität auf der IP-Ebene