Matter Network Fundamentals

Matter does not define its own networking technology but instead builds on established Internet protocols. The transport layer is based exclusively on IPv6; IPv4 is explicitly not part of the supported protocol suite. Under normal operation, communication takes place over UDP.

The protocol stack can be simplified as follows:

Avoiding TCP is a deliberate design decision. TCP provides reliability, ordering, and flow control as generic mechanisms for arbitrary applications, which introduces additional overhead. Instead, Matter uses UDP and implements the functions required for IoT applications within its own Message Layer through the Message Reliability Protocol (MRP). This allows acknowledgements, retransmissions, and duplicate detection to be tailored to the requirements of short, transaction-oriented messages.

Structure of a Matter Message

Matter transmits messages as binary data streams. Unlike text-based protocols such as HTTP, a message—apart from its headers—consists of a sequence of binary-encoded fields. To serialize payload data, Matter uses a TLV (Type-Length-Value) encoding scheme, which provides a compact representation of variable data types.

A Matter message has the following schematic structure:

Among other things, the Message Header contains:

• a Message Counter,
• the Session ID,
• security parameters, and
• acknowledgement information.

These fields are evaluated by the Message Reliability Protocol. MRP implements end-to-end acknowledgements, detects lost or duplicate messages, and initiates retransmissions when necessary. In this way, Matter augments UDP’s connectionless transport with exactly the reliability mechanisms required by the protocol.

Matter Fabrics and Commissioning

Being connected to the same IP network is not sufficient for Matter devices to communicate. A device must first be added to a so-called Fabric by a controller. This process is known as commissioning.

A Fabric forms the central trust domain of a Matter installation. It defines the cryptographic relationships between controllers and end devices. All members of a Fabric share common trust anchors and can authenticate each other. Which operations a participant is actually allowed to perform is determined by Access Control Lists (ACLs).

The simplified structure is as follows:

During commissioning, the device receives, among other things:

• a Fabric-specific identity,
• the required operational keys and certificates,
• information about authorized controllers, and
• access control entries.

The controller acts as the Commissioner, performing the administrative task of adding the device to the Fabric.

Roles During Commissioning

Initially, only two components participate in the commissioning process:

The Commissioner authenticates the device, establishes a secure connection, and transfers all configuration data required for operation within the Fabric. Until this process is complete, the device has neither a Fabric identity nor any permanent cryptographic relationships with other Matter components.

Membership in Multiple Fabrics

One of Matter’s key architectural features is support for multiple Fabrics on the same device.

An end device can simultaneously belong to several independent Fabrics, for example:

• a private smart home installation,
• a second Fabric owned by another user, or
• a Fabric operated by a service or management provider.

Each Fabric manages its own certificates, operational keys, and access controls. No trust relationships exist between different Fabrics. Consequently, a controller belonging to one Fabric can access only those devices for which a separate cryptographic relationship and corresponding ACL entries have been established within that Fabric.

Discovery and Onboarding

A factory-new (unprovisioned) Matter device initially starts in Commissionable Mode. In this state, it does not yet belong to any Fabric and provides only the discovery services required for commissioning.

The device deliberately advertises only a limited set of information. In particular, it does not disclose cryptographic keys or complete device configurations. Instead, a Commissioner identifies suitable devices using standardized discovery mechanisms.

For the actual onboarding process, the Commissioner additionally requires the Onboarding Payload, which is typically provided via a QR code or a numeric setup code outside the actual communication channel (out-of-band).

The QR code contains, among other things:

• Vendor ID,
• Product ID,
• Device Discriminator,
• Setup PIN Code, and
• supported commissioning transports.

Only with this information can the Commissioner uniquely identify the desired device and start the commissioning process.

Discovery of a Commissionable Device

With Matter over Ethernet or Wi-Fi, device discovery is performed using DNS Service Discovery (DNS-SD) based on mDNS.

The process can be summarized as follows:

The mDNS advertisement includes, among other things:

• the IPv6 address,
• the Device Discriminator,
• supported commissioning methods, and
• additional discovery parameters.

The Device Discriminator is used solely for pre-selecting suitable devices. Actual authentication takes place only during the subsequent cryptographic connection establishment.

Establishing the Secure Connection

After successful discovery, the Commissioner first establishes a temporary encrypted session using PASE (Password Authenticated Session Establishment). This is based on the Setup PIN Code contained in the onboarding payload.

This secure connection is then used for:

• device authentication,
• adding the device to the Fabric,
• exchanging operational keys and certificates, and
• configuring access control.

After successful commissioning, the device has a permanent identity within the Fabric. For normal communication, Matter subsequently uses CASE (Certificate Authenticated Session Establishment), in which communication partners authenticate each other using their operational certificates.

After Commissioning

Once commissioning has been completed, the device typically leaves Commissionable Mode. All further communication takes place exclusively through regular Matter sessions within the Fabric.

