Abstract

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.1SOFTWARE 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
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
5.1 DATA FLOW DIAGRAM

Sender Uploa Rout

d er
Packe
ts
Find Neighbor Nodes
Location
No
Check
Check
Select Other
Lowest
Lowest
Distanc Lowest Node
Distanc
e
e Node
Node
Power
Power
Yes
Lowest Node
Chec
Chec
kk Low Congestion/Traffic
Energ
Energ
yy
Statu
StatuHigh
ss
Select that Nodes

Location
Yes
Calculate Time
Delay
Received to
Destination
5.2 SEQURENE DIAGRAM
Sequence Diagram
Source Routing path

Initiate Destination
Sender
Node Receive Request
initialization
Path Req to other
nodes Find all neighbor nodes
Path Req
Response
File
Send Store
Sending
dataConfirmation
toConfirmation
Destination Receive data
Send request from

one to another
nodes
Find Req reply from other
nodes Location
Find the Shortest Distance

5.3 SYSTEM ARCHITECTURE 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
Chapter 6
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.
6.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.
REFERENCES
[1] T. Melodia, D. Pompili, and I.F. Akyildiz, A Communication Architecture for Mobile
Wireless Sensor and Actor Networks, Proc. IEEE Conf. Sensor, Mesh and Ad Hoc Comm. and
Networks (SECON), Sept. 2006.
[2] I.F. Akyildiz and I.H. Kasimoglu, Wireless Sensor and Actor Networks: Research
Challenges, Ad Hoc Networks, vol. 2, no. 4, pp. 351-367, Oct. 2004.
[3] G. Wang, G. Cao, T.L. Porta, and W. Zhang, Sensor Relocation in Mobile Sensor
Networks, Proc. IEEE INFOCOM, Mar. 2005.
[4] P. Ogren, E. Fiorelli, and N.E. Leonard, Cooperative Control of Mobile Sensor Networks:
Adaptive Gradient Climbing in a Distributed Environment, IEEE Trans. Automatic Control, vol.
49, no. 8, pp. 1292-1302, Aug. 2004.
[5] R. Shah, S. Roy, S. Jain, W. Brunette, and G. Borriello, Data MULEs: Modeling a Three-
Tier Architecture for Sparse Sensor Networks, Ad Hoc Networks, vol. 1, no. 3, pp. 215-233,
Sept. 2003.
[6] M. Rahimi, H. Shah, G. Sukhatme, J. Heidemann, and D. Estrin, Studying the Feasibility of
Energy Harvesting in a Mobile Sensor Network, Proc. IEEE Intl. Conf. Robotics and
Automation, pp. 19- 24, May 2003.
[7] L. Hu and D. Evans, Localization for Mobile Sensor Networks, Proc. ACM MobiCom,
Sept. 2004.
[8] T. Melodia, D. Pompili, V.C. Gungor, and I.F. Akyildiz, Communication and Coordination in
Wireless Sensor and Actor Networks, IEEE Trans. Mobile Computing, vol. 6, no. 10, pp. 1116-
1129, Oct. 2007.
[9] J. Li, J. Jannotti, D.D. Couto, D. Karger, and R. Morris, A Scalable Location Service for
Geographic Ad Hoc Routing, Proc. ACM MobiCom, pp. 120-30, 2000.
[10] S.M. Das, H. Pucha, and Y.C. Hu, Performance Comparison of Scalable Location Services
for Geographic Ad Hoc Routing, Proc. IEEE INFOCOM, Mar. 2005.
[11] K. Seada, M. Zuniga, A. Helmy, and B. Krishnamachari, Energy- Efficient Forwarding

