wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows

Version 28 (modified by chunter, 10 years ago) (diff)

--

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:

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.

No image "experimental_setup.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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
  • Channel 1

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.

No image "connected_symmetric_simultaneous_xput.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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.

No image "connected_symmetric.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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.

No image "modified_cw_simultaneous_xput.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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
No image "hidden_simultaneous_xput.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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.

No image "hidden.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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

No image "connected_symmetric_cw.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs No image "hidden_cw.png" attached to 802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs
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.

Attachments (1)

Download all attachments as: .zip