Abstract

This research aims to modify an existing mobile ad-hoc network (MANET)

reactive routing protocol (AODV) into a hybrid protocol by introducing adaptive,

proactive behavior to improve its performance. Under our proposed scheme, route

maintenance decisions are based on predicted values of 'link-breakage times' (when

the next-hop node will move out of transmission range) obtained from a series of

position/velocity estimates of the next-hop node. These estimates are based on the

power level of the received MAC frames. If a link is about to break, proactive

discovery of new routes to all destinations using the next-hop node depends on the

history of traffic to that destination. We simulated (using thens2 simulator)

numerous test conditions using VBR and TCP traffic and compared

performance metrics for the original and modified versions of the protocol. We

were able to achieve a significant reduction in mean packet latency for VBR traffic

and a reduction in control overhead in TCP traffic, while incurring other small

penalties for both types of traffic. Also, a comparison of some performance metrics

for TCP and VBR traffic led us to conclude that slight modifications in TCP

can lead to its improved performance over MANETs.

Introduction

A wireless ad-hoc network is a collection of mobile/semi-mobile nodes with no

pre-established infrastructure, forming a temporary network. Each of the nodes has

a wireless interface and communicates with each other over either radio or

infrared. Laptop computers and personal digital assistants that communicate

directly with each other are some examples of nodes in an ad-hoc network. Nodes

in the ad- hoc network are often mobile, but can also consist of stationary nodes,

such as access points to the Internet. Semi mobile nodes can be used to deploy

relay points in areas where relay Figure 1 show a simple ad-hoc network with

three nodes. The outermost nodes are not within transmitter range of each other.

However the middle node can be used to forward packets between the outermost

nodes. The middle node is acting as a router and the three nodes have formed an

ad-hoc network.

Figure 1

An ad-hoc network uses no centralized administration. This is to be sure that the

network won’t collapse just because one of the mobile nodes moves out of

transmitter range of the others. Nodes should be able to enter/leave the network as

they wish. Because of the limited transmitter range of the nodes, multiple hops

may be needed to reach other nodes. Every node wishing to participate in an ad-

hoc network must be willing to forward packets for other nodes. Thus every node

acts both as a host and as a router. A node can be viewed as an abstract entity

consisting of a router and a set of affiliated mobile hosts. A router is an entity,

which, among other things runs a routing protocol. A mobile host is simply an IP-

addressable host/entity in the traditional sense. Ad-hoc networks are also capable

of handling topology changes and malfunctions in nodes. It is fixed through

network reconfiguration. For instance, if a node leaves the network and causes link

breakages, affected nodes can easily request new routes and the problem will be

solved. This will slightly increase the delay, but the network will still be

operational. Wireless ad-hoc networks take advantage of the nature of the wireless

communication medium. In other words, in a wired network the physical cabling is

done a priori restricting the connection topology of the nodes. This restriction is

not present in the wireless domain and, provided that two nodes are within

transmitter range of each other, an instantaneous link between them may form.

Figure 2

HOST

HOST

HOST

Router

Figure 3

Over the last few years ad-hoc networking has attracted a lot of research interest.

This has led to creation of a working group at the IETF that is focusing on mobile

ad-hoc networking, called MANET (MANET, 2002), (Corson, 1999). Figure 8.19

shows the relation of MANET to mobile IP and DHCP. While mobile IP and

DHCP handle the connection of mobile devices to a fixed infrastructure, MANET

comprises mobile routers, too. Mobile devices can be connected either directly

with an infrastructure using Mobile IP for mobility support and DHCP 331

Figure 8.19 MANETs and mobile IP as a source of many parameters, such as an

IP address. MANET research is responsible for developing protocols and

components to enable ad-hoc networking between mobile devices. It should be

noted that the separation of end system and router is only a logical separation.

Typically, mobile nodes in an Adhoc scenario comprise routing and end system

functionality. The reason for having a special section about ad-hoc networks

within a chapter about the network layer is that routing of data is one of the most

difficult issues in ad-hoc networks. Some examples for routing algorithms suited to

ad-hoc networks. NB: routing functions sometimes exist in layer 2, not just in the

network layer (layer 3) of the reference model. Bluetooth, for example, offers

forwarding/routing capabilities in layer 2 based on MAC addresses for ad-hoc

networks. One of the first ad-hoc wireless networks was the packet radio network

started by ARPA in 1973. It allowed up to 138 nodes in the ad-hoc network and

used IP packets for data transport. This made an easy connection possible to the

Arpanet, the starting point of today’s Internet. Twenty radio channels between

1718.4-1840 MHz were used offering 100 or 400 kbit/s. The system used DSSS

with 128 or 32 chips/bit. A variant of distance vector routing was used in this ad-

hoc network (Perlman, 1992). In this approach, each node sends a routing

advertisement every 7.5 s. These advertisements contain a neighbor table with a

list of link qualities to each neighbor. Each node updates the local routing table

according to the distance vector algorithm based on these advertisements.

Received packets also help to update the routing table. A sender now transmits a

packet to its first hop neighbor using the local neighbor table. Each node forwards

a packet received based on its own local neighbor table. Several enhancements to

this simple scheme are needed to avoid routing loops and to reflect the possibly

fast changing topology. The following sections discuss routing problems and

enhanced routing mechanisms for ad-hoc networks in more detail. Perkins (2001a)

comprises a collection of many routing protocols together with some initial

performance considerations.

Characteristics

Ad-hoc networks are often characterized by a dynamic topology due to the fact that

nodes change their physical location by moving around. This favors routing

protocols that dynamically discover routes over conventional routing algorithms

like distant vector and link state [23]. Another characteristic is that a host/node has

very limited CPU capacity, storage capacity, battery power and bandwidth, also

referred to as a “thin client”. This means that the power usage must be limited thus

leading to a limited transmitter range. The access media, the radio environment,

also has special characteristics that must be considered when designing protocols

for ad-hoc networks. One example of this may be unidirectional links. These links

arise when for example two nodes have different strength on their transmitters,

allowing only one of the host to hear the other, but can also arise from disturbances

from the surroundings. Multihop in a radio environment may result in an overall

transmit capacity gain and power gain, due to the squared relation between

coverage and required output power. By using multihop, nodes can transmit the

packets with a much lower output power. It is important to acknowledge the

properties or characteristics of mobile ad hoc networks (MANETs), since these

properties have a significant impact on the design of security protocols for

MANETs. Although these properties are detailed in various papers [8] [3] [9] [10],

security protocols that do not suit these characteristics are frequently published.

The thesis is therefore started by defining the characteristics of MANETs. The

security implications of the characteristics are discussed where applicable.

Network Infrastructure

There is no fixed or pre-existing infrastructure in an ad hoc network: all network

functionality (routing, security, network management etc.) is performed by the

nodes themselves. Due to the nodes’ limited transmission range, data

dissemination is achieved in a multi- hop fashion; nodes can therefore be

considered as hosts and routers. Although the lack of infrastructure opens a new

window of opportunity for attacks, the author believes the lack of infrastructure

can help to ensure the survivability of the network in a very hostile environment.

This holds true not only from a network security perspective, but also when the

users of the network are under physical attack. Ad hoc networks may be

spontaneously formed with no a priori knowledge of the physical location and

networking environment. Mantes’ lack of infrastructure thus makes it suitable for

various applications where conventional networks fall short. Some researchers

have already addressed security issues in hybrid ad hoc networks. Hybrid ad hoc

networks combine conventional network infrastructure with multi-hopping. This

derivative of ad hoc networks will find useful application where fixed

infrastructure can be extended through multi-hop networks or where the

functionality (and performance) of multi-hop networks can be enhanced by relying

on some infrastructure. The access point does not just control medium access, but

also acts as a bridge to other wireless or wired networks. Several wireless networks

may form one logical wireless network, so the access points together with the fixed

network in between can connect several wireless networks to form a larger

network beyond actual radio coverage

Figure 4

Typically, the design of infrastructure-based wireless networks is simpler because

most of the network functionality lies within the access point, whereas the

wireless clients can remain quite simple. This structure is reminiscent of switched

Ethernet or other star-based networks, where a central element (e.g., a switch)

controls network flow. This type of network can use different access schemes with

or without collision. Collisions may occur if medium access of the wireless nodes

and the access point is not coordinated. However, if only the access point controls

medium access, no collisions are possible. This setting may be useful for quality

of service guarantees such as minimum bandwidth for certain nodes. The access

point may poll the single wireless nodes to ensure the data rate. Infrastructure-

based networks lose some of the flexibility wireless networks can offer, e.g., they

cannot be used for disaster relief in cases where no infrastructure is left. Typical

cellular phone networks are infrastructure-based networks for a wide area . Also

satellite-based cellular phones have an infrastructure - the satellites. Infrastructure

does not necessarily imply a wired fixed network. Ad-hoc wireless networks,

however, do not need any infrastructure to work. Each node can communicate

directly with other nodes, so no access point con- trolling medium access is

necessary. Figure 2 shows two ad-hoc networks with three nodes each. Nodes

within an ad-hoc network can only communicate if they can reach each other

physically, i.e., if they are within each other’s radio range or if other nodes can

forward the message. Nodes from the two networks shown in Figure 2 cannot,

therefore, communicate with each other if they are not within the same radio

range. In ad-hoc networks, the complexity of each node is higher because every

node has to implement medium access mechanisms, mechanisms to handle hidden

or exposed terminal problems, and perhaps priority mechanisms, to pro- vide a

certain quality of service. This type of wireless network exhibits the greatest

possible flexibility as it is, for example, needed for unexpected meetings, quick

replacements of infrastructure or communication scenarios far away from any

infrastructure.

Figure 5

Clearly, the two basic variants of wireless networks (here especially WLANs),

infrastructure-based and ad-hoc, do not always come in their pure form. There are

networks that rely on access points and infrastructure for basic services (e.g.,

authentication of access, control of medium access for data with associated quality

of service, management functions), but that also allow for direct communication

between the wireless nodes. However, ad-hoc networks might only have selected

nodes with the capabilities of forwarding data. Most of the nodes have to connect

to such a special node first to transmit data if the receiver is out of their range.

From the three WLANs presented, IEEE 802.11and HiperLAN2 are typically

infrastructure-based networks, which additionally support ad-hoc networking.

However, many implementations only offer the basic infrastructure-based version.

The third WLAN, Bluetooth is a typical wireless ad-hoc network. Bluetooth

focuses precisely on spontaneous ad-hoc meetings or on the simple connection of

two or more devices without requiring the setup of an infrastructure.

Network Topology

