INTRODUCTION

Wireless Sensor Networks (WSNs) consist of a great number of nodes with

limited computing, sensing, and wireless communication capabilities. These
networks have been used in a wide area of applications, such as health care, pollution
monitoring, and target tracking systems. In many applications, it is not possible to
recharge the limited energy of the sensor nodes’ on-board batteries, a limitation
which has motivated manufacturers to produce low energy consuming hardware
devices and researchers to propose energy-aware data collection protocols. By
making optimum use of this bounded energy of nodes, early energy depletion may be
avoided.
Compared with non-clustering protocols, clustering, in general,
mitigates energy dissipation due to collisions, idle listening, and overhearing. When
clusters are created, within every cluster, an exclusive time slot is assigned to each
node and thus collisions are avoided. Besides, a node does not need to be awake
during every Time- Division Multiple Access (TDMA) frame, but only at its specific
time slot because it knows when to transmit. This option prevents the energy
depletion caused by idle listening and overhearing. Therefore, clustering is an
energy-efficient solution for extending the network life cycle. In clustering
approaches, the large difference in the Amount of energy consumption by cluster
heads and that of other nodes is a great motivation for balancing the nodes’ workload
and thus avoiding the premature death of the sensor nodes.

This work considers such a WSN-assisted emergency navigation problem by

utilizing the sensor network infrastructure as a cyber-physical system. In this mobile
scenario, people are equipped with communicating devices like mobile phones that
can talk to the sensors. When emergencies happen and mobile users are trapped in
the field, the sensor network explores the emergencies and provides necessary
guidance information to the mobile users, so that the users can be eventually guided
to safe exits through ubiquitous interactions with sensors.
 Although many WSN-assisted emergency navigation methods have been
proposed almost all existing approaches equally regard the hazard levels of different
emergencies, different emergencies could occur concurrently with each
corresponding to a specific hazard level. Considering a field with poisonous gas
leakage, the hazard levels of emergencies are closely related to the poisonousness of
the leaked gas. For instance, chlorine gas is much more fatal than carbon monoxide
Furthermore, different sizes of leakage holes lead to different amounts of gas leakage
per unit time. Therefore, when planning emergency navigation paths, people should
be kept farther away from chlorine compared with carbon monoxide. A similar idea
has been elaborated in the field of chemical process safety the navigation approaches
without considering different hazard levels of emergencies may fail to provide
necessary protection in the navigation process.

MOTIVATION
As described, WSN consists of thousands of tiny sensor nodes or even more.
These nodes individually possess limited capabilities but collectively via
coordination they can perform many useful networking tasks for various applications
like disaster management, healthcare, habitat monitoring etc. WSN performs its tasks
in an unattended manner and each sensor node has limited battery capacity.
Transmission and reception of data consumes energy. Energy of every sensor node
keeps on deteriorating with time. A stage is reached when the energy of the whole
sensor network is exhausted and network dies down. So energy is the main constraint
regardless of the application area in a WSN. In a large scale WSN, the nodes which
are closer to the sink are always used for forwarding packets from distant nodes.
Energy holes are created near the sink and the sink becomes unreachable even as
many nodes in the network are still alive. As the sensor nodes are densely deployed
in a WSN, the physical environment tends to produce similar data in close by sensor
nodes and most of the data is more or less redundant. If sensor nodes take turns for
alternatively performing data collection, data processing and communication tasks
then the lifetime of the WSN can be improved.
 In a WSN, sink is usually a powerful device and fails very rarely. But
due to energy constraints and some other unavoidable issues, node failures are pretty
commonly encountered in WSN. Although for a densely deployed WSN, a single
nodes failure does not have affect much, yet when some individual nodes failure
creates an energy hole in the network, then it a effects the performance of the whole
WSN. Keeping in mind, the importance and widely growing applications of WSN,
we have decided to carry out work on this subject. We want to reduce the energy
consumption of the nodes for increasing the lifetime of WSN. Energy efficiency is
the most important metric for the design of an algorithm for data collection,
processing and communication.

Aim and Objective

