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

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 this controller for three different purposes:

1. Transmission of "short" MPDU frames (i.e. MPDUs that required no RTS medium reservation)
2. Transmission of RTS frames
3. Transmission of "long" MPDU frames (i.e. MPDUs that were preceded by an RTS/CTS handshake)

The unifying trait of each of the above transmissions is the need for a post-Tx timeout window during which a response is expected.

Implementation Details

The above image gives a more detailed view on the state machine implemented in Tx Controller A. Prior to actually transmitting, the controller is capable of starting a backoff or deferring to an already running backoff when the medium is not idle. Alternatively, it can wait for a deterministic interval before transmitting. This interval is defined by either the postRxTimer1 or postTxTimer1 timers described above.

For the DCF implementation, short MPDU and RTS transmissions do not employ the green deterministic-wait state. These transmission do employ the purple and blue backoff deferral states. Long MPDU transmissions, however, must occur a deterministic SIFS interval after the previous CTS reception. As such, these transmissions use the green deterministic-wait states.

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
2. 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.

Implementation Details

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.