The density of silicon in modern microcontrollers has increased exponentially in the past decade. This increase has resulted in significantly more performant and efficient devices than their historical counterparts. This category of devices referred to as the “Internet of Things,” or IoT, has allowed everyday household items, such as light bulbs, switches, and outlets, to be equipped with the capability to interact with us in increasingly advanced manners. 

For example, in the case of a light bulb, beyond just hitting a switch to turn on a light bulb, an IoT-equipped light bulb can allow users to:

  • Use their voice to turn on lights in a specific room (or all the rooms) in their home.
  • Automatically configure the lights to turn on or off during specific days and times.
  • Automatically turn on when motion is detected when paired with the light sensors.

The above capabilities (along with many more) can all be done wirelessly since these devices are usually equipped with wireless capabilities.

However, the ubiquity of IoT devices has resulted in ad hoc interface implementations for each device. Every vendor has its unique interface that is not openly available to other vendors or users. Thus, users sometimes are forced to install multiple apps to control different lightbulbs in their homes!

Matter is a protocol that aims to eliminate these ad-hoc implementations and simplify interactions with IoT devices. Matter was introduced in 2022 after collaboration with Amazon, Google, Samsung, and other organizations that have a significant presence in the IoT space. Matter has the following objectives:

  • Interoperability: As mentioned, Matter’s standardized protocols and specifications guarantee that IoT devices from different vendors can easily communicate with each other, resulting in a seamless and integrated IoT ecosystem.
  • Development ease: Matter provides a common framework that can simplify the development process for IoT device manufacturers, resulting in reduced time to market and overall development costs.
  • Enhanced security: Matter was developed with security in mind. It includes robust security features, including end-to-end encryption and secure device authentication, to protect IoT devices and their corresponding data from cybersecurity attacks.
  • Improved UX: Matter’s focus on interoperability ensures that users can easily set up their devices without managing a myriad of applications for all their devices.
  • Local connectivity: Unlike traditional IoT devices, Matter-enabled devices can operate in an ad-hoc fashion, across the local network without an Internet connection. This can greatly reduce the end-to-end latency since neither the app on the user side nor the device has to go out to the Internet to interact with each other. 

Key Features

The following diagram illustrates Matter’s architecture:

Graphical user interface

Description automatically generated

As the above image shows, Matter follows a layered architecture similar to other networking stacks.

The application layer defines the interactions between devices. The application layer in Matter, which will be covered in more detail in a later section, enables automatic discovery and secure pairing among Matter devices.

Similar to other networking stacks, the transport layer is responsible for end-to-end communication between devices, whether connection-oriented (in the case of TCP) or connectionless (in the case of UDP). Considering the types of devices that comprise an IoT network, such as a light bulb, we may wonder why Matter supports TCP? Surely, UDP must be sufficient to turn on a lightbulb. However, we must remember that Matter-enabled devices are intended to interact with a cloud backend. 

Usually, the communication between an IoT device and a cloud backend is performed using HTTPS or MQTT, which rely on TCP. Thus, even though the direct actions of interacting with a Matter-enabled device, such as turning on a light switch or light bulb may not seemingly require a TCP-based connection, the connection to the backend may require such a connection.

Again, similarly to other networking stacks, the network layer is responsible for data transmission and reception between devices. It is agnostic of the underlying physical layer, ensures reliable communication, and is responsible for addressing and routing. Matter uses IPv6 as its addressing scheme, over the traditional IPv4 addressing scheme. Matter’s decision to opt for IPv6 was based on meeting the high-level objectives outlined previously. Specifically, IPv6 offers the following benefits:

  • Address space: IPv6 offers a significantly greater address space than IPv4. Since IoT devices will inherently be greater in number than personal computing devices, the address space of IPv6 will easily support the number of IoT devices that are projected to be present.
  • Auto-configuration: IPv6 has built-in support for stateless address auto-configuration (SLAAC), eliminating the need for a central DHCP server. This feature of IPv6 enables Matter to form an ad-hoc mesh network with other devices, without a central access point, as in the case of traditional network stacks, such as WiFi.
  • Local-link addresses: Similar to the previous point, local-link addresses in IPv6 allow devices to communicate with one another without being assigned a traditional, routable IP address. Thus, Matter-enabled devices can form a peer-to-peer network and communicate with each other without communicating with a central backend.

The link layer is responsible for transmitting and receiving packets on the underlying medium. While Matter currently supports popular IoT communication standards, such as WiFi, Thread, and 802.15.4, its architecture enables support for additional protocols that may arise in the future.

Application and Device Model

Matter’s application and device model enables interoperability across devices from different vendors and manufacturers. Specifically, the following features of the application model enable this interoperability:

  • Device Abstraction: The application model abstracts away the underlying implementation details of the IoT device. If a device advertises itself as a particular device with certain capabilities, then it must implement and respond to certain requests by counterpart Matter devices.
  • Event Handling: The application model allows Matter-enabled devices to subscribe to events generated by other Matter-enabled devices. Matter provides mechanisms for handling certain events, allowing applications to certain events in real-time.

Similarly, the Matter data model ensures that Matter-enabled devices that advertise certain capabilities adhere to a particular specification. Within this category, we can look at the specification of the “On/Off Light,” which implements the following “clusters”, which refers to a functional unit in the device that represents a certain capability or feature):

ID

Cluster

Client/Server

Quality

Conformance

0x0003

Identify

Server

 

M

0x0004

Groups

Server

 

M

0x0005

Scenes

Server

 

M

0x0006

On/Off

Server

 

M

0x0008

Level Control

Server

 

O

0x0406

Occupancy Sensing

Client

 

O

The “Conformance” column in the above table indicates whether a particular capability must be implemented by the device (“M”) or whether it is optional (“O”). The above table shows that if a Matter-enabled device advertises itself as an “On/Off Light,” it must implement the “On/Off” capability, which makes sense for a light switch. However, we also see that it can also implement the “Level Control” capability. This means that even if a device advertises itself as only an “On/Off Light,” if it implements the level control cluster and another Matter-enabled device requests that the light be set to a particular level, the switch can respond. However, if the device does not implement the level control cluster, the device can ignore the request.

If we look at the cluster definition of the “Dimmable Light,” we see the following:

ID

Cluster

Client/Server

Quality

Conformance

0x0003

Identify

Server

 

M

0x0004

Groups

Server

 

M

0x0005

Scenes

Server

 

M

0x0006

On/Off

Server

 

M

0x0008

Level Control

Server

 

M

0x0406

Occupancy Sensing

Client

 

O

Here, we see that the “Level Control” cluster is required to be implemented by a device that advertises itself as a “Dimmable Light,” which makes sense. A dimmable light must be able to set the light to a particular value in addition to being turned on and off. The reason for the similarity is to allow a “Dimmable Light” and an “On/Off Light” to be grouped together, which is sensible. A combination of “On/Off Lights” and “Dimmable Lights” may be combined in a single room and it’s useful to have a singular interface to command the entire group at once.

Order device driver development services -> 

This is the first chapter of our complete guide to Matter. If you found this article useful, we invite you to stay tuned as we will guide you through a hands-on demonstration with real-life examples of IoT devices using Matter.