Location Aware Sensor Routing Protocol For Mobile Wireless Sensor Networks

Location aware sensor routing protocol for mobile wireless sensor networks
ABSTRACT
Location aware sensor routing (LASeR) protocol is a novel solution to the challenges of routing
in mobile wireless sensor networks (MWSNs). It addresses the high reliability and low latency
requirements of emerging applications. The protocol uses location information to maintain a
gradient field even in highly mobile environments, whilst reducing the routing overhead. This
allows the protocol to utilise a blind forwarding technique to propagate packets towards the sink.
The protocol inherently utilises multiple paths simultaneously to create route diversity and
increase its robustness. LASeR is designed for use in a high variety of MWSN applications with
autonomous land, sea or air vehicles. Analytical expressions are derived and evaluated against
the simulations. Extensive modelling and simulation of the proposed routing protocol has shown
it to be highly adaptable and robust. It is compared with the recent MWSN proactive highly
ambulatory sensor routing protocol, the high performance mobility adaptive cross-layer routing
protocol, as well as adhoc on-demand distance vector and optimised link state routing. Protocols
are evaluated on packet delivery ratio, end-toend delay, overhead, throughput and energy
consumption. The results highlight both the high performance of LASeR in various challenging
environments and its superiority over the state-of-the-art.
Chapter 1
INTRODUCTION
WIRELESS Sensor and Actor Networks (WSANs) [2] are distributed wireless systems of
heterogeneous devices referred to as sensors and actors. Sensors are low-cost, low-power,
multifunctional devices that communicate untethered in short distances. Actors collect and
process sensor data and consequently perform actions on the environment. In most applications,
actors are resource-rich devices equipped with high processing capabilities, high transmission
power, and long battery life. In WSANs, the collaborative operation of the sensors enables the
distributed sensing of a physical phenomenon. After sensors detect an event that is occurring in
the environment, the event data are distributively processed and transmitted to the actors, which
gather, process, and eventually reconstruct the event data. The process of establishing data paths
between sensors and actors is referred to as sensor-actor coordination [2]. Once the event has
been detected, the actors coordinate to reconstruct it, to estimate its characteristics, and make a
collaborativedecision on how to perform the action. This process is referred to as actor-actor
coordination [2]. As a result, the operation of a WSAN can be thought of as an event-sensing,
communication, decision, and acting loop. Several applications for WSANs are concerned with
enhancing and complementing existing sensor network applications. In these applications, the
performed actions serve the purpose of enhancing the operation of the sensor network by
enabling or extending its monitoring capability. For example, mobile actors can accurately
deploy sensors [3], enable adaptive sampling of the environment [4], pick up data from the
sensors when in close range, buffer it, and drop off the data to wired access points [5], or perform
energy harvesting [6], or enhance the localization capabilities of sensors [7]. Conversely, we are
concerned with new applications
where actors are part of the network and perform actions based on the information gathered by
sensors. We envision that WSANs will be an integral part of systems such as battlefield
surveillance, nuclear, biological or chemical attack detection, home automation, and
environmental monitoring [2]. For example, in fire detection applications, sensors can relay the
exact origin and intensity of the fire to water sprinkler actors that will extinguish the fire before it
spreads. Moreover, sensors can detect plumes, i.e., visible or measurable discharges of
contaminants in water or in the air, and actors can reactively take countermeasures. Similarly,
motion, acoustic, or light sensors in a building can detect the presence of intruders and command
cameras or other instrumentations to track them. Alternatively, mobile actors can be moved to the
area where the intruder has been detected to get high-resolution images, prompt or block the
intruder. As a last example, in earthquake scenarios, sensors can help locate survivors and guide
mobile actors performing rescue operations. As an abstraction of several application setups
encountered in the above-mentioned applications, we refer to a scenario where sensors monitor a
given terrain and send samples of the event to the actors deployed on the terrain whenever an
event occurs. Actors distributively reconstructthe event based on partial information available at
different actors, estimate the event characteristics, and identify an action area. Based on this,
actors collaboratively decide on which actors should move to the action area and at which speed.
The coordinated mobility of actors is thus triggered by the occurrence of events. Actors keep
receiving event data until the event is active, and multiple consecutive events trigger subsequent
reassignment of tasks among the actors. In our prior work on WSANs [8], we introduced a
framework for communication and coordination problems with static WSANs. The concepts of
sensor-actor coordination and actor-actor coordination were introduced, and centralized optimal
solutions and distributed heuristics were proposed. However, many challenging applications
require support for mobile actors, which is not provided in [8]. Hence, in this paper, we extend
our previous work in several directions. First, we introduce a hybrid location management
scheme to handle the mobility of actors with minimal
energy consumption for the sensors. The proposed solution is tailored for WSAN applications
and overcomes the drawbacks of previously proposed localization services [9], [10]. Actors
broadcast updates limiting their scope based on Voronoi diagrams, while sensors predict the
movements of actors based on Kalman filtering of previously received updates. Our proposed
scheme combines joint use of Kalman filtering with Voronoi scoping on sensors and actors to
lead to a new location management technique, which is shown to consistently reduce the energy
consumption on sensors by avoiding over 75 percent of location updates with respect to existing
location update algorithms. The location management scheme is designed to enable efficient
geographical routing for sensor-actor communications.
Based on this, the second contribution of this paper is the development of an integrated
routing/physical layer scheme for sensor-actor communication based on geographical routing,
which is suited for mobile WSANs, and which leverages the information provided by the
location management scheme. We derive a simple yet optimal forwarding rule based on
geographic position in presence of Rayleigh fading channels. With respect to the previously
proposed geographic forwarding rules [11], [12], our rule is optimal from the energy
consumption standpoint. Furthermore, we show how to control the delay of the data-delivery
process based on power control, i.e., to trade optimal energy consumption for decreased delay in
case of low or moderate traffic. In case of high traffic, we introduce a new network
congestion control mechanism at the network layer that forces multiple actors to share the traffic
generated in the event area. This is shown to reduce delay, packet drops, and energy consumption
even when traffic is sent to actors that are sub optimal from a network layer stand point.
Chapter 2
LITERATURE SURVEY
Ehsan, S., Bradford, K., Brugger, M., et al.: Design and analysis of delay-tolerant
sensor networks for monitoring and tracking free-roaming animals,
This paper is concerned with the design and analysis of delay-tolerant networks (DTNs)
deployed for free-roaming animal monitoring, wherein information is either transmitted or
carried to static access-points by the animals whose movement is assumed to be random.
Specifically, in such mobility-aided applications where routing is performed in a store-carry-and-
drop manner, limited buffer capacity of a carrier node plays a critical role, and data loss due to
buffer overflow heavily depends on access-point density. Driven by this fact, our focus in this
paper is on providing sufficient conditions on access-point density that limit the likelihood of
buffer overflow. We first derive sufficient access-point density conditions that ensure that the
data loss rates are statistically guaranteed to be below a given threshold. Then, we evaluate and
validate the derived theoretical results through comparison with both synthetic and real-world
data.
Grocholsky, B., Keller, J., Kumar, V., et al.: Cooperative air and ground
surveillance,
Unmanned aerial vehicles (UAV) can be used to cover large areas searching for targets.
However, sensors on UAVs are typically limited in their accuracy of localization of targets on the
ground. On the other hand, unmanned ground vehicles (UGV) can be deployed to accurately
locate ground targets, but they have the disadvantage of not being able to move rapidly or see
through such obstacles as buildings or fences. In this paper, we describe how we can exploit this
synergy by creating a seamless network of UAVs and UGVs. The keys to this are our framework
and algorithms for search and localization, which are easily scalable to large numbers of UAVs
and UGVs and are transparent to the specificity of individual platforms. We describe our
experimental testbed, the framework and algorithms, and some results
Liu, B., Dousse, O., Nain, P., et al.: Dynamic coverage of mobile sensor
networks
In this paper we study the dynamic aspects of the coverage of a mobile sensor network resulting
from continuous movement of sensors. As sensors move around, initially uncovered locations are
likely
to be covered at a later time. A larger area is covered as time continues, and intruders that might
never be detected in a stationary sensor network can now be detected by moving sensors.
However,
this improvement in coverage is achieved at the cost that a location is covered only part of the
time,
alternating between covered and not covered. We characterize area coverage at specific time
instants and
during time intervals, as well as the time durations that a location is covered and uncovered. We
further
characterize the time it takes to detect a randomly located intruder. For mobile intruders, we take
a game
theoretic approach and derive optimal mobility strategies for both sensors and intruders. Our
results show
that sensor mobility brings about unique dynamic coverage properties not present in a stationary
sensor
network, and that mobility can be exploited to compensate for the lack of sensors to improve
coverage.
Bohacek, S.: Performance improvements provided by route diversity in multihop
wireless networks
In multihop wireless networks, the variability of channels results in some paths providing better
performance than other paths. Although it is well known that some paths are better than others, a
significant number of routing protocols do not focus on utilizing optimal paths. However,
cooperative diversity, which is an area of recent interest, provides techniques for efficiently
exploiting path and channel diversity. This paper examines the potential performance
improvements offered by path diversity. Three settings are examined, namely, where the path
loss and channel correlation are neglected, where path loss is considered, but channel correlation
is neglected, and where path loss and channel correlation are both accounted for. It is shown that,
by exploiting path diversity, dramatic improvements in the considered route metric may be
achieved. Furthermore, in some settings, if the link statistics are held constant, then when path
diversity is exploited, the route metric improves with path length. This implies that, if links
statistics are fixed and if sufficient path diversity exists, then paths with more hops tend to
support higher bit rates than paths with fewer hops. It is shown that such behavior occurs when a
particular map has a nonzero fixed point.
Soliman, H., AlOtaibi, M.: An efficient routing approach over mobile wireless
Ad-Hoc sensor networks
In this paper, we efficiently adapt the prominent Ad Hoc On-Demand Distance Vector (AODV)
routing protocol with a reactive Local Link Repair, AODV-LR, for effective deployment in
restricted power-budget and bandwidth mobile ad hoc sensor networks (MASNET). We
introduce a better replacement mechanism to the local repair phase of the AODV. Our new
approach is a preemptive, self-repairing AODV (called AODV-PSR) scheme that is able to find
an alternative link to a failing link. The new preemptive protocol achieves better performance
than the ADOV-LR, due to its avoidance of packet buffering delay and excess use of control
messages during link repair. Experimental results show a much lower obtained packet delay, a
higher packet delivery ratio, and lower control message overhead. Hence, our mechanism is
amenable to deployment in areas of restricted power-budget and bandwidth, such as a MASNET
domain.
Han, Y., Lin, Z.: A geographically opportunistic routing protocol used in mobile
wireless sensor networks
Opportunistic routing protocols have been widely explored to improve the performance of multi-
hop communication. However, most existing opportunistic routing protocols face several
challenges such as low efficiency in mobile wireless sensor networks (WSNs), diverging, long
latency etc. In this paper, a new geographically opportunistic routing protocol (GOR) is proposed
to tackle these challenges. The essential idea of GOR is to base routing on static geographic
information instead of mobile sensors. In GOR, the bounded sensor area is divided into
unchangeable geographic grids at the initialization of a network. Each grid has its priority
according to its distance to the static sink. When a source node is going to send a data packet to
the sink, it follows the steps below: (1) This source node determines the forwarding path table
and the starting grid whose distance is equal to the maximum one-hop transmission distance (the
distance that ensures accepting power is larger than a specific threshold), and includes these
information at the head of the packet. (2) Then this packet is broadcast. Nodes in the starting grid
have the highest priority to forward the packet. If some of these nodes have received the packet,
they compete to be the only forwarding node and send acknowledge signals (ACKs) to lower
priority nodes by flooding meanwhile. Nodes in lower priority grids delay for different time
according to their priorities and forward the packet if having not received ACKs from higher
priority nodes. (3) The forwarding node only updates the starting grid of the next hop
transmission at the head of the packet. The packet is then transmitted hop by hop until it reaches
the sink. Simulation results are presented to demonstrate the effectiveness of GOR.
Heinzelman, W., Chandrakasan, A., Balakrishnan, H.
Energy efficient communication protocol for wireless micro sensor networks.
Wireless distributed micro-sensor systems will enable the reliable monitoring of a variety of
environments for both civil and military applications. In this paper, we look at communication
protocols, which can have significant impact on the overall energy dissipation of these
networks.Based on our findings that the conventional protocols of direct transmission, minimum-
transmission-energy, multihop routing, and static clustering may not be optimal for sensor
networks, we propose LEACH (Low-Energy Adaptive Clustering Hierarchy), a clustering-based
protocol that utilizes randomized rotation of local cluster base stations (cluster-heads) to evenly
distribute the energy load among the sensors in the network. LEACH uses localized coordination
to enable scalability and robustness for dynamic net-works, and incorporates data fusion into the
routing protocol to reduce the amount of information that must be transmitted to the base station.
Simulations show that LEACH can achieve as much as a factor of 8 reduction in energy
dissipation compared with conventional routing protocols. In addition, LEACH is able to
distribute energy dissipation evenly throughout the sensors, doubling the useful system lifetime
for the networks we simulated.
Chapter 3
SYSTEM ANALYSIS
3.1 EXISTING SYSTEM
In general MWSN routing protocols take influence from two main research areas; WSNs and
MANETs. WSNs are commonly considered to be static and so cannot handle the mobility of
nodes, whereas MANETs are designed to cope with mobile nodes. Contrastingly to MANETs,
most sensor networks only require data to flow in one direction; from source to sink. In addition
to this the hardware and power constraints on these small sensor nodes, means that protocols
must have low computational complexity and low energy consumption. Energy is a major
concern with battery powered mobility platforms since high energy consumption can
dramatically reduce the lifetime of the network.
MANET protocols are often defined as proactive or reactive. The proactive protocols, such as
optimised link state routing (OLSR) [7], attempt to ensure that each node has an active path to
every other node. This usually requires the flooding of topology data, which can cause huge
amounts of congestion in large networks. Contrastingly, reactive protocols, such as ad-hoc on-
demand distance vector (AODV) [8], only discovers routes when they are needed. This can often
reduce the overhead of control packets, making reactive protocols a more common choice for
mobile networks. This can be seen by the number of reactive protocols that have been adapted
from MANETs to MWSNs. For example, AODV with preemptive self-repair [9], is an
adaptations of AODV designed for MWSNs, which, attempts to predict link breaks and find
replacements. Another technique used is opportunistic routing, such as seen in geographically
opportunistic routing [10], which splits up the network into sections. Using location information,
each node then tries to forward the packet to a node in a section that is closer to the sink. It
opportunistically attempts to transmit to the furthest section within its transmission radius, before
trying increasingly closer sections.
3.2 PROPOSED SYSTEM
In the proposed system, the system implemented the protocol to utilise a blind
forwarding technique to propagate packets towards the sink. The protocol inherently utilises
multiple paths simultaneously to create route diversity and increase its robustness. LASeR is
designed for use in a high variety of MWSN applications with autonomous land, sea or air
vehicles. Analytical expressions are derived and evaluated against the simulations. Extensive
modelling and simulation of the proposed routing protocol has shown it to be highly adaptable
and robust. It is compared with the recent MWSN proactive highly ambulatory sensor routing
protocol, the high performance mobility adaptive cross-layer routing protocol, as well as adhoc
on-demand distance vector and optimised link state routing. Protocols are evaluated on packet
delivery ratio, end-toend delay, overhead, throughput and energy consumption. The results
highlight both the high performance of LASeR in various challenging environments and its
superiority over the state-of-the-art.
Chapter 4
SYSTEM REQUIREMENTS AND SPECIFICATION
4.1 SOFTWARE SPECIFICATION
Operating system : Linux ( Ubutun )
Software : Network Simulator 2.35
Programming langs : Tool Command Language, AWK, C++
4.2 HARDWARE SPECIFICATION
Main processor : Dual Core
Hard disk capacity : 80GB
Cache memory : 2 GB
4.3 Software Description
SOFTWARE DESCRIPTION
5.3.1 THE NETWORK SIMULATOR2.35 (NS2)
Network Simulator (NS2) is a discrete event driven simulator developed at UC Berkeley.

