{{{#!comment
[[Include(wiki:802.11/beta-note)]]
}}}

[[TracNav(802.11/TOC)]]

= 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 [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_low_dcf/wlan_mac_dcf.c wlan_mac_dcf.c] and [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_low_framework/wlan_mac_low.c 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 ==

[[Image(wiki:802.11/files:mpdu_tx.png, width=800)]]

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:
{{{
convert high-level MCS/rate into PHY-understandable rate parameter
	
if( insert duration )
	calculate duration of SIFS and ACK
	insert duration into MAC header

if ( insert timestamp )
	tell PHY Tx which bytes to overwrite with usec timestamp

call the frame_tx_callback()
}}}

For the DCF application, the {{{frame_tx_callback()}}} executes the {{{frame_transmit()}}} function in the DCF code.

----

'''P2:'''

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:

* draw a random backoff according to the binary exponential backoff
* use the [wiki:802.11/MAC/Support_HW MAC Support Core] to transmit a frame that defers to the medium
* if needed, send an RTS instead of the data itself to reserve the medium
* if needed, look out for a response frame (i.e. a CTS from a transmitted RTS or an ACK from a transmitted data frame)
* if needed, handle a timeout and implement the complex [wiki:802.11/MAC/Lower/Retransmissions retransmission behavior]

The {{{frame_transmit()}}} context will only exit when an MPDU is "done." Here, "done" can mean multiple things:

* a unicast frame that is acknowledged
* a unicast frame whose every retransmission attempt has failed
* any multicast frame has been transmitted (since multicast frames are, by definition, successful since they cannot be acknowledged)

Pseudocode:
{{{
continue_retries = 1
while( continue_retries )
	if( mpdu is long )
		load MAC support core with RTS
	else
		load MAC support core with MPDU

	draw a random backoff and set MAC support core (will only be used if medium is busy)

	start MAC support core Tx state machine

	do
		if( MAC support core is done )
			switch( MAC support core result )
				case immediate success (e.g., multicast):
					reset contention windows and counters
					start backoff
					continue_retries = 0

				case Rx has started:
					call frame_receive() and check return value
					if( Rx was ACK and we were waiting for ACK )
						reset contention windows and counters
						start backoff
						continue_retries = 1
					
					if ( Rx was CTS and we were waiting on CTS )
						frame_receive handled the MPDU Tx, so we should set
							the MAC support core status variable to pending explicitly
							so we do not fall out of the do-while

					if ( other Rx )
						increment counters and contention window
						continue_retries = 1

				case Timeout has occurred:
					increment counters and contention window
					continue_retries = 1
					
	while( MAC support core is pending )
	
	
}}}


'''P3:'''

The {{{frame_receive()}}} function, when called from the context of the above frame_transmit function ({{{P2}}} block), should perform two tasks:

* 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
* If the received frame is a good FCS CTS that is addressed to this node, it should raise a flag in its return value stating this. It should also start the transmission of the MPDU a SIFS interval after the reception is complete.

The [wiki:802.11/MAC/Support_HW MAC Support Core] is capable of transmitting a frame an arbitrary interval after the completion of a reception, so we can use this for sending the MPDU after receiving a CTS.

Pseudocode:
{{{

}}}


== MPDU Reception ==

[[Image(wiki:802.11/files:mpdu_rx.png, width=800)]]