Вы находитесь на странице: 1из 5

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- environment. There is one feasible solution to extend the intra-
terized by the interconnection of heterogeneous domains. The domain routing protocol to the inter-domain routing protocol
same trend is emerging in civilian MANETs (e.g., search and is adding inter-domain functions into the intra-domain proto-
rescue, vehicular networks). In these networks it is important
to be able to efficiently propagate information across domains col. However, the revision may introduce additional control
in multicast mode (e.g., situation awareness dissemination, com- overhead and decrease the packet delivery ratio. To build
mands, streams). Several multicast protocols have been developed an efficient and scalable multicast routing, we introduce the
for single domain MANET. However, few can be extended to geographical assisted multicast inter-domain routing (GMIDR)
inter-domain operation. In fact, multicast routing across different protocol.
MANET domains faces the challenges of node motion, topology
changes, dynamic gateway election and, possibly, connectivity The main goal of our protocol is to achieve a scalable and
interruption. To overcome these challenges, especially to achieve efficient multicast routing in inter-domain networks. Also, it is
routing scalability and at the same time maintains efficient rout- important to minimize the control overhead and provide ways
ing, this paper proposes the Geo-assisted Multicast Inter-domain to handle inter-domain policy compliance and heterogeneity.
Routing (GMIDR) protocol based on geographical assistance and We utilize geo-routing protocol and cluster techniques to
cluster technology. Intensive simulation results show that the
GMIDR protocol is scalable and stable with various numbers achieve these goals. The proposed GMIDR applies the geo-
of multicast group members, and it outperforms other multicast routing strategy to reduce network overhead. Namely, each
protocols. Geocast by applying GMIDR shows the flexibility of node is aware of its own geographical location, and the geo-
the protocol. routing protocol looks for the node in the multicast group
based on the location information, which consumes much less
I. I NTRODUCTION
control overhead. To enable scalable and efficient routing,
The mobile ad-hoc network (MANET) inter-domain mul- cluster techniques is introduced. Clusters as the basic structure
ticasting comes out as an efficient communication paradigm in GMIDR in each domain help the protocol to obtain effi-
for the emerging multicast communications across multiple cient communication among different domains. Furthermore,
domains, e.g., large military operations, emergency and rescue multicast group cluster heads (GCHs) are elected within
missions. For instance, a commander-in-general would send the multicast group covering the entire multicast group. A
the order to the army, navy and air forces to cooperate each multicast tree is established from source to each GCH instead
other to finish an overall military mission. Also, a remote of each member in the multicast group. The GCH acts as
rescue surgery may need cooperation from multiple doctors the stronghold in its group cluster. It obtains the data from
physically located in different regions. These above-mentioned outside the group cluster, and delivers to all its children within
missions cover several areas and need fast response. Therefore, the group cluster. By taking advantage of GCH, our proposed
it is very important to define a network routing policy to protocol consumes very low control overhead on the group
disseminate data to different domains. Some civilian MANET management.
applications would also require an inter-domain multicast The remainder of this paper is organized in the following
routing protocol. For example, a vehicle driver may wish to way. The related work is briefly reviewed in section II. The
send a traffic situation message to a group of cars in different basic structure behind the protocol is discussed in section
domains. Multicast TV [4] on public transportation such as III. We describe the protocol design of GMIDR in details
buses requires scalable transmission to provide the multimedia in section IV. The performance evaluations are presented in
service. section V and the last section of the paper is our conclusion.
Towards this end, Ji and Corson have developed the Dif-
II. R ELATED W ORK
ferential Destination Multicast (DDM) protocol [1] which
aims to adapt to small multicast groups. SENCAST [2] is a A. Geo-based inter-domain routing (GIDR)
routing protocol designed for large ad hoc emergency network. Geo-based inter-domain routing (GIDR) [5] protocol for
However, these protocols are hard to meet the inter-domain MANET is an efficient unicast protocol to apply the clustering
multicast routing requirements. To the best of our knowledge, technique and geo-routing protocol to obtain the efficient com-
very few multicast procotols are designed to inter-domain munication and achieve the scalability. Clusters are assigned

978-1-61284-233-2/11/$26.00 ©2011 IEEE


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. Domain B

The cluster head (CH) is elected to take the role of local CH