It is part of the VINT project. The goal of NS2 is to support networking research and education.
It is suitable for designing new protocols, comparing different protocols and traffic evaluations.
NS2 is developed as a collaborative environment. It is distributed freely and open source. A large
amount of institutes and people in development and research use, maintain and develop NS2.
This increases the confidence in it. Versions are available for FreeBSD, Linux, Solaris, Windows
and Mac OS X.
5.3.2 STRUCTURE OF NS2
NS2 is built using object oriented methods in C++ and OTcl (object oriented variant of
Tcl.
Fig 5.1 Simplified Users View of Ns
can see in Fig 5.1, NS2 interprets the simulation scripts written in OTcl. A user has to set the
different components (e.g. event scheduler objects, network components libraries and setup
module libraries) up in the simulation environment. The user writes his simulation as a OTcl
script, plumbs the network components together to the complete simulation. If he needs new
network components, he is free to implement them and to set them up in his simulation as well.
The event scheduler as the other major component besides network components triggers the
events of the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS2 are
written in C++ for efficiency reasons. The data path (written in C++) is separated from the
control path (written in OTcl). Data path object are compiled and then made available to the OTcl
interpreter through an OTcl linkage (tclcl) which maps methods and member variables of the C+
+ object to methods and variables of the linked OTcl object. The C++ objects are controlled by
OTcl objects. It is possible to add methods and member variables to a C++ linked OTcl object.
5.3.3 FUNCTIONALITIES OF NS2.35
Functionalities for wired, wireless networks, tracing, and visualization are available in
NS2.
Support for the wired world include
Routing DV, LS, and PIM-SM.
Transport protocols: TCP and UDP for unicast and SRM for multicast.
Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio.
Different types of Queues: drop-tail, RED, FQ, SFQ, DRR.
Quality of Service: Integrated Services and Differentiated Services.
Emulation.
Support for the wireless world include
Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA
Wired-cum-wireless networks
Mobile IP
Directed diffusion
Satellite
Senso-MAC
Multiple propagation models (Free space, two-ray ground, shadowing)
Energy models
Tracing
Visualization
Network Animator (NAM)
Trace Graph
Utilities
Mobile Movement Generator
Fig 5.2 OTcl and C++: the duality
5.3.3.1 MOBILE NETWORKING IN NS2.35
This section describes the wireless model that was originally ported as CMUs Monarch
groups mobility extension to NS2. The first section covers the original mobility model ported
from CMU/Monarch group. In this section, we cover the internals of a mobile node, routing
mechanisms and network components that are used to construct the network stack for a mobile
node. The components that are covered briefly are Channel, Network interface, Radio
propagation model, MAC protocols, Interface Queue, Link layer and Address resolution protocol
model (ARP). CMU trace support and Generation of node movement and traffic scenario files
are also covered in this section. The original CMU model allows simulation of pure wireless
LANs or multi-hop ad-hoc networks. Further extensions were made to this model to allow
combined simulation of wired and wireless networks. Mobile-IP was also extended to the
wireless model.
5.3.3.2 THE BASIC WIRELESS MODEL IN NS
The wireless model essentially consists of the MobileNode at the core, with additional
supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc.
The MobileNode object is a split object. The C++ class MobileNode is derived from parent class
Node. A MobileNode thus is the basic Node object with added functionalities of a wireless and
mobile node like ability to move within a given topology, ability to receive and transmit signals
to and from a wireless channel etc. A major difference between them, though, is that a
MobileNode is not connected by means of Links to other nodes or mobilenodes. In this section
we shall describe the internals of MobileNode, its routing mechanisms, the routing protocols
dsdv, aodv, tora and dsr, creation of network stack allowing channel access in MobileNode, brief
description of each stack component, trace support and movement/traffic scenario generation for
wireless simulations.
5.3.3.3 MOBILE NODE: CREATING WIRELESS TOPOLOGY
MobileNode is the basic nsNode object with added functionalities like movement, ability to
transmit and receive on a channel that allows it to be used to create mobile, wireless simulation
environments. The class MobileNode is derived from the base class Node. MobileNode is a split
object. The mobility features including node movement, periodic position updates, maintaining
topology boundary etc are implemented in C++ while plumbing of network components within
MobileNode itself (like classifiers, dmux , LL, Mac, Channel etc) have been implemented in
Otcl.
Table 5.1: Available Options For Node Configuration

Option Available Values Default
General
Address type Flat, Hierarchical Flat
MPLS ON,OFF OFF
Both Satellite and Wireless Oriented
Wired Routing ON,OFF OFF
II Type LL,LL/sat OFF
Mac Type Mac/802_11,Mac/Csma/Ca, OFF

Mac/Sat/Unslotted/Aloha,Mac/Tdma
ifq Type Queue/DropTail, Queue/Droptail/PriQueue OFF
Phy Type Phy/wirelessPhy,Physat OFF
Option Available Values Default
Satellite Oriented
satNodeType Polar,Geo,Terminal,Geo-repeater OFF
downlinkBW <bandwidth value, e.g 2MB> OFF
Wireless Oriented
Adhoc Routing DIFFUSION/RATE,DIFFUSION/PROB, OFF
DSDV,FLOODING,OMNICAST,AODV,TORA
propType Propagation/2RayGround,Propagation Shadowing OFF
propInstance Propagation/2RayGround,Propagation Shadowing OFF
antType Antenna/Omni Antenna OFF
Channel Channel/Wireless Channel,Channel/sat OFF
topoInstance <toplogy file> OFF

MobileIP ON,OFF OFF
Energy model Energy model OFF
Initial Energy <value in joules> OFF
rxPower <value in W> OFF
txPower <value in W> OFF
Idle Power <value in W> OFF
AgentTrace ON,OFF OFF
routerTrace ON,OFF OFF
macTrace ON,OFF OFF
movementTrace ON,OFF OFF
Errproc UniformErrorProc OFF
FECProc ? ?
toraDebug ON,OFF OFF
Chapter 5
SYSTEM DESIGN
Data Flow diagram
Upload
Sender Packets Rout
er
Find Neighbor Nodes

Location
Check Lowest
Distance Node No
Power
Select Other
Lowest Node
Yes
Lowest Node
Check Energy
Status
Low Congestion/Traf
c
High
Select that Nodes

Location
Yes
Calculate
Time Delay
Received to
Destination
6.2 SYSTEM ARCHITECTURE
Find All
Neighbor Nodes
Location
Find All Possible
Routing paths
DESTINATION
SOURCE
RE
Select High Q Receive data
energy nodes RE
P
Routing path
REQ
Leave less energy Send RREP and
REP
node RREQ to Source
REQ
Find Shortest Measure Time
path nodes Delay
RE
P
Graph
Transfer data Measure Total
from one to Calculate energy
another nodes Energy
Location Find Less
Energy Path
REQ Request
REP Reply
5.3 Sequence Diagram
Source Routing path

Destination
Initiate
Sender
Node Receive Request
initializati Find all neighbor
Path Req to
nodes
other nodes
Path Req
Response
Send request
from one to
another nodes
Find Req reply from other
nodes Location
Send
Store
data
FileConfirmation
Sending
to Destination Receive data
Find the Shortest

Distance Node in each
Neighbor nodes Location
Find for traffic if
node energy is less
Find the
Shortest
Nodes
Find the
Time Taken
and its path
5.4 SYSTEM STUDY
2.1 FEASIBILITY STUDY
The feasibility of the project is analyzed in this phase and business
proposal is put forth with a very general plan for the project and some cost
estimates. During system analysis the feasibility study of the proposed system is
to be carried out. This is to ensure that the proposed system is not a burden to
the company. For feasibility analysis, some understanding of the major
requirements for the system is essential.

Three key considerations involved in the feasibility analysis are
ECONOMICAL FEASIBILITY
TECHNICAL FEASIBILITY
SOCIAL FEASIBILITY
ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that
the system will have on the organization. The amount of fund that
the company can pour into the research and development of the
system is limited. The expenditures must be justified. Thus the
developed system as well within the budget and this was

achieved because most of the technologies used are freely
available. Only the customized products had to be purchased.
TECHNICAL FEASIBILITY
This study is carried out to check the technical
feasibility, that is, the technical requirements of the system. Any
system developed must not have a high demand on the available
technical resources. This will lead to high demands on the
available technical resources. This will lead to high demands
being placed on the client. The developed system must have a
modest requirement, as only minimal or null changes are required
for implementing this system.
SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of
the system by the user. This includes the process of training the
user to use the system efficiently. The user must not feel
threatened by the system, instead must accept it as a necessity.
The level of acceptance by the users solely depends on the
methods that are employed to educate the user about the system
and to make him familiar with it. His level of confidence must be
raised so that he is also able to make some constructive criticism,
which is welcomed, as he is the final user of the system.
6. SYSTEM TESTING
The purpose of testing is to discover errors. Testing is the

process of trying to discover every conceivable fault or weakness
in a work product. It provides a way to check the functionality of
components, sub assemblies, assemblies and/or a finished
product It is the process of exercising software with the intent of
ensuring that the
Software system meets its requirements and user expectations

and does not fail in an unacceptable manner. There are various
types of test. Each test type addresses a specific testing
requirement.
TYPES OF TESTS
Unit testing
Unit testing involves the design of test cases that validate
that the internal program logic is functioning properly, and that
program inputs produce valid outputs. All decision branches and
internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the
completion of an individual unit before integration. This is a
structural testing, that relies on knowledge of its construction and
is invasive. Unit tests perform basic tests at component level and
test a specific business process, application, and/or system
configuration. Unit tests ensure that each unique path of a
business process performs accurately to the documented
specifications and contains clearly defined inputs and expected
results.
Integration testing
Integration tests are designed to test integrated software

components to determine if they actually run as one program.
Testing is event driven and is more concerned with the basic
outcome of screens or fields. Integration tests demonstrate that
although the components were individually satisfaction, as shown
by successfully unit testing, the combination of components is
correct and consistent. Integration testing is specifically aimed at
exposing the problems that arise from the combination of
components.
Functional test
Functional tests provide systematic demonstrations that

functions tested are available as specified by the business and
technical requirements, system documentation, and user
manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be

accepted.
Invalid Input : identified classes of invalid input must be

rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must

be exercised.
Systems/Procedures: interfacing systems or procedures must be

invoked.
Organization and preparation of functional tests is focused on

requirements, key functions, or special test cases. In addition,
systematic coverage pertaining to identify Business process flows;
data fields, predefined processes, and successive processes must
be considered for testing. Before functional testing is complete,
additional tests are identified and the effective value of current
tests is determined.
System Test
System testing ensures that the entire integrated software
system meets requirements. It tests a configuration to ensure
known and predictable results. An example of system testing is
the configuration oriented system integration test. System testing
is based on process descriptions and flows, emphasizing pre-
driven process links and integration points.
White Box Testing

White Box Testing is a testing in which in which the software
tester has knowledge of the inner workings, structure and
language of the software, or at least its purpose. It is purpose. It is
used to test areas that cannot be reached from a black box level.
Black Box Testing

Black Box Testing is testing the software without any
knowledge of the inner workings, structure or language of the
module being tested. Black box tests, as most other kinds of
tests, must be written from a definitive source document, such as
specification or requirements document, such as specification or
requirements document. It is a testing in which the software
under test is treated, as a black box .you cannot see into it. The
test provides inputs and responds to outputs without considering
how the software works.
6.1 Unit Testing:

Unit testing is usually conducted as part of a combined code

and unit test phase of the software lifecycle, although it is not
uncommon for coding and unit testing to be conducted as two
distinct phases.
Test strategy and approach

Field testing will be performed manually and functional tests
will be written in detail.
Test objectives
All field entries must work properly.
Pages must be activated from the identified link.
The entry screen, messages and responses must not be
delayed.
Features to be tested
Verify that the entries are of the correct format
No duplicate entries should be allowed
All links should take the user to the correct page.
6.2 Integration Testing
Software integration testing is the incremental integration

testing of two or more integrated software components on a
single platform to produce failures caused by interface defects.
The task of the integration test is to check that components

or software applications, e.g. components in a software system or
one step up software applications at the company level
interact without error.
Test Results: All the test cases mentioned above passed

successfully. No defects encountered.
6.3 Acceptance Testing
User Acceptance Testing is a critical phase of any project and

requires significant participation by the end user. It also ensures
that the system meets the functional requirements.
Test Results: All the test cases mentioned above passed

successfully. No defects encountered.
SYSTEM TESTING
TESTING METHODOLOGIES
The following are the Testing Methodologies:
o Unit Testing.
o Integration Testing.
o User Acceptance Testing.
o Output Testing.
o Validation Testing.
Unit Testing
Unit testing focuses verification effort on the smallest unit of Software design that is the
module. Unit testing exercises specific paths in a modules control structure to ensure complete
coverage and maximum error detection. This test focuses on each module individually, ensuring
that it functions properly as a unit. Hence, the naming is Unit Testing.
During this testing, each module is tested individually and the module interfaces are
verified for the consistency with design specification. All important processing path are tested for
the expected results. All error handling paths are also tested.
Integration Testing
Integration testing addresses the issues associated with the dual problems of verification
and program construction. After the software has been integrated a set of high order tests are
conducted. The main objective in this testing process is to take unit tested modules and builds a
program structure that has been dictated by design.
The following are the types of Integration Testing:
1)Top Down Integration
This method is an incremental approach to the construction of program structure.

