Preemptive Multicast Routing in Mobile Ad-hoc Networks

Transcription

1 Preemptive Multicast Routing in Mobile Ad-hoc Networks Uyen Trang Nguyen and Xing Xiong Department of Computer Science and Engineering York University, Toronto, Ontario Canada, M3J 1P3 {utn, Abstract Preemptive routing has been used for point-to-point (unicast) communications in mobile ad-hoc networks (MANETs) to minimize route breakage and end-to-end delay. In this paper, we present design and implementation issues of preemptive multicast routing. We then describe a preemptive multicast routing protocol based on ODMRP, which we call PMR (Preemptive Multicast Routing). Compared with ODMRP, PMR protocol offers higher packet delivery ratio and better scalability with less overhead. These advantages of PMR have been confirmed by simulation results. 1 Introduction Mobile ad-hoc networks (MANETs) require no fixed infrastructure or central administration. Mobile nodes in an ad-hoc network work not only as hosts but also as routers, and communicate with each other via packet radios. Characteristics particular to mobile ad-hoc networks are frequent changes of topology due to hosts mobility, limited energy, low bandwidth and unreliable communication. Mobile ad-hoc networks support many important applications such as search and rescue, disaster recovery, emergency support, tactical military, as well as group communication such as communication set-up in exhibitions, conferences, presentations, meetings, and lectures. Unicast routing protocols in MANETs can be classified as table-driven or on-demand. In both types of algorithms, an alternate path is sought only after the primary path fails. The consequences of this practice include packet losses resulting from link breakage and long delays before the failure is detected and a new path is established. Preemptive route maintenance allows detection of potential link breakage and establishment of an alternate path before the 1

2 disconnection occurs. This may prevent an actual route break and thus minimizes packet loss. When a route break cannot be avoided, the latency of new path establishment is reduced. Preemptive route maintenance has been shown to improve the performance of unicast routing [1, 2, 3]. In this paper we extend the concept of preemptive routing to multicast routing. Wireless ad-hoc networks are well suited for multicast because of their inherent broadcast capability. Multicast routing protocols designed for wired networks may fail to keep up with node mobility and frequent topology changes in a MANET. Those protocols also require node to store routing information, for which mobile hosts would not have sufficient storage or energy. Many multicast routing protocols have been proposed specifically for MANETs. They can be classified into two main groups: tree-based and mesh-based. Examples of tree-based protocols are AMRIS [4], MAODV [5], and LAM [6]. Studies have shown that tree-based protocols are not necessarily best suited for multicast in MANETs where network topology changes frequently. Mesh-based protocols have been shown to outperform tree-based protocols thanks to alternative paths which allow routing after primary paths fail. Among existing mesh-based protocols such as ODRMP [7], CAMP [8], and FGMP [9], ODMRP is the simplest protocol yet offers high packet delivery ratio and adapts well to high mobility of nodes. The main disadvantage of ODMRP is overhead caused by the flooding of join requests and join replies. This in turn affects the scalability of ODMRP. The traffic overhead and scalability problems of ODMRP can be remedied using preemptive routing. To reduce the overhead of flooding, the refresh interval should be increased (i.e., the frequency of flooding should be reduced). However, less frequent flooding will result in more route breaks, and an increase in packets lost. Preemptive routing is thus used to detect potential route breaks and, after detection, initiates a new route discovery using a join request. That is, between refresh messages, route discovery is initiated only when a potential route break is detected. Preemptive routing applied to ODMRP results in better performance due to: Reducing overhead of join requests by reducing the frequency of flooding Reducing the number of collisions of data packets that would have been caused by join requests in the original ODMRP. The result is less packet loss with less overhead. In this paper we describe a preemptive multicast routing protocol based on ODMRP, which we call PMR (Preemptive Multicast Routing). Compared with ODMRP, PMR protocol offers higher packet delivery ratio and better 2

3 scalability with less overhead. These advantages of PMR have been confirmed by simulation results. The concept of preemptive routing can also be applied to other multicast routing protocols in MANETs to improve their performance. In section 3, we provide, as examples, suggestions to add preemptive routing to CAMP and AMRIS protocols. This paper is organized as follows. Section 2 gives an overview of ODMRP, preemptive routing, and PMR protocol. Section 3 describes PMR in detail. Experimental results are presented in Section 4 to validate the effectiveness and performance of PMR. Section 5 concludes the paper. 2 Overview This section provides an overview of ODMRP, preemptive routing, and PMR protocol. 2.1 ODMRP Overview ODMRP creates a mesh of nodes (the forwarding group ) which forward multicast packets via flooding (within the mesh), thus providing path redundancy. In ODMRP, group membership and multicast routes are established and updated by the source on demand. When multicast sources have data to send, but do not have routing or membership information, they flood a JOIN DATA packet. When a node receives a non-duplicate JOIN DATA, it stores the upstream node ID (i.e., backward learning) and rebroadcasts the packet. When the JOIN_DATA packet reaches a multicast receiver, the receiver creates a JOIN TABLES and broadcasted to the neighbors. When a node receives a JOIN TABLE, it checks if the next node ID of one of the entries matches its own ID. If it does, the node realizes that it is on the path to the source and thus is part of the forwarding group. It then broadcasts its own JOIN TABLE built upon matched entries. The JOIN TABLE is thus propagated by each forwarding group member until it reaches the multicast source via the shortest path. This process constructs (or updates) the routes from sources to receivers and builds a mesh of nodes, the forwarding group. Multicast senders refresh the membership information and update the routes by sending JOIN DATA periodically. 3

4 2.2 Preemptive Unicast Routing Preemptive route maintenance allows a routing algorithm maintains connectivity by preemptively switching to a higher quality path when the quality of the currently used path is deemed suspicious. Preemptive routing initiates recovery action early by detecting that a link is likely to be broken soon and searching for a new path before the current path actually breaks. Specifically, a preemptive routing algorithm consists of two components: (1) detecting that a path is likely to be broken soon; (2) searching for a new path and switch to it. A critical design issue of a preemptive routing protocol is to determine when a path should be replaced (which triggers the search for a new path). The quality of a path can be evaluated based on several factors such as signal strength, hop count, the age of the path, and traffic load. The algorithm in [1] uses the signal strength of received packets as the primary criterion with the hop count being used as the second measure. The protocol in [2] also uses signal strength, more specifically the SNR (signal-to-noise ratio), as a measure of path quality. In MANETs most route breaks are caused by link failures due to node mobility. Therefore the signal strength is the most direct indication of how well mobile hosts can communicate with each other. We thus use signal strength as a measure of path quality in the PMR protocol. 2.3 Preemptive Route Maintenance for Multicast: Design Issues Implementing preemptive route maintenance with multicast is not a trivial task due to multiple senders/receivers, and the broadcast nature of ad-hoc data transmission. The most serious problem is feedback implosion. The problem of feedback implosion is best explained using a tree structure (although the underlying routing structure can be a mesh, as in the case of ODMRP). If the routing structure is viewed as a logical tree, we can define the following relationships between any two nodes, A and B, with respect to the source and the logical tree in the routing mesh [10]: Direct: packets are routed trough A before reaching B. Indirect: packets that reach A and B share some common path from the source. No relationship: packets that reach A and B do not share in any common paths from the source. 4

5 S Figure 1: A logical tree in the routing mesh In Figure 1, nodes 10 and 11, for example, have a direct relationship. If link (9, 10) is a bout to break, both nodes 10 and 11 (and 12) would detect this fact and generate two different warning messages. However, only one warning, for example from node 10, would be sufficient. Nodes 6 and 8 have an indirect relationship. If both links (5,6) and (7,8) are about to break, nodes 6 and 8 would both send different warning messages one right after another, while only one warning would suffice to inform the source of both potential breakages. Feedback implosion has two implications when applying preemptive route maintenance to multicast. The first implication is high traffic overhead caused by warning messages. To overcome this problem, there must be a feedback suppression mechanism to minimize the number of warning messages traveling in the network. Without a feedback suppression mechanism, several warning messages caused by the same broken link would cause a sender to flood the network with several duplicate route refresh messages, consuming resources unnecessarily and causing collision: this is the second implication of the feedback implosion problem. Nodes 2 and 10 have no relationship. It may happen that two nodes with no relationship send warning messages to a source and the two warning messages arrive at the source one right after another. The source would then send out two refresh messages one right after another, although only one refresh message should take care of both warnings. Thus in this case, we also need to make sure that (unrelated) warning messages arriving at a source at a high frequency are suppressed properly to avoid unnecessary flooding that could be worse than the flooding of refresh messages in the original ODMRP algorithm. 5

6 In preemptive unicast routing, the receiver estimates channel condition based on the signal strength of the receive packet, and sends a warning message to the source if needed. In multicast, a route break may affect several receivers. Thus a potential route break should be relayed to the source as quickly as possible: instead of letting receivers estimate channel condition and send feedback, a forwarding (intermediate) node can do that when it detects a potential route break. In summary, when preemptive route maintenance is applied to multicast, the following design issues must be considered: (1) feedback implosion; (2) high frequency of (unrelated) route refresh messages; (3) detection of potential route breaks by intermediate nodes for early feedback. In the next section we describe the PRM protocol that addresses the above design issues. 3 The PMR Protocol In this section we present a preemptive multicast routing protocol based on ODMRP [7]. We chose ODMRP because it is simple yet offers high packet delivery ratio and adapts well to high mobility of nodes. The main disadvantage of ODMRP is high overhead, and thus scalability, caused by the flooding of join requests and join replies. Preemptive routing is exploited to minimize the overhead and improve the scalability of ODMRP. Although preemptive routing is described in the context of ODMRP, it can be applied to other multicast routing algorithms to minimize overhead and/or improve their performance, as will be discussed on Section??. The main idea of applying preemptive routing to ODMRP is to reducing the frequency of flooding the network with JOIN_QUERY packets. Since the interval between route refreshments is now longer, more route breaks and thus packet loss may happen between route refreshments. Potential route breaks will be taken care of by PRM to prevent actual breakage and packet loss. If very few or no route breaks occur, we save overhead on unsent JOIN_QUERY packets. If several route breaks occur between route refreshments, the PRM algorithm is designed so that the frequency of route re-building is the same as the frequency of flooding in the original ODMRP. Thus in the worst-case scenario (e.g., high mobility), the overhead of PRM is similar to that of the original ODMRP. Similar to a preemptive unicast routing protocol, in PRM, when a node receives a data packet, it compares the signal strength from the packet against a threshold value. If the signal 6

7 strength is lower than the threshold, a warning message may be generated and sent to the source. Unlike a preemptive unicast routing protocol, PRM allows intermediate (forwarding) nodes to detect potential route breaks and send warning messages. The reason is to inform the source of the potential route break as early as possible since an actual route break in a multicast group may affect many receivers. We now describe how to solve the problems of feedback implosion and high frequency of unrelated route refresh messages at the source, using the aforementioned examples illustrated by Figure 1. Direct relationship: Link (9, 10) is about to break. Node 10 sends a warning message to the source, and forwards the data packet to 11. Since the signal strength is weak, node 11 would also send a warning message to the source, and so would node 12. To suppress the warnings from 11 and 12, node 10 sets a bit "WarningGenerated" in the header of the data packet. Before nodes 11 and 12 attempt to send a warning, they check the bit and will not send if the bit is set. Indirect relationship: Links (5, 6) and (7, 8) are about to break. Nodes 6 and 8 send warnings to the source. Node 4 will see both messages. If the warnings are received sufficiently far apart, node 4 will forward both to the source. If they arrive soon one after another, the warning message arrives later will be suppressed. That is, if at least MinRefreshInterval seconds has elapsed since the last warning was forwarded to the source S, the current warning is forwarded to S; otherwise it is discarded. No relationship: Links (1,2) and (9,10) are about to break. Nodes 2 and 10 send warnings to the source. The source receives both warning messages. If the warnings are received sufficiently far apart, the source will send a JOIN_QUERY for each warning. If they arrive soon one after another, the warning message arrives later will be ignored. That is, if at least MinRefreshInterval seconds has elapsed since the last JOIN_QUERY was sent by the source, a new JOIN_QUERY is sent in response to the current warning; otherwise the current warning is ignored. Therefore if MinRefreshInterval is set to the value of the JOIN_QUERY refresh interval of ODMRP, then in the worst case scenario (i.e., high mobility and thus many route breaks) route establishment of PRM behaves as the flooding of JOIN_QUERY packets in ODMRP. Following is the detailed description of the PRM protocol that is built on top of ODMRP operations. 7

8 Each data message has a bit WarningGenerated. Each node has a bit SentWarning S for each multicast source S. Each source node has a bit SentJoinRefresh for each multicast group. A sender sends a join query when a timer expires (e.g., every 12 seconds), or when it receives a warning message and its SentJoinRefresh = FALSE. When a node receives a data message from source S with a receiving power below a threshold SignalThreshold, o If SentWarning S = FALSE and WarningGenerated = FALSE, the node (1) creates a control warning message and unicasts to S (using the route defined by the routing tables); (2) sets SentWarning S and WarningGenerated to TRUE; (3) forwards the message to the next nodes. o If SentWarning S = TRUE and WarningGenerated = FALSE, this means that the node just sent a warning to S some short time ago. Thus the node simply sets WarningGenerated to TRUE and forwards the message to the next nodes. o If SentWarning S = FALSE and WarningGenerated = TRUE, this means that another node upstream has sent a warning to S. The current node thus simply sets SentWarning S to TRUE and forwards the message to the next nodes. o If SentWarning S = TRUE and WarningGenerated = TRUE, the node simply forwards the message to the next nodes. When a node receives a warning message destined for a source S, o If SentWarning S = FALSE, the node unicasts the warning message upstream towards the source using its routing table. o If SentWarning S = TRUE, the node simply ignores and discards the warning message (because it just forwarded a warning message to S just some short time ago). When a source S receives a warning message destined for it, o If SentJoinRefresh = FALSE, the source broadcasts a JOIN_REFRESH message and sets SentJoinRefresh to TRUE. o Otherwise, it simply ignores the current warning (since it just sent a JOIN_REFRESH just some short time ago). 8

9 Whenever a node in the forwarding mesh receives a non-duplicated data message or a join refresh, it updates its entries in the routing table. (Note that ODMRP only updates routing table when a join query is received.) The purpose is to keep routing tables up to date, because routing tables are used by both join replies and warning messages. A non-sender node will set its bit SentWarning S to FALSE every MinRefreshInterval seconds (e.g., MinRefreshInterval = 3), OR after a join refresh is received. A sender will set its bit SentJoinRefresh to FALSE every MinRefreshInterval seconds, OR after a join refresh is sent. The next section presents experimental results that show the effectiveness and performance of PRM in comparison with ODMRP. 4 Experimental Results Our experiments are carried out under GloMoSim environment, which provides scalable simulations for wireless networks. We compare the performance of PRM and ODMRP. The refresh intervals of ODMRP are 3 and 30 seconds respectively. In PMR, the minimum warning interval is 6 seconds and the maximum refresh interval is 30 seconds. We have used the following metrics in the comparison: Packet delivery ratio: the ratio of the number of data packets actually delivered to the receivers versus the number of data packets supposed to be received. This metric indicates the effectiveness of a protocol. Total number of packets (control and data) transmitted per data packet delivered: this measure shows the efficiency in terms of channel access. The smaller the value is, the less contention a protocol would cause. We measure the above metrics a functions of node mobility, the number of senders, and the network load. The experiment setting is similar to that in [11]. We used similar setting in order to reproduce the experiments in [11] for verification, and to make a fair comparison of PRM with ODMRP. Specifically, in all the experiments, we modeled a network of 50 mobile hosts placed randomly within a 1,000m x 1,000m area. Radio propagation range for each node was 250m, and channel capacity was 2 Mbps. Each node has an average number of neighbors of 6.8. The duration of each simulation was 600 seconds. Each experiment was run several times using 9

10 different seed numbers, and collected statistics were averaged over those runs. Members of a multicast group were selected with uniform probability among the 50 mobile hosts. The members join the multicast group at the beginning of the simulation and stay until the whole group is terminated. The senders of a multicast group were chosen randomly among the multicast group members, and transmitted at a constant bit rate. The packet size excluding the header size is 512 bytes. The channel and radio model and the medium access control protocol are as described in [11]. 4.2 Mobility Speed In each experiment, the nodes moved constantly with the predefined speed. The speeds were varied from 0 m/sec to 20 m/sec. Moving directions of the nodes were selected randomly; when they reached the simulated terrain boundary, they bounced back and continued to move. In the following experiments, 20 nodes are multicast members and 5 senders each transmit packets at a rate of 2 packets/sec. The results are shown in Figures 2 and 3 and provide the following observations: Fig. 2 10

11 Fig. 3 When mobility is low, PMR and ODMRP_30 give similar delivery rates. The frequency of sending JOIN_QUERY does not make a big difference when node mobility is low. As we expected, PMR has a higher delivery rate than ODMRP_30 when mobility is high, because PMR sends JOIN_QUERY more frequently, when potential route breaks are identified. Unexpectedly, PMR even offers a higher delivery rate than ODMRP_3. The reason is that ODMRP_3 sends a large number of JOIN_QUERY packets, many of which may be unnecessary. These unnecessary JOIN_QUERY packets do not help improve delivery rate, but cause more packets collisions. From Fig. 3, we can see that ODMRP_3 transmits much more packets than PMR, a lot of which are control packets. The ratio R = Total number of packets transmitted per data packet delivered of PMR is a bit higher than that of ODMRP_30. That is due to warning and route refresh packets. But that is the cost for a higher packet delivery ratio PMR gives over ODMRP_ Number of Senders The multicast group size in these experiments is 20 nodes and node mobility speed is at set at 15 m/sec. The network traffic load is controlled at 10 packets/sec. We varied the number of senders in the multicast group from 1 to 20. The simulation results are shown in Figures 4 and 5. 11

12 We can see that PMR offers a higher delivery ratio than ODMRP_3, while the overhead in terms of number of control packets is significantly lower. The packet delivery ratio and overhead of PMR is comparable to those of ODMRP_30. Fig. 4 Fig. 5 12

13 4.4 Traffic Load In this experiment, there were 20 multicast group members, five of which were senders. There was no mobility; thus packet drops were only caused by collision, congestion and buffer overflow. The network traffic load was varied between 1 packet/sec and 50 packets/sec. The results are given in Figure 6. 5 Summary Figure 6 We present design principles for incorporating preemptive route maintenance to a multicast routing protocol. The most important issue is to solve the feedback implosion problem. We apply design principles to built a preemptive multicast routing protocol, PMR, that works in conjunction with ODMRP. Experimental results show that PMR improves the packet delivery ration while reducing the overhead incurred by ODMRP. References [1] Tom Goff, Nael B. Abu-Ghazaleh, Dhananjay S. Phatak, and Ridvan Kahvecioglu, Preemptive Routing in Ad Hoc Networks, Mobile Computing and Networking, [2] Yih-Chun Hu and David B. Johnson, Design And Demonstration Of Live Audio And Video Over Multihop Wireless Ad Hoc Networks, MILCOM

14 [3] P. Abhilash, Srinath Perur and Sridhar Iyer, Router Handoff: An Approach for Preemptive Route Repair in Mobile Ad Hoc Networks, Proc. of High Performance Computing, [4] C. Wu and Y. Tay, AMRIS: A Multicast Protocol for Ad hoc Wireless Networks, Proceedings of IEEE MILCOM '99, Atlantic City, NJ, Nov [5] E. Royer and C. Perkins, Multicast Ad hoc On- Demand Distance Vector (MAODV) Routing, IETF, Intemet Draft: draft-ietf-manet-maodv-00.txt, [6] LAM [7] ODRMP [8] CAMP [9] FGMP [10] B.N. Levine and J.J. Garcia-Luna-Aceves, ``Improving Internet Multicast with Routing Labels, 'Proc. IEEE ICNP '97, Atlanta, Georgia, Oct [11] ODMR comparison paper 14