• To propose a scheme that forms fixed and optimum number of equal sized
Dynamic rectangular zonal clusters.
• To propose formation of near zone, far zone and division of far zone into
sub-zones based on the zonal clusters.
• To propose selection of dual cluster heads based on the residual energy,
distance from BS and centrality among neighbors.
CHAPTER 2

LITERATURE SURVEY

Title: Impact of Network Load on the Performance of a Polling MAC With

Wireless Recharging of Nodes
Author: Mohammad shahnoor islam khan, jelena mi.i.,
Year: 2015

Description:
Wireless sensor networks (WSNs) are often expected to perform for
prolonged periods of time without human intervention. As one of the most frequent
reasons for maintenance is replacement or manual recharging of batteries, periodic
recharging of node batteries can significantly extend the WSN lifetime Recharging
may be accomplished using energy harvesting from the network surrounding, which
is unreliable since there is no guarantee that the environment will be capable of
supplying the required amount of energy when needed. Alternatively, node batteries
may be recharged through RF pulses emitted by the network coordinator or base
station which results in more predictable operation since the energy increment
provided by a single recharging pulse depends only on the attenuation of wireless
between the coordinator and the node.

Algorithm: Energy Harvesting Algorithm.

Advantages:
 The energy increment provided by a single recharging pulse depends only on
the attenuation of wireless signal between the coordinator and the node.
 Maintenance-free operation and the desired level of communications
performance.

Disadvantages:
 Unreliable power source.
Title: Wireless power transfer and applications to sensor networks
Author: Ligaungu Xi, Yi shi.
Year:2013

Description:
As wireless and portable mobile devices become pervasive, charging batteries for
these deviceshas become a critical problem. Existing battery charging technologies
are dominated by wired technology, which requires a wired power plug to be
connected to an electrical wall outlet. This article explores recent advances in
wireless power transfer (WPT), which achieves the same goal but without the hassle
of wires. WPT technologies are revolutionizing the way energy is transferred and
have the potential to make our lives truly “wireless.

Algorithm:

 Heuristic Algorithm
 Optimistic Algorithm

Advantages:
 Higher efficiency in WPT.
 Higher power transfer efficiency even under omni-direction, and not
requiring LOS.

Disadvantages:

 A limited lifetime due to battery constraint poses a performance bottleneck

and barrier for large scale deployment.
Title: A Generic Model for Optimizing Single-Hop Transmission Policy of
Replenishable Sensors
Author: Jing Lei, Roy Yates
Year: 2009
Description:

Wireless sensor networks have attracted a plethora of research efforts since recent
technological advances allow us to envision the future as a world embedded with
networked sensors. Active research has been conducted in the area of environmental
energy harvesting techniques . Although recent developments in this area can be
employed to replenish the power supply of sensor networks, energy management is
still an important issue since the replenishing rates are typically small and the
stochastic energy renewal process only provides a partial solution to the aggressive
power demands of a large-scale network.

Algorithm:

 Howard’s policy improvement algorithm

Advantages:

 The existence of optimal thresholds that maximize the average reward rate.
 The unconditional transmit-all policy, which transmits every message as long
as the energy storage is positive, optimal transmission policy, is to achieve
significant gains in the average reward rate.

Disadvantages:
 Power management is still a crucial issue for such networks due to the
uncertainty of stochastic replenishment.
 CHAPTER 3

SYSTEM ANLAYSIS

EXISTING SYSTEM:

 Existing distributed algorithms to aid navigation of a user through a

geographic area covered by sensors. The sensors sense the level of danger at
their locations and we use this information to find a safe path for the user
through the sensor field.
 Traditional distributed navigation algorithms rely upon flooding the whole
network with packets to find an optimal safe path. To reduce the
communication expense, we introduce the concept of a skeleton graph which
is a sparse subset of the true sensor network communication graph.
 Using skeleton graphs we show that it is possible to find approximate safe
paths with much lower communication cost. We give tight theoretical
guarantees on the quality of our approximation and by simulation, show the
effectiveness of our algorithms in realistic sensor network situations.
DISADVANTAGES OF EXISTING SYSTEM:

 Although many WSN-assisted emergency navigation methods have been

proposed almost all existing approaches equally regard the hazard levels of
different emergencies.
 Existing methods simply guide people to the nearest one for the sake of
