FINAL PROJECT REPORT

A PROJECT REPORT ON
DYNAMIC ROUTING OF PACKETS IN
WIRELESS SENSOR NETWORKS
UNDER THE GUIDANCE
PROF. G.R. Pathak
BY
APEKSHA A. JAIN (B8238565) ROHIT M. KULKARNI (B8238577)
SOHAM C. WADEKAR (B8238639) KEDAR D.WAGHOLIKAR (B8238640)
IN THE PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE
AWARD OF THE DEGREE
OF
BACHELOR OF ENGINEERING
(INFORMATION TECHNOLOGY)
AT
DEPARTMENT OF INFORMATION TECHNOLOGY
SINHGAD COLLEGE OF ENGINEERING, PUNE 411041
AFFILATED TO
UNIVERSITY OF PUNE

i
MAY 2012
CERTIFICATE
This is to certify that the project report entitles
“DYNAMIC ROUTING OF PACKETS IN WIRELESS SENSOR NETWORKS”
Submitted by
APEKSHA A. JAIN (B8238565)
ROHIT M. KULKARNI (B8238577)
SOHAM C. WADEKAR (B8238639)
KEDAR D.WAGHOLIKAR (B8238640)
Is a bonafide work carried out by them under the supervision of Prof. G.R. Pathak and it is approved
for the partial fulfilment of the requirement of University of Pune, Pune for the award of the degree of
Bachelor of Engineering (Information Technology)
This project work has not been earlier submitted to any other Institute or University for the award of
any degree or diploma.
(Prof. G.R. Pathak)
Guide
Department of Information Technology
(Prof. A.W. Rohankar) (Prof. S.D. Lokhande)
Head Principal
Department of Information Technology Sinhgad College of Engineering
EXAMINATION:
EXAMINER 1:.................................................................
EXAMINER 2:.................................................................

30 March, 2012
B.E Project Certificate of Completion
This is to certify that following students have completed their final year
B.E. Project at Persistent Systems Ltd. for academic year 2011-12.
The project details are as below:
Project Title: Dynamic routing of packets in wireless sensor networks.
Project Mentor: Janardhan Hungund
College Name: SCOE
Name of Students:
i. Rohit Mangesh Kulkarni
ii. Kedar Deepak Wagholikar
iii. Soham Chandrashekhar Wadekar
iv. Apeksha Avneesh Jain
For Persistent Systems Ltd.
Kaustubh Bhadbhade
Manager - Human Resource

ABSTRACT
Sensor networks consist of a large number of small independent devices. Each device, called
a sensor node, is battery powered and equipped with integrated sensors, data processing, and
short-range radio communication capabilities. A significant amount of research has been
done in the area of connecting large numbers of these sensors to create robust and scalable
Wireless Sensor Networks (WSNs). Although individual sensor nodes have limited
capabilities, WSNs aim to be energy efficient, self-organizing, scalable, and robust. A
substantial amount of research has cantered on meeting these challenges.
The large deployment of WSNs and the need for energy efficient strategy necessitate efficient
organization of the network topology for the purpose of balancing the load and prolonging
the network lifetime. Clustering has been proven to provide the required scalability and
prolong the network lifetime. Due to the bottle neck phenomena in WSNs, a sensor network
loses its connectivity with the base station and the remaining energy resources of the
functioning nodes are wasted.
This project aims to implement a clustering scenario and analyze the effects of increase in the
number of nodes in the cluster on the energy of Cluster Head (CH). The sensor nodes are free
to move from one cluster to another. The project further aims to implement an energy
efficient dynamic algorithm which re-elects the CH after a specific period of time hence,
saving energy. We also compare the efficiency of this algorithm by analyzing the graphs of
energy levels of the CH during the lifetime of the network.
ii

ACKNOWLEDGEMENT
We have great pleasure and sense of satisfaction in presenting this project report on “Routing
Protocol for Dynamic Wireless Sensor Network”. We take this opportunity to express our
sincere thanks to all those people who have helped us to complete this project successfully.
We hereby take this opportunity to record our sincere thanks and heartily gratitude to our
internal guide Prof. G. R. Pathak for his useful guidance and for sharing his intimate
knowledge and experience in preparation of the project with us. We would like to sincerely
thank him for his valuable time and for rectifying our errors, to make our project more
accurate. We also want to thank the entire faculty of Department of Information Technology
especially for giving us their constant guidance.
We are pleased to express our deep sense of gratitude to our Head of Department Prof. A .W.
Rohankar and our principal Prof. S. D. Lokhande for their support.
We would also like to thank Mr. Janardhan Hungund, our mentor from Persistent Systems
Limited for their continuous cooperation, encouragement and valuable help and coordination
in achieving the project goals.
Last but not the least, we would like to thank Mr. Sanket Sabnis, Mr. Sahil Shah, Mr.
Tanmay Sawant and Mr. Suresh Rathore for sharing their knowledge on the topic and helping
in making it a better project.
June 2011
Place: Pune
iii

Contents
CERTIFICATE i
ABSTRACT ii
ACKNOWLEDGEMENT iii
1 INTRODUCTION 1
1.1 Wireless Sensor Network........................................................................... 2
1.2 Application................................................................................................. 3
1.3 Challenges.................................................................................................. 4
1.4 Report Structure......................................................................................... 4
2 BACKGROUND AND LITERATURE SURVEY 6
2.1 Clustering…………................................................................................... 7
2.2 Energy Efficient Routing Protocols……................................................... 8
2.3 Routing Protocol in Wireless Sensor Networks......................................... 9
2.4 Addressing Schemes.................................................................................. 11
2.5 Literature Survey........................................................................................ 12
3 PROBLEM STATEMENT 13
3.1 Basic Cluster Communication.................................................................... 14
3.2 Re-Election Algorithm............................................................................... 15
3.3 Movement of Nodes................................................................................... 17
4 PROJECT PLANNING 18
4.1 Project Development Life Cycle................................................................ 19
4.2 Software Requirement Specifications........................................................ 19
4.3 Project Schedule and Gantt Chart….......................................................... 20

5 PROJECT ANALYSIS 23
5.1 Use Case Diagrams.................................................................................... 24
5.2 Sequence Diagrams.................................................................................... 27
6 PROJECT DESIGN 28
6.1 Class Diagram............................................................................................ 29
6.2 Activity Diagram........................................................................................ 30
7 IMPLEMENTATION 31
7.1 Network Simulator..................................................................................... 32
7.2 A Sample TCL Script……….................................................................... 33
7.3 Simulation Logic…….…........................................................................... 36
8 ANALYSIS 44
8.1 Scenario 1................................................................................................... 47
8.2 Scenario 2................................................................................................... 48
8.3 Scenario 3................................................................................................... 50
9 CONCLUSION 50
10 FUTURE SCOPE 52
11 APPENDIX A 54
12 BIBLIOGRAPHY 61

LIST OF FIGURES
1.1 Architecture of a Sensor Node………………………………………….. 2
2.1 Distributed cluster formation in LEACH…………………………….…. 8
2.2 AODV Routing Path……………………………………………………… 10
3.1 Cluster Communication Architecture……………………………………. 14
3.2 Cluster Head re-election…………………………………………………. 16
4.1 Iterative Life Cycle……………………………………………………… 19
4.2 Gantt Chart……………………………………………………………… 22
5.1 Use Case of WSN ……………………………………………………… 24
5.2 Use Case of CH Re-election …………………………………………… 25
5.2 Sequence Diagram of CH Re-election…………………………………. 27
6.1 Class Diagram………………………………………………………….. 29
6.2 Activity Diagram………………………………………………………. 30
7.1 Basic Structure of NS…………………………………………………… 32
7.2 Application Node………………………………………………………. 39
7.3 The Basic Structure of a Mobile Node…………………………………. 40
7.4 The Movement of nodes………………………………………………… 44
8.1 Snapshot of Scenario1…………………………………………………… 47

8.2 Xgraph image of Scenario 1……………………………………………… 48
8.3 Snapshot of Scenario2……………………………………………………. 49
8.4 Xgraph image of Scenario 2…………………………………………….. 49
8.5 Snapshot of Scenario3…………………………………………………... 50
8.6 XGraph of Scenario3 …............................................................................ 50
8.7 X-Graph on the Basis of All Three Scenario………………………….... 51
A.1 C++ -- OTcl linkage……………………………………………………... 53
A.2 Major components in NS……………………………………………….. 59

LIST OF TABLES
4.1 Project Schedule………………………………………………………… 20

