In the previous article we saw that a Logical Transport (ACL, SCO, eSCO) is a pipe between a Master and a Slave. A Logical Link is a named sub-channel that rides inside that pipe and is dedicated to carrying a specific kind of traffic.

The simplest way to understand this distinction is with an analogy. Imagine an ACL transport as a highway. On that highway you have different lanes — one lane carries trucks (control messages between link managers), another carries cars (user data from your app). Each lane is a Logical Link. They all share the same physical highway, but they carry different types of cargo and have different priority rules.

LOGICAL LINKS ON TOP OF LOGICAL TRANSPORTS
============================================================
ACL Logical Transport
┌─────────────────────────────────────┐
│  ┌─────────┐      ┌─────────────────┐  │
│  │  ACL-C  │      │      ACL-U      │  │
│  │ Control │      │    User Data    │  │
│  │  (LMP)  │      │  (L2CAP layer)  │  │
│  └─────────┘      └─────────────────┘  │
└─────────────────────────────────────┘
(LC link rides inside packet headers, not payload)

SCO Logical Transport
┌─────────────────────────────────────┐
│  ┌─────────────────────────────┐    │
│  │            SCO-S            │    │
│  │   Synchronous Voice Stream  │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

eSCO Logical Transport
┌─────────────────────────────────────┐
│  ┌─────────────────────────────┐    │
│  │           eSCO-S            │    │
│  │   Enhanced Sync Voice/WBS   │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘
============================================================

LC Link — the Invisible Link

The LC link is special because it does not get a slot in the packet payload. Instead, it is embedded directly in the packet header of every single Bluetooth packet that is transmitted. Fields like the acknowledgement bit (ARQN), the flow control bit (FLOW), and the sequence number (SEQN) are all LC link fields. This makes the LC link an ever-present background channel — you cannot send any Bluetooth packet without also sending LC information.

ACL-C vs ACL-U — Priority Matters

Both ACL-C and ACL-U share the same ACL logical transport, but they are not treated equally. ACL-C has higher priority than ACL-U. This makes sense — you never want your application’s file download to block a critical LMP control message that manages the connection itself.

Let’s walk through three everyday Bluetooth use cases and see exactly which links are involved in each one.

[Phone] ──────── ACL Link ──────────► [Laptop]
                 │
               ACL-U 
           (L2CAP data)
                 │
        FTP profile on top
       File chunks transferred 
       in bursts, retransmitted 
             if lost

[Phone] ──── Physical Link ────► [Headset]
             │            │
           [ACL]     [SCO / eSCO]
             │            │
       HFP commands   Voice audio
       (call accept,  (64 kbps or 
       volume, mute)  WBS 16kHz)

[Phone]                             [Stereo Headset]
   │                                       │
   │   MP3 / AAC → SBC encode              │
   │                                       │
   │ ────── ACL-U link (L2CAP + A2DP) ────►│
   │                                       │
   │         SBC compressed stream         │
   │                                       │
   │                        SBC decode → speaker


Sampling rates:
────────────────────────────────────────────────────────────
Voice (SCO) :  8,000 Hz → only 64 kbps, fine for calls
WBS (eSCO)  : 16,000 Hz → richer but still voice-only
Music (ACL) : up to 48,000 Hz → SBC codec needed
============================================================

In BlueZ (the Linux Bluetooth stack), when user-space code opens an L2CAP socket to a remote device, it is actually using the ACL-U logical link underneath. The kernel sets up the ACL transport automatically. Here is what that looks like at the application level:

#include <stdio.h> #include <string.h> #include <sys/socket.h> #include <bluetooth/bluetooth.h> #include <bluetooth/l2cap.h> int main(void) { /* AF_BLUETOOTH + BTPROTO_L2CAP creates a socket that rides on the ACL-U logical link. Every L2CAP PSM connection you open to a remote device goes through the ACL transport. */ int sock = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP); if (sock < 0) { perror("socket"); return 1; } struct sockaddr_l2 addr = {0}; addr.l2_family = AF_BLUETOOTH; addr.l2_psm = htobs(0x1001); /* PSM for your custom service */ /* Remote device address — replace with your target */ str2ba("AA:BB:CC:DD:EE:FF", &addr.l2_bdaddr); /* connect() triggers an ACL connection at the HCI level. BlueZ's kernel module (net/bluetooth/l2cap_core.c) will: 1. Check if an ACL link to this BD_ADDR already exists. 2. If not, issue HCI_Create_Connection to the controller. 3. Once ACL is up, open the L2CAP channel on ACL-U. */ if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("connect"); return 1; } printf("ACL-U link established via L2CAP socket\n"); /* From here: send() / recv() carry your user data on ACL-U */ return 0; }

