关于传感器网络中实时通信的研究
传感器网络中实时通信的研究
近年来,由于能够适应多种现实智能环境,传感器网络得到了快速发展,并以其自组织、自管理、自节能、可靠性高、造价低和适用于恶劣环境等特点,被广泛应用于军事、医疗卫生、环境保护和交通等领域。在一些具体应用中,有时需要对传感器测量信息做出实时反映。比如在医疗中,对于病人血压值的突然升高必须在很短时间内了解并采取措施。在军事打击中,一些重要传感器的数据必须尽快得到处理并能得到快速反应。传感器网络应用于工业自动制造中也有实时性的要求。根据工业自动化系统理论,实时系统分为3个等级:低约束级,允许响应时间超过100 ms;一般约束级,响应时间在5~10 ms之间;高约束级,响应时间低于1 ms。本文以星型为网络拓扑结构,以IEEE802.15.4标准和ZigBee为基础协议,研究传感器网络中MAC协议的实时性能。
2协议分析
IEEE 802.15.4定义了2个工作频段,即2.4 GHz频段和868/915 MHz频段(适合不同国家地区),共分配27个具有3种速率的信道:在2.4 GHz频段有16个速率为250 kb/s的信道,在915 MHz频段有10个40 kb/s的信道,在868 MHz频段有1个20 kb/s的信道。
为了达到网络同步,IEEE 802.15.4在MAC层定义了超帧结构。超帧的格式由传感器网络的协调器定义,有16个大小相等的时隙,每个超帧之间由网络信标帧(beacon)分隔,信标帧在超帧的第一个时隙被传输。超帧分为竞争访问周期(ContenTIon Access Period,CAP)和无竞争访问周期(ContenTIon Free Period,CFP)。在CAP阶段,设备采用CSMA-CA机制竞争信道,设备对信道的访问延迟无法控制,无法实现实时要求,在CFP阶段,网络协调器为有实时性要求的设备分配GTS时隙,实现实时通信,如图1所示。
2.1超帧的参数
由于IEEE 802.15.4允许设备采用节能模式,因而超帧有活动和非活动2种状态。在非活动状态下,节点进入休眠模式。这时使用2个参数信标帧间隔:一个是信标序号BO,即信标间隔,要求0≤BO≤14;另一个参数是超帧序号SO,并且0≤SO≤BO≤14。当BO=15时,协调器将不再发送信标帧,并且忽略 SupeRFrameOrder参数值。协调器只在超帧的活动状态为设备分配GTS,如图2所示。
2.2 GTS的分配过程
当设备发送MLME-GTS.request原语时请求GTS,设备将要发送的信息的长度和目的地址都包含在原语中。协调器一旦接收到请求,为提出请求的设备分配GTS并发送应答信息,然后协调器检查当前超帧是否有足够空问分配请求,并且重新计算CAP和CFP参数的长度。如果协调器同时收到多个GTS请求,将按照FIFO(First in First out)机制排队,协调器将在aGTSD-escPersistenceTIme时间内完成决策,如图3所示。
如果分配成功,协调器就在信标中加入GTS指示帧,GTS指示帧中包含申请设备的短地址、GTS的开始时隙和GTS的长度等信息。如果没有足够的空间可以分配申请的GTS,GTS指示帧中的开始传送时隙就被设置为0。当设备收到协调器发送的确认应答后,将监听信道,并等待最长 aGTSDescPersistenceTIme时间(aGTSDescPersistenceTime=4 surperframe)。若在此期间收到的信标帧中包含该设备的GTS指示时,设备处理GTS指示;如果信标帧中不含有该设备的GTS指示,宣布申请失败。在GTS发送之前,发送者发送MCPS—DATA.request原语以监测接收者是否做好接收准备。当协调器接到MCPS- DATA.request时,协调器的MAC层将检查是否有效,即是否为该设备分配过GTS。如果有效,在分配的时隙发送数据。GTS传送不必使用 CSMA-CA机制,没有竞争和退避时间,这种方法能够适合实时请求。
3 Petri网模型
Petri网的概念是由德国人Carl Adam Petri于1960首先提出的,具有严密数学基础,能深刻、简洁地描述控制系统并能对系统的动态性质进行分析。该方法以图形的表达方式描述系统,可直观地显示系统的动态过程,具有可读性和易于理解的特点。经典的Petri网是简单的过程模型,由2种设备(库所和变迁)、有向弧、以及令牌等元素组成的。库所(Place)一般用圆形设备表示;变迁(Transition)用方形设备或者线表示,代表事件、转化或传输;有向弧用来实现库所和变迁之间的连接;令牌(Token)是库所中的动态对象,可以从一个库所移动到另一个库所,令牌表示事物、信息、条件或对象的状态。
根据上面的分析,协调器对于GTS的请求采取先来先服务的规则,设备1请求GTS得到协调器的安排可能性如图4所示。这里假设设备1是一周期采样的传感器结点,而且采样周期小于等于帧长,在同一超帧中不会连续申请多个GTS。
一旦产生数据包,在队列中等待发送。当数据包移动到队首时,发送GTS请求,直到分配到GTS时隙时才发送数据包。这样,响应时间由3部分组成:人队时间、分配GTS时间和等待发送时间片的时间。
3.1设备请求GTS的响应时间模型
分析中,假设每个设备申请GTS只占一个时隙(IEEE 802.15.4中允许一个GTS占用连续多个时隙)。假设网络中只有一个设备需要GTS传输,采用PETRI网为传感器网络建立关于延迟模型如图5所示。
图 5中,t1处加入时间控制,用来仿真数据包到达,由传感器周期性采样的性质,选择间隔为常数的分布,参数为λ,表示每秒到达信息包个数。根据采样时间,将传感器分为2种:一种是周期传感器;另一种是事件驱动传感器。采用周期采样,一般探测周期为300 ms,于是,λ=300 ms。
在 t4时间加入常数分布的时间控制,均值为μ,根据文献[3]计算,aBaseSlotDuration=60 symbols,datarate=62.5 ksymbols/s(2 450 MHz),则计算得到a slot time="0".96 ms,μ=0.96×16=15.36 ms;变化范围为正负6×0.96=5.76 ms,符合(9.6,21.12)的均匀分布。由于处理速度大于包的生成速度,设备的GTS请求被立即分配,立即发送所有包。此过程满足高约束实时环境。
3.2 多个设备请求GTS的响应时间的模型
如果有多于7个设备同时请求GTS,它的完整模型如图6所示。
图 6中左边每一行表示1个设备要求申请GTS传送,8行表示8个设备要求GTS传送;右边的2行,下面一行用来控制整帧的时间推进,上面的用来控制帧中时隙的推进。P6和P22的7个令牌,表示帧中最多可以分配7个时隙的GTS(这里表示最多可分配7个设备的申请)。P1,P6等4个令牌表示每个设备有4个数据包产生,并需要发送。在t1,t5,t7,t11,t17,t20,t23,t26处设置时间控制函数,表示数据包产生的时间间隔。仿真中假设传感器周期探测,设常数分布300 ms(大部分温度湿度传感器的探测周期)。在t4处设置时间控制函数,常数分布,表示时隙之间间隔,即时隙宽度,0.96 ms。在t13处设置时间控制函数,表示整个帧的长度,常数分布15.36 ms。仿真表明,响应时间不是很长,最大等待时间为1个超帧的长度15.36 ms,即它能满足实时的低约束环境。如果设备请求GTS的个数增加30倍,需要分配5个超帧时间的长度,而设备最多等待4个超帧时间。因此,一些设备失去了分配GTS的机会。实际上,1个设备可以请求多个GTS,随着GTS请求丢失的越多,响应时间也随着增加,仿真结果如图7所示。
3.3多设备随机请求GTS
图 6中的模型也适合于事件驱动传感器,GTS请求随机到达。假设包到达服从泊松分布,改变t1,t5,t7,t11,t17,t20,t23,t26处设置时间控制函数,设服从期望值为15.36 ms(1帧的长度)的负指数分布,产生GTS请求的结点从3~7进行仿真。仿真结果如图8所示。由于随机产生的GTS请求,GTS的响应时间比上面定时同时产生请求要短。但也可以看到随着产生站点GTS请求的站点增多,最大响应时间和平均响应时间都在逐步增大。这样随着产生GTS的数量增多,丢失GTS的情况一定还会发生。由于随机产生的GTS请求,GTS的响应时间比上面定时同时产生请求要短。但也可以看到随着产生站点GTS请求的站点增多,最大响应时间和平均相应时间都在逐步增大。这样随着产生GTS的数量增多,丢失GTS的情况一定还会发生。
4结语
根据对星型传感器网络的分析和仿真,如果每个设备只请求1个GTS时隙,最多允许7个设备同时请求GTS;否则,不满足高约束实时环境。如果请求GTS的设备大于28,GTS将会丢失。如果1个设备请求多个GTS时隙,GTS丢失率会成倍增加。因而,现有的传感器网络协议不足以满足实时系统,协议的改进有待进一步研究。本文的研究成果对于传感器网络应用于实时控制系统具有重要的参考价值。
图片新闻
技术文库
最新活动更多
-
即日-12.26立即报名>>> 【在线会议】村田用于AR/VR设计开发解决方案
-
1月8日火热报名中>> Allegro助力汽车电气化和底盘解决方案优化在线研讨会
-
1月9日立即预约>>> 【直播】ADI电能计量方案:新一代直流表、EV充电器和S级电能表
-
即日-1.14火热报名中>> OFweek2025中国智造CIO在线峰会
-
即日-1.20限时下载>>> 爱德克(IDEC)设备及工业现场安全解决方案
-
即日-1.24立即参与>>> 【限时免费】安森美:Treo 平台带来出色的精密模拟
推荐专题
发表评论
请输入评论内容...
请输入评论/评论长度6~500个字
暂无评论
暂无评论