DEPARTMENT OF INFORMATION TECHNOLOGY, SCOE
1
CHAPTER 1
INTRODUCTION

2
CHAPTER 1
INTRODUCTION
1.1 WIRELESS SENSOR NETWORK
The field of Wireless Sensor Networks may be in an infant stage but has a made great
progress over the years. WSN is a network of sensor nodes deployed over a wide area. The
sensor nodes are micro computers having the ability of sensing data, capturing, processing
and transmit it to the sink or main base station of the information. Sensor node is made of
five main components namely, sensing unit, processing unit, memory, transceiver and power
management unit.
Figure 1.1 Architecture of a Sensor Node
The sensing unit captures the required data, passes it to the processing unit which aggregates
together different data and stores it in packets. After timely duration it is transmitted over to
the sink from where the user can access the data of various WSN.

3
A sensor node has many limitations. A sensor node has limited power since it has a small
battery as power source. If it dies out, it has to be replaced with new sensor nodes. It has
limited computation capability due to which it cannot be loaded with huge computation
problems. Although the sensor nodes individually have limited capabilities, their
collaboration to perform a specific task produces an enhanced view of the physical world. It
is widely used because of its robust nature, easy deployment in remote places and retrieval of
variety of information which is helpful in applications.
Most applications fall into one of four classes: environmental data collection, security
monitoring, node tracking, and hybrid networks. The different applications are target field
imaging, intrusion detection, weather monitoring, security and tactical surveillance;
distributed computing; the detection of ambient conditions such as temperature, movement,
sound, and light or the presence of specific objects, inventory control, and disaster
management.
1.2 APPLICATION
The applications for WSNs are many and varied. They are used in commercial and industrial
applications to monitor data that would be difficult or expensive to monitor using wired
sensors. They could be deployed in wilderness areas, where they would remain for many
years (monitoring some environmental variable) without the need to recharge / replace their
power supplies.
Typical applications of WSNs include monitoring, tracking, and controlling. Some of the
specific applications are habitat monitoring, object tracking, nuclear reactor controlling, fire
detection, traffic monitoring, etc. In a typical application, a WSN is scattered in a region
where it is meant to collect data through its sensor nodes.
• Environmental monitoring
• Habitat monitoring
• Acoustic detection
• Seismic Detection
• Military surveillance
• Medical monitoring
• Smart spaces
• Inventory tracking

4
1.3 CHALLENGES
In WSN, the limited capabilities (battery power, transmission range, processing hardware and
memory used, etc.) of the sensor nodes combined with the special location-based conditions
met (not easily accessed in order recharge the batteries or replace the entire sensors) make the
energy efficiency and the scalability factors even more crucial. Moreover, the challenge of
prolonging network lifetime under the above restrictions is difficult to be met by using only
traditional techniques.
• Dynamic Network Topology: The variability of network topologies due to node
failures, introduction of additional nodes, variations in sensor location and changes to
cluster allocations in response to network demands requires the adaptability of
underlying network structures and operations.
• Resource Limitations: Battery power, memory, processing power and lifetime are
physical constraints that impact every aspect of WSNs.
• Failure Prone: Individual sensors are unreliable in harsh and unpredictable
environments.
• Network congestion resulting from dense network deployment: The quantity of
data gathered may exceed the requirements of the network and so evaluation of the
data and transmission of only relevant and adequate information needs to be
performed.
The WSNs with high performance will come into practice if the following requirements are
satisfied
• Low power usage
• Efficient memory usage
• Self-organization
• Collaborative processing
• Querying ability
• Scalability
• Reliability
• Fault tolerance
1.4 REPORT STRUCTURE
In the first chapter, a brief description about WSN is provided. In the initial phase of the
chapter, detail description of WSN is given which tells about what it is, its limitations and

5
advantages. Then the report continues about the applications of WSN in various field and
then proceeds to describing the challenges faced in deploying it.
The second chapter talks about routing and clustering protocols in detail and along with that
discusses about the addressing schemes. The third chapter talks about the problem statement
and various aspects related to it.
Fourth, fifth and sixth chapters tells about the different life cycles through which the project
passes like the planning, analysis and designing. An assortment of UML diagrams help in
understanding the project better.
Seventh chapter briefs more about NS-2 commands and codes utilized to implement the
project and how it leads to various outputs.
Eight chapter describes different scenarios so analysis can be made from the results with are
obtained from the simulation. It has different graphs which help understanding the results
through graphical visualization of results.
Inference obtained and how the project can be expanded is described in the latter chapters.

6
CHAPTER 2
BACKGROUND AND
LITERATURE
SURVEY

7
CHAPTER 2
BACKGROUND AND LITERATURE SURVEY
2.1 CLUSTERING
Clustering is the process of dividing a WSN into groups or sub parts. The main purpose of
dividing a WSN into clusters is to increase its scalability, robustness, high- efficiency and
moreover to increase its power consumption. A cluster also increases the efficiency by
managing the communication bandwidth by reusing it. There are various objectives of cluster
systems that distinguish them from others, such as load balancing, fault tolerance, increase in
connectivity, and maximize longevity. Thus, clustering is a good technique for longer
network life and efficient management of resources.
There are 2 types of communications that take place in a typical clustered system:-
• Inter cluster communication: Communication between 2 different clusters.
• Intra cluster communication: Communication in a single cluster.
Various clustering algorithms are used for implementing clustering in a WSN, namely:-
2.1.1 Variable convergence time algorithm
• Link Cluster Algorithm
• Adaptive Clustering Algorithm
• Random Competition Based Clustering.
2.1.2 Constant convergence time algorithm
• Energy Efficient Hierarchical Clustering
• Low Energy Adaptive Clustering Hierarchy
• Fast Local Clustering Service
• Hybrid Energy Efficient Distributed Clustering
• Distributed Weight based Energy Efficient Hierarchical Clustering
• Attribute Based Clustering.

8
2.2 ENERGY EFFICIENT ROUTING PROTOCOLS
Protocol designers have started developing energy efficient routing protocols for WSN
because of the energy constraints of the sensor nodes. Protocols are designed by using
shortest paths between nodes, clustered environment with hierarchical routing between nodes
that are helpful in conserving energy in WSN. Single hop communication between nodes,
network congestion due to the large number of sensor nodes under one cluster are some of the
bottleneck’s for the energy efficiency in the WSN. There are some existing routing protocols
that can be compared for analysis.
1. Low Energy Adaptive Clustering Hierarchy (LEACH)
LEACH is the first hierarchical protocol in WSN. It has some distinctive characteristics
like self-reconfiguration, adjustment of communication range according to distance,
schedule of data transmission of individual nodes etc. It has some assumptions like
fixed-base station location, energy constrained homogeneous nodes and predetermined
ratio of cluster heads among all nodes. The operation of LEACH is separated into a
series of equal length time spans. In each of these time spans, cluster head selection,
cluster formation and scheduling procedures are completed, respectively, at the very
beginning. Cluster heads are selected based on a probabilistic value satisfying the
condition that those nodes have not played that role previously. Upon receiving
broadcasted advertisement messages from a single or multiple cluster heads, a node
sends joining declaration to the nearest cluster head. Cluster heads then create a TDMA
schedule and notify its member nodes. The following data transmission phase has the
larger chunk of each span, which is also divided into a number of equal frames. In each
frame, there is a slot for every member node.
Figure 2.1: Distributed cluster formation in LEACH

9
Member nodes send data to cluster heads at their slot time. The cluster head aggregates the
data and send to the base station. Despite of significant advantages, LEACH also has to deal
with some drawbacks such as:
• Cluster head is selected based on probabilistic value. So there is a possibility that cluster
heads will be repeatedly selected from one part of the network.
• Cluster head role is not uniformly distributed. Thus, some of the nodes might be out of
service quickly.
The framework of LEACH has been utilized in development of other protocols.
2. Power-Efficient Gathering in Sensor Information System (PEGASIS)
It uses the first order radio model. It is an extended version of LEACH protocol. In
PEGASIS, sensor nodes transmit data to their nearest neighbors, which eventually
transmit the data captured by the sensor nodes to the base station. In PEGASIS, the equal
distribution of the network energy resources among all the sensor nodes was the energy
efficient strategy employed for the selection of cluster head. Like LEACH, the cluster
configuration is centrally managed by base station and the WSN is logically divided into
clusters headed by CHs.
In PEGASIS, a multi-hop communication is used for data transmission to the BS. This
implies that data is not being directly transmitted to the BS but conveyed via neighboring
CHs to the BS. The CH closest to the BS is tasked with the responsibility of the
aggregated data transmission to the BS. The network lifetime is increased by the dynamic
clustering utilized by PEGASIS. Furthermore, the network lifetime is further enhanced
and the energy dissipation is reduced by performing local data aggregation. However, if
PEGASIS is utilized in large-scale networks it faces scalability problems. This is due to
the extra overhead as a result of the dynamic clustering network function. In addition, the
scarce energy resources of the sensor nodes may be further drained by the periodic
broadcast of updates and exchange of network queries. The merit of PEGASIS over
LEACH is it being more robust to node failures than LEACH.
2.3 ROUTING PROTOCOLS IN WIRELESS SENSOR NETWORKS
Focus is put on how AODV protocol work and its suitability for different network and
mobility conditions, as this is important for its deployment in a WSN.

