Sunteți pe pagina 1din 35

Routing in Mobile ad ho

networks
Srinath Perur

20th February 2001


Abstra t
Mobile ad ho networks are infrastru ture-less, wireless networks of mobile nodes that are formed

dynami ally without mu h set up time or ost. They are used where ommuni ations infrastru ture

is unavailable or infeasible to use, as in battleeld or disaster relief operations. Routing in su h

ad-ho networks is an issue sin e node mobility makes the network topology highly dynami .

This thesis surveys some of the work done in the area of ad ho routing and proposes Kelpi, a

new routing algorithm. Kelpi is based on the observation that with most routing algorithms, an

intermediate node's movement ould ause routes between distant nodes to be ae ted. Kelpi is

designed to maintain stable routes that form a dynami virtual ba kbone in an ad ho network.

The prin iple behind this is to keep routing information onned to a geographi al area despite

nodes being mobile. This is done by imposing a ellular stru ture on the ad ho network using an

a urate positioning servi e at every node. Kelpi also aims to in rease link-layer throughput by

using multiple levels of transmission power to redu e radio interferen e.

An implementation of Kelpi for the Network Simulator ns-2 is des ribed.


Contents

1 Introdu tion 4
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Mobile ad ho networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 S ope of this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Related Work 7
2.1 Rea tive algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Dynami Sour e Routing (DSR) . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Ad-ho On-Demand Distan e Ve tor Routing . . . . . . . . . . . . . . . . 9

2.1.3 Temporally Ordered Routing Algorithm (TORA) . . . . . . . . . . . . . . 9

2.1.4 Asso iativity Based Routing (ABR) . . . . . . . . . . . . . . . . . . . . . . 9

2.1.5 Signal Stability Routing (SSR) . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Pro-a tive algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Destination Sequen ed Distan e Ve tor Routing (DSDV) . . . . . . . . . . 10

2.2.2 Clusterhead Gateway Swit h Routing (CGSR) . . . . . . . . . . . . . . . . 12

2.3 Hybrid Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Pro-a tive vs. Rea tive routing . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 Zone Routing Proto ol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Lo ation based algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Lo ation Aided Routing (LAR) . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Kelpi: An overview 14
3.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Prin iple of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 Node-Router ommuni ation . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3 Router-Router ommuni ation . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.4 Node-Node ommuni ation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2
3.2.5 An example of routing using Kelpi . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Kelpi: Details 20
4.1 Data Stru tures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.1 Events at a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.2 Events at the router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4 Ex eption Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Simulation 27
5.1 Introdu tion to ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 ns framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.2 Wireless support in ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.3 Pa ket Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Kelpi: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.1 Preliminary modi ations to ns-2 . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.2 Modi ations to the ns-2 pa ket header . . . . . . . . . . . . . . . . . . . . 29

5.2.3 Implementation of data stru tures . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.4 Implementation of Cell Router Address . . . . . . . . . . . . . . . . . . . . 30

5.2.5 Implementation of multi-powered network interfa e . . . . . . . . . . . . . . 30

5.2.6 Current implementation status . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Con lusion 32
6.1 Future dire tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3
Chapter 1

Introdu tion

1.1 Context

Sin e the advent of omputing, advan es in te hnology have onstantly been making omputers

smaller, heaper and more powerful than before. This has had an impa t on the way we use

omputers. Mobile omputing has gained in reasing popularity in the last de ade or so due to the

availaibility of small, e onomi al and portable omputers. Minituarization has allowed devi es to

have omputers embedded within them to automate their ontrol. These trends seem to indi ate

that we are moving towards a s enario where we will have a large number of mobile, wirelessly

networked omputers in use around us.

The traditional way of enabling wireless networking has been to use a ellular infrastru ture.

The mobile user registers with a servi e provider who maintains a number of base stations over a

xed area of operation. Ea h of these base stations handles ommuni ations with mobile devi es

in its ' ell', that is, the region over whi h it an send or re eive a radio transmission. These base

stations in turn are onne ted with a xed network, enabling ommuni ation between devi es in

dierent ells. While this onstitutes a fairly reliable means af providing networking to mobile

hosts, it has its drawba ks in requiring large expenditure on infrastru ture. Further, this kind

of servi e is restri ted to areas where the supporting infrastru ture exists: where it is viable,

physi ally and e onomi ally, to establish the required infrastru ture.

In the emerging s enario mentioned above, it may not always be desirable to depend on su h a

ellular infrastru ture. Situations an arise where it would be useful to network mobile omputers,

but there is no existing infrastru ture. Typi al examples in lude battleeld or disaster relief

operations where su h support either does not exist or has been destroyed. Other examples

in lude a meeting of people with mobile hosts, in whi h ase, the people involved may not want

to use a ellular system be ause the ost involved in setting up and using su h a fa ility might

outweigh the benets of using the network for their spe i task.

An alternate approa h to network mobile omputers, without establishing a ommuni ations

infrastru ture, is the mobile ad ho network.

4
1.2 Mobile ad ho networks

An ad ho network is the o-operative engagement of a olle tion of mobile hosts

