Changes between Version 8 and Version 9 of 802.11/MAC/Lower/DCF
- Timestamp:
- Aug 7, 2015, 4:17:43 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
802.11/MAC/Lower/DCF
v8 v9 22 22 [[Image(wiki:802.11/files:mpdu_tx.png, width=800)]] 23 23 24 From the DCF's perspective, a new MPDU transmission begins when an IPC message arrives from CPU_HIGH with a payload that must be sent. The origin of this payload is irrelevant - it might be an encapsulated Ethernet frame, or it might be a beacon created by the Access Point (AP) project, or it might even be a LTG frame. Those are all concerns of CPU_HIGH. All we care about, in this project, is that there are bytes that must be sent and certain actions may possibly be required of us to modify those bytes (e.g. timestamp insertion in a beacon transmission). The above figure is labeled with {{{P1}}}, {{{P2}}}, and {{{P3}}}. These are generic labels for "processing blocks" and each will be explained below alongside pseudocode the represents the behavior.24 From the DCF's perspective, a new MPDU transmission begins when an IPC message arrives from CPU_HIGH with a payload that must be sent. The origin of this payload is irrelevant - it might be an encapsulated Ethernet frame, or it might be a beacon created by the Access Point (AP) project, or it might even be a LTG frame. Those are all concerns of CPU_HIGH. In CPU_LOW, all that matters is that there are bytes that must be sent and certain actions may possibly be required of us to modify those bytes (e.g. timestamp insertion in a beacon transmission). 25 25 26 ''' P1:'''26 '''IPC Message from CPU_HIGH: MPDU Ready''' 27 27 28 28 When an IPC message arrives, the MAC Low Framework needs to perform a few different actions before passing the frame off to the DCF for transmission. … … 46 46 ---- 47 47 48 ''' P2:'''48 '''frame_transmit()''' 49 49 50 The {{{frame_transmit()}}} needs to do a lot. It is safe to say that the function is certainly the most complex part of the DCF and, perhaps, even the entire 802.11 Reference Design. In no particular order, the function needs to:50 The 802.11 DCF Tx state machine is complex. The implementation of frame_transmit() reflects much of this complexity. In no particular order, the function needs to: 51 51 52 52 * draw a random backoff according to the binary exponential backoff … … 64 64 Pseudocode: 65 65 {{{ 66 continue_retries = 166 continue_retries = True 67 67 while( continue_retries ) 68 68 if( mpdu is long ) … … 81 81 reset contention windows and counters 82 82 start backoff 83 continue_retries = 083 continue_retries = False 84 84 85 85 case Rx has started: … … 88 88 reset contention windows and counters 89 89 start backoff 90 continue_retries = 190 continue_retries = True 91 91 92 92 if ( Rx was CTS and we were waiting on CTS ) … … 97 97 if ( other Rx ) 98 98 increment counters and contention window 99 continue_retries = 199 continue_retries = True 100 100 101 101 case Timeout has occurred: 102 102 increment counters and contention window 103 continue_retries = 1103 continue_retries = False 104 104 105 105 while( MAC support core is pending ) … … 109 109 110 110 111 ''' P3:'''111 '''frame_receive()''' 112 112 113 The {{{frame_receive()}}} function, when called from the context of the above frame_transmit function ({{{P2}}}block), should perform two tasks:113 The {{{frame_receive()}}} function, when called from the context of the above {{{frame_transmit()}}} function block), should perform two tasks: 114 114 115 115 * If the received frame is a good FCS ACK that is addressed to this node, it should raise a flag in its return value stating this … … 143 143 MPDU reception is considerably simpler than transmission. The DCF software is responsible for polling the PHY Rx by calling the {{{wlan_mac_low_poll_frame_rx()}}} function in the MAC Low Framework. 144 144 145 '''P 1:'''145 '''PHY Rx Poll''' 146 146 147 147 The {{{wlan_mac_low_poll_frame_rx()}}} function reads the status registers from the PHY and converts that information into a {{{phy_rx_details}}} structure that contains the following: … … 172 172 ---- 173 173 174 In the DCF, the {{{frame_rx_callback()}}} is attached to the {{{frame_receive()}}} function. In the above MPDU transmission state, we have already seen some executions of this function to deal with the receptions of ACK and CTS frames. Independently of these actions, the {{{frame_receive()}}} function needs to pass receptions up to CPU_HIGH and, if needed, generated acknowledgment responses.174 In the DCF, the {{{frame_rx_callback()}}} is attached to the {{{frame_receive()}}} function. In the above MPDU transmission state, we have already seen some executions of this function to deal with the receptions of ACK and CTS frames. Independently of these actions, the {{{frame_receive()}}} function needs to pass receptions up to CPU_HIGH and, if needed, generated control frame responses (i.e. ACK and CTS frames). 175 175 176 176 Pseudocode: … … 182 182 if( FCS good ) 183 183 configure MAC support core to send ACK after SIFS interval 184 case ACK: 185 wait for FCS 186 if( FCS good ) 187 configure MAC support core to send CTS after SIFS interval 184 188 185 189 if( frame passes CPU_LOW filter )
