Date post: | 14-Apr-2017 |
Category: |
Documents |
Upload: | akash-pandey |
View: | 35 times |
Download: | 0 times |
1 | P a g e
A MAJOR PROJECT REPORT ON
“Energy Efficient Wireless Sensor Networks”
Submitted By – Akash Pandey, Roll Number-1005011 Guided By - Asst Prof. Sital Dash
Department Of Computer Science and Engineering,
Kalinga Institute of Industrial Technology,
BHUBANESWAR, ODISHA.
2 | P a g e
Certificate.
This is to certify that the major project entitled Energy Efficient Wireless
Sensor Networks is being carried out by AKASH PANDEY, bearing roll number
1005011 in fulfillment for the award of degree of Bachelor of Technology in Computer
Science at the School of Computer Engineering, KIIT University, Bhubaneswar during
the academic year 2013-2014 under my supervision. The matter embodied in this report
is original and has not been submitted for the award of any other degree.
Signature Of Guide ______________________
(Asst. Prof. Sital Dash)
19th April, 2014
3 | P a g e
Acknowledgement.
I am overwhelmed in all humbleness and gratefulness to acknowledge our depth to all
those who have helped me to put my ideas and assigned work, well above the level of
simplicity and into something concrete.
I thank whole heartedly Asst. Prof. Sital Dash for constantly motivating for doing
better and showing complete confidence in my work.
I would also like to thank Prof. Amulya Ratna Swain for constantly guiding me
throughout my work, pointing the mistakes and helping me to add more effort.
4 | P a g e
Abstract.
A Wireless Sensor Network (WSN) consists of hundreds or thousands of sensor nodes or
motes equipped with various sensing devices to observe events in the real world. Sensor
nodes usually communicate among themselves using wireless only. Also they are usually
powered by battery, and therefore have limited energy. Besides each sensor node has
limited computation power and memory again due to constraints imposed by the
available supply of energy. The major function of WSNs is to observe and record events
in the environment and report them to the sink if necessary. In the process, the sink
node may also need to broadcast messages to each node of the WSN, and sensor nodes
may need to communicate with each other as well. Wireless sensor network are usually
deployed, possibly in extreme conditions such as mountainous region, and left
unattended to function for long time. In order to prolong the network lifetime, it is
necessary to minimize the consumption of energy by individual nodes. In addition, it is
also necessary to ensure that the average rate of consumption of energy by each node is
also the same. This would ensure that the connectivity needed to transmit data from a
sensor node to sink can always be maintained. A third requirement of WSNs for
applications such as tracking of intruders, detection of fire etc. is that the delay to
transmit data from sensor node to the sink should be as minimum as possible. These are
complex set of requirements which a routing protocol for wireless sensor networks
needs to fulfill. Moreover, the transceiver is the major unit that consumes lots of energy
in each sensor node even when it is idle. Therefore, sensor nodes are usually put to sleep
if they are not required to transmit data and/or sense environment, and the challenge is
to integrate sleep scheduling scheme with routing protocols for WSNs so that the
5 | P a g e
objective of routing protocols as given above are also met. We assume that the
transceiver, processor, and sensing units can be put to sleep independently and when we
say that the sensor node is put to sleep, we mean that the transceiver and the processor
are put to sleep. The sleep scheduling of sensing units can be done independently to
ensure sensing coverage.
6 | P a g e
Contents.
1.Introduction…………………………………………………………………………………………………………………………………………7
1.1 SENSORS.......................................................................................................................................8
1.1.1 Sensor Nodes .........................................................................................................................8
1.1.2 Sensor Networks..................................................................................................................13
1.1.2.1 Sensor Network Scenarios..............................................................................................14
1.2 Related Works............................................................................................................................18
2.Proposed Routing Protocol…………………………………………………………………………………………………………………23
2.1 Informal Description of the Algorithm ..........................................................................................24
2.1.1 Construction of the Broadcast Tree (BTC)...............................................................................25
2.2 The Algorithm .............................................................................................................................26
2.2.1 Explanation ..........................................................................................................................28
2.2.2 Transmission of Data from Source to Sink ..............................................................................31
3.Implementation………………………………………………………………………………………………………………………………….32
3.1 Code...........................................................................................................................................32
3.2 Challenges ..................................................................................................................................37
3.3 Workarounds ..............................................................................................................................38
4.Testing………………………………………………………………………………………………………………………………………………..39
4.1 Test Case (1)...............................................................................................................................39
4.1 Test Case (2)...............................................................................................................................41
5.Conclusion and Future scope………………………………………………………………………………………………………………49
6.References…………………………………………………………………………………………………………………………………………50
7 | P a g e
Introduction.
Wireless Sensor Networks (WSNs) consist of a large number of small and low cost
sensor nodes powered by small batteries and equipped with various sensing devices.
Usually, for many applications, once a WSN is deployed, probably in an inhospitable
terrain, it is expected to gather the required data for quite some time, say for years.
Since each sensor node has limited energy, these nodes are usually put to sleep to
conserve energy, and this helps to prolong the network lifetime. There are two major
approaches to sleep scheduling of sensor nodes, viz. (i) random (ii) synchronized. Any
sleep scheduling scheme has to ensure that data can always be routed from source to
sink. In this paper, we propose a novel approach for sleep scheduling of sensor nodes
using a tree and an energy aware routing protocol which is integrated with the proposed
sleep scheduling scheme. The tree is rooted at the sink node. The internal nodes of the
tree remain awake and the leaf nodes are made to sleep. This provides an assured path
from any node to the sink node. The tree is periodically reconstructed considering the
remaining energy of each node with a view to balance energy consumption of nodes, and
removes any failed nodes from the tree. The proposed approach also considerably
reduces average energy consumption rate of each node as we are able to put more
number of nodes to sleep in comparison to other approaches. Additional fault-tolerance
is provided by keeping two paths from each node towards the sink. Extensive simulation
studies of the proposed routing protocol has been carried out using Castalia simulator,
and its performance has been compared with that of a routing protocol, called GSP,
which incorporates sleep scheduling using random approach.
8 | P a g e
1.1 Sensors Generally speaking, a sensor is a device which responds to physical stimulus (such
as heat, light, sound, pressure, magnetism, etc.) and converts the quantity or parameter
of a physical stimulus into recordable signals (such as electrical signals, mechanical
signals, etc.) [28] . These signals are normally digitalized to produce sensing data.
Sensors represent a part of interfaces between the physical world and the world of
electrical devices, such as computers, and facilitate people to understand, monitor, and
control machines and environments. Sensors come in many types and shapes and can
measure almost all kinds of physical stimulus.
1.1.1 Sensor Nodes A sensor node, which is the basic unit of a sensor network, not only integrates sensors
for sensing the physical world but also includes other units to process and deliver
sensing data. A typical architecture of a sensor node is shown in the figure above, which
consists of sensor unit, communication unit, microcontroller unit, and memory and
power unit. A sensor node may also include some other units, depending on application
scenarios and requirements, such as a locomotive unit that enables a sensor node to
9 | P a g e
move around, an energy scavenge unit that obtains energy from the physical world, a
GPS unit that acquires node geographical location, etc.
Microcontroller Unit
The microcontroller is the core of a sensor node. Its functionalities include collecting
and processing the sensing data from the sensor unit, deciding where and when to send
the data, and controlling data reception from other sensor nodes, etc. We may liken the
microcontroller to the central processor unit (CPU) of a desktop computer; however, a
microcontroller consumes much less energy compared with a CPU. A microcontroller
can be implemented by an application-specific integrated circuit (ASIC) which is
designed for particular applications. A microcontroller can also be im plemented by
applying general reduced instruction set computer (RSIC) architectures running on
some operating systems (OS), such as the famous Tiny OS. Tiny OS is an open-source
operating system particularly designed to meet the severe constraints—small memory
and low power—of sensor nodes. Its event-driven execution model allows the scheduling
flexibility, which is essential to a wireless sensor node due to the unpredictable nature of
physical world stimuli and wireless communications. Usually, a microcontroller can
operate in different modes in order to save energy. This is done by only switching on
some parts of the microcontroller and switching off the other parts. Some general
operational modes include normal active mode, idle mode, and sleep mode. In the
active model, all parts of the processor are fully powered. In the idle model, clocks and
peripherals are active, and any interrupt will cause the microcontroller return back to
the active mode. In the sleep mode, only the real-time clock remains active, and a wake-
up occurs every fixed time interval.
10 | P a g e
Memory
The memory component includes both the on-chip random access memory (RAM) used
by the microcontroller and the on-board read-only memory (ROM) used for storing
program codes and sensory data. While RAM is fast, its main disadvantage
is that it loses its content if power supply is interrupted. The typical ROM includes
Electrically Erasable Programmable ROM (EEPROM) and flash memory, while the later
is similar to EEPROM but allowing data to be erased or written in blocks instead of only
a byte at a time. The volume and size of memory unit are much dependent on the
application requirements, ranging from hundreds of KB to hundreds of MB. The volume
of a memory of the same size has being continuously increased due to recent technique
advances. The power consumption of on-chip memory is typically included in the power
consumption numbers given for the microcontroller. Reading from and writing to on-
board flash memory consumes time and energy. The reading times and read energy
consumption are similar between different types of flash memory. But there are
considerable differences in writing times and write energy consumption among different
types of memory. As an example, the power consumption rate for reading from and
writing to the flash memory in a Mica sensor node are 1.111 nAh and 83.333 nAh,
respectively.
11 | P a g e
Sensor Unit
A sensor unit may consist of more than one type of sensors. Furthermore, a sensor unit
usually includes analogue-to-digital converters (ADCs), which convert the analog signals
produced by the sensors to digital signals and input to the microcontroller for further
processing. It is widely assumed in the literature that each sensor has a certain sensing
capability that can cover some area such that the quantity of interest in this area can be
reliably and accurately sensed. In other words, an active sensor can cover some subject
when it is turning on for sensing. The sensor unit can also be turned off for not sensing,
and hence it does not cover any subject at all. In such a case, the sensor unit is
deactivated, or it is called in a sleep state. The activation and deactivation of the sensor
unit are controlled by the microcontroller according to the implemented coverage
control algorithms in each sensor node. This book is devoted to various coverage control
problems in sensor networks and concerns with how to efficiently control the activation
and deactivation of sensor nodes in a network-wide way.
The power consumption rates are much different for different types and makes of
sensors. The power consumption of a sensor also depends on the application specific
sampling rate and accuracy requirement. The sampling rate determines how frequently
to output a unit of sensing data; and the accuracy requirement determines how to
enforce analogue-to-digital conversion and quantization. In most cases, a sensor does
not consume any energy if it is in the sleep state. Furthermore, the power consumption
rate for producing one-bit sensing data by an active sensor is usually regarded as much
less than that for transmitting or receiving one-bit sensing data by a transceiver.
12 | P a g e
However, it is still important to enforce some control of the sensor unit for more overall
energy savings, since processing and transmitting the sensing data produced by a sensor
unit also consume energy. Finally, we provide an example: For the humidity sensor of
the Mica Weather Board, the sampling rate is 500 Hz, and the current draw of the
sampling is 0.775 mA.
Communication Unit
The communication unit is used to exchange data among individual nodes. Both wired
and wireless communications are allowable for sensor nodes. In the case of wired
communications, sensor nodes have to be connected via wires or field buses, which
limits the flexibility and scalability of a sensor network. In both industrial and academic
domain, wireless communication is of more interests. In the case of wireless
communications, sensor nodes are equipped with transceivers and can easily form an
ad-hoc wireless sensor network (WSN) in an unattended way. A transceiver which
consists of a transmitter, a receiver, and all other necessary circuitry such as modulator
and demodulator, power amplifiers, filters, antenna, etc., converts bit streams to or
from radio waves. A radio transceiver usually works in a half-duplex way, since
transmitting and receiving at the same time over the wireless media is impractical in
most cases. Many transceivers can operate in four different operational modes, namely,
transmit, receive, idle, and sleep mode. In the transmit mode, the transmit part of the
transceiver is active, and the antenna radiates energy. In the receive mode, the receiver
part is active. In the idle mode, a transceiver is ready to receive but is not currently
receiving anything. In the idle mode, only a part of the receive circuitry is active, and the
rest can be switched off. In the sleep mode, most parts of a transceiver are switched off.
13 | P a g e
Usually, the sleep mode is the most energy saving mode with the least energy
consumption rate, and the next one is the idle mode. Some transceivers offer additional
sub modes that turn different parts of the transceiver on and off for further energy
saving. However, a considerable amount of energy is consumed when a transceiver
transits from one state to another. The mode of the transceiver is controlled by the
microcontroller according to the implemented algorithms and protocols.
Power Unit
The power unit of a sensor node usually consists of one or more non rechargeable
batteries, sometimes, chargeable batteries are used if some energy scavenging device
(such as photovoltaic cells) is also present on the node. Both non chargeable
and chargeable batteries output power by converting the stored chemical energy to
electrical energy. Different types of batteries may have different capacities. It is
desirable that a battery has high capacity (milliampere-hour, mAh) at small size, tiny
weight, and low cost.
1.1.2 Sensor Networks Sensor nodes are usually deployed in a field of interests to monitor some physical
phenomena. Such a field is called a sensor field, and the sensor nodes form a sensor
network. Diverse scenarios exist in the architecture and management of sensor
networks. Numerous sensor network applications are expected to emerge in the near
future.
14 | P a g e
1.1.2.1 Sensor Network Scenarios
A sensor network normally consists of a large number of sensor nodes and one or more
sinks. Sensor nodes monitor physical phenomena and produce sensory data. A sink, on
the other hand, does not generate any data by itself but collects data from sensor nodes.
A sink can be regarded as a gateway between a sensor network and other networks, or
an interface between a sensor network and the people operating the sensor network.
sink is often assumed as resource abundant, without energy supply limit and with
advanced computation capability. Aside from data collection, a sink is also a central
controller which can execute network management algorithms and instruct sensor
15 | P a g e
nodes only the computation results. Sensor networks may work in different
architectural and operational scenarios, depending on the sensor nodes’ and sinks’
capabilities and on the communication paradigm used by the sensor nodes and sinks.
For example, some sensor nodes may have more advanced sensor unit, microcontroller,
or radio transceivers, which enable them to take more responsibilities in the whole
sensor network. Sensor nodes or sinks may also be equipped with locomotives which
enable them to move around the sensor field for better performing tasks. In what
follows, we introduce several typical sensor network scenarios.
Homogeneous vs. Heterogeneous Networks
In a homogeneous sensor network, all sensor nodes have the same sensing, processing,
communication, and other capabilities (excluding the initial power supply). Figures (b)
and (d) illustrate two homogeneous networks. In a heterogeneous sensor network,
sensor nodes have different capabilities. For example, a node may have a stronger
sensor unit and can cover a larger area. Figures (a) and (c) present two examples of
heterogeneous networks. Two nodes that have different amount of initial power supplies
but with identical all the other capabilities are usually not considered as two
heterogeneous nodes. A homogeneous network can be considered as just many copies of
a sensor node in different geographical locations, and due to such characteristics, many
theoretical analyses are carried out for homogeneous networks. On the other hand, it is
generally recognized that the performance of a homogeneous network can be greatly
improved by adding some more advanced sensor nodes or some mobile sensor nodes.
For example, in Fig. (c) some advanced sensor nodes serve as cluster heads to form
clusters.
16 | P a g e
Stationary vs. Mobile Networks
In a stationary sensor network, all sensor nodes are fixed and cannot move around after
they have been deployed. A mobile sensor node is equipped with a locomotive unit and
can move around after deployment. In general, a mobile node is more expensive than its
stationary compeer. It is usually considered in the literature that a mobile sensor
network is a network consisting of only mobile nodes, and a hybrid sensor network is a
network consisting of both stationary nodes and mobile nodes. As mobile nodes can
move to desired locations, it is not unexpected that using mobile nodes can improve
sensor network performance. Such performance improvements are often at the cost of
expensive mobile nodes and more energy consumed for moving. In some cases, a sink
can also be a mobile node, and it moves around to collect sensing data. For example,
Fig. (d) illustrates a trajectory along which a mobile sink moves.
Single-Hop vs. Multi-Hop Networks
There are two basic communication paradigms between sensor nodes and sinks,
namely, single-hop communication and multi-hop communication. In a single-hop
sensor network, all sensor nodes transmit directly to the sink. Figure (a) illustrates a
single-hop sensor network where all stationary sensor nodes transmit directly, via either
wired or wireless communications, to the sink outside the sensor field. Such a direct
communication paradigm might be very expensive, especially for a large-scale network.
17 | P a g e
If wired communication is used, the cost of wires might be much larger than that of
sensor nodes. If wireless communication is used, the long distance between a node and
the sink requires very high transmission power. Another option is to use mobile sinks
which move around in the sensor field to collect data via short-distance radio
communication, as illustrated by Fig. (b). In such a case, a sensor node only transmits to
the sink when the sink moves close to itself, and due to the reduced transmission
distance, a considerable amount of transmission energy can be saved. In a multi-hop
sensor network, instead of transmitting to the sink directly, some sensor nodes use a
multi-hop path consisting of other nodes as relays to deliver their data to the sink. Many
routing algorithms, such as the Djikstra shortest-path algorithm, can be used to find an
appropriate multi-hop path for each node. Figure (b) illustrates a flat multi-hop sensor
network where only three nodes closer to the sink transmit to the sink directly, and
others uses multi-hop communications. Figure (c) illustrates a hierarchical multi-hop
sensor network where clusters are formed, and some powerful nodes serve as cluster
heads and other nodes serve as cluster members. In a cluster, each cluster member
transmits to its cluster head via either single-hop or multi-hop transmission. The choice
of a single-hop or a multi-hop network is heavily dependent on the application
requirements. In general, a single-hop network is easy to maintain and suitable for
small-scale networks. Multi-hop networks, on the other hand, are often the practical
choices for large-scale networks with hundreds or thousands of nodes. It is worth noting
that, unlike the traditional store-and-forward networks, in network data processing is
allowed and even encouraged in sensor networks. In the store-and-forward networks, an
intermediate relay node does not attempt to modify received data but just retransmit the
data to other nodes. However, the idea of in-network data processing is to allow a node
18 | P a g e
to process its received data packets, analyzing the packets’ content and even aggregating
them to a new packet yet with reduced volume. Multi-hop networks, obviously, are the
better choice for in-network processing.
1.2 Related Works In general, routing in WSNs can be divided into three types, viz. flat structure based
routing, hierarchical structure based routing and location-based routing . In flat
structure based routing , all nodes are typically assigned equal roles or functionality. In
hierarchical structure based routing , however, nodes play different roles in the network
depending on their position in the hierarchy. In location-based routing [10][11], sensor
nodes’ positions are exploited to route data in the network. In the recent past, many
routing protocols have been proposed for sensor networks. Most of the protocols try to
ensure that the consumption of energy by different nodes of WSN does not lead to
situations where some nodes become dead early, and thereby disrupt the connectivity of
the WSN. The descriptions of some of these protocols are as given below. Heinzelman,
Kulik, and Balakrishnan have proposed a protocol, called Sensor Protocols for
Information via Negotiation (SPIN), that provides data-centric routing approach where
the data should be named using high level descriptors or metadata. The SPIN family of
protocols includes many protocols. The main two protocols are called SPIN-1 and SPIN-
2. The SPIN-1 protocol is a 3-stage protocol, but does not consider any energy aware
technique. However, in SPIN- 2, when energy in the nodes is abundant, it
communicates using the 3-stage protocol of SPIN-1. However, when the energy in a
node starts approaching a low energy threshold, it reduces its participation in the
19 | P a g e
protocol, i.e., it participates only when it believes that it can complete all the other
stages of the protocol without going below the low-energy threshold. In the energy
aware routing protocol proposed by Shah and Rabaey, a set of path is chosen based on
probability. The value of this probability depends on how low the energy consumption of
each path is. By choosing paths at different times, the energy of any single path will not
deplete quickly, and this can achieve longer network lifetime as energy is dissipated
more equally among all nodes. The protocol initiates a connection through localized
flooding, which is used to discover all routes between source to sink and their costs; thus
building up the routing tables. The high-cost paths are discarded and a forwarding table
is built by choosing neighboring nodes in a manner that is proportional to their cost.
Problems with this protocol are complex addressing method and communication
overhead during the setup phase. Ye, Chen, Lu, and Zhang have proposed an algorithm,
called Minimum Cost Forwarding Algorithm (MCFA) , that sets up a back off based cost
field to find the optimal cost path from all the nodes to the sink. Once the field is
established, the message, carrying dynamic cost information, flows along the minimum
cost path in the cost field. This protocol consists of two phases. First phase is a setup
phase for setting up the cost value in all nodes. In the second phase, the source
broadcasts the data to its neighbors. To reduce the number of broadcast messages, the
MCFA was modified to run a back off algorithm at the setup phase. The back off
algorithm dictates that a node will not send the updated message until back off time
units have elapsed from the time at which the message is updated. Problems with the
algorithm are high consumption of bandwidth and it may cause duplicate copies of
sensor messages to arrive at the sink. In Power Aware Chain (PAC) [15] routing protocol
proposed by Pham, Kim, Doh, and Yoo, all nodes organize themselves into the energy
20 | P a g e
efficient chain with the help of MCFA protocol and depth first search. One node, elected
as leader node, transmits data back to sink on behalf of all other nodes. Leader node
election is based on the power available and the power needed for transmission from the
node to sink. Each node aggregates received data from the previous node in the chain
with its own collected data to produce an aggregated data packet. In the recent past,
Hong and Yang have proposed an energy balanced multipath routing protocol for sensor
network which is based on rumor routing technique. In this protocol, authors consider a
probabilistic approach to find multipath from source to sink by considering the residual
energy and hop count from source to sink. Chakchouk, Hamdaoui, and Frikhax also
have proposed a protocol that uses remaining energy and the hop count from sensor
node to the sink in order to make hop-by-hop energy-aware routing. There are some
energy aware routing protocol like which use hierarchical or cluster based approach by
considering the residual energy or remaining energy to distribute the traffic over the
whole network and also prolong the network lifetime. All the routing protocols
discussed above are based on energy-aware technique. But, to minimize energy
consumption and prolong the lifetime of the network, the routing protocols have to
support sleep scheduling schemes so that most of the nodes are put to sleep, and the
remaining nodes are active. There are very few routing protocols that support sleep
scheduling and some of them are described below. Hou and Tipper have proposed flat
structure based protocol called Gossip-based Sleep Protocol (GSP) that employs
probabilistic based sleep modes. At the beginning of a gossip period, each node chooses
either to sleep with probability p or to stay awake with probability 1 - p for the period, so
that all the sleep nodes will not be able to transmit or receive any packet during the
period. When an active node receives any packet, it must retransmit the same. All
21 | P a g e
sleeping nodes wake up at the end of each period. All the nodes repeat the above process
for every period extending the lifetime of densely deployed wireless sensor networks by
keeping only a necessary set of sensor nodes active. It presents an algorithm for finding
out which nodes should be put into sleep mode depending upon their location in sensing
area. After deciding which nodes should be in sleep mode, and which nodes should be in
active mode, the sink node generates a tree structure for routing purpose by using a
breadth-first search (BFS) over the connective graph of active nodes. The whole process
runs periodically. In this case, if the period is large and any node goes down in the
middle of this period, then the whole routing structure can be disturbed. However, if we
reduce the period, the operation performed at the beginning of each period is more, and
hence, the energy consumption over whole network is also increased. From the above, it
is clear that the equal consumption of energy by all nodes is an important requirement
to prolong the network lifetime. However, if the nodes for sleeping are chosen randomly
as in, a path from source to sink may not always be present, and sufficient number of
nodes have to remain awake to ensure the existence of such a path. Alternatively, data
can be stored at a node till a neighboring node towards the sink is found, but this
approach would delay the delivery of the message to the sink considerably.
Alternatively, a fixed path may be chosen from a node to the sink as in . The problem
with the approach in is that the whole process is centralized, and the decisions of the
sink node need to be conveyed to all the nodes. However, in this approach, delay to
transmit data from source to sink will be less as such a path will always exist. In this
paper, we have proposed a distributed algorithm for constructing such a tree using the
approach given in. The algorithm is energy aware and always chooses the paths whose
nodes have higher remaining energy. In addition, the tree constructed is fault -tolerant
22 | P a g e
to single node failure, i.e., the communication from a node will not be disrupted due to
the failure of a single neighbor node in the tree.
23 | P a g e
Proposed Routing Protocol
The routing protocol proposed in this section is intended for WSNs in which sensor
nodes are static. Besides the applications running in the WSN require that the
information gathered by the sensor nodes have to be transmitted immediately to the
sink. Furthermore, it is also assumed that each node has a unique ID, and the
communication between neighboring nodes is symmetric and bidirectional. It is also
assumed that the clocks of the sensor nodes in the WSN are synchronized so that nodes
can be woken up nearly at the same time, and they can execute the proposed protocol.
The objectives of the proposed routing protocol with sleep scheduling are as follows.
(i) Most sensor nodes should be asleep most of the time so that the energy consumption
by each node is reduced.
(ii) Consumption of energy by all the sensor nodes remains balanced, i.e., at any time,
every node should have consumed nearly the same amount of energy.
(iii) Time required to transmit data from a sensor node to the sink is as minimum as
possible subject to the constraints given in (ii) above.
24 | P a g e
2.1 Informal Description of the Algorithm
During the construction of the tree, the following needs to be ensured in order to
minimize energy consumption during the tree construction phase and provide support
for fault-tolerance.
(i) Number of broadcasts is as minimum as possible.
(ii) There are two branches from each node of the tree towards the sink to ensure fault-
tolerance.
After the construction of the tree is complete, each node can identify itself either as
internal node of the tree or as leaf node of the tree. The leaf nodes are put to sleep and
internal nodes remain awake. A node wishing to send data to the sink can send it along
the edges of the tree towards the sink. The tree is constructed in such a way that the
internal nodes have higher remaining energy compared to the other nodes. This is
required to ensure that the consumption of energy by all nodes remains balanced. The
tree is reconstructed periodically to ensure balanced consumption of energy by all the
nodes. As outlined above, the proposed routing protocol with sleep scheduling consists
of the following.
(i) Construction of the broadcast tree at the beginning of the every period.
(ii) Transmission of the data from source to sink whenever required.
25 | P a g e
2.1.1 Construction of the Broadcast Tree (BTC)
Each node in the WSN stores the IDs of two parent nodes along with the associated least
cost of the paths to the sink through them. The nodes which are directly reachable from
the sink have both the parent nodes set to sink node. Besides, each node also stores its
node ID, its remaining energy, the cost to be added to a path to sink that passes through
this node. These variables at each node j are represented as follows.
CFj,1 = Value of first cost field of node j
CFj,2 = Value of second cost field of node j
PFj,1 = Value of first parent node field of node j
PFj,2 = Value of second parent node field of node j
Nj = jth node
REj = Remaining energy of Nj
Cj =1/REj= Each node’s cost to be added to a path.
26 | P a g e
2.2 The Algorithm
27 | P a g e
28 | P a g e
2.2.1 Explanation
The broadcast tree construction of the routing protocol consists of two phases. In the
first phase, the sink node broadcast an advertisement message ADV1. Upon receipt of
ADV1 message, each node of the WSN executes the algorithm given in the procedure
BTC-phase1, and set its first parent field so that the path to the sink node through it has
least cost. Upon completion of the first phase, the sink broadcast a second
advertisement message ADV2. Upon receipt of ADV2 message, each node of the WSN
executes the algorithm given in the procedure BTC-phase2, and set its second parent
field so that the path to the sink node through it has the second least cost. The
advertisement messages ADV1 and ADV2 broadcasted by node j have the following
parameters.
ADV 1 = (Nj ,CFj,1, PFj,1), ADV 2 = (Nj ,CFj,1)
The algorithm to construct the initial tree is given in the procedure BTC-phase1 which
performs its task as follows. At the beginning of first period, each node except the sink
node sets its both cost fields to ∞ and parent node fields to -1, but at the beginning of
subsequent periods, each node only sets its both cost field to ∞ and no change is made to
the parent node fields. The sink node sets its both cost fields to 0 and set its parent node
fields to its own ID. At the beginning of this phase, sink node broadcasts an ADV1
message to all its neighbors. When a node receives an ADV1 message, it does not
broadcast its own ADV1 message to its neighbor immediately. Before sending the ADV1
message to its neighbors, the following steps are executed.
1. When a node receives the first ADV1 message, it sets back off timer.
29 | P a g e
2. If the first ADV1 message comes from the sink node, then the node stores the sink
node ID in two parent node fields, and computes the new cost by adding reciprocal of its
remaining energy to the received cost, and stores the new cost in two cost fields. If the
first ADV1 message comes from any other node, then the node compares the new cost
with the existing cost stored in the first cost field. If the new cost is less than the existing
cost, then the new cost value is stored in two cost fields of the node and received node
ID is stored in two parent node fields.
3. Upon reception of any further ADV1 message from other neighbors, it computes the
new cost in the same way as in step 2. If the node has already stored the sink node ID in
its parent node field, then it will discard the ADV1 message, otherwise, it compares this
new cost with the existing cost stored in its first cost field and updates its cost fields and
parent node fields as in step2.
Once the backoff timer expires, the node broadcasts ADV1 message that contains its own
ID, the value stored in the first cost field, and the parent node ID stored in the first
parent node field. After broadcasting ADV1 message, if a node receives any ADV1
message from any other node, then the node compares its own ID with the parent node
ID stored in the received broadcast message. If its own ID is equal to the parent node ID
in received ADV1 message, the node declares itself as an internal node. If a node does
not receive any ADV1 message where its own ID is equal to the parent node ID stored in
the broadcast message, then the node declares itself as a leaf node. The algorithm to add
second parent to each node of the tree constructed in phase 1 is given in the procedure
BTCphase2 which performs its task as follows. At the beginning of this phase, sink node
broadcasts an ADV2 message to all its neighbors. When a node receives the first ADV2
30 | P a g e
message, it sets back off timer. When a node receives an ADV2 message, and the node
has already stored the sink node ID in its parent node fields or the node ID stored in the
received ADV2 message is equal to the node ID stored in its first parent node field, it
will discard the ADV2 message. Otherwise, the node executes the following steps:
1) If the node receives the ADV2 message from the sink node, then it computes the new
cost by adding reciprocal of its remaining energy to the received cost, and sets its two
cost fields to new cost and stores the sink node ID in its both parent node fields.
2) If both the parent node fields of the receiving node are equal, then it stores the new
cost value as computed in step 1 in the second cost field and stores the received node ID
in the second parent node field.
3) If both the parent node fields of the receiving node are not equal, then it compares
the new cost with the cost stored in the second cost field, and if the new cost is less than
the value stored in the second cost field, then it stores the new cost value in the second
cost field and stores the received node ID in the second parent node field.
After receiving the first ADV2 message, if a node has declared itself as an internal node
in the first phase of the algorithm, the node broadcast its own ADV2 message that
contains its own ID and the value stored in the first cost field. Upon receipt of further
ADV2 message from any other node, it will not broadcast any more advertisement
message. Once the back off timer expires, if a node has declared itself as a leaf node in
the first phase of the algorithm, then the node goes to sleep mode.
After completion of BTC phase, each node is classified either as an internal node or as a
leaf node. Since a leaf node will not receive any data packets from any other node for
onward transmission, it can go to sleep till the beginning of next period or till it detects
31 | P a g e
an event. The leaf nodes will again participate in the BTC phase at the beginning of next
period.
2.2.2 Transmission of Data from Source to Sink
When an event occurs at an internal node, data will be transmitted to a parent node in
the tree. If an event occurs at a leaf node, the node will wake up and transmit data and
again go to sleep till next event or next period whichever is earlier. Each data packet
consists of ID of node which would receive the data, ID of node which generated the
data, and the data itself. Data will be transmitted from source to sink via minimum cost
paths computed in the BTC phase. The first packet received by any internal node is
forwarded to its parent that is in the first parent node field, and the next packet is
forwarded to the parent that is in the second parent node field. Similarly, for subsequent
data packets, it chooses one of the parents from parent node fields alternately. A
periodic check is also made using hello packet to find out if any of the parent is dead. If
any parent is dead, packets are forwarded to active parent only.
32 | P a g e
Implementation.
3.1 Code
ValueReporting.cc
#include "ValueReporting.h"
#include<math.h>
Define_Module(ValueReporting);
void ValueReporting::startup()
{
first_rcv=0;
n[0].nodeID=n[1].nodeID=-1;
active=0;
level=0;
currSentSampleSN = 0;
sentOnce = false;
if(isSink)
{
active=1;
setTimer(REQUEST_SAMPLE,1+genk_dblrand(0)/100);
}
}
void ValueReporting::timerFiredCallback(int index)
{
ValueReportData reqData;
ValueReportingDataPacket *packet2Net = new
ValueReportingDataPacket("Value reporting pck", APPLICATION_PACKET);
switch (index)
{
case REQUEST_SAMPLE:
{ //in case of sink node;
// requestSensorReading();
//packet creation and sending request
//a request packet
reqData.nodeID = (unsigned short)self;
reqData.locX = mobilityModule->getLocation().x;
33 | P a g e
reqData.locY = mobilityModule->getLocation().y;
reqData.destID1=-99; //since broadcast message.
reqData.destID2=-99;
reqData.pacType=1; //request packet
cost=0.5(1/reqrEnergy());
reqData.cost=cost;
reqData.level=level;
packet2Net->setExtraData(reqData);
packet2Net-
>setSequenceNumber(currSentSampleSN);
currSentSampleSN++;
toNetworkLayer(packet2Net,
BROADCAST_NETWORK_ADDRESS);
sentOnce = true;
break;
}
case SEND_DATA:
{
reqData.nodeID = (unsigned short)self;
reqData.locX = mobilityModule->getLocation().x;
reqData.locY = mobilityModule->getLocation().y;
reqData.destID1=n[0].nodeID;
reqData.destID2=n[1].nodeID;
reqData.pacType=0; // packet from other node
distance=(mobilityModule-
>getLocation().x,mobilityModule->getLocation().y,n[0].locX,n[0].locY);
cost= 1*(n[0].cost+(1/reqrEnergy())) +
1*(distance);
reqData.cost=cost;
while(!level) //if the level is not set
{
if(n[0].nodeID!=-1 && n[1].nodeID!=-1)
level= (n[0].level < n[1].level) ?
(n[0].level+1) : (n[1].level+1);
else if(n[0].nodeID==-1)
level= (n[1].level)+1;
else
level= (n[0].level)+1;
}
reqData.level=level;
packet2Net->setExtraData(reqData);
packet2Net-
>setSequenceNumber(currSentSampleSN);
currSentSampleSN++;
toNetworkLayer(packet2Net,
BROADCAST_NETWORK_ADDRESS); //send to its neighbour
break;
34 | P a g e
}
}
}
void ValueReporting::fromNetworkLayer(ApplicationPacket * genericPacket,
const char *source, double rssi, double lqi)
{
ValueReportingDataPacket *rcvPacket =
check_and_cast<ValueReportingDataPacket*>(genericPacket);
ValueReportData theData = rcvPacket->getExtraData();
int i,j;
if(!isSink)
{
if (theData.pacType==1) //if request packet from sink
{
{
n[0].nodeID=n[1].nodeID=theData.nodeID;
n[0].locX=theData.locX;
n[0].locY=theData.locY;
n[1].locX=theData.locX;
n[1].locX=theData.locY;
n[0].cost=n[1].cost=(theData.cost);
level=1;
setTimer(SEND_DATA,0+genk_dblrand(0));
}
}
else if(theData.destID1!=self && theData.destID2!=self) // request
packet from any other node
{
if(first_rcv==0) //if the node is receiving for the
first time
{
setTimer(SEND_DATA,5+genk_dblrand(0)/100);
first_rcv=1;
}
for(int i=0;i<2;i++)
{
if(n[i].nodeID==-1 || n[i].cost > (theData.cost))
{//if parents are unallocated or the received
cost is less than existing cost
n[i].nodeID=theData.nodeID;
n[i].locX=theData.locX;
n[i].locY=theData.locY;
35 | P a g e
n[i].cost=(theData.cost);
n[i].level=theData.level;
break;
}
}
}
else if(theData.destID1==self||theData.destID2==self)//reply
packet from the neighbour
{
while(active==0)
active=1;
}
}
}
void ValueReporting::handleSensorReading(SensorReadingMessage * rcvReading)
{
}
void ValueReporting::finishSpecific()
{
trace()<<self<<" Parents ="<<n[0].nodeID<<" "<<n[1].nodeID<<" ,Active-
"<<active<<" ,Level="<<level;
}
double ValueReporting:: reqrEnergy()
{
double initialEnergy;
double spentEnergy;
double remainingEnergy;
initialEnergy=(double)par("initialEnergy");
spentEnergy=resMgrModule->getSpentEnergy();
remainingEnergy=(initialEnergy-spentEnergy);
return remainingEnergy;
}
double ValueReporting:: calcDistance(double x1,double y1,double x2,double y2)
{
double distance=sqrt((x2-x1)*(x2-x1) + (y2-y1)*(y2-y1));
return (1/distance);
}
36 | P a g e
ValueReporting.h
#ifndef _VALUEREPORTING_H_
#define _VALUEREPORTING_H_
#include "VirtualApplication.h"
#include "ValueReportingPacket_m.h"
using namespace std;
enum ValueReportingTimers {
REQUEST_SAMPLE = 1,
SEND_DATA = 2,
};
struct StoreNodeInfo
{
int nodeID;
double cost;
int level;
double locX;
double locY;
};
class ValueReporting: public VirtualApplication {
private:
double maxSampleInterval;
double minSampleInterval;
int routingLevel;
double lastSensedValue;
int currSentSampleSN;
double randomBackoffIntervalFraction;
bool sentOnce;
struct StoreNodeInfo n[2];
int first_rcv;//first receive
double cost;
int active;
int level;
double distance;
protected:
void startup();
void fromNetworkLayer(ApplicationPacket *, const char *, double,
double);
void handleSensorReading(SensorReadingMessage *);
void timerFiredCallback(int);
double reqrEnergy();
37 | P a g e
void finishSpecific();
double calcDistance(double,double,double,double);
};
#endif // _VALUEREPORTING_APPLICATIONMODULE_H_
3.2 Challenges The project seemed to have been facing some challenges,according to the observations
made the following challenges were outlined:
1)Low powered sensors- The sensors to be used for the technology exhibited very low
processing power, battery dependency, wireless radios. Hence the major challenge was
to optimize the algorithm in such a way that the energy can be conserved without
depleting fast, as well as the load wasn't much on the individual sensors.
2)Energy depleted quickly-The nodes which were placed nearer to the sink node,
depleted more quickly than the nodes placed farther from the sink. This was due to the
fact that nearer nodes had to be working/communicating all the time.
38 | P a g e
3.3 Workarounds
1)For the low powered sensors the only solution was the optimization of the algorithm.
2)For the nodes that depleted energy more quickly the formula to choose a particular
node was edited a bit to add the idea of its cost and distance from the sink.
Cj “(edited)= (1-α) *( Cj) + α*(1/d)
[ α-the parameter to be provided, d-distance of the node from the sink]
39 | P a g e
Testing
4.1 Test Case (1) Number of nodes=50, Area=200x200,distribution=uniform
Results: Number of active nodes=24, Maximum level=6
----------------------------------------------------------------------------------------------------
600.002031536877SN.node[0].Application 0 Parents =3 3
,Active- 1 ,Level=1
600.002031536877SN.node[1].Application 1 Parents =3 3
,Active- 1 ,Level=1
600.002031536877SN.node[2].Application 2 Parents =15 34
,Active- 0 ,Level=2
600.002031536877SN.node[3].Application 3 Parents =-1 -1
,Active- 1 ,Level=0
600.002031536877SN.node[4].Application 4 Parents =31 39
,Active- 1 ,Level=3
600.002031536877SN.node[5].Application 5 Parents =46 -1
,Active- 0 ,Level=5
600.002031536877SN.node[6].Application 6 Parents =0 34
,Active- 1 ,Level=2
600.002031536877SN.node[7].Application 7 Parents =3 3
,Active- 0 ,Level=1
600.002031536877SN.node[8].Application 8 Parents =15 27
,Active- 0 ,Level=2
600.002031536877SN.node[9].Application 9 Parents =28 44
,Active- 0 ,Level=5
600.002031536877SN.node[10].Application 10 Parents =36 23
,Active- 1 ,Level=3
600.002031536877SN.node[11].Application 11 Parents =15 49
,Active- 0 ,Level=2
600.002031536877SN.node[12].Application 12 Parents =9 17
,Active- 1 ,Level=3
600.002031536877SN.node[13].Application 13 Parents =-1 -1
,Active- 0 ,Level=0
600.002031536877SN.node[14].Application 14 Parents =29 -1
,Active- 0 ,Level=3
600.002031536877SN.node[15].Application 15 Parents =3 3
,Active- 1 ,Level=1
600.002031536877SN.node[16].Application 16 Parents =19 10
,Active- 1 ,Level=3
600.002031536877SN.node[17].Application 17 Parents =28 22
,Active- 0 ,Level=2
600.002031536877SN.node[18].Application 18 Parents =1 29
,Active- 0 ,Level=2
600.002031536877SN.node[19].Application 19 Parents =40 10
,Active- 0 ,Level=4
600.002031536877SN.node[20].Application 20 Parents =40 -1
,Active- 0 ,Level=4
40 | P a g e
600.002031536877SN.node[21].Application 21 Parents =7 0
,Active- 0 ,Level=2
600.002031536877SN.node[22].Application 22 Parents =28 20
,Active- 1 ,Level=3
600.002031536877SN.node[23].Application 23 Parents =34 34
,Active- 1 ,Level=2
600.002031536877SN.node[24].Application 24 Parents =28 44
,Active- 0 ,Level=4
600.002031536877SN.node[25].Application 25 Parents =49 -1
,Active- 0 ,Level=2
600.002031536877SN.node[26].Application 26 Parents =7 34
,Active- 0 ,Level=2
600.002031536877SN.node[27].Application 27 Parents =7 21
,Active- 1 ,Level=2
600.002031536877SN.node[28].Application 28 Parents =44 -1
,Active- 1 ,Level=4
600.002031536877SN.node[29].Application 29 Parents =1 -1
,Active- 1 ,Level=2
600.002031536877SN.node[30].Application 30 Parents =9 44
,Active- 0 ,Level=4
600.002031536877SN.node[31].Application 31 Parents =28 20
,Active- 0 ,Level=4
600.002031536877SN.node[32].Application 32 Parents =0 34
,Active- 1 ,Level=2
600.002031536877SN.node[33].Application 33 Parents =34 32
,Active- 0 ,Level=2
600.002031536877SN.node[34].Application 34 Parents =3 3
,Active- 1 ,Level=1
600.002031536877SN.node[35].Application 35 Parents =44 -1
,Active- 1 ,Level=5
600.002031536877SN.node[36].Application 36 Parents =0 23
,Active- 1 ,Level=2
600.002031536877SN.node[37].Application 37 Parents =1 29
,Active- 0 ,Level=2
600.002031536877SN.node[38].Application 38 Parents =34 34
,Active- 1 ,Level=2
600.002031536877SN.node[39].Application 39 Parents =0 17
,Active- 1 ,Level=2
600.002031536877SN.node[40].Application 40 Parents =31 16
,Active- 1 ,Level=3
600.002031536877SN.node[41].Application 41 Parents =3 3
,Active- 0 ,Level=1
600.002031536877SN.node[42].Application 42 Parents =36 10
,Active- 1 ,Level=3
600.002031536877SN.node[43].Application 43 Parents =12 7
,Active- 0 ,Level=2
600.002031536877SN.node[44].Application 44 Parents =28 -1
,Active- 1 ,Level=4
600.002031536877SN.node[45].Application 45 Parents =15 0
,Active- 0 ,Level=2
600.002031536877SN.node[46].Application 46 Parents =42 -1
,Active- 1 ,Level=4
600.002031536877SN.node[47].Application 47 Parents =7 1
,Active- 0 ,Level=2
600.002031536877SN.node[48].Application 48 Parents =35 -1
,Active- 0 ,Level=6
41 | P a g e
600.002031536877SN.node[49].Application 49 Parents =3 3
,Active- 0 ,Level=1
4.1 Test Case (2) Number of nodes=200, Area=200x200, Distribution=uniform
Results: Number of active nodes=63, Maximum level=7
--------------------------------------------------------------------------------------------------
600.045340165434SN.node[0].Application 0 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[1].Application 1 Parents =71 176
,Active- 0 ,Level=2
600.045340165434SN.node[2].Application 2 Parents =176 175
,Active- 0 ,Level=2
600.045340165434SN.node[3].Application 3 Parents =-1 -1
,Active- 1 ,Level=0
600.045340165434SN.node[4].Application 4 Parents =94 158
,Active- 0 ,Level=2
600.045340165434SN.node[5].Application 5 Parents =93 58
,Active- 0 ,Level=4
600.045340165434SN.node[6].Application 6 Parents =133 193
,Active- 0 ,Level=2
600.045340165434SN.node[7].Application 7 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[8].Application 8 Parents =28 133
,Active- 0 ,Level=2
600.045340165434SN.node[9].Application 9 Parents =108 110
,Active- 1 ,Level=3
600.045340165434SN.node[10].Application 10 Parents =159 121
,Active- 1 ,Level=3
600.045340165434SN.node[11].Application 11 Parents =185 175
,Active- 0 ,Level=2
600.045340165434SN.node[12].Application 12 Parents =61 108
,Active- 1 ,Level=5
600.045340165434SN.node[13].Application 13 Parents =176 187
,Active- 0 ,Level=2
600.045340165434SN.node[14].Application 14 Parents =85 176
,Active- 0 ,Level=2
600.045340165434SN.node[15].Application 15 Parents =185 175
,Active- 0 ,Level=2
600.045340165434SN.node[16].Application 16 Parents =159 105
,Active- 1 ,Level=3
600.045340165434SN.node[17].Application 17 Parents =22 108
,Active- 0 ,Level=3
600.045340165434SN.node[18].Application 18 Parents =183 79
,Active- 1 ,Level=3
600.045340165434SN.node[19].Application 19 Parents =193 120
,Active- 1 ,Level=2
600.045340165434SN.node[20].Application 20 Parents =94 114
,Active- 1 ,Level=2
42 | P a g e
600.045340165434SN.node[21].Application 21 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[22].Application 22 Parents =108 158
,Active- 0 ,Level=3
600.045340165434SN.node[23].Application 23 Parents =22 193
,Active- 0 ,Level=2
600.045340165434SN.node[24].Application 24 Parents =28 178
,Active- 0 ,Level=3
600.045340165434SN.node[25].Application 25 Parents =93 54
,Active- 0 ,Level=3
600.045340165434SN.node[26].Application 26 Parents =43 64
,Active- 0 ,Level=2
600.045340165434SN.node[27].Application 27 Parents =30 150
,Active- 0 ,Level=2
600.045340165434SN.node[28].Application 28 Parents =102 12
,Active- 1 ,Level=5
600.045340165434SN.node[29].Application 29 Parents =71 43
,Active- 1 ,Level=2
600.045340165434SN.node[30].Application 30 Parents =108 94
,Active- 1 ,Level=4
600.045340165434SN.node[31].Application 31 Parents =22 94
,Active- 0 ,Level=3
600.045340165434SN.node[32].Application 32 Parents =126 55
,Active- 0 ,Level=4
600.045340165434SN.node[33].Application 33 Parents =185 107
,Active- 0 ,Level=2
600.045340165434SN.node[34].Application 34 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[35].Application 35 Parents =177 9
,Active- 0 ,Level=4
600.045340165434SN.node[36].Application 36 Parents =90 159
,Active- 1 ,Level=2
600.045340165434SN.node[37].Application 37 Parents =71 180
,Active- 0 ,Level=3
600.045340165434SN.node[38].Application 38 Parents =193 39
,Active- 1 ,Level=2
600.045340165434SN.node[39].Application 39 Parents =108 94
,Active- 1 ,Level=3
600.045340165434SN.node[40].Application 40 Parents =193 89
,Active- 1 ,Level=2
600.045340165434SN.node[41].Application 41 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[42].Application 42 Parents =121 16
,Active- 0 ,Level=4
600.045340165434SN.node[43].Application 43 Parents =177 9
,Active- 0 ,Level=4
600.045340165434SN.node[44].Application 44 Parents =61 108
,Active- 0 ,Level=2
600.045340165434SN.node[45].Application 45 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[46].Application 46 Parents =93 58
,Active- 0 ,Level=4
600.045340165434SN.node[47].Application 47 Parents =71 98
,Active- 0 ,Level=2
600.045340165434SN.node[48].Application 48 Parents =9 197
,Active- 0 ,Level=4
43 | P a g e
600.045340165434SN.node[49].Application 49 Parents =185 176
,Active- 0 ,Level=2
600.045340165434SN.node[50].Application 50 Parents =193 114
,Active- 1 ,Level=2
600.045340165434SN.node[51].Application 51 Parents =177 197
,Active- 1 ,Level=5
600.045340165434SN.node[52].Application 52 Parents =24 148
,Active- 1 ,Level=2
600.045340165434SN.node[53].Application 53 Parents =177 28
,Active- 0 ,Level=2
600.045340165434SN.node[54].Application 54 Parents =176 175
,Active- 1 ,Level=2
600.045340165434SN.node[55].Application 55 Parents =121 91
,Active- 0 ,Level=4
600.045340165434SN.node[56].Application 56 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[57].Application 57 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[58].Application 58 Parents =159 93
,Active- 1 ,Level=3
600.045340165434SN.node[59].Application 59 Parents =58 169
,Active- 0 ,Level=4
600.045340165434SN.node[60].Application 60 Parents =94 155
,Active- 0 ,Level=3
600.045340165434SN.node[61].Application 61 Parents =28 197
,Active- 0 ,Level=5
600.045340165434SN.node[62].Application 62 Parents =85 176
,Active- 0 ,Level=2
600.045340165434SN.node[63].Application 63 Parents =20 174
,Active- 0 ,Level=3
600.045340165434SN.node[64].Application 64 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[65].Application 65 Parents =16 93
,Active- 0 ,Level=4
600.045340165434SN.node[66].Application 66 Parents =128 174
,Active- 1 ,Level=3
600.045340165434SN.node[67].Application 67 Parents =108 94
,Active- 0 ,Level=3
600.045340165434SN.node[68].Application 68 Parents =177 21
,Active- 1 ,Level=2
600.045340165434SN.node[69].Application 69 Parents =28 133
,Active- 0 ,Level=3
600.045340165434SN.node[70].Application 70 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[71].Application 71 Parents =177 21
,Active- 0 ,Level=2
600.045340165434SN.node[72].Application 72 Parents =16 93
,Active- 0 ,Level=4
600.045340165434SN.node[73].Application 73 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[74].Application 74 Parents =176 77
,Active- 0 ,Level=2
600.045340165434SN.node[75].Application 75 Parents =193 114
,Active- 0 ,Level=2
600.045340165434SN.node[76].Application 76 Parents =71 98
,Active- 0 ,Level=2
44 | P a g e
600.045340165434SN.node[77].Application 77 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[78].Application 78 Parents =133 178
,Active- 0 ,Level=3
600.045340165434SN.node[79].Application 79 Parents =71 180
,Active- 1 ,Level=3
600.045340165434SN.node[80].Application 80 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[81].Application 81 Parents =185 176
,Active- 0 ,Level=2
600.045340165434SN.node[82].Application 82 Parents =133 21
,Active- 0 ,Level=2
600.045340165434SN.node[83].Application 83 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[84].Application 84 Parents =50 121
,Active- 0 ,Level=3
600.045340165434SN.node[85].Application 85 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[86].Application 86 Parents =158 38
,Active- 0 ,Level=2
600.045340165434SN.node[87].Application 87 Parents =98 117
,Active- 0 ,Level=2
600.045340165434SN.node[88].Application 88 Parents =94 -1
,Active- 1 ,Level=3
600.045340165434SN.node[89].Application 89 Parents =121 10
,Active- 0 ,Level=4
600.045340165434SN.node[90].Application 90 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[91].Application 91 Parents =121 10
,Active- 0 ,Level=4
600.045340165434SN.node[92].Application 92 Parents =133 -1
,Active- 0 ,Level=3
600.045340165434SN.node[93].Application 93 Parents =159 16
,Active- 1 ,Level=3
600.045340165434SN.node[94].Application 94 Parents =28 133
,Active- 0 ,Level=5
600.045340165434SN.node[95].Application 95 Parents =187 180
,Active- 0 ,Level=2
600.045340165434SN.node[96].Application 96 Parents =177 71
,Active- 0 ,Level=2
600.045340165434SN.node[97].Application 97 Parents =94 158
,Active- 0 ,Level=4
600.045340165434SN.node[98].Application 98 Parents =177 71
,Active- 1 ,Level=3
600.045340165434SN.node[99].Application 99 Parents =175 175
,Active- 0 ,Level=2
600.045340165434SN.node[100].Application 100 Parents =93 58
,Active- 0 ,Level=3
600.045340165434SN.node[101].Application 101 Parents =66 -1
,Active- 0 ,Level=4
600.045340165434SN.node[102].Application 102 Parents =108 24
,Active- 1 ,Level=4
600.045340165434SN.node[103].Application 103 Parents =176 34
,Active- 0 ,Level=2
600.045340165434SN.node[104].Application 104 Parents =98 43
,Active- 0 ,Level=2
45 | P a g e
600.045340165434SN.node[105].Application 105 Parents =19 121
,Active- 0 ,Level=3
600.045340165434SN.node[106].Application 106 Parents =16 93
,Active- 0 ,Level=4
600.045340165434SN.node[107].Application 107 Parents =133 39
,Active- 0 ,Level=2
600.045340165434SN.node[108].Application 108 Parents =28 -1
,Active- 0 ,Level=6
600.045340165434SN.node[109].Application 109 Parents =175 93
,Active- 0 ,Level=2
600.045340165434SN.node[110].Application 110 Parents =61 28
,Active- 0 ,Level=6
600.045340165434SN.node[111].Application 111 Parents =177 117
,Active- 0 ,Level=2
600.045340165434SN.node[112].Application 112 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[113].Application 113 Parents =193 83
,Active- 0 ,Level=2
600.045340165434SN.node[114].Application 114 Parents =128 19
,Active- 0 ,Level=3
600.045340165434SN.node[115].Application 115 Parents =94 -1
,Active- 0 ,Level=3
600.045340165434SN.node[116].Application 116 Parents =177 150
,Active- 0 ,Level=2
600.045340165434SN.node[117].Application 117 Parents =177 189
,Active- 0 ,Level=5
600.045340165434SN.node[118].Application 118 Parents =71 21
,Active- 0 ,Level=2
600.045340165434SN.node[119].Application 119 Parents =108 94
,Active- 0 ,Level=3
600.045340165434SN.node[120].Application 120 Parents =148 159
,Active- 0 ,Level=3
600.045340165434SN.node[121].Application 121 Parents =50 16
,Active- 1 ,Level=3
600.045340165434SN.node[122].Application 122 Parents =16 93
,Active- 0 ,Level=4
600.045340165434SN.node[123].Application 123 Parents =185 193
,Active- 0 ,Level=2
600.045340165434SN.node[124].Application 124 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[125].Application 125 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[126].Application 126 Parents =148 159
,Active- 1 ,Level=3
600.045340165434SN.node[127].Application 127 Parents =94 158
,Active- 0 ,Level=2
600.045340165434SN.node[128].Application 128 Parents =97 165
,Active- 0 ,Level=3
600.045340165434SN.node[129].Application 129 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[130].Application 130 Parents =176 175
,Active- 0 ,Level=2
600.045340165434SN.node[131].Application 131 Parents =28 43
,Active- 1 ,Level=2
600.045340165434SN.node[132].Application 132 Parents =174 -1
,Active- 0 ,Level=3
46 | P a g e
600.045340165434SN.node[133].Application 133 Parents =158 24
,Active- 1 ,Level=4
600.045340165434SN.node[134].Application 134 Parents =176 175
,Active- 0 ,Level=2
600.045340165434SN.node[135].Application 135 Parents =108 94
,Active- 0 ,Level=2
600.045340165434SN.node[136].Application 136 Parents =93 58
,Active- 0 ,Level=4
600.045340165434SN.node[137].Application 137 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[138].Application 138 Parents =185 0
,Active- 1 ,Level=2
600.045340165434SN.node[139].Application 139 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[140].Application 140 Parents =61 98
,Active- 1 ,Level=3
600.045340165434SN.node[141].Application 141 Parents =185 85
,Active- 1 ,Level=2
600.045340165434SN.node[142].Application 142 Parents =94 69
,Active- 1 ,Level=3
600.045340165434SN.node[143].Application 143 Parents =36 93
,Active- 0 ,Level=3
600.045340165434SN.node[144].Application 144 Parents =175 139
,Active- 0 ,Level=2
600.045340165434SN.node[145].Application 145 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[146].Application 146 Parents =177 71
,Active- 0 ,Level=2
600.045340165434SN.node[147].Application 147 Parents =58 11
,Active- 1 ,Level=3
600.045340165434SN.node[148].Application 148 Parents =193 38
,Active- 0 ,Level=2
600.045340165434SN.node[149].Application 149 Parents =61 108
,Active- 0 ,Level=4
600.045340165434SN.node[150].Application 150 Parents =177 71
,Active- 1 ,Level=4
600.045340165434SN.node[151].Application 151 Parents =28 133
,Active- 1 ,Level=3
600.045340165434SN.node[152].Application 152 Parents =61 110
,Active- 0 ,Level=4
600.045340165434SN.node[153].Application 153 Parents =61 98
,Active- 0 ,Level=2
600.045340165434SN.node[154].Application 154 Parents =93 58
,Active- 0 ,Level=4
600.045340165434SN.node[155].Application 155 Parents =94 70
,Active- 0 ,Level=2
600.045340165434SN.node[156].Application 156 Parents =94 114
,Active- 1 ,Level=2
600.045340165434SN.node[157].Application 157 Parents =133 21
,Active- 0 ,Level=2
600.045340165434SN.node[158].Application 158 Parents =151 24
,Active- 1 ,Level=4
600.045340165434SN.node[159].Application 159 Parents =193 105
,Active- 1 ,Level=2
600.045340165434SN.node[160].Application 160 Parents =71 175
,Active- 0 ,Level=2
47 | P a g e
600.045340165434SN.node[161].Application 161 Parents =98 133
,Active- 1 ,Level=2
600.045340165434SN.node[162].Application 162 Parents =94 101
,Active- 0 ,Level=2
600.045340165434SN.node[163].Application 163 Parents =28 43
,Active- 0 ,Level=2
600.045340165434SN.node[164].Application 164 Parents =176 175
,Active- 0 ,Level=2
600.045340165434SN.node[165].Application 165 Parents =94 156
,Active- 0 ,Level=2
600.045340165434SN.node[166].Application 166 Parents =133 -1
,Active- 0 ,Level=3
600.045340165434SN.node[167].Application 167 Parents =85 176
,Active- 0 ,Level=2
600.045340165434SN.node[168].Application 168 Parents =85 176
,Active- 0 ,Level=2
600.045340165434SN.node[169].Application 169 Parents =121 16
,Active- 0 ,Level=4
600.045340165434SN.node[170].Application 170 Parents =121 16
,Active- 0 ,Level=3
600.045340165434SN.node[171].Application 171 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[172].Application 172 Parents =110 197
,Active- 0 ,Level=4
600.045340165434SN.node[173].Application 173 Parents =94 165
,Active- 0 ,Level=2
600.045340165434SN.node[174].Application 174 Parents =94 165
,Active- 0 ,Level=2
600.045340165434SN.node[175].Application 175 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[176].Application 176 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[177].Application 177 Parents =61 -1
,Active- 1 ,Level=4
600.045340165434SN.node[178].Application 178 Parents =108 98
,Active- 1 ,Level=2
600.045340165434SN.node[179].Application 179 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[180].Application 180 Parents =96 18
,Active- 1 ,Level=3
600.045340165434SN.node[181].Application 181 Parents =133 24
,Active- 0 ,Level=2
600.045340165434SN.node[182].Application 182 Parents =150 71
,Active- 1 ,Level=5
600.045340165434SN.node[183].Application 183 Parents =176 187
,Active- 1 ,Level=2
600.045340165434SN.node[184].Application 184 Parents =85 180
,Active- 0 ,Level=2
600.045340165434SN.node[185].Application 185 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[186].Application 186 Parents =71 172
,Active- 1 ,Level=2
600.045340165434SN.node[187].Application 187 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[188].Application 188 Parents =3 3
,Active- 0 ,Level=1
48 | P a g e
600.045340165434SN.node[189].Application 189 Parents =177 98
,Active- 1 ,Level=4
600.045340165434SN.node[190].Application 190 Parents =10 93
,Active- 1 ,Level=3
600.045340165434SN.node[191].Application 191 Parents =150 71
,Active- 1 ,Level=2
600.045340165434SN.node[192].Application 192 Parents =108 94
,Active- 0 ,Level=3
600.045340165434SN.node[193].Application 193 Parents =3 3
,Active- 1 ,Level=1
600.045340165434SN.node[194].Application 194 Parents =19 89
,Active- 0 ,Level=3
600.045340165434SN.node[195].Application 195 Parents =94 165
,Active- 0 ,Level=3
600.045340165434SN.node[196].Application 196 Parents =22 108
,Active- 1 ,Level=3
600.045340165434SN.node[197].Application 197 Parents =110 -1
,Active- 0 ,Level=7
600.045340165434SN.node[198].Application 198 Parents =3 3
,Active- 0 ,Level=1
600.045340165434SN.node[199].Application 199 Parents =175 93
,Active- 0 ,Level=2
49 | P a g e
Conclusion and Future Work
In this paper, we have presented an energy aware routing protocol with sleep scheduling
for WSNs. The core of the routing protocol is the efficient construction of the broadcast
tree with two paths from each node towards the sink, and with higher remaining energy
at each internal node of the tree. The tree is reconstructed at the beginning of each
period so that none of these nodes die before other nodes, which means that all nodes
will die at around the same time. Consecutive packets are routed through alternative
path to reduce traffic in individual paths. Leaf node sleep mechanism is highly energy
efficient as more number of nodes are able to sleep, and this helps to prolong the
network lifetime. We have evaluated the performance of our protocol through
simulation studies for different number of nodes and rounds. Simulation results show
that data packet delivery in our multipath protocol is more than that using unipath, and
energy consumption of nodes is also balanced. Comparison with GSP shows that our
protocol has more number of sleep nodes, and therefore provides longer network
lifetime. We have used very high data rate in our simulation studies. Future work
includes adaptively adjusting the period of tree reconstruction depending on the input
data rate with a view to further increase the network lifetime.
50 | P a g e
References
[1] L. Wang and Y. Xiao, “A survey of energy-efficient scheduling mechanisms in sensor networks,” Mob. Netw. Appl., vol. 11, no. 5, pp. 723–740, 2006.
[2] X. Hou and D. Tipper, “Gossip-based sleep protocol (gsp) for energy efficient routing in wireless ad hoc networks,” in Wireless Communications and Networking Conference, 2004. WCNC. 2004 IEEE, vol. 3, March 2004, pp. 1305–1310 Vol.3. [3] J. Al-Karaki and A. Kamal, “Routing techniques in wireless sensor networks: a survey,” Wireless Communications, IEEE, vol. 11, no. 6, pp. 6–28, Dec. 2004. [4] K. Akkaya and M. F. Younis, “A survey on routing protocols for wireless sensor networks,” Ad Hoc Networks, vol. 3, no. 3, pp. 325–349, 2005 . [5] R. Sim´on Carbajo, M. Huggard, and C. McGoldrick, “An end-to-end routing protocol for peer-to-peer communication in wireless sensor networks,” in MiNEMA ’08: Proceedings of the 6th workshop on Middleware for network eccentric and mobile applications. New York, NY, USA: ACM, 2008, pp. 5–9. [6] D. Braginsky and D. Estrin, “Rumor routing algorthim for sensor networks,” in WSNA ’02: Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications. New York, NY, USA: ACM, 2002, pp. 22–31. [7] W. Jinghua, G. Tingting, H. Huan, and C. Yuanyuan, “An energy and load-based routing algorithm in wireless sensor network,” in Computational Intelligence and Design, 2009. ISCID ’09. Second International Symposium on, vol. 1, Dec. 2009, pp. 284–287. [8] L. Hong and J. Yang, “An energy-balance multipath routing based on rumor routing for wireless sensor networks,” in Natural Computation, 2009. ICNC ’09. Fifth International Conference on, vol. 3, Aug. 2009, pp. 87–91. [9] N. Chakchouk, B. Hamdaoui, and M. Frikha, “Wcds-induced routing for data-aggregation in wireless sensor networks,” in
51 | P a g e
Communications and Networking, 2009. ComNet 2009. First International Conference on, Nov. 2009, pp. 1–6. [10] n. Zamalloa, Marco Z´u K. Seada, B. Krishnamachari, and A. Helmy, “Efficient geographic routing over lossy links in wireless sensor networks,” ACM Trans. Sen. Netw., vol. 4, no. 3, pp. 1–33, 2008. [11] S.-C. Choi, S.-L. Gong, and J.-W. Lee, “An average velocitybased routing protocol with low end-to-end delay for wireless sensor networks,” Communications Letters, IEEE, vol. 13, no. 8, pp. 621–623, August 2009. [12] W. R. Heinzelman, J. Kulik, and H. Balakrishnan, “Adaptive protocols for information dissemination in wireless sensor networks,” in MobiCom ’99: Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking. New York, NY, USA: ACM, 1999, pp. 174–185. [13] R. Shah and J. Rabaey, “Energy aware routing for low energy ad hoc sensor networks,” in Wireless Communications and Networking Conference, 2002. WCNC2002. 2002 IEEE, vol. 1, Mar 2002, pp. 350–355 vol.1. [14] F. Ye, A. Chen, S. Lu, and L. Zhang, “A scalable solution to minimum cost forwarding in large sensor networks,” in Computer Communications and Networks, 2001. Proceedings. Tenth International Conference on, 2001, pp. 304–309. [15] M.-L. Pham, D. Kim, Y. Doh, and S. eun Yoo, “Power aware chain routing protocol for data gathering in sensor networks,” in Intelligent Sensors, Sensor Networks and Information Processing Conference, 2004. Proceedings of the 2004, Dec. 2004, pp. 107–112. [16] T. Liu, Y. Gu, and Z. Hu, “Energy equalizing routing algorithm for wireless sensor networks,” in Computational Intelligence and Design, 2009. ISCID ’09. Second International Symposium on, vol. 1, Dec. 2009, pp. 546–549. [17] E. Bulut and I. Korpeoglu, “Dssp: A dynamic sleep scheduling protocol for prolonging the lifetime of wireless sensor networks,” in Advanced Information Networking and Applications Workshops, 2007, AINAW ’07. 21st International Conference on, vol. 2, May 2007, pp. 725–730.
52 | P a g e
[18] “Castalia a simulator for wireless sensor networks,” http://castalia.npc.nicta.com.au/pdfs/Castalia User Manual.pdf. [19] “Cc2420 data sheet,” http://www.stanford.edu/class/cs244e/ papers/cc2420.pdf. [20] “Telosb data sheet,” http://www.xbow.com/Products/ Product pdf files/Wireless pdf/TelosB Datasheet.pdf.