without the required intervention of any entralized a ess point [1.

Mobile Ad ho NETworks (MANETs) are infrastru ture-less wireless networks where nodes are

apable of moving. They are formed arbitrarily and dynami ally without mu h set up time or

ost. Generally, some or all nodes of a MANET fun tion as routers and ommuni ation between

two hosts is done by multi-hop routing through the nodes of the network. This is required be ause

nodes whi h want to ommuni ate may not be within dire t radio range of ea h other. The nodes

in su h a network work together to dis over and maintain routes between hosts in the network.

Some hara teristi s of MANETs are:

 Dynami topology

Dire t links between nodes an be broken and reformed rapidly due to mobility.

As a result, the topology of the network hanges very frequently in omparision with

wired networks, where topology hange is generally due to o asional link failure or

link re-establishment.

 Constrained power

Often, the nodes in a MANET are battery operated devi es and need to onserve

power in order to remain operational for as long as possible.

 Uni-dire tional links

Due to a dieren e in radio transmission powers, a node may be able to re eive

from a parti ular node, but not send to it.

1.2.1 Routing
Routing in a network deals with the task of nding a path through the network between a given

pair of nodes. A sour e wanting to send a pa ket to a parti ular destination sends the pa ket to

a neighbouring node with a route to the destination. This node in turn sends the pa ket to the

next-hop on the route, and so on, till the destination is rea hed.

Routing in wired networks


Several routing proto ols exist for wired networks. Almost all an be lassied as using either the

distan e ve tor or the link-state algorithms. In distan e ve tor routing [2, ea h router periodi ally
sends its view of its distan e from every other node in the network to its neighbours. Based on

this information, ea h router al ulates its next-hop neighbours along the shortest path to every

node. In link-state routing [2, ea h router periodi ally sends its view of the status of its adja ent

network links to all the routers in the network. Ea h router an then take forwarding de isions
based on a omplete pi ture of the network obtained by ombining the latest updates from all the

routers.

5
Routing in MANETs
The algorithms des ribed above were designed for use in stati wired networks where topology

hanges are infrequent and all links are bi-dire tional. They are also omputation intensive, making

them di ult to use with onstrained resour es. Due to these problems, new routing algorithms are

required that take into a ount the hara teristi s of MANETs. The issue of routing in MANETs

deals with nding paths between nodes that are part of a rapidly hanging topology with possibly

uni-dire tional links, while using minimum resour es.

1.3 S ope of this work

The work presented in this thesis deals with the issue of routing in MANETs. A survey of

existing routing algorithms for MANETs showed that most of them had the drawba k of allowing

a node's mobility to ae t routes between other nodes using that node in the route between them.

This alled for an algorithm that provided relatively stable routes. A new routing algorithm for

MANETs, Kelpi, is presented and its implementation using the ns-2 network simulator des ribed.

Kelpi aims at maintaining long-lived, stable routes in a MANET.

1.4 Thesis organization

Chapter 2 des ribes a survey of existing work relating to routing in MANETs. Chapter 3 outlines

the algorithm Kelpi; hapter 4 oers a detailed des ription. Chapter 5 introdu es the Network

Simulator ns-2 and des ribes the implementation of Kelpi for ns. Chapter 6 ontains on lusions

and dire tions for future work.

6
Chapter 2

Related Work

A number of algorithms have been devised for routing in MANETs. Most of these an be lassied

as using one of two approa hes: rea tive or pro-a tive. The following se tions lassify several
existing algorithms a ording to the approa h used in them and outline the basi me hanism used

in these algorithms. Ad ho routing algorithms that use lo ation servi es are of spe ial interest in

light of the work presented in this thesis; the nal se tion presents some of the work published in

this area.

2.1 Rea tive algorithms

The rea tive approa h (or on-demand approa h) to routing in MANETs is hara terized by routes

being reated only when required by some node. When a node requires a route to a destination, it

initiates a route dis overy pro ess within the network. On e a route is established, it is maintained

by some form of route maintenan e till the route is either invalid or unne essary [3.

2.1.1 Dynami Sour e Routing (DSR)


Dynami Sour e Routing (DSR) [4 is designed to allow nodes to dynami ally dis over a sour e

route a ross multiple network hops to any destination in the ad ho network. When using sour e

routing, ea h pa ket to be routed arries in its header the omplete, ordered list of nodes through

whi h the pa ket must pass. An advantage of sour e routing is that intermediate hops do not

need to maintain routing information in order to route the pa kets they re eive, sin e the pa kets

already ontain the ne essary routing information. An example of a pa ket moving through an ad

ho network with sour e routing is illustrated in Figure 2.1.

DSR does not require the periodi transmission of router advertisements or link status pa kets,

redu ing messaging overhead when mobility is low. DSR has also been designed to ompute orre t

routes in the presen e of uni-dire tional links.

Proto ol Overview
DSR onsists of three fun tional omponents: routing, route dis overy and route maintenan e.
Routing uses sour e routing as des ribed above. Route dis overy is the me hanism by whi h a node

7
Figure 2.1: A pa ket being sour e routed from node 9 to node 5.

wishing to send a pa ket to a destination obtains a path to the destination. Route maintenan e is

the me hanism by whi h a node dete ts a break in its sour e route and obtains a orre ted route.

Route Dis overy


The sour e node broad asts a route request pa ket with a re orded sour e route listing only itself.

Ea h node that hears the route request (RREQ) forwards the request to its neighbours, adding

its own address to the re orded sour e route in the pa ket. The RREQ propagates hop-by-hop

outward from the sour e node until either the destination node is found or until another node

is found that an supply a route to the destination. Nodes forward RREQs if they are not the

destination node and they are not already listed as a hop in the route. In addition, ea h node

maintains a a he of re ently re eived RREQs and does not propagate any opies. All sour e

routes learned by a node are kept (memory permitting) in a route a he, whi h is used to further

redu e the ost of route dis overy. A node may learn of routes from virtually any pa ket the

node forwards or overhears. When a node wishes to send a pa ket, it examines its own route

a he and performs route dis overy only if no suitable sour e route is found. Further, when a

node re eives a route request for whi h it has a route in its a he, it does not propagate the route

request, but instead returns a route reply (RREP) to the sour e node. The RREP ontains the

full on atenation of the re orded route from the sour e, and the a hed route leading to the

destination. If a RREQ pa ket rea hes the destination node, it returns a RREP pa ket to the

sour e node with the full sour e to destination path listed.

Route Maintenan e
If a node along the path of a pa ket dete ts an error, the node returns a route error pa ket to

the sender. The route error pa ket ontains the addresses of the nodes at both ends of the hop in

error. When a route error pa ket is re eived or overheard, the hop in error is removed from any

route a hes and all routes whi h ontain this hop must be trun ated at that point. There are

many methods of returning a route error pa ket to the sender. The easiest of these, appli able in

networks that use only bidire tional links, is to simply reverse the route ontained in the pa ket

from the original host.

8
The above des ription of DSR is a modied extra t from [5.

2.1.2 Ad-ho On-Demand Distan e Ve tor Routing


This builds on the DSDV algorithm des ribed in se tion 2.2.1. It tries to improve DSDV by

minimizing the number of broad asts by reating routes on an on-demand basis. Route dis overy

is initiated by the sending of a Route Request (RREQ) pa ket to its neighbours, whi h in turn

forward the pa ket to their neighbours till a fresh enough route is found. Destination sequen e

numbers are used to keep routes loop free and fresh. On rea hing a node with a fresh route, the

node sends a route reply (RREP) pa ket. Route maintenan e is similar to the poli y followed in

DSR with link failure noti ation pa kets. This proto ol is des ribed in [6.

2.1.3 Temporally Ordered Routing Algorithm (TORA)


This algorithm is based on the on ept of link reversal. TORA is designed to work in a highly

dynami MANET. It also provides multiple routes to any desired destination. This proto ol has

three phases. In the rst and se ond, route reation and maintenan e, nodes use a height metri

to establish a Dire ted A y li Graph (DAG). Thereafter, links are assigned a dire tion (upstream

or downstream) based on the relative height of neighbouring nodes. When a link is broken, a node

generates a new height whi h propagates and auses the dire tion of links to hange. The third

phase is a erase phase where invalid routes are erased. The TORA proto ol is des ribed in [7.

2.1.4 Asso iativity Based Routing (ABR)


This denes an interesting metri for routes in MANETS, degree of asso iation stability. In ABR,
a route is sele ted based on the degree of asso iation stability of nodes. Ea h node generates

regular bea ons on whi h neighbouring nodes update a ount. The ount in reases proportional

to the asso iation stability between nodes. A high value of this metri generally indi ates low

mobility. The fundamental obje tive of ABR is to derive longer-lived routes in a MANET. This

proto ol is des ribed in [8.

2.1.5 Signal Stability Routing (SSR)


This is similar to ABR, but uses the metri of signal stability between nodes. This algorithm,
therefore, tends to generate routes whi h have a strong signal strength. More about this proto ol

an be found in [9.

2.2 Pro-a tive algorithms

Pro-a tive algorithms try to maintain onsistent, up-to-date routing information for all nodes in

the network. They require ea h node to maintain tables of routing information, and respond to

hanges in network topology by propagating updates throughout the network in order to maintain

a onsistent network view [3.

9
Figure 2.2: Routing in DSDV

2.2.1 Destination Sequen ed Distan e Ve tor Routing (DSDV)


DSDV is based on the distan e ve tor proto ol ommonly used in wired networks. It makes some

modi ations to adapt it for routing in MANETs.

Proto ol Overview
In DSDV, pa kets are routed between nodes of an ad ho network using routing tables stored

at ea h node. Ea h node ontains a routing table with an entry for every node in the network,

ontaining the next hop node to rea h that node. Figure 2.2 illustrates the routing pro edure

in DSDV. In this example, a pa ket is being sent from node 1 to node 3 (node 3 is not shown).

From node 1, the next hop for the pa ket is node 4 (Figure 2.2 a). When node 4 re eives the

pa ket, it looks up the destination address (node 3) in its routing table (Figure 2.2 b). Node 4

then transmits the pa ket to the next hop as spe ied in the table, in this ase node 5 (Figure 2.2

). This pro edure is repeated as required until the pa ket nally rea hes its destination.

Routing Table Management


While routing is a relatively trivial task, the maintainan e of up-to-date routing tables is not.

Every time the network topology hanges, the routing table in every node needs to be updated.

Also, when routing tables are out of syn (i.e. the routing proto ol has not onverged), routing

loops may form. To fa ilitate routing table maintenan e, several additional pie es of information

10
Table 2.1: Updation of routing tables in DSDV

are stored in the routing tables. In addition to the destination address and next hop address,

routing tables maintain the route metri and the route sequen e number.

Periodi ally, or immediately when network topology hanges are dete ted, ea h node will broad-

ast a routing table update pa ket. The update pa ket starts out with a metri of one. This signies

to ea h re eiving neighbor they are one hop away from the node. The neighbors will in rement this

metri (in this ase, to two) and then retransmit the update pa ket. This pro ess repeats itself un-

til every node in the network has re eived a opy of the update pa ket with a orresponding metri .

If a node re eives dupli ate update pa kets, the node will only pay attention to the update pa ket

with the smallest metri and ignore the rest. To distinguish stale update pa kets from valid ones,

ea h update pa ket is tagged by the original node with a sequen e number. The sequen e number

is a monotoni ally in reasing number whi h uniquely identies ea h update pa ket from a given

node. Consequently, if a node re eives an update pa ket from another node, the sequen e number

must be equal to or greater than the sequen e number already in the routing table; otherwise the

update pa ket is stale and ignored. If the sequen e number mat hes the sequen e number in the

routing table, then the metri is ompared and updated as previously dis ussed. Ea h time an

update pa ket is forwarded, the pa ket not only ontains the address of the eventual destination,

but it also ontains the address of the transmitting node. The address of the transmitting node

is entered into the routing table as the next hop. Table 2.1 illustrates how a node pro esses an

update pa ket under varying onditions. Note that update pa kets with higher sequen e numbers

are always entered into the routing table, regardless of whether they have a higher metri or not.

11
Responding to Topology Changes
Mobile nodes ause broken links as they move. The broken link may be dete ted by the om-

muni ation hardware, or it may be inferred if no broad asts have been re eived for a while from

a former neighbor. A broken link is des ribed as having a metri of innity. Sin e this qualies

as a substantial route hange, the dete ting node will broad ast an update message for the lost

destination. This update message will have a new sequen e number and a metri of innity. This

will essentially ause the routing table entries for the lost node to be ushed from the network.

Routes to the lost node will be established again when the lost node sends out its next broad ast.

To avoid nodes and their neighbors generating oni ting sequen e numbers when the topology

hanges, nodes only generate even sequen e numbers for themselves, and neighbors responding to

link hanges only generate odd sequen e numbers.

The above des ription of DSDV is a modied extra t from [5.

2.2.2 Clusterhead Gateway Swit h Routing (CGSR)


This is based on the DSDV algorithm. It is hierar hi al in nature in an attempt to improve

s alability. It is dierent in that it divides the nodes in the network into lusters and ea h luster

ele ts a node as a lusterhead. A node that is in range of two lusterheads is alled a gateway.

Routing takes pla e from lusterhead to gateway to lusterhead till the message rea hes the luster

of the destination. Ea h node maintains a table of all nodes in the network and their luster

heads. These lusterhead tables are propagated regularly through the network as in DSDV. This

is des ribed in [10.

2.3 Hybrid Routing

2.3.1 Pro-a tive vs. Rea tive routing


Pro-a tive s hemes provide valid routes instantly. But, they result in more messaging overhead

and omputation for route maintenan e. They are useful in real-time appli ations. In the ase of

rea tive proto ols, power and bandwidth are saved by preventing onstant maintenan e of routes,

but there is a laten y involved in nding a route. Pro-a tive proto ols an prove even more

expensive when the degree of mobility involved is high. There also exists a hybrid ombination of

the two in the Zone Routing Proto ol.

2.3.2 Zone Routing Proto ol


This routing algorithm tries to ombine the pro-a tive and rea tive approa hes. For every node,

a zone is maintained that ontains all nodes within zone radius hops from the node. Two routing
proto ols are employed, the IntrAzone Routing Proto ol (IARP) and the IntErzone Routing Pro-

to ol (IERP). The IARP is pro- a tive and the IERP is rea tive. The zone radius an be varied

a ording to the needs of the appli ation. More details about this proto ol an be found in [11.

12
2.4 Lo ation based algorithms

2.4.1 Lo ation Aided Routing (LAR)


LAR makes the use of geographi lo ation of nodes in a MANET by using a Global Positioning

System (GPS) re eiver with ea h node. Based on this every node denes a request zone and an

expe ted zone where the destination is to be found. When a route request pa ket is sent, only

those nodes whi h are in the expe ted zone forward the pa ket thus minimizing the area in whi h

ooding is to be done. This brings about a saving in the number of messages required for nding

a route. If a route is not found within an expe tation zone, the zone an be widened. LAR uses

GPS for optimizing routing, but is not dependent on it. LAR is presented in [12.

2.5 Observations

The work presented in the following hapters deals with a routing algorithm designed to provide

long-lived routes. In this respe t, most of the algorithms above tend to have some short omings.

In the ase of rea tive algorithms like DSR and AODV, the movement of a node an have the

following ee t:

1. routes to and from the node in question an be broken; and

2. routes that use this node as an intermediate hop an be broken.

In the ase of pro-a tive algorithms like DSDV, the following undesirable ee ts an be observed:

1. large overheads are in urred in broad asting periodi routing advertisements; this o urs

when nodes are stationary too;

2. the size of these advertisements in rease with the size of the network, leading to poor s ala-

bility.

The problem of s alability is generally handled by using a hierar hi al s heme as in CGSR. Sin e

CGSR is based on DSDV, the problem of large overheads in periodi advertisements is present

here too. Further, there is more overhead involved in ele ting a lusterhead and managing the

hierar hy.

The next hapter presents an overview of a routing algorithm, Kelpi, that aims to address

these problems.

13
Chapter 3

Kelpi: An overview

Kelpi is a routing algorithm designed to provide long lived stable routes when possible and to

redu e routing overheads; it is also designed with the aim of improving throughput at the link

layer by redu ing interferen e between transmissions of dierent nodes.

3.1 Preliminaries

The hoi e of a routing algorithm to deploy in a MANET depends on the hara teristi s of the

nodes and their appli ation: the routing needs of a MANET that is being used in a onferen e

room are quite dierent from that being used in a battleeld. Some of these hara teristi s are

area of operation, rate of mobility, density of nodes, transmission range of nodes, type of tra ,

whether there exists some xed infrastru ture, power onstraints of nodes, et . Loosely, Kelpi is

intended for operation in a MANET spread over a fairly large area, say a few kilometres, with

nodes moving at or less than vehi ular speeds, with power not being a major onstraint and

with a node density of around tens of nodes per square kilometre. These seem to hara terize

an appli ation in the battleeld or in a disaster relief operation. The exa t hara teristi s of the

appli ation that Kelpi is best suited for will emerge only after detailed experimentation.

3.1.1 Prin iple of operation


The dynami virtual ba kbone
Kelpi tries to ensure stable routes by imposing a ellular stru ture on an ad ho network. The

area of operation is geographi ally divided into ells. Ea h node is apable of omputing a 'map'

of these ells using its initialization parameters set before deployment. Ea h node is also apable

of dete ting whi h ell it is urrently within by using a positioning system su h as the Global
Positioning System (GPS ). At any given time, an o upied ell has a router through whi h all
other nodes in the ell route their ommuni ation; the routers ommuni ate among themselves.

The existan e of a router in a ell is independent of any parti ular node; that is, any node an

fun tion as a router. A router that is moving out of a ell an appoint a node in that ell as a

router after transferring the ne essary information to it. This ensures that even if a set of nodes are

steadily moving a ross a ell, the routes going through that ell are unae ted. The routers of ells

14
form a 'virtual ba kbone ' whi h is expe ted not to hange very frequently. Routing information for
this virtual ba kbone is maintained by pro-a tive periodi broad asting of route update pa kets.

3.1.2 Assumptions
The following assumptions are made about the nodes to be used in the network:

 ea h node is equipped with an a urate positioning devi e su h as a GPS re eiver; and

 ea h node is apable of multi-level transmission range.

Further, it is assumed that the bounding re tangle of the area of operation is known before

the network is deployed. While multi-level transmission is preferred, the algorithm is apable

of fun tioning with single power transmitters. The assumptions are not unreasonable given the

typi al usage s enarios.

3.2 Operation

All nodes rst undergo initialization; then nodes ommuni ate with their routers, and routers

ommuni ate among themselves. When a node ommuni ates with another node or its ell router,

it operates at a lower transmission power whi h is enough for its transmission to be re eived at

any point within the ell. When a router transmits to another router, it hanges its power of

transmission to enable it to be re eived at any point in any of its neighbouring ells.

3.2.1 Initialization
Before the MANET is deployed, it is initialized with the following details:

 the bounding re tangle of the area of operation; and

 a value of transmission power at whi h all nodes an transmit, typi ally the maximum value

if the nodes are similar.

In gure 3.1, the area of operation is denoted by a shaded oval and the o-ordinates < x0 ; y0 >and

< xl ; yl >denote the bounding re tangle. These o-ordinates would depend on the kind of position-

ing system being used. If GPS is being used they are assumed to be the absolute two-dimensional

geographi al o-ordinates of the points. Using these initialization parameters, ea h ell an on-

stru t the grid shown in gure 3.1; this pro ess is des ribed in detail in Chapter 4. Further, ea h

node an determine, using its urrent GPS o-ordinates, its urrent ell.

3.2.2 Node-Router ommuni ation


Ea h ell has a node that performs the role of a router. This node responds to a Cell Router
Address (CRA) that is a fun tion of the ell for whi h that node is a router, in addition to its
own network address. This is to keep the hanging of ell routers transparent to other nodes in

the network.

15
Figure 3.1: Routing in Kelpi

A node on being swit hed on, or on entering a new ell, sends a HI (Here I am) message to the

router using the CRA for that ell. If a router does not a knowlege the HI, the node de lares itself

the router of that ell and begins responding to the CRA. When a node S wants to send a pa ket

to a node D, S sends its router a FIND_CELL message ontaining D's address. The router nds

out whi h ell D is urrently in and sends a reply to S with D's ell. S an then send a pa ket

addressed by D's address and ell to the router whi h knows the next hop ell to rea h D's ell.

A node also sends a BYE message to its ell's router while leaving a ell whi h ontains the

new ell of this node. A router, before leaving a ell, broad asts a RTR_MOVE message to all

the nodes in the ell. This initiates a sequen e of messages that leads to a parti ular node being

hoosen as the new router after existing routing information has been transferred to this node.

3.2.3 Router-Router ommuni ation


Routers, among themselves, ex hange periodi routing updates, forward pa kets to other routers

and propagate FIND_CELL messages. Ea h of these is explained below in some detail.

Periodi Routing Updates


Ea h router needs to know the next hop ell for a pa ket's destination ell. This information would

be stati if all the ells were o upied, guaranteeing a router in every ell and redu ing the network

to a stati ellular network. However, it is quite likely that ell o upan y hanges; therefore,

periodi distan e ve tor updates are essential to maintain up-to-date forwarding information. This

16
also ensures that partitioned sub-networks in a MANET an ombine smoothly.

Periodi updates are essential only when a ell be omes empty or when a router omes up in

an empty ell. Due to the router hando me hanism mentioned earlier, this is not expe ted to be

very frequent. A node broad asts a destination sequen ed update (see se tion 2.2.1) ontaining

its distan e in hops from all other o upied ells, to all its neighbouring ells.

Forwarding pa kets
Ea h router maintains a routing table that stores the next hop ell for a given destination ell.

This table is updated when any hanges in the network are noti ed through the periodi distan e

ve tor updates from the neighbouring ells.

When a pa ket arrives at a router, the router he ks if the pa ket is destined for its urrent

ell. If not, the router forwards it to a neighbouring ell determined by the routing table.

Flooding FIND_CELL messages


When a node sends a FIND_CELL message to a router, the router oods the neighbouring routers

with this pa ket. A router that has the destination node in its ell, replies dire tly to the node that

initiated the message. Ea h FIND_CELL has a sequen e number; a router will not forward any

su h message with a sequen e number lower than one it has already seen for that sour e-destination

pair.

3.2.4 Node-Node ommuni ation


If a node learns from a reply to its FIND_CELL message that the destination node is in the same

ell as itself, it initiates ommuni ation dire tly with the node. Also, when a node in a tive om-

muni ation with some other nodes leaves its urrent ell, it sends these nodes a CHANGED_CELL

message ontaining its new ell to enable ommuni ation to ontinue uninterrupted.

3.2.5 An example of routing using Kelpi


Figure 3.1 shows an example of routing using Kelpi. A node S in ell 21 wants to ommuni ate

with node D. The sequen e of events that o ur are as follows:

1. S sends a FIND_CELL message ontaining D to the router in its ell. Although S does not

know the address of the node a ting as the router, it knows that the router is listening on a

ell router address (CRA) that is xed for the ell and sends the message to that address.

2. The router for ell 21 re eives the FIND_CELL message. It rst looks for D in a list of

nodes that are present in the ell, and not nding it there, broad asts the message.

3. Routers of ells neighbouring 21, that is, 30, 22 and 13, re eive the message, he k if D is

present in their ell, and broad ast the message. A router never repeats the broad ast of a

FIND_CELL sin e it dis ards the message if it has seen the sequen e number of the message

before.

17
4. The router in ell 24, on re eiving the message, nds that D is present in its ell. It sends a

FIND_CELL_REPLY to node S ontaining D's ell, 24.

5. On re eiving D's ell, S sends its data pa ket addressed to D, to the router of ell 21. The

pa ket also ontains the destination ell number, 24.

6. The router of ell 21 on re eiving this pa ket, looks into its routing table and nds that the

next hop ell for ell 24 is ell 22. The pa ket is therefore forwarded to the CRA of ell 22.

The pa ket is similarly forwarded till it rea hes the router of ell 24.

7. The router of ell 24 on nding that the pa ket is addressed to its urrent ell, transmits the

pa ket to node D. The path followed is indi ated in gure 3.1 with dotted arrows.

8. Assume that subsequently, the router in ell 22 approa hes the ell boundary adjoining 31

and sends a RTR_MOVE broad ast.

9. The only node in ell 22 on re eiving this message replies with a RTR_MOVE_ACK on-

taining its urrent o-ordinates.

10. The router waits for some time for responses and times out. It appoints the node losest to

the entre as the new router; in this ase, by default, it is the solitary node.

11. The router sends the node a RTR_HANDOFF message ontaining all the router data stru -

tures.

12. The node on re eiving the RTR_HANDOFF be omes the new router and starts responding

to the CRA for ell 22. The old router now fun tions as a node.

13. This hange of router has no impa t on the route already passing through ell 22. The router

of ell 21 is still sending pa kets to ell 24, using the CRA of ell 22 as a next hop address.

Several nodes ould ome and go in any of the ells, but as long as there is at least one node

in a ell at any given time, routes are unae ted. This approa hes the on ept of a ba kbone

in ellular networks and is therefore alled a virtual ba kbone.

14. Now let the node in ell 22, the ex-router, move to ell 31. It sends a BYE message to the

router in ell 22 and a HI message to the router of ell 31.

15. Sin e there is no router in ell 31, no HI_ACK is re eived by this node. It times out and

de lares itself the router.

16. It is possible that another node ould have similarly entered ell 31 and sent a HI. One node

would set its timer as the other one is waiting for its own timer to expire. This situation

would result in two routers in the same ell. To prevent a node on timing out sends a RH

(Router Here) message. Any other nodes with their timers set would an el their timers and

send a HI to the new router, the sender of the RH.

3.3 Comments

The approa h taken by Kelpi has some trade-os; some of the advantages and disadvantages are

listed below.

18
3.3.1 Advantages
 Results in formation of more stable routes sin e using the ell router address (CRA) and the

router hand-o me hanism shield the rest of the network from the ee ts of node mobility.

 Redu es link layer interferen e sin e all nodes do not transmit at their maximum power.

This is expe ted to result in in reased network throughput.

 Sin e dire t ommuni ation between two nodes is always within the same ell, multiple

broad ast hannels, as in a ellular system, an be used.

3.3.2 Disadvantages
 The hierar hi al nature of the algorithm results in routers being loaded mu h more heavily

than the other nodes.

 Kelpi requires an a urate positioning system for its fun tioning. Although this is not an

unreasonable assumption to make given the target appli ations, it would be preferable for

an algorithm to fun tion orre tly, if not optimally, in the ase of unavailability or failure of

the positioning system.

This hapter presented an overview of the fun tioning of Kelpi. Several details have not been

mentioned here; the next hapter explains the algorithm in greater detail, in luding des riptions

of the data stru tures involved, ontents of routing messages and exa t behaviour at various events

that o ur during the lifetime of a node or router.

19
Chapter 4

Kelpi: Details

This hapter provides a detailed des ription of the algorithm Kelpi. The organization of this hap-

ter is as follows: the data stru tures maintained at every node are des ribed; then, events o urring

in the lifetime of a node are listed; messages that o ur with dierent events are mentioned along

with the events. Design de isions are ommented upon where required.

4.1 Data Stru tures

Sin e every node is a potential router, no distin tion is made between the data stru tures main-

tained at a node and router. Some of them, however, are used only when a node fun tions as a

router.

Ea h node maintains the following values: urrent- ell, previous- ell, a is_router ag that is
set if the node is a router, the bounding o-ordinates of the area of operation, present o-ordinates

and last known o-ordinates. Sin e the nodes an transmit at two dierent powers, they store

these powers in maxTxPower and nodeTxPower. Other data stru tures required for operation
are:

node-list: Ea h router maintains a node-list whi h ontains the addresses of nodes that are in
its ell.

node- a he: Ea h node maintains a a he mapping nodes it has ommuni ated with to their

ells. This is to prevent repeated FIND_CELL messages for the same destination.

forwarding-pointers: Ea h router keeps tra k of whi h ell a node has moved to after leaving.

This is used to forward pa kets that arrive for the node just after it has left the ell. Entries

for nodes are removed after a timer times out.

routing-queue: Ea h node maintains a routing-queue where pa kets are buered while the desti-
nation ell is being found. Although this fun tion is typi ally performed by routers in wired

networks, nodes perform the fun tion here to redu e router load.

routing-table: Contains the next-hop forwarding ell for every possible destination ell. Ea h

entry ontains a destination node address, its ell and the destination sequen e number.

20
In addition to the above mentioned, ea h router also keeps tra k of the last sequen e number seen

in the FIND_CELL for every sour e-destination pair.

4.2 Messages

The routing messages used in Kelpi, their ontents, and the events orresponding to their genera-

tion are as follows:

 HI - <msg_type, urrent_ ell, previous_ ell > : sent by a node when it enters a new ell.

 RH - <msg_type, ell > : sent by a node that de lares itself a router.

 HIACK - <msg_type, ell > : sent by a router in a knowledgement of a HI message.

 BYE - <msg_type, urrent_ ell, previous_ ell, sender_node_address > : sent by a node
after it leaves a ell.

 FIND_CELL - <msg_type, dst_address, sr _address, sr _ ell, sequen e_number > : sent


by a node that wants to send a pa ket, but does not have a valid destination ell in its

node- a he.

 RTR_MOVE - <msg_type, ell > : broad ast by a router as it approa hes a ell boundary.

 RTR_HANDOFF - <msg_type, ell, node-list, routing-table, seq_numbers > : sent by a


router after having appointed a new router for that ell.

 RTR_MOVE_ACK - <msg_type, ell, sender_node_address, urrent_x, urrent_y > :


sent by a node in response to a RTR_MOVE.

 FIND_CELL_REPLY - <msg_type, dst_address, dst_ ell, sr _address > : sent by a router


who nds the target node of a FIND_CELL message in its ell.

 CHANGED_CELL - <msg_type, sender_node_address, new_ ell > : sent by a node to


other nodes with whi h it is in a tive ommuni ation after it moves to a new ell.

 RT_UPDATE - <msg_type, routing_table > : sent periodi ally by routers.

These messages are sent in the ontext of ertain events. These events are des ribed in the next

se tion.

4.3 Events

The algorithm Kelpi is des ribed by enumerating the events that o ur in the lifetime of a node

and dening the behaviour of a node on o urren e of a ertain event. Events are listed separately

for nodes and routers, but sin e all routers are also nodes, several events are ommon to both. An

event listed as o urring for nodes is repeated as o urring for a router only if there is a dieren e

in the resulting behaviour.

21
4.3.1 Events at a node
1. Initialization
This o urs before the deployment of the network. Nodes are initialized with:

 (x0 ; y0 ) and (xl ; yl ) - the o-ordinates of the bounding re tangle of the area of operation; and

 maxTxPower - the maximum transmission power that a node an use. This value is ommon

for all nodes in the MANET.

2. Node omes on
When a node omes on, it already knows the values of the initialization parameters. From these

parameters, it needs to ompute nodeTxPower; s, the side of ea h ell in the grid; ellsx and

ellsy , the number of ells on the X and Y axis respe tively; and r, the maximum transmission
range. The al ulations pro eed as follows:

1. r is obtained from the value of maxTxPower by using a relation dependent on terrain,


frequen y of transmission, et ., whi h varies from system to system.

2. r is now the range that an be overed by a router. This must be twi e the diagonal of a ell,
sin e the routers of two neighbouring ells must be within range. We an therefore derive s

as the side of a square, twi e of whose diagonal gives r.

s = pr
2 2

3. Numbering of ells is as shown in Figure 3.1. We ompute ellsx and ellsy next as follows:

xl x0
ellsx = eil (
s
)

yl y0
ellsy = eil (
s
)

Given the urrent o-ordinates of a ell as (x,y) we an al ulate its ell as:

ell = f loor (
x
s
x0
) + ellsy  f loor( yl s y0 )

3. Node in new ell


1. The node sends a HI (Here I am) message addressed to the ell router address.

2. If the node does not re eive a HI_ACK within a time of HI_TIMEOUT, the node de lares

itself a router (event 4).

4. Node de lares itself router


1. The node broad asts a RH (Router Here) message. This is a signal to any other nodes who

have set the HI timer to an el the timer and learn that a router is present in the ell.

2. The node starts listening to pa kets addressed to the ell router address (CRA).

3. Responses to events hen eforth are as des ribed in 4.3.2.

22
5. Node re eives RH message
The node performs the following a tions if the ell eld in the RH message is its urrent ell:

1. Can els HI timer if it is set.

2. Sends HI message to the CRA of its urrent_ ell.

6. Node re eives RTR_MOVE message


If the ell eld in the message is the same as the urrent_ ell, the node replies to the CRA with
a RTR_MOVE_ACK message whi h ontains the node's address and its urrent geographi al

o-ordinates. This is to enable the router to hoose as a new router a node whi h is losest to the

entre of the ell.

7. Node moves ells


Nodes he k their urrent ell every POSITION_POLL_INTERVAL. If the al ulated urrent_ ell
is dierent, the node does the following:

1. Sends a BYE message ontaining its new ell to the CRA of the ell it has just left.

2. Behaves as in event 3.

8. Node wants to swit h o


The node sends a BYE message with a spe ial urrent_ ell eld indi ating that it is swit hing o.

9. Node wants to send pa ket


1. The node he ks to see if there is a valid entry to the destination in its node_ a he.

2. If so, the node sends the pa ket with the dst_ ell eld set to the a he entry and sends it
to the router of its ell.

3. If there is no valid entry in the node_ a he, the node buers the pa ket in its routing queue
and sends a FIND_CELL message to its router.

4. If a transmission using a valid a he entry fails, after a ertain number of retries, the node

sends a FIND_CELL message to its router.

10. Node re eives FIND_CELL_REPLY


1. The node enters the ell for the destination in its node- a he.

2. Queued pa kets for the destination are dequeued and sent.

11. Node re eives CHANGED_CELL


This message is re eived from a node with whi h this node has ommuni ated in the re ent past

(less than CACHE_STALE time). On re eiving this, the node updates its node_ a he entry for
the sender of the message to the ell indi ated in the message.

23
12. Node re eives RTR_HANDOFF
1. The node initializes router data stru tures to those re eived in the RTR_HANDOFF.

2. Goes to Event 4.

13. Node re eives a pa ket


The pa ket is forwarded to a higher layer.

4.3.2 Events at the router


1. Router starts operation
When a router starts operation, it re eives updates from its neighbours and builds its routing-table.
It also periodi ally broad asts its own routing-table through a RT_UPDATE message. Other data

stru tures are built in responses to re eived messages.

2. Router re eives HI
1. If the node sending the HI is present in the forwarding-pointers of the router, the entry is
removed.

2. The sending node's address is entered into the node-list.

3. The router sends a HI_ACK to the sending node.

3. Router re eives FIND_CELL


1. The router he ks its list of already seen FIND_CELL sequen e numbers and if the message's

sequen e number is lower than the entry it has for that sour e-destination pair, it ignores

the message.

2. Otherwise, it he ks to see if it has the node with the required dst_address in its node-list.
If so, it sends a FIND_CELL_REPLY to the node that originated the message.

3. Otherwise, it broad asts the pa ket to propagate ooding of the message.

4. Router re eives pa ket


1. The router he ks if the dst_ ell eld in the pa ket is its urrent ell.

2. If so, the router transmits the pa ket to the node with dst_address. If the node is not

present, it he ks if there is a valid forwarding pointer for that node, and if so forwards the

pa ket to its new ell. Otherwise, the pa ket is dropped.

3. If the dst_ ell is not its urrent ell, the router forwards the pa ket to the router of the ell
indi ated in the forwarding hop for that dst_ ell in its routing-table.

24
5. Router approa hes ell boundary
A router onstantly he ks to see if it is within a ertain threshold distan e from a ell boundary.

This distan e is al ulated su h that a router moving at the maximum possible speed should be

able to omplete hand-o of routing information before leaving the ell.

1. Router broad asts a RTR_MOVE message and starts a timer.

2. It re eives a RTR_MOVE_ACK message from all nodes in the same ell ontaining their

geographi al o-ordinates. These messages are re eived until the timer expires.

3. The router hooses the node losest to the entre of the ell and sends it a RTR_HANDOFF

ontaining routing information for that ell.

4. The router then starts behaving as a node.

Note that a router starts behaving as a node even before it rosses the ell boundary, if at all it

does. Also, if a router is alone in a ell and re eives no RTR_MOVE_ACK messages, it ontinues

to fun tion as a router till it hanges ells ex ept for replying to HI messages. If another node

enters the ell, times out on its HI message and sends a RH message, the router turns to node

and sends a HI to the new router. The prin iple is that of a node near a ell boundary taking

minimum responsibility of being a router.

6. Router be omes node


The router stops responding to the CRA. This at on e implies that the router also stops re eiving

messages addressed to the CRA and routing updates from other routers.

7. Router re eives BYE message


1. The router removes the sour e node of the message from its node-list.

2. The new ell of the sour e node is entered into its forwarding-pointers.

8. Router re eives RH message


A router re eives a RH message in its own ell when it is alone and has approa hed a ell boundary.

The router, on re eiving an RH message stops fun tioning as a router and sends a HI to the CRA.

9. Router re eives a RTR_MOVE_ACK


1. If the RTR_MOVE_TIMER is not running, the message is ignored.

2. Otherwise, the sour e node address and its o-ordinates are stored.

After the timer expires, the node losest in position to the entre is hosen as the router and sent

a RTR_HANDOFF message ontaining routing information.

10.Router wants to swit h o


The router's behaviour in this ase is the same as that in event 5.

25
4.4 Ex eption Handling

The most ommon sour e of unreliability is expe ted to be loss of routing messages. This requires

areful handling with re-transmissions sin e many events are timer driven. Timeouts should be

xed with due onsideration to other events that may be ae ted.

Another sour e of unreliability in the fun tioning of the algorithm is expe ted to be the apri-

ious nature of the wireless medium itself. Cal ulated transmission ranges may not be very on-

sistent or a urate; this problem an be alleviated to some extent by assuming large margins of

error in al ulations.

Unexpe ted router failure is another undesirable ase. This an be solved by ele ting a new

router in the ell, with the ele tion being alled for by the rst node that dete ted the error. A

simple riterion for ele ting the new router ould be the distan e of a node from the entre of the

ell, with the losest being ele ted the router.

4.5 Summary

This hapter presented details of the algorithm Kelpi. The next hapter deals with the implemen-

tation of Kelpi for the network simulator ns-2.

26
Chapter 5

Simulation

The last hapter ontained a detailed des ription of the routing algorithm Kelpi. In order to

examine its working, it has been implemented for the Network Simulator ns-2. This hapter

provides an introdu tion to ns-2, mentions the various hanges that had to be made to ns-2 to

in orporate Kelpi into it, and dis usses the implementation details of some features of Kelpi.

5.1 Introdu tion to ns-2

ns-2 [13 is an event driven network simulator for simulating omputer networks and network

proto ols. It was hosen for simulating Kelpi sin e it is free, open sour e and is used ommonly

by the resear h ommunity for evaluating work in ad-ho networks. The version of ns used for

simulating Kelpi is ns-2.1b6.

5.1.1 ns framework
ns uses a split language approa h. OT l, an obje t-oriented version of T l is used as a ontrol

language for simulation. Setting up nodes and links, and ontrolling their behaviour is done in

OT l. Per pa ket pro essing, routing and other omputation intensive a tivities are implemented

in C++ for purposes of speed. Even the OT l obje ts are represented during simulation run-

time by C++ shadow lasses. The results of a simulation are dumped in a tra e le whi h an

be analysed to extra t information of interest. Network Animator (NAM) provides a graphi al

visualization of simulations.

5.1.2 Wireless support in ns-2


ns was rst extended to support mobile and wireless networks by the CMU Monar h extensions

[14; these extensions were later in orporated into ns. For wireless support, ns denes a MobileNode
inherited from the basi Node obje t with the additions that the MobileNode is able to move, keep
tra k of its lo ation and use radio transmission and re eption with several propagation models to

ommuni ate instead of using a xed link. To be re eived or transmitted by a MobileNode, pa kets
have to move through several layers. A s hemati is shown in Fig. 5.1.

27
Figure 5.1: S hemati of the wireless model in ns-2 [13

28
Ad ho routing is implemented for ns-2 as a routing agent on port 255. Currently ns omes

with four ad ho routing proto ols: DSR, DSDV, AODV and TORA.

5.1.3 Pa ket Format


A pa ket in ns-2 onsists of the header of various layers of the network sta k. In addition, there is a

ommon header that is used by the simulator itself. This header a ompanies the pa ket through

the network and an be used to arry information required for simulation su h as pa ket_size,
next_hop for routing, et .

5.2 Kelpi: Implementation

5.2.1 Preliminary modi ations to ns-2


As mentioned in the previous se tion, implementing an ad ho routing proto ol involves reating

a routing agent on a MobileNode. This se tion des ribes some of the hanges that were made to
ns to in lude the Kelpi routing agent.

The Kelpi routing agent is a C++ lass alled KelpiAgent whi h inherits from the lass Agent.
The lass KelpiAgent ontains the implementation of the algorithm des ribed in Chapter 4.
The routing agent is set in the user's OT l s ript whi h is interpreted on exe ution to initialize

various simulation parameters. The le ns/t l/lib/ns-lib.t l ontains ode that instantiates the

right routing agent. This was modied to atta h an instan e of KelpiAgent to ea h node that
had Kelpi listed as its routing algorithm. Sin e this o urs at the beginning of the simulation,

the Kelpi start pro edure also ontains ode to pass essential simulation information ontained in

the user s ript to lass KelpiAgent. This is done by using a ' ommand' method of the agent lass
whi h allows values to be passed from OT l to C++. Information passed in this manner in ludes

the node's address, transmission power set in the s ript and a handle to a topography obje t

whi h ontains lo ation information. The le ns/t l/mobility/kelpi.t l ontains initialization of

the KelpiAgent variables. This had to be sour ed into ns-lib.t l.


In addition, make les for ns had to be hanged to ensure that the newly reated obje ts are

ompiled into ns-2.

5.2.2 Modi ations to the ns-2 pa ket header


The ommon pa ket header was modied to arry ertain extra information required for imple-

menting Kelpi. In order to atta h the destination ell eld with ea h pa ket and the sour e ell

eld with some pa kets, sour e_ ell and destination_ ell elds were introdu ed in the ommon
header. Another eld txPower was introdu ed to help implement a multi-level wireless network
interfa e. These modi ations an be found in ns/pa ket.h.

5.2.3 Implementation of data stru tures


In the implementation of Kelpi, it is assumed that the maximum number of nodes, MAX_NODES

is 999.

29
Node-list
The node-list is implemented as a single dimensional array of hara ters indexed by node address.
If a node is present in the ell, the value for that parti ular element is set to 'y'; otherwise, it is

'n'.

Router-queue
Other routing algorithms like TORA and AODV use this data stru ture for buering. Therefore,

it is already implemented in ns-2. It supports the operations enque, deque, and deque all pa kets

for a parti ular node address.

Forwarding pointers
This onsists of a MAX_NODE sized array of re ords whi h ontain:

<new ell, timestamp >

Node- a he
This is implemented as a MAX_NODE sized array of re ords whi h ontain:

<node_address, ell, time_last_a essed, request_sent, request_time >


The time_last_a essed eld is used to re ognize a stale a he entry. The request_sent and
request_time elds are asso iated with the FIND_CELL messages sent by a the node.

5.2.4 Implementation of Cell Router Address


In Kelpi, ea h ell has a unique address to whi h the node a ting as router of that ell will respond

to. This has been simulated in the implementation by maintaining a mapping of ells to their

urrent router's address. A node wanting to send a pa ket to the CRA sends it to CRA( ell) whi h

is transformed into the a tual address of the urrent router of the ell.

5.2.5 Implementation of multi-powered network interfa e


This is simulated by modifying the physi al layer ns-2 ode in the le ns/wireless-phy. . The

required power of transmission for the al ulated ell size is al ulated using the Two Ray Ground

propagation model used by ns-2. This value is passed along with ea h pa ket through the txPower
eld introdu ed in the ommon header. Just before transmission, this value is a essed and opied

into the variable that denes the transmission power at the physi al level.

5.2.6 Current implementation status


The algorithm Kelpi has been implemented as des ribed in Chapter 4, with the ex eption of two

features. The periodi routing updates are not used urrently; instead, orre t routing information

learnt from a global pi ture is given to the routers. This is to examine whether the rest of the

algorithm is working as expe ted. Also, the CHANGED_CELL message, sent by a node to inform

other nodes in a tive ommuni ation with it about a hange in its ell, has not been implemented.

30
5.3 Experimentation

Simulations have been run for small test ases involving 4 to 5 nodes spread a ross 2 to 3 ells.

The tra e les for these simulations show that ell dis overy, destination ell a hing, buering,

pa ket forwarding and router hand-os o ur su essfully.

31
Chapter 6

Con lusion

The work presented in this thesis des ribes a routing algorithm for mobile ad ho networks, Kelpi,

designed to provide stable routes between nodes in a network. It is based on the prin iple that

routing information an be retained in a parti ular geographi al area despite the nodes of the

network being transient. This is a hieved by imposing a ellular stru ture on the MANET, whi h

allows node mobility in a region to be hidden from other parts of the network. The routes formed

by the routers in Kelpi an be thought of as a dynami virtual ba kbone enabling stable routes
to be formed. Kelpi is also designed to in rease link-layer throughput by using multiple levels of

transmission power to redu e radio interferen e.

Preliminary simulations of Kelpi have been arried out using the ns-2 simulator.

6.1 Future dire tions

Although Kelpi is designed to provide stable routes, its requirements are quite restri tive: it

uses an a urate positioning servi e and a network interfa e that operates at multiple levels of

transmission power. Some dire tions for future work are:

 Implementation of the omplete algorithm.

 Eliminating the need for a positioning system. An alternative ould be a ompass and an

inertial motion dete tor atta hed to the mobile devi e; work on augmenting hardware to aid

MANET routing ould be an interesting dire tion.

 The prin iple behind Kelpi may be applied to other routing algorithms to provide a more

general solution.

32
Bibliography

[1 C.E. Perkins and P.Bhagwat, Highly Dynami Destination-Sequen ed Distan e-Ve tor Rout-

ing (DSDV) for Mobile Computers, Computer Communi ations Review, pp. 234-244, O to-

ber 1994.

[2 A.S. Tanenbaum, Computer Networks, 3 ed., Prenti e-Hall India, 1994.

[3 E.M. Royer and C.-K. Toh, A Review of Current Routing Proto ols for Ad-Ho Mobile

Wireless Networks, IEEE Personal Communi ations Magazine, April 1999, pp. 46-55.

[4 D.B. Johnson and D.A. Maltz, Dynami Sour e Routing in Ad-Ho Wireless Networks,

Mobile Computing, ed. T.Imielinski and H.Korth, Kluwer A ademi Publishers, pp. 153-181,

1996.

[5 B. Cameron Lesiuk, Routing in Ad ho networks of mobile hosts, Te hni al Re-

port, Department of Me hani al Engineering, University of Vi toria, Vi toria, Canada,

http://phantom.me.uvi . a/ lesiuk/thesis/reports/adho /adho .html

[6 C.E. Perkins and E.M. Royer, Ad-Ho On-Demand Distan e Ve tor Routing, Pro eedings

of 2nd IEEE Workshop on Mobile Computing Sysems and Appli ations, February 1999.

[7 V.D. Park and M.S. Corson, A Highly Adaptive Distributed Routing Proto ol for Mobile

Wireless Networks, Pro eedings of INFOCOM '97, April 1997.

[8 C.-K. Toh, A Novel Distributed Routing Proto ol To Support Ad-Ho Mobile Computing,

Pro eedings of the 1996 IEEE Fifteenth Annual International Phoenix Conferen e on Com-

puters and Communi ation, pp. 480-486, Mar h 1996.

[9 R. Dube, C.D. Rais, K.-Y. Wang, and S.K. Tripathi, Signal Stability based Adaptive Routing

(SSA) for Ad-Ho Mobile Networks, IEEE Personal Communi ations, pp. 36-45, February

1997.

[10 C.-C. Chiang, G.Pei, M.Gerla, T.-W. Chen, S alable Routing strategies for ad ho wireless

networks, IEEE Journal on Sele ted Areas in Communi ation, pp. 1367-79, Aug. 1999.

[11 Z.J. Haas and M.R. Pearlman, The performan e of a new routing proto ol for the re ong-

urable wireless networks, IEEE International Conferen e on Communi ations, pp. 156-60,

June 1998.

33
[12 Y.B. Ko and N.H. Vaidya, Lo ation-Aided Routing (LAR) in Mobile Ad Ho Networks,

Pro eedings of ACM/IEEE MOBICOM '98, O tober 1998.

[13 The ns-2 Manual, available at http://www.isi.edu/nsnam/ns/do /

[14 CMU Monar h Wireless and Mobility extensions to ns, available at

ftp://ftp.monar h. s. mu.edu/pub/monar h/wireless-sim/ns- mu.ps

34

S-ar putea să vă placă și