Improving WLAN Performance with RTS/CTS

By Jim Geier

August 13, 2002

Learn how the optional Request to Send/Clear to Send function of 802.11 operates, and understand when and why you should use it.

As an optional feature, the 802.11 standard includes the RTS/CTS (Request to Send/Clear to Send) function to control station access to the medium. Generally only the more costly, high-end wireless LANs offer RTS/CTS in radio network interface cards (NICs) and access points — you won’t find this on inexpensive home or SOHO products. Through the proper use of RTS/CTS, you can fine-tune the operation of your wireless LAN depending on the operating environment.

RTS/CTS in action

If you enable RTS/CTS on a particular station, it will refrain from sending a data frame until the station completes a RTS/CTS handshake with another station, such as an access point. A station initiates the process by sending a RTS frame. The access point receives the RTS and responds with a CTS frame. The station must receive a CTS frame before sending the data frame. The CTS also contains a time value that alerts other stations to hold off from accessing the medium while the station initiating the RTS transmits its data.

The RTS/CTS handshaking provides positive control over the use of the shared medium. The primary reason for implementing RTS/CTS is to minimize collisions among hidden stations. This occurs when users and access points are spread out throughout the facility and you’re finding a relatively high number of retransmissions occurring on the wireless LAN.

Imagine there are two 802.11 end users (Station A and Station B) and one access point. Station A and Station B can’t hear each other because of high attenuation (e.g., substantial range), but they can both communicate with the same access point. Because of this situation, Station A may begin sending a frame without noticing that Station B is currently transmitting (or vice versa). This will very likely cause a collision between Station A and Station B to occur at the access point. As a result, both Station A and Station B would need to retransmit their respective packets, which results in higher overhead and lower throughput.

If either Station A or Station B activates RTS/CTS, however, the collision will not happen. Before transmitting, Station B would send a RTS and receive a CTS from the access point. The timing value in the CTS (which Station A also receives) will cause Station A to hold off long enough for Station B to transmit the frame. Thus, the use of RTS/CTS reduces collisions and increases the performance of the network if hidden stations are present.

Keep in mind, though, that an increase in performance using RTS/CTS is the net result of introducing overhead (i.e., RTS/CTS frames) and reducing overhead (i.e., fewer retransmissions). If you don’t have any hidden nodes, then the use of RTS/CTS will only increase the amount of overhead, which reduces throughput. A slight hidden node problem may also result in performance degradation if you implement RTS/CTS. In this case, the additional RTS/CTS frames cost more in terms of overhead than what you gain by reducing retransmissions. Thus, be careful when implementing RTS/CTS.

RTS/CTS implementation tips

One of the best ways to determine if you should activate RTS/CTS is to monitor the wireless LAN for collisions. If you find a large number of collisions and the users are relatively far apart and likely out of range, then try enabling RTS/CTS on the applicable user wireless NICs. You can activate the function by clicking “enable RTS/CTS” somewhere in the user setup screens. You don’t need to enable RTS/CTS at the access point in this case. After receiving a RTS frame from a user’s radio NIC, the access point will always respond with a CTS frame.

Of course, keep in mind that user mobility can change the results. A highly mobile user may be hidden for a short period of time, perhaps when you perform the testing, then be closer to other stations most of the time. If collisions are occurring between users within range of each other, the problem may be the result of high network utilization or possibly RF interference.

After activating RTS/CTS, test to determine if the number of collisions is less and the resulting throughput is better. Because RTS/CTS introduces overhead, you should shut it off if you find a drop in throughput, even if you have fewer collisions. After all, the goal is to improve performance.

The method for enabling RTS/CTS on access points is different than with NICs. For access points, you enable RTS/CTS by setting a specific packet size threshold (0 — 2347 bytes) in the user configuration interface. If the packet that the access point is transmitting is larger than the threshold, it will initiate the RTS/CTS function. If the packet size is equal to or less than the threshold, the access point will not kick off RTS/CTS. Most vendors recommend using a threshold of around 500. The use of 2347 bytes effectively disables RTS/CTS for the access point.

In most cases, initiating RTS/CTS in the access point is fruitless because the hidden station problem doesn’t exist from the perspective of the access point. All stations having valid associations are within range and not hidden from the access point. Forcing the access point to implement the RTS/CTS handshake will significantly increase the overhead and reduce throughput. Focus on using RTS/CTS in the NICs to improve performance.

Author
Recent Posts

Eric Sandler

Chief Writer at WiFi Planet

Eric Sandler is a veteran US tech writer with over 25 years of experience covering the latest advancements in the world of technology. From groundbreaking innovations to in-depth reviews, Eric has built a reputation for delivering insightful, reliable content. His work spans across a variety of tech topics, including smartphones, gadgets, AI, and more, making him a trusted voice in the industry.