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

Question

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?

Edit: here is a diagram (the one on the right) explaining my problem

Thank you very much.

Answer 1

I found the answer here IEEE 802.11 MAC Dictionary

here is the relevant section

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.