Matter wykorzystuje protokół IPv6 do komunikacji operacyjnej oraz wykorzystuje zarówno adresowanie Unicast, jak i Multicast IPv6 do uzyskiwania dostępu odpowiednio do węzłów i grup.
Niska moc
Niektóre węzły Matter są podłączone przewodowo i mają budżet na energię, który umożliwia im nieprzerwaną pracę radiową. Inne typy węzłów, takie jak czujniki, muszą działać przez lata na baterii i działać radiowe w sieciach o małej mocy, np. Thread. Architektura serwera proxy w połączeniu z Thread Sleepy End Devices umożliwia w pełni z wykorzystaniem węzłów dostarczanie funkcji zarówno na poziomie sieci, jak i na poziomie aplikacji, co izoluje węzły podrzędne przed transakcjami energooszczędnymi.
Podstawowym aspektem usługi Matter jest to, że działa ona zarówno w sieciach o dużej przepustowości, takich jak Wi-Fi i Ethernet, jak i przy małych opóźnieniach i niskiej przepustowości (np. Thread). Gdyby wszystkie pakiety Multicast z Wi-Fi zostały połączone z serwerem Thread, przeciążbyłoby to sieć i może ją zalać. Celem Thread jest włączenie protokołu IPv6 w sieciach typu mesh o małej mocy i małych opóźnieniach, a nie w przypadku przesyłania danych o dużej przepustowości. Choć pingi ICMPv6 systemu Thread w sieci lokalnej zwykle trwają poniżej kilku dziesiątek milisekund (RTT), łączna przepustowość jest ograniczona do 250 kb/s w przypadku PHY IEEE 802.15.4. W przypadku ponownego przesyłania pakietów i narzutu typowa maksymalna przepustowość to około 125 kb/s. Innymi słowy, rzędy wielkości mniejsze niż Wi-Fi.
Ramki w przeglądarce IEEE 802.15.4 PHY mają 127 bajtów, ale największa (i typowa) maksymalna jednostka przesyłania (MTU) pakietów IPv6 w Thread ma 1280 bajtów. Z tego względu pakiety IPv6 często trzeba podzielić na kilka ramek PHY. Ten proces jest zdefiniowany w dokumencie RFC4944.
Aby dowiedzieć się więcej, zapoznaj się z sekcją Adresowanie IPv6 w aplikacji Thread Primer na stronie openthread.io.
Frezy graniczne
W jaki sposób Węzły mogą współistnieć w obu środkach transportu, jeśli są w tej samej tkaninie? Mimo że obie sieci korzystają ze wspólnych danych logowania Matter na poziomie aplikacji, nie korzystają z tej samej technologii łączenia. W tym scenariuszu sieć potrzebuje Thread routera granicznego (BR), aby umożliwić połączenie. BR to routery typu Stub IPv6.
routery kablowe umożliwiają łączenie się z sieciami typu „królewka” i „zwykłymi sieciami”, Sieć Stub to sieć „ostatnia kilometra”, która zapewnia swoim członkom zewnętrzne połączenie, ale nie pełni jej jako ścieżki tranzytowej między innymi sieciami. Zwykle Matter sieci typu Stub opierają się na Thread. Więcej informacji o sieciach tymczasowych znajdziesz w wersji roboczej RFC.
W związku z tym BR odpowiada za łączenie sieci Stub z sąsiadującą siecią infrastruktury, czyli lokalną siecią Wi-Fi lub Ethernet. Przekazują one tylko te pakiety, które są istotne w sieci Thread.
Ten proces odbywa się przez przypisanie różnych prefiksów IPv6 do sieci Thread i sąsiednich sieci infrastruktury. Oznacza to, że BR przekazuje tylko wiadomości pojedyncze na lub z prefiksu IPv6 Thread.
Routery graniczne są też odpowiedzialne za:
- automatycznie konfigurując prefiksy i trasy IPv6 zarówno dla sieci infrastruktury Thread, jak i sieci przyległej, tak aby hosty po obu stronach routera granicznego Thread mogły się komunikować.
- publikowanie pakietów wykrywania mDNS DNS-SD w imieniu węzłów Thread, aby można je było wykrywać w sąsiedniej sieci infrastruktury;
Więcej informacji znajdziesz w przewodniku Border Router na stronie openthread.io.
Multicast IPv6
Wiadomości grupowe są również ważne, ponieważ umożliwiają jednoczesne kontrolowanie kilku węzłów Matter za pomocą Multicast. Aby skierować ten ruch do sieci Thread, zarówno Matter, jak i Thread implementują Unicast schemat adresu IPv6 Multicast oparty na prefiksie zdefiniowany w RFC 3306.
Ta metoda umożliwia wybór węzłów docelowych pakietu Multicast na podstawie ich wspólnego prefiksu IPv6 Unicast.
Na przykład adres dla adresu Matter Multicast może wyglądać tak:
FF35:0040:FD<Fabric ID>00:<Group ID>
Tabela 1 zawiera szczegółowe informacje o konstrukcji tego adresu:
| Bitwy | Opis |
| 12-bitowa | 0xFF3 |
| 4 bity | 0x05
Zakres: witryna-lokalna |
| 8-bitowa | 0x00
zarezerwowane |
| 8-bitowa | 0x40
Wskazuje 64-bitowy prefiks |
| 8-bitowa | 0xFD
Wskazuje prefiks ULA |
| 56-bitowa | Identyfikator tkaniny |
| 8-bitowa | 0x00 |
| 16-bitowa | Identyfikator grupy |
Więcej informacji znajdziesz w sekcji Multicast w Thread Primer oraz w dokumencie RFC.
Gdy tworzone są adresy Multicast IPv6, obejmują one także górne 56 bitów identyfikatora Fabric. Istotne znaczenie ma to, że zakres Multicast znajduje się w ramach usługi Fabric, a adresy Unicast są współdzielone przez Fabric. Węzły z wieloma tkaninami mogą mieć kilka adresów Multicast definiujących nakładające się grupy węzłów w każdej tkaninie.
Porty
Matter używa portu 5540 do obsługi multiemisji.