前言

本文将介绍 ZigBee 3.0 入网过程相比于 ZHA 入网过程新增的部分，并通过抓包详细介绍这些部分的作用，以及对不同类型的设备，如何做到在入网环节尽可能精简的读取设备信息，从而做到仅从协调器端达成对不同厂商设备的兼容的目的。

 

一、入网过程

废话不多说，我们直接进入正题，ZHA 和 ZigBee 3.0 的入网流程对比。

 

ZHA 在入网过程中，使用 Global Link Key 加密 Network Key 来获取该网络的秘钥，此后，入网过程结束。如图1-1 ZHA 终端设备入网流程抓包。Device Announce 之后设备入网，且通过 Network Key 来加密信息传输。Global Link Key 为全球通用秘钥，可以理解成公钥，所以在传输秘钥这一步是网络中最薄弱的环节，并且 Link Key 没有替换，若在接下来的过程中，需要用 Link Key 加密去传输信息，如：更换 Network Key，则还是会出现安全的风险。整个入网过程比较简单，传递的信息有限，协调器端仅仅只能通过 Association Response 和 Device Announce 来获取入网设备信息。

图 1-1 ZHA 终端设备入网流程抓包

ZigBee 3.0 入网过程相比 ZHA 入网过程，在 Device Announce 之后增加了几个过程。

1. 老化时间同步。对标抓包中的 Unknown 包，ZigBee 联盟在 ZigBee Specification-Revision 21 的文档中，定义了设备在入网时应该将自身老化时间上报上去，在父节点上同步，超过该事件，该设备老化，则该设备邻居将该设备从邻居表移除。老化机制详细介绍见我们同事的另一篇博文《NXP ZigBee 3.0 软件开发流程-子设备老化机制分析》。
2. Node Descriptor Request 和 Simple Descriptor Request。节点描述符请求主要请求改节点的相关信息，包括节点类型、使用频段、节点的 MAC 功能、制造商代码等；简单描述符请求主要请求端点上的设备功能，包括端点的设备类型、端点所使用的 Cluster等。详细信息请参阅附录一，4.2.1 和 2.4.2.2 节。
3. Request Key。ZigBee 3.0 的设备在入网之后，会在设备端发起请求 Link Key ，要求协调器（或 Trust Center ）更换 Global Link Key ，从而使网络更加安全。但实际上，入网过程在传输秘钥这一步还是有安全隐患，所以 ZigBee 3.0 加入了 Install Code 机制，就是每个 End Device 加入到网络是采用独立的 Link Key，所以即使黑客抓到包，没有 Link Key 也无法得到 Network Key 密钥。
4. Management Permit Joining Request。新设备入网后，会发包通知协调器，让协调器继续打开入网窗口一段时间，默认是 3 分钟（180 s）。

 

如图1-2 ZigBee 3.0 终端设备入网过程抓包。

图 1-2 ZigBee 3.0 终端设备入网过程抓包

 

综上，ZigBee 3.0 在入网过程上，对设备的信息获取，网络的安全加密上，都有更大的进步。但是，这只是一个标准的入网过程，面对同一类设备不同厂商，同一个厂商不同的设备端点数，如何做到能够在入网过程中就将这些设备区别开来，上报给网关，做到兼容呢？继续来看下一章。

二、兼容性处理

不同的厂商有不同的设备，不同的设备又会有不同的端点，ZigBee 3.0 虽然已经是实现兼容 ZigBee 各类的协议，但是在实际应用场合，想要对接不同厂商的设备，还需要在软件上进行一定的修改。

默认的入网过程中，协调器在设备入网时，会主动发送 Simple Descriptor Request 和 Node Descriptor Request，来获取入网设备的相关信息。

Simple Descriptor 中包含：

■  应用程序运行和通信的端点

■  应用程序实现的ZigBee设备类型

■  设备类型实现的ZigBee集群

■  是否有相应的复杂和用户描述符

■  应用程序分别使用和提供的输入和输出集群列表（Input and Output Cluster）

Node Descriptor 中包含：

■  类型（终端设备，路由器或协调员）

■  使用的频段（868 MHz，902 MHz或2400 MHz）

■  IEEE802.15.4 MAC功能 - 即，是否：

■  该设备是否是PAN协调员

■  节点实现全功能或简化功能的IEEE 802.15.4设备

■  设备由电源供电

■  设备能够使用MAC安全性

■  接收器在空闲期间保持开启状态

■  制造商代码

■  堆栈符合性修订（堆栈符合的ZigBee PRO Core规范 - 在修订版21之前，这些位保留并设置为零）

■  最大缓冲区大小

具体的细节这里就不做展开了，有兴趣的小伙伴可以去翻阅 NXP 的 JN-UG-3113 ZigBee 3.0 Stack User Guide v1.5，里面有详细的介绍。

在 NXP 的代码中，Simple Descriptor 存储端点号的变量没有定义成数组，不好实现循环请求，所以我们可以使用 Active Endpoint Request来请求端点号，并用其中的另外一个数组变量来对端点号进行区分。

整个兼容性入网的参考过程如下：

设备发送信标帧和关联请求，请求入网 -> 协调器允许入网，并分配秘钥 -> 设备入网，Device Announce -> Node Descriptor Request -> Active Endpoints Request -> Simple Descriptor Request -> Basic Attribute Request

可以看到，整体过程多出了一个 Active Endpoints Request 和 Basic Attribute Request 。

Active Endpoints Request 用来请求当前节点的所有活跃节点，为不同厂家设备使用不同的端点做兼容处理；

Basic Attribute Request 用来请求当前节点的基本属性，包括设备软、硬件版本，厂商 ID等信息，为不同厂家的不同设备做兼容性处理；

在活跃端点获取到之后，添加一个循环即可请求所有端点的 Simple Descriptor。

以上两点完成，即可通过串口将信息传送到 MCU 上报到云端，对不使用标准端点（默认为1）的设备进行兼容，也可以对该设备进行唯一识别，从而完成不同设备的区分。

 

三、代码实现

1、设备入网代码入口

2、添加 Active Endpoints Request

3、收到 Active Endpoints Response 后，发送 Simple Descriptor Request

4、收到 Simple Descriptor Response 后，发送 Basic Attribute Request

参考资料

[1]: JN-AN-1216-ZigBee-3-0-IoT-ControlBridge-UserGuide

[2]: JN-UG-3113 ZigBee 3.0 Stack User Guide v1.5