0 概述

随着物联网技术的不断发展, 基于802.15.4标准^[1]的无线传感网络与IPv6(Internet Protocol version 6)网络的融合越来越重要。在诸多无线传感网络技术中, ZigBee是目前应用较多的技术^[2]。由于ZigBee技术仅支持传感网内部节点间的通信, 因此无法直接与IP网互联。IPv6作为下一代互联网的核心技术^[3], 其设计之初是为了实现互联网通信设计, 并没有考虑到其应用于无线传感网络会造成节点能耗受限和传输带宽低等问题。将ZigBee网络与IPv6网络进行融合需要考虑能耗、带宽、处理能力以及不同协议间的兼容性等问题。6LoWPAN(IPv6 over Low WPAN)技术是当前连接ZigBee(802.15.4)和IPv6(802.3)的主要方式, 6LoWPAN工作组通过在2种异构网络中添加适配层来完成2种异构网络的连接。目前, 6LoWPAN技术仍在完善中, 例如, 需对6LoWPAN中的报头压缩、报文分片等进行改进。

本文提出一种基于Contiki操作系统和6LoWPAN技术的网关设计方案, 来实现ZigBee无线传感网络与IPv6网络的互联。针对报头压缩率低的问题, 对报文分片之后的每个分片进行再压缩, 以改善能耗和时延。

1 研究背景

国内外科研人员提出很多ZigBee无线传感网络和IPv6网络互联的方法, 总体可分为网关协议转换、网关协议承载和直接接入3种方式。

1.1 网关协议转换

网关协议转换是在网关上运行IPv6和ZigBee双栈协议^[4-5]。这种方案虽然部署方便, 但是需要额外投入网关硬件设备, 成本较高, 还需要重新设计轻量级的IPv6协议栈^[6-7], 不便于IPv6用户直接寻址物联网节点, 其应用存在局限性。

1.2 网关协议承载

网关协议承载的方式分为IPv6 over ZigBee和ZigBee over IPv6 2种。

1) IPv6 over ZigBee方法将IPv6堆栈放在ZigBee NWK层的顶部, 给每个ZigBee节点分配一个IPv6地址。该方法的关键是数据包大小问题, 由于IEEE 802.15.4最大传输单元(Maximum Transmission Unit, MTU)仅有127 Byte, 且不支持数据包分片, 因此其不能处理IPv6的1 280 Byte的最小传输单元。国际互联网工程任务组(The Internet Engineering Task Force, IETF)于2004年成立了6LoWPAN^[8]协议工作组, 专门解决IPv6包在IEEE 802.15.4网络上的传输问题, 其提出的解决方案是在802.15.4的MAC层以上新增一个适配层。该适配层的功能是进行IPv6数据包的分片和重组^[9], 使得IPv6数据可以分成许多802.15.4帧进行传输。由于该方案丢弃了ZigBee堆栈, 没有ZigBee NWK层, 因此需要重新设计数据转发、地址分配等环节, 具有很大的挑战, 但其仍具有重要的参考价值。

2) ZigBee over IPv6方法是在ZigBee网络的NWK层与APL层间添加IPv6/UDP层, 使与ZigBee网络进行通信的IPv6节点上出现虚网络。利用隧道技术, 将ZigBee网络中的数据包以负载的方式封装在IPv6数据包中, 并在IPv6网络中传输^[10]。这种方式最大的问题在于首部压缩与数据分片, 文献[11-12]对这种基于网络地址转换的方法进行改进, 但仍旧存在基站代价高、用户透明度低等缺点, 数据的分片问题也未得到解决。

1.3 直接接入方式

直接接入方式直接将ZigBee网络与TCP/IP(v6)进行结合, 其也称为全IP方式。这种方式是在ZigBee传感器网络全部节点植入TCP/IP(v6)协议栈, 为每个节点分配IPv6地址, 其需要轻量级的IPv6协议栈。目前认可度较高的是文献[13]的适用于无线传感器网络的轻量级uIP和LwIP协议栈, 但其只停留在理论研究阶段, 在实际应用中并没有可以借鉴的模式。

2 方案设计

由于上述机制都未能较好地融合ZigBee/802.15.4和IPv6/802.3网络, 为此, 本文设计了一种基于Contiki操作系统和6LoWPAN技术的嵌入式网关, 提出IPv6网络与ZigBee网络的互联方案, 具体如下:

1) 利用6LoWPAN技术, 结合轻量级的uIPv6协议栈, 设计基于Contiki操作系统的嵌入式网关。

2) 针对6LoWPAN适配层中互联网协议头压缩(Internet Protocol Header Compression, IPHC)效率较低的问题, 提出改进方案, 并进行仿真测试。

3) 将本文设计的网关移植到基于cc2530平台的传感网Sink节点中, 完成系统搭建, 并进行连通性测试。

2.1 软硬件平台搭建

实验开发环境:硬件选择基于cc2530的开发板, 将其作为6LoWPAN网关节点和Contiki操作系统的承载媒介。软件采用Ubuntu 16.04+Contiki 3.0+IAR+串口助手+上位机传感数据监测软件(自主开发)。

Contiki是专门为硬件资源不足的嵌入式开发设备而设计的微型操作系统, 其采用C语言开发, 具有小型、开源、易移植的特点, 并且集成了轻量级的uIPv6和Rime协议栈^[14], 使得搭载该系统的节点能与IPv6直接进行通信。对比与之类似的用Nesc语言开发的Tiny操作系统^[15-16], Contiki操作系统能更好地解决IPv6和ZigBee网络融合^[17]问题, 因此本文将其应用于系统的搭建中。

2.2 6LoWPAN适配层设计

6LoWPAN适配层设计过程如下:

1) IPv6数据包分片和重组

由于IPv6链路的MTU为1 280 Byte, 而ZigBee允许的MTU为127 Byte, 除去MAC头部和标识等其他信息, 实际负载仅剩81 Byte, 因此必须对IPv6数据包进行分片和重组。分片的过程为:通过适配层检测一个经头部压缩的IPv6数据包长度是否大于127 Byte, 若大于则调用6lowpan_split()函数进行分片, 否则直接将其传输给媒介传输控制层的Rime来处理。重组的过程为:由适配层来检测从媒介传输控制层发来的数据包是否已经分片, 若已分片则将其存储到一个缓冲区队列中, 待所有分片到达后调用6lowpan_reass()函数进行重组, 最后发给网络层的uIP处理。图 1所示为分片、重组过程。

2) 报文头部压缩

由于IPv6报头长度为40 Byte, 加上用户数据包协议(User Datagram Protocol, UDP)报头的8 Byte, 报头较长势必会降低有效负载和传输效率, 因此必须进行报头压缩。RFC4944定义的HC1和HC2无状态报头压缩方案仅适用于单播链路本地地址^[18], 而IPHC^[19]虽然适合全局地址, 但是经该方案压缩后的分片头部依然存在大量冗余, 在数据传输中会增加节点的能量消耗。

由于同一组分片中每个分片的头部信息都包含相同的源地址和目的地址, 因此本文通过设定一个8 Byte的标记字段, 最多可对256个分片进行标记, 用标记字段来替换除第一分片之外的头部冗余字段, 并在6LoWPAN网关中保存映射表。改进后的压缩方案大致步骤如下:

(1) 检查收到的数据包是否大于127 Byte, 小于则用原IPHC方案对报头进行压缩, 否则进行分片。

(2) 用改进后的分片报头压缩方案对报文进行冗余字段标记, 并在网关中建立映射表。

(3) 当数据到达目的地后, 利用不同的压缩方案进行重组。

图 2所示为改进后的报头压缩流程。

3) 协议栈缓存

缓存空间对每个协议栈的实现都具有重大意义。由于IPv6分片、重组都要先放入一个缓存空间, 且ZigBee传感器模块的硬件资源有限, 因此本文采取缓存空间大小固定的方案。设计的规则是:将接收和发送的报文都存储在单一的缓冲空间内, 发送的报文头部放在缓存的头字段中, 接收的报文头部和数据则放入缓存的数据字段中。

4) 地址配置

寻址是异构网络协议连通的首要问题, IEEE 802.15.3定义的链路层地址有PAN内的16位短地址和由设备制造商设定的全球唯一EUI-64地址2种。由于16位短地址无法实现跨协议传输, 因此本文采用EUI-64地址作为接口标识符, 再加上64位的本地链路地址前缀, 以完成IPv6地址的无状态自动配置。

2.3 Contiki移植与部署

