BLE Link Layer / PHY

The easiest place to misread BLE is the air interface: what looks like a GATT or business-logic problem often comes from connection events, retransmission, hopping, or link quality.

This article focuses on four things: how a connection starts from advertising, how connection events run, how ACK and retransmission affect the link, and why hopping and DLE (Data Length Extension) raise throughput and stability together.

Build the Smallest Useful Mental Model

From the top down, GAP describes what should happen, while Link Layer / PHY actually executes how packets are sent, when they are sent, on which channel, and whether they are retransmitted.

Reduce the BLE air interface to two cases:

Advertising stage: the device sends Advertising PDU (Protocol Data Unit) on advertising channels 37 / 38 / 39
Connection stage: both sides exchange Data PDU on the 37 data channels inside connection events

The most important thing is not the full packet syntax. It is separating:

Advertising solves the entry point for discovery and connection
Connection solves stable data exchange
Throughput, latency, power consumption, and interference resistance are all tightly tied to connection-event scheduling, retransmission, and hopping

How the 40 Channels Are Divided

BLE uses 40 RF channels in the 2.4 GHz band:

37, 38, 39: advertising channels
0 to 36: data channels

The point of this split is straightforward:

Discovery keeps the entry point concentrated on a few channels, so scanners can find advertising more easily
After connection, hopping across data channels reduces interference and collisions

If a capture shows that a device can advertise but is unstable, first check timing and content on the advertising channels. If it can connect but later drops packets or has poor throughput, then check connection-event behavior on the data channels.

How Connection Starts from Advertising

The advertising article already split out how devices are discovered, how advertising data is organized, and how scan response fills in missing information. In Link Layer / PHY, the advertising stage only needs one minimal path into connection state:

Advertiser sends ADV_IND
-> Scanner optionally sends SCAN_REQ
-> Advertiser returns SCAN_RSP
-> Initiator sends CONNECT_REQ
-> Both sides enter connection state

What matters here is the boundary:

SCAN_REQ / SCAN_RSP are only part of active scanning; they are not yet a connection
CONNECT_REQ is the action that switches from advertising state into connection state; it is not a GATT or SMP packet
Once connection succeeds, the main factors for latency, throughput, and stability are no longer the advertising packets, but the connection events

If you are still stuck on names appearing and disappearing, the primary advertising payload, or why the scanner cannot filter the target device, that is not this article’s main focus. Go back to BLE Advertising Analysis. This article starts from the moment connection state begins.

Connection Events Are the Real Main Unit

Once connected, the smallest real work unit in the Link Layer is the Connection Event.

You can think of it like this:

Both sides meet at an agreed time on a data channel
Central sends first
Peripheral replies
Within one connection event, several packet exchanges may happen in sequence
When there is no business payload, empty packets may still appear

That is why:

Connection interval directly affects latency and power consumption
Throughput is not only a GATT issue; it also depends on how many packets fit into one connection event
Seeing empty packets is not necessarily abnormal; they may just be part of link maintenance and ACK behavior

Why ACK, Empty Packets, and Retransmission Matter

Reliable delivery on BLE data channels is not based on the upper layer saying “I received it.” The Link Layer confirms and retransmits inside connection events.

The three things to keep in mind are:

After a correct packet is received, the next packet reflects acknowledgment state through sequence-related behavior
When there is no new payload, a device may still send empty packets to keep the event moving
If a packet is not acknowledged, the sender retransmits when it gets another chance

This leads directly to several common observations:

Seeing similar packets repeatedly in a capture does not necessarily mean the application sent duplicates; it may be Link Layer retransmission
Poor RF conditions, interference, or bad antennas usually show up first as more retransmissions
An upper layer may think “the write succeeded but the peer did nothing,” when the real root cause is that the air link is already in bad shape

Why Hopping Affects Stability

After connection, the two sides do not stay on a single data channel. They hop across the 37 data channels using shared parameters.

The engineering value of hopping is:

Avoid persistent interference
Spread collision risk
Improve robustness

If some channels are bad, the controller can also remove them from the Channel Map. So when a capture shows the channel changing constantly, that is often not noise or confusion; it is BLE stability design working as intended.

Where PHY, DLE, and MTU Each Apply

These three concepts are easy to mix up, so separate them first:

PHY: physical-layer speed and coding, which determines how an air packet is sent
DLE: Link Layer data length extension, which determines how much a Link Layer data PDU can carry
ATT MTU: how much upper-layer data one ATT PDU can carry

So:

MTU is an ATT-layer concept
DLE is a Link Layer concept
PHY sits below both

They often appear together, but they are not the same knob:

Increasing MTU alone may still leave Link Layer fragmentation in place
Enabling DLE alone does not help much if ATT is still at the default 23
A smooth state usually comes from MTU, DLE, connection parameters, and the sending model working together

When you talk about throughput, these three layers must be separated. Otherwise, it is easy to misjudge why “MTU got larger, but it is still not fast.”

What Really Constrains Throughput, Latency, and Stability

BLE performance is not determined by one parameter. It is the result of several layers combining their constraints.

At minimum, you need to look at these four layers:

Layer	Main constraint
`ATT / GATT`	Whether you are using `Read/Write Request` or `Notification/Write Command`, and the `MTU` size
`Link Layer`	How much one data PDU can carry, how many packets fit into one connection event, and whether retransmission happens
`PHY`	How long each packet stays on air, and the trade-off between speed and coverage
Platform implementation	Controller scheduling, buffers, queue depth, task scheduling, and phone OS policy

So “slow” can mean four very different root causes:

Model slow: you are using request-response mode for continuous transfer
Event slow: connection events are too sparse, so the air-interface opportunity is not enough
Air slow: retransmissions are too frequent, and theoretical throughput is eaten away
Implementation slow: application threads, buffers, or platform policy cannot feed the link fast enough

A practical order of checks is:

Confirm whether the current main path is Read/Write Request or Notification / Write Command
Confirm whether MTU has been negotiated and whether DLE is active
Check how many packets are exchanged in one connection event
Finally check whether retransmission is obvious, whether there are too many empty packets, or whether the implementation side is not keeping up

What to Look at in Captures

For air-interface debugging, these signs are more useful than memorizing field names:

Does the device appear stably on the advertising channels?
Does SCAN_REQ / SCAN_RSP happen?
Does CONNECT_REQ appear successfully?
After connection, do connection events continue to run?
Are there many retransmissions, empty packets, or obvious losses?
Is the channel being excluded frequently, or is the link dropping quickly?

Common judgments can be split like this:

Cannot scan: first check whether advertising is really being sent and whether the scanner can hit the advertising channels
Cannot connect: first check whether CONNECT_REQ is sent and accepted
Low throughput: first check how many packets are exchanged in each connection event and whether retransmission is frequent
Occasional disconnects: first check whether the link layer is already weak, then go back and question GATT or application logic

If you have both an air capture and host logs, use this order:

Phenomenon	What to check in the capture	What to check in host logs
Cannot scan	Whether `ADV_*` appears stably	Scan filtering conditions, duplicate filtering
Cannot connect	Whether `CONNECT_REQ` is sent	Connection initiation failure reason, timeout
Low throughput	How many packets are exchanged per connection event	`MTU` / `DLE` / queues and buffers
Occasional disconnects	Retransmissions, empty packets, channel quality	`Disconnect Reason`, controller events

If all you get is “it is too slow” or “it is unstable,” collapse the symptom further into the table below:

Symptom	First thing to suspect
`MTU` is already negotiated large, but throughput is still low	`DLE`, connection-event utilization, retransmission
The upper layer writes frequently, but the air capture shows very few exchanges	Connection-event packet count is limited, or the controller implementation is limiting throughput
Similar packets appear repeatedly in the capture	Link-layer retransmission, not necessarily repeated application sends
Functionally correct, but latency feels high	Check connection parameters in `GAP` first, then air scheduling in `Link Layer`
Fine in close range, but speeds drop in a more complex environment	Interference, hopping, antenna, and channel quality

References

Bluetooth Core Specification

Bluetooth Core Specification
- Vol 6, Part B: Link Layer Specification
  - Section 2: Physical layer
  - Section 4: Air interface protocol
  - Section 4.4: Advertising physical channel PDU
  - Section 4.5: Data physical channel PDU
Official entry: https://www.bluetooth.com/specifications/specs/