Implementation of Reliable and Efficient Reporting Mechanism with Randomized Energy-Conservation Protocol in Wireless Sensor Networks

Introduction

Energy efficiency is one of the major concerns in wireless sensor networks, since it impacts the network lifetime. In this paper, we investigate the relationship between sensor network performance, particularly its lifetime, and the number of active reporting nodes N by using both analytical and simulation approaches. We first demonstrate that decreasing the number of reporting nodes increases the number of reports that need to be sent to the sink in order to achieve the desired information reliability regarding a detected event. On one side, we show that reducing the number of reporting nodes reduces the probability of collision occurrence. Based on these results and as the first main contribution, we derive the optimal number of reporting nodes Nopt energy that minimizes the energy consumed to report reliably the occurrence of an event. In other words, we prove that limiting the reporting tasks of a detected event to a small subset of sensor nodes (i.e., Nopt energy ), instead of using all the sensor nodes in the event area, enables significant energy conservation. Furthermore, with regard to the latency properties, we show that the average time required to reliably report an event is a convex function of the number of reporting nodes, where the minimum is obtained for a given Nopt latency ¼ Nopt energy . Consequently and as the second main contribution, we demonstrate that the fastest way to reliably report an event does not correspond to the optimal way of consuming the scarce network energy. The trade-off between these two requirements is sensor application specific, depending on this one particular need in terms of quality of service. To the best of our knowledge, we are the first to tackle the energy efficiency problem from this perspective while considering the energy-reliability-latency trade-offs.

About This Project

This project addresses a randomized energy-conservation protocol that seeks to build resilient sensor networks by decreasing the number of reporting nodes increases the number of reports that need to be sent to the sink in order to achieve the desired information reliability regarding a detected event. The proposed protocol extends the network lifetime by maintaining a necessary set of working nodes and turning off redundant ones, which wake up after randomized sleeping times and re- place failed ones when needed. The fully localized operations of this protocol are based on each individual node’s observation of its local environment but do not require per neighbor state at any node; this allows this protocol to scale to very dense node deployment. The proposed protocol is highly robust against node failures due to its simple operations and randomized design; it also ensures asymptotic connectivity.

The proposed protocol will be simulated on ns2 and its performance will be analyzed.

 

The Sleep and Wakeup Mechanism for Reliable and Efficient Reporting

Proposed WSN works for ad hoc sensor networks that consist of large numbers of densely-deployed, small, inexpensive sensors. Such networks find applications in forest fire monitoring, military surveillance, ocean environmental sampling, etc. Due to adverse external factors, these nodes may suffer frequent and unpredictable failures. The network relies on a certain degree of redundancy in working nodes for robust functioning. Nodes are usually deployed at much higher densities than the minimum required for extended system lifetime. We assume that each sensor node can vary its transmission power to choose a power level to cover a circular area given a radius.

The goal of proposed WSN is to extend system lifetime by exploiting the high redundancy in deployment, while being robust against severe, unpredictable node failures. The basic approach is to turn off redundant nodes. Two main issues are how to decide which nodes to turn off and how long they sleep. The two components of proposed WSN, Probing Environment and Adaptive Sleeping, address these issues, respectively.

To decide which sensors to turn off, nodes need to coordinate among themselves. This is typically achieved based on each node’s knowledge about its neighborhood, such as each neighbor’s location, connectivity, etc. However, in a dense network with frequent, unpredictable node failures, keeping track of each neighbor’s status can be very difficult; the con- strained memory and energy resources of each node further aggravate the situation. We thus strive to avoid per neighbor state, eliminating the burden of maintaining such state. The real challenge is, without the knowledge of each neighbor, how do nodes achieve distributed coordination? This is what Probing Environment answers. It utilizes a probing mechanism by which a node discovers whether a working one exists in a certain probing range and decides whether it should be turned off. It determines the topology of working nodes while requiring minimum amount of knowledge of local neighborhood.

The next observation is that, how long nodes sleep decides how quick a dead working node can be replaced because only when sleeping nodes wake up can they replace dead working neighbors. Each unexpected death of working nodes causes an interruption in sensing and communication. The lengths of such interruptions should be kept within what are tolerable from the application’s perspective. Adaptive Sleeping decides when a sleeping node should wake up. It keeps the aggregate wake up rate of the sleeping neighbors of each working node at appropriate levels desired by the application, in order to meet application requirements and minimize the control overhead.

