新浪博客

转载【深度分析Zigbee】第四讲：Zigbee网络中的三种设备类型详解

2015-03-12 20:13阅读：

http://blog.sina.cn/dpool/blog/u/3539652391

在Zigbee网络中，一共有3种设备类型：协调器、路由、终端。如果我们打开Zstack协议栈的SampleLight工程（位于：X:\Texas Instruments\ZStack-CC2530-2.5.0\Projects\zstack\HomeAutomation\SampleLight\CC2530DB），在Workspace的下拉菜单中分别可以看到CoordinatorEB、RouterEB和EndeviceEB，分别对应着上面提到的三种不同的设备类型，那么这3种设备在ZIgbee网络中究竟起着什么样的作用呢？
转载【深度分析Zigbee】第四讲：Zigbee网络中的三种设备类型详解

首先最为关键的就是协调器了，它是每个独立的Zigbee网络中的第一个设备，也是唯一一个协调器设备，只所以这么说是因为协调器最为重要的一项工作就是组建网络。那么在组建网络的过程中，协调器都做了哪些工作呢？在这里我们要特别关注协议栈里的一个文件f8wConfig.cfg，这个文件主要涉及到协议栈一些关键参数的配置，大家可以看下这个文件的内容，一些关键的地方我们后面会逐渐讲到。
在f8wConfig.cfg中，可以找到这样的语句：-DDEFAULT_CHANLIST=0x00000800 // 11 - 0x0B，从字面意思不难理解DEFAULT_CHANLIST是指默认信道的意思，Zstack默认的采用信道11。那么信道11和0x00000800有什么关系呢？我们把0x800写成二进制的形式：1000 0000 0000，这里的每一位都代表一个信道的开关，最右端代表的是0信道。聪明的朋友很自然就会问：如果我使用11和12两个信道，DEFAULT_CHANLIST是不是就应该配置成0x00001800。对的，You got it！f8wConfig.cfg中还有一个跟网络组建息息相关的参数：-DZDAPP_CONFIG_PAN_ID=0xFFFF。ZDAPP_CONFIG_PAN_ID是用于配置默认的网络标号（NETWORK ID），这里的NETWORK ID是用于区分不同网络设备的标识，和我们计算机局域网中网关类似。每个局域网中的设备只能和本网络中的计算机通信，也就是同一网关的计算机才可以相互通信。Zstack默认的ZDAPP_CONFIG_PAN_ID设置为0XFFFF，这并不是说设备会将FFFF作为自己的NETWORK ID，而是说协调器会随机生成一个16位的NETWORK ID。假如我们将ZDAPP_CONFIG_PAN_ID配置为0X1234，那么协调器会“优先考虑”将1234作为自己的NETWORK ID。
协调器在通电之后，会进行信道扫描，以便查找附近是否还有别的Zigbee网络。如果协调器发现在同一信道中（即11信道）有别的Zigbee网络存在，那么协调器会检查对方的NETWORK ID和自己ZDAPP_CONFIG_PAN_ID所配置的NETWORK ID是否冲突。假设网络A已经存在，它的NETWORK ID为0X1234，，协调器B在通电之后想要组建网络B，它和网络A使用同一个信道，默认的ZDAPP_CONFIG_PAN_ID配置为0X1234。协调器B在检测到网络A的存在并获知A的NETWORK ID和自己默认的NETWORK ID一样，便会放弃0X1234，转而考虑0X1235。在发现0X1235并未被周围的网络所占用后，协调器B便以0X1235作为自己的网络标识，组建新的zigbee网络。协调器的这一特性也注定了在一个网络之中有且只有一个协调器。
协调器在组建完成网络之后便和普通的路由器没有区别了，那么路由器又有哪些特点呢？提到路由器大家自然而然会想到家里所使用的WIFI路由器，但是zigbee的路由器却与之不同。在zigbee网络中，路由器起着非常关键的作用。Zigbee自组织、自修复、拓扑网络结构等等无一不是通过路由来实现的，可以说，路由是zigbee的灵魂。在协调器完成网络组建之后，我们再为一个路由通电，路由的ZDAPP_CONFIG_PAN_ID被配置为0X1235，在这种情况下，该路由只能加入到NETWORK ID为0X1235的网络中。即便是网络中只存在NETWORK ID为0X1234的A网络的设备，该路由也不会加入到A网络中，它将一直处于网络搜寻状态，直到找到NETWORK ID为0X1235的路由设备并加入到改网络中。在这里有一个大家经常遇到的问题：假如网络B中已经有了NETWORK ID为0X1235的一个路由和一个协调器，它们肯定是可以直接通信的，如果我把协调器关闭再打开，等它再次组建好网络之后却发现协调器和路由不能通信了，这是为何？我们知道，协调器再次上电之后还是要组建网络的，当它搜寻周围网络环境发现了NETWORK ID为0X1235的路由，那么它意识到存在NETWORK ID为0X1235的网络，那么它将不会使用0X1235作为NETWORK ID，很可能它组建了NETWORK ID为0X1236的新网络C，因此它也就不能和NETWORK ID为0X1235的路由通信了。
终端设备是Zigbee实现低功耗的核心，它的入网过程和路由是一样的，和协调器、路由不一样，终端并不是时刻都处在接收状态的，大部分情况下，它都将处于IDLE或者低功耗休眠模式。它会定时同自己的父节点进行通信，询问是否有发给自己的消息，这个过程被形象地成为“心跳”。心跳周期也是在f8wConfig.cfg里配置的：-DPOLL_RATE=1000。Zstack默认的心跳周期为1000ms，终端节点每1s会同自己的父节点进行一次通信，处理属于自己的信息。因此，终端的无线传输是有一定延迟的。对于终端节点来说，它在网络中的生命是依赖于自己的父节点的，当终端的父节点由于某种原因失效时，终端能够“感知”到，并开始搜索周围NETWORK ID相同的路由设备，重新加入网络，并将该设备认作为自己新的父节点，保证自身无线数据收发的正常进行。
本文为与非网月光码头原创，未经允许谢绝转载。
更多内容请见：【深度分析Zigbee】Zigbee技术知多少？资深大牛对对碰
----------------------------
主讲嘉宾简 介：网名：月光码头。毕业于中国科学院电子学研究所，主要从事zigbee物联网方向的应用研究，尤其擅长TI RF芯片、和Silicon Lab MCU芯片的使用。现就职于上海理滋芯片设计公司，任研发部门经理，主要从事智能家居产品的设计开发，拥有5年多的zigbee软硬件开发经验。
------------------

我的更多文章

下载客户端阅读体验更佳

APP专享