Changes between Version 11 and Version 12 of 802.11/MAC/Support_HW

Timestamp:

Apr 18, 2016, 10:12:40 AM (8 years ago)

Author:

murphpo

Comment:

--

802.11/MAC/Support_HW

@@ -54 +54 @@
 == MAC Tx Controller A ==
 
-Tx Controller A is capable of honoring a post-Tx timeout interval in which a reception is expected by the MAC state.
-
-The DCF implementation uses Tx Controller A for three transmission scenarios:
+Tx Controller A is capable of honoring a post-Tx timeout interval during which the MAC expects an immediate response to its transmission. The DCF implementation uses Tx Controller A for three transmission scenarios:
 
 1. Transmission of MPDU frames which do not require RTS ("short" frames)
@@ -163 +161 @@
  * postTxTimer1_done: postTx_Timer1 has expired
  * postTxTimer2_done: postTx_Timer2 has expired
- * backoff_done: The backoff counter has reached zero
+ * backoff_A_done: The A backoff counter has reached zero
  * idle_for_difs: The medium has been idle for a DIFS interval
  * phy_tx_done: The Tx PHY has finished transmitting
@@ -191 +189 @@
 == MAC Tx Controller B ==
 
-The Tx Controller B is simpler than Tx Controller A. After a transmission is complete, the controller is done and does not need to start any kind of post-Tx timeout interval. Optionally, Tx Controller B can condition its transmission on medium idleness. The DCF implementation uses this controller for two purposes:
-
-1. Transmission of CTS frames
-1. Transmission of ACK frames
-
-Both of the above transmissions have the common trait of being "fire and forget." They are slightly different from one another in that ACK frames must be transmitted regardless of perceived medium busyness. This is not the case for CTS frames, which are only sent when the medium is deemed idle.
+Tx Controller B is a simpler state machine that can schedule its transmission relative to post Tx/Rx timers. The reference DCF implementation uses Tx Controller B for two transmissions:
+
+1. Transmission of CTS frames a SIFS after an RTS Rx
+1. Transmission of ACK frames a SIFS after a DATA Rx
+
+This controller is unique in being able to cancel its transmission based on the node's NAV value. This behavior is required when transmitting a CTS frame. When the DCF receives an RTS it schedules a CTS transmission a SIFS interval later. However if the NAV is non-zero at the end of the SIFS, the CTS frame is not transmitted.
 
 === Implementation Details ===
-
-[[Image(tx_core_b.png, width=1000)]]
-
-Like Tx Controller A, the green section of the above state machine forces the controller to wait for a deterministic amount of time prior to a transmission. The DCF uses this to schedule CTS and ACK transmissions a SIFS interval after the previous reception. The CTS case additionally instructs the controller to condition transmission on medium idleness.
+The Tx Controller B state machine is illustrated below. Each box is a state. Each arrow is a state transition, with the arrow's label specifying the input conditions that trigger the transition. The conditions for the color-coded arrows from the {{{IDLE}}} state are described in the table below.
+
+[[Image(tx_fsm_b.png)]]
+
+{{{#!th colspan=2 align=center
+'''Tx Controller B FSM - Transitions from {{{IDLE}}}'''
+}}}
+|-----------------------------------
+{{{#!td
+}}}
+{{{#!td align=left
+
+{{{#!c
+if(new_tx) {
+}}}
+
+}}}
+|-----------------------------------
+{{{#!td
+[[Image(tx_fsm_transition_1.png)]]
+}}}
+{{{#!td
+{{{#!c
+        if(pre_wait_for_postRxTimer1 | pre_wait_for_postRxTimer2 | pre_wait_for_postTxTimer1 ) {
+                //Tx fixed interval after previous Tx/Rx
+                // Ignore medium and backoff states
+                st_next = ST_PRE_TX_WAIT;
+}}}
+}}}
+|-----------------------------------
+{{{#!td
+[[Image(tx_fsm_transition_2.png)]]
+}}}
+{{{#!td
+
+{{{#!c
+        } else {
+                // Transmit immediately
+                st_next = ST_DO_TX;
+}}}
+}}}
+|-----------------------------------
+{{{#!td
+
+}}}
+{{{#!td
+
+{{{#!c
+} else {
+        //No new Tx this cycle; keep waiting in IDLE
+        st_next = ST_IDLE;
+}
+}}}
+
+}}}
+
+Notice that the state transitions depend on the postRx_Timer1 (SIFS timer). The state machine can also be conditioned on postRx_Timer2 and postTx_Timer1 for other MAC protocol extensions.
+
+Inputs from software:
+ * reset: Forces FSM back to {{{IDLE}}} state
+ * new_tx: Triggers new execution of FSM
+ * req_nav_zero: Require NAV be zero at time of Tx, cancel Tx otherwise
+ * pre_wait_for_postRxTimer1: Wait before Tx until postRx Timer 1 is done
+ * pre_wait_for_postRxTimer2: Wait before Tx until postRx Timer 2 is done
+ * pre_wait_for_postTxTimer1: Wait before Tx until postTx Timer 1 is done
+
+Inputs from MAC hardware:
+ * nav_nonzero: NAV is nonzero
+ * postRxTimer1_done: postRx Timer 1 is done
+ * postRxTimer2_done: postRx Timer 2 is done
+ * postTxTimer1_done: postTx Timer 1 is done
+ * phy_tx_done: PHY Tx has completed
+
+The lower MAC framework provides macros for configuring the software parameters above:
+{{{#!c
+// Configure Tx Controller B
+//  pktBuf: Tx packet buffer index (passed directly to PHY at TX_START)
+//  antMask: antenna selection mask  (passed directly to PHY at TX_START)
+//  req_zeroNAV: require NAV=0 at Tx time, must be 0 or 1
+//  preWait_postRxTimer1: param for FSM, must be 0 or 1
+//  preWait_postRxTimer2: param for FSM, must be 0 or 1
+//  preWait_postTxTimer1: param for FSM, must be 0 or 1
+wlan_mac_tx_ctrl_B_params(pktBuf, antMask, req_zeroNAV, preWait_postRxTimer1, preWait_postRxTimer2, preWait_postTxTimer1);
+}}}
+
+The Tx Controller B state machine is started by toggling its enable bit in the MAC support core's register bank:
+{{{#!c
+// Start Tx Controller B
+wlan_mac_tx_ctrl_B_start(1);
+wlan_mac_tx_ctrl_B_start(0);
+}}}
+
+The Tx Controller B state machine is implemented as an m-code block in the {{{wlan_mac_hw}}} core. The m source code is in the repository at [browser:/ReferenceDesigns/w3_802.11/sysgen/wlan_mac_hw/mcode_blocks/mac_tx_ctrl_b_fsm.m mac_tx_ctrl_b_fsm.m]