原创 [转载]如何开发更具鲁棒性的ZigBee解决方案

　　通过精心地定义ZigBee规范中的网络和应用层，ZigBee联盟希望独立的设备制造商能够开发出可以互操作的优秀终端产品。成员们对ZigBee芯片组给予了很高的期望，希望能够帮助OEM制造商进一步降低成本，从而为系统集成商和终端用户提供低成本的终端产品。

　　随着市场需求的增长以及大量的志愿者投入研究ZigBee规范，现在已经到了将一个低成本、低功率的无线网络的可行性方案提供给人们的时候了。本文将讨论设计和集成一个ZigBee方案时应该考虑的一些重要因素。文中的许多内容来自MaxStream公司在研发其首套ZigBee认证产品——XBee OEM无线模块过程中所获取的经验。

　　ZigBee一览

　　1. ZigBee网络

　　ZigBee定义了三种节点类型：协调器、路由器和终端设备。协调器可以通过选择网络的工作信道和个域网识别标志(PAN ID)来启动一个ZigBee网络。一旦网络启动，路由器和终端设备就能加入网络。协调器和路由器都能通过网络发射和路由数据，并且允许其它的路由器和终端设备加入。终端设备不能参与路由数据，因此在不发射和接收数据时可以休眠。当设备加入ZigBeePAN时，设备间的父子关系即形成，加入的设备为子，允许加入的设备为父。一个简单的ZigBee网络如图1所示。

　　2. ZigBee寻址

　　ZigBee设备支持两种地址类型：一种是64位IEEE地址，另一种是16位网址。64位地址在所有ZigBee设备之中是唯一，其中包含一个由IEEE分配、也是全球唯一的24位制造商特定组织识别符(OUI)。

　　当设备加入ZigBee个域网时，它可以从允许其加入的父设备上获取16位网址。该网址在个域网内被规定为唯一。该网址用于数据传输和数据包路由。用于路由数据包的路由表存放着各个目标设备和下一跳设备的网络地址。因此个域网的各设备都必须有明确且唯一的网络地址，以保证数据能到达正确的设备。

　　图1：简单的ZigBee网络。

　　ZigBee联盟正在加紧研究解决这些地址问题的对策，并将解决方案整合到ZigBee规范中去。但是，一些协议栈和模块提供者，譬如MaxStream公司已经研发出解决这些问题的方法。

　　3. ZigBee路由

　　ZigBee包括一个用于AODV网状路由的基本框架。如果一个设备需要向其它设备发送数据，它首先需要发现一条可能要经过多台路由器才能到达目标设备的路由。网状路由允许动态地建立、修改或替换传输路径，从而保持设备间有一条可靠的路径。

　　然而，除网状路由之外，ZigBee规范还经常依赖树状路由。在树状路由中，数据将在源设备和目标设备之间的“树”状路由上严格地按照从父到子或从子到父的路径传输。

　　图2：树状路由(左)和网状路由(右)的演示。

　　当节点移动或删除时路由可能出现问题。这时如果单个节点无法从一条路由中隔离开来，那么整个树状路由就无法定位故障点。而网状网络就能在现有路由发生故障时发现一条新路由。

　　ZigBee协议栈按照规范采用树状和网状路由的ZigBee1.0标准而建立。两种路由之间的交互是相当复杂的，而且协议栈之间的交互也是不断变化的。但是，增强型ZigBee规范(2006)增加了一个nwkUseTreeRouting功能，该功能可以使整个树状路由彻底断开，再由(NLME)路由发现请求(route-discovery-request)原语根据需要强制进行路由发现。这些功能可以解决与树状路由相关的问题，并且允许开发商充分发挥网状路由的优势。

　　图3：当所建通道上的一个节点失效时树状路由(左)和网状路由(右)的性能。

        4. ZigBee互操作性

　　ZigBee规范包括一些可以用来定义各种网络的配置功能。开发商可以很容易地配置以下参数：目标系统中的路由器和/或终端设备数量;安全级别;路由表和邻居表规模;网络最大深度(从协调器到最远派生设备的连接深度);协调器/父路由器允许的子路由器和终端设备的最大数量。

　　ZigBee联盟研发出了为这些不同协议栈建立通用设置的公共框架-可配置参数表。为了完成框架(如家庭控制协议栈框架就定义了开灯、关灯、或切换一个灯光的簇ID)内的共同任务，该框架还定义了一些称作簇ID的接口。

　　终端设备必须围绕可互操作的同一框架来设计。因此，应用开发商必须设置他们的协议栈参数以匹配公共框架所规定的参数值，从而确保与采用同一框架的其它解决方案的互操作性。另外，开发商也可以为了满足其设计而通过采用专用(定制)的框架来自由修改协议栈参数。不过，在专用框架中所定义的簇ID不具备与基于公共框架的设备互操作的能力。