Ad hoc On-demand Distance Vector (AODV)
AODV is a stateless on-demand routing protocol. It is classified under reactive protocols. The
operation of the protocol is divided in two functions, route discovery and route maintenance.
In Ad-hoc routing, when a route is needed to some destination, the protocol s
discovery. Then the source node sends route request message to its neighbors. And if those
nodes do not have any information about the destination node, they will send the message to
all its neighbors and so on. And if any neighbor node has the
destination node, the node sends route reply message to the route request message initiator.
On the basis of this process a path is recorded in the intermediate nodes. This path identifies
the route and is called the reverse path. Si
of its neighbors, more than one copy of the original route request message can arrive at a
node. A unique id is assigned, when a route request message is created. When a node
received, it will check this id and the address of the initiator and discarded the message if it
had already processed that request. Node that has information about the path to the
destination sends route reply message to the neighbor from which it has received route
request message. This neighbor does the same. Due to the reverse path it can be possible.
Then the route reply message travels back using reverse path. When a route reply message
reaches the initiator the route is ready and the initiator can start sending data packets.
The advantage of AODV is that it utilizes destination sequence numbers to ensure loop
freedom at all times and to avoid the count
distance-vector protocols. It offers low overhead, quick adaptation to dynamic lin
and low processing and memory overhead.
10
demand Distance Vector (AODV)
demand routing protocol. It is classified under reactive protocols. The
hoc routing, when a route is needed to some destination, the protocol s
all its neighbors and so on. And if any neighbor node has the information about the
the route and is called the reverse path. Since each node forwards route request message to all
id and the address of the initiator and discarded the message if it
already processed that request. Node that has information about the path to the
This neighbor does the same. Due to the reverse path it can be possible.
e advantage of AODV is that it utilizes destination sequence numbers to ensure loop
freedom at all times and to avoid the count-to-infinity problem associated with classical
vector protocols. It offers low overhead, quick adaptation to dynamic lin
and low processing and memory overhead.
Figure 2.2: AODV Routing Path
demand routing protocol. It is classified under reactive protocols. The
hoc routing, when a route is needed to some destination, the protocol starts route
information about the
nce each node forwards route request message to all
id and the address of the initiator and discarded the message if it
already processed that request. Node that has information about the path to the
This neighbor does the same. Due to the reverse path it can be possible.
e advantage of AODV is that it utilizes destination sequence numbers to ensure loop-
infinity problem associated with classical
vector protocols. It offers low overhead, quick adaptation to dynamic link conditions

11
2.4 ADDRESSING SCHEMES
In routing technologies, the addressing structure and the naming system of networks the
fundamental components used to denote and find end users or messages in networking.
Addresses can be either bound with hardware during the manufacturing process (MAC) or
assigned on demand by addressing protocols(IP).The on-demand addressing protocols can be
further sorted into centralized and distributed. The first one employs a central addressing
coordinator and the latter one does not respectively.
Addressing deals with assignment of ID to sensor nodes in the network so that sensors can
build a functional communication paradigm. Due to special data reporting behaviour of
sensor nodes in the network and other physical constraints, address assignment problem for
sensor network is significantly different from that of for tradition network. There are
currently two types of distributed addressing schemes, flat and hierarchical.
• Flat Addressing: The majority of MANET routing protocols employ a flat addressing
mechanism. In a flat network, addresses are randomly assigned to nodes; therefore, the
distribution of addresses is unrelated to the network topology. Although the addressing
process is easy, a flat address structure always makes it hard to build a path between two
arbitrary nodes.
• Hierarchical addressing: In a hierarchical addressing scheme can make the path
discovery process easier due to its systematic structure. The distribution of hierarchical
addresses also does not need a central coordinator; however, it causes the waste of
address resources if the network grows irregularly. In case of large topologies, reduce
memory requirements by downsizing the routing table size. The table size is reduced from
n2, for flat routing, to about log n for hierarchical routing. However some overhead costs
results as number of hierarchy levels are increased. In addition, networks do not reserve
addresses for the nodes roaming out of range. This feature makes hierarchical addressing
more adaptable for static networks rather than for mobile networks.

12
2.5 LITERATURE SURVEY
The WSN as a research domain is gaining importance today because of its low cost, mobile
nature, small size and its applications in remote area. The literature review is focused over the
papers published during the year 2006-2011 in IEEE journal, proceedings and international
conferences. The papers are focusing mainly on WSN architecture, clustering and energy
efficient protocols. These papers primarily study the above mentioned aspects of WSN and
lay down proposed guideline for a better performing WSN. Some of these are elaborated
below.
Few Indian authors point out that Energy efficient grid based topology and Cluster Head
election based on energy increase the overall life of the network drastically [7]. Mr. Enamul
Haque in his thesis compares LEACH, CACH and CAMHP in all aspects. Comparison shows
reduced data traffic in CACH compared with LEACH, which ensures more idle time and
longevity of the network. Performance evaluation of CAMHP shows significant energy
efficiency compared to LEACH and Multi-Hop model. As a whole, techniques applied in
CAMHP performs efficiently in energy saving and the network provides a longer full-scale
active service. [9].
Mr Muattaz Elaneizi in his thesis conclude that transmission tuning algorithm for cluster-
based WSNs balance the load among cluster heads that fall in different regions. This
algorithm is applied prior to a cluster algorithm to improve the performance of the clustering
algorithm without affecting the performance of individual sensor nodes. As a result, the
network lifetime has been prolonged. But they also point out that this algorithm is suited only
for static WSN [8]. Another Author shows us the energy consumption for some algorithms in
WSN. He proposes a dynamic routing protocol based on probability to reduce the energy
consumption of the nodes. Here, the information is routed through the node with the highest
energy. But mobility of nodes hampers the routing protocol [11].

13
CHAPTER 3
PROBLEM
STATEMENT

14
CHAPTER 3
PROBLEM STATEMENT
The system is designed such that different scenarios of routing within a WSN can be analyzed
in such a way that their energy efficiency can be increased. The different effects of changes in
parameters of the scenario where nodes are moving within and in between clusters are
observed to increase their life.
3.1 BASIC CLUSTER COMMUNICATION
The cluster formation process eventually leads to a two-level hierarchy where the Cluster
head (CH) nodes form the higher level and the cluster-member nodes form the lower level.
The sensor nodes periodically transmit their data to the corresponding CH nodes. The CH
nodes aggregate the data (thus decreasing the total number of relayed packets) and transmit
them to the BS (BS) either directly or through the intermediate communication with other CH
nodes. However, because the CH nodes send all the time data to higher distances than the
common (member) nodes, they naturally spend energy at higher rates. A common solution in
order balance the energy consumption among all the network nodes is to periodically re-elect
new CHs (thus rotating the CH role among all the nodes over time) in each cluster.
Figure 3.1 Cluster Communication Architecture

15
The BS is the data processing point for the data received from the sensor nodes, and where
the data is accessed by the end user. It is generally considered fixed and at a far distance from
the sensor nodes. The CH nodes actually act as gateways between the sensor nodes and the
BS. The function of each CH, as already mentioned, is to perform common functions for all
the nodes in the cluster, like aggregating the data before sending it to the BS. In some way,
the CH is the sink for the cluster nodes, and the BS is the sink for the CHs. Moreover, this
structure formed between the sensor nodes, the sink (CH), and the BS can be replicated as
many times as it is needed, creating (if desired) multiple layers of the hierarchical WSN
(multi-level cluster hierarchy).
3.2 RE-ELECTION ALGORITHM
The communication of between members of a cluster takes place in the fashion where all the
nodes communicate with CH and CH aggregates the data and forwards it to the sink. Due to
this energy of CH is utilised more than the other nodes. This increases the probability of it
dying out due to complete utilization of energy sooner as compared to other nodes. Therefore,
to increase the life of the nodes of the cluster, the job of CH should be rotated between the
members of the cluster. This can be done on the basis of different parameters. For example, if
it is based on the distance then the node which is closest to the sink is elected as CH so that
minimum energy is required for transmission. If it is based on the energy, then a node with
maximum energy is elected as the CH. This makes sure that when the energy of the node
drops down below a particular level, the load of the node is reduced by making other node
with higher energy as the CH.

