Energy efficient and data reporting for navigation position free

hybrid wireless sensor

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 netwo

ii
 CHAPTER 1
INTRODUCTION
 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.
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  Military surveillance

 Habitat monitoring  Medical monitoring
 Acoustic detection  Smart spaces
 Seismic Detection  Inventory tracking
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

• Querying ability
• Efficient memory usage
• Scalability
• Self-organization
• Collaborative processing • 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
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.
 CHAPTER 2

BACKGROUND AND
LITERATURE
SURVEY
 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.
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

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 starts route
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 information about 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. Since each node forwards route request message to all
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-to-infinity problem associated with classical
distance-vector protocols. It offers low overhead, quick adaptation to dynamic link conditions
and low processing and memory overhead.

Figure 2.2: AODV Routing Path

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.
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].
CHAPTER 3

PROBLEM
STATEMENT
 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

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.
Figure 3.2 Cluster Head re-election
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.
 CHAPTER 4

PROJECT PLANNING
 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.
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

Discuss about various

2 15/07/2011 18/07/2011 4
projects

3 Project topic searching 19/07/2011 21/07/2011 3

“Dynamic routing of
4 Packets in WSN” as a 22/07/2011 22/07/2011 1
project.

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

Collecting required
9 28/07/2011 06/08/2011 10
documents

Study of IEEE papers and

10 07/08/2011 28/08/2011 22
references

11 Estimate resources required 29/08/2011 10/09/2011 13

Documentation and
12 11/09/2011 3/10/2011 23
designing

UML ,DFD , Activity

13 11/09/2011 3/10/2011 23
Diagrams

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

 Installation of Ubuntu 10.04
17 10/10/2011 21/10/2011 12
and NS 2.34

Study of Linux commands

18 21/12/2011 27/12/2011 7
and NS2 basics

Learning TCL and OTCL in

19 28/12/2011 05/01/2012 9
detail

Execution of sample TCL

20 06/01/2012 10/01/2012 5
scripts in NS2

Study of available cluster

21 11/01/2012 14/01/2012 4
formation algorithms

Implementation of grid
22 15/01/2012 19/01/2012 5
based clustering algorithm

Study of various election

23 20/01/2012 24/01/2012 5
algorithms to elect CH

Implementation of energy
24 25/01/2012 31/01/2012 7
efficient election algorithm

Study of Inter and Intra

26 06/02/2012 08/02/2012 3
cluster communication

27 3rd Review 09/02/2012 12/02/2012 4

Study of AWK scripting and

30 Xgraph tool for generating 27/02/2012 08/03/2012 10
graphs

Generation and comparison

31 09/03/2012 17/03/2012 9
of various graphs

Drawing Conclusion from

32 18/03/2012 23/03/2012 6
generated graphs

4th Review and Project

33 18/04/2012 19/04/2012 7
exhibition

Table 4.1 Project Schedule

Figure 4.2 Gantt chart
 CHAPTER 5
PROJECT ANALYSIS
 CHAPTER 5
PROJECT ANALYSIS

5.1 USECASE DIAGRAMS

5.1.1 Wireless Sensor Networks
uc wsn

WSN

Cluster formation and

re-election

Collect data]

Network Analysis Monitor Network

Generate
Performance graph Base Station

Communicate to
wired
connection

Sense data

Sensor Node Data cheking and

Validation

Transfer to
Custer
Head Transfer data to
BS
«include»

Acting as CH

«include»

Aggregate Data

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.
 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

uc cluster

Cluster

Sense
data

Report energy
level
to BS Fwd node info to
NA

Report Position to
BS Assign CH Base Station
Sensor Node

CH notification
Act as to Request position &
«include»
CH nodes energy from nodes

«include»

Receive CH
assignment

Request energy
and
position
Network
Arthitect

CH election
Distance
based

CH re-election
Energy
based

Assign CH

Figure 5.2 Use Case of CH Re-election

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.
5.2 SEQUENCE DIAGRAM

sd Use Case Model

Network Admin Base Station ClusterHead 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

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.
 CHAPTER 6
PROJECT DESIGN
 CHAPTER 6
PROJECT DESIGN

6.1 CLASS DIAGRAM

Base_Station
Network_Arch
- BS_Corod: int
- BS_ID: int - Arch_Id: int
- Node_Coord: int - Arch_name: char
1.. 1
+ Design_nw();() : void
+ Collect_data() : void
+ Ini_relection() : void
+ Conn_Wired() : void
+ Manage_nw()() : void
+ Trans_Data() : void

Cluster_Head
- Cluster_no: int Sensor_Node
- Node_Coordinate: int
- Node_Coordinate: int
- Node_Energy: int
- Node_Energy: int
- Node_Id: int
- Node_Id: int
1 *
+ Agg_Data() : void
+ Collect_Data() : void + Get_cid() : void
+ Fwd_Data() : void + Get_energy() : void
+ Get_Energy() : void + Get_movcord() : void
+ Get_Movcord() : void + Send_data() : void

Figure 6.1 Class Diagram

6.2 ACTIVITY DIAGRAM

act Use Case Model

Start

Sense Data

[NO]
Aggerate Data If CH Route Data To Cluster
[YES]
Head

Route Data To Base

Station

Figure 6.2 Activity Diagram

 CHAPTER 7
IMPLEMENTATION
 CHAPTER 7
IMPLEMENTATION

7.1 NETWORK SIMULATOR

7.1.1 Network Simulator version 2 (NS2)

The network simulator (NS), which is an object-oriented, discrete event-driven network

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/ISI, Xerox
PARC, LBNL, and UCB).NS2 is very useful for developing and investigating variety of
protocols. This mainly includes protocols regarding TCP and UDP behavior, traffic source
behavior such as FTP, Telnet and CBR, router queue management mechanism such as Drop
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.

Figure 7.1 Basic Structures of NS

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 start and stop
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
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 \
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
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
 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.
 Figure 7.3 Basic Structure of a Mobile Node.

Each component is briefly described here below.

 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).
  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
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)
 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.

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). Clusters are given
boundaries and if a node lies within these boundaries then it is enlisted in that respective
cluster. Graphically clusters are differentiated by their respective colors. As usual, in a
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.

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. This is also known as “Distance based
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 nature. They make inter or intra cluster movements. The only
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.
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.
CHAPTER 8

ANALYSIS
 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

 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
 Figure 8.3 Snapshot of Scenario2

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.
8.3 SCENARIO 3
4 clusters, 20 node in the cluster, CH re-election based on energy

Figure 8.5 Snapshot of Scenario3

Figure 8.6 XGraph of Scenario3

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.
CHAPTER 9

CONCLUSION
 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.
 CHAPTER 10

FUTURE SCOPE
 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.
APPENDIX A

NS-2
 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.
 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.
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
 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
 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
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.
BIBLIOGRAPHY
 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.
[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