1.

INTRODUCTION

A mobile ad hoc network is a network formed and functioning without any

established infrastructure or centralized administration and consists of mobile nodes that

use a wireless interface to communicate with each other. These mobile nodes serve as both

hosts and routers so that they can forward packets on behalf of each other. Hence, the

mobile nodes are able to communicate beyond their transmission range by supporting

multihop communication.

The issue of routing in a mobile ad hoc network becomes a challenging task since

the mobile nodes are free to move randomly. Ad hoc routing protocols can be classified in

to three classes: proactive, reactive and hybrid routing protocols. In proactive routing the

routing table of every node is updated periodically. Reactive routing is performed on-

demand, i.e. the sending node searches for a route to the destination node only when it

needs to communicate with it. Hybrid routing uses a mixture of these two routing

approaches. That is, proactive routing is used in a limited area around the mobile node and

reactive routing is used outside this area.

Mobile Ad Hoc Networking (MANET) is the name of a working group in the

Internet Engineering Task Force (IETF) and it serves as a meeting place for people dealing

with MANET approaches. The primary focus of the working group is to develop and

evolve MANET routing specifications and introduce them to the Internet Standards track.

Many routing protocols have been proposed for MANET. Most of the protocols

assume mobile nodes have single wireless interface. Early proposed protocols such as

DSDV [1] are usually proactive. They disseminate topology information proactively even

when there is no data to send. Such approach commonly leads to large control overhead.

1
To reduce the overhead, reactive approach can be used in which route is searched only

when there is data to send. Reactive approach generally imposes an initial route discovery

delay which is undesirable in many circumstances.

1.1 THE WIRELESS WORLD

The wireless mode can work in two different modes; the first one is the most

common, called the architecture mode. This mode is just using wireless for the end user

loop. The second kind of operating mode for a wireless network is the Ad Hoc mode. This

one relies only on wireless communications.

1.1.1 Infrastructure

The most known example of infrastructure wireless network is GSM and, more

recently, WIFI. As said above, this mode is just using the wireless for the end user loop,

which means between the user terminal and a “radio terminal”. This term “radio terminal”

describes a Base station (for GSM), or an access point (for WIFI). Its role is basically to

serve as a gateway between a wired network (called distribution system) and its wireless

zone.

Technically speaking, each “radio terminal” spreads a signal around, creating a

coverage zone. Each client is able to communicate within this zone, but then, has to

renegotiate with another “radio terminal” if available. The “radio terminal” has the key role

of referee in this kind of network, as each station has to communicate only with its radio

terminal.

Mobility is then limited to a coverage zone, and so, has a limited impact on this

implementation. This infrastructure design can be seen as a first way to implement wireless

technologies into the settled wired world. In fact, from the technical point of view, only the

2
first two layers are modified in the OSI model. These changes concern only the physical

layer (going from a wire to a wireless media) and the Logical Link Control (LLC) layer

(how to access the media). Other layers of the OSI model are working as in a wired

network.

1.1.2 Ad Hoc

Ad Hoc is an expression from the Latin which means “for this purpose”. Ad Hoc

networks introduce a new way of communication. Since communications networks were

created, there were two kinds of device, the one which uses the network and the one which

acts for the network. This rule is true in telephony (phones vs. switches), in Internet

(computers, servers vs. routers, switches, hub…) and also in the infrastructure mode

described above (user terminal vs. radio terminal).

In Ad Hoc networks, each station is using the network and creating the network.

For example, in a wifi network, a laptop is able to send and receive data for itself, but it

can also forward others data (acting as a router).

This design has the main advantage to be independent of any distribution system, or

any hierarchy such as an access point. If A wants to communicate with B, then, they just

have to connect to each other and exchange data. But, this design also extends coverage

and mobility possibilities. If A wants to communicate with C, but C is out of range, B, a

station in both A and C radio zones, can forward packets. Also, if A is moving closer to C,

A and C can stop using B as a relay.

3
 Access point

A B

A B

Figure 1.1 Infrastructure modes vs. Ad Hoc mode

1.2 USAGE OF AD HOC NETWORKS

1.2.1 Extending Coverage

Ad Hoc networks can be used for extending the coverage area of an access point.

By this way, a single access point where a few users are connected can provide a network

access to out-of-range machines. Figure 2-2 describes this implementation of Ad Hoc

networks:

Figure 1.2 Example of range extension with Ad Hoc

This example shows how the Ad Hoc model can extend an infrastructure wireless

network. Without Ad Hoc, only station A could access the internet using the access point.

But, if each station is able to forward the packets to the Access Point, then, B can access

the internet, as well as C and the final user.

4
 1.2.2 Communicating where no infrastructure exists

Ad Hoc networks can also be used in an environment where no infrastructure

exists. A good example is when an army is deploying into a destroyed place or an empty

space. In this case, each station can be configured for forwarding communications to the

appropriate destination. This example also shows the mobility benefit of the Ad Hoc

model. This case also applies in the ocean, in the air or even in space (for satellites).

1.2.3 Community Networks

A community network is a network where everybody shares its connections with

other people. There are two ways to use Ad Hoc for community networks. The most

commonly used, is to extend coverage as explained above. Access points are deployed into

a city (most common scale) depending of the density of users, and then, Ad Hoc is used to

extend the coverage of these access points. In this scenario, the density of access points is

important as too many users connected to the same access point can overload its

connection. Also, there must be enough users to relay the network where no coverage

exists.

Another way to use the Ad Hoc model is to create what’s called a mesh network.

This time, each access point is part of the Ad Hoc network, and can be connected or not to

a distribution system. The notion of hierarchy present in the architecture doesn’t exist

anymore.

1.3 ADVANTAGES AND DRAWBACKS

Ad hoc networks are really an alternative to fixed networks in some operational

situations, but an analysis of their advantages and drawbacks that will help us know the

applications and the contexts they may be useful for. Below, we present some of those.

5
 1.3.1 The advantages of Ad Hoc Networks (AHN’s)

• Fast installation: the level of flexibility for setting up AHN’s is high, since

they do not require any previous installation or infrastructure and, thus, they can be

brought up and torn down in very short time.

• Dynamic topologies: nodes can arbitrarily move around the network and

can disappear temporally from the AHN, so the network topology graph can be

continuously changing at undetermined speed.

• Fault tolerance: owing to the limitations of the radio interfaces and the

dynamic topology, AHN’s support connection failures, because routing and transmission

control protocols are designed to manage these situations.

• Connectivity: the use of centralized points or gateways is not necessary for

the communication within the AHN, due to the collaboration between nodes in the task of

delivering packets.

• Mobility: the wireless mobile nodes can move at the same time in different

directions. Although the routing algorithms deal with this issue, the performance

simulations show that there is a threshold level of node mobility such that protocol

operation begins to fail.

• Cost: AHN’s could be more economical in some cases as they eliminate fixed

infrastructure costs and reduce power consumption at mobile nodes.

• Spectrum reuse possibility: owing to short communication links (node-to-

node instead of node to a central base station), radio emission levels could be kept at low

level. This increases spectrum reuse possibility or possibility of using un licensed bands.

6
 1.3.2 Some problems of the Ad Hoc Networks (AHN’s)

• Bandwidth constraints: As commented above, the capacity of the wireless

links is always much lower than in the wired counterparts. Indeed, several Gbps are

available for wired LAN, while, nowadays, the commercial applications for wireless LANs

work typically around 2 Mbps.

• Processing capability: Most of the nodes of the AND are devices without a

powerful CPU. Furthermore, the network tasks such as routing and data transmission

cannot consume the power resources of the devices, intended to play any other role, such

as sensing functions.

• Energy constraints: The power of the batteries is limited in all the devices,

which does not allow infinitive operation time for the nodes. Therefore, energy should not

be wasted and that is why some energy conserving algorithms have been implemented

(COMPOW, PARO and MBCR are some examples).

• High latency: When an energy conserving design has been applied it means

that the nodes are sleeping or idle when they do not have to transmit any data. When the

data exchange between two nodes goes through nodes that are sleeping, the delay may be

higher if the routing algorithm decides that these nodes have to wake up.

• Transmission errors: Attenuation and interferences are other effects of the

