A RATE-ADAPTIVE COOPERATIVE MAC PROTOCOL BASED ON RTS/CTS SCHEME FOR MANETS Haitao Zhao, Jibo Wei, Yong Xi School of Electronic Science and Engineering, NUDT ChangSha, China E-mail:
[email protected]
ABSTRACT In this paper we propose a novel relay-enabled MAC protocol based on IEEE 802.11 RTS/CTS scheme for MANETs. The protocol enable the middle node lies between the source and destination to decide whether to relay for them adaptively based on the current channel state information (CSI). Because the channel with better quality can transmit data with higher rate, and distance is one of the primary factors that determine wireless channel quality, the throughput will be greatly improved if there is a higher rate supporting relay between source and destination. Besides, the throughput can be farther improved due to its ability to cooperative retransmit by taking advantage of the spatial diversity. When there is a transmission error, the relay will retransmit the signal that it received during the error slot to the destination in the following slot. By processing the originally received error packet and the packet retransmitted by the relay, the destination node can recover the original packets. The proposed approach is approved to have good performance by simulation based on NS2 platform. I. INTRODUCTION AND BACKGROUND Wireless mobile ad hoc networks (MANETs) are typically formed by a group of wireless devices without pre-existing infrastructure. The ease of deployment will make ad hoc networks widely used in the future wireless systems. However, the requirements on future wireless (ad hoc) communication systems in terms of data rate and quality of service are far from satisfied for the moment. To increase the throughput of the wireless communication networks, it is a megatrend to enable devices to operate using many different transmission rates for the variety of wireless channels. Many current and proposed wireless networking standards have this multi-rate capability. These include the 802.11b, 802.11a, 802.11g, and HiperLAN2 standards. While most of the traditional routing protocols select the shortest path which has the least hops as data route, which means that the average distance between the adjacent nodes along the route is as long as possible. Since distance is one of the primary factors that determine wireless channel quality, there is a direct relationship between the rate of communication and the distance required to support that communication reliably. Though multi-rate devices provide increased flexibility, they cannot change the
inherent trade-off between speed and range. Both high speed and long range cannot be achieved simultaneously. We need a scheme that can change the trade-off between speed and range adaptively. In this paper we’ll introduce a rate-adaptive cooperative MAC protocol based on the IEEE 802.11 RTS/CTS scheme for MANETs. This protocol enables the middle node lies between the source and destination to decide whether to relay for them or not based on the current channel state. Besides taking advantage of multi-rate channel, another benefit of having a relay between source and destination is that it can resolve transmission error by taking advantage of spatial diversity. When there is a transmission error, the error packets are saved in the relay’s buffer. In the following slots, the relay retransmits the signal that it received during the previous slot. By processing the original error packets and the signals forwarded by the relay, by the means proposed in [5], the destination node can recover the original packets. The rest of the paper is organized as follows. In Section II, we outline the related work. In Section III, we provide the detailed description of the proposed approach. The system performance analysis and simulation are presented in Section IV. And then we give the conclusion of this paper in Section V. II. RELATED WARK Some work has been done to enhance the throughput of the network in the MAC layer by taking advantage of relays. A node cooperative automatic repeat request (ARQ) scheme for wireless ad hoc networks is proposed in [1]. It assumed that there was a perfect feedback channel between the sender and the receiver. After overhearing the ACK or NAK of the destination, the relay chooses to keep silent or relay for the source respectively. It also showed that cooperation among a small number of nodes can significantly improve the performance of retransmission process in terms of throughput, average delay, and delay jitter by reducing the average duration of retransmission trials. In [5] the author develop a MAC protocol based on slotted ALOHA that allows neighbors of a transmitter to act as relays and forward a packet toward its final destination when the transmission to the intended recipient fails. But either of them adopts the multi-rate capability. CoopMAC[2] and rDCF[4] are the cooperative MAC protocols based on the Distributed Coordination Function (DCF) of IEEE 802.11. The basic ideas in them are similar.
They take advantage of the multi-rate capability of the IEEE 802.11 standard. The source choose the best modulation scheme based on the received signal-to-noise ratio (SNR). The threshold SNR for each modulation type is pre-defined and stored in a physical mode table. Besides, they assumed that every node knows all its relay nodes at any time, so the source can choose a relay before it send data to the receiver. This is realized by maintaining a list of relay node. However, there are some problems. Firstly, they assume that they already know the relay node before they begin to transmit the data (by maintaining a relay list), but to maintain this kind of list is complicated and energyconsuming. Furthermore, because the mobility of nodes in ad hoc networks and the channel state may change, the pre-determined information on relay nodes may not be usable. Secondly, they only think of the transmit rate and do not take advantage of the inherent spatial diversity brought by the source node and the relay node. The proposed protocol in Section III will resolve those problems. III. RATE-ADAPTIVE COOPERATIVE MAC PROTOCOL BASED ON HANDSHAKING In CSMA/CA, before data transmission, request-to-send (RTS) and clear-to-send (CTS) packets are transmitted by the source/destination pair to reserve the transmission floor for the upcoming data transmission. In the proposed relayenabled MAC protocol, after RTS and CTS, ready-to-relay (RTR) is transmitted by the relay to declare that itself has the ability to relay. And thus a more effective transmission can be done through relay. One of the important differences of the proposed protocol in this paper with that in [2] and [4] is that the ready-to-relay message is send out after the relay received the CTS other than before that. This change will throw off the trouble to maintain relay lists. Furthermore, since the relay node is selected just as the transmit begin instead of being predetermined by the relay list, the proposed protocol is more suitable for the MANETs with fast-moving nodes. A. System model In this paper we adopt the six-node network model, see Fig 1. Node s, d, r are source, destination and relay respectively, and a, b, c are the neighbors of s, d, r respectively. We assume that the channel is slow fading that during the transmission of a packet the channel state doesn’t change. We also take the assumption that the channel is symmetrical, which means the link state from a to b is the same as that from b to a. B. Protocol description The protocol is based on the IEEE 802.11 RST/CTS scheme. To make relay possible, we make some changes: i)
The RTR message is added; ii) There are two SIFSs between CTS frame and data frame; iii) After receiving the RTR instead of CTS, the source node begin to transmit data frames. The detailed handshaking scheme and transmission process are presented as follows. c
r ③
s a
③ ① ② ① ②
d b
①RTS (2Mbps) ② CTS (2Mbps) ③ RTR (s->r: 11Mbps; r->d: 5.5Mbps)
Fig 1. Network model Step 1: After sensing the control channel being idle, if there is no reserve for the data channel, s initiates the handshaking procedure by transmitting the RTS packet. This packet is used to (i) reserve the transmission floor during the control phase and (ii) broadcast the information on the upcoming transmission, including link rate, to the neighbor nodes so that these nodes can determine whether they are eligible for relay or not. Step 2: After d successfully receives the RTS packet, it responds with a CTS packet if the data channel is not reserved by any other neighbor node. After r successfully receives the RTS packet, by measuring the signal strength of the received RTS packet, it can determine the highest link rate that can be supported between itself and s, noted as LRsr. And if the destination is in its neighbor-list, it will waiting for the CTS. Step 3: If r receives the CTS send by d, it measures the signal strength of the received CTS packet and determine the highest link rate that can be supported between itself and d, noted as LRrd. And by decoding the CTS, it gets to know the destination d and the link rate between s and d, noted as LRsd. And Now r has got three link rate: LRsd, LRsr, LRrd, and by a process of “relay decision” (see Section 3.3) according to the three link rate, r determines whether itself has the ability to relay for s and d, sending a RTR message, or keeping silent. (Here, we take an assumption that once r send a RTR message both s and d will receive it correctly, based on the fact that the channel between them is reliable due to their short distance.) In the RTR message include the information of LRsr and LRrd. Step 4: If s and d receives the RTR, they know that there is a relay. So s transmit the data at rate LRsr. Otherwise, s
send the data at the rate LRsd. In the former case, after receiving the packet, r will directly relay it to d at rate LRrd. See Fig. 2.
Fig. 2. Handshaking scheme when r has the ability to be a relay On the other hand, if there is no usable relay between s and d, s will never receive a RTR as mentioned earlier. Under this situation, after receiving CTS from d, s waits for a period of no less than two SIFSs, and if no RTR received, it will send data frame directly to d. In this case, though not transmit data, r knows that itself lies between s and d through the handshaking process, and it can overhear the communication between s and d. According to the ordinary operation, if there is a transmission error, d will request for retransmission. However, if the error is caused by channel degeneration and the channel never get better in the following slots, continuous retransmissions through the same link will not work. Because r is closer to d than s and it already overhear the original packet from s, so let r rather than s retransmit the packet will greatly enhance the probability to recover the error packet due to the inherent diversity. We call this process as cooperative retransmission. When transmission error happens, r will compete with s to transmit the data received from s to d at the rate of LRsd. See Fig. 3.
which it can efficiently manage them. This is the purpose for the maintenance of a structure called the Network Allocation Vector (NAV). The NAV is a data structure that stores the aggregate duration of time that the medium is presumed to be “busy”, based on the reservation requests that have been received. Nodes that overhear a reservation request are free to update their NAVs without regard to any further communication. In Table 3, we list the “busy” duration reservation requests of different types of frame in this protocol. Table 3. Reservation requests Frame type Reservation request RTS CTS+HTS+2σ+3SIFS CTS HTS+DATA(s>d)+ACK+3σ+3SIFS RTR DATA(s->d)+ σ+2SIFS DATA(S->D) ACK+σ+SIFS DATA(S->R) DATA(r->d)+ACK+2σ+2SIFS DATA(R->D) 0 Note: σ is the delay of transmission C. Relay decision The remained question is that how node r determines that itself has the ability to relay or not. According to IEEE 802.11b standard, it supports four transmitting rate: 11 Mbps, 5.5 Mbps, 2.0 Mbps and 1.0Mbps. Table 1 and table 2 respectively list the effective throughputs under different link rates in one-hop transmission and two-hop transmission, which are obtained via NS2 simulation. We can see that the throughput of two-hop-11&11Mbps link rate is less than that of one-hop-5.5Mbps link rate. So
Fig.3. Cooperative retransmission process Note that r and a are both the neighbors of node s, but they act differently. The reason lies that every node knows its neighbors by maintaining a neighbor-list, so after receiving the RTS from s and checking itself’s neighborlist, r knows that itself lies between s and d. While a finds out that itself is not between s and d in the same way. That’s why after receiving RTS from s, r can wait to send a RTR, however, a can only enter a NAV state. Since a node may overhear many different, potentially overlapping, reservation requests, it needs a means by
when the direct link rate between s and d is higher than 5.5Mbps, it shouldn’t use relay. However, to increase the throughput, 1Mbps and 2Mbps direct link between s and d should both be replace by s->r->d link if both the link rate of s->r and r->d is no lower than 5.5Mbps and 11Mbps. In this protocol, node r can get LRsd by decoding RTS. And it uses the received power of message RTS and CTS as the index of link rate. So the decision formula can be presented as follows: If (LRsd < 5.5Mbps) AND
( min(rx_Power_RTS, rx_Power _CTS)>= Th5.5) Then use relay (r sends a RTR) Else Do not use relay (r keeps silent) Where Th5.5 is the receiving threshold to support link rate 5.5Mbps Table 1. Link rate and effective throughput under UDP traffic(RTS always ON) Link Rate(Mbps) Throughput(Mbps) 11 4.37 5.5 3.05 2.0 1.47 1.0 0.83 Table 2. Two hop path and throughput Throughput(Mbps) Link rate(Mbps) 1st hop 2nd hop 11 11 2.23 11 5.5 1.64 11 2.0 1.05 5.5 5.5 1.51 5.5 2.0 0.97 2.0 2.0 0.74 D. Some extensions to the protocol (1)As we know, RTS and CTS are always sent at the basic rate, which will bring down the throughput of the network [7]. So when packets of small size are being transmitted, the RTS and CTS can be turned off, and just adopt the DATA/ACK scheme. The proposed protocol in this paper is compatible with this case, when s sends the data frame direct to d rather than send a RTS before sending data frame. (2) See the shadow part of NAV(CTS) in Fig. 3, node b has to wait a longer time than actually needed. This is because that the reservation request in CTS is not suitable for the case of using cooperative relay. Here we are enlightened by the PBAR[1] protocol, and similarly we can update this field by the header in the DATA(r->d) frame send by r in the case b can hear r to relieve the problem. (3)In the system model, we take the assumption that there is only one relay between s and d. But in many cases there may be more than one node can be the relay. In these cases there must be a scheme to choose the best one as relay node. Here we adopt a Slotted ALOHA like scheme. There are two time slots scheduled for RTR frames, the potential relays contend during the RTR frames using the Slotted ALOHA, which means there’re at most two potential relays have the chance to send the RTR frame even though the potential relays are more than two. Then, after receiving all RTRs, s selects the best relay node
based on the information of LRsr and LRrd that each RTR frame carries. IV. PERFORMANCE ANALYSIS AND SIMULATION A. Throughput analysis In this section, we will analyze the throughput of our proposed MAC protocol in a saturated network, which assumes that all nodes have a backlog of packets for transmission. All nodes are assumed to be uniformly distributed in the coverage area. Here are some notations: Px,y. denotes the probability that a relay node exists between s and d, where x means the link rate from s to r, and y means the link rate from r to d. Rx denotes the link rate of x Mbps. L denotes the size of a transmitting packet, in bit. T denotes the average time needed to transmit a packet. Tx denotes the time needed to transmit a packet at the rate of x Mbps. And TRTS, TCTS, TACK are the time needed to transmit a RTS, CTS and ACK respectively, in second. So the throughput of the network can be given by the following equation: Throughput= L/T (bps) (1) Where T= f11T11 + f5.5T5.5 + f2T2 + f1T1, fx denotes the fraction of nodes transmitting packets at rate x Mbps. And because the signal power is in reverse relation with the square of the transmit range, we have: f11=Th1/Th11 f5.5= (Th11- Th5.5) Th1/(Th11 Th5.5) f2= (Th5.5- Th2) Th1/(Th5.5 Th2) f1=(Th2- Th1)/Th2 Where, ThX is the receiving threshold to support the link rate of x Mbps. And according to [9] we have T11 = Tcont(N) + Toverhead +L/R11 T5.5 = Tcont(N) + Toverhead +L/R5.5 Where Toverhead = TPLCP + DIFS + TRTS + TCTS +3SIFS + TACK，and Tcont(N) is the time spent in the contention period when the node is competing with other N-1 nodes. And according to [8] Tcont(N) ≈ SLOT ×(1 + Pc(N))/2N ×CWmin /2, where Pc(N) =1-(1-1/CWmin)N−1 and SLOT is the time period corresponding to one time slot. For nodes which have a direct transmission rate of 2Mbps and 1Mbps, we have to consider both the transmission time where a relay is present and that if the relay is not available. T2 = Tcont(N) + (P11,11 + P5.5,11 + P11, 5.5+ P5.5,5.5)TcoopOH + 2P11,11L/R11+ P5.5,11L/R5.5+ P5.5,11L/R11+ P11,5.5L/R11+ P11,5.5L/R5.5+ 2P5.5,5.5L/R5.5+ (1- P11,11- P5.5,11P11, 5.5 - P5.5,5.5)(Toverhead +L/R2) T1 = Tcont(N) + (P11,11 + P5.5,11 + P11, 5.5+ P5.5,5.5)TCoopOH+ 2P11,11L/R11+ P5.5,11L/R5.5+ P5,11L/R11+
P11,5.5L/R11+ P11,5.5L/R5.5+ 2P5.5,5.5L/R5.5+ (1- P11,11- P5.5,11P11, 5.5 - P5.5,5.5)(Toverhead +L/R1) Where TCoopOH = 2TPLCP + DIFS + 5SIFS + TRTS + TCTS +TRTR +TACK B. Energy analysis As the transmission energy consumption takes the most part of the energy consumption of the network, we ignore other kinds of energy consumption, such as the energy consumed during the idle period and the contention period. In the proposed protocol every node sends the packets in a fixed power, so the energy consumption is decided by the transmitting time. As mentioned in the former section, the time needed to transmit a packet in our proposed protocol can be presented as Trelay= f11Tr_11 + f5.5Tr_5.5 + f2Tr_2 + f1Tr_1 Where Tr_x equals to Tx minus Tcont(N) with Toverhead being changed to TPLCP + TRTS + TCTS + TACK and TCoopOH being changed to 2TPLCP + TRTS + TCTS +TRTR +TACK That time in the non-relay protocols can also be given as Tnon-relay = f11Tn_11 + f5.5Tn_5.5 + f2Tn_2 + f1Tn_1 Where Tn_x = TRTS + TCTS +TACK+L/Rx So we can define the energy saving rate as Eng_Sav_Rate=(En-Er)/En, where En and Er are the energy consumption in the non-relay protocols and proposed protocol respectively. Suppose P5.5,11 = P11, 5.5 , RTS, CTS, RTR, ACK are all transmit at rate R1. Because R1 = R11/11= R5.5/5.5= R2/2, we get Eng_Sav_Rate=[ (25/22) P11,11L+(21/11) P11,5.5L+(17/22) P5.5,5.5L - 2(P11,11+2 P11, 5.5 + P5.5,5.5) ( LPLCP + LRTR)] / [(f11+ f5.5 + f2 + f1)( LRTS + LCTS +LACK)+ f11L/11 + f5.5 L/5.5 + f2 L/2 + f1 L] (2) C. Simulation results We simulate the proposed MAC protocol on the platform of NS2. The determination of Th5.5 will greatly influence the performance of the protocol. The transmitting power being 31.6mW, we set Th5.5= 1.99e6mW according to the Lucent Orinoco PC Card [10], a commonly used 802.11b wireless adapter. And to compare the simulation result with that of analysis, the other threshold is given in table 3. And the other basic parameters used in the simulation are listed in table 4. Giving the parameter, according to (1) and (2) we get the throughput and the energy-saving rate as: Throughput≈8192/(6120-3938 P11,11-3297P11, 5.5 -3297 P 5.5,11-2759P5.5,5.5) (3) Eng_Sav_Rate =1.32 P11,11+ 1.09 P11, 5.5 + 1.09 P 5.5,11 +0.86 P5.5,5.5 (4) From (3) and (4) we can see that i) When Px,y =0, throughput≈1.32Mbps, Eng_Sav_Rate =0, this is the case when no relay exists. ii) Both the throughput and the
energy-saving rate will increase with the increase of Px,y; iii) If list the Px,y in the order of the influence to the throughput and the energy-saving rate, we will get P11,11>P11, 5.5 = P 5.5,11 > P5.5,5.5, which means that the higher rate the relay supports the more throughput increment and energy saving are brought. Table 3. Receiving threshold and sensitive range of different link rate Parameter Th11 Th5.5 Th2 Th1 Value (mW) 6.31e-6 1.99e-6 7.94e-7 3.98e-7 Cover Range(m) 122.6 163.6 205.9 244.7 Table 4. Simulation parameters Parameter Value Topo Circle (r=245m) basicRate_ 1Mb Traffic CBR SlotTime 20us DIFS 50us SIFS 10us L 8192 bits ACK, CTS 112 bits RTS 160 bits RTR 168 bits PLCP length 96 bits CWwin 31 Nodes velecity 0~10m/s Fig.4 shows the comparison of the analysis result and simulation result. Both analysis and simulation results show that when the nodes are stationary the proposed protocol is over perform the original non-relay protocol, and almost equal to CoopMAC[2]; When the nodes is moving, the throughput is keeping at the level of about 2.2Mbps see Fig.5. That’s the evidence that the proposed scheme is very suitable to the mobile ad hoc networks. And note that when the average velocity of the nodes is increased the throughput is even higher, this can be explained by that the high mobile rate may make the nodes distribute more uniformly. The performance of energy saving is showed in Fig.6, we can see that the proposed protocol can bring evident energy saving. For example it can bring about 18 percents energy saving when there are 20 nodes in the network. And with the increment of the network dense, which enhances the probability that relays are present between the sender and the receiver, the energy saving rate increases. V. CONCLUSIONS In this paper we proposed a relay-enabled protocol in the MAC layer. It can increase the throughput of network by enabling the middle node lies between the source and
0.25 Eng_Sav_Rate
destination to relay for them at a higher link rate and cooperative retransmit by taking advantage of the spatial diversity. It also have a good performance on energy saving. The protocol is based on RTS/CTS scheme, so it is particularly suitable for the burst transmit with large-size packets. And because it determines the relay node just before the data transmission, so it can adapt the case that the topology is changed rapidly. It is very suitable for the MANETs that demands high throughput.
0.2 0.15 0.1
analysis
0.05
simulation
0 4
8
12
16
20
24
28
32
36
40
number of nodes
2.5
Fig.6. Energy saving rate v.s. number of nodes
throughput(Mbps)
2
VI. REFERENCES
1.5
[1] M. Dianati, X. Ling, S. Naik, and X. Shen, "A Node Cooperative ARQ Scheme for Wireless Ad Hoc Networks", IEEE Trans. on Vehicular Technology, Vol. 55, No. 3, 1032-1044, 2006. [2] Liu, Tao, Panwar "A Cooperative MAC protocol for Wireless local area Networks", in Proc. of IEEE ICC 2005, Seoul, Korea, May
1 non-relay analysis non-relay simulation proposed protocol simulation proposed protocol analysis
0.5 0 4
8
12
16
20
24
28
32
36
16-20, 2005.
40
number of nodes
Fig.4. Throughput v.s. number of stationary nodes
IEEE INFOCOM 2005, Miami, Florida, USA, March 13-17, 2005.
2.3 throughput(Mbps)
[3] Baruch Awerbuch, etc. Effects of Multi-rate in Ad Hoc Wireless Networks[EB/OL] ， www.ends.jhu.edu/research/networks/ archipelago/ publications/Multi-rate Effects-Technical Report. pdf [4] H. Zhu and G. Cao, “rDCF: A Relay-enabled Medium Access Ccontrol Protocol for Wireless Ad Hoc Networks,” in Proc. of
2.2
2.1
2 0
2
4
6
8
10
average velocity of the nodes(m/s)
Fig. 5. Throughput when nodes are moving (20 nodes in the network)
[5] J. M. Shea, T. F. Wong, and W.-H. Wong, "Cooperative Diversity Slotted ALOHA," ACM Wireless Networks, 2006. Invited paper. [6] Amir Khandani, Jinane Abounadi, Eytan Modiano, and Lizhong Zhang, “Cooperative routing in wireless networks,” in Proc. of Allerton Conference on Communications, Control and Computing, Oct. 2003. [7] Yong Xi, Byung-Seo Kim, Ji-bo Wei, Qing-Yan Huang “Adaptive multirate auto rate fallback protocol for IEEE 802.11 WLANS”, in Proc. of MILCOM 2006, Washingto D.C. [8] M. Heusse, F. Rousseau, G. Berger-Sabbatel, and A. Duda, “Performance anomaly of 802.11b,” in Proc. of IEEE INFOCOM 2003, San Francisco, USA, March-April 2003. [9 ]D. Qiao, S. Choi, and K. Shin, “Goodput Analysis and Link Adaptation for IEEE 802.11a Wireless LANs,” IEEE Trans. on Mobile Computing, vol. 1, no. 4, pp. 278–292, OctomberDecember 2002. [10] “Orinoco wireless networks,” www.orinocowireless.com/.