Nodes in ad hoc networks may be mobile resulting in a dynamic, weakly

connected topology. Since node mobility is unrestricted, the topology may be

unpredictable. The net- work will however demonstrate global mobility patterns

which may not be completely random. The topology is weakly connected due to

transient, error-prone wireless connectivity. The users may therefore experience

unavailability of essential security services. Node mobility and wireless

connectivity allow nodes to spontaneously join and leave the network, which

makes the network amorphous. Security services must be able to scale seamlessly

with rapid changes in network density.

Self-Organization

MANETs cannot rely on any form of central administration or control; this is

essential to avoid a single point of attack [1]. A self-organized MANET cannot

rely on any form of offline trusted third party (TTP); the network can thus be

initialized by a distributed on-line TTP. A pure or fully self-organized MANET

does not rely on any form of TTP whatsoever , i.e. the on-line TTP is also

eliminated. Nodes will therefore only have compatible devices with the same

software installed. In the extreme case, the nodes will not even share a common set

of security system parameters. The lack of a TTP may force the end-users to

actively participate in the setup of security associations. A (fully) self-organized

MANET has some inherent security implications:

->Fully self-organized MANETs are “open” in nature: similar to the internet, any

user can join the network at random. Access control to applications will have to

be provided at the application layer with a varying degree of user interaction

->Each user will be its own authority domain, hence responsible for generating and

distributing its own keying material. As pointed out by Douceur any node can

generate more than one identity when there is no of-line TTP. It is thus clear that it

will be very difficult (if not impossible) to limit users to one and only one unique

identity in a (fully) self-organized setting.

->The network will always be vulnerable to the active insider adversary. In fact,

the Dolev-Yao adversary model is too restrictive, for example, it fails to capture

information an adversary may gain from detailed knowledge of the protocols in

use. An interesting topic for future research will be the adversary model in “open”

ad hoc networks.

-> It will be difficult to hold malicious nodes accountable for their actions, since

they can always rejoin the network under a different (new) identity.

Literature Survey

Impact of Node Mobility on MANET Routing Protocols Models

A Mobile Ad-Hoc Network (MANET) is a self-configuring network of mobile

nodes connected by wireless links to form an arbitrary topology without the use of

existing infrastructure. In this paper, we have studied the effects of various

mobility models on the performance of two routing protocols Dynamic Source

Routing (DSR-Reactive Protocol) and Destination-Sequenced Distance-Vector

(DSDV-Proactive Protocol). For experiment purposes, we have considered four

mobility scenarios: Random Waypoint, Group Mobility, Freeway and Manhattan

models. These four Mobility Models are selected to represent possibility of

practical application in future. Performance comparison has also been conducted

across varying node densities and number of hops. Experiment results illustrate

that performance of the routing protocol varies across different mobility models,

node densities and length of data paths. Empirical results illustrate that the

performance of a routing protocol varies widely across different mobility models

and hence the study results from one model cannot be applied to other model.

Hence we have to consider the mobility of an application while selecting a routing

protocol. DSR gives better performance for highly mobile networks than DSDV.

DSR is faster in discovering new route to the destination when the old route is

broken as it invokes route repair mechanism locally whereas in DSDV there is no

route repair mechanism. In DSDV, if no route is found to the destination, the

packets are dropped.

A Survey of QoS Routing Solutions for Mobile Ad Hoc Networks

This document offers an up-to-date survey of most major contributions to the pool

of QoS routing solutions for MANETs published in the period 1997-2006. We

include a thorough overview of QoS routing metrics, resources and factors

affecting performance and classify the protocols found in the literature. We also

summaries their operation and describe their interactions with the medium access

control (MAC) protocol, where applicable. This provides the reader with insight

into their differences and allows us to highlight trends in protocol design and

identify areas for future research. The majority of the solutions proposed in the

literature till now have focused on providing QoS based on two metrics:

throughput and delay. Of these, the more common is throughput. This is probably

because assured throughput is somewhat of a lowest common denominator

requirement; most voice or video applications require some level of guaranteed

throughput in addition to their other constraints. However, many other metrics are

also used to quantify QoS and in this work we cover most of them and provide

examples of their use. To some extent this is an historical limitation, since mobile

devices are becoming increasingly powerful and capable. However, it still holds

true that such devices generally have less computational power, less memory and a

limited (battery) power supply, compared to devices such as desktop computers

typically employed in wired networks. This factor has a major impact on the

provision of QoS assurances, since low memory capacity limits the amount of QoS

state that can be stored, necessitating more frequent updates, which incur greater

overhead. Additionally, QoS routing generally incurs a greater overhead than best-

effort routing in the first place, due to the extra information being disseminated.

These factors lead to a higher drain on mobile nodes' limited battery power supply.

Dynamic Source Routing in Ad Hoc Wireless Networks

An ad hoc network is a collection of wireless mobile hosts forming a temporary

network without the aid of any established infrastructure or centralized

administration. In such an environment, it may be necessary for one mobile host to

enlist the aid of other hosts in forwarding a packet to its destination, due to the

limited range of each mobile host’s wireless transmissions. This paper presents a

protocol for routing in ad hoc networks that uses dynamic source routing. Routing

protocols in conventional wired networks generally use either distance vector or

link state routing algorithms, both of which require periodic routing advertisements

to be broadcast by each router. In distance vector routing each router broadcasts to

each of its neighbor routers its view of the distance to all hosts, and each router

computes the shortest path to each host based on the information advertised by

each of its neighbors. In link state routing each router instead broadcasts to all

other routers in the network its view of the status of each of its adjacent network

links, and each router then computes the shortest distance to each host based on the

complete picture of the network formed from the most recent link information

from all routers. In addition to its use in wired networks, the basic distance vector

algorithm has also been adapted for routing in wireless ad hoc networks,

essentially treating each mobile host as a router. Finally, we are beginning

implementation of the protocol on notebook computers for use by students in an

academic environment.

QoS-Aware Routing Based on Bandwidth Estimation for Mobile Ad Hoc

Networks

We believe that such QoS support can be achieved by either finding a route to

satisfy the application requirements or offering network feedback to the application

when the requirements cannot be met. We propose a QoS-aware routing protocol

that incorporates an admission control scheme and a feedback scheme to meet the

QoS requirements of real-time applications. The novel part of this QoS-aware

routing protocol is the use of the approximate bandwidth estimation to react to

network traffic. Our approach implements these schemes by using two bandwidth

estimation methods to find the residual bandwidth available at each node to

support new streams. We simulate our QoS-aware routing protocol for nodes

running the IEEE 802.11medium access control. Results of our experiments show

that the packet delivery ratio increases greatly, and packet delay and energy

dissipation decrease significantly, while the overall end-to-end throughput is not

impacted, compared with routing protocols that do not provide QoS support. We

propose a QoS-aware routing protocol, which is based on residual bandwidth

estimation during route set up. Our QoS-aware routing protocol is built off AODV,

in which the routing table is used to forward packets, “Hello” messages are used to

detect broken routes and “Error” messages are used to inform upstream hosts about

a broken route. We explore two ways to perform bandwidth estimation, and we

incorporate both an adaptive feedback-based scheme and an admission control

scheme. The accurate measurement of the capacity of a multi-hop mobile network

is an open issue right now. Further study of the802.11 MAC layer’s behavior could

be helpful to understand this capacity issue. Also, in a real scenario, shadowing

will cause a node’s transmission range to vary, and it will not be the ideal circle

that is assumed here.

Performance Evaluation of MANET Routing Protocols under CBR and FTP

traffic classes

Understanding the performance of routing protocols in ad hoc networks is a key

feature to determine which routing protocol is best suited for which type of

network scenario. From the literature survey it was found that there is a lot of work

done on evaluating the performance [3] of various MANET routing protocols for

CBR traffic but there is very little work done for variable bit rate like FTP,

TELNET type of traffic.So, in this paper it is proposed to evaluate and analyze the

performance of proactive (WRP) and reactive (AODV, DSR) routing protocols

based on traffic generators like FTP under different network scenarios like pause

time, offered load (i.e. number of source destination pairs), node speed. For CBR

traffic, we have presented 3 different scenarios, varying pause time, offered load

(i.e. number of source destination pairs) and average node speed.In pause time

scenario, performance analysis shows that AODV performs better than DSR and

WRP in terms of packet delivery ratio, throughput and routing message overhead.

WRP exhibits the worst performance in terms of packet delivery ratio, throughput

and routing message overhead. But for average end-to-end delay WRP shows the

best performance while DSR shows worst performance in terms of average end-to-

end delay. we have simulated the AODV, DSR and WRP routing protocols and

evaluated the performance under CBR and FTP traffics. Performance of each

routing protocols evaluated using a detailed simulation-based analysis.

Performance metrics considered are packet delivery ratio.

Project Introduction

A Mobile Ad Hoc Network generally does not have any infrastructure and each

mobile host also acts as a router. Communication between various hosts

takes place through wireless links. Direct communication can take place between

hosts that are within the communication range of the antennas of the respective

hosts; otherwise, communication is achieved through multi-hop routing. Figure 1

represents a MANET of 3 nodes. Node2 can communicate directly with Node 1

and Node 3. But any communication between Nodes 1 and 3 must be routed

through Node 2.

Figure 1

The following are the salient features of MANETs:

Dynamic Topologies: All nodes in the MANET generally move with

varying velocities, and hence the network topology changes dynamically. Frequent

link breaks are quite common. New nodes may join the network or existing nodes

can leave the network. The dynamic changes in the network topology pose the

biggest challenge to routing in Ad Hoc Networks.

Asymmetrical Communication: Each node in the Ad Hoc Network may

have antennas of different characteristics, and hence symmetrical, bi-

directional communication over the same link is not always possible. In some

cases, only unidirectional communication is possible

Bandwidth limitations: Since the nodes communicate via wireless links, the

realized throughput in these networks when compared to a wired network of

similar size is quite small. The relatively lower capacity of the wireless links does

not facilitate transmission of delay-constrained traffic (real-time or

multimedia traffic). Moreover, the wireless links are quite error-prone, which

may further degrade throughput due to upper layer retransmissions, etc.

Energy limitations: The nodes in the MANET are generally battery

operated. Hence, energy conservation techniques and energy-aware routing in

MANETs become necessary.

/Existing routing protocols in wired networks (both link state and distance vector)

are not suitable for MANETs. These routing protocols distribute topological

information across the network to update other nodes of topological changes. This

mechanism is not suitable in MANETs, because there are frequent topological

changes as the nodes move randomly causing frequent link breakages.

