Investigating the DCF with Multiple Traffic Flows

The purpose of the 802.11 Distributed Coordination Function (DCF) is to allow multiple flows of traffic to contend for a shared wireless medium. In this application note, we investigate how the 802.11 Reference Design behaves when subjected to multiple traffic flows. This note provides a case study on how the WLAN Experiment Framework can be used to control and analyze the performance of the 802.11 Reference Design.

In this application note, we look at two things:

1. The effects of contention windows on medium access.
2. The effects of the hidden node problem on medium access.

This application note is not novel research. All of the insights provided here are known to the research community and have been for years. Instead, it is best to take this application note as an exercise of the WLAN Experiment Framework to re-discover known features of the 802.11 DCF.

Requirements

To run the code provided in this note, the following requirements must be met:

• 3 WARP v3 kits
• 802.11 Reference Design v.91 Beta

Experimental Setup

While all of the example code provided by this application note will operate over-the-air (OTA) with antennas, we chose to use RF cabling with attenuators to make the results repeatable and easier to discuss.

Block Diagram	Photo

The above figure shows the experimental setup. We use an ​Mini-Circuits Power Splitter/Combiner and rely on imperfect isolation between the two station-connected ports to allow the stations to carrier-sense one another. The three ports of the combiner are connected to three sets of attenuators, whose values we will define in the coming experimental description sections. In each of the below experiments, we refer to a common legend of traffic flows:

• Flow 1: Backlogged constant bit-rate (CBR) traffic from AP to STA_1
• Flow 2: Backlogged CBR traffic from AP to STA_2
• Flow 3: Backlogged CBR traffic from STA_1 to AP
• Flow 4: Backlogged CBR traffic from STA_2 to AP

The colors used to identify each flow in the above figure are common throughout this application note.

Experiment 1: Symmetric and Fully Connected

In this first experiment, we aim to see how the 802.11 Reference Design behaves when all nodes are "fully connected" with nearly-matched path losses between every combination of nodes. Topologically, this mimics the scenario where each of the three nodes sit on the vertex of an equilateral triangle.

Experiment Details

• Attenuation 1: 45dB
• Attenuation 2: 15dB
• Attenuation 3: 15dB
• Packet Length: 1400 byte payloads (1428 bytes OTA with MAC header and FCS)
• PHY Rate: 18 Mbps
• Trial Duration: 90 seconds

Baseline: Performance of Each Flow in Isolation

As a first cut, we establish the best-case performance for each backlogged flow by running a series of experiments with only on flow enabled at a time. To do this, we use the WLAN Experiment Framework to reset the nodes, set the PHY rate, and then start locally generated traffic from the nodes. The script used for this is provided below in the Resources Section.

Non-Simultaneous	Throughput (Mbps)
Flow 1	14.17
Flow 2	14.17
Flow 3	14.07
Flow 4	14.07

Each flow, on its own, is capable of achieving ~14Mbps out of the 18Mbps PHY rate. This is near the theoretical maximum throughput, given the unavoidable MAC overhead of the 802.11 DCF. Each flow in the network sees a high-quality link through the RF cabling and attenuators -- there are virtually no PHY packet losses due to outage.

Performance of Simultaneous Flows

Next, we use the WLAN Experiment Framework to enable all 4 flows simultaneously.

Simultaneous	Throughput (Mbps)
Flow 1	2.06
Flow 2	2.06
Flow 3	4.18
Flow 4	4.47
Sum Throughput	12.77

The first thing to notice is that the sum throughput achieved by all flows together is less than any one of the throughputs achieved by one of the flows on their own. The isolated throughputs in the previous section are upper bounds on perfomance because there are no losses due to collisions. When all four flows contend for the same medium, collisions are inevitable, yielding an overall reduction in network sum throughput.

Relative Share of Network Sum Throughput

The above figures shows the same table of data, but emphasis the relative share of the 12.77 Mbps sum throughput that each flow achieves. Here, we can see that Flows 3 and 4 each achieve about 1/3 of the overall throughput while Flows 1 and 2 have to split the remaining 1/3. This is due to the fact that the AP is burdened with sourcing two flows (Flow 1 and 2) while each STA only needs to source a single flow. The 802.11 DCF gives each of the three devices (AP, STA 1, and STA 2) a fair shot at grabbing the medium -- it does not care that one of the three nodes has more traffic it needs to send.

The WLAN Experiment Framework is capable of providing much more detailed observations about the performance of the network than coarse throughput measures. Specifically, the event log lets us observe events that occur during the experiment directly without aggregation. Given the fact that the "wireless" network in this experiment very static (RF cabling and attenuators), one might expect that the throughput values presented thus far are accurate for any arbitrarily short span of time. Using the event log, we can see this is not the case.

Throughput Timeline

The above figure shows the timeline of throughputs achieved by each of the four flows during the experiment with a one second rolling window average. These timelines were constructed from the event log using a technique identical to that presented in the Log Analysis Example. Furthermore the script used for this experiment is provided in the Resources Section.

The above figure has two interesting features that we would like to point out:

1. Even though this experiment has no channel dynamics, the 802.11 DCF itself is fundamentally dynamic -- between each transmission of each node is a random backoff interval. Furthermore the interval over which the backoff time is randomly drawn is itself dependent on how successful the node is performing at any given time. The effect is that the three nodes running the DCF are constantly giving and taking their relative share of the wireless medium. You can see this in the throughput traces. As one flow dips, another flow increases to take up the gap from their absence. The sum throughput of all four flows together is less dynamic than any one of them. This is the result of this natural ebb and flow of channel access provided by the DCF.
2. Notice that Flows 1 and 2 have nearly the same throughput timeline. In fact, it is a little difficult to even see Flow 1's timeline because Flow 2 is plotted directly in front of it. The AP is sourcing Flow 1 and Flow 2 in a round-robing fashion -- it simply alternates between each. What this throughput timeline tells us is that both flows are exposed to the same effective network dynamics: both Flows 1 and 2 show the AP's view of the network.

The 802.11 DCF treats makes no real distinction between an AP or a STA even though an AP might need to source many more traffic flows than STAs. In the next section, we make a slight modification to the 802.11 DCF to give the AP some help with its extra burden.

A Simple Modification to the DCF

How can we improve the performance of Flows 1 and 2 from the AP relative to Flows 2 and 3 from each of the stations? There are many ways to do this, but one approach can be modifying the DCF at the AP such that, on average, it has a higher likelihood of winning the backoff game over the other two stations.

Backoff Primer

The 802.11 DCF employs a binary exponential backoff (BEB)

Experiment 2: Symmetric with Hidden Stations

Experiment Details

• Attenuation 1: 0dB
• Attenuation 2: 60dB
• Attenuation 3: 60dB
• Packet Length: 1400 byte payloads (1428 bytes OTA with MAC header and FCS)
• PHY Rate: 18 Mbps
• Trial Duration: 90 seconds

Resources

Links to the data sets and experiment scripts used to perform this study will be posted shortly.