RTS (Request to Send) & CTS (Clear to Send) frames are used to enhance the virtual carrier sense process. It is possible for a client station to be able to communicate with a AP, but not able to hear or be heard by any of the other client stations. This will lead to possible collisions when a station transmits.
RTS/CTS is a mechanism that performs NAV distribution & helps to prevent collisions from occurring. So when RTS/CTS is enabled on a STA, every time STA want to transmit a frame, it must perform RTS/CTS exchange prior to the normal data transmission. I have used below topology to see the RTS/CTS behavior.
If you capture wireless frames on CH149, you will see something similar to below & you can clearly see the STA send RTS & then wait for CTS prior to any data transmission.
Here is the frame format of a RTS farme. It is 20 byte in length. Frame type is “Control or value 1” & subtype is “RTS or value 11“. Duration value of RTS frame include the time needed for the subsequent frames in the transmit operation to be transmitted.
Here is the RTS frame capture. Note that it is 20 byte long Control Frame with subtype 11 (ie RTS). TA is the iPhone5 mac address (04:F7:E4:EA:5B:66) where as RA is the BSSID(1C:6A:7A:BC:4D:6E). Duration set to 124 μS which is the estimated time require to transmit the data frame which includes time for CTS & ACK as well (includes SIFS as well)
When the RTS received by the AP, it will respond with CTS after SIFS & if the medium is idle, to indicate client that he can transmit the data frame. When a STA in the BSS could not hear the original RTS, they may hear the CTS & then adjust their NAV to the duration set in CTS frame. Here is the frame format of a CTS frame.
CTS is a 14 byte long control frame. Subtype is 12 in this case. It simply get the TA of the RTS frame & set it to RA. Duration of the CTS frame is the duration field of RTS, adjusted by subtraction of aSIFS & time required to transmit the CTS frame.
Here is the frame capture of CTS frame. In this case duration is set to 80μS ( 124-44, indicate CTS frame require 44μS ). RA set to iPhoe5 mac address.
Once client get the CTS, he will transmit the Data frame. In this frame duration set to time required to ACK + aSIFS. In my case it is a DNS frame destined to a DNS server in wired side. Destination MAC address is the gateway MAC of the wireless client (Cisco HSRP address 00:00:0C:07:AC:8E in my case).nHere is the data frame captured.
Here is the Acknowledgement frame send to the client (iPhone5) to confirming the data frame received by AP. ACK is 14 byte long frame & duration always set to 0.
Below diagram (figure 9.4 IEEE-802.11-2012 std )summarize the RTS/CTS frame exchange & how each of them duration value is calculated.
RTS duration = SIFS + CTS + SIFS + Data + SIFS + ACK
CTS duration = SIFS + Data + SIFS + ACK
If a data frame is a fragmented MSDU or MMPDU then the Duration/ID field of a data and ACK frames specifies the total duration of the next fragment and acknowledgment as shown below.
In 802.11n where BlockAck is used, a client can send multiple frames before that block of data frames get BlockAck as shown below.
In this case RTS & CTS frame set its duration value to accommodate time required for all these frames.
CTS-to-Self
CTS-to-Self is simply another method of performing NAV distribution & that use only CTS frames. It is used strictly as protection mechanism for mixed mode environment. The CTS-to-self NAV distribution mechanism is lower in network overhead cost than is the RTS/CTS NAV distribution mechanism, but CTS-to-self is less robust against hidden nodes and collisions than RTS/CTS. CTS-to-Self duration value is calculated as shown below (page 194- CWAP study guide).
STAs employing a NAV distribution mechanism should choose a mechanism such as CTS-to-self or RTS/CTS that is appropriate for the given network conditions. If errors occur when employing the CTS-to-self mechanism, STAs should switch to a more robust mechanism.
Reference
1. CWAP Official Study Guide – Chapter 5
mrn-cciew 
What tools you have used for results of wireless frames capturing and analyzing you showed above? thanks
Hi Russell,
I used omnipeek (now called Savvius)
https://www.savvius.com/
HTH
Rasika
Hi, i am reading the CWNA book and probably i haven’t read that part yet, but i want to know if RTS/CTS is purely a protection mechanism for mixed environments or if in a pure 802.11g environment or lets say a 802.11a environment it will also be used. I am asking because i was watching a video tutorial where it was told that ALWAYS a STA have to send a RTS/CTS.
Hi, i am reading the CWNA book and probably i haven’t reached to that part yet, but i would like to ask if RTS/CTS is only a protection mechanism used to be backward compatible or if it is used in a a pure 802.11g network. I am asking because i am also watching a CBT where they told RTS/CTS is needed before every frame was transmitted regardless if protection was used or not.
Pingback: Client Induced Co-Channel Interference – 802.11du
Hi Rasik,
Hope you are doing well.
Have a doubt in the RTS/CTS mechanism. What is the rate do RTS being sent.
and what are the rate mandatory for it. I knew that its depends on the Data Rates .
Can you clarify this. I didn’t found regarding this Rate of RTS/CTS.
Thanks,
Pradipta
RTS and CTS frames are basically sent @ basic data rates so that all the listening stations can read the Duration value from these frames and adjust their NAV timer
Yes, that is true. It provide protection mechanism in a BSS whre legacy & 11n,11ac STA coexist.
Rasika
hi Rasik!!
how do I get the size of the package or the enio time of the package requested by the frame how do I get the frame data ???
thank you!!
Hi Rasika , I have been following the your blog from long time and you are really putting good effort to share your knowledge thanks for that .
I have a doubt regarding this topic , I read in book , Listening stations NAV timers are updated after hearing RTS/CTS frames . But here one condition is there , NAV timer is updated only when the Duration value > Present NAV else it is ignored , what if Duration value < Present NAV ?
Idea of NAV (Virtual Carrier Sense) is to adjust its value based on the duration value of active frame communication. If Duration value of current trasnmission frame is higher than NAV value, that station will update NAV to that value, so it will not declare medium is free until current trasnmission process finishes.
If a STA already has a NAV value higher that duration value of current transmit frame, then it imply even after current transmission process is over that STA NAV is not become 0. So there is no risk of declaring medium is free falsely. When there is next transmission occur, it may get higher duration compare to that STA NAV and that time it may update.
So short answer is if Duraation value is less than present NAV then it will not set NAV.
HTH
Rasika
Hi Rasika ,
While I am reading CWNA book , I came across a point , it states that “When client using SM Power save dynamic mode , AP sends RTS frame to client to wake up its all radios to receive multiple streams of data ”
Does AP sends RTS frames to any Wi-Fi Devices in any case ?
Hi Rasika,
I have some basic questions related to enabling RTS/CTS.
Which AP or Station capability decides whether the RTS/CTS supported?
From the Wireshark capture, how can we confirm that the RTS/CTS mechanism is enabled or not?
Thanks,
Raviraj
If you take a packet capture, you should see RTS/CTS frames before data frame transmitted. You do not want to enable it specifically… It is the protection mechansim used for co-existance in 11n/11ac..
HTH
Rasika
How to view rts threshold value in wireshark ?