由于Contiki系统的高度可移植性, 其源码包含众多文件, 支持的硬件种类较多, 而cc2530硬件平台无需用到全部代码, 因此只需要对部分文件进行修改、移植。Contiki源码文件夹目录下只有cpu和platform文件中的内容与硬件相关, 所以系统移植主要针对cpu目录和platform目录中文件的修改, 其次是core目录下的dev文件, 其中的外设驱动和一些硬件相关。基本思路是:先在源代码中找到与目标平台相近的平台代码并进行修改; 再利用系统时钟模块向进程提供系统时间, 同时检查是否有事件到期, 从而对etimer库发出通知。移植的顺序如下:由内核开始, 依次为系统时钟模块、LED模块、串口模块、射频等底层驱动等, 最后是uIPv6协议和RPL路由协议。

由于IP的无线传感器网络比其他使用特定协议的异构网络更易于实现数据交互, 互联网关使得感知节点和互联网主机之间形成端到端的通信。本文所设计的6LoWPAN网关依托Contiki操作系统, 集成uIPv6和Rime 2种协议栈, 网关与IPv6主机以及感知节点之间的通信如图 3所示。PC机和网关都通过网线连接到支持IPv6的路由器上, 其中, 6LoWPAN网关架构部署在Sink节点上, ZigBee节点仍具有自组网特性。在实际组网过程中, 网关负责接收和处理来自ZigBee网络和IPv6网络的数据, 为每个节点分配IPv6地址, PC机通过DHCPv6自动获取IPv6地址。

3 实验结果与分析

为验证本文设计方案的效果, 通过Contiki自带的cooja模拟器对压缩方案改进前后的效果进行仿真, 在系统能耗和平均时延方面进行对比, 最后设计一套环境监测系统来验证方案的可行性。

3.1 改进前后的仿真测试

为了测试本文方案的可行性, 在Contiki操作系统自带的cooja模拟器中进行对比仿真。通过设定数据包大小, 测试IPHC报头压缩算法改进前后的节点能耗与网络时延。

图 4所示为压缩算法改进前后的节点功耗对比。由图 4可知, 改进后的算法在处理超过400 Byte的数据包时, 其能耗开始低于改进前的IPHC算法。这是因为降低分片冗余之后, 每个分片的负载更多, 总的分片个数减少, 所以改进后的方案在处理大数据包时效果更优。

图 5所示为压缩方案改进前后的平均时延对比。由图 5可以看出, 在处理大于500 Byte的数据包时, 改进后算法的平均时延较改进前有明显降低, 因此本文方案对于数据包较大的应用场景效果更好。

3.2 Contiki与协议栈的移植测试

本文搭建的测试环境包含一台支持IPv6的路由器、一台PC机、一个网关节点和若干个ZigBee节点, 其中, 网关节点中搭载了本文所设计的嵌入式网关架构。令各节点组建局域网, PC通过串口连接网关, 如图 6所示。利用串口助手读字符串, 依次打印出Contiki版本号、开发板型号、rime地址、网关的链路本地地址、监听端口号等, 验证Contiki及其协议栈到cc2530硬件平台能够成功移植。

3.3 连通性测试

搭建环境之后, 利用ping命令对网关节点进行测试, 在一台支持IPv6的PC上打开命令行窗口, 利用ping命令测试本文架构的连通性, 在测试中, 把6LoWPAN网关节点的IPv6地址设置为:fe80::74ac:6aff:fe71:327, PC的IPv6地址前缀和6LoWPAN网关节点保持一致, 测试结果如图 7所示。根据返回的IPv6数据包进行参数分析, 证明6LoWPAN网关节点已处于IPv6网络中。

3.4 PC端传感器数据采集测试

利用本文网关设计环境监控系统, 实现对ZigBee传感器温湿度、烟雾、红外、风扇的监控。图 8为在实际室内环境下, 通过IPv6网络内的PC终端采集到的ZigBee传感器数据, 其结果验证了本文方案的可行性。

4 结束语

为解决ZigBee无线传感网络与IPv6网络互联互通的问题, 本文提出一种基于6LoWPAN技术和Contiki操作系统的嵌入式网关连接方案。通过分析分片重组和报头压缩的过程, 对分片后的报文进行再压缩, 在原有压缩方案的基础上减少各分片的冗余数据。仿真结果表明, 在通信规模较大的网络状态下, 该方案具有低时延、低功耗的优点。通过设计上位机软件, 搭建真实实验环境, 进一步验证了该方案的可行性。下一步将对6LoWPAN技术中的RPL路由协议进行研究, 针对RPL目标函数单一的问题, 提出改进的多度量因子的目标函数, 以延长整个网络的生存周期, 提高网络传输性能。