A Reliable Multicast MAC Protocol for Wireless Ad ... - Semantic Scholar

6 downloads 112203 Views 162KB Size Report
Email: {ws4u, cl4v}@cs.virginia.edu .... The first protocol, called “Batch Mode Multicast MAC (BMMM)”, is also an extension to the IEEE ... sender. On the other hand, being sender-initiated, RMAC is capable of achieving full reliability, but it has ...
RMAC: A Reliable Multicast MAC Protocol for Wireless Ad Hoc Networks Weisheng Si and Chengzhi Li Department of Computer Science, University of Virginia Email: {ws4u, cl4v}@cs.virginia.edu

Abstract This paper presents a new MAC protocol called RMAC that supports reliable multicast for 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 for the receivers to respond, such that the problem of feedback collision is solved; (2) it extends the traditional usage of busy tone for preventing data frame collisions into the multicast scenario; and (3) it introduces a new usage of busy tone for acknowledging data frames. In addition, we also generalize RMAC into a comprehensive MAC protocol that provides both reliable and unreliable services for all the three modes of communications: unicast, multicast, and broadcast. Our evaluation shows that RMAC achieves a high degree of 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. Key Words: wireless ad hoc networks, MAC protocol, reliable multicast, busy tone

1 Introduction To date, most MAC protocols for wireless networks do not provide a reliable multicast service. For example, IEEE 802.11 [9], the widely-used wireless MAC protocol today, only supports reliability for unicast with the RTS/CTS/DATA/ACK scheme; and for multicast or broadcast, it simply transmits the data frames 1 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 for 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]). Unfortunately, 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 forwarding 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. Therefore, reliable multicast support is needed from the MAC layer to improve the upper layer performance. 1

In this paper, we call the protocol data units in the network layer and above “packets” and those in the MAC layer “frames”.

1

Second, in the perspective of functionality provisioning in the protocol stack, the MAC layer is a proper place to provide the reliability for 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 perform local recovery at each hop. As shown in [4], adding local recovery at the MAC layer can greatly improve the end-to-end performance for 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 for 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. On the other hand, in ARQ, retransmission is used for 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 implement the MAC layer reliable multicast for wireless ad hoc networks where the number of one-hop multicast receivers is not very large. Examples of such ad hoc networks include battlefield ad hoc networks, emergency rescue networks, sparse sensor networks, etc. In applying ARQ to multicast for wireless ad hoc networks, two problems have to be solved: (1) how to reserve the wireless channel for 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 802.11 RTS/CTS/DATA/ACK scheme to the multicast scenario. Observing that these IEEE 802.11 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 achieves a high degree of reliability with very limited overhead. The rest of the paper is organized as follows. Section 2 briefly reviews other ARQ-based reliable multicast MAC protocols. Section 3 describes RMAC in detail. Section 4 presents our simulation results on RMAC. Section 5 concludes this paper.

2 Related Work for receiver 1 contention phase

RTS

CTS

DATA 1

ACK

for receiver 2 contention phase

RTS

CTS

DATA 2

for receiver n contention phase

ACK

RTS

CTS

DATA n

n unicasts

(a) BMW for receiver 1 contention phase

RTS

for receiver n

CTS

n pairs

RTS

CTS

for receiver 1 DATA 1

RAK

ACK

for receiver n RAK

ACK

for receiver 1 contention phase

n pairs

RTS

for receiver n

CTS

RTS

n pairs

(b) BMMM

Figure 1: BMW and BMMM. 2

CTS

for receiver 1 DATA 2

RAK

ACK

for receiver n RAK

n pairs

ACK

ACK

The current ARQ-based reliable multicast MAC protocols, including [11], [17], and [16], all extend the RTS/CTS/DATA/ACK scheme in IEEE 802.11 Distributed Coordination Function (i.e., 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. In addition, LBP introduces two new control frames, NCTS (Not Clear to Send) and NAK (Negative Acknowledgment), as the negative acknowledgments for channel reservation and DATA frame transmission respectively. 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 which only adds the reliable broadcast service to the IEEE 802.11. Basically, BMW (illustrated in Fig. 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 for DATA frame receptions. For example, in Fig. 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 for each receiver i (i = 1, 2, · · · , n − 1) to successfully obtain DATA frames from 1 to i before it can have a chance to ask for the retransmission of DATA frame 1. In [16], Sun et al. proposed two protocols to add the reliable multicast service to the IEEE 802.11 networks. The first protocol, called “Batch Mode Multicast MAC (BMMM)”, is also an extension to the IEEE 802.11. The second protocol, called “Location Aware Multicast MAC (LAMM)”, utilizes location information by GPS to further improve BMMM. Here we only discuss BMMM. Basically, BMMM (illustrated in Fig. 1 (b)) introduces n pairs of RTS/CTS frames and n pairs of RAK (Request for ACK)/ACK frames for 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 for a single DATA frame. According to the IEEE 802.11b [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 M bps. • physical layer header: having a length of 48 bits, required to transmit at 2 M bps. 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 M bps. 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 for a moderate n. Overlapping with our work, a new protocol called “802.11MX” 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, 802.11MX 3

is targeted as an extension to the current IEEE 802.11. Maintaining all the behavior of IEEE 802.11, it has the advantage of being compatible with the existing standard. However, we believe the introduction of the busy tones can radically change the behavior of IEEE 802.11, 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 802.11. Consequently, RMAC can provide higher reliability and is more efficient. Second, 802.11MX is a receiver-initiated protocol (using negative feedback), while RMAC is a sender-initiated protocol (using positive feedback). Being receiver-initiated, 802.11MX 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, 802.11MX 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 narrow-bandwidth 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 nonpresent. The busy tone mechanism has been used in several research efforts such as [18], [20], and [8]. It is believed that the hardware with busy tone support is certain to be cheap with the development of wireless technologies and the temporal overhead involved in control can be considerably saved with the separation of data channel and control channel. Generally, all the three aforementioned approaches ([18], [20], and [8]) use busy tones to address the hidden-node or the exposed-node problems in the wireless environment for the unicast scenario, such that the efficiency of channel access and the reliability of frame transmission are improved. 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 (see Fig. 2) 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 dual busy tones: the transmit busy tone (BT t ) and the receive busy tone (BTr ). Concretely, they let the receivers set up BTr while receiving data frames, thus solving the hidden-node problem; on the other hand, they let the senders set up BTt 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 BTt , DBTMA completely exempts nodes from the operation of sensing the data channel, such that the exposed-node problem is also solved.

3.2 Basic Ideas of RMAC Due to the inefficiency of reliable multicast in the IEEE 802.11 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). 4

S

R can not transmit A

Figure 2: Basic idea of busy tone by Tobagi and Kleinrock. Dotted circle depicts the busy tone range at receiver R. 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 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. With the introduction of RBT and ABT, the basic steps of our reliable multicast service are as follows: 1. The sender first transmits a control frame called Multicast Request-To-Send (MRTS) to the intended receivers. With a variable length, the MRTS frame (shown in Fig. 3) 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. 2. Upon receiving an MRTS, a receiver turns on the RBT if its MAC address is contained in the MRTS. The RBT has two usages here: one is to tell the sender that certain node has received the MRTS and the other is to protect the data reception at the receiver. 3. If the sender detects RBT after the transmission of MRTS, the sender transmits the data frame. Note that the sender does not need to distinguish how many RBTs are present. 4. Upon correctly receiving the data frame, a receiver replies to the sender an ABT according to the order specified in the MRTS. The ABT from each receiver lasts an equal length of time and is checked by the sender in its expected arriving duration. 5. The sender waits for the ordered ABT arrivals after the data frame transmission. If an ABT is missing, the sender knows which receiver it belongs to according to the order specified in the MRTS frame. If not all ABTs arrive, the sender reconstructs an MRTS frame that contains the MAC addresses of those receivers for which no ABTs are detected and repeats from step 1. 5

Bytes:

1 Frame Type

6

1

6

Transmitter Number of Address 1 Address Receivers

6 Address 2

4

... ...

FCS

Figure 3: The MRTS Frame Format. Number of Receivers contains the number of receiver MAC addresses included and FCS (Frame Check Sequence) contains a 32-bit cyclic redundancy code. We have three notes on the above basic steps. First, these steps can be easily adapted to the scenario of unicast or broadcast by putting the unicast receiver address or all the one-hop neighbor addresses into the MRTS address sequence. Second, since a long frame is easy to be corrupted in a wireless environment, a control frame should not have a long length. Here we point out that with each receiver MAC address costing 6 bytes, the length of MRTS is acceptable in most cases, which is verified by the evaluation results presented in Subsection 4.3.3. Moreover, the protocol refinement described in Subsection 3.4 will split the receivers into several executions of the multicast service in case of a large number of receivers. Third, the advantage of our condensing information into a single MRTS frame, instead of using a sequence of 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.

3.3 RMAC Description The RMAC protocol is a comprehensive MAC protocol that provides both reliable and unreliable transmission services to the upper layer. Both of them cover three modes of communications: unicast, multicast, and broadcast. Hereafter, the two services are called Reliable Send and Unreliable Send services respectively. The provision of both services is due to the consideration that a MAC layer protocol should be able to support various upper layer requirements that in most cases demand both services. For example, while many data applications need the reliability of transmission, many routing protocols use periodical one-hop broadcast, where reliability is not a concern. Specifically, the Reliable Send service implements the reliable transmission of data frames to multiple receivers with the use of MRTS, RBT, and ABT; and the Unreliable Send service only performs one transmission of data frames without any recovery mechanism. In RMAC, the data frames in Reliable Send and Unreliable Send are distinguished into “reliable data frames” and “unreliable data frames” by labeling the data frames with different frame types. In the design of RMAC, we determine its physical parameters (e.g., Clear Channel Assessment time, slot time, etc.) according to the IEEE 802.11b [10], so as to conform to practice. We note that these parameters could change with the evolution of wireless technologies. In the following subsections, we in turn describe the backoff procedure, the procedures of the two services, and the protocol refinement for RMAC. To help understanding the protocol implementation, the state transition diagram and conditions for RMAC is attached as an appendix. 3.3.1

The Backoff Procedure

In RMAC, the backoff procedure is used by both Reliable Send and Unreliable Send services. It is invoked under any of the following three conditions: (1) a node has a packet to transmit, but either data or RBT channel is busy; (2) a node tries to retransmit upon a failed transmission; (3) a node completes a successful transmission or drops a frame. Note the backoff under condition (3) is to ensure that any two successive

6

frame transmissions are separated by a backoff procedure, giving chances for other nodes to transmit. Each node in RMAC maintains two variables for the backoff procedure: Backoff Interval (BI), which records the remaining period to be deferred, and Contention Window (CW), which increases exponentially upon failed transmissions and is used to initialize BI. Both variables are in the unit of slot times. According to IEEE 802.11b [10], we set a slot time in RMAC to 20 µs, which includes the Clear Channel Assessment time and other time needed by physical layer operations in a backoff slot. When a node enters the backoff procedure, it sets its BI to a random number between 0 and the current CW. In each backoff slot, the node senses both data channel and RBT channel. If both channels are idle, the node decreases BI by 1. If either channel is busy, the backoff procedure is suspended with BI not decreased. The node resumes the backoff procedure when both data channel and RBT channel are determined to be idle again. When BI counts down to 0, the sender begins frame transmission immediately. In essence, the effect of this procedure is that when several nodes are deferring in backoff, the node selecting the smallest BI will win the contention. 3.3.2

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 the physical layer of IEEE 802.11b [10]. • Twf rbt : a timer set up by the sender right after the MRTS transmission. The RBT should be detected before the expiration of this timer. Its period |T wf rbt | is set to 2τ + λ. • Twf 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 before 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. • labt : the duration of ABT. We set labt = 2τ + λ, which guarantees the ABT detection in consideration of propagation delay. • Ttx abt : the timer used to trigger the response of ABT at the receiver. Its period |T tx abt | is set to i × labt . • Twf

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 (for illustration, see Fig. 4): 1. The sender transmits an MRTS to the intended receivers.

7

Figure 4: Procedure of The Reliable Send Service. In this figure, Node A is the sender, which has two multicast receivers, Node B and Node C. 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. 3. If a node in transmission of an MRTS frame senses an RBT, it has to abort its current transmission, which is to guarantee that no collisions will occur at the node setting up the RBT. 4. After the transmission of MRTS, the sender begins to sense the RBT and sets up the timer T wf rbt . Upon the expiration of Twf 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. 5. When turning on the RBT, a receiver also sets up the timer T wf rdata . If the first bit of data frame arrives before Twf 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 |Ttx abt | = i × labt . When Ttx abt expires, it turns on the ABT for the duration of l abt . 6. 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 for which no ABTs are detected and enters the backoff procedure to retransmit. Note in this procedure: (1) there is a limit for the number of retransmissions associated with a frame; if this limit is exceeded, the frame will be dropped; (2) the reason for 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 for detecting a busy tone is λ and the maximum round trip delay for a receiver is 2τ ; and (3) the transmission abortion of MRTS described in step 3 rarely occurs, since it can only happen when the aborting 8

node starts its transmission in the tiny interval between the time when another node sets up an RBT and the time when the aborting node detects this RBT. This rareness is also verified by our evaluation presented in Subsection 4.3.4. 3.3.3

Procedure of The Unreliable Send Service

The Unreliable Send service simply performs 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 BI counts down to 0, 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 for the node in cases of unicast, multicast, or broadcast, the node accepts it; otherwise, the node discards it.

3.4 Protocol Refinement The protocol can be refined by setting a limit to the maximum number of receivers the Reliable Send service can accept. If a transmission request has a larger number of receivers than this limit, RMAC will simply divide these receivers into multiple Reliable Send invocations, with any two consecutive invocations separated by a backoff procedure. The reasons for this protocol refinement are twofold. First, by limiting the maximum number of receivers, MRTS will not be long, thus increasing its possibility of successful reception. Second, if a sender has too many receivers, it may receive ABTs from nodes other than its intended receivers. Using Fig. 5 as an example, where node S is a multicast sender with a large number of receivers A, B, C, D, E, etc. and node U is another sender with a single receiver V , the scenario for the mixed-up ABTs to happen is as follows: node S executes a Reliable Send to its receivers A, B, C, D, E, etc.; and during S’s period of collecting ABTs, U executes a Reliable Send to V . If the number of S’s receivers is so large that by the time when V replies U an ABT, S is still waiting ABTs from its receivers, S will simply take V ’s ABT as coming from one of its receivers. Since this phenomenon can only happen when the period of collecting ABTs is long enough such that another nearby Reliable Send can be completed within it, setting a limit to the maximum number of receivers can solve this problem. In our implementation of RMAC, we set this limit to 20, which is in consideration of eliminating mixedup ABTs. The reasoning is as follows: the detection of an ABT takes 17 µs and the transmission of the shortest MRTS and the shortest data frame in RMAC altogether takes 352 µs, so the maximum number of receivers should be no more than 352/17 = 20. This limit can be further reduced in case of high error bit rate in the wireless channel.

9

E

D

U

V

S

A

C B

Figure 5: Mixed-up ABTs.

4 Evaluation RMAC is implemented and evaluated under GloMoSim [22], a widely-used simulator in wireless networking research. Our detailed implementation of RMAC is enabled by GloMoSim’s capability of simulating wireless channel characteristics such as signal propagation, frame collision, and various delays. Our evaluation on RMAC focuses on two aspects: effectiveness and overhead, with each aspect evaluated under several metrics. For each metric, we compare RMAC with BMMM [16] if BMMM can also be evaluated by that metric. The reasons for choosing BMMM for comparison are that (1) BMMM is the most recent reliable multicast MAC protocols (except 802.11MX) 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.

4.1 Experiment Setup 4.1.1

Experiment Environment

We use multi-hop 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 for each node is 75 m and the transmission bit rate at each node is 2 M bps. To test the performance of RMAC and BMMM, we use a multicast application that forwards packets along 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 formed by only one operation — a periodical onehop broadcast of the routing messages. This broadcast is performed by the unreliable services of RMAC or BMMM accordingly. An example of the tree topologies formed in our experiments is shown in Fig. 6. 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 for a non-leaf node are 3.54 and 9 respectively.

10

28

3

33

46

20

11

0 38

74

16

65

44

70

39

60 25

68

17

41

67

72

8

48

69 55

30 12

31

40

22

45 27

62

26

13

23

4 43

54 49

52

5

32

24

71

61 50 1

9

2

18

29

56

37 36

66

34

64 15

7

58 10

59 57

19 47

6

63

21

35

53

14

51

73 42

Figure 6: An Tree Topology Example. Node with ID=0 is the root. 4.1.2

Experiment Method

To evaluate RMAC in both static and mobile networks, we altogether conduct experiments in the following three scenarios: • Stationary: no node is moving. • 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 uniformly distributed between MIN-SPEED and MAX-SPEED. After reaching the destination, the node stays there for INTER-PAUSE time. In this scenario, we use MIN-SPEED = 0 m/s, MAX-SPEED = 4 m/s, and INTER-PAUSE = 10 s. • 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 10000 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 for RMAC and BMMM respectively with identical node placements.

4.2 Effectiveness In the effectiveness evaluation of RMAC, we put special emphasis on the reliability, for which we measured two types of data: packet delivery ratio and packet drop ratio. In addition, we measured the end-to-end 11

delays experienced by packets from the source node to each of other nodes in the network as an evaluation of speed for RMAC. Packet Delivery Ratio 1

1

0.95

0.95

0.9

0.9

0.9

0.85 0.8 0.75 0.7 0.65 BMMM RMAC

0.6

Packet Delivery Ratio

1 0.95

Packet Delivery Ratio

Packet Delivery Ratio

4.2.1

0.85 0.8 0.75 0.7 0.65 BMMM RMAC

0.6

0.55 20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

0.8 0.75 0.7 0.65

0.55

0.5 5 10

0.85

0.6

0.55

0.5

BMMM RMAC

0.5 5 10

(a) Stationary.

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

5 10

20

(b) Moving at Speed 1.

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 7: Packet Delivery Ratio in RMAC and BMMM. We define the “packet delivery ratio” (denoted by R deliv ) 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. We use Rdeliv as the major metric for multicast reliability in this paper. Fig. 7 plots Rdeliv in each kind of our experiments for RMAC and BMMM respectively. From this figure we see that (1) when the nodes are stationary, R deliv for RMAC is close to 1, showing that RMAC can achieve ideal reliability for a stationary network; (2) when the nodes are moving, R deliv for 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 for one-hop communications, the issue of out-of-range nodes should be dealt with by upper layer protocols. Packet Drop Ratio

0.2 BMMM RMAC

0.16

Average Packet Drop Ratio

Average Packet Drop Ratio

0.18

0.14 0.12 0.1 0.08 0.06

0.2

0.2

0.18

0.18

0.16

0.16

0.14 0.12 0.1 0.08 0.06

0.04

0.04

0.02

0.02

0

0 5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(a) Stationary.

120

Average Packet Drop Ratio

4.2.2

0.14 0.12 0.1 0.08 0.06 0.04

BMMM RMAC

BMMM RMAC

0.02 0

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(b) Moving at Speed 1.

120

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 8: Average Packet Drop Ratio in RMAC and BMMM. 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 for 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. 12

Fig. 8 plots the average Rdrop over all non-leaf nodes in the network in each kind of our experiments. Note that for a leaf node, since it forwards no packets, it drops no packets. From Fig. 8 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 Rdrop for a non-leaf node is only about 0.0032 on average; (2) when the nodes are moving, the average Rdrop in RMAC increases considerably, since mobility often results in that nodes cannot be reached by their previous parents until the new parents are discovered. (3) for all the three scenarios, RMAC has less packet drops than BMMM. 4.2.3

End-to-End Delay 7

5 4 3 2 1 0

7 BMMM RMAC

6

Average End-to-End Delay (seconds)

BMMM RMAC

6

Average End-to-End Delay (seconds)

Average End-to-End Delay (seconds)

7

5 4 3 2 1 0

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(a) Stationary.

BMMM RMAC

6 5 4 3 2 1 0

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(b) Moving at Speed 1.

120

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 9: Average End-to-End Delay (in seconds) in RMAC and BMMM. In evaluation on the speed of RMAC, we measured the end-to-end delay for a packet to travel from the source node to each of other nodes in the network. To get a general idea of these end-to-end delays, we calculated the average value (denoted by D) of all the end-to-end delays experienced by all the packets in each kind of our experiments. Fig. 9 plots D in each kind of our experiments. From this figure we see that (1) having a value less than 2 seconds, D for RMAC increases slowly with the growth of the source traffic rate, which is a reflection of the increasing queueing delay and the number of retransmissions at nodes; (2) D does not rise significantly when nodes are moving, since more packets are dropped in motion and many of these dropped packets have potential long delays; and (3) RMAC has a much lower D than BMMM in all the three scenarios, which indicates that RMAC offers a relatively fast reliable multicast service to the upper layer.

4.3 Overhead In the overhead evaluation of RMAC, we mainly measured data on the following four metrics: packet retransmission ratio, transmission overhead ratio, length of MRTS, and MRTS abortion ratio. With the last two metrics specific to RMAC, measurement on only the first two metrics is done for BMMM for comparison. 4.3.1

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 Rretx ), 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. 13

1.8

1.6

1.6

1.4 1.2 1 0.8 BMMM RMAC

0.6 0.4 0.2

Average Retransmission Ratio

1.8

1.6 Average Retransmission Ratio

Average Retransmission Ratio

1.8

1.4 1.2 1 0.8 0.6 0.4 BMMM RMAC

0.2

0 20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

1.2 1 0.8 0.6 0.4 BMMM RMAC

0.2

0 5 10

1.4

0 5 10

20

(a) Stationary.

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

5 10

20

(b) Moving at Speed 1.

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 10: Average Packet Retransmission Ratio in RMAC and BMMM. Fig. 10 plots the average Rretx 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 for a non-leaf node in RMAC on average is no more than 0.32, a very low retransmission ratio for the multicast scenario; (2) when the nodes are moving, Rretx for RMAC increases to around 1; however, RMAC still has less R retx than BMMM. In general, the above results evidence that the protection of RBT really helps to reduce the number of retransmissions. 4.3.2

Transmission Overhead Ratio

BMMM RMAC

3 2.5 2 1.5 1 0.5 0

4

3.5

Average Transmission Overhead Ratio

4 Average Transmission Overhead Ratio

Average Transmission Overhead Ratio

4 3.5

BMMM RMAC

3 2.5 2 1.5 1 0.5 0

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(a) Stationary.

120

3.5

BMMM RMAC

3 2.5 2 1.5 1 0.5 0

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(b) Moving at Speed 1.

120

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 11: Average Transmission Overhead Ratio in RMAC and BMMM. 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. Rtxoh can be similarly defined for BMMM, except that no time spent in checking ABTs is included. Fig. 11 plots the average Rtxoh 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 txoh for RMAC increases slowly from 0.16 to 0.23, which is quite low compared with R txoh for BMMM (ranging from 1.0 to 1.1) and (2) when the nodes are moving, the values of Rtxoh for both RMAC and BMMM rise significantly, but RMAC can still achieve an Rtxoh below 1.1. It can be concluded from this figure that the use of MRTS and ABT generates very limited transmission overhead.

14

100

90

90

80 70 60

Average Maximum 99 Percentile

50

80 70 60

40

30

30 20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

Average Maximum 99 Percentile

50

40

5 10

Length of MRTS (in bytes)

100

90 Length of MRTS (in bytes)

Length of MRTS (in bytes)

100

80 70 60

Average Maximum 99 Percentile

50 40 30

5 10

(a) Stationary.

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

5 10

(b) Moving at Speed 1.

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 12: Average, 99 percentile, and Maximum Lengths (in bytes) of MRTSs in RMAC. 4.3.3

Length of MRTS

The MRTS frame introduced in RMAC has a variable length. Since it is a general concern that a control frame should not be long, we measured the average, maximum, and 99 percentile lengths of the MRTS frames in each kind of our experiments. These measurement results are plotted in Fig. 12, which shows that (1) when nodes are stationary, the average length of MRTS is below 41 bytes and 99% of the MRTSs have a length less than 74 bytes; (2) both mobility and high source traffic rate tend to reduce the average length of MRTS, because the number of retransmissions increases under these two conditions and MRTSs in retransmissions are generally shorter than those in initial transmissions; and (3) the maximum length of MRTS increases when nodes are moving, because a mobile tree topology can produce parents with a larger number of children than a static one. Generally, the above results verify our assumption that MRTS is not long in most cases. MRTS Abortion Ratio 0.07

0.07

0.06

0.06

0.06

0.05

0.05

0.05

0.04 0.03 0.02 0.01

Average Maximum 99 Percentile

0.04 0.03 0.02 0.01

0

MRTS Abortion Ratio

0.07

MRTS Abortion Ratio

MRTS Abortion Ratio

4.3.4

Average Maximum 99 Percentile

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(a) Stationary.

120

0.03 0.02 0.01

0 5 10

0.04

Average Maximum 99 Percentile

0 5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

(b) Moving at Speed 1.

120

5 10

20

40 60 80 100 Source Packet Transmission Rate (pkts/s)

120

(c) Moving at Speed 2.

Figure 13: Average, 99 percentile, and Maximum Value of MRTS Abortion Ratio in RMAC. To guarantee the collision-free data reception in RMAC, a transmitting MRTS or unreliable data frame has to be aborted if an RBT is detected during its transmission. Since the abortion of an unreliable data frame will not incur any further overhead, in this subsection we only focus on the MRTS abortion which will cause retransmission if the limit for retransmission is not exceeded. We define the “MRTS abortion ratio” (denoted by R abort ) at a node as the total number of MRTSs aborted by that node versus the total number of MRTS transmissions performed by that node. Fig. 13 plots the average, maximum, and 99 percentile values of R abort for all non-leaf nodes in the network in each kind 15

of our experiments. From this figure we see that (1) when nodes are stationary, for all source traffic rates, the average values of Rabort are below 0.0035 and the 99 percentile values of R abort are below 0.03; (2) when nodes are moving, the three values of R abort are slightly larger than those in stationary, since a node with ongoing MRTS transmission may move from an RBT-free area into the RBT range of another node. In brief, Fig. 13 shows that MRTS abortion is a rare phenomenon in RMAC.

5 Conclusion In this paper, we presented a new MAC protocol for wireless ad hoc networks called RMAC that implements the reliable multicast service at the MAC layer using the busy tone mechanism. RMAC is also generalized into a comprehensive protocol that supports both reliable and unreliable services for all the three modes of communications: unicast, multicast, and broadcast. The key ideas of RMAC are summarized as follows: • A variable length MRTS frame is used to stipulate an order for the multicast receivers to respond with ABTs. By using a single relatively long MRTS frame instead of a sequence of short control frames, significant overhead is saved. • RBT is utilized to guarantee the collision-free data reception at the multiple receivers, so the ratio of retransmission is significantly reduced. The use of RBT also obviates the need for a node to maintain the NAV variable, thus simplifying the protocol. • ABT is utilized to acknowledge the data frames. Since an ABT is much shorter than an ACK frame and has no problem of collisions or bit errors, the efficiency of acknowledgments is improved greatly. Evaluation is done on RMAC and comparison is also made with BMMM, an example of other ARQbased reliable multicast MAC protocols. Fully justifying our claims, the evaluation and comparison presented in this paper mainly showed the following: • RMAC achieves high reliability: (1) when the nodes are stationary, R deliv is close to 1, showing that the RMAC can be ideally used in a static network and (2) when the nodes are moving, though R deliv drops apparently, it remains much larger than that of BMMM. • RMAC introduces very limited overhead: (1) R retx is less than 0.32 when nodes are stationary and is less than 1.3 when nodes are moving; (2) R txoh is around 0.2 in case of stationary nodes and is around 1.0 in case of moving nodes; (3) the MRTS length has an average of 41 bytes and is less than 74 bytes in most cases, which is quite acceptable for a control frame; and (4) the phenomenon of MRTS abortion rarely occurs. Moreover, for the first two comparable metrics, RMAC is found to have lower overhead than BMMM.

16

Appendix A — State Transition of RMAC Combining the procedures of Reliable Send and Unreliable Send services, a node in RMAC runs in one of the following eight states: • IDLE: the node has no packet to transmit; or the node is waiting to start or resume the backoff procedure due to the busy data channel or RBT channel. • BACKOFF: both data channel and RBT channel are idle and BI is not 0. • WF RBT: after transmission of an MRTS, the node waits for the RBT to arrive. • WF RDATA: after turning on the RBT, the node waits for the data frame to arrive. If the first bit of the data frame arrives, this state continues to the end of the data frame reception; otherwise, this state ends at the expiration of the timer T wf rdata . • WF ABT: after transmission of the data frame, the node waits for the ordered ABTs to arrive. • TX MRTS: in transmission of an MRTS. • TX RDATA: in transmission of a reliable data frame. • TX UNRDATA: in transmission of an unreliable data frame. Here we note that the reception of the MRTS frame or the unreliable data frame can only happen in IDLE state. It cannot happen in BACKOFF state, because while receiving frames, a node regards the data channel as busy. The state transition diagram is shown in Fig. 14 and the state transition conditions (labeled in Fig. 14 with the form “C#”) are detailed in Table 1. TX_UNRDATA

C1

WF_RDATA

C3

C7

C2

C6 C4 C5

C8

IDLE

C14

C13 C10

C11

C12

TX_MRTS

BACKOFF

C9

C17

C16

C15

WF_RBT

C18

TX_RDATA

C19

WF_ABT

Figure 14: The State Transition Diagram of RMAC.

17

C# C1 C2 C3 C4

C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19

State Transition Conditions Transmission requires unreliable service and both data channel and RBT channel are idle and BI is 0. Transmission is aborted due to detection of RBT; or after transmission, either data or RBT channel is busy. An MRTS is correctly received. After frame reception, (1) the transmission queue is empty and BI is 0; or (2) either data or RBT channel is busy and BI is not 0; or (3) the transmission queue is not empty and either data or RBT channel is busy and BI is 0. After transmission, both data and RBT channels are idle. BI is 0 and transmission requires unreliable service. After frame reception, both data and RBT channels are idle, and (1) BI is not 0 or (2) transmission queue is not empty and BI is 0. Both data and RBT channels are idle and BI is not 0. BI is 0 and transmission queue is empty; or either data or RBT channel is busy and BI is not 0. Transmission requires reliable service and both data and RBT channels are idle. Transmission is aborted due to detection of RBT. No RBT arrives and either data or RBT channel is busy. After all ABTs, either data or RBT channel is busy. BI is 0 and transmission requires reliable service. No RBT arrives and both data and RBT channels are idle. After all ABTs, both data and RBT channels are idle. Transmission of MRTS is complete. RBT is detected before timer Twf rbt expires. Transmission of reliable data frame is complete. Table 1: The State Transition Conditions of RMAC.

References [1] D. Bertsekas and R. G. Gallagher. Data Networks, Second Edtion. Prentice-Hall, 1992. [2] Christian Bettstetter. Mobility modeling in wireless networks: categorization, smooth movement, and border effects. ACM SIGMOBILE Mobile Computing and Communications Review, 5(3):55–66, 2001. [3] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. AMRoute: Ad hoc multicast routing protocol. Internet Draft, IETF, Aug 1998. [4] David Eckhardt and Peter Steenkiste. Improving wireless LAN performance via adaptive local error control. In Proc. IEEE ICNP’98, 1998. [5] J.J. Garcia-Luna-Aceves and E.L. Madruga. The core-assisted mesh protocol. IEEE Journal on Selected Areas in Communications, 17:1380–1394, Aug 1999. [6] Mario Gerla, Ching-Chuan Chiang, and Lixia Zhang. Tree multicast strategies in mobile multihop wireless networks. ACM/Balzter Mobile Network and Applications Journal, 4:193–207, 1999. 18

[7] S.K.S. Gupta, V. Shankar, and S. Lalwani. Reliable Multicast MAC Protocol for Wireless LANs. In Proc. IEEE ICC’03, May 2003. [8] Z. Haas and J. Deng. Dual busy tone multiple access (DBTMA): A multiple access control scheme for ad hoc networks. IEEE Transactions on Communications, 50:975–985, June 2002. [9] IEEE. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. ANSI/IEEE Std 802.11, 1999 Edition, 1999. [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 802.11b, 1999 Edition, 1999. [11] J. Kuri and S. K. Kasera. Reliable multicast in multi-access wireless LANs. Wireless Networks, 7(3):359–369, 2001. [12] S. Lee, W. Su, and M. Gerla. Ad hoc wireless multicast with mobility prediction. In Proc. IEEE ICCCN’99, Boston, MA, October 1999. [13] S.J. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia. A performance comparison study of ad hoc wireless multicast protocols. In Proc. IEEE INFOCOM’00, Tel Aviv, Israel, March 2000. [14] P. Levis and D. Culler. Mate: A virtual machine for tiny networked sensors. In Proc. ACM Conference on Architectural Support for Programming Languages and Operating Systems, pages 207–218, San Jose, CA, October 2002. [15] Elizabeth M. Royer and Charles E. Perkins. Multicast operation of the ad hoc on-demand distance vector routing protocol. In Proc. ACM MobiCom’99, pages 207–218, Seattle, WA, August 1999. [16] M. T. Sun, L. Huang, A. Arora, and T. H. Lai. MAC layer multicast in IEEE 802.11 wireless networks. In Proc. the International Conference on Parallel Processing (ICPP) 2002, 2002. [17] K. Tang and M. Gerla. MAC reliable broadcast in ad hoc networks. In Proc. IEEE MILCOM 2001, pages 1008–1013, October 2001. [18] F.A. 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:1417–1433, Dec 1975. [19] Don Towsley, James Kurose, and Sridhar Pingali. A comparison of sender-initiated and receiverinitiated reliable multicast protocols. IEEE Journal on Selected Areas in Communications, 15:398– 406, April 1997. [20] C. Wu and V.O. Li. Receiver-initiated busy-tone multiple access in packet radio networks. In Proc. ACM SIGCOMM’87, pages 336–342, 1987. [21] C. Wu and Y. Tay. AMRIS: A multicast protocol for ad hoc wireless networks. In Proc. IEEE MILCOM’99, Atlantic City, NJ, Nov 1999. [22] Xiang Zeng, Rajive Bagrodia, and Mario Gerla. GloMoSim: a library for parallel simulation of largescale wireless networks. In Proc. The 12th Workshop on Parallel and Distributed Simulations, Alberta, Canada, May 1998.

19