timeliness, such strategy would probably guide a majority of people to the
same exit, which potentially causes extreme congestions at the exit and
significantly prolongs the emergency navigation time while leaving other
exits of low usages.

PROPOSED SYSTEM:

 We propose an iterative method to establish the hazard potential field by

sensor readings in a fully distributed manner.
 Based on the established hazard potential field, we next propose a path
selection method and theoretically prove that the selected paths guarantee
successful navigation and are optimal in terms of safety.
 We also propose a scheme to accelerate the establishment of the hazard
potential field, in order to achieve timely emergency navigation.
 The proposed protocol is based on equal sized static rectangular clusters that
divide the network into zones, the use of dual CHs within a cluster, optimum
CHs selection procedure and energy-efficient inter-cluster multi-hop
communication.
 First phase is known as the set-up phase that involves rectangular clusters
formation and formation of zones .dual CHs selection and selection of relay
nodes for forwarding data to the BS in the subsequent round.
 Second Phase Network assumptions, first order radio energy model, network
architecture, all the stages of the set-up phase i.e., formation of rectangular
clusters, formation of zones, CHs selection mechanism and relay nodes
selection mechanism.
ADVANTAGES OF PROPOSED SYSTEM:

 Emergencies of different hazard levels and exits with different evacuation

capabilities have considered.
 Fully distributed algorithm to provide users the safest navigation paths, as
well as an accelerated version that can significantly boost up the speed of the
navigation.
 SYSTEM STUDY

PRELIMINARY INVESTIGATION

The first and foremost strategy for development of a project starts from the
thought of designing a mail enabled platform for a small firm in which it is easy and
convenient of sending and receiving messages, there is a search engine ,address book
and also including some entertaining games. When it is approved by the organization
and our project guide the first activity, ie. preliminary investigation begins. The
activity has three parts:

 Request Clarification

 Feasibility Study

 Request Approval

Request Clarification

After the approval of the request to the organization and project guide,
with an investigation being considered, the project request must be examined to
determine precisely what the system requires. Here our project is basically meant for
users within the company whose systems can be interconnected by the Local Area
Network(LAN). In today’s busy schedule man need everything should be provided in
a readymade manner. So taking into consideration of the vastly use of the net in day
to day life, the corresponding development of the portal came into existence.

FEASIBILITY ANALYSIS

An important outcome of preliminary investigation is the determination that

the system request is feasible. This is possible only if it is feasible within limited
resource and time. The different feasibilities that have to be analyzed are

 Operational Feasibility
 Economic Feasibility
 Technical Feasibility
Operational Feasibility
Operational Feasibility deals with the study of prospects of the system to be
developed. This system operationally eliminates all the tensions of the Admin and
helps him in effectively tracking the project progress. This kind of automation will
surely reduce the time and energy, which previously consumed in manual work.
Based on the study, the system is proved to be operationally feasible.

Economic Feasibility

Economic Feasibility or Cost-benefit is an assessment of the economic

justification for a computer based project. As hardware was installed from the
beginning & for lots of purposes thus the cost on project of hardware is low. Since
the system is a network based, any number of employees connected to the LAN
within that organization can use this tool from at anytime. The Virtual Private
Network is to be developed using the existing resources of the organization. So the
project is economically feasible.

Technical Feasibility
According to Roger S. Pressman, Technical Feasibility is the assessment of
the technical resources of the organization. The organization needs IBM compatible
machines with a graphical web browser connected to the Internet and Intranet. The
system is developed for platform Independent environment. Java Server Pages,
JavaScript, HTML, SQL server and WebLogic Server are used to develop the
system. The technical feasibility has been carried out. The system is technically
feasible for development and can be developed with the existing facility.

Request Approval

Not all request projects are desirable or feasible. Some organization receives
so many project requests from client users that only few of them are pursued.
However, those projects that are both feasible and desirable should be put into
schedule. After a project request is approved, it cost, priority, completion time and
personnel requirement is estimated and used to determine where to add it to any
project list. Truly speaking, the approval of those above factors, development works
can be launched.
 CHAPTER 4
SYSTEM SPECIFICATION

