Analyzing the RTS/CTS Mechanism in the DFWMAC Media Access Protocol for Wireless LANs

Presented at IFIP TC6 Workshop Personal Wireless Comm. April 95 Prague, Czech Rep. Analyzing the RTS/CTS Mechanism in the DFWMAC Media Access Protocol for Wireless LANs Jost Weinmiller*, Hagen Woesner*, Jean-Pierre Ebert*, Adam Wolisz*# * Technical University Berlin, Electrical Engineering Department Einsteinufer 25 10587 Berlin, Germany # GMD Fokus - STEP Hardenbergplatz 2, 10623 Berlin email: [ jost woesner ebert wolisz]@ftsu00.ee.tu-berlin.de Abstract The distributed coordination function that is used as the access scheme for asynchronous traffic within the upcoming standard for wireless LANs IEEE 802.11 optionally applies the RTS/CTS message exchange to solve the hidden terminal scenario. In this paper, following a general discussion of the mechanism and its problems, we show the effectiveness or lack thereof of this mechanism in various cases like hidden terminals and fully meshed, optional (distributed) use of RTS/CTS and the dependencies from various parameters like physical preambles and packet sizes. We conclude this paper with a discussion of the results drawn from the simulations and an outline of problems that have yet to be investigated. 1. Introduction Wireless LANs (WLANs) are expected to be a major growth factor for the network industry in the upcoming years. They will play their part in the network architecture as a provider for easy and unconstrained access to the wired infrastructure - an extension of the wired network with a wireless last link to attach the large number of mobile data communication terminals (from high performance laptops to small communication devices maybe as small as pagers). Especially for such a technology that is calling for mobility of equipment across borders of any kind it is important to provide a well defined i.e. standardized interface between the elements of the architecture to avoid unnecessary limitations of the mobility due to technical interface boundaries. Therefore standardization is currently under work for the IEEE 802.11 1 standard specifying physical layer (PHY) and media access control (MAC) for wireless LANs [1] as well as for the ETSI 2 HIPERLAN [2] standard with the same task. 1. Institute of Electrical and Electronics Engineers, Inc. 2. European Telecommunications Standards Institute

The IEEE 802.11 working group has selected a proposal called DFWMAC 1 as the draft standard. DFWMAC integrates two coordination functions - a point coordination function for synchronous data transmission and a distributed coordination function for asynchronous data. These two modes share the mediums bandwidth in a time multiplexed manner organized in a superframe structure. The distributed coordination function shares access to the medium based on a CSMA/CA scheme that is extended with a RTS/CTS message exchange to improve performance in two aspects. If collisions occur, they occur with smaller packets, therefore the lost piece of bandwidth is smaller compared to a collision of long packets. The main purpose for the integration of the mechanism into DFWMAC however is the solution of the hidden terminal problem: The successful exchange of small messages - RTS (Request To Send) sent by the sender and CTS (Clear To Send) - reserves the area within range of the receiver and the sender for the intended transmission guaranteeing undisturbed media for the longer data packet. According to the draft standard [1] this mechanism is optionally applied whereas the rules of application of this exchange - never used, only used under certain circumstances or constantly used - are set on a per-station-basis. In this paper we present the results of our simulative analysis on the RTS/CTS message exchange, the effects in the hidden terminal case and in the fully meshed case, defining the dependencies and areas of useful application and showing its effects on the overall network performance when its application strategies are not harmonized throughout the network. Section 2 of this paper gives an overview of the hidden terminal scenario in wireless LANs and how this special problem is addressed in DFWMAC, section 3 presents simulations on the RTS/CTS mechanism in the DFWMAC standard and discusses the problems arising from it, section 4 finishes this paper with conclusions and an outlook on further problems that have to be addressed. 2. RTS/CTS operation in DFWMAC Radio networks create a problem due to their specific nature: Carrier sensing is difficult due to the hidden terminal scenario where collisions cannot be securely detected at the sending stations. This scenario is explained in Figure 1: if station B is sending to station C the medium appears used only for the stations located within the range of station B - other stations cannot sense a signal and consider the medium idle. Therefore station D might start a transmission since it does not notice B s ongoing transmission. However since the receiving station C is within range of B and D and thus receives two signals at once it will not be able to clearly understand either of the two transmission (whether destined for it or not). This collision however cannot be detected at the sending station B unless it notices the lacking acknowledgment from station C after a certain time-out. 1. DFWMAC - Distributed Foundation Wireless Medium Access Control RTS/CTS Analysis Page 2

