| | 47 | = Tx/Rx Log Results = |
| | 48 | |
| | 49 | In this experiment, we use the Tx/Rx logs in each node to generate Throughput vs. Time results in the same way as the [wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows multiflow app note]. For brevity, this document will not cover the basics of log processing. Please see the previously mentioned app note as well as the [wiki:802.11/wlan_exp/log wlan_exp log documentation] for more details. |
| | 50 | |
| | 51 | || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_hidden_nodes/figs:rts_disabled.png, width=400)]] || [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_hidden_nodes/figs:rts_enabled.png, width=400)]] || |
| | 52 | || '''RTS/CTS Disabled''' || '''RTS/CTS Enabled''' || |
| | 53 | |
| | 54 | In the above plots, we can clearly see the three phases of the experiment over each trial's 90 second duration. There are three fundamental things to notice about RTS/CTS relative to basic access: |
| | 55 | |
| | 56 | 1. During the contention free phases (i.e., the first 60 seconds of each trial), RTS/CTS actually harmed the achieved throughput. We dropped from achieving ~10 Mbps of the 12 Mbps PHY rate to slightly more than 9 Mbps. In the absence of any collisions, RTS and CTS transmissions are purely overhead. Transmitting those frames takes a non-negligible amount of time. That time could have been spent transmitting the actual data MPDUs. The overall cost of this overhead is a function of the duration of each data MPDU. Large sized and low rate transmissions incur a relatively smaller penalty than short and/or high rate transmissions. |
| | 57 | 1. During the contention phase (i.e. the last 30 seconds of each trial), we can see the benefit provided by RTS/CTS to overall sum throughput. Without RTS/CTS, the network achieved ~6.5 Mbps. This is a considerable loss over the ideal ~10 Mbps of achievable throughput in the contention-free phases. When RTS/CTS is enabled, however, sum throughput is recovered to 9 Mbps. This is a direct result of the improved virtual carrier sensing ability given to each station when they overhear the AP's CTS to the other station. |
| | 58 | 1. In addition to providing a big improvement in sum throughput during the contention, RTS/CTS also radically improves the delay profile of each of the two constituent flows. Notice in the RTS/CTS disabled that any given slice of time generally sees all throughput from Flow 1 or all throughput from Flow 2 (i.e. the either the red or green line overlaps with the black sum line). This is a result of the binary exponential backoff structure of the DCF. In the event of a collision, contention windows increase and provide a longer window of time to allow another device contention-free access to the medium. The result is an extreme swing of short-term outages for each link. Each STA can potentially be stuck backing off for seconds at a time while the other STA is getting its traffic to the AP. Then, at some point, there is a chance for them to trade places if the STA that was stuck backing off is able to choose a lower slot time than its neighbor. Compare this behavior to the RTS/CTS enabled case. In general, the two stations are splitting the medium and trading off on much smaller timescales. |
| | 59 | |
| | 60 | So, should devices use RTS/CTS? The answer is not obvious. There is clearly an inherent tradeoff between the increased overhead caused by RTS/CTS and the benefits to improved carrier sensing range. Which side wins this tradeoff is dependent on many factors including the size of the payload being delivered, the overall network contention, and the network topology. The 802.11 Standard notes this and defines a "dot11RTSThreshold" that can be specified by equipment manufacturers. Any MPDU above this threshold is considered "long" and the overhead of the RTS/CTS exchange is considered "worth it." Anything lower than this threshold uses basic access without RTS/CTS. However, we have seen from our previous experiment than even fairly long (1400 byte) frames and fairly low rates (12 Mbps) still exhibit a non-obvious tradeoff in the utility of RTS/CTS. |
| | 61 | |
| | 62 | In the next section, we will see if we can do better than simply enabling or disabling RTS/CTS as a function of packet size. |
| | 63 | |
| | 64 | = A Heuristic Extension = |
| | 65 | |
| | 66 | First, we begin with an important disclaimer. The extension described in this section is not and should not be considered paper-worthy research. It is an obvious, intuitive extension and it is inadequately defended for peer-reviewed publication. The extension is only exposed to this single extreme hidden node example and not exposed to any kind of rigorous empirical study with varied topologies and traffic profiles. This is not the point of this application note. Instead, the purpose of this document is to show how a handful of easy changes to the C-code of the 802.11 Reference Design can radically change the behavior of the MAC protocol. Furthermore, it demonstrates how tools like the wlan_exp framework can be used to study those radical changes in behavior. In short, it is a glimpse at one way the 802.11 Reference Design can be used to study research problems. |
| | 67 | |
| | 68 | One way to resolve the tradeoff is to teach the node to recognize a heavy-contention period from a light-contention period. During the heavy-contention period, the node could enable RTS/CTS to mitigate the effects of collision from hidden nodes. During the light-contention period, the node by disable RTS/CTS to improve efficiency. The DCF already has a parameter that correlates to the amount of contention: the contention window. |
| | 69 | |
| | 70 | Here, we will intuit a small extension to the DCF that allows it to adaptively enable and disable the RTS/CTS structure as a function of the behavior of its contention window. When a contention window increases, this is a piece of evidence that indicates a collision may have occurred and overall contention may be increasing. Conversely, when a contention window resets due to the successful receipt of an ACK, this is a piece of evidence that indicates that we may be entering a light-contention period. Let's define two variables for tracking this behavior {{{num_consecutive_cw_increases}}} and {{{num_consecutive_cw_resets}}}. {{{num_consecutive_cw_increases}}} will be used to track the number of consecutive times a contention window increases. If a contention window reset occurs, {{{num_consecutive_cw_increases}}} is set back to zero as the chain of increases has been broken. {{{num_consecutive_cw_resets}}} tracks the number of times that contention window resets have consecutively occurred. If a contention window increases, {{{num_consecutive_cw_resets}}} is set back to zero as the chain of resets has been broken. |
| | 71 | |
| | 72 | Finally, we define two parameters {{{RTS_EN_THRESH}}} and {{{RTS_DIS_THRESH}}}. {{{RTS_EN_THRESH}}} defines the number of consecutive contention window increases that must occur before the node decides that enabling RTS/CTS is a good idea. {{{RTS_DIS_THRESH}}} defines the number of consecutive contention window resets that must occur before the node is comfortable disabling RTS/CTS. In this way, {{{RTS_EN_THRESH}}} and {{{RTS_DIS_THRESH}}} can be set to change how aggressively the node reacts to contention window changes with enabling and disabling the RTS/CTS structure. For this example, we will require {{{RTS_EN_THRESH = 5}}} consecutive CW increases before we enable RTS/CTS and require {{{RTS_DIS_THRESH = 100}}} consecutive CW resets to disable RTS/CTS. |
| | 73 | |
| | 74 | This simple protocol is easy to add to the existing DCF implementation. The key changes required are: |
| | 75 | |
| | 76 | 1. |
| | 77 | |
| | 78 | {{{ |
| | 79 | #!text/c |
| | 80 | #define RTS_EN_THRESH 5 |
| | 81 | #define RTS_DIS_THRESH 100 |
| | 82 | volatile u32 num_consecutive_cw_increases; |
| | 83 | volatile u32 num_consecutive_cw_resets; |
| | 84 | }}} |