CH
S GCH
DNS for its cluster subnet and its neighbor subnets. The
CH
CH advertises to its neighbors and connective members its Domain A
GCH
GCH
known information such as connectivity, members, and domain
information to other domains. When a source node wants to Route
RPF
transmit the data packet, it looks up the source’s local routing Multicast Group Domain C

table to find the destination node. If the destination node Fig. 1: Overview of GMIDR
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
B. Multicast Group Cluster Head (GCH)
head. Then the cluster head forwards the packet until it reaches
to the destination. We introduce the multicast group cluster head (GCH) to
The GIDR protocol uses geographical direction forwarding achieve the scalability of the multicast routing. As we have
routing as the routing mechanism to transmit the package to already indicated, multicast GCH is the node elected in the
the destination. Specifically, it exploits greedy forwarding as multicast group to assist the accomplishment of the multicast
its basic mode of operation to tackle the routing issue in data delivery. It would be a great complicated multicast tree
MANET. Whereas, the selected next hop may be not satisfied if the data packet were transmitted to every multicast group
with the greedy forwarding condition due to the presence member directly. Instead, the multicast tree is built only
of holes or obstacles. Instead of perimeter routing, GIDR between the source and GCHs. There are several GCHs chosen
switches to the direction forwarding. The packet is ”direction” in the multicast session to cover the entire group. The most
forwarded to the ”most promising” node in the indicated efficient GCHs are the dominating set of the multicast group.
direction. However, the construction of a dominating set is a complicated
GIDR works well in unicast inter-domain routing applica- question and costs very much computation resources. By
tions, but it is inefficient to send messages to a large group of relaxing the selection condition, we propose a distributed GCH
receivers. Therefore, we propose the GMIDR multicast inter- election algorithm. Our strategy of GCH election is described
domain protocol to adapt to new situations transmitting data as following: the first step is to find nodes with maximal
to large group members as we described in Section I. number of neighbors in the multicast group. If existing GCHs
cannot cover the whole group, the protocol will continuously
B. On Demand Multicast Routing Protocol(ODMRP) choose the GCH in the rest of the group until every node
in the multicast group can be reached in one hop by some
ODMRP [3] is an on demand multicast routing protocol for GCH. Obviously, multicast group clusters may overlap each
multihop wireless network. It reduces the network traffic by other during the election using this algorithm. To balance the
creating routes on demand. Each source and receiver keeps work load of each GCH, it is better to make the overlapping
broadcast join query and join reply to construct the routes. It nodes distribute evenly into clusters. Our scheme is to partition
maintains a forwarding group between sources and receivers overlapping nodes based on parity of the node ID. Namely, if
to forward multicast packet via scoped flooding. However, the overlapping node ID is odd, we consider it as a member
ODMRP suffers from a route acquisition. Meanwhile, it has of the old multicast group cluster. While if the overlapping
a problem of excessive flooding when number of multicast node ID is even, we put it to the new multicast group cluster.
senders are more. Besides, ODMRP is designed for one The algorithm is abstracted as Algorithm 1.
domain multicasting. It cannot work directly on the inter- GCHs compose the main trunk of the multicast tree. It takes
domain multicast directly. the role of stronghold to deliver multicast data to every end
of the multicast group. It is impossible that fixed multicast
III. P ROTOCOL D ESIGN GCHs cover the entire multicast group permanently due to
the mobility of networks. Hence, it is necessary to elect GCHs
A. Overview of GMIDR
periodically, but the reelection of GCHs in the entire multicast
The general architecture of GMIDR is represented in Fig. group leads to the reestablishment of the multicast tree, which
1. CHs are elected in each domain and multicast group cluster makes the multicast routing instable. Therefore, we introduce
heads (GCHs) are elected in the multicast group. Each GCH a scheme to ensure that the whole group can be covered by
finds routes to the source node. Then the source uses Reversed GCHs without frequent GCH reelection. Our approach is that
Path Forwarding (RPF) [6] technique to build multicast trees. each node periodically (i.e. 10s) checks its status if it still has
Following the established multicast tree, multicast data packets connection to its GCH. If it loses the connection from its GCH,
can be delivered from the source to every GCH. Upon a GCH it checks if there any other GCHs around. If it detects one in
receiving the data packet, it distinguishes its children from range, it switches its GCH to the one detected. Otherwise, it
members in the multicast group, and then forwards the packets elected itself as a temporary GCH. By this mean, all GCH
to its children. 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 D. Multicast Group Management


