Tutorial: Building a Completely Custom MAC

A major feature of the 802.11 Reference Design is its compliance to the 802.11 standard to enable interaction with commercial Wi-Fi devices. This is the design in its "reference" state -- a known quantity that is intended to be modified to suit the needs of research applications. In our other app notes, we made small modifications to the design and characterized how those design changes manifested using the WLAN Experiments Framework. Ultimately, however, those design changes were small and the design you ended up with was a mildly tweaked 802.11 implementation.

This application note is fundamentally different -- we will build a completely non-standard MAC from scratch and use the WLAN Experiments Framework to characterize our novel design. The intent of this application note is to act as a tutorial. It is a step-by-step example of how to build something that really does not even resemble the standard 802.11 MAC. In fact, the MAC we will build in this tutorial is really the philosophical opposite to the 802.11 Distributed Coordination Function (DCF). The DCF is the classical example of a random access MAC. In this tutorial, we will build a simple scheduled access MAC that we call "TokenMAC."

Overview of TokenMAC

The entire purpose of a MAC is to figure out a way that a shared wireless medium can be split up amount multiple competing devices. The standard 802.11 DCF employs two classic techniques to achieve this goal:

1. ​Binary Exponential Backoff - Devices should randomly dither their transmission times to reduce the likelihood they transmit at the same time as another device. In the event of a failed transmission, a device should increase the average wait time before the next transmission. The result is that a large network of many competitors inherently reduces the rate at which each competitor contends for the medium.
2. ​Carrier Sense Multiple Access - Devices should listen for the transmissions of competitors and defer their own transmissions to any ongoing transmissions of others.

These two simple ideas form the crux of the entire 802.11 DCF. It's worth noting that these two concepts are often conflated but they are logically distinct. ​ALOHAnet employed a backoff mechanism in 1971 prior to the development of CSMA. The basic idea of the DCF is to employ randomness to resolve collisions. Devices will never deadlock and continually collide. The random access structure of the DCF ensures that one device will eventually win. Additionally, the protocol tweaks the parameters of the random variables as a function of its estimation on how much contention is present in the network at any point in time. When a network load is busy, each device actively reduces the likelihood of collisions by transmitting less often. When the network load is light, devices become more aggressive in the access of the shared channel in order to reduce overhead.

In this tutorial, we will implement a completely different kind of MAC based on ​the token ring. This MAC does not use randomness to avoid collisions but rather explicitly allows only a single transmitter at a time by passing around a token that authorizes transmissions. This is a form a scheduled access MAC (as opposed to a random access MAC).

TokenMAC avoids contention not through randomness, but rather through explicit token passing from a managing Access Point (AP).

In this tutorial, we will modify the role of an Access Point (AP) to include the responsibility of managing which device on its network has a token and is permitted to transmit.