Chapters

34 Matter Protocol Stack

zigbee-thread
matter
protocol-stack
data-model

Matter interoperability depends on two connected review surfaces: the protocol stack that carries protected messages, and the data model that names what those messages mean. A useful review does not stop at saying that Matter is IP-based or cluster-based. It checks the transport boundary, session state, message reliability, interaction path, endpoint structure, cluster support, attribute and command behavior, and the evidence that proves a controller will see the same device model another controller sees.

This chapter reviews Matter protocol stack and data-model evidence for advanced learners. It focuses on transport independence, IPv6 reachability, message and exchange behavior, MRP reliability, secure sessions, the interaction model, the data-model hierarchy, endpoint-cluster conformance, and bounded approval decisions.

34.1 Start With the Device Experience

Follow One Action Through the Whole Stack

Picture a tenant who adds a new door sensor and expects a hall light from another maker to react. The phone says both devices joined, but the light stays dark after the door opens. The product owner must find which layer accepted the device and which layer failed the action.

Write one user action as a trace. Name the device, its shared home, the target function, the person allowed to act, and the result the user should see. Then follow join, trust, session, request, device path, reply, and visible outcome. Keep the same time and device identity across each record.

Test a wrong device path, a missing feature, an expired session, a lost reply, a repeated request, and a sleeping device that wakes late. Check that a rejected action is clear and safe. Being able to reach a device does not prove that the action is allowed or supported.

Keep local safety independent of a distant service. A lock, heater, or alarm must retain its safe rule when a phone or remote account is unavailable.

This opening does not certify two products or cover every stack detail. Practitioner maps the user action to test evidence. Under the Hood separates message exchange, secure sessions, data paths, retries, and the limits that each layer owns.

Use a short release check. Can the team name the action? Does each step keep the same device and time? Does a denied act stay safe? Can a second person repeat the trace? Is each open gap owned? If any answer is no, stop and repair the record.

Start with a user expecting a Matter device to join, advertise, and respond through a controller without caring which vendor built each piece. Matter Protocol Stack is the evidence route for deciding whether that expectation is realistic.

Keep one device story in view: commissioning, fabric membership, interaction model, transport, and certification all have to line up. The advanced details are useful when they explain where that story can break.

34.2 In 60 Seconds

  • Matter separates application behavior from the underlying Thread, Wi-Fi, or Ethernet network path.
  • IPv6 reachability is necessary but not enough. Review also needs secure-session, exchange, interaction, and data-model evidence.
  • MRP adds reliability behavior for Matter messages over UDP paths, but the approval should still be bounded by retry, duplicate, timeout, and sleepy-device evidence.
  • PASE and CASE evidence belongs to the secure-session layer; it should not be confused with link-layer security or application authorization.
  • The data model organizes a node into endpoints, clusters, attributes, commands, and events.
  • Endpoint 0 is the root and utility area; application endpoints expose device functions.
  • A clean approval states the stack boundary, target path, cluster evidence, device-type expectation, interaction outcome, and retest trigger.

34.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Review Matter stack evidence without collapsing transport, session, message, interaction, and data-model responsibilities.
  • Explain how the same application model can run over different IP-capable network paths.
  • Evaluate data-model evidence for nodes, endpoints, clusters, attributes, commands, events, and device types.
  • Identify wrong-layer, wrong-endpoint, unsupported-cluster, stale-descriptor, and overbroad-conformance claims.
  • Write bounded protocol-stack and data-model review decisions with accepted evidence, open gaps, and retest triggers.

34.4 Quick Check: Matter Stack

34.5 Prerequisites

This chapter assumes you have reviewed:

34.6 Protocol Stack Review Claim

Use a claim that can be checked against records:

Matter stack review claim: A Matter device model is ready for the reviewed scenario only when the network path, secure session, message reliability behavior, interaction target, endpoint-cluster structure, attribute or command semantics, device-type expectation, and retest trigger all support the same bounded approval.

The claim is intentionally narrow. Evidence that a device has an IPv6 address does not prove cluster conformance. Evidence that a controller established a secure session does not prove the requested command exists. Evidence that one endpoint works does not prove a bridge or multi-endpoint device is modeled correctly.

34.7 Stack Evidence Map

The first figure shows the evidence path from network transport to application approval.

Before stack Evidence Map, inspect Figure 34.1 to compare “IPv6 reach” with “Read, Write”. Their juxtaposition makes matter protocol stack evidence map visible.

Matter protocol stack evidence map showing network path, IPv6 reachability, secure session, message exchange, interaction model, data model target, and bounded approval decision.
Figure 34.1: Matter protocol stack evidence map.

