§ 1 — Control Packets Before the Piconet is Up

When two Bluetooth devices first interact, neither one has yet established a shared hopping sequence or a common channel. A small but critical set of special-purpose control packets handles the initialization phase. These packets are defined in the Baseband specification and are handled by the Link Controller hardware before the higher-level Link Manager Protocol (LMP) even gets involved.

NULL Packet

The NULL packet carries no user data — its sole function is acknowledgement. When a Master sends a data packet to a Slave and the Slave has nothing to transmit in return, it responds with a NULL packet. This tells the Master that the transmission was received without error and that the link is still alive. Think of it as a lightweight “ACK” at the baseband level that keeps the polling cycle running without wasting bandwidth on empty DM1 packets.

FHS — Frequency Hop Synchronisation Packet

The FHS packet is used for frequency hop synchronisation — either before a piconet channel is established for the first time, or when a role switch changes which device is acting as Master (since the hopping sequence is derived from the Master’s clock and address).

The FHS packet carries two pieces of information that are critical for synchronisation:

• BD_ADDR of the sender — a 48-bit device address, similar in concept to a MAC address.
• Clock value of the sender at transmission time — the Slave uses this to align its own clock offset and predict the hop sequence.

Crucially, if the FHS packet needs to be retransmitted (because no acknowledgement was received), the clock value is refreshed before each retransmission rather than replaying the stale timestamp. This ensures the clock information is always accurate at the moment it arrives, regardless of how many retransmission attempts were needed.

DM1 — Data Medium Rate, 1-Slot

The DM1 packet bridges control and data. It is the workhorse of the Link Manager — used to exchange LMP control messages between devices during connection setup, parameter negotiation, and encryption handshakes. However, DM1 can also carry regular user data, which makes it a useful fallback when devices cannot agree on a higher-performance packet type.

Its payload supports 0–17 bytes, giving a symmetric maximum rate of 108.8 kb/s — modest by modern standards, but perfectly adequate for control traffic where payload size is small and reliability matters more than throughput.

§ 2 — ACL Packet Types & Throughput Analysis

Asynchronous Connection-Less (ACL) links carry bursty data traffic — file transfers, protocol exchanges, and application data. The Bluetooth baseband defines a rich menu of packet types, categorised by data rate (Basic Rate vs. Enhanced Data Rate) and slot duration (1, 3, or 5 slots). Selecting the right packet type is a genuine engineering decision that affects throughput, latency, and power consumption.

Naming Convention

The naming scheme encodes useful information. DM = Data Medium-rate; DH = Data High-rate. A prefix of 2 or 3 indicates the EDR modulation scheme (π/4-DQPSK for 2× or 8DPSK for 3×). The trailing number (1, 3, 5) is the number of slots the packet occupies. So 3-DH5 means: EDR at 3× rate, high-rate coding, 5-slot packet.

Complete ACL Packet Type Reference

Choosing the Right Packet Type

The choice of packet type is not made by the application directly — it is negotiated by the two devices’ Link Managers at the time the ACL connection is created. Each device advertises which packet types it supports, and only mutually-supported types are used. After negotiation, the link controller selects among the agreed types based on channel conditions.

From an application design perspective, the key insights are:

• File transfer / download: Use 3-DH5 if EDR is available, otherwise DH5. These give maximum asymmetric throughput (data flows heavily in one direction; acknowledgements flow in the other).
• Interactive protocols: DH1 or 2-DH1 give lower latency since you do not wait for a 5-slot window to complete before responding.
• Constrained devices: DM packets include FEC (Forward Error Correction) which reduces payload size but improves reliability in noisy environments. DH packets sacrifice FEC for raw throughput.

BlueZ: ACL Connection & Packet Type Negotiation

In the Linux BlueZ stack, ACL connection creation and packet type selection is handled in the HCI (Host Controller Interface) layer. The hci_conn structure tracks the negotiated packet types per connection. The relevant source is in the BlueZ kernel tree under net/bluetooth/hci_conn.c:

🔗 BlueZ Source: lib/hci.c — Packet type definitions & HCI helpers 🔗 Kernel Source: net/bluetooth/hci_conn.c — ACL connection management

§ 3 — Synchronous Packet Types: SCO & eSCO

Bluetooth Classic was designed from day one to support wireless telephony and voice calls. This required a connection type fundamentally different from ACL — one that guarantees delivery at regular intervals regardless of channel noise. That is the role of synchronous links: SCO (Synchronous Connection-Oriented) and its enhanced successor eSCO.

SCO: HV and DV Packets

