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 does not present research results. Fairness in the 802.11 DCF is a ​well studied topic. The goal of this app note is to demonstrate how the 802.11 Reference Design and its experiments framework can be used to study high- and low-level behaviors across many nodes in real time.

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

In order to isolate inherent DCF behaviors from uncontrollable fading and interference, we run the first set of experiments using wired connections between the RF interfaces of the WARP v3 nodes.

Block Diagram	Photo

The above figure shows the experimental setup. We use an ​Mini-Circuits Power Splitter/Combiner and discrete attenuators to establish a "shred" medium among the three RF interfaces. The path loss between each pair of nodes is controlled by varying the attenuation values. The inherent path loss through the power splitter/combiner is ~3dB for paths S-1 and S-2 and ~28dB for path 1-2.

We use 4 traffic flows in our experiments:

• 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 in the figure above correspond to the colors used in per-flow plots below.

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 node. This mimics topology of three nodes at the vertices 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
• Channel 1

Baseline: Contention-Free Performance

We first establish the best-case performance for each backlogged flow in isolation. We use the Experiment Framework to reset the nodes, set the PHY rate, and then start locally generated traffic from the nodes. The Tx/Rx statistics are then retrieved from every node twice spanning a 90 second interval. The per-flow throughput is calculated as the ratio of new Rx bytes received vs. the time span over which they were received.

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 is capable of achieving ~14Mbps out of the 18Mbps PHY rate. This is near the theoretical maximum throughput, given the normal overhead in the 802.11 MAC and OFDM PHY. Each flow sees a high-quality link through the RF cabling and attenuators -- there are virtually no PHY packet losses.

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 sum throughput achieved by all flows is less than the individual best-case per-flow throughput. The isolated throughputs in the previous section are upper bounds on performance, reflecting the achievable performance when no packets are lost 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). Roughly speaking, each packet transmission is separated by a random wait time that may be paused by other transmissions from other nodes. This random interval is chosen uniformly over a contention window (CW). The CW itself is dynamic. It increases when nodes do not receive an acknowledgement that their transmission succeeded (an indication that the medium is under heavy contention). This makes the node less aggressive about transmission attempts and serves to reduce the likelihood of collisions. Conversely, the CW resets to its minimum value when nodes successfully transmit and receive an acknowledgement. For 802.11g, the minimum contention window over which a backoff is drawn is [0, 15]. After failures, this window doubles to [0, 31], [0, 63], and so on. The 802.11 standard caps the maximum CW to [0,1023].

Reducing the CW of the AP

One way that we can modify the performance of the AP is to let it play by a different set of rules than the two connected stations. In the 802.11 Reference Design, the CW selection is purely in C-code. By making a simple change to this C-code, we have modified the AP such that it's minimum CW is [0, 7] instead of the standard [0, 15]. After a failure, its next CW is [0, 15] instead of [0, 31] and so on. We expect that this change will tend to make the AP win access to the medium in front of the two stations on average since it is usually drawing from a set of smaller values.

Re-running the experiments with this change yields the following.

	Isolated Throughput (Mbps)	= Simultaneous Throughput (Mbps)
Flow 1	14.84	3.7
Flow 2	14.83	3.7
Flow 3	14.07	2.72
Flow 4	14.08	2.71
Sum Throughput	n/a	12.83

When the flows are run separately, we can see that Flow 1 and Flow 2 achieve slightly higher throughputs than they used to because of the CW change. When each flow is run simultaneously, we can see that their relative share of the sum throughput is a very different story than what it used to be.

Relative Share of Network Sum Throughput

Whereas Flow 1 and Flow 2 used to split 1/3 access to the medium, they now get a much larger share. The AP gets to be much more aggressive about transmitting with the change to the contention window behavior, thus compensating for its extra burden of needing to source two traffic flows.

Experiment 2: Symmetric with Hidden Stations

In this second experiment, we modify the attenuation values in the experimental setup such that each flow sees the same path loss as the first experiment, but the path loss between the two STA nodes is dramatically larger. Topologically speaking, this is an extreme ​hidden node problem: STA 1 and STA 2 can each "see" the AP, but they cannot see one another. Note: this experiment resets the CW changes we made to the AP at the end of the prior experiment. Each node is running a completely standard 802.11 Reference Design.

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
• Channel 1

Performance of Simultaneous Flows

The per-flow isolated throughputs are identical to the first experiment, so they will not be re-presented here for brevity. Instead, we jump directly to the case where all four flows are activated simultaneously.

Simultaneous Throughput (Mbps) Flow 1 3.9 Flow 2 3.9 Flow 3 2.37 Flow 4 2.25 Sum Throughput 12.42

Relative Share of Network Sum Throughput

The hidden node problem has massively reduced the achievable throughput of Flows 3 and 4 since they cannot carrier-sense one another to avoid collisions. Using the event log, we can look deeper into the design to see some very interesting behaviors.

Throughput Timeline

Notice that Flows 3 and 4 are very unstable. They do not simply oscillate around some nominal throughput like they did in the first experiment. It appears that they alternate between nearly turning off with near-zero throughput and achieving very high instantaneous throughput. How can we explain this?

The event log of the WLAN Experimental Framework is very powerful. It can reveal much more than throughput timelines. Another set of data it can give us is what the contention windows of each node in the network as a function of time. In this way, we can visualize the binary exponential backoff of each node in the networks

Experiment 1 (Fully Connected) Contention Window	Experiment 2 (Hidden Stations) Contention Window

Comparing the contention data from the two experiments reveals what is going on with the throughput behavior in the hidden node case. Whereas the first experiment saw each node's contention window hovering around similar values, the second experiment's hidden station nodes have radically different behavior. The contention window wildly swings and rails between maximum and minimum values many times. Notice that when STA 1 has a large CW, STA 2 has a small CW and vice versa. The gap of idle time created by one station choosing a large contention window allows the other station many opportunities to successfully transmit and minimize its own contention window. These contention window selections explain why the throughputs of Flows 3 and 4 vary between high and low values with such frequency.

Conclusion

In this application note, we used the WLAN Experimental Framework to study behaviors of the DCF. We used the framework's event logs to dive deeply into these behaviors and describe transient effects -- we are not limited to coarse aggregate measures of performance. An extension to this experiment would be to remove the RF cabling altogether and investigate over-the-air performance. In this scenario, there is much more to deal with. For example, there will be interference from other ISM band transmitters and there will also be multipath fading. The WLAN Experimental Framework can help uncover the guiding forces behind the performance that is observed. For example, the Channel Estimate Viewer shows how to extract channel estimates from the log. This can be viewed and analyzed alongside MAC events to help uncover PHY reasons for the causes of performance changes.

Resources

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