ZigBee网络通信概念区分

先说几个ZigBee里边的缩写词：

ZCL：Zigbee Cluster Library

ZDP：ZigBee Device Profile

OTA：Over The Air

ISR：Interrupt Service Routine中断服务程序

KVP: Key-value pair (键值对)

MSG： Message service type(报文)

1、Endpoint

    每个设备都是一个节点，每个节点都有长短两个地址，每个设备有241个endpoint(0保留，1~240由应用层分配，241~254保留，255用于向所有的端点广播)，每次通信的时候都需要对方的网络地址和endpoint号。其实endpoint就相当于TCP/IP通信中的端口号。一个应用程序只要有一个endpoint。每个endpoint都有一个简单描述符（zigbee simple descriptor，即SimpleDescriptionFormat_t）。每个endpoint都能接收（用于输入）或发送（用于输出）串格式的数据。

2、Cluster

    一个endpoint是一个逻辑设备，可以包含多个Cluster，每个Cluster包含不同的属性（开、关是“灯控制” Cluster对应不同情况的attribute）。另外，网络拓扑结构中提到的cluster是集群树，包括家长（parent）及其子女(child)。网络拓扑中的Cluster是指的节点（物理设备）之间的关系，而通信中的Cluster号指的通信事务的标号。在有些文章中，cluster定义成设备通信的“串”。

    ZCL通过判断ClusterID来达到相应的作用。ID和功能形成一一对应关系，这样，在无线传输过程当中，就不需要传输大量指令，只需传输clusterID，然后通过clusterID就可以判断需要执行的命令了。这样既保证了数据的安全性和通信可靠性，又提高了通信效率。

3、Node

    node是物理设备，相当于Internet网络中的无线网卡。endpoint是逻辑工作端。

4、重要数组

    指针数组tasksEvents[ ]里面最终分别指向的是各任务存储空间

    指针数组tasksArr[ ]里面最终分别指向的是各任务事件处理函数

    这两个指针数组里面各元素的顺序要一一对应,因为后面需要相应任务调用相应事件处理函数.

Zstack里,对于同一个任务可能有多种事件发生,那么需要执行不同的事件处理,为了方便,对于每个任务的事件处理函数都统一在一个事件处理函数中实现,然后根据任务的ID号(task_id)和该任务的具体事件(events)调用某个任务的事件处理函数,进入了该任务的事件处理函数之后,再根据events再来判别是该任务的哪一种事件发生,进而执行相应的事件处理.pTaskEventHandlerFn 是一个指向函数(事件处理函数)的指针,这里实现的每一个数组元素各对应于一个任务的事件处理函数,比如SampleApp_ProcessEvent对于用户自行实现的事件处理函数uint16 SampleApp_ProcessEvent( uint8 task_id, uint16 events ),所以这里如果我们实现了一个任务,还需要把实现的该任务的事件处理函数在这里添加.

5、绑定

    绑定机制允许一个应用服务在不知道目标地址的情况下向对方（的应用服务）发送数据包。发送时使用的目标地址将由应用支持子层从绑定表中自动获得，从而能使消息顺利被目标节点的一个或多个应用服务，乃至分组接收。

    绑定指的是两个节点在应用层上建立起来的一条逻辑链路。在同一个节点上可以建立多个绑定服务，分别对应不同种类的数据包。此外，绑定也允许有多个目标节点（一对多绑定）。举个例子，在一个灯光网络中，有多个开关和灯光设备，每一个开关可以控制一个或以上的灯光设备。在这种情况下，需要在每个开关中建立绑定服务。这使得开关中的应用服务在不知道灯光设备确切的目标地址时，可以顺利地向灯光设备发送数据包。一旦在源节点上建立了绑定，其应用服务即可向目标节点发送数据，而不需指定目标地址了（调用zb_SendDataRequest()，目标地址可用一个无效值0xFFFE代替）。这样，协议栈将会根

据数据包的命令标识符，通过自身的绑定表查找到所对应的目标设备地址。在绑定表的条目中，有时会有多个目标端点。这使得协议栈自动地重复发送数据包到绑定表指定的各个目标地址。同时，如果在编译目标文件时，编译选项NV_RESTORE被打开，协议栈将会把绑定条目保存在非易失性存储器里。因此当意外重启（或者节点电池耗尽需要更换）等突发情况的发生时，节点能自动恢复到掉电前的工作状态，而不需要用户重新设置绑定服务。配置设备绑定服务，有两种机制可供选择。如果目标设备的扩展地址（64位地址）已知，可通过调用zb_BindDeviceRequest()建立绑定条目。如果目标设备的扩展地址未知，可实施一个“按键”策略实现绑定。这时，目标设备将首先进入一个允许绑定的状态，并通过zb_AllowBindResponse()对配对请求作出响应。然后，在源节点中执行zb_BindDeviceRequest()（目标地址设为无效）可实现绑定。此外，使用节点外部的委托工具（通常是协调器）也可实现绑定服务。请注意，绑定服务只能在“互补”设备之间建立。那就是，只有分别在两个节点的简单描述结构体（simple descriptor structure）中，同时注册了相同的命令标识符（command_id）并且方向相反（一个属于输出指令“output”，另一个属于输入指令“input”），才能成功建立绑定。

6、和TCP/IP协议的相似之处

    绑定，自然的想到了TCP/IP当中的绑定。在TCP/IP中，客户端和服务端都可以绑定，在绑定后，通信直接将数据通过send/recv函数发送/读取，不需要做过多的操作，在对应于一些特殊服务，比如常见的TFTP服务，总在相应的端口发生，因为，从此端口得到数据后，不需要做任何判断就可以知道是TFTP服务的数据。

    上边的绑定过程，TCP/IP和Zigbee绑定有相似之处，TCP/IP的端口相似与ZigBee的endpoint。而在通信的时候，即使知道是TFTP数据，也需要进一步判断，TFTP的细节，就类似于taskID中的taskEvents，每一个任务ID（taskID）中都有最多16个taskEvents与之对应，每一个endpoint中，还有不同属性的clusterID。