major project report

52
1 | Page A MAJOR PROJECT REPORT ON Energy Efficient Wireless Sensor NetworksSubmitted 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.

Upload: akash-pandey

Post on 14-Apr-2017

35 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: MAJOR PROJECT REPORT

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.

Page 2: MAJOR PROJECT REPORT

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

Page 3: MAJOR PROJECT REPORT

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.

Page 4: MAJOR PROJECT REPORT

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

Page 5: MAJOR PROJECT REPORT

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.

Page 6: MAJOR PROJECT REPORT

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

Page 7: MAJOR PROJECT REPORT

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.

Page 8: MAJOR PROJECT REPORT

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

Page 9: MAJOR PROJECT REPORT

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.

Page 10: MAJOR PROJECT REPORT

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.

Page 11: MAJOR PROJECT REPORT

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.

Page 12: MAJOR PROJECT REPORT

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.

Page 13: MAJOR PROJECT REPORT

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.

Page 14: MAJOR PROJECT REPORT

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

Page 15: MAJOR PROJECT REPORT

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.

Page 16: MAJOR PROJECT REPORT

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.

Page 17: MAJOR PROJECT REPORT

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

Page 18: MAJOR PROJECT REPORT

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

Page 19: MAJOR PROJECT REPORT

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

Page 20: MAJOR PROJECT REPORT

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

Page 21: MAJOR PROJECT REPORT

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

Page 22: MAJOR PROJECT REPORT

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.

Page 23: MAJOR PROJECT REPORT

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.

Page 24: MAJOR PROJECT REPORT

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.

Page 25: MAJOR PROJECT REPORT

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.

Page 26: MAJOR PROJECT REPORT

26 | P a g e

2.2 The Algorithm

Page 27: MAJOR PROJECT REPORT

27 | P a g e

Page 28: MAJOR PROJECT REPORT

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.

Page 29: MAJOR PROJECT REPORT

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

Page 30: MAJOR PROJECT REPORT

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

Page 31: MAJOR PROJECT REPORT

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.

Page 32: MAJOR PROJECT REPORT

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;

Page 33: MAJOR PROJECT REPORT

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;

Page 34: MAJOR PROJECT REPORT

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;

Page 35: MAJOR PROJECT REPORT

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);

}

Page 36: MAJOR PROJECT REPORT

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();

Page 37: MAJOR PROJECT REPORT

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.

Page 38: MAJOR PROJECT REPORT

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]

Page 39: MAJOR PROJECT REPORT

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

Page 40: MAJOR PROJECT REPORT

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

Page 41: MAJOR PROJECT REPORT

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

Page 42: MAJOR PROJECT REPORT

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

Page 43: MAJOR PROJECT REPORT

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

Page 44: MAJOR PROJECT REPORT

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

Page 45: MAJOR PROJECT REPORT

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

Page 46: MAJOR PROJECT REPORT

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

Page 47: MAJOR PROJECT REPORT

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

Page 48: MAJOR PROJECT REPORT

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

Page 49: MAJOR PROJECT REPORT

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.

Page 50: MAJOR PROJECT REPORT

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

Page 51: MAJOR PROJECT REPORT

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.

Page 52: MAJOR PROJECT REPORT

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.