本文首先介绍基于ZigBee协议的OTA系统，并在CC2530F256硬件平台上进行验证。在Z-Staek协议栈中，设计出一种镜像页请求的空中下载(Over the Air，OTA)更新方式，并通过实验测试，与原有的镜像块请求方式进行了比较分析。实验结果表明，镜像页请求方式可以大大减少网络的更新流量，从而提高节点的更新效率。
本文移植并验证了一种基于ZigBee协议的空中下载(OTA)技术，其分发协议支持点对多传输更新功能，多跳网络的代码分发功能由路由协议支撑。在Z-Stack协议栈下，仅仅支持镜像块请求功能，更新效率并不理想。针对此问题，设计出一种高效的镜像页请求功能，能够提高点对多的传输更新效率，并减少网络流量。
1 OTA概述
ZigBee协议规范使用了IEEE 802．15．4定义的物理层(PHY)和媒体介质访问层(MAC)，并在此基础上定义了网络层(NWK)和应用层(APL)。针对无线传感网络重编程技术的需求，ZigBee联盟在原有协议的框架上，提出了一种OTA规范，其作为一个系统可选的功能模块。OTA系统的结构示意图和服务器与客户端之间的数据交互过程略——编者注。
2 OTA系统设计
本文的OTA系统基于TI公司的ZigBee SoC芯片CC2530F256设计，包括硬件与软件的设计。
2．1 硬件系统
CC2530F256内部集成一个增强型8051单片机，拥有8 KB SRAM和256 KB内部Flash存储器。内部Flash主要用来保存程序代码和常量数据。由于传统8051代码存储空间寻址范围只有64 KB，CC2530把内部256 KBFlash分成8个bank，每一个bank大小是32 KB，通过寄存器FMA P．MAP[2：0]选择不同的bank映射到代码存储空间，解决了寻址空间受限的问题。
对于OTA客户端，启动代码位于bank0的0x0000～0x0800地址区域，大小为2 KB。其余的254 KB的Flash空间，用来存储当前固件和其他信息。值得注意的是，0x0888～0x088B区域存放了CRC校验信息，0x088C～0x0897区域存放了PREAMBLE，包括镜像大小、制造商ID、镜像类型和镜像版本号信息。另外，bank7最后的14 KB空间(0x7C800～0x7FFFF)用作非易失性(None Volatile，NV)变量区(12 KB)和特定信息保留区(2 KB)。
OTA系统升级方案有两种，分别是片内Flash升级和片外Flash升级。考虑到一般程序固件大小都超过128KB和以后程序功能升级的扩展性，本文采用片外Flash的方案。采用的片外Flash(M25PE20)容量为256 KB，通过SPI总线与CC2530之间传输数据。
2．2 软件系统
对于基于任务事件轮询机制的Z-Stack工程，默认没有添加OTA功能。如果节点需要开启OTA功能，首先需要烧写OTA的启动代码。当节点完成镜像接收之后，对新镜像进行CRC校验，并清空当前镜像的CRC信息，然后重启。当节点重启后，首先跳转到启动代码的地址，开始执行如图1所示的工作流程。
3 OTA的镜像页请求实现
根据ZigBee OTA的规范，OTA客户端向OTA服务器请求镜像的方式有两种，分别是镜像块请求与镜像页请求。镜像块请求的OTA更新方式效率较低。
本文根据ZigBee OTA的规范，在Z-Stack协议栈上设计出镜像页请求的更新方式。页请求命令与块请求命令类似，在数据帧当中附加了镜像页大小与响应间隔信息。当OTA服务器收到一次页请求后，在一定时间间隔内多次向节点发送块响应，免去了多次块请求。其中，块响应的次数由镜像页大小决定，时间间隔由响应间隔设定。正因为请求命令的锐减，能够大大减轻整个网络流量的负担，并提高节点的传输更新效率。
Z-Stack运行在一个OSAL操作系统上，OSAL是一种基于任务事件调度机制的操作系统。每个任务包含若干事件，每个事件对应一个事件号。当一个事件需要产生时，可以通过API函数设置相应的事件号，然后提交给操作系统调度触发。本文设计的镜像页请求功能正是基于这种机制。OTA服务器的镜像页请求处理流程如图2所示，OTA服务器为每一个请求更新的节点分配一个事件号，并通过请求节点的短地址索引，设置特定的事件。进入事件后，OTA服务器通过串口向OTA应用控制台请求镜像数据块，并向节点发送镜像块数据。通过把事件添加到定时器链表，就能够以响应间隔为时间单位，循环发送镜像块数据，直到累计的发送镜像块大小等于节点的请求镜像页大小，从而完成一次镜像页请求的传输过程。
Z-Stack协议栈有一个MAC定时器为操作系统提供计时。该定时器以每1 ms为单位，更新系统的定时器事件链表。定时器事件链表如图3所示，链表的每一个结点记录了任务号(task_id)、事件号(event_flag)，计时时间(timeout)和下一个结点地址(*next)。图中的ZCL_OTA_MT_ READ n定义为每个请求节点对应的事件号，Response SPACing即为节点请求的响应间隔，把两者添加到链表当中。当计时时间减为0后，系统自动设定对应的事件号，从而使OTA服务器循环地向OTA应用控制台索取镜像块数据，并向节点发送镜像块响应。
OTA服务器处理镜像页请求的部分代码段如下：
4 验证与分析
4．1 功能验证
为了验证OTA功能，在CC2530F256平台上搭建一个小型树状网络，并使用PACket Sniffer对OTA更新时的节点进行抓包分析。4个传感节点的固件并没有添加温度采集功能，所以温度显示为0。在新的固件中添加了温度采集函数，用于验证OTA更新成功。
对于某些特定应用，需要节点更新固件后能够保持原来的网络拓扑结构。内部Flash的NV区能够保存节点的网络信息，只要在工程添加NV_INIT与NV_RESTORE预编译项，节点在掉电后还能恢复原来网络信息。
对4个传感节点进行OTA更新。OTA更新后，温度采集功能成功添加，而且传感节点的网络短地址没有发生变化，网络拓扑结构保持完整，验证了进行OTA镜像升级过程中，并不会对NV区进行擦除，有利于节点网络信息的恢复。
OTA服务器被配置为路由器(0x06BC)，对传感节点(0x0002)进行点对点更新。第一条短帧是子路由向OTA服务器发送Image BLOCk Reque st，应用层载荷从第4字节开始记录了新镜像的制造商ID(0x5678)、镜像类型(0x1234)、版本号(0x00000002)和镜像块偏移量。最后1个字节记录了每次传送最大镜像块大小(OTA_MAX_MTU)，默认为0x20，即为32字节。第二条长帧是OTA服务器发送的Image Block Response，载荷记录格式与前者类似，并在最大镜像块大小字节后面附上32字节镜像块信息，从而完成一个镜像块传输周期。
4．2 效率分析
搭建一个星形网络，把OTA服务器配置成协调器，把所有OTA客户端配置成节点，并进行如下两个实验。
4．2．1 实验一
为了对比分析两种更新手段的效率，分别使用镜像块请求命令与镜像页请求命令，对节点进行OTA更新。星形网络中，通过广播Image Notify，能够对多节点进行批量更新。网络规模分别为1～6个节点，测量了不同规模网络下节点完成更新传输所需的时间。Min与Max分别
指最快与最慢完成更新传输的节点对应的时间，Ave指平均每个节点完成更新传输所需时间(使用Max值计算)。
其中，镜像页请求设置的Response Spacing为100 ms，镜像页大小为640字节。镜像大小统一为113 KB，并修改OTA_MAX_MTU大小为64字节。节点与OTA服务器间隔均为5 m。镜像块、镜像页请求的传输时间分别如表1、表2所列，响应间隔均为100 ms。
实验一中，使用镜像块请求，节点发送镜像块请求所需时间为15．5 ms，OTA服务器返回镜像块响应所需时间实际为96 ms，来回确认帧时间大概为1．92+3．84=5．76ms。一个更新周期传输镜像块大小为64字节，完成113KB大小的镜像传送需要1765个周期。总时间为(96+15．5 +5．76)×1765=206 963 ms，这与表1中的测量值207．2 s基本符合。
本文关键字：技术 综合通信技术，通信技术 - 综合通信技术
