BLE Architecture Overview

BLE problems often come from mixing phases, roles, and permissions into one bucket: being visible in a scan is not the same as being connected; being connected is not the same as being encrypted or ready for application data; and a successful mobile API callback does not mean every layer on the air interface and in the stack completed as expected.

If those boundaries are not separated early, later reading of GAP (Generic Access Profile), GATT (Generic Attribute Profile), ATT (Attribute Protocol), SMP (Security Manager Protocol), and Link Layer quickly collapses into one vague phrase: “the Bluetooth connection flow.”

BLE is not a single-layer protocol. It is a system that establishes a wireless link in stages, organizes data access by layer, and adds security and privacy only when needed.

What BLE Is Solving

BLE is not trying to replace classic Bluetooth in every scenario. It targets device connectivity problems that need lower power, shorter interactions, and a simpler data model:

• Battery-powered devices need long lifetime
• Each transfer is small, but communication happens frequently
• Phones, tablets, and gateways need fast discovery and access to peripherals
• Devices care more about advertising, connection, status reporting, and configuration than about continuous audio or video streams

Typical BLE devices are:

• Sensors
• Wearables
• Locks and home accessories
• Industrial data collectors
• Beacons and asset tags

Keep that target in mind, and later topics such as advertising, connection, pairing, and attribute tables become much easier to read. BLE is not just a smaller serial port with a long-lived connection.

The Main Path

From a debugging perspective, BLE usually follows this path:

Advertising and scanning
-> Establish LE connection
-> Enter periodic connection events
-> Service discovery and attribute access
-> Pairing, encryption, and bonding if needed
-> Ongoing reads, notifications, and reconnects

Five states matter more than the rest:

• Seen: the scanner has received advertising
• Connected: Central and Peripheral have entered connection state
• Link stable: connection events keep progressing
• Protected: encryption or pairing has completed
• Usable: services, permissions, notifications, and application logic are all working

A common mistake is to treat one state as another:

• Seeing a device name in the scan list does not mean it is connectable
• A successful connection callback does not mean service discovery will succeed
• Service discovery success does not mean protected characteristics are already accessible
• Being paired does not mean the same identity and keys will always be reused on reconnect

Once these stages are separated, the protocol stack finally has clear roles.

A Minimal BLE Model

The BLE stack can be reduced to a workable diagram:

Application
  -> GAP: discovery, advertising, scanning, connection, roles, address semantics
  -> GATT/ATT: service organization, attribute discovery, read/write, notify/indicate
  -> SMP: pairing, bonding, keys, privacy
  -> L2CAP: multiplexing and upper-layer transport
  -> HCI: the control boundary between host and controller
  -> Link Layer / PHY: air packets, connection events, ACK/retransmission, hopping, PHY

Each layer solves a different problem:

Debugging usually follows those boundaries:

• Can’t scan or connect: start with GAP
• Connected but unstable or slow: start with Link Layer / PHY
• Connected but services, handles, or notifications look wrong: start with GATT/ATT
• Permission failures, reconnect identity issues, or pairing problems: start with SMP

These layers are related, but debugging should start at the layer that owns the current responsibility.

GAP, GATT, and SMP

These three are often introduced together, but their positions in the main path are different.

GAP solves the entry problem

GAP is mainly about:

• Which role the device is playing: Broadcaster, Observer, Peripheral, or Central
• What state the device is in: advertising, scanning, initiating, or connected
• What other devices see through advertising and address information
• How connection parameters affect latency, power, and stability

So GAP is about how to enter the link, not how to access application data after connection.

GATT/ATT solves the data-plane problem

Once connected, the data path moves to GATT/ATT:

• ATT defines how to discover, read, and write attributes by Handle
• GATT defines how those attributes are grouped into Service, Characteristic, and Descriptor

If service discovery fails, a CCCD (Client Characteristic Configuration Descriptor) is wrong, or notifications do not arrive, that is not a GAP problem.

SMP is a security layer added when needed

SMP handles:

• Whether pairing is required
• Whether bonding is required
• How link encryption keys are established
• How address privacy and identity recovery work together

Many BLE devices connect first, discover services first, and only trigger pairing when protected characteristics are accessed. Security is not always a precondition for connection; it can also be introduced after connection when the access path needs it.

Roles and Layers Must Not Be Mixed Up

A common BLE mistake is to mix concepts from different dimensions.

These three groups are separate:

• Central / Peripheral: who initiates the connection and who is being connected
• GATT Client / Server: who sends requests and who owns the attribute table
• Advertising / Scanning / Connection: what state the device is in right now

In most products you will see:

• Phone: Central + GATT Client
• Sensor: Peripheral + GATT Server

They are not the same thing. Link roles, data-access roles, and state-machine roles belong to different layers. If you do not separate them, logs and packet captures quickly become hard to read.

Host and Controller Are the Real Implementation Boundary

In embedded systems, Linux, Android, phone SoCs, and dual-chip designs, knowing GAP/GATT/SMP is still not enough. BLE implementation also depends on the split between Host and Controller.

Host
  -> GAP / GATT / ATT / SMP / L2CAP
  -> maintains attribute tables, pairing state, and application logic

HCI
  -> command, event, and data boundary between Host and Controller

Controller
  -> Link Layer / PHY
  -> performs advertising, scanning, connection setup, connection events, encryption, and air exchange

• Application code usually runs on the Host
• Air behavior usually lives in the Controller
• The two sides communicate through HCI events and commands

That is why mismatched evidence is common in the field:

• The application log says “connection started”
• But no matching air behavior appears in the capture
• Or the host requested encryption, but the controller never entered the expected state

That is not necessarily a bug in one layer. It often means two different evidence sources are describing two different boundaries.

BLE Is Staged by Design

The staged design is not there to make the protocol look complicated. It exists because different problems need different mechanisms.

Discover first, then decide whether to connect

Advertising and scanning answer the question “Can I see you, and should I approach you?” At this point the device usually does not have a long-lived data link yet:

• Standby power can stay low
• Nearby devices can be filtered first
• You do not need to connect to every visible device

Once connected, stabilize the link first

After connection, both sides enter Connection Event cycles. This layer handles:

• When data is exchanged
• Whether acknowledgments are received
• Whether retransmission is needed
• How hopping improves robustness

If this layer is unstable, no GATT design will save the user experience.

Data access and security are not the same problem

GATT/ATT answers “which attribute do you access and how,” while SMP answers “are you allowed to access it, and how are keys created.” Separating them supports real-world cases such as:

• Public services can be read without pairing
• Configuration writes require encryption
• Initial connection can discover services first, and pairing only starts when sensitive data is accessed
• Reconnect can restore encryption and identity instead of repeating everything

In other words, BLE does not force “everything completed at connection time.” It splits link state, data access, and trust relationships into separate steps.

Reading Logs and Captures

BLE debugging is hard when every log is looked at without a clear boundary. Use the layers below:

When you have multiple kinds of evidence, keep their positions separate:

• Air captures are closest to the Controller view
• HCI logs are closest to the Host/Controller boundary
• Application logs are closest to the Host and business view

They do not always describe the same state at the same moment, but together they cover different boundaries of the BLE architecture.

Unified Debugging Entry Point

When a field issue arrives, the easiest mistake is to start from the wrong stage.

The order should be:

1. First confirm whether the problem happens before advertising, during connection setup, after connection, or after reconnect
2. Then confirm whether you have any one of these: air capture, HCI logs, or application logs
3. Check whether the link is really established, whether encryption has started, and whether service discovery happened
4. Only then start suspecting business fields, SDK APIs, or application logic

If you only have one entry point, prioritize as follows:

• Air behavior problems: inspect the air capture
• Host or phone behavior problems: inspect HCI or system logs
• Business protocol problems: inspect GATT reads/writes and application logs

Common symptoms can be mapped like this:

This table only exists to route the next step to the right article, the right capture layer, and the right field entry point.

What Each Article in This Set Solves

See the table below for the concrete problem each article addresses:

A Useful BLE Engineering Judgment

The minimal conclusion is:

BLE is not a single-stage protocol where everything is done once you connect. It is a wireless system that advances layer by layer through discovery, link setup, data access, and security establishment.

Engineering steps:

1. First identify which stage is blocked
2. Then ask which layer owns that stage
3. Only after that look at fields, parameters, SDK APIs, or application logic

If you see these symptoms next time, you will not start from the wrong entry point:

• A device appears in scan results but still cannot be used
• A connection succeeds, but notifications never arrive
• Pairing was done, but reconnect still behaves like a first meeting
• MTU was changed, but throughput barely changed

Further Reading

• BLE GAP Analysis: continue with advertising, scanning, connection setup, and connection parameters
• BLE Advertising Analysis: continue with advertising types, advertising data, scan response, and debugging entry points
• BLE Link Layer / PHY: continue with connection events, ACK/retransmission, hopping, and PHY
• BLE GATT/ATT Analysis: continue with service discovery, read/write, notifications, and attribute tables
• BLE SMP Security Pairing: continue with pairing, bonding, encryption, and privacy
• BLE Mesh: see why a network built on BLE bearer cannot be understood with a normal single-connection mental model