Read Figure 34.1 from “IPv6 reach” to “Read, Write”. Taken together, “IPv6 reach” and “Read, Write” express matter protocol stack evidence map. For stack Evidence Map, the observed relationship between “IPv6 reach” and “Read, Write” is evidence that “IPv6 reach” carries into the next decision.

This map prevents a common review failure: approving the whole Matter stack from one visible app action. The reviewer needs to know which layer supplied which evidence and which layer remains unproven.

34.8 Evidence Families

Matter stack and data-model review needs several evidence families.

Network path Record whether the device is using Thread, Wi-Fi, Ethernet, or a bridge path, and whether the reviewed claim depends on that path.
IP reachability Record the IPv6 route, discovery evidence, and whether multicast or unicast behavior was part of the scenario.
Session state Record whether PASE or CASE was used, why that session type was appropriate, and whether the session matches the reviewed fabric.
Message behavior Record acknowledgments, retries, duplicate handling, exchange lifetime, timeouts, and whether sleepy-device behavior changes the result.
Interaction target Record the Read, Write, Subscribe, Invoke, or Timed Request path and response status.
Data model Record endpoint, cluster, attribute, command, event, descriptor, feature, and device-type evidence.

34.9 Layer Boundaries

Good Matter review separates what each layer proves.

Link and network Proves packets can move over the selected path. It does not prove fabric identity, ACL privilege, or cluster conformance.
Secure session Proves the nodes established the expected protected session. It does not prove every operation is authorized.
Message and exchange Proves framing, reliability behavior, duplicate handling, and response pairing for the reviewed transaction.
Interaction model Proves how the controller accessed a path: read, write, subscribe, invoke, or timed operation.
Data model Proves how the device exposes functions through endpoints, clusters, attributes, commands, and events.
Application decision Combines layer evidence into a bounded approval or rejection, with open gaps and retest triggers.

34.10 Portable Layer Stack

The useful portability question is not whether Thread, Wi-Fi, Ethernet, and bridge paths behave identically. They do not. The question is whether the upper Matter layers keep the same meaning while each lower path supplies its own reachability, timing, reliability, and retest evidence.

Before portable Layer Stack, inspect Figure 34.2 to compare “Wi-Fi 802.11” with “Network Layer (IPv6 in navy)”. Their juxtaposition makes matter protocol stack separating the interaction layer from transport and link-layer options visible.

Matter protocol stack showing the interaction layer carried over transport, IPv6 network, and link-layer options such as Thread, Wi-Fi, and Ethernet.
Figure 34.2: Matter protocol stack separating the interaction layer from transport and link-layer options.

Read Figure 34.2 from “Wi-Fi 802.11” to “Network Layer (IPv6 in navy)”. Taken together, “Wi-Fi 802.11” and “Network Layer (IPv6 in navy)” express matter protocol stack separating the interaction layer from transport and link-layer options. For portable Layer Stack, the observed relationship between “Wi-Fi 802.11” and “Network Layer (IPv6 in navy)” is evidence that “Wi-Fi 802.11” carries into the next decision.

Data model Nodes, endpoints, clusters, attributes, commands, and events describe what the device exposes.
Interaction model Read, Write, Subscribe, Invoke, and Timed Request operations act on those data-model paths.
Message and session Matter frames, secures, pairs, acknowledges, retransmits, and times the reviewed operation.
Transport path The selected IPv6 path carries the messages; BLE commissioning traffic is not the operational control path.

Operational Matter traffic uses the selected IP-capable network path. In practice that usually means Matter messages over IPv6/UDP with Matter reliability behavior; Bluetooth transport is commissioning evidence, not proof that the device remains controlled over BLE after it joins a fabric.

Layer separation is what makes the same application model portable. A controller should not need different On/Off cluster logic for a Thread light and a Wi-Fi light; it needs the same upper-layer path plus different lower-layer evidence about reachability, timing, and failures.

34.11 Layer Separation Check

34.12 Transport Independence Review

Matter aims to keep the application model stable across different network paths. That does not mean every path has identical performance, reliability, power behavior, or troubleshooting evidence.

For a transport-independence claim, review:

  • Whether the same endpoint and cluster model appears through each supported path.
  • Whether discovery and reachability evidence match the path under review.
  • Whether sleepy-device, multicast, bridge, or border-router behavior changes the interaction evidence.
  • Whether a path migration changes timing, retry, report, or subscription behavior.
  • Whether the approval is scoped to one path or to several separately tested paths.

This keeps the claim bounded. “The light is Matter-compatible” is too broad. “Endpoint 1 exposes the expected On/Off and Level Control behavior over the reviewed Thread path, with CASE session, ACL, interaction, and report evidence” is reviewable.