SCO uses HV (High Quality Voice) packets. Three variants exist — HV1, HV2, and HV3 — each carrying progressively more payload per packet (10, 20, and 30 bytes respectively) but all delivering a net voice rate of 64 kb/s. The difference is in Forward Error Correction: HV1 uses the most redundant FEC (1/3 rate) and HV3 uses none, relying on the application to tolerate occasional lost frames.

A crucial property of all HV packets: there is no CRC, and lost packets are never retransmitted. For voice, this is correct — replaying a stale audio frame would sound worse than the brief silence that comes from skipping it. The speech codec (typically CVSD or mSBC) handles concealment of lost frames.

The DV (Data-Voice) packet is a hybrid. It splits its payload into a voice section (which behaves like an HV packet — no CRC, no retransmission) and a data section (which includes CRC and is retransmitted on error). This makes DV useful when a headset needs to carry both a voice call and a small trickle of data simultaneously on the same SCO link.

eSCO: EV Packets with Windowed Retransmission

eSCO is an evolution of SCO that adds CRC protection and a retransmission window on all packets (EV series). If the receiver does not acknowledge within the retransmission window, the packet is sent again. This makes eSCO far more robust for high-quality audio codecs like aptX or mSBC that cannot tolerate any packet loss.

BlueZ: SCO Connection Setup

In BlueZ, SCO connections are created via hci_connect_sco(). The voice setting (which determines whether HV1/2/3 or EV packets are used, and which codec is active) is configured at the HCI level before connection establishment:

🔗 Kernel Source: net/bluetooth/hci_conn.c — SCO/eSCO connection handling

§ 4 — Link Controller State Machine

Every Bluetooth Classic device runs a state machine in its Link Controller hardware. At any given moment the device is in one of three major states, with seven substates used during the transitions between them. Getting a firm mental model of this state machine is essential — it is the foundation of every connection establishment and power-management sequence in the Bluetooth specification.

The Three Major States

Inside CONNECTION: Active, Sniff & Hold Modes

During the CONNECTION state, a device can further reduce power consumption by entering one of three sub-modes negotiated via LMP:

• Active mode: The device participates in every Master polling slot. Highest power, lowest latency.
• Sniff mode: The Slave listens only during agreed sniff intervals (e.g., every 100 ms). Most common power-saving mode for HID and sensor profiles.
• Hold mode: The Slave suspends ACL activity for a negotiated hold period, during which it can scan for other piconets or enter a deep-sleep cycle.

The Seven Substates

Substates are transient — a device enters them to perform a specific discovery or connection operation and then moves on. They are grouped into two categories:

Device Discovery Substates

These three substates implement the inquiry procedure, which allows a device to discover what other Bluetooth devices are in range without knowing their addresses in advance:

• Inquiry Scan: The device periodically listens on the two inquiry scan frequencies, waiting for an ID packet from a device performing an inquiry. A device in this substate is “discoverable.”
• Inquiry: The device broadcasts ID packets across all inquiry hop frequencies and collects FHS responses from devices in inquiry scan mode. The result is a list of BD_ADDRs and clock offsets for nearby devices.
• Inquiry Response: After a device in inquiry scan receives an inquiry ID packet, it enters this transient state and transmits an FHS packet back to the inquiring device.

Connection Establishment Substates

Once a device knows the address of its target (from a prior inquiry or from stored pairing info), these four substates execute the paging procedure to build the actual connection:

• Page Scan: The device listens on its own page scan hop frequencies. A device in this substate is “connectable.”
• Page: The initiating device (which will become Master) sends page ID packets to the specific BD_ADDR it wants to connect to, using the target’s predicted page scan hop sequence.
• Slave Response: Upon receiving a page ID packet, the paged device enters this state, sends a Slave response (its own ID packet), and waits for the Master’s FHS.
• Master Response: After receiving the Slave response, the Master sends its FHS packet (containing its BD_ADDR and clock) and transitions to full connection mode after receiving the Slave’s second acknowledgement.

Connection Establishment Flow (Visual Summary)

BlueZ: Triggering Inquiry & Page from Userspace

In BlueZ, the inquiry procedure is initiated via the hci_inquiry ioctl, which eventually triggers the HCI Inquiry command. The paging sequence is driven by hci_create_conn() in the kernel. From userspace tooling, hcitool scan exercises the inquiry substates and hcitool cc <bdaddr> exercises the paging substates:

🔗 Kernel Source: net/bluetooth/hci_core.c — Inquiry & connection state management 🔗 BlueZ Tools: hcitool.c — Userspace inquiry and connection commands