RMAC: A New MAC Protocol with Reliable Multicast Support for Wireless Ad-Hoc Networks

Transcription

1 RMAC: A New MAC Protocol with Reliable Multicast Support for Wireless Ad-Hoc Networks Weisheng Si, ws4u@cs.virginia.edu Huafeng Lü, hl3d@cs.virginia.edu Dec 6th, 00 1 Introduction In most of the MAC protocols for wireless ad hoc networks today, no reliable multicast service is provided. For example, IEEE 80.11[5], the most widely used MAC protocol at present, only supports reliable unicast with the RTS/CTS/DATA/ACK scheme; while for broadcast or multicast frames 1, it simply performs one transmission of them without any reliability guarantee. In this report, we propose a new MAC protocol called RMAC which provides reliable multicast service to the upper layer. Our propose of this new protocol with reliable multicast support is mainly based on the following observations. First, we notice that multihop multicast communication in wireless ad hoc networks needs reliable multicast service from the MAC layer. Recently, many network layer multicast protocols have been proposed. They can be largely classified into two categories tree-based multicast protocols([4, 9, 14, 1]) and meshbased multicast protocols([7, 3]). However, people find out both of the two kinds of approaches have serious problems if high reliability is needed by the multicast communication. In tree-based multicast protocols, no matter how the tree is built in different protocols, they all eventually use a tree to do multicast. And it is shown by some research works[3, 8] that multicasting with a tree in wireless networks suffers from severe packet loss due to the unreliable wireless channel and the lean connectivity of the tree. An illustration of this problem is given in Figure 1, which shows that if one node in the multicast tree, say node B, does not receive the packet, then all its children can not receive the packet, thus resulting in significant packet loss. R A B C I D E F G H Figure 1: Problem of multicasting with a tree. 1 To comply with the terminology of the IETF and IEEE standards, we call the protocol data units in the network layer packets and those in the MAC layer frames in this report. 1

2 Trying to solve the above problem, people move on to the mesh-based multicast protocols which forward multicast packets along a mesh. In a mesh, there usually exist more than one node sending packets to an arbitrary node, thus increasing the chance that a node can get the packets. However, this class of protocols are inefficient since they introduce redundant packet transmissions and nodes in the multicast group have to memorize previous packets to avoid sending duplicate packets to the upper layer. As shown above, we believe that solely working on the network layer can not provide highly reliable multicast for wireless networks in an efficient way, i.e., multicast reliability support is needed from the MAC layer. Second, in the perspective of functionality provision at different protocol layers of wireless networks, MAC layer is the correct place to put the reliability functionality. In wired networks, the links almost have no loss and errors. So reliability functionality is usually implemented at the end-to-end level in the transport layer(e.g., TCP), since it is not worth to do recovery at each hop that the packets pass through. However, in wireless networks, the links are prone to have loss and errors, which makes local recovery mechanism worth to be performed. In [], it is shown that adding local recovery mechanism at the MAC layer can greatly improve the end-to-end communication performance in case of unicast. Here we believe that providing the reliable multicast functionality at the MAC layer will produce the same effect, which is justified by our later simulations. The rest of the report is structured as follows. Section describes other research works that providing reliable multicast service at the MAC layer. Section 3 presents our RMAC protocol in detail. Section 4 describes how the RMAC is implemented under GloMoSim. Section 5 presents our evaluation results on the RMAC protocol. Finally, section 6 concludes this report. Related Works As far as we know, only two reliable multicast MAC protocols have been proposed up to now. One is called Broadcast Medium Window(BMW) protocol[11] and the other is called Batch Mode Multicast MAC protocol[10]. Both of them provide reliable broadcast or multicast functionality by modifying the IEEE DCF(Distributed Coordination Function) mode. BMW mainly considers supporting reliability for broadcast. The basic idea of BMW is that a node reliably transmit a broadcast frame to each of its neighbors in a round robin fashion. The neighbor list is obtained by both periodical HELLO messages and overhearing. Once a frame other than HELLO message is transmitted by a node, the node will suppress its next HELLO message, assuming neighbor nodes can know its presence by overhearing this frame. The main drawback of BMW is that it uses at least rounds of unicasts for a broadcast frame destined to its neighbors, which not only introduces at least rounds of contention phases but also takes no utilization of the broadcast nature of the wireless channel. Considering the problem of BMW, BMMM proposes to consolidate the contention phases of BMW into one contention phase and transmits the data only one time before the ACK collecting. To transmit a reliable multicast frame in BMMM, a sender first uses its RTS frames to request intended receivers one by one to reply with a CTS. If the sender receives at least one CTS, it transmits the data frame. After the data frame transmission, it uses a new control frame called RAK(Request for ACK) to request ACKs from the intended receivers one by one. In case of missing ACKs, the sender will do retransmission. All the intervals between the above sequence of frames are set to a value less than DIFS, so once the sender grabs the channel, the reliable multicast operation will not be interrupted by other transmissions. Here we point out some drawbacks of the BMMM. First, it introduces rounds of RTS/CTS exchange and RAK/ACK exchange, in which any missing of the frames will cause retransmission. Second, though the four control frames have short length, other overheads of transmitting a frame in the wireless physical layer is high. For example, in IEEE specification, if the DSSS physical layer is used, the preamble