GCH ID ← 1 In GMIDR, there is no explicit control message for joining
while 1 do or leaving the multicast group. If a multicast GCH is going to
for each node k in multicast group do leave group, it simply stops sending the routing messages,
if N ode[k].num neighbor > N ode[GCH ID] then thus the reversed path for the node cannot be established.
GCH ID ← k Meanwhile, members of that GCH starts to switch to other
end if GCHs or elect themselves as temporary GCHs if no GCHs in
end for its range. If a child wants to leave the group, it stops sending
if GCH ID = −1 then subjection messages to its GCH to terminate its membership
break of the multicast group. If a group member node neither a GCH
end if nor a child intends to leave the group, the protocol changes its
for each node i in multicast group do membership to a normal node. On the other hand, if a node
if i is the neighbor of GCH ID then wants to join the multicast group,it changes its membership to
N ode[i].GCH ← GCH ID that multicast group and elect itself as a temporary GCH until
end if a GCH reelection across the entire multicast group.
end for
IV. P ERFORMANCE E VALUATION
if overlap then
for each node j in overlap do The GMIDR simulation is implemented on the platform
if N ode[i].ID is even then of Qualnet 3.9.5, which is widely used in wireless networks
N ode[j].GCH ← GCH ID simulation. Our simulation models run on the 1500m * 1500m
end if network area. The PHY/MAC protocol is IEEE 802.11b,
end for which has CSMA/CA with RTS/CTS. The channel capability
end if is 2 Mbps and the radio propagation range of each node is 375
end while meters. Each simulation executes 900 seconds of simulation
time [5, 7].
There are two domains in the network, and each domain
table. However, this local GCH detection procedure cannot be has 20 nodes. The total number of nodes in the network
used forever. Otherwise, all nodes in the multicast group may is 40. One multicast group is simulated in our experiment.
become GCHs, and GCHs will lose its meanings. Therefore, Multicast group members are randomly chosen with uniform
it is still necessary to do the entire network GCH reelection probabilities from the whole network. That means the nodes
but with less frequency (i.e. 200s). in the multicast group are from different domains. Nodes join
the multicast group at the beginning of the simulation and
C. Packet Transmission in Multicast Group remain as multicast group members throughout the simulation.
If multicast group members did not undertake the mission of Each source node as the sender sends multicast data with
forwarding packets, every GCH can simply finish the last step MCBR format at the rate of one packet per 2.25 seconds to
by forwarding data packet to its members in its own cluster the multicast group. The size of data payload is 512 bytes. The
in Internet based network. However, the case in MANET is a simulation takes RPGM [7] as the mobility model. Each node
little bit complicated. Every node in MANET can be taken as in a domain shares the common group motion. Besides, each
a router. Therefore, GCH has the duty to distinguish multicast individual node has an intra-group motion component. In our
group members who does not participate the packet forwarding scenario, the group speed of nodes is varied from 10 m/s to
and needs their GCHs send data to them. We call this kind of 50 m/s based on different scenarios[5], while the intra-group
members as the children of the GCH. speed is fixed in a range of 0 m/s to 5 m/s and the pause time
The challenge is how GCHs find out who are their children. is 10 s. We will evaluate GMIDR by following typical metrics
Intuitively, multicast group members who do not participate in [3, 7]:
the multicast routing are children of some GCH. We use the • Packet delivery ratio: The number of data packets
multicast routing table to figure out these nodes. It is clear delivered to multicast receivers over the number of data
that if a node participates the routing for a specific source and packets supposed to be delivered to multicast receivers.
multicast data packet, there will be one entry in the multicast The range of the delivery ratio is from 0 to 1. The
routing table of that node. Therefore, the children are nodes higher delivery ratio indicates the more efficient packets
that do not have an entry in their multicast routing table for the transmission.
specific source node. Unfortunately, it is impossible that the • Control overhead: The total bytes of control packets
GCH has all routing tables of its cluster member and only the needed to accomplish the entire multicast routing pro-
node itself has its own routing table. Hence, the node needs cedure. In the design of routing protocols, we pursuit a
to detect its own identity when they check their subjection lower control overhead.
relationship. Then, it send a message to the GCH to confirm To study the scalability and stability of GMIDR, the ex-
its subjection and report its status. 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


