Rate-adaptive Multicast in Mobile Ad-hoc Networks

Transcription

1 Rate-adaptive Multicast in Mobile Ad-hoc Networks Uyen Trang Nguyen and Xing Xiong Department of Computer Science and Engineering York University Toronto, Canada M3J P3 {utn, Abstract A current trend in wireless communications is to enable wireless devices to transmit at different rates. That multirate capability has been defined in many standards such as 802.a, 802.b, 802.g, and HiperLAN2. We propose a Rate-Adaptive Multicast () protocol that is multirate-aware. During the process of path discovery, the quality of wireless links is estimated to suggest optimal transmission rates, which are then used to calculate the total transmission time incurred by the mobile nodes on a path. Among several considered paths from a source to a destination, selects the path with the lowest total transmission time. Our work is the first that proposes the use of the multirate capability in multicast. The proposed protocol works with any multirate standards, and does not require any modifications to the standards. Our simulation results show that outperforms single-rate multicast in terms of packet delivery ratio, packet end-to-end delay, and throughput of the multicast group. I. INTRODUCTION Mobile ad-hoc networks (MANETs) require no fixed infrastructure or central administration. Mobile nodes in an adhoc 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 communications in exhibitions, conferences, presentations, meetings, and lectures. A current trend in wireless communications is to enable wireless devices to transmit at different rates. Many standards supporting this capability have been made available, such as 802.a, 802.b, 802.g, and HiperLAN2. For example, 802.b specifies rates of Mbps, 2 Mbps, 5.5 Mbps and Mbps. Rate adaptation is the process of dynamically switching data rates to match the channel conditions. The goal is to select a rate that will give the optimum throughput given the channel conditions. The motivation behind the multirate capability stems from the fact that consumers desire both high rates and long transmission ranges. However long range transmissions must operate at low rates; otherwise the error rate would be very high. Similarly high rate transmissions must occur over short distances to maintain a tolerable bit error rate (BER). The multirate capability offers consumers the flexibility of choosing between high speeds and long ranges. Devices and standards have been made to support this tradeoff. In addition, several rate-adaptation protocols have been proposed for wireless local area networks (WLANs) [], [2], [4], [5], as well as MANETs [3], [6] [8]. Experimental results and analysis from these papers indicate that multirate transmissions significantly improve network throughput. The proposed protocols however were designed for unicast (point-to-point) communications. Our work presented in this paper aims at exploiting the multirate capability to support multicast. Multicast refers to one-to-many or many-to-many communications. The above examples of group communications are typical multicast applications. Wireless ad-hoc networks are well suited for multicast because of their inherent broadcast capability. Many multicast routing protocols have been proposed specifically for MANETs [9] [3]. Currently most multicast routing protocols tend to select the shortest path from a sender to a receiver. Such a path contains a minimum number of hops between the source and the destination; the distances between hops are thus long, and the transmission rates should be low. A low transmission rate incurs long transmission time, which results in low throughput and high energy consumption. We expect that another route selection criterion combined with multi-rate transmission can help improve the situation. For example, we could choose paths that are slightly longer than the shortest paths (i.e., having more hops) but on which distances between neighboring nodes are shorter. Shorter distances allow mobile nodes to be connected for a longer time when they move, increasing reliability of routes. Shorter distances between multicast nodes also permit transmissions at rates higher than the base rate, lowering transmission time, increasing network throughput, and thus reducing energy consumption. By the above reasoning, it seems that long paths would give better performance. That may not always be the case however. It is true that the longer the path, the shorter the links on that path tend to be and the higher the transmission rate that can be achieved. However more hops are needed to reach the destination. Each hop incurs contention delay for accessing wireless channels. Furthermore, the selected path will affect the traffic load of other flows on that path, and the congestion level at the nodes within the interference range of the path. Therefore finding an optimal path for the best performance is not an easy task, especially in a large network. It is not practical or productive either in a MANET because as soon as such a path is found, mobile nodes may move, making that

2 path no longer optimal. Therefore, instead of taking into account all factors that could affect the performance of a route, we consider a very simple routing metric: among several paths between a sender a a receiver, the routing protocol selects the path with the lowest total transmission time. As mentioned above, low transmission time helps increase throughput and reduce energy consumption. Experimental results will show that even this simple route selection criterion can offer significant improvement over single-rate multicast. Specifically, we propose a Rate-Adaptive Multicast () protocol based on ODMRP [2]. ODMRP is a mesh-based multicast protocol that is simple yet offers high packet delivery ratios and adapts well to high mobility of nodes.isa multirate-aware routing protocol: During the process of path discovery, the quality of wireless links is estimated to suggest optimal transmission rates, which are then used to calculate the total transmission time incurred by the mobile nodes on a path. Among several considered paths from a source to a destination, the routing protocol selects the path with the lowest total transmission time. Experimental results show that outperforms single-rate multicast in almost all scenarios, in terms of packet delivery ratio, packet end-to-end delay, and throughput of the multicast group. Our work is the first that proposes the use of the multirate capability in multicast. The proposed protocol does not require any modifications to the standards, and it works with any multirate standards. In this paper we present in the context of 802.b. The paper is organized as follows. Related work is presented in Section II. The proposed protocol is described in detail in Section III. Section IV provides experimental results to illustrate the effectiveness and performance of the protocol. Section V summarizes the paper. II. RELATED WORK Rate adaption involves two stages: channel quality estimation and rate selection. Several metrics can be used as indicators of channel quality such as signal-to-noise ratio, signal strength, symbol error rate, or bit error rate. The rate selection procedure then uses the channel quality estimate to select an appropriate rate. A common technique of rate selection is to compare the value of the channel quality indicator against a list of threshold values representing boundaries between the data rates [5], [6]. With respect to channel quality estimation, the Autorate Fallback (ARF) rate adaptation scheme implemented in Lucent s 802. WaveLAN-II networking devices uses the receipts or absence of acknowledgments (ACKs) as an indication of channel quality. The Receiver-Based Autorate (RBAR) protocol [2], on the other hand, uses the strength of received The main drawback of ODMRP is control overhead caused by the flooding of route refresh control packets to keep routes up-to-date, especially when the number of senders in the multicast group is high. This problem can be overcome using preemptive route maintenance as suggested by Nguyen et al. [4]. signals. This method gives faster and more accurate estimate than the use of ACKs. The protocol proposed by Pavon and Choi for WLANs [4] combines the use of signal strength and the frame error rate to determine the transmission rate. All the above protocols were originally designed for WLANs, and can be applied to MANETs [3]. However these rate-adaptation protocols operate independently of the routing protocol. Therefore if the routing protocol finds a short path with long hops, the rate-adaptation protocol might not be able to use high rates. The protocol we propose incorporate rate selections into the routing protocol for optimal performance. The Opportunistic Media Access (OMA) protocol [6] uses RBAR for channel quality estimation and rate selection. Once the rate is calculated and the channel is reserved, the source will send for a duration as if the base rate were used. That is, a flow with a data rate of Mbps will transmit 5.5 times as many packets as a flow with a data rate of 2 Mbps. This scheme aims at achieving temporal fairness, as opposed to throughput fairness in RBAR. The rate-adaptation schemes proposed by Qiao et al. for WLANs [5] and Awerbuch et al. for MANETS [7] are based on theoretical models of the attainable throughput in WLANs/MANETS. The models permit us to compute link rates that maximize the throughput. The models however make simplifying assumptions (e.g., all nodes in the network are within each other s transmission range [7]), and the rate computation assumes that the packet size is known in advance and that all packets have the same size. A multirate-aware routing protocol for MANETs was proposed by Seok et al. [8]. The protocol requires a new sub-layer called Multirate Aware Sub-layer (MAS) to be added between the network layer and the MAC layer. The route discovery procedure still searches for the shortest path. When the data packets are actually routed, the MAS layer will attempt to find a two-hop sub-path between every pairs of nodes on the shortest path that can offer transmission time shorter than that of the one-hop link. The major drawback of this protocol is the addition of the MAS layer, which requires considerable modifications to the standards. The protocol we propose is the first multirate-aware routing protocol for multicast. It is simple, yet offers significant improvement over single-rate multicast, as will be proved by simulation results. It works with any multirate standards, and require no modifications to the standards. III. THE PROTOCOL In this section, we first present an overview of ODMRP to facilitate the discussion of the protocol. We then describe the protocol in detail. A. Overview of ODMRP 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

3 to send, but do not have routing or membership information, they flood a JOIN QUERY (route refresh) packet. When a node receives a non-duplicate JOIN QUERY, it stores the upstream node ID (i.e., backward learning) and rebroadcasts the packet. When the JOIN QUERY packet reaches a multicast receiver, the receiver creates a JOIN REPLY and broadcasts the JOIN REPLY to the neighbors. When a node receives a JOIN REPLY, 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 REPLY built upon matched entries. The JOIN REPLY 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 QUERY periodically. B. Routing Metric of the Protocol Awerbuch et al. propose to use the medium time metric (MTM) for multirate-aware routing for unicast in MANETs [7]. The MTM assigns a weight to each link that is proportional to the amount of medium time used by sending a packet on that link. The medium time includes the time spent backing off during contention, plus the overhead and the transmission time of a full RTS (Request To Send), CTS (Clear To Send), DATA, and ACK (acknowledgment) exchange. Note that the RTS and CTS are sent at the Mbps base rate, while the DATA and ACK are transmitted at the selected link rate (obtained from measuring the signal strength of the received RTS). Assuming a network with full interference (i.e., all the nodes are within each other s transmission range), the authors show that a routing protocol that chooses a path having the smallest weight maximizes the network throughput. In practice the assumption of full interference does not often hold true, especially in larger MANETS. As such the MTM may not deliver the optimal throughput as assumed. However simulation results have shown that the use of MTM as a routing metric, rather than the shortest-path metric, did indeed improve network throughput [7]. Currently the medium access control for multicast is simply CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance); there is no RTS/CST exchange, nor ACK. Therefore the medium access time of multicast flows is simpler, consisting of only the contention time and the transmission time of the DATA packet. We simplify the metric even further by eliminating the contention time component for the following reasons: Without the contention time component, computing the link weights does not require the packet size. The estimate of the average time spent backing off during contention is 30 µsec (the value of half the minimum contention window size multiplied by the slot time) [7]. The estimate contention time is small compared with the transmission time of data packets, especially when the link Packet Size 52 bytes 024 bytes 500 bytes Trx Rate Mbps Mbps Mbps Mbps TABLE I TRANSMISSION TIMES (IN µsec) OF PACKETS OF VARIOUS SIZES AT DIFFERENT RATES SUPPORTED BY IEEE 802. rates are low. See Table I, which lists the transmission times of packets of various sizes at different link rates. Including the contention time in the routing metric does not guarantee optimal throughput as explained above, since the assumption of full interference does not always hold. Our goal is to improve network throughput over the case of singlerate transmission, rather than offering optimal throughout. Our simulation results will show that a simple routing metric that considers only data transmission time can significantly improve the throughput over the case of single-rate transmission. In our protocol, the routing metric is transmission times of data packets. Each link is assigned a weight that is inversely proportional to the the transmission rate of the link as determined by the signal strength of a received packet. The weight of a path is the sum of the weights of the links on that path. Given several paths between a sender and a receiver, will select the path that has the smallest weight, i.e., the path that will incur the lowest total transmission time. Note that ignoring the contention time in the routing metric may result in a path with many high-rate links (e.g., a path with ten -Mbps links, and thus having a weight of 0 )being chosen over a path with a small number of low-rate links (e.g., a path with one -Mbps link, and thus having a weight of one). However the throughput of the longer path is lower than that of the shorter path due to contention at each of the ten -Mbps links (a detailed explanation can be found in [7]). Our protocol provides a heuristic that minimizes the probability that this case will ever happen, as described in the next sections. C. Overview of the Protocol Given the optimal transmission rate R of a link (as determined by the signal strength of a received packet), the weight of the link is defined as /R. The weight of a path is the sum of the weights of all the links on that path. In designing the protocol, we considered two main issues: () path selection based on path weights; and (2) computing transmission rates (at the physical layer) of the nodes on the selected paths. JOIN QUERY packets are used for estimating channel conditions, and for accumulating the weights of the links on the paths they traverse (in a field called pathw eight). Every node on paths between a sender and a receiver, after receiving ajoinquery, measures the signal strength of the packet, which is then compared against a set of threshold values to