3 length for a frame is 144 micro-seconds and the PLCPHeaderLength is 48 micro-seconds. So we believe using large number of control frames is also not efficient. The RMAC protocol proposed in this report is designed to overcome the drawbacks of the two aforementioned protocols. Since in the BMMM paper it is shown that BMMM is better than BMW, we are planning to give a comparative evaluation of RMAC and BMMM in the future. 3 The RMAC Protocol 3.1 RMAC Overview Due to the inefficiency of realizing reliable multicast with the RTS/CTS like mechanism, we turn to another mechanism called busy tone to achieve the multicast reliability. Busy tone is simply a radio signal transmitted via a narrow-bandwidth channel other than the data channel. The busy tone mechanism is used in several other research works such as [1], [13], and [6]. In [1], the busy tone is used to solve the hiddenterminal problem in the wireless environment where there is a central base station. In [13], the busy tone is also used to solve the hidden-terminal problem, but in an ad hoc wireless environment. In [6], the busy tone used by [13] is kept and another busy tone is added to eliminate the exposed-terminal problem for the RTS transmission, so that both the hidden-terminal and the exposed-terminal problems are solved. It is a general belief that the hardware for a busy tone is very cheap to be equipped. In our RMAC protocol, we also introduce two busy tones in order to realize reliable multicast. We call one busy tone RBT(Receiver Busy Tone), and the other one ABT(Acknowledgement Busy Tone). Basically, we use RBT the same way as [13] and [6] to solve the hidden-node terminal problem, guaranteeing collisionfree data reception. The main idea of RBT is that before receiving a frame in a transmission, the receiver sets up the RBT, whose sensing range is the same as the sensing range of the data channel. Nodes(except the sender) in the sensing range of the receiver shall not start frame transmission or abort their current frame transmission once the RBT is sensed(see Figure ). In this way, the frame transmission to the receiver is guaranteed to encounter no collisions, thus greatly reducing the retransmissions.. S text R can not transmit A Figure : The Basic Idea of Receiver Busy Tone. As a novel use of busy tone, we use the ABT to acknowledge the frame reception. Since the ABT is only a signal, the sender has to no way to tell which node the ABT comes from. So we use a control frame(still called RTS frame) to specify an order of replying ABTs by the multicast receivers. The format of the RTS frame is shown in Figure 3. The ABT from each receiver has the same duration and is expected by the multicast sender at a pre-calculated time slot. For each receiver, it determines its time slot to respond with the ABT according to the order specified in the preceding RTS frame. Using ABT to do acknowledgements mainly has the following two advantages: (1) As a signal, ABT does not need the preamble or PLCP header 3

