RMAC: A Reliable Multicast MAC Protocol for Wireless Ad Hoc Networks

Transcription

1 RMAC: A Reliable Multicast MAC Protocol Wireless Ad Hoc Networks Weisheng Si and Chengzhi Li Department of Computer Science, University of Virginia {ws4u, cl4v}@cs.virginia.edu Abstract This paper presents a new MAC protocol called RMAC that supports reliable multicast wireless ad hoc networks. By utilizing the busy tone mechanism to realize multicast reliability, RMAC has the following three novelties: (1) it uses a variable-length control frame to stipulate an order the receivers to respond, such that the problem of feedback collision is solved; (2) it extends the traditional usage of busy tone preventing data frame collisions into the multicast scenario; and (3) it introduces a new usage of busy tone acknowledging data frames. In addition, we also generalize RMAC into a comprehensive MAC protocol that provides both reliable and unreliable services all the three modes of communications: unicast, multicast, and broadcast. Our evaluation shows that RMAC achieves high reliability with very limited overhead. We also compare RMAC with other reliable multicast MAC protocols, showing that RMAC not only provides higher reliability but also involves lower cost. 1. Introduction To date, most MAC protocols wireless networks do not provide a reliable multicast service. For example, IEEE [9], the widely-used wireless MAC protocol today, only supports reliability unicast with the RTS/CTS/DATA/ACK scheme; and multicast or broadcast, it simply transmits the data frames once without any recovery mechanism. In recent years, however, the provision of multicast reliability at the MAC layer has received increasing attention due to the following two observations. First, mechanisms solely at the network layer cannot provide highly reliable multicast wireless ad hoc networks in an efficient way. So far, many network layer multicast protocols have been proposed, such as [6], [15], [21], [3], [12], and [5]. They can be classified into tree-based protocols ([6], [15], [21], [3]) and mesh-based protocols ([12], [5]). Untunately, both types of protocols encounter problems in achieving multicast reliability. In tree-based protocols, where a tree is used to do multicast, severe packet loss occurs due to the scarce connectivity of the tree. As manifested by [5] and [13], if one node in the tree does not receive a multicast packet, then all its downstream children cannot receive the packet. On the other hand, mesh-based protocols overcome the problem of the tree by warding multicast packets with a mesh, such that a node can receive the packets from several upstream nodes. However, mesh-based protocols are inefficient in that they introduce redundant packet transmissions and nodes need to be able to distinguish previously-received packets in some way. Second, in the perspective of functionality provisioning in the protocol stack, the MAC layer is a proper place to provide the reliability wireless ad hoc networks. Unlike the wired networks where, with almost error-free links, reliability can only be implemented at the end-to-end level (e.g., TCP), wireless networks are characterized by error-prone links, so it is worthwhile to perm local recovery at each hop. As shown in [4], adding local recovery at the MAC layer can greatly improve the end-to-end permance unicast in wireless networks. For multicast, we believe that the same effect will be produced if MAC layer reliability is provided. For the implementation of multicast reliability, two basic technologies exist: Forward Error Correction (FEC) and Automatic Repeat request (ARQ). In FEC, redundant data are transmitted error recovery and no feedback is needed from the receivers. The advantage of FEC is that it scales to a large number of receivers and its disadvantages are that it involves encoding/decoding overhead and the sender cannot know whether full reliability has been achieved. In ARQ, retransmission is used error recovery and feedback is needed from the receivers. The advantage of ARQ is that it can achieve full reliability and its disadvantage is that it cannot scale to a large number of receivers due to the feedback implosion problem [19]. In this paper, we focus on using ARQ to imple-