Modules are integrated by moving downward through the control hierarchy, beginning with the
main program module. The module subordinates to the main program module are incorporated
into the structure in either a depth first or breadth first manner.
In this method, the software is tested from main module and individual stubs are replaced
when the test proceeds downwards.
2. Bottom-up Integration
This method begins the construction and testing with the modules at the lowest level in
the program structure. Since the modules are integrated from the bottom up, processing required
for modules subordinate to a given level is always available and the need for stubs is eliminated.
The bottom up integration strategy may be implemented with the following steps:
The low-level modules are combined into clusters into clusters that
perform a specific Software sub-function.
A driver (i.e.) the control program for testing is written to coordinate test
case input and output.
The cluster is tested.
Drivers are removed and clusters are combined moving upward in the
program structure
The bottom up approaches tests each module individually and then each module is
module is integrated with a main module and tested for functionality.
OTHER TESTING METHODOLOGIES
User Acceptance Testing
User Acceptance of a system is the key factor for the success of any system.
The system under consideration is tested for user acceptance by constantly keeping
in touch with the prospective system users at the time of developing and making
changes wherever required. The system developed provides a friendly user
interface that can easily be understood even by a person who is new to the system.
Output Testing
After performing the validation testing, the next step is output testing of the
proposed system, since no system could be useful if it does not produce the
required output in the specified format. Asking the users about the format required
by them tests the outputs generated or displayed by the system under
consideration. Hence the output format is considered in 2 ways one is on screen
and another in printed format.
Validation Checking
Validation checks are performed on the following fields.