In the experimental results illustrate that performance of the routing protocol

AODV varies across different random mobility models: Random Waypoint,

Random Walk with Reflections and Random Walk with Wrapping. The

performances of latest three mobility models have been evaluated in [12] with

AODV routing protocol. The results show that Random Waypoint Model is the

best model which outperforms both Random Walk Model and Random Direction

Model in both scenarios. The results indicate that Random Waypoint produces the

highest throughput but the throughput of the Random Walk Model and Random

Direction drastically falls over a period of time.

Existing System

The existing routing protocols in MANETs can be classified into two

categories: (1)Table-driven routing protocols, and (2) On-demand routing

protocols. Fig 2 shows the classification along with some examples of existing

MANET protocols.

Figure 2

Table Driven or Proactive Protocols Table-driven protocols (proactive

protocols) generate frequent updates of network topology information to

maintain a consistent view of the network at all nodes. These nodes are required to

maintain tables containing topology information, so that any node wishing to

communicate with any other node may do so by computing a route to the

destination node from the table. It is fairly expensive in terms of table size and

control overhead to maintain a table of topological information of all nodes.

The chief disadvantage of this method is that the nodes may be maintaining

topological information about nodes with which it may never communicate.

Destination Sequenced Distance Vector Routing Destination-Sequenced

Distance-Vector (DSDV)

Routing is based on the classical Bellman-Ford routing scheme. DSDV,

unlike traditional distance vector protocols, guarantees loop-freedom by tagging

each route table entry with a sequence number to order the routing information.

Each node maintains a routing table with all available destinations along with

information like next hop, the number of hops to reach to the destination, sequence

number of the destination originated by the destination node, etc. DSDV uses both

periodic and triggered routing updates to maintain table consistency. Triggered

routing updates are used when network topology changes are detected , so that

routing information is propagated as quickly as possible. Routing table updates can

be of two types - "full dump" and “incremental”. “Full dump” packets carry

all available routing information and may require multiple network protocol

data units (NPDU);“incremental” packets carry only information changed since

the last full dump and should fit in one NPDU in order to decrease the amount of

traffic generated.

Dynamic Source Routing Dynamic Source Routing (DSR), as the name

suggests, is based on the concept of source routing. There are no periodic

routing advertisements; instead, routes are dynamically determined based on

cached information or on the result of a route discovery process. In source routing,

the sender of the packet specifies the complete sequence of the nodes that the

packet has to take. The sender explicitly lists this route in the packet’s

header, identifying each forwarding “hop” by the address of the next node to which

the packet must be sent on its way to the destination host. A key advantage of

source routing is that intermediate hops do not need to maintain routing

information in order to route the packet they receive, since the packets

themselves already contain all the necessary routing information. Unlike

conventional routing protocols, the DSR protocol does not periodically transmit

route advertisements, thereby reducing control overhead, particularly during

periods when little or no significant host movement is taking place. The DSR

protocol consists of two mechanisms: Route Discovery and Route Maintenance.

When a mobile node wants to send a packet to some destination, it first consults its

route cache for a non-expired route. If the node does not have such a route, it

will initiate route discovery by broadcasting a route request (RREQ) packet,

which contains the addresses of the source node and the destination, and a unique

sequence number “request id”, which is set by the source node. Each node in the

network maintains a list of (source address, request id) pair that it has recently

received from any host in order to detect duplicate route requests received.

Ad-hoc On-Demand Distance Vector Routing (AODV) is essentially a

combination of both DSR and DSDV. It borrows the conception of sequence

numbers from DSDV, plus the use of the on-demand mechanism of route

discovery and route maintenance from DSR. It is called a “pure on-demand route

acquisition system”; nodes that do not lie on active paths neither maintain any

routing information nor participate in any periodic routing table exchanges. It

is loop-free, self-starting, and scales to a large number of mobile nodes.

AODV Process Normal RREQ and RREP processing mechanism of AODV is as

follows: The source node S tries to send a packet to destination D. If S does not

know the next hop for D, then it broadcasts a route request message. The RREQ

message propagates in all directions to reach the destination D. the intermediate

nodes that receive the RREQ message forward the packet to all its one hop

adjacent nodes. If the destination, D, receives a RREQ message through a

node N, then it sends a RREP to S by forwarding it to N since N may contain

at least one routing table entry for S. On receiving the RREQ message through

different nodes, the destination D will send the RREP message through

different nodes and they may reach the source node through different possible

paths. At the end, the source node S will have different possible resolved

paths to select from based on defined criteria.

Proposed System

Standard AODV routing process broadcasts route request to all nodes. In the

proposed scheme, a table of nodes in a given neighborhood (one-hop nodes) is

maintained. When a message is transmitted, only a subset of nodes in each

neighborhood is allowed to transmit. The number of selected nodes can be varied

dynamically depending on the application and required quality of service. In this

proposed scheme, the parameters that are used are defined in Table 1. Each node in

the network will forward a route request message if and only if a condition based

on its neighborhood density at that instance is satisfied. The proposed scheme

minimizes network congestion due to redundant transmission. If the RREQ is

received from an intermediate node then there will be at least one possible path

which includes that node in its path list. Therefore, if only selected nodes

are allowed to forward the RREQ packet, then only these nodes will be

included in the path list. In this proposed scheme, the neighborhood density

of an intermediate node is considered as a criterion in RREQ forwarding

decision at intermediate node. It means that if the number of nodes in the

neighborhood is high, then the probability of any node transmitting will decrease

and hence reduces the transmission overhead. Random selection of nodes

from the neighborhood set increases the chance of full network coverage.

Greater savings could be achieve by using a range dependent technique to select

nodes for transmission but this can only be achieved at the cost of greater

complexity. In this proposed system we improve the performance of AODV

routing protocol using VBR traffic process, the VBR traffic models being able to

capture both the real data styles and various compression techniques are needed.

The content based approach to the modeling of VBR data streams is one of the

research directions aimed at solving this problem. The VBR coded data has a very

complicated structure. The previous attempts to characterize VBR data streams by

various stochastic models without understanding the nature of the coding process

have not been fully successful and have only limited usability. Such models

focused only on matching the trace statistics or queuing analysis. The introduction

of data content into the VBR data modeling allows us to create realistic VBR data

traffic based not only on global statistical parameters but also on the data style,

scene or object description. Since the particular data stream is a combination of

scene characteristic and coding algorithm specific mapping, it is desirable to

separate them by identifying the independent descriptor variables characterizing

the scene, frame, and objects.

Implementation & Methodology

SOFTWARE SPECIFICATIONS

1. OS : Linux (vmware)

2. Simulator : NS2

3. Language : Tcl/Tk

4. Graph : GNUplot

5. Protocol Design : CC

HARDWARE SPECIFICATIONS

1. Processor Type : Pentium IV

2. Processor Speed : 2.7GHz

3. RAM : 1GB

Overview of ns-2 simulation test bed

NS-2 is n event driven packet level network simulator developed as a part of

the VINT project (Virtual Internet Test bed).Version 1 of NS was developed in

1995 and with version 2 in 1996. The Ns-2 with C++/OTCL integration feature.

Version 2 included a scripting language called Object oriented Tcl (OTcl). It is an

open source software package available for both Windows 32 and Linux platforms.

NS-2 has many and expanding uses included.

To evaluate that performance of existing network protocols

To evaluate new network protocols before use.

To run large scale experiments not possible in real experiments

To simulate a variety of ip networks.

NS -2 is an object oriented discrete event simulator. Simulator maintains list of

events and executes one event after another. Single thread of control: no locking

or race conditions Back end is C++ event scheduler.

Protocols mostly

Fast to run, more control

Front end is OTCL

Creating scenarios, extensions to C++ protocols

fast to write and change

Characteristics of NS-2

NS-2 implementation the following features

Multicasting

Simulation of wireless networks

Terrestrial (cellular, Adhoc, GPRS, WLAN, BLUETOOTH), satellite

IEEE 802.11 can be simulated, Mobile IP and Ad hoc protocols such as DSR,

TORA, DSDV and AODV Routing

Software Tools used with NS-2

In the simulation, there are the two tools are used.

NAM(Network Animator)

xGraph

NAM (Network Animator)

NAM provides a visual interpretation of the network topology created. The

application was developed as part of the VINT project. Its feature is as follows.

Provides a visual interpretation of the network created

Can be executed directly from a Tcl script

Controls include play; stop fast forward, rewind, pause, a display speed

controller button and a packet monitor facility.

Presented information such as throughput, number packets on each link

X Graph

X- Graph is an X-Window application that includes:

Interactive plotting and graphing Animated and derivatives to use Graph in NS-2

the executable can be called within a TCL script. This will then load a graph

displaying the information visually displaying the information of the file produced

from the simulation. The output is a graph of size 800 x 400 displaying information

on the traffic flow and time.

Simulation tool

NS2 are often growing to include new protocols. LANs need to be updated

for new wired/wireless support. ns are an object oriented simulator, written in C++,

with an OTcl interpreter as a front-end. The simulator supports a class hierarchy in

C++ and a similar class hierarchy within the OTcl interpreter (also called the

interpreted hierarchy). The two hierarchies are closely related to each other; from

the user’s perspective, there is a one-to-one correspondence between classes in the

interpreted.

NS2 uses two languages because simulator has two different kinds of things it

needs to do. On one hand, detailed simulations of protocols require a systems

programming language which can efficiently manipulate bytes, packet headers, and

implement algorithms that run over large data sets. For these tasks run-time speed

is important and turn-around time (run simulation, find bug, fix bug, recompile, re-

run) is less important.

On the other hand, a large part of network research involves slightly varying

parameters or configurations, or quickly exploring a number of scenarios. In these

cases, iteration time (change the model and re-run) is more important. Since

configuration runs once (at the beginning of the simulation), run-time of this part

of the task is less important. Ns meets both of these needs with two languages, C++

and OTcl. C++ is fast to run but slower to change, making it suitable for detailed

protocol implementation. OTcl runs much slower but can be changed very quickly

(and interactively), making it ideal for simulation configuration. NS (via tclcl)

provides glue to make objects and variables appear on both languages.

Modules

Architecture model

Route discovery

Route switching mechanism

Resource State Maintenance

Performance evaluation

Architecture model

In the ns-2 802.11 code, a transmitted packet’s reception is conditional upon the

SINR being higher than the threshold for the particular modulation scheme that the

packet was transmitted with. However, both the standard, as well as commercial

WLAN cards also require the absolute signal power to be above a modulation

mode-specific threshold for reliable signal reception.

Random Way point

Each node stores the rate that was last used for transmission to each of its

