The choice is driven by several factors, including the communications protocol or protocols being used and the device type and location within the local Matter ecosystem. Solution size requirements, powering expectations, and bandwidth needs are some deciding factors when choosing between various Matter platforms. If a MCU platform is used, there’s the added choice between a real-time operating system (RTOS) or an OS-based environment like Linux.
There’s no simple answer to the question of when to use standalone or MCU-hosted Matter platforms. This FAQ reviews several of the considerations and presents some representative solutions.
While Matter is expected to eventually embrace more wireless communications protocols, today, the choice is limited to Wi-Fi or Thread. Thread fits in applications that need energy-efficient networking and robust connectivity. A Matter device with Thread must also include Bluetooth LE for device onboarding (pairing or commissioning) because smartphones are often used for commissioning and do not include Thread.
Wi-Fi can maximize connectivity performance and is widely available. A Matter device with Wi-Fi does not need to include Bluetooth LE. The choice of communication protocol will directly impact the available development platforms. The type of device is also important when selecting the platform. Matter currently includes six types of nodes or devices (Figure 1):
- End Nodes, also called Thread sleepy, use only Thread, are usually battery powered, and connect to a Thread edge node or Border Router (orange)
- Edge Nodes include Thread mesh extenders or Wi-Fi nodes, which are usually AC-powered and connect to End Nodes acting as Thread mesh extenders or to gateways or Thread border routers (green)
- Thread Border Routers connect the Wi-Fi and Thread networks, are usually AC powered, and can be integrated into other Matter devices (red)
- Gateways and Hubs connect the Matter network to the cloud and are AC-powered (light blue).
- Bridges provide a connection between a Matter network and legacy networks and are AC-powered (purple)
- Controllers are used to provision Matter devices to the system. They can be standalone AC-powered devices but will often be smartphones (medium blue)
Figure 1: The Matter device type is important when choosing between hosted and standalone connectivity platforms. (Image: NXP)
Taking the various connectivity possibilities and device types into consideration impacts the power and performance needs of the application. It helps direct the choice of MCU hosted with an OS like Linux, MCU hosted with an RTOS, and standalone Matter implementations. The high-performance requirements of devices like gateways, bridges, hubs, and thread border routers using Thread, Wi-Fi, and/or Ethernet in applications such as smart televisions, security systems, and video door locks can benefit from using a Linux-hosted solution.
Depending on the specific application, edge nodes have the widest range of power and performance needs. As a result, these devices can use OS-hosted, MCU-hosted with RTOS, and standalone Matter implementations. Examples of OS (Linux) hosted edge nodes include smart thermostats and some security systems that use Thread, Wi-Fi, and/or Ethernet. MCU-hosted platforms with RTOS can be used with heating, ventilation, and air conditioning (HVAC) controls, and smart plugs that use Thread, Wi-Fi, and/or Ethernet; for HVAC controls and smart plugs that use Thread and Wi-Fi, but not Ethernet can often benefit from standalone platforms.
Edge nodes also have a wide range of power and performance requirements depending on the device specifications. These devices rely solely on Thread (with Bluetooth for commissioning). Matter devices like light switches and light bulbs, remote controllers, window coverings, and door locks can be implemented with MCU-hosted platforms with RTOS or standalone platforms. Only the simplest Thread devices, like basic sensors and actuators, are best implemented exclusively with standalone platforms (Figure 2).
Linux-hosted Matter
Linux-based MCU-hosted matter devices are currently the most common OS implementation. They can support Wi-Fi and Thread connectivity and can be used to create Thread mesh extenders, Thread border routers, Matter controllers, hubs, bridges and gateways, and Matter-connected media devices and building controls. These tend to be two-board solutions with one board for wireless connectivity and the MCU board for all other aspects of device functionality.
These platforms often include hardware-accelerated video, audio, and graphics functions to support applications like video streaming and human-machine interfaces (HMIs). The need for speed is well-recognized for video and graphics applications. HMIs are often required to respond accurately in 4 milliseconds to touch screen and gesture inputs. These platforms include extensive security and privacy protection measures; some can be operated using FreeRTOS and Linux. They are often available with application software examples for Matter devices.
RTOS MCU-hosted Matter
Devices that benefit from using size-optimized software for memory-constrained Matter devices can use an RTOS-based design. RTOSs typically do not have the more advanced features in operating systems like Linux, and not all ROTSs are created equal. There are three general classifications of RTOSs:
- Hard real-time RTOSs strictly handle deadlines. That makes them useful in some medical, and safety-critical industrial and transportation applications. Hard real-time applications are not a core target of the current Matter specification.
- Firm real-time RTOSs follow deadlines but with more flexibility than challenging real-time implementations. These RTOSs can be helpful for Matter applications like multimedia systems.
- Soft real-time RTOSs allow some delays in processing. Building automation controls and other non-time critical Matter applications can use these RTOSs.
RTOS size is another consideration. Zephyr from the Linux Foundation is a small open-source soft RTOS; its minimum configuration with threading interrupts and memory allocation is 8K. Adding Bluetooth increases the size to 16K, still small by most standards, making it useful for small IoT devices. General purpose RTOSs such as FreeRTOS, LynxOS, QNX, and VxWorks are more powerful and can offer firm real-time performance but are also larger.
Zephyr was specifically designed to support resource-constrained devices across multiple architectures and applications like sensors and actuators on the edge of a Matter network. The Zephyr system architecture separates the OS part, the kernel, and OS Services from the user-specific application services. The OS part itself contains low-level, platform-specific drivers, Wi-Fi, Thread, and Bluetooth connectivity functions, and the generic implementation of I/O APIs, file systems, kernel-specific functions, and the cryptographic library. The application services layer includes middleware such as message queuing telemetry transport (MQTT), constrained application protocol (CoAP), lightweight machine-to-machine (LwM2M), various libraries, hardware drivers, specific firmware for security, and a secure bootloader (Figure 3). Zephyr is available on several MCU platforms.
There are RTOSs based on the portable operating system interface (POSIX), a family of standards specified by the IEEE Computer Society. Zephyr is not one of them. If a project calls for a POSIX-based RTOS, NuttX may provide an answer. NuttX is a soft RTOS and is scalable from 8-bit to 64-bit MCU environments and is based on POSIX and ANSI standards.
Standalone Matter platforms
For applications like gateways, hubs, sensors, switches, door locks, lighting, glass break or wake-word detection, and building automation, standalone Matter platforms can speed the development process for low-power smart home devices. These high-performance integrated modules are often based on system-on-chip (SoC) devices. They are mostly limited to Matter over Thread with integrated ZigBee and Bluetooth to support simple device commissioning. Some are also available with integrated Wi-Fi.
The basic SoCs include the needed 2.4 GHz RF connectivity, an artificial intelligence/machine learning (AI/ML) accelerator supported by an ARM processor, and enough memory for advanced applications. They are designed for low current consumption to support battery-powered designs and include extensive security measures to protect against various cyber-attacks.
In addition to the SoC, some of these integrated modules can include 15 or more discrete components like capacitors, magnetics, and antennas, shrinking the solution and speeding the design process. The inclusion of a built-in antenna can be especially important. The optimized RF design, including the antenna and needed EMC shielding, has several benefits. It eliminates time-consuming and expensive testing. And the resulting device can be RF certified for worldwide use, including CE (Europe), FCC (United States), ISED (Canada), MIC (Japan), TELEC (Japan), and UKCA (United Kingdom) standards, reducing design risks and further speeding time to market.
Summary
Selecting between standalone and MCU-hosted Matter platforms is not as simple as it might appear. While there are obvious differences in performance between OS based MCU hosted platforms and SoC-based modules, there are a lot of grey areas when considering RTOS-based MCU platforms; sometimes those platforms compete with OS based designs, and sometimes they compete with standalone designs. Factors related to wireless connectivity protocols, powering, device type, and application function are all important when weighing the use of the various Matter platforms.
References
A Matter of Interoperability, NXP
Matter: A Unified Approach to IoT Device Development, Silicon Laboratories
Matter Development Platforms, NXP
Zephyr Security Overview, Zephyr Project