Text Field:
The text field can contain only the number of characters lesser than or equal to its size.
The text fields are alphanumeric in some tables and alphabetic in other tables. Incorrect entry
always flashes and error message.
Numeric Field:
The numeric field can contain only numbers from 0 to 9. An entry of any character
flashes an error messages. The individual modules are checked for accuracy and what it has to
perform. Each module is subjected to test run along with sample data. The individually tested
modules are integrated into a single system. Testing involves executing the real data
information is used in the program the existence of any program defect is inferred from the
output. The testing should be planned so that all the requirements are individually tested.
A successful test is one that gives out the defects for the inappropriate data and produces
and output revealing the errors in the system.
Preparation of Test Data
Taking various kinds of test data does the above testing. Preparation of test data plays a
vital role in the system testing. After preparing the test data the system under study is tested
using that test data. While testing the system by using test data errors are again uncovered and
corrected by using above testing steps and corrections are also noted for future use.
Using Live Test Data:
Live test data are those that are actually extracted from organization files.
After a system is partially constructed, programmers or analysts often ask users to
key in a set of data from their normal activities. Then, the systems person uses this
data as a way to partially test the system. In other instances, programmers or
analysts extract a set of live data from the files and have them entered themselves.
It is difficult to obtain live data in sufficient amounts to conduct extensive testing. And,
although it is realistic data that will show how the system will perform for the typical processing
requirement, assuming that the live data entered are in fact typical, such data generally will not
test all combinations or formats that can enter the system. This bias toward typical values then
does not provide a true systems test and in fact ignores the cases most likely to cause system
failure.
Using Artificial Test Data:
Artificial test data are created solely for test purposes, since they can be generated
to test all combinations of formats and values. In other words, the artificial data,
which can quickly be prepared by a data generating utility program in the
information systems department, make possible the testing of all login and control
paths through the program.
The most effective test programs use artificial test data generated by persons other
than those who wrote the programs. Often, an independent team of testers
formulates a testing plan, using the systems specifications.
The package Virtual Private Network has satisfied all the requirements specified
as per software requirement specification and was accepted.
USER TRAINING
Whenever a new system is developed, user training is required to educate them

