Matter （CHIP） 从入门到入土 （一）

前言

Matter（Project Connected Home over IP，简称为CHIP项目）是一个智能家居开源标准项目，由亚马逊、苹果、谷歌、ZigBee联盟联合发起，旨在开发、推广一项免除专利费的新连接协议，以简化智能家居设备商开发成本，提高产品之间兼容性。

2021年5月11日，CHIP更名为Matter，ZigBee联盟也更名为连接标准联盟（Connectivity Standards Alliance）。

CHIP 让不同的智能家居设备间，使用 IP 地址作为身份证，互相通讯。最终目的是让那些功能各不相同的智能家居，有一套统一的「语言」。

之所以要有统一的语言，是因为智能家居正在由单独的设备，向「全屋智能」的方向发展。不同设备需要协同工作，并实现一定程度的自动化，需要统一的管理方式。

这次发布的第一代 Matter 标准，完全基于现有的网络技术开发，包括以太网、Wi-Fi、Thread 以及低功耗蓝牙。通过推行这套标准，Matter 希望提供一套标准化的智能家居体验。从选购、接入，到控制、管理，让智能家居更灵活易用，具有更好的兼容性，使用门槛更低。

这些特性，技术上实现起来都不难。实际上，早在 20 年前成立的 Zigbee 联盟，就是为解决这些问题而生。他们推出的 Zigbee 协议，就是一套为「多设备」、「多场景」设计的智能家居互联协议。Zigbee 采用了 mesh 组网的方式，让网络里的每个设备都能成为「通讯节点」，即便某一个设备下线，也不会影响其他设备正常工作。

• Thread 和 ZigBee协议层对比
  
• 说明：Thread协议实际上只包含了上图中的网络层部分协议，MAC层与PHY层 和ZigBee一样都是使用的IEEE 802.15.4 MAC 和 IEEE 802.15.4 PHY。所以Thread协议可以结合不同的应用层来实现基于Thread的协议的其他类型的协议，例如（CHIP,Homekit，Openweave，DotDot等协议）

但 Zigbee 协议将「接入许可」的控制权交给了厂商。如果厂商不允许某款设备接入，即使设备的通讯协议与平台兼容，它也不能接入该平台。最后导致的结果就是，你的门锁可能只兼容 HomeKit，台灯可能只支持亚马逊 Alexa，空调温控器又只兼容 Google Nest。

在国内，类似的情况可能涉及华为、米家、阿里智能。总之，用户需要用不同的 App 去控制不同的智能家居设备。而每一家，都想做自己的平台。

• 无线协议对比：CHIP协议链路层使用的是基于IPV6的Thread协议或者WiFi协议，可以参照下表中的Thread 和 WiFi协议。
  

这正是 Matter 要解决的问题。它与过往所有智能家居协议最大的不同之处，在于它得到了苹果、谷歌、亚马逊三家的共同支持。基于 Matter 标准开发的智能家居设备，能够同时接入 Alexa、HomeKit、Google Assistant。除这三家外，首批支持 Matter 标准的企业还包括华为和三星旗下的 SmartThings。

Matter 是一套开放标准，不向设备商抽取任何佣金，欢迎所有人接入。在发布的同时，Zigbee 联盟也正式宣布更名为 CSA（连接标准联盟）。似乎希望通过更泛化的名称，吸引更多厂商加入这个「智能家居的联合国」。

某种程度上，Matter 也是各家「搁置争议，共同开发」的一次尝试。

Matter 设计了一套统一的「设置流程」。用户通过扫码、NFC、手动输入代码等方式，和设备建立蓝牙配对，然后交换网络信息，将新设备接入到 Wi-Fi 网络。这套流程和 HomeKit 设备注册的流程很像，简洁、方便，只不过此前 HomeKit 设备用的是苹果的私有通讯协议，Matter 设备用的是通用协议。

Matter 设备会有一个「设置码」，用户可以通过设置码，将 Matter 设备注册到不同的平台上。这意味着用户和家庭成员即便一个用 iPhone，一个用 Android，也可以共同控制家居设备，还可以在不同房间用不同品牌的智能音箱控制家居设备。这打破了平台间的壁垒。