4 as a frame does, so it can be very short and () ABT does not have the collision or bit error problems suffered by a frame. SRC ADDR # RECEIVERS ADDR 1 ADDR ADDR Figure 3: Format of The RTS Frame in RMAC. Here ADDR1, ADDR,..., are a list of the receiver addresses. As described above, the main idea of our RMAC protocol can be summarized as follows: 1. The mechanism of realizing reliable multicast in RMAC altogether needs the following: a flexiblelength RTS frame containing an address list of the intended multicast receivers, Receiver Busy Tone, and Acknowledgement Busy Tone.. The multicast sender uses the RTS frame to specify an order for the intended receivers to reply with an ABT which is a very short signal. 3. The intended receivers getting the RTS set up the RBT to guarantee the collision-free data reception, thus reducing the number of retransmissions. 3. RMAC Description Generally, the RMAC protocol provides two data transmission service primitives to the upper layer. We call them Reliable Send and Unreliable Send respectively: Reliable Send It has the form reliable-send(payload, receiver list). Here payload is a protocol data unit from the upper layer to be encapsulated in a reliable data frame and receiver list is an address list of the intended receivers. This service primitive guarantees the reliable transmission of payload to the listed receivers for the upper layer unless the number of retransmissions exceeds the limit. Since in a reliable transmission the sender needs to know who are its receivers, this service primitive requires the address list of the receivers be passed from the upper layer, giving MAC layer the flexibility to support various kinds of upper layer protocols. Note that this service primitive covers the case of reliable unicast if only one receiver is specified in the receiver list and the case of reliable broadcast if all neighbors of a node is specified in the receiver list. Unreliable Send It has the form unreliable-send(payload, dst). Here payload is a protocol data unit from the upper layer to be encapsulated in a unreliable data frame and dst is a destination address which has three forms a unicast address, a multicast address, and a broadcast address. This service primitive only transmits payload one time to dst without any recovery mechanism. Note that we provide this service primitive in the RMAC protocol is because many upper layer protocols need a light-weight transmission service when reliability is not a big concern. For example, periodical one-hop broadcasting usually should be performed by this service primitive. In the following two subsections, we present how these two service primitives are realized in the RMAC protocol. 4

5 3..1 The Reliable Send Service Primitive The following concepts or symbols are used in the Reliable Send service primitive description: : The maximum one-way propagation delay. : The duration needed to detect a busy tone. : The timer for waiting for RBT after the RTS transmission. Its length is set to. : The timer for waiting for the reliable data frame after turning on the RBT. Its length is set to. : The location index of an intended receiver in the address list of the RTS frame. For example, the first receiver listed in the RTS frame has "!, and the second receiver has $#, etc. % : The timer for responding with an ABT after the successful data frame reception. Its length % is set to '&)(+*,.-. / : The timer for sensing an ABT at the sender. is initially set to *, right after the data frame transmission for sensing the first ABT and afterwards / is reset to *, 0 at each / expiration for sensing the subsequent ABTs. As mentioned above, this service primitive takes the payload to be transmitted, and the list of intended receivers as input parameters from the upper layer. After receiving such a request from the upper layer, it mainly performs the following steps (illustrated in Figure 4): A-BT Receiver-BT Node B RTS DATA Node A RTS 3 DATA A-BT A-BT Node C RTS DATA Receiver-BT A-BT Figure 4: Time Diagram of Reliable Send Service Primitive. 1. The sender senses both the data channel and the RBT channel. If both of them are idle, it transmits an RTS which contains a list of the addresses of the intended receivers. If either of them is not idle, the sender backs off. 5

6 . Upon receiving an RTS, a node checks if it is one of the intended receivers by looking at the address list in RTS. If it is, it memorizes its index in the RTS address list and turns on the RBT. The RBT has two usages here: one is to tell the sender that some node has received the RTS and the other is to guarantee collision-free data reception at the receiver as illustrated in Subsection If a node which is transmitting an RTS frame or an unreliable data frame senses the RBT during its transimission, it should abort its on-going transmission, ensuring no collisions at the node setting up the RBT. Here we note that this abortion seldom happens, since the only chance is that the interrupted node starts its RTS or unreliable data transmission in a very short interval approximately between the time the RBTing node receives the RTS and the time the interrupted node detects the RBT. 4. After transmitting RTS, the sender sets up the timer.. If RBT is sensed before expires (note that the sender only needs to tell whether at least one RBT is on), it transmits the payload in a data frame upon the timer expiration. Otherwise, the sender backs off upon the timer expiration. Here we set the timer period 1, which is because 1 is the safe time required to allow other RTS or unreliable data transmissions which may interfere this transmission to be aborted. 5. After turning on the RBT, the intended receiver sets up the timer If the data frame arrives before 4 expires, it cancels the timer. Otherwise it stops the RBT upon the timer expiration. If the data frame is correctly received, it immediately turns off the RBT and sets up the timer 5%. Here % is set to 6&)(+*,.-. When % expires, it turns on the ABT for duration *,. 6. After the data frame transmission, the sender sets up the timer / with / 7*, to sense the first ABT and afterwards a new / for later ABTs will be set at the beginning of previous / expiration with / 8*, 9$. So the sender senses each ABT from the intended receivers for a time slot with length *, :;. If in th slot an ABT is not sensed, the sender assumes that the th receiver in the RTS address list does not receives the data frame. After the sensing of the last ABT, if all intended receivers have responded with an ABT, the sender yields for a period so that other nodes may have chance to transmit. Otherwise, the sender constructs a new RTS frame which contains those receivers failing to respond with an ABT and repeats from step 1. Compared with IEEE based reliable multicast solutions, the RMAC Reliable Send service primitive is simple in the following two ways. First, unlike the RTS frame in IEEE 80.11, the RTS frame in RMAC does not have a duration field. This is because data frame reception is protected by the RBT so that NAV no longer needs to be maintained by the wireless nodes. Second, since ABT does not has the problem of collisions or errors, the reception of transmitted ABT is almost guaranteed. So there is no need to put sequence numbers in the data frames and nodes do not need to memorize the sequence number of the previously received data frame. 3.. The Unreliable Send Service Primitive The Unreliable Send service primitive is introduced for protocol operations in which reliability is not necessary. As mentioned in Subsection 3.1, this service primitive takes the payload to be broadcast and the destination address dst as the parameter passed from the upper layer. The basic protocol steps of the Unreliable Send service primitive is described as follows: 1. The sender senses both the data channel and the RBT channel. If both of them are idle, the sender encapsulates the payload into a unreliable data frame in which the destination address field is set to dst. Then it transmit this frame. If either of two channels is not idle, the sender backs off. 6

7 . During the transmission of a data frame, the sender keeps listening to the RBT channel. If RBT is sensed, it will abort the on-going transmission without performing retransmission in the future. 3. Upon correctly receiving a unreliable data frame, a node checks the destination address field in the frame. If it should accept this frame, it decapsulates this frame and passes the payload to the upper layer, without replying an acknowledgement to the sender. Otherwise, it discards the frame RMAC State Transition Combining the implementation of Reliable Send and Unreliable Send service primitives in RMAC, a node in RMAC protocol is running in one of the following nine states: IDLE: Upper layer has no packets to send. BACKOFF: Upon a busy data channel or RBT channel, the node waits for a random period before next contending for the channel. YIELD: After a successful data frame transmission, the node waits for a fixed period so that other nodes have chances to transmit. WF RBT: After the transmission of the RTS frame, the node waits for the RBT to arrive. WF RDATA: After turning on the RBT, the node waits for the reliable data frame to arrive. WF ABT: After the transmission of the reliable data frame, the node waits for the ABT to arrive. TX RTS: The node is in the process of transmitting an RTS frame. TX RDATA: The node is in the process of transmitting a reliable data frame. TX UNRDATA: The node is in the process of transmitting a unreliable data frame. The state transition diagram and the state transition conditions are shown in Figure 5. 4 RMAC Implementation The RMAC protocol is implemented and evaluated under GloMoSim[15], a widely used simulator for wireless networks today. GloMoSim has a very well-organized framework for developing new protocols. It is structured with a layered architecture which consists of five layers-physical layer, MAC layer, network layer, transport layer, and application layer. At each layer, well-defined interfaces make it easy to add new protocols. An advantage of GloMoSim is that it supports multiple network interfaces at a node, which exactly satisfies the multiple-interface requirement of our RMAC protocol. In the implementation of RMAC, each node is initiated with three interfaces and we use one interface as the data channel and the other two interfaces as the RBT channel and ABT channel respectively. The programming tasks for the RMAC implementation include: (1) Implementing a physical layer for the busy tone channel. () Implementing the RMAC protocol. The programming tasks for the RMAC evaluation include: (1) Implementing an application called FLOOD which sends CBR(Constant Bit Rate) traffic to the entire network by flooding and each node only forwards a packet one time. 7

8 WF_RBT C3 TX_RDATA C4 WF_ABT C no BT fail success TX_RTS abort BACKOFF YIELD C1 busy timeout C6 C6 abort C5 IDLE C6 C7 WF_RDATA TX_UNRDATA C8 C9 Figure 5: The State Diagram of The RMAC Protocol. Some state transition conditions are listed as follows. C1: Upper layer has reliable data to send and both the data and RBT channels are idle. C: An RTS frame is transmitted. C3: RBT is sensed before <>=@? ABDC expires. C4: A reliable data frame is transmitted. C5: An unreliable data frame is transmitted. C6: An RTS frame for the node is received. C7: An reliable data frame is received. C8: Upper layer has unreliable data to send and both the data and RBT channels are idle. C9: The period of yielding ends. () Implementing an application called TREECAST which sends CBR traffic to the entire network along a existing tree. The usage of the FLOOD and TREECAST applications will be described in Subsection Evaluation We evaluate the RMAC protocol based on our implementation of it under the GloMoSim. We mainly focus on two aspects of the RMAC in our evaluation. One is the level of reliability it achieves and the other is the overhead introduced for providing reliable multicast. 5.1 Experiment Setup The network used in our evaluation contains 75 wireless nodes which are randomly placed on a FE!HGI& *HJ,!HG plain. The communication range of all nodes is set to K!ML *,!HG. Basically, we use the network-wide broadcast, a special case of multihop multicast, to evaluate our RMAC protocol. With RMAC as the underlying MAC protocol, we run the TREECAST application over a tree covering all the 75 nodes in the network. The CBR traffic rates used in our evaluation are 5 pkts/sec, 10 pkts/sec, 0 pkts/sec,..., and 60 pkts/sec, with packet size 600 bytes. We call this kind of experiment TREE-RMAC in the later description. An example tree topology used in our evaluation is shown in Figure 6. To make a comparison, we also run two other kinds of experiments with the same parameters set as those in TREE-RMAC experiments: (1) running the FLOOD application with IEEE DCF mode as the underlying MAC protocol and () running the TREECAST application with IEEE DCF mode as the underlying MAC protocol, using the same tree topology as TREE-RMAC. We call these two kinds of experiments FLOODING and TREE-DCF respectively. 8

9 Figure 6: An Example Network Tree Topology. 5. Reliability We define the successful packet delivery rate (denoted by N ) as N total number of packets received by all nodes total number of packets that should be received by all nodes (1) We use N as an important metric both for measuring the reliability of the RMAC protocol and for making comparisons with FLOODING and TREE-DCF. Figure 7 plots the experiment results of the TREE-RMAC, FLOODING, and TREE-DCF experiments. From this figure we see that Almost equal to one, N of TREE-RMAC is much higher than N of FLOODING or TREE-DCF. N of FLOODING degrades quickly with the increasing of the traffic rate. N of TREE-DCF is the lowest due to the problem illustrated in Figure Overhead In evaluating the overhead of RMAC, we mainly measure the following total number of frames sent to the channel, average number of retransmissions per packet, and total number of frames dropped. In the overhead experiments, the source node of TREE-RMAC, FLOODING, or TREE-DCF altogether generates 10 packets. And the tree topology used by TREE-RMAC and TREE-DCF has 44 leaf nodes, which means that all nodes can get the 10 packets with ideally 310 ( ( K EPO H -1&Q#R! ) transmissions at the non-leaf nodes. Figure 8 plots the total number of frames sent to channel by experiments TREE-RMAC, FLOODING, TREE-DCF, and the ideal value of 310 frames. Note that we only count the data frames here. From this figure we see that (1) FLOODING sends the most number of frames to the channel, introducing significant overhead to the network capacity, () TREE-RMAC only sends slightly more than the ideal number of frames to the channel, showing its overhead is very limited, and (3) TREE-DCF sends less than the ideal number of frames to the channel due to its severe packet loss. 9

10 Successful Packet Delivery Rate TREE-RMAC FLOODING TREE-DCF Source Traffic Generating Rate(pkts/s) Figure 7: Deliver Rate. Figure 9 plots the average number of retransmissions per packet for TREE-RMAC. From this figure we see that the absolute value of average retransmissions is quite small, though it is increasing with the rising of the traffic rate. So we can draw the conclusion that retransmission does not cause significant overhead in RMAC. Figure 10 plots the total number of packets dropped during the TREE-RMAC experiments. From this figure we see that the number of packets dropped is very small, arguing for the strong reliability of the RMAC protocol. According to our observation of the experiments, all packet droppings are caused by the phenomenon that the number of retransmissions exceed the limit, which is set to 8 in our experiments. 6 Conclusion References [1] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. Amroute: Ad hoc multicast routing protocol. Internet Draft, IETF, Aug [] David Eckhardt and Peter Steenkiste. Improving wireless lan performance via adaptive local error control. In Proc. IEEE ICNP 98, [3] J.J. Garcia-Luna-Aceves and E.L. Madruga. The core-assisted mesh protocol. IEEE Journal on Selected Areas in Communications, 17: , Aug [4] 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 07, [5] IEEE Working Group. Part 11: Wireless lan medium access control (mac) and physical layer (phy) specifications. ANSI/IEEE Std 80.11, 1999 Edition, [6] 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: , June

11 Total Num of Pkts Sent to Channel TREE-RMAC FLOODING TREE-DCF IDEAL Source Traffic Generating Rate(pkts/s) Figure 8: Total Number of Frames Sent to The Channel. [7] S. Lee, W. Su, and M. Gerla. Ad hoc wireless multicast with mobility prediction. In Proceedings of IEEE ICCCN 99, Boston, MA, October [8] 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 000. [9] Elizabeth M. Royer and Charles E. Perkins. Multicast operation of the ad hoc on-demand distance vector routing protocol. In Proceedings of ACM MobiCom 99, pages 07 18, Seattle, WA, August [10] M. T. Sun, L. Huang, A. Arora, and T. H. Lai. MAC layer multicast in IEEE wireless networks. In Proceedings of the International Conference on Parallel Processing (ICPP) 00, 00. [11] K. Tang and M. Gerla. Mac reliable broadcast in ad hoc networks. In Proc. IEEE MILCOM 001, pages , October 001. [1] 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-3: , December [13] C. Wu and V.O. Li. Receiver-initiated busy-tone multiple access in packet radio networks. In Proceedings of ACM SIGCOMM 87, pages , [14] C. Wu and Y. Tay. Amris: A multicast protocol for ad hoc wireless networks. In Proceedings of IEEE MILCOM 99, Atlantic City, NJ, Nov [15] Xiang Zeng, Rajive Bagrodia, and Mario Gerla. Glomosim: a library for parallel simulation of largescale wireless networks. In Proc. The 1th Workshop on Parallel and Distributed Simulations, Alberta, Canada, May

12 Average Num of Retransmission per Pkt Source Traffic Generating Rate(pkts/s) Figure 9: Average Retransmission. 3 3 Total Num of Pkts Dropped in Network Source Traffic Generating Rate(pkts/s) Figure 10: Total Number of Packets Dropped. 1