ACK Procedure
================

.. contents::
   :local:
   :depth: 3

Overview
--------

IEEE 802.11 defines two acknowledgment mechanisms for confirming successful frame
delivery over the wireless medium:

- **Normal ACK (Immediate Acknowledgment)**
- **No-ACK Policy**

Because Wi-Fi operates on a shared, half-duplex medium, collision detection is impossible.
Hence, acknowledgments are essential to ensure reliability or, in some traffic types,
deliberately disabled to reduce overhead.

Why Acknowledgments Are Needed
------------------------------

- The wireless channel is prone to collisions and bit errors.
- Transmitters cannot detect collisions directly (unlike Ethernet).
- The receiver explicitly confirms successful frame reception using an **ACK frame**.
- Lack of ACK indicates a collision or channel error, triggering retransmission.

Normal ACK Procedure
--------------------

**Normal ACK (Immediate Acknowledgment)** is the standard and default mechanism for
unicast data and management frames. Each frame sent by a transmitter must be acknowledged
by the receiver within a strict timing window.

Sequence of Operations
~~~~~~~~~~~~~~~~~~~~~~

1. Sender contends for the channel using the DCF procedure (DIFS + backoff).
2. Sender transmits the DATA frame.
3. Receiver waits for a **SIFS** interval.
4. Receiver transmits an **ACK** frame.
5. Sender, upon receiving ACK before timeout, declares success.
6. If ACK is not received, the sender retries using exponential backoff.

Transmission Sequence
~~~~~~~~~~~~~~~~~~~~~

.. code-block:: none

   |<-- DIFS -->|<-- Backoff -->|------ DATA ------|<-- SIFS -->|-- ACK --|

ACK Frame Format
~~~~~~~~~~~~~~~~

The acknowledgment frame is a short control frame with the following fields:

+--------------------+------------------------------------------+
| Field              | Description                              |
+====================+==========================================+
| Frame Control      | Type = Control, Subtype = ACK            |
| Duration / ID      | Usually 0 (not used for NAV)             |
| Receiver Address   | MAC address of the sender of DATA frame  |
| FCS                | 32-bit CRC checksum                      |
+--------------------+------------------------------------------+

Properties:

- **Length:** 14 bytes
- **Type/Subtype:** Control (1) / ACK (13)
- **Rate:** Sent at the **lowest basic rate** supported by the BSS for reliability.
- **Timing:** Sent exactly **after SIFS** (Short InterFrame Space).

ACK Timeout
~~~~~~~~~~~~

The transmitter starts a timer immediately after sending the DATA frame.
If an ACK is not received before timeout, the transmission is considered failed.

**ACK Timeout (simplified):**

.. math::

   T_{ACK\_timeout} = SIFS + T_{ACK} + \text{propagation delay} + \text{margin}

Retransmission Procedure
~~~~~~~~~~~~~~~~~~~~~~~~

If no ACK is received:

1. Increment retry counter.
2. Double Contention Window (CW) up to CWmax.
3. Retransmit the frame using the same Sequence Number.
4. If retry limit exceeded → frame dropped, upper layers notified.

**Short Retry Limit (SRL):** typically 7
**Long Retry Limit (LRL):** typically 4

Fragmented Frame Acknowledgments
--------------------------------

When fragmentation is enabled:

- Each **fragment** is individually acknowledged.
- ACK is sent **after SIFS** following each fragment.
- The transmitter does not perform new backoff between fragments.

Example timing for fragmented frames:

.. code-block:: none

   Frag#0 → SIFS → ACK → SIFS → Frag#1 → SIFS → ACK → SIFS → Frag#2 → SIFS → ACK

Timing with RTS/CTS
-------------------

When RTS/CTS protection is used:

.. code-block:: none

   |<-- DIFS -->| RTS | SIFS | CTS | SIFS | DATA | SIFS | ACK |

- RTS/CTS reserve the medium.
- ACK confirms completion of the final DATA transmission.
- The ACK still follows **SIFS** after DATA.

No-ACK Policy
--------------

**No-ACK** is an optional policy where the transmitter sends frames without expecting
an acknowledgment. It is used when throughput is more critical than reliability.

Purpose and Use Cases
~~~~~~~~~~~~~~~~~~~~~

- Broadcast or multicast transmissions (always unacknowledged).
- Real-time or streaming data (tolerant to occasional loss).
- Certain management frames or test modes.

Sequence (No-ACK)
~~~~~~~~~~~~~~~~~

.. code-block:: none

   [Medium Idle for DIFS] → [Backoff Countdown] → DATA (no ACK expected)

Timeline:

.. code-block:: none

   |<-- DIFS -->|<-- Backoff -->|------ DATA (No ACK) ------|

Key Differences from Normal ACK:

- No SIFS + ACK exchange.
- No ACK timeout waiting.
- No retransmission on loss.
- Medium becomes available immediately after frame transmission ends.

NAV and Duration Behavior
-------------------------

For **Normal ACK**:
  - The **Duration field** reserves the channel for the ACK exchange.
  - Formula:

    .. math::

       Duration = SIFS + T_{ACK}

  - Other stations set NAV to defer transmission until the ACK completes.

For **No-ACK**:
  - **Duration field = 0**
  - Other stations may attempt contention as soon as the frame ends.

Comparison — Normal ACK vs No-ACK
---------------------------------

+------------------+-----------------------+-----------------------+
| Feature          | Normal ACK            | No-ACK                |
+==================+=======================+=======================+
| Reliability      | High (ACK confirms)   | None (no feedback)    |
| Retransmission   | Yes, per retry limit  | No                    |
| SIFS/ACK Timing  | Required              | Not used              |
| NAV Reservation  | Includes SIFS + ACK   | Duration = 0          |
| Efficiency       | Lower (overhead)      | Higher                |
| Use Case         | Unicast data/ctrl     | Broadcast, streaming  |
+------------------+-----------------------+-----------------------+

ACK and No-ACK Timing Diagrams
------------------------------

Normal ACK Sequence
~~~~~~~~~~~~~~~~~~~

.. code-block:: none

   Sender:   |<-- DIFS -->|<-- Backoff -->|------ DATA ------|<-- SIFS -->|-- ACK --|
   Receiver:                               Receives DATA     Wait SIFS    Sends ACK
   Other STAs: NAV set for (SIFS + ACK) duration

No-ACK Sequence
~~~~~~~~~~~~~~~

.. code-block:: none

   Sender:   |<-- DIFS -->|<-- Backoff -->|------ DATA (No ACK) ------|
   Receiver: (No ACK sent)
   Other STAs: medium becomes idle immediately after DATA ends

ACK Rate and Robustness
-----------------------

- ACKs are sent using one of the **basic rates** supported by the BSS.
- Selected rate ≤ rate of received frame.
- Ensures sender can always decode ACK, even in poor channel conditions.
- Control frames (RTS/CTS/ACK) are never encrypted.

Implementation Notes
--------------------

- ACKs must start **exactly SIFS** after the end of the received frame.
- **ACK timeout** must account for SIFS + ACK duration + PHY propagation delay.
- Retransmissions must follow exponential backoff with CWmin/CWmax limits.
- **NAV updates** depend on whether ACK is expected.
- Broadcast and multicast frames are *never* acknowledged.
- If receiver detects a CRC or PHY error, no ACK is sent (sender times out).

Edge Cases
----------

1. **Broadcast / Multicast Frames**
   - Never acknowledged.
   - Duration = 0.
   - No NAV updates.

2. **Hidden Node Collisions**
   - Failure to receive ACK triggers retransmission.

3. **PHY or CRC Errors**
   - Receiver drops frame silently, no ACK sent.

4. **Power Save Mode**
   - Dozing stations do not send ACKs until awake.

Timing Summary
---------------

+-------------------+--------------------------------------------+
| Parameter         | Description                                |
+===================+============================================+
| DIFS              | Idle period before new transmission        |
| SIFS              | Short gap between DATA and ACK             |
| ACK Timeout       | SIFS + ACK + guard margin                  |
| Retry Interval    | Determined by DCF backoff procedure        |
| NAV (Normal ACK)  | Includes SIFS + ACK duration               |
| NAV (No-ACK)      | Usually 0                                 |
+-------------------+--------------------------------------------+

Advantages and Tradeoffs
------------------------

+---------------+--------------------------------------------+-------------------------------------------+
| Policy        | Advantages                                 | Disadvantages                            |
+===============+============================================+===========================================+
| Normal ACK    | High reliability; per-frame feedback        | Control overhead; SIFS delay             |
| No-ACK        | Low latency; higher throughput potential    | Frame loss not detected; no retry       |
+---------------+--------------------------------------------+-------------------------------------------+

References
----------

- IEEE Std **802.11-2020**, Clause **9.3.2.8 (Acknowledgment)**
- IEEE Std **802.11-2016**, Clause **9.2.8.3 (No-ACK transmission)**
- M. Gast, *802.11 Wireless Networks: The Definitive Guide*
- Heusse et al., *Performance Anomaly of 802.11b*, IEEE INFOCOM 2003

Figures
-------

.. figure:: _static/ack_timing.svg
   :align: center
   :alt: Normal ACK timing diagram

   Normal ACK exchange between sender and receiver.

.. figure:: _static/no_ack_timing.svg
   :align: center
   :alt: No-ACK transmission timing diagram

   No-ACK transmission with no acknowledgment or SIFS interval.