. RTS A B CTS C D = Area of reception for Signals from Station B = Area of reception for Signals from Station C = Area of reception for Signals from Station B and Station C Figure 1:Hidden Terminal Situation To solve this situation the RTS/CTS mechanism, developed in [3] and analyzed in [4], has been integrated in the DFWMAC in the following fashion: Each station seeking access to the medium selects a random slot within the contention window. The station with the earliest slot wins the competition and may start transmitting. Stations with a later slot number hear the other station transmitting and refrain from sending ([1] and [5]). When the RTS/CTS mechanism is applied, the winning station does not send data packets right away but sends a RTS packet to the receiving station, that responds with a CTS packet. If a station captures a RTS packet from another station and it is not the destination of the RTS packet it reads the indended transmission duration from the RTS packet and stays silent for that time (this is done by setting the Network Allocation Vector NAV). The same happens if only a CTS packet is received i.e. by a station outside of the transmission range of the sender but within the range of the receiver. This guarantees that all stations within range of either sender or receiver have knowledge of the transmission as well as of the duration of it. DIFS Source RTS SIFS SIFS DATA DIFS Destination Other Stations CTS NAV (RTS) NAV (CTS) ACK DIFS Contention Window next MPDU Defer Access Figure 2:RTS/CTS mechanism Backoff after Defer RTS/CTS Analysis Page 3

To sum up the effects of the RTS/CTS mechanism, we can say, that it increases bandwidth efficiency by its reduced collision probability since the ongoing transmission has been made known everywhere within the range of it increases bandwidth efficiency since if collisions occur they do not occur with the long data packets but with the relative small control packets decreases bandwidth efficiency since it transmits two additional packets without any payload decreases bandwidth efficiency since it reserves geographical space for its transmission where or when it might actually not need it. Due to the above listed trade-offs of the RTS/CTS mechanism, the DFWMAC draft standard allows its usage but does not demand it. Usage policy is set on a per-station-basis with the help of a manageable object RTS_Threshold that indicates the payload length under which the data frames should be sent without the RTS/CTS prefix. This parameter is not fixed in the draft standard and has to be set seperatly by each station. The packet size is the only parameter that is used to decide whether the mechanism is applied, however we will show in the simulations presented below, that there are several more factors relevant to guarantee efficiency gain. We identified the following elements: configuration and geometry and the physical preamble length, but there might be further dependencies. 3. Discussing the RTS/CTS Mechanism in DFWMAC In order to analyze the behavior of the DFWMAC we simulated a possible network cell. We chose Ptolemy [6] as our simulation tool for several reasons: its an object oriented general purpose simulation tool with many connectable simulation environments (discrete event, synchronous data flow, concurrent processes) for several different simulation types. It allows simple modelling, has a rich library and a big number of users, allowing exchange of experience over a dedicated newsgroup. We simulated a WLAN consisting of 8 stations using DFWMAC s distributed coordination function as the access scheme with a raw physical throughput of 2 Mbit/s. The channel and packet source model is basically the same as it is described in [7], i.e. Poisson distributed packet sources in a wireless channel model. In addition to that we simulated the signal run time, which can be left out if one only considers a range of a microcell, but which becomes considerable at distances of 300 m and more. Several parameters had to be set to a certain value for our simulations since they are not (yet) defined in the draft standard: The contention window size was set to 32 slots, lasting 4µs each, the physical preamble was set to 30 bytes unless other values are explicitly mentioned, 16 RTS packets transmission attempts with missing CTS response and 4 data packet transmissions with missing acknowledgment response are sent out before the transmission is cancelled and the packet is dropped. RTS/CTS Analysis Page 4

Originally, the RTS/CTS mechanism was introduced to solve the hidden terminal problem. In result our first simulations intended to show the positive effect of this mechanism in this case. In further simulations we evaluated the use of RTS/CTS in a fully meshed network (i.e. without hidden terminals) and special values for certain parameters. 3.1. RTS/CTS in the hidden terminal scenario To show the effect of the RTS/CTS mechanism, we simulated the following scenario: There are 8 stations in a cell, where station 1 is hidden to stations 2 and 3, respectively. All of the outer stations (1,2 and 3) try to send data to the inner, i.e. audible to all, stations. The destinations of data traffic are shown in Figure 3. Meter 90.00 2 5 70.00 3 4 50.00 6 1 30.00 7 8 100 200 300 Figure 3:Map of the stations in the hidden terminal simulation Meter The result of these simulations was that using the RTS/CTS does not completely solve the hidden terminal problem, even though significant improvements can be achieved. The breakdown of inbound data traffic in the case of higher load stems from the fact that the mutually hidden stations become synchronized by an earlier data exchange in the area between them. In result, they start their backoff counters at the same time but they are unable to detect the begin of transmission of the other station. Figure 4 shows the through- RTS/CTS Analysis Page 5