34.13 Message Reliability Evidence

MRP and exchange behavior should be reviewed through outcomes, not slogans.

Accepted evidence The record shows a request, response, acknowledgment or retry behavior, timeout boundary, and duplicate handling for the reviewed interaction.
Open gap The page says the protocol is reliable, but provides no evidence for retry, sleepy-device delivery, response pairing, or what happens when a message is lost.
Retest trigger Retest after firmware changes to exchange handling, transport migration, sleepy polling changes, border-router replacement, or reliability timeout changes.

34.14 Security Layer Evidence

Matter security should be reviewed at the right layer.

PASE is commissioning bootstrap evidence. CASE is operational-session evidence. Link-layer security and Wi-Fi security may protect the network path, but they do not replace Matter secure-session evidence. Likewise, a CASE session does not replace ACL evidence for a command.

Commissioning session PASE evidence is appropriate when the device does not yet have operational credentials and is being commissioned.
Operational session CASE evidence is appropriate for normal operation after fabric membership and operational credentials are installed.
Authorization boundary ACL privilege still has to match the interaction. Secure channel success alone does not approve a write, invoke, or management action.

34.15 Data Model Evidence Path

The second figure shows the review path from node identity to exact data-model target.

Before data Model Evidence Path, inspect Figure 34.3 to compare “Cluster” with “Endpoint”. Their juxtaposition makes matter data model evidence path visible.

Matter data model evidence path showing node, endpoint, device type, clusters, attributes, commands, events, descriptor evidence, and conformance decision.
Figure 34.3: Matter data model evidence path.

Read Figure 34.3 from “Cluster” to “Endpoint”. Taken together, “Cluster” and “Endpoint” express matter data model evidence path. For data Model Evidence Path, the observed relationship between “Cluster” and “Endpoint” is evidence that “Cluster” carries into the next decision.

Data-model review should be precise enough that another reviewer can reproduce the target path. A product name, room name, or marketing device category is not enough.

34.16 Node and Endpoint Evidence

A Matter node is the addressable device identity within a fabric. Endpoints expose root utilities and application functions.

Node evidence Record fabric identity, node identity, operational session, and whether the physical or bridged device boundary is clear.
Endpoint 0 Endpoint 0 is the root and utility area. It should not be confused with a controllable light, plug, sensor, lock, or bridged endpoint.
Application endpoints Endpoints above 0 should map to controllable or reportable functions. Multi-outlet, bridge, and composite devices need separate endpoint evidence.

34.17 Cluster Evidence

Clusters are reusable capability groups. A review should identify which cluster instance is present on which endpoint and whether the required behavior for the scenario is implemented.

For each cluster under review, record:

  • The endpoint that hosts the cluster.
  • Whether the cluster is server-side, client-side, or both for the scenario.
  • Which required and optional features are relevant.
  • Which attributes are read, reported, persisted, or writable.
  • Which commands are accepted, rejected, or unsupported.
  • Which events are emitted and how they are consumed.

This catches a common modeling mistake: treating cluster names as universal proof. The same cluster type can appear on multiple endpoints, and each endpoint instance needs its own evidence.

34.18 Attribute Evidence

Attributes are data values. Review them as typed, scoped, and access-controlled values.

Type and range Record the expected data type, accepted range, nullable behavior, and what value means in the device context.
Access Separate read-only, writable, reportable, persistent, and fabric-filtered behavior. Do not infer write access from read success.
Freshness Record whether the value came from a read, report, subscription, event, or cached controller state.

34.19 Command Evidence

Commands are actions, not attributes. An invoke review should preserve command identity, arguments, status, resulting state, and any timed requirement.

Command target Record endpoint, cluster, command name, and command direction for the reviewed operation.
Arguments Record fields that change behavior, such as level, transition, mode, credential, or optional feature-dependent fields.
Result Record status plus follow-up attribute, event, or report evidence. A status alone may not prove the device reached the intended state.

34.20 Device Type and Conformance Evidence

Device type evidence connects a device’s claimed category to the clusters and behavior a controller can expect.

Accepted evidence The endpoint descriptor, device type, cluster list, feature map, relevant attributes, commands, and observed interaction outcomes support the claim.
Open gap The device advertises a product category, but the reviewed endpoint does not show the expected descriptor, cluster, or behavior evidence.
Retest trigger Retest after firmware updates, certification profile changes, bridge endpoint changes, optional feature changes, or cluster-revision changes.

34.21 Quick Stack Check

34.22 Worked Review Records

34.23 Record 1: Multi-Outlet Device Modeled as One Endpoint

Scenario: A smart power strip claims independent outlet control, but the review record shows only one application endpoint with one On/Off cluster.