2 ment the MAC layer reliable multicast wireless ad hoc networks where the number of one-hop multicast receivers is not large. In applying ARQ to multicast wireless ad hoc networks, two problems have to be solved: (1) how to reserve the wireless channel multiple receivers so as to increase the successful transmissions and (2) how to collect the feedback from multiple receivers. Several existing ARQ-based multicast MAC protocols (to be described in Section 2) try to solve these two problems by extending the IEEE RTS/CTS/DATA/ACK scheme to the multicast scenario. Observing that these IEEE based protocols are not efficient, in this paper we present the RMAC protocol which solves these two problems by the introduction of the busy tone mechanism. Besides supporting multicast reliability, RMAC is also generalized into a comprehensive MAC protocol that provides both reliable and unreliable services to the upper layer, with each service covering three modes of communications: unicast, multicast, and broadcast. Our evaluation shows that RMAC can achieve high reliability with very limited overhead. 2. Related work The current ARQ-based reliable multicast MAC protocols, including [11], [17], and [16], all extend the RTS/CTS/DATA/ACK scheme in IEEE Distributed Coordination Function (the ad hoc mode) to provide the reliable multicast service. Generally, while maintaining the use of RTS and CTS to reserve the wireless channel and the use of ACK to acknowledge the DATA frames, they augment the use of these frames into the multicast scenario. Also, some new control frames are introduced in [11] and [16]. In the Leader Based Protocol (LBP) proposed by Kuri and Kasera [11], a leader selected by the multicast receivers takes the responsibility to reply CTS and ACK to the sender, such that no multiple CTSs or ACKs are generated by the receivers. Although LBP avoids the multiple acknowledgments, selecting and maintaining a leader by multicast receivers are not easy tasks. In [17], Tang and Gerla proposed the Broadcast Medium Window (BMW) protocol that only adds the reliable broadcast service to the IEEE Basically, BMW (Figure. 1 (a)) realizes the reliable broadcast by using a unicast to each of the one-hop neighbors with the RTS/CTS/DATA/ACK scheme. The gain of BMW lies in that during each unicast to a neighbor, other neighbors try to overhear the DATA frame. When a unicast is successful, the sender increases the sequence number of the DATA frame and switches to the next neighbor. If a neighbor does not receive a DATA frame, it replies to the sender a CTS with the sequence number being expected when the sender sends it an RTS, then the sender will retransmit the DATA frame with that sequence number. BMW is advantageous in its simplicity; however, it can introduce arbitrary long delays DATA frame receptions. For example, in Figure. 1 (a), when the sender transmits DATA frame 1 to receiver 1 and all receivers except receiver n obtain the DATA frame, receiver n needs to wait each receiver i (i = 1, 2,, n 1) to successfully obtain DATA frames from 1 to i bee it can have a chance to ask the retransmission of DATA frame 1. In [16], Sun et al. proposed the Batch Mode Multicast MAC (BMMM) protocol to add the reliable multicast service to the IEEE Basically, BMMM (Figure. 1 (b)) introduces n pairs of RTS/CTS frames and n pairs of RAK (Request ACK)/ACK frames the reliable transmission of a DATA frame to n receivers, with RTS and RAK being transmitted to solicit CTS and ACK respectively from each receiver. The advantages of BMMM are that (1) it does not cause arbitrary long delays and (2) as shown in [16], the number of contention phases involved to complete the reliable multicast transmissions is much less than that of BMW. Here we point out the drawback of BMMM is its high control overhead: 2n pairs of control frames are introduced a single DATA frame. According to the IEEE b [10], each frame transmission involves two types of overhead at the physical layer: physical layer preamble (having a length of 72 bits, required to transmit at 1 Mbps) and physical layer header (having a length of 48 bits, required to transmit at 2 Mbps). Thus, these two types of overhead together introduce a transmission delay of 96 µs, a delay even longer than the transmission delay of a control frame itself. For example, the transmission of an ACK frame (14 bytes) only takes 56 µs if transmitted at 2 Mbps. Considering both physical layer and MAC layer transmission delays, 2n pairs of control frames in BMMM (with RTS being 20 bytes and CTS, RAK, and ACK being 14 bytes) totally cost 632n µs, which is a very large overhead even a moderate n. Overlapping with our work, a new protocol called MX that also uses the busy tones to realize multicast reliability was recently proposed by Gupta et al. [7]. Though we propose the same idea, our employments of this idea in designing reliable MAC protocols have fundamental differences. First, MX is targeted as an extension to the current IEEE , having the advantage of being compatible with the existing standard. However, we believe the introduction of the busy tones can radically change the behavior of

