Changes between Version 14 and Version 15 of 802.11/wlan_exp/app_notes/dcf_with_hidden_nodes


Ignore:
Timestamp:
Jun 23, 2015, 10:04:58 PM (9 years ago)
Author:
murphpo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 802.11/wlan_exp/app_notes/dcf_with_hidden_nodes

    v14 v15  
    33= Investigating Hidden Nodes and RTS/CTS Access =
    44
    5 The [https://en.wikipedia.org/wiki/Hidden_node_problem Hidden Node Problem] is a classic topology studied in wireless networking where traditional carrier sensing breaks down since one or more nodes are "hidden" from the carrier sensing capability of the rest of the network.
     5The [https://en.wikipedia.org/wiki/Hidden_node_problem Hidden Node Problem] is a classic topology studied in wireless networking where the arrangement of nodes prevents traditional carrier sensing from protecting against collisions. In a simple hidden node topology a central node has a high SNR link with two other nodes, but these other nodes are too far apart to detect the other's transmissions. Transmissions by these "hidden" nodes will frequently collide when physical carrier sensing is unable to infer a busy medium at the central node.
    66
    7 ||  [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_hidden_nodes/figs:hidden_node.png, width=800)]]  ||
     7||  [[Image(wiki:802.11/wlan_exp/app_notes/dcf_with_hidden_nodes/figs:hidden_node_topology.png, width=800)]]  ||
    88||  '''Classic Hidden Node Topology'''  ||
    99
    10 As we have seen in the [wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows multiflow app note], carrier sensing plays a crucial role in the DCF's ability deal with contention in a shared wireless medium. In the classic hidden node topology shown above, STA 1 can carrier sense the AP and vice versa. STA 2 can carrier sense the AP and vice versa. However, STA 1 and STA 2 are out of range of one another and cannot detect each other's transmissions. The traditional solution to this problem is the [https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS RTS/CTS handshake]. The basic timeline of this handshake is as follows:
     10As we have seen in the [wiki:802.11/wlan_exp/app_notes/dcf_with_multiple_flows multiflow app note], carrier sensing plays a crucial role in the DCF's ability deal with contention in a shared wireless medium. In the classic hidden node topology shown above, STA 1 can carrier sense during transmissions by the AP, and vice versa. Likewise STA 2 and the AP can detect each other's transmissions. However STA 1 and STA 2 are out of range of one another and cannot detect each other's transmissions.
    1111
    12 1. STA 1 wishes to send a data MPDU to the AP. Since STA 2 cannot directly hear this transmission, the likelihood of a collision might be large. Instead, STA 1 "requests to send" the MPDU by sending a very short RTS frame to the AP. This transmission may still collide, but it is very short, so the penalty to lost medium time is significantly mitigated.
    13 1. When the AP receives this RTS frame, it checks the medium by looking at its NAV. If the NAV says the medium is clear, it sends the "clear to send" CTS frame in response. Critically, this CTS frame contains a duration field that species how long the medium will be occupied for the upcoming MPDU and ACK transmissions.
    14 1. Since STA 2 is within the transmission range of the AP, it overhears this CTS transmission and updates it NAV for the entire duration specified in the CTS frame. This will prevent STA 2 from colliding with the upcoming MPDU transmission from STA 1.
    15 1. Finally, STA 1 receives this CTS message and begins the transmission of the actual MPDU. This MPDU is now protected from collisions from anyone who overheard the AP's CTS transmission.
     12The 802.11 MAC design uses virtual carrier sensing and the [https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS RTS/CTS handshake] to address the hidden node problem. The basic timeline of the RTS/CTS handshake is:
    1613
    17 RTS/CTS support was added in [wiki:../../../Changelog#a1.3Release 802.11 Reference Design (version v1.3)]. In this application note, we'll use the reference design and its [wiki:802.11/wlan_exp experiments framework] to investigate the hidden node problem.
     141. STA 1 wishes to send a data packet (MPDU) to the AP. STA 1 "requests to send" the MPDU by sending a very short RTS frame to the AP. This RTS transmission may still collide with a transmission by STA 2, but the RTS payload is very short, so the cost of losing the RTS is much less than losing the MPDU.
     151. When the AP receives this RTS frame, it checks the medium by looking at its NAV. If the NAV says the medium is clear, it sends the "clear to send" CTS frame in response. This CTS frame contains a duration field that species how long the medium will be occupied for the upcoming MPDU and ACK transmissions. The AP derives this duration value from the duration field in the RTS is received from STA 1.
     161. Since STA 2 is within the transmission range of the AP, it receives this CTS transmission and updates it NAV for the entire duration specified in the CTS frame. The non-zero NAV will prevent STA 2 from transmitting during the subsequent MPDU transmission by STA 1, avoiding an expensive collision.
     171. Finally, STA 1 receives this CTS message and begins the transmission of the actual MPDU. This MPDU is now protected from collisions from anyone who received the RTS or CTS transmissions.
     18
     19We added support for the standard RTS/CTS handshake in [wiki:../../../Changelog#a1.3Release 802.11 Reference Design v1.3]. In this application note, we'll use the reference design and its [wiki:802.11/wlan_exp experiments framework] to demonstrate the hidden node problem and measure the impact of using the RTS/CTS handshake.
    1820
    1921== Table of Contents ==
    … …  
    22241. [#TxRxLogResults Tx/Rx Log Results]
    23251. [#AHeuristicExtension A Heuristic Extension]
    24 
    2526
    2627= Experimental Setup =