neighbors with which it has communicated, as well as the numbers of contiguous

missed or received ACKs. Since the transmission rate is likely to change multiple

times per second, following the fluctuations due to shadowing, it is impractical to

report every change to the network layer protocols. Instead, the rate in use by each

packet is recorded, and the average rate is calculated in a sliding window.

Route discovery

In the newly proposed protocol, once a session being admitted by StAC has found

a suitable route and its CS neighbors have been tested during the SREQ/SREP

exchange (stage 2), a backup route for the session must be found.

Resource State Maintenance

StAC uses a source route header extension to carry a source node’s view of the

available residual capacity at the nodes on a session’s route. If, upon forwarding a

data packet, a node detects that the source’s view differs from its own estimate of

the residual capacity by a given amount, and no update has been sent to that source

node recently, an update packet is sent.

Performance evaluation

That StAC and StAC-backup are not multirate aware, and hence, a fixed 6 Mbps

BPSK mode transmission rate is assumed. Simulations of StAC-multirate and

StAC-multirate-backup employ the multirate MAC model described above.

Data Flow Diagram

VBR Trafficallocation

Yes

YES

Performanceevaluation

reachdestination

Path Establishment

RouteDiscovery

Send RREQ

Architecture model

NO Request discard

ano

Buy SmartDraw!- purchased copies print this document without a watermark .

Visit www.smartdraw.com or call 1-800-768-3729.

Conclusion and Future Enhancement

We presented a new framework of content based approach to modeling of VBR

data sources. This approach is based on the fact that typical data compression

algorithms such as MPEG-2 in order to encode the original data stream have

explored a variety of high-correlated features in both spatial and temporal scale.

Identification of various features descriptors and their influence on the final bit rate

is the key point in the content-based data modeling. We outlined the separation

principle which isolates the independent data features from their specific use

during the compression. Such separation allows us to accommodate both current

(MPEG-2) and future coding algorithms (e.g. regionbased, object-based or model-

based coding) into the same framework by specification of only algorithmic,

coding specific part of the model. The data feature part of the model could remain

the same. The classification of higher level features such as camera movement,

zooming, panning, etc.,In the future, by identifying and separating other

independent data features, we would like to accommodate new content-based data

coding techniques into the same framework. The proposed approach to VBR data

traffic modeling also has great synergy with recent work on content-based

image/data search and retrieval

AODV Process

//#include <ip.h>

#include <aodv/aodv.h>#include <aodv/aodv_packet.h>#include <random.h>#include <cmu-trace.h>//#include <energy-model.h>

#define max(a,b) ( (a) > (b) ? (a) : (b) )#define CURRENT_TIME Scheduler::instance().clock()

//#define DEBUG//#define ERROR

#ifdef DEBUGstatic int extra_route_reply = 0;static int limit_route_request = 0;static int route_request = 0;#endif

/* TCL Hooks*/

int hdr_aodv::offset_;static class AODVHeaderClass : public PacketHeaderClass {public: AODVHeaderClass() : PacketHeaderClass("PacketHeader/AODV", sizeof(hdr_all_aodv)) {

bind_offset(&hdr_aodv::offset_);}

} class_rtProtoAODV_hdr;

static class AODVclass : public TclClass {public: AODVclass() : TclClass("Agent/AODV") {} TclObject* create(int argc, const char*const* argv) { assert(argc == 5); //return (new AODV((nsaddr_t) atoi(argv[4])));

return (new AODV((nsaddr_t) Address::instance().str2addr(argv[4]))); }} class_rtProtoAODV;

intAODV::command(int argc, const char*const* argv) { if(argc == 2) { Tcl& tcl = Tcl::instance(); if(strncasecmp(argv[1], "id", 2) == 0) { tcl.resultf("%d", index); return TCL_OK;

} if(strncasecmp(argv[1], "start", 2) == 0) { btimer.handle((Event*) 0);

#ifndef AODV_LINK_LAYER_DETECTION htimer.handle((Event*) 0); ntimer.handle((Event*) 0);#endif // LINK LAYER DETECTION

rtimer.handle((Event*) 0); return TCL_OK; } } else if(argc == 3) { if(strcmp(argv[1], "index") == 0) { index = atoi(argv[2]); return TCL_OK; }

else if(strcmp(argv[1], "log-target") == 0 || strcmp(argv[1], "tracetarget") == 0) { logtarget = (Trace*) TclObject::lookup(argv[2]); if(logtarget == 0)

return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "drop-target") == 0) { int stat = rqueue.command(argc,argv); if (stat != TCL_OK) return stat; return Agent::command(argc, argv); } else if(strcmp(argv[1], "if-queue") == 0) { ifqueue = (PriQueue*) TclObject::lookup(argv[2]); if(ifqueue == 0)

return TCL_ERROR; return TCL_OK; } else if (strcmp(argv[1], "port-dmux") == 0) { dmux_ = (PortClassifier *)TclObject::lookup(argv[2]);

if (dmux_ == 0) {fprintf (stderr, "%s: %s lookup of %s failed\n", __FILE__,argv[1], argv[2]);return TCL_ERROR;

}return TCL_OK;

} } return Agent::command(argc, argv);}

/* Constructor*/

AODV::AODV(nsaddr_t id) : Agent(PT_AODV),

btimer(this), htimer(this), ntimer(this), rtimer(this), lrtimer(this), rqueue() {

index = id; seqno = 2; bid = 1;

/* Get Position Sundaresh k - Elysium Technologies*/xpos = 0.0;ypos = 0.0;zpos = 0.0;MobileNode *iNode;iEnergy = 0.0; LIST_INIT(&nbhead); LIST_INIT(&bihead);

logtarget = 0; ifqueue = 0;}

/* Timers*/

voidBroadcastTimer::handle(Event*) { agent->id_purge(); Scheduler::instance().schedule(this, &intr, BCAST_ID_SAVE);}

voidHelloTimer::handle(Event*) { agent->sendHello(); double interval = MinHelloInterval + ((MaxHelloInterval - MinHelloInterval) * Random::uniform()); assert(interval >= 0); Scheduler::instance().schedule(this, &intr, interval);}

voidNeighborTimer::handle(Event*) { agent->nb_purge(); Scheduler::instance().schedule(this, &intr, HELLO_INTERVAL);}

