Distributed Coordination Function (DCF)

The 802.11 DCF is responsible for many behaviors. These actions include (but are not limited to):

• Acknowledging good receptions
• Retransmitting failed transmissions
• Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA)
• Binary Exponential Backoff (BEB)

The purpose of this document is not to explain or defend aspects of the DCF. Instead, this document is to aid in the understanding of how the standard DCF behavior is realized within the Mango 802.11 Reference Design. This document is intended to be read alongside the actual wlan_mac_dcf.c​ and wlan_mac_low.c​ code themselves.

Rather than structure this documentation as a function-by-function pseudocode equivalent to the above-linked codebases, we will instead approach the documentation from the perspective of two different roles: MPDU transmission and MPDU reception. There is overlap between these roles in what functions they execute (e.g., MPDU transmission still has an element of frame reception to deal with acknowledgments).

MPDU Transmission

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.

P1:

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.

Pseudocode:

	if

MPDU Reception