RTS/CTS: The Hidden Node Problems in WiFi Networks



In the world of wireless networking, collision avoidance is a critical challenge. Unlike wired networks where collisions can be detected, wireless networks must employ mechanisms to prevent collisions before they happen. One of the most important mechanisms in IEEE 802.11 (WiFi) networks is the Request to Send/Clear to Send (RTS/CTS) protocol. Let's dive into how this solution works and why it's essential for efficient wireless communications.

The Hidden Node Problem

Before understanding RTS/CTS, we need to understand the problem it solves: the hidden node problem.

Imagine three wireless stations (STAs) - A, B, and C. Station-B can communicate with both A and C, but A and C are out of range of each other. If station A is transmitting to B, station C has no way of knowing this and might also try to transmit to B simultaneously, causing a collision at B. This is the "hidden node" problem - where some nodes in a network are invisible to each other but can still interfere with each other's transmissions.


RTS/CTS

The RTS/CTS mechanism is a virtual carrier-sensing protocol that addresses this issue. It's a handshake process that occurs before the actual data transmission, letting all nearby stations know about an upcoming transmission and how long it will take.

The RTS Frame

The Request to Send (RTS) frame is 20 bytes long and contains several important fields:

  • Frame Control (2 bytes): Identifies this as an RTS control frame
  • Duration/ID (2 bytes): Contains timing information crucial for the Network Allocation Vector (NAV)
  • RA (6 bytes): Receiver Address - identifies the intended recipient
  • TA (6 bytes): Transmitter Address - identifies the source
  • FCS (4 bytes): Frame Check Sequence for error detection

The purpose of the RTS frame is to announce the sender's intention to transmit data and to share duration information with all stations in the coverage area. The duration represents the total time needed for the complete four-way handshake (RTS-CTS-Data-ACK) including the three SIFS (Short Interframe Space) intervals between these frames.


Wireshark Filter: wlan.fc.type_subtype == 27



CTS Frame

Upon receiving an RTS frame, the intended recipient responds with a Clear to Send (CTS) frame. This frame is 14 bytes long and contains:

  • Frame Control (2 bytes): Identifies this as a CTS control frame
  • Duration/ID (2 bytes): Timing information
  • RA (6 bytes): Receiver Address - This is the Transmitter address of the RTS Frame
  • FCS (4 bytes): Frame Check Sequence

The CTS frame is broadcast to all stations within range, including those that might not have heard the original RTS. The duration value in the CTS frame is calculated by subtracting one SIFS interval and the transmission time of the CTS frame from the duration value received in the RTS frame.

Wireshark Filter: wlan.fc.type_subtype == 28


The 4-Way Handshake

Together, RTS and CTS form the first half of what's known as the 4-Way Handshake:

  1. RTS: The transmitter sends an RTS frame to the receiver (Frame 1)
  2. CTS: The receiver responds with a CTS frame (Frame 2)
  3. Data: The transmitter sends the actual data or management frame
  4. ACK: The receiver acknowledges receipt of the data

How does the NAV Protection Mechanism help?

The key to collision avoidance is the Network Allocation Vector (NAV). When stations receive either an RTS or CTS frame, they update their NAV based on the duration field. This essentially sets a timer during which they will not attempt to transmit, even if they sense the medium is idle. This "virtual carrier sensing" mechanism ensures that all stations, even those that can only hear either the transmitter or the receiver (but not both), defer their transmissions.

Real-World Implications 

In practice, RTS/CTS is particularly valuable in deployments such as:

  • High-density environments: Office buildings, conference centers, stadiums
  • Large coverage areas: Where hidden nodes are more likely such as Warehouses. 
  • Applications sensitive to latency: VoIP, video conferencing, Video Camera's streaming etc.

Comments

Post a Comment

Popular posts from this blog

Understanding RSSI and LQI Metrics of IOT

Image
 In the rapidly increasing adaption of Internet of Things (IoT), understanding  the basics network performance metrics is crucial for building reliable and efficient systems. Two fundamental metrics that play a n important role in the IOT Device communication are the Received Signal Strength Indicator (RSSI) and Link Quality Indication (LQI). Let's dive deep into what these metrics mean and why they matter for IoT implementations. Received Signal Strength Indicator (RSSI) RSSI serves as a fundamental measurement of RF power received by a wireless device. What makes RSSI particularly interesting is that it measures all RF power in a channel, regardless of the source. This means it captures: Signals from IEEE802.15.4 transmitters Interference from Bluetooth devices WiFi signals Background radiations This comprehensive measurement makes RSSI an essential tool for Clear Channel Assessment (CCA), helping devices determine if a channel is free befo...
Read more

Understanding "Invalid FTE" Error with 802.11r Roaming

Image
 When investigating Fast Transition (FT) roaming issues in enterprise wireless networks, packet captures often hold the key to diagnosis. Let's analyze this specific roaming failure case where a client fails to roam from one access point to another. Problem Statement: Random Devices are facing FT roaming issue and requires reauthentication.  While the problem statement sounds easy, capturing roaming failures could be challenging when the problem is random/intermittent. It is also important to know where to capture; Remember CWAP Guidelines? For roaming we need to capture near multiple AP's.  In this case we used RUCKUS AP Remote PCAP feature to stream captures from multiple AP's to the Wireshark and Voila! We were lucky to capture the failure  use case.  Now lets see what does it look like: The packet captures shows us an "Invalid FTE (0x0037)" error. FTE stands for Fast Transition Element, a critical component of the 802.11r protocol that facilitates seaml...
Read more

Association Failures with Legacy Printers due to Management Frame Protection- A Technical Analysis

Image
 Let's understand first, what is Management Frame Protection? Based on the IEEE 802.11w amendment, Protected Management Frames (PMF), also known as Management Frame Protection (MFP), is a security feature that provides integrity protection for both unicast and broadcast management frames, while also encrypting unicast management frames in the same way as data to provide confidentiality. Without the Protected Management Frames feature, all management frames are sent unprotected in the open. Transmitting open frames makes connections vulnerable to attack. To leverage Protected Management Frames, both the AP and the STA need to be capable of using it, and it must be activated for each encrypted Wi-Fi network of the AP. If those conditions are met, Protected Management Frames are automatically invoked during client association. Understanding Management Frame Protection Failures MFP is one of the common challenge when working with legacy devices in modern wireless networks. My recent t...
Read more