Dense cluster gateway based routing protocol for multi-hop mobile ad hoc networks

Ad Hoc Networks 4 (2006) 168–185

www.elsevier.com/locate/adhoc

Dense cluster gateway based routing protocolfor multi-hop mobile ad hoc networks

R.K. Ghosh a,*, Vijay Garg b, M.S. Meitei c, S. Raman c, A. Kumar c, N. Tewari c

a Department of CSE, IIT Kanpur, Kanpur 208 016, Indiab Electrical and Computer Engineering Department, University of Illinois at Chicago, Chicago, IL 60607, USA

c Department of CSE, IIT Guwahati, Guwahati 781 039, India

Received 28 October 2003; accepted 9 April 2004

Available online 15 June 2004

Abstract

In a multi-hop mobile ad hoc network dynamic clusterization of nodes can be quite effective for better management

of routing problems. In a cluster based protocol inter cluster data transfer takes place through the cluster gateways.

Therefore, it is important to maintain information about the gateways as a part of the routing tables in order that

the inter cluster routing proceeds smoothly even as the nodes move about. In this paper we propose a randomized ap-

proach for inter cluster routing over dense cluster gateways (DCG). A group of large number of gateway edges between

two adjacent clusters offering inter cluster connectivity between the two is referred to as a DCG. The minimum number

of gateway edges that define a DCG is dependent on the characteristics of particular ad hoc network. A DCG is ex-

pected to offer robust inter cluster connectivity as it typically has a large number of gateway edges. Our protocol is

an improvement over the cluster based routing using k-tree core backbone proposed in [Information Processing Letters

88 (2003) 187–194]. It distributes the routing load on the cluster gateways without adding the extra overhead of main-

taining information about dense cluster gateways. We also propose a heuristic which reduces the load on the cluster-

heads. The heuristic elects some nodes to act as sub-cluster-heads which share a part of the workload of the respective

cluster-heads. The protocol has been implemented on ns-2 simulator. An analysis of the result of the experiments has

been presented.

� 2004 Elsevier B.V. All rights reserved.

Keywords: k-Tree core; Ad hoc network; Cluster-head; Dense cluster gateway; Sub-cluster-head; Routing algorithm; Wheel game;

Load balancing; Back-bone topology

1570-8705/$ - see front matter � 2004 Elsevier B.V. All rights reserved.

doi:10.1016/j.adhoc.2004.04.011

* Corresponding author. Tel.: +91 512 2597645; fax: +91 512 2590725.

E-mail addresses: [email protected] (R.K. Ghosh), [email protected] (V. Garg), [email protected] (M.S. Meitei),

[email protected] (S. Raman), [email protected] (A. Kumar), [email protected] (N. Tewari).

mailto:[email protected]






R.K. Ghosh et al. / Ad Hoc Networks 4 (2006) 168–185 169

1. Introduction

A multi-hop mobile ad hoc networks is a spon-

taneous network of mobile nodes which move

freely and communicate with their peers via wire-less links. The nodes in an ad hoc network are

powered by batteries, which gets discharged over

time due to computations and communication be-

tween nodes. Therefore, the amount of communi-

cations and computations should be kept to a

minimum to avoid a node dropping prematurely

out of the network. The dynamic topology of a

large ad hoc network makes it difficult to managerouting information. Several cluster based routing

protocols [3,5] have been designed to take the

advantage of locality. These protocols attempt

restrict the broadcast of control messages. Also

provide a way to distribute the responsibilities

for maintaining routing information at the partic-

ipating nodes. Hence, reduce the load on the indi-

vidual nodes. The cluster-heads and the gatewaysare special nodes which have some added responsi-

bilities over the ordinary participating nodes in an

ad hoc network. A cluster-head keeps track of all

the nodes in a cluster, and the routing information

needed for efficient inter cluster communications.

The gateways are the nodes at the fringe of a clus-

ter and communicate with the gateways of the

neighbouring clusters.The cluster based routing using k-tree core back-

bone [9] proposes a two-tier hierarchical routing

scheme which combines the optimality of the short-

est path algorithms and at the same time restricts

flooding of control packets utilizing the low over-

head of the on-demand algorithms. Each cluster-

head lies on the k-tree core backbone and induces

a unique cluster––a subtree in the original spanningtree. A cluster-head takes the responsibility of

maintaining routing information about the mem-

bers of its cluster. It is obliged to listen to the route

request from any node within the cluster and re-

spond to that request with a route reply message.

The focus of the work in this paper is three-fold:

1. reducing the routing load of cluster-heads,2. efficient method of keeping cluster information,

3. distributing inter cluster routing loads among

the cluster gateways.

As mentioned earlier, the cluster gateways play

a critical role for routing the packets across the

clusters when source and destinations are in differ-ent clusters. In order to find a route between a

source and destination, the source must first send

a request to its own cluster head. Thus, the work-

load at a cluster-head is high and could be reduced

by sharing it with a sub-cluster-head. It would im-

prove the performance of traffic within a cluster

and also make k-tree core backbone robust. Real-

izing this we came up with the idea of dense clustergateway, sub-cluster-head, and a randomized ap-

proach for routing the packets over these dense

cluster gateways in order to distribute the routing

load on cluster gateways. Our idea is to exploit all

the cluster gateways and to reduce the bottleneck

at cluster-heads chosen by the k-tree core algo-

rithm [9]. Dense cluster gateway based routing

(DCGR) algorithm has been designed incorporat-ing all aspects of the routing like k-tree core, for-

mation of the clusters, identification of the dense

cluster gateways and also the most importantly

the balancing of routing load. We implemented the

protocol on ns-2 simulator [7]. The results of the

simulation are presented in Section 6.

2. Terminology and definitions

We follow the notation and definition as in [9].

Given a tree T, a k-tree core [4] of T is denned to