16
Figure 3.2 Cluster Head re-election

17
3.3 MOVEMENT OF NODES
Sensor nodes are required to capture certain data of the surrounding. For this purpose, the
sensor might also be tagged to objects which are in motion. For example, a sensor node may
be attached to an animal in a sanctuary to indentify its location. Doing so, the energy of the
node isn't utilized so there is no effect on energy level of the node. But due to the movement
of nodes, the movement may also be inter-cluster and not just intra-cluster. So the nodes must
identify the new CH and send the data packets to the new CH instead of the old CH. While
re-election of the CH the transferred nodes should also be considered as a part of the cluster
and the nodes which have left should not be taken into consideration.

18
CHAPTER 4
PROJECT PLANNING

19
CHAPTER 4
PROJECT PLANNING
4.1 PROJECT DEVELOPMENT LIFECYCLE
Figure 4.1 Iterative Lifecycle
Iterative and Incremental development is at the heart of a cyclic software development
process developed in response to the weaknesses of the waterfall model. It starts with an
initial planning and ends with deployment with the cyclic interactions in between. The basic
idea behind the agile method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental), allowing software developers to take advantage of
what was learned during development of earlier parts or versions of the system. Learning
comes from both the development and use of the system, where possible key steps in the
process start with a simple implementation of a subset of the software requirements and
iteratively enhance the evolving versions until the full system is implemented. Design
modifications and addition of new functional capabilities are done on each iteration.
4.2 SOFTWARE REQUIREMENT SPECIFICATIONS
H/W Requirements:
1. 1024 MB RAM
2. Processor: Intel family.

20
S/W Requirements:
1. Network Simulator (NS) 2.34-all-in-one.
Operating System:
1. LINUX Ubuntu 10.04.
4.3 PROJECT SCHEDULE AND GANTT CHART
# Task Starting Finish No. of days
1 Project selection 15/07/2011 25/07/2011 11
2
Discuss about various
projects
15/07/2011 18/07/2011 4
3 Project topic searching 19/07/2011 21/07/2011 3
4
“Dynamic routing of
Packets in WSN” as a
project.
22/07/2011 22/07/2011 1
5 Synopsis creation 23/07/2011 25/07/2011 3
6 1st
Review 26/07/2011 26/07/2011 1
7 Approval of project 26/07/2011 27/07/2011 2
8 Information gathering 28/07/2011 10/09/2011 45
9
Collecting required
documents
28/07/2011 06/08/2011 10
10
Study of IEEE papers and
references
07/08/2011 28/08/2011 22
11 Estimate resources required 29/08/2011 10/09/2011 13
12
Documentation and
designing
11/09/2011 3/10/2011 23
13
UML ,DFD , Activity
Diagrams
11/09/2011 3/10/2011 23
14 2nd
Review 04/10/2011 04/10/2011 1
15 SRS generation 05/10/2011 06/10/2011 2
16 Partial Report generation 06/10/2011 09/10/2011 4

21
17
Installation of Ubuntu 10.04
and NS 2.34
10/10/2011 21/10/2011 12
18
Study of Linux commands
and NS2 basics
21/12/2011 27/12/2011 7
19
Learning TCL and OTCL in
detail
28/12/2011 05/01/2012 9
20
Execution of sample TCL
scripts in NS2
06/01/2012 10/01/2012 5
21
Study of available cluster
formation algorithms
11/01/2012 14/01/2012 4
22
Implementation of grid
based clustering algorithm
15/01/2012 19/01/2012 5
23
Study of various election
algorithms to elect CH
20/01/2012 24/01/2012 5
24
Implementation of energy
efficient election algorithm
25/01/2012 31/01/2012 7
26
Study of Inter and Intra
cluster communication
06/02/2012 08/02/2012 3
27 3rd
Review 09/02/2012 12/02/2012 4
30
Study of AWK scripting and
Xgraph tool for generating
graphs
27/02/2012 08/03/2012 10
31
Generation and comparison
of various graphs
09/03/2012 17/03/2012 9
32
Drawing Conclusion from
generated graphs
18/03/2012 23/03/2012 6
33
4th
Review and Project
exhibition
18/04/2012 19/04/2012 7
Table 4.1 Project Schedule

22
Figure 4.2 Gantt chart

23
CHAPTER 5
PROJECT ANALYSIS

24
CHAPTER 5
PROJECT ANALYSIS
5.1 USECASE DIAGRAMS
5.1.1 Wireless Sensor Networks
Figure 5.1 Use Case of WSN
1. Network Analyst: Network Analyst runs cluster formation and CH re-election
algorithm based on energy and distance. In distance based algorithm, the node closest
to the BS is made the CH. In the second case, the node having maximum energy is
made the CH. It also monitors the network and generates energy based performance
graphs. The generated performance graphs are useful in analyzing the energy
requirements of a sensor node in various scenarios.
uc wsn
WSN
Sensor Node
Sense data
Data cheking and
Validation
Generate
Performance graph
Transfer to Custer
Head
Network Analysis Monitor Network
Aggregate Data
Transfer data to BS
Base Station
Collect data]
Communicate to wired
connection
Acting as CH
Cluster formation and
re-election
«include»
«include»

25
2. Sensor Node: The sensor node senses data and forwards the data to the CH. If a
sensor node is elected as a CH it will aggregate the data from all other sensor nodes in
the cluster and will transmit it to the BS.
3. BS: BS will collect the data from all the CHs and forward it to a wired station. It also
performs necessary tasks in cluster formation and CH re-election on request of
Network Architect.
5.1.2 CH Re-election
Figure 5.2 Use Case of CH Re-election
uc cluster
Cluster
Sensor Node
Sense data
Report energy level
to BS
Report Position to BS
Network Arthitect
Request energy and
position
CH election Distance
based
Assign CH
CH re-election Energy
based
Base StationAssign CH
Fwd node info to NA
Act as CH
CH notification to
nodes
Receive CH
assignment
Request position &
energy from nodes
«include»
«include»

26
The above Use case diagram describes the process of Cluster Formation and CH re-election.
The Functionality of each actor is as follows:-
1. Network Architect: The network architect requests for energy and position data to
the BS, on receiving the positional parameters, the node with the lowest distance from
the BS is taken into consideration and CH privileges are assigned to it.
2. BS: According to the Network Architects request, the BS will request a node to
forward its Positional and energy data. On receiving the energy and position
information the BS will forward it to the Network Architect. A notification in
correspondence to the CH assignment will be received by the BS from the NA and the
BS will assign a node as a CH.
3. Sensor Node: Sensor node on receiving the request from the BS, the sensor node will
report its energy levels and position to the BS. The BS assigns a sensor node as a CH,
and then the sensor node will notify other nodes of its assignment.

27
5.2 SEQUENCE DIAGRAM
Figure 5.3 Sequence Diagram of CH Re-election
1. The Network Architect requests for node position and energy levels from the BS.
2. The BS requests position and energy levels from the sensor nodes.
3. The sensor nodes returns its position and energy to the BS and the BS returns it to the
network architect
4. The network architect runs distance based and energy based CH re-election algorithm.
5. It assigns a CH amongst the sensor nodes in a cluster based on the Distance based or
energy based CH re-election algorithm and notifies it to the BS.
6. The BS notifies the sensor node about the CH assignment.
7. The CH notifies other nodes in a cluster about the CH assignment.
sd Use Case Model
Network Admin ClusterHeadBase Station End Node Energy Database
Get_node_posn
Req_posn
Return_pos
Return_pos
Get_energy_
info
Get_energy
Get_Energy(node_id)
Return
Return
Reurn
Distance_based_CH_reelection
Assign_CH
CH_Notification
CH_Notification
Energy_based_CH_reelection
Assign_CH
CH_Notification
CH_Notification

28
CHAPTER 6
PROJECT DESIGN

