Changes between Version 11 and Version 12 of 802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

Timestamp:

Jun 23, 2015, 3:55:26 PM (9 years ago)

Author:

chunter

Comment:

--

802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

@@ -66 +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.
 
-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.
+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 could disable RTS/CTS to improve efficiency. The DCF already has a parameter that correlates to the amount of contention: the contention window.
 
 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.