3 contention phase RTS receiver 1 receiver 2 receiver n contention contention CTS DATA 1 ACK phase RTS CTS DATA 2 ACK phase RTS CTS DATA n ACK contention phase receiver 1 receiver n receiver 1 RTS CTS RTS CTS DATA 1 RAK ACK RAK ACK (a) BMW receiver n contention phase n unicasts receiver 1 receiver n receiver 1 receiver n RTS CTS RTS CTS DATA 2 RAK ACK RAK ACK n pairs n pairs (b) BMMM n pairs n pairs Figure 1: BMW and BMMM. the IEEE , so we design our protocol as an independent protocol that completely exploits the busy tones to prevent the data frame collisions, discarding the virtual carrier-sense mechanism used by IEEE As a result, RMAC can provide higher reliability and is more efficient. Second, MX is a receiver-initiated protocol (using negative feedback), while RMAC is a sender-initiated protocol (using positive feedback). Being receiver-initiated, MX is efficient in processing feedback, but its sender cannot know whether full reliability is achieved, since a receiver will not enter the state to send a negative feedback if it fails to receive the initial transmission request from the sender. On the other hand, being sender-initiated, RMAC is capable of achieving full reliability, but it has to pay the price of dealing with multiple feedback. So here we note that, happening in parallel, MX and RMAC embody different directions in applying the busy tone idea to implement a reliable multicast MAC protocol. 3. The RMAC protocol 3.1. Background on busy tone A busy tone is a signal transmitted over a narrowbandwidth channel with enough spectral separation from the data channel [1]. With a narrow bandwidth, a busy tone can only be sensed as being present or non-present. The busy tone mechanism has been used in several research efts such as [18], [20], and [8]. It is believed that the temporal overhead caused by control can be considerably saved with the separation of data channel and control channel. Basically, all the three aementioned approaches ([18], [20], and [8]) use busy tones to address the hidden-node or the exposed-node problems in the wireless environment the unicast scenario. In [18], Tobagi and Kleinrock first introduced the busy tone mechanism to eliminate the hidden-node problem in a wireless environment with a central station. Their basic idea is that during the reception of a frame, the receiver turns on the busy tone; other nodes that sense the busy tone cannot start new transmissions, thus the frame reception at the receiver will experience no collision. In [20], Wu and Li extended the same usage of busy tone into the wireless environment with time-slotted channels to address the hidden-node problem. Recently in [8], Haas and Deng proposed the Dual Busy Tone Multiple Access (DBTMA) protocol, which solves both the hidden-node and the exposed-node problems in a wireless ad hoc environment by using two busy tones: the transmit busy tone (BT t ) and the receive busy tone (BT r ). Concretely, they let the receivers set up BT r while receiving data frames, thus solving the hidden-node problem; on the other hand, they let the senders set up BT t while transmitting RTS frames, thus other nodes can sense BT t instead of the data channel to avoid sending RTSs simultaneously. By using both BT r and BT t, DBTMA completely exempts nodes from the operation of sensing the data channel, such that the exposed-node problem is also solved Basic ideas of RMAC Due to the inefficiency of reliable multicast in the IEEE based solutions described in Section 2, we propose to utilize busy tones to realize multicast reliability at the MAC layer. We altogether introduce two busy tones (each with its own narrow-bandwidth channel) in our RMAC protocol: the Receiver Busy Tone (RBT) and the Acknowledgment Busy Tone (ABT). RBT is used the same way as suggested by Tobagi and Kleinrock to eliminate the hidden-node problem, and we extend its use to multiple receivers, letting every receiver set up the RBT during the data reception. Using RBT to address the hidden-node problem is superior to the the RTS/CTS mechanism in that (1) the data reception is guaranteed to be collision-free, thus

