| 53 | | We first establish the best-case performance for each backlogged flow in isolation. We use the [wiki:../../ 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. |
| 54 | | |
| 55 | | The script used for this is provided below in the [#Resources Resources Section]. |
| 56 | | |
| 57 | | ||= Non-Simultaneous =||= Throughput (Mbps) =|| |
| 58 | | ||= Flow 1 =|| 14.17 || |
| 59 | | ||= Flow 2 =|| 14.17 || |
| 60 | | ||= Flow 3 =|| 14.07 || |
| 61 | | ||= Flow 4 =|| 14.07 || |
| 62 | | |
| 63 | | 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. |
| 64 | | |
| 65 | | === Performance of Simultaneous Flows === |
| 66 | | |
| 67 | | Next, we use the WLAN Experiment Framework to enable all 4 flows simultaneously. |
| 68 | | |
| 69 | | ||= Simultaneous =||= Throughput (Mbps) =|| |
| 70 | | ||= Flow 1 =|| 2.06 || |
| 71 | | ||= Flow 2 =|| 2.06 || |
| 72 | | ||= Flow 3 =|| 4.18 || |
| 73 | | ||= Flow 4 =|| 4.47 || |
| 74 | | ||= Sum Throughput =|| 12.77 || |
| 75 | | |
| 76 | | The sum throughput achieved by all flows is less than the individual best-case per-flow throughput. The isolated throughputs in the [#baseline_no_contention 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. |
| 77 | | |
| 78 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:connected_symmetric_simultaneous_xput.png, width=300)]] || |
| 79 | | || ''Relative Share of Network Sum Throughput''' || |
| 80 | | |
| 81 | | 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. |
| 82 | | |
| 83 | | The WLAN Experiment Framework is capable of providing ''much'' more detailed observations about the performance of the network than coarse throughput measures. Specifically, the [wiki:../../log 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. |
| 84 | | |
| 85 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:connected_symmetric.png, width=600)]] || |
| 86 | | || '''Throughput Timeline''' || |
| 87 | | |
| 88 | | 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 [wiki:../../examples/txrx_log_analysis Log Analysis Example]. Furthermore the script used for this experiment is provided in the [#Resources Resources Section]. |
| 89 | | |
| 90 | | The above figure has two interesting features that we would like to point out: |
| 91 | | |
| 92 | | 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. |
| 93 | | 1. 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. |
| 94 | | |
| 95 | | 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. |
| 96 | | |
| 97 | | === A Simple Modification to the DCF === |
| 98 | | |
| 99 | | 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. |
| 100 | | |
| 101 | | ==== Backoff Primer ==== |
| 102 | | |
| 103 | | The 802.11 DCF employs a [http://en.wikipedia.org/wiki/Exponential_backoff 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]. |
| 104 | | |
| 105 | | ==== Reducing the CW of the AP ==== |
| 106 | | |
| 107 | | 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. |
| 108 | | |
| 109 | | Re-running the experiments with this change yields the following. |
| 110 | | |
| 111 | | || ||= Isolated Throughput (Mbps) =|| = Simultaneous Throughput (Mbps) =|| |
| 112 | | ||= Flow 1 =|| 14.84 || 3.7 || |
| 113 | | ||= Flow 2 =|| 14.83 || 3.7 || |
| 114 | | ||= Flow 3 =|| 14.07 || 2.72 || |
| 115 | | ||= Flow 4 =|| 14.08 || 2.71 || |
| 116 | | ||= Sum Throughput =|| n/a || 12.83 || |
| 117 | | |
| 118 | | 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. |
| 119 | | |
| 120 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:modified_cw_simultaneous_xput.png, width=300)]] || |
| 121 | | || ''Relative Share of Network Sum Throughput''' || |
| 122 | | |
| 123 | | 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. |
| | 45 | === Experiment Results === |
| 157 | | {{{#!html |
| 158 | | </td> |
| 159 | | <td align=right> |
| 160 | | }}} |
| 161 | | |
| 162 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:hidden_simultaneous_xput.png, width=300)]] || |
| 163 | | || ''Relative Share of Network Sum Throughput''' || |
| 164 | | |
| 165 | | {{{#!html |
| 166 | | </td></tr></table> |
| 167 | | }}} |
| 168 | | |
| 169 | | 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. |
| 170 | | |
| 171 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:hidden.png, width=600)]] || |
| 172 | | || '''Throughput Timeline''' || |
| 173 | | |
| 174 | | 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? |
| 175 | | |
| 176 | | 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 |
| 177 | | |
| 178 | | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:connected_symmetric_cw.png, width=600)]] || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows/figs:hidden_cw.png, width=600)]] || |
| 179 | | || '''Experiment 1 (Fully Connected) Contention Window''' || '''Experiment 2 (Hidden Stations) Contention Window''' || |
| 180 | | |
| 181 | | 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. |
| 182 | | |
| 183 | | |
| 184 | | == Conclusion == |
| 185 | | |
| 186 | | 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 [wiki:../../examples/chan_est_viewer 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. |
