Abstract Additional

Mobile ad-hoc networks pose real difficulty in finding the multihop shortest paths because of
continuous changing positions of the nodes. Traditional ad-hoc routing protocols are proposed
to find multi-hop routes based on shortest path routing algorithms, which cannot effectively
adapt to time-varying radio links and network topologies of Ad-hoc networks. In this paper
we proposed an enhanced routing algorithm, which uses probabilistic approach for the
stability of the neighboring nodes in finding and maintaining the routing paths in Ad-hoc
networks. The probability of a node being stable in the path is modeled by queuing theory,
where the stability of a node is measured by number of packets arrived at a node and the
number of packets being serviced by the node per unit time.
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by
mobile nodes in an ad hoc network and other wireless ad hoc network. AODV enables
dynamic, multihop, self-starting routing for all participating mobile nodes on demand and
maintain ad hoc network. AODV allows mobile nodes to find routes quickly for new
destinations nodes, and does not require nodes to maintain routes to destinations that are not
in active communication. AODV allows mobile nodes to respond to link breakages and
changes in network topology in a timely manner. The operation of AODV is loop-free

DSR vs AODV

Dynamic Source Routing (DSR) and AdHoc On Demand Distance Vector Routing (AODV)
are both routing protocols for wireless mesh/ad hoc networks. Both the protocols employ
different mechanisms that result in varied performance levels. DSR and AODV can be
compared and evaluated based on the packet delivery ratio, normalized MAC load,
normalized routing load, and average end-to-end delay by altering the number of sources,
speed, and pause time.
AODV Ad hoc on-demand distance vector enables self starting, multihop, and dynamic
routing for mobile wireless ad hoc networks. AODV discovers paths without source routing
and maintains table instead of route cache. It is loop free using destination sequence numbers
and mobile nodes to respond to link breakages, changes in network topology in a timely
manner. DSR (Dynamic Source Routing) is on-demand, simple and efficient routing protocol
for multi-hop wireless ad hoc networks of mobile nodes. DSR uses source routing and
protocol composed of two main mechanisms-Route Discovery and Route Maintenance,
which works together entirely, on demand. The protocol allows multiple routes to destination,
loop-free routing, support for unidirectional links, use of only soft state In routing, rapid
discovery when routes in the network change, designed for mobile ad hoc networks of up to
about two hundred nodes and to work well even with high rates of mobility. DSR and AODV
both belong to the category of flat routing protocols, in which all nodes are assigned the same
functionalities. Flat routing protocols work well for small networks containing a few hundred

nodes; however, their performance degrades rapidly as the network grows because of the
routing overhead.
Both DSR and AODV are demand-driven protocols which form a route on demand when a
transmitting computer desires a route. The main difference between DSR and AODV is the
source routing feature. The DSR is based on source routing in which all the routing
information such as is maintained at the mobile nodes. The DSR computes the routes and also
updates them. The source routing is a technique in which the packet sender identifies the
entire sequence of the node into which the packet has to pass through. The packet sender lists
the route in the packets header so that the next node to which the packet has to be transmitted
can be identified by the address on the way to the destination host. The AODV uses a
combination of a DSR and DSDV mechanism. It uses the route discovery and route
maintenance from a DSR and hop-by-hop routing, periodic advertisements, sequence numbers
from DSDV. The AODV easily overcomes the counting to infinity and Bellman Ford
problems, and it also provides quick convergence whenever the ad hoc network topology is
altered.

When DSR and AODV are analyzed using a packet delivery ratio parameter by varying the
paused time in the intervals of 0, 10, 20, 40, 100, the results obtained for both on demand
routing protocols look similar.

The normalized routing load is analyzed for both protocols by varying paused times. The
values for the DSR protocol were less as compared to the AODV which show fairly stable
results even after increasing the number of sources. If normalized routing load is stable, the
protocol is considered to be scalable. The routing overhead for AODV is mainly from the
route requests. DSR finds the route in the cache as a result of aggressive caching. This helps
to avoid a frequent route discovery process in DSR thereby decreasing the routing overhead
for DSR when compared to AODV.

The normalized MAC load is analyzed by varying different paused times. The values for
AODV is less when compared to DSR when analyzed for lower paused times.

When it comes to performance comparison between the two protocols, the cache staleness and
high MAC overhead degrade the performance of DSR in high mobility scenarios. In lowermobility scenarios, the performance of DSR is better than AODV as the route is always found
quickly in cache avoiding the route discovery process.

Summary:
1. DSR has less routing overhead than AODV.

2. AODV has less normalized MAC overhead than DSR.

3. DSR is based on a source routing mechanism whereas AODV uses a combination of DSR
and DSDV mechanisms.

4. AODV has better performance than DSR in higher-mobility scenarios.

5. DSR has less frequent route discovery processes than AODV.

Comparison Table

Report on Present Investigation

3.1 Project Scheduling

The project schedule is the tool that communicates what work needs to be performed, which
resources of the organization will perform the work and the timeframes in which that work
needs to be performed. The project schedule should reflect all of the work associated with
delivering the project on time. Without a full and complete schedule, the project manager will
be unable to communicate the complete effort, in terms of cost and resources, necessary to
deliver the project.
3.1.1 Project organization
We will have a small team; hence we use a flat team structure of peers, with one person
having an additional role of project manager. Following table gives the

