How to Use Matter to Connect the Islands of Smart Home Automation

Designers of wireless smart home automation devices are challenged by a lack of broad based interoperability that is limiting the growth of wireless smart home ecosystems. Amazon Alexa, Apple HomeKit, and Google Assistant devices, for example, currently operate in their own islands of automation. The same is true in varying degrees for Ethernet, Thread, Insteon, SmartThings, Wi-Fi, Z-Wave, and other wireless Internet of Things (IoT) protocols.

Designing multiprotocol devices is a potential solution, but it requires complex designs that extend the development process and increase device cost. Additionally, multiprotocol devices can only partially connect the islands of smart home automation as the various protocols have different approaches to implementing security and privacy for users, further complicating their design and implementation.

To address these issues, designers can turn to the Matter 1.0 specification from the Connectivity Standards Alliance to connect the islands of automation and enhance the utility of smart home IoT networks. The Matter software suite is also designed to simplify the commissioning of new devices and provide comprehensive security and privacy.

This article begins with a brief overview of the origins of Matter as the Connected Home over IP (CHIP) project of the Zigbee Alliance, and its evolution into its current position within the Connectivity Standards Alliance (CSA). It then reviews Matter’s application-layer software stack that sits on top of protocols like Ethernet, Wi-Fi, Bluetooth, and Thread. It also examines Matter’s security and privacy tools. It concludes by presenting several evaluation kits and development boards from NXP Semiconductors, along with associated microcontrollers (MCUs) that can speed the design of interoperable wireless smart home devices using Matter.

Matter emerges from CHIP

A typical smart home can have over 100 IoT devices using over 20 protocols, creating a networking tower of babel where the various automation islands operate in isolation (Figure 1). The CHIP project was launched in December 2019 by the Zigbee Alliance to develop a common software suite and connect the islands. CHIP became a major focus of the Alliance, which changed its name to the CSA, and the CHIP project was renamed Matter. Matter is based on the Internet protocol (IP) and is offered as an open-source software specification that is royalty-free. Membership in the CSA and the Matter working group are required to obtain intellectual property rights to use Matter. The Matter project has also defined certification requirements and has established a series of independent testing laboratories so devices can be verified as compliant.

Figure 1: A typical smart home can have over 100 IoT devices using over 20 different protocols, creating numerous islands of automation. (Image source: NXP)

Where does Matter fit in?

Matter is built on top of the IP layer and uses it as a common language for communicating with IP-based networks like Ethernet, Thread, and Wi-Fi. By using IPv6, Matter can communicate with devices without needing a translator. Matter sits below the device application layer and on top of the transmission control protocol (TCP) layer, through which it links to the IP layer in the communications stack. Matter is an interoperable application layer solution that is constructed with six functional layers below the application layer, including the data model, interaction model, action framing, security, message framing and routing, and IP framing and transport management. The transport management layer handles the links to individual protocols. In its initial release, Matter supports Ethernet, Thread, Bluetooth Low Energy (BLE), and Wi-Fi. Work is already underway to expand its network connectivity (Figure 2).

Figure 2: Matter uses IPv6 to communicate with Wi-Fi, Thread, BLE, and Ethernet devices, eliminating the need for dedicated translators. (Image source: NXP)

Ensuring secure operation is a key element in Matter deployments. Matter combines an authentication code and encryption to maintain the confidentiality and accuracy of messages and to authenticate the data source. It uses advanced encryption standard (AES) 128 cipher block chaining message authentication code (CCM) encryption with 128-bit AES cipher block chaining (CBC) for security. In addition, it employs a defense-in-depth principle to provide the most appropriate levels of security and privacy for individual devices. The layered approach optimizes resource utilization and ensures the availability, integrity, and confidentiality of communication.

What does a Matter network look like?

Matter is managed by the CSA and licensed under Apache 2.0. The CSA also maintains a library of standard implementations and applications that members can use to support the development of their own Matter-compliant devices. Security and user privacy are a major focus of Matter, and the library ensures uniformity in the implementation of security across the Matter device universe. In terms of hardware, Matter includes end nodes, edge nodes, gateways (also called controllers), bridges, and border routers. There can be confusion since both gateways and border routers are sometimes referred to as ‘hubs’ (Figure 3). When in doubt about a device, it’s best practice to clarify the specific function of any ‘hub.’

Figure 3: Matter networks include gateways, bridges, and border routers to provide connectivity across different local networks and connectivity to the Internet. (Image source: NXP)