Matter 不只是互联协议，还是一种产品认证。它的 Logo 由三个指向同一中心的箭头组成，暗示着苹果、谷歌、亚马逊三家的强强联合。未来，符合 Matter 标准的智能家居产品会将这个 Logo 打在产品包装，甚至产品机身上。

架构

只制定应用层交互的标准

Matter 架构如上，该项目定义了将部署在设备和控制器上的应用层，以及支持的基于 IPv6 的网络，以帮助实现我们的互操作性架构目标。

Matter 最初将支持用于核心、操作通信和蓝牙低功耗 (BLE) 的 Wi-Fi 和 Thread，以简化设备调试和设置。

CSA想告诉你，Matter是一个聚焦在制定应用层标准的协议规范，塔尖的蓝色部分是我们的活儿，在此之下的所有灰色的基建都不属于Matter规范的范畴。一句话，既然Matter专注于应用层，底层的我就用这些现成的就行。

那这个应用层的协议规范到底定义了哪些内容呢？我们把蓝色的塔尖再放大如下，可以进一步分解为七个主要组件：

1. Application: 设备的高阶业务逻辑。例如，专注于照明的应用程序可能包含处理打开/关闭灯泡及其颜色特性的逻辑。

2. Data Model: 帮助描述设备各种功能的数据原语。当有与设备交互的意图时，应用程序对这些数据结构进行操作。

3. Interaction Model:表示可以在设备上执行以与之交互的一组操作。例如，在设备上读取或写入属性将对应于交互设备，这些操作对数据模型定义的结构进行操作。

4. Action Framing: 一旦使用交互模型构建动作，它就会被框架化为规定的打包二进制格式，以便在“wire”上很好地表示。

5. Security: 将编码的动作帧向下发送到安全层以加密和签署有效载荷，以确保数据由数据包的发送者和接收者保护和验证。

6. Message Framing & Routing: 通过加密和签名的交互，消息层使用必需和可选的标头字段构造有效负载格式；其中指定了消息的属性以及一些路由信息。

7. IP Framing & Transport Management: 构建最终有效载荷后，将其发送到底层传输协议以对数据进行 IP 管理。

规范

Matter规范目前暂时是聚焦在局域网通信的协议，厂商一般暂时将其作为组件集成到自有系统中，与其他局域网方案共存。

也就是说，Matter规范目前包含的内容，并不能直接解决对设备远程或者跨网络间通信这种使用需求。这样也是好事，毕竟你们呕心沥血搭建好的云服务暂时还是用得到的。

因为属于应用层封装，我们可以将其划分为几个不同的模型与规范。

角色：

• Cluster ：An object within an Endpoint of a Node for keeping state information and performing operations 一个节点的端点对象，用于保存状态信息和执行操作
• Administrator ：A Node having Administer privilege over at least the ACL Cluster of another Node 一个至少对另一个节点的 ACL 集群具有管理权限的节点
• Commissioner ：A Role of a Node that performs Commissioning 一个正在执行调试的节点角色
• Commissionee ：An entity that is being Commissioned to become a Node 一个被委托成为节点的实体
• Role ：Some set of (related) behaviors of a Node. Each Node can have multiple roles 节点的一些（相关）行为， 每个节点可以有多个角色
• Commission ：To bring a Node into a Fabric 将一个Node带入Fabric
• Commissionable Node ：可以委托的节点。可能需要特定操作（例如按下按钮）将可调试节点置于调试模式，以便允许调试
• Controller ：A Role of a Node that has permissions to enable it to control one or more Nodes 一个有权控制一个或多个节点的节点角色
• Controlee ：A Role of a Node that has permissions defined to enable it to be controlled by one or more Nodes 一个具有能够控制一个或多个节点权限的节点角色
• Endpoint ：A particular component within a Node that is individually addressable 一个节点中可单独寻址的特定组件
• Node ：An addressable entity which supports the CHIP protocol stack and (once Commissioned) has its own Operational Node ID and Node Operational credentials 支持 CHIP 协议栈并且（一旦委托）拥有自己的操作节点 ID 和节点操作凭证的可寻址实体
• OTA Provider ：A Node implementing the OTA Software Update Provider role 实现 OTA 软件更新提供者角色的节点
• OTA Requestor ：A Node implementing the OTA Software Update Requestor role 实现 OTA 软件更新请求者角色的节点