If you want to watch the actual ACL link come up at the HCI level, you can use btmon while running the above code:

For SCO (voice) connections, BlueZ uses BTPROTO_SCO instead. The kernel internally issues HCI_Add_SCO_Connection or HCI_Setup_Synchronous_Connection to the controller, which creates the SCO or eSCO logical transport and the SCO-S / eSCO-S link on top.

Every packet sent over a Bluetooth physical channel has the same three-part structure at the top level: an Access Code, a Header, and a Payload. Only the Access Code is mandatory. The Header and Payload are optional depending on the packet type.

STANDARD BR (BASIC RATE) PACKET FORMAT
============================================================
┌──────────────┬──────────────┬──────────────────────┐
│ ACCESS CODE  │    HEADER    │       PAYLOAD        │
│  (72 bits)   │  (54 bits)   │   (0 – 2745 bits)    │
└──────────────┴──────────────┴──────────────────────┘
  ^ Mandatory     ^ Optional      ^ Optional

STANDARD EDR (ENHANCED DATA RATE) PACKET FORMAT
============================================================
┌──────────────┬──────────────┬───────┬──────┬──────────────┬─────────┐
│ ACCESS CODE  │    HEADER    │ GUARD │ SYNC │   PAYLOAD    │ TRAILER │
│  (72 bits)   │  (54 bits)   │       │      │              │         │
└──────────────┴──────────────┴───────┴──────┴──────────────┴─────────┘
  ^ Extra fields needed because EDR switches modulation for payload
============================================================

The modulation scheme changes between the header and payload in an EDR packet. The GUARD and SYNC fields signal this transition to the radio hardware so it can switch cleanly. The TRAILER marks the end of the high-speed payload section. We will cover this more in the EDR section below.

The Access Code is the very first thing in every Bluetooth packet and it is always present. Before the receiver even looks at the header or payload, it checks the Access Code. If the code does not match what the receiver expects, the entire packet is silently discarded.

It serves three purposes at once: synchronisation (helps the receiver lock its clock to the incoming signal), DC offset compensation (corrects for any DC bias in the radio hardware), and identification (tells the receiver whether this packet belongs to its piconet or not).

WHICH ACCESS CODE DOES EACH PHASE USE?
============================================================
Phase         Access Code Used      Purpose
───────────── ───────────────────  ──────────────────────
Discovery     IAC                  "Is anyone out there?"
Paging        DAC (target BD_ADDR) "Calling device XYZ..."
Connected     CAC (piconet key)    "This belongs to our net"

Receiver logic on every packet:
┌──────────────────────────────────────────────┐
│              Read Access Code                │
│                     ↓                        │
│   Does it match expected code for my mode?   │
│                                              │
│       YES → process header + payload         │
│        NO → silently discard, look for next  │
└──────────────────────────────────────────────┘
============================================================

The 54-bit packet header carries six fields. Together they tell the receiver who should process this packet, what type it is, whether to pause or resume sending, whether the previous packet was received correctly, and whether this header itself is intact.

BLUETOOTH PACKET HEADER (54 bits total, includes 1/3 rate FEC)
============================================================
┌──────────┬──────┬──────┬──────┬──────┬─────┐
│ LT_ADDR  │ TYPE │ FLOW │ ARQN │ SEQN │ HEC │
│  3 bits  │4 bits│1 bit │1 bit │1 bit │8bits│
└──────────┴──────┴──────┴──────┴──────┴─────┘

The full 54 bits = 18 raw bits encoded with 1/3 rate FEC 
(every bit sent 3 times for robust header delivery)
============================================================

The payload section holds the actual data being transferred, followed by a CRC for integrity checking. The payload’s internal structure depends on the logical transport it belongs to:

PAYLOAD STRUCTURE BY PACKET TYPE
============================================================
ACL Packet Payload:
┌──────────────────────────────────┬───────┐
│     Asynchronous Data Field      │  CRC  │
│  (L2CAP frames, LMP messages)    │       │
└──────────────────────────────────┴───────┘

SCO/eSCO Packet Payload:
┌──────────────────────────────────┐
│     Synchronous Data Field       │
│  (PCM voice samples — no CRC)    │
└──────────────────────────────────┘
Note: SCO payloads have no CRC because dropped voice 
bytes are not retransmitted.

