📡 Free Bluetooth Development Course · EmbeddedPathashala
Bluetooth development in c Bluetooth Architecture
Understand how Bluetooth is structured — layers, host, controller, HCI, and profiles — all explained simply.
Welcome!
Hello, students! Welcome to this free Bluetooth development course by EmbeddedPathashala, your go-to resource for embedded systems education.
In this lecture we will explore the Bluetooth architecture — what are different layers in bluetooth architecture, what each layer in bluetooth architecture does, and how all layers in bluetooth architeture work together. By the end of this page you will have a clear picture of how Bluetooth is organized inside any device you use every day.
Think of Bluetooth architecture like a building with floors. The ground floor handles the raw radio signals, the middle floors handle how data is packaged and sent, and the top floors are where your apps live. Each floor depends on the one below it. Let’s walk through them one by one!
🔑 Key Terms in This Lecture
1. The Big Picture — Bluetooth Layers
Bluetooth does not work as a single block of code. It is split into several well-defined layers, each responsible for a specific job. At a broad level there are four main pieces: the Controller, the Host (Upper Layers), the Profiles, and the Applications.
┌─────────────────────────────────────────────────────────────────────────┐ │ YOUR APPLICATION │ │ e.g. File Transfer App, Music Player, Find My Device │ ├─────────────────────────────────────────────────────────────────────────┤ │ PROFILES │ │ GAP · A2DP · OPP · FTP · HFP · HID · AVRCP · ... │ │ (define HOW protocol layers work together for a use-case) │ ├─────────────────────────────────────────────────────────────────────────┤ │ HOST (Upper Layers) │ │ L2CAP · RFCOMM · SDP · AVDTP · AVCTP · ... │ │ (complex features: serial emulation, data chunking …) │ ├─────────────────────────────────────────────────────────────────────────┤ ◄─┐ │ HCI (Host Controller Interface) │ │ │ UART / USB / SDIO / RS232 — defined by BT Spec │ ├── Bridge ├─────────────────────────────────────────────────────────────────────────┤ ◄─┘ │ CONTROLLER (Lower Layers) │ │ Baseband · Link Manager · LE Link Layer · Radio │ │ (lives inside the Bluetooth chip — handles raw radio communication) │ └─────────────────────────────────────────────────────────────────────────┘
Fig 1. High-Level Bluetooth Architecture — four main pieces stacked on top of each other.
The controller is the low-level workhorse of Bluetooth. It is physically embedded inside the Bluetooth chip (also called a Bluetooth SoC — System on Chip). Everything that requires direct contact with radio signals happens here.
Its responsibilities include:
- Device discovery — scanning the area for nearby Bluetooth devices.
- Establishing connections — setting up a communication link with another device.
- Exchanging data packets — sending and receiving raw data over the air.
- Security — encryption and authentication at the hardware level.
- Low-power modes — putting the radio to sleep when idle to save battery.
The host runs on the application processor — the main CPU of your phone, PC, or microcontroller. It uses the basic services provided by the controller to offer higher-level, more complex features.
Examples of what the host does:
- Serial port emulation — making Bluetooth look like a good old serial cable (RFCOMM).
- Transferring large chunks of data — breaking big data into small packets (segmentation) and reassembling them at the other end.
- Audio streaming — sending high-quality music wirelessly to your earphones (AVDTP is used for this).
Profiles sit on top of the protocol stack. They are not protocols themselves — they are guidelines that describe how multiple protocol layers should work together to implement a specific use-case.
Think of a profile like a recipe. A recipe does not invent new ingredients; it just tells you which existing ingredients to use, in what order, and in what quantities to bake a specific cake. A Bluetooth profile says: “To implement wireless audio, use these protocols in this sequence.”
Bluetooth SIG (the organization that owns the Bluetooth standard) requires that devices from different manufacturers must work together seamlessly. Your laptop may have a Realtek Bluetooth chip, and your earphones may use a MediaTek chip — yet they connect perfectly. That is because both follow the same profile specification.
Applications are the end-user facing software that you interact with directly. They use the functionality exposed by the profiles and protocol stack to do useful things.
Examples:
- Selecting a file and sending it over Bluetooth.
- Searching for nearby Bluetooth devices and showing a list on screen.
- A music app that streams audio to your earphones.
- A fitness app that reads heart rate data from a BLE sensor.
2. Protocol Classification — Core vs. Adopted
Bluetooth defines many protocols. These protocols are grouped into two categories depending on who wrote them:
BLUETOOTH PROTOCOLS │ ┌───────────────┴───────────────┐ │ │ CORE PROTOCOLS ADOPTED PROTOCOLS (written from scratch (borrowed from other by Bluetooth SIG) standard bodies) │ │ ┌──────┴──────┐ ┌───────┴────────┐ │ L2CAP │ │ RFCOMM │ │ SDP │ │ (from ETSI) │ │ Link Mgr │ ├────────────────┤ │ RFCOMM* │ │ OBEX │ │ HCI │ │ (from IrDA) │ └─────────────┘ ├────────────────┤ │ HID │ │ (from USB HID)│ └────────────────┘
Fig 2. Bluetooth protocol family tree — core protocols on the left, adopted protocols on the right.
| Type | Who Wrote It? | Examples | Why It Exists |
|---|---|---|---|
| Core Protocols | Bluetooth SIG (designed from scratch) | L2CAP, Link Manager, SDP, HCI | Bluetooth-specific needs that no existing standard could meet. |
| Adopted Protocols | Other standards bodies (borrowed and adapted) | RFCOMM (from ETSI), OBEX (from IrDA), HID (from USB) | Re-use proven, well-understood specifications instead of reinventing the wheel. |
3. Key Terminology — Host, Controller, and HCI
You will hear these three terms constantly in Bluetooth development. Let’s define them clearly once and for all.
┌──────────────────────────────────────────┐
│ HOST SOFTWARE │
│ • Runs on the application processor │
│ (phone CPU, PC CPU, microcontroller) │
│ • Contains: L2CAP, RFCOMM, SDP, AVDTP … │
│ • Contains: Profiles (GAP, A2DP, OPP …) │
│ • Contains: Your Applications │
└──────────────┬───────────────────────────┘
│
═══════════════╪═══════════════════════════
│ HCI (Host Controller Interface)
│ Physical link: UART / USB / SDIO / RS232
═══════════════╪═══════════════════════════
│
┌──────────────┴───────────────────────────┐
│ CONTROLLER (Bluetooth Chip) │
│ • Embedded in the Bluetooth SoC │
│ • Contains: Baseband, Link Manager │
│ • Contains: LE Link Layer, Radio │
│ • Handles all raw radio operations │
└──────────────────────────────────────────┘
Fig 3. Host, HCI, and Controller — where each piece lives and how they connect.
The Host refers to all the upper layers of the Bluetooth stack — everything above the HCI line. This includes:
- Protocol layers: L2CAP, RFCOMM, SDP, AVDTP, AVCTP, and more.
- Profiles: GAP, A2DP, OPP, FTP, and so on.
- Your application software.
The host software runs on the main CPU of your device — not on the Bluetooth chip itself.
The Controller is the Bluetooth chip itself (the SoC). It executes all the lower layers of the stack — everything below the HCI line: the Radio, Baseband, and Link Manager. These are implemented in firmware burned into the Bluetooth chip by the chip manufacturer.
HCI is the communication channel between the host and the controller. It is a well-defined protocol — specified by the Bluetooth standard — that describes exactly which commands the host can send to the controller and what responses (events) the controller sends back.
HCI can run on top of several physical transports:
4. Real-World Scenarios
Now that you know what host, controller, and HCI mean, let’s see how they map to real devices you use every day. There are three classic scenarios.
📦 Scenario 1 — PC + Bluetooth USB Dongle
┌─────────────┐ ┌─────────────┐ │ PC │ │ USB Dongle │ │ │ USB │ │ │ HOST │◄────►│ CONTROLLER │ │ (Windows / │ HCI │ (BT chip │ │ Linux) │ │ inside) │ └─────────────┘ └─────────────┘
- Host: Bluetooth stack on the PC OS (e.g., BlueZ on Linux, Windows BT stack).
- Controller: The Bluetooth chip inside the USB dongle.
- HCI transport: USB interface.
📱 Scenario 2 — Smartphone / Tablet
┌─────────────────────────────┐ │ SMARTPHONE │ │ │ │ ┌──────────────────────┐ │ │ │ Application CPU │ │ │ │ (HOST software) │ │ │ └──────────┬───────────┘ │ │ │ UART on PCB │ │ ┌──────────┴───────────┐ │ │ │ Bluetooth SoC Chip │ │ │ │ (CONTROLLER) │ │ │ └──────────────────────┘ │ └─────────────────────────────┘
- Host: Bluetooth stack on the phone’s application processor (ARM CPU).
- Controller: A separate Bluetooth SoC chip on the phone’s PCB.
- HCI transport: UART connection on the PCB between the two chips.
🖱️ Scenario 3 — Bluetooth Mouse / Headset
┌────────────────────────────┐ │ BLUETOOTH MOUSE │ │ │ │ ┌──────────────────────┐ │ │ │ Single MCU │ │ │ │ │ │ │ │ HOST + CONTROLLER │ │ │ │ (both on same chip) │ │ │ │ │ │ │ │ No HCI needed ✓ │ │ │ └──────────────────────┘ │ └────────────────────────────┘
- Host + Controller: Both run on a single microcontroller — no separation.
- HCI: Not needed — upper layers call lower layers directly in the same firmware.
- This design is used in simple, cost-sensitive Bluetooth devices.
5. Single Controller vs. Dual Controller (Bluetooth 3.0+ HS)
Before Bluetooth 3.0, a device was only allowed to have one host and one controller. Bluetooth 3.0+ HS (High Speed) changed this rule.
Before Bluetooth 3.0 Bluetooth 3.0+ HS onwards ┌──────────────────┐ ┌───────────────────────────────┐ │ HOST │ │ HOST │ └────────┬─────────┘ └──────────────┬────────────────┘ │ HCI │ HCI ┌────────┴─────────┐ ┌──────────────┴────────────────┐ │ ONE CONTROLLER │ │ PRIMARY CONTROLLER │ │ (BR/EDR or LE │ │ (BR/EDR only, LE only, or │ │ or BR/EDR+LE) │ │ BR/EDR + LE combined) │ └──────────────────┘ ├───────────────────────────────┤ │ SECONDARY CONTROLLER(s) │ │ AMP (Alternate MAC/PHY) │ │ e.g. Wi-Fi chip for 24 Mbps │ └───────────────────────────────┘
Fig 4. Before and after Bluetooth 3.0 — multiple controllers became possible.
Primary Controller — the main Bluetooth controller. It can support:
- BR/EDR only — Classic Bluetooth (e.g., older headsets, file transfer).
- LE only — Bluetooth Low Energy (e.g., fitness trackers, beacons).
- BR/EDR + LE combined — most modern smartphones.
Secondary Controller (AMP) — stands for Alternate MAC/PHY. This is an additional controller (often a Wi-Fi chip) that can be used to boost Bluetooth throughput up to 24 Mbps — much faster than standard Bluetooth. This is why this version is called High Speed (HS).
🎯 Quick Summary
1Bluetooth has four broad layers: Controller → Host → Profiles → Applications, each layer depending on the one below it.
2Controller = the Bluetooth chip (SoC). Handles radio, baseband, link management — all the low-level stuff.
3Host = software on your main CPU (phone/PC). Provides complex features like serial emulation, audio streaming, etc.
4HCI = the well-defined bridge between host and controller. Runs over UART, USB, SDIO, or RS232. Not needed when both are on the same chip.
5Profiles ensure interoperability — devices from different manufacturers work together because they follow the same profile specification.
6Core protocols are written by Bluetooth SIG from scratch. Adopted protocols are borrowed from other standards (USB, IrDA, ETSI) to save effort.
7Bluetooth 3.0+ HS introduced secondary AMP controllers, enabling throughput up to 24 Mbps via Wi-Fi.
📖 What’s Next?
In the next lecture, we will learn about the Bluetooth Device Address and Device Name — what they are, how they are assigned, and how devices use them to discover and identify each other. Stay tuned!
Keep Learning — It’s 100% Free!
EmbeddedPathashala offers free, high-quality courses on Embedded Systems, Linux Kernel Programming, and Bluetooth/BLE development. No paywalls, ever.