Matter’s protocol stack is a six-layer architecture built on IPv6 that uses UDP with a custom Message Reliable Protocol (MRP) for transport, AES-CCM for encryption, and a structured Data Model where physical devices (Nodes) contain Endpoints, which host Clusters of Attributes and Commands. This layered design enables any Matter controller to discover and interact with any Matter device regardless of manufacturer or transport (Thread, Wi-Fi, or Ethernet).
By the end of this section, you will be able to:
Matter’s protocol architecture organizes functionality into six distinct layers, each with specific responsibilities:
Link Layer - Physical transmission using Thread (802.15.4 mesh), Wi-Fi (802.11), or Ethernet. This layer is swappable – a Matter device can switch transports without changing upper layers.
Network Layer (IPv6) - Provides addressing and routing. Every Matter device has an IPv6 address, enabling direct peer-to-peer communication without proprietary bridges. Thread uses 6LoWPAN for IPv6 over 802.15.4.
Transport Layer (UDP + MRP) - Uses UDP for low overhead, but adds Matter Reliable Protocol (MRP) for guaranteed delivery. MRP implements application-layer acknowledgments and retransmission without TCP’s connection overhead.
Message Layer - Handles message framing, fragmentation/reassembly for large payloads, and duplicate detection. Manages retransmission timers and exponential backoff.
Security Layer (AES-CCM + CASE/PASE) - All messages are encrypted with AES-128-CCM after session establishment. PASE (Passcode Authenticated Session Establishment) handles initial commissioning; CASE (Certificate Authenticated Session Establishment) handles ongoing operation.
Application Layer - Contains the Data Model (how devices describe themselves) and Interaction Model (how controllers access device capabilities). This layer is transport-agnostic.
This separation of concerns enables true interoperability: a controller can use the same Application Layer APIs whether the device uses Thread, Wi-Fi, or Ethernet.
“Matter’s protocol stack has six layers, like a six-story building!” said Max the Microcontroller, drawing on the whiteboard. “The ground floor is the transport – Thread, Wi-Fi, or Ethernet. Second floor is IPv6 addressing. Third is UDP for sending packets. Fourth is MRP – a special reliability layer that makes sure messages actually arrive.”
Sammy the Sensor counted along. “What about floors five and six?” Max continued, “Fifth floor is encryption – AES-CCM wraps every message in a secure envelope. And the top floor is the application layer with the Data Model, where devices describe themselves using Nodes, Endpoints, and Clusters.”
“I love the Endpoint system!” said Lila the LED. “A smart power strip might have Endpoint 0 for device-wide info, and then Endpoints 1 through 4 for each individual outlet. Each Endpoint has its own set of Clusters – On/Off, Power Measurement, and so on. It is like each outlet is its own mini-device.”
Bella the Battery appreciated the efficiency. “And since Matter uses UDP instead of TCP, there is less overhead and less energy wasted on connection management. The MRP layer handles reliability with lightweight acknowledgments, so I do not drain my power on heavy protocols!”
Before diving into this chapter, you should be familiar with:
Architecture Deep Dives:
Device Implementation:
Transport:
Think of a Matter device like a well-organized office building:
When you ask Alexa to “dim the living room light to 50%,” here’s what happens: 1. Alexa identifies the Node (your smart light) 2. Selects the correct Endpoint (main light, not nightlight) 3. Finds the Level Control Cluster 4. Sends a MoveToLevel Command with value 50% 5. The cluster updates its CurrentLevel Attribute to 50% 6. The light physically dims to 50%
This diagram focuses on Matter’s security mechanisms and trust model.
| Layer | Component | Responsibility |
|---|---|---|
| Application | Data Model | Define device capabilities (what it can do) |
| Application | Interaction Model | Define how to access capabilities (how to control it) |
| Security | CASE/PASE | Establish secure sessions |
| Security | AES-CCM | Encrypt and authenticate messages |
| Message | Framing | Structure messages with headers and payloads |
| Transport | MRP | Ensure reliable delivery over UDP |
| Network | IPv6 | Route packets between nodes |
| Link | Thread/Wi-Fi/Eth | Physical transmission |
The Message Reliable Protocol (MRP) provides reliable delivery over UDP:
Why UDP instead of TCP?
| Consideration | UDP + MRP | TCP |
|---|---|---|
| Latency | Lower (no connection setup) | Higher (3-way handshake) |
| Power | Lower (simpler stack) | Higher (state maintenance) |
| Sleepy devices | Better (stateless) | Problematic (connection timeouts) |
| Multicast | Supported | Not supported |
Matter operates over three transport networks:
| Transport | Standard | Range | Power | Best For |
|---|---|---|---|---|
| Thread | 802.15.4 + 6LoWPAN | 10-30m | Very low | Battery sensors, locks |
| Wi-Fi | 802.11 | 30-50m | High | Cameras, displays |
| Ethernet | 802.3 | Wired | Low | Border routers, hubs |
The Matter Data Model defines how device capabilities are structured and accessed.
A Node is a uniquely addressable Matter entity—typically a physical device.
Node Properties:
Node Examples: | Physical Device | Matter Node | |—————–|————-| | Smart light bulb | Single node, 1-2 endpoints | | Smart power strip (4 outlets) | Single node, 4 endpoints | | Thread Border Router | Single node, bridge endpoint |
An Endpoint is a logical container for related functionality within a node.
Standard Endpoints: | Endpoint | Purpose | Required Clusters | |———-|———|——————-| | Endpoint 0 | Root/Utility | Basic Information, Network Commissioning | | Endpoint 1+ | Application functions | Device-specific clusters |
Example: Smart Light with Nightlight
A Cluster is a collection of related attributes and commands representing a specific capability.
Cluster Types:
| Category | Cluster Examples | Purpose |
|---|---|---|
| Utility | Basic Information, Binding | Device management |
| Lighting | On/Off, Level Control, Color Control | Light operations |
| HVAC | Thermostat, Fan Control | Climate control |
| Closure | Door Lock, Window Covering | Access and privacy |
| Sensors | Temperature, Humidity, Occupancy | Environmental data |
Cluster Structure:
Attributes are named, typed data values within a cluster:
| Property | Description | Example |
|---|---|---|
| ID | Unique within cluster | 0x0000 (OnOff) |
| Type | Data type | Boolean, uint8, string |
| Access | Read/Write permissions | R, RW |
| Quality | Nullable, Reportable, Persistent | Reportable |
Common Attribute Types:
Boolean - true/false (On/Off state)uint8 - 0-255 (brightness level)int16 - -32768 to 32767 (temperature x 100)string - Variable length (device name)struct - Complex objects (color XY)list - Arrays (supported features)Commands are actions that can be invoked on a cluster:
| Property | Description |
|---|---|
| ID | Unique command identifier within cluster |
| Direction | Client-to-Server or Server-to-Client |
| Fields | Input parameters |
| Response | Expected response command |
Example: MoveToLevel Command
Command: MoveToLevel (0x00)
Direction: Client -> Server
Fields:
- Level (uint8): Target brightness 0-254
- TransitionTime (uint16): Transition time in tenths of seconds
- OptionsMask (uint8): Override options
- OptionsOverride (uint8): Override values
Response: None (status only)Scenario: You are designing a Matter-compatible smart light bulb with dimming and color temperature control. Define the endpoint structure, required clusters, and attribute implementation following Matter specification.
Given:
Steps:
Define endpoint structure:
Implement On/Off Cluster (0x0006):
Implement Level Control Cluster (0x0008):
Implement Color Control Cluster (0x0300) for Color Temperature:
Result: Smart light implements Matter device type 0x010C with full dimming (0-254) and color temperature (2700K-6500K) support. Endpoint 0 handles commissioning and network management. Endpoint 1 provides application-level light control through On/Off, Level Control, and Color Control clusters.
Key Insight: Matter’s cluster-based architecture enables interoperability by standardizing behavior. Any Matter controller (Apple, Google, Amazon) can control this light identically because the On/Off, Level Control, and Color Control clusters have standardized attribute types, command formats, and expected behaviors defined in the Matter specification.
Objective: Use the Matter SDK’s chip-tool to inspect a real Matter device’s endpoint and cluster structure, understanding the hierarchical Data Model in practice.
Prerequisites:
Exercise Steps:
Discover All Endpoints:
chip-tool descriptor read parts-list 1 0parts-list attribute returns all endpoints (e.g., [1, 2])Read Device Type on Endpoint 1:
chip-tool descriptor read device-type-list 1 10x0100 = On/Off Light, 0x010C = Color Temperature Light)List All Clusters on Endpoint 1:
chip-tool descriptor read server-list 1 1[0x0006, 0x0008, 0x0300] = On/Off, Level Control, Color Control)Read Cluster Attributes:
chip-tool levelcontrol read current-level 1 1
chip-tool levelcontrol read min-level 1 1
chip-tool levelcontrol read max-level 1 1Inspect Cluster Metadata:
chip-tool levelcontrol read cluster-revision 1 1
chip-tool levelcontrol read feature-map 1 1What to Observe:
Challenge: Find a multi-endpoint device (like a smart plug with 4 outlets) and map all endpoints to clusters. Does each outlet have its own On/Off cluster on separate endpoints?
Developers often overlook how much of a Matter packet is consumed by protocol overhead. Understanding the message size budget prevents surprises when payload doesn’t fit.
Matter over Thread (worst case for payload):
| Layer | Overhead | Remaining |
|---|---|---|
| IEEE 802.15.4 frame | 127 bytes total | 127 bytes |
| MAC header + FCS | 25 bytes | 102 bytes |
| 6LoWPAN + IPv6 (compressed) | 7 bytes | 95 bytes |
| UDP header (compressed) | 4 bytes | 91 bytes |
| MRP header | 6 bytes | 85 bytes |
| Matter message header | 8 bytes | 77 bytes |
| Matter security (AES-CCM tag) | 16 bytes | 61 bytes |
| Matter protocol header | 4 bytes | 57 bytes available |
The available payload for a single unfragmented Matter-over-Thread packet:
\[\text{Payload} = \text{Frame Size} - \sum \text{Overheads}\]
Worked example: Starting with 127-byte 802.15.4 frame:
\[127 - 25 - 7 - 4 - 6 - 8 - 16 - 4 = 57 \text{ bytes}\]
This means a single attribute read response (TLV-encoded) for a thermostat reporting 5 attributes (temperature, humidity, setpoint, mode, fan state) at ~10 bytes each = 50 bytes fits without fragmentation.
But a bulk read of 10 attributes = ~100 bytes requires 6LoWPAN fragmentation into 2 frames. With 5% per-frame loss, success drops from 95% (1 frame) to \((0.95)^2 = 90.25\%\) (2 frames).
Design rule: Keep attribute reports under 50 bytes for reliable single-frame delivery over Thread.
With only 57 bytes per unfragmented packet, a single thermostat attribute report (temperature, humidity, setpoint, mode, fan state) easily fits. But reading all attributes of a complex device in one request may require 6LoWPAN fragmentation, which increases latency and power consumption.
Design Matter-over-Thread devices to keep individual attribute reports under 50 bytes. For bulk reads (e.g., commissioning), expect fragmentation and plan for 200-500ms latency. Matter-over-Wi-Fi has no practical payload limit since Wi-Fi MTU is 1500 bytes.
| Concept | Related To | Relationship |
|---|---|---|
| Node | Endpoint | A Node (physical device) contains one or more Endpoints |
| Endpoint | Cluster | Each Endpoint hosts multiple Clusters representing capabilities |
| Cluster | Attribute/Command | Clusters contain Attributes (data) and Commands (actions) |
| MRP | UDP | MRP adds reliability (ACKs, retransmit) to unreliable UDP |
| 6LoWPAN | IPv6 | 6LoWPAN compresses IPv6 headers for efficient Thread transmission |
| Device Type | Required Clusters | Each Device Type mandates specific clusters (e.g., lights need On/Off) |
Matter certification requires all mandatory attributes and commands of required clusters to be implemented. Omitting even one mandatory feature will cause certification failure. Read device type specifications carefully and implement all mandatory items.
Matter’s security operates at the application layer on top of the transport. Matter over Thread still needs IEEE 802.15.4 link security enabled. Matter security and transport security are complementary, not redundant.
Matter prohibits certain cluster combinations on the same endpoint and requires descriptor clusters to correctly enumerate composed device types. Violating composition rules will fail commissioning validation.
Matter’s protocol stack provides end-to-end interoperability from physical transport through application data models
The Data Model hierarchy is: Node (device) -> Endpoints (functional units) -> Clusters (capabilities) -> Attributes/Commands (data/actions)
Endpoint 0 is mandatory on every device for utility functions (Basic Info, Network Commissioning, Administrator Commissioning)
Clusters are reusable building blocks - the same On/Off cluster works identically on lights, plugs, fans, and any on/off device
MRP (Message Reliable Protocol) provides reliable delivery over UDP with acknowledgments, retransmission, and deduplication
Transport flexibility - Matter works over Thread (low-power mesh), Wi-Fi (high bandwidth), and Ethernet (wired reliability)
::
::
| Chapter | Focus |
|---|---|
| Matter Interactions and Commissioning | How controllers read, write, subscribe, and invoke commands on clusters |
| Matter Fabric and Security | Multi-admin fabric management, CASE/PASE session establishment, and encryption |
| Matter Device Types and Clusters | Complete library of standardized device types and their required clusters |
| Matter Implementation | SDKs, development tools, and building Matter-compatible firmware |
| Thread Network Architecture | Thread mesh networking fundamentals – Matter’s primary low-power transport |