4 suggest a transmission rate, SuggestedRate, using an algorithm similar to RBAR [3]. The SuggestedRate is converted to a link weight, which is then added to the pathw eight recorded in the JOIN QUERY. After the JOIN QUERY arrives at a receiver node and is processed, field pathw eight contains the weight of the source-to-destination path traversed by the JOIN QUERY. A node participating in the route discovery/refresh process may receive multiple JOIN QUERY packets from the same sender that take different paths. The node examines all these JOIN QUERY packets and selects the JOIN QUERY, and hence the path, with the minimum pathw eight value. This process is termed as JOIN QUERY consolidation. If the node is a receiver, the selected path is the source-to-destination path incurring the lowest total transmission time among those examined. The receiver then creates a JOIN REPLY that records the routing information, and sends the JOIN REPLY to the source, as in the ODMRP algorithm. To prevent the implosion of JOIN REPLY packets, every node on the paths from the receivers to the sender consolidates information from several JOIN REPLY packets it receives from downstream 2 nodes into one JOIN REPLY, as in ODMRP. This process is termed as JOIN REPLY consolidation. In unicast communications, every data packet is preceded by an RTS/CTS exchange, and the current channel condition, and thus the transmission rate of a node, can be estimated from the signal strength of the RTS. Since there is no RTS/CTS exchange in multicast, channel conditions must be estimated from JOIN QUERY packets, and the resulting rates are stored at the routing tables of the nodes in the routing mesh, and used for future data transmissions. The rate information is updated with every route refresh. Note that the recorded rates may become inaccurate before the next route refresh round due to nodes mobility. However they still offer better performance than single-rate multicast, as will be shown in our experimental results. Specifically, when a node n receives a JOIN QUERY from an upstream node p, it suggests a SuggestedRate based on the signal strength of the JOIN QUERY, and the SuggestedRate is stored in the routing table of n. After n receives a JOIN REPLY from downstream (or creates a JOIN REPLY if n is a receiver), it adds the recorded SuggestedRate to the JOIN REPLY (in addition to updating the routing information as required by ODMRP), and sends the JOIN REPLY to p. This is the transmission rate p should usetosenddataton, as suggested by the signal strength of the JOIN QUERY measured by n. Note however that p may receive several JOIN REPLY packets from different downstream nodes, and the SuggestedRate values in these JOIN REPLY packets may be different. Therefore p will select the minimum SuggestedRate value among those it has seen during that JOIN QUERY consolidation interval, so as to accommodate the downstream link with the lowest quality. Node p will then use the selected rate to transmit data packets 2 Downstream direction is from a sender toward a receiver. to its neighboring downstream nodes. Note that all transmissions of JOIN QUERY and JOIN REPLY packets use the base rate (e.g., Mbps in 802.b) to ensure that they are received correctly over long links. Routing fields in control packets and routing tables at mobile nodes are maintained and processed in the same way as in ODMRP algorithm. Following is the detailed description of the protocol. D. Data Structures The protocol uses the data structures defined by ODMRP, plus the following new data structures: Each JOIN QUERY contains a new field pathw eight that records the weight of the path the packet has traversed. Field pathw eight is initialized to zero. Every time the JOIN QUERY traverses a link, the weight of the link is added to variable pathw eight of the JOIN QUERY. AnewfieldSuggestedRate[s] is added to each entry s of a routing table and a JOIN REPLY packet (see Figure ). The use of this field has been described in the previous section and will be discussed in more detail in the next sections. A new field TrxRate[s] is added to each entry s of a routing table (Figure ). As mentioned above, during a JOIN REPLY consolidation interval, a node p may receive several JOIN REPLY packets from downstream with different SuggestedRate values. Node p then selects the minimum SuggestedRate value and stores it in field TrxRate[s]. Data packets from source s will be transmitted by p at the rate specified by TrxRate[s]. E. JOIN QUERY Consolidation When a node receives a non-duplicate JOIN QUERY (i.e., the first JOIN QUERY of a route refresh broadcast), it delays for a certain period of time before forwarding the packet to the next nodes in order to consolidate JOIN QUERY packets that take different paths from the source to this node. The goal is to look for a path with a pathw eight as small as possible. Therefore the node stores the JOIN QUERY packet and waits for some amount of time, termed as ConsolidationInterval, to collect a sufficient number of JOIN QUERY packets from different paths, and then selects the JOIN QUERY with the smallest pathw eight. When the timer of the ConsolidationInterval expires, the selected JOIN QUERY is broadcast, and the routing table at the node is updated as specified by the ODMRP algorithm. In addition, also records the SuggestedRate[s] value for each sender s from the selected JOIN QUERY into the routing table. If the node is a receiver, it generates a JOIN REPLY with field JOIN REPLY.SuggestedRate[s] set to the SuggestedRate[s] value stored its routing table, and sends the JOIN REPLY upstream. After the timer expires, all duplicate JOIN QUERY packets received from the same source are discarded, just as in the ODMRP algorithm. The ConsolidationInterval timer is set to 0 msec in our experiments. This value was chosen heuristically and should not be long in order to speed up the route refresh process

