“Hidden node” vs. “Exposed node”

Posted on by

I thought of writing this post to clarify these two different situations and how they can be solved.

Hidden node

The “hidden node” or “hidden station” problem refers to a well-known issue that arises when not every station within the medium can sense the carrier, due to the distance, signal attenuation, reflections, etc.

To illustrate it, let’s take this scenario as an example:

In this scenario, both Stations and the Access Point are on the same channel. Both stations can hear the Access Point (green arrows), but they cannot hear each other (red arrow).

In this situation, the transmission from STA1 cannot be heard from STA2. STA2 starts its own transmission, which collides with that of STA1 at the Access Point:

Each station expects an ACK frame from the Access Point which never arrives, as neither station is aware of the collisions that happen at the Access Point. These collisions can occur multiple times, until the Back-Off timers eventually act as the tie-breaker and either station manages to transmit.

Exposed node

The “exposed node” problem is different. It too involves two Stations, but each other associated with different Access Points on the same channel:

In this scenario, neither AP can hear each other (red arrow). Stations can hear each other and the Access Point they are associated with (green arrows). Coverage areas from both APs don’t necessarily overlap- the “exposed node” issue arises whenever the two stations can hear each other.

In this situation, the transmissions from STA1 interfere with those of STA2:

STA2 cannot find the channel available and is forced to wait, even though STA2 wouldn’t interfere with STA1 (remember that AP1 cannot hear STA2). As a result, STA2’s transmissions are continuously deferred – until either STA1 stops transmitting or the Back-Off timers allow STA2 to “win”.

“Hidden node” and “exposed node” are both undesirable situations that can be prevented with the use of the RTS/CTS (Request-to-Send/Clear-to-Send), mechanism, which is optional in 802.11.

RTS/CTS

RTS/CTS is an orchestration mechanism that is optional in 802.11 and originally aimed at solving the “hidden node” problem. RTS/CTS is basically a handshake based on two new frames: CTS and RTS. These frames announce a NAV (Network Allocation Vector) to the rest of the Stations. The NAV is a virtual carrier sense: it signals the amount of time that the subsequent data transmission is going to take, so all the stations can hold back for at least that amount of time before attempting a transmission.

Here is how RTS/CTS solves the “hidden node” issue:

STA2 cannot hear the RTS frame from STA1, however it can hear the CTS response from the AP. At that point, STA2 knows that it’s in a “hidden node” situation and must wait the CTS NAV period (SIFS+Data+SIFS+ACK) before attempting its own transmission.

RTS/CTS can help alleviating the “exposed node” issue too, with some limitations:

In this case, STA2 can hear the RTS frame from STA1, but not the CTS response from AP1 (an inverse situation from that of hidden node). At this point, STA2 knows that it’s in an “exposed node” situation, and can safely transmit to AP2 without interfering with ST1/AP1.

The limitation of RTS/CTS at solving “exposed node” is that the affected node must be able to support the data rates at which the RTS/CTS frames are sent on the neighbouring cell. If it doesn’t, then it will be “deaf” to these frames and won’t be able to use them as an orchestration mechanism.

Conclusions

While the hidden node/exposed node situations can be solved (or minimised) with the use of RTS/CTS, by doing this we are introducing more control frames and overhead in the network, reducing the airtime available for actual application data. The best workaround is to avoid these situations altogether by means of careful network planning.

RTS/CTS has yet another purpose in addition to alleviating the “hidden node” issue: in 802.11g and faster 2.4 GHz networks, the use of this handshake can alert 802.11b stations (which cannot decode OFDM traffic) that traffic is being sent, so they can refrain from sending on the medium. In a way, a wireless network with a mix of 802.11b and 802.11g stations is a “hidden node” scenario where the stations cannot hear each other due to the differences in their modulation (OFDM vs. DSSS). Again, the only way to avoid the extra RTS/CTS overhead is by preventing 802.11b stations from associating to the network (for example, by disabling 802.11b data rates). Not many 802.11b devices remain nowadays, but the possibility is still there.