4 the number of retransmissions is greatly reduced; recall that the RTS/CTS mechanism cannot completely avoid frame collisions; and (2) RBT exempts nodes from maintaining the Network Allocation Vector (NAV) variable needed in the RTS/CTS mechanism, thus simplifying the protocol. ABT is used to acknowledge the data frames, i.e., the receiver will reply an ABT to the sender if a data frame is correctly received. Using ABT to do acknowledgments has the following two advantages over using frames: (1) an ABT does not need the physical layer preamble and header prepended to a frame as described in Section 2, so it can be very short, only having to be long enough to be detected; (2) an ABT does not suffer from collisions or bit errors. Bytes: Frame Type Transmitter Number of Address 1 Address Address Receivers FCS Figure 2: MRTS mat. Number of Receivers contains the number of receiver MAC addresses included. FCS (Frame Check Sequence) contains a 32-bit cyclic redundancy code. To distinguish ABTs from multiple receivers, we introduce a new control frame called Multicast Request- To-Send (MRTS) to lay down an order the receivers to respond. With a variable length, the MRTS frame (Figure. 2) mainly contains a sequence of the MAC addresses of the intended receivers. The order of the receivers appearance in this sequence is used by the receivers to reply ABTs to the sender. The advantage of our condensing control inmation into a single MRTS frame, instead of using multiple control frames as BMMM does, is that the control frame overhead is greatly reduced: (1) each receiver only costs six bytes in MRTS instead of costing an entire control frame and (2) the physical layer overhead associated with the frame transmissions is also reduced accordingly. Note that in our protocol, MRTS is also used in the case of reliable unicast or broadcast by putting the unicast receiver address or all the one-hop neighbor addresses into the MRTS address sequence RMAC description The RMAC protocol is a comprehensive MAC protocol that provides both reliable and unreliable transmission services to the upper layer, with each service covering three modes of communications: unicast, multicast, and broadcast. We call the two services in RMAC Reliable Send and Unreliable Send respectively. Specifically, Reliable Send implements the reliable transmission of data frames to the receivers with the use of MRTS, RBT, and ABT; and Unreliable Send only perms one transmission of data frames without any recovery mechanism. We distinguish the data frames in Reliable Send and Unreliable Send into reliable data frames and unreliable data frames by labeling the frames with different frame types Procedure of the Reliable Send service. The Reliable Send service provides reliability to three modes of communications: unicast, multicast, and broadcast. All three modes essentially follow the same procedure. The only difference is that the MRTS frame includes the MAC address(es) of the unicast receiver, the multicast receivers, or the entire one-hop neighbors in its address sequence depending on the communication mode. The symbols and timers used in the procedure description are as follows: n: the number of intended receivers. τ: the maximum one-way propagation delay. We set τ = 1 µs, assuming that the maximum radio range is less than 300 m. λ: the duration needed to detect a busy tone. We use λ = 15 µs according to the Clear Channel Assessment time in physical layer of IEEE b [10]. T wf rbt : a timer set up by the sender right after the MRTS transmission. The RBT should be detected bee the expiration of this timer. Its period T wf rbt is set to 2τ + λ. T wf rdata : a timer set up by the receiver right after the reception of the MRTS frame. The first bit of the data frame should arrive bee its expiration. Its period T wf rdata is set to 2τ + λ. i: the location index of a receiver in the address sequence in MRTS. For example, the first receiver in the sequence has i = 0, and the second receiver has i = 1, etc. l abt : the duration of ABT. We set l abt = 2τ + λ, which guarantees the ABT detection in consideration of propagation delay. T tx abt : the timer used to trigger the response of ABT at the receiver. Its period T tx abt is set to i l abt. T wf abt : the timer used to sense an ABT at the sender. Its period T wf abt is set to 2τ + λ. The procedure of the Reliable Send service is as follows (Figure. 3): 1. The sender transmits an MRTS to the intended receivers. 2. Upon receiving the MRTS, a node checks whether its MAC address is contained in the address sequence of MRTS. If it is, it memorizes its index i in the address sequence and turns on the RBT.

5 Figure 3: Procedure of the Reliable Send service. In this figure, Node A is the sender, which has two multicast receivers, Node B and Node C. 3. After the transmission of MRTS, the sender begins to sense the RBT and sets up the timer T wf rbt. Upon the expiration of T wf rbt, if there is RBT detected during the timer period, the sender transmits the reliable data frame; otherwise, the sender enters the backoff procedure to retransmit. 4. When turning on the RBT, a receiver also sets up the timer T wf rdata. If the first bit of data frame arrives bee T wf rdata expires, it cancels the timer and the RBT continues until the end of the data frame reception; otherwise, it stops the RBT upon the expiration of T wf rdata. If the data frame is correctly received, the receiver sets up the timer T tx abt with T tx abt = i l abt. When T tx abt expires, it turns on the ABT the duration of l abt. 5. After the data frame transmission, the sender sets up the timer T wf abt, which will cycle n times. During each timer period, an ABT from one of the receivers is sensed. At the end, if all the intended receivers are found to have responded with an ABT, the transmission is successful. Otherwise, the sender constructs a new MRTS frame which contains those receivers which no ABTs are detected and enters the backoff procedure to retransmit. Note in this procedure: (1) there is a limit the number of retransmissions associated with a frame; if this limit is exceeded, the frame will be dropped; (2) the reason setting T wf rbt = 2τ + λ is because 2τ + λ is the minimum time required to guarantee the detection of all the possible arriving RBTs, since the duration detecting a busy tone is λ and the maximum round trip delay a receiver is 2τ Procedure of the Unreliable Send service. The Unreliable Send service simply perms one transmission of the unreliable data frame over the data channel. It covers the three modes of communications (unicast, multicast, and broadcast) by setting the receiver address in the unreliable data frame to the intended unicast address, multicast address, or broadcast address respectively. The procedure of the Unreliable Send service is as follows: 1. The sender senses both data channel and RBT channel. If both are idle, the sender transmits the unreliable data frame. If either channel is busy, the sender enters the backoff procedure; when the backoff procedure comes to the end, it transmits the frame. 2. During the transmission of the unreliable data frame, the sender keeps sensing the RBT channel. If RBT is sensed, it will simply abort the current transmission, which is to guarantee the collision-free data reception in the Reliable Send service. 3. Upon receiving an unreliable data frame, a node checks the receiver address in the frame. If the frame is destined the node in cases of unicast, multicast, or broadcast, the node accepts it; otherwise, the node discards it. 4. Evaluation RMAC is implemented and evaluated under Glo- MoSim [22], a widely-used simulator in wireless networking research. Our evaluation on RMAC focuses on two aspects: reliability and overhead, with each aspect evaluated under several metrics. For each metric, we also compare RMAC with BMMM [16]. The reasons choosing BMMM comparison are that (1) BMMM is the most recent reliable multicast MAC protocols (except MX) known by us and (2) Ref. [16] has shown that BMMM is better than BMW in terms of reliability and efficiency. To make comparison under the same environment, we also implemented BMMM under GloMoSim Experiment setup Experiment environment. We use multihop wireless ad hoc networks to evaluate RMAC and BMMM, since the busy tone mechanism or the RTS/CTS/DATA/ACK scheme can affect nodes that are within two hops of each other. The networks used in our experiments contain 75 nodes randomly placed on a 500 m 300 m plain. The radio propagation range each node is 75 m and the transmission bit rate at each node is 2 Mbps. To test the permance of RMAC and BMMM, we use a multicast application that wards packets along

6 Figure 4: An tree topology example Experiment method. To evaluate RMAC in both static and mobile networks, we altogether conduct experiments in the following three scenarios: (1) Stationary: no node is moving. (2) Moving at speed 1: nodes are moving under the random waypoint model [2]. In random waypoint, a node first randomly selects a destination from the physical plain, then moves toward that destination in a speed unimly distributed between MIN-SPEED and MAX-SPEED. After reaching the destination, the node stays there INTER-PAUSE time. In this scenario, we use MIN-SPEED = 0 m/s, MAX- SPEED = 4 m/s, and INTER-PAUSE = 10 s. (3) Moving at speed 2: nodes are also moving under the random waypoint model. However, the parameters are different: we use MIN-SPEED = 0 m/s, MAX-SPEED = 8 m/s, and INTER-PAUSE = 5 s. In each of the scenario above, we conduct eight kinds of experiments with the source node transmitting packets at rates of 5, 10, 20, 40, 60, 80, 100, 120 packets/second respectively. All these packets have a length of 500 bytes and in each experiment the source node transmits packets in total. To make the experimental results independent of the network topologies, in each kind of experiments, we conduct a set of ten experiments with different random node placements (i.e., different tree topologies). And in the plots to be presented, each data point except the maximum and 99 percentile values represents the average result of a set of ten experiments. To compare RMAC with BMMM, each set of ten experiments is done RMAC and BMMM respectively with identical node placements. a single source tree to all the 75 nodes in the network. At each hop, the packets are transmitted from the parent node to the child nodes using the reliable multicast services provided by RMAC or BMMM at the MAC layer. The single source tree is obtained by a simplified version of the BLESS protocol [14]. In this simple protocol, the node with ID=0 is always designated as the root node (which is to be used as the source node by the multicast application); and the tree is med by only one operation a periodical one-hop broadcast of the routing messages. This broadcast is permed by the unreliable services of RMAC or BMMM accordingly. An example of the tree topologies med in our experiments is shown in Figure. 4. Our experiments on such tree topologies show that (1) the average and 99 percentile number of hops to root in these tree topologies are 3.87 and 10 respectively and (2) the average and 99 percentile number of children a non-leaf node are 3.54 and 9 respectively Reliability In the reliability evaluation of RMAC, we measured data on the following two metrics: the packet delivery ratio and the packet drop ratio The packet delivery ratio. We define the packet delivery ratio (denoted by R delv ) in a multicast experiment as the total number of packets received by all nodes versus the total number of packets supposed to be received by all nodes. Figure. 5 plots R delv in each kind of our experiments RMAC and BMMM respectively. From this figure we see that (1) when the nodes are stationary, R delv RMAC is very close to 1, showing that RMAC can achieve very high reliability a stationary network and (2) when the nodes are moving, R delv RMAC drops to around 0.75, but it remains much higher than that of BMMM. Here we note that the apparent decrease of reliability in mobile networks is because nodes move out of range of the previous parents. Since the MAC layer is only responsible one-hop communications, the issue of out-of-range nodes should be dealt with by upper layer protocols. Packet Delivery Ratio BMMM:Stationary RMAC:Stationary BMMM:Speed 1 RMAC:Speed 1 BMMM:Speed 2 RMAC:Speed Source Packet Transmission Rate (pkts/s) Figure 5: Packet delivery ratio in RMAC and BMMM.

