CoAP: Zusammenfassung der Spezifikation (high level)

Constrained Application Protocol (CoAP)
CoAP ist ein Internet Anwendungsprotokoll, welches innerhalb der RFC 7252 spezifiziert wurde. Das Protokoll dient der Kommunikation von Geräten ‚Nodes‘ z.B. embedded devices, die besonders wenig Energie verbrauchen (low-power) und in einem Netzwerk mit erhöhtem Datenverlußt (lossy networks) z.B. IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) zum Einsatz kommen.
CoAP kann zusätzlich innerhalb Internet basierten Netzwerken zur mobilen Kommunikation via SMS verwendet werden.
CoAP wird hauptsächlich im Rahmen von Internet of Things (IoT) und Machine-to-Machine (M2M) eingesetzt, da hier meistens Gerätedaten/Sensordaten mit geringer Größe übertragen werden. Dadurch, dass diese Art von Daten in regelmäßigen Abständen (Zyklen) übertragen werden, haben einzelne (verlorengegangene) Datenpakete keine Größe Auswirkung auf die verarbeitenden Systeme bzw. Anwendungen wie z.B. eine IoT-Plattform, der entsprechende Sensordaten (Temperatur, Umdrehungszahl etc.) verarbeitet und/oder grafisch darstellt.

Die Arbeitsgruppe ’strained RESTful Environments‘ kurz ‚CoRE‘ plant unter Anderem den Einsatz der REST Architektur innerhalb von Embedded devices (Nodes). Nodes verwenden hauptsächlich einen 8-bit microcontroller und stellen wenig RAM- und ROM-Speicher zur Verfügung.

Zielsetzung des Protokolls

  • Erstellung eines generischen Protokolls, sodass dieser im Rahmen von IoT Anwendungen z.B. Home automation oder im M2M-Anwendungen eingesetzt werden kann
  • Vereinfachung/Verkleinerung des Protokolls, was zu einer Reduzierung der Fragmentierung führen wird
  • built-in discovery
  • multicast support
  • asynchronous message exchanges

Protokoll Features

  • Erfüllung von M2M Anforderungen innerhalb eingeschränkter Netzwerke
  • [ENG] UDP binding with optional reliability supporting unicast and multicast requests
  • Asynchroner Austausch von Nachrichten
  • Einfacher Header und damit eine Reduzierung der Komplexität beim Parsing
  • Unterstützung von Uniform Resource Identifier (URI) & Content-types
  • Proxy und caching support
  • [ENG] A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP.
  • Datagram Transport Layer Security (DTLS) binding

Das Interaktionsmodell vom CoAP entspricht dem client/server Modell aus HTTP d.h. ein ‚client‘ sendet eine Anfrage (request) an einem Server und fragt nach einer URI. Der Server liefert daraufhin die angefragte Ressource.
Anders als bei HTTP erfolgt die Kommunikation über UDP.

CoAP unterscheidet vier unterschiedliche Arten von Nachrichten

  1. Confirmable
  2. Non-confirmable
  3. Acknowledgement
  4. Reset

Dadurch, dass CoAP das UDP Protokoll verwendet, sind grundsätzlich Duplikate oder Datenverlusste möglich.
Aus diesem Grund wurden innerhalb von CoAP die folgenden beiden mechanismen implementiert:

  • [ENG] Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages.
  • Duplikaterkennung für Confirmable und Non-confirmable Nachrichten

CoAP Nachrichtenformat

  • Ver (Version): CoAP Versionsnummer
  • T (Type): Gibt den Nachrichtentyp (0-3) an: Confirmable (0), Non-confirmable (1), Acknowledgement (2), oder Reset (3)
  • TKL (Token Length): Gibt die variable Länge des Tokens an.
  • Code: request (0), a success response (2), client error response (4), server error response (5)
  • Message ID: Wird zwecks Erkennung von Duplikaten oder zwecks Matching von Nachrichten verwendet
  • Options: Hier können Optionsnummern z.B. Max-Age mit der Nummer 14 oder Proxy-Uri (35) angegeben werden. Die komplette Liste der Optionsnummern kann aus der Spezifikation entnommen werden.
  • Payload

Paketgröße
Die max. Paketgröße beim CoAP Header liegt bei 1152 bytes und 1024 bytes für den Payload.
Ein CoAP Paket sollte die maximale Größe nicht überschreiten, da gößere Pakete zu einer unerwünschten Fragmentierung führen können.
Um eine IP Fragmentierung zu vermeiden, sollte die Übertragung der Pakete via IPv6 erfolgen. Sollte IPv4 zum Einsatz kommen, so muss die Größe der Pakete entspricht reduziert werden. Die Spezifikation bietet weitere Details.

