无标题 重谈Zigbee的绑定问题.pdfVIP

无标题 重谈Zigbee的绑定问题 注：本文档以TI的2.3.1协议栈和CC2530为基础。 绑定是Zigbee中非常重要的一个概念，想必大家都看了很多文章，其中以“Zigbee四种绑定方式在TI_Z-Stack协议栈中的 应用”最为典型，此文我也读过几遍，收货颇丰。此外飞比(Feibit)论坛上也有帖子讲解了EndDeviceBinding蛋疼的传来 传去机理，分析的也相当透彻。我这里不在想解释具体的各种绑定方式的代码实现和机制，而是简单说明一下各种绑定机 制的特点，希望大家能够从应用层面上概念性地理解和认识绑定，然后针对各种机制的应用场景加以举例。 一、绑定方式再解释 Zigbee绑定的四种方式： 1、 两个节点分别通过按键机制调用ZDP_EndDeviceBindReq函数 即：在一定时间内两个节点都通过按键(其他方式也可以)触发调用这个函数 特点：这个函数的调用将会向协调器发出绑定请求(具体如何调用及参数设置请看协议栈相关代码)，如果在16S(协议栈默 认)时间内两个节点都执行了这个函数，协调器就会帮忙实现绑定，这个过程的代码很复杂，我不想说。绑定表应该是存在 OutCluster那边，即这两个节点应该是一个输出控制命令，一个接收控制命令，绑定表存在输出控制命令这边，至于如何 实现，有兴趣同学可以继续研究代码。 注意：这种方式一定需要协调器，否则不行；但是一旦绑定成功，不再需要协调器，协调器只是帮忙绑定的一个第三方； 虽然叫做EndDeviceBind，但是不局限于End Device，路由器也一样用；重复上述操作会解绑定，也就是说这是一个乒乓方 式。 2、 Match方式 即：一个节点可以通过调用afSetMatch函数允许或禁止本节点被Match(协议栈默认允许，可以手工关闭)，然后另外一个节 点在一定的时间内发起ZDP_MatchDescReq请求，允许被Match的节点会响应这个Req，发起的节点在接收到RSP的时候就会自 动处理绑定。 特点：不需要别人帮忙，只要在网络中的节点互相之间就可以实现，但是前提是他们一定要Match，即一方的outcluster至 少有一个是另外一方的incluster，这种方式在很多时候用起来比较方便。 注意：如果同时有多个节点(一个节点上的多个端点也一样)处于允许Match状态，那么req的这个节点可能会收到一大票满 足Match条件的rsp，那么你发起req的节点要在这个处理上多下功夫了。 3、 ZDP_BindReq和ZDP_UnbindReq方式 即：应用程序通过调用这两个函数实现绑定和解绑定，这种方式很有趣。具体说来是为了让A和B绑定到一起，还需要一个 节点C。例如：你想A控制B，那么这种方式是由C发出bind或unbind命令给A(发给谁谁就处理绑定、并负责存储绑定表)，A 在接收到req的时候直接处理绑定，也就是添加绑定表项，并且这个过程B并不知道。但是A知道绑定表里面有了关于控制B 的记录，并且这种方式可以实现一个节点绑定到一个Group上去。 注意：这种方式需要知道A和B的长地址，具体协议栈拿长地址做什么用，有兴趣的就去挖代码好了。 4、 手工管理绑定表 即：通过应用程序调用诸如bindAddEntry(函数在BindingTable.h文件中定义，具体实现被封包了)来实现手工绑定表管 理，这种方式自由度很大，也不需要别的节点参与，但是应用程序要做的工作多一些，整个绑定表都是你说了算。 注意：这种方式你需要事先知道被绑定的节点信息，诸如短地址，端点号，incluster和outcluster这些信息，否则你没办 法把那些函数的参数填进去。 二、应用场合举例 1、第一种方式(enddevicebind) 例：网络中有协调器存在，另外有两个节点A和B，这两个节点具有互补特性(即A节点的incluster是B节点的outcluster)， A和B结点都有按钮可以通过程序来触发EndDeviceBind的调用。在这种情况下，你只要在规定的时间内分别按A和B上的某个 按钮，绑定就会在协调器的帮助下自动完成。这适合于节点很方便操作，没有被装墙里或者无法接触的地方；绑定完成 后，具有outcluster性质的B节点即可以通过绑定方式给具有incluster性质的A节点发消息，但是不能指望反过来由A发消 息给B，因为A节点根本就没有关于B的信息，绑定表是存在B中的。 2、第二种方式(Match) 例：网络中不一定有协调器存在，但是有A、B