wireless links that increase the error rate.

• Security: Analyses some of the vulnerabilities and attacks AHN’s can suffer.

The authors divide the possible attacks in passive ones, when the attacker only attempts to

discover valuable information by listening to the routing traffic; and active attacks, which

occur when the attacker injects arbitrary packets into the network with some proposal like

7
disabling the network. Other security issues such as availability, authenticity, integrity,

confidentiality and privacy are also have to be discussed

• Location: the addressing is the another problem for the network layer in

AHN’s, since the information about the location the IP addressing used in fixed networks

offers some facilities for routing that cannot be applied in AHN’s. The way of addressing

in AHN’s, of course, has nothing to do with the position of the node.

• Roaming: the continuous changes in the network connectivity graph involve

that the roaming algorithms of the fixed network are not applicable in AHN’s, because

they are based on the existence of guaranteed paths to some destinations.

• Commercially unavailable: AHN’s are yet far from being deployed on

large-scale commercial basis.

1.4 APPLICATIONS OF AD HOC NETWORKS

Once known the features of ad hoc networks, the examples of their potential

practical use are only limited by imagination. So, the set of applications for AHN’s is

diverse, from small, static networks that are constrained by power sources, to large-scale,

mobile, highly dynamic networks. Typical applications are those in which survivable

efficient and dynamic communications must be established. Some examples are:

• Conferences and meetings for a group of people with laptop computers that

may wish to exchange files and data without mediation of any additional infrastructure

between them.

• Home environment for communication between smart household appliances

can be hold by an AHN between the different devices, which may share control

information for their correct functioning. We can think in an AHN formed by our electrical

household appliances in the kitchen, the laptop computer, which can be moved arbitrarily,

8
the television set, the windows and doors, the air conditioning system, all together

communicated to automatically perform imaginative functions related with their control

and their relation with the user.

Figure 1.3 Ad Hoc networks can be very useful in emergency and rescue

operations

• Emergency search and rescue operations require quick and dynamic

communications, and with the assistance of AHN’s they could be developed in

inhospitable areas.

• AHN’s are suitable to be used in areas where earthquake or other natural

disasters have destroyed communication infrastructures. In this case, the rapid deployment

is a fundamental parameter, as well as the lack of necessity of any fixed infrastructure.

• AHN’s perfectly satisfy military needs like battlefield survivability,

operation without pre-placed infrastructure and connectivity beyond the LOS. Indeed, the

research about packet radio network started in a military context and nowadays, the

concept of Digital Battlefield is a burning topic.

9
 • For monitoring and measuring purposes a large number of small computing

devices could be spread over a geographical area (sensors scattering) to form a self-

sustained AHN. In this case one of the most important design criteria should be obtaining

the highest average life of the network, based on power consumption requirements, as well

as the need for scalability, provided that the number of sensors could be very high. Some

examples of this sort of applications could be:

 Military sensor networks to detect enemy movements, the presence of

dangerous material (such as poison gases or radiation), explosions, etc.

 Environmental sensor networks to detect and monitor environmental changes.

 Wireless traffic sensor networks to monitor vehicle traffic on a highway or in a

congested part of a city.

 Wireless surveillance sensor networks for providing security in a shopping

mall, parking garage, or other facility.

 Wireless parking sensor networks to determine which spots are occupied and

which spots are free.

This network could be useful, in addition to provide mobile Internet access to

allow consumer and business services, to mitigate urban traffic congestion through an area-

wide road pricing system.

1.5 ROUTING

1.5.1 Definition

Routing is the mechanism used in communications to find a path between two

entities. This is represented in the OSI model as the third layer (called Network). The role

of routing a network is similar to the role of a road map for a post office, in both cases; we

need to locate the destination, and more importantly, the best way to reach it.

10
 It especially has an important role, as the Internet was first designed for military

communications. Americans wanted a communication infrastructure able to handle the fact

that some part of a network core may be down. In this case, a mechanism should redirect

data to its destination.

As an OSI layer, this mechanism receives data “ready to send” from the upper

layer, then calculates the best path for the destination, and forwards it to layer 2. In the real

world, this layer has a very limited role for computers, but, it is the main role for routers, in

a network core.

For other kinds of network, there are similar mechanisms. For mobile phones, a

database centralises the base station where each mobile is connected. This database is used

for every call to a mobile phone, providing the end destination to the network core.

1.5.2 Routing in a wired environment

Routing has been designed firstly for a routing environment, where there is a

network core and network clients. In this case, routers use routing protocol to logically

locate themselves, and draw a network topology. With this mechanism, routers are able to

define a routing table. This routing table contains the information for helping the router to

make a decision on where to forward received packets.

Routing protocols helps to build routing tables, as these protocols exchange data

between routers, containing information about the network. Each protocol acts a different

way. The forwarding decision can be taken only depending on the number of hops, the

“shortest path”, or including more data for judging the best route, such as latency

congestion.

Routing protocols are often qualified depending on the size of information they

have to exchange in order to build a correct table. A routing protocol should not use by

11
itself the entire bandwidth available on a link. They are also qualified on how often they

have to exchange data, and how complex they are (just link state or using more information

on the link).

1.5.3 Routing problems in Ad Hoc networks

In infrastructure mode, the routing part is handled by the access point and the

distribution system; every wireless device just has to forward all its traffic to this access

point. But, in Ah Hoc networks, there is no “referee” for connections, and, every device

acts as a router.

This scenario is totally new. Adding to this, devices are not fixed, they can be

mobile, contrary to the Internet where every router has “fixed” neighbors (excepts if a link

goes down).

For solving this problem, the IETF (Internet Engineering Task Force), powerful

standardisation authority in the communication world, created the MANET work group.

This group has a mission to create and discuss routing protocols for Ad Hoc networks. This

task is very important, due to the complexity of routing on Ad Hoc networks.

The work started in January 1999, with the publication of the informational RFC

2501. This document presents the 4 main constraints for routing on Ad Hoc networks, such

as dynamics topology, bandwidth constraints, energy constraints and low physical security.

The group has then to comply with these constraints in order to build an efficient algorithm

of route calculation.
Routing Protocols

Latency Energy

Proactive Reactiv Hybrid

e
12
 Figure 1.4 Ad Hoc routing protocols design

1.6 AD HOC ROUTING PROTOCOLS

There were different approaches, and then, different solutions. The three mains

approaches are proactive protocols, reactive protocols and hybrids.

1.6.1 Proactive

Proactive protocols are close to wired routing protocols in the manner that the

routing table is built before the data has to be sent. That means these protocols are

constantly making requests to their neighbors (if any) in order to draw a network topology,

and then, build the routing table.

The disadvantage of this principle is to not be reactive to topology changes, as the

tables are pre-established. At the time the data has to be sent, it is not certain that the

gateway designed by the routing table will still be there to forward the data.

1.6.2 Reactive

Reactive protocols are more specific to Ad Hoc networks. Contrary to the proactive

algorithm, they ask their neighbors for a route when they have data to send. If the

neighbors do not have any known route, they broadcast the request, and so on. Once the

final destination has been reached by these broadcasts, an answer is built and forwarded

back to the source. This source can then transmit the data on the newly discovered route.

Each device used for forwarding the routing packets has learned the route at the same time.

The disadvantage of this design is the amount of routing traffic exchanged between

devices. In the case of a large topology, the traffic will be spread on each link until the end

node is found. It also can result in a high latency.

13
 1.6.3 Hybrid

A Hybrid protocol will use the two above algorithms. The main goal is to reduce

broadcasts and latency, but improve the dynamism impact. The whole network will be

separated into logical zones, and each zone will have a gateway. Inside each zone, a

reactive protocol will be used. For inter-zone routing, a proactive protocol will be used.

1.7 PRO-ACTIVE PROTOCOLS

As proactive protocols are constantly updating their routing tables in order to be

ready when data has to be sent, they are called table-driven protocols. This type of protocol

is close to wired networks where the same mechanisms are used in order to take routing

decisions. These mechanisms are used for finding the shortest path across the network

topology; it can be the “Link state” method or the “Distance Vector” method.

With the “Link State” method, each node has its own view of the network,

including the states of its own channels. When an event on the channel occurs, the node

