重谈Zigbee的绑定问题

重谈Zigbee的绑定问题
(By   kennan, 2011.7.23)
注：本文档以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、C、D等多个节点，A性质是Outcluster，B、C、D的性质是Incluster，你可以通过按键策略来在一定时间内允许B、C、D中的任何一个开启被Match的功能，同时A发起Match请求(广播的)，那么被允许Match的节点就会在收到请求后将自己的信息返给A，A在得到rsp的时候来处理绑定，如果你还想让A绑到其它节点上，可以依次这么做。这种方式其实同第一种操作过程类似，只不过不需要协调器的参与。
3、第三种方式(Bindreq,Unbindreq)
例：假设你有一个主控(可能是ARM板子，可能是PC……)，并且有一个Zigbee节点A通过串口或者U口等方式连在了主控上，主控可以给A发命令(什么命令你要自己定义、自己实现了)；你还有一个B节点是开关，还有一个C节点是灯。你想让在B上建立绑定表，以用来控制C。那么你可以通过主机命令A向另外的节点B发起BindReq要求，主机发给A的命令中会带着C的一些信息(主机如何有C的信息？这种场合下，主机应该了解整个网络的细节，至于如何了解。。。。，以后再说)。这样，A就可以向B发起BindReq请求，这个请求的参数中包含了必要的C的信息，B在收到请求后就会建立起关于控制C的绑定表，以后B可以通过开关控制C了，也不再需要A的参与。这种方式适合那种集中管理的网络。
4、第四种方式(手工)
例：你还是有一个主机，主机上有Zigbee节点A能够串口或者U口通信。你想由主机来深入地管理整个网络上的绑定情况，你就可以通过主机给A发命令，告诉A给某一个节点发命令，让它去建立、删除、追加。。。。绑定表。这种方式实际上最灵活，但是需要用户(也就是你,写程序的)的工作最多，用户也需要很清晰的思路去管理绑定表，要是不小心管理错了，就杯具了。

还要补充说明的是：为什么要用绑定？尤其是3，4两种，都知道了被绑定节点的具体信息了？绑定有必要吗？实际上，在每一个节点入网的时候，都会向网络自动发出DeviceAnnce报告（这里面包含了节点的IEEE地址和新得到的短地址)，告诉大家自己来了，在看到这个DeviceAnnce的时候，每个节点都会根据IEEE地址信息更新自己的绑定表的，这样你就不怕短地址变化啦。还有的时候你可能根本就不知道某些节点的具体信息，尤其是EP信息，在这种情况下，如果你没有主机来统一管理，再不用绑定，两个节点想通信是不可能的。

分析得很全面，毛毛老师辛苦了

分析得很全面，毛毛老师辛苦了

顶起。好贴！！

建议将一种绑定从原理到程序实现讲的清清楚楚好一点，只要一种方式搞清楚了，其他的一通百通

呵呵。绑定原理程序讲解网上很多的。不过偏偏这几种绑定方式原理完全不同喔。另外，这个帖子是从概念上区分几种绑定之间实现方式的本质区别。等你真正需要在这几种绑定方式选择的时候，就知道我在说什么了。

按键进行绑定的过程我还在看

分析的很棒  以前也在想两个enddevice要怎样去实现绑定  但是苦于对程序看的不是很透  也找不到一个文档说明  现在对绑定这块的实现方法有了个宏观的理解  谢谢毛毛老师

楼主好，学习过绑定过程后，对绑定表的组成元素起了疑问。绑定表条目放置了些什么？BindingEntry_t结构体中给出了srcEP/dstEP/numClusterIds/clusterIdList[MAX_BINDING_CLUSTER_IDS]

之前看文档，简单的以为上层不提供目的地址，以oxfffe替代，APS会根据clusterid寻bindingtable中匹配的条目，以获得目的地址，有多个则发多份。实践过程中遇到疑问，APS查表的过程是仅仅根据clusterid？还是必须同时考虑ep？ep在AF_DataRequest发送时必须给出。假设场景：一个开关已经点对点绑定好了多个灯，灯的ep不全相同，clusterid都一样。

多谢楼主，分析的很透彻。绑定的流程以及概念我花了很长时间才彻底搞清楚。都是一句句抠代码的。如果早看到这篇文章就不用那么辛苦了啊。哈哈。