Hardware Requirement:
• Processor : Intel core processor
• Ram : 1GB
• Hard Disk : 160 GB

Software Requirement:
• Operating System : Ubuntu 9.0
• Coding Language : OTCL

Simulator:
• Package : NS 2 Simulator
NS-2

NS-2 [NS-2_wiki, NS-2_isi, Egea05, Sinha09, Yi08, Stevens09, Xue07] is

the abbreviation of Network simulator version two, which first been developed by
1989 using as the REAL network simulator. Now, NS-2 is supported by Defense
Advanced Research Projects Agency and National Science Foundation. NS-2 is a
discrete event network simulator built in Object-Oriented extension of Tool
Command Language and C++. People can run NS-2 simulator on Linux Operating
Systems or on Cygwin, which is a Unix-like environment and command-line
interface running on Windows. NS-2 is a popular non-specific network simulator can
used in both wire and wireless area. This simulator is open source and provides
online document.

Merits and Limitations

NS-2 [NS-2_wiki, NS-2_isi, Egea05, Sinha09, Yi08, Stevens09 and Xue07]

contains both merits and limitations when people use it to simulate WSNs. To the
merits, firstly as a non-specific network simulator, NS-2 can support a considerable
range of protocols in all layers. For example, the ad-hoc and WSN specific protocols
are provided by NS-2. Secondly, the open source model saves the cost of simulation,
and online documents allow the users easily to modify and improve the codes.
However, this simulator has some limitations. Firstly, people who want to use this
simulator need to familiar with writing scripting language and modeling technique;
the Tool Command Language is somewhat difficult to understand and write.
Secondly, sometimes using NS-2 is more complex and time-consuming than other
simulators to model a desired job. Thirdly, NS-2 provides a poor graphical support,
no Graphical User Interface (GUI) the users have to directly face to text commands
of the electronic devices. Fourthly, due to the continuing changing the code base, the
result may not be consistent, or contains bugs. In addition, since NS-2 is originally
targeted to IP networks but WSNs, there are some limitations when apply it to
simulate WSNs. Firstly, NS-2 can simulate the layered protocols but application
behaviors. However, the layered protocols and applications interact and cannot be
strictly separated in WSNs.
1. In Cygwin Command Prompt, to open the NAM Editor by using the
command “startxwin.bat”

Fig 7.1: To Open Cygwin Command Prompt

2. After giving the command, the NAM Editor command prompt will opened
like this.
 Fig 7.2: Opening NAM Window

3. Then type the command “cd c:” in NAM Editor command prompt, the
Cygwin will enter into the drive to process the data.

Fig 7.3: NAM Command Prompt

4. After entering into the c drive, it defines the path “cd cygwin/usr/local/ns-
allinone-2.28/ns-2.28 to search the executing file and get the result.
 Fig 7.4: Entering into NAM Drive

5. Now to run the executing file in the Cygwin Command Prompt.

NS (Version 2) is an open source network simulation tool. It is an object

oriented, discrete event driven simulator written in C++ and Otcl. The primary use of
NS is in network researches to simulate various types of wired/wireless local and
wide area networks; to implement network protocols such as TCP and UPD, traffic
source behavior such as FTP, Telnet, Web, CBR and VBR, router queue
management mechanism such as Drop Tail, RED and CBQ, routing algorithms such
as Dijkstra, and many more.

Ns2 is written in C++ and Otcl to separate the control and data path
implementations. The simulator supports a class hierarchy in C++ (the compiled
hierarchy) and a corresponding hierarchy within the Otcl interpreter (interpreted
hierarchy).

Agents, applications and traffic sources

The most common agents used in ns2 are UDP and TCP agents. In case of a
TCP agent, several types are available. The most common agent types are:

 Agent/TCP – a Tahoe TCP sender

 Agent/TCP/Reno – a Reno TCP sender
 Agent/TCP/Sack1 – TCP with selective acknowledgement

The most common applications and traffic sources provided by ns2 are:

 Application/FTP – produces bulk data that TCP will send

 Application/Traffic/CBR – generates packets with a constant bit rate
 Application/Traffic/Exponential – during off-periods, no traffic is sent.
