Matter Netzwerk Grundlagen

Matter definiert keine eigene Netzwerktechnologie, sondern setzt auf etablierten Internet-Protokollen auf. Die Transportschicht basiert ausschließlich auf IPv6; IPv4 gehört ausdrücklich nicht zum unterstützten Protokollumfang. Die eigentliche Kommunikation erfolgt im Regelbetrieb über UDP.

Der Protokollstapel lässt sich vereinfacht wie folgt darstellen:

Der Verzicht auf TCP ist eine bewusste Designentscheidung. TCP implementiert Zuverlässigkeit, Reihenfolge und Flusskontrolle generisch für beliebige Anwendungen und verursacht dadurch zusätzlichen Overhead. Matter nutzt stattdessen UDP und ergänzt die für IoT-Anwendungen erforderlichen Funktionen in dem eigenen Message Layer durch das Message Reliability Protocol (MRP). Dadurch lassen sich Quittierungen, Wiederholungen und Duplikaterkennung an die Anforderungen kurzer, transaktionsorientierter Nachrichten anpassen.

Aufbau einer Matter-Nachricht

Matter überträgt Nachrichten als binäre Datenströme. Anders als textbasierte Protokolle wie HTTP besteht eine Nachricht – abgesehen von Headern – aus einer Folge binär kodierter Felder. Für die Serialisierung der Nutzdaten verwendet Matter ein TLV-Verfahren (Type-Length-Value), das eine kompakte Darstellung variabler Datentypen ermöglicht.

Eine Matter-Nachricht besitzt schematisch folgenden Aufbau:

Der Message Header enthält unter anderem

• einen Message Counter,
• die Session-ID,
• Sicherheitsparameter sowie
• Informationen zur Quittierung.

Diese Felder werden vom Message Reliability Protocol ausgewertet. MRP implementiert Ende-zu-Ende-Quittierungen, erkennt verlorene oder doppelt empfangene Nachrichten und stößt bei Bedarf Wiederholungen an. Damit ergänzt Matter die verbindungslose UDP-Übertragung um genau diejenigen Zuverlässigkeitsmechanismen, die das Protokoll benötigt.

Matter Fabrics und Commissioning

Die Mitgliedschaft in einem gemeinsamen IP-Netzwerk genügt bei Matter nicht, damit Geräte miteinander kommunizieren können. Ein Gerät muss zunächst durch einen Controller in eine sogenannte Fabric aufgenommen werden. Dieser Vorgang wird als Commissioning bezeichnet.

Eine Fabric bildet die zentrale Vertrauensdomäne einer Matter-Installation. Sie definiert die kryptographischen Beziehungen zwischen Controllern und Endgeräten. Alle Mitglieder einer Fabric verfügen über gemeinsame Vertrauensanker und können sich gegenseitig authentifizieren. Welche Operationen ein Teilnehmer tatsächlich ausführen darf, legen Access Control Lists (ACLs) fest.

Vereinfacht ergibt sich folgende Struktur:

Während des Commissionings erhält das Gerät unter anderem

• eine Fabric-spezifische Identität,
• die erforderlichen Betriebsschlüssel und Zertifikate,
• Informationen über autorisierte Controller sowie
• Einträge für die Zugriffskontrolle.

Der Controller fungiert dabei als Commissioner und übernimmt die administrative Aufnahme des Geräts in die Fabric.

Rollen beim Commissioning

Am Commissioning sind zunächst lediglich zwei Komponenten beteiligt:

Der Commissioner authentifiziert das Gerät, etabliert eine gesicherte Verbindung und überträgt sämtliche für den Betrieb innerhalb der Fabric erforderlichen Konfigurationsdaten. Vor Abschluss dieses Vorgangs besitzt das Gerät weder eine Fabric-Identität noch dauerhafte kryptographische Beziehungen zu anderen Matter-Komponenten.

Mitgliedschaft in mehreren Fabrics

Ein wesentliches Architekturmerkmal von Matter ist die Unterstützung mehrerer Fabrics auf demselben Gerät.

Ein Endgerät kann gleichzeitig Mitglied mehrerer voneinander unabhängiger Fabrics sein, beispielsweise

• einer privaten Smart-Home-Installation,
• einer zweiten Fabric eines weiteren Benutzers oder
• einer Fabric eines Service- oder Verwaltungsanbieters.

Jede Fabric verwaltet ihre eigenen Zertifikate, Betriebsschlüssel und Zugriffskontrollen. Zwischen verschiedenen Fabrics bestehen keinerlei Vertrauensbeziehungen. Ein Controller einer Fabric kann daher nur auf die Geräte zugreifen, für die innerhalb dieser Fabric eine eigene kryptographische Beziehung und entsprechende ACL-Einträge eingerichtet wurden.

Discovery und Onboarding

Ein fabrikneues (unprovisioniertes) Matter-Gerät befindet sich zunächst im Commissionable Mode. In diesem Zustand nimmt es noch an keiner Fabric teil und stellt ausschließlich die für das Commissioning erforderlichen Discovery-Dienste bereit.