floods the network topology with its own new view of the topology. Other nodes which

receive this information use algorithms to reflect changes on the network table.

With the “Distance Vector” routing approach, each node transmits to its close

nodes its vision of the distance which separates it from all the hosts of the network. Based

on the information received by the neighbourhood, each node performs a calculation in

order to define routing tables with the shortest path to all destinations available in the

network.

1.7.1OPTIMIZED LINKED STATE ROUTING (OLSR)

Optimized Link State Routing Protocol, OLSR, is another routing protocol

developed for mobile ad hoc networks. It is a proactive protocol, which means that the

mobile nodes exchange topology information with each other regularly.

14
 To keep the routing tables updated the network is flooded and every mobile node

receives the same message from each of its neighbors. Thus, bandwidth and energy are

wasted for useless messages. To avoid too many redundant retransmissions, the flooding

process is optimized in OLSR. In OLSR, only some selected nodes forward the broadcast

messages during the flooding process. These selected nodes are referred to as multipoint

relays (MPRs).

Algorithm

OLSR is using a state link routing protocol. It takes decisions based on the shortest

path, using the Dijkstra algorithm for calculating this shortest path. This algorithm is the

most used for state link routing. Also, a particularity of OLSR is to use a mechanism of

multipoint relays (MPR). Multipoint relays for a specific node are the only ones to forward

routing specific broadcasted messages, in order to reduce the amount of traffic exchanged

and duplicates data. As a proactive protocol, OLSR defines two ways to maintain and

update tables. First, OLSR acts for its neighborhood; it uses “HELLO” messages in order

to inform its neighbors about its current links states. These “HELLO” messages contain a

timeout, a hold time, and information about link status, such as symmetric, asymmetric or

MPR. In opposition to DSDV, it is not the routing table that is exchanged. OLSR will use

this data base on all neighbors received packets to modify and maintain the routing table.

These “HELLO” packets are broadcasted on a regular basis. OLSR also uses

“TOPOLOGY CONTROL” packets. This type of packet is event scheduled. Each node

which detects a change in its direct neighborhood will send this packet containing its

network address and a list of its MPR. This packet is used to inform other nodes of

topology changes. This will start a new route calculation process.

15
 Multipoint Relay (MPR)

The multipoint relay selection algorithm is based on a very simple rule. Each node

assigns a relay to a few of its direct neighbors, for covering every node at a two-hop

distance.

Figure 1.5 Relay Selection mechanisms

On figure 2-5, A has to choose relays for the network. Its direct neighbors are B, C,

D and E. The relay selection algorithm will check which one of these direct neighbors can

cover the two-hop distance one (F, G, H, I, J, K). In this case, B and E is the only nodes

able to cover these two-hop nodes for A, so, A will select them as primary relays. In the

end, the best neighbors are qualified depending on how many nodes they can cover. That

brings more effectiveness for the routing protocol by avoiding duplicate traffic. One of the

characteristics of this algorithm is that depending on the source node, relays of this source

can be different as soon as the multipoint rule is respected. This leads to a good traffic

distribution between each node. With OLSR, this relay selection avoids unnecessary

traffic, as only MPR can relay routing table updates.

16
 Figure 1.6 Example of traffic reduction using selected relays

Performance

OLSR increases performance comparing to DSDV, due to the multipoint relay

mechanism. This mechanism reduces the amount of data exchanged by avoiding useless

transmissions such as duplicates. MPR also reflects changes quicker in the topology by

reducing the route fluctuation impact in a mobile environment. So, compared to DSDV,

OLSR is quicker and uses less control traffic. But, on large topologies, OLSR is still

vulnerable to quick network changes.

1.8 REACTIVE PROTOCOLS

As covered in chapter 2, proactive protocols define a best path through the topology

for every available node. This route is saved even if not used. Permanently saving routes

cause a high traffic control on the topology, in particular in networks with a high number

of nodes. Reactive protocols are the most advanced design proposed for routing on Ad Hoc

networks. They define and maintain routes depending on needs. There are different

approaches for that, but most are using a backward learning mechanism or a source routing

mechanism.

17
 1.8.1 AD HOC ON-DEMAND DISTANCE VECTOR (AODV) ROUTING

PROTOCOL

Ad hoc On-Demand Distance Vector (AODV) is a distance vector routing protocol

that is reactive. The reactive property of the routing protocol implies that it only requests a

route when it needs one and does not require that the mobile nodes maintain routes to

destinations that are not communicating. AODV guarantees loop-free routes by using

sequence numbers.

AODV requires each node to maintain a routing table containing one route entry

for each destination that the node is communicating with. Each route entry keeps track of

certain fields. Some of these fields are:

Destination IP Address: The IP address of the destination for which a route is

supplied.

Destination Sequence Number: The destination sequence number associated to

the route.

Next Hop: Either the destination itself or an intermediate node designated to

forward Packets to the destination.

Hop Count: The number of hops from the Originator IP Address to the Destination

IP Address

Lifetime: The time in milliseconds for which nodes receiving the RREP consider

the route to be valid

Routing Flags: The state of the route; up (valid), down (not valid) or in repair

Route Discovery:

Whenever a source node desires a route to a destination node for which it

does not already have a route, it broadcasts a route request (RREQ) message to all its

18
neighbors. The neighbors update their information for the source and create reverse route

entries for the source node in their routing tables. A neighbor receiving a RREQ may send

a route reply (RREP) if it is either the destination or if it has an unexpired route to the

destination. If any of these two cases is satisfied, the neighbor unicasts a RREP back to the

source.

Along the path back to the source, intermediate nodes that receive the RREP create

forward route entries for the destination node in their routing tables. If none of the two

cases mentioned is satisfied, the neighbor rebroadcasts (forwards) the RREQ. Each mobile

node keeps a cache where it stores the source IP address and ID of the received RREQs

during the last PATH_DISCOVERY_TIME seconds. If a mobile node receives another

RREQ with the same source IP address and RREQ ID during this period, it is discarded.

Hence, duplicated RREQs are prevented and not forwarded.

Figure 1.7 AODV reverse path information

When searching for a route to the destination node, the source node uses the

expanding ring search technique to prevent unnecessary network-wide dissemination of

RREQs. This is done by controlling the value of the time to live (TTL) field in the IP

header. The first RREQ message sent by the source has TTL=TTL_START. The value of

TTL defines the maximal number of hops a RREQ can move through the mobile ad hoc

network, i.e. it decides how far the RREQ is broadcasted. In other words, it implies that the

19
RREQ which is broadcasted by the source is received only by mobile nodes TTL hops

away from the source.

Apart from setting the TTL, the timeout for receiving a RREP is also set. If the

RREQ times out without reception of a corresponding RREP, the source broadcasts the

RREQ again. This time TTL is incremented by TTL_INCREMENT, i.e. the TTL of the

second RREQ message is TTL_START + TTL_INCREMENT. This continues until a

RREP is received or until TTL reaches TTL_THRESHOLD. If TTL reaches

TTL_THRESHOLD a RREQ is sent with TTL=NET_DIAMETER, which disseminate the

RREQ widely, throughout the MANET. Broadcasting a RREQ with

TTL=NET_DIAMETER is referred to as a network-wide search. If a source node does a

network-wide search and still does not receive a RREP, it may try again to find a route to

the destination node, up to a maximum of RREQ_RETRIES times.

Route Maintenance

When a link in a route breaks, the node upstream of the break invalidates all its

routes that use the broken link. Then, the node broadcasts a route error (RERR) message to

its neighbors (TTL is set to one). The RERR message contains the IP address of each

destination which has become unreachable due to the link break. Upon reception of a

RERR message, a node searches its routing table to see if it has any route(s) to the

unreachable destination(s) which use the originator of the RERR as the next hop. If such

routes exist, they are invalidated and the node broadcasts a new RERR message to its

neighbors. This process continues until the source receives a RERR message. The source

invalidates the listed routes as previously described and reinitiates the route discovery

process if needed.

20
 Algorithm

The AODV algorithm is inspired from the Bellman-Ford algorithm like DSDV.

The principal change is to be On Demand. The node will be silent while it does not have

data to send. Then, if the upper layer is requesting a route for a packet, a “ROUTE