During on-periods, packets are generated with a constant rate. The length of
both on and off-periods is exponentially distributed.
 Application/Traffic/Trace – Traffic is generated from a trace file, where the
sizes and interarrival times of the packets are defined.

Traffic Sinks
 If the information flows are to be terminated without processing, the udp and
tcp sources have to be connected with traffic sinks. A TCP sink is defined in the class
Agent/TCPSink and an UDP sink is defined in the class Agent/Null.

A UDP sink can be attached to n2 and connected with udp0 in the following
way:

set null [new Agent/Null]

$ns attach-agent $n2 $null

$ns connect $udp0 $null

A standard TCP sink that creates one acknowledgement per a received packet
can be attached to n3 and connected with tcp1 with the commands:

set sink [new Agent/Sink]

$ns attach-agent $n3 $sink

$ns connect $tcp1 $sink

There is also a shorter way to define connections between a source and the
destination with the command:

$ns create-connection <srctype><src><dsttype><dst><pktclass>

For example, to create a standard TCP connection between n1 and n3 with a class ID
of 1:

$ns create-connection TCP $n1 TCPSink $n3 1

One can very easily create several tcp-connections by using this command inside a
for-loop.

Links

Links are required to complete the topology. In ns2, the output queue of a
node is implemented as part of the link, so when creating links the user also has to
define the queue-type.
 Figure 7.1 Link in ns2

Figure 7.2 shows the construction of a simplex link in ns2. If a duplex-link is

created, two simplex links will be created, one for each direction. In the link, packet
is first enquired at the queue. After this, it is dropped, passed to the Null Agent and
freed there, or de queued and passed to the Delay object which simulates the link
delay. Finally, the TTL (time to live) value is calculated and updated.

Links can be created with the following command:

$ns duplex/simplex-link endpoint1 endpoint2 bandwidth delay queue-type

For example, to create a duplex-link with Drop Tail queue management between n0
and n2:

$ns duplex-link $n0 $n2 15Mb 10ms DropTail

Creating a simplex-link with RED queue management between n1 and n3:

$ns simplex-link $n1 $n3 10Mb 5ms RED

The values for bandwidth can be given as a pure number or by using

qualifiers k (kilo), M (mega), b (bit) and B (byte). The delay can also be expressed in
the same manner, by using m (milli) and u (mikro) as qualifiers. There are several
queue management algorithms implemented in ns2, but in this exercise only Drop
Tail and RED will be needed.
Simple Simulation Example

This section presents a simple NS simulation script and explains what each
line does. Example 3 is an OTcl script which creates the simple network
configuration and runs the simulation scenario in Figure 4. To run this simulation,
copy the code in Example 3 in a file named "ns-simple.tcl" and type "ns ns-
simple.tcl" at shell prompt.

Figure 7.2: A Simple Network Topology and Simulation Scenario

The network consists of 4 nodes (n0, n1, n2, n3) as shown in above figure.
The duplex links between n0 and n2, and n1 and n2 have 2 Mbps of bandwidth and
10 ms of delay. The duplex link between n2 and n3 has 1.7 Mbps of bandwidth and
20 ms of delay. Each node uses a DropTail queue, of which the maximum size is 10.
A "tcp" agent is attached to n0, and a connection is established to a tcp "sink" agent
attached to n3. As default, the maximum size of a packet that a "tcp" agent can
generate is 1KByte. A tcp "sink" agent generates and sends ACK packets to the
sender (tcp agent) and frees the received packets. A "udp" agent that is attached to n1
is connected to a "null" agent attached to n3. A "null" agent just frees the packets
received. A "ftp" and a "cbr" traffic generator are attached to "tcp" and "udp" agents
respectively, and the "cbr" is configured to generate 1 KByte packets at the rate of 1
Mbps. The "cbr" is set to start at 0.1 sec and stop at 4.5 sec, and "ftp" is set to start at
1.0 sec and stop at 4.0 sec.

Extending NS: Creating a new Agent

One can extend NS by adding new protocols. This section will discuss about
how a new agent can be created in NS using an example. The code in this section
implements some sort of simple ‘ping’ protocol. One node will send n user defined
number packets, one at a time at regular intervals, to another node which will return
the packet immediately. For each packet the sender will then calculate the round trip
time.
 CHAPTER 5