29
CHAPTER 6
PROJECT DESIGN
6.1 CLASS DIAGRAM
Figure 6.1 Class Diagram
custom Requirements Model
Cluster_Head
- Cluster_no: int
- Node_Coordinate: int
- Node_Energy: int
- Node_Id: int
+ Agg_Data() : void
+ Collect_Data() : void
+ Fwd_Data() : void
+ Get_Energy() : void
+ Get_Movcord() : void
Sensor_Node
- Node_Coordinate: int
- Node_Energy: int
- Node_Id: int
+ Get_cid() : void
+ Get_energy() : void
+ Get_movcord() : void
+ Send_data() : void
Network_Arch
- Arch_Id: int
- Arch_name: char
+ Design_nw();() : void
+ Ini_relection() : void
+ Manage_nw()() : void
Base_Station
- BS_Corod: int
- BS_ID: int
- Node_Coord: int
+ Collect_data() : void
+ Conn_Wired() : void
+ Trans_Data() : void
1 *
1
*
1.. 1

30
6.2 ACTIVITY DIAGRAM
Figure 6.2 Activity Diagram
act Use Case Model
Sense Data
Aggerate Data
Route Data To Base
Station
Route Data To Cluster
Head
If CH
Start
[NO]
[YES]

31
CHAPTER 7
IMPLEMENTATION