Evidence found: The physical device is reachable and secure sessions work, but the endpoint model does not prove independent control for each outlet.

Decision: Do not approve the multi-outlet model. Require descriptor and cluster evidence for each independently controlled application endpoint, plus interaction outcomes per endpoint.

34.24 Record 2: Bridge Endpoint Changes After Firmware Update

Scenario: A bridge exposes several devices. After firmware update, a controller sends a command to the previous endpoint and receives an unsupported-path response.

Evidence found: Network and CASE evidence are healthy. The endpoint mapping changed and the controller cache is stale.

Decision: Keep transport and session approved, but reopen data-model approval. Refresh descriptor evidence, endpoint mapping, cluster lists, and affected subscriptions.

34.25 Record 3: Attribute Read Accepted, Write Rejected

Scenario: A controller reads a level attribute but cannot write a new value.

Evidence found: The read path is valid, but the write record lacks proof of writable access, value constraints, and required ACL privilege.

Decision: Treat the write as unapproved until the attribute access, value boundary, privilege, status, and resulting report evidence are recorded.

34.26 Failure Signatures

Classify failures by the layer where the evidence breaks.

Wrong layer The review uses network reachability as proof of command support, or secure-session success as proof of ACL authorization.
Wrong endpoint The command targets root endpoint 0 or a stale bridge endpoint instead of the application endpoint that exposes the function.
Unsupported cluster The expected cluster is absent, client/server direction is wrong, or an optional feature is assumed without feature evidence.
Attribute misuse The review treats a read-only attribute as writable, ignores value constraints, or accepts cached state as current device evidence.
Command mismatch The controller sends an invoke to the wrong command path, missing feature-dependent arguments, or omits a timed requirement.
Conformance overclaim The page says a device type is supported, but does not show descriptor, cluster, feature, and behavior evidence for the reviewed endpoint.

34.27 Common Mistakes

  • Approving the whole stack because the device appears in a controller app.
  • Treating Thread, Wi-Fi, Ethernet, IPv6, Matter session, and Matter data model as one undifferentiated layer.
  • Assuming a secure CASE session authorizes every data-model operation.
  • Using one endpoint’s cluster evidence to approve another endpoint.
  • Treating product marketing category as device-type conformance evidence.
  • Ignoring descriptor changes after firmware updates or bridge reconfiguration.
  • Keeping command-line tutorials or code snippets where the chapter should explain evidence quality.
  • Using brittle packet-budget arithmetic as a universal design rule instead of reviewing measured behavior in the scenario.

34.28 Match the Stack Evidence

34.29 Order the Review Path

34.30 Data Model Check

34.31 Review Checklist

Use this checklist before accepting a protocol-stack or data-model claim:

Scope The decision names the fabric, node, transport path, endpoint, cluster, and interaction under review.
Layer evidence Network, secure session, message behavior, interaction, and data-model evidence are not substituted for one another.
Descriptor evidence Endpoint lists, device types, cluster lists, feature maps, and cluster revisions are current for the reviewed firmware or bridge state.
Operation evidence Attributes, commands, events, reports, and statuses are tied to exact paths and expected access rules.
Failure handling Unsupported path, unsupported cluster, wrong privilege, stale descriptor, duplicate, retry, and timeout cases are classified.
Retest The approval states what changes invalidate the evidence: firmware, transport, bridge map, feature set, ACL, fabric, or controller.

34.32 Summary

Matter protocol-stack review is strongest when each layer keeps its job. The network path proves reachability. The secure-session layer proves the right commissioning or operational session. Message and exchange evidence proves response, retry, duplicate, and timeout behavior. The interaction model proves how the controller accessed a target. The data model proves what the target means. A bounded approval ties those records to a specific endpoint, cluster, attribute, command, event, device-type expectation, and retest boundary.

34.33 Key Takeaway

Matter Protocol Stack Evidence should align Matter protocol stack, fabrics, commissioning, clusters, transports, interoperability, certification, and deployment evidence.

34.34 Concept Relationships

  • Network Path and Application Model: The same Matter data model can run over different IP-capable paths, but each path still needs evidence.
  • PASE and CASE: PASE supports commissioning bootstrap; CASE supports operational sessions.
  • MRP and UDP: MRP adds Matter-level reliability behavior for relevant UDP message exchanges.
  • Endpoint and Cluster: Endpoints expose device functions; clusters group related attributes, commands, and events.
  • Device Type and Conformance: Device type expectations should be supported by descriptor, cluster, feature, and behavior evidence.
  • Interaction and Data Model: Interactions act on data-model paths; the path determines what is being read, written, subscribed to, invoked, or timed.

34.35 What’s Next