5 and to eliminate paths with too many hops. After a node receives the first JOIN QUERY of a route refresh broadcast from a source s, it sets the timer to 0 msec during which it consolidates JOIN QUERY packets sent by s that take different paths. If a JOIN QUERY follows a long path with too many hops, it is unlikely that it will reach the node within this 0 msec due to long contention time resulting from having to traverse a large number of hops (JOIN QUERY packets are transmitted at the base rate). F. JOIN REPLY Consolidation To minimize feedback implosion, every intermediate node p in ODMRP collects JOIN REPLY packets from downstream nodes during a ReplyConsolidationInterval. The node combines routing information for several sources from the collected JOIN REPLY packets, records all the information into a single JOIN REPLY, and then broadcasts the aggregate JOIN REPLY. Our protocol makes use of the ReplyConsolidationInterval in ODMRP not only to minimize JOIN REPLY implosion but also to consolidate SelectedRate values from different downstream nodes in order to compute the transmission rate TrxRate[s] node p will use to transmit data packets from source s. Specifically, node p selects the minimum value among all SuggestedRate values (with respect to source s) it receives during the ReplyConsolidationInterval, and stored the selected rate as TrxRate[s] into its routing tables. Selecting the minimum SuggestedRate ensures that data packets from s will be received correctly on the link with the lowest quality. Node p will transmit data packets from source s at the rate indicated by TrxRate[s], until the next ReplyConsolidationInterval, at which time p s new transmission rate will be computed. An example of JOIN REPLY consolidation is given in Figure. Node I 2 combines the information from the JOIN REPLY packets received from R, R 2 and R 3 into a single routing table. Note that for data sent by source S 2,the receivers R and R 3 suggest two different rates: Mbps and 5.5 Mbps, respectively. Node I 2 selects the minimum value among those rates, Mbps, and records this value in its routing table as TrxRate[S 2 ]. Similarly, a source s also consolidates SuggestedRate values from its downstream neighboring nodes to select the lowest transmission rate, termed as SourceTrxRate. Note that this is the rate to be used for data transmission at the physical layer. The rate at which the application layer delivers data to the lower layers is much lower than SourceTrxRate. For example, in our experiments, applications produce data at a constant bit rate and the maximum rate is 0 packets/sec per sender 3, or approximately 4 Kbps, given a packet size of 52 bytes. The gap between any two data packets is thus 0. sec or 00 msec. This 00 msec interval is more than sufficient for a sender to consolidate JOIN REPLY packets from its downstream neighbors. In the ODMRP algorithm and 3 For a multicast group with five senders, a higher rate will result in very low packet delivery ratios. Fig.. Routing tables at multicast nodes. Routing tables in JOIN REPLY packets are the same but without column TrxRate. In the routing mesh, the arrows indicate the JOIN REPLY flows; the number associated with each arrow denotes the transmission rate of the link in the opposite direction of the arrow. In the routing tables of nodes R, R 2 and R 3,fieldsT rxrate are unused since these nodes receive and do not transmit data packets. in our experiments, the ReplyConsolidationInterval value issetto20msec. IV. EXPERIMENTAL RESULTS We present a comprehensive set of experiments that show that the protocol outperforms single-rate multicast in terms of packet delivery ratio, average packet end-to-end delay, and throughput. A. Simulation Environment Our experiments are carried out using QualNet [7], a software that provides scalable simulations of wireless networks and a commercial version of GloMoSim [8]. We compare the performance of the protocol with ODMRP in which data is transmitted at a single rate of Mbps (ODMRP-Mbps) and 2Mbps (ODMRP-2Mbps) respectively. We use the following metrics in the comparison: Packet delivery ratio (PDR): 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 multicast protocol.

