Matter

Matter 1
1.Why is it necessary? 1
2.Vision 1
3.Overview 2
4.Topology 3
4.1 Matter controller 4
4.2 Matter accessory 5
5. Architecture 6
6. Reference 9

Matter demo 10
1. Build 10
2.Setting up the environment via Docker 10
3.Build cross-compile for Raspberry Pi 4 11
4.Installing prerequisites on Raspberry Pi 4 11
5.Run CHIP Linux Lighting Example 12

1.Why is it necessary?
Smart home market fragmentation has negative consequences
● For consumers: no interoperability between ecosystems
● For developers and manufacturers: costly development
● For retail: multiple variants of the same products

2.Vision
● Address key pain points for interoperability, choice and ease of use
● Enable easier, faster, less costly IoT product development and innovation
● Ease and improve the retail/customer purchase experience
● Enable greater and more accelerated adoption in smart home, building and commercial
uses
3.Overview
Matter is a new Working Group within the Connectivity Standards Alliance (formerly Zigbee
Alliance). This Working Group develops and promotes the adoption of a new connectivity
standard to increase compatibility among smart home products, with security as a fundamental
design tenet.

The main idea for the CHIP project is to simplify development for manufacturers and increase
compatibility for consumers.

Matter is an app-layer standard that works on top of IP-based protocols such as Thread, BLE,....
It's not a networking protocol itself

Matter is developed with the following goals and principles in mind:

● Unifying: Matter will produce a new specification, building with and on top of
market-tested, existing technologies.
● Interoperable: The specification permits communication between any Matter-certified
device, subject to users’ permission.
● Secure: The specification leverages modern security practices and protocols.
● User Control: The end user is in control of authorization for interaction with devices.
● Federated: No single entity serves as a throttle or a single-point-of-failure for the root of
trust.
● Robust: The set of protocols specify a complete lifecycle of a device — starting with the
seamless out-of-box experience, through operational protocols, to device and system
management specifications required for proper function in the presence of change.
● Low Overhead: The protocols are practically implementable on low compute-resource
devices, such as MCUs.
● Pervasive: The protocols are broadly deployable and accessible, thanks to leveraging
IP and being implementable on low-capability devices.
● Ecosystem-Flexible: The protocol must be flexible enough to accommodate
deployment in ecosystems with differing policies.
● Easy to Use: The protocol should aim to provide smooth, cohesive, integrated
provisioning and out-of-box experience.
● Open: The Project’s design and technical processes should be open and transparent to
the general public, including to non-members wherever possible.
4.Topology

Multi-admin is a foundational feature in Matter.

With multi-admin users can connect Matter devices to multiple apps and ecosystems locally,
securely and even simultaneously.

Matter device will use Thread or WiFi and BLE technology for transaction

● Thread is usually used for devices which require highest energy efficiency like sensors,
light bulbs…
● Wifi is used for device having larger energy budget and require higher bandwidth like
cameras…
● BLE is used by a Matter controller (smart speaker, mobile phone…) to commission/setup
new device into the network.
○ Commissioning is a process transfer network necessary information to new
device can securely join existing network
■ To start the commissioning procedure, the Controller must get the
onboarding information from the Matter accessory device
■ The last part of the commissioning procedure, the Controller sends
credential (ithe provisioning operation) to new device so it can join the the
network
○ After commissioning phase, the new device will use thread/wifi to communicate in
the network

4.1 Matter controller

The Matter controller is a role within the Matter development environment. The controller device
is used to pair and control the Matter accessory device remotely over a network, interacting with
it using Bluetooth LE and the regular IPv6 communication.

Bluetooth LE is used to commission a new device into the network using a Matter controller.

Bluetooth LE is NOT used for a device to device communication, or a device to controller

communication after commissioning is finalized
4.2 Matter accessory
The Matter accessory device is a basic node of the Matter network. The accessory is formed by
the development kit and the application that is running the Matter stack.

To allow the use of non-Matter Iot devices to communicate and interact with Matter devices.
This enables the consumer to keep using existing non-Matter devices together with their Matter
devices.

To enable the IPv6 communication with the Matter accessory device over the Thread network,
the Matter controller requires the Thread Border Router. This is because the Matter controller
types described on this page do not have an 802.15.4 Thread interface. The Border Router
bridges the Thread network with the network interface of the controller, for example Wi-Fi.

Sequence of commissioning procedure (the provisioning operation):

1. The controller gets the onboarding information from the Matter accessory device. The
data payload, which includes the device discriminator and setup PIN code, is encoded
within a QR code, printed to the UART console, and can be shared using an NFC tag.
2. The Matter controller sends the Thread network credentials to the Matter accessory
device.
3. The Matter accessory join the Thread network and communicate with other Thread
devices in the network.
OTBR: Wifi, Thread
Matter accessory: BLE, Thread
Matter controller: BLE, Wifi
Old thread node could control by matter controller?
Discriminator?
What protocol message transfer between MA and MC through?
Could 2 MAs communicate with each other?
MultiAdmin role?, Public key, private key share?

