Geo-Assisted Multicast Inter-Domain Routing (GMIDR) Protocol for ...

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 characterized 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, commands, 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 routing, 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 multicasting 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 Differential 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

environment. There is one feasible solution to extend the intradomain routing protocol to the inter-domain routing protocol is adding inter-domain functions into the intra-domain protocol. 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 georouting strategy to reduce network overhead. Namely, each node is aware of its own geographical location, and the georouting 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 efficient 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 communication and achieve the scalability. Clusters are assigned

978-1-61284-231-8/11/$26.00 ©2011 IEEE


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 applications, but it is inefficient to send messages to a large group of receivers. Therefore, we propose the GMIDR multicast interdomain 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 interdomain 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


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 procedure. In the design of routing protocols, we pursuit a lower control overhead. To study the scalability and stability of GMIDR, the experiment results of comparison of variety number of multicast


7

100% Control overhead (bytes)

4

Delivery ratio

80% 60% 40%

5 group members 10 group members 15 group members 20 group members

20% 0% 10

20

30 40 Mobility speed (m/s)

(a) Delivery ratio

50

x 10

3

2 5 group members 10 group members 15 group members 20 group members

1

0 10

20

30 40 Moblity speed (m/s)

50

(b) Control overhead

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

4 Group with join and leave

80% 60% 40% 20% 0% 10

20


x 10

Constant group members

Constant group members

Control overhead (bytes)

A. Scalability and stability of GMIDR 1) Comparison of Variety Number of Multicast Members: We consider the multicast group as the receiver in our experiments. There are four different multicast group sizes are designed in experiments which are 5 nodes, 10 nodes, 15 nodes and 20 nodes respectively [3]. There are 5 senders and 20% of nodes are CHs in this group of experiment scenarios.

7

100%

Delivey ratio

members and dynamic multicast group in subsection A. We compare our protocol with ODMRP in subsection B to exhibit the outstanding performance of GMIDR. Additionally, we show applications of GMIDR in subsection C.

50

(a) Delivery ratio

Group with join and leave

3

2

1

0 10

20


50


Fig. 3: Delivery ratio and control overhead: dynamic multicast group vs. constant multicast group

one starts with 10 multicast group members, 5 new nodes join in and 5 nodes leave the group during the time of the simulation. 10% of nodes are CHs and there are 5 senders in the experiments. Fig. 3(a) represents the comparison of delivery ratio between constant multicast group and dynamic multicast group as a function of mobility speed. The constant multicast group shows a little bit better performance than the 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 mobility 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 multicast group members with 20% CHs. Fig. 4(a) shows the comparison of delivery ratio as the function of velocity. The


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

100% Control overhead (bytes)

4

Delivery ratio

80% 60% 40% 20%

GMIDR

x 10

3

2

1

GMIDR ODMRP

ODMRP 0% 10

20


50

0 10

20

(a) Delivery ratio


50


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 neighborhoods. 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%

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 of nodes bypass the geocast area. The figure shows that the success rate of more CHs is higher owe to its sufficient interdomain communication. The rate decreases as the growth of nodes speed from the perspective of single curve. We interpret it as two reasons. Firstly, the high speed makes the network changed frequently and it is difficult to maintain a stable connection. Secondly, nodes with higher speed stay shorter in the geocast area and thus they have less chance to receive packets. V. C ONCLUSIONS The proposed GMIDR protocol provides a scalable multicast routing mechanism for mobile ad-hoc networks. We introduce multicast GCHs to manage the multicast group. To overcome 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

Rate

40%

R EFERENCES

20 CHs

30% 20% 10% 0 10

20 30 40 Mobility speed (m/s)

50

Fig. 5: Success receiving rate of geocast 1) Geocast: Geocast [8] refers to the delivery of information to a group of destinations in a network identified by their geographical locations. There are several civil applications 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

[1] L. Ji and M. S. Corson, “Differential Destination Multicast-A MANET Multicast Routing Protocol for Small Groups”, in Proc. IEEE INFOCOM 2001. [2] P. Appavoo and K. Khedo, “SENCAST: A Scalable Protocol for Unicasting and Multicasting in a Large Ad hoc Emergency Network”, 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 Independent 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 Communications Surveys and Tutorials, 2009.