Bluetooth Low Energy Architecture Explained
A BLE application can request a sensor reading without constructing radio packets itself. The Bluetooth stack divides that work into cooperating parts.
What you’ll learn
- Identify application, Host, HCI and Controller responsibilities
- Place GAP, GATT, ATT, L2CAP, SMP, Link Layer and PHY in context
- Distinguish BLE roles from architectural divisions and BleuIO AT commands from HCI
Why use layers?
When an app reads a sensor, it deals with a measurement and an operation such as “read this value.” It should not have to choose every radio channel or assemble each over-the-air packet. Layers separate these responsibilities and give independently built devices a common way to communicate.
The Bluetooth Core Specification defines a Host and Controller as logical divisions, with a Host Controller Interface (HCI) between them. A manufacturer may place both on one chip or use separate components. The application sits above the core stack. This model helps developers locate a problem: discovery, permissions, attribute data, link behavior and radio reception are different concerns.
The architecture at a glance
Application: decides what the product does with data. Host: handles higher-level BLE procedures, data organization and security. HCI: is the standardized logical command and data interface at the Host–Controller boundary. Controller: manages lower-level link behavior and radio transmission.
This is a map of responsibilities, not a claim that every protocol box is stacked directly on every other one. Bluetooth LE also includes optional features beyond this introductory map.
Inside the Controller
The Physical Layer (PHY) defines how bits are transmitted and received over the radio, including supported modulation and physical channels. The Link Layer manages advertising and connection link procedures, scheduling and link-level packet handling. The Controller works with the physical radio hardware.
A poor antenna position may affect received packets even when the application code is correct. Conversely, a GATT read permission failure is a Host or application-level issue, not evidence that the PHY is broken. This distinction is useful when debugging.
Inside the Host
L2CAP routes data to the appropriate Host protocol and can segment and reassemble data. ATT defines client/server operations on a server’s attribute table, including discovery, reads, writes and server-initiated updates. GATT organizes those attributes as services, characteristics and descriptors and defines higher-level procedures for using them.
GAP defines discovery, advertising and connection-related modes and procedures, plus aspects of security and user interaction. SMP supports security procedures such as pairing and key management. The exact set of features used depends on the device and application; a broadcaster that never connects does not need the same data workflow as a connected GATT sensor.
ATT provides the attribute operations. GATT gives meaning and structure to groups of attributes. A service name in a device UI comes from the GATT model, while the actual read request uses ATT.
What HCI does—and does not mean
HCI is the Bluetooth-defined interface between the Host and Controller. It describes commands, events and data exchange at that boundary. “Host” and “Controller” do not require two physical chips; HCI remains a useful logical division when they are integrated.
A BleuIO dongle exposes a different interface to your computer: documented AT commands over USB serial. For example, an application can ask BleuIO to scan or perform supported BLE operations without implementing the complete BLE stack on the computer. These AT commands are not raw Bluetooth HCI commands. BleuIO’s firmware handles the underlying BLE behavior behind its own documented interface.
Follow a GATT read
Suppose a connected computer app asks to read a temperature characteristic on a sensor. The app chooses the characteristic; GATT/ATT represent the operation and attribute handle; L2CAP carries the ATT data; the Host passes relevant data across HCI; and the Controller sends it using the link and radio. The sensor’s stack receives it, checks whether the read is allowed, and returns a response through the reverse path. The application then decodes the returned bytes according to that characteristic’s format.
A read requires an established connection and the right attribute permissions. An advertisement can carry data without this flow. The diagram is a learning model, not a literal representation of every packet on the air.
Architecture is not a device role
Central and peripheral describe GAP connection roles. GATT client and server describe who initiates attribute operations and who holds the attribute table. Host and Controller describe where stack responsibilities sit. A central is often a GATT client, but that pairing is a common arrangement rather than a definition.
A phone and a sensor each have their own Host and Controller. The phone may act as the central and GATT client while the sensor acts as peripheral and GATT server. This is why a diagram showing “phone = Host” and “sensor = Controller” would be wrong: both devices need a working stack.
Explore the protocol stack
Choose a part of the stack to see its job. Then try to locate the layer involved in a failed scan, a denied GATT read and a weak radio signal.
Select a component to read its role.
If you want to see the developer-facing side of a BLE operation, the advertising lab uses the BleuIO Web App ↗ to send a high-level scan command. That command interface sits outside the Bluetooth HCI shown above.
Check your understanding
Which statement correctly describes BleuIO AT commands and Bluetooth HCI?
Key takeaways
- Host and Controller are logical stack divisions separated by HCI.
- GAP, GATT, ATT, L2CAP and SMP handle different Host responsibilities; Link Layer and PHY belong to the Controller.
- BLE roles, GATT client/server responsibilities and stack architecture answer different questions.
Further Reading and Resources
Save your progress in this browser.