802.11 Reference Design
- Download
- Changelog
- FAQ
- Architecture
Using the Design...
Benchmarks
- IFS Calibration
- Throughput
- Transmitter Characterization
- Receiver Characterization
- Pkt. Det. Min. Power Characterization
MAC
- PHY
Experiments Framework...
- Packet Flow
- FPGA Architecture
- FPGA Resource Usage
- App Notes
- Other Resources
- License
- Changelog
MAC Support Core
The software implementation of the lower-level MAC in CPU Low operates in real time. A key requirement of the lower-level MAC is to monitor the medium and react to Tx and Rx events on precise time boundaries relative to medium events. In order to simplify the MAC software implementation we use a small core in the FPGA. This core implements various timers and simple state machines which facilitate real-time operation of the lower-level MAC.
The MAC support core is not a fixed DCF implementation. All behaviors in the MAC core are defined by software. The primitives implemented in the core enable our DCF implementation, but the same primitives can be used for a wide variety of specialized MAC protocols.
The core is named wlan_mac_hw and is designed in System Generator. The source model is in the repository at /ReferenceDesigns/w3_802.11/sysgen/wlan_mac_hw.
A few of the key subsystems in the wlan_mac_hw core are described in detail below.
Post Tx/Rx Timers
Many MAC algorithms require precise scheduling of transmissions relative to some preceding transmission or reception event. Examples in the DCF include the following:
- ACK and CTS transmissions must occur a SIFS period after previous qualified receptions
- Contention windows must begin a timeout interval after a previous unsuccessful transmission
The wlan_mac_hw core implements dedicated post Tx/Rx timers. There are 4 times total, 2 each for post-Tx and post-Rx. The timers start automatically following Tx/Rx event. The timer durations are programmed from software in CPU Low. When a timer expires it can trigger Tx events via the Tx Controllers described below.
The MAC Low Framework provides macros for configuring the 4 timers and checking whether a timer is currently running:
// Set the "count to" value for the post Tx/Rx timers // Argument d is in units of 100nsec wlan_mac_set_postTx_timer1(d); wlan_mac_set_postTx_timer2(d); wlan_mac_set_postRx_timer1(d); wlan_mac_set_postRx_timer2(d); // Enable/Disable post Tx/Rx timers // Argument x should be 0 (disable) or 1 (enable) // A timer only runs if it is enabled and has a non-zero "count to" value wlan_mac_postTx_timer1_en(x); wlan_mac_postTx_timer2_en(x); wlan_mac_postRx_timer1_en(x); wlan_mac_postRx_timer2_en(x); // Check if a post Tx/Rx timer is running wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTTX_TIMER1_RUNNING; wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTTX_TIMER2_RUNNING; wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTRX_TIMER1_RUNNING; wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTRX_TIMER2_RUNNING;
The reference DCF implementation uses two timers:
- postTx_timer2: timeout timer, indicates timeout following RTS and DATA transmissions
- postRx_timer1: SIFS timer, triggers CTS/DATA/ACK Tx following RTS/CTS/DATA receptions
MAC Core Tx Controllers
A key function of the lower MAC is implementing the MAC protocol's transmit state machines. The MAC protocol defines when packets can be transmitted. For example the DCF requires an ACK transmission a SIFS interval after receiving a DATA packet. The DCF also requires a random backoff period before an RTS or DATA transmission if the medium was recently busy.
The wlan_mac_hw core implements 4 transmit state machines to facilitate these various protocol requirements. The 4 Tx controllers differ in their state machine inputs/outputs, each tailored to a different MAC protocol task. Each controller is configured from software.
Our reference DCF implementation requires 4 Tx state machines to implement the worst-case event of 4 simultaneous packets "in flight" that occurs when:
- TX A: Unicast MPDU is deferring to medium activity
- TX D: Multicast packets buffered for DTIM overlap next TBTT, multicast Tx defers to beacon Tx
- TX C: Beacon Tx is required at TBTT, defers to ongoing Rx event
- TX B: ACK Tx
In this case all four Tx controllers have pending transmissions at the same time. The ACK Tx uses the PHY first (B), followed by the deferred Beacon (C), then the remaining DTIM multicast packets (D), then finally the deferred unicast packet (A).
MAC Tx Controller A
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:
- Transmission of MPDU frames which do not require RTS ("short" frames)
- Transmission of RTS frames
- Transmission of "long" MPDU frames following reception of a CTS
Implementation Details
The Tx Controller A 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.
Tx Controller A FSM - Transitions from IDLE | |
---|---|
if(new_tx) { | |
if(wait_for_postRxTimer1 | wait_for_postTxTimer1) { //Tx fixed interval after previous Tx/Rx // Ignore medium and backoff states st_next = ST_PRE_TX_WAIT; | |
} else if(backoff_A_done & idle_for_difs) { //Previous backoff already finished, medium idle // Transmit immediately st_next = ST_DO_TX; | |
} else if(!backoff_A_done) { //Backoff already running - use it to defer st_next = ST_DEFER; | |
} else if(backoff_A_done & !idle_for_difs) { //No backoff running, but medium is busy // Start new backoff st_next = ST_START_BO; } | |
} 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) and postTxTimer2 (timeout timer), as discussed above.
The Tx Controller A state machine depends on various input signals. These inputs are either parameters set by the MAC software or signals driven by other parts of the MAC support core.
Inputs from software:
- reset: Forces FSM back to IDLE state
- new_tx: Triggers new execution of FSM
- pre_wait_postRxTimer1: Wait for postRx_Timer1 before transmitting
- pre_wait_postTxTimer1: Wait for postTx_Timer1 before transmitting
- post_wait_postTxTimer2: Wait for postTx_Timer2 after transmitting
Inputs from MAC hardware:
- postRxTimer1_done: postRx_Timer1 has expired
- postTxTimer1_done: postTx_Timer1 has expired
- postTxTimer2_done: postTx_Timer2 has expired
- 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
- phy_rx_start: The Rx PHY has detected a new reception
The lower MAC framework provides macros for configuring the software parameters above:
// Configure Tx Controller A // pktBuf: Tx packet buffer index (passed directly to PHY at TX_START) // antMask: antenna selection mask (passed directly to PHY at TX_START) // preTx_backoff_slots: number of backoff slots (passed to backoff counter in START_BO state) // preWait_postRxTimer1: param for FSM, must be 0 or 1 // preWait_postTxTimer1: param for FSM, must be 0 or 1 // postWait_postTxTimer2: param for FSM, must be 0 or 1 // phy_mode: Tx PHY mode, 1 for NONHT, 2 for HTMF wlan_mac_tx_ctrl_A_params(pktBuf, antMask, preTx_backoff_slots, preWait_postRxTimer1, preWait_postTxTimer1, postWait_postTxTimer2, phy_mode);
The Tx Controller A state machine is started by toggling its enable bit in the MAC support core's register bank:
// Start Tx Controller A wlan_mac_tx_ctrl_A_start(1); wlan_mac_tx_ctrl_A_start(0);
Finally the backoff counter for Tx Controller A can be paused from software via the code below. The backoff counter must be paused when another Tx controller with higher priority is started (i.e. when a Beacon Tx must occur while an MPDU Tx defers).
// Pause Tx Controller A backoff counter wlan_mac_pause_backoff_tx_ctrl_A(1); // Verify Tx A backoff is paused - must check after asserting Pause in case backoff just expired u32 mac_tx_ctrl_status; mac_tx_ctrl_status = wlan_mac_get_tx_ctrl_status(); if( ((mac_tx_ctrl_status & WLAN_MAC_TXCTRL_STATUS_MASK_TX_A_STATE) == WLAN_MAC_TXCTRL_STATUS_TX_A_STATE_DEFER) || ((mac_tx_ctrl_status & WLAN_MAC_TXCTRL_STATUS_MASK_TX_A_STATE) == WLAN_MAC_TXCTRL_STATUS_TX_A_STATE_IDLE) ) { // Backoff paused successfully - handle higher-priority Tx here ... } // Resume Tx Controller A backoff counter wlan_mac_pause_backoff_tx_ctrl_A(0);
The Tx Controller A state machine is implemented as an m-code block in the wlan_mac_hw core. The m source code is in the repository at mac_tx_ctrl_a_fsm.m
MAC Tx Controller B
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:
- Transmission of CTS frames a SIFS after an RTS Rx
- 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
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.
Tx Controller B FSM - Transitions from IDLE | |
---|---|
if(new_tx) { | |
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; | |
} else { // Transmit immediately st_next = ST_DO_TX; | |
} 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:
// 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 // phy_mode: Tx PHY mode, 1 for NONHT, 2 for HTMF wlan_mac_tx_ctrl_B_params(pktBuf, antMask, req_zeroNAV, preWait_postRxTimer1, preWait_postRxTimer2, preWait_postTxTimer1, phy_mode);
The Tx Controller B state machine is started by toggling its enable bit in the MAC support core's register bank:
// 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 mac_tx_ctrl_b_fsm.m
MAC Tx Controllers C and D
Tx Controllers C and D implement identical state machines. The C/D state machine is designed to support transmission of packets which do not require timeouts and re-transmissions. In our reference DCF implementation Tx C is used for Beacon frames and Tx D is used for multicast frames buffered between DTIM intervals. Beacon and DTIM multicast transmissions are unique in that they can occur in between re-transmissions of other MPDUs. The reference DCF implementation uses Tx Controller A for MPDU transmissions, so separate controllers (Controller C and D) are required to support Beacon and multicast DTIM transmissions.
The logic for Tx Controllers C and D each include a dedicated backoff counter, independent of the backoff counter implemented for Tx Controller A. These dedicated backoff counters are required to allow beacon and DTIM multicast transmissions which defer to medium activity without overriding the state of primary backoff counter. This behavior is especially important in ad hoc (IBSS) networks where every node transmits beacons after random delays, with each node canceling its own beacon Tx if it receives a beacon from a peer in the same beacon interval.
Implementation Details
The Tx Controller C/D 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. The MAC core implements separate instances of this state machine for Tx Controllers C and D.
Tx Controller C/D FSM - Transitions from IDLE | |
---|---|
if(new_tx) { | |
if(idle_for_difs & !require_backoff) { //Medium idle, no backoff required // Transmit immediately st_next = ST_DO_TX; | |
} else { // Busy medium, or backoff required; start backoff st_next = ST_START_BO; | |
} else { //No new Tx this cycle; keep waiting in IDLE st_next = ST_IDLE; } |
Inputs from software:
- reset: Forces FSM back to IDLE state
- new_tx: Triggers new execution of FSM
- require_backoff: Always start backoff pre-Tx
Inputs from MAC hardware:
- backoff_C_done: Previously started backoff has completed
- idle_for_difs: Medium as been idle >= T_DIFS
- phy_tx_done: PHY Tx has completed
The lower MAC framework provides macros for configuring the software parameters above:
// Configure Tx Controller C and D // pktBuf: Tx packet buffer index (passed directly to PHY at TX_START) // antMask: antenna selection mask (passed directly to PHY at TX_START) // req_backoff: require a backoff before this Tx, must be 0 or 1 // phy_mode: Tx PHY mode (1 for NONHT, 2 for HTMF) // num_slots: number of backoff slots, if this FSM starts the C backoff counter // Tx Controller C wlan_mac_tx_ctrl_C_params(pktBuf, antMask, req_backoff, phy_mode, num_slots); // Tx Controller D wlan_mac_tx_ctrl_D_params(pktBuf, antMask, req_backoff, phy_mode, num_slots);
The Tx Controller C/D state machine is started by toggling its enable bit in the MAC support core's register bank:
// Start Tx Controller C wlan_mac_tx_ctrl_C_start(1); wlan_mac_tx_ctrl_C_start(0); // Start Tx Controller D wlan_mac_tx_ctrl_D_start(1); wlan_mac_tx_ctrl_D_start(0);
Finally the backoff counter for Tx Controllers C and D can be paused from software via the code below. The backoff counter must be paused when another Tx controller with higher priority is started.
// Code below pauses/checks/resumes Tx C backoff // Replace "C" with "D" in macros to control Tx D backoff // Pause Tx Controller C backoff counter wlan_mac_pause_backoff_tx_ctrl_C(1); // Verify Tx C backoff is paused - must check after asserting Pause in case backoff just expired u32 mac_tx_ctrl_status; mac_tx_ctrl_status = wlan_mac_get_tx_ctrl_status(); if( ((mac_tx_ctrl_status & WLAN_MAC_TXCTRL_STATUS_MASK_TX_C_STATE) == WLAN_MAC_TXCTRL_STATUS_TX_C_STATE_DEFER) || ((mac_tx_ctrl_status & WLAN_MAC_TXCTRL_STATUS_MASK_TX_C_STATE) == WLAN_MAC_TXCTRL_STATUS_TX_C_STATE_IDLE) ) { // Backoff paused successfully - handle higher-priority Tx here ... } // Resume Tx Controller C backoff counter wlan_mac_pause_backoff_tx_ctrl_C(0);
The Tx Controller C/D state machine is implemented as an m-code block in the wlan_mac_hw core. The m source code is in the repository at mac_tx_ctrl_cd_fsm.m
Attachments (7)
- tx_fsm_transition_1.png (1.7 KB) - added by murphpo 8 years ago.
- tx_fsm_transition_2.png (1.7 KB) - added by murphpo 8 years ago.
- tx_fsm_transition_3.png (1.9 KB) - added by murphpo 8 years ago.
- tx_fsm_transition_4.png (1.8 KB) - added by murphpo 8 years ago.
- tx_fsm_a.png (59.7 KB) - added by murphpo 8 years ago.
- tx_fsm_b.png (32.5 KB) - added by murphpo 8 years ago.
- tx_fsm_cd.png (23.5 KB) - added by murphpo 8 years ago.
Download all attachments as: .zip