put achieved by the different stations when RTS/CTS is permanently switched off. The relevant differences are clearly visible in the higher load range. The stations that are hidden to other stations hardly get any packets through due to the above mentioned synchronization effect. The stations that attempt to send towards the hidden stations have significantly lower throughput than the two stations 5 and 7 that only send to non-hidden stations. The first group successfully gets packets through, however many acknowledgment packets are destroyed by traffic from the hidden stations. Throughput per station in % stations 5,7 stations 4,6 station 8 stations 1,2,3 Offered Load per station in % Figure 4:Throughput per Station, Hidden Terminals, RTS/CTS off Figure 5 shows the same setup when RTS/CTS is permanently used. This figure shows clearly that still the hidden terminal scenario is not solved: Station 1 still hardly gets any packets through, but its throughput is improved compared to the figure without RTS/ CTS. The same goes for stations 2 and 3 - all of the hidden stations benefit from the captured CTS packets. The non-hidden terminals all achieve the same (high) throughput due to the fact that outbound traffic is protected by the RTS packets. RTS/CTS Analysis Page 6

Throughput per station in % all other stations stations 2,3 station 1 Offered Load per station in % Figure 5:Throughput per station, Hidden Terminals, RTS/CTS on 3.2. RTS/CTS in a fully meshed network In the above paragraph we showed the performance gain that can be achieved by applying the RTS/CTS mechanism in the case with hidden terminals. For the fully meshed case we followed several different goals in our simulations: we showed that there are situations where application of the mechanism has significant positive effects as well as there are situations with significant negative effects thus proving that there cannot be an overall same strategy on the usage policy we then tried to analyze the relevant factors that determine the efficiency of the mechanism under fixed non-extreme circumstances we defined a range of values for useful application of RTS/CTS (RTS_Threshold parameter) we investigated asymmetric usage policies of the mechanism. Our first two simulations were meant to show extreme situations, one resulting in significant negative effect in using RTS/CTS, one resulting in significant negative effects RTS/CTS Analysis Page 7

when NOT using it, both compared to a realistic scenario. The first situation was determined by a short packet length of only 64 byte payload, while the PHY preamble was set to 30 bytes. Since observations of Ethernet traffic show that a very large number of packets is shorter than 100 byte, this situation can actually be considered realistic. Both figures show decreasing performance - lower throughput and higher access delay due to the higher overhead of the RTS/CTS extension. Throughput per station in % Not using RTS/CTS Using RTS/CTS Offered Load in % Figure 6:Negative effect on throughput, if packet size is small Access Delay in ms Using RTS/CTS 7.00 5.00 Not using RTS/CTS 0.00 50.00 100.00 150.00 200.00 Offered Load in % Figure 7:Negative effect on access delay, if packet size is small RTS/CTS Analysis Page 8

For the following simulations we used packet sizes from an Ethernet trace (Leland trace, [8]) i.e. packet sizes are distributed as in real ethernet traffic with an average packet size of 682 byte. It shows that using the RTS/CTS mechanism permanently in this case is significantly better than not using it. Throughput in Kbyte/s Using RTS/CTS Not using RTS/CTS Offered Load in % Figure 8:Positive effect on throughput, if packet size is larger (mean=682 byte) Access Delay in ms Not using RTS/CTS Using RTS/CTS Offered Load in % 150.00 300.00 450.00 Figure 9:Positive effect on access delay, if packet size is larger (mean=682 byte) RTS/CTS Analysis Page 9

In the same scenario as above we determined the gain or loss of throughput and delay versus load, if RTS/CTS is used, depending on the packet size. Since the packet size on the wireless channel consists of the MAC-layer packet size and the physical layers preamble the length of this latter part has to be taken into account when determining the RTS_Threshold parameter. Our simulations gave larger best values for RTS_Treshold for larger physical preambles. Since this physical preamble has different lengths depending on the channel used - for the defined physical layers in the 802.11 specification those values are 128 bits with a variable number of stuff bits for 2.4GHz FHSS 1 channel, 192 bits for the 2.4GHz DSSS 2 channel and between 96 and 112 slots of 250ns length plus 32 bits for the baseband infrared channel - therefore this value has to be taken into account when configuring the RTS_Threshold parameter. This gets even more difficult in the case of the 2.4GHz FHSS channel as well as for the infrared channel, where no fixed length is added but a variable number of bits. Total throughput in % RTS/CTS on RTS/CTS off Offered Load in % Figure 10:Throughput vs. Load, PHY_preamble=0 If we assume the physical preamble to be non-existent we get the highest total throughput for RTS_threshold=64, i.e. RTS/CTS is switched on permanently since no packets are smaller than 64 bytes. 1. FHSS - Frequency Hopping Spread Spectrum 2. DSSS - Direct Sequence Spread Spectrum RTS/CTS Analysis Page 10