Table 3.1 Project Organization

Name

Role

Group member 1

Project Leader

Group member 2

Supervisor

Group member 2

Developer

organization:

3.1.3 Gantt Chart

A Gantt chart is a type of bar chart, which illustrates a project schedule. Gantt chart
illustrates the start and finish dates of the terminal elements and summary elements of a
project. Terminal elements and summary elements comprise the work breakdown
structure of the project. A Gantt chart is helpful when monitoring a projects progress.

Table 3.2 Gantt chart

Sr.
Task
No

Start Date

Duratio
n
(days)

Finish
Date

Deciding domain of the

8/11/2014
project

8/13/2014

Deciding project

8/14/2014

8/20/2014

Requirement gathering

8/21/2014

8/26/2014

Requirement analysis

8/27/2014

9/2/2014

Risk analysis

9/3/2014

9/9/2014

Abstract

9/10/2014

9/15/2014

Introduction

9/16/2014

9/22/2014

Review of Literature

9/23/2014

10/2/2014

10/3/2014

12

10/20/201
4

System design

10

Implementation of project

10/21/2014

95

3/2/2015

11

Testing

3/3/2015

15

3/23/2015

12

Deployment

3/24/2015

10

4/6/2015

13

Conclusion

4/7/2015

4/13/2015

Figure 3.2 Gantt chart

3.2 System Analysis
Systems analysis is the study of sets of interacting entities, including computer systems
analysis. It is the process of studying a procedure or business in order to identify its goals and
purposes and create systems and procedures that will achieve them in an efficient way.
This approach breaks systems analysis into 5 phases:

Scope Definition: which is denoting an instrument for observing, viewing, or

examining.

Problem analysis: Analyzing the problem that arises.

Requirements analysis: encompasses the conditions that need to be met.

Logical design: look at logical relationship among the objects and

Decision analysis: where a decision is made.

3.2.1 Requirement analysis

Requirements analysis in systems engineering and software engineering, encompasses
those tasks that go into determining the needs or conditions to meet for a new or altered
product, taking account of the possibly conflicting requirements of the various

stakeholders, analyzing, documenting, validating and managing software or system

requirements.
Requirements analysis is critical to the success of a systems or software project. The
requirements should be documented, actionable, measurable, testable, traceable, related
to identified business needs or opportunities, and defined to a level of detail sufficient for
system design.
3.2.1.1 Functional Requirements:

1. Inputs to the system:

a) Source node
b) Destination node and
2. Outputs from the system:
a) Time to reach destination
b) Calculated path
c) Nodes visited
d) Nodes included in the path
e) Distance of calculated path
4. Computations performed:
a) Computing the time taken for each algorithm to reach the destination.
Computing the efficiency of AODV algorithm in its
I. Best case possibility
II. Worst case possibility and
III. Medium case possibility.

b) Timing & sync: Each entity consists of one individual algorithm. All entities will
start at the same time, and calculate their individual optimum path. The time to reach
the destination will be recorded for each entity.
c)

Total distance covered by the entity: This involves summing the

distances of all nodes which are included in the calculated path from source node
to destination node.
d) The system can be in the following modes:
a. Input State: In this state, the user will provide inputs to the system like:
I. Source Node
II. Destination Node
b. Computing State: In this state, the inputs provided by the user are applied
and the system computes the path in tandem with the specified inputs.
c. Output State: In this state, the system should display the outputs
with respect to each algorithm:
1. Time to reach the destination
2. Nodes included in the path
3. Total Nodes visited
4. Distance of calculated path.

3.2.1.2 Non-Functional Requirement:

1. Resource utilization:
Total resource utilization will not be more than 500 MB of Disk Space. System will use
less than 50% of the total CPU time when run on a 2.4 GHz machine under a certain
operating system.
2. Allowances for maintainability and enhancement:
In order to ensure that the system can be adapted in the future, following changes can be
anticipated for associated environments:

Congestion system in networks

Comparison of additional algorithms and simulation in 3D environment.

3. Allowances for reusability:

Code can be used for Packet Routing.
4. Minimum software and Hardware Requirements:
a. Operating System:
Windows 7 Service Pack 1 or above, Windows 8, Windows 8.1.
b. C P U :
Intel Pentium Processor with 2.4 GHz or above. OR AMD Athlon Processor with 2.4
GHz or above.

3.2.2 Risk analysis

Although a detailed project plan was devised, giving sufficient amount of time for the
different tasks under normal conditions, it was essential to consider several risks that
could hinder the project. The following table lists possible risk as well as suggested
solutions that could minimize their effects.
Table 3.3 Risk Analysis
Risk
Change

Probability
of

Requirements

Low

Unrealistic prediction
of time required for

The requirements will be reviewed and

adjusted throughout the project.
The plan will be reviewed throughout the

Medium

the task
Software Failures

Contingency Plan

project and buffer time is allocated to deal

with small delays.

Low

Ensure that the required Software is

available in more than one location.