Matter uses IPv6 for its operational communications, and leverages on both IPv6 unicast and multicast addressing for accessing its Nodes and Groups, respectively.
Some Matter Nodes are wired and have energy budgets that allow them to keep their radios continuously on. Other types of Nodes such as sensors have requirements to run for years on a battery, operating their radios on low-power networks such as Thread. The proxy architecture, along with Thread Sleepy End Devices, allows full-powered Nodes to provide both network-level and application-level functionality that insulates their child Nodes from energy-intensive transactions.
A fundamental aspect of Matter is that it works both on high-throughput network mediums such as Wi-Fi and Ethernet, but also on low-latency, low-bandwidth, such as Thread. If all multicast packets from Wi-Fi are bridged into Thread we'd be burdening the network, and potentially flooding it. Thread's goal is to enable IPv6 in low-power, low-latency mesh networking, not high-bandwidth data transfer. While Thread's ICMPv6 pings in a local network are typically under few tens of milliseconds RTT, its total bandwidth is limited to 250 kbps at the IEEE 802.15.4 PHY. With packet retransmissions and overhead, the typical max bandwidth is around 125 kbps. In other words, orders of magnitude less than Wi-Fi.
Frames on the IEEE 802.15.4 PHY are 127 bytes, but the largest (and typical) maximum transmission unit (MTU) of IPv6 packets in Thread is 1280 bytes. Thus IPv6 packets often need to be split into several PHY frames. This process is defined by RFC4944.
So how can Nodes coexist on both transport mediums while in the same fabric? Although both networks share application-level Matter credentials, they don't share the same link technology. In this scenario, the network needs a Thread Border Router (BR) to enable connectivity. BRs are Stub IPv6 Routers.
Stub Routers enable connectivity between stub networks and regular networks. A Stub Network is a "last-mile" network that provides outer connectivity to its members, but doesn't serve as a transit network path between other networks. Typically, Matter Stub Networks are Thread-based. Refer to RFC draft for further information on stub networks.
BRs therefore have the responsibility of being the link between the Stub Network and the Adjacent Infrastructure Network, which is the local Wi-Fi or Ethernet network. They forward only the packets that are relevant to the Thread network.
This process is accomplished by assigning different IPv6 prefixes to Thread and Adjacent Infrastructure Networks. Thus the BR only forwards unicasts to or from the Thread IPv6 prefix.
Border Routers are also responsible for:
- automatically configuring IPv6 prefixes and routes for both the Thread and Adjacent Infrastructure Networks so that hosts on either side of the Thread Border router can communicate.
- publishing mDNS DNS-SD discovery packets on behalf of Thread Nodes, so they can be discovered on the adjacent infrastructure network.
Group messages are also important as they allow simultaneous control of several Matter Nodes through multicast. In order to route this traffic into the Thread network, both Matter and Thread implement the Unicast Prefix-based IPv6 Multicast Addressing Scheme defined by the RFC 3306.
This method allows the selection of the destination Nodes of a multicast packet based on their shared IPv6 unicast prefix.
For example, a Matter multicast address might look like this:
FF35:0040:FD<Fabric ID>00:<Group ID>
Table 1 details how this address is constructed:
Indicates a 64-bit long prefix
Designates a ULA prefix
|56 bits||Fabric ID|
More information can be found in the Multicast section of the Thread Primer and on the RFC itself.
When IPv6 Multicast Addresses are formed, they also include the upper 56-bits of the Fabric ID. The important implication is that the scope of multicast is within a Fabric, while unicast addresses are shared between Fabrics. Nodes with many fabrics can potentially have several multicast addresses defining overlapping Node Groups scoped at each fabric.
Matter uses Port 5540 for its Multicasts.
Thread Credentials on Android
On Android, most of the Google-specific functionality is handled by a module in Google Play Services. On Matter-compatible versions of Google Play Services, it also includes features for handling Thread credentials on compatible Border Routers. The Thread Network API allows Thread network configuration that is seamless and transparent.
Google Home app (GHA) makes use of these APIs for injecting the correct credentials on a new Node during the Matter commissioning flow.
Whenever a new Border Router such as the Google Nest Hub (2nd gen) is commissioned to your Android account using the GHA, it receives the same credentials used by other compatible Border Routers in the local network, as well from other mobile apps from vendors that choose to share their Thread network credentials.
There are several advantages of unifying the credentials of independent Thread mesh networks, such as better network reliability and lower interference.
To learn more about Thread, refer to the Thread Primer on openthread.io.