Strategies for Geographic Routing in Lossy Wireless Sensor Networks, Proc. ACM Conf.
Embedded Networked Sensor Systems (SENSYS), Nov. 2004.
[12] M. Rossi and M. Zorzi, Cost Efficient Localized Geographical Forwarding Strategies for
Wireless Sensor Networks, Proc. Tyrrhenian Intl Workshop Digital Comm. (TIWDC 05), July
2005.
[13] J.A. Stankovic, T.F. Abdelzaher, C. Lu, L. Sha, and J. Hou, Real- Time Communication
and Coordination in Embedded Sensor Networks, Proc. IEEE, vol. 91, no. 7, pp. 1002-1022,
July 2003.
[14] R. Vedantham, Z. Zhuang, and R. Sivakumar, Hazard Avoidance in Wireless Sensor and
Actor Networks, Computer Comm., vol. 29, nos. 13/14, pp. 2578-2598, Aug. 2006.
[15] R. Vedantham, Z. Zhuang, and R. Sivakumar, Mutual Exclusion in Wireless Sensor and
Actor Networks, Proc. IEEE Conf. Sensor, Mesh and Ad Hoc Comm. and Networks (SECON),
Sept. 2006.
[16] A. Durresi, V. Paruchuri, and L. Barolli, Delay-Energy Aware Routing Protocol for Sensor
and Actor Networks, Proc. Intl. Conf. Parallel and Distributed Systems, vol. 1, pp. 292-298,
July 2005.
[17] T. He, J. Stankovic, C. Lu, and T. Abdelzaher, SPEED: A Real- Time Routing Protocol for
Sensor Networks, Proc. IEEE Intl. Conf. Distributed Computing Systems (ICDCS), pp. 46-55,
May 2003.
[18] E. Felemban, C.-G. Lee, E. Ekici, R. Boder, and S. Vural, Probabilistic QoS Guarantee in
Reliability and Timeliness Domains in Wireless Sensor Networks, Proc. IEEE INFOCOM, Mar.
2005.
[19] T. Melodia, D. Pompili, and I.F. Akyildiz, On the Interdependence of Distributed Topology
Control and Geographical Routing in Ad Hoc and Sensor Networks, J. Selected Areas Comm.,
vol. 23, no. 3, pp. 520-532, Mar. 2005.
[20] F. Aurenhammer, Voronoi DiagramsA Survey of a Fundamental Geometric Data

Structure, ACM Computing Surveys, vol. 23, pp. 345-405, 1991.
[21] S. Meguerdichian, F. Koushanfar, M. Potkonjak, and M. Srivastava, Coverage Problems in

Wireless Ad-Hoc Sensor Networks, Proc. IEEE INFOCOM, Apr. 2001.
[22] S. Meguerdichian, F. Koushanfar, G. Qu, and M. Potkonjak, Exposure in Wireless Ad-Hoc

Sensor Networks, Proc. ACM MobiCom, pp. 139-150, 2001.
[23] S. Megerian, F. Koushanfar, M. Potkonjak, and M. Srivastava, Worst and Best-Case

Coverage in Sensor Networks, IEEE Trans. Mobile Computing, vol. 4, no. 1, pp. 84-92,
Jan./Feb. 2005.
[24] I. Stojmenovic, A.P. Ruhil, and D.K. Lobiyal, Voronoi Diagram and Convex Hull Based
Geocasting and Routing in Wireless Networks, Wiley Wireless Comm. and Mobile Computing,
vol. 6, pp. 247-258, 2006.
[25] S. Tilak, V. Kolar, N.B. Abu-Ghazaleh, and K.-D. Kang, Dynamic Localization Control for
Mobile Sensor Networks, Proc. IEEE Intl Performance Computing and Comm. Conf. (IPCCC),
Apr. 2005.
[26] A. Deshpande and S. Madden, Mauvedb: Supporting Model- Based User Views in
Database Systems, Proc. ACM SIGMOD, pp. 73-84, 2006.
[27] R. Olfati-Saber, Distributed Tracking for Mobile Sensor Networks with Information-
Driven Mobility, Proc. Am. Control Conf., July 2007.
[28] A. Ahmad, M. Gani, and F. Yang, Decentralized Robust Kalman Filtering for Uncertain
Stochastic Systems over Heterogeneous Sensor Networks, Signal Processing, vol. 88, no. 8, pp.
1919-1928, 2008.
[29] H. Medeiros, J. Park, and A. Kak, Distributed Object Tracking Using a Cluster-Based
Kalman Filter in Wireless Camera Networks, IEEE J. Selected Topics in Signal Processing, vol.
2, no. 4, pp. 448-463, Aug. 2008.
[30] I.N. Psaromiligkos and S.N. Batalama, Recursive Short-Data- Record Estimation of AV
and MMSE/MVDR Linear Filters for DS-CDMA Antenna Array Systems, IEEE Trans. Comm.,
vol. 52, no. 1, pp. 136-148, Aug. 2004.

Abstract

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Abstract

Hochgeladen von

Copyright:

Verfügbare Formate

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

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

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

movementTrace ON,OFF OFF

Errproc UniformErrorProc OFF

toraDebug ON,OFF OFF