MQTT: Protokoll für das Internet der Dinge

Inhaltsverzeichnis

Die Eignung für eine zuverlässige und effiziente Kommunikation auch über instabile Mobilfunk-Netze und die Vernetzung vieler Tausender Geräte ist in vielen Situation gefragt. Deshalb zählt MQTT (Message Queue Telemetry Transport) inzwischen zu einem der wichtigsten Protokolle im Internet der Dinge.

Da MQTT meistens in den Bereichen "Maschine zu Maschine" und "Internet der Dinge" zum Einsatz kommt, ist es etwas überraschend, dass die Geschichte des Protokolls bereits 1999 beginnt. Die Firmen IBM und Arcom Control Systems entwickelten das Protokoll im Zuge eines gemeinsamen Projekts zur Überwachung einer Ölpipeline. Da die mobile Infrastruktur damals noch in keinem Verhältnis zum aktuellen Ausbau stand, gab es
nicht unerhebliche Herausforderungen. Eine davon war die Datenübertragung über Satellit und terrestrische Netze mit möglichst geringen Kosten. Ebenso sollte eine generische Lösung gefunden werden, die über eine direkte Punkt-zu-Punkt-Verbindung hinaus geht und die Sensoren als Datenproduzenten von den Datennutzern entkoppelt.

Ziele und Weg zur Standardisierung

Um die Herausforderungen zu bewältigen, wurden folgende Eigenschaften für das Protokoll erarbeitet:

• Die Implementierung muss einfach sein, um auch Geräte mit eingeschränkten Ressourcen damit zu vernetzen.
• Es muss unterschiedliche Servicequalitäten bei der Datenübertragung geben, damit die Übertragung auch in instabilen Netzen gewährleistet wird.
• Die Übertragung muss einfach und effizient die zur Verfügung stehende Bandbreite nutzen.
• Da bei Wiederaufnahme abgebrochener Verbindungen oft Metainformationen erneut gesendet werden, wäre es von Vorteil, diese serverseitig zu speichern (Session-awareness).
• Das Protokoll sollte unterschiedliche Datentypen übertragen können und nicht auf eine bestimmte Struktur festgelegt sein (datenagnostisch).

Andy Standford-Clark und Arlen Nipper haben zum Erreichen dieser Ziele das Protokoll Message Queuing Telemetry Transport (MQTT) entwickelt, das bei IBM in der Folge in verschiedenen Projekten zum Einsatz kommt. 2010 wurde es dann offiziell unter einer freien Lizenz veröffentlicht, was auch Open-Source-Implementierungen ermöglichte. Im folgenden Jahr brachten IBM und Eurotech (vormals Arcom) ihre MQTT-Bibliothek unter das Dach der Eclipse Foundation und gaben damit der breiten Verwendung des Protokolls einen weiteren Schub. Denn die einst identifizierten Ziele und ihre Umsetzung verlangen auch 2014 eine Technik für skalierbare Echtzeitkommunikation mit minimaler Breitband- und Ressourcennutzung. Unter Echtzeit ist eine Datenübertragung ohne Polling oder ähnliche Mechanismen zu verstehen. Es kann sehr wohl zu Verzögerungen aufgrund unzuverlässiger Netzwerke kommen.

Zentraler Ansprechpartner erwünscht

MQTT implementiert das Publish/Subscribe-Pattern. Der Paradigmenwechsel von einer Request/Response- zu einer ereignisgesteuerten Publish/Subscribe-Architektur ist hierbei der zentrale Aspekt. Sie ersetzt die Punkt-zu-Punkt-Verbindungen durch einen zentralen Server (Broker), zu dem sich Datenproduzenten und -nutzer gleichermaßen verbinden können. Das Senden (publish) und Empfangen (subscribe) von Nachrichten funktioniert über sogenannte Topics. Ein Topic ist ein String, der eine Art Betreff der Nachricht darstellt, aber ähnlich einer URL aufgebaut ist. Ein Temperatursensor in einem Wohnzimmer könnte beispielsweise seine aktuelle Temperatur auf folgendem Topic veröffentlichen: Zuhause/Wohnzimmer/Temperatur.

Eine mobile App kann sich nun ebenfalls zum Broker verbinden und den gleichen Topic abonnieren (subscribe), um alle Nachrichten zu erhalten, die der Temperatursensor versendet. Die komplette Kommunikation funktioniert rein über Topics, und der Sensor und das Mobiltelefon wissen nichts über die Existenz des jeweils anderen. Der Ablauf ist in Abbildung 1 dargestellt. Topics haben noch ein weiteres wichtiges Konzept, wodurch sie flexibel sind – nämlich Wildcards.