SYSTEM DESIGN

System Architecture

Fig: System Architecture

Illustration of situation-aware emergency navigation with a 2D WSN. The
emergency navigation paths when
(a) There are equal hazard levels of emergencies,
(b) The hazard level is higher at the red marked area and lower at the yellow marked
area,
(c) The two exits have equal evacuation capabilities, and
(d) One exit has higher evacuation capability than the other.
 To address the above issues, in this paper, we present SEND, a situation-
aware emergency navigation algorithm, which take the hazard levels of emergencies
and the evacuation capabilities of exits into a count and provides the mobile users the
safest navigation paths accordingly. Motivated by the fact that the natural gradients
of some physical quantities always follows a natural diffusion law, e.g., water always
flows from the place with a higher gravity potential to that with a lower gravity
potential, we thus propose to model the hazard levels of emergencies and the
evacuation capabilities of exits as hazard potentials with positive and negative
values, respectively. Then we establish a hazard potential field in the network, which
is theoretically free of local minima. By guiding users following the descend gradient
of the hazard potential field, our method can thereby achieve guaranteed success of
navigation and provide optimal safety to users.
 PROCESS FLOW DIAGRAM

Node strucutre Diagram

 FLOW CHART

1. The DFD is also called as bubble chart. It is a simple graphical formalism that
can be used to represent a system in terms of input data to the system, various
processing carried out on this data, and the output data is generated by this
system.
2. The data flow diagram (DFD) is one of the most important modeling tools. It
is used to model the system components. These components are the system
process, the data used by the process, an external entity that interacts with the
system and the information flows in the system.
3. DFD shows how the information moves through the system and how it is
modified by a series of transformations. It is a graphical technique that
depicts information flow and the transformations that are applied as data
moves from input to output.
4. DFD is also known as bubble chart. A DFD may be used to represent a
system at any level of abstraction. DFD may be partitioned into levels that
represent increasing information flow and functional detail.
MAC PARAMETERS
 CHAPTER 8
SYSTEM TESTING
System Testing

 Ns Traffic.tcl
in ns-2.28/tcl/ex: a simple demo to illustrate link failure and recovery; no
dynamic routing is done to heal the failure.
 Ns Traffic-avg.tcl
in ns-2.28/tcl/ex: a dynamic routing demo.
 Ns Main.tcl
in ns-2.28/tcl/ex: Neighbor node through two equal cost routes.
Broadcasting Routing (HSRP)

 nsmcast.tcl
in ns-2/tcl/ex: a multicast routing demo. Comments in mcast.txt.
 nscmcast.tcl
in ns-2/tcl/ex/newmcast: centralized multicast computation for use in
``session-level'' simulations. Instead of using join messages and implementing
multicast routing protocols in the individual routers, the multicast routing
tables are implemented in a centralized fashion for the entire topology. PIM
sparse mode shared trees and source-specific trees are supported. Comments
in cmcast.txt.
nscmcast-spt.tcl
uses source-specific trees.
ns cmcast-100.tcl
creates a topology of 100 nodes and 950 edges. 10 members join the multicast
group. One sender sends for 90 seconds.
 ns detailed*.tcl
in ns-2/tcl/ex/newmcast: Dense Mode protocol that adapts to network changes
and works with LAN topologies (LANs created by the multi-link method).
Note that this is the recommended version of the dense mode protocol in ns.
Comments in detailedDM.txt.
 ns traffic*.tcl
in ns-2/tcl/ex/traffic*.tcl: multicast routing demos to illustrate the use of
Centralized multicast and the dense mode protocols. Comments in mcast.txt
To validate the Node Structure and Position
for Each node.If the transmission node to
control for CH to CH.
Transport protocols (UDP, TCP, RTP):

 basic TCP behavior (test-suite-traffic.tcl, test-suite-v1{,a}.tcl)

 Tahoe, Reno, New-Reno, and SACK TCP under different losses (test-suite-
tcpVariants.tcl)
 FACK TCP (limited validation in test-suite-tcpVariants.tcl)
 TCP vegas (test-suite-vegas-v1.tcl)
 CH TCP (test-suite-conn.tcl)
 SACK TCP (test-suite-sack{,-v1,v1a})
 RTP (in test-suite-friendly.tcl, not yet added to "validate")