Already commissioned devices continue to be discovered using DNS-SD and mDNS. In this case, the discovery mechanism serves only to locate reachable participants; authentication and authorization are performed independently through the existing cryptographic relationships within the respective Fabric.

Matter over Thread

Matter is largely independent of the underlying networking technology. In addition to Ethernet and Wi-Fi, the standard also supports Thread as a transport network. Thread was developed for low-power IoT devices and combines IPv6 communication with a self-organizing mesh network based on IEEE 802.15.4.

Although Thread uses the same 2.4 GHz frequency band as Wi-Fi, it is an entirely different wireless standard. The two technologies are interoperable neither at the MAC layer nor at the PHY layer.

Thread Protocol Stack

Thread provides a native IPv6 network. Data transmission takes place over IEEE 802.15.4, while 6LoWPAN adapts IPv6 to the comparatively small wireless frames.

The simplified protocol stack is as follows:

From Matter’s perspective, a Thread network is fundamentally no different from an Ethernet or Wi-Fi network: the application communicates exclusively over IPv6 and UDP. Routing, mesh formation, and wireless communication are handled entirely by Thread.

Structure of a Thread Network

A Thread network consists of routers and end devices. Routers forward IPv6 packets within the mesh and collectively form the mesh topology.

Unlike traditional star topologies, there is no central wireless base station. If a router fails, traffic can automatically be rerouted through other routers.

Battery-powered devices frequently operate as Sleepy End Devices (SEDs). They do not permanently participate in routing but communicate exclusively with their respective parent router and can power down their radio hardware between communication events.

Thread Border Router

A Thread network forms its own Layer 2 domain. To communicate with an Ethernet or Wi-Fi network, a Thread Border Router is required.

The Border Router acts as an IPv6 router between two different Layer 2 networks. It does not translate Matter or Thread into other protocols. Instead, IPv6 packets are forwarded unchanged between the two networks.

In addition, the Border Router performs Thread-specific infrastructure tasks such as:

• providing the IPv6 prefix,
• sending Router Advertisements,
• DNS and service proxying, and
• managing the Thread network.

From Matter’s perspective, there is therefore no difference between a device on Ethernet and a device on a Thread network—both communicate over IPv6.

Thread Integration During Commissioning

A factory-new Matter-over-Thread device contains the necessary radio hardware but is not yet aware of the local Thread network. In particular, it lacks:

• the Thread Network Key,
• the Active Operational Dataset,
• channel and PAN configuration, and
• additional parameters required to join the network.

Without this information, the device cannot join the Thread network and therefore cannot establish IPv6 connectivity with the Border Router.

For this reason, joining the Thread network is part of the commissioning process.

Bluetooth Low Energy as the Commissioning Transport

For Matter over Thread, the Thread network parameters are typically transferred via Bluetooth Low Energy (BLE) as a temporary transport channel, since the same radio hardware can later be used for normal Thread communication.

The simplified sequence is as follows:

During the BLE connection, the Commissioner transfers both the Thread network parameters and the information required for Matter commissioning.

The Thread configuration is described by the Active Operational Dataset. Among other things, it contains the Network Key, the PAN ID, the radio channel in use, and additional network-specific parameters.

How the Commissioner obtains this dataset is not defined by the Matter specification. In practice, the information often comes from the Thread Border Router or from the integrated Thread management component of the respective ecosystem. If the Commissioner and the Border Router use different implementations, the Operational Dataset may have to be exported and imported manually.

Communication After Commissioning

Once the device has successfully joined the network, the BLE connection is no longer required. All communication subsequently takes place over IPv6 within the Thread network.

BLE is used exclusively for the initial network onboarding. Normal operation relies entirely on the native IPv6 communication path through the Thread network and the Border Router.

Building Your Own Matter Test Network with Open-Source Software

No proprietary infrastructure is required for experimenting with Matter. A complete test environment can be built entirely from open-source components.

For example, Matter.js can serve as the Matter controller, while OpenThread Border Router (OTBR) provides connectivity to a Thread network. Both components can be run easily on a Raspberry Pi or comparable hardware.

For Matter over Thread, an additional IEEE 802.15.4 radio adapter is required, since Raspberry Pi systems include Bluetooth and Wi-Fi but do not provide an IEEE 802.15.4 radio interface. In practice, USB dongles or USB/UART-connected radio modules based on chips such as the Nordic nRF52840 or Silicon Labs EFR32 are commonly used.

The Raspberry Pi’s Bluetooth interface can be used during commissioning for the temporary BLE connection to the Matter device. After commissioning has been completed, communication takes place exclusively over Thread, Ethernet, or Wi-Fi.

The resulting architecture is shown schematically below:

By separating the Matter Controller from the Thread Border Router, the architecture of different vendor ecosystems can be reproduced realistically. Likewise, both functions can be distributed across different systems, since Matter requires only IP connectivity between the participating components.

The practical setup of such a test environment, the installation of the required software, and the commissioning of the first devices are described in the next part of this article series.

Add a comment