Übertragung & Übertragungsparameter
Die Übertragung findet ähnlich wie bei HTTP über die Request/Response Semantik statt, wobei im Gegensatz zu HTTP keine Übertragung über eine bestehende bzw. vorherige Verbindung stattfindet.
CoAP unterstützt die folgenden basis Methoden, die man bereits von HTTPS kennt:

  • GET z.B. GET /status/power
  • POST
  • PUT
  • DELETE

Die Methoden GET, PUT und DELETE sind idempotent. POST ist NICHT idempotent.
Bei Response basiert auf dem Request Code innerhalb des Headers. Folgende drei Response Codes werden unterschieden:

  • Success
  • Client Error
  • Server Error

Das Protokoll bietet die folgende Übertragungsparameter an, die der Anwender für seine Umgebung entsprechend konfigurieren kann.

Bei der Veränderung der Konfiguration ist zu beachten, dass z.B. eine Verringerung von ‚ACK_TIMEOUT‘ auf eine Sekunde gegen ‚Unicast UDP Usage Guidelines for Application Designers‘ versossen wird.
Weitere Veränderungen können dabei gegen andere Guidelines verstoßen. Weiterhin haben Veränderungen der obigen Parameter in bestimmten Kombinationen bzw. Konstellationen weitere Einflüsse auf die Übertragung.
Für die Gewährleistung einer sicheren Kommunikation kommt ‚Datagram Transport Layer Security (DTSL)‘ zum Einsatz.

Security
CoAP unterscheidet die folgenden vier Security Level (mode):

  1. NoSec
  2. PreSharedKey – symmetrische Verschlüsselung
  3. RawPublicKey – asymmetrische Verschlüsselung
  4. Certificate – asymmetrische Verschlüsselung via X.509 Zertifikat

CoAP URI
Bei CoAP wird ähnlich wie bei HTTP zwischen http (coap) und https (coaps) unterschieden. Das CoAP Schema sieht wie folgt aus:

  • coap-URI = „coap:“ „//“ host [ „:“ port ] path-abempty [ „?“ query ]
  • coaps-URI = „coaps:“ „//“ host [ „:“ port ] path-abempty [ „?“ query ]

Service Discovery
Service-Discovery bezeichnet die automatische Erkennung von Diensten in einem Rechnernetz. Hierbei kommen Kommunikationsprotokolle zum Einsatz, welche beschreiben, wie sich die Dienste finden, um miteinander kommunizieren können.
Grundsätzlich unterscheidet man zwischen zwei Gruppen von Service-Discovery-Protokollen (SDPs):

  1. Dienste registrieren sich in einem zentralen Dienst (einer Registry) und können über diesen gefunden werden.
  2. Dienste fragen mittels Broadcasting das gesamte Netzwerk nach einem bestimmten Dienst und der gesuchte Dienst oder eine Registry antwortet. [wikipedia]

Nachdem Hosten eines Servers seitens eines 6LoWPAN nodes, kann der Server über die Portnummer 5683 und 5684 bei einer DTSL erreicht werden.
Das Entdecken (discovery) der Ressourcen erfolgt über ein CoAP Endpoint. Daher sollte ein Endpoint den CoRE Link format unterstützen. Das Format ist innerhalb von [RFC6690] beschrieben.
Für eine Kommunikation mit einem Server kann der CoAP-Agent Copper (Cu) verwendet werde.
https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