模型：

• Data Model / 数据模型：定义端点、集群、属性、数据类型等的一阶元素和命名空间。
• Interaction Model / 交互模型：定义节点之间的交互、事务和动作。
• System Model / 系统模型：定义 端点endpoints 和 集群clusters 之间管理的关系。

每一个Model 又包含Qualities、Conformance、Element、Fabric、Access、 Node、Endpoint、Cluster、command、Attribute、Event 等。

• Fabric（Admin）：Fabric 是一个security domain，它允许在域的上下文中识别和通信一组节点。 一个节点可以在一个或多个结构中被识别。如果用于传递命令调用、属性读取或属性写入的Session 与特定 Fabric 相关联，则该 Fabric 称为“accessing Fabric”。

• Fabric ID 是一个 64 位数字，用于唯一标识特定根 CA 范围内的 Fabric。从概念上讲，完全合法的Fabric结构由包含根证书颁发机构的公钥和FabricID 的元组组成。

• Fabric Index：设备上的每个Fabric都有一个与完整Fabric参考相对应的唯一索引。这应由 fabric-idx 类型表示。访问Fabric对应的Local Fabric Index称为“访问Fabric Index”。如果访问结构不存在，则访问结构索引应为“无结构”索引 0。

• Node 封装了网络上可寻址的唯一资源，该资源具有一组功能和能力，用户可以清楚地将其识别为一个功能整体。Node是数据模型中最高或最外层的一阶元素，且最外层唯一可寻址元素。一个节点可以有多个节点 ID，每个 ID 都作用于一个特定的结构。

网络拓扑结构

原则上，任何承载IPv6的网络都适合CHIP部署，但需支持少数核心IPv6标准。在这个版本的规范中，我们重点关注三种链路层技术：以太网、Wi-Fi 和 Thread。

我们将规范限制在上述范围内，以便规范可以适当地涵盖这些链路层的配置，并且使得认证中的测试量得到适当的限制。

1. CHIP 将网络视为共享资源 ：它没有规定专有的网络所有权或访问权限。因此，可以在同一组 IP 网络上运行多个 CHIP 网络。

2. CHIP 网络可能在没有全球可路由 IPv6 基础设施的情况下运行。此要求允许在与全球 Internet 断开连接或有防火墙的网络中操作。

3. CHIP 还支持在互联网服务提供商不支持消费者场所的 IPv6 或支持证明存在限制的情况下部署 CHIP，例如，如果委派前缀无法容纳场所内的所有网络和设备。

CHIP 专注于跨越一个或多个 IPv6 子网的本地通信。支持 CHIP 结构的规范网络可能包括 Wi-Fi / 以太网子网，或一个或多个低功耗和有损网络 (LLN) 子网（在此版本的规范中，Thread 是受支持的 LLN 标准）。

Single network

在单一网络拓扑中，所有 CHIP 设备都连接到单一逻辑网络。这可以是 Thread / 802.15.4 网络、Wi-Fi 网络或以太网网络。

在 WiFi / 以太网的情况下，网络实际上可以跨越多个 Wi-Fi 和/或 以太网段，前提是所有段都在链路层桥接。节点Node 是 fabric中 CHIP 设备的单个实例，可在 IP 网络上运行。

单网络拓扑中的每个Node都通过单个网络接口与 Fabric 中的每个其他节点进行通信

Star network topology

星形网络拓扑由多个外围网络组成，这些外围网络通过中央集线器网络连接在一起。中心网络通常是客户的家庭网络（Wi-Fi / 以太网），而外围网络可以是任何受支持的网络类型。

外围网络必须始终通过一个或多个边界路由器直接连接到集线器网络。

在架构上，任何数量的外围网络都可以存在于单个 Fabric 中，包括多个相同类型的网络。