5. Architecture
● Matter defines the application layer that will be deployed on devices and
controllers as well as the supported IPv6-based networks to help achieve our
interoperability architectural goal
● Application is broken down as:

1. Application: High order business logic of a device. For example, an application

that is focused on lighting might contain logic to handle turning on/off the bulb
as well as its color characteristics.
 2. Data Model: Data primitives that help describe the various functionalities of the
devices. The Application operates on these data structures when there is intent
to interact with the device.
3. Interaction Model: Represents a set of actions that can be performed on the
devices to interact with it. For example, reading or writing attributes on a device
would correspond to interactions with the devices. These actions operate on the
structures defined by the data model.
4. Action Framing: Once an action is constructed using the Interaction Model, it is
framed into a prescriptive packed binary format to enable being well represented
on the “wire”.
5. Security: An encoded action frame is then sent down to the Security Layer to
encrypt and sign the payload to ensure that data is secured and authenticated by
both sender and receiver of a packet.
6. Message Framing & Routing: With an interaction encrypted and signed, the
Message Layer constructs the payload format with required and optional header
fields; which specify properties of the message as well as some routing
information.
7. IP Framing & Transport Management: After the final payload has been
constructed, it is sent to the underlying transport protocol for IP management of
the data.
● Matter-enabled devices can operate in two different configurations, such as:
○ System on chip (SoC). A Matter SoC runs all Matter layers on a single
device. This configuration is a good fit for systems where the main system
function is the Matter application. An SoC is common for higher-volume
products such as lights, sensors or smart locks.
○ Co-processor. A Matter co-processor runs a subset of Matter layers and
pairs with another main processor to create a complete Matter solution.
There are two possible types of co-processors: network co-processors
(NCPs) and radio co-processors (RCPs).

This is example nRF stack which implement Matter layer inside:

6. Reference
How to Scale Your IoT Designs with Matter and NXP
Introduction to Matter
https://github.com/project-chip/connectedhomeip-doc
https://github.com/project-chip/connectedhomeip
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.1/nrf/ug_matter_configuring.html#
matter-development-environment-setup-options
Matter demo

1. Build
Prerequisites
● A Raspberry Pi 4 board
● A laptop / workstation etc
● Ubuntu 20.04 or newer image for ARM64/AMD64 platform

To check out the Matter repository:

$ git clone --recurse-submodules

[email protected]:project-chip/connectedhomeip.git

If you already have a checkout, run the following command to sync submodules:

$ git submodule update --init

2.Setting up the environment via Docker

To use the Docker container for setup, complete the following steps:

Build Docker

$ cd integrations/docker/images/chip-build-crosscompile
$ ./build.sh

after that docker image chip-build-crosscompile would be created, start Docker with the
builded image by running the following command, customized to your needs as
described below:

$ docker run --rm -it -e RUNAS=$(id -u) -v ~/connectedhomeip:/var/chip \

chip-build-crosscompile
In this command:
○ ~/connectedhomeip must be replaced with an absolute path to the Matter
source directory.
○ -e RUNAS=$(id -u) is needed to start the container session as the current
user instead of root.
3.Build cross-compile for Raspberry Pi 4
Before running any other build command, the scripts/activate.sh environment setup
script should be sourced at the top level. This script takes care of downloading GN,
ninja, and setting up a Python environment with libraries used to build and test.

$ source scripts/activate.sh

If this script says the environment is out of date, it can be updated by running:

$ source scripts/bootstrap.sh

The scripts/bootstrap.sh script re-creates the environment from scratch, which is

expensive, so avoid running it unless the environment is out of date.

To build the lighting-app example:

$ export
PKG_CONFIG_PATH="/opt/ubuntu-21.04-aarch64-sysroot/lib/aarch64-linux-gnu/pkgcon
fig"

$ gn gen --check --fail-on-unused-args --export-compile-commands

--root=/var/chip/examples/lighting-app \'--args=target_cpu="arm64"
is_clang=true chip_crypto="mbedtls"
sysroot="/opt/ubuntu-21.04-aarch64-sysroot"\'
/var/chip/out/linux-arm64-lighting-app

$ ninja -C /var/chip/out/linux-arm64-lighting-app

4.Installing prerequisites on Raspberry Pi 4

Using rpi-imager, install the Ubuntu 21.04 64-bit server OS for arm64 architectures on
a micro SD card. This release will have bluez 5.55 or newer which is required for BLE
functionality.

Boot the SD card, login with the default user account "ubuntu" and password "ubuntu",
then proceed with "How to install prerequisites on Linux".

Finally, install some Raspberry Pi specific dependencies:

sudo apt-get install pi-bluetooth avahi-utils

