What is Matter?

The connectedhomeip project, home of the open-source Matter SDK, describes Matter as a unified, open-source application-layer connectivity standard built on Internet Protocol. A working group inside the Connectivity Standards Alliance (CSA) develops it, and the project calls it royalty-free.

Google’s Matter primer places the core protocol in the top three layers of the OSI model, so it can run over any IPv6 transport. The CSA lists the ones it supports today: Wi-Fi, Thread and Ethernet for connecting devices, and Bluetooth Low Energy for setting them up. Google notes that Bluetooth LE does not carry IP, so Matter treats it as an onboarding technology rather than a way to operate devices. The Thread Group describes the split this way: Wi-Fi for high-bandwidth devices such as security cameras, and Thread for low-bandwidth devices such as door locks and motion sensors.

Matter therefore sits above the network, not beside it. The BLE mesh vs Thread vs Matter page compares the layers side by side.

What Matter standardises is how devices describe themselves and how others act on them. Google’s primer sets out the hierarchy:

• A node is one addressable device on the network, and all Matter communication starts and ends at a node.
• A node has endpoints, each a feature set, such as a light on one endpoint and a motion sensor on another. Endpoint 0 is reserved for utility functions such as discovery, diagnostics and software update.
• Each endpoint holds clusters, groups of related functionality such as on/off or level control.
• Clusters contain attributes (current state), commands (actions, like a remote procedure call) and events (a record of past state changes).

A device type, such as Dimmable Light or Door Lock, is a set of mandatory and optional clusters, so any controller that understands the device type knows what a product can do. Relationships between nodes are horizontal: a node can be a server for one cluster and a client for another. The CSA notes that this data model borrows heavily from the Zigbee Cluster Library, covered in How does Zigbee work?.

The SDK’s documentation describes the layers beneath it: an interaction model for reads, writes and commands, action framing into a packed binary format, a security layer that encrypts and signs the payload, message framing and routing, and finally IP transport.

Adding a device is called commissioning, and it is where a device gets its credentials. The CSA describes setup with a QR code or numeric code, over Bluetooth LE. Google’s primer lists the steps behind it:

1. The new device advertises that it is ready, and the commissioner, such as a phone app or hub, uses the setup passcode to establish a secure session (PASE).
2. The commissioner reads the device’s descriptors and basic information, including vendor and product IDs.
3. Attestation. The device presents a Device Attestation Certificate and proves it holds the matching private key, which shows it is a genuine, certified Matter product.
4. The device generates its own operational key pair and sends a certificate signing request. The ecosystem’s certificate authority issues a Node Operational Certificate, and the private key never leaves the device.
5. For Wi-Fi and Thread devices, the commissioner provides network credentials. It then finds the device on the operational network with DNS-SD, opens a certificate-based session (CASE) and completes commissioning.

The set of nodes that share a root certificate authority, and so trust each other, is a fabric. Google’s primer explains that each fabric has a 64-bit Fabric ID and each node in it a 64-bit Node ID.

A node can be commissioned onto more than one fabric. This is multi-admin: one light can belong to its maker’s fabric and to a smart home platform’s fabric at once, each fabric with its own credentials, while the device’s data model is shared. The CSA describes this as sharing a device across platforms and choosing which apps and platforms can access it. One of the project’s stated goals is that no single entity serves as a single point of failure for the root of trust.

The CSA says adding Matter to a product lets it use a local connection for greater reliability and responsiveness, and that makers can still keep a cloud connection for remote control.

Matter does not cover every radio. The CSA states there is no native interoperability between Matter and Zigbee devices, even though Thread and Zigbee share the IEEE 802.15.4 radio. Instead, Matter defines bridges: Google’s primer describes a bridge as a member of both a Matter network and another network, such as Zigbee, Bluetooth Mesh or Z-Wave, which lets those devices be operated as if they were Matter devices.

Matter also inherits the rules of its transports. The CSA requires Matter products to be certified for the underlying technologies they use, such as Wi-Fi or Thread, as their own governing organisations require.