[Spezifikation: https://tools.ietf.org/html/rfc7252#section-12.2]

 

LwM2M Client & Servers
Wer einen eigenen Server oder Client erstellen möchte, kann die OMA Lightweight M2M server und client Implemtierung von LESHAN in Java verwenden.

Anbei ein paar Links zum LESHAN Projekt:
https://github.com/eclipse/leshan/blob/master/README.md
https://github.com/eclipse/leshan/wiki/Getting-started

MQTT: Zusammenfassung der Spezifikation (high level)

MQTT (Message Queue Telemetry Transport) ist ein offenes Nachrichtenprotokoll für Machine-to-Machine-Kommunikation (M2M), das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten ermöglicht, trotz hoher Verzögerungen oder beschränkter Netzwerke.
Entsprechende Geräte reichen von Sensoren und Aktoren, Mobiltelefonen, Eingebetteten Systemen in Fahrzeugen oder Laptops bis zu voll entwickelten Rechnern. [Wikipedia]

Die unten aufgeführten Informationen über die Spezifikation stammen unter anderem aus der aktuellen MQTT Spezifikation der IBM.

OSI
Innerhalb des OSI-Modells ist MQTT wie folgt angesiedelt:

Die MQTT-Spezifikation unterscheidet TCP/IP-basierte und Nicht-TCP/IP-Netzwerk. Standardmäßig verwendet MQTT das TCP Protokoll/Verbindung (Port 1883 und 8883 für eine SSL-Verbidung). Bei MQTT-SN (MQTT for Sensor Networks) wird statt TCP das UDP Protokoll verwendet.

MQTT Paket Struktur

Fixed header ist immer vorhanden, wobei ‚variable header‘ und ‚payload‘ nicht immer vorkommen.

Fixed header
Der ‚fixed‘ Header eine MQTT Nachricht hat eine Länge von zwei byte und ist wie folgt unterteilt:

Auflistung der ‚Message Types‘ – byte 1, bits 7-4:

Für eine detaillierte Beschreibung verweise ich auf die Spezifikation Kapitel 3.

Auflistung von byte 1, bits 3-1:

RETAIN
Wenn ein subscriber sich für eine topic registriert, so bekommt er die Daten erst wenn der publisher neue Daten zur Verfügung stellt. Sollten die Daten z.B. einmal am Tag übertragen werden, so wird der subscriber erst einmal so lange warten müssen, bis der neue Datensatz eintrifft. Um diesen Umstand entgegen zu wirken, kann der publisher dafür sorge tragen, dass neue subscriber den letzten Datensatz (obwohl vielleicht veraltet) erhalten. Hierfür muss der RETAIN flag auf den Wert 1 gesetzt werden.

Quality of Service (QoS)
QoS oder Dienstgüte bezeichnet die Güte eines Kommunikationsdienstes aus der Sicht der Anwender. Das heißt, wie stark die Güte des Dienstes mit deren Anforderungen übereinstimmt. Formal ist QoS eine Menge von Qualitätsanforderungen an das gemeinsame Verhalten beziehungsweise Zusammenspiel von mehreren Objekten.

Standard IEEE 802.1p

  • Ein Anwender möchte zuverlässig mit dem gewünschten Ziel verbunden werden und nach Ende der Kommunikation zuverlässig getrennt werden.
    Der Verbindungsaufbau soll rasch erfolgen.
  • Probleme beim Verbindungsaufbau (z. B. Ziel-Teilnehmer nicht erreichbar) sollen dem Anwender schnellstmöglich mitgeteilt werden.
  • Eine Kommunikationsverbindung soll stabil bestehen bleiben.
  • Die Kommunikationsteilnehmer wollen sich verstehen können.
  • Die Informationen sollen vollständig und ohne Fehler übertragen werden.
  • Es sollen keine Informationen anderer Kommunikationsteilnehmer und keine Störungen übertragen werden.
  • Die Kommunikation soll möglichst originalgetreu vor sich gehen.
  • Es sollen keine langen Wartezeiten während der Kommunikation bestehen.
  • Die Abrechnung der Kommunikation soll dem korrekten Zeit- und Datenumfang entsprechen. [Wikipedia]

Im Kontext von MQTT werden folgende drei QoS Stufen voneinander unterschieden:

Anbei die Darstellung der QoS Varrianten als Sequenzdiagramm für ein besseres Verständnis:

Duplicate delivery (DUP)
Dieser Flag wird immer dann gesetzt, wenn der Client oder der Server folgende Kommandos erneut senden möchten:

  • PUBLISH
  • PUBREL
  • SUBSCRIBE
  • UNSUBSCRIBE

DUP kann bei QoS > 0 gesetzt werden.

Variable header
Zusätzlich zum fixed header können MQTT Nachrichten einen variablen Header beinhalten.

Message identifiers

Der variable header der folgenden ‚Message Types‘ wird durch ‚Message identifiers‘ beschrieben:

  • PUBLISH
  • PUBACK
  • PUBREC
  • PUBREL
  • PUBCOMP
  • SUBSCRIBE
  • SUBACK
  • UNSUBSCRIBE
  • UNSUBACK

Payload
die folgenden MQTT Kommandos haben einen payload: