Wireless Networks and Mobile Communications
Wireless networks are central to modern Internet access. Most Internet connections -- from smartphones, laptops, and IoT devices -- occur over wireless links.
In this post, we examine the unique characteristics of wireless links, the structure and operation of WiFi (802.11) protocols, the evolution of cellular networks, and mobility management mechanisms.
1. Components of Wireless Networks
Wireless Network Components
==============================
[Wired Internet]
|
[Base Station/AP] ----Wireless---- [Wireless Host]
| Link [Wireless Host]
| [Wireless Host]
[Wired Network]
Components:
1. Wireless Hosts: Smartphones, laptops, tablets
2. Base Station: AP, cell tower
3. Wireless Link: Communication channel between host and base station
4. Network Infrastructure: Connects base stations to wired network
1.1 Wireless Network Classification
Wireless Network Classification
==================================
| Infrastructure-based | Infrastructure-less
-----------------+-----------------------+--------------------
Single Hop | WiFi, 4G LTE | Bluetooth
| (Via AP/Base Station) | (Direct device-to-device)
-----------------+-----------------------+--------------------
Multi Hop | Wireless Mesh | MANET, VANET
| (Using relays) | (Ad hoc networks)
2. Characteristics of Wireless Links
2.1 Differences from Wired Links
Wireless links have fundamentally different characteristics from wired links.
Key Characteristics of Wireless Links
========================================
1. Path Loss
- Signal strength decreases rapidly with distance
- Free space: inversely proportional to square of distance
- Indoors: additional attenuation from walls, furniture, etc.
2. Multipath Fading
- Signals arrive via multiple reflected/diffracted paths
- Multiple signals combine to strengthen or cancel
3. Interference
- Interference from other devices using same frequency
- Microwaves, Bluetooth, etc. (2.4GHz band)
4. SNR (Signal-to-Noise Ratio)
- Higher SNR: fewer errors
- High SNR: high modulation rate, high data rate
- Low SNR: low modulation rate, low data rate
2.2 Hidden Terminal Problem
Hidden Terminal Problem
========================
Obstacle
[A] .....|..... [B] ---------- [C]
| | | |
| A's range | B's range |
|<----->| |<----------->|
| |
A cannot sense C
C cannot sense A
Problem:
A is transmitting to B
C senses channel: "Idle!" (cannot sense A's signal)
C also starts transmitting to B --> Collision at B!
This is why CSMA/CD cannot be used in wireless
3. WiFi (IEEE 802.11)
3.1 802.11 Architecture
802.11 Network Structure
===========================
BSS (Basic Service Set):
[AP (Access Point)]
/ | \
[H1] [H2] [H3]
Wireless hosts
ESS (Extended Service Set):
[AP1] --- Wired --- [AP2] --- Wired --- [AP3]
/ \ / \ / \
[H1][H2] [H3][H4] [H5][H6]
Key Components:
- BSS: Group of wireless hosts associated with one AP
- AP: Bridge connecting wired network and wireless hosts
- SSID: Network identification name (e.g., "MyWiFi")
- Channel: 1~11 (2.4GHz) or 36~165 (5GHz)
3.2 802.11 Association Process
WiFi Association Process
==========================
1. AP Discovery
- Passive Scan: AP periodically sends beacon frames
- Active Scan: Host sends probe request, AP responds
2. Authentication and Association
Host AP
|--- Authentication Request -->|
|<-- Authentication Response --|
|--- Association Request ----->|
|<-- Association Response -----|
3. Obtain IP address via DHCP
4. Begin data transfer
3.3 802.11 MAC Protocol: CSMA/CA
In wireless environments, collision detection (CD) is difficult, so collision avoidance (CA) is used instead.
CSMA/CA Operation
====================
1. Carrier Sense
- If channel is idle during DIFS (Distributed Inter-Frame Space), transmit
2. If channel is busy:
- Start random backoff timer
- Countdown timer only when channel is idle
- Transmit when timer reaches 0
3. ACK Confirmation
- Receiver sends ACK after SIFS (Short Inter-Frame Space)
- Retransmit if ACK not received (increase backoff value)
Timeline:
Sender: [DIFS Wait][Data Transmission]....[Timeout]
Receiver: [SIFS][ACK]
CSMA/CD vs CSMA/CA:
CD: Detect collision then stop immediately (Ethernet)
CA: Avoid collision + ACK confirmation (WiFi)
3.4 RTS/CTS Mechanism
An optional mechanism to solve the hidden terminal problem.
RTS/CTS Operation
====================
Sender A AP Nodes in range
| | |
|-- RTS ----------->| |
| (Request to Send)| |
| |---- CTS ------------->|
|<-- CTS -----------| (Channel reservation)|
| | |
|== Data =========>| |
| | | (Refrain from transmitting)
|<-- ACK -----------| |
| | |
RTS: Request to Send
CTS: Clear to Send
All nodes receiving CTS refrain from transmitting for the specified duration
--> Hidden terminal problem solved
3.5 802.11 Frame Format
802.11 Frame Structure
========================
+-------+------+------+------+------+-----+------+------+-----+
|Frame |Dur- |Addr |Addr |Addr |Seq |Addr |Data | CRC |
|Control|ation | 1 | 2 | 3 |Ctrl | 4 | | |
| 2B | 2B | 6B | 6B | 6B | 2B | 6B |0-2312| 4B |
+-------+------+------+------+------+-----+------+------+-----+
4 MAC Address Fields:
Address 1: MAC of receiving wireless interface
Address 2: MAC of sending wireless interface
Address 3: MAC of router interface connected to AP
Address 4: Used only in ad hoc mode
Why 3 addresses are needed:
H1 --> AP --> Router (R1)
Address 1: AP's MAC (wireless receiver)
Address 2: H1's MAC (wireless sender)
Address 3: R1's MAC (toward final destination)
4. Evolution of 802.11 Standards
WiFi Standard Evolution
=========================
Standard | Release | Frequency | Max Speed | Features
------------+---------+------------+--------------+------------------
802.11b | 1999 | 2.4 GHz | 11 Mbps | Early adoption
802.11a | 1999 | 5 GHz | 54 Mbps | OFDM
802.11g | 2003 | 2.4 GHz | 54 Mbps | Backward compat. with b
802.11n | 2009 | 2.4/5 GHz | 600 Mbps | MIMO
(WiFi 4) | | | |
802.11ac | 2013 | 5 GHz | 6.9 Gbps | MU-MIMO
(WiFi 5) | | | |
802.11ax | 2020 | 2.4/5/6 | 9.6 Gbps | OFDMA
(WiFi 6) | | GHz | |
5. Cellular Networks
5.1 Cellular Structure
Cellular Network Basic Structure
===================================
[Cell 1] [Cell 2] [Cell 3]
/ \ / \ / \
/ \ / \ / \
/ BTS \ / BTS \ / BTS \
(Base ) (Base ) (Base )
(Station ) (Station ) (Station )
| | |
+----------+----------+
|
[BSC/RNC]
(Base Station Controller)
|
[MSC/MME]
(Mobile Switching Center)
|
[Core Network] --- [Internet]
Cell: Area covered by one base station
Frequency Reuse: Same frequency used in non-adjacent cells
5.2 Generational Evolution
Cellular Network Generational Evolution
==========================================
Gen | Technology | Speed | Features
-------+-----------+-----------------+------------------
1G | AMPS | 2.4 Kbps | Analog voice
2G | GSM | 14.4 Kbps | Digital voice
2.5G | GPRS | 56-114 Kbps | Packet data
2.75G | EDGE | 384 Kbps | Enhanced data
3G | UMTS | 2 Mbps | Mobile Internet
3.5G | HSPA | 14 Mbps | High-speed packet
4G | LTE | 100 Mbps~1Gbps | All-IP network
4.5G | LTE-A | 3 Gbps | Carrier aggregation
5G | NR | 20 Gbps | Ultra-low latency, IoT
5.3 4G LTE Architecture
4G LTE Network Structure
===========================
[UE] --Wireless-- [eNodeB] --- [S-GW] --- [P-GW] --- [Internet]
| | |
| [MME] [PCRF]
| (Mobility (Policy/
| Management) Charging)
|
[HSS]
(Subscriber DB)
UE: User Equipment
eNodeB: Base Station (evolved Node B)
S-GW: Serving Gateway (data path management)
P-GW: Packet Gateway (Internet connectivity)
MME: Mobility Management Entity
HSS: Home Subscriber Server (subscriber info)
Key Features:
- All traffic transmitted as IP packets (All-IP)
- Voice also handled as VoLTE (Voice over LTE)
- Flat architecture (reduced layers for minimum latency)
6. Mobility Management
6.1 Mobility Spectrum
Mobility Levels
=================
No mobility High mobility
|-------|--------|--------|--------|---------|
Fixed Low Medium High Ultra-high
Desktop WiFi Pedestrian Vehicle High-speed
Roaming Handoff Handoff Train
6.2 Handoff (Handover)
Handoff Process
=================
Mobile device moving from one base station to another:
[Old BS] .... [Mobile Device] .... [New BS]
| |
| Signal weakening Signal strengthening
| |
|<--- Handoff Decision ------->|
| |
|---- Traffic Path Switch ---->|
| |
Handoff Types:
1. Hard Handoff: Disconnect old, connect new (GSM)
2. Soft Handoff: Maintain both connections simultaneously (CDMA)
Handoff Criteria:
- Signal strength (RSSI)
- Signal quality (SINR)
- Load balancing
6.3 Indirect Routing and Direct Routing
Mobility Support: Indirect Routing
=====================================
Home Network Visited Network
[Home Agent] [Foreign Agent]
| |
|<---- Mobile Registration ----|
| |
Correspondent --> Home Agent --> Foreign Agent --> Mobile Device
(Tunneling) (Forwarding)
Disadvantage: Triangle Routing
Even if correspondent is right next to visited network,
traffic must go through home network
Direct Routing:
Correspondent checks current location from Home Agent
Then sends directly to Foreign Agent (avoids triangle routing)
7. Wireless Security
WiFi Security Protocol Evolution
===================================
Protocol | Release | Encryption | Security Level
---------+---------+---------------+-----------
WEP | 1999 | RC4 (40bit) | Very weak (do not use)
WPA | 2003 | TKIP | Transitional
WPA2 | 2004 | AES-CCMP | Good
WPA3 | 2018 | SAE + AES | Strong
WPA2 Operation (4-way Handshake):
1. AP sends random value
2. Client sends random value + MIC
3. AP sends group key + MIC
4. Client sends confirmation
--> Both sides securely share session key
Following One CSMA/CA Transmission All the Way Through
Section 3.3 summarized CSMA/CA in three lines. If you follow a single frame all the way from "I have something to send" to "it was acknowledged," it becomes much clearer why real WiFi throughput falls so far short of the headline numbers in the standards table.
One CSMA/CA transmission (DCF)
=================================
[frame ready to send]
|
v
(1) Carrier sense
Is the channel physically idle?
|
+-- idle ------> if it stays idle for DIFS, transmit immediately
|
+-- busy ------> (2)
v
(2) Enter backoff
Draw a slot count uniformly at random from the contention window CW
backoff = an integer between 0 and CW (unit: slots)
|
v
(3) Slot countdown
Decrement backoff by 1 for every idle slot
If the medium becomes busy, freeze the counter where it is
When the medium is idle again for DIFS, resume from the remaining value
|
v
(4) backoff reaches 0 --> transmit the data frame
|
v
(5) Receiver decodes the frame successfully
Waits only SIFS, then sends an ACK
|
v
(6) ACK received --> success. Reset CW to its minimum
No ACK --> treat as failure. Grow CW and return to (2)
Three things deserve attention here.
First, the freeze and resume. The backoff counter only decrements during idle slots. If another station starts transmitting mid-countdown, the counter stops where it is, and when the medium clears the station does not draw a new random number: it continues from whatever was left. If it drew 7 slots and had counted down to 3 when the medium got busy, it resumes at 3, not 7. Without this rule, a station that has already waited a long time would have to re-enter the competition from scratch every time and could be starved by late arrivals. Preserving the remaining value means whoever has waited longest is more likely to go first in the next round.
Second, why 802.11 needs ACKs when Ethernet does not. Ethernet can compare the signal it is putting on the wire against what is actually on the wire and detect a collision — that is the CD in CSMA/CD. On a wireless link that comparison does not work. A radio that is transmitting hears its own signal overwhelmingly loudly at its own antenna, so a distant station's signal arriving on top of it simply cannot be distinguished. Worse, the collision does not happen at the transmitter's antenna at all; it happens at the receiver's. However well the sender listens from where it stands, the place where the damage occurs is somewhere else. So 802.11 gives up on detection, switches to avoidance, and determines whether a transmission actually succeeded from exactly one piece of evidence: an ACK from the receiver. The absence of an ACK is the only failure signal there is.
Third, why the ACK goes out after SIFS specifically. SIFS is shorter than DIFS, and that single difference in length creates a priority. A station wanting to send a new frame must wait at least DIFS, while a receiver wanting to send an ACK only has to wait the shorter SIFS, so it always grabs the medium first. The practical result is that an in-progress data/ACK exchange always outranks an exchange that is only just starting. The exact microsecond values depend on the PHY and the band, so check the standard for the version you are using. What matters here is not the absolute value but the ordering: SIFS is shorter than DIFS.
The Contention Window and Binary Exponential Backoff
The contention window CW is the range the backoff slot count is drawn from. Every failed transmission widens that range.
Binary exponential backoff (concept)
=======================================
attempt 1 : CW = CWmin --> drawn from a narrow range (goes out fast)
attempt 2 : CW roughly doubles
attempt 3 : CW roughly doubles again
...
attempt n : CW = CWmax, growth stops
Reset conditions:
- the frame is ACKed successfully --> CW = CWmin
- the retry limit is exceeded and the frame is dropped --> CW = CWmin
The actual slot counts for CWmin / CWmax differ per PHY and per
access category (QoS) — check the standard and driver docs you are on
A wider range lowers the probability that two stations draw the same slot number, so the busier the channel gets, the more the collision probability drops automatically. The cost is that average waiting time grows with it. CW is essentially each station's private short-term estimate of "how crowded is this channel right now," and a single success resets that estimate. This is usually what is behind the stair-step drop in perceived speed in a crowded cafe: more stations means more collisions, more collisions means a larger CW, and a larger CW means more time spent waiting rather than sending data.
Working the Hidden Terminal Problem Out with A-B-C
Let us rewrite the picture from section 2.2 as an ordered sequence. Station A, receiver B (usually the AP), and station C are in a line. A and C are each within B's range, but outside each other's range.
Hidden terminal: the failing sequence
========================================
t0 A: carrier sense --> idle. DIFS elapses. Starts transmitting
C: carrier sense --> idle (A's signal never reaches C)
t1 A: ===== transmitting data frame =====> B
C: still looks idle. DIFS elapses. Starts transmitting
t2 C: ===== transmitting data frame =====> B
B: A's signal and C's signal arrive together --> collision
t3 B: neither can be decoded --> no ACK is sent
A: ACK timeout --> failure. Grow CW, retry
C: ACK timeout --> failure. Grow CW, retry
The point:
Both A and C followed the rules perfectly from where they stand.
Physical carrier sense reports the state of "where I am listening,"
but collisions happen "where the receiver is."
The limit of physical carrier sense is on full display here. A and C both obeyed the protocol and still collided, and both now retry with a larger CW. Under load this failure repeats, and a substantial fraction of channel time is burned on transmissions that were never going to succeed.
RTS/CTS converts this from "is the medium idle, as heard by my ears" into "who has reserved the medium."
RTS/CTS and the NAV
======================
A B (AP) C
| | |
|--- RTS (duration) ---->| |
| | |
| |--- CTS (duration) ---->| C cannot hear A,
|<--- CTS (duration) ----| | but it can hear B
| | |
| | | C: sets NAV
|=== data ==============>| | (no transmit for duration)
| | |
|<--- ACK ---------------| |
| | | C: NAV expires --> competes again
The duration field in RTS and CTS frames carries
"how much time remains until this exchange completes."
Every station that hears it sets a Network Allocation Vector (NAV)
that counts down for exactly that long.
This is why the NAV is called virtual carrier sense. A station treats the medium as busy while its NAV is non-zero, even when it hears nothing at all. C never physically hears A's data frame, but the duration value in B's CTS tells it that now is not its turn. The medium counts as busy if either physical or virtual carrier sense says so.
There is an honest trade-off. RTS/CTS spends two extra short control frames plus the SIFS gaps between them on every data frame. That cost is fixed and independent of the data length, so for short frames the overhead can exceed the payload. Turning RTS/CTS on unconditionally for traffic dominated by small frames — VoIP, game packets — actually reduces throughput. This is why implementations expose an RTS threshold and only use RTS/CTS when the frame length exceeds it. Check the default in the documentation for the driver or AP you are using.
How an Association Actually Comes Together: Scan, Authenticate, Associate, Key Exchange
Expanding the four steps from section 3.2 into the actual frame sequence:
From scan to data transfer
=============================
[1] Scanning -- find out which APs exist
Passive scan: hop channel by channel and wait for a beacon
AP -->(beacon)--> all stations (periodic broadcast)
Active scan: send a probe request on each channel, take the reply
STA --(probe request)--> AP
STA <--(probe response)-- AP
[2] Authentication -- the 802.11-layer formality
STA --(auth request)--> AP
STA <--(auth response)-- AP
Under WPA2 this is normally Open System and simply passes.
Real identity verification happens in step [4].
[3] Association -- join this AP's BSS
STA --(assoc request: supported rates, capabilities)--> AP
STA <--(assoc response: status code, AID)------------- AP
Once the AID is assigned, the AP maintains buffers for this station.
[4] Key exchange -- 4-way handshake for WPA2, SAE for WPA3
Only after this do encrypted data frames flow.
[5] Obtain an IP address via DHCP --> data transfer begins
A beacon is not just an "I am here" ping. The beacon frame body carries the SSID, the list of transmission rates the AP supports, capability information, the beacon interval, the operating channel, the security configuration (RSN information), and traffic indication information for stations in power save. From a single beacon a station can already tell whether it can join this AP, and at what rates and under what security, before it attempts association at all.
That is also where passive scanning's slowness comes from. A passive scan transmits nothing and only listens, so to learn whether an AP exists on a channel it has to stay on that channel until a beacon happens to come out. Beacons only appear on their interval, so the station must dwell at least one beacon interval per channel, and repeating that across every channel makes total scan time scale with the channel count. An active scan sends a probe request first and takes the immediate reply, so per-channel dwell time is far shorter. The costs are that the station broadcasts its presence and the SSIDs it is looking for, and that in some regulated bands transmitting first is restricted, which forces passive scanning on those channels. The power profile differs too: passive scanning means staying awake longer, active scanning means shorter but with transmissions.
It also helps to keep authentication and association separate in your head. The 802.11 authentication step is close to a historical artifact, and under WPA2 it passes without verifying anything real. Actually proving you know the passphrase and deriving session keys happens in the 4-way handshake after association completes. That is why you see logs asking "the password was wrong, so why did association succeed?" Association did succeed; the key exchange is what failed.
What Actually Eats Throughput in the Real World
The gap between the headline rate and the observed rate mostly comes from three places.
Rate Adaptation and Airtime Unfairness
A wireless link continuously changes its modulation and coding scheme (MCS) based on SNR. With a good signal it packs data densely at a high MCS; as distance or interference grows and retries climb, the driver's rate control algorithm automatically steps down to a lower MCS. On Linux mac80211, the minstrel family of algorithms does this job. Stepping down to a lower MCS means spending more time on the air to move the same number of bytes.
The problem is that what CSMA/CA distributes fairly is transmission opportunities, not bandwidth.
Airtime unfairness
=====================
Suppose each station sends one frame of the same size.
near client (high MCS) : [==] short occupancy
far client (low MCS) : [==================] long occupancy
DCF roughly equalizes the NUMBER of transmissions.
So one slow client takes most of the channel time.
Result: the fast clients' throughput collapses too.
One slow station drags the whole cell down.
This is the mechanism behind "one laptop in the corner makes the whole office WiFi slow." It is not a bandwidth problem but a channel-time allocation problem, so replacing the AP with a faster model does not fix it. The right moves are to shrink coverage and add APs so every client can run at a high MCS, or to use equipment that supports airtime fairness.
Co-Channel vs. Adjacent-Channel Interference
You need to separate these two to diagnose anything. Co-channel interference is when other APs and their clients share your exact channel. Their signals are decodable 802.11 signals to you, so carrier sense works correctly and everyone simply shares channel time. Throughput drops, but behavior is normal. Adjacent-channel interference is when the frequencies only partially overlap. You cannot decode the other side's frames — they register only as noise — so carrier sense does not work properly and the two sides simply corrupt each other's transmissions. The retry rate climbs sharply.
Counterintuitively, when channels are scarce, overlapping on the same channel is often better than moving to a partially overlapping one.
20 MHz channels in the 2.4 GHz band
======================================
channel: 1 2 3 4 5 6 7 8 9 10 11
|---20MHz---|
|---20MHz---|
|---20MHz---|
^ ^ ^
1 6 11
In most regulatory domains the 2.4 GHz channel spacing is narrow enough
that, at 20 MHz width, effectively only 1 / 6 / 11 are non-overlapping.
--> with four or more APs, channel reuse is unavoidable.
5 GHz has far more non-overlapping 20 MHz channels.
--> the room for channel planning is fundamentally different.
(available channels and DFS requirements vary by regulatory domain,
so check your country's rules and your equipment's documentation)
Picking a "looks empty" channel like 3 or 9 in the 2.4 GHz band is a common mistake. Such a channel partially overlaps both channel 1 and channel 6, so it becomes noise to both and receives noise from both.
Failure Cases and Traps
Symptom: Full Bars, Still Slow
This is the most common report and the most commonly misdiagnosed one. Three full bars mean RSSI is high; it does not mean the link is healthy. RSSI describes the strength of what you are receiving, and says nothing about whether your transmissions are arriving at the other end.
Diagnosis order
==================
1) Look at the retry rate first
If tx retries is more than a few percent of tx packets, the link is sick.
However good the RSSI is, high retries mean the channel is polluted.
--> suspect interferers, adjacent-channel overlap, hidden terminals
2) Look at the actual MCS / tx bitrate
If the negotiated physical rate is far below what the link supports,
rate control has already stepped down.
--> check distance, obstacles, antenna orientation, band (2.4 vs 5 GHz)
3) Look at channel occupancy
If 1 and 2 are fine and it is still slow, the problem is not your link
but the channel itself.
--> count other APs / clients on the same channel, check airtime
4) Look at RSSI last
RSSI is a supporting indicator you use to explain the causes in 1-3.
It is not the starting point.
On Linux you can read these values directly with iw. The examples below assume the interface is named wlan0; substitute your own interface name. The documented form is written like iw dev <devname> link.
# Summary of the current connection: SSID, frequency, signal, negotiated tx bitrate
iw dev wlan0 link
Example output
=================
Connected to 02:11:22:33:44:55 (on wlan0)
SSID: office-5g
freq: 5180
RX: 184203311 bytes (152884 packets)
TX: 21944072 bytes (61230 packets)
signal: -47 dBm
tx bitrate: 54.0 MBit/s
How to read it:
signal -47 dBm --> RSSI is excellent ("full bars")
the tx bitrate line carries no MCS notation at all
--> the link has fallen back to a legacy rate, not an HT/VHT rate.
A healthy 802.11n link prints something like the kernel docs' example:
tx bitrate: 300.0 MBit/s MCS 15 40Mhz short GI
with the MCS index and channel width shown alongside.
Good signal with a low rate = rate control stepped down due to interference.
That is why this line, not RSSI, is the one to read first.
# Detailed statistics including the retry counters
iw dev wlan0 station dump
Among everything station dump prints, the fields that actually drive a diagnosis are tx retries, tx failed, tx bitrate, rx bitrate and signal avg. If tx retries is noticeably large relative to tx packets, that link is already in trouble regardless of signal strength. The exact field names and layout vary with the driver and kernel version, so check the documentation for the version you are on.
Symptom: It Only Drops at Certain Times of Day
Here the diagnosis order is different. First check whether the number of people rises at that hour (airtime contention), then whether a non-802.11 interferer such as a microwave oven or a cordless phone is running, and finally, if you are on 5 GHz, whether radar detection is forcing a channel change. The first two show up as a rising retry rate; the last shows up as a short complete outage plus a change of channel number, so the logs distinguish them.
Trap: Turning RTS/CTS On Unconditionally
After learning about the hidden terminal problem it is tempting to drop the RTS threshold to its minimum and apply RTS/CTS to every frame. In an environment where hidden terminals do not actually exist, this is pure loss. Every frame now carries two extra control frames and the SIFS gaps between them, so throughput drops noticeably for traffic made of many small frames. RTS/CTS is a tool you enable after you have established the diagnosis "retries are high, and the cause is stations that cannot hear each other rather than interference."
When Not to Use Wireless
Wireless beats wired on convenience by a wide margin, but in three cases wired is the correct answer.
First, workloads where latency must be bounded and predictable. CSMA/CA is probabilistic by construction: backoff slots are drawn at random, the counter freezes when the medium is busy, and CW grows on failure. Even with a low average latency, there is no upper bound you can guarantee on the worst case. Where the tail of the latency distribution is what matters — industrial control, real-time audio synchronization, high-frequency trading — a good average is not enough to make wireless usable.
Second, high station density, where the constraint is channel time rather than bandwidth. In an auditorium or a conference hall with hundreds of devices in one space, raising the AP's rated speed does not help. Every station shares one channel's time, and as station count grows, the fraction of that time consumed by collisions and backoff grows with it. What such a place needs is not a faster AP but tighter cell design, a channel reuse plan, and wired backup where possible.
Third, environments where you cannot control the RF. Wireless performance is governed by the neighbor's AP, the road outside the window, the plumbing inside the wall — things you have no authority over. Between server racks, in shared office buildings, in leased space where you cannot manage the surrounding spectrum, staking service availability on a wireless link means owning outages you can neither localize nor fix. Paths that must not break — server-to-server traffic, backups, storage traffic — belong on wire.
Conversely, the cases where wireless is clearly right are just as definite: when mobility is the requirement itself, when cabling cost dominates the performance loss, and for ordinary web and streaming traffic where the latency tail does not affect the user experience.
8. Summary
| Concept | Key Points |
|---|---|
| Path Loss | Signal strength drops rapidly with distance |
| Hidden Terminal | Collision due to inability to sense other's transmission |
| CSMA/CA | Collision avoidance + ACK confirmation |
| RTS/CTS | Channel reservation solves hidden terminal |
| 802.11 Frame | Contains 4 MAC address fields |
| Cellular | Frequency reuse per cell, generational evolution |
| 4G LTE | All-IP network, flat architecture |
| Handoff | Connection switchover during base station transition |
In the next post, we will examine multimedia networking and streaming technologies.
References
- James F. Kurose, Keith W. Ross, "Computer Networking: A Top-Down Approach", 6th Edition, Chapter 6
- IEEE 802.11 - Wireless LAN Standard
- 3GPP TS 36.300 - LTE Architecture
802.11 is an IEEE standard, not an RFC. Go to IEEE for the standard itself and to the kernel documentation for the Linux-side tooling.
- IEEE 802.11 Working Group (the WLAN standards working group, including the free IEEE 802 standards download program) — https://www.ieee802.org/11/ (verified 2026-08-16)
- IEEE Std 802.11-2020, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications" (now superseded by IEEE Std 802.11-2024) — https://standards.ieee.org/ieee/802.11/7028/ (verified 2026-08-16)
- IEEE P802.11 project page (status of the current revision) — https://standards.ieee.org/ieee/802.11/11852/ (verified 2026-08-16)
- Linux Wireless, iw usage examples (
iw dev wlan0 link,iw dev wlan1 station dump,iw dev wlan0 scan,iw list) — https://wireless.docs.kernel.org/en/latest/en/users/documentation/iw.html (verified 2026-08-16) - Linux Wireless, mac80211 documentation (Rate Control / minstrel) — https://wireless.docs.kernel.org/en/latest/en/developers/documentation/mac80211.html (verified 2026-08-16)