be the sub-tree T 0 with exactly k leaves which min-

imizes the sum of the distances from all other

nodes in T, where the distance of a node, v, from

a tree is defined to be the minimum distance fromv to any node in the tree. When k=2, T 0 is a simple

path and is called the 2-tree core or equivalently a

core of the tree.

More formally, let T denote an unrooted tree

with vertex set V(T). Let jT j denote the number

of vertices in T. A parent of a leaf node is defined

to be a node adjacent to that leaf. For a vertex v2T, we define the distance dðvÞ ¼

Pu2V ðT Þdðu; vÞ,

where d(u,v) is the length of the path from u to

v. If P is a path in T, then we define distance

of P, dðP Þ ¼P

u2V ðT Þdðu; P Þ, where dðu; P Þ ¼minv2pdðu; vÞ. A path is called a core of T if its

170 R.K. Ghosh et al. / Ad Hoc Networks 4 (2006) 168–185

distance is the minimum amongst all paths in

T. Let T 0 be a subtree of the tree T. We define

the distance of T 0, dðT 0Þ ¼P

v2V ðT Þdðv; T 0Þ where

dðv; T 0Þ ¼ minu2V ðT 0Þdðu; vÞ.Let the numbers of leaves in a tree v be denoted

by nleaves(v). A sub-tree, Sk, of a tree T containing

min(k,nleaves(Sk)) leaves is called a k-tree core if

dðSkÞ ¼ minSdðSÞ, where S is any sub-tree of T with

k or less leaves. We note that, as a consequence of

optimization criterion, the leaves of a k-tree core

will be the leaves of the tree T. We also note that

the k-tree core of a tree need not be unique.

In [4], a centralized algorithm is presented forcomputing the core using the concept of the

distance saved by a path. Let Pl,v be a path from

a vertex v to a leaf l2Tr. Then the distance saved

by this path, saved(Pl,v) is defined as d(v)�d(Pl,v).

The value of saved(Pl,v) is the important measure

for guiding the optimal selection of path exten-

sions from the vertex v. From the definition,

saved(Pl,v)> saved(Pl 0,v) if and only if d(Pl,v)<d(Pl 0,v) for l, l 02Tr. Consequently, minimizing

d(Pl,r) is equivalent to maximizing saved(Pl,r) over

leaves l2Tr.

3. Constructing the clusters

We follow the k-tree core approach in [9] forfinding the cluster-head and partitioning the net-

work graph into clusters but with a little difference.

The difference is in the format of Claim-Domi-

nating-Leaf (CDL) message and its propaga-

tion during the process of finding backbone of

cluster-heads. For the sake of completeness, we pre-

sent a quick review of the above approach in this

section.In the mobile ad hoc network, the connectivity

between nodes is decided by the wireless range of

broadcast signal. The topology of such a network

can have any arbitrary structure. Ideally, we re-

quire an optimal backbone of cluster-heads in

the mobile network which can be constructed from

a spanning tree with the leaves at the periphery of

the mobile network. First we construct a (distrib-uted) spanning tree which is the subgraph of the

network topology. The root of this spanning tree

should be located as much towards the center of

the network as possible. During the construction

of the spanning tree, we keep track of non-tree

edges as yellow edges. The yellow edges are used

to construct dense cluster gateways. The algorithmused for finding a spanning tree is essentially the

same as the algorithm used in k-tree core algo-

rithm [9] but with a simple modification so as to

take care of the non-tree edges. For convenience

in description of the algorithm, a color attribute

is associated with every node and every edge. This

attribute indicates the state of a node. As for

edges, the color attribute determines the role ofthe edge in the tree formed:

� Edges

� yellow: non-tree edge but part of the network

graph.

� green: tree edges which are part of the net-

work graph.

� Nodes� white: parent pointer=null, child list=null.

� gray: parent pointer=null, child list 6¼null.

� black: parent pointer 6¼null.

An a-cone around a node denotes a region of

space with the origin at that node and boundedby two rays with an angle a between them. An a-cone is empty when there are no neighboring

nodes in that region of space or if present they

are all black. The nodes which are on the periphery

will know there peripheral status by virtue of not

having any nodes, or only black nodes in some

a-cone as shown in Fig. 1.

3.1. Finding spanning tree

The algorithm consists of two phases. In the

first phase a spanning forest is constructed and

in the subsequent phase the trees of the forest is

merged together to form a spanning tree.

3.1.1. Finding forest

We do not propose any change in the first

phase. It is handled by each node executing the

procedure find_parent [9].

Backbone topology

Clusters

Nodes inside the cluster

Fig. 2. Backbone topology after merging the trees in forest.

alpha-cone

Gray node

White node

Black node

Fig. 1. a-Cone and find_parent procedure.


The nodes which turn black during execution offind_parent() do not accept any children since

this may result in the formation of cycles. After the

completion of this phase a distributed forest is

formed. Every tree belonging to this forest is trea-

ted as a directed rooted tree.

3.1.2. Connecting trees and identifying yellow edges

The trees of the forest found in first phase aremerged into a single spanning tree during the sec-

ond phase. The message for the interconnecting

trees are passed through broadcast sequence. A

node which does not take part in the interconnec-

tion process keeps listening for any new node it

can have an edge with and maintains an yellow

edge list containing the nodeid of such nodes.

The yellow edges discovered during this phase areused in the formation of dense cluster gateways.

3.2. Finding backbone of cluster-heads

A backbone of cluster-heads of the spanning

tree constructed above is determined again in the

same way as in [9] but with a little modification.

The difference is in the way the dominant leaf isfound. When each leaf node sends a Claim-Dom-

inating-Leaf (CDL) message up its parent in

the tree with its identity and its distance saved

value, it also sets a hop count value (=1). The

intermediate nodes in the upstream path need to

increment the hop count value by one while pass-

ing the message up to the cluster-head. This mod-

ification helps us in determining the depth of thesub-tree induced by the cluster-head which would

be used later in finding the sub-cluster-head. Each

node on the k-core i.e., a cluster-head, induces a

unique cluster. As shown in Fig. 2, each cluster

is basically a subtree in the original spanning tree,

and maintains routing information about the

members of its cluster in an hierarchical manner.With the modified version of k-core approach,

we are able to

� construct a backbone which minimizes the sum

of distances of all the other nodes in the network

and

� identify sub-cluster-heads which assist the clus-

ter-heads by sharing its workload in maintainingthe routing information.

4. Finding dense cluster gateway

The dense connectivity of the yellow edges be-

tween two adjacent clusters together to form the

connectivity which is termed as dense cluster gate-way. The group of yellow edges is called a gateway

as it provides inter cluster routes for the packets.

Fig. 3 depicts the set of yellow edges grouped to-

gether between two adjacent clusters forming the

dense cluster gateway. A dense cluster gateway

provides high bandwidth route and can be used

for load balancing on the gateways nodes. To ex-

ploit these gateways for the purpose of balancingof the inter cluster routing load, we describe a

randomized approach in selection of gateways in

Yellow Edges

A

B

Fig. 4. Yellow edges between clusters with head A and B.

Fig. 3. Yellow edges grouped together between two adjacent clusters form DCGs.


turn. Note that the yellow edges were discovered at

the time of connecting the directed trees. The algo-

rithm is as follows.

Step I. Each cluster-head sends report-yel-

low(Head) message to all the nodes in its cluster

down the subtree where Head is the nodeid of

the cluster-head.

Step II. Any node on receiving report-yel-

low(Head) message will note the nodeid Head as

its cluster-head and propagate the message to itschild nodes. The node will multicast report-

head (Head) message to the nodes in its yellow

edge list to report their cluster-head and will wait

for the reply to come back with a timeout value

set for the reply.

Step III. Any node on receiving report-

head(Head) message replies back with the

nodeid of the cluster-head if it knows and is dif-ferent from Head. If it does not know the id of its

cluster-head, then it waits for the report-yel-

low(Head)message in order to know the identity

of its cluster-head and then replies back if it is dif-

ferent from Head.

Step IV. After a node receives all the replies of

the report-head(Head) message or after time-

out, it forwards the nodeid of such nodes alongwith their cluster-head respectively to its own clus-

ter-head.

Step V. The cluster-head receives the responses

to report-yellow(Head) message as the gate-

way nodes in its cluster having a yellow edge with

a gateway in the neighboring cluster and the neigh-

boring cluster-head nodeid. This information is

maintained by the cluster-head in a table having

attributes neighboring cluster-head, gateway edge

(denoted by the gateway nodes pair).

A point to be noted here is that even before the

completion of this dense cluster gateway algo-

rithm, the communication between nodes could

have started. A table will be consulted to play

the random wheel game by the sub-cluster-head

which is discussed in the next section.In Fig. 4 we have shown the yellow edges be-

tween the clusters with head A and B. These yellow

edges grouped together for a pair of clusters form

the dense cluster gateway.


5. Finding sub-cluster-head

Many cluster based routing protocols (see [8])

have been designed for ad hoc networks. But a few

of them, like ZRP [2], take the cluster size intoconsideration. The election of sub-cluster-heads

within a cluster takes the cluster size into consid-

eration.

If the size of subtree induced by the cluster-head

is larger than a threshold and no sub-cluster-head

exists, then we can apply the sub-cluster-head elec-

tion algorithm. The two main parameters are: the

size and the threshold value. The size of the clustercould be measured either in terms of the depth of

the subtree or the density of nodes in the subtree.

We have chosen the depth of the subtree as a meas-

ure of the cluster size. The cluster-head knows the

depth with the help of Claim-Dominating-

Leaf message. The threshold value depends upon

the depth of the subtree.

After receiving the message from all its children,a cluster-head knows the depth of the subtree and

the node v which has reported the message with

maximum depth. If same depth is reported by

more than one child, then the tie could be resolved

by taking the node which has largest saved value

among them. The algorithm for finding the sub-

cluster-head is as follows:

Step I. A Claim-Sub-Cluster-Head mes-

sage is sent by the cluster-head to node v with

two fields of hop count value set equal to half

the depth of the subtree.Step II. The node which receives this message,

first checks the hop count value of the message.

If this hop count value is equal to zero, it be-

comes the sub-cluster-head and stores the second

hop value field in the Claim-Sub-Cluster-

Head message as radius. If the first hop

count field of Claim-Sub-Cluster-Head

message is not equal to zero, it decrements thishop count value by one and sends the message

to the child node which has the largest saved va-

lue.

Step III. The node which is elected as the sub-

cluster-head broadcasts IM-Sub-Cluster-

Head message with the hop count value equal to

the radius within the cluster.

Step IV. Each node receiving the message IM-

Sub-Cluster-Head propagates this message

by decreasing the hop count value by one.

Step V. The IM-Sub-Cluster-Head mes-

sage acts as an acknowledgment for the Claim-

Sub-Cluster-Head message. The cluster-head

sets a timeout value for receiving the acknowl-

edgment. The timeout value is set with the help

of radius, the average round trip time between

two nodes and some small time for processing

of the message. If the timeout occurs, the clus-

ter-head sends the Claim-Sub-Cluster-Head mes-

sage along some other path having same orlesser depth.

6. Routing algorithm

The proposed routing algorithm has a hierarchy

of two levels, namely, inter cluster route and intra

cluster route.Different approaches may be used for intra

cluster route. For example, the topology for intra

cluster routing may be maintained by a central-

ized head, or an on-demand routing like AODV

[6,8] may be used for intra cluster routing. The

on-demand routing appear to be quite effective

for a small set of highly mobile nodes within the

cluster but suffers from the frequent path findingoverhead. On the other hand, the centralized

topology based approach reduces frequent path

finding broadcast overhead, but suffers from the

overhead required for maintaining topology of

all members of the cluster at a central head node.

In our algorithm, we follow the centralized ap-

proach of maintaining the topology graph of the

cluster members at the sub-cluster-head using link

state updates (LSU) messages. The sub-cluster-

head sends the cluster topology using cluster

topology updates (CTU) to the cluster-head so

that it can respond to cluster membership query

(CMQ).

For inter cluster routes, the cluster-heads keeps

track of the inter-cluster connectivity using cluster

state updates (CSU). The cluster route is a se-quence of clusters from the cluster-head of the

source node to the cluster-head of the destination

node. The proposed routing algorithm is presented


below in four parts according to the role of the

respective nodes.

6.1. Actions of the sub-cluster-head

A source node trying to communicate first

checks its cache to find a route to the destination

node. If the route in cache is stale or not available,

it sends a route request RREQ(Dest) message to

the sub-cluster-head with Dest as the nodeid of

the destination.

After receiving RREQ(Dest) message, the sub-

cluster-head checks whether the destination nodebelongs to its own cluster or not. If Dest is a

member of its cluster, it replies back with the

shortest path between the two nodes as internal

route reply (IREP). Otherwise the sub-cluster-head

looks for a cluster route entry for Dest in its

cache. If there is no valid cluster route entry in

the cache, then it sends a cluster route request

CREQ(Dest) to the cluster-head. Prom the clusterroute reply (CREP) received in response to the

CREQ(Dest) message, it determines the neigh-

boring cluster and picks out the gateway edge to

route the packets to the neighboring cluster by

playing rotating wheel game. The sub-cluster-head

calculates the internal route to its gateway and

then sends the IREP message to the source.

Procedure handle_RREQ(packet){

destination=get_destination(packet)

cluster=find_next_cluster(destina-

tion)

gateway=rotate_wheel(cluster)

path=find_shortest_path(gateway)

send IREQ

}

Procedure rotate_wheel(cluster){

(for each gateway to cluster) {

gateway.wheelsector

=get_bandwidth(gateway)}

total_angle=360result=random(total_angle)sector_on_wheel

=get_sector_from_angle (result)

gateway=get_gateway_from_sector

(sector_on_wheel)

return gateway

}

The specification of random wheel game played

by sub-cluster-head for balancing routing load

among edges of a DCG and the intra cluster rout-ing required to route the data through the chosen

gateway edge is provided by in the pseudo-code

which appears above. A detailed discussion on

wheel game is provided separately in Section 7.

Note that the game is not directly related to the

routing protocol except that it is played by the

sub-cluster-head to distribute the routing load

among the gateway edges between two adjacentclusters.

6.2. Actions of the cluster-head

After receiving the CREQ(Dest) message, the

cluster-head checks whether it knows the cluster

in which the destination lies. If so, the cluster-head

sends cluster route reply (CREP) to the sub-cluster-head specifying the neighboring cluster to reach

the destination�s cluster through the shortest path

as known to the cluster-head. If it does not know

the destination�s cluster, it broadcasts a cluster

membership query (CMQ) within the core nodes.

The cluster-head of the destination replies with a

cluster membership reply (CMREP). The cluster-

head sends the CREP message to the sub-cluster-head.

6.3. Actions of the source node

When IREP is received from the sub-cluster-

head, the source node uses internal route send data

to the destination if the destination is in its cluster.

Otherwise it routes the data to the gateway in theIREP message if the destination belongs to a dif-

ferent cluster. The entire route is source coded by

the source node when it sends the data.

6.4. Actions of the gateway node

A gateway node can either send a packet from

its own cluster to a gateway node of a neighbouring

Backbone

Sub-Cluster-Head

Fig. 5. A sub-cluster-head.

Fig. 6. Rotating wheel.


cluster or it may receive a packet from a gateway

node of a neighbouring cluster. We deal the two

cases separately.

If a cluster gateway node receives a packet to be

routed to a neighboring cluster, it routes the pack-et to the neighboring cluster through the gateway

edge specified by the sub-cluster-head. If this spec-

ified gateway edge has died, then the gateway node

could send it to another gateway edge in the neigh-

boring cluster. The gateway node reports this to

the sub-cluster-head with the nodeid of the failed

gateway or of the successful gateway so that the

load table at sub-cluster-head can be updatedaccordingly.

A gateway node on receiving a packet from a

neighboring cluster first looks up for a path in

its cache. If it fails to get any it sends RREQ(D-

est) to the sub-cluster-head. The sub-cluster-

head would follow the steps as discussed earlier

in this section, to determine a route to the destina-

tion.

6.5. Actions of other nodes

If the receiving node is not a cluster gateway

and the packet contains its id as one of the intra

cluster hops, then it simply forwards the packet

to the next intra cluster hop. Note that these

nodes are intermediate nodes in the cluster whichoccur on an intra cluster route as a data packet

is being routed from a source to a destination

(Fig. 5).

7. Sub-cluster-heads playing the wheel game

Rotating wheel game is a random game whichconsists of a wheel partitioned into a number of

sectors labeled by numbers and a pointer fixed to

the axle of the wheel which points to one of the

sectors of the wheel. Fig. 6 gives a schematic illus-

tration of the rotating wheel game. The wheel is

rotated by giving a large random torque. It stops

after a completion of few cycles and the pointer

points to one of the sectors. The outcome of thegame is the number corresponding to the sector

pointed to by the pointer. The probability of a

number to be the outcome of the game depends

upon the arc length or the corresponding angle

subtended by the sector, with which the number

is associated.

A sub-cluster-head plays the rotating wheelgame to select a gateway edge from the dense gate-

way edges to route the packets. As the sub-cluster-

head is more concerned with intra cluster routing

information. The information related to inter clus-

ter routing is obtained from the cluster-head. The

cluster-head keeps the information about the clus-

ter gateways for each neighboring cluster in a

table. The information about gateway edges fromthe table is provided to the sub-cluster-head. Based

on this information it plays the rotating wheel

game. The sub-cluster-head maintains a load table


of the cluster gateways which consists of two attri-

butes edgeid and load where edgeid is the gateway

edge and load is the number of sources for which

that gateway edge is routing the data packets. Ini-

tially, the value of load corresponding to a gate-way is set to zero. The load of a gateway edge is

incremented by one for every source assigned to

that edge; and decremented by one when that

source has completed its communication. The

game played by the sub-cluster-head for load dis-

tribution is as follows:

1. Let M be the maximum load value in the loadtable entry for m gateway edges GE1,GE2, . . . ,GEm between a pair of adjacent clusters. The

sub-cluster-head determines the values B1,B2,

. . . ,Bm by subtracting each value of load in

the load table corresponding to the required

neighboring cluster from M+1.

2. Let S be the sum B1+B2+ � � �+Bm. The wheel is

partitioned into S sectors of equal sizes.3. In the partitioned wheel, the segment of Bi, con-

secutive sectors are mapped to the gateway

edges GEi, for 1 6 i 6 m.

4. The wheel is then rotated randomly. The gate-

way edge, corresponding to the sector that is

produced as outcome of the wheel game, is cho-

sen for routing. The load field of the chosen

gateway edge is incremented by one.5. The sub-cluster-head determines the node which

is the endpoint of this selected gateway edge and

lies in its cluster. The intra cluster route to this

node is sent to the source node; and the gateway

node is informed about the gateway edge se-

lected by the game for the inter cluster routing.

8. Expected gateway load balancing

The technique of computing the weights Bi,

1 6 i 6 m, of sectors at step 1 of the wheel game

implies that the probability of repeatedly selecting

a previously selected gateway edge decreases with

respect to selecting an unselected gateway edge

each time by a multiplicative factor. That is, if agateway edge es is selected repeatedly for k times

then its probability of selection reduced to 1/k

times of that of the probability of selecting an un-

selected edge. So it is expected that the routing

load will be assigned in a round-robin fashion over

the gateway edges for the inter cluster routing be-

tween two adjacent clusters. We have used a sim-

ple method of computing the weights of thesectors for partitioning the wheel to convey the

idea behind using the random wheel game instead

of employing sophisticated method for load bal-

ancing. Another factor that influenced the decision

to keep the computation simple is to keep the over-

head of wheel game as small as possible.

Assuming that initially the load on all the gate-

way edges between two adjacent clusters to besame; we can derive an expression for the lower

bound of the probability that after each cycle of

N routing decisions, the load on all the edges re-

main the same.

Let Pb, be the probability that the load is per-

fectly balanced after every cycle of N routing deci-

sions.

Let us consider the current cycle of N randomrouting decisions steps. For each step let Ps be

the probability that a selected gateway edge is se-

lected again and Pu be the probability that an un-

selected gateway edge is selected. At step 1, Ps=0

and Pu=2/2N. After the first step, one of the N

gateway edges gets selected, and hence, at step 2

Ps= I/(2N�1) and Pu=2/(2N�1). After step 2,

these probabilities are 1/(2N�2) and 2/(2N�2)respectively. Thus after ith step:

P s ¼1

2N � iand Pu ¼

2

2N � i:

At (i+1)th step, (N� i) unselected gateways are

left. Let Pti + 1be the probability that at (i+1)th

step one of the unselected gateways is selected.

Then

ptiþ1¼ ðN � iÞ 2

2N � i

� �1� 1

2N � i

� �i

:

Now, for the load to be balanced at the end of a N

step-routing cycle, at each step we should have se-

lected an unselected edge. Hence,

Pb ¼YN�1

i¼0

P tiþ1¼

YN�1

i¼0

ðN � iÞ 2

2N � i

� �1� 1

2N � i

� �i

:


Using the approximation in binomial expansion

up to the second term,

1� 1

2N � i

� �i

� 1� i2N � i

� �;

we get the following:

Pb �YN�1

i¼0

ðN � iÞ 2

2N � i

� �( )2

¼YN�1

i¼0

2N � 2i2N � i

� �2

¼2N

QN�1

i¼0

ðN � iÞ

QN�1

i¼0

ð2N � iÞ

8>>><>>>:

9>>>=>>>;

2

¼ N !2N

ð2NÞ!=N !

� �2

¼ ðN !Þ22Nð2NÞ!

( )2

:

Further simplification using Stirling�s approxima-

tion leads to

Pb >ðpNÞ1=2

2N:

The lower bound derived above decreases expo-

nentially with increase in number of edges in a

gateway.The number of gateway edges between two

adjacent clusters cannot exceed the minimum of

the cluster sizes. But in reality we noticed in an

average a DCG typically consists of 5 or 6 edges.

In a few cases we did observe a DCG to consist

of 10 or more edges. Though the expected proba-

bility of balanced distribution of load decreases

with increase in the number of gateway edges,the probability to have the routing loads distrib-

uted over different edges increases. For example,

if we consider the two scenarios for sending N

packets through

1. a DCG one consisting of 5 edges,2. a DCG consisting of 10 edges,

then it is observed that the load is distributed more

evenly on the edges of the DCG in case 1.

Whereas, each edge in the DCG in case 2 is likely

to carry a less load than an edge in the DCG in

case 1. This happens due the fact that the DCG

for case 1 has 5 less edges than the DCG for case