REQUEST” packet will be sent to the direct neighborhood. If a neighbor has a route

corresponding to the request, a packet “ROUTE REPLY” will be returned. This packet is

like a “use me” answer. Otherwise, each neighbor will forward the “ROUTE REQUEST”

to their own neighborhood, except for the originator and increment the hop value in the

packet data. They also use this packet for building a reverse route entry (to the originator).

This process occurs until a route has been found.

Another part of this algorithm is the route maintenance. While a neighbor is no

longer available, if it was a hop for a route, this route is not valid anymore. AODV uses

“HELLO” packets on a regular basis to check if they are active neighbors. Active

neighbors are the ones used during a previous route discovery process. If there is no

response to the “HELLO” packet sent to a node, then, the originator deletes all associated

routes in its routing table. “HELLO” packets are similar to ping requests. While

transmitting, if a link is broken (a station did not receive acknowledgment from the layer

2), a “ROUTE ERROR” packet is unicast to all previous forwarders and to the sender of

the packet.

21
 Illustration

Figure 1.8 Example of AODV route discovery

In the example illustrated by figure 2.8, A needs to send a packet to I. A “ROUTE

REQUEST” packet will be generated and sent to B and D (a). B and D add A in their

routing table, as a reverse route, and forward the “ROUTE REQUEST” packet to their

neighbors (b). B and D ignored the packet they exchanged each others (as duplicates). The

forwarding process continues while no route is known (c). Once I receive the “ROUTE

REQUEST” from G (d), it generates the “ROUTE REPLY” packet and sends it to the node

it received from. Duplicate packets continue to be ignored while the “ROUTE REPLY”

packet goes on the shortest way to A, using previously established reverse routes (e and f).

The reverse routes created by the other nodes that have not been used for the

“ROUTE REPLY” are deleted after a delay. G and D will add the route to I once they

receive the “ROUTE REPLY” packet.

22
 2. Literature survey

With the advent of new technologies and the demand for flexibility and ease in

working environment, the use of mobile wireless computing is growing fast. Beside their

use, mobile wireless networks are assumed to grow in size too. They can function in

independent groups, containing some tens of nodes up to several hundreds of nodes. As the

network size increases, it becomes common for the nodes to be dispersed in a larger area

than the radio range of individual nodes. Under such conditions, one has to employ routing

techniques such that the out of range nodes may communicate with each other via

intermediate nodes. This problem of routing in mobile ad hoc networks is our focus of our

project. The solution proposed is a new protocol.

Design issues for developing a routing protocol for wireless environment with

mobility are very different and more complex than those for wired networks with static

nodes. Major problems in mobile ad hoc network are (a) limited band width and (b) high

rate of topological changes. Thus the goal for a routing protocol is to minimize its control

traffic overhead while at the same time, it should be capable of rapidly adapting to link

failures and additions caused by node movements. It implies, therefore, that the routing

protocol should work in a distributed manner and it should be self starting and self

organizing. The possibility of ad hoc network to grow in size to have large diameters

brings with it the scaling up problem, possibility of loops in the routes, and inconsistency

of information in different parts of the network. Moreover, the existence of uni-directional

link is a real challenge for routing protocols.

Here we implement the proposed optimized link state routing protocol, named

OLSR, for mobile wireless networks in network simulator (we used NS 2.34). The protocol

is based on the link state algorithm and it is proactive (or table – driven) in nature. It

23
employs periodic exchange of messages to maintain topology information of the network

at each node. OLSR is an optimization over a pure link state protocol as it compacts the

size of information sent in messages, and furthermore, reduces the number of

retransmissions to flood these messages in entire network. For this purpose, the protocol

uses multipoint relaying technique to efficiently and economically flood its control

messages. It provides optimal routes in terms of number of hops, which are immediately

available when needed. The proposed protocol is best suitable for large and dense ad hoc

networks

The Efficient Routing in Real Time Networks with the help of implementing the

Optimized Link State Routing algorithm being simulated through the Network Simulator

(NS-2.34) available. In the simulation, all the characteristics like the packet dropping,

packet losses and packets received have been analyzed using the Xgraphs available in the

simulator. This simulation is shown in the Network Animator (NAM). This animator gives

the real time environment of the mobile ad-hoc network and the real time packet transfers

and droppings by the mobile nodes in the network. The details about the simulation,

simulation goals and the introduction about the simulation purpose are given below. The

simulation is done under the Linux environment (Ubuntu 10). It can also be done under the

Windows environment by creating a virtual Linux environment in the Windows working

space, so as to feel the Linux environment in Windows, for this purpose, Cygwin can be

used to provide the required Linux environment in Windows.

24
 3. SYSTEM ANALYSIS

Study and Analysis of routing algorithm

OLSR is a proactive routing protocol for mobile ad hoc networks. The protocol

inherits the stability of a link state algorithm and has the advantage of having the routes

immediately available when needed due to its proactive nature. OLSR is an optimization

over the pure link state protocol, tailored for mobile ad hoc networks.

1) It reduces the size of the control packets: rather than declaring all links, a node

declares only a subset of links with its neighbors, namely the links to those nodes which

are its multipoint relay selectors (see section 6 on Multipoint Relays).

2) OLSR minimizes flooding of control traffic by using only selected nodes, called

multipoint relays, to diffuse its messages. This technique significantly reduces the number

of retransmissions in a flooding or broadcast procedure.

3) OLSR provides support for protocol extensions such as sleep mode operation,

multicast-routing etc. Such extensions may be introduced as additions to the protocol

without breaking backwards compatibility with earlier versions.

4) OLSR performs hop by hop routing, i.e. each node uses its most recent

information to route the packet. Hence for OLSR to be able to route packets, the speed of

mobile nodes should be limited such that their movements can be tracked, at least by their

neighborhood.

25
3.1 REQUIREMENTS SPECIFICATION

3.1.1 Software Requirements:

Operating System

 Ubuntu 10.04

Simulator

 NS-2.34

• Scripting language

 TCL Scripting

Programming language

 C++

3.1.2 Hardware Requirements:

System Configuration

 Pentium IV Processor with 3.0 GHz Clock Speed 512 MB RAM, 80 GB

HDD.

26
 4. SYSTEM DESIGN

4.1 Algorithm Implementation for OLSR Algorithm

In this section we describe the details of the protocol functioning. This includes

descriptions of the contents of the packets being exchanged by routers, the algorithms (e.g.

for packet handling and routing table calculation) and suggested data structures internally

in each router.

4.2. Neighbor sensing

4.2.1 HELLO message broadcast

Each node should detect the neighbor nodes with which it has a direct and

symmetric link. The uncertainties over radio propagation may make some links

asymmetric. Consequently, all links MUST be checked in both directions in order to be

considered valid.

To accomplish this, each node broadcasts HELLO messages, containing

information about neighbors and their link status. The link status may either be

"symmetric", "heard" (asymmetric) or "MPR". "Symmetric" indicates that the link has

been verified to be bi-directional, i.e. it is possible to transmit data in both directions.

"Heard" indicates that the node is hearing from a neighbor, but it is not confirmed that this

neighbor is also hearing from the node. "MPR" indicates that a node is selected by the

sender as multipoint relay. MPR status implies that the link is symmetric too.

These control messages are broadcast to all one-hop neighbors, but are *not

relayed* to further nodes. A HELLO-message contains at a minimum:

- a list of addresses of neighbors, to which there exists a symmetric link;

- a list of addresses of neighbors, which have been "heard";

- a list of neighbors, which have been selected as multipoint relays.

27
 The list of neighbors in a HELLO message can be partial (e.g. due to message

size limitations, imposed by the network), the rule being that all neighbor nodes are cited

at least once within a predetermined refreshing period (HELLO_INTERVAL).

4.2.2 HELLO message processing

The HELLO messages permit each node to acquire information about its

neighborhood up to two hops. A node maintains a Neighbor table in which it records the

information (obtained from the HELLO messages) about its one hop neighbors, the status

of the link with these neighbors, a list of two hop neighbors that these one hop neighbors

give access to, and an associated holding time. The information is recorded in the Neighbor

table as a neighbor entry, with the following field names:

1. N_addr N_status N_2hop_list N_time

