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
Related Posts