Zuhause/Wohnzimmer/Temperatur
Zuhause/Wohnzimmer/Luftfeuchtigkeit
Zuhause/Schlafzimmer/Temperatur
Zuhause/Schlafzimmer/Luftfeuchtigkeit

In oben stehenden Codebeispiel sind vier Topics aufgelistet, und je ein Sensor sendet eine neue Nachricht auf den jeweiligen Topic, sobald sich ein Wert geändert hat. Man kann nun je nach Anwendungsfall Wildcards benutzen, um mehrere Topics zu abonnieren.

Zuhause/+/Temperatur
Zuhause/Wohnzimmer/#
#

Hier sind alle möglichen Wildcard-Operatoren aufgelistet. Im ersten Fall bekommt die mobile Anwendung nur alle Nachrichten über neue Temperaturwerte, im zweiten Fall nur alle Werte aus dem Wohnzimmer und im dritten Fall alle Werte. Dabei lässt sich der +-Operator immer nur für eine Hierarchiestufe einsetzen und der
#-Operator für beliebig viele Hierarchiestufen mit der Bedingung, dass dieser am Ende stehen muss. Möchte man also Zuhause und Zimmer nicht genau benennen, sind zwei +-Operatoren zu benutzen: +/+/Temperatur. Falsch wäre #/Temperatur.

Mechanismen zur Qualitätskontrolle

Ein weiteres wichtiges Konzept sind die drei Servicequalitäten bei der Datenübertragung 0, 1 und 2. Dazu muss man wissen, dass MQTT auf TCP basiert, weshalb eine große Zuverlässigkeit beider Übertragung gegeben ist. Trotzdem ist das bei Netzen mit vielen Übertragungsfehlern durch Verbindungsprobleme, wie bei mobilen Netzen, keine ausreichende Lösung. Daher hat das Protokoll Mechanismen eingebaut, die das erfolgreiche Übertragen von Nachrichten garantieren.

Die Zusicherung variiert von keiner Garantie (Level 0) über die, dass die Nachricht mindestens einmal ankommt (Level 1), bis hin zur Garantie, dass die Nachricht genau einmal ankommt (Level 2). Der Unterschied zwischen Level 1 und 2 liegt darin, dass es bei Level 1 passieren kann, dass eine Nachricht öfter einen Client erreicht. Je nach Anwendungsfall sollte der passende Level gewählt werden, denn je höher der Level, desto höher ist die benötigte Bandbreite.

Letzter Wille und gespeicherte Nachrichten

Mit den Möglichkeiten, die Publish/Subscribe und die Verwendung von QoS-Level (Quality of Service) kann man viele Probleme lösen. Da verschiedene Clients immer wieder mal die Verbindung verlieren, kann es passieren, dass eine mobile Applikation, die sich neu verbunden hat, nicht weiß, ob überhaupt ein Temperatursensor verbunden ist und was der aktuelle Wert des Sensors ist. Außerdem erfährt man nicht, ob ein Sensor ausgefallen ist. Für diese Probleme gibt es in MQTT die Konzepte "Last Will and Testament" und "Retained Messages". Jeder Client kann beim Verbinden eine Nachricht mit seinem letzten Willen an den Broker schicken, bestehend aus Topic und Nachricht. Sobald der Broker das Unterbrechen der Verbindung merkt, sendet dieser die Nachricht im Auftrag des Clients.

Das Ganze funktioniert nur, wenn die Anwendung zum Zeitpunkt verbunden ist, an dem die Verbindung des Sensors abbricht. Abhilfe schafft hier eine "Retained Message". Sie ist eine Nachricht, die vom Broker gespeichert und jedem Client, der sich neu verbindet und den jeweiligen Topic abonniert, zugestellt wird. Es lässt sich für jeden Topic nur eine Nachricht speichern. Dies kann benutzt werden, um beispielsweise den letzten Wert des Sensors auf dem Topic Zuhause/Wohnzimmer/Temperatur oder den Status des Sensors auf Zuhause/Wohnzimmer/Temperatur/Status zu speichern. Dadurch können auch neu verbundene Geräte den letzten Wert empfangen, auch wenn sie zum Zeitpunkt des Sendens nicht verbunden waren.