6 Average end-to-end delay (EED): The end-to-end delay of every packet received at every receiver is recorded; the average over all the packets received is then computed. Average throughput :The receiver throughput is defined as the total amount of data a receiver R actually receives from all the senders of the multicast group divided by the time it takes for R to get the last packet. The average taken over all the receivers is the average receiver throughput of the multicast group. The average throughput is the average receiver throughput divided by the number of senders. Our simulations model networks of sizes ranging from 25 to 200 nodes that are placed randomly within a,000m x,000m area. A two-ray propagation model is used in our experiments, with free space path loss (2.0, 0.0) for near sight and plane earth path loss (4.0, 0.0) for far sight. The transmission power is set constant at 5dBm. We implemented PHY802.b at the physical layer, which uses a preconfigured BER-based packet reception model. The MAC802. with Distributed Coordination Function (DCF) was chosen as the medium access control protocol. Multicast and broadcast transmissions used CSMA/CA. Unicast transmissions also used RTS/CTS in addition to CSMA/CA. We model node movements using the random waypoint mobility model [9] with mobility speed ranging from 0 m/sec to 20 m/sec (0 km/hr to 72 km/hr). A node randomly selects a destination and moves towards that destination at a predefined speed. Once the node arrives at the destination, it stays in its current position for a pause time between 0 and 30 seconds. After that it selects another destination and repeats the same process. One multicast group is simulated in all the experiments. Senders and receivers of a multicast group were selected with uniform probability among the mobile hosts. The members joined the multicast group at the beginning of the simulation and stayed until the whole group was terminated. The senders of a multicast group transmitted at a constant bit rate specified for each experiment. The packet size excluding the header size was 52 bytes. The size of the queue at every mobile node is 50 Kbytes. The refresh interval in ODMRP is 20 seconds, the default value set in QualNet. In each experiment, every source sent data for 600 seconds of simulated time. The simulation then continued for another 300 seconds to allow all packets to be processed and routed. Each experiment was run several times using different random seed numbers, and collected statistics were averaged over those runs. We measure the above metrics as functions of node density, node mobility, the number of multicast senders, the number of multicast receivers, and network traffic load. Additional parameters used in each of the experiments described below are listed in Table II. Note that ND, the node density, is indicated by the number of nodes placed randomly within a,000m x,000m area; TL, the network traffic load, is the sum of all the senders rates. Function of NS NR SR MS ND ND, Fig.2(a) NS, Fig. 2(b,c) (*) 50, 00 NR,Fig.3(a) MS, Fig. 3(b) TL, Fig. 3(c) ND: node density (nodes); NS: number of senders; NR: number of receivers; SR: each sender s rate (packets/sec); MS: node mobility speed (m/sec); TL: network traffic load; TL = NS SR; (*) SR = 0 packets/sec NS TABLE II PAETERS USED IN THE EXPERIMENTS B. Simulation Results Figure 2(a) shows the graphs of PDRs, average throughputs and average EEDs of the three protocols under different node densities (25, 50, 75, 00, 50 and 200 nodes in a,000m x,000m area). The PDRs and average throughputs of are higher than those of ODMRP-Mbps and ODMRP-2Mbps, and remain almost constant, independent of node density. The average EEDs of are significantly lower, especially when compared with those of ODMRP-Mbps. When the node density is low, ODMRP-Mbps gives higher PDRs than ODMRP-2Mbps. When the network is sparse, transmission ranges are longer. When a high transmission rate, 2Mbps in this case, is used over long ranges, the bit error rates will be high. Therefore ODMRP-2Mbps gives lower PDRs than ODMRP-Mbps. As the node density increases, distances between nodes are shortened, and the error rates of ODMRP- 2Mbps transmission are improved. When the network becomes dense, the PDRs of ODMRP-2Mbps increases, and even surpass the PDRs of ODMRP-Mbps. In ODMRP-Mbps, the low transmission rate means longer transmission time; thus more packets are waiting for accessing the channels. The more contentions, the more chances of collisions and the lower the PDRs. The PDRs of are always the highest, above 97%, because can always choose optimal transmission rates. When the node density is sparse, it uses low transmission rates for long distances to ensure low error rates. When the node density is dense, it chooses high rates so that wireless channels are optimally utilized, resulting in less contentions and collisions and higher throughputs. The end-to-end delay of a packet is determined by three factors: transmission time, propagation time, and processing time at mobile nodes which includes delay due to channel contention. Given the same network configuration, propagation time can be considered the same in all the experiments. The deciding factors are thus transmission time and channel contention delay. The higher the transmission rate, the shorter the transmission time. Also, the shorter the transmission time, the less contentions and hence the lower the contention delay at each hop. On the other hand, in our experiments, the average path lengths from the three protocols do not differ much. As a result, ODMRP-2Mbps offers lower average EEDs than

