无线传感器网络(WSN)由一些独立、完全嵌入式操作的小体积低功耗节点组成,这些节点能够检测来自目标环境的数据或控制目标环境,并且相互间通过无线方式通信。检测和控制是通过互连着的传感器和激励器完成的,而这些传感器和激励器或通过远程、或通过嵌入式应用程序进行管理。这些节点的数量从十几个到数千个不等,一个典型系统由数百个分布于整座大楼或室外空间的节点组成。
许多无线传感器网络采用私有标准实现无线组网,但最近的趋势是逐渐向标准化的低功耗无线通信发展。基于著名的802.15.4规范的ZigBee就是一种用于无线检测和控制的标准。虽然802.15.4文档仅描述了协议的PHY和MAC层,但基于802.15.4构建的ZigBee还提供网络和应用层规范。
ZigBee具有许多优点,包括可以实现多跳路由和数据发送的网格协议、安全规范和针对应用层互操作性的整套参数设置。总之,ZigBee向嵌入式应用开发人员提供了管理网络以及连接其它节点的更高抽象层次。
虽然本文主要讨论的是ZigBee,但其中许多观点和结论同样也适用于采用802.15.4 MAC和PHY的其它标准。为了避免出现混乱,后文假设我们的目标设计涉及的是使用网格路由协议、802.15.4兼容调制方案和介质访问协议的多跳网络。本文还假设读者对ZigBee和802.15.4规范已有基本了解。
网络组织和规模
网络组织和规模也许是最重要的设计选项,它往往对接下来的设计过程起着告知和指导作用。它还有约束作用,因为大型网络通常更难设计和维护。幸运的是,如今已经有方法能轻松实现和维护非常大的网络。
目前最先进的ZigBee网络规模在300到500个节点之间。这个规模看起来不大,但试想一下,所有这些节点工作在同一物理信道上,彼此在同一时间发送数据,根据每个节点的行为路由数据,并在同一时间试图保持整个网络的完整性(通过发送周期性控制消息),这该是个很吵很拥挤的网络。另外还要注意,ZigBee标准所依据的802.15.4规范使用了CSMA/CA(载波侦听多址访问/碰撞避免)协议,也就是说,在各自“听力”范围内没有两个节点能同时“说话”。如果同时“说话”,都会遭遇通信失败,必须延迟一段时间后重试。如果网络已经拥塞,那么这些重试将产生级联传输故障,试图发起空中访问的节点将越来越多,从而加剧信道的拥挤。
事实上,在设计数百个节点以上的网络时面临的主要挑战之一是如何有效地管理网络拥塞(另外一个挑战是在运行时优化用于存储内部堆栈状态的系统资源)。下面的小节将简要介绍用于解决拥塞问题的三种不同策略。
图1:基于802.15.4的ZigBee提供网络层和应用层规范。
网络密度
显然,“300个节点的网络”给我们提供的有关网络组织的信息是很少的。由于存在上述冲突碰撞问题,网络密度也是影响网络健康的一个重要因素,也就是说在每个节点听力范围内存在多少个节点,或者换句话说,一个普通节点可以听到多少个其它节点?专家建议是小于5个,因为这个数量支持冗余设计和相对无阻塞的通信介质。7个节点以上的网络很可能出现严重拥塞的网段而加重网络负担。
一个相关的问题随之而来,系统设计师该如何判断有多少个节点能被听到?一个显而易见的策略是定制嵌入式应用程序。有关相邻节点的信息实际上是ZigBee网络中协议操作的一个重要部分。事实上,节点会主动广播他们自己的信息,并且这些信息会被有效范围内的每个其它节点接收到。相邻表格可以被驻留程序查询,并计算唯一性条目的数量。然后驻留程序再将这个诊断结果发送给指定节点。很明显,这样做只有在网络密度仍能改变的网络安装过程中才有意义。一旦网络安装完毕并开始运行,密度信息将在故障排除过程中发挥顾问的作用。
请注意,如果相邻表格的大小小于周围节点的数量,ZigBee堆栈将强制周期性地撤消表格条目。这种撤消也可能负面影响总体网络性能,因为即使路径中没有节点离线,也会强制路由被重新发现。因此,除了限制网络密度以避免拥塞外,还必须根据系统资源(如相邻表格的大小)确定网络密度。
在节点的物理位置由于应用要求而被固定的情况下,网络密度可以方便地通过降低拥塞区域中收发器的输出功率来得到控制。从理论上讲,降低输出功率与增加节点间距离、使它们彼此听到的可能性变小具有相同的效果。制造商倾向于将输出功率设为最大值,以确保最大工作范围和最佳链路质量。根据我们的经验,在距离性能不很重要的室内应用场合,输出功率可以很容易降低。根据经验,输出功率降低3dBm,有效距离范围可以缩短1.5倍。
有关密度的最后一个考虑因素是,故障率增加到足够高以致于触发上述级联故障效应的理论极限。当然,这个参数取决于应用程序本身发送的信息量。根据经验,如果每个节点每秒发送一个最大长度的数据包,那么在各个节点的听力范围内这个极限值约为25个节点。密度极限似乎是不变的,与堆栈实现无关,这意味着密度极限与MAC层更基本的CSMA操作有关。例如,我们可以推断每隔n秒发送一个包的节点的密度极限值,就是将最大密度乘以1.2n倍。这个近似值从来不应被用作网络密度的精确指导值,因为实际值将取决于网络中的路由器和终端设备的比例。
根据信道进行网络划分
在不能删除节点或降低输出功率的情况下,系统设计师可以选择将工作在单个信道上的单一网络划分为工作在不同信道上的多个网络来解决网络拥塞问题。802.15.4在2.4GHz频率范围内规定了16个信道,在900MHz频率范围内另外还增加了10个信道。将网络置于不同的信道上能够完全隔离不同网络间的相互影响,但根据需要,每个网络可能需要使用协调器(coordinator),并需连接这些协调器,从而带来额外的复杂性。
如果待分割的网络逻辑上已经是分开的,那么根据信道进行网络划分的方法最有效果。例如,在大楼自动化应用中,让每一楼层的网络工作在各自的信道上通常是比较理想的。但如果每个楼层都有一个网络协调器,那么不同楼层之间的节点相互通信就很麻烦,特别是这样做可能会影响网络性能(高密度网络就是这种情况)。
同样,还可以根据房间或办公面积进行划分。最重要的是,应该根据具体应用要求和可用信道数量来做出根据物理信道划分网络的决定。当多个子网络中的节点需要相互通信时,这种划分还会使总体设计变得更加复杂。
信道掩码(就象收发器输出功率一样)是一个可设置的网络参数。应用工程师可以给网络协调器以及必须与该协调器建立连接的网络设备分配一个合适的信道掩码。作为一个标准步骤,协调器将执行能量检测扫描,以便从信道掩码中挑选出“活跃性最差”的信道。
值得注意的是,除了给掩码分配单个信道外,没有其它方法能强制协调器工作在特定信道上。不过强烈建议在信道掩码中至少要保持两个信道,因为来自WiFi网络、蓝牙耳机和其它电子设备的带内干扰会临时占用本来是空闲的特定信道,致使整个网络瘫痪。在信道掩码中留有多个信道不仅给协调器提供了信道选择余地,今后还能让它灵活地切换到拥塞程度较低的信道。
图2:ZigBee网状网拓扑。
根据PANID进行网络划分
最后一种策略是根据PANID划分网络,这种方法的效率公认要比根据物理信道划分网络的方法低。PANID是一个给定网络中所有设备都知道的唯一标识符。使用不同PANID的设备之间是无法通信的,从而允许多个网络共存于同一区域,而且其中一个网络的数据不会在另外一个网络中出现。事实上,具有不同PANID的多个网络都可以使用相同的物理信道实现相互间的通信。
虽然根据PANID分割网络不会影响空中拥塞程度,但可以通过在堆栈的较低层滤除来自相邻网络设备(具有另外一个PANID)的业务而减少每个节点处的处理开销量。在大多数情况下,滤除工作可以由PHY层硬件自动完成,从而释放更多的应用资源和时间。对于应用处理和路由开销占主导的应用而言,根据PANID进行划分的方法能够非常有效地在给定区域内容纳更多的节点。
基于PANID分段的一个好处是具有相对较多的可能唯一分段,准确地讲可达216个。虽然只有26个物理信道,但PANID为实现分段提供了更灵活的方法,尽管效率较低。大多数无线系统将同时使用PANID分段和信道数量分段的组合策略。总之,在解决网络拥塞问题时这种组合策略可以提供最佳的灵活性和效率折衷方案。
图3:居民住宅楼内的无线抄表应用。
吞吐量
另外一个需要仔细考虑的设计因素是吞吐量。简单地说,吞吐量指的是一个设备在单位时间内希望传送的有用数据总量。许多系统工程师错误地认为系统具有比实际可用带宽大得多的带宽(有时甚至超出一个数量级),从而导致性能差或无法运行的设备和失败的设计。
导致这个常见问题的原因是802.15.4网络链路宣称有250kbps的介质容量。实际上,这个数字指的是理论上的物理极限,也就是PHY层的有效带宽。它忽略了物理层上其它堆栈层引起的协议延时、处理和解析每个数据包的开销、介质访问时间、数据确认机制和误码率。根据我们的经验,在相隔一跳的两个ZigBee节点之间建立的点到点链路的传输速率不超过110到120kbps。在引入确认机制后,这个速率还要下降近一半。在任一给定时间点有3到5个节点试图访问共享介质的典型网络环境中,这个传输速率还将进一步降低到数十kbps。
显然,20~40kbps与标准宣称的最大250kbps有很大差异,而一个缺乏经验的系统工程师往往不知道这种差异,直到悔之晚矣。关键是无线传感器网络从来没有打算要支持高带宽的应用。相反,其目标市场是具有低带宽要求的相对大型网络。如果有个传感器是产生100kbps数据流的视频摄像机,那么无线传感器网络和ZigBee肯定不是最好的选择,市场上有其它无线技术能更好地完成这个工作。
尽管吞吐量期望值和某种技术能够支持的指标不匹配很常见,但仍可以合理使用这种技术,并通过带宽优化在目标环境中高效地运行。例如考虑每秒采样100次的温度传感器。每次用一个数据包发送一个样值将是一个较差的设计选择。事实上,由于前面提到的网络拥塞和级联重传故障问题,这样做将给网络健康带来不良后果。一个更好的策略是,将多个样值汇聚到一个数据包中,因为在大多数情况下,最大的数据包比较小的数据包更优。
当汇聚无法实现时,可以用本地处理来降低带宽要求。让我们考虑具有低门限和高门限的典型自动调温器应用。只要这些温度读数落在可接受的温度范围内,那么绝对不需要发送瞬时温度读数。节点可以使用本地处理功能来判断何时读数超出规定范围,并在需要时才发送数据以警示另一个远程设备。减少待发送数据量的另一个策略是采用某种形式的数据求和或平均算法。
然而需要注意的是,当多个物理事件同时发生时,即使是高度优化的设备也会遭遇拥塞。如果整个楼层的温度上升,可能会出现许多自动调温器希望立即发送温度读数。对付这样的带宽峰值的一个实用方法是随机化传送延时。显然,MAC层的重传就是一种随机化处理,但它无助于防止碰撞,它只在发生碰撞后起作用。应用层的延时如果做得好可以有效减少碰撞于发生之前。当每小时有数百个节点需要发送数据包,最佳设计会把传送均匀分配在整个时段内,以尽量减少碰撞的机会。在有大量传送的场合,强烈建议系统工程师采用这种策略。
作者:Ilya Bagrak
软件产品经理
MeshNetics公司