This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts
for publication in the IEEE ICC 2011 proceedings
Geo-assisted Multicast Inter-Domain Routing
(GMIDR) Protocol for MANETs
Konglin Zhu ∗ , Biao Zhou + , Xiaoming Fu ∗ , Mario Gerla +
∗
Institute of Computer Science, University of Goettingen, Germany
+
Department of Computer Science, University of California, Los Angeles, USA
Email: {zhu, fu}@cs.uni-goettingen.de {zhb, gerla}@cs.ucla.edu
Abstract— Large military ad hoc networks are often charac-
terized by the interconnection of heterogeneous domains. The
same trend is emerging in civilian MANETs (e.g., search and
rescue, vehicular networks). In these networks it is important
to be able to efficiently propagate information across domains
in multicast mode (e.g., situation awareness dissemination, com-
mands, streams). Several multicast protocols have been developed
for single domain MANET. However, few can be extended to
inter-domain operation. In fact, multicast routing across different
MANET domains faces the challenges of node motion, topology
changes, dynamic gateway election and, possibly, connectivity
interruption. To overcome these challenges, especially to achieve
routing scalability and at the same time maintains efficient rout-
ing, this paper proposes the Geo-assisted Multicast Inter-domain
Routing (GMIDR) protocol based on geographical assistance and
cluster technology. Intensive simulation results show that the
GMIDR protocol is scalable and stable with various numbers
of multicast group members, and it outperforms other multicast
protocols. Geocast by applying GMIDR shows the flexibility of
the protocol.
I. I NTRODUCTION
The mobile ad-hoc network (MANET) inter-domain mul-
ticasting comes out as an efficient communication paradigm
for the emerging multicast communications across multiple
domains, e.g., large military operations, emergency and rescue
missions. For instance, a commander-in-general would send
the order to the army, navy and air forces to cooperate each
other to finish an overall military mission. Also, a remote
rescue surgery may need cooperation from multiple doctors
physically located in different regions. These above-mentioned
missions cover several areas and need fast response. Therefore,
it is very important to define a network routing policy to
disseminate data to different domains. Some civilian MANET
applications would also require an inter-domain multicast
routing protocol. For example, a vehicle driver may wish to
send a traffic situation message to a group of cars in different
domains. Multicast TV [4] on public transportation such as
buses requires scalable transmission to provide the multimedia
service.
Towards this end, Ji and Corson have developed the Dif-
ferential Destination Multicast (DDM) protocol [1] which
aims to adapt to small multicast groups. SENCAST [2] is a
routing protocol designed for large ad hoc emergency network.
However, these protocols are hard to meet the inter-domain
multicast routing requirements. To the best of our knowledge,
very few multicast procotols are designed to inter-domain
978-1-61284-233-2/11/$26.00 ©2011 IEEE
environment. There is one feasible solution to extend the intra-
domain routing protocol to the inter-domain routing protocol
is adding inter-domain functions into the intra-domain proto-
col. However, the revision may introduce additional control
overhead and decrease the packet delivery ratio. To build
an efficient and scalable multicast routing, we introduce the
geographical assisted multicast inter-domain routing (GMIDR)
protocol.
The main goal of our protocol is to achieve a scalable and
efficient multicast routing in inter-domain networks. Also, it is
important to minimize the control overhead and provide ways
to handle inter-domain policy compliance and heterogeneity.
We utilize geo-routing protocol and cluster techniques to
achieve these goals. The proposed GMIDR applies the geo-
routing strategy to reduce network overhead. Namely, each
node is aware of its own geographical location, and the geo-
routing protocol looks for the node in the multicast group
based on the location information, which consumes much less
control overhead. To enable scalable and efficient routing,
cluster techniques is introduced. Clusters as the basic structure
in GMIDR in each domain help the protocol to obtain effi-
cient communication among different domains. Furthermore,
multicast group cluster heads (GCHs) are elected within
the multicast group covering the entire multicast group. A
multicast tree is established from source to each GCH instead
of each member in the multicast group. The GCH acts as
the stronghold in its group cluster. It obtains the data from
outside the group cluster, and delivers to all its children within
the group cluster. By taking advantage of GCH, our proposed
protocol consumes very low control overhead on the group
management.
The remainder of this paper is organized in the following
way. The related work is briefly reviewed in section II. The
basic structure behind the protocol is discussed in section
III. We describe the protocol design of GMIDR in details
in section IV. The performance evaluations are presented in
section V and the last section of the paper is our conclusion.
II. R ELATED W ORK
A. Geo-based inter-domain routing (GIDR)
Geo-based inter-domain routing (GIDR) [5] protocol for
MANET is an efficient unicast protocol to apply the clustering
technique and geo-routing protocol to obtain the efficient com-
munication and achieve the scalability. Clusters are assigned
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
by the affinity among nodes in each domain of the network.
The cluster head (CH) is elected to take the role of local
DNS for its cluster subnet and its neighbor subnets. The
CH advertises to its neighbors and connective members its
known information such as connectivity, members, and domain
information to other domains. When a source node wants to
transmit the data packet, it looks up the source’s local routing
table to find the destination node. If the destination node
locates in the local domain, the source can deliver the data via
local routing protocol. However, if no information is found in
the local routing table, the data will be transmitted to a cluster
head. Then the cluster head forwards the packet until it reaches
to the destination.
The GIDR protocol uses geographical direction forwarding
routing as the routing mechanism to transmit the package to
the destination. Specifically, it exploits greedy forwarding as
its basic mode of operation to tackle the routing issue in
MANET. Whereas, the selected next hop may be not satisfied
with the greedy forwarding condition due to the presence
of holes or obstacles. Instead of perimeter routing, GIDR
switches to the direction forwarding. The packet is ”direction”
forwarded to the ”most promising” node in the indicated
direction.
GIDR works well in unicast inter-domain routing applica-
tions, but it is inefficient to send messages to a large group of
receivers. Therefore, we propose the GMIDR multicast inter-
domain protocol to adapt to new situations transmitting data
to large group members as we described in Section I.
B. On Demand Multicast Routing Protocol(ODMRP)
ODMRP [3] is an on demand multicast routing protocol for
multihop wireless network. It reduces the network traffic by
creating routes on demand. Each source and receiver keeps
broadcast join query and join reply to construct the routes. It
maintains a forwarding group between sources and receivers
to forward multicast packet via scoped flooding. However,
ODMRP suffers from a route acquisition. Meanwhile, it has
a problem of excessive flooding when number of multicast
senders are more. Besides, ODMRP is designed for one
domain multicasting. It cannot work directly on the inter-
domain multicast directly.
III. P ROTOCOL D ESIGN
A. Overview of GMIDR
The general architecture of GMIDR is represented in Fig.
1. CHs are elected in each domain and multicast group cluster
heads (GCHs) are elected in the multicast group. Each GCH
finds routes to the source node. Then the source uses Reversed
Path Forwarding (RPF) [6] technique to build multicast trees.
Following the established multicast tree, multicast data packets
can be delivered from the source to every GCH. Upon a GCH
receiving the data packet, it distinguishes its children from
members in the multicast group, and then forwards the packets
to its children.
Domain B
CH
CH
S GCH
CH
Domain A
GCH
GCH
Route
RPF
Multicast Group Domain C
Fig. 1: Overview of GMIDR
B. Multicast Group Cluster Head (GCH)
We introduce the multicast group cluster head (GCH) to
achieve the scalability of the multicast routing. As we have
already indicated, multicast GCH is the node elected in the
multicast group to assist the accomplishment of the multicast
data delivery. It would be a great complicated multicast tree
if the data packet were transmitted to every multicast group
member directly. Instead, the multicast tree is built only
between the source and GCHs. There are several GCHs chosen
in the multicast session to cover the entire group. The most
efficient GCHs are the dominating set of the multicast group.
However, the construction of a dominating set is a complicated
question and costs very much computation resources. By
relaxing the selection condition, we propose a distributed GCH
election algorithm. Our strategy of GCH election is described
as following: the first step is to find nodes with maximal
number of neighbors in the multicast group. If existing GCHs
cannot cover the whole group, the protocol will continuously
choose the GCH in the rest of the group until every node
in the multicast group can be reached in one hop by some
GCH. Obviously, multicast group clusters may overlap each
other during the election using this algorithm. To balance the
work load of each GCH, it is better to make the overlapping
nodes distribute evenly into clusters. Our scheme is to partition
overlapping nodes based on parity of the node ID. Namely, if
the overlapping node ID is odd, we consider it as a member
of the old multicast group cluster. While if the overlapping
node ID is even, we put it to the new multicast group cluster.
The algorithm is abstracted as Algorithm 1.
GCHs compose the main trunk of the multicast tree. It takes
the role of stronghold to deliver multicast data to every end
of the multicast group. It is impossible that fixed multicast
GCHs cover the entire multicast group permanently due to
the mobility of networks. Hence, it is necessary to elect GCHs
periodically, but the reelection of GCHs in the entire multicast
group leads to the reestablishment of the multicast tree, which
makes the multicast routing instable. Therefore, we introduce
a scheme to ensure that the whole group can be covered by
GCHs without frequent GCH reelection. Our approach is that
each node periodically (i.e. 10s) checks its status if it still has
connection to its GCH. If it loses the connection from its GCH,
it checks if there any other GCHs around. If it detects one in
range, it switches its GCH to the one detected. Otherwise, it
elected itself as a temporary GCH. By this mean, all GCH
relationship subjection can be checked based on local routing
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
Algorithm 1 Group Cluster Head Election Algorithm
GCH ID ← 1
while 1 do
for each node k in multicast group do
if N ode[k].num neighbor > N ode[GCH ID] then
GCH ID ← k
end if
end for
if GCH ID = −1 then
break
end if
for each node i in multicast group do
if i is the neighbor of GCH ID then
N ode[i].GCH ← GCH ID
end if
end for
if overlap then
for each node j in overlap do
if N ode[i].ID is even then
N ode[j].GCH ← GCH ID
end if
end for
end if
end while
table. However, this local GCH detection procedure cannot be
used forever. Otherwise, all nodes in the multicast group may
become GCHs, and GCHs will lose its meanings. Therefore,
it is still necessary to do the entire network GCH reelection
but with less frequency (i.e. 200s).
C. Packet Transmission in Multicast Group
If multicast group members did not undertake the mission of
forwarding packets, every GCH can simply finish the last step
by forwarding data packet to its members in its own cluster
in Internet based network. However, the case in MANET is a
little bit complicated. Every node in MANET can be taken as
a router. Therefore, GCH has the duty to distinguish multicast
group members who does not participate the packet forwarding
and needs their GCHs send data to them. We call this kind of
members as the children of the GCH.
The challenge is how GCHs find out who are their children.
Intuitively, multicast group members who do not participate in
the multicast routing are children of some GCH. We use the
multicast routing table to figure out these nodes. It is clear
that if a node participates the routing for a specific source and
multicast data packet, there will be one entry in the multicast
routing table of that node. Therefore, the children are nodes
that do not have an entry in their multicast routing table for the
specific source node. Unfortunately, it is impossible that the
GCH has all routing tables of its cluster member and only the
node itself has its own routing table. Hence, the node needs
to detect its own identity when they check their subjection
relationship. Then, it send a message to the GCH to confirm
its subjection and report its status.
D. Multicast Group Management
In GMIDR, there is no explicit control message for joining
or leaving the multicast group. If a multicast GCH is going to
leave group, it simply stops sending the routing messages,
thus the reversed path for the node cannot be established.
Meanwhile, members of that GCH starts to switch to other
GCHs or elect themselves as temporary GCHs if no GCHs in
its range. If a child wants to leave the group, it stops sending
subjection messages to its GCH to terminate its membership
of the multicast group. If a group member node neither a GCH
nor a child intends to leave the group, the protocol changes its
membership to a normal node. On the other hand, if a node
wants to join the multicast group,it changes its membership to
that multicast group and elect itself as a temporary GCH until
a GCH reelection across the entire multicast group.
IV. P ERFORMANCE E VALUATION
The GMIDR simulation is implemented on the platform
of Qualnet 3.9.5, which is widely used in wireless networks
simulation. Our simulation models run on the 1500m * 1500m
network area. The PHY/MAC protocol is IEEE 802.11b,
which has CSMA/CA with RTS/CTS. The channel capability
is 2 Mbps and the radio propagation range of each node is 375
meters. Each simulation executes 900 seconds of simulation
time [5, 7].
There are two domains in the network, and each domain
has 20 nodes. The total number of nodes in the network
is 40. One multicast group is simulated in our experiment.
Multicast group members are randomly chosen with uniform
probabilities from the whole network. That means the nodes
in the multicast group are from different domains. Nodes join
the multicast group at the beginning of the simulation and
remain as multicast group members throughout the simulation.
Each source node as the sender sends multicast data with
MCBR format at the rate of one packet per 2.25 seconds to
the multicast group. The size of data payload is 512 bytes. The
simulation takes RPGM [7] as the mobility model. Each node
in a domain shares the common group motion. Besides, each
individual node has an intra-group motion component. In our
scenario, the group speed of nodes is varied from 10 m/s to
50 m/s based on different scenarios[5], while the intra-group
speed is fixed in a range of 0 m/s to 5 m/s and the pause time
is 10 s. We will evaluate GMIDR by following typical metrics
[3, 7]:
• Packet delivery ratio: The number of data packets
delivered to multicast receivers over the number of data
packets supposed to be delivered to multicast receivers.
The range of the delivery ratio is from 0 to 1. The
higher delivery ratio indicates the more efficient packets
transmission.
• Control overhead: The total bytes of control packets
needed to accomplish the entire multicast routing pro-
cedure. In the design of routing protocols, we pursuit a
lower control overhead.
To study the scalability and stability of GMIDR, the ex-
periment results of comparison of variety number of multicast
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings

members and dynamic multicast group in subsection A. We 7

x 10
100% 4
compare our protocol with ODMRP in subsection B to exhibit Constant group members Constant group members

Control overhead (bytes)

80% Group with join and leave Group with join and leave
the outstanding performance of GMIDR. Additionally, we 3

Delivey ratio
60%
show applications of GMIDR in subsection C. 2
40%

A. Scalability and stability of GMIDR 20%

1

1) Comparison of Variety Number of Multicast Members: 0%

10 20 30 40 50
0
10 20 30 40 50
Mobility speed (m/s) Mobility speed (m/s)
We consider the multicast group as the receiver in our ex-
periments. There are four different multicast group sizes are (a) Delivery ratio (b) Control overhead
designed in experiments which are 5 nodes, 10 nodes, 15 nodes Fig. 3: Delivery ratio and control overhead: dynamic multicast
and 20 nodes respectively [3]. There are 5 senders and 20% group vs. constant multicast group
of nodes are CHs in this group of experiment scenarios.

100% 4
7
x 10
one starts with 10 multicast group members, 5 new nodes
join in and 5 nodes leave the group during the time of the
Control overhead (bytes)

80%
3
simulation. 10% of nodes are CHs and there are 5 senders
Delivery ratio

60%

40% 5 group members

20%
10 group members
15 group members
0%
10 20 30
20 group members
40
Mobility speed (m/s)
(a) Delivery ratio
Fig. 2: Delivery ration and control overhead of different
multicast groups
The delivery ratio of different multicast groups as a function
of mobility speed is shown in Fig. 2(a). The tendency of
each curve decrease as the increasing of mobility speed. When
nodes move faster, the radio links among nodes are frequently
changed, which causes weaker node connectivity and thus
reduces the packet delivery ratio. Additionally, as the change
of multicast group size, the difference of delivery ratio is less
than 10%, which shows the relative consistence. The multicast
tree is built from source to GCH. Due to the distribution of
nodes is even which means that no matter large or small group,
almost the same number of GCH are elected in the group
and thus will not affect the delivery ratio. Hence, the GMIDR
protocol has stable delivery ratio in case of different multicast
group sizes as a function of mobility speed.
Fig.2(b) is the presentation of control overhead for different
multicast groups as a function of mobility speed. From the
perspective of single curve, the fluctuation of the curve is
unobserving. This is because that each updates is driven by
a event (e.g., forwarding packet, periodical updates), which
are not affected by the mobility speed of nodes. These four
curves show the consistence of control overhead for different
scenarios. Different numbers of multicast group members have
little impact on the control overhead. This consistence show
the advantage of GCH. It reduces the complexity to build
the multicast tree and therefore the control overhead remains
stable as the change of multicast group size.
2) Dynamic Multicast Group: In this group of experiments,
we will show the results comparison between the dynamic
multicast group and the network with constant multicast group
members.
There are two groups of simulation scenarios set up. One
contains 10 constant multicast group members. The other
2
5 group members
in the experiments. Fig. 3(a) represents the comparison of
1 10 group members
15 group members
delivery ratio between constant multicast group and dynamic
50
0
20 group members
multicast group as a function of mobility speed. The constant
10 20 30 40 50
Moblity speed (m/s)
multicast group shows a little bit better performance than the
(b) Control overhead dynamic multicast group in terms of delivery ratio. This is
group dynamic change affects the construction of the multicast
tree and some data packets may be lost in the process of the
reestablishment of the multicast tree. However, we see that
the difference of delivery ratio is subtle. The reestablishment
of the multicast tree is completed with changing very limited
numbers of branches. The pruning operation on the multicast
tree only involves the GCH to add or remove nodes. Thus the
multicast tree still keeps the stability.
The comparison of control overhead as a function of mo-
bility speed is illustrated in Fig. 3(b). The control overhead
of constant multicast group is less than the control overhead
of dynamic multicast group. The dynamic change of multicast
group members will trigger multicast tree to be pruned, which
cost more control messages than the constant group members.
However, the difference of control overhead between constant
group members and group members with join and leave is
slight. As we discussed in the section of multicast group
management, both joining and leaving process do not need
explicit messages and thus there is no distinguished difference
on control overhead.
B. Comparison with ODMRP
In this section, we revised a intra domain routing protocol
ODMRP to a inter domain routing protocol to compare with
our GMIDR protocol. There are two reasons making us choose
ODMRP. Firstly, ODMRP is one of the widely used multicast
protocol on MANETs and many protocols are developed based
on it. Secondly, it is easy to modify the source code on
ODMRP to adapt to the inter-domain routing.
We add the basic structure such as clusters, domain split
and node isolation detection into ODMRP to guarantee that
ODMRP can be deployed on inter-domain networks. In this
group of experiments, we choose 5 sources and 10 multi-
cast group members with 20% CHs. Fig. 4(a) shows the
comparison of delivery ratio as the function of velocity. The
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
GMIDR protocol outperforms than the ODMRP protocol. This
outstanding performance attributes to the geo-based routing
protocols. GMIDR can find each node by its geographical
location. It is efficient to forward packets to destinations. We
also conclude from Fig. 4(a) that both curves are in decreasing
trend as the increasing of speed. The higher mobility makes a
lower delivery achievements.
100%
80%
Delivery ratio
60%
40%
20% GMIDR
ODMRP
0%
10 20 30 40
Mobility speed (m/s)
(a) Delivery ratio
Fig. 4: Delivery ratio and control overhead: GMIDR vs.
ODMRP
Fig. 4(b) represents the comparison of control overhead
between GMIDR and ODMRP. The overhead of ODMRP
increases as the increasing of node speed. This is conformed
with the original ODMRP protocol. The curves show that
ODMRP costs more control overhead than GMIDR. This is
because GMIDR can detect neighbors by their locations but
ODMRP needs to send beacons to aware of their neighbor-
hoods. Though the result is somehow effected by functions we
added to ODMRP, considering GMIDR also including those
functions, we can conclude that GMIDR is better performed
than ODMRP in terms of overhead.
C. GMIDR Applications
50%
40%
30%
Rate
20%
10%
0 Unicasting and Multicasting in a Large Ad hoc Emergency Network”,
10 20
Mobility speed (m/s)
Fig. 5: Success receiving rate of geocast
1) Geocast: Geocast [8] refers to the delivery of informa-
tion to a group of destinations in a network identified by
their geographical locations. There are several civil applica-
tions with geocast, such as finding nearby friends, geographic
advertising, and accident warning on a highway. In geocast,
a node automatically becomes a member of a geocast group
if its location belongs to the geocast region. GMIDR can be
easily deployed as a geocast if we change the multicast group
as a fixed region. Different from multicast, the destination in
geocast is marked with a geo-location, and geocast protocols
distinguish the group members by their coordinates. In this
scenario, we assigned a geocast region with a circle of 500m
radius in the simulation area of 1500m * 1500m. There are
two domains and 20 nodes in each domain. The speed of
each node ranges from 10m/s to 50m/s. There is one source
sending packets at the rate of 5s per packet. The simulation
length is 200s simulation time. We measured the rate of nodes
receiving packets in geocast region as a function of node speed
as shown in Fig.5. The rate is calculated by the number of
nodes receiving packets in geocast region over the number
7
of nodes bypass the geocast area. The figure shows that the
x 10
4
success rate of more CHs is higher owe to its sufficient inter-
Control overhead (bytes)
3 domain communication. The rate decreases as the growth of
2
nodes speed from the perspective of single curve. We interpret
it as two reasons. Firstly, the high speed makes the network
1
GMIDR
ODMRP
changed frequently and it is difficult to maintain a stable
50
0
10 20 30 40 50
connection. Secondly, nodes with higher speed stay shorter
Mobility speed (m/s)
in the geocast area and thus they have less chance to receive
(b) Control overhead
packets.
V. C ONCLUSIONS
The proposed GMIDR protocol provides a scalable multi-
cast routing mechanism for mobile ad-hoc networks. We intro-
duce multicast GCHs to manage the multicast group. To over-
come the challenges caused by network mobility, the GMIDR
protocol sends periodical beacons to guarantee the connectivity
of the multicast routes. We also introduce the GCH-reelection
mechanism to ensure the efficiency of the GCHs and the
stability of the multicast tree. In our protocol, joining and
leaving multicast group have little impact on delivery ratio
and control overhead. The experimental comparison results
shows the scalability of the protocol with different number
of multicast group members. We also compared GMIDR with
other multiple protocol in the inter-domain mode. It shows
GMIDR outperformed than ODMRP in terms of delivery ratio.
In addition, by taking advantage of geo-routing protocol, the
GMIDR can be exploited to the geocast.
10 CHs
R EFERENCES
20 CHs
[1] L. Ji and M. S. Corson, “Differential Destination Multicast-A MANET
Multicast Routing Protocol for Small Groups”, in Proc. IEEE INFO-
COM 2001.
[2] P. Appavoo and K. Khedo, “SENCAST: A Scalable Protocol for
30 40 50
International Journal of Computer Science and Network Security, vol.
8, no. 2, pp. 154-164, Feb. 2008.
[3] S.-J. Lee, W. Su, and M. Gerla, “On-Demand Multicast Routing
Protocol in Multihop Wireless Mobile Networks”, Mobile Networks
and Applications, vol. 7, no. 6, pp. 441–453, Dec 2002.
[4] A. Canovas, F. Boronat, C. Turro and J. Lloret, “Multicast TV over
WLAN in a University Campus Network”, in Proc. ICNS 2009.
[5] B. Zhou, A. Tiwari, and et al. “Geo-based inter-domain routing (GIDR)
protocol for MANETs”, in Proc. IEEE MILCOM 2009.
[6] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, “Protocol In-
dependent Multicast – Sparse Mode (PIM-SM): Protocol Specification
(Revised)”, IETF RFC 4601 (proposed standard), Aug. 2006.
[7] X. Hong, M. Gerla, G. Pei, and C.-C. Chiang. A Group Mobility
Model for Ad Hoc Wireless Networks. Proceedings of ACM/IEEE
MSWiM’99; Seattle, WA, Aug. 1999.
[8] Maihofer, C., “A survey of geocast routing protocols”, in Communica-
tions Surveys and Tutorials, 2009.