RF Wireless World

Browse articles, tutorials, tools, and vendors.

Bluetooth ARQ Explained: ACK, NAK & Retransmissions

By RF Wireless Expert Team

The 2.4 GHz wireless spectrum is a crowded spectrum. Wi-Fi routers, microwaves, baby monitors, and neighboring Bluetooth devices are constantly using frequencies from this band simultaneously. Because of this, it is an absolute certainty that some Bluetooth packets will be destroyed in mid-air.

So, how does a wireless keyboard never miss a keystroke? How does a file transfer arrive flawlessly without a single corrupted byte?

Bluetooth achieves this reliability using a fast, highly efficient error recovery system called Automatic Repeat Request (ARQ). By utilizing tiny 1-bit flags in the packet header, Bluetooth devices can instantly acknowledge successful deliveries or demand retransmissions. Let’s explore how this digital receipt system works.

The Core Mechanism: ARQ and ARQN Bit

Bluetooth uses a “fast, unnumbered acknowledgment” scheme. This means it doesn’t wait around to acknowledge a large batch of packets at once. Instead, every single data packet is acknowledged almost immediately in the next available time slot.

This is controlled by a single bit in the 54-bit Packet Header called the ARQN (Acknowledgment Request Number) bit.

Because Bluetooth is a two way street (Time Division Duplexing), devices take turns transmitting. When Device A sends a data packet to Device B, Device B will process it and then reply in its next designated time slot. Inside the header of Device B’s reply is the ARQN bit, which acts as the delivery receipt for Device A’s packet.

  • ACK (ARQN = 1): Positive Acknowledgment. Device B is saying, “I received your last packet perfectly. I am ready for the next one.”
  • NAK (ARQN = 0): Negative Acknowledgment. Device B is saying, “Your last packet was corrupted. Please send it again.”

What Triggers a NAK?

A receiver will issue a NAK (or refuse to issue an ACK) if any of the following happen:

  1. HEC Failure: The Header Error Check fails, meaning the routing information is corrupted.
  2. CRC Failure: The Cyclic Redundancy Check fails, meaning the actual user payload was corrupted by interference.
  3. MIC Failure: The Message Integrity Check fails, indicating an encryption error or tampering.
  4. The Implicit NAK: If the packet was so badly destroyed that the receiver didn’t even detect the Access Code, it won’t send a reply at all. The sender treats this “radio silence” as an implicit NAK.

The Duplicate Problem: Enter the SEQN Bit

Retransmitting data introduces a dangerous edge case: The Lost ACK.

Imagine Device A sends a photo to Device B. Device B receives it perfectly and sends an ACK (ARQN = 1). However, a sudden burst of Wi-Fi noise destroys the ACK before it reaches Device A. Device A assumes the photo was lost and retransmits it. Now, Device B has received the exact same piece of the photo twice! If left unchecked, the resulting image file would be hopelessly corrupted.

To solve this, Bluetooth uses the SEQN (Sequence Number) bit, also located in the packet header.

The SEQN bit is simply a toggle switch. It flips between 0 and 1 for every new packet sent.

  • If Device A is sending new data, the sequence goes: 0, 1, 0, 1.
  • If Device A is retransmitting a packet, it keeps the SEQN bit exactly the same as the previous attempt.

When Device B receives a packet, it checks the SEQN bit. If it sees two packets in a row with a SEQN of 0, it instantly realizes, “Wait, I already have this data!” Device B will safely discard the duplicate payload, but it will transmit another ACK (ARQN = 1) to help Device A realize the data was delivered and move on.

Knowing When to Quit: Flush Timeouts

If a sender receives a NAK, it will retransmit the exact same packet with the exact same SEQN. But it won’t do this forever.

If a user walks out of range, or the interference is too severe, the device could be stuck trying to send the same packet for hours. To prevent this, the Bluetooth Link Manager employs a Flush Timeout.

A Flush Timeout is a pre-negotiated countdown timer for a specific packet or message. If a packet has been retransmitted multiple times and the Flush Timeout expires before an ACK is received, the Baseband says, “Enough is enough.” It “flushes” (i.e. deletes) the packet from its transmit buffer, skips it and moves on to the next piece of data.

For reliable data transfers (like sending a file), the Flush Timeout is usually set to “infinite”; the connection will drop before it gives up on the packet. But for time sensitive data (like a video game controller input), the Flush Timeout is very short, because old inputs are useless.

Who Bypasses ARQ?

While the ARQ system is vital for standard data (ACL logical transports), there are two major exceptions in Bluetooth that completely ignore ACK/NAK and retransmissions.

  1. Legacy Voice Calls (SCO): Real-time synchronous audio cannot wait for retransmissions. If a piece of your voice is lost during a phone call, it is better to just drop it and keep the conversation moving in real-time. SCO packets do not have a CRC and do not use ARQ.
  • Note: The modern eSCO standard adds a tiny, limited retransmission window to fix this.
  1. Broadcasts (APB / CPB): When a Central device broadcasts data to multiple Peripherals at once, the Peripherals are not allowed to send ACKs. If five devices all shouted “ACK!” at the same time, the signals would collide and crash. Instead, broadcasts are simply transmitted multiple times in a row blindly, hoping all receivers catch at least one clean copy.

References & Further Reading

  1. Bluetooth SIG : Bluetooth Core Specification Version 6.3, May 5, 2026.
  2. Bluetooth SIG : Bluetooth Core Specification change history
  3. Bluetooth SIG : Bluetooth Technology Overview

Continue Learning Bluetooth Basic Concepts

Continue Learning Bluetooth Technology

Compare Bluetooth With Other Technologies

Explore Deep Insight Bluetooth Technology

Keep Reading

Related Posts