purpose of NAV and its relation to the exposed node problem in 802.11

[use062]

802.11 uses csma/ca as the mac protocol.

Every station senses the medium, if something is being sent, then they will set their NAV to the duration ID from the packet being sent weather RTS, CTS, DATA, ACK.

RTS/CTS was introduced to mitigate the hidden node and exposed node problems.

The exposed node problem occurs when a node in a BSS senses the

But if the nodes set their nav to the duration in the RTS packet (which is then they will be backing off when CTS, therefore the problem will still persist, so is this how the nav works?

Also, in the exposed node problem, why can't the node read from the RTS packet that it is being sent to a different node/AP?

Here another closely related unanswered question: How do DCF and MACAW solve the exposed node problem?

the diagram on the right explains my problem

Thank you very much.

I also asked this question here Mechanism/purpose of the NAV and its relation to the exposed node problem in 802.11 

and here Mechanism/purpose of the NAV and its relation to the exposed node problem in 802.11 

but received no answer/satisfactory answer.

[Flavio Miranda]

"Every station senses the medium, if something is being sent, then they will set their NAV to the duration ID from the packet being sent weather RTS, CTS, DATA, ACK."

This statement is wrong.

"Any frames transmitted during the contention-free period set the Duration field to 32,768. Naturally, this applies to any data frames transmitted during this period."

"Frames transmitted to a broadcast or multicast destination (Address 1 has the group bit set) have a duration of 0. Such frames are not part of an atomic exchange and are not acknowledged by receivers, so contention-based access to the medium can begin after the conclusion of a broadcast or multicast data frame. The NAV is used to protect access to the transmission medium for a frame exchange sequence. With no link-layer acknowledgment following the transmission of a broadcast or multicast frame, there is no need to lock access to the medium for subsequent frames."

https://www.oreilly.com/library/view/80211-wireless-networks/0596100523/ch04.html 

[use062]

Thank you very much for you reply,
I didn't know that about the contention free period, but my question is about contention based period, apologies if that wasn't clear from the question.

I did read the part about Duration from the book, but i still fail to understand how that answers my question.

from the book:

that would mean if a station connected to another access point overhears the the rts frame, it would set its nav the the whole exchange time.

Could you please elaborate/clarify?

[Flavio Miranda]

You question on the original post was:

"

But if the nodes set their nav to the duration in the RTS packet (which is then they will be backing off when CTS, therefore the problem will still persist, so is this how the nav works?

Also, in the exposed node problem, why can't the node read from the RTS packet that it is being sent to a different node/AP?"

But, you was misunderstanding the concept of NAV by thinking that any frames would  trigger the NAV counter. When, in fact, only data frames is able to do that.

It is also clear, on this question as well:

"Also, in the exposed node problem, why can't the node read from the RTS packet that it is being sent to a different node/AP?"

Also on the same scenario. RTS is management frame and has a duration of 0.

So, you need to be clear on what is your question, otherwise no forum can´t help you.

[use062]

I got that management frames don't trigger the NAV, but the RTS is a control frame and not a management frame

from the book (relevant sentence in bold):

---

Request to Send (RTS)

RTS frames are used to gain control of the medium for the transmission of “large” frames, in which “large” is defined by the RTS threshold in the network card driver. Access to the medium can be reserved only for unicast frames; broadcast and multicast frames are simply transmitted. Like all control frames, the RTS frame is all header.

[Flavio Miranda]

Oh yes, I agree. I used management in broader concept but what I meant is that it is not a Data frame.

"that would mean if a station connected to another access point overhears the the rts frame, it would set its nav the the whole exchange time."

If in that period it does not hear any data frame, why not ?

"The NAV is used to protect access to the transmission medium for a frame exchange sequence. With no link-layer acknowledgment following the transmission of a broadcast or multicast frame, there is no need to lock access to the medium for subsequent frames"

And keep in mind that this mechanism can help but will never be perfect. Just need to look at the amount of retransmition in a real wifi network or response time which is much higher then wired network.

[use062]

i understood the paragraph you quoted as being exclusive to broadcast/multicast frames and not unicast frames, which need a frame exchange sequence which is an rts/cts exchange so my problem still persists.

here is another reference from a networking course i used

when stations hear an exchange they set the nav, this includes hearing rts

Thank you very much for your patience with me.

[Flavio Miranda]

 "i understood the paragraph you quoted as being exclusive to broadcast/multicast frames and not unicast frames, which need a frame exchange sequence which is an rts/cts exchange so my problem still persists."

 But which frame is broadcast and which frame is unicast?  For my understanding, all management and control frames is broadcast or multicast frames.

unicast frames are frames with specific target which is the data frames.

This chart confuse things.  It is not that the RTS, CTS, ACK etc does not need to be respected.   "Such frames are not part of an atomic exchange and are not acknowledged by receivers, so contention-based access to the medium can begin after the conclusion of a broadcast or multicast data frame"

The Wi-Fi network can be divided between management and control frames, sent by Access Points only, and data frames, sent by Clients through the Access Points.  Would be like an underlay and overlay network.

The underlay  can be dictaded by the CIFs interval as the Access Points have controll of it and does not need to envolve clients.  Clients are passive for this frames.

But then clients start to send data frames  and then the client need to have a mechnism to guide everyone on the Cell . That´s the CSMA/CA.

As clients can either speak or hear, they can not do both at the same time, they need to avoid collision instead detect collision. And NAV is the best mechanism so far to handle Collition avoidance.

[use062]

to be honest i'm confused,

from the book:

---

Address 1: Receiver Address

The receiver of a CTS frame is the transmitter of the previous RTS frame, so the MAC copies the transmitter address of the RTS frame into the receiver address of the CTS frame. CTS frames used in 802.11g protection are sent to the sending station, and are used only to set the NAV.

---

this also says that rts and cts are unicast:

Robust Broadcast : Improving the reliability of broadcast transmissions on CSMA/CA 
section 3.1

another proof from here CWAP – 802.11 Ctrl : RTS/CTS :

only managment frames (such the beacon frame at the buttom) are broadcast

also as someone pointed out in this question:

RTS/CTS -unicast or broadcast + Random backoff time 

---

RTS/CTS are unicast. If the messages were broadcast, a sender could send out an RTS and then potentially have every other node in the wireless network sending back CTS resulting in collision.

[use062 · Accepted solution]

I found the answer here IEEE 802.11 MAC Dictionary

the relevant part:

---

NAV (Virtual carrier sense)

It is interesting that the RTS set its NAV covering  to the end of whole RTS-CTS-DATA-ACK process. How about a RTS has not been ACKed with a proper CTS. Then all the nodes around the sending node will wait for such a long idle period, and just wasting the bandwidth?! The standard provides a solution, that the nodes could reset NAV if it does not hears DATA packet at some time. However, it is still seems not perfect because anyway, the NAV settings broadcasted by RTS has to be re-confirmed by a following DATA frame, the first setting in RTS seems always flexible and non-compulsive. Thus, schemes could just say, we set the NAV first to "2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime", then announce the final decision in DATA frame. This is very useful, in case that the sending node cannot be sure how long it takes to transmit without a CTS reply in some scheme

Excerpts from 9.2.5.4

STAs receiving a valid frame shall update their NAV with the information received in the Duration/ID field,
but only when the new NAV value is greater than the current NAV value and only when the frame is not
addressed to the receiving STA. Various additional conditions may set or reset the NAV, as described in
9.3.2.2. When the NAV is reset, a PHY-CCARESET.request shall be issued.
Figure 53 indicates the NAV for STAs that may receive the RTS frame, while other STAs may only receive
the CTS frame, resulting in the lower NAV bar as shown (with the exception of the STA to which the RTS
was addressed).
A STA that used information from an RTS frame as the most recent basis to update its NAV setting is permitted
to reset its NAV if no PHY-RXSTART.indication is detected from the PHY during a period with a duration
of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication
corresponding to the detection of the RTS frame. The ¡°CTS_Time¡± shall be calculated using the length of
the CTS frame and the data rate at which the RTS frame used for the most recent NAV update was received.
Figure 53¡ªRTS/CTS/data/ACK and NAV setting

---

Thank you very much @Flavio Miranda for the help, i really appreciate it, you have been so patient with me.