DV Packet Payload (special — carries both):
┌────────────────┬──────────────────────┬───────┐
│   Sync Data    │      Async Data      │  CRC  │
│    (Voice)     │   (ACL-C LMP data)   │       │
└────────────────┴──────────────────────┴───────┘
DV = Data + Voice in a single packet
============================================================

The DV (Data-Voice) packet is an interesting special case. It carries voice in the synchronous field and control data (LMP) in the asynchronous field — both inside a single packet. Only the async part has a CRC because voice data doesn’t need error correction.

BR (Basic Rate) packets use GFSK (Gaussian Frequency Shift Keying) modulation throughout — for both the header and payload. At 1 Mbps it gives decent throughput.

EDR (Enhanced Data Rate) keeps GFSK for the access code and header (for backward compatibility with every Bluetooth receiver), but then switches to a more efficient modulation for the payload — either π/4-DQPSK (2 Mbps) or 8DPSK (3 Mbps). This is why EDR packets need three extra fields that BR packets don’t have:

EDR MODULATION SWITCH
============================================================
[ACCESS CODE] [HEADER] [GUARD][SYNC][PAYLOAD][TRAILER]
      ↑          ↑       ↑     ↑      ↑        ↑
     GFSK       GFSK  Transition    EDR mod  Return to
   (1 Mbps)   (1 Mbps) ramp-down  π/4-DQPSK   GFSK / end
                                   or 8DPSK

GUARD : ramp-down period, radio transitions out of GFSK
SYNC  : synchronisation sequence, receiver locks to EDR
TRAILER: marks end of EDR payload, radio transitions back

Result: header stays compatible with all BT receivers. 
Only EDR-capable receivers decode the payload.
============================================================

The 4-bit TYPE field in the header can represent 16 values (0–15). Different sets of values are interpreted differently depending on the logical transport. Broadly, packet types fall into three categories:

Bluetooth packet names look cryptic at first but each character has a specific meaning. Let’s decode two examples:

READING ACL PACKET NAME — 3DH5
============================================================
  3  D  H  5
  │  │  │  │
  │  │  │  └── Occupies 5 time slots
  │  │  │
  │  │  └────── High Rate packet (H = High Rate)
  │  │
  │  └────────── D = ACL Data Packet
  │
  └────────────── EDR prefix: 3 = 8DPSK (3 Mbps)
                  (No prefix = Basic Rate 1 Mbps)

So "3DH5" = EDR, ACL data, high-rate, 5-slot packet
─────────────────────────────────────────────────
READING SYNC PACKET NAME — 2EV3
============================================================
  2  E  V  3
  │  │  │  │
  │  │  │  └── Occupies 3 time slots
  │  │  │
  │  │  └────── V = Voice (synchronous)
  │  │
  │  └────────── EV = Enhanced Voice → eSCO packet
  │
  └────────────── EDR prefix: 2 = π/4-DQPSK (2 Mbps)
                  (HV or DV prefix = SCO packet)

So "2EV3" = EDR, eSCO, 3-slot voice packet
============================================================

For BR packets there is no numeric prefix — so DH3 is a 1 Mbps ACL high-rate 3-slot packet, and HV1 is a 1 Mbps SCO voice 1-slot packet.

These five packet types are used to manage the piconet itself — before, during, and after connection setup. None of them carry user data (except DM1 which can also carry control data).

ID Packet:
┌──────────────┐
│ ACCESS CODE  │  <-- No Header, No Payload
│  (DAC / IAC) │      Most robust, minimal size
└──────────────┘

NULL Packet use-cases:
┌──────────────────────────────────────────────────┐
│  Master sends data → Slave has nothing to send   │
│  Slave replies with NULL (ARQN=1 = got it fine)  │
│                                                  │
│  Slave buffer fills up → FLOW=0 in NULL          │
│  Master pauses → Slave clears buffer             │
│  Slave sends FLOW=1 → Master resumes             │
└──────────────────────────────────────────────────┘

POLL / NULL interaction:
   Master                         Slave
     │                              │
     │──── POLL ──────────────────► │  "Are you there? Any data?"
     │                              │
     │◄─── NULL ─────────────────── │  "Yes I'm here, nothing to send"
     │                              │
     │             OR               │
     │                              │
     │◄─── [Data Packet] ────────── │  "Yes I'm here, here's my data"
     │                              │

Note: NULL does not require an ACK from Master.
POLL always requires a response from Slave.