Medium Access Control Protocols | Jason Fantl<br>Jason Fantl<br>A computer science blog

HOME CATEGORIES ARCHIVES ABOUT SUBSCRIBE

Home Medium Access Control Protocols Post<br>Cancel

Medium Access Control Protocols<br>Posted May 13, 2026 Updated May 30, 2026<br>By Jason Fantl 43 min read

Introduction<br>A medieval General is using messengers to communicate with his regiments, but he finds that using people to send messages is slow. After thinking, he realizes he could use drums for communication. Every regiment learns their distinct drum patterns to send reports and listen for commands. But in practice, the General finds that two regiments will often start drumming over each other and he is unable to decipher the message. This is because the regiments might start drumming at the same time, or one regiment won’t hear that the other is already drumming when they start. The potential for overlapping signals means the General won’t always understand the message, and the regiments can’t know if the General heard their message. How can the General prevent such costly communication failures?<br>Solutions to this type of problem are known as Medium Access Control (MAC) protocols, and are critical to the function of all modern digital communications. Instead of drums, we use radio waves, but the idea is the same. Our WiFi, cellular, and Bluetooth devices must all solve this problem. Because they operate under different constraints, they each solve it in a slightly different way.<br>Before we look at modern communications, let us travel back to 1969 to the islands of Hawai’i and discover how the first wireless computer network solved this issue.<br>ALOHA<br>On the island of Oʻahu, the main campus of the University of Hawai’i hosted a powerful IBM computer. Nearby community colleges wanted to connect to this powerful computer, but unfortunately these colleges sat on separate islands. Laying down a cable to create a point-to-point network, like the experimental ARPAnet of the time, would have been expensive. So, they decided to use this as the perfect excuse to research implementing a wireless computer network.<br>Thus was born the ALOHAnet.<br>The goal was fairly simple: enable all the islands to communicate with the IBM machine at the same time. This meant a radio on every island, each trying to communicate with the base station.

One big issue presented itself: If two islands tried to communicate with the base station at the same time, their radio signals would overlap and become indecipherable, exactly the issue our General struggled with when listening to multiple regiments at once.<br>This is where we introduce the first MAC protocol, today known as Pure ALOHA.<br>Take a moment to try and solve the problem yourself. How could the regiments minimize collisions, or at least make sure their message was heard by the General? Later we will see how WiFi solves this issue using a single communication channel, but ALOHA had it easier since it used two frequencies for its protocol. In our army metaphor this can be represented as being able to use both drums and horns, where different instruments can each communicate without interfering with the other instruments.<br>Below is the description for Pure ALOHA, the first-ever, random-access MAC protocol for a wireless computer network.<br>Pure ALOHA<br>When you have a message to send, immediately send it. This may collide with someone else, so you need to get back an acknowledgement from the base station (the General) confirming they got your message. We might worry that the acknowledgement message could collide with another message being sent at the same time, but ALOHA uses two frequencies: one for sending messages to the base station, and the other for sending messages from the base station, so the base station’s acknowledgment will not collide with incoming messages. This also means that when the base station sends you information, it doesn’t need an acknowledgement back.<br>If you don’t get back the acknowledgment (called an ACK) in a short timeframe, try sending the message again. But we need to be careful here. Imagine everyone immediately tries to resend their messages after they fail; what would happen? Two users who just interfered with each other would immediately resend and interfere again! And this would repeat forever. To solve this, you need to wait a random amount of time before resending the message. Eventually, by chance, messages will stop colliding (as long as there aren’t too many stations). In the original paper the authors sample their random delay from an exponential distribution, but later we will see how this can be improved.<br>Below is a simulation of Pure ALOHA with three stations talking to a base station. Stations will begin a backoff immediately after sending a message, with a minimum delay to allow for an ACK to be sent back, in which case they cancel their backoff.<br>We denote a message being sent from a station as a colored bar with full height, and a message being heard as a bar at half height. A...