NAV is a virtual carrier sensing mechanism. What does this mean ? I assume that you know what 'Carrier Sensing' mean. Carrier Sensing is a process that a WLAN station physically measure(sense) the energy level in a medium (channel) to figure out whether there is any communication already being done by other stations (Refer to CSMA/CA). In real CSCM/CA process, the station perform physical measurement to figure out whether the channel is available or not.
However there is a case where a station can figure out the availability of channel without performing the physical measurement.
How ?
- How does the Duration field set the NAV ?
- How do RTS and CTS set the NAV of the other stations ?
- How long is the NAV that each frame sets ?
- Reference
How does the Duration field set the NAV ?
Some of WLAN MAC Frame carries(e.g, RTS, CTS, ACK) the field called 'Duration'. If a station decode these frame and extract Duration field, it can figure out when the channel will be available without performing any physical measurement. Once it decoded this 'Duration' info, the station store the information into the internal configuration field so that it does not try carrier sensing for that period.
Simply put, NAV is a period during which a station should not transmit anything.
The NAV works like a counter. When a station decodes a Duration value, it loads the counter with that value, and the counter counts down to zero at a fixed rate. While the counter is not zero, the virtual carrier sense reports the medium as busy. When it reaches zero, the virtual carrier sense reports the medium as idle. The station still uses its physical carrier sense as well, and it transmits only when both of them report idle.
The Duration field is 16 bits long. Wireshark decodes values below 0x8000 as microseconds, so one frame can reserve the medium for at most 32767 microseconds. This limit keeps a single frame from holding the channel for a long time.
The NAV is virtual carrier sense : it tells the station that the medium is busy without any energy measurement.The station decodes only one field : the Duration field in the MAC header is enough, even for a frame addressed to another station.The reservation has a ceiling : 32767 microseconds is the largest value one Duration field can carry.
How do RTS and CTS set the NAV of the other stations ?
The RTS/CTS exchange is the classic case, and it also helps with the hidden node problem. A station that cannot hear Src may still hear Dest. So the CTS reaches stations that the RTS missed, and those stations set their NAV too.
Following is an example showing how NAV is configured.
- i) Station (Src) is sending RTS frame to another station (Dest)
- ii) Station (Dest) detects the RTS from Station Src and send CTS frame to the Station Src.
- iii) All other stations around Src and Dest can detect the RTS and CTS between Src and Dest because these frames are broadcast in a shared medium and decode the information contained in RTS / CTS / ACK frame and contsruct NAV information.
The diagram below has three rows: Src, Dest and Other. G1 is SIFS and G3 is DIFS, as the legend at the upper right says. Src waits for DIFS and sends RTS. Dest answers with CTS after SIFS, Src sends Data after SIFS, and Dest sends ACK after SIFS. The Other row shows two NAV bars, one set from the RTS and one set from the CTS.

NAV (RTS) : it starts at the end of the RTS and ends with the ACK. So it covers the CTS, the Data, the ACK and three SIFS gaps.NAV (CTS) : it starts at the end of the CTS and ends at the same point. A station that heard only the CTS still defers until the ACK is over.Defer Access and G3 : after the NAV expires, Other waits one more DIFS.Contention Window : Other then starts its random backoff, labelled Backoff After Defer.
The RTS and the CTS are each addressed to one station. Other stations still receive them, because the radio medium is shared, and they read only the Duration field. Both NAV bars end at the same time, because each frame announces only the time that is left after it.
Two frames protect one exchange : the RTS covers the stations around Src, and the CTS covers the stations around Dest.NAV is followed by DIFS and backoff : the end of the NAV does not give a station the right to transmit at once.
How long is the NAV that each frame sets ?
The diagram shows the NAV bars, but not their length in microseconds. Let's compute them for one exchange, because the numbers show how much air time a single RTS reserves.
Assume 802.11a at 5 GHz, where SIFS is 16 microseconds. For simplicity, RTS, CTS and ACK are sent at 6 Mbps, and the Data frame is a 1500 byte MPDU at 54 Mbps. An 802.11a PPDU takes 20 microseconds for the preamble and the SIGNAL field. After that, it takes one 4 microsecond OFDM symbol for every 24 bits at 6 Mbps, or for every 216 bits at 54 Mbps. The bits to carry are the 16 bit SERVICE field, the MPDU and 6 tail bits.
- RTS, 20 bytes : (16 + 160 + 6) / 24 rounds up to 8 symbols, so the RTS takes 20 + 32 = 52 microseconds.
- CTS and ACK, 14 bytes each : (16 + 112 + 6) / 24 rounds up to 6 symbols, so each one takes 20 + 24 = 44 microseconds.
- Data, 1500 bytes : (16 + 12000 + 6) / 216 rounds up to 56 symbols, so the Data takes 20 + 224 = 244 microseconds.
Each Duration field covers what is left of the exchange after that frame ends. So the RTS carries 3 x SIFS + CTS + Data + ACK = 48 + 44 + 244 + 44 = 380 microseconds. The CTS carries 380 - 16 - 44 = 320 microseconds, which is 2 x SIFS + Data + ACK. The Data frame carries SIFS + ACK = 60 microseconds. The ACK carries 0, because nothing follows it. The whole exchange takes 52 + 380 = 432 microseconds, and the Data frame uses 244 of them.
The Duration covers the rest of the exchange : each frame reserves only the time after it ends.RTS/CTS costs air time : in this example, RTS, CTS and two SIFS gaps add 52 + 16 + 44 + 16 = 128 microseconds before the Data starts.The rates change the numbers : a faster control rate shortens RTS, CTS and ACK, so real Duration values differ from this example.
Reference
- Network allocation vector - Wikipedia
- DCF Interframe Space - Wikipedia
- The MU-RTS/CTS process in the HE (802.11ax) - standard - Gjermund Raaen, legacy RTS/CTS frame sizes and NAV
- packet-ieee80211.c - Wireshark IEEE 802.11 dissector, Duration field decoding