Matter verwendet IPv6 für die betriebliche Kommunikation und sowohl die IPv6-Unicast- als auch die IPv6-Multicast-Adressierung für den Zugriff auf seine Knoten bzw. -Gruppen.
Niedriger Energiebedarf
Einige Matter-Knoten sind verkabelt und haben Energiebudgets, die es ihnen ermöglichen, die Funkverbindung durchgehend eingeschaltet zu halten. Andere Knotentypen wie Sensoren müssen jahrelang mit einer Batterie betrieben werden, um ihre Funkschnittstellen in Netzwerken mit geringem Energieverbrauch wie Thread zu betreiben. Die Proxy-Architektur ermöglicht zusammen mit Thread Sleepy End Devices mit voll ausgestatteten Knoten, sowohl auf Netzwerk- als auch auf Anwendungsebene Funktionalität bereitzustellen, die ihre untergeordneten Knoten vor energieintensiven Transaktionen isoliert.
Ein grundlegender Aspekt von Matter besteht darin, dass es sowohl bei Netzwerkmedien mit hohem Durchsatz wie WLAN und Ethernet als auch mit niedriger Latenz und niedriger Bandbreite wie Thread funktioniert. Wenn alle Multicast-Pakete aus dem WLAN zu Thread überbrückt werden würden, würde das Netzwerk überlastet und möglicherweise überflutet. Das Ziel von Thread ist es, IPv6 in Mesh-Netzwerken mit geringem Stromverbrauch und niedriger Latenz zu ermöglichen, nicht in Datenübertragungen mit hoher Bandbreite. Während die ICMPv6-Pings von Thread in einem lokalen Netzwerk in der Regel weniger als wenige Millisekunden RTT betragen, ist seine Gesamtbandbreite beim IEEE 802.15.4 PHY auf 250 kbit/s begrenzt. Bei der Übertragung von Paketen und des Overheads liegt die typische maximale Bandbreite bei etwa 125 kbit/s. Mit anderen Worten: Der WLAN-Standard ist um einiges niedriger.
Frames in IEEE 802.15.4 PHY sind 127 Byte groß, die größte (und typische) maximale Übertragungseinheit (MTU) von IPv6-Paketen in Thread beträgt jedoch 1.280 Byte. Daher müssen IPv6-Pakete häufig in mehrere PHY-Frames aufgeteilt werden. Dieser Prozess ist durch RFC4944 definiert.
Weitere Informationen finden Sie unter IPv6-Adressierung in der Thread-Primer von openthread.io.
Border-Router
Wie können Knoten also auf beiden Transportmedien im selben Fabric zusammen verwendet werden? Obwohl beide Netzwerke dieselben Matter-Anmeldedaten auf Anwendungsebene haben, haben sie nicht dieselbe Verknüpfungstechnologie. In diesem Szenario benötigt das Netzwerk einen Thread Border Router (BR), um die Verbindung zu aktivieren. BRs sind Stub-IPv6-Router.
Stub-Router ermöglichen die Verbindung zwischen Stub-Netzwerken und regulären Netzwerken. Ein Stub-Netzwerk ist ein Netzwerk auf der letzten Meile, das seinen Mitgliedern äußere Konnektivität bietet, jedoch nicht als Transit-Netzwerkpfad zwischen anderen Netzwerken dient. In der Regel basieren Matter-Stub-Netzwerke auf Thread. Weitere Informationen zu Stub-Netzwerken finden Sie im RFC-Entwurf.
BRs sind daher für die Verbindung zwischen dem Stub-Netzwerk und dem benachbarten Infrastrukturnetzwerk verantwortlich, bei dem es sich um das lokale WLAN- oder Ethernet-Netzwerk handelt. Sie leiten nur die Pakete weiter, die für das Netzwerk Thread relevant sind.
Dazu werden Thread und benachbarten Infrastrukturnetzwerken verschiedene IPv6-Präfixe zugewiesen. Daher leitet der BR nur Unicasts zum oder vom IPv6-Präfix Thread weiter.
Border Router sind außerdem verantwortlich für:
- automatische Konfiguration von IPv6-Präfixen und -Routen für Thread und benachbarte Infrastrukturnetzwerke, sodass Hosts auf beiden Seiten des Border-Routers Thread kommunizieren können.
- Veröffentlichung von mDNS-DNS-SD-Discovery-Paketen im Namen von Thread-Knoten, damit sie im angrenzenden Infrastrukturnetzwerk erkannt werden können.
Weitere Informationen finden Sie im Leitfaden zum Border Router auf openthread.io.
IPv6-Multicast
Gruppennachrichten sind ebenfalls wichtig, da sie die gleichzeitige Kontrolle mehrerer Matter-Knoten über Multicast ermöglichen. Damit dieser Traffic an das Thread-Netzwerk weitergeleitet werden kann, implementieren sowohl Matter als auch Thread das Unicast-Präfix-basierte Multicast-Adressierungsschema für Unicast, 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 der Aufbau dieser Adresse beschrieben:
| Bit | Beschreibung |
| 12 Bit | 0xFF3 |
| 4 Bit | 0x05
Umfang: website-lokal |
| 8 Bit | 0x00
reserviert |
| 8 Bit | 0x40
Gibt ein 64-Bit-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 Primer App von Thread und im RFC selbst.
Wenn Multicast-IPv6-Adressen gebildet werden, enthalten sie auch die oberen 56 Bit der Fabric-ID. Die wichtige Folge ist, dass der Bereich von Multicast innerhalb einer Fabric liegt, während Unicast-Adressen zwischen Fabrics gemeinsam genutzt werden. Knoten mit vielen Fabrics können möglicherweise mehrere Multicast-Adressen haben, die sich überschneidende Knotengruppen in jeder Fabric definieren.
Ports
Matter verwendet Port 5540 für seine Multicasts.