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.
Matter Topology. For a better experience, download the
block diagram.
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 would 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 a 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 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.
The RW612 Wi-Fi 6 Tri-Radio Wireless MCU provides a single-chip border router solution.
Learn more about the RW612.
“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.
“Matter Hub” Functional Blocks.For a better experience, download the
block diagram.
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 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 node 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.