about the working of the system so that it can be put to efficient use by those for
whom the system has been primarily designed. For this purpose the normal working
of the project was demonstrated to the prospective users. Its working is easily
understandable and since the expected users are people who have good knowledge
of computers, the use of this system is very easy.
MAINTAINENCE
This covers a wide range of activities including correcting code and design errors. To
reduce the need for maintenance in the long run, we have more accurately defined
the users requirements during the process of system development. Depending on
the requirements, this system has been developed to satisfy the needs to the
largest possible extent. With development in technology, it may be possible to add
many more features based on the requirements in future. The coding and designing
is simple and easy to understand which will make maintenance easier.
TESTING STRATEGY :
A strategy for system testing integrates system test cases and design techniques
into a well planned series of steps that results in the successful construction of
software. The testing strategy must co-operate test planning, test case design, test
execution, and the resultant data collection and evaluation .A strategy for software
testing must accommodate low-level tests that are necessary to verify that a
small source code segment has been correctly implemented as well as high
level tests that validate major system functions against user requirements.
Software testing is a critical element of software quality assurance and represents

the ultimate review of specification design and coding. Testing represents an
interesting anomaly for the software. Thus, a series of testing are performed for
the proposed system before the system is ready for user acceptance testing.
SYSTEM TESTING:
Software once validated must be combined with other system elements (e.g.
Hardware, people, database). System testing verifies that all the elements are
proper and that overall system function performance is achieved. It also tests to
find discrepancies between the system and its original objective, current
specifications and system documentation.
UNIT TESTING:
In unit testing different are modules are tested against the specifications produced
during the design for the modules. Unit testing is essential for verification of the
code produced during the coding phase, and hence the goals to test the internal
logic of the modules. Using the detailed design description as a guide, important
Conrail paths are tested to uncover errors within the boundary of the modules.
This testing is carried out during the programming stage itself. In this type of testing
step, each module was found to be working satisfactorily as regards to the expected
output from the module.
In Due Course, latest technology advancements will be taken into