2
5 group members
in the experiments. Fig. 3(a) represents the comparison of
20%
10 group members
15 group members
1 10 group members
15 group members
delivery ratio between constant multicast group and dynamic
0%
10 20 30
20 group members
40 50
0
20 group members
multicast group as a function of mobility speed. The constant
10 20 30 40 50
Mobility speed (m/s) Moblity speed (m/s)
multicast group shows a little bit better performance than the
(a) Delivery ratio (b) Control overhead dynamic multicast group in terms of delivery ratio. This is
Fig. 2: Delivery ration and control overhead of different group dynamic change affects the construction of the multicast
multicast groups tree and some data packets may be lost in the process of the
reestablishment of the multicast tree. However, we see that
The delivery ratio of different multicast groups as a function the difference of delivery ratio is subtle. The reestablishment
of mobility speed is shown in Fig. 2(a). The tendency of of the multicast tree is completed with changing very limited
each curve decrease as the increasing of mobility speed. When numbers of branches. The pruning operation on the multicast
nodes move faster, the radio links among nodes are frequently tree only involves the GCH to add or remove nodes. Thus the
changed, which causes weaker node connectivity and thus multicast tree still keeps the stability.
reduces the packet delivery ratio. Additionally, as the change The comparison of control overhead as a function of mo-
of multicast group size, the difference of delivery ratio is less bility speed is illustrated in Fig. 3(b). The control overhead
than 10%, which shows the relative consistence. The multicast of constant multicast group is less than the control overhead
tree is built from source to GCH. Due to the distribution of of dynamic multicast group. The dynamic change of multicast
nodes is even which means that no matter large or small group, group members will trigger multicast tree to be pruned, which
almost the same number of GCH are elected in the group cost more control messages than the constant group members.
and thus will not affect the delivery ratio. Hence, the GMIDR However, the difference of control overhead between constant
protocol has stable delivery ratio in case of different multicast group members and group members with join and leave is
group sizes as a function of mobility speed. slight. As we discussed in the section of multicast group
Fig.2(b) is the presentation of control overhead for different management, both joining and leaving process do not need
multicast groups as a function of mobility speed. From the explicit messages and thus there is no distinguished difference
perspective of single curve, the fluctuation of the curve is on control overhead.
unobserving. This is because that each updates is driven by
a event (e.g., forwarding packet, periodical updates), which B. Comparison with ODMRP
are not affected by the mobility speed of nodes. These four In this section, we revised a intra domain routing protocol
curves show the consistence of control overhead for different ODMRP to a inter domain routing protocol to compare with
scenarios. Different numbers of multicast group members have our GMIDR protocol. There are two reasons making us choose
little impact on the control overhead. This consistence show ODMRP. Firstly, ODMRP is one of the widely used multicast
the advantage of GCH. It reduces the complexity to build protocol on MANETs and many protocols are developed based
the multicast tree and therefore the control overhead remains on it. Secondly, it is easy to modify the source code on
stable as the change of multicast group size. ODMRP to adapt to the inter-domain routing.
2) Dynamic Multicast Group: In this group of experiments, We add the basic structure such as clusters, domain split
we will show the results comparison between the dynamic and node isolation detection into ODMRP to guarantee that
multicast group and the network with constant multicast group ODMRP can be deployed on inter-domain networks. In this
members. group of experiments, we choose 5 sources and 10 multi-
There are two groups of simulation scenarios set up. One cast group members with 20% CHs. Fig. 4(a) shows the
contains 10 constant multicast group members. The other 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 radius in the simulation area of 1500m * 1500m. There are
outstanding performance attributes to the geo-based routing two domains and 20 nodes in each domain. The speed of
protocols. GMIDR can find each node by its geographical each node ranges from 10m/s to 50m/s. There is one source
location. It is efficient to forward packets to destinations. We sending packets at the rate of 5s per packet. The simulation
also conclude from Fig. 4(a) that both curves are in decreasing length is 200s simulation time. We measured the rate of nodes
trend as the increasing of speed. The higher mobility makes a receiving packets in geocast region as a function of node speed
lower delivery achievements. 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
100% x 10
4
success rate of more CHs is higher owe to its sufficient inter-