2. However, it may turn out that the load on each

edge in a DCG with 10 edges may not be as much

evenly distributed as compared to an edge in aDCG having 5 edges.

We used some approximations to arrive at the

probability bound. Besides that, the bound we de-

rived is only for perfect load balancing. Therefore,

the probability bound should be considered in thatprospective. In fact, with N=5, if we compare the

probability of selecting an unused gateway edge

against that of a previously selected gateway edge

even after 4 of the 5 edges have been chosen; the

latter is just the double of that of the former. So

the expected balancing of load turns out to be gen-

erally high. Apart from this, as explained earlier

the probability of selecting a unselected gatewayedge increases against that of repeatedly selecting

a previously selected edge by a multiplicative fac-

tor after each step. Therefore, the proposed rand-

omization scheme for load balancing works well in

practice.

9. Maintaining sub-cluster-heads

Once a node is elected as a sub-cluster-head, it

is desirable that the node continues as a sub-clus-

ter-head up to a maximum specified amount of

time or a budget defined to meet the characteristics

of the system like battery life of individual nodes

[1]. The sub-cluster-head retires after this budget.

It helps to evenly distribute the responsibility ofacting as sub-cluster-head among all the nodes.

When a sub-cluster-head is about to retire, it sends

a Claim-New-Sub-Cluster-Head message

along with the radius value to its neighboring node

having the lowest nodeid. This neighboring node

broadcasts IM-New-Sub-Cluster-Head mes-

sage with this radius value as the hop count value.

It is possible that there may be some nodes in thenetwork which were unable to receive IM-New-

Sub-Cluster-Head or IM-Sub-Cluster-

Head message. These nodes could be intimated

about the sub-cluster-head by their neighboring

nodes who have the information about the sub-

cluster-head.


10. Local repair of core

If a cluster-head dies out then the core has to be

recomputed. The overhead incurred in recomput-

ing the core could be reduced with the help ofsub-cluster-heads. The sub-cluster-head is aware

of the whole topology graph of the cluster. It also

has the knowledge of neighboring cluster-heads

with the help of information provided by its previ-

ous cluster-head. This information enables the

sub-cluster-head to find out a node which is at

one hop distance from the neighboring cluster-

heads. For convenience in discussion we denotethe above node as n. The sub-cluster-head sends

Claim-New-Cluster-Head message along

with the depth as twice the radius value and the list

of the neighboring cluster-heads to n. The node n

acknowledges it by broadcasting IM-New-Clus-

ter-Head message down its cluster members. It

also unicasts IM-New-Cluster-Head message

and the previous cluster-head id to all the neighbor-ing cluster-heads. The neighboring cluster-heads

update the cluster-head value and acknowledge it.

This way n becomes the new cluster-head for the

orphaned cluster.

It is possible that when the cluster-head dies

out, the sub-cluster-head could not find any node

which is at one hop distance from the neighboring

cluster-heads. In this situation, the sub-cluster-head tries to find out two nodes such that they

are at one hop distance from one neighboring clus-

ter-head but not in one hop range of the other

cluster-heads and these two nodes are in the wire-

less range of one another. Essentially, the pair of

nodes form a bridge between two adjacent clusters

on the core. The sub-cluster-head sends Claim-

Two-New-Cluster-Head message to these twonodes along with the list of the neighboring clus-

ter-heads and the list of orphaned nodes. These

two nodes unicast the message Join-Cluster-

Head with the list of orphaned nodes and a hop

count value as one. The respective orphaned nodes

on receiving this message check the hop count

value of the message and join the cluster-head hav-

ing lower hop count value. If two messages havingthe same hop count value reaches any node, then

the node selects one of the two cluster-head to join

with by tossing a coin. The orphaned nodes

send Joined-Cluster-Head message to the

respective cluster-heads. Joined-Cluster-

Head message acts as an acknowledgment for

Join-Cluster-Head message. The two clus-

ter-head sends each other the list of orphanednodes which have joined them thus ensuring that

all the orphaned nodes have joined one of the

two cluster-heads. These two cluster-heads broad-

cast UR-New-Cluster-Head message down

their respective cluster members. They also unicast

IM-New-Cluster-Head message and the previ-

ous cluster-head id to all the neighboring cluster-

heads within one hop distance. This way the corerepair is over.

11. Simulations

We implemented the DCGR routing protocol

in ns-2 and monitored the performance of our pro-

tocol with respect to the load on the Dense ClusterGateways (DCGs) and the variation in paths taken

to route data from a source to a destination. We

compared the load on nodes in DCGR with that

in AODV. Our studies showed that in DCGR

the variation of routed path is not very much dif-

ferent from the shortest path that AODV discovers

between a source and a destination. The topology

of the nodes that we followed for our simulation isshown in Fig. 7. The source node which is node 0

and the destination node which is node 99 are indi-

cated separately by big black squares in the net-

work topology.

11.1. Finding the backbone topology

The DCGR protocol followed the k-tree coreapproach [9] to find the backbone topology. A

suitably chosen value of a helps in identifying the

peripheral nodes and then create a backbone

topology with root nodes in between.

We experimented with various values of a for

the grid topology in Fig. 7. If we consider a convex

polygon of n sides, the sum of internal angles is

180* (n�2)=180n�360, or equivalently the sumthe external angles is 180n+360.

So any sweep angle less than (180n+360)/n=

180+360/n can be used to process the peripheral.

Fig. 7. Topology of grid size 1200·1200.


However, to expect the leaves of the tree to be lo-

cated strictly at peripheral, it is better to choose

the largest sweep angle. But it depends on n and

the shape of the space occupied by nodes. Since

limn!1

ð180þ 360=nÞ ¼ 180;

a=180� is the most appropriate sweep angle in the

