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

Timestamp:

Jun 23, 2015, 3:56:46 PM (9 years ago)

Author:

chunter

Comment:

--

802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

@@ -68 +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 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.
+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.
 
 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.