7 ODMRP-Mbps. performs better than both of them for the same reasons: can transmit at a higher rate (e.g., 5.5Mbps or Mbps) whenever possible. Since the PDRs of are higher and the EEDs are lower, the throughputs given by are higher than those from ODMRP-Mbps and ODMRP-2Mbps. Note that the average throughput graph is consistent with the PDR graph. We will see in the following experiments that outperforms ODMRP-Mbps and ODMRP-2Mbps for the same reasons as explained above. Figures 2(b) and (c) provides PDRs, average throughputs and average EEDs as functions of the number of multicast senders. shows good scalability in terms of PDRs and average EEDs as the number of senders increases. When the node density is high, the PDRs of ODMRP-Mbps and ODMRP-2Mbps decline noticeably as the number of senders grows. More senders imply more JOIN QUERY packets to be flooded, which creates more traffic and therefore more collisions. The problem is more serious when nodes are close to each other, i.e., when the network is dense. is able to mitigate the increased traffic due to the use of high transmission rates whenever possible, resulting in excellent scalability. also performs better than both singrate protocols in terms of average receiver throughput. The performance difference is bigger when the network is dense (Figure 2(c)). Figures 3(a), (b) and (c) show PDRs, average throughputs and average EEDs as functions of the number of receivers, node mobility speed, andnetwork traffic load, respectively. The graphs indicate that outperforms the single-rate protocols in all cases. We arrived at the same conclusion from experiments using other node densities (25 and 00 nodes in a,000m x,000m area). Moreover, as the node density increases, the performance improvement of over single-rate multicast is magnified, similarly to the cases illustrated by the graphs in Figures 2(b) and (c). We do not show those results here due to space limitation. REFERENCES [] A. Kamerman and L. Monteban, WaveLAN-II: A high-performance wireless LAN for the unlicensed band, Bell Labs Technical Journal, vol. 2, 997. [2] G. Holland, N. Vaidya, and P. Bahl, A rate-adaptive MAC protocol for multi-hop wireless networks, Technical Report TR00-09, Dept. of Computer Science, Texas A & M University, August [3] G. Holland and N. H. Vaidya and Paramvir Bahl, A rate-adaptive MAC protocol for multi-hop wireless networks, Proc. of ACM MOBICOM, 200. [4] J. del Prado Pavon, and S. Choi, Link adaptation strategy for IEEE 802. WLAN via received signal strength measurement, Proc. of IEEE ICC, [5] D. Qiao, S. Choi, and K. G. Shin, Goodput analysis and link adaptation for IEEE 802.a wireless LANs, IEEE Transaction on Mobile Computing, [6] B. Sadeghi, V. Kanodia, A. Sabharwal, E. Knightly, Opportunistic media access for multirate ad hoc networks, Proc. of ACM MOBICOM, [7] B. Awerbuch, D. Holmer, and H. RubensHigh, Throughput route selection in multi-rate ad hoc wireless networks, Technical Report, Johns Hopkins University, March [8] Y. Seok J. Park, and Y. Choi, Multi-rate aware routing protocol for mobile ad hoc networks, Proc. of IEEE Vehicular Technology Conference, Spring [9] C. de Morais Cordeiro, H. Gossain and D. P. Agrawal, Multicast over wireless mobile ad hoc networks: Present and future directions, IEEE Network, Jan [0] C. Wu and Y. Tay, AMRIS: A multicast protocol for ad hoc wireless networks, Proc. of IEEE MILCOM, 999. [] E. Royer and C. Perkins, Multicast Ad hoc On- Demand Distance Vector (MAODV) routing, IETF, Internet Draft: draft-ietf-manet-maodv- 00.txt, [2] S. J. Lee, W. Su, and M. Gerla, On-Demand Multicast Routing Protocol (ODMRP) for ad hoc networks, Internet Draft, draft-ietf-manet-odmrp- 02.txt, January [3] J.J. Garcia-Luna-Aceves, E. L. Madruga, The Core-Assisted Mesh protocol, IEEE JSAC, August 999. [4] U. T. Nguyen, X. Xiong, and L. Nguyen, Preemptive multicast routing in mobile ad-hoc networks, Technical Report, Department of Computer Science and Engineering, York University, [5] K. Balachandran, S. R. Kadaba, and S. Nanda, Channel quality estimation and rate adaption for cellular mobile radio, IEEE JSAC, July 999. [6] T. Ue, S. Sampei, N. Morinaga, and K. Hamaguchi Symbol rate and modulation level-controlled adaptive modulation/tdma/tdd system for high-bit-rate wireless data transmission, IEEE Trans. on Vehicular Technology, 998. [7] QualNet Network Simulator, [8] GloMoSim Simulator, pcl.cs.ucla.edu/projects/glomosim/ [9] J. Yoon, M. Liu, and B. Noble, Random waypoint considered harmful, Proceedings of IEEE INFOCOM, V. CONCLUSION We propose a multirate-aware routing protocol for multicast in MANETs. Among several paths between a sender and a receiver, the routing protocol selects the path with the lowest total transmission rate. This simple route selection criterion results in better throughputs, higher packet delivery ratios, and lower end-to-end delays compared with single-rate multicast. Our simulation results show that the proposed protocol outperforms single-rate ODMRP in terms of packet delivery ratio, end-to-end delay and throughput. is the first multicast routing protocol that exploits the multirate capability of mobile devices. It works with any multirate standards and does not require any modifications to the standards.

8 Number of Nodes Average Throughput (Kbps) Average Receiver Throughput (Kbps) Average Receiver Throughput (Kbps) Number of Nodes Number of Nodes (a) F (node density) (b) F (number of senders), density = 50 nodes (c) F (number of senders), density = 00 nodes Fig. 2. Functions of node density and number of senders

9 Number of Receivers Mobility (m/s) Traffic (packets/s) Average Throughput (Kbps) Average Throughput (Kbps) Average Throughput (Kbps) Number of Receivers Mobility (m/s) Traffic(packets/s) Number of Receivers Mobility (m/s) Traffic(packets/s) (a) F (number of receivers) (b) F (node mobility) (c) F (traffic load) Fig. 3. Functions of number of receivers, node mobility, and network traffic load (network density = 50 nodes)