2. N_addr N_status N_2hop_list N_time

3. ,, ,, ,, ,,

Each entry in the table consists of N_addr, N_status, N_2hop_list, and N_time.

This specifies that the node with address N_addr is a one-hop neighbor to this node, the

status of the link between them is N_status, and this neighbor provides access to the two

hop neighbors listed in N_2hop_list. Each entry in N_2hop_list consists of a 2 hop

neighbor address and associated holding time. The N_status can be ASYM_LINK,

SYM_LINK or MPR_LINK. A link status of MPR_LINK implies that the link with the

neighbor node N_addr is symmetric *AND* the node N_addr is selected as a multipoint

relay by this node. Each neighbor entry has an associated holding time N_time, upon

expiration of which it is no longer valid and hence MUST be removed.

28
 The node also contains a sequence number N_MPR_seq. This specifies that the

node has selected its most recent MPR set with the sequence number N_MPR_seq. Every

time a node selects or updates its multipoint relay set, N_MPR_seq is incremented to a

higher value. This number is put into the HELLO messages.

Upon receiving a HELLO message, the node should update the neighbor entry

corresponding to the sender node address (a node may - e.g. for security reasons - wish to

restrict updating the neighbor-table, i.e. ignoring HELLO messages from some nodes):

1. If the entry already exists:

1.1 If the recipient of the HELLO has recorded the sender as asymmetric:

1.1.1 If the node finds its own address among the addresses listed in the

HELLO message (with Link Type ASYM_LINK, SYM_LINK or MPR_LINK), it updates

the status of the link to the sender node as SYM_LINK and refreshes the N_time to

NEIGHB_HOLDING_TIME.

1.1.2 Otherwise, if the node does not find its own address among the

addresses listed in the HELLO message, it refreshes the N_time to

NEIGHB_HOLDING_TIME.

1.2 Otherwise, if the recipient of the HELLO has recorded the sender as symetric

(or MPR):

1.2.1 if the node finds its own address among the addresses listed in the

HELLO message (with Link Type ASYM_LINK, SYM_LINK or MPR_LINK), it

refreshes the N_time to NEIGHB_HOLDING_TIME.

2. Otherwise, a new entry is recorded in the Neighbor table with:

- N_addr is set to the address of the sender node,

29
 - N_status is set to the value of SYM_LINK if the node finds its own address

(with Link Type ASYM_LINK, SYM_LINK or MPR_LINK) among the addresses listed

in the HELLO message, and to the value of ASYM_LINK otherwise

- N_time is set to the value of NEIGHB_HOLD_TIME

4.2.3 Multipoint relay selection

Each node in the network selects independently its own set of multipoint relays.

Multipoint relays are used to flood the control messages of that node into the network. The

MPR set is calculated in a way such that it contains a subset of one hop neighbors which

covers all the two hop neighbors. This means, that the union of the neighbor sets of all

MPRs contains the entire two hop neighbor set. In order to build the list of the two hop

nodes, make the union of N_2hop_lists of all neighbors (with Link Type SYM_LINK or

MPR_LINK), then remove from this union the one-hop neighbors (with Link Type

SYM_LINK or MPR_LINK), and finally remove the node itself. Multipoint relays of a

given node are declared in the subsequent HELLOs transmitted by this node, so that the

information reaches the multipoint relays themselves. These selected multipoint relays are

indicated in the HELLO messages with a link status of "MPR". The multipoint relay set is

re-calculated when:

- a change in the neighborhood is detected, i.e. either a symmetric link with a

neighbor is failed, or a new neighbor with a symmetric link is added; or

- a change is detected in the two-hop neighborhood such that a symmetric link

is either detected or broken between a two-hop neighbor and a neighbor.

We propose a heuristic for the selection of multipoint relays

[2]. We use the following terminology in describing this algorithm:

30
 MPR(x): Multipoint relay set of node x which is running this algorithm N(x):One

hop neighbor set of node x (containing only symmetric neighbors)

N2(x): Two hop neighbor set of node x (containing only symmetric

neighbors of nodes in N(x) ). The two hop neighbor set N2(x) of node x does not contain

any one hop neighbor of node x

D(x,y): Degree of one hop neighbor node y (where y is a member of N(x) ), is

defined as the number of symmetric one hop neighbors of node y EXCLUDING the node x

and all the symmetric one hop neighbors of node x, i.e.,

D(x,y) = number of elements of N(y) - {x} - N(x)

The proposed heuristic is as follows:

1. Start with an empty MPR(x)

2. Calculate D(x,y), where y is a member of N(x), for all nodes in N(x)

3. First select as MPRs those nodes in N(x) which provide the "only path" to

reach some nodes in N2(x)

4. While there still exist some nodes in N2(x) that are not covered by MPR(x):

4.1 For each node in N(x), calculate the number of nodes in N2(x) which are

not yet covered by MPR(x) and are reachable through this one hop neighbor;

4.2 Select as a MPR that node of N(x) which reaches the maximum number of

uncovered nodes in N2(x). In case of a tie, select that node as MPR whose D(x,y) is

greater.

5. To optimize, process each node y in MPR(x), one at a time, and if MPR(x) -

{y} still covers all nodes in N2(x) then remove y from MPR(x)

31
 After selecting the multipoint relays among the neighbors, the link status of the

corresponding one hop neighbors is changed from SYM_LINK to MPR_LINK in the

neighbor table. MPR_Seq_Num value in the Neighbor table is also incremented by one.

4.3 Multipoint relay information declaration

4.3.1. TC Message Broadcast

In order to build the topology information database needed for routing the packets,

each relay node broadcasts specific service messages called Topology Control (TC)

messages. TC messages are forwarded, like usual broadcast messages, to all nodes in the

network and take advantage of multipoint relays. Multipoint relays enable a better

scalability in the distribution of topology information.

A TC message is sent by a node in the network to declare its MPR Selector set. I.e.,

the TC message contains the list of neighbors which have selected the sender node as a

multipoint relay. The sequence number (MSSN) associated with this multipoint relay

selector set is also sent with the list. The list of addresses can be partial in each TC

message (e.g. due to message size limitations, imposed by the network), but parsing of all

TC messages describing a nodes MPR selector set MUST be complete within a certain

refreshing period (TC_INTERVAL). The information diffused in the network by these TC

messages will help each node to calculate its routing table. A node which has an empty

MPR Selector set, i.e. nobody has selected it as a multipoint relay, MUST NOT generate

any TC message.

A node MAY transmit additional TC-messages to increase its reactiveness to link

failures. I.e. when a change to the MPR selector set is detected and this change can be

attributed to a link failure, a TC-message SHOULD be transmitted after a shorter interval

than TC_INTERVAL.

32
 5. IMPLEMENTATION & SIMULATION

In the previous chapters, we have given detailed explanation of our Optimized Link

State Routing Algorithm and its implementation. In this chapter, we give the

implementation details of our scheme in ns2 simulator. We also present our simulation

environment and results. The simulation results presented are analyzed in the last section.

We have added the UM-OLSR patch that is compatible with the ns-2.34 version.

By adding this patch to this simulator, OLSR also becomes a part of the ns-2.34 allinone

package along with many other routing protocols like AODV, DSR, TORA.

Now, we write a simulation script that makes use of this OLSR protocol and routes

the packets in the region based on the implementation of OLSR. This simulation script will

be written in tcl (Tool Command Language) and all the compiler code of ns-2.34 and the

patch code will be written in C++.

5.1 Simulation Environment

All the simulations are done in ns-2. The simulation parameters are chosen such

that they can resemble a real environment. The performance of any network layer routing

protocol is measured in terms of Packet Loss Ratio, End to End Delay and Average

Throughput. The above parameters have been measured for 5 nodes with pause time

varying from 0-100sec in an area of 600x800 for 60secs. The CBR sources and

destinations (10 CBRsources/50 nodes) were spread randomly over the network. Packet

size was set to 512 bytes with a rate of 4 packets per second. In order to measure the index

distribution cost, we have simulated a scenario in which each node can share a maximum

of 50 data items or files and the indices are generated using a pseudo random number

generator available in ns-2. The performance has been compared with standard routing

protocols like DSDV (proactive routing protocol) and AODV (reactive routing protocol)