IMPLEMENTATION
7.1 NETWORK SIMULATOR
7.1.1 Network Simulator version 2 (NS2)
The network simulator (NS), which is an object
simulator for networks, is a simulated program written in C++ and OTcl. It was developed by
VINT (Virtual InterNetwork Testbed) project group (A Collaboration among USC/
PARC, LBNL, and UCB).NS2 is very useful for developing and investigating variety of
protocols. This mainly includes protocols regarding TCP and UDP
behavior such as FTP, Telnet and CBR, router queue management mechanism
Tail, RED and CBQ, routing algorithms such as AODV, DSR, and more. NS also implements
multicasting, multimedia, static and dynamic wireless networking, MAC layer protocols and
application-level protocols.
To setup and run a simulation, a user writes an OTcl script, which is a simulation program to
initiate an event scheduler, set up the network topology using the network objects and
plumbing functions in the library, and to tell traffic sources when to sta
32
CHAPTER 7
IMPLEMENTATION
.1 NETWORK SIMULATOR
.1.1 Network Simulator version 2 (NS2)
The network simulator (NS), which is an object-oriented, discrete event
VINT (Virtual InterNetwork Testbed) project group (A Collaboration among USC/
protocols. This mainly includes protocols regarding TCP and UDP behavior
such as FTP, Telnet and CBR, router queue management mechanism
Figure 7.1 Basic Structures of NS
plumbing functions in the library, and to tell traffic sources when to sta
oriented, discrete event-driven network
VINT (Virtual InterNetwork Testbed) project group (A Collaboration among USC/ISI, Xerox
behavior, traffic source
such as FTP, Telnet and CBR, router queue management mechanism such as Drop
plumbing functions in the library, and to tell traffic sources when to start and stop

33
transmitting packets through the event scheduler. When NS-2 which works as OTcl
interpreter receives the OTcl script, it will set environment parameters following the received
script. If a user wants to make a new network object, it will be easy to make a compound
object from the object library, and plumb the data path through the object rather than write a
new one. When the simulation is finished, the simulation results are produced in one or more
text-based output files known as “trace files” that contain detailed simulation data, which can
be used to analyze results of simulation into a trace graph directly or can be used in the
graphical user interface. NS is extended by supportive utilities like Network Animator
(NAM) and Xgraph:
7.1.2 Network Animator (NAM)
Nam is a Tcl/TK based animation tool or a graphical interpreter for visualizing network
simulation traces and real world packet traces. It supports topology layout, packet level
animation, and various data inspection tools.
7.1.3 Xgraph
Xgraph is a plotting program which can be used to create graphic representations of
simulation results. It draws a graph on an X display given data read from either data files (in
our case Trace Files) or from standard input if no files are specified.
7.2 A SAMPLE TCL SCRIPT
wireless.tcl
#======================================================================
# Define options
#======================================================================
1. set val(chan) Channel/WirelessChannel ; # channel type
2. set val(prop) Propagation/TwoRayGround ; # radio-propagation model
3. set val(ant) Antenna/OmniAntenna ; # Antenna type
4. set val(ll) LL ; # Link layer type
5. set val(ifq) Queue/DropTail/PriQueue ; # Interface queue type
6. set val(ifqlen) 50 ; # max packet in ifq
7. set val(netif) Phy/WirelessPhy ; # network interface type
8. set val(mac) Mac/802_11 ; # MAC type
9. set val(rp) AODV ; # ad-hoc routing protocol
10. set val(nn) 2 ; # number of mobilenodes
11. set val(energymodel) EnergyModel; # Energy Model

34
12. set val(initialenergy) 100 ; # value
# Create simulator object
13. set ns [new Simulator]
# Setup the Trace File
14. set tf [open out.tr w]
15. $ns trace-all $tf
# Open the NAM trace file
16. set nf [open out.nam w]
17. $ns namtrace-all $nf
#Define a finish procedure
18. proc finish {} {
19. global ns nf tf
20. $ns flush-trace
21. close $nf
22. exec nam out.nam &
23. exec –f file1.awk out.tr > final.tr
24. close $tf
25. exec xgraph -t "Final Graph" -geometry 1600x850 final.tr &
26. exit 0
27. }
#Create Topology
28. set topo [new Topography]
29. $topo load_flatgrid 500 500
#Create Object God
30. create-god $val(nn)
# Configure nodes
31. $ns node-config -adhocRouting $val(rp)
32. -llType $val(ll)
33. -macType $val(mac)
34. -ifqType $val(ifq)
35. -ifqLen $val(ifqlen)
36. -antType $val(ant)
37. -propType $val(prop)
38. -phyType $val(netif)
39. -topoInstance $topo
40. -channelType $val(chan)
-energyModel $opt(energymodel)
-initialEnergy $opt(initialenergy)
-rxPower 2.0
-txPower 0.2
-wiredRouting OFF
41. -agentTrace ON

35
42. -routerTrace ON
43. -macTrace OFF
44. -movementTrace ON
#Create 2 nodes
45. set n0 [$ns node ]
46. set n1 [$ns node ]
47. $n0 random-motion 0; # disable random motion
48. $n1 random motion 0
# Create link between the nodes
49. $ns duplex-link $n0 $n1 1Mb 10ms DropTail
# Configure Initial Position
50. $n0 set X_ 5.0
51. $n0 set Y_ 2.0
52. $n0 set Z_ 0.0
53. $n1 set X_ 390.0
54. $n1 set Y_ 385.0
55. $n1 set Z_ 0.0
# Create Movement
56. $ns at 50.0 "$n1 setdest 25.0 20.0 15.0" # Node (1) starts to move towards node (0)
57. $ns at 10.0 "$n0 setdest 20.0 18.0 1.0"
58. $ns at 100.0 "$n1 setdest 490.0 480.0 15.0" # Node (1) starts to move away from node (0)
# Setup traffic flow
59. set tcp [new Agent/TCP]
60. $ns attach-agent $n0 $tcp
61. set sink [new Agent/TCPSink]
62. $ns attach-agent $n1 $sink
63. $ns connect $tcp $sink
67. set ftp [new Application/FTP]
68. $ftp attach-agent $tcp
69. $ns at 10.0 "$ftp start"
# Set Simulation Stop Time
70. $ns at 150.0 "$n0 reset";
71. $ns at 150.0 "$n1 reset";
72. $ns at 150.0001 "stop"
73. $ns at 150.0002 "puts "NS EXITING...”;
74. $ns at 160.0 "finish"
#Run the simulation
75. puts "Starting Simulation..."
76. $ns run

36
The following is the explanation of the script above.
7.2.1 GENERAL NS COMMANDS
• set ns [new Simulator] generates a new NS simulator object instance, and assigns it to a
variable ns. This line creates an event scheduler for the simulation, initializes the packet
format and selects the default address format.
• $ns namtrace-all nf tells the simulator to record simulation traces in NAM input format.
nf is the file name that the trace will be written to later by the command $ns flush-trace.
• $ns trace-all $tf tells the simulator to tarce the activities at the agent, router and MAC
level. This command by default starts tracing the Queue. tf is the file name that the trace
will be written to later by the command $ns flush-trace.
• proc finish {} closes the trace file filters the trace file with the help of an awk script into
another trace file containing values for X and Y-axis which are used to show the
simulation results on the X-Graph . It also starts the NAM.
• create-god $val(nn) stores information like the number of nodes and creates a matrix to
store the connectivity information of the topology and is known as the General
Operation Director
• set n0 [$ns node] creates a node. A node in NS is compound object made of address
(attached to routing module) and port classifiers (attached to transport agent).
• $ns duplex-link $n0 $n1 1Mb 10ms DropTail creates two simplex links of specified
bandwidth, delay, and queue type and connects the two specified nodes. When a node
wants to send a packet through a link, it puts the packet on the queue object of the link.
Packets de-queued from the queue object are passed to the delay object. The delay object
simulates link delay. Sending a packet to a null agent from the queue object simulates the
dropping of the packet. The TTL object calculates the time to live of each packet received
and updates the TTL field of the packet.
• set tcp [new Agent/TCP] and set sink [new Agent/TCPSink] creates a TCP and
TCPSink agents, respectively. Default traffic flow is from TCP to TCPSink. Users can
create any agent or traffic sources in this way.
• $ns attach-agent $n0 $tcp and $ns attach-agent $n1 $sink attaches an agent object
created to a node object.
• $ns connect $tcp $sink connects the two agents specified. After two agents that will
communicate with each other are created, the next thing is to establish a logical network

37
connection between them. This line establishes a network connection by setting the
destination address to each others' network and port address pair.
• set ftp [new Application/FTP] creates an instance of FTP Application for bulk data
transfer.
• $ftp attach-agent $tcp attaches an FTP object to the TCP agent.
• $ns at 10.0 "$ftp start" tells the FTP agent when to start sending data.
Figure 7.2 Application Layer of Node.
• $ns at 160.0 “finish” tells the simulator object to execute the 'finish' procedure after
160.0 seconds of simulation time
• $ns run start the simulation.
7.2.2 MOBILE NODE COMMANDS
Mobile Node is a split object. In addition to the basic node model, it consists of a network
stack. The network stack for a mobile node consists of a link layer (LL), an ARP module
connected to LL, an interface priority queue (IFq), a Mac layer (MAC), a network interface
(netIF), all connected to a common wireless channel. These network components are created
and plumbed together in OTcl. A packet sent down the stack flows through the link layer
(and ARP), the Interface queue, the MAC layer, and the physical layer. At the receiving node,
the packet then makes its way up the stack through the Mac, and the LL.

38
Figure 7.3 Basic Structure of a Mobile Node.
Each component is briefly described here below.

39
• Link Layer: The link layer for mobile node has an ARP module connected to it
which resolves all IP to hardware (Mac) address conversions. Normally for all
outgoing (into the channel) packets, the packets are handed down to the LL by the
Routing Agent. The LL hands down packets to the interface queue. For all incoming
packets (out of the channel), the Mac layer hands up packets to the LL which is then
handed off at the node_entry_ point.
• ARP: The Address Resolution Protocol (implemented in BSD style) module receives
queries from Link layer. If ARP has the hardware address for destination, it writes it
into the Mac header of the packet. Otherwise it broadcasts an ARP query, and caches
the packet temporarily. For each unknown destination hardware address, there is a
buffer for a single packet. Incase additional packets to the same destination is sent to
ARP, the earlier buffered packet is dropped. Once the hardware address of a packet's
next hop is known, the packet is inserted into the interface queue.
• Interface Queue: The Interface queue is implemented as a priority queue, which
gives priority to routing protocol packets, inserting them at the head of the queue. It
supports running a filter over all packets in the queue and removes those with a
specified destination address.
• Mac Layer: Depending on the type of physical layer, the MAC layer must contain a
certain set of functionalities such as: carrier sense, collision detection, collision
avoidance, etc. Since these functionalities affect both the sending and receiving sides,
they are implemented in a single Mac object. For sending, the Mac object must follow
a certain medium access protocol before transmitting the packet on the channel. For
receiving, the MAC layer is responsible for delivering the packet to the link layer.
• Network Interfaces (Physical layer): The Network Interface layer serves as a
hardware interface which is used by mobile node to access the channel. This
interface subject to collisions and the radio propagation model receives packets
transmitted by other node interfaces to the channel. The interface stamps each
transmitted packet with the meta-data related to the transmitting interface like the
transmission power, wavelength etc. This meta-data in packet header is used by the
propagation model in receiving network interface to determine if the packet has
minimum power to be received and/or captured and/or detected (carrier sense) by the
receiving node. The Network interface in NS approximates the DSSS radio interface
(Lucent WaveLan direct-sequence spread-spectrum).

40
• Radio Propagation Model: These models are used to predict the received signal
power of each packet. At the physical layer of each wireless node, there is a receiving
threshold. When a packet is received, if its signal power is below the receiving
threshold, it is marked as error and dropped by the MAC layer. NS supports the free
space model (at near distances), two-ray ground reflection model (at far distances)
and the shadowing model (includes fading)
• Antenna: An omni-directional antenna having unity gain is used by mobile nodes.
The following API configures for a mobile node with all the given values of adhoc-routing
protocol, network stack, channel, topography, propagation model, with wired routing turned
on or off (required for wired-cum-wireless scenarios) and tracing turned on or off at different
levels (router, Mac, agent).
$ns node-config -adhocRouting $val(rp) # dsdv/dsr/aodv/tora
-llType $val(ll) #specifies link layer object
-macType $val(mac) # specifies mac object
-ifqType $val(ifq) # specifies ifq object
-ifqLen $val(ifqlen) # specifies length of ifq
-antType $val(ant) # specifies antenna object
-propType $val(prop) # propagation object
-phyType $val(netif) # specifies physical layer object
-topoInstance $val(topo) # specifies topography
-channelType $val(chan) # specifies channel object
-energyModel $val(energymodel # specifies energymodel object
-initialEnergy $val(initialenergy) # specifies initial energy
-wiredRouting OFF # specifies routing type
-agentTrace ON # tracing the agent
-routerTrace ON # tracing the router
-macTrace OFF #trace node’s MAC layer
-movementTrace ON # tracing the movement

41
A mobile node is created using the following procedure:
for { set j 0 } { $j < $opt(nn)} {incr j} {
set node_($j) [ $ns_ node ]
$node_($i) random-motion 0
}
This procedure creates a mobile node (split)object, creates an adhoc-routing routing agent as
specified, creates the network stack consisting of a link layer, interface queue, Mac layer, and
a network interface with an antenna, uses the defined propagation model, interconnects these
components and connects the stack to the channel.
7.2.3 Mobile Node Movement Commands
The Mobile Node is designed to move in a three dimensional topology. However, the third
dimension (Z) is not used. That is the Mobile Node is assumed to move always on a flat
terrain with Z always equal to 0. Thus the Mobile Node has X, Y, Z (=0) co-ordinates that is
continually adjusted as the node moves. We first need to define the topography creating the
mobile nodes. Normally flat topology is created by specifying the length and width of the
topography using the following primitive:
set topo [new Topography]
$topo load_flatgrid 500 500
$n0 set X_ 5.0
$n0 set Y_ 2.0
$n0 set Z_ 0.0
$ns at 50.0 "$n1 setdest 25.0 20.0 15.0" # Node (1) starts to move towards node (0)
$ns at 10.0 "$n0 setdest 20.0 18.0 1.0"
$ns at 100.0 "$n1 setdest 490.0 480.0 15.0" # Node (1) starts to move away from node
(0)

At $time sec, the node would start moving from its initi
destination (x2,y2) at the defined speed.
7.3 SIMULATION LOGIC
The simulation of the wireless sensor network (WSN) is depicted in a clustered environment
and the nodes are addressed hierarchically and are placed in a flat topography. Being a flat
topography the co-ordinates of the nodes are in the form (x, y, 0). Clus
boundaries and if a node lies within these boundaries then it is enlisted in that respective
cluster. Graphically clusters are differentiated by their respective
hierarchical addressing scheme an end node communicates
communicate with the BS which in turn connects the WSN to the Internet.
So initially, all the nodes depending on their position are divided into cluster. The node which
is nearest to the BS is elected as the CH of that cluster.
Election of a CH”. Communication is set up between the end nodes and their respective CH
and also all the CH aggregates the data and after a certain interval, report that data to the BS.
Sensor nodes are dynamic in na
constraint is that whenever a node moves to another cluster it should know its new CH. It is
done depending on the position of that node which is enlisted in that cluster as mentioned
above. This is called as “Clustering of the nodes” and it is done after every specific time
interval. Consider a special case like, CH of a certain cluster itself, moves to another cluster.
42
Figure 7.4 Movement of nodes.
At $time sec, the node would start moving from its initial position of (x1,y1) towards a
destination (x2,y2) at the defined speed.
.3 SIMULATION LOGIC
ordinates of the nodes are in the form (x, y, 0). Clus
cluster. Graphically clusters are differentiated by their respective colors
hierarchical addressing scheme an end node communicates with its CH and all the CHs
communicate with the BS which in turn connects the WSN to the Internet.
is nearest to the BS is elected as the CH of that cluster. This is also known as “Distance based
Sensor nodes are dynamic in nature. They make inter or intra cluster movements. The only
s called as “Clustering of the nodes” and it is done after every specific time
al position of (x1,y1) towards a
ordinates of the nodes are in the form (x, y, 0). Clusters are given
colors. As usual, in a
with its CH and all the CHs
This is also known as “Distance based
ture. They make inter or intra cluster movements. The only
s called as “Clustering of the nodes” and it is done after every specific time

43
In such a situation, the current CH is made an end node and CH is elected from the remaining
nodes of the cluster.
CH being just another sensor node like other end nodes has energy constraints. As it manages
the whole cluster its energy depletion rate is more than that of the end nodes. So, in order to
maintain optimum energy levels of all the nodes in the cluster, CH re-election is initiated
after every certain period of time. This saves the cluster from being unstable, as CH can be
dead and management of the cluster becomes unstable. So, “Energy Based Re-election of
CH” is held in every cluster.
Energy Based Re-election means energies of all the nodes including the current CH in that
respective cluster are compared. The node having the highest energy level at that point of
time is appointed as the new CH. Then all the nodes communicate to the new CH.
There have been drastic drops observed in the energy levels of CH when there is no Energy
Based Re- election. Further, these energy levels drop, to extreme values when the load (in
terms of number of end nodes) is increased under a certain CH. But with Energy Based Re-
election applied, the energy levels of CH are maintained at an optimum level, even though;
the load under the CH was increased. It is also observed that the whole network works with
more efficiency and stability under this re-election scheme.

44
CHAPTER 8
ANALYSIS

45
CHAPTER 8
ANALYSIS
8.1 SCENARIO 1
4 clusters, 5 nodes under one CH
In this scenario, there are four clusters, each electing their respective CH based on distance.
The node in the cluster closest to the BS is elected as the CH. There are approximately five
nodes operating under one CH. The nodes send the data to CH and it forwards the data to the
BS. It is obvious that compared to other nodes, the CH will consume more energy.
Figure 8.1 Snapshot of Scenario1

46
Figure 8.2 Xgraph image of Scenario 1
The Xgraph for Scenario 1 is an Energy Vs Time graph which shows the energy level of
three nodes during the lifetime of the simulation. The blue line shows the energy levels of the
CH. It can be seen that the CH consumes the maximum energy. As the number of nodes
under one CH will increase, the CH will consume greater energy.
8.2 SCENARIO 2
4 clusters, 20 nodes under one CH
In this scenario, there are four clusters but we make cluster number 1 as our point of focus.
The cluster contains 20 nodes operating under one CH. In this scenario, the CH is elected
based on distance. The node closest to the BS becomes the CH. All the 20 nodes operating
under one CH send the data to the CH which forwards the data to the BS. In this case, the
energy of the node which gets elected as the CH reduces faster than the first scenario and that
node will wear off faster

47
Figure 8.4 Xgraph image of Scenario 2
The XGRAPH for Scenario 2 is Energy Vs Time graph for three nodes from cluster number
1. The blue line shows the energy level of the CH. Hence, the energy requirement of the CH
goes up and the node might wear off faster than other nodes in the network. Compared to the
Scenario 1, the CH in Scenario 2 requires much more energy.

48
8.3 SCENARIO 3
4 clusters, 20 node in the cluster, CH re-election based on energy
Figure 8.6 XGraph of Scenario3

49
Scenario 3 implements the CH re-election algorithm. After a specific period of time the CH is
re-elected on basis of energy. The graph shows the energy levels of three nodes which
become CH at some point of time during simulation. Graph shows that these nodes require
lesser energy as compared to node in Scenario 2. This we can infer that re-election algorithm
can prove useful in energy conservation.
Figure 8.7 X-Graph on the Basis of All Three Scenarios
When comparison is made between the CH of first and second scenario, it can be observed
that, as the number of nodes of a cluster increase the energy required by the CH increases
drastically. But when CH re-election algorithm is applied the energy is used more efficiently.
So it can be concluded that using the energy based re-election of CH algorithm the shelf life
of nodes can be increased.

50
CHAPTER 9
CONCLUSION

51
CHAPTER 9
CONCLUSION
WSN has a wide scope of application and it plays a very important role in collection of data
in these applications. But while working in WSN, its limitations must also be taken into
consideration. We have learnt about the various aspects of a sensor node like its internal
structure, features and limitation. But our area of focus is to provide an efficient solution to
the problem of energy limitation in sensor nodes. As observed from the results of the
implemented scenarios, it can be seen that re-election of CH on basis of energy of nodes can
help in increasing the life of the nodes. Thus, we have successfully simulated the
conservation of energy of sensor nodes by applying an energy efficient algorithm for CH re-
election. We have also achieved other objectives like handling the intra and inter cluster
movement of sensor nodes, grid based clustering and distance based election of CH.

52
CHAPTER 10
FUTURE SCOPE

53
CHAPTER 10
FUTURE SCOPE
As wireless sensor networks continue to grow, so does the need for effective security
mechanisms. Because sensor networks may interact with sensitive data and/or operate in
hostile unattended environments, it is imperative that these security concerns be addressed
from the beginning of the system design. However, due to inherent resource and computing
constraints, security in sensor networks poses different challenges than traditional
network/computer security. There is currently enormous research potential in the field of
wireless sensor network security.
Because of the nature of wireless communications, resource limitation on sensor nodes, size
and density of the networks, unknown topology prior to deployment, and high risk of
physical attacks to unattended sensors, it is a challenge to provide security in WSNs. The
ultimate security requirement is to provide confidentiality, integrity, authenticity, and
availability of all messages in the presence of resourceful adversaries. To provide secure
communications for the WSNs, all messages have to be encrypted and authenticated. Security
attacks on information flow can be widespread. Modification of information is possible
because of the nature of the wireless channels and uncontrolled node environments. An
opponent can use natural impairments to modify information and also make the information
unavailable. WSNs have the general security requirements of availability, integrity,
authentication, confidentiality and non-repudiation.

54
APPENDIX A
NS-2

55
APPENDIX A
NS-2
A.1 Introduction to Network Simulator (NS2)
NS2 is an object-oriented, discrete event-driven network simulator developed at UC Berkeley
written in C++ and OTcl. NS2 is very useful for developing and investigating variety of
protocols. These mainly include protocols regarding TCP behavior, router queuing policies,
multicasting, multimedia, wireless networking and application-level protocols.
A.2 Software Architecture
NS software promotes extensions by users. It provides a rich infrastructure for developing
new protocols. Also, instead of using a single programming language that defines a
monolithic simulation, NS uses the split-programming model in which the implementation of
the model is distributed between two languages (Breslau, Estrin, and Fall 2000). The goal is
to provide adequate flexibility without losing performance. In particular, tasks such as low-
level event processing or packet forwarding through simulated router require high
performance and are not modified frequently once put into place. Hence, they can be best
implemented in compiled language like C++. On the other hand, tasks such as the dynamic
configuration of protocol objects and exploring a number of different scenarios undergo
frequent changes as the simulation proceeds. Hence, they can be best implemented in a
flexible and interactive scripting language like OTcl. Thus, C++ implements the core set of
high performance primitives and the OTcl scripting language express the definition,
configuration and control of the simulation.
A.3 C++ - OTcl Linkage
NS supports a compiled class hierarchy in C++ and also similar interpreted class hierarchy in
OTcl. From the user’s perspective, there is a one-to-one correspondence (see Figure 4.1)
between a class in the interpreted hierarchy and a class in the compiled hierarchy. The root of
this class hierarchy is the class TclObject. Users create new simulator objects through the
interpreter. These objects are instantiated within the interpreter and are closely mirrored by a
corresponding object in the compiled hierarch y. The interpreted class hierarchy is
automatically established through methods defined in class TclClass while user instantiated
objects are mirrored through methods defined in class TclObject.

56
Figure A.1 C++ -- OTcl linkage.
The following classes are mainly responsible for maintaining C++ and OTcl linkage.
• Class Tcl: This class encapsulates the actual instance of the OTcl interpreter, and
provides methods to access and communicate with that interpreter. It provides
methods for obtaining a reference to Tcl instance, invoking OTcl procedures through
the interpreter, getting or passing the results to the interpreter, storing and looking up
“TclObjects” etc.
• Class TclObject: It is the base class for most of the other classes in the interpreted
and compiled hierarchies. Every object in the class TclObject is created by the user
from within the interpreter and an equivalent shadow object is created in the compiled
hierarchy. The class TclClass performs this shadowing.
• Class TclClass: This is a pure virtual compiled class. Classes that are derived from
this base class provide two functions: constructing the interpreted class hierarchy to
mirror the compiled class hierarchy- and providing methods to instantiate new
TclObjects.
• Class EmbeddedTcl: The objects in this class are responsible for loading and
evaluating some NS scripts that are required at initialization.
• Class InstVar: This class defines the methods and mechanisms to bind a C++
member variable in the compiled shadow object to a specified OTcl instance variable
in the equivalent interpreted object. This binding allows setting or accessing the
variable from within the interpreter or compiled code at all times.

57
A.4 Major Components
Figure A.2 shows some major network components model in NS along with their place in
the class hierarchy. The root of the hierarchy is the TclObject class that is the super class
of all OTcl library objects. NsObject, the direct descendent of the TclObject, is the super
class of all basic network component objects that handle packets, which may compose
compound network objects such as nodes and links. The basic network components are
further divided into two subclasses, Connector and Classifier, based on the number of the
possible output data paths. The basic network objects that have only one output data path
are under the Connector class, and switching objects that have possible multiple output
data paths are under the Classifier class.
Figure A.2 Major components in NS.
A.5 Other Wireless Sensor Network Simulators
There are several simulators that have been used in sensor network research.
• SensorSim
SensorSim, which has been built on NS-2, is a simulation framework for sensor
networks. It provides sensor channel models, energy consumers; lightweight

58
protocol stacks for wireless micro sensors, scenario generation and hybrid
simulation. The sensor channel models the dynamic interaction between the
sensor nodes and the physical environment. At each node, energy consumers are
said to control the power in multiple modes to efficiently use the power and
prolong the nodes lifetime. But this simulator is no longer developed, therefore,
no more available.
• J-Sim
J-Sim (formerly known as JavaSim), is an object-oriented, component-based,
compositional simulation environment written in Java. The key benefits of J-Sim
are that modules can be easily added and deleted in a plug-and-play manner, and it
is also useful both for network simulation and emulation by incorporating one or
more real sensor devices. J-Sim provides supporting target, sensor and sink
nodes, sensor channels and wireless communication channels, physical media,
power models and energy models.
• GloMoSim
GloMoSim (Global Mobile Information system Simulate), which is a scalable
simulation environment written both in C and Parsec, is capable of parallel
discrete-event simulation. GloMoSim is a collection of library modules each of
which simulates a specific wireless communication protocol in the protocol stack.
GloMoSim is widely used to simulate Ad-hoc and Mobile wireless networks.
• SENS
SENS (Sensor, Environment, and Network Simulator), is a high level sensor
network simulator for wireless sensor network applications. It consists of
application, network and physical components which are interchangeable and
extensible. Application components are used to simulate the execution on a
sensor node, network components are used to simulate the packet to send and
receive functions of a sens or node, and physical components are use to model
sensors, actuators and power and interact with the environment. Users can modify
these existing components or write the new one for their applications, network

59
models, sensor capabilities and environments. SENS features the application
portability to enable direct portability between the simulator and real sensor
nodes.
• TOSSIM
TOSSIM is a discrete event simulator built specifically to simulate the Berkeley
MICA mote hardware platform running applications built on TinyOS wireless
sensor networks. Instead of running a TinyOS application on motes, users can
compile it in the TOSSIM framework which runs on a PC. By running on a PC,
users can test the application in a controlled environment and develop their
TinyOS codes by using debuggers and other development tools. TOSSIM
supports four key requirements of a TinyOS simulator which are scalability,
completeness, fidelity and bridging. TOSSIM is sufficient for the evaluation of a
high level application, but it is not sufficient for low level protocol such as MAC.
Due to TOSSIM mainly focuses on the TinyOS sensor networks; it should not be
used for absolute evaluations in the real world.
• OMNeT++
OMNeT++ (Objective Modular Network Test-bed in C++), is a wireless sensor
network simulator which is based on the discrete event simulation framework. As
the OMNeT++ model collects hierarchy modules, it is possible to capture the
complex system. These modules are separated into two types which are simple
and compound. Simple modules are programmed in C++, while compound
modules which consist of simple modules are programmed in a high-level
language (NED). To communicate between modules, the exchanging messages
which represent the packets in the network are used. OMNeT++ supports users to
study the effect of scale, node-level architecture, energy efficiency,
communication architecture, system architecture, protocols etc.
• Why NS2?
NS2 is a publicly available common simulator with support for simulations of
large number of protocols. It provides a very rich infrastructure for developing

60
new protocols. It also provides the opportunity to study large-scale protocol
interaction in a controlled environment. Moreover, NS software really promotes
extension by users. The fundamental abstraction the software architecture
provides is “programmable composition”. This model expresses simulation
configuration as a program rather than as a static configuration.
NS also has certain disadvantages. NS’s dual language implementation is proving
to be a barrier to some developers. But increasing awareness among the
researchers along with the other tools like tutorials, manuals and mailing lists
have improved the situation.

61
BIBLIOGRAPHY

62
BIBLIOGRAPHY
[1] “The ns Manual”, VINT Project by UC Berkeley, LBL, USC/ISI, and Xerox PARC.
http://www.isi.edu/nsnam/ns/ns-documentation.html [accessed 29 July 2011].
[2] “Introduction to Network Simulator NS2”, Teerawat Issariyakul & Ekram Hossain,
2009, Springer, www.cs.pitt.edu/Courses/Sensors/intro_to_ns2.pdf, 978-0-387-71759-
3, [accessed 28 July 2011].
[3] “Tutorial for the Network Simulator NS”, M.Greis, http://www.isi.edu/nsnam/ns/tutori
al/index.html, [accessed 8 August, 2011].
[4] “NS by Example”, Chung, M. Claypool, WPI Worcester Polytechnic Institute,
Computer Science, http://nile.wpi.e du/NS, [accessed 28 July 2011].
[5] “An Energy-efficient Grid based Clustering Topology for a Wireless Sensor Network”,
Ketki Ram Bhakare, Computer Science & Engg RCERT, Chandrapur, India, February
2012.
[6] “Prolonging Network Lifetime of Clustered- Wireless Sensor Networks”, Muattaz
Elaneizi, Electrical and Computer Engineering Waterloo, Ontario, Canada, May 2008.
[7] “Energy Efficient Protocols for Wireless Sensor Networks”, Md. Enamul Haque,
Department of Information and Computer Sciences Graduate School of Science and
Engineering Saitama University, September 2010.
[8] “Real-time support and energy efficiency in Wireless sensor networks.”, Mahmood Ali
and Sai Kumar Ravula, School of Information Science, Computer and Electrical
Engineering Halmstad University, January 2008.
[9] “An Novel Energy Balanced Dynamic Routing Protocol Based on Probability in
Wireless Sensor Networks”, Ming Zhang, Department of Electronic Engineering,
Huaihai Institute of Technology, March 2011.

63
[10] “A survey on clustering algorithms for wireless sensor network”, Ameer Ahmed
Abbasi & Mohamed Younis, Department of Computer Science and Electrical
Engineering, University of Maryland, www.elsevier.com/locate/com, 21 June, 2007.
[11] Li Qun; Aslam, Javed; Rus, Daniella. Hierarchical Power-aware Routing in Sensor
Networks Rutgers University, http://www.cs.wm.edu/paper/dimacs.pdf, May 21, 2001.
[12] “Practical Programming in Tcl and Tk”, Brent Welch, 0-13-182007-9,
http://www.sunlabs.com/bwelch/book, 13 January, 1995.
[13] “Energy-efficient Secure Routing in Wireless Sensor Networks”, Shriram Sharma,
Department of Computer Science and Engineering National Institute of Technology
Rourkela, May 2009,
[14] “Routing Protocols in Wireless Sensor Networks – A Survey”, Shio Kumar Singh & M
P Singh & D K Singh, Department Of Computer Science and Engineering National
Institute of Technology,
[15] http://isi.edu/nsnam/ns

FINAL PROJECT REPORT

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FINAL PROJECT REPORT

Similar to FINAL PROJECT REPORT (20)

FINAL PROJECT REPORT