You need to reboot your RPi after install pi-bluetooth.

By default, wpa_supplicant is not allowed to update (overwrite) configuration, if you

want the Matter app to be able to store the configuration changes permanently, we need
to make the following changes.

1. Edit the dbus-fi.w1.wpa_supplicant1.service file to use configuration file instead.

sudo nano /etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service

Change the wpa_supplicant start parameters to:

ExecStart=/sbin/wpa_supplicant -u -s -i wlan0 -c
/etc/wpa_supplicant/wpa_supplicant.conf

2. Add the wpa-supplicant configuration file

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

And add the following content to the file:

ctrl_interface=DIR=/run/wpa_supplicant

update_config=1

Finally, reboot your RPi.

5.Run CHIP Linux Lighting Example

In RPi:

$ sudo out/debug/chip-lighting-app

In laptop:

$ chip-tool pairing ble-wifi ${NODE_ID_TO_ASSIGN} ${SSID} ${PASSWORD} 20202021

3840
where:

● ${NODE_ID_TO_ASSIGN} (which must be a decimal number or a 0x-prefixed

hex number) is the node id to assign to the node being commissioned.
● ${SSID} is the Wi-Fi SSID either as a string, or in the form hex:XXXXXXXX
where the bytes of the SSID are encoded as two-digit hex numbers.
● ${PASSWORD} is the Wi-Fi password, again either as a string or as hex data

To use the Client to send Matter commands, run the built executable and pass it the
target cluster name, the target command name as well as an endpoint id.

The endpoint id must be between 1 and 240.

$ chip-tool onoff on 1

The client will send a single command packet and then exit.

IPv6

Introduction

Overview
IPv6 has 128 bit addresses and has a much larger address space than 32-bit IPv4
which offered us a bit more than 4 billion addresses.

With 128 bits this is the largest value you can create:

340,282,366,920,938,463,463,374,607,431,768,211,456

The main reason to start using IPv6 is that we need more addresses but it also offers
some new features:

● No Broadcast traffic: that’s right, we don’t use broadcasts anymore. We use

multicast instead. This means some protocols like ARP are replaced with other
solutions.
● Stateless Autoconfiguration: this is like a “mini DHCP server”. Routers running
IPv6 are able to advertise the IPv6 prefix and gateway address to hosts so that
they can automatically configure themselves and get access outside of their own
network.
 ● Address Renumbering: renumbering static IPv4 addresses on your network is a
pain. If you use stateless autoconfiguration for IPv6 then you can easily swap the
current prefix with another one.
● Mobility: IPv6 has built-in support for mobile devices. Hosts will be able to move
from one network to another and keep their current IPv6 address.
● No NAT / PAT: we have so much IPv6 addresses that we don’t need NAT or PAT
anymore, every device in your network can have a public IPv6 address.
● IPsec: IPv6 has native support for IPsec, you don’t have to use it but it’s built-in
the protocol.
● Improved header: the IPv6 header is simpler and doesn’t require checksums. It
also has a flow label that is used to quickly see if certain packets belong to the
same flow or not.
● Migration Tools: IPv4 and IPv6 are not compatible so we need migration tools.
There are multiple tunneling techniques that we can use to transport IPv6 over
IPv4 networks (or the other way around). Running IPv4 and IPv6 simultaneously
is called “dual stack”.

X:X:X:X:X:X:X:X where X is a 16-bit hexadecimal field

We don’t use decimal numbers like for IPv4, we are using hexadecimal now. Here’s an
example of an actual IPv6 address:

2041:1234:140F:1122:AB91:564F:875B:131B

Shortening IPv6 Addresses

IPv6 addresses can be shortened:

● Original: 2041:0000:140F:0000:0000:0000:875B:131B
● Short: 2041:0000:140F::875B:131B

If there is a string of zeros then you can remove them once. In the example above I
removed the entire 0000:0000:0000 part. You can only do this once, your IPv6 device
will fill up the remaining space with zeros until it has a 128 bit address.

There is more however, the address can be shortened even more:

● Short: 2041:0000:140F::875B:131B
● Shorter: 2041:0:140F::875B:131B

If you have a “hextet” with 4 zeros then you can remove those and leave a single zero.
Your IPv6 device will add the remaining 3 zeros.
Leading zeros can also be removed, here’s another address to demonstrate this:

● Original: 2001:0001:0002:0003:0004:0005:0006:0007
● Short: 2001:1:2:3:4:5:6:7

To summarize these rules:

● An entire string of zeros can be removed, you can only do this once.
● 4 zeros can be removed, leaving only a single zero.
● Leading zeros can be removed.

IPv6 Prefix

IPv4 addresses have a subnet mask but instead of typing something like 255.255.255.0
we use a prefix length for IPv6. Here is an example of an IPv6 prefix:

2001:1111:2222:3333::/64