分享：ZigBee空中下载技术研究及其优化设计

　　无线传感网络是由大量体积小，供电资源有限，并配置一定计算能力和无线通讯能力的传感节点组成。对于传感网络系统，一定存在程序代码更新和维护的需求，但由于传感节点分散部署的特点，使得网络远程节点的程序升级变得异常困难。为此，空中下载（over the air， OTA）提供了一种有效的更新手段。本文首先介绍基于 ZigBee协议的OTA系统，并在CC2530F256 硬件平台作出验证。最后，在Z-Stack协议栈中，设计出一种镜像页请求的OTA更新方式，并通过实验测试，与原有的镜像块请求方式进行了比较分析。实验结果表明，镜像页请求方式可以大大减少网络的更新流量，从而提高节点的更新效率。

　　引言

　　近年来，由于硬件成本的下降以及制造工艺的进步，无线传感网络技术逐步取得大规模商业应用，如医疗监控，智能电网和智能家居［1］。对于任何一个嵌入式计算机系统，都存在程序代码升级的需要。在无线传感网络的应用环境中，由于大量节点分散性部署，节点的回收工作变得异常困难，使传统的物理连接的程序更新手段不再适用。对此，一种有效的解决方案是OTA技术。

　　空中下载技术起源于移动电话网络，能够通过移动通信网络（如GSM）对SIM卡数据进行远程管理与更新［2］。借鉴于移动通信网络，空中下载技术也能应用于无线传感网络。与网络层的路由协议［3］不同，代码分发协议［4］是支撑OTA的核心技术。前者关注的是如何迅速高效地中转网络中的数据信息，后者关注的是如何向各节点完整无误地传递更新代码［5］。目前，成熟的代码分发协议已经提出，典型的如基于TinyOS系统的Xnp［6］与Deluge［7］，前者提出了单跳网络的更新方案，后者支持多跳网络更新功能，但都需要具体的硬件平台支持。

　　本文移植并验证了一种基于ZigBee协议［8］的空中下载技术，其分发协议支持点对多传输更新功能，多跳网络的代码分发功能由路由协议支撑。在Z-Stack协议栈［9］下，仅仅支持镜像块请求功能，更新效率并不理想。针对此问题，设计出一种高效的镜像页请求功能，能够提高点对多的传输更新效率，并减少网络流量。

　　1. OTA概述

　　ZigBee协议规范使用了IEEE 802.15.4定义的物理层（PHY）和媒体介质访问层（MAC），并在此基础上定义了网络层（NWK）应用层（APL）。针对无线传感网络重编程技术的需求，ZigBee联盟在原有协议的框架上，提出了一种OTA规范［10］，作为一个系统可选的功能模块。

　　图1为OTA系统的结构示意图，整个系统主要由3部分构成：OTA应用控制台，OTA服务器，OTA客户端。其中OTA应用控制台是上位机管理软件，负责OTA镜像管理，网络节点信息陈列与发送更新命令；OTA服务器负责向远程节点无线发送升级镜像，并通过串口与上位机连接，向应用控制台汇报各节点更新进度信息等；OTA客户端是指远程网络中的待升级节点。

　　根据代码的更新范围，分为整体代码更新与基于差异性的更新［11］。前者是把所有可执行的二进制代码打包成一个镜像分发给节点，后者是通过比较新旧镜像文件之间的差异，产生一个编辑脚本，然后把这个脚本分发到网络中的节点进行差异性更新。毫无疑问，前者需要传输的数据量较大，一般为上千字节级，增加了网络负担，但代码更新操作相对简单；后者发送的数据量虽少，但增加了更新过程的复杂度，对处理器产生更大的负担，带来较大的能源损耗。由于ZigBee协议对网络节点的低功耗标准有严格的要求，其OTA代码分发协议采用前者的镜像传输方式。

　　服务器与客户端之间的数据交互过程如图2所示。首先OTA服务器通过单播或者广播方式向OTA客户端（节点）发送镜像公告（Image Notify），指示新镜像已经准备好。收到镜像提示信息后，节点就向OTA服务器发送查询下一个镜像请求（Query Next Image Request），此请求信息包含了当前运行固件的版本信息。收到该请求后，OTA服务器作出响应（Query Next Image Response）。随后，OTA客户端与OTA服务器通过二次握手机制，镜像块请求（Image Block Request）和镜像块响应（Image Block Response），完成整个镜像传输过程。当OTA客户端收到镜像块数据后，把块数据写到第二存储区（客户端当前运行的镜像保存在第一存储区）。完成下载后，节点将对下载后的镜像进行CRC校验。最后，当节点需要更新时，把新镜像从第二存储区复制到第一存储区，新固件开始运行，从而完成了整个升级过程。