　　由于开发商具有选择框架的灵活性，从而并非所有的ZigBee设备都能互操作。虽然这种灵活性一开始会在市场上引起一些混乱，但允许开发商决定其产品是否要与其他供应商的设备进行互操作。在不需要互操作性的场合，功能强大的ZigBee可以围绕一个专用框架进行开发，并剪裁协议栈参数来满足特殊应用需求。

　　5. ZigBee认证

　　经认证的ZigBee硬件平台(芯片组和模块)和软件层(PHY层、MAC层和网络层)必须做ZigBee验证平台(ZCP)测试。通过ZCP认证的硬件平台和软件协议栈表明适用于ZigBee终端产品的研发。

　　在ZigBee兼容平台上开发的终端产品可以直接做产品认证测试。终端产品认证允许产品出现在ZigBee认证产品列表中，并打上ZigBee标识。ZigBee联盟已经开发了相关测试标准来认证基于公共和专用框架的终端产品是否是合格的ZCP产品。

　　尚未解决的ZigBee问题

　　ZigBee规范正在继续改进并将提供更多的功能，但同时ZigBee联盟也认识到该规范还存在一些问题：

　　1. 更改网络地址

　　如前所述，在ZigBeePAN中分配给节点的网络地址可以改变，甚至在某些条件下会重名。这就使得网络必须解决不可靠的寻址机制，以确保将数据发送到正确的设备中。

　　ZigBee联盟正在考虑改变寻址机制，以提供更具鲁棒性的寻址机制。同时，包括MaxStream在内的一些模块提供商研发出了基于唯一性64位地址的解决方案，能确保可靠的数据传输。

　　2. 固定工作信道

　　由于ZigBee采用802.15.4 MAC/PHY规范中所规定的直序扩频(DSSS)调制，因此可以工作在固定信道。在通过能量扫描筛选出具有较高能量的信道后选出工作信道。但是，一旦初始能量扫描完成后，在所选的信道质量变坏时ZigBee网络无法重置新的信道。因为有许多设备(包括蜂窝电话、微波和802.11网络)占用2.4GHz频段，因此这可能是一个大问题。目前，终端设备开发商必须在其设计中解决干扰问题。ZigBee联盟也在研究此问题的解决方案。ZigBee规范的新版本可能会解决此问题。 

        3. 容量限制

　　ZigBee刚开始打算用64K闪存。但是，对于需要可靠的数据传输、网状组网、更高安全等级、低功率的终端设备等高级应用而言，这一空间将很难满足802.15.4 MAC/PHY、ZigBee网络层以及其它所期望的应用功能要求。随着ZigBee的持续发展，先进的应用似乎需要迁移至带有更多闪存的微控制器。

　　ZigBee实现方案

　　随着市场需求的增长和ZigBee自身要素的改善，部署一个经认证的ZigBee方案将具有极高的价值。随着ZigBee规范的最新进展，可以采用现有的ZigBee架构开发出可靠的ZigBee解决方案。开发商必须在从零开始研发自己的软硬件还是集成已经验证过的ZigBee模块解决方案之间作出慎重选择。

　　为了开发一个鲁棒的ZigBee解决方案，MaxStream公司在ZigBee规范方面付出了大量的时间和精力。以下一些建议都来自于我们的实际经验，对那些打算采用ZigBee解决方案的开发商将有所裨益。

　　1. 硬件选择

　　在开发ZigBee解决方案时，首先是要确定硬件平台。通常，硬件平台由一个芯片组或模块组成。如前所述，ZigBee联盟定义了一个用于平台验证的ZigBeeZCP，可用来验证平台是否支持ZigBee方案。如果ZigBee终端产品想携带ZigBee标识并作为ZigBee认证产品上市，所用的硬件平台和ZigBee软件协议栈必须被ZigBee联盟认证为ZigBee兼容平台。

　　2. 采用模块

　　模块提供了比芯片组更多的优点。选用模块可以为开发商节省成本，省去痛苦的RF前端设计、样机设计、产品测试和EMC测试。模块提供商已经通过了严格的应用测试和网络协议栈测试，并且已经加入简化ZigBee接口的一些功能。特别是MaxStream XBee模块还提供了固件，这些固件提供了鲁棒性的网状组网、可靠寻址甚至信道迁移策略，为的是解决尚未解决的ZigBee问题。