Design and Working of Proposed WSN

Each node in proposed WSN has three operation modes: Sleeping, Probing and Working. After nodes are deployed, they are initially in the Sleeping mode.

Each node sleeps for an exponentially distributed duration generated according to a probability density function (PDF

After a node wakes up, it enters the Probing mode. A probing node seeks to detect whether any working node is present within a certain probing range Rp .

The probing node uses an appropriate transmission power to broadcast a PROBE message within its local probing range Rp .

Any working node(s) within that range should respond with a REPLY message, also sent within the range of Rp .

It is possible that multiple working nodes exist within Rp when a node probes. To reduce collisions, each working node waits for a small random time before it sends back the REPLY.

If the probing node hears a REPLY, it goes back to the Sleeping mode for another random period of time ts , generated according to the same PDF.

If the probing node does not hear any REPLY, it enters the Working mode and starts functioning. Thus nodes can only work when they are far enough from existing working ones.

It is possible that PROBE and REPLY messages are still lost due to factors such as collisions or link errors. In such cases, a probing node supposed to sleep again will start working, unnecessarily wasting energy. To correct such errors, working node react to REPLYs sent by its working neighbors that respond to probing nodes. Because REPLYs are also sent within a distance of Rp , two working nodes are less than Rp away if they can hear the REPLYs from each other. One of them should be turned off.

In practice, if either of the two can turn off the other, they may take turns to work and cause an unstable working node topology. Many routing protocols have to rebuild routing state in new working nodes and suffer from unstable topologies.

Preliminary Simulation Results and Analysis

For the purpose of this study, we have experimented with various kinds of simulations on NS2 to understand and implement the proposed protocol for sensor Network.

The Simulation Parameters

The following list shows some of the important simulation parameters

 

The Simulation Scripts

Some of the Important Parameters

set opt(chan) Channel/WirelessChannel ;# channel type
set opt(prop) Propagation/TwoRayGround ;# radio-propagation model
set opt(ant) Antenna/OmniAntenna ;# Antenna type
set opt(ll) LL ;# Link layer type
set opt(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set opt(ifqlen) 10 ;# max packet in ifq
set opt(netif) Phy/WirelessPhy ;# network interface type
set opt(mac) Mac/802_11 ;# MAC type
set opt(rp1) DSDV
set opt(energymodel) EnergyModel ;
set opt(initialenergy) 60 ;# Initial energy in Joules

set opt(DefaultTransmissionPower) 0.060 ;# 60mW
set opt(DefaultReceptionPower) 0.012 ;#12mW
set opt(DefaultIdlePower) 0.012 ;#12mW
set opt(DefaultSleepModePower) 0.003 ;#0.03mW

set SleepingDuration 50 ;# in seconds
set MaxWakeupDuration 20
set NetworkField 500 ;# 
set InitDataSendTime 1 ;# in seconds
set FinishTime 200 ;# in seconds
set SensorNodeSize 10 ;# 5m is only for visibility of the node in NAM
set AgentPortAddress 40
set MaxRange 15 ;#Communication Range of the Sensor (in meters)
set TotalSensorNodes 100 ;#number of sensor Nodes 50,100,150,200, ...
set DataInterval 10 ;# in seconds
set DataSize 100 ;#25 in bytes. Increase it if you want to 'see' the packet in NAM
set PercentageOfWakeupNodes 15
set PercentageOfFailure 5
set FailureRate 1 ;#

set TotalRecievedDataPackets 0
set RecordingInterval 5
set TotalSentPackets 0


Phy/WirelessPhy set L_ 1.0

 

Setting Node Parameters

set topo [new Topography]

$topo load_flatgrid $NetworkField $NetworkField

#create-god $TotalSensorNodes
set god_ [create-god $TotalSensorNodes]

$ns node-config -adhocRouting $opt(rp1) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-topoInstance $topo \
-channelType $opt(chan) \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON \
-energyModel $opt(energymodel) \
-idlePower $opt(DefaultIdlePower) \
-rxPower $opt(DefaultReceptionPower) \
-txPower $opt(DefaultTransmissionPower) \
-sleepPower $opt(DefaultSleepModePower) \
-transitionPower $opt(DefaultTransmissionPower) \
-transitionTime 0.005 \
-initialEnergy $opt(initialenergy)

 

Designing the Protocol SensorAgent  by inheriting it from MessagePassing Agent

 

	

		
Hidden Section! Contact Charles  
		
The key/passphrase will be given once you have been approved for getting paid research support/assistance from Charles. To get paid support, you may start a 'free' research discussion.  
Discuss Through WhatsApp
 

		
		

			
			 
			
			
			
						
		
		
		

		
		

			
		
	



for {set idx 0} {$idx < [expr $TotalSensorNodes] } {incr idx} {

set node($idx) [$ns node ]
$god_ new_node $node($idx)
#puts $idx
$node($idx) random-motion 1 ;# disable random motion

set xval [expr [$rng integer [expr $NetworkField-$SensorNodeSize]] + $SensorNodeSize]
set yval [expr [$rng integer [expr $NetworkField-$SensorNodeSize]] + $SensorNodeSize]
$node($idx) set X_ $xval
$node($idx) set Y_ $yval
$node($idx) set Z_ 0.0 
$node($idx) color "green"

if { $idx == 0 } {
$ns at [$ns now] "$node($idx) color blue"
$ns initial_node_pos $node($idx) [expr $SensorNodeSize * 2 ] 
} else {
$ns initial_node_pos $node($idx) $SensorNodeSize 
} 
#puts "$xval $yval"
$ns at [$ns now] "$node($idx) setdest $xval $yval 99999"


# attach a new PEAS to on $AgentPortAddress
set SAgent($idx) [new Agent/SensorAgent]
$node($idx) attach $SAgent($idx) $AgentPortAddress
$SAgent($idx) set TotalSentDataPackets 0
# need to tell the agent about their link layers (for broadcast)
set ll [$node($idx) set ll_(0)]
#$ns at 0.0 "$SAgent($idx) set-ll $ll"

if {$idx == 0 } {
$SAgent($idx) set ModeOfTheNode "Waking"
}

$SAgent($idx) set ProbeReplyCount 0
if { $idx > 0 } {
set Jitter [expr ([$rng integer 100]+1.0 )/100.0]
if { [ expr [$rng integer 100] ] > $PercentageOfWakeupNodes } {
#$ns at [$ns now] "$node($idx) off"
$SAgent($idx) set ModeOfTheNode "NotDefined"
set tSleepingDuration [expr [$rng integer $SleepingDuration] + $Jitter ]
set Jitter [expr ([$rng integer 100]+1.0 )/10.0]
$ns at [expr [$ns now] + $Jitter ] "$SAgent($idx) PutNodeIntoSleepMode $tSleepingDuration"


} else {
$SAgent($idx) set ModeOfTheNode "Waking"
$ns at [expr [$ns now] + $Jitter ] "$SAgent($idx) WakeupNode"

}
$ns at [expr $InitDataSendTime + $Jitter + [$rng integer $DataInterval] ] "$SAgent($idx) ScheduleDataTransmission"
}

}



Agent/SensorAgent instproc WakeupNode {} {
$self instvar node_ ModeOfTheNode
global ns node rng MaxWakeupDuration SleepingDuration
set WakeupTime [$ns now]
$ns at $WakeupTime "$node_ on"
set id [$node_ node-addr]
$ns at $WakeupTime "$node_ delete-mark $id"
set ModeOfTheNode "Waking"
$ns at $WakeupTime "$ns trace-annotate \"$WakeupTime :Wakingup Sensor Node :[$node_ node-addr]\""
puts "$WakeupTime :Wakingup Sensor Node :[$node_ node-addr]"
set Jitter [expr ([$rng integer 100]+1.0 )/10.0]
$ns at [expr [$ns now] + $Jitter + $MaxWakeupDuration ] "$self PutNodeIntoSleepMode $SleepingDuration"
}


Agent/SensorAgent instproc PutNodeIntoSleepMode {SleepDuration} {
$self instvar node_ ModeOfTheNode
global ns node rng
set SleepingTime [$ns now]
$ns at $SleepingTime "$node_ off"
set ModeOfTheNode "Sleeping"
$ns at $SleepingTime "$ns trace-annotate \"$SleepingTime :Putting Sensor Node [$node_ node-addr] to Sleep Mode for $SleepDuration Seconds\""
puts "$SleepingTime :Putting Sensor Node [$node_ node-addr] to Sleep Mode for $SleepDuration Seconds"
set id [$node_ node-addr]
$ns at $SleepingTime "$node_ add-mark $id blue circle"
#sheduling wakeup probe
$ns at [expr $SleepingTime + $SleepDuration] "$self WakeupNode"

}


Agent/SensorAgent instproc ScheduleDataTransmission {} {
$self instvar node_ ModeOfTheNode TotalSentDataPackets 
global ns AgentPortAddress DataSize rng TransmissionJitter DataInterval 
set TransmissionJitter [expr [$rng integer 100] / 10.0]
if { $ModeOfTheNode == "Waking" } {
# it is a Wakeup Node so send sensor data to BS and Re-schedule Data Transmission
set CurrentSensorData "DATA"

$ns at [$ns now] "$self SendDataToBS 100 $CurrentSensorData"
set TotalSentDataPackets [expr $TotalSentDataPackets +1 ]

$ns at [expr [$ns now] + $DataInterval + $TransmissionJitter] "$self ScheduleDataTransmission"
} else {
$ns at [expr [$ns now] + $DataInterval + $TransmissionJitter] "$self ScheduleDataTransmission"
}

}

Agent/SensorAgent instproc SendDataToBS {size Value} {

$self instvar node_
global ns node AgentPortAddress


$self sendto $size $Value 0 $AgentPortAddress

}

Agent/SensorAgent instproc recv {source sport size message} {
$self instvar node_ ProbeReplyCount
global ns AgentPortAddress rng TotalRecievedDataPackets

#puts $message
$ns trace-annotate "[$ns now] :BS Recieved data from $source"


if { $message == "DATA" } {
puts "[$ns now] : BS Recieved data from $source"
set TotalRecievedDataPackets [expr $TotalRecievedDataPackets +1 ]
}
}

 

 

Creating Nodes and Setting up the Traffic

for {set i 0} {$i <$TotalSensorNodes } {incr i} {
set tt [expr 0 + [ $SAgent($i) set TotalSentDataPackets ] ]
set TotalSentPackets [expr $TotalSentPackets + $tt ]
$SAgent($i) set TotalSentDataPackets 0

set Status [$SAgent($i) set ModeOfTheNode ] 

if { $Status == "Waking" } {
set PWakingNodes [expr $PWakingNodes +1 ]
}
}

set PWakingNodes [expr $PWakingNodes / $TotalSensorNodes.0 * 100.0]

puts $fdSentDataPackets "$now $TotalSentPackets"
puts $fdPercentageOfWakingNodes "$now $PWakingNodes"

set pdf [expr $TotalRecievedDataPackets / ( $TotalSentPackets+1.0 ) * 100.0 ]
puts $fdPaketDeliveryRatio "$now $pdf"

set TotalSentPackets 0
set TotalRecievedDataPackets 0

#Re-Schedule The Procedure
$ns at [expr $now+$time] "record"

}

The Nam Output

 

In the above Nam output, the Green Color nodes are the Wakeup Sensor Nodes. The Nodes Marked with Blue (Except 0 – The BS Node) are Sleeping Sensor Nodes. The Blue Node 0 is the Base Station Node to Which All the sensor nodes will send the data.

The Wakeup Sensor Nodes Periodically sending data to Base Station.

 

The Console Output Showing Sensor Network Events

 

 

The Graphical Results

The following graph shows the average percentage of node that were in Wakeup mode over time.

 

 

The following graph shows the average sent data packets over time.

The following graph shows the average recieved data packets over time.

 

Conclusion

The implementation of reliable and efficient reporting mechanism with randomized energy-conservation protocol in wireless sensor networks has been done on ns-2.  To implement the wakeup and lleep modes in the wireless sensor node, the energy model of ns2 was used. So one should do the necessary change in ns2 and recompile it before running the proposed WSN simulation script.