节点可以与任何网络（集线器或外围设备）有接口，并且可以直接与同一网络上的其他节点通信。然而，任何必须跨越网络边界到达目的地的通信都必须通过边界路由器。

CHIP 对边界路由器提出了一系列要求。这些要求与地址分配、路由分配和通告、多播支持和发现代理有关。

请注意，在此版本的规范中，Thread 是主要支持的 LLN。

在许多情况下，客户安装将尝试维护一个简单的网络拓扑，具有单个 WiFi / 以太网子网和单个 Thread 网络。但是，多个 Thread 网络仍可能并支持。

为了支持家庭自动化互操作性，CHIP 支持桥接概念，通过 CHIP 节点，实现其他家庭自动化技术、传输和链路层的设备可用。

matter 设备发现

本节的目的是描述发现设备以将其调试到可操作的 Fabric 上的过程。

根据设备支持的网络技术，可以使用蓝牙低功耗 (BLE)、Wi-Fi (IEEE 802.11-2020) 技术或通过 IP（如果设备已经在 IP 网络上）进行发现和调试。

• 使用 Thread (IEEE 802.15.4) 网络技术的设备还必须支持 BLE 以进行发现和调试。既不指定也不支持直接使用基于Thread的调试进行设备发现和调试。

• BLE 调试使用通用访问配置文件 (GAP) 进行发现和建立连接，使用通用属性配置文件 (GATT) 进行凭证传输。

• Wi-Fi 调试利用 Soft-AP 功能，其中设备充当不提供 Internet 连接的接入点 (AP)。标准 Wi-Fi AP 广播和连接协议分别用于设备发现和凭证传输。

如果设备已经具有网络连接（通过 Wi-Fi、以太网或其他方式），则 Commissioner 可以使用基于 DNS 的服务发现 (DNS-SD) 发现此类设备，并通过 IP 将凭据传送给设备。

设备应按照发现能力位掩码中所示的任何优先级顺序宣布其支持的所有网络技术（参见表 35，“Discovery Capabilities Bitmask”）。

using BLE

使用 BLE Commissioners 应实现 GAP Central 的角色。

为了发现通过 BLE 发布的可委托设备广播，Commissioners 应在所有三个广播信道上执行 BLE 扫描，并具有足够的停留时间、间隔和总扫描持续时间。

为了促进快速发现，建议 Commissioners 在 Commissioner device functionality/UX 限制内尽可能积极地进行扫描。

此外，如果不需要制造商特定的数据，则进行被动扫描（即，仅侦听广播 PDU 而不发出扫描请求 PDU 的扫描）。

• 如果发现过程是用户启动的，则扫描间隔应该设置在 30 ms 和 60 ms 之间，并且扫描窗口应该设置为 30 ms。

• 如果发现过程不是用户发起的（即，Commissioner 正在后台扫描），则设备可以使用更宽松的扫描，例如，扫描间隔设置为 1.28 秒，扫描窗口设置为 11.25 毫秒。

参考：Timers and Constants of Bluetooth Core Specification Version 5.2, Vol 3, Part C.

using WIFI

为发现充当 Soft-AP 的可调试设备并广播其可调试状态，Commissioner 应扫描其操作监管域允许的所有 2.4 GHz Wi-Fi 信道。

鉴于首选通道 1、6 和 11（see Section 5.4.2.6.2, “AP Operating Parameters”），应优先扫描这些通道以最小化发现时间。

在可行且法规允许的情况下，还应使用使用探测请求的主动扫描来帮助最小化发现时间。但是，始终将扫描作为后台活动的Commissioner 应该被动地这样做（即，不应发送探测请求），以减少共享 2.4 GHz 频谱中的不必要传输。

Using Existing IP-bearing Network

要通过现有的 IP 承载网络连接发现可委托设备，Commissioner 应使用 DNS-SD 执行服务发现，如第 4.3 节“Discovery”，更具体地说，在第 4.3.1 节“Commissionable Node Discovery”中详述。

示例