　　如果模块固件不能满足某个特定应用的需求，某些模块提供商还提供了一个灵活的选择。某些情况下(包括MaxStream XBee模块)，设计师能够在模块硬件上开发自己的应用，并定制满足其需求的ZigBee应用。这样的方案虽然需要一些固件开发，但仍然节省了与RF设计、样机设计和EMC测试相关的时间和成本。

　　3. 采用芯片组

　　如果采用芯片组，设计师必须准备支持无线设计所需的大量设计、测试和生产要求。在定制板上使用芯片组要求支持硬件生产工艺，包括板级测试、调试和返工。如果选用此方案，必须从IEEE获得一个24位的OUI，以便为每个设备分配一个唯一的64位地址。

　　当定制板采用芯片组时，设计师还必须选用一个ZigBee网络层协议栈。设计师必须将协议栈连接到他们的硬件上，细心地测试ZigBee应用，并评估网络性能。上述未解决的许多问题甚至所有的ZigBee问题都必须在应用中解决，这将大大地增加研发时间方面的开销。

　　4. 设备开发

　　如果必须在芯片组或模块平台上开发定制固件，下面的步骤将会有用。
5. 选择框架类型

　　在着手开发ZigBee设备前，设计师必须确定是公共框架还是专用框架更能满足需求。设备是需要与与其它普通的ZigBee产品兼容，还是只适合特定的应用?协议栈参数是否需要调整到最佳性能?如果专用框架更合适，就需要向ZigBee联盟申请一个专用框架。

　　6. 确定路由策略

　　开发商应该清楚是否允许使用树状路由。对于简单的静态网络，树状路由将足够。如果某些节点有可能去掉，或者需要可靠的数据传输，树状路由就显得不足了。此时，就需要花些时间对协议栈何时调用路由发现进行评估。

　　如果所选的ZigBee协议栈符合增强型ZigBee规范，应用层就可以利用路由发现请求原语和nwkUseTreeRouting属性来控制路由发现和去除树状路由。如果采用的是网状路由，开发商应该考虑当所有的路由表入口都被占用的情况下系统将如何执行。因为ZigBee规范并不对老化路由和过期路由表条目进行监管，因此一些ZigBee协议栈实现不会去除旧的路由表条目。一旦所有的路由表条目被占用，设备将不能再参与路由发现。如果协议栈无法老化或取代过期条目，应用层就应该加入自己的监管措施来实现。

　　7. 考虑固定信道操作

　　对于许多应用，即便是存在突发干扰，ZigBee网络也可以可靠地工作在固定信道上。但是，对于那些必须与其它系统共同工作在同一频段的系统，或者无法允许数据包偶然丢失的系统，则有必要支持信道的迁移。因为目前的ZigBee规范还没有定义信道迁移机制，应用开发商可以自行决定将网络迁移到一个新信道的条件，并开发相应的实现方案。

　　8. 克服寻址限制

　　在许多应用中，目前的网络地址分配机制是足够的。但是，为了防止地址重复的可能，更具鲁棒性的ZigBee解决方案应具有复位网络地址的能力(如协调器被替换时)。

　　由于设备的网络地址不可靠而且会变化(例如，一个加电周期或复位后设备无法找到其父设备)，应用层可能也需要一个能够唯一识别每个节点的解决方案。

　　为了确保将数据发送到正确的设备上，包括MaxStream XBee在内的一些ZigBee解决方案依赖于唯一的64位地址。如果采用这样的方案，应用层中就必须有相应的配置功能，以便在传送数据之前将64位地址转换成16位的网络地址。

        9. 测试

　　测试应该包括验证系统如何对本文所述的应用场景反应。当路由器关掉时系统有什么反应?在工作信道上出现干扰时系统将如何执行?如果设备接收到一个新的网络地址，该新地址如何被发现?需要重申的是，一些模块和协议栈开发商已经开发出了解决这些问题的配置方案，从而大大减轻了应用开发商的开发负担。

　　本文小结

　　虽然ZigBee在前进道路上面临一些重要的问题，但ZigBee联盟具有坚强的毅力、伟大的领导力，还有大批为标准升级积极贡献的优秀设计师。即使是初级阶段，能够为设计师提供强大的网络层功能和应用层灵活性的ZigBee规范的重要基础工作也已经完成。

　　由于在嵌入式设备领域中有着强大的领导联盟，ZigBee正成为嵌入式设备市场上的重要角色。目前ZigBee联盟正在讨论配置问题以便增加ZigBee价值，并试图解决ZigBee规范中尚未解决的许多遗留问题。经过ZigBee认证的模块和网络协议栈正在开始面市，他们提供强大的网状解决方案，并有效地解决了目前ZigBee规范中存在的许多(即便不是全部)限制。现在正是开始开发可靠的、低功率和更高性价比的ZigBee解决方案的时候了。