CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance

We've established that wireless stations cannot detect collisions during transmission. We've explored how interframe spaces provide timing structure and how the contention window reduces collision probability. But what happens when, despite all these mechanisms, a collision still occurs?

The answer is the Acknowledgment (ACK) mechanism—the third pillar of CSMA/CA that provides collision inference as a substitute for collision detection. Every unicast frame requires explicit acknowledgment from the recipient. If the ACK doesn't arrive within a precise time window, the sender infers that the transmission failed.

This simple concept—send frame, wait for ACK, retry if missing—has profound implications for protocol design, efficiency, and reliability. Understanding the ACK mechanism is essential for diagnosing wireless performance issues and comprehending advanced features like Block ACK and frame aggregation.

In wired Ethernet (CSMA/CD), there are no acknowledgments at the MAC layer. If a frame is sent without collision detection, it's assumed to succeed. Error recovery is handled by upper layers (TCP, for example). Why doesn't 802.11 follow the same approach?

The 802.11 ACK frame is one of the simplest frames in the protocol—designed for minimum overhead and maximum speed.

ACK Frame Structure:

+-------------+-------------+----------+---------+-----+
|   Frame     |  Duration   | Receiver |   FCS   |     |
|   Control   |    /ID      | Address  |         |     |
+-------------+-------------+----------+---------+-----+
    2 bytes       2 bytes     6 bytes    4 bytes

Total ACK frame: 14 bytes (plus PHY preamble/header)

Frame Control Field Breakdown:

Bit:  0  1   2  3  4  5  6  7   8   9  10  11  12  13  14  15
     [Protocol ][Type][--Subtype--][ToDS][FromDS][MF][Retry][PM][MD][WEP][O]
     [   00    ][ 01 ][ 1  1  0  1][ 0  ][ 0    ][ 0][  0  ][ 0][0 ][ 0 ][0]

Type = 01 (Control frame)
Subtype = 1101 (ACK)
All other flags = 0 for normal ACK

ACK Transmission Requirements:

1. Timing: Must begin exactly SIFS after data frame ends (±4 μs tolerance)
2. Rate: Transmitted at mandatory rate for response (typically same as data frame or 6/1 Mbps)
3. No contention: ACK is immediate, no backoff required
4. Address matching: Receiver Address = Transmitter Address of data frame

The timing of ACK transmission is critical. Too early, and it overlaps with the end of the data frame. Too late, and other stations interpret the channel as idle and begin their DIFS countdown. The SIFS timing window is precise and non-negotiable.

ACK Timing Diagram (802.11a):

Time (μs):    0            500          516         560
              |-------------|------------|-----------|---->
               DATA Frame    SIFS(16μs)   ACK Frame
               (500 μs)                   (44 μs)

              |<-- Sender transmits -->|<-- Recipient -->|
                                       |<-- Sender waits -->|

              DATA Frame ends at T=500
              ACK must begin at T=500+16=516 (±4 μs tolerance)
              ACK ends at T=516+44=560
              DIFS starts at T=560
              Other stations can contend at T=560+34=594

Why Exactly SIFS?

• Shorter than SIFS: ACK would overlap data frame's end or processing time
• Longer than SIFS: Other stations (waiting DIFS = SIFS + 2 slots) might sense idle and transmit, causing collision with ACK

The SIFS-DIFS gap (2 slots = 18 μs in 802.11a) is precisely sized to accommodate ACK transmission. ACK at lowest rate (6 Mbps) takes about 44 μs, well within the protection window.

After transmitting a data frame, the sender waits for an ACK. If the ACK doesn't arrive within a calculated timeout period, the sender concludes that transmission failed. This timeout must be carefully calibrated—too short causes false failures; too long wastes time.

ACK Timeout Calculation:

ACKTimeout = SIFS + ACK_Tx_Time + Slot_Time + aPHY-RX-START-Delay

Where:

• SIFS: Time before recipient starts ACK transmission
• ACK_Tx_Time: Time to transmit ACK frame (preamble + header + 14 bytes)
• Slot_Time: Guard time for propagation and detection
• aPHY-RX-START-Delay: Time for receiver to detect incoming frame

Values (802.11a at 6 Mbps ACK):

Failure Recovery Procedure:

1. ACKTimeout expires without receiving valid ACK
2. Increment retry counter
3. If retry counter > retry limit:
   a. Discard frame
   b. Report failure to upper layer
   c. Reset CW to CWmin
   d. Proceed to next frame in queue
4. Else:
   a. Double CW (up to CWmax) — Binary Exponential Backoff
   b. Select new random backoff from [0, CW]
   c. Wait for channel idle + DIFS
   d. Execute backoff procedure
   e. Retransmit frame (with Retry bit set in Frame Control)