7 The packet drop ratio. We define the packet drop ratio (denoted by R drop ) at a node as the total number of packets dropped by that node versus the total number of packets to be transmitted by that node. Recall that in Reliable Send, the only reason a receiver to lose a packet is because its sender drops the packet after certain number of failed transmissions, so packet drop has a direct relationship with reliability. Average Retransmission Ratio BMMM:Stationary RMAC:Stationary BMMM:Speed 1 RMAC:Speed 1 BMMM:Speed 2 RMAC:Speed Average Packet Drop Ratio BMMM:Stationary RMAC:Stationary BMMM:Speed 1 RMAC:Speed 1 BMMM:Speed 2 RMAC:Speed Source Packet Transmission Rate (pkts/s) Figure 6: Average packet drop ratio in RMAC and BMMM. Figure. 6 plots the average R drop over all non-leaf nodes in the network in each kind of our experiments. Note that a leaf node, since it wards no packets, it drops no packets. From Figure. 6 we see that (1) when the nodes are stationary, RMAC has very few packet drops: e.g., under the highest source traffic rate 120 pkts/sec, the R drop a non-leaf node is only about on average; (2) when the nodes are moving, the average R drop in RMAC increases considerably, since mobility often causes that nodes cannot be reached by their previous parents until the new parents are discovered; (3) all the three scenarios, RMAC has less packet drops than BMMM Overhead In the overhead evaluation of RMAC, we measured data on the following two metrics: the packet retransmission ratio and the transmission overhead ratio The packet retransmission ratio. Retransmission is a major overhead involved in the ARQ-based reliable networking protocols. To evaluate the retransmission overhead of RMAC, we use a metric called the packet retransmission ratio (denoted by R retx ), which is defined as the total number of retransmissions conducted by a node versus the total number of packets to be transmitted by that node Source Packet Transmission Rate (pkts/s) Figure 7: Average packet retransmission ratio in RMAC and BMMM. Figure. 7 plots the average R retx over all non-leaf nodes in the network in each kind of our experiments. From this figure we see that (1) when the nodes are stationary, R retx a non-leaf node in RMAC on average is no more than 0.32, a very low retransmission ratio the multicast scenario; (2) when the nodes are moving, R retx RMAC increases to around 1; however, RMAC still has less R retx than BMMM. In general, the above results reflect that the protection of RBT really helps to reduce the number of retransmissions The transmission overhead ratio. We define the transmission overhead ratio (denoted by R txoh ) at a node as the total time spent in transmitting/receiving control frames and checking ABTs versus the total time spent in transmitting the reliable data frames. R txoh can be similarly defined BMMM, except that no time spent in checking ABTs is included. Average Transmission Overhead Ratio BMMM:Stationary RMAC:Stationary BMMM:Speed 1 RMAC:Speed 1 BMMM:Speed 2 RMAC:Speed Source Packet Transmission Rate (pkts/s) Figure 8: Average transmission overhead ratio in RMAC and BMMM. Figure. 8 plots the average R txoh over all non-leaf