consideration. As part of technical build-up many components of the networking
system will be generic in nature so that future projects can either use or interact
with this. The future holds a lot to offer to the development and refinement of this
project.

Location Aware Sensor Routing Protocol For Mobile Wireless Sensor Networks

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Location Aware Sensor Routing Protocol For Mobile Wireless Sensor Networks

Загружено:

Авторское право:

Доступные форматы

Location aware sensor routing protocol for mobile wireless sensor networks

sensor networks for monitoring and tracking free-roaming animals,

Bohacek, S.: Performance improvements provided by route diversity in multihop

Ad-Hoc sensor networks

wireless sensor networks

Heinzelman, W., Chandrakasan, A., Balakrishnan, H.

Energy efficient communication protocol for wireless micro sensor networks.

3.1 EXISTING SYSTEM

3.2 PROPOSED SYSTEM

SYSTEM REQUIREMENTS AND SPECIFICATION

4.1 SOFTWARE SPECIFICATION

Operating system : Linux ( Ubutun )

Software : Network Simulator 2.35

Programming langs : Tool Command Language, AWK, C++

4.2 HARDWARE SPECIFICATION

Main processor : Dual Core

Hard disk capacity : 80GB

4.3 Software Description

5.3.1 THE NETWORK SIMULATOR2.35 (NS2)

