RTS/CTS is often taught as a solution to the hidden-node problem. That is still true, but it is only one part of what these control frames do in a modern Wi-Fi network.
In Wi-Fi 5, Wi-Fi 6, and Wi-Fi 7, the same basic idea also helps protect wide channels, coordinate multi-user exchanges, and reduce the risk around expensive transmissions.
The important thing is not simply that an RTS or CTS appears in a capture. It is understanding what that exchange is protecting.
RTS/CTS reserves time on the medium
The original exchange is straightforward. A sender transmits an RTS, the receiver answers with a CTS, and the data exchange follows.
Both control frames carry a Duration value. Stations that hear them use that value to update their Network Allocation Vector, or NAV, and remain silent for the reserved period. This is virtual carrier sensing: the stations do not need to decode the protected data transmission to know that the medium has already been claimed.
The CTS matters because it can reach stations that heard the receiver but could not hear the original sender. That is how the exchange addresses the classic hidden-node case.
Modern protection mechanisms keep reusing this principle: send a control frame that more stations can understand, reserve the required airtime, and then transmit something more complex.
MU-RTS protects a multi-user TXOP
Wi-Fi 6 defines the MU-RTS Trigger frame. It lets an AP solicit CTS responses from multiple non-AP stations before a multi-user transmission opportunity.
The purpose is protection. The AP identifies the participating stations and the bandwidth on which it expects their CTS responses. Those responses are transmitted using a legacy format so other stations can detect the reservation and set their NAV.
This is easy to confuse with a Basic Trigger frame. A Basic Trigger schedules the HE trigger-based uplink data transmission and assigns RUs for that data. An MU-RTS Trigger prepares and protects the TXOP before those multi-user exchanges take place.
In other words, MU-RTS does not replace OFDMA scheduling. It protects the airtime in which that scheduling will be used.
In practice, you may not see MU-RTS at all, even in a busy Wi-Fi network. It is optional, and its use depends on the AP vendor, firmware, client mix, radio conditions, and scheduling logic. Many APs can schedule trigger-based uplink transmissions with Basic Trigger frames without first sending MU-RTS.
If you do not see MU-RTS in a capture, that absence does not prove that OFDMA is inactive. It only tells you that the AP is not using this particular protection mechanism.
Non-HT duplicate frames protect wide channels
A station operating on only one 20 MHz channel cannot interpret every wideband transmission that occupies 40, 80, 160, or 320 MHz. Protection therefore has to be visible on each relevant 20 MHz segment.
With a non-HT duplicate transmission, the same legacy-format control frame is duplicated across the component 20 MHz channels. A neighbouring station listening on one of those segments can decode the frame, read its Duration value, and defer.
This is why an RTS or CTS can appear across a wide channel immediately before a VHT, HE, or EHT transmission. The small control exchange is reserving the wider piece of spectrum that the following transmission needs.
In dynamic-bandwidth operation, the CTS response can also indicate that only a narrower portion of the requested channel is available. The data transmission can then proceed on that available bandwidth instead of treating the entire wide channel as one indivisible resource.
Protection changes with cost and overhead
RTS/CTS always adds airtime. The exchange is useful only when the transmission it protects is worth more than that overhead.
RTS/CTS is selective, not constant
Most Wi-Fi transmissions do not use an RTS/CTS exchange. In a healthy network, a station usually contends for the medium, sends its data, and receives an ACK or Block Ack. RTS/CTS is added when the transmitter considers the collision risk or transmission cost high enough to justify the extra airtime. That decision can depend on configured thresholds, frame size, retries, channel width, hidden nodes, and vendor-specific logic. MU-RTS is similarly optional and does not precede every multi-user exchange. As a result, conventional RTS/CTS may appear only occasionally in modern captures, while its frequency can rise sharply in a congested or poorly performing network.
As an example, here is a capture I have done during a busy presentation (so in a congested environment), showing that RTS/CTS frames were consuming about 10% of the airtime on average:
Large A-MPDUs raise the cost of a collision
Modern Wi-Fi can place many MPDUs into one aggregate. When that transmission is large, losing the entire attempt is more expensive than losing a small frame.
This gives vendors a reason to use RTS/CTS around large or repeatedly unsuccessful transmissions. A configured RTS threshold can influence that behaviour, but the exact decision is implementation-specific. Aggregation, rate control, retries, and firmware logic can all affect when an RTS appears.
For that reason, an RTS before an A-MPDU does not automatically prove that the aggregate crossed one universal size threshold. It tells you that the transmitter chose to protect that attempt.
CTS-to-self trades coverage for lower overhead
CTS-to-self removes the first half of the handshake. A station sends a CTS addressed to itself, then uses the reserved period for the transmission that follows.
Stations that hear the CTS set their NAV, and the sender avoids the airtime required for a separate RTS. The trade-off is that CTS-to-self does not solve the hidden-node problem as completely: a station that cannot hear the transmitter will not hear its CTS-to-self either.
This makes CTS-to-self a lighter protection mechanism, not a shorter version of every RTS/CTS behaviour.
What to look for in a packet capture
The first question I ask is not, “Why is RTS/CTS enabled?” It is, “What happens immediately after this control exchange?”
- RTS and CTS: Use
wlan.fc.type_subtype == 27 || wlan.fc.type_subtype == 28. Compare the Duration fields with the data and acknowledgement sequence that follows. - MU-RTS: Use
wlan.fc.type_subtype == 0x0012 && wlan.trigger.he.trigger_type == 3. Inspect the Trigger frame, the participating stations, the response bandwidth, and the CTS frames that follow. - Wide-channel protection: Check the radiotap or PHY information for non-HT duplicate transmission across the component 20 MHz channels. A capture taken on only one 20 MHz segment cannot show the complete wide-channel behaviour.
- Protected aggregates: Follow an RTS/CTS exchange into the QoS Data and Block Ack frames. Look at the sequence as one protected transaction rather than treating each frame in isolation.
- CTS-to-self: Start with
wlan.fc.type_subtype == 28, then inspect the sequence. A likely CTS-to-self has no corresponding RTS immediately before it, its Receiver Address belongs to the station that transmits the protected frame next, and that transmission follows after SIFS.
RTS/CTS is no longer one mechanism with one purpose. The frame names stayed familiar while the behaviours around them expanded with wider channels, larger aggregates, and multi-user transmission.
Once you follow the sequence rather than filtering on one frame, the reason for the protection usually becomes visible.
Resources
These references are useful when you want to inspect the frame fields in more detail.
- The 802.11ax Trigger Frame explains the Common Info and User Info fields in a Trigger frame and provides Wireshark filters for exploring them. Start here if MU-RTS is new to you.
- IEEE 802.11ax: The Sixth Generation of Wi-Fi places MU-RTS/CTS within the larger 802.11ax protection model. It is useful for understanding why simultaneous CTS responses exist and what they protect.
- Wireshark Display Filter Reference: IEEE 802.11 wireless LAN is the definitive field reference when a filter name changes or you need to inspect a less familiar part of the frame.