Routing:

 algorithmic routing (test-suite-HSRP- algo-routing)

 lan routing and broadcast (test-suite-lan.tcl)
 manual routing (test-suite-manual-routing.tcl)
 centralized multicast, DM multicast, not detailedDM, not multicast over LAN
(test-suite-mcast.tcl)
 routing dynamics (test-suite-routed.tcl)
 mixed-mode session-levels simulation (test-suite-mixmode.tcl)
  session-level simulation (test-suite-session.tcl)

Router Mechanisms (scheduling, Sleep and awakequeue management, admissions

control, etc.):

 several queue scheduling algorithms: FQ (Fair Queueing), SFQ (Stochastic

Fair Queuing), DRR (Deficit Round Robin), FIFO (with drop-tail and RED
queue management) (test-suite-schedule.tcl)
 CBQ (both in v1 and v2 mode) (test-stuite-cbq{,-v1,-v1a})
 RED queue management (test-suite-red{,-v1,-v1a})
 ECN behavior (and TCP interactions) (test-suite-ecn.tcl)

Link-layer mechanisms:

 LANs, with TDMA/CD MAC protocols (in test-suite-lan.tcl)

 snoop

Other:

 Error Modules (e.g., in test-suite-ecn.tcl, test-suite-tcp-init-win.tcl, test-suite-

session.tcl, and test-suite-srm.tcl)

Protocols and modules in the core but not validated include:

 FACK and ASYM TCP

 RTCP
 RTP
 LANs with TDMA/CA MAC protocols (tcl/ex/mac-test.tcl), with
MultihopMac (mac-multihop.cc), with 802.11 (mac-802_11.cc)
 RLM (Receiver Layered Multicast) (tcl/ex/test-rlm.tcl)
 token bucket filters (tcl/ex/test-tbf.tcl)
 trace-generated sources (tcl/ex/tg.tcl)
 delay-adaptive receivers (tcl/ex/test-rcvr.tcl)
Unit testing
 Ns check1.tcl
in ns-2.28/tcl/ex: to illustrate link failure and recovery; no dynamic routing
is done to heal the failure.
 ns packetloss.tcl
 ns dsr.tr, conn.tr, TR1.tr, Mapsw.tr
in ns-2.28/tcl/ex: a dynamic routing and inter clustering routing .
 nsconnection.tcl
in ns-2.28/tcl/ex: equal cost multi-path routing through two equal cost
routes.
 ns check1.tcl
shows equal cost multi-path routing on a different dynamic topology.

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.

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

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.
 CHAPTER 6
SYSTEM IMPLEMENTATION

List of MODULES:

 Process of admin
 Network Process
 Navigating Destination
 Emergency Navigation

MODULES DESCRIPTION:

To determine the life of sensor network energy consumption is very important

because usually sensor nodes are driven by battery. Sensor network of energy
optimization is more difficult because it involved not only reduction of energy
devouring but also extends the life of the network as much possible. Every aspect of
design and operation is optimized can be done by energy awareness. Navigation has
been important issue in robotics fields, and computational geometry. Self-organized
network consisting more sensor nodes will prefer tobe conducted in a shared manner.
Emergency navigation helps to direct the trapped users to safe places and Connection
process is done by wi-fi medium. Cyber physical interaction is established by user’s
position estimation between users and sensor, path planning based on location details
can be stored in centralized control system, mapping and navigation to destination.

Centralized system stores the map details to determine shortest path. Sensor nodes
compute the hop count to find the shortest path according to the maps, thus the user
can escape from the danger area. Sensor node have three emergency process are
Network Formation, Destination Navigation, Emergency Navigation.

1. Process of admin
To navigate properly at the time of emergency, the admin should have the
whole knowledge about the area by preprocessing the environment as it needs to add
the block details and the exit -path to the central system so that it can guide correctly
when needed.
A. Network Organization

