Investigating Hidden Nodes and RTS/CTS Access

The ​Hidden Node Problem is a classic topology studied in wireless networking where traditional carrier sensing breaks down since one or more nodes are "hidden" from the carrier sensing capability of the rest of the network.

Classic Hidden Node Topology

As we have seen in the multiflow app note, carrier sensing plays a crucial role in the DCF's ability deal with contention in a shared wireless medium. In the classic hidden node topology shown above, STA 1 can carrier sense the AP and vice versa. STA 2 can carrier sense the AP and vice versa. However, STA 1 and STA 2 are out of range of one another and cannot detect each other's transmissions. The traditional solution to this problem is the ​RTS/CTS handshake. The basic timeline of this handshake is as follow:

1. STA 1 wishes to send a data MPDU to the AP. Since STA 2 cannot directly hear this transmission, the likelihood of a collision might be large. Instead, STA 1 "requests to send" the MPDU by sending a very short RTS frame to the AP. This transmission may still collide, but it is very short, so the penalty to lost medium time is significantly mitigated.
2. When the AP receives this RTS frame, it checks the medium by looking at its NAV. If the NAV says the medium is clear, it sends the "clear to send" CTS frame in response. Critically, this CTS frame contains a duration field that species how long the medium will be occupied for the upcoming MPDU and ACK transmissions.
3. Since STA 2 is within the transmission range of the AP, it overhears this CTS transmission and updates it NAV for the entire duration specified in the CTS frame. This will prevent STA 2 from colliding with the upcoming MPDU transmission from STA 1.
4. Finally, STA 1 receives this CTS message and begins the transmission of the actual MPDU. This MPDU is now protected from collisions from anyone who overheard the AP's CTS transmission.

RTS/CTS support was added in 802.11 Reference Design (version v1.3). In this application note, we'll use the reference design and its experiments framework to investigate the hidden node problem.

Table of Contents

1. Experimental Setup
2. Aggregate Results
3. Tx/Rx Log Results
4. Source Code

Experimental Setup

The experiments described below use 3 Mango WARP v3 kits, each running the 802.11 Reference Design (version v1.3), including the WLAN Experimental Framework. To construct a hidden node topology, we could space nodes apart from one another and lower transmit powers to induce the effect. However, this is not the easiest set up for repeatability of these experiments. Instead, we can artificially "blind" two stations from one another via RF cabling and sufficient attenuation.

Experimental Setup

The above figure shows the wired topology. STA 1 and the AP are suppressed by 50 dB of external attenuation (plus cable loss and 3 dB loss through the power splitter). The same is true for the link between STA 2 and the AP. The link between STA 1 and STA 2, however, involves 100 dB of external attenuation as well as the tens of dB attenuation after leakage between the two input ports of the power splitter. This attenuation is sufficiently large such that neither STA can decode the other's transmissions. Furthermore, it is sufficient attenuation such that neither STA can physically carrier sense each other's transmissions.

Experiment Details

• Packet Length: 1400 byte payloads (1428 byte MPDUs, with MAC header and FCS)
• PHY Rate: 18 Mbps (QPSK, code rate 3/4) for data MPDUs
• Tx Power: 15 dBm
• 2.4GHz channel 1

We use 4 traffic flows in our experiments:

• Flow 1: Backlogged traffic from STA 1 to AP
• Flow 2: Backlogged traffic from STA 2 to AP

In this experiment, we will break up a single trial into three sequential pieces. In the first 30 second phase, we will start Flow 1 all by itself. In the second 30 second phase, we will disable Flow 1 and start Flow 2 by itself. In the third and final 30 second phase, we will enable both Flows 1 and 2. This entire experiment will be performed for both an RTS/CTS disabled case as well as an RTS/CTS enabled case.

Tx/Rx Log Results

A Heuristic Extension

---

Resources

Python Scripts

Download: multi-flow_python_scripts_v1_00.zip

• Requirements:
  • 3 WARP v3 Kits configured as 1 AP and 2 STA
  • Mango 802.11 Reference Design v1.0

Zip Contents:

• multi-flow_experiment.py - This script will run the experiment and write the log files from each board to the directory in which this script is executed.
• multi-flow_plotter.py - This script will open the generated log files and produce the plots used in the application note.
• log_analysis_util.py - Utility script that is used by multi-flow_plotter.py. This should not be run directly. Instead, it should be in the same directory as multi-flow_plotter.py

Experiment Data

In addition to providing the python scripts to gather and process the data in this application note, we also provide the actual data log files we gathered, processed, and presented.

Download: ​multi-flow_log_data_v1_00.zip (371MB)