worst case, when n ! 1. Typically, an ad hoc net-

work is bounded by limited space, and thus n is

Fig. 8. The position of the

small. So, in practice any angle greater than 180�will also do.

When a=90� the root of the spanning tree was

found to occur at position indicated by the darksquares labeled 1 in Fig. 8. Then we experimented

with a-values equal to 120�, 150�, 180� respec-

tively. The root occurred at the positions of dark

squares labeled 1 and 2. Taking a=210�, 240�,we found the root of the spanning tree to be

root for a=90�–240�.


located at positions where dark squares labeled 3

and 4 occur, in Fig. 8. As evident from Fig. 8,

the root is found to be near the middle of the grid

when we use a-values at 210�–240�. In certain

favourable situations, the root may be found nearthe middle with smaller a as indicated by the dark

square labeled 2 in Fig. 8.

A comparison of the relative time for computa-

tions for formation of spanning tree with different

values of the sweep angle a is provided by the plot

shown in Fig. 9. It may be observed the computa-

Fig. 9. Computation times for spanning tree with different

sweep angles.

3

4

5

13

14

15

23

24

25

16

6

26

36

7

17

27

37

47

25 56

0

Cluster Heads

Gateways between clusters 25 and 56 Gatew

Source

Fig. 10. Three clusters with cluster-heads 25, 56 and 96 and the DCGs

is to be routed from source 0 to destination 99.

tion time increases with a. The rise is found to be

gradual for 90 6 a 6 180 whereas for a=210 the

increase is sharp.

11.2. Load monitoring on the Dense Cluster

Gateways

After the Dense Cluster Gateways are identified

a packet has options to be routed to the next clus-

ter through the gateways of the DCG (Dense Clus-

ter Gateways) it belongs. The sub-cluster-head

selects the gateway for routing using the pseudo-

code shown in Section 6. We observed that theprobabilistic model distributes loads on each gate-

way evenly over a period of time.

We considered the clusters shown in Fig. 10

with cluster-heads 25, 56 and 96. About 1000

packets were sent from source 0 to destination

99. Then we studied the cumulative load on each

of the 12 gateways in the DCG between clusters

with cluster-heads 56 and 96. The graph in Fig.11 shows that cumulative load on the gateway con-

sisting of nodes 27–29. It is observed that the

cumulative load on that gateway increased line-

arly. At no time it stays constant or there is any

sharp increase. This means that the load is not

being equally shared by this gateway in the DCG.

19

9

29

39

49

59

96

99

ays between clusters 56 and 96

Destination

between them. These clusters are of our concern when a packet

Table 2

Cumulative load in passing 372 packets through the DCG

Gateways No. of packets Load % share

47–39 372 28 7.53

17–19 372 32 8.60

27–29 372 31 8.33

37–39 372 30 8.06

27–19 372 30 8.06

47–49 372 31 8.33

37–49 372 32 8.60

47–59 372 31 8.33

Fig. 11. Cumulative load on gateway edge 27–29. X -axis represents the number of packets passed. Y -axis represents the cumulative

load.


Tables 1 and 2 show the percentage share of

each of the 12 gateways in the DCGs when 12

and 372 packets are sent respectively. Table 1

shows that initially when a small number pack-ets were sent load was not shared equally

among the gateways. Table 2 shows that with

larger number of packets the load almost evenly

shared by all 12 gateways. We have also shown

the cumulative load variation in all the gate-

ways in Fig. 12. It may be observed that the

Table 1

Cumulative load on each of the 12 gateways when 12 packets

were sent through the DCG

Gateways No. of packets Load % share

47–39 12 2 16.67

17–19 12 2 16.67

27–29 12 2 16.67

37–39 12 1 8.33

27–19 12 1 8.33

47–49 12 1 8.33

37–49 12 1 8.33

47–59 12 1 8.33

17–29 12 1 8.33

7–19 12 0 0.00

7–9 12 0 0.00

17–9 12 0 0.00

17–29 372 32 8.60

7–19 372 32 8.60

7–9 372 30 8.06

17–9 372 31 8.33

load variation in the gateway is similar in all

the gateways. This implies that load has been

shared equally by all the gateways between the

clusters.We compared the cumulative load on any of the

nodes on the routing path using the AODV proto-

col with that using our protocol. The results are

shown in Fig. 13. In our protocol any two nodes

of the routing path followed among the DCGs

the load is shared evenly among the individual

gateways of the respective DCGs. So the gradient

of the curve corresponding to AODV is much

Fig. 12. Cumulative load on each of the 12 gateways.


greater than the gradient of the curve correspond-

ing to DCGR. In AODV the same shortest path isbeing followed each time but in the case of DCGR

the path will be different each time based upon the

rotating wheel game, hence the load is shared also

by other paths.

We also studied the overhead due to core com-

putation. The results are provided in Figs. 14–16.

In general, for low to moderate mobilities, the

Fig. 13. Cumulative loads of a particular pair of n

overhead of core computation is reasonably low

with moderate pause times.For 50 nodes, we used a grid area which is one

quarter (600·600) of that used for 100 nodes, while

for 80 nodes the size of grid used was 1000·1000. Ifwe consider the relative overheads for core compu-

tation with increasing number of nodes then we

find that for 50 or 80 nodes the overhead is quite

low. As far as relative overhead for 50 and 80 nodes

odes for both DCGR and AODV protocols.

Fig. 14. Overhead of core computation for 50 nodes.



are concerned, the overhead in the former case is

slightly low. This happens because the grid size in

the case of 50 nodes is much smaller than that used

in the case of 80 nodes. So the cluster changes are

more often in the first case than in the second case.

But overall the results are pretty close.

When pause time is low, then with high mobility

the overhead is about 6 packets per node for 100

nodes in a grid of 1200·1200 as in Fig. 16. This