Das Gerät veröffentlicht dabei bewusst nur einen begrenzten Satz von Informationen. Insbesondere werden weder kryptographische Schlüssel noch vollständige Gerätekonfigurationen bekanntgegeben. Stattdessen kann ein Commissioner geeignete Geräte über standardisierte Discovery-Verfahren identifizieren.

Für das eigentliche Onboarding benötigt der Commissioner zusätzlich den Onboarding Payload, der üblicherweise über einen QR-Code oder einen numerischen Setup-Code außerhalb des eigentlichen Kommunikationskanals bereitgestellt wird (Out-of-Band).

Der QR-Code enthält unter anderem

• Vendor ID,
• Product ID,
• Device Discriminator,
• Setup PIN Code sowie
• die unterstützten Commissioning-Transporte.

Erst mit diesen Informationen kann der Commissioner das gewünschte Gerät eindeutig identifizieren und den Commissioning-Prozess starten.

Discovery eines Commissionable Device

Bei Matter over Ethernet oder Wi-Fi erfolgt die Gerätesuche über DNS Service Discovery (DNS-SD) auf Basis von mDNS.

Der Ablauf lässt sich wie folgt zusammenfassen:

Die mDNS-Ankündigung enthält unter anderem

• die IPv6-Adresse,
• den Device Discriminator,
• unterstützte Commissioning-Verfahren sowie
• weitere Discovery-Parameter.

Der Device Discriminator dient dabei ausschließlich der Vorauswahl geeigneter Geräte. Die eigentliche Authentifizierung erfolgt erst während des nachfolgenden kryptographischen Verbindungsaufbaus.

Aufbau der gesicherten Verbindung

Nach erfolgreicher Discovery etabliert der Commissioner zunächst eine temporäre, verschlüsselte Sitzung mittels PASE (Password Authenticated Session Establishment). Grundlage hierfür ist der Setup PIN Code aus dem Onboarding Payload.

Über diese Verbindung erfolgen anschließend

• die Geräteauthentifizierung,
• die Aufnahme in die Fabric,
• der Austausch der betrieblichen Schlüssel und Zertifikate sowie
• die Konfiguration der Zugriffskontrolle.

Nach erfolgreichem Commissioning verfügt das Gerät über eine dauerhafte Identität innerhalb der Fabric. Für die reguläre Kommunikation verwendet Matter anschließend CASE (Certificate Authenticated Session Establishment), bei dem sich die Kommunikationspartner gegenseitig über ihre operativen Zertifikate authentifizieren.

Nach dem Commissioning

Nach Abschluss des Commissionings verlässt das Gerät in der Regel den Commissionable Mode. Die weitere Kommunikation erfolgt ausschließlich über reguläre Matter-Sessions innerhalb der Fabric.

Bereits eingerichtete Geräte werden weiterhin über DNS-SD und mDNS gefunden. Das Discovery-Verfahren dient in diesem Fall ausschließlich der Auffindung erreichbarer Teilnehmer; Authentifizierung und Autorisierung erfolgen unabhängig davon über die bestehenden kryptographischen Beziehungen innerhalb der jeweiligen Fabric.

Matter über Thread

Matter ist von der darunterliegenden Netzwerktechnologie weitgehend unabhängig. Neben Ethernet und Wi-Fi unterstützt der Standard auch Thread als Transportnetz. Thread wurde für energiearme IoT-Geräte entwickelt und kombiniert IPv6-Kommunikation mit einem selbstorganisierenden Mesh-Netzwerk auf Basis von IEEE 802.15.4.

Obwohl Thread wie WLAN das 2,4-GHz-Band nutzt, handelt es sich um einen vollständig anderen Funkstandard. Beide Technologien sind weder auf MAC- noch auf PHY-Ebene interoperabel.

Thread-Protokollstack

Thread stellt ein natives IPv6-Netzwerk bereit. Die Übertragung erfolgt über IEEE 802.15.4; die Anpassung von IPv6 an die vergleichsweise kleinen Funkframes übernimmt 6LoWPAN.

Der vereinfachte Protokollstack lautet:

Aus Sicht von Matter unterscheidet sich ein Thread-Netz damit nicht grundsätzlich von einem Ethernet- oder WLAN-Netz: Die Anwendung kommuniziert ausschließlich über IPv6 und UDP. Routing, Mesh-Bildung und Funkkommunikation werden vollständig von Thread übernommen.

Aufbau eines Thread-Netzwerks

Ein Thread-Netz besteht aus Routern und Endgeräten. Router leiten IPv6-Pakete innerhalb des Meshs weiter und bilden gemeinsam die vermaschte Topologie.

Im Gegensatz zu klassischen Sternnetzwerken existiert keine zentrale Funkbasisstation. Fällt ein Router aus, kann das Routing automatisch über andere Router erfolgen.

Batteriebetriebene Geräte arbeiten häufig als Sleepy End Devices (SED). Sie nehmen nicht dauerhaft am Routing teil, sondern kommunizieren ausschließlich mit ihrem jeweiligen Parent Router und können ihre Funkhardware zwischen zwei Kommunikationsvorgängen abschalten.

Thread Border Router