• wifi 和 ethernet网络服务内部发现：内部设备发现采用 dns-sd + mDNS实现
• thread 网络服务对外发现：BR(border router)实现了dns-sd discovery proxy，R采用SRP(service register protol)注册服务到BR，wifi/ethernet网络内的node通过dns-sd可以发现thread网络内部的服务
• thread 网络发现外部服务：thread设备R发送 short lived 或 long lived unicast DNS到BR，BR在 wifi / ethernet 网络中通过 dns-sd 发现服务

1.待配网设备发布服务
dns-sd -R DD200C20D25AE5F7 _matterc._udp,_S3,_L840,_V123,_CM,_T81 . 11111 D=840
VP=123+456 CM=2 DT=81 DN="Kitchen Plug" PH=256 PI=5
//待配网设备发布服务：
//_S3：短标识符(short discriminator)是3
//_L840：长标识符( long discriminator)是840
//_V123:厂家id是123
//VP=123+456:产品id是456
//CM=2:待配网者(commissionee)当前处于配网模式，需要使用动态passcode
//_T81:设备类型81，表示是一个智能插座
//DN="Kitchen Plug":设备名称“厨房插座”
//PI=5: 设备的重置按钮需要按下5秒才能进入配网模式 

  
2.DNS记录缓存
 
_matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
_S3._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
_L840._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
_V123._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
_CM._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
_T81._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.
DD200C20D25AE5F7._matterc._udp.local. TXT "D=840" "VP=123+456" "CM=1" "DT=81"
"DN=Kitchen Plug" "PH=256" "PI=5"
DD200C20D25AE5F7._matterc._udp.local. SRV 0 0 11111 B75AFB458ECD.local.
B75AFB458ECD.local. AAAA fe80::f515:576f:9783:3f30
  
3.配网者(commissioner)发现局域网内的待配网者(commissionee)

  dns-sd -B _matterc._udp,_CM  
 
 -CM：使用动态passcode的待配网者

配网者发现待配网者服务的过程如下：

1. 使用服务类型_matterc._udp查询ptr记录

从ptr记录中找到instance name “DD200C20D25AE5F7”

如果用户选中短标识符3，就会命中如下记录

_S3._sub._matterc._udp.local. PTR DD200C20D25AE5F7._matterc._udp.local.

2. 使用instance name查询srv记录

从中找到设备ip和port：fe80::f515:576f:9783:3f30 和 11111， 命中如下记录：

DD200C20D25AE5F7._matterc._udp.local. SRV 0 0 11111 B75AFB458ECD.local.B75AFB458ECD.local. AAAA fe80::f515:576f:9783:3f30

从上面信息中，配网者commissioner可以获取设备ip和port，用于后续连接

3. 使用instance name查询txt记录

命中如下记录

DD200C20D25AE5F7._matterc._udp.local. TXT “D=840” “VP=123+456” “CM=1” “DT=81”“DN=Kitchen Plug” “PH=256” “PI=5

从上面记录中，配网者commissioner可以获取待配网设备的 厂商id，产品id，设备类型，设备名称等信息，展示给用户查看

matter 配网流程

• commissioner准备好fabric信息（），时间和时区
• commissioner通过ble，softAp或ip网络发现commissionee
• commissioner和commissionee建立PASE
• commissioner设定Fail-safe timer（配网超时timer）
• commissioner配置信息到commissionee：UTC，timezone，DST offset（冬令时夏令时），网络监管配置（wifi国家码）
• commissionee认证（Device Attestation Procedure）
  • AttestationRequest & AttestationResponse Command
  • CertificateChainRequest & CertificateChainResponse Command
  • Attestation Information Validation 设备需要在产测阶段写入DAC，通过PAI签发
• commissoner请求csr，commissionee发送csr响应
• commissionee获取noc
  • commissioner生成或获取NOC，添加到commissionee commissioner配置ACL
• commissioner执行CASE
  
  

引用

• CHIP 官网
• Matter 官网
• rfc文档 dns-sd
• mDNS-responder 开源实现
• CSA - Matter - Github
• 极客公园 - 为这件「小」事，苹果谷歌亚马逊罕见联手了