Courtesy: NXP Semiconductors
Since the release of Matter in 2022, there has been rapid development and device additions as well as adoption by product manufacturers and consumers. Matter brings unification to the smart home by providing a standardized common language in which smart devices can communicate with each other.
Matter specification defines roles and responsibilities for many classes of devices that can operate in a fabric, and this new terminology can be a source of confusion for many customers approaching Matter for the first time. This article provides a high-level definition of each of these Matter device roles and terminologies.
Matter Fabric
A Matter fabric is a collection of devices that communicate with each other inside a single application-layer security domain. A single Matter fabric may support devices that use multiple different networking technologies, with infrastructure to make these technologies visible to each other at the IPv6 networking layer (for example, a Wi-Fi access point enables Ethernet-connected devices and Wi-Fi-connected devices to communicate with each other at the IP networking layer by bridging these two different networking technologies). So, at the application layer, the fabric is the security domain that enables a set of devices that may be using different networking technologies to communicate with each other using the Matter application layer language.
Matter Roles in the Fabric
The Matter topology figure below shows an example instance of Matter with a representative Matter fabric outlining the various device roles that can exist in a fabric. Each role will be explained in further detail.
Commissioner
A Matter commissioner is the entity that adds a new Matter device into a fabric. A Matter commissioner may be an application on a smartphone or it may be a role fulfilled by a different device (for example, a smart speaker). Commissioners add devices into a Matter fabric by first verifying the authenticity of a new device, then assigning network credentials to the device.
Administrator
A Matter administrator is a device that performs the following functions:
- Setting up the rules about which devices are able to communicate with each other. For example, if a particular light switch is meant to turn on a particular light bulb, then the administrator is responsible for setting up this binding based on a prompt from the end user
- Configuring scenes and automations
- In a Matter fabric, there may be more than one administrator. If a fabric contains multiple administrators, then synchronization of the network metadata between the controllers (that is, information about which devices are bonded together) is outside the scope of the current Matter specification
A Matter administrator is not required to support multiple network interfaces, but it may support multiple IPv6 network interfaces and send/receive Matter messages on all interfaces. A smartphone, for example, can act as a Matter administrator and support Matter over Wi-Fi only.
Controller
A controller is not a role that is formally defined in the Matter specification—the term ‘controller’ is used to refer to any combination of the commissioner role, administrator role, and client functionality on the fabric. Clients on the Matter fabric are able to communicate with any device on the network, and a controller generally acts as a universal client, able to send/receive messages from all devices on the fabric.
Bridge
A Matter bridge is a class of end device that is designed to translate messages from the Matter fabric to/from a non-Matter domain. Bridge devices work as follows:
- Scan the non-Matter domain to discover devices
- Create a virtual representation of the non-Matter devices on the Matter fabric
- Act as the destination node for messages sent/received on the Matter fabric that will be translated to the non-Matter network
- Perform full protocol translation of the Matter messages to the corresponding non-Matter messages
- Forward the corresponding non-Matter message to the appropriate device on the non-Matter side of the network.
From an implementation standpoint, the bridge device probes the non-Matter domain to discover all devices and associated capabilities, then maps these devices and associated capabilities to the Matter fabric by using dynamic endpoints. For each device that is discovered on the non-Matter domain, the bridge device will instantiate a new endpoint at run-time on the Matter fabric and create a mapping of all the device functions and capabilities from the non-Matter domain into the Matter fabric by instantiating all of the corresponding Matter clusters on this new endpoint.
For example, if a Matter bridge device is implementing a Matter to Zigbee bridge, and there is one device, such as a light bulb, on the Zigbee side commissioned into the network, then the bridge will instantiate a new endpoint on its Matter network interface, and then instantiate all of the corresponding Matter clusters needed to represent the functionality of the device on the Zigbee network.
Once the Matter bridge has completed this process, then the bridge device will work as follows:
- If a Matter light switch wishes to send a message to the Zigbee light bulb, then it will send an on/off message to the bridge device
- The destination of this message will be the endpoint on the Matter bridge that corresponds to the Zigbee light bulb
- The Matter bridge will receive this message—destined for one of its endpoints—and translate the received Matter message into the corresponding Zigbee message
- The Matter bridge will then transmit the Zigbee message to the Zigbee light bulb to complete the state change request that was initially requested by the Matter light switch
- The non-Matter functionality being mapped into the Matter fabric must be supported by Matter with appropriate cluster definitions. For example, Matter does not support clusters for electronic shelf labels, so it would not be possible to create a Matter bridge for electronic shelf labels that exposes all of the features/functionality from the non-Matter network for this product
- The Matter Bridge is only able to expose as many virtual devices as it has endpoints due to memory constraints
Gateway
A gateway is not a Matter device role, but rather a networking-level device role. A gateway is generally the device that provides LAN access to the internet, and acts as the DNS server, DHCP server, as well as performing other networking-level functions.
A gateway may be a Matter controller, bridge or end device. The gateway functionality at the network layer is independent of the Matter device role at the application layer.
Border Router
A border router is a networking-level device role. It is a device role defined in the Thread specification that supports a Thread network interface alongside some other IP-enabled network interface and routes packets between these network interfaces.
From an implementation standpoint, the way that the border router works is that it will perform the following operations for the Thread network:
- The border router will provide the IPv6 address prefix for the realm’s local or globally scoped IPv6 network. This may be generated by the border router itself or received upstream from a gateway on the infrastructure interface (that is, the non-Thread network interface)
- Use unicast DNS to discover the services that are available for each node in the Thread network via SRP
- Cache these services in a database in memory
- Whenever an mDNS request is received on the infrastructure interface, the border router will respond with the cached services for the corresponding Thread end device
- Whenever a message is received on either the Thread or infrastructure interface, the border router will route the packet to the appropriate destination node after performing some basic firewall functionality
A Thread network may support multiple border routers, enabling multiple different routes for a message to reach the infrastructure network.
A border router may be a Matter controller, bridge, or end device—the functionality at the network layer is independent of the Matter device role at the application layer.
“Matter Hub” Functional Blocks
The above terminology outlining the various roles involved in a Matter fabric are sometimes used interchangeably, but in reality, they are very distinct. These roles can be combined into a single device that is used to manage multiple networks and provide multiple capabilities. Using a generic term ‘’Matter Hub” to describe these types of devices, the diagram below shows how the functional blocks fit into an overall implementation.
End Nodes
A Matter end node is a device that supports one or more IPv6 network interfaces upon which Matter messages can be sent or received. An end node can be either a client device or a server device. The distinction between client and server is whether state information is stored on the device or not. Generally, if a device stores state information that can be read or written using commands on the Matter fabric, then the device is a server. An example server device would be a light bulb, where the state of the LEDs in the bulb (brightness, color temperature, hue/saturation, etc.) can be read or written using commands on the Matter fabric. If a device does not store any state information and instead uses commands on the Matter fabric to change the state of a remote device, then the device is a client. An example client device would be a light switch, where the switch uses commands sent on the Matter fabric to turn on/off a light bulb.
It is possible to build composite Matter end devices that support both client and server functionality by instantiating the corresponding client or server clusters to the endpoints on the Matter device. For example, it is possible to create a Matter end device that is a light switch (supporting the lighting client functionality) and an occupancy sensor (supporting the occupancy sensor server functionality) by instantiating both sets of clusters on the device.
Sleepy End Nodes
A sleepy end node is not a Matter device role—it is another networking level device role specific to Thread networks. A sleepy end node is a device on a Thread network that spends the majority of its time in a low-power state with the radio receiver tuned off. Given that a sleepy end node does not have 100% receiver duty cycle, it must find a parent node (a proxy that will queue messages destined for the sleepy end node), so it may turn off its radio to enter a low-power state to conserve power. Sleepy end nodes are typically battery-powered, so reducing power consumption is of the utmost importance.
One interesting characteristic of sleepy end nodes is that the communication latency is asymmetric. Sleepy end nodes can send messages with very low latency but receive messages with very high latency. This occurs because sending a message is typically an interrupt-driven process, where some external signal triggers the sleepy end node to transmit a message (for example, in a battery-powered light switch, the trigger would be a user actuating the switch). Given the fundamental asynchronous behavior of a Thread network, the message can be transmitted with limited delay. Conversely, to receive a message as a sleepy end node, the latency is typically very high because the sleepy end node is in a low-power state with the radio receiver turned off. The sleepy end nodes will wake up periodically to query the network for messages that are destined for it (by polling the proxy/parent node on the network that is queueing messages on behalf of the sleepy end node), and this wake-up interval is typically measured in the range of seconds or minutes. As a result of this communication latency asymmetry, sleepy end nodes are typically used to implement Matter client devices rather than Matter server devices. For example, a battery-powered light switch (that is, a lighting control client) can send messages to a light bulb (that is, a lighting control server) with very low latency, providing a good user experience for a lighting control system. However, when messages must be sent to the battery-powered light switch, the latency will be higher (for example, to initiate a firmware update to the light switch), but this does not generally negatively impact user experience.
Conclusion
The new terminology introduced and used by the Matter specification can result in confusion as there are many terms that are used interchangeably but have canonically different meanings. This explanation of the common device roles on a Matter fabric—and the underlying networking technologies upon which Matter is built—clarifies the definitions of these terms. With a deeper understanding of the language used to describe Matter fabrics, product designers are now better armed to define and deliver their next generation of devices that rely on Matter.