• Gateways – A Matter gateway supports remote access to Matter devices by providing a connection to the Internet. Some pre-existing devices like smart home hubs from SmartThings, Amazon, and Google can get software updates that turn them into Matter gateways. Matter is specified so it can exist with manufacturer-provided communications functionality such as cloud connections or remote controls, allowing those devices to still use their existing communications capabilities even when operating as part of a Matter network.
• Bridges – Matter bridges are used to connect Matter networks with nearby wireless networks. Devices that are not Matter compatible can operate through a bridge and work seamlessly with a Matter network. Bridges are also expected to speed the adoption of Matter by enabling non-Matter-compatible nodes and networks to easily be integrated into a larger Matter network structure. Some existing devices can be updated and become Matter compatible, enabling direct integration into a Matter network without connecting through a bridge.
• Border routers – Border routers are specifically designed to integrate Thread networks and devices like motion, door and window sensors into a Matter network. Thread is a low-power wireless IP protocol that runs on the IEEE 802.15.4 physical layer (PHY). Since 802.15.4 is not compatible with Wi-Fi, it’s more complicated to update a device to be a border router. That is set to change. Manufacturers like NXP have introduced devices that combine support for Wi-Fi 6, Bluetooth 5.2, and 802.15.4 that simplify the design of border routers and other Matter devices. In addition to linking networks, some border routers have an interface for smart home controls.

Designing Matter network elements

Building a Matter network requires several types of devices, including end nodes like sensors and actuators, edge nodes like smart lighting, smart locks, and heating ventilation and air conditioning (HVAC) controls, and a range of gateways, border routers, and bridges to tie it all together. NXP offers a full range of development hardware for every type of Matter network element, along with extensive materials on GitHub, including Matter platform support and application examples to speed the development process (Table 1).

Table 1: Selected development environments for Matter platforms offered by NXP. (Table source: NXP, modified by author)

End node

Developers of end node Matter platforms can leverage the IOTZTB-DK06 development environment using a K32W0x MCU platform such as the K32W041AZ (Figure 4). The environment includes the hardware and software needed to create standalone end nodes, and a three-unit demonstration network—including a control bridge, switch node, and light/sensor node.

The K32W041AZ MCUs are purpose designed with an Arm® Cortex®-M4 MCU with 640 kilobytes (Kbytes) of on-board flash memory and 152 Kbytes of static random access memory (SRAM) to power the next generation of ultra-low-current multiprotocol wireless devices and support BLE 5.0 and Zigbee 3.0/Thread/IEEE 802.15.4. In addition to ultra-low transmit and receive power consumption, these MCUs can support complex applications and over-the-air (OTA) updates without external memory.

Figure 4: The IOTZTB-DK06 platform includes a switch node (left), control bridge (center), and light/sensor node (right). (Image source: NXP)

Edge node

The i.MX RT1170 EVK provides an integrated development platform for Matter edge nodes. This eval kit is built on a six-layer pc board with through-hole components for better electromagnetic compatibility (EMC) performance, and it includes key components and interfaces to speed development projects (Figure 5). It’s based on the i.MX RT1170 Crossover MCU family, which includes the MIMXRT1176CVM8A, and can be combined with the IOTZTB-DK06 described above. The dual-core i.MX RT1170 runs on the Cortex-M7 core at 1 gigahertz (GHz) and the Arm Cortex-M4 at 400 megahertz (MHz). It supports several advanced security features including:

• Secure boot
• Inline encryption engine (IEE)
• On-the-fly AES decryption (OTFAD)
• High-performance cryptography
• Active and passive tamper detection

Figure 5: The i.MX RT1170 EVK can be used for the development of Matter edge node devices. (Image source: NXP)

In addition, the MIMXRT1170-EVK can be used with the OM-A5000ARD Arduino dev kit for implementing security. This Arduino dev kit is based on the A5000, a ready-to-use secure IoT authenticator that includes a root of trust at the IC level. The A5000 can securely store and provision credentials and perform cryptographic operations for the security of critical communication and authentication. It’s designed for use in a range of IoT security use cases like device-to-device authentication, secure connection to public/private clouds, and counterfeit protection. To support rapid development of security solutions, the A5000 comes with pre-installed software for application authentication and security.

Gateways, border routers, and bridges

When the need is for more complex designs like gateways, border routers, and bridges, designers can turn to the i.MX 8M Mini EVKB. This eval board supports the i.MX 8M Mini Applications Processor family, such as NXP’s MIMX8MM5CVTKZAA (Figure 6).

Figure 6: The i.MX 8M Mini EVKB supports the development of Matter gateways, border routers and bridges. (Image source: NXP)

The i.MX 8M Mini applications processor has a broad range of capabilities in terms of system connectivity and memory interface flexibility, making it suitable for both media-rich consumer and embedded industrial applications, and non-media-rich general purpose applications requiring power efficiency and high performance.

The 8MMINILPD4-EVKB eval board can be used together with the IOTZTB-DK006 and OM-A5000ARD, described above. The addition of the K32W061 upgrade boards and a USB dongle allows for a small wireless Matter network to be quickly assembled for testing and development of multiprotocol applications.

Conclusion

Interoperability is critical for end users of IoT devices, regardless of vendor, platform, or ecosystem. Matter is an open-source software specification designed specifically to connect the many islands of automation in smart home environments, while also ensuring security and privacy. As shown, a Matter network consists of a variety of devices including end nodes, edge nodes, gateways, border routers and bridges. For designers looking to quickly kickstart a design, NXP offers an extensive line of software and hardware development platforms for the entire range of Matter devices.

Recommended reading

1. How to Reduce Power Consumption in Always-On Voice Interface Designs