无线传感器网络各类路由协议仿真教程文件
无线传感器网络各类路由协议仿真
实
验
报
告
课程无线传感网络各类路由协议仿真
1.实验目的
网络数据传输离不开路由协议，路由协议是其组网的基础，路由协议是无线传感器网络研究的重点之一，其主要的设计目标是降低节点能量消耗，延长网络的生命周期。本次实验将仿真各类无线传感器网络路由协议。
2.实验要求
争取考虑全面，考虑到各因素对各类协议的影响，以提高无线传感网络的性能。
3.设计思想
(1)Flooding
泛洪是一种传统的路由技术，不要求维护网络的拓扑结构，并进行路由计
算，接收到消息的节点以广播形式转发分组。对于自组织的传感器网络，泛洪
路由是一种较直接的实现方法，但消息的“内爆”(implosion)和“重叠”(overlap)是
其固有的缺陷。为了克服这些缺陷，S.hedetniemi等人提出了Gossiping策略，节
点随机选取一个相邻节点转发它接收到的分组，而不是采用广播形式。这种方
法避免了消息的“内爆”现象，但有可能增加端到端的传输延时。
Flooding路由协议中的内爆和重叠问题
(2)SPIN (sensor protocol for information via negotiation)
SPIN是以数据为中心的自适应路由协议，通过协商机制来解决泛洪算法中的“内爆”和“重叠”问题。传感器节点仅广播采集数据的描述信息，当有相应的请求时，才有目的地发送数据信息。SPIN协议中有3种类型的消息，即ADV，REQ和DATA。
ADV—用于新数据广播。当一个节点有数据可共享时，它以广播方式向外发送DATA数据包中的元数据。
REQ—用于请求发送数据。当一个节点希望接收DATA数据包时，发送REQ数据包。
DATA—包含附上元数据头(meta一header)的实际数据包。
SPIN协议有4种不同的形式:
? SPIN-PP：采用点到点的通信模式，并假定两节点间的通信不受其他节点的干扰，分组不会丢失，功率没有任何限制。要发送数据的节点通过ADV向它的相邻节点广播消息，感兴趣的节点通过REQ发送请求，数据源向请求者发送数据。接收到数据的节点再向它的相邻节点广播ADV消息，如此重复，使所有节点都有机会接收到任何数据。
? SPIN-EC：在SPIN-PP的基础上考虑了节点的功耗，只有能够顺利完成所有任务且能量不低于设定阈值的节点才可参与数据交换。
? SPIN-BC：设计了广播信道，使所有在有效半径内的节点可以同时完成数据交换。为了防止产生重复的REQ请求，节点在听到ADV消息以后，设定一个随机定时器来控制REQ请求的发送，其他节点听到该请求，主动放弃请求权利。? SPIN-RL：它是对SPIN-BC的完善，主要考虑如何恢复无线链路引入的分组差错与丢失。记录ADV消息的相关状态，如果在确定时间间隔内接收不到请求数据，则发送重传请求，重传请求的次数有一定的限制。图3.2表明了SPIN协议的路由建立与数据传送。
SPIN协议的路由建立与数据传送
基于数据描述的协商机制和能量自适应机制的SP创协议能够很好地解决传统的Flooding协议所带来的信息爆炸、信息重复和资源浪费等问题。此外，由于协议中每个节点只需知道其单跳邻居节点的信息，拓扑改变呈现本地化特征。SP州协议的缺点是数据广告机制不能保证数据的可靠传递，如果对数据感兴趣的节点远离源节点或者在源节点和目的节点中间的节点对数据不感兴趣，那么数据就不可能被传递到目的地。因此，对于入侵发现等需要在定期间隔内可靠传递数据的应用系统来说，SP州并不是一个很
好的选择。
(3)SAR (sequential assignment routing)
在选择路径时，有序分配路由(SAR)策略充分考虑了功耗、QoS和分组优先权等特殊要求，采用局部路径恢复和多路经备份策略，避免节点或链路失败时进行路由重计算需要的过量计算开销。为了在每个节点与sink节点间生成多条路经，需要维护多个树结构，每个树以落在sink节点有效传输半径内的节点为根向外生长，枝干的选择需满足一定QOS要求并要有一定的能量储备。这一处理使大多数传感器节点可能同时属于多个树，可任选其一将采集数据回传到sink节点。
(4) LEACH (low energy adaptive clustering hierarchy)
LEACH是MIT的Chandrakasan等人为无线传感器网络设计的低功耗自适应聚类路由算法。与一般的平面多跳路由协议和静态聚类算法相比,LEACH可以将网络生命周期延长15%,主要通过随机选择聚类首领,平均分担中继通信业务来实现。LEACH定义了“轮”(round)的概念,一轮由初始化和稳定工作两个阶段组成。为了避免额外的处理开销,稳定态一般持续相对较长的时间。如图3.4所示：
LEACH协议的时序图
在初始化阶段,聚类首领是通过下面的机制产生的。传感器节点生成0,1之间
的随机数,如果大于阈值T,则选该节点为聚类首领.T 的计算方法如下:
()[]p r P P
T 1mod 1-= （3.1）
其中p 为节点中成为聚类首领的百分数,r 是当前的轮数。
当簇头选定之后，簇头节点主动向网络中节点广播自己成为簇头的消息
(ADV_CH)。接收到此消息的节点，依据接收信号的强度，选择它所要加入的簇，并发消息通知相应的簇头(JOIN_REQ)。基于时分多址(Time Division
Multiple Address ，简称TDMA)的方式，簇头节点为其中的每个成员分配通信时隙，并以广播的形式通知所有的簇内节点(ADVSCH)。这样保证了簇内每个节点在指定的传输时隙进行数据传输，而在其他时间进入休眠状态，减少了能量消耗。在稳定工作阶段，节点持续采集监测数据，在自身传输时隙到来时把监测数据传给簇头节点(DATA)，如图3.5所示。簇头节点对接收到数据进行融合处理之后，发送到Sink 节点，这是一种减小通信业务量的合理工作模式。持续
一段时间以后，整个网络进入下一轮工作周期，重新选择簇头节点。
LEACH 协议采用动态转换簇头的方法来平均网络节点的能量消耗，使因能量耗尽而失效的节点呈随机分布状态，因而与一般的多跳路由协议和静态簇算法相比，LEACH 可以将网络生命周期延长15%。但是LEACH 协议在每轮固定簇头节点后在划分簇的过程中，簇头节点开销较大。并且簇头节点的选择无法达到最优，有可能簇头节点位于网络的边缘或者几个簇头节点相邻，某些节点不得不传输较远的距离来与簇头通信，这就导致了大量能量消耗。而且LEACH 协议所有簇头节点直接与Sink 节点通信，采用连续数据发送模式和单跳路径选择模式，使得每轮中簇头节点能耗巨大，因此不适合在大规模的传感器网络中应用。
(5) TEEN (threshold sensitive energy efficient sensor network protocol)
依照应用模式的不同，通常可以简单地将无线自组织网络(包括传感器网络和Ad-hoc网络)分为主动(proactive)和响应(reactive)两种类型。主动型传感器网络持续监测周围的物质现象，并以恒定速率发送监测数据；而响应型传感器网络只是在被观测变量发生突变时才传送数据。相比之下,响应型传感器网络更适合应用在敏感时间的应用中。TEEN和LEACH的实现机制非常相似,只是前者是响应型的，而后者属于主动型传感器网络。在TEEN中定义了硬、软两个门限值，以确定是否需要发送监测数据。当监测数据第一次超过设定的硬门限时,节点用它作为新的硬门限,并在接着到来的时隙内发送它。在接下来的过程中，如果监测数据的变化幅度大于软门限界定的范围，则节点传送最新采集的数据，并将它设定为新的硬门限。通过调节软门限值的大小，可以在监测精度和系统能耗之间取得合理的平衡。图3.6表示的是TEEN协议中由聚簇构成的层次结构。
TEEN协议中由聚簇构成的层次结构
TENE适用于实时性要求较高的应用场合，比如入侵警报，爆炸预警等，用户可以及时获取感兴趣的信息。而且用户可以通过设置不同的软门限方便地平衡监测的准确性与系统节能性两项指标。但是这个方案也有一些不足之处，例如门限值达不到，节点就永远不会和簇头节点通信，用户就无法从网络得到任何数据;没有相应的机制去区分那些没有感应到足够大变化的节点和处于关闭状态的节点，所以TEEN协议不适合应用在。
(6) PEGAGIS (power-efficient gathering in sensor information system)
PEGASIS由LEACH发展而来。它假定组成网络的传感器节点是同构且静止的。节点发送能量递减的测试信号，通过检测应答来确定离自己最近的相邻节点。在收集数据前，首先利用贪心算法将网络中的所有节点连接成一条单链。通过这种方式，网络中的所有节点能够了解彼此的位置关系，进而每个节点依据自己的位置选择所属的聚类，聚类的首领向链的两端发出收集数据的请求，数据从单链的两个端点向首领流动。中间节点在传递数据前要执行融合操作，最终由首领节点将结果数据传送给Sink节点。因为PEGASIS中每个节点都以最小功率发送数据分组，并有条件完成必要的数据融合，减小业务流量。因此,整个网络的功耗较小。研究结果表明，PEGASIS支持的传感器网络的生命周期是LEACH的近两倍。
4.实验器材与工具
MATLAB
5.程序源代码
function x=animation_data
small=5; medium=20; large=50;
% Event_name Animated Color/{on/off/toggle} Size
anim_def={...
{'Init_Application', 0, [0 0 0 ], small}, ...
{'Packet_Sent', 1, [0 1 0 ], small}, ...
{'Packet_Received', 1, [0 1 0 ], small}, ...
{'Collided_Packet_Received', 0, [1 0 0 ], small}, ...
{'Clock_Tick', 0, [0 0 0 ], small}, ...
{'Channel_Request', 0, [0 0 0 ], small}, ...
{'Channel_Idle_Check', 1, [1 0 0 ], small}, ...
{'Packet_Receive_Start', 0, [0 1 0 ], small}, ...
{'Packet_Receive_End', 0, [0 0 0 ], small}, ...
{'Packet_Transmit_Start', 1, [1 0 0 ], medium}, ...
{'Packet_Transmit_End', 0, [0 1 0 ], small}};
for i=1:length(anim_def)
a=anim_def{i};
x(i)=struct('event', a{1}, 'animated', a{2}, 'color', a{3}, 'size', a{4}); end
function application(S)
% DO NOT edit simulator code (lines that begin with S;)
S; persistent app_data
S; global ID t
S; [t, event, ID, data]=get_event(S);
S; [topology, mote_IDs]=prowler('GetTopologyInfo');
S; ix=find(mote_IDs==ID);
S; if ~strcmp(event, 'Init_Application')
S; try memory=app_data{ix}; catch memory=[]; end,
S; end
S;
switch event
case 'Init_Application'
signal_strength=1;
if ID==1 % first node starts flood
Set_Clock(1000)
end
PrintMessage('i')
case 'Packet_Sent'
PrintMessage('s')
case 'Packet_Received'
% data.data % message
% data.signal_strength % received signal strength
if memory.send
p=sim_params('get_app', 'P');
if isempty(p); p=.5; end
if rand Send_Packet(radiostream(data.data, memory.signal_strength)); end memory.send=0; PrintMessage('r') end case 'Collided_Packet_Received' % this is for debug purposes only