voidRouteCacheTimer::handle(Event*) { agent->rt_purge();#define FREQUENCY 0.5 // sec Scheduler::instance().schedule(this, &intr, FREQUENCY);}

voidLocalRepairTimer::handle(Event* p) { // SRD: 5/4/99aodv_rt_entry *rt;struct hdr_ip *ih = HDR_IP( (Packet *)p);

/* you get here after the timeout in a local repair attempt */ /* fprintf(stderr, "%s\n", __FUNCTION__); */

rt = agent->rtable.rt_lookup(ih->daddr());

if (rt && rt->rt_flags != RTF_UP) { // route is yet to be repaired // I will be conservative and bring down the route // and send route errors upstream. /* The following assert fails, not sure why */ /* assert (rt->rt_flags == RTF_IN_REPAIR); */

//rt->rt_seqno++; agent->rt_down(rt); // send RERR#ifdef DEBUG fprintf(stderr,"Node %d: Dst - %d, failed local repair\n",index, rt->rt_dst);#endif } Packet::free((Packet *)p);}

/* Broadcast ID Management Functions*/

voidAODV::id_insert(nsaddr_t id, u_int32_t bid) {BroadcastID *b = new BroadcastID(id, bid);

assert(b); b->expire = CURRENT_TIME + BCAST_ID_SAVE; LIST_INSERT_HEAD(&bihead, b, link);}

/* SRD */boolAODV::id_lookup(nsaddr_t id, u_int32_t bid) {BroadcastID *b = bihead.lh_first; // Search the list for a match of source and bid for( ; b; b = b->link.le_next) { if ((b->src == id) && (b->id == bid)) return true; } return false;}

voidAODV::id_purge() {BroadcastID *b = bihead.lh_first;BroadcastID *bn;

double now = CURRENT_TIME;

for(; b; b = bn) { bn = b->link.le_next; if(b->expire <= now) { LIST_REMOVE(b,link); delete b; } }}

/* Helper Functions*/

doubleAODV::PerHopTime(aodv_rt_entry *rt) {int num_non_zero = 0, i;double total_latency = 0.0;

if (!rt) return ((double) NODE_TRAVERSAL_TIME );

for (i=0; i < MAX_HISTORY; i++) { if (rt->rt_disc_latency[i] > 0.0) { num_non_zero++; total_latency += rt->rt_disc_latency[i]; } } if (num_non_zero > 0) return(total_latency / (double) num_non_zero); else return((double) NODE_TRAVERSAL_TIME);

}

/* Link Failure Management Functions*/

static voidaodv_rt_failed_callback(Packet *p, void *arg) { ((AODV*) arg)->rt_ll_failed(p);}

/* * This routine is invoked when the link-layer reports a route failed. */voidAODV::rt_ll_failed(Packet *p) {struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);aodv_rt_entry *rt;nsaddr_t broken_nbr = ch->next_hop_;

#ifndef AODV_LINK_LAYER_DETECTION drop(p, DROP_RTR_MAC_CALLBACK);

#else

/* * Non-data packets and Broadcast Packets can be dropped. */ if(! DATA_PACKET(ch->ptype()) || (u_int32_t) ih->daddr() == IP_BROADCAST) { drop(p, DROP_RTR_MAC_CALLBACK); return; } log_link_broke(p);

if((rt = rtable.rt_lookup(ih->daddr())) == 0) { drop(p, DROP_RTR_MAC_CALLBACK); return; } log_link_del(ch->next_hop_);

#ifdef AODV_LOCAL_REPAIR /* if the broken link is closer to the dest than source, attempt a local repair. Otherwise, bring down the route. */

if (ch->num_forwards() > rt->rt_hops) { local_rt_repair(rt, p); // local repair // retrieve all the packets in the ifq using this link, // queue the packets for which local repair is done, return; } else#endif // LOCAL REPAIR

{ drop(p, DROP_RTR_MAC_CALLBACK); // Do the same thing for other packets in the interface queue using the // broken link -Maheshwhile((p = ifqueue->filter(broken_nbr))) { drop(p, DROP_RTR_MAC_CALLBACK); } nb_delete(broken_nbr); }

#endif // LINK LAYER DETECTION}

voidAODV::handle_link_failure(nsaddr_t id) {aodv_rt_entry *rt, *rtn;Packet *rerr = Packet::alloc();struct hdr_aodv_error *re = HDR_AODV_ERROR(rerr);

re->DestCount = 0; for(rt = rtable.head(); rt; rt = rtn) { // for each rt entry rtn = rt->rt_link.le_next; if ((rt->rt_hops != INFINITY2) && (rt->rt_nexthop == id) ) { assert (rt->rt_flags == RTF_UP); assert((rt->rt_seqno%2) == 0); rt->rt_seqno++;

re->unreachable_dst[re->DestCount] = rt->rt_dst; re->unreachable_dst_seqno[re->DestCount] = rt->rt_seqno;#ifdef DEBUG fprintf(stderr, "%s(%f): %d\t(%d\t%u\t%d)\n", __FUNCTION__, CURRENT_TIME,

index, re->unreachable_dst[re->DestCount], re->unreachable_dst_seqno[re->DestCount], rt->rt_nexthop);

#endif // DEBUG re->DestCount += 1; rt_down(rt); } // remove the lost neighbor from all the precursor lists rt->pc_delete(id); }

if (re->DestCount > 0) {#ifdef DEBUG fprintf(stderr, "%s(%f): %d\tsending RERR...\n", __FUNCTION__, CURRENT_TIME, index);#endif // DEBUG sendError(rerr, false); } else { Packet::free(rerr); }}

voidAODV::local_rt_repair(aodv_rt_entry *rt, Packet *p) {#ifdef DEBUG fprintf(stderr,"%s: Dst - %d\n", __FUNCTION__, rt->rt_dst); #endif // Buffer the packet rqueue.enque(p);

// mark the route as under repair rt->rt_flags = RTF_IN_REPAIR;

sendRequest(rt->rt_dst);

// set up a timer interrupt Scheduler::instance().schedule(&lrtimer, p->copy(), rt->rt_req_timeout);}

voidAODV::rt_update(aodv_rt_entry *rt, u_int32_t seqnum, u_int16_t metric,

nsaddr_t nexthop, double expire_time) {

rt->rt_seqno = seqnum; rt->rt_hops = metric; rt->rt_flags = RTF_UP; rt->rt_nexthop = nexthop; rt->rt_expire = expire_time;}

voidAODV::rt_down(aodv_rt_entry *rt) { /*

* Make sure that you don't "down" a route more than once. */

if(rt->rt_flags == RTF_DOWN) { return; }

// assert (rt->rt_seqno%2); // is the seqno odd? rt->rt_last_hop_count = rt->rt_hops; rt->rt_hops = INFINITY2; rt->rt_flags = RTF_DOWN; rt->rt_nexthop = 0; rt->rt_expire = 0;

} /* rt_down function */

/* Route Handling Functions*/

voidAODV::rt_resolve(Packet *p) {struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);aodv_rt_entry *rt;

/* * Set the transmit failure callback. That * won't change. */ ch->xmit_failure_ = aodv_rt_failed_callback; ch->xmit_failure_data_ = (void*) this;

rt = rtable.rt_lookup(ih->daddr()); if(rt == 0) {

rt = rtable.rt_add(ih->daddr()); }

/* * If the route is up, forward the packet */

if(rt->rt_flags == RTF_UP) { assert(rt->rt_hops != INFINITY2); forward(rt, p, NO_DELAY); } /* * if I am the source of the packet, then do a Route Request. */

else if(ih->saddr() == index) { rqueue.enque(p); sendRequest(rt->rt_dst); } /* * A local repair is in progress. Buffer the packet. */ else if (rt->rt_flags == RTF_IN_REPAIR) { rqueue.enque(p);

}

/* * I am trying to forward a packet for someone else to which * I don't have a route. */ else { Packet *rerr = Packet::alloc(); struct hdr_aodv_error *re = HDR_AODV_ERROR(rerr); /* * For now, drop the packet and send error upstream. * Now the route errors are broadcast to upstream * neighbors - Mahesh 09/11/99 */ assert (rt->rt_flags == RTF_DOWN); re->DestCount = 0; re->unreachable_dst[re->DestCount] = rt->rt_dst; re->unreachable_dst_seqno[re->DestCount] = rt->rt_seqno; re->DestCount += 1;#ifdef DEBUG fprintf(stderr, "%s: sending RERR...\n", __FUNCTION__);#endif sendError(rerr, false);

drop(p, DROP_RTR_NO_ROUTE); }

}

voidAODV::rt_purge() {aodv_rt_entry *rt, *rtn;double now = CURRENT_TIME;double delay = 0.0;Packet *p;

for(rt = rtable.head(); rt; rt = rtn) { // for each rt entry rtn = rt->rt_link.le_next; if ((rt->rt_flags == RTF_UP) && (rt->rt_expire < now)) { // if a valid route has expired, purge all packets from // send buffer and invalidate the route.

assert(rt->rt_hops != INFINITY2); while((p = rqueue.deque(rt->rt_dst))) {#ifdef DEBUG fprintf(stderr, "%s: calling drop()\n", __FUNCTION__);#endif // DEBUG drop(p, DROP_RTR_NO_ROUTE); } rt->rt_seqno++; assert (rt->rt_seqno%2); rt_down(rt); } else if (rt->rt_flags == RTF_UP) { // If the route is not expired, // and there are packets in the sendbuffer waiting,

// forward them. This should not be needed, but this extra // check does no harm. assert(rt->rt_hops != INFINITY2); while((p = rqueue.deque(rt->rt_dst))) { forward (rt, p, delay); delay += ARP_DELAY; } } else if (rqueue.find(rt->rt_dst)) // If the route is down and // if there is a packet for this destination waiting in // the sendbuffer, then send out route request. sendRequest // will check whether it is time to really send out request // or not. // This may not be crucial to do it here, as each generated // packet will do a sendRequest anyway.

sendRequest(rt->rt_dst); }

}

/* Packet Reception Routines*/

voidAODV::recv(Packet *p, Handler*) {struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);

assert(initialized()); //assert(p->incoming == 0); // XXXXX NOTE: use of incoming flag has been depracated; In order to track direction of pkt flow, direction_ in hdr_cmn is used instead. see packet.h for details.

if(ch->ptype() == PT_AODV) { ih->ttl_ -= 1; recvAODV(p); return; }

/* * Must be a packet I'm originating... */if((ih->saddr() == index) && (ch->num_forwards() == 0)) { /* * Add the IP Header */ ch->size() += IP_HDR_LEN; // Added by Parag Dadhania && John Novatnack to handle broadcasting if ( (u_int32_t)ih->daddr() != IP_BROADCAST) ih->ttl_ = NETWORK_DIAMETER;} /*

* I received a packet that I sent. Probably * a routing loop. */else if(ih->saddr() == index) { drop(p, DROP_RTR_ROUTE_LOOP); return; } /* * Packet I'm forwarding... */ else { /* * Check the TTL. If it is zero, then discard. */ if(--ih->ttl_ == 0) { drop(p, DROP_RTR_TTL); return; } }// Added by Parag Dadhania && John Novatnack to handle broadcasting if ( (u_int32_t)ih->daddr() != IP_BROADCAST) rt_resolve(p); else forward((aodv_rt_entry*) 0, p, NO_DELAY);}

voidAODV::recvAODV(Packet *p) {struct hdr_aodv *ah = HDR_AODV(p);struct hdr_ip *ih = HDR_IP(p);

assert(ih->sport() == RT_PORT); assert(ih->dport() == RT_PORT);

/* * Incoming Packets. */ switch(ah->ah_type) {

case AODVTYPE_RREQ: recvRequest(p); break;

case AODVTYPE_RREP: recvReply(p); break;

case AODVTYPE_RERR: recvError(p); break;

case AODVTYPE_HELLO: recvHello(p); break; default:

fprintf(stderr, "Invalid AODV type (%x)\n", ah->ah_type); exit(1); }

}

voidAODV::recvRequest(Packet *p) {struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p);aodv_rt_entry *rt;

/* * Drop if: * - I'm the source * - I recently heard this request. */

if(rq->rq_src == index) {#ifdef DEBUG fprintf(stderr, "%s: got my own REQUEST\n", __FUNCTION__);#endif // DEBUG Packet::free(p); return; }

if (id_lookup(rq->rq_src, rq->rq_bcast_id)) {

#ifdef DEBUG fprintf(stderr, "%s: discarding request\n", __FUNCTION__);#endif // DEBUG Packet::free(p); return; }

/* * Cache the broadcast ID */ id_insert(rq->rq_src, rq->rq_bcast_id);

/* * We are either going to forward the REQUEST or generate a * REPLY. Before we do anything, we make sure that the REVERSE * route is in the route table. */ aodv_rt_entry *rt0; // rt0 is the reverse route rt0 = rtable.rt_lookup(rq->rq_src); if(rt0 == 0) { /* if not in the route table */ // create an entry for the reverse route. rt0 = rtable.rt_add(rq->rq_src); }

rt0->rt_expire = max(rt0->rt_expire, (CURRENT_TIME + REV_ROUTE_LIFE));

if ( (rq->rq_src_seqno > rt0->rt_seqno ) || ((rq->rq_src_seqno == rt0->rt_seqno) &&

(rq->rq_hop_count < rt0->rt_hops)) ) { // If we have a fresher seq no. or lesser #hops for the // same seq no., update the rt entry. Else don't bother.rt_update(rt0, rq->rq_src_seqno, rq->rq_hop_count, ih->saddr(), max(rt0->rt_expire, (CURRENT_TIME + REV_ROUTE_LIFE)) ); if (rt0->rt_req_timeout > 0.0) { // Reset the soft state and // Set expiry time to CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT // This is because route is used in the forward direction, // but only sources get benefited by this change rt0->rt_req_cnt = 0; rt0->rt_req_timeout = 0.0; rt0->rt_req_last_ttl = rq->rq_hop_count; rt0->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT; }

/* Find out whether any buffered packet can benefit from the * reverse route. * May need some change in the following code - Mahesh 09/11/99 */ assert (rt0->rt_flags == RTF_UP); Packet *buffered_pkt; while ((buffered_pkt = rqueue.deque(rt0->rt_dst))) { if (rt0 && (rt0->rt_flags == RTF_UP)) {

assert(rt0->rt_hops != INFINITY2); forward(rt0, buffered_pkt, NO_DELAY); } } } // End for putting reverse route in rt table

/* * We have taken care of the reverse route stuff. * Now see whether we can send a route reply. */

rt = rtable.rt_lookup(rq->rq_dst);

// First check if I am the destination ..

if(rq->rq_dst == index) {

#ifdef DEBUG fprintf(stderr, "%d - %s: destination sending reply\n", index, __FUNCTION__);#endif // DEBUG

// Just to be safe, I use the max. Somebody may have // incremented the dst seqno. seqno = max(seqno, rq->rq_dst_seqno)+1; if (seqno%2) seqno++;

sendReply(rq->rq_src, // IP Destination 1, // Hop Count index, // Dest IP Address seqno, // Dest Sequence Num MY_ROUTE_TIMEOUT, // Lifetime rq->rq_timestamp); // timestamp Packet::free(p); }

// I am not the destination, but I may have a fresh enough route.

else if (rt && (rt->rt_hops != INFINITY2) && (rt->rt_seqno >= rq->rq_dst_seqno) ) {

//assert (rt->rt_flags == RTF_UP); assert(rq->rq_dst == rt->rt_dst); //assert ((rt->rt_seqno%2) == 0); // is the seqno even? sendReply(rq->rq_src, rt->rt_hops + 1, rq->rq_dst, rt->rt_seqno,

(u_int32_t) (rt->rt_expire - CURRENT_TIME), // rt->rt_expire - CURRENT_TIME,

rq->rq_timestamp); // Insert nexthops to RREQ source and RREQ destination in the // precursor lists of destination and source respectively rt->pc_insert(rt0->rt_nexthop); // nexthop to RREQ source rt0->pc_insert(rt->rt_nexthop); // nexthop to RREQ destination

#ifdef RREQ_GRAT_RREP

sendReply(rq->rq_dst, rq->rq_hop_count, rq->rq_src, rq->rq_src_seqno,

(u_int32_t) (rt->rt_expire - CURRENT_TIME), // rt->rt_expire - CURRENT_TIME,

rq->rq_timestamp);#endif // TODO: send grat RREP to dst if G flag set in RREQ using rq->rq_src_seqno, rq->rq_hop_counT // DONE: Included gratuitous replies to be sent as per IETF aodv draft specification. As of now, G flag has not been dynamically used and is always set or reset in aodv-packet.h --- Anant Utgikar, 09/16/02.

Packet::free(p); } /* * Can't reply. So forward the Route Request */ else { ih->saddr() = index; ih->daddr() = IP_BROADCAST;

rq->rq_hop_count += 1; // Maximum sequence number seen en route if (rt) rq->rq_dst_seqno = max(rt->rt_seqno, rq->rq_dst_seqno); forward((aodv_rt_entry*) 0, p, DELAY); }

}

voidAODV::recvReply(Packet *p) {//struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p);aodv_rt_entry *rt;char suppress_reply = 0;double delay = 0.0;

#ifdef DEBUG fprintf(stderr, "%d - %s: received a REPLY\n", index, __FUNCTION__);#endif // DEBUG

/* * Got a reply. So reset the "soft state" maintained for * route requests in the request table. We don't really have * have a separate request table. It is just a part of the * routing table itself. */ // Note that rp_dst is the dest of the data packets, not the // the dest of the reply, which is the src of the data packets.

rt = rtable.rt_lookup(rp->rp_dst); /* * If I don't have a rt entry to this host... adding */ if(rt == 0) { rt = rtable.rt_add(rp->rp_dst); }

/* * Add a forward route table entry... here I am following * Perkins-Royer AODV paper almost literally - SRD 5/99 */

if ( (rt->rt_seqno < rp->rp_dst_seqno) || // newer route ((rt->rt_seqno == rp->rp_dst_seqno) && (rt->rt_hops > rp->rp_hop_count)) ) { // shorter or better route

// Update the rt entry rt_update(rt, rp->rp_dst_seqno, rp->rp_hop_count,

rp->rp_src, CURRENT_TIME + rp->rp_lifetime);

// reset the soft state rt->rt_req_cnt = 0; rt->rt_req_timeout = 0.0;

rt->rt_req_last_ttl = rp->rp_hop_count; if (ih->daddr() == index) { // If I am the original source // Update the route discovery latency statistics // rp->rp_timestamp is the time of request origination

rt->rt_disc_latency[rt->hist_indx] = (CURRENT_TIME - rp->rp_timestamp) / (double) rp->rp_hop_count; // increment indx for next time rt->hist_indx = (rt->hist_indx + 1) % MAX_HISTORY; }

/* * Send all packets queued in the sendbuffer destined for * this destination. * XXX - observe the "second" use of p. */ Packet *buf_pkt; while((buf_pkt = rqueue.deque(rt->rt_dst))) { if(rt->rt_hops != INFINITY2) { assert (rt->rt_flags == RTF_UP); // Delay them a little to help ARP. Otherwise ARP // may drop packets. -SRD 5/23/99 forward(rt, buf_pkt, delay); delay += ARP_DELAY; } } } else { suppress_reply = 1; }

/* * If reply is for me, discard it. */

if(ih->daddr() == index || suppress_reply) { Packet::free(p); } /* * Otherwise, forward the Route Reply. */ else { // Find the rt entryaodv_rt_entry *rt0 = rtable.rt_lookup(ih->daddr()); // If the rt is up, forward if(rt0 && (rt0->rt_hops != INFINITY2)) { assert (rt0->rt_flags == RTF_UP); rp->rp_hop_count += 1; rp->rp_src = index; forward(rt0, p, NO_DELAY); // Insert the nexthop towards the RREQ source to // the precursor list of the RREQ destination rt->pc_insert(rt0->rt_nexthop); // nexthop to RREQ source } else {

// I don't know how to forward .. drop the reply. #ifdef DEBUG fprintf(stderr, "%s: dropping Route Reply\n", __FUNCTION__);#endif // DEBUG drop(p, DROP_RTR_NO_ROUTE); } }}

voidAODV::recvError(Packet *p) {struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_error *re = HDR_AODV_ERROR(p);aodv_rt_entry *rt;u_int8_t i;Packet *rerr = Packet::alloc();struct hdr_aodv_error *nre = HDR_AODV_ERROR(rerr);

nre->DestCount = 0;

for (i=0; i<re->DestCount; i++) { // For each unreachable destination rt = rtable.rt_lookup(re->unreachable_dst[i]); if ( rt && (rt->rt_hops != INFINITY2) &&

(rt->rt_nexthop == ih->saddr()) && (rt->rt_seqno <= re->unreachable_dst_seqno[i]) ) {

assert(rt->rt_flags == RTF_UP);assert((rt->rt_seqno%2) == 0); // is the seqno even?

#ifdef DEBUG fprintf(stderr, "%s(%f): %d\t(%d\t%u\t%d)\t(%d\t%u\t%d)\n", __FUNCTION__,CURRENT_TIME,

index, rt->rt_dst, rt->rt_seqno, rt->rt_nexthop, re->unreachable_dst[i],re->unreachable_dst_seqno[i],

ih->saddr());#endif // DEBUG rt->rt_seqno = re->unreachable_dst_seqno[i]; rt_down(rt);

// Not sure whether this is the right thing to do Packet *pkt;

while((pkt = ifqueue->filter(ih->saddr()))) { drop(pkt, DROP_RTR_MAC_CALLBACK); }

// if precursor list non-empty add to RERR and delete the precursor list if (!rt->pc_empty()) { nre->unreachable_dst[nre->DestCount] = rt->rt_dst; nre->unreachable_dst_seqno[nre->DestCount] = rt->rt_seqno; nre->DestCount += 1;

rt->pc_delete(); } } }

if (nre->DestCount > 0) {#ifdef DEBUG

fprintf(stderr, "%s(%f): %d\t sending RERR...\n", __FUNCTION__, CURRENT_TIME, index);#endif // DEBUG sendError(rerr); } else { Packet::free(rerr); }

Packet::free(p);}

/* Packet Transmission Routines*/

voidAODV::forward(aodv_rt_entry *rt, Packet *p, double delay) {struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);

//**********Get Position, Energy Sundaresh k - Elysium Technologies

iNode = (MobileNode *) (Node::get_node_by_address(index));xpos = iNode->X();ypos = iNode->Y();iEnergy = iNode->energy_model()->energy();printf("at Time (%.6f), Position of %d is X: %.4f and Y: %.4f \n", CURRENT_TIME,index,xpos,ypos);printf("at Time (%.6f): Updated Energy for Node %d is Energy %.4f \n",CURRENT_TIME, index, iEnergy);

if(ih->ttl_ == 0) {

#ifdef DEBUG fprintf(stderr, "%s: calling drop()\n", __PRETTY_FUNCTION__);#endif // DEBUG drop(p, DROP_RTR_TTL); return; }

if (ch->ptype() != PT_AODV && ch->direction() == hdr_cmn::UP &&((u_int32_t)ih->daddr() == IP_BROADCAST)

|| ((u_int32_t)ih->daddr() == here_.addr_)) {dmux_->recv(p,0);return;

}

if (rt) { assert(rt->rt_flags == RTF_UP); rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT; ch->next_hop_ = rt->rt_nexthop; ch->addr_type() = NS_AF_INET; ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction

} else { // if it is a broadcast packet // assert(ch->ptype() == PT_AODV); // maybe a diff pkt type like gaf assert(ih->daddr() == (nsaddr_t) IP_BROADCAST); ch->addr_type() = NS_AF_NONE; ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction }

if (ih->daddr() == (nsaddr_t) IP_BROADCAST) { // If it is a broadcast packet assert(rt == 0); /* * Jitter the sending of broadcast packets by 10ms */ Scheduler::instance().schedule(target_, p, 0.01 * Random::uniform()); } else { // Not a broadcast packet if(delay > 0.0) { Scheduler::instance().schedule(target_, p, delay); } else { // Not a broadcast packet, no delay, send immediately Scheduler::instance().schedule(target_, p, 0.); } }

}

voidAODV::sendRequest(nsaddr_t dst) {// Allocate a RREQ packet Packet *p = Packet::alloc();struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p);aodv_rt_entry *rt = rtable.rt_lookup(dst);

assert(rt);

/* * Rate limit sending of Route Requests. We are very conservative * about sending out route requests. */

if (rt->rt_flags == RTF_UP) { assert(rt->rt_hops != INFINITY2); Packet::free((Packet *)p); return; }

if (rt->rt_req_timeout > CURRENT_TIME) { Packet::free((Packet *)p); return; }

// rt_req_cnt is the no. of times we did network-wide broadcast // RREQ_RETRIES is the maximum number we will allow before // going to a long timeout.

if (rt->rt_req_cnt > RREQ_RETRIES) { rt->rt_req_timeout = CURRENT_TIME + MAX_RREQ_TIMEOUT; rt->rt_req_cnt = 0; Packet *buf_pkt; while ((buf_pkt = rqueue.deque(rt->rt_dst))) { drop(buf_pkt, DROP_RTR_NO_ROUTE); } Packet::free((Packet *)p); return; }

#ifdef DEBUG fprintf(stderr, "(%2d) - %2d sending Route Request, dst: %d\n", ++route_request, index, rt->rt_dst);#endif // DEBUG

// Determine the TTL to be used this time. // Dynamic TTL evaluation - SRD

rt->rt_req_last_ttl = max(rt->rt_req_last_ttl,rt->rt_last_hop_count);

if (0 == rt->rt_req_last_ttl) { // first time query broadcast ih->ttl_ = TTL_START; } else { // Expanding ring search. if (rt->rt_req_last_ttl < TTL_THRESHOLD) ih->ttl_ = rt->rt_req_last_ttl + TTL_INCREMENT; else { // network-wide broadcast ih->ttl_ = NETWORK_DIAMETER; rt->rt_req_cnt += 1; } }

// remember the TTL used for the next time rt->rt_req_last_ttl = ih->ttl_;

// PerHopTime is the roundtrip time per hop for route requests. // The factor 2.0 is just to be safe .. SRD 5/22/99 // Also note that we are making timeouts to be larger if we have // done network wide broadcast before.

rt->rt_req_timeout = 2.0 * (double) ih->ttl_ * PerHopTime(rt); if (rt->rt_req_cnt > 0) rt->rt_req_timeout *= rt->rt_req_cnt; rt->rt_req_timeout += CURRENT_TIME;

// Don't let the timeout to be too large, however .. SRD 6/8/99 if (rt->rt_req_timeout > CURRENT_TIME + MAX_RREQ_TIMEOUT) rt->rt_req_timeout = CURRENT_TIME + MAX_RREQ_TIMEOUT;

rt->rt_expire = 0;

#ifdef DEBUG fprintf(stderr, "(%2d) - %2d sending Route Request, dst: %d, tout %f ms\n",

++route_request, index, rt->rt_dst, rt->rt_req_timeout - CURRENT_TIME);

#endif // DEBUG

// Fill out the RREQ packet // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rq->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->prev_hop_ = index; // AODV hack

ih->saddr() = index; ih->daddr() = IP_BROADCAST; ih->sport() = RT_PORT; ih->dport() = RT_PORT;

// Fill up some more fields. rq->rq_type = AODVTYPE_RREQ; rq->rq_hop_count = 1; rq->rq_bcast_id = bid++; rq->rq_dst = dst; rq->rq_dst_seqno = (rt ? rt->rt_seqno : 0); rq->rq_src = index; seqno += 2; assert ((seqno%2) == 0); rq->rq_src_seqno = seqno; rq->rq_timestamp = CURRENT_TIME;

Scheduler::instance().schedule(target_, p, 0.);

}

voidAODV::sendReply(nsaddr_t ipdst, u_int32_t hop_count, nsaddr_t rpdst, u_int32_t rpseq, u_int32_t lifetime, double timestamp) {Packet *p = Packet::alloc();struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p);aodv_rt_entry *rt = rtable.rt_lookup(ipdst);

#ifdef DEBUGfprintf(stderr, "sending Reply from %d at %.2f\n", index, Scheduler::instance().clock());#endif // DEBUG assert(rt);

rp->rp_type = AODVTYPE_RREP; //rp->rp_flags = 0x00;

rp->rp_hop_count = hop_count; rp->rp_dst = rpdst; rp->rp_dst_seqno = rpseq; rp->rp_src = index; rp->rp_lifetime = lifetime; rp->rp_timestamp = timestamp; // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rp->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_INET; ch->next_hop_ = rt->rt_nexthop; ch->prev_hop_ = index; // AODV hack ch->direction() = hdr_cmn::DOWN;

ih->saddr() = index; ih->daddr() = ipdst; ih->sport() = RT_PORT; ih->dport() = RT_PORT; ih->ttl_ = NETWORK_DIAMETER;

Scheduler::instance().schedule(target_, p, 0.);

}

voidAODV::sendError(Packet *p, bool jitter) {struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_error *re = HDR_AODV_ERROR(p); #ifdef ERRORfprintf(stderr, "sending Error from %d at %.2f\n", index, Scheduler::instance().clock());#endif // DEBUG

re->re_type = AODVTYPE_RERR; //re->reserved[0] = 0x00; re->reserved[1] = 0x00; // DestCount and list of unreachable destinations are already filled

// ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + re->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->next_hop_ = 0; ch->prev_hop_ = index; // AODV hack ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction

ih->saddr() = index; ih->daddr() = IP_BROADCAST; ih->sport() = RT_PORT; ih->dport() = RT_PORT;

ih->ttl_ = 1;

// Do we need any jitter? Yes if (jitter) Scheduler::instance().schedule(target_, p, 0.01*Random::uniform()); else Scheduler::instance().schedule(target_, p, 0.0);

}

/* Neighbor Management Functions*/

voidAODV::sendHello() {Packet *p = Packet::alloc();struct hdr_cmn *ch = HDR_CMN(p);struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_reply *rh = HDR_AODV_REPLY(p);

#ifdef DEBUGfprintf(stderr, "sending Hello from %d at %.2f\n", index, Scheduler::instance().clock());#endif // DEBUG

rh->rp_type = AODVTYPE_HELLO; //rh->rp_flags = 0x00; rh->rp_hop_count = 1; rh->rp_dst = index; rh->rp_dst_seqno = seqno; rh->rp_lifetime = (1 + ALLOWED_HELLO_LOSS) * HELLO_INTERVAL;

// ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rh->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->prev_hop_ = index; // AODV hack

ih->saddr() = index; ih->daddr() = IP_BROADCAST; ih->sport() = RT_PORT; ih->dport() = RT_PORT; ih->ttl_ = 1;

Scheduler::instance().schedule(target_, p, 0.0);}

voidAODV::recvHello(Packet *p) {//struct hdr_ip *ih = HDR_IP(p);struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p);AODV_Neighbor *nb;

nb = nb_lookup(rp->rp_dst); if(nb == 0) { nb_insert(rp->rp_dst); } else { nb->nb_expire = CURRENT_TIME + (1.5 * ALLOWED_HELLO_LOSS * HELLO_INTERVAL); }

Packet::free(p);}

voidAODV::nb_insert(nsaddr_t id) {AODV_Neighbor *nb = new AODV_Neighbor(id);

assert(nb); nb->nb_expire = CURRENT_TIME + (1.5 * ALLOWED_HELLO_LOSS * HELLO_INTERVAL); LIST_INSERT_HEAD(&nbhead, nb, nb_link); seqno += 2; // set of neighbors changed assert ((seqno%2) == 0);}

AODV_Neighbor*AODV::nb_lookup(nsaddr_t id) {AODV_Neighbor *nb = nbhead.lh_first;

for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) break; } return nb;}

/* * Called when we receive *explicit* notification that a Neighbor * is no longer reachable. */voidAODV::nb_delete(nsaddr_t id) {AODV_Neighbor *nb = nbhead.lh_first;

log_link_del(id); seqno += 2; // Set of neighbors changed assert ((seqno%2) == 0);

for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) { LIST_REMOVE(nb,nb_link); delete nb; break; } }

handle_link_failure(id);

}

/* * Purges all timed-out Neighbor Entries - runs every * HELLO_INTERVAL * 1.5 seconds. */voidAODV::nb_purge() {AODV_Neighbor *nb = nbhead.lh_first;AODV_Neighbor *nbn;double now = CURRENT_TIME;

for(; nb; nb = nbn) { nbn = nb->nb_link.le_next; if(nb->nb_expire <= now) { nb_delete(nb->nb_addr); } }

}

AODV Communication

#include <assert.h>

#include <cmu-trace.h>#include <aodv/aodv_rqueue.h>

#define CURRENT_TIME Scheduler::instance().clock()#define QDEBUG

/* Packet Queue used by AODV.*/

aodv_rqueue::aodv_rqueue() { head_ = tail_ = 0; len_ = 0; limit_ = AODV_RTQ_MAX_LEN; timeout_ = AODV_RTQ_TIMEOUT;}

voidaodv_rqueue::enque(Packet *p) {struct hdr_cmn *ch = HDR_CMN(p);

/* * Purge any packets that have timed out. */ purge(); p->next_ = 0; ch->ts_ = CURRENT_TIME + timeout_;

if (len_ == limit_) { Packet *p0 = remove_head(); // decrements len_

assert(p0); if(HDR_CMN(p0)->ts_ > CURRENT_TIME) { drop(p0, DROP_RTR_QFULL); } else { drop(p0, DROP_RTR_QTIMEOUT); } } if(head_ == 0) { head_ = tail_ = p; } else { tail_->next_ = p; tail_ = p; } len_++;#ifdef QDEBUG verifyQueue();#endif // QDEBUG}

Packet*aodv_rqueue::deque() {Packet *p;

/* * Purge any packets that have timed out. */ purge();

p = remove_head();#ifdef QDEBUG verifyQueue();#endif // QDEBUG return p;

}

Packet*aodv_rqueue::deque(nsaddr_t dst) {Packet *p, *prev;

/* * Purge any packets that have timed out. */ purge();

findPacketWithDst(dst, p, prev); assert(p == 0 || (p == head_ && prev == 0) || (prev->next_ == p));

if(p == 0) return 0;

if (p == head_) { p = remove_head(); } else if (p == tail_) { prev->next_ = 0; tail_ = prev; len_--; } else { prev->next_ = p->next_; len_--; }

#ifdef QDEBUG verifyQueue();#endif // QDEBUG return p;

}

char aodv_rqueue::find(nsaddr_t dst) {Packet *p, *prev;

findPacketWithDst(dst, p, prev); if (0 == p) return 0; else return 1;

}/* Private Routines*/

Packet*aodv_rqueue::remove_head() {Packet *p = head_; if(head_ == tail_) { head_ = tail_ = 0; } else { head_ = head_->next_; }

if(p) len_--;

return p;

}

voidaodv_rqueue::findPacketWithDst(nsaddr_t dst, Packet*& p, Packet*& prev) { p = prev = 0; for(p = head_; p; p = p->next_) {

// if(HDR_IP(p)->dst() == dst) { if(HDR_IP(p)->daddr() == dst) {

return; } prev = p; }}

voidaodv_rqueue::verifyQueue() {Packet *p, *prev = 0;int cnt = 0;

for(p = head_; p; p = p->next_) { cnt++; prev = p; } assert(cnt == len_); assert(prev == tail_);

}

/*voidaodv_rqueue::purge() {Packet *p;

while((p = head_) && HDR_CMN(p)->ts_ < CURRENT_TIME) { // assert(p == remove_head()); p = remove_head(); drop(p, DROP_RTR_QTIMEOUT); }

}*/

boolaodv_rqueue::findAgedPacket(Packet*& p, Packet*& prev) { p = prev = 0; for(p = head_; p; p = p->next_) { if(HDR_CMN(p)->ts_ < CURRENT_TIME) { return true; } prev = p; } return false;}

voidaodv_rqueue::purge() {Packet *p, *prev;

while ( findAgedPacket(p, prev) ) { assert(p == 0 || (p == head_ && prev == 0) || (prev->next_ == p));

if(p == 0) return;

if (p == head_) { p = remove_head(); } else if (p == tail_) { prev->next_ = 0; tail_ = prev; len_--; } else { prev->next_ = p->next_; len_--; }#ifdef QDEBUG verifyQueue();#endif // QDEBUG

p = prev = 0; }}

AODV Routing Table Formation

#include <aodv/aodv_rtable.h>//#include <cmu/aodv/aodv.h>

/* The Routing Table*/

aodv_rt_entry::aodv_rt_entry(){int i;

rt_req_timeout = 0.0; rt_req_cnt = 0;

rt_dst = 0; rt_seqno = 0; rt_hops = rt_last_hop_count = INFINITY2; rt_nexthop = 0; LIST_INIT(&rt_pclist); rt_expire = 0.0; rt_flags = RTF_DOWN;

/* rt_errors = 0; rt_error_time = 0.0; */

for (i=0; i < MAX_HISTORY; i++) { rt_disc_latency[i] = 0.0; } hist_indx = 0; rt_req_last_ttl = 0;

LIST_INIT(&rt_nblist);

};

aodv_rt_entry::~aodv_rt_entry(){AODV_Neighbor *nb;

while((nb = rt_nblist.lh_first)) { LIST_REMOVE(nb, nb_link); delete nb; }

AODV_Precursor *pc;

while((pc = rt_pclist.lh_first)) { LIST_REMOVE(pc, pc_link); delete pc; }

}

voidaodv_rt_entry::nb_insert(nsaddr_t id){AODV_Neighbor *nb = new AODV_Neighbor(id); assert(nb); nb->nb_expire = 0; LIST_INSERT_HEAD(&rt_nblist, nb, nb_link);

}

AODV_Neighbor*aodv_rt_entry::nb_lookup(nsaddr_t id){AODV_Neighbor *nb = rt_nblist.lh_first;

for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) break; } return nb;

}

voidaodv_rt_entry::pc_insert(nsaddr_t id){

if (pc_lookup(id) == NULL) {AODV_Precursor *pc = new AODV_Precursor(id);

assert(pc); LIST_INSERT_HEAD(&rt_pclist, pc, pc_link);

}}

AODV_Precursor*aodv_rt_entry::pc_lookup(nsaddr_t id){AODV_Precursor *pc = rt_pclist.lh_first;

for(; pc; pc = pc->pc_link.le_next) { if(pc->pc_addr == id) return pc; } return NULL;

}

voidaodv_rt_entry::pc_delete(nsaddr_t id) {AODV_Precursor *pc = rt_pclist.lh_first;

for(; pc; pc = pc->pc_link.le_next) { if(pc->pc_addr == id) { LIST_REMOVE(pc,pc_link); delete pc; break; } }

}

voidaodv_rt_entry::pc_delete(void) {AODV_Precursor *pc;

while((pc = rt_pclist.lh_first)) { LIST_REMOVE(pc, pc_link); delete pc; }}

boolaodv_rt_entry::pc_empty(void) {AODV_Precursor *pc;

if ((pc = rt_pclist.lh_first)) return false; else return true;}

/* The Routing Table*/

aodv_rt_entry*aodv_rtable::rt_lookup(nsaddr_t id){aodv_rt_entry *rt = rthead.lh_first;

for(; rt; rt = rt->rt_link.le_next) { if(rt->rt_dst == id) break; } return rt;

}

voidaodv_rtable::rt_delete(nsaddr_t id){aodv_rt_entry *rt = rt_lookup(id);

if(rt) { LIST_REMOVE(rt, rt_link); delete rt; }

}

aodv_rt_entry*aodv_rtable::rt_add(nsaddr_t id){aodv_rt_entry *rt;

assert(rt_lookup(id) == 0); rt = new aodv_rt_entry; assert(rt); rt->rt_dst = id; LIST_INSERT_HEAD(&rthead, rt, rt_link); return rt;}

TCL Scriptset opt(chan) Channel/WirelessChannelset opt(prop) Propagation/TwoRayGroundset opt(netif) Phy/WirelessPhyset opt(mac) Mac/802_11 ;# MAC typeset opt(ifq) Queue/DropTail/PriQueueset opt(ll) LLset opt(ant) Antenna/OmniAntenna

set opt(x) 1500 ;# X dimension of the topographyset opt(y) 300 ;# Y dimension of the topographyset opt(cp) "cbr/cbr_rate21"set opt(sc) "scen/scen-1500x300-50-0-20-1"

set opt(ifqlen) 50 ;# max packet in ifqset opt(nn) 100 ;# number of nodesset opt(seed) 0.0set opt(stop) 300.0 ;# simulation timeset opt(tr) out.tr ;# trace fileset opt(nam) out.nam ;# animation fileset opt(rp) AODV ;# routing protocol script#set opt(lm) "off" ;# log movementset opt(agent) AODVset opt(energymodel) EnergyModel ;#set opt(energymodel) RadioModel ;set opt(radiomodel) RadioModel ;set opt(initialenergy) 100 ;# Initial energy in Joules#set opt(logenergy) "on" ;# log energy every 150 seconds

#set opt(lm) "off" ;# log movement#set opt(imep) "OFF"

#set opt(debug) "OFF"#set opt(errmodel) "" ;# for errmodel#set opt(em) "" ;# set to name of errmodel file

#set opt(ps) 128 ;# cbr data pkt size#set opt(pi) 0.33 ;# cbr data interval

set opt(usepsm) 1 ;# use power saving mode

set opt(usespan) 1 ;# use span electionset opt(spanopt) 1 ;# use psm optimization

#set opt(slaver) "" ;# remote drive an ad-hockey at this ip addr

# ======================================================================

set AgentTrace ONset RouterTrace ONset MacTrace ON

LL set delay_ 0LL set mindelay_ 25usLL set maxdelay_ 50us#LL set bandwidth_ 0 ;# not used#LL set off_prune_ 0 ;# not used#LL set off_CtrMcast_ 0 ;# not used#source rpAgent/CBR set sport_ 0Agent/CBR set dport_ 0

#Agent/TCPSink set sport_ 0#Agent/TCPSink set dport_ 0

#Agent/TCP set sport_ 0#Agent/TCP set dport_ 0#Agent/TCP set packetSize_ 1460

#if [TclObject is-class Scheduler/RealTime] { # Scheduler/RealTime set maxslop_ 10#}

# unity gain, omni-directional antennas# set up the antennas to be centered in the node and 1.5 meters above itAntenna/OmniAntenna set X_ 0Antenna/OmniAntenna set Y_ 0Antenna/OmniAntenna set Z_ 1.5Antenna/OmniAntenna set Gt_ 1.0Antenna/OmniAntenna set Gr_ 1.0

# Initialize the SharedMedia interface with parameters to make# it work like the 914MHz Lucent WaveLAN DSSS radio interfacePhy/WirelessPhy set CPThresh_ 10.0Phy/WirelessPhy set CSThresh_ 1.559e-11Phy/WirelessPhy set RXThresh_ 3.652e-10Phy/WirelessPhy set Rb_ 2.0e6Phy/WirelessPhy set Pt_ 0.2818Phy/WirelessPhy set freq_ 914e+6 Phy/WirelessPhy set L_ 1.0#source mac# the above parameters result in a nominal range of 250mset nominal_range 250.0set configured_range -1.0

set configured_raw_bitrate -1.0

# ======================================================================

set ns_ [new Simulator]set topo [new Topography]set tracefd [open $opt(tr) w]set namtrace [open $opt(nam) w]set prop [new $opt(prop)]#$ns_ use-newtrace$topo load_flatgrid $opt(x) $opt(y)#ns-random 1.0$ns_ trace-all $tracefd$ns_ namtrace-all-wireless $namtrace 1500 300

## Create god#set god_ [create-god $opt(nn)]

#global node setting

$ns_ node-config -adhocRouting $opt(agent) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channelType $opt(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -energyModel $opt(energymodel) \ -idlePower 1.0 \ -rxPower 1.0 \ -txPower 1.0 \

-sleepPower 0.001 \ -transitionPower 0.2 \ -transitionTime 0.005 \

-initialEnergy $opt(initialenergy)

$ns_ set WirelessNewTrace_ ONset AgentTrace ONset RouterTrace ONset MacTrace ON

for {set i 0} {$i < $opt(nn) } {incr i} {set node_($i) [$ns_ node]

$ns_ initial_node_pos $node_($i) 30;

$node_($i) random-motion 0 ;# disable random motion

}

source $opt(sc)

# $node_(1) set agentTrace ON # $node_(1) set macTrace ON# $node_(1) set routerTrace ON # $node_(0) set macTrace ON# $node_(0) set agentTrace ON # $node_(0) set routerTrace ON

$ns_ at 0.0000 "$node_(1) add-mark m2 red circle"$ns_ at 0.0000 "$node_(2) add-mark m2 red circle"$ns_ at 0.0000 "$node_(1) label \"Sender\""$ns_ at 0.0000 "$node_(2) label \"Receiver\""

set udp_(0) [new Agent/TCP]$ns_ attach-agent $node_(1) $udp_(0)set null_(0) [new Agent/TCPSink]$ns_ attach-agent $node_(2) $null_(0)set cbr_(0) [new Application/FTP]$cbr_(0) set packetSize_ 512$cbr_(0) set interval_ 5.0$cbr_(0) set random_ 1$cbr_(0) set maxpkts_ 10000$cbr_(0) attach-agent $udp_(0)$ns_ connect $udp_(0) $null_(0)$ns_ at 2.5568388786897245 "$cbr_(0) start"#$ns_ at 177.000 "$node_(0) set ifqLen"

## Tell all the nodes when the simulation ends#for {set i 0} {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop) "$node_($i) reset";}$ns_ at $opt(stop) "puts \"NS EXITING...\" ; $ns_ halt"

puts "Starting Simulation..."$ns_ run