Matter verwendet IPv6 für die betriebliche Kommunikation und nutzt sowohl IPv6-Unicast- als auch Multicast-Adressierung für den Zugriff auf die Knoten und Gruppen.
Niedriger Energiebedarf
Einige Matter-Knoten sind kabelgebunden und haben Energiebudgets, die es ihnen ermöglichen, ihre Funkmodule kontinuierlich eingeschaltet zu lassen. Andere Arten von Knoten wie Sensoren müssen jahrelang mit einer Batterie betrieben werden und ihre Funkmodule in Netzwerken mit geringem Stromverbrauch wie Thread betreiben. Die Proxy-Architektur ermöglicht zusammen mit Thread-Sleepy-End-Geräten, dass Knoten mit voller Leistung sowohl Funktionen auf Netzwerk- als auch auf Anwendungsebene bereitstellen, die ihre untergeordneten Knoten vor energieintensiven Transaktionen schützen.
Ein grundlegender Aspekt von Matter ist, dass es sowohl in Netzwerkmedien mit hohem Durchsatz wie WLAN und Ethernet als auch in Netzwerkmedien mit niedriger Latenz und geringer Bandbreite wie Thread funktioniert. Wenn alle Multicast-Pakete aus dem WLAN in Thread überbrückt würden, würde das Netzwerk überlastet und möglicherweise überflutet werden. Das Ziel von Thread ist es, IPv6 in Mesh-Netzwerken mit geringem Stromverbrauch und niedriger Latenz zu ermöglichen, nicht die Datenübertragung mit hoher Bandbreite. Während die ICMPv6-Pings von Thread in einem lokalen Netzwerk normalerweise eine RTT von weniger als einigen zehn Millisekunden haben, ist die Gesamtbandbreite auf 250 Kbit/s auf der IEEE 802.15.4-PHY begrenzt. Mit Paketwiederholungen und Overhead liegt die typische maximale Bandbreite bei etwa 125 Kbit/s. Mit anderen Worten: um Größenordnungen weniger als WLAN.
Frames auf der IEEE 802.15.4-PHY sind 127 Byte groß, aber die größte (und typische) maximale Übertragungseinheit (MTU) von IPv6-Paketen in Thread beträgt 1.280 Byte. Daher müssen IPv6-Pakete oft in mehrere PHY-Frames aufgeteilt werden. Dieser Prozess ist in RFC4944 definiert.
Weitere Informationen finden Sie unter IPv6-Adressierung im Thread-Primer auf openthread.io.
Border-Router
Wie können Knoten also in derselben Fabric auf beiden Transportmedien koexistieren? Obwohl beide Netzwerke Matter-Anmeldedaten auf Anwendungsebene gemeinsam nutzen, verwenden sie nicht dieselbe Linktechnologie. In diesem Szenario benötigt das Netzwerk einen Thread Border Router (TBR), um die Verbindung zu ermöglichen. BRs sind Stub-IPv6-Router.
Stub-Router ermöglichen die Verbindung zwischen Stub-Netzwerken und regulären Netzwerken. Ein Stub-Netzwerk ist ein „Last-Mile“-Netzwerk, das seinen Mitgliedern eine externe Verbindung bietet, aber nicht als Transitnetzwerkpfad zwischen anderen Netzwerken dient. In der Regel sind Matter-Stub-Netzwerke Thread-basiert. Weitere Informationen zu Stub-Netzwerken finden Sie im RFC-Entwurf.
BRs sind daher für die Verbindung zwischen dem Stub-Netzwerk und dem angrenzenden Infrastrukturnetzwerk verantwortlich, d. h. dem lokalen WLAN oder Ethernet-Netzwerk. Sie leiten nur die Pakete weiter, die für das Netzwerk Thread relevant sind.
Dazu werden Thread und angrenzenden Infrastrukturnetzwerken unterschiedliche IPv6-Präfixe zugewiesen. Daher leitet der BR nur Unicasts an das oder vom Thread-IPv6-Präfix weiter.
Border-Router sind außerdem für Folgendes verantwortlich:
- Automatische Konfiguration von IPv6-Präfixen und -Routen für das Thread-Netzwerk und die angrenzenden Infrastrukturnetzwerke, damit Hosts auf beiden Seiten des TBR-Netzwerks kommunizieren können.
- Veröffentlichen von mDNS-DNS-SD-Erkennungspaketen im Namen von Thread-Knoten, damit sie im angrenzenden Infrastrukturnetzwerk erkannt werden können.
Weitere Informationen finden Sie im Leitfaden zu OpenThread Border Router (OTBR).
IPv6-Multicast
Gruppennachrichten sind ebenfalls wichtig, da sie die gleichzeitige Steuerung mehrerer Matter-Knoten über Multicast ermöglichen. Um diesen Traffic in das Thread-Netzwerk weiterzuleiten, implementieren sowohl Matter als auch Thread das Unicast-Präfix-basierte IPv6-Multicast-Adressierungsschema, das durch RFC 3306 definiert ist.
Mit dieser Methode können die Zielknoten eines Multicast-Pakets anhand ihres gemeinsamen IPv6-Unicast-Präfixes ausgewählt werden.
Eine Matter-Multicast-Adresse könnte beispielsweise so aussehen:
FF35:0040:FD<Fabric ID>00:<Group ID>
In Tabelle 1 wird beschrieben, wie diese Adresse aufgebaut ist:
| Bits | Beschreibung |
| 12 Bit | 0xFF3 |
| 4 Bit | 0x05
Bereich: standortlokal |
| 8 Bit | 0x00
reserved |
| 8 Bit | 0x40
Gibt ein 64 Bit langes Präfix an. |
| 8 Bit | 0xFD
Gibt ein ULA-Präfix an |
| 56 Bit | Fabric-ID |
| 8 Bit | 0x00 |
| 16 Bit | Gruppen-ID |
Weitere Informationen finden Sie im Abschnitt Multicast der Thread-Einführung und im RFC selbst.
Wenn IPv6-Multicast-Adressen gebildet werden, enthalten sie auch die oberen 56 Bit der Fabric-ID. Das bedeutet, dass der Bereich von Multicast innerhalb einer Fabric liegt, während Unicast-Adressen von mehreren Fabrics gemeinsam genutzt werden. Knoten mit vielen Fabrics können potenziell mehrere Multicast-Adressen haben, die sich überschneidende Knotengruppen definieren, die auf die einzelnen Fabrics beschränkt sind.
Ports
Matter verwendet Port 5540 für Multicasts.