Control overhead (bytes)


80%
3 domain communication. The rate decreases as the growth of
Delivery ratio

60%
2
nodes speed from the perspective of single curve. We interpret
40% it as two reasons. Firstly, the high speed makes the network
1
20% GMIDR GMIDR
ODMRP
changed frequently and it is difficult to maintain a stable
ODMRP
0%
10 20 30 40 50
0
10 20 30 40 50
connection. Secondly, nodes with higher speed stay shorter
Mobility speed (m/s) Mobility speed (m/s)
in the geocast area and thus they have less chance to receive
(a) Delivery ratio (b) Control overhead
packets.
Fig. 4: Delivery ratio and control overhead: GMIDR vs.
V. C ONCLUSIONS
ODMRP
The proposed GMIDR protocol provides a scalable multi-
Fig. 4(b) represents the comparison of control overhead cast routing mechanism for mobile ad-hoc networks. We intro-
between GMIDR and ODMRP. The overhead of ODMRP duce multicast GCHs to manage the multicast group. To over-
increases as the increasing of node speed. This is conformed come the challenges caused by network mobility, the GMIDR
with the original ODMRP protocol. The curves show that protocol sends periodical beacons to guarantee the connectivity
ODMRP costs more control overhead than GMIDR. This is of the multicast routes. We also introduce the GCH-reelection
because GMIDR can detect neighbors by their locations but mechanism to ensure the efficiency of the GCHs and the
ODMRP needs to send beacons to aware of their neighbor- stability of the multicast tree. In our protocol, joining and
hoods. Though the result is somehow effected by functions we leaving multicast group have little impact on delivery ratio
added to ODMRP, considering GMIDR also including those and control overhead. The experimental comparison results
functions, we can conclude that GMIDR is better performed shows the scalability of the protocol with different number
than ODMRP in terms of overhead. of multicast group members. We also compared GMIDR with
other multiple protocol in the inter-domain mode. It shows
C. GMIDR Applications GMIDR outperformed than ODMRP in terms of delivery ratio.
In addition, by taking advantage of geo-routing protocol, the
50% GMIDR can be exploited to the geocast.
10 CHs
40% R EFERENCES
20 CHs
30%
Rate

[1] L. Ji and M. S. Corson, “Differential Destination Multicast-A MANET


20% Multicast Routing Protocol for Small Groups”, in Proc. IEEE INFO-
COM 2001.
10%
[2] P. Appavoo and K. Khedo, “SENCAST: A Scalable Protocol for
0 Unicasting and Multicasting in a Large Ad hoc Emergency Network”,
10 20 30 40 50
Mobility speed (m/s) International Journal of Computer Science and Network Security, vol.
8, no. 2, pp. 154-164, Feb. 2008.
Fig. 5: Success receiving rate of geocast [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.
1) Geocast: Geocast [8] refers to the delivery of informa- [4] A. Canovas, F. Boronat, C. Turro and J. Lloret, “Multicast TV over
tion to a group of destinations in a network identified by WLAN in a University Campus Network”, in Proc. ICNS 2009.
[5] B. Zhou, A. Tiwari, and et al. “Geo-based inter-domain routing (GIDR)
their geographical locations. There are several civil applica- protocol for MANETs”, in Proc. IEEE MILCOM 2009.
tions with geocast, such as finding nearby friends, geographic [6] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, “Protocol In-
advertising, and accident warning on a highway. In geocast, dependent Multicast – Sparse Mode (PIM-SM): Protocol Specification
(Revised)”, IETF RFC 4601 (proposed standard), Aug. 2006.
a node automatically becomes a member of a geocast group [7] X. Hong, M. Gerla, G. Pei, and C.-C. Chiang. A Group Mobility
if its location belongs to the geocast region. GMIDR can be Model for Ad Hoc Wireless Networks. Proceedings of ACM/IEEE
easily deployed as a geocast if we change the multicast group MSWiM’99; Seattle, WA, Aug. 1999.
[8] Maihofer, C., “A survey of geocast routing protocols”, in Communica-
as a fixed region. Different from multicast, the destination in tions Surveys and Tutorials, 2009.
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