8 nodes in the network in each kind of our experiments. From this figure we see that (1) when the nodes are stationary, R txoh RMAC increases slowly from 0.16 to 0.23, which is quite low compared with R txoh BMMM (ranging from 1.0 to 1.1) and (2) when the nodes are moving, the values of R txoh both RMAC and BMMM rise significantly, but RMAC can still achieve an R txoh below 1.1. It can be concluded from this figure that the use of MRTS and ABT generates very limited transmission overhead. 5. Conclusion In this paper, we presented a new MAC protocol wireless ad hoc networks called RMAC that implements the reliable multicast service at the MAC layer using the busy tone mechanism. In addition, we generalize RMAC into a comprehensive protocol that supports both reliable and unreliable services all the three modes of communications: unicast, multicast, and broadcast. Evaluation is done on RMAC and comparison is also made with BMMM, an example of other ARQ-based reliable multicast MAC protocols. The evaluation and comparison showed that RMAC achieves high reliability with very limited overhead. References [1] D. Bertsekas and R. G. Gallagher. Data Networks, Second Edtion. Prentice-Hall, [2] C. Bettstetter. Mobility modeling in wireless networks: categorization, smooth movement, and border effects. ACM SIGMOBILE Mobile Computing and Communications Review, 5(3):55 66, [3] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. AMRoute: Ad hoc multicast routing protocol. Internet Draft, IETF, Aug [4] D. Eckhardt and P. Steenkiste. Improving wireless LAN permance via adaptive local error control. In Proc. IEEE ICNP 98, [5] J. Garcia-Luna-Aceves and E. Madruga. The coreassisted mesh protocol. IEEE Journal on Selected Areas in Communications, 17: , Aug [6] M. Gerla, C.-C. Chiang, and L. Zhang. Tree multicast strategies in mobile multihop wireless networks. ACM/Balzter Mobile Network and Applications Journal, 4: , [7] S. Gupta, V. Shankar, and S. Lalwani. Reliable Multicast MAC Protocol Wireless LANs. In Proc. IEEE ICC 03, May [8] Z. Haas and J. Deng. Dual busy tone multiple access (DBTMA): A multiple access control scheme ad hoc networks. IEEE Transactions on Communications, 50: , June [9] IEEE. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. ANSI/IEEE Std , 1999 Edition, [10] IEEE. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz Band. ANSI/IEEE Std b, 1999 Edition, [11] J. Kuri and S. K. Kasera. Reliable multicast in multiaccess wireless LANs. Wireless Networks, 7(3): , [12] S. Lee, W. Su, and M. Gerla. Ad hoc wireless multicast with mobility prediction. In Proc. IEEE ICCCN 99, Boston, MA, Oct [13] S. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia. A permance comparison study of ad hoc wireless multicast protocols. In Proc. IEEE INFOCOM 00, Tel Aviv, Israel, Mar [14] P. Levis and D. Culler. Mate: A virtual machine tiny networked sensors. In Proc. ACM Conference on Architectural Support Programming Languages and Operating Systems, pages , San Jose, CA, Oct [15] E. M. Royer and C. E. Perkins. Multicast operation of the ad hoc on-demand distance vector routing protocol. In Proc. ACM MobiCom 99, pages , Seattle, WA, Aug [16] M. T. Sun, L. Huang, A. Arora, and T. H. Lai. MAC layer multicast in IEEE wireless networks. In Proc. the International Conference on Parallel Processing (ICPP) 2002, [17] K. Tang and M. Gerla. MAC reliable broadcast in ad hoc networks. In Proc. IEEE MILCOM 2001, pages , Oct [18] F. Tobagi and L. Kleinrock. Packet switching in radio channels: Part II the hidden terminal problem in carrier sense multiple-access and the busy-tone solution. IEEE Transactions on Communications, Com-23: , Dec [19] D. Towsley, J. Kurose, and S. Pingali. A comparison of sender-initiated and receiver-initiated reliable multicast protocols. IEEE Journal on Selected Areas in Communications, 15: , Apr [20] C. Wu and V. Li. Receiver-initiated busy-tone multiple access in packet radio networks. In Proc. ACM SIG- COMM 87, pages , [21] C. Wu and Y. Tay. AMRIS: A multicast protocol ad hoc wireless networks. In Proc. IEEE MILCOM 99, Atlantic City, NJ, Nov [22] X. Zeng, R. Bagrodia, and M. Gerla. GloMoSim: a library parallel simulation of large-scale wireless networks. In Proc. The 12th Workshop on Parallel and Distributed Simulations, Alberta, Canada, May 1998.