Ein Thread-Netz bildet eine eigene Layer-2-Domäne. Soll es mit einem Ethernet- oder WLAN-Netz kommunizieren, ist ein Thread Border Router erforderlich.

Der Border Router arbeitet als IPv6-Router zwischen zwei unterschiedlichen Layer-2-Netzen. Er übersetzt weder Matter noch Thread in andere Protokolle. IPv6-Pakete werden unverändert zwischen beiden Netzen weitergeleitet.

Zusätzlich übernimmt der Border Router thread-spezifische Infrastrukturaufgaben wie

• Bereitstellung des IPv6-Präfixes,
• Router Advertisements,
• DNS- und Service-Proxying sowie
• die Verwaltung des Thread-Netzes.

Aus Sicht von Matter existiert daher kein Unterschied zwischen einem Gerät im Ethernet und einem Gerät im Thread-Netz; beide kommunizieren über IPv6.

Thread-Integration beim Commissioning

Ein fabrikneues Matter-over-Thread-Gerät besitzt zwar die erforderliche Funkhardware, kennt jedoch das lokale Thread-Netz noch nicht. Insbesondere fehlen

• der Thread Network Key,
• der Active Operational Dataset,
• Kanal- und PAN-Konfiguration sowie
• weitere Parameter für den Netzbeitritt.

Ohne diese Informationen kann das Gerät dem Thread-Netz nicht beitreten und folglich auch keine IPv6-Konnektivität zum Border Router aufbauen.

Der Beitritt zum Thread-Netz ist deshalb Bestandteil des Commissioning-Prozesses.

Bluetooth Low Energy als Commissioning Transport

Die Übertragung der Thread-Netzwerkparameter erfolgt bei Matter-over-Thread typischerweise über Bluetooth Low Energy (BLE) als temporären Transportkanal, da dafür die gleiche Funk-Hardware verwendet werden kann wie für den späteren Regelbetrieb.

Der Ablauf sieht vereinfacht wie folgt aus:

Während der BLE-Verbindung überträgt der Commissioner sowohl die Parameter des Thread-Netzes als auch die für das Matter-Commissioning erforderlichen Informationen.

Die Thread-Konfiguration wird durch den Active Operational Dataset beschrieben. Er enthält unter anderem den Network Key, die PAN-ID, den verwendeten Funkkanal sowie weitere netzspezifische Parameter.

Woher der Commissioner diesen Dataset erhält, ist nicht Bestandteil der Matter-Spezifikation. Häufig stammen die Informationen vom Thread Border Router oder einer integrierten Thread-Verwaltung des jeweiligen Ökosystems. Verwenden Commissioner und Border Router unterschiedliche Implementierungen, muss der Operational Dataset gegebenenfalls manuell exportiert und importiert werden.

Kommunikation nach dem Commissioning

Nach erfolgreichem Netzbeitritt wird die BLE-Verbindung nicht mehr benötigt. Sämtliche Kommunikation erfolgt anschließend über IPv6 im Thread-Netz.

BLE dient ausschließlich dem initialen Netzbeitritt. Der reguläre Betrieb verwendet ausschließlich den nativen IPv6-Kommunikationspfad über das Thread-Netz und den Border Router.

Eigenes Matter-Testnetz mit Open-Source-Software

Für Experimente mit Matter ist keine proprietäre Infrastruktur erforderlich. Eine vollständige Testumgebung lässt sich mit Open-Source-Komponenten aufbauen.

Als Matter-Controller eignet sich beispielsweise Matter.js, während OpenThread Border Router (OTBR) die Anbindung eines Thread-Netzes übernimmt. Beide Komponenten lassen sich problemlos auf einem Raspberry Pi oder vergleichbarer Hardware betreiben.

Für Matter-over-Thread wird zusätzlich ein IEEE-802.15.4-Funkadapter benötigt, da Raspberry-Pi-Systeme zwar Bluetooth und WLAN integrieren, jedoch keine IEEE-802.15.4-Funkschnittstelle besitzen. Üblicherweise kommen hierfür USB-Dongles oder per USB beziehungsweise UART angeschlossene Funkmodule auf Basis von Chips wie Nordic nRF52840 oder Silicon Labs EFR32 zum Einsatz.

Die Bluetooth-Schnittstelle des Raspberry Pi kann während des Commissionings für die temporäre BLE-Verbindung zum Matter-Gerät verwendet werden. Nach Abschluss des Commissionings erfolgt die Kommunikation ausschließlich über Thread beziehungsweise Ethernet oder WLAN.

Die resultierende Architektur sieht schematisch wie folgt aus:

Durch die Trennung zwischen Matter-Controller und Thread Border Router lässt sich die Architektur verschiedener Hersteller-Ökosysteme realitätsnah nachbilden. Ebenso können beide Funktionen auf unterschiedliche Systeme verteilt werden, da Matter lediglich IP-Konnektivität zwischen den beteiligten Komponenten voraussetzt.

Der praktische Aufbau einer solchen Testumgebung, die Installation der benötigten Software sowie das Commissioning erster Geräte werden im nächsten Teil der Artikelserie beschrieben.

Add a comment