Why Wi-Fi Shouldn't Work (And Why It Does)
Picture a meeting room with thirty people in it. No chairs. No moderator. Nobody keeping order. Anyone can start talking whenever they feel like it, and — here's the annoying part — nobody can tell for certain whether they're being talked over while they're mid-sentence.
That's Wi-Fi.
That's genuinely how it works. There is no wire separating you from everyone else. Multiple devices share the same radio channel, your neighbours may be using that same channel, and nobody can guarantee that a transmission will make it to its destination on the first attempt.
And yet, I stream video calls over it. My whole house runs on it. Most days, I don't even think about it. Which is, honestly, a little suspicious.
So in this post, I want to slow down and actually explain what Wi-Fi is, where it came from, and how it pulls off this trick — a mechanism called CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance.
Because CSMA/CA is doing a lot more work than it gets credit for.
What is Wi-Fi, actually?
Here's a fun one to drop at a party: Wi-Fi isn't actually the name of the technology.
Wi-Fi is a brand and certification program operated by the Wi-Fi Alliance. The underlying technology is IEEE 802.11. When you see the Wi-Fi logo on a device, it means the device has been tested and certified against the relevant Wi-Fi specifications, helping ensure that devices from different manufacturers can actually talk to each other.
Underneath the branding, you can think of Wi-Fi as a wireless networking technology that provides many of the same networking functions you'd traditionally get from Ethernet — except the cable has been replaced by radio, operating in shared, license-exempt spectrum.
Two things about that matter for everything that follows:
The air is shared. Everyone within radio range is competing for access to the same channel. Your device doesn't get its own private piece of the air.
The spectrum is license-exempt, not unrestricted. There isn't an operator assigning you a slice of spectrum or centrally scheduling every transmission, as there is in a cellular network. Multiple devices and networks can use the same frequencies, provided they follow the applicable rules for power, channels, and spectrum access.
And that's where things start getting interesting…
Because if everyone is sharing the same piece of radio spectrum, the obvious question is: Who gets to talk and when?
A short history
1971, ALOHAnet
Researchers at the University of Hawaii had a problem: they needed to connect computers and terminals spread across the islands to a central computer, using radio. Norman Abramson's team came up with an idea that sounds almost embarrassingly simple: just transmit when you have something to send. If the packet doesn't make it, wait for a random amount of time and try again. It's crude. And it gets increasingly inefficient as more people start talking.
Pure ALOHA tops out at only about 18% theoretical channel utilization. But the important idea was born: multiple devices could share the same medium without a central controller, using randomness and retransmission to recover from collisions.
That idea would travel much further than anyone expected.
1973, Ethernet
At Xerox PARC, Bob Metcalfe and David Boggs took inspiration from ALOHAnet and adapted the concept to a wired local-area network. But they made an important improvement: listen before you talk.
If the cable is quiet, transmit. If you detect a collision while transmitting, stop and try again later.
That became CSMA/CD — Carrier Sense Multiple Access with Collision Detection. And this is where the story starts getting interesting for Wi-Fi.
On a cable, you can detect a collision while you're transmitting. Radio is a different problem entirely.
1985, the FCC opens the door
The U.S. Federal Communications Commission changed its Part 15 rules to allow spread-spectrum transmitters to operate without an individual user license in parts of the Industrial, Scientific and Medical (ISM) bands, including 902–928 MHz, 2.4 GHz and 5.8 GHz. That didn't create Wi-Fi. But it created an important piece of the environment in which wireless data networks could develop.
And yes, the 2.4 GHz band is also where your microwave oven operates — although microwave ovens and Wi-Fi use the band for very different purposes.
Late 1980s–1990s, WaveLAN
NCR wanted to connect cash registers to back-office computers without running cables through every store. Its research and development lab in Nieuwegein, the Netherlands, took on the problem. The result was WaveLAN, one of the important precursors to modern Wi-Fi. It was publicly demonstrated in 1990, and members of the NCR team went on to play an important role in the IEEE 802.11 standardization effort.
One of those people was Vic Hayes, who later chaired the IEEE 802.11 working group for many years.
1997, IEEE 802.11
The first IEEE 802.11 standard was published.
It wasn't anything like the Wi-Fi we know today. The original standard supported data rates up to 2 Mbps, with radio PHYs operating around 2.4 GHz. But one crucial piece was already there: CSMA/CA.
The mechanism at the heart of this entire story was built into 802.11 from the beginning.
1999, things take off
802.11b pushed the 2.4 GHz data rate to 11 Mbps. 802.11a introduced 5 GHz and up to 54 Mbps using OFDM.
The same year, the Wi-Fi Alliance was formed, and the Wi-Fi name began appearing on interoperable 802.11 products. Apple's AirPort helped push wireless networking into mainstream consumer computers.
And then things got ridiculous
2003 — 802.11g: up to 54 Mbps.
2009 — Wi-Fi 4 (802.11n): up to 600 Mbps.
2013 — Wi-Fi 5 (802.11ac): multi-gigabit theoretical rates.
2021 — Wi-Fi 6 (802.11ax): up to 9.6 Gbps.
Wi-Fi 6E: 802.11ax expanded into the 6 GHz band.
Wi-Fi 7 (802.11be): wider 320 MHz channels, Multi-Link Operation, 4096-QAM and a theoretical PHY rate in the tens of gigabits per second.
Every generation brought faster radios, better modulation, more antennas, wider channels and increasingly sophisticated ways of squeezing more bits through the same shared medium.
But here's the part I find fascinating: Through all of that evolution, the fundamental problem never went away. We're still sharing the air. And we're still trying to figure out who gets to talk next.
What never actually changed
All that speed came from smarter modulation, wider channels, more antennas, better coding, and some genuinely impressive engineering.
But one thing never moved an inch: Everyone is still sharing the same air.
There is no dedicated wire between every device. No permanent lane reserved for your packets. And no single controller that can simply tell every device exactly when it is allowed to transmit.
That's the fundamental problem Wi-Fi has to solve, over and over again, every time devices want to use the same channel. And it has to solve it incredibly quickly.
CSMA/CD vs CSMA/CA — same idea, different reality
I used to think of these as basically the same thing with different names. They're not, and understanding why is honestly the key to the rest of this post.
Both start from the identical rule: Carrier Sense Multiple Access. Multiple devices, one medium, so before you transmit, you listen first.
With traditional shared Ethernet, CSMA/CD could detect a collision while a frame was being transmitted. If the device noticed that the signal on the wire didn't match what it was sending, it knew something had gone wrong.
So the basic strategy was:
“I'll start talking. If I detect someone talking over me, I'll stop.”
Wi-Fi has a fundamentally different problem.
A Wi-Fi transmitter is producing a signal that can be enormously stronger at its own receiver than the signal it is trying to hear from another device. The radio therefore cannot reliably listen for a collision while transmitting.
So Wi-Fi has to work differently.
Instead of detecting a collision as it happens, CSMA/CA tries to reduce the probability of one happening in the first place. The station listens to the channel, waits according to the rules of the protocol, and uses a randomized backoff before transmitting.
And then it waits for an acknowledgment to find out whether the frame actually got through.
In simplified form:
“I can't tell if someone's talking over me once I've started, so I'll listen first, wait a random moment, and hope for the best.”
| CSMA/CD — Ethernet | CSMA/CA — Wi-Fi | |
|---|---|---|
| Meaning | Collision Detection | Collision Avoidance |
| Shared medium | Traditional shared, half-duplex Ethernet | Shared wireless channel |
| Collision handling | Detect collision while transmitting | Try to avoid collision before transmitting |
| When does it react? | During transmission | Primarily before transmission, then through acknowledgements/retransmission |
| Random backoff | After a detected collision | Before transmission when the channel is contended, and after failed transmissions |
| Acknowledgment | Not generally required | Normally used for unicast data frames |
| Basic strategy | Detect, then recover | Avoid, then recover |
One thing worth being upfront about: modern switched, full-duplex Ethernet doesn't use CSMA/CD anymore. Each link is its own point-to-point connection between a device and a switch port, so there's no shared medium left to collide on. CSMA/CD belongs to the era of shared, half-duplex Ethernet — hubs, and coax before that. So yes, this comparison is a bit of a history lesson on the Ethernet side. On the Wi-Fi side, it's very much still today.
Which brings me to the obvious question.
Each Ethernet link is effectively a point-to-point connection between a device and a switch port. There is no longer a shared electrical medium on which multiple devices are simultaneously competing to transmit. CSMA/CD belongs to the era of shared, half-duplex Ethernet — hubs, and coaxial Ethernet before that. So yes, this comparison is partly a history lesson on the Ethernet side.
On the Wi-Fi side, however, the underlying problem of sharing a radio channel is very much alive today.
Which brings me to the obvious question:
If Wi-Fi can't detect a collision while it's transmitting, how does CSMA/CA actually decide when to transmit?
So why can't Wi-Fi just use CSMA/CD?
It comes down to physics, and the gap is bigger than you'd guess.
A Wi-Fi transmitter might radiate around 20 dBm (100 mW) EIRP, while the signal it is trying to receive may arrive at around −70 dBm. That's a 90 dB difference. In terms of power, that's a factor of one billion.
Think about what that means. While you're transmitting, your own signal can be a billion times more powerful than the signal you're trying to receive. Your receiver isn't simply hearing the other device and your own transmission at the same time. Your own transmitter is effectively shouting directly into the receiver's ear.
That enormous self-interference is why conventional Wi-Fi radios cannot reliably detect collisions while transmitting on the same channel. Wi-Fi is fundamentally half-duplex: a station transmits or receives, rather than reliably doing both simultaneously on the same channel.
And there's a second problem. A collision happens at the receiver, not necessarily at the transmitter. What you can hear isn't necessarily what the access point can hear. A station might have a perfectly clear view of the channel from its own location while another transmission is reaching the access point at the same time.
This is one of the fundamental differences between wireless and a shared Ethernet cable. So Wi-Fi can't simply listen for a collision while transmitting and stop when it detects one. Instead, it does the next best thing: it tries to avoid the collision in the first place.
That's CSMA/CA — Carrier Sense Multiple Access with Collision Avoidance.
CSMA/CA, step by step
Back to that meeting room. You wait until it's quiet. Then you wait a little longer, just in case someone else was also about to jump in. Then you wait a random extra amount of time on top of that. Only then do you speak — and afterward, you wait to hear “got it” back.
Here's what that looks like on an actual Wi-Fi radio:
1. Listen
First, the radio checks whether the channel is available. This is called Clear Channel Assessment (CCA). It can use both energy detection (ED) and Wi-Fi signal detection (SD) to decide whether the medium is busy. The exact thresholds depend on the PHY, frequency band, channel bandwidth and implementation, but as a useful example for an OFDM radio, the receiver may be able to detect a valid Wi-Fi signal down around −82 dBm, while energy from a non-Wi-Fi source may need to be considerably stronger — around −62 dBm — before the channel is declared busy. That's an important distinction.
The radio isn't simply asking:
“Is there any energy here?”
It's asking something closer to:
“Is there a transmission here that I can recognize, or is there enough energy that I should assume the channel isn't safe to use?”
2. Wait a fixed time
If the channel is clear, the station doesn't immediately transmit. It first waits for an interframe space called DIFS, the Distributed Interframe Space. For the classic OFDM timing used by 802.11a/g, that's 34 µs: a 16 µs SIFS plus two 9 µs slot times.
Why wait? Because some higher-priority protocol exchanges, such as an ACK, get shorter interframe spaces. DIFS effectively says: “If nobody with higher priority is using the channel, I'll contend for it.”
3. Random backoff
Now comes the clever part. The station picks a random number from its current contention window. On the first attempt, with the minimum contention window of 15, that means a random value from 0 to 15. It then counts that number down in 9 µs slots in this classic OFDM example.
But there's a catch: the countdown only happens while the channel remains idle.
If another station starts transmitting, the counter freezes.
When the channel becomes idle again and the required interframe space has passed, the countdown resumes. This is what makes the system work when lots of stations are competing. Stations don't all immediately transmit when the channel becomes free. They spread themselves out in time using randomized backoff. And because a station that has already waited part of its backoff keeps that progress, the mechanism provides a degree of fairness, although it is not strict first-come, first-served priority.
4. Transmit
When the backoff counter reaches zero, the station transmits its frame. Hopefully, nobody else reaches zero at exactly the same time.
5. Wait for the ACK
For a normal unicast data transmission, the sender expects an acknowledgment. The receiver waits the shorter SIFS interval and sends the ACK. With the classic OFDM timing we're using here, SIFS is 16 µs. If the sender receives the ACK, everything is good.
If it doesn't, the sender has no direct way of knowing exactly what went wrong. The frame may have collided, been corrupted by interference, or simply failed to reach the receiver. From the sender's perspective, though, the result is the same: no ACK, try again.
The station increases its contention window — typically doubling it after a failed attempt:
15 → 31 → 63 → 127 → 255 → 511 → 1023
until it reaches the configured maximum. Then it chooses another random backoff and tries again.
And this is the beautiful part of CSMA/CA: the more trouble the network has, the more reluctant the stations become to transmit.
That random backoff is also why collisions can still happen.
Two stations can listen to an apparently quiet channel, independently choose the same backoff value, count down together, and reach zero at exactly the same time. With two stations, that may happen relatively infrequently. With thirty stations all competing for the same channel, it becomes considerably more likely.
And that's when the meeting room gets loud.
The interframe spaces: the part that actually decides who goes first
These wait times aren't arbitrary. They're one of the mechanisms that determine which frames get an opportunity to use the channel first.
The basic idea is simple: shorter wait → earlier opportunity.
| Space | Formula | Classic 5 GHz OFDM example | Used for |
|---|---|---|---|
| SIFS | fixed per PHY | 16 µs | ACK, CTS, and other immediate responses |
| DIFS | SIFS + 2 × slot | 34 µs | Normal DCF contention |
| AIFS[AC*] | SIFS + AIFSN × slot | 34–79 µs | EDCA/QoS contention |
| EIFS | SIFS + ACK time + DIFS | longest | After receiving a frame that could not be decoded |
For the classic OFDM timing we're using here, the slot time is 9 µs and SIFS is 16 µs.
DIFS = 16 + (2 × 9) = 34 µs
The older 2.4 GHz DSSS/CCK PHYs use different timing: a 20 µs slot, 10 µs SIFS, and therefore a 50 µs DIFS.
The important part is what these different waiting periods accomplish. Suppose a station has just received a frame and needs to send an ACK. It doesn't have to compete with everyone else. It waits only SIFS.
Everyone trying to start a new transmission has to wait longer — DIFS or its applicable AIFS — before it can even begin its contention process. So the ACK effectively jumps the queue.
Nobody can hear a frame finish and immediately wedge a new transmission in between the frame and its ACK. That's the whole point of SIFS.
In practice: EDCA
Here's where things get more interesting.
Almost no modern Wi-Fi traffic relies solely on the old, basic DCF (Distributed Coordination Function) model. In normal Wi-Fi deployments, QoS is generally handled using EDCA — Enhanced Distributed Channel Access, introduced with 802.11e and commonly exposed through WMM (Wi-Fi Multimedia). Instead of every frame competing with exactly the same parameters, Wi-Fi divides traffic into four Access Categories (AC*):
| Category | AIFSN | AIFS (5 GHz OFDM) | CWmin | CWmax |
|---|---|---|---|---|
| Voice | 2 | 34 µs | 3 | 7 |
| Video | 2 | 34 µs | 7 | 15 |
| Best effort | 3 | 43 µs | 15 | 1023 |
| Background | 7 | 79 µs | 15 | 1023 |
And now the meeting-room analogy gets even better.
Imagine four groups of people waiting to speak. The voice group gets to start counting almost immediately and chooses its random delay from a tiny range. The video group gets a slightly larger random range. Best effort has to wait longer and chooses from a much larger range. And background traffic has to wait the longest before it can even start counting.
So Voice doesn't always win. But statistically, it gets a much better chance.
That's the important distinction: EDCA doesn't guarantee priority. It biases the odds.
Voice's initial contention window is tiny: 0–3
Video gets: 0–7
Best effort: 0–15
Background: 0–15
And when contention causes a retransmission, those windows can grow further according to the contention algorithm. So EDCA is essentially turning the random-access mechanism into a weighted lottery.
Not: “Voice always goes first.”
But: “Voice gets better odds of going first.”
And then there's TXOP
EDCA has another trick. When an access category wins the contention, it can be granted a TXOP — Transmission Opportunity. Instead of having to finish one frame, go back to the end of the contention process, and fight for the channel again, the station can transmit a permitted sequence of frames during that TXOP, subject to the applicable duration limit and rules. That's particularly useful for latency-sensitive traffic.
Win once, then make efficient use of that opportunity.
So what started as: Listen → wait → random backoff → transmit
has evolved into something much more sophisticated: Listen → choose an access category → wait the appropriate AIFS → random backoff → win → use your TXOP → repeat.
And suddenly that “random wait” doesn't look quite so random anymore.
The hidden node problem
Here's one that trips people up even after they've understood CSMA/CA.
Take two clients on opposite sides of an AP. Both can hear the AP just fine. Neither can hear the other. So both clients do exactly what CSMA/CA tells them to do: they listen to the channel, find it apparently idle, run their backoff, and eventually transmit. And then both transmissions arrive at the AP at roughly the same time.
!!! COLLISION !!!
The interesting part? Neither client necessarily knows what happened. From each client's perspective, the channel looked perfectly clear. The problem isn't that either station ignored CSMA/CA. The problem is that each station can only make decisions based on what it can hear.
This is the classic hidden node problem.
So how do you deal with a problem you can't hear? RTS/CTS: Request to Send / Clear to Send.
Instead of immediately sending the DATA frame, the client first sends a short RTS frame to the AP. The AP responds with a CTS.
And here's the clever part: the CTS comes from the AP, so it can potentially be heard by both clients, including the one that could not hear the original sender.
The CTS contains a duration indicating how long the medium is expected to remain reserved. Stations that hear it update their NAV (Network Allocation Vector), Wi-Fi's virtual carrier-sense mechanism, and defer their own transmissions for that period.
So the sequence becomes:
Client A: “Can I use the channel?”
AP: “Yes. Everyone else who can hear me, stay quiet.”
Client C: “I can't hear A, but I can hear the AP. I know the medium has been reserved, so I'll wait.”
Client A can now send its DATA frame, followed by the normal ACK exchange, without Client C unknowingly transmitting at the same time.
That's the clever part of RTS/CTS: the AP becomes the common voice that hidden stations can hear.
But there's a price.
RTS and CTS are extra frames. They consume airtime, introduce additional contention, and add overhead to every exchange that uses the mechanism. For a tiny DATA frame, that overhead can be significant. In some cases, you could spend almost as much airtime protecting the transmission as you would have spent sending the data itself. That's why RTS/CTS isn't normally something you want for every frame. It's generally used selectively, for example, when frames are large enough that a collision would be particularly expensive, or when hidden-node problems are actually causing trouble.
And there's an important subtlety: RTS/CTS doesn't eliminate collisions. It moves the expensive part of the collision out of the DATA exchange. The RTS itself can still collide. But an RTS is short. Losing a short RTS is a lot less painful than losing a large DATA frame.
And that's a recurring theme in Wi-Fi: spend a little airtime trying to avoid wasting a lot of airtime.
Your neighbours are in the room too
Here's the part that surprises people most: your Wi-Fi doesn't care whose network a transmission belongs to.
If your radio detects another transmission on the same channel strongly enough to trigger carrier sense, that transmission can affect whether your client is allowed to transmit, even if it's your neighbour's network, with a completely different SSID, password, and owner.
Your client waits while their frames are on the air. Their client waits while yours are on the air. Airtime doesn't belong to anyone. It's shared, whether you agreed to that arrangement or not. And this is where the number printed on the router box starts becoming almost meaningless.
A manufacturer can tell you that your AP supports several gigabits per second. That's a PHY rate, not a promise that a single client will get several gigabits per second of useful throughput. What actually matters is how efficiently you can use the available airtime.
If ten clients share a channel, they don't each get a magical slice of the advertised data rate. They contend for access to the same medium. More devices mean more backoff, more waiting, more protocol overhead and potentially more retransmissions when the channel gets busy or interference causes frames to fail.
And your clients aren't the only ones competing.
Your neighbours are using the same shared spectrum. Other APs, other clients, and sometimes even non-Wi-Fi sources can consume airtime or cause enough energy to be detected that your own devices defer. That's why channel planning matters.
It's also why simply adding more APs isn't automatically an improvement. If you pile multiple APs onto the same channel and fill that channel with more traffic, you've increased the number of devices competing for the same finite resource.
And the same principle is behind something else that's easy to underestimate: SSID count matters too.
Multiple SSIDs don't magically create additional capacity. They add management and beacon traffic, consuming some airtime that could otherwise be used for client traffic. And this brings us to an interesting question:
If the fundamental problem is that too many devices are competing for the same shared medium, can Wi-Fi do something smarter than simply making everyone wait their turn?
As it turns out, yes. And that's where Wi-Fi 6 changes the game.
From contention to coordination
By now, we've established the fundamental problem.
Wi-Fi has a shared medium. Devices compete for access, they can't reliably detect collisions while transmitting, and when the network gets busy, they spend more time waiting, backing off and retrying. It works. But eventually, simply making everyone better at waiting isn't enough. So Wi-Fi started looking for ways to use the channel more efficiently.
Enter Wi-Fi 6
Wi-Fi 6 (IEEE 802.11ax) introduced several mechanisms aimed at improving efficiency in crowded networks. One of the most important is OFDMA (Orthogonal Frequency Division Multiple Access). Instead of treating the entire channel as one indivisible resource, OFDMA allows the access point to divide it into smaller pieces called Resource Units (RUs) and coordinate transmissions from multiple clients within the same channel access opportunity.
Think back to our meeting room. The old approach was essentially: “One person gets the floor. Everyone else waits.”
OFDMA makes it possible to say: “You use this part. You use that part. You can both talk now.” The channel hasn't magically become bigger. Wi-Fi has simply become better at using the space it already has. And importantly, CSMA/CA didn't disappear.
Wi-Fi is still a shared medium. Devices and access points still contend for access, and interference, hidden nodes and retransmissions haven't gone away. OFDMA simply adds another layer of coordination.
The evolution is therefore quite interesting:
ALOHA: Transmit and try again if it fails.
CSMA/CD: Listen first and detect collisions.
CSMA/CA: Listen, wait, and try to avoid collisions.
OFDMA: Once we have access, use the channel more intelligently.
The fundamental problem hasn't disappeared. Wi-Fi has simply become better at managing the chaos.
To conclude
So, why does Wi-Fi work at all? It really shouldn't.
We took a shared piece of radio spectrum, filled it with devices that can't reliably hear everything happening around them, placed competing networks on top of one another, and somehow expected the whole thing to behave like a network.
There is no dedicated wire. No perfect referee. No guarantee that your transmission will get through the first time. Instead, there is a remarkably simple foundation:
Listen.
Wait.
Transmit.
Hope.
Try again if it didn't work.
Everything we've built since has been about making that process a little smarter. CSMA/CA gave devices a way to share the medium without constantly talking over one another. Backoff, acknowledgements, retransmissions, EDCA and RTS/CTS added increasingly sophisticated ways of dealing with contention and uncertainty. And with Wi-Fi 6 and OFDMA, we've started moving beyond simply avoiding collisions toward actively coordinating how the available spectrum is used.
But underneath all that sophistication, the fundamental problem remains unchanged.
We're still sharing the air.
And somehow, millions of devices do it every day without us even thinking about it. Maybe that's the most impressive thing about Wi-Fi. It doesn't work because the chaos disappeared. It works because we've become remarkably good at managing it.
Sources and references
Technical parameters (SIFS, DIFS, AIFS, contention windows, EDCA access categories) verified against:
J. Henry, B. Hart, B. Gupta, M. Smith, Wi-Fi 7 In Depth: Your Guide to Mastering Wi-Fi 7, the 802.11be Protocol, and Their Deployment, Cisco Press / Pearson, 2024.
IEEE 802.11-2020, IEEE Standard for Information Technology — Telecommunications and Information Exchange between Systems, Local and Metropolitan Area Networks — Specific Requirements, Part 11: Wireless LAN MAC and PHY Specifications.
Historical background draws on:
Abramson, “THE ALOHA SYSTEM: another alternative for computer communications,” AFIPS Fall Joint Computer Conference, 1970.
R. Metcalfe & D. Boggs, “Ethernet: Distributed Packet Switching for Local Computer Networks,” Communications of the ACM, Vol. 19, No. 7, 1976.
U.S. Federal Communications Commission, Part 15 rules (47 CFR §15), 1985 spread-spectrum order.
Wi-Fi Alliance published history, wi-fi.org.
Historical dates and figures not covered above are drawn from general industry knowledge and were not independently verified against primary sources.