The Retry Bit:

Retransmitted frames have the Retry bit (bit 11 in Frame Control) set to 1. This allows recipients to detect duplicates if the original transmission succeeded but ACK was lost. The recipient should not process the same frame twice.

The rate at which ACK frames are transmitted is not arbitrary—it's determined by specific rules designed to ensure the ACK is decodable by all stations that heard the original data frame.

ACK Rate Rules (IEEE 802.11-2020):

The ACK must be transmitted at a rate that is:

1. A member of the basic rate set (rates all stations must support)
2. The same or lower modulation class as the data frame
3. The highest rate from the basic set not higher than the data rate

Examples:

ACK Duration by Rate:

Observation: OFDM ACKs (802.11a/g/n/ac) take ~28-44 μs. DSSS ACKs (802.11b) can take over 300 μs at 1 Mbps! This is one reason why 802.11b presence dramatically reduces network efficiency.

Mixed Network Impact:

When 802.11b stations are present in an 802.11g network:

• ACKs may be sent at 1 or 2 Mbps for compatibility
• Each ACK wastes 200+ extra microseconds
• Overall throughput can drop by 50% or more

Sending an ACK for every frame imposes significant overhead, especially at high data rates where the ACK time approaches the data time. Block ACK (BA) was introduced in 802.11e and enhanced in 802.11n to acknowledge multiple frames with a single response.

Block ACK Operation:

1. Sender transmits multiple MPDUs (A-MPDU aggregation) in a burst
2. Recipient receives all frames during the burst
3. Sender sends BlockACKRequest (BAR) after the burst
4. Recipient responds with BlockACK (BA) containing a bitmap
5. Bitmap indicates which frames in the sequence were received correctly

Block ACK Bitmap:

BlockACK Frame (minimum 32 bytes):
+--------+----------+------+--------+-------+-----+
| Frame  | Duration | RA   | BA     | BA    | FCS |
| Control|          |      | Control| Info  |     |
+--------+----------+------+--------+-------+-----+
    2        2         6       2      24+     4

BA Info contains:
- BA Starting Sequence Control (2 bytes)
- Block Ack Bitmap (8-128 bytes depending on variant)

Example Bitmap (8 bytes = 64 frames):
  Bit 0: Frame 0 received correctly (1) or not (0)
  Bit 1: Frame 1 received correctly (1) or not (0)
  ...
  Bit 63: Frame 63 received correctly (1) or not (0)

Efficiency Comparison:

Sending 64 frames of 1500 bytes at 300 Mbps:

Block ACK provides 25x reduction in acknowledgment overhead!

This is why 802.11n and later achieve much higher throughput—frame aggregation combined with Block ACK dramatically reduces per-frame overhead.

While ACKs are mandatory for normal unicast frames, IEEE 802.11e introduced QoS extensions that allow different acknowledgment policies for different traffic types.

No ACK Policy Details:

The No ACK policy is specified in the QoS Control field of the MAC header (Ack Policy bits). When set:

1. Sender transmits frame without waiting for ACK
2. Receiver does not send ACK even if frame received correctly
3. No retransmission occurs if frame is lost
4. Sender immediately proceeds to contention for next frame

Use Cases for No ACK:

• Voice over IP (VoIP): Late packets are useless; better to drop than retry
• Video streaming: Similar to VoIP; playout buffers handle minor loss
• Multicast/Broadcast: ACKs from all recipients would cause massive collision
• Control channel: Some management frames don't require reliability

When No ACK Is Dangerous:

• TCP traffic: TCP assumes reliable delivery; lost frames cause end-to-end retransmission
• Critical control: Connection management, authentication, etc.
• High error environments: Without retry, throughput collapses rapidly

We've completed our deep dive into the acknowledgment mechanism—the final pillar of CSMA/CA. Let's consolidate the key concepts:

Module Complete:

You've now mastered CSMA/CA—the fundamental medium access control protocol for IEEE 802.11 wireless networks. You understand:

1. Collision Avoidance — Why wireless cannot use collision detection and how CSMA/CA prevents collisions proactively
2. Why Not CSMA/CD — The physical constraints (near-far problem, hidden terminals, half-duplex hardware, fading) that make collision detection impossible
3. Interframe Spaces — SIFS, DIFS, AIFS, PIFS, EIFS, and how they provide timing structure and priority
4. Contention Window — Random backoff, binary exponential backoff, and collision probability analysis
5. ACK Mechanism — Frame format, timing, rate selection, Block ACK, and QoS policies

These mechanisms work together to enable efficient, reliable wireless communication despite the inherently challenging nature of the radio medium.