Node considers 100 sensor nodes that are homogeneous and are
deployed randomly in 100 m x 100 m field. The deployment can be uniform
as well as non-uniform. The BS is assumed to be placed at (150, 50) and
(300, 50) coordinates. A powerful BS capable of forwarding the data from the
CHs to the intended recipients is used.

B. Formation of Equal Size Clusters using Static Clustering

The total sensing area is partitioned into fixed number of equal sized
rectangular clusters by the BS. We present the case of nine clusters formed by
the BS to explain the protocol operation. ZBEEC offers reliable coverage and
connectivity. Equal sized clusters ensure uniform energy consumption among
the clusters and cluster formation is energy-efficient.
2. Network Process:
A connection is created within the user and sensor that also covers the neighbour
nodes each sensor are also connected with the mobile nodes of the user.
A. Formation of Network based on Clusters

The clusters form two zones known as near and far zone. The
zone near the BS is termed as near zone and rest of the field makes up
the far zone. Near zone has three and far zone has six clusters. Far
zone is further divided into two subzones. The zone based topology
balances the traffic across the zones, lends support for multi-hop
communication and prohibits formation of hot-spots. The near zone
restricts the number of transmissions above the threshold distance.

B. Cluster Head Selection Procedure

ZBEEC scheme is fully centralized and CHs are allotted by the BS.
The CH IDs are broadcasted by the BS and in the situation of being a match
between a sensor node and CH IDs, that node becomes a CH. Otherwise, the
node gets its time slot for data transmission. Each near zone cluster contains
two CHs, one main cluster head (MCH) and one auxiliary cluster head
(ACH).

3. Navigating Destination
At the time of emergency the user request the sensor to show him/her the
particular path for escaping. The centralized server then checks the source of the user
and determines the suitable path and shows it to the user using the maps.

4. Emergency Navigation
The wireless sensor networks continuously checks the environmental condition and if
it senses any kind of abnormality it immediately informs the user that are connected
with the sensor. An emergency situation is alarmed and soon the navigation maps are
shown to the users in their handheld devices to navigate them to the safe places.
The proper navigation path can be done by using the following ways:

1) The proper navigation path is not defined

2) To calculate the congestion that is not taken into account to avoid the hazardous.
3) Measurethe safety of a path is equal to Measure the hazard of a path is not possible
all the time.
4) Trust calculation time be high in navigation path
5)2D and 3D representation there is no proper and clear graphical and visualization
in navigation map.

If any emergency situation arises, the sensor networks send the information that are
needed to the users to guide them and to move them from the hazardous area. The
WSN provides them the necessary safety guide to the users. The proposed system,
SEND, provides the users a better way to avoid the hazardous area or to make them
possible to reach safe places while having the minimum congestion. Using the human
navigation is not as suitable as sensor navigation, because, human navigation as fast
as sensor navigation and at the first chance it could nothave detected the safest route.
SEND searches all the sub-optimal paths and suggest the most appropriate path for
the evacuation process.

With the Advantages of WSNtechnology, huge scale deployment of these networks

is getting added and further. These days the WSN are used into emergency
navigation system , when emergency occurs like geologic disasters wildfire hazards
and gas leakages and navigating people to safe exits while keeping them away from
emergencies. The wireless sensor networks provide the necessary information to the
users so user can escape safely using the sensor's navigation for that road map
navigation approach is Introduced. RMN approach Ain sensor navigation which will
use to connect road map and provide a safe path. Road map based navigation, forms
road map by connecting the center point around which routes revolves.
In this mobile scenario people are equipped with communicating devices like mobile
that can talk to the sensors. SEND is a situation aware emergency navigation, this
process have a main pattern to considering the effect of both danger levels of
emergencies and discharge capabilities ofexits.

Crowd sensing is an way to collecting a lot of samples of a phenomena of draw your

attention by distributing the across a sample amount of individuals. Navigation
application was interaction between sensor and user that will guide user in a safe path
through shortest path. people inside e the building are expected to be at once
navigated to suitable exits. Particularly, the emergency navigation paths are excepted
to be more distant away from hazards areas and all the people should be lead to exits
with more evacuation ability to perform. In terms of safety the emergency navigation
problem is more basically to find the optimum emergency navigation paths