Total throughput in % RTS_threshold =256 RTS/CTS on RTS/CTS off Figure 11:Throughput vs. Load, PHY_preamble=30 bytes For a physical preamble length of 30 bytes, we achieve best results for RTS_threshold around 256 bytes. Total throughput in % Offered Load in % RTS/CTS off RTS_threshold=1024 RTS/CTS on Figure 12:Throughput vs. Load, PHY_preamble=100 bytes Offered Load in % RTS/CTS Analysis Page 11

For the extreme (and slightly unrealistic) case of the PHY_preamble having 100 bytes we get optimal values for RTS_threshold around 512 bytes. Summing up we can say that for the proposed PHY_preamble sizes of the draft standard we recommend, based on our simulations, a value of around 200 byte MPDU size for the RTS_threshold. This of course depends on the source model of our simulations. Since traffic on a wireless network can be expected similar to Ethernet traffic we consider our applied source model to be reasonable. The use of RTS/CTS in the DFWMAC draft standard is managed on a per-station basis. This can result in asymmetric configurations in the network, e.g. one station does never use the mechanism, all the others do. We simulated some of those asymmetric configurations to determine whether the stations behaving different than the rest might win performance at the cost of the others, whether they will loose or whether they will cause degradation of the overall network performance. It showed that there is no individual gain for a station which does for some reason not behave like the others, but that there is a small decrease in the overall performance Total throughput per group in % using RTS/CTS The strategy based on setting a fixed value for RTS_Threshold obviously does not optimize the optional use of the mechanism. We will experiment with a different approach trying to design it as a load adaptive scheme: Considering the fact that under low load connot using RTS/CTS Figure 13:Throughput vs. Load 4 Stations use RTS/CTS, 4 Stations don t 4. Conclusions % Offered Load per group RTS/CTS Analysis Page 12

dition in the network the few collisions caused by the hidden terminal scenario do not harm the overall performance as much as under high load condition, it seems to be reasonable only to use RTS/CTS when load is high. However it is not trivial to get the knowledge about current load to the stations. One thinkable switch-on criteria could be an experienced collision: once a data packet collided the next attempt would have to be preceded by a RTS/CTS exchange (possibly this step to more secure transmission should only take place after two or more collided attempts). This strategy however leaves it open when the station should switch back to non-rts/cts mode - after each successful transmission of a data packet, after a certain silence period, after a certain time period or other. As we have shown several factors have significant influence on the efficiency with which the RTS/CTS mechanism can be applied in the context of DFWMAC. At current standing we cannot advise for or against its use. This is especially true considering further uncertainties e.g.what happens if PCF is also used, i.e. DCF is only partly active? what happens if considerably different signal strength levels are sent out from different stations (e.g. when the battery power is low in one station) and therefore the station can hear all stations but is not heard by all of them? Another topic for further work could be the exploitation of the hidden terminal scenario - since the collision can only occur at the receiving side of the communication it is not necessary to reserve space around the sending side. A station only hearing the RTS packet and the data packets but not the CTS packet can assume, that it is out of range of the receiving station and thus not disturbing the ongoing communication. It could therefore start communication with another station if that station is able to receive the signal as well undisturbed by the other ongoing communication. These problems will be the subject for our future activities in this area. References [1] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Draft Standard IEEE 802.11, P802.11/D1; The editors of IEEE 802.11 [2] HIPERLAN Functional Specification Section 6 MAC Layer, Draft Version 0.6, ETSI Secretariat, December 1994 [3] MACA - A new Channel Access Method for Packet Radio, P. Karn, ARRL/CRRL Amateur Radio 9th Computer Networking Conference, Sept. 22 1990 [4] MACAW: A Media Access Protocol for Wireless LAN s; Bharghavan V., Demers A., Shenker S., Zhang L., SIGCOM 94; http://beta.xerox.com/pub/net-research/ macaw-cr.ps [5] Modified Backoff Algorithms for DFWMAC`s Distributed Coordination Function; Woesner H., Weinmiller J., Ebert J-P., Wolisz A.; submitted to 2. ITG-Fachtagung RTS/CTS Analysis Page 13

Mobile Kommunikation 95; http://ftsu10.ee.tu-berlin.de/bibl/ours/backoff- ITG.ps.Z [6] PTOLEMY, anonymous ftp site: ftp.ptolemy.eecs.berkeley.edu, www: http:// ptolemy.eecs.berkeley.edu, Copyright 1990-1995 The Regents of the University of California [7] A Wireless MAC Protocol comparison, W. Diepstraten; IEEE 802.11 working paper P802.11-92/51, May 1992 [8] W. Leland et al.: On the Self-similar nature of Ethernet traffic (extended version), IEEE Transactions on Networking, Vol 2, No 1, Feb 1994 RTS/CTS Analysis Page 14