Matter utilise IPv6 pour ses communications opérationnelles, et exploite à la fois l'adressage IPv6 Unicast et l'adressage Multicast pour accéder respectivement à ses nœuds et à ses groupes.
Faible consommation d'énergie
Certains nœuds Matter sont câblés et disposent d'un budget énergétique qui leur permet de maintenir leurs signaux radio en continu. D'autres types de nœuds, tels que les capteurs, doivent fonctionner pendant des années sur une batterie et faire fonctionner leurs signaux radio sur des réseaux à faible consommation d'énergie tels que Thread. L'architecture de proxy, combinée à Thread Sleepy End Devices, permet aux nœuds complets de fournir à la fois des fonctionnalités au niveau du réseau et de l'application qui isolent leurs nœuds enfants des transactions énergivores.
L'un des aspects fondamentaux de Matter est qu'il fonctionne à la fois sur les réseaux à haut débit tels que le Wi-Fi et Ethernet, mais aussi sur des réseaux à faible latence et à faible bande passante, tels que Thread. Si tous les paquets Multicast provenant du Wi-Fi étaient pontés vers Thread, le réseau serait surchargé et pourrait l'inonder. L'objectif de Thread est d'activer le protocole IPv6 dans un réseau maillé à faible consommation d'énergie et à faible latence, et non dans un transfert de données à haut débit. Bien que les pings ICMPv6 de Thread sur un réseau local durent généralement moins de quelques dizaines de millisecondes en DAR, sa bande passante totale est limitée à 250 kbit/s selon la norme IEEE 802.15.4 PHY. Avec la retransmission de paquets et la surcharge, la bande passante maximale typique est d'environ 125 kbit/s. En d'autres termes, des ordres de grandeur inférieurs au Wi-Fi.
Les trames de la norme IEEE 802.15.4 PHY ont une taille de 127 octets, mais l'unité de transmission maximale (MTU) des paquets IPv6 dans Thread est de 1 280 octets. C'est pourquoi les paquets IPv6 doivent souvent être divisés en plusieurs trames PHY. Ce processus est défini par le document RFC4944.
Pour en savoir plus, consultez la section Adressage IPv6 dans le guide Thread sur openthread.io.
Routeurs de bordure
Comment les nœuds peuvent-ils coexister sur les deux supports de transport dans la même data fabric ? Bien que les deux réseaux partagent les identifiants Matter au niveau de l'application, ils ne partagent pas la même technologie de liaison. Dans ce scénario, le réseau a besoin d'un routeur de bordure Thread pour activer la connectivité. Les BR sont des routeurs IPv6 stub.
Les routeurs bouchon permettent d'établir la connectivité entre les réseaux bouchons et les réseaux standards. Un réseau bouchon est un réseau sur le "dernier kilomètre" qui fournit une connectivité externe à ses membres, mais ne sert pas de chemin de réseau de transit entre d'autres réseaux. En règle générale, les réseaux stub Matter sont basés sur Thread. Pour plus d'informations sur les réseaux bouchons, consultez le brouillon RFC.
Les serveurs BR ont donc la responsabilité d'être le lien entre le réseau stub et le réseau d'infrastructure adjacent, qui est le réseau Wi-Fi ou Ethernet local. Ils ne transfèrent que les paquets pertinents pour le réseau Thread.
Ce processus est réalisé en attribuant différents préfixes IPv6 à Thread et aux réseaux d'infrastructure adjacents. Ainsi, le BR ne transfère que les unicasts vers ou depuis le préfixe IPv6 Thread.
Les routeurs de bordure sont également chargés de:
- en configurant automatiquement les préfixes et routes IPv6 du réseau Thread et du réseau d'infrastructure adjacent afin que les hôtes situés de chaque côté du routeur de bordure Thread puissent communiquer.
- Publication des paquets de découverte DNS-SD mDNS pour le compte de nœuds Thread afin qu'ils puissent être découverts sur le réseau d'infrastructure adjacent.
Pour en savoir plus, consultez le guide des routeurs de bordure sur openthread.io.
Multidiffusion IPv6
Les messages de groupe sont également importants, car ils permettent le contrôle simultané de plusieurs nœuds Matter via Multicast. Pour acheminer ce trafic vers le réseau Thread, Matter et Thread mettent tous deux en œuvre le schéma d'adressage Multicast IPv6 basé sur le préfixe Unicast défini par le document RFC 3306.
Cette méthode permet de sélectionner les nœuds de destination d'un paquet Multicast en fonction de leur préfixe IPv6 Unicast partagé.
Par exemple, une adresse Multicast Matter peut se présenter comme suit:
FF35:0040:FD<Fabric ID>00:<Group ID>
Le tableau 1 détaille la construction de cette adresse:
| Bits | Description |
| 12 bits | 0xFF3 |
| 4 bits | 0x05
Champ d'application: site-local |
| 8 bits | 0x00
réservés |
| 8 bits | 0x40
Indique un préfixe de 64 bits. |
| 8 bits | 0xFD
Désigne un préfixe ULA. |
| 56 bits | ID de structure |
| 8 bits | 0x00 |
| 16 bits | ID du groupe |
Pour en savoir plus, consultez la section Multicast du Primer Thread et le document RFC lui-même.
Lorsque des adresses IPv6 Multicast sont formées, elles incluent également les 56 bits supérieurs de l'ID Fabric. L'important est que le champ d'application de Multicast se trouve dans un Fabric, tandis que les adresses Unicast sont partagées entre Fabric. Les nœuds comportant de nombreuses fabrics peuvent potentiellement avoir plusieurs adresses Multicast définissant des groupes de nœuds se chevauchant et limités à chaque fabric.
Ports
Matter utilise le port 5540 pour ses multidiffusions.