Network Simulator (NS2) is a discrete event driven simulator developed at UC Berkeley.

5.3.2 STRUCTURE OF NS2

Fig 5.1 Simplified Users View of Ns

5.3.3 FUNCTIONALITIES OF NS2.35

Support for the wired world include

Routing DV, LS, and PIM-SM.

Different types of Queues: drop-tail, RED, FQ, SFQ, DRR.

Quality of Service: Integrated Services and Differentiated Services.

Support for the wireless world include

Multiple propagation models (Free space, two-ray ground, shadowing)

Network Animator (NAM)

Mobile Movement Generator

Fig 5.2 OTcl and C++: the duality

5.3.3.1 MOBILE NETWORKING IN NS2.35

5.3.3.2 THE BASIC WIRELESS MODEL IN NS

5.3.3.3 MOBILE NODE: CREATING WIRELESS TOPOLOGY

Table 5.1: Available Options For Node Configuration

Option Available Values Default

Address type Flat, Hierarchical Flat

MPLS ON,OFF OFF

Both Satellite and Wireless Oriented

Wired Routing ON,OFF OFF

II Type LL,LL/sat OFF

Mac Type Mac/802_11,Mac/Csma/Ca, OFF

ifq Type Queue/DropTail, Queue/Droptail/PriQueue OFF

Phy Type Phy/wirelessPhy,Physat OFF

Option Available Values Default

satNodeType Polar,Geo,Terminal,Geo-repeater OFF

downlinkBW <bandwidth value, e.g 2MB> OFF

Adhoc Routing DIFFUSION/RATE,DIFFUSION/PROB, OFF

propType Propagation/2RayGround,Propagation Shadowing OFF

propInstance Propagation/2RayGround,Propagation Shadowing OFF

antType Antenna/Omni Antenna OFF

Channel Channel/Wireless Channel,Channel/sat OFF

topoInstance <toplogy file> OFF

MobileIP ON,OFF OFF

Energy model Energy model OFF

Initial Energy <value in joules> OFF

rxPower <value in W> OFF

txPower <value in W> OFF

Idle Power <value in W> OFF

AgentTrace ON,OFF OFF

routerTrace ON,OFF OFF

macTrace ON,OFF OFF