is expected; because with high mobility and low

pause times the requirement for core computation

increases.



12. Conclusion

In this paper, we have proposed a new ap-

proach to cluster based hierarchical routing in

large mobile ad hoc networks. Our routing algo-rithm exploits the dense connectivity between clus-

ters to increase the available bandwidth and the

robustness of inter-cluster routes. With the rand-

omized approach of distributing the load over

the cluster gateways, we are able to provide load-

balancing over the gateway edges. The rotating

wheel game takes care of expected load factors

of all the gateway nodes without overhead of rin-ding the actual load information. We have also

introduced the concept of sub-cluster-head, which

takes care of intra-cluster routing information and

reduces the workload of the cluster-head. The sub-

cluster-head increase the robustness of the k-tree

core backbone by electing the cluster-head locally

instead of global recomputation of core.

References

[1] A.D. Amis, R. Prakash, Load-balancing clusters in wireless

ad hoc networks, in: Proceedings of ASSET 2000, March

2000.

[2] Z.J. Haas, M.R. Pearlman, P. Samar, The zone routing

protocol (zrp) for ad hoc networks, Technical Report,

Internet Draft, draft-ietf-manet-zone-zrp-04.txt, July 2002.

[3] C. Lin, M. Gerla, Adaptive clustering for mobile wireless

networks, IEEE Journal on Selected Areas in Communica-

tions 15 (7) (1997) 1265–1275.

[4] S. Peng, A.B. Stephens, Y. Yesha, Algorithms for a core

and k-tree core of a tree, Journal of Algorithms 15 (1993)

143–159.

[5] C.E. Perkins, Ad Hoc Networking, Addison-Wesley, Read-

ing, MA, 2000.

[6] C.E. Perkins, E.M. Belding-Royer, S.R. Das, Ad hoc on-

demand distance vector (aodv) routing, Technical Report,

Internet Draft, draft-ietf-manet-aodv-12.txt, November 2002.

[7] The VNIT Project, The ns manual (formerly ns Notes and

Documentation). Available from: <http://www.isi.edu/

nsnam/ns/doc/index.html>.

[8] E.M. Royer, C.-K. Toh, A review of current routing

protocols for ad-hoc mobile wireless networks, IEEE

Magazine on Personal Communication 17 (8) (1999) 46–55.

[9] S. Srivastava, R.K. Ghosh, Distributed algorithms for

finding and maintaining a k-tree core in a dynamic networks,

Information Processing Letters 88 (2003) 187–194.

R.K. Ghosh is a professor in ComputerScience and Engineering Departmentat the Indian Institute of Kanpur,India where he teaches courses onMobile Computing, Advanced GraphAlgorithms, Parallel and DistributedComputing. He graduated with amasters in science from RavenshawCollege, Cuttack, India. He receivedhis Ph.D. from the Indian Institute ofTechnology, Kharagpur, India. Hehad been a professor in the faculty ofComputer science and engineering at

IIT Guwahati, India during 2002–2003. He has co-authored a
book on parallel processing and published several technical
http://www.isi.edu/nsnam/ns/doc/index.html

http://www.isi.edu/nsnam/ns/doc/index.html


papers. He is a senior member of IEEE. His area of interest aremobile computing and wireless ad hoc networks.

Vijay Garg is a professor in the Elec-trical Engineering and ComputerEngineering Department at the Uni-versity of Illinois at Chicago, where heteaches courses in wireless communi-cations and wireless networking. Heworked at Bell Labs of Lucent Tech-nologies for the last 15 years; where heperformed various technical assign-ments dealing with wireless networks,network performance evaluations,teletraffic engineering, data communi-cation, etc. He received his Ph.D. from

the Illinois Institute of Technology, Chicago, in 1973 and his
MS from the University of California at Berkeley, California, in1966. He has co-authored several technical books, in the fieldsof advanced dynamics, railway vehicle dynamics, and tele-communications (Wireless and Personal Communications Sys-tem and Principle and Applications of GSM with Joe Wilkes,Application of CDMA in Wireless Communications with KenSmolik and Joe Wilkes, IS-95 CDMA and cdma 2000, andWireless Network Evolution 2G to 3G). He is a Fellow ofASCE and ASME and a senior member of IEEE. He is a reg-istered professional engineer in the states of Illinois and Maine.He is an academic member of the Russian Academy ofTransport. He has served on various technical committees ofIEEE, ASME, and ASCE. He has published approximately 100technical papers, and was a feature editor for the PCS series inIEEE Communication Magazine from 1996 to 2000.
M.S. Meitei received B. Tech. degreein Computer Science and Engineeringfrom Indian Institute of Technology,Guwahati, India in 2003. He is cur-rently working at Ensim India Pvt.Ltd., Pune. His research interest in-cludes Ad hoc networks, OperatingSystem, Security and WebhostingServices.

S. Raman received the B. Tech. degreein Computer Science and Engineeringfrom Indian Institute of Technology,Guwahati, India in 2003. He is cur-rently working as a member of re-search staff at IBM India ResearchLab, New Delhi. His research interestincludes QoS in IP Networks, Ad hocNetworks, Databases and InformationIntegration.

A. Kumar received his B. Tech studiesin Computer science and engineeringfrom IIT Guwahati in 2004. He isgoing to pursue his Masters studies incomputer science at SUNY-Buffalo.His area of interest lies in wirelessnetworks especially the network andMAC layer issues.

N. Tewari received the B. Tech. degreein Computer Science and Engineeringfrom Indian Institute of Technology,Guwahati, India in 2004. He is goingto pursue his Ph.D. in Computer Sci-ence at University of Virginia. His re-search interest includes wirelessnetworks, especially the network andMAC layer issues.

Dense cluster gateway based routing protocol for multi-hop mobile ad hoc networks

Documents