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
5. Appendix?

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.

Experimental Setup

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

The colors in the figure above are used throughout this app note to denote each flow.

Tx/Rx Log Results

---

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)