33
whose implementations are available in ns-2. So we executed the ns-2 code of AODV,

DSDV and our protocol for the results. The results are plotted in the graphs given below

the mobile nodes were placed in a 1000x1000 m at grid.

5.2 Simulation parameters:

Table 5.1 simulation parameters & values

Parameters Values

o.
Area 600x800, 1000x1000
Transmission Range 250m
Nodes 5
Pause time 0, 10 sec
Mobility 0-20m/s
No of files shared by a node 0-50
Simulation time 60 sec

5.3 Trace

Trace files are the output we get after running a smiluation script in ns2. This file

gives us the detailed information about the various packets transmitted from each node at

every point of time all over the simulation is running. S- sender, r- receivre, ACK-

34
acknowledgement packet. The packets vary depending on the kind of protocol we are

running.

5.3.1 AODV:

This is an extract from the trace file for AODV protocol

s 0.000050000 _1_ AGT --- 0 tcp 40 [0 0 0 0] ------- [1:0

3:0 32 0] [0 0] 0 0
s 0.000425000 _1_ MAC --- 0 AODV 106 [0 ffffffff 1 800]
------- [1:255 -1:255 30 0] [0x2 1 1 [3 0] [1 4]] (REQUEST)
s 0.000550000 _2_ AGT --- 1 tcp 40 [0 0 0 0] ------- [2:0
3:0 32 0] [0 0] 0 0
r 0.001273126 _2_ MAC --- 0 AODV 48 [0 ffffffff 1 800]
------- [1:255 -1:255 30 0] [0x2 1 1 [3 0] [1 4]] (REQUEST)
r 0.001273159 _0_ MAC --- 0 AODV 48 [0 ffffffff 1 800]
------- [1:255 -1:255 30 0] [0x2 1 1 [3 0] [1 4]] (REQUEST)
r 0.001273163 _3_ MAC --- 0 AODV 48 [0 ffffffff 1 800]
------- [1:255 -1:255 30 0] [0x2 1 1 [3 0] [1 4]] (REQUEST)
s 0.001593163 _3_ MAC --- 0 ARP 86 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.002281258 _2_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.002281326 _1_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.002281353 _0_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
s 0.002391258 _2_ MAC --- 0 AODV 106 [0 ffffffff 2 800]
------- [2:255 -1:255 30 0] [0x2 1 1 [3 0] [2 4]] (REQUEST)
r 0.003239353 _0_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 30 0] [0x2 1 1 [3 0] [2 4]] (REQUEST)
r 0.003239353 _3_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 30 0] [0x2 1 1 [3 0] [2 4]] (REQUEST)
r 0.003239385 _1_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 30 0] [0x2 1 1 [3 0] [2 4]] (REQUEST)
s 0.003509385 _1_ MAC --- 0 RTS 44 [52e 3 1 0]
r 0.003861548 _3_ MAC --- 0 RTS 44 [52e 3 1 0]
s 0.003871548 _3_ MAC --- 0 CTS 38 [3f4 1 0 0]
r 0.004175711 _1_ MAC --- 0 CTS 38 [3f4 1 0 0]
s 0.004185711 _1_ MAC --- 0 ARP 86 [13a 3 1 806] -------
[REPLY 1/1 3/3]
r 0.004873874 _3_ MAC --- 0 ARP 28 [13a 3 1 806] -------
[REPLY 1/1 3/3]
s 0.004883874 _3_ MAC --- 0 ACK 38 [0 1 0 0]
s 0.005050000 _0_ AGT --- 2 tcp 40 [0 0 0 0] ------- [0:0
3:0 32 0] [0 0] 0 0
r 0.005188037 _1_ MAC --- 0 ACK 38 [0 1 0 0]
s 0.005257969 _2_ MAC --- 0 AODV 106 [0 ffffffff 2 800]
------- [2:255 -1:255 29 0] [0x2 2 1 [3 0] [1 4]] (REQUEST)
r 0.006106064 _0_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 29 0] [0x2 2 1 [3 0] [1 4]] (REQUEST)

35
 r 0.006106064 _3_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 29 0] [0x2 2 1 [3 0] [1 4]] (REQUEST)
r 0.006106096 _1_ MAC --- 0 AODV 48 [0 ffffffff 2 800]
------- [2:255 -1:255 29 0] [0x2 2 1 [3 0] [1 4]] (REQUEST)
s 0.006216064 _3_ MAC --- 0 ARP 86 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/2]
r 0.006904159 _2_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/2]
r 0.006904227 _1_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/2]
r 0.006904254 _0_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/2]
s 0.007034254 _0_ MAC --- 0 AODV 106 [0 ffffffff 0 800]
------- [0:255 -1:255 29 0] [0x2 2 1 [3 0] [2 4]] (REQUEST)
r 0.007882349 _2_ MAC --- 0 AODV 48 [0 ffffffff 0 800]
------- [0:255 -1:255 29 0] [0x2 2 1 [3 0] [2 4]] (REQUEST)
r 0.007882413 _1_ MAC --- 0 AODV 48 [0 ffffffff 0 800]
------- [0:255 -1:255 29 0] [0x2 2 1 [3 0] [2 4]] (REQUEST)
r 0.007882444 _3_ MAC --- 0 AODV 48 [0 ffffffff 0 800]
------- [0:255 -1:255 29 0] [0x2 2 1 [3 0] [2 4]] (REQUEST)
s 0.008012444 _3_ MAC --- 0 RTS 44 [5ae 1 3 0]
r 0.008364607 _1_ MAC --- 0 RTS 44 [5ae 1 3 0]
s 0.008374607 _1_ MAC --- 0 CTS 38 [474 3 0 0]
r 0.008678770 _3_ MAC --- 0 CTS 38 [474 3 0 0]
s 0.008688770 _3_ MAC --- 0 AODV 102 [13a 1 3 800] -------
[3:255 1:255 30 1] [0x4 1 [3 4] 10.000000] (REPLY)
r 0.009504934 _1_ MAC --- 0 AODV 44 [13a 1 3 800] -------
[3:255 1:255 30 1] [0x4 1 [3 4] 10.000000] (REPLY)
s 0.009514934 _1_ MAC --- 0 ACK 38 [0 3 0 0]
r 0.009819097 _3_ MAC --- 0 ACK 38 [0 3 0 0]
s 0.009889060 _2_ MAC --- 0 RTS 44 [52e 3 2 0]
r 0.010241155 _3_ MAC --- 0 RTS 44 [52e 3 2 0]
s 0.010251155 _3_ MAC --- 0 CTS 38 [3f4 2 0 0]
r 0.010555250 _2_ MAC --- 0 CTS 38 [3f4 2 0 0]
s 0.010565250 _2_ MAC --- 0 ARP 86 [13a 3 2 806] -------
[REPLY 2/2 3/3]

5.3.2 DSDV

s 0.000050000 _1_ AGT --- 0 tcp 40 [0 0 0 0] ------- [1:0

3:0 32 0] [0 0] 0 0
s 0.000550000 _2_ AGT --- 1 tcp 40 [0 0 0 0] ------- [2:0
3:0 32 0] [0 0] 0 0
s 0.005050000 _0_ AGT --- 2 tcp 40 [0 0 0 0] ------- [0:0
3:0 32 0] [0 0] 0 0
s 0.184845103 _0_ MAC --- 3 message 90 [0 ffffffff 0 800]
------- [0:255 -1:255 32 0]
r 0.185565198 _2_ MAC --- 3 message 32 [0 ffffffff 0 800]
------- [0:255 -1:255 32 0]
r 0.185565262 _1_ MAC --- 3 message 32 [0 ffffffff 0 800]
------- [0:255 -1:255 32 0]
r 0.185565293 _3_ MAC --- 3 message 32 [0 ffffffff 0 800]
------- [0:255 -1:255 32 0]

36
 s 0.634901779 _3_ MAC --- 4 message 90 [0 ffffffff 3 800]
------- [3:255 -1:255 32 0]
r 0.635621874 _2_ MAC --- 4 message 32 [0 ffffffff 3 800]
------- [3:255 -1:255 32 0]
r 0.635621942 _1_ MAC --- 4 message 32 [0 ffffffff 3 800]
------- [3:255 -1:255 32 0]
r 0.635621969 _0_ MAC --- 4 message 32 [0 ffffffff 3 800]
------- [3:255 -1:255 32 0]
s 0.635861969 _0_ MAC --- 0 DSDV 86 [0 ffffffff 0 806]
------- [REQUEST 0/0 0/3]
r 0.636550064 _2_ MAC --- 0 ARP 28 [0 ffffffff 0 806]
------- [REQUEST 0/0 0/3]
r 0.636550127 _1_ MAC --- 0 ARP 28 [0 ffffffff 0 806]
------- [REQUEST 0/0 0/3]
r 0.636550159 _3_ MAC --- 0 ARP 28 [0 ffffffff 0 806]
------- [REQUEST 0/0 0/3]
s 0.636680127 _1_ MAC --- 0 ARP 86 [0 ffffffff 1 806]
------- [REQUEST 1/1 0/3]
r 0.637368254 _2_ MAC --- 0 DSDV 28 [0 ffffffff 1 806]
------- [REQUEST 1/1 0/3]
r 0.637368286 _0_ MAC --- 0 ARP 28 [0 ffffffff 1 806]
------- [REQUEST 1/1 0/3]
r 0.637368290 _3_ MAC --- 0 ARP 28 [0 ffffffff 1 806]
------- [REQUEST 1/1 0/3]
s 0.637538254 _2_ MAC --- 0 ARP 86 [0 ffffffff 2 806]
------- [REQUEST 2/2 0/3]
r 0.638226349 _0_ MAC --- 0 ARP 28 [0 ffffffff 2 806]
------- [REQUEST 2/2 0/3]
r 0.638226349 _3_ MAC --- 0 ARP 28 [0 ffffffff 2 806]
------- [REQUEST 2/2 0/3]
r 0.638226380 _1_ MAC --- 0 ARP 28 [0 ffffffff 2 806]
------- [REQUEST 2/2 0/3]
s 0.638436349 _3_ MAC --- 0 DSDV 44 [52e 0 3 0]
r 0.638788539 _0_ MAC --- 0 RTS 44 [52e 0 3 0]
s 0.638798539 _0_ MAC --- 0 CTS 38 [3f4 3 0 0]
r 0.639102729 _3_ MAC --- 0 CTS 38 [3f4 3 0 0]
s 0.639112729 _3_ MAC --- 0 ARP 86 [13a 0 3 806] -------
[REPLY 3/3 0/0]
r 0.639800919 _0_ MAC --- 0 ARP 28 [13a 0 3 806] -------
[REPLY 3/3 0/0]
s 0.639810919 _0_ MAC --- 0 ACK 38 [0 3 0 0]
r 0.640115109 _3_ MAC --- 0 ACK 38 [0 3 0 0]
s 0.640284919 _0_ MAC --- 0 RTS 44 [6ce 3 0 0]
r 0.640637109 _3_ MAC --- 0 RTS 44 [6ce 3 0 0]
s 0.640647109 _3_ MAC --- 0 CTS 38 [594 0 0 0]
r 0.640951299 _0_ MAC --- 0 CTS 38 [594 0 0 0]
s 0.640961299 _0_ MAC --- 2 DSDV 138 [13a 3 0 800] -------
[0:0 3:0 32 3] [0 0] 0 0
r 0.642065489 _3_ MAC --- 2 tcp 80 [13a 3 0 800] -------
[0:0 3:0 32 3] [0 0] 1 0
s 0.642075489 _3_ MAC --- 0 ACK 38 [0 0 0 0]
r 0.642090489 _3_ AGT --- 2 tcp 80 [13a 3 0 800] -------
[0:0 3:0 32 3] [0 0] 1 0

37
 5.3.3 DSR

Sconfig 0.00000 tap: on snoop: rts? on errs? on

Sconfig 0.00000 salvage: on !bd replies? on
Sconfig 0.00000 grat error: on grat reply: on
Sconfig 0.00000 $reply for props: on ring 0 search: on
Sconfig 0.00000 using MOBICACHE
s 0.000050000 _1_ AGT --- 0 tcp 40 [0 0 0 0] ------- [1:0
3:0 32 0] [0 0] 0 0
s 0.000550000 _2_ AGT --- 2 tcp 40 [0 0 0 0] ------- [2:0
3:0 32 0] [0 0] 0 0
s 0.003331018 _2_ MAC --- 3 DSR 90 [0 ffffffff 2 800]
------- [2:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.004051113 _0_ MAC --- 3 DSR 32 [0 ffffffff 2 800]
------- [2:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.004051113 _3_ MAC --- 3 DSR 32 [0 ffffffff 2 800]
------- [2:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.004051144 _1_ MAC --- 3 DSR 32 [0 ffffffff 2 800]
------- [2:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
s 0.005050000 _0_ AGT --- 5 tcp 40 [0 0 0 0] ------- [0:0
3:0 32 0] [0 0] 0 0
s 0.007306454 _0_ MAC --- 6 DSR 90 [0 ffffffff 0 800]
------- [0:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.008026549 _2_ MAC --- 6 DSR 32 [0 ffffffff 0 800]
------- [0:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.008026613 _1_ MAC --- 6 DSR 32 [0 ffffffff 0 800]
------- [0:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.008026644 _3_ MAC --- 6 DSR 32 [0 ffffffff 0 800]
------- [0:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
s 0.008529761 _1_ MAC --- 1 DSR 90 [0 ffffffff 1 800]
------- [1:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.009249887 _2_ MAC --- 1 DSR 32 [0 ffffffff 1 800]
------- [1:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.009249919 _0_ MAC --- 1 DSR 32 [0 ffffffff 1 800]
------- [1:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.009249924 _3_ MAC --- 1 DSR 32 [0 ffffffff 1 800]
------- [1:255 3:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
s 0.009459924 _3_ MAC --- 0 ARP 86 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/0]
r 0.010148019 _2_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/0]
r 0.010148087 _1_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/0]
r 0.010148114 _0_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/0]
s 0.010403114 _0_ MAC --- 0 RTS 44 [52e 3 0 0]
r 0.010755304 _3_ MAC --- 0 RTS 44 [52e 3 0 0]
s 0.010765304 _3_ MAC --- 0 CTS 38 [3f4 0 0 0]
r 0.011069494 _0_ MAC --- 0 CTS 38 [3f4 0 0 0]
s 0.011079494 _0_ MAC --- 0 ARP 86 [13a 3 0 806] -------
[REPLY 0/0 3/3]

38
 r 0.011767684 _3_ MAC --- 0 ARP 28 [13a 3 0 806] -------
[REPLY 0/0 3/3]
s 0.011777684 _3_ MAC --- 0 ACK 38 [0 0 0 0]
r 0.012081874 _0_ MAC --- 0 ACK 38 [0 0 0 0]
s 0.012251684 _3_ MAC --- 0 ARP 86 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.012939779 _2_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.012939847 _1_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
r 0.012939874 _0_ MAC --- 0 ARP 28 [0 ffffffff 3 806]
------- [REQUEST 3/3 0/1]
s 0.013009684 _3_ MAC --- 0 RTS 44 [5ae 0 3 0]
r 0.013361874 _0_ MAC --- 0 RTS 44 [5ae 0 3 0]
s 0.013371874 _0_ MAC --- 0 CTS 38 [474 3 0 0]
r 0.013676064 _3_ MAC --- 0 CTS 38 [474 3 0 0]
s 0.013686064 _3_ MAC --- 7 DSR 102 [13a 0 3 800] -------
[3:255 0:255 254 0] 2 [0 1] [1 1 2 0->3] [0 0 0 0->0]
r 0.014502254 _0_ MAC --- 7 DSR 44 [13a 0 3 800] -------
[3:255 0:255 254 0] 2 [0 1] [1 1 2 0->3] [0 0 0 0->0]
s 0.014512254 _0_ MAC --- 0 ACK 38 [0 3 0 0]
SFESTs 0.014527254 _0_ 5 [0 -> 3] 1(1) to 3 [0 |3 ]
r 0.014816443 _3_ MAC --- 0 ACK 38 [0 3 0 0]
s 0.014946254 _0_ MAC --- 0 RTS 44 [6ae 3 0 0]
r 0.015298443 _3_ MAC --- 0 RTS 44 [6ae 3 0 0]

5.3.4 OLSR

s 0.017208489 _22_ MAC --- 1 90 [0 ffffffff 16 800] -------

[22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928537 _21_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928537 _23_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928584 _20_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928631 _19_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928678 _18_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928678 _24_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _17_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _16_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _14_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _13_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _12_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]

39
 r 0.017928725 _11_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _10_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _9_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _8_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _7_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _6_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _5_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _4_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _3_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _2_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _1_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928725 _0_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
r 0.017928774 _15_ MAC --- 1 OLSR 32 [0 ffffffff 16 800]
------- [22:255 9:255 32 0] 1 [1 1] [0 1 0 0->0] [0 0 0 0->0]
s 0.022343916 _9_ MAC --- 0 ARP 86 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _8_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _7_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _6_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _5_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _4_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _3_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _2_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _1_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _0_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _10_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _11_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _12_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]

40
 r 0.023031916 _13_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _14_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _16_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031916 _17_ MAC --- 0 ARP 28 [0 ffffffff 9 806]
------- [REQUEST 9/9 0/22]
r 0.023031963 _18_ MAC --- 0 ARP 28 [0 ffffffff 9 806]

5.4 Sample Output

Screen showing the deployment of 24 mobile nodes on 600X800:

Fig 5.4.1

Screen shown the beginning of the simulation from the node 0 . :

41
 Fig 5.4.2

First level of MPR is selected:

Fig 5.4.3

Screens showing the selection of MPR’s at various levels. :

42
 Fig 5.4.4

Screen shown data forwarding:

Fig 5.4.5

Packets are forwarded to destination node(23):

43
 Fig 5.4.6

Screens showing the packet exchange between the final MPR and the node it

chooses to send the packets to.

5.5 Xgraph Visualization

The nodes in the MANET boot up at random locations and move using the random

waypoint mobility model defined in ns-2. We conducted simulation to evaluate the

performance of Optimized Link State Routing Protocol (OLSR).

44
45
 6. CONCLUSION

In this project, a novel routing protocol OLSR is considered to reduce the number

of retransmissions used to transfer a packet in a MANET. The contribution of this work is

its exploratory study on reducing the delay in topology discovery and dissemination by

exploiting the organizational structure of clusters. Simulation result has shown that OLSR

has good scalability and better performance than existing protocols in highly mobile

heterogeneous MANET. Hence, OLSR serves as a proof-of-concept and shows a possible

direction to improve the performance of routing protocol for highly mobile heterogeneous

MANET.

46
 REFERENCES

[1]. P. Jacquet, P. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum, and L. Viennot,

“Optimized link state routing protocol for ad hoc networks,” Multi Topic Conference,

2001. IEEE INMIC 2001. Technology for the 21st Century. Proceedings. IEEE

International, pp. 62–68, 2001.

[2]. C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced

distance-vector routing (dsdv) for mobile computers,” SIGCOMM Comput. Commun.

Rev., vol. 24, no. 4, pp. 234–244, 1994.

[3]. K. Xu, X. Hong, and M. Gerla, “An ad hoc network with mobile backbones,”

Communications, 2002. ICC 2002. IEEE International Conference on, vol. 5, pp. 3138–

3143 vol.5, 2002.

[4]. C. Perkins, E. Belding-Royer, and S. Das, “Ad hoc On-Demand Distance

Vector (AODV) Routing,” RFC 3561 (Experimental), Jul. 2003. [Online]. Available:

http://www.ietf.org/rfc/rfc3561.txt

[5]. E. H.-K. Wu and Y.-Z. Huang, “Dynamic adaptive routing for a heterogeneous

wireless network,” Mob. Netw. Appl., vol. 9, no. 3, pp. 219–233, 2004.

[6]. NS-2 software and documents from http://www.isi.edu/nsnam

47
 Appendix A

A. Network Simulator (NS)

The network simulator (NS), which is a discrete event simulator for networks, is a

simulated program developed by VINT (Virtual Internet work Test bed) project group (A

Collaboration among USC/ISI, Xerox PARC, LBNL, and UCB). It supports simulations of

TCP and UDP, some of MAC layer protocols, various routing and multicast protocols over

both wired and wireless network etc. The basic structure of NS-2 is:

NS-2

Simulation OTcl Simulation

OTcl Script Interpreter Results

C++
Libraries

Figure A.1 structure of NS

To setup and run a simulation, a user writes an OTcl script, which is a simulation

program to initiate an event scheduler, set up the network topology using the network

objects and plumbing functions in the library, and to tell traffic sources when to start and

stop transmitting packets through the event scheduler. When NS-2 that works as OTcl

interpreter receives the Otcl script, it will set environment parameters following the

received script. If a user wants to make a new network object, it will be easy to make a

compound object from the object library, and plumb the data path through the object rather

48
than write a new one. When the simulation is finished, the simulation results are produced

in one or more text-based output files that contain detailed simulation data, which can be

used to analyze directly or can be used in the graphical user interface “Network Animator

(NAM)”. This graphical user interface shows the simulation result in an easy way.

B. OTcl Linkage

NS is an object-oriented simulator, written in C++, with an OTcl interpreter as a

front-end. The simulator supports a class hierarchy in C++ (also called the compiled

hierarchy in this document), and a similar class hierarchy within the OTcl interpreter (also

called the interpreted hierarchy in this document). The two hierarchies are closely related

to each other; from the user’s perspective, there is a one-to-one correspondence between a

class in the interpreted hierarchy and one in the compiled hierarchy. The root of this

hierarchy is the class TclObject. Users create new simulator objects through the interpreter;

these objects are instantiated within the interpreter, and are closely mirrored by a

corresponding object in the compiled hierarchy. The interpreted class hierarchy is

automatically established through methods defined in the class TclClass. User instantiated

objects are mirrored through methods defined in the class TclObject. There are other

hierarchies in the C++ code and OTcl scripts; these other hierarchies are not mirrored in

the manner of TclObject.

B.1. Concept Overview:

Why two languages? ns 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

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

Which language for what? Having two languages raises the question of which

language should be used for what purpose.

Our basic advice is to use OTcl:

• For configuration, setup, and “one-time” stuff

• If you can do what you want by manipulating existing C++ objects and use C++:

• If you are doing anything that requires processing each packet of a flow

• If you have to change the behavior of an existing C++ class in ways that weren’t

anticipated

For example, links are OTcl objects that assemble delay, queuing, and possibly loss

modules. If your experiment can be done with those pieces, great. If instead you want do

something fancier (a special queuing discipline or model of loss), then you’ll need a new

C++ object.

50
 There are certainly gray areas in this spectrum: most routing is done in OTcl

(although the core Dijkstra algorithm is in C++). We’ve had HTTP simulations where each

flow was started in OTcl and per-packet processing was all in C++. This approach worked

OK until we had 100s of flows starting per second of simulated time. In general, if you

ever have to invoke Tcl many times per second, you probably should move that code to C+

+.

B.2. Code Overview

In this document, we use the term “interpreter” to be synonymous with the OTcl

interpreter. The code to interface with the interpreter resides in a separate directory, tclcl.

The rest of the simulator code resides in the directory, ns-2. We will use the notation

~tclcl/hfilei to refer to a particular hfilei in the Tcl directory. Similarly, we will use the

notation, ~ns/hfilei to refer to a particular hfilei in the ns-2 directory.

There are a number of classes defined in ~tclcl/. We only focus on the six that are

used in ns: The Class Tcl contains the methods that C++ code will use to access the

interpreter. The class TclObject is the base class for all simulator objects that are also

mirrored in the compiled hierarchy. The class TclClass defines the interpreted class

hierarchy, and the methods to permit the user to instantiate TclObjects. The class

TclCommand is used to define simple global interpreter commands. The class

EmbeddedTcl contains the methods to load higher-level built-in commands that make

configuring simulations easier. Finally, the class InstVar contains methods to access C++

member variables as OTcl instance variables.

51
C. Screen shot of NS-2 simulation with NAM:

Figure A.2 Screenshot of a NAM window explaining the most important functions.

52