If you are curious how the Matter smart home specification works, then keep reading to learn about the Matter software stack, underlying technologies, data and interaction models and Matter device onboarding.
For an introduction to the Matter smart home standard, check out part one of this series covering why Matter is necessary and the basic steps in building a Matter device.
Contents
Matter Software Stack
Matter’s main goal is to provide a “universal IPv6-based communication protocol for smart home devices.” Applications built on the Matter stack employ Matter’s Cluster API (equivalency would be HTTPS requests via web browser) to communicate and/or enact Matter device changes. Delving a bit deeper, let’s examine the Matter software stack using the Open Systems Interconnection (OSI) model as our guide.
The essence of the Matter stack falls within OSI layers 5 through 7 (Session, Presentation and Application). For the other OSI layers, the Matter stack emphasizes preexisting protocols. For the transport and network layers, Matter relies on TCP or Message Reliability Protocol/UDP — all over IPv6 network protocol. (Exception: For device commissioning, Matter uses the Bluetooth Transport Protocol (BTP) and Bluetooth Low Energy (GATT) networking protocol. Device commissioning is discussed later). Finally, Matter utilizes a diverse set of media layer (data link layer and physical layer) protocols — Wi-Fi, Ethernet, Thread — to transmit and receive data.
Figure 1. The Matter Software Stack
Figure 2. Matter Connectivity
As stated earlier, the crux of the Matter architecture is defined in OSI layers 5-7 ( hereby called the Matter application layer). The Matter application layer is broken down further into the following components:
- Application layer: Defines the business logic for your unique spin on the end product.
- Data model layer: Describes the supported remote operations of a Matter node (e.g., a smart video doorbell is on/off, LED or camera functions). The application layer interacts with the data structures defined in this layer, which reflect the state of the underlying device.
- Interaction model layer: Defines the set of interactions allowed between client and server devices and how to exchange data between nodes through interactions. These interactions are performed on the data model layer-defined elements.
- Action framing layer: Transforms messages that are part of interactions into serialized binary packets.
- Security layer: Encrypts the encoded frames from the action framing layer and appends them with a message authentication code.
- Message framing and routing layer: Composes the payload with required and optional header fields that specify the properties of the message and logical routing information.
- Transport and IP framing layer: Manages the payload transmission through the IP network to the peer device. This layer can use either TCP or MRP over UDP. During the commissioning process, Bluetooth Transport Protocol over BLE can be used instead of this layer.
Figure 3. Matter Application Layer
As we delve deeper into how Matter works, let’s more closely examine the Matter device data model to understand how devices communicate within this groundbreaking framework.
Matter Device Data Model
All Matter devices are composed of nodes, or uniquely identifiable and addressable resources in a network, that the user can perceive as functionally whole. A node is an entirely complete Matter application functionality.
Matter network communication originates and terminates at a node, implying Matter devices can have multiple nodes (and they often do!). Nodes are composed of a collection of endpoints. And nodes can have several endpoints — each creating an instance of the same functionality. Finally, each endpoint encapsulates a feature set. Note that every Matter node must have endpoint 0, which is reserved for Matter utility clusters.
Figure 4. Matter Device Data Model
In the example of a smart video doorbell, an endpoint may pertain to a lighting functionality, another to motion detection and still another to a utility function, such as over-the-air (OTA) updates.
The backbone of all of this is the cluster. Endpoints are composed of one or more clusters. A cluster groups specific functionality — such as level control of on/off — on a dimmable light endpoint. There are two types of clusters:
- Server is stateful and responsible for holding values for Attributes, Commands and Events.
- Client is stateless and initiates interactions with remote Server Clusters.
Clusters are composed of one or more of the following: attributes, commands and/or events. Attributes are states held by the node (e.g., current state). Commands are actions that may be performed – equivalent to a remote procedure call. Events are a record of past state transitions, including a monotonically increasing counter, a timestamp and priority.
Matter device types are a collection of mandatory and optional clusters on one or more endpoints that define top-level attributes of a physical device. If a node implements a DeviceType, then it must include a set of clusters on one or more endpoints to define a distinct, cohesive behavior. These are outlined in the Matter Device Library specification.
Figure 5. Matter Device Data Model Clusters
To further understand how Matter works, let’s dive into how nodes interact with each other.
Matter Device Interaction Model
The interaction model defines a node’s data model relationship with the data model of other nodes. Nodes have a horizontal relationship — reading and subscribing to attributes and events, writing to attributes and invoking commands. Confusingly, the response to a command is also a command.
Figure 6. Matter Device Interaction Model
Interaction is when a node establishes an encrypted communication sequence with another node. Interactions may be composed of one or more transactions, which are composed of one or more actions. Actions are interaction model-level messages between nodes.
Figure 7. Matter Device Interaction Examples
Interaction Examples
In the realm of a smart video doorbell, the Matter controller reads the LockType attribute of the DoorLock cluster (read) and modifies the OperatingMode of the DoorLock cluster (write).
The Matter controller can also harness the UnlockDoor command of the DoorLock Cluster to remotely unlock the door. In this specialized case of timed interaction, two messages must be exchanged before a command is sent (invoke). This sophisticated mechanism helps counter potential attackers from intercepting and replaying the command to unlock the door later.
Finally, the Matter controller can also subscribe to the different attributes of the DoorLock cluster — LockState, for example — enabling the controller to receive notifications whenever the door is unlocked.
A Matter node belongs to at least one “fabric” — a logical set of nodes that communicate with each other — but can belong to multiple fabrics. Nodes in the fabric share the same root of trust and configuration state and are identifiable with a unique 64-bit ID. Nodes can also belong to a “group,” or mechanism for simultaneously addressing and sending messages to several nodes in the same action. Whenever a Matter node interacts with an attribute, event or command, a “path” must be specified in the messaging.
Now that we know how data models interact in the Matter protocol, let’s look at the Matter device onboarding process.
Matter Device Onboarding
With Matter, commissioning is the process of assigning fabric credentials to a new device:
Figure 8. Matter Device Onboarding
During device discovery, the device being commissioned must advertise itself via one of three methods:
- Bluetooth LE: This method is used especially if the node is being added to its first Matter fabric.
- DNS-SD: This method is commonly used if the node is connected to ethernet or is already a member of a Wi-Fi or Thread network (or a member of a fabric).
- Wi-Fi Soft Access Point: This method involves device discovery via an ad-hoc soft access point network. The Network SSID format is MATTER-ddd-vvvv-pppp, where:
-
- ddd = 12-bit discriminator hexadecimal number.
- vvvv = 16-bit vendor ID in hexadecimal format.
- pppp = 16-bit product ID in hexadecimal format.
From there, the commissioner runs the Passcode-Authenticated Session Establishment (PASE) protocol. The PASE protocol establishes the first session between devices participating in commissioning. The session is established with a passcode provided out of band and is known only to the commissioner and the commissionee to derive encryption keys. There can be only one ongoing PASE session at a time.
The onboarding data payload contains:
- 16-bit vendor ID
- 12-bit device discriminator
- 27-bit setup passcode
- 8-bit discovery capabilities bitmask
This onboarding payload is encoded in one of the following ways:
- Manual Pairing Code: Onboarding information is a sequence of digits.
- QR Code: Scan via mobile application (mobile device is commissioner).
- QR Code Payload: Alphanumeric code that is represented visually by a QR Code. This code can be input manually to command line tools.
The commissioner then requests that the commissionee backup its original configuration — a fail-safe if commissioning is unsuccessful. The commissioner reads all the descriptors from the commissionee and the basic information cluster, which includes the vendor ID, product ID, product name and serial number. Next, the commissioner configures the commissionee with regulatory information (i.e., location and country, current UTC time, etc.).
The next step is attestation to determine whether a device has been certified and is a genuine Matter device. Here, the commissioner extracts the device attestation certificate and the product attestation intermediate (PAI) certificate from the commissionee — and then does a challenge request to establish the commissionee’s authenticity.
Then, the commissioner sends a certificate signing request (CSR) to the commissionee, which creates a unique operational key pair that will be used in a certificate-authenticated session establishment. The commissionee returns the resulting CSR information back to the commissioner, which passes the CSR information received to the administrative domain manager to generate a trusted node operational certificate (NOC).
After the commissioner installs the root certificate on the commissionee using the AddTrustedRootCertReq command and the NOC and operational ID using the AddNOC command, the commissionee becomes the new node of the Matter fabric.
In the network provisioning stage, the commissioner configures the operational network on the commissionee. This step is necessary for Thread or Wi-Fi devices but not for ethernet devices that are already connected to the network.
During operational discovery, the newly commissioned node is connected to the network. If the commissionee is a Wi-Fi device, it will use mDNS to discover the device. If the commissionee is a Thread device, then the Thread Border Router will use mDNS for the Thread device. Once the newly commissioned node has been operationally discovered, the commissioner and the node use the CASE protocol to establish secure communication. The CASE protocol validates that the commissioner and the device are in the same logical fabric and can begin exchanging AES-encrypted messages on the fabric.
With a comprehensive understanding of the Matter device onboarding process, you’re better prepared to delve into the practical realm of creating a Matter device.
Connect with Cardinal Peak to Build Your Matter Device
At Cardinal Peak, we provide Matter-compatible smart home product design. If you’re seeking an expert product design and development firm to ensure your smart home devices will work seamlessly together — today and tomorrow — let our experts know how we can bring your vision to life.