广播的形式通知所有的簇内节点(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协议中由聚簇构成的层次结构。

High level cluster head Sink Low level cluster head

Clustering Normal sensor node

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

case 'Clock_Tick'

Send_Packet(radiostream('Message for 00111 from Golomb', memory.signal_strength));

case 'GuiInfoRequest'

disp(sprintf('Memory Dump of mote ID# %d:\\n',ID)); disp(memory)

case 'Application_Stopped'

% this event is called when simulation is stopped/suspended

case 'Application_Finished'

% this event is called when simulation is finished

otherwise

error(['Bad event name for application: ' event]) end

S; app_data{ix}=memory; function b=Send_Packet(data); global ID t