Unifying Smart Home IoT with a Ubiquitous, IP-based Protocol

Demystifying Matter 1.0 Specification and Portents for IoT Connectivity

Jean-Jacques DeLisle for Mouser Electronics

Introduction

The Matter 1.0 specification is the culmination of massive industry collaboration among hundreds of key stakeholders in Internet of Things (IoT) connectivity. The Connectivity Standards Alliance (CSA) has recently released the standard and certification program intending to bring about a new era of IoT connectivity that impacts the entire smart home IoT vertical, from silicon to point-of-sale. The purpose of Matter 1.0 is to deliver a single, IP-based protocol that can unite smart home IoT connectivity around the globe.
This article discusses the fundamental architecture, security, transport, and interaction model of Matter 1.0 and what this means for the future of the smart home. The article closes with a section devoted to illuminating readers of development options ideal for Matter 1.0 development over Wi-Fi, from rapid prototyping to full development use cases.

Key Matter 1.0 Specifications

In essence, the Matter 1.0 specification is an interoperability application layer solution to provide connectivity among smart home devices using the Internet Protocol (IP). This includes an application layer and a transport layer stack. The specification is intended to be a complete standard, but this article notes other references that are significant to the specification. An important note is that the Matter Specification R1.0 takes precedence over the Matter SDK available on github.com.

Architecture
Matter is based on IPv6 and designed as a communication protocol specifically for smart home devices. It consists of an application layer and a networking layer (Figure 1). The networking layer is composed of a transport layer (TCP and UDP), a network layer (IPv6), and a link/media layer (Ethernet, Wi-Fi, Thread, and IEEE 802.15.4). This approach allows for efficient division of responsibilities and is intended to provide a sufficient level of encapsulation amongst the protocol stack layers.
 

Figure 1: Matter R1.0 application and networking layers. (Source: Connectivity Standards Alliance)

The specification is designed with the thought that most interactions will follow the progression through the stack as seen in Table 1.

Table 1: Descriptions of layered architecture (Sources: Connectivity Standards Alliance and Mouser Electronics)

As Matter 1.0 is IPv6 based, virtually any IPv6-bearing network is compatible with the specification as long as it supports several core IPv6 standards. However, this initial standard version is focused on helping Ethernet, Wi-Fi, and Thread link layers. Hence, the specification is restricted to these three link layers at this stage.

The Matter 1.0 specification allows for operation outside a globally routable IPv6 infrastructure so that non-networked or firewalled intranets can support a Matter network. This is important for situations where an internet service provider (ISP) does not adequately support IPv6 with provided consumer premises equipment. Moreover, because the Matter 1.0 specification treats networks as shared resources, multiple Matter networks can be present on the same constituent IP networks.

This protocol can support local communications that span one or more IPv6 subnets, with canonical networks, including Ethernet/Wi-Fi subnets, and low-power and lossy networks (LLN) subnets such as Thread. Matter can be operated as a single network (e.g., a single Wi-Fi or Thread network) or as a star network topology, with multiple peripheral networks bridged by a central hub network (e.g., a home Ethernet/Wi-Fi network). For communications to cross a network boundary, a border router is needed.

Security and Cryptography
The Matter protocol supports multiple administrators (multi-admin) without common trust roots. Matter also introduces a concept called Fabric, a collection of Matter devices that share a trusted root. Hence, the multi-admin operation is addressed by multiple Fabrics and is a core part of the naming scope. Onboarding, secure communications, and a Fabric-scoped data portion of the data model allow for multiple-Fabric functionality. As a member of multiple Fabrics, a Matter device can have multiple Node IDs. This is possible because Matter relies on an operational root of trust, or root certificate authority (CA) identified by a public key (Root PK), which is used to allocate the correct Fabric-scoped identifiers. Matter uses an administrative domain manager to contain the collaboration with the commissioner and its root CA, along with other data stores. The private key of the CA is protected, unguessable, and unobtainable, and this implies a globally unique public key. Within a root CA, a unique 64-bit identifier is used. Moreover, a reserved primordial Fabric ID allows for a set of initial access control privileges used with the initial commissioning sessions; this means that before primary commissioning, a Matter device has no pre-allocated operational roots of trust or operational IDs.

Matter public key cryptography and digital signatures are secured using an elliptic curve cryptography approach based on the NIST P-256 curve (Secp256r1). Shared key cryptographic operations are protected using established AES modes, and SPAKE2+ is used for out-of-band, passcode-based authentication. Moreover, all unicast Node-to-Node (N2N) messages have replay protection, are authenticated, and are secured.

Matter makes use of a variety of cryptographic protocol building blocks, algorithms, and primitives. Symmetric block ciphers also provide message security in this protocol. To protect all unicast and multicast messages between Nodes that require confidentiality protection and integrity with origin authentication, Authenticated Encryption with Associated Data (AEAD) must be used as primitive.

Moreover, the protocol uses Certificate-Authenticated Session Establishment (CASE) or Password-Authenticated Connection Establishment (PASE) to ensure secure session establishment, which enables the Secure Channel and Message Layer (Figure 2) to allow for secure communication among Nodes. A Secure Channel Protocol is employed to define the control plan for secure channel functions. A Device Attestation function is also used with Matter to establish trust between entities before any sensitive information (i.e., credentials or keys) is shared. The Device Attestation Certificate and Certification Declaration functions are components of the Matter Device Attestation mechanism.  

Figure 2: Message layer stack. (Source: Connectivity Standards Alliance)

Data Model
The Matter Data Model specification is a group of specifications derived from the Dotdot Architecture Model and Chapter 2 of the Zigbee Cluster Library (ZCL) specification and designed to be agnostic to the underlying encoding, message, network, transport, and other layers. The Data Model for Matter is intended to extend and more fully define a data model architecture without breaking certifiable cluster specifications set by the ZCL. The data model is implemented in the application layer of the communication stack and primarily defines the first-order elements and namespace of the data model. Hence, it is denoted as a meta-model of the data model.

The Data Model section of the Matter specification defines Fabric as a set of Nodes that interact by accessing data model elements defined by the Interaction Model. This section also establishes that “a Node encapsulates an addressable, unique resource on the network that has a set of functions and capabilities that a user recognizes distinctly as a functional whole.” It further explains that a Node is typically a physical device or a logical instance of a physical device. An endpoint is also defined as an instance, either a service or virtual device, indicated by a device type. Other definitions within the data model include clusters, commands, attributes, global elements, events, device types, non-standard, data fields, data types, and manufacturer-specific extensions.

Interaction Model
Like the Data Model, the Matter Interaction Model is independently maintained, agnostic/decoupled from the lower layers, and defines interactions, transactions, and actions between Nodes. Also like the Data Model, the Interaction Models’ roots derive from the ZCL Chapter 2 relating to ZCL commands and interactions. Matter 1.0 addresses the following gaps in the ZCL:

• Multi-element message support
• Synchronized reporting
• Reduce message types (commands and actions)
• Complex data type support in all messages
• Events
• Interception attack

The Interaction Model is designed to align with current ZCL cluster specifications and to continue ongoing support of the cluster evolution. Specifically, the Interaction Model defines an abstraction layer that abstracts interactions of the other layers (i.e., security, transport, message format, and encoding). This section describes an action as “a single logical communication from a source Node to one or more destination Nodes. An action is conveyed by one or more messages.” A transaction is defined as a sequence of actions, whereas an interaction is a sequence of transactions. Exchanges can take place within the context of an accessing Fabric or not. An interaction between an initiator and a target can be a node or a group. The four interaction types are Read, Subscribe, Write, and Invoke (Table 2).

Table 2: Four types of interactions (Source: Connectivity Standards Alliance)

A transaction can be a part of the entirety of an interaction. An action in a transaction is either the first action that is initiated by a single Node or has a target destination that is a single Node or group of Nodes (either unicast or group cast). A Matter message, or multiple, may be used to communicate an action.

System Model
The Matter System Model specification defines a system as “a set of Nodes and persistent relationships that automate data flow and control based on local or external stimulus.” Moreover, the system model accommodates a bridge for non-Matter IoT devices in a Fabric, allowing a user’s legacy non-Matter devices to work with Matter devices (Figure 3).
 
Figure 3: Principle of bridging Matter devices with non-Matter devices. (Source: Connectivity Standards Alliance)

Developing Matter 1.0-Compliant Hardware

There are a variety of goals associated with developing Matter 1.0, including rapid prototyping using pre-made kits, building a proof of concept with unique features, or doing full development with a complete RF system that is near a final production model. When developing Matter devices, it is essential to remember that Matter 1.0 rides along the top of wireless IP networking protocols (i.e., either Thread or Wi-Fi). Hence, a developer will need to choose which protocol is the best match for a given project. If the goal is to develop sophisticated and efficient wireless mesh networks with an emphasis on robust wireless connectivity, then Thread is a good candidate. If the goal is to establish a wireless network emphasizing both low-power and optimal connectivity, then Wi-Fi is likely the best choice.

Most homes already have Wi-Fi routers for home internet purposes, so we will discuss some options for development kits, platforms, and wireless modules that are well suited to Matter 1.0 development over Wi-Fi. Homes that are already equipped with compatible Wi-Fi routers are already equipped with a Matter-over-Wi-Fi controller, which should aid in adoption of Matter-over-Wi-Fi end products. For Matter-over-Thread applications, a Matter Border Router (i.e., a specific Matter hub capable of translating Matter-over-Thread messages) is needed.

Matter 1.0 Development over Wi-Fi
To save a substantial amount of development time and rapidly cycle through iterative deployment options, select a development kit that pairs well with various Wi-Fi-certified modules. Selecting a development kit and Wi-Fi module from well-established OEMs and suppliers will likely result in the least amount of additional development time, as these types of OEMs and suppliers tend to have good relationships and a wealth of support material that can help a developer overcome hurdles faster and more effectively.

One such kit is the Infineon Technologies CY8CEVAL-062S2 PSoC™ 62S2 Evaluation Kit (Figure 4), which uses the Infineon PSoC 62 microcontroller (MCU). The PSoC 62 features a 150MHz Arm® Cortex®-M4 core, 100MHz Arm Cortex-M0+ core, 1MB of flash, 288KB of SRAM, hardware crypto accelerator, and a diverse range of analog and digital peripherals (Figure 5). The evaluation kit supports an M.2 interface connector for the increasingly popular M.2 radio modules as well as an Infineon OPTIGA™ Trust M security controller and a mikroBUS interface.

 
Figure 4: Board layout of the Infineon Technologies CY8CEVAL-062S2 PSoC 62S2 Evaluation Kit, featuring an M.2 interface for connecting high-speed M.2 radio modules. (Source: Infineon Technologies)

 
Figure 5: A block diagram of Infineon Technologies PSoC 6 microcontrollers family. (Source: Mouser Electronics)

The evaluation kit is part of the Infineon Technologies IoT ecosystem, which includes several key hardware module partners that enable the ecosystem to provide high-performance and highly interoperable digital and RF hardware. The ecosystem’s module partners include Laird Connectivity, Murata, and Lantronix, which offer a range of Wi-Fi, Bluetooth®, and combined Wi-Fi/Bluetooth-enabled modules that seamlessly integrate with Infineon MCU solutions and evaluation kits ideal for Matter 1.0 development over Wi-Fi.

The CY8CEVAL-062S2 PSoC 62S2 Evaluation Kit comes with a pre-installed Laird Connectivity Sterling-LWB5+ wireless module and a Laird Connectivity FlexPIFA antenna. The LWB5+ module is based on the Infineon AIROC™ CYW4373E chipset, supports Wi-Fi 5 with Bluetooth 5.0 communication, and is specifically designed to meet the standards of medical and Industrial IoT (IIoT) applications. A main advantage of this wireless module is that it is built on a platform of wireless IP that allows for maximum interoperability.

Another lower-power, Bluetooth and Wi-Fi-enabled option is the Murata Type 1LV module, which supports the Bluetooth 5.0 Low Energy specification and Wi-Fi 802.11a/b/g/n/ac (i.e., 20MHz channel only) to a 72.2Mbps PHY data rate. This module is compatible with both 2.4 GHz and 5 GHz Wi-Fi and incorporates the Infineon CYW43012 chipset (Figure 6). The module’s Wi-Fi section communicates using the AP and STA dual-mode network topology. WLAN supports the SDIO v2.0 SDR25 interface, while the Bluetooth section supports a high-speed, four-wire UART interface. An alternative to the Type 1LV module is the Murata Type 1YN module, which is based on the Infineon CYW43439 combo chipset.
 

 
Figure 6: A block diagram of the Infineon AIROC CYW43012 dual-band Wi-Fi 4 and Bluetooth 5.2 combination device. (Source: Infineon Technologies)

Infineon’s Matter over Wi-Fi solutions, which were taken through the Matter pre-certification process and developed on the hardware platforms previously listed, are incorporated into ModusToolbox™. ModusToolbox™ is Infineon’s modern extensible development environment, which supports both the Infineon PSoC™ microcontroller devices and AIROC™ Bluetooth/Wi-Fi combo devices. To save a substantial amount of development time and rapidly cycle through iterative deployment options, visit https://www.infineon.com/matter for training material to kickstart your first Matter over Wi-Fi product development.

Conclusion

This article highlights several sections and details of the recently released Matter 1.0 specification. The near future will see manufacturer devices that are already Matter 1.0 compatible gain new and enhanced interoperability. With industry-wide buy-in and support of the Matter 1.0 specification, virtually all future smart home IoT devices will be Matter 1.0 compatible and/or certified. There are also provisions included in the specification that allow for non-Matter devices to function on a Matter Fabric alongside Matter devices by using a bridge. This means that users’ existing smart home IoT devices that aren't Matter-compatible won’t necessarily need to be replaced, and users will enjoy a new level of interoperability, security, and ease of use.