Chapter 13 — Generic Attribute Profile (GATT)
Part 1 of 2 · Introduction · Profile Architecture · Profiles Services Characteristics · Roles · Caching · Notifications · Service Definition
13.1 — Introduction
GATT Adds Structure to ATT’s Flat Attribute List
ATT defines a flat collection of attributes — just a list of numbered data items — without any organisation. GATT takes those same attributes and groups them into a hierarchy: profiles contain services, services contain characteristics, and characteristics have descriptors. This makes any BLE device discoverable and understandable to any GATT client without prior knowledge of that specific device’s internals.
GATT is mandatory for all LE devices. It is optional on BR/EDR. Every BLE device must implement both GAP and GATT at minimum before any application-level profiles can be added.
The << >> notation: Throughout GATT documentation, angle-bracket pairs like <<Primary Service>> or <<Characteristic>> indicate Bluetooth SIG-defined UUIDs. These are standardised 128-bit values, but a shorter 16-bit equivalent is used in practice.
13.1.1 — Profile Dependencies
GATT-based profile architecture has only two layers — much simpler than classic BR/EDR profiles which had many nested layers. GAP and GATT sit in the outermost box. All application profiles (Heart Rate, Proximity, Find Me, etc.) sit at the same flat level inside GAP/GATT. No profile depends on another application profile.
13.1.2 — Profile → Service → Characteristic Hierarchy
A profile is a collection of one or more services that fulfil a complete use case (e.g., heart rate monitoring). A service is a logical group of related data items (e.g., the Heart Rate Service). A characteristic is one specific value within a service (e.g., the Heart Rate Measurement value).
Service reuse: The Immediate Alert Service is mandatory in Find Me Profile but optional in Proximity Profile. If a device implements both profiles, it exposes only one instance of the Immediate Alert Service and both profiles share it. This keeps the attribute database compact and avoids duplication.
13.2 — GATT Roles: Client and Server
A GATT Server holds the attribute database — services, characteristics, descriptors. It responds to client requests and sends notifications/indications. Simple sensors typically only implement the server role. A GATT Client initiates transactions and receives responses. A phone is usually the client. A device can be both simultaneously.
(Mobile Phone)
(Heart Rate Monitor)
13.3.1 — Attribute Caching — Saves Discovery Overhead
Service discovery (running all those Read By Group Type and Read By Type requests) takes time and uses radio airtime. GATT lets clients store the discovered attribute database and reuse it across connections. A phone that paired yesterday does not need to rediscover the Heart Rate Monitor’s services today — it uses its cached copy.
13.3.3 — Notifications and Indications — Push Instead of Poll
The difference between polling and push matters enormously for battery life. A client that reads the heart rate every second burns 60 ATT transactions per minute even when the user is asleep and the rate is flat. A client that subscribes to Notifications receives data only when the sensor actually has a measurement to send — potentially saving hours of battery life.
Like a microprocessor reading keyboard registers every 10ms to detect keypresses. Even if no key is pressed, the CPU is busy reading. Wasteful if events are rare.
The keyboard sends an interrupt only when a key is actually pressed. The CPU does nothing until the interrupt fires. This is how Notifications and Indications work — the server pushes data only when it has data.
Health Thermometer Profile uses Indication for temperature — each measurement is important and must be confirmed received. Heart Rate Monitor uses Notification for heart rate — missing one sample in a stream of 60-per-minute is acceptable and avoids confirmation overhead.
13.4 — Service Definition Structure
Three Parts — Declaration, Includes, Characteristics
Every service starts with a Service Declaration attribute, followed by zero or more Include Definitions (references to other services), followed by zero or more Characteristic Definitions. This sequence is fixed — declarations before includes, includes before characteristics.
| Property | Bit Value | What It Means |
|---|---|---|
| Broadcast | 0x01 | Value can be broadcast in advertising data |
| Read | 0x02 | Client can read this characteristic |
| Write Without Response | 0x04 | Client can write using Write Command (no ACK) |
| Write | 0x08 | Client can write using Write Request (with ACK) |
| Notify | 0x10 | Server can send Handle Value Notifications |
| Indicate | 0x20 | Server can send Handle Value Indications |
| Authenticated Signed Writes | 0x40 | Signed Write Command permitted |
| Extended Properties | 0x80 | More properties in Extended Properties Descriptor |
/* Exploring GATT services and characteristics with bluetoothctl */
bluetoothctl
[bluetooth]# connect AA:BB:CC:DD:EE:FF
[AA:BB:CC:DD:EE:FF]# list-attributes
/* Output shows full hierarchy: */
/* Primary Service */
/* /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service000a */
/* UUID: 0000180d-0000-1000-8000-00805f9b34fb */
/* Heart Rate (0x180d) */
/* Characteristic */
/* /org/bluez/hci0/.../service000a/char000b */
/* UUID: 00002a37-0000-1000-8000-00805f9b34fb */
/* Heart Rate Measurement (0x2a37) [notify] */
/* Descriptor */
/* /org/bluez/hci0/.../service000a/char000b/desc000d */
/* UUID: 00002902-0000-1000-8000-00805f9b34fb */
/* Client Characteristic Configuration (CCCD) */
/* With Python / BlueZ D-Bus to read Characteristic Props: */
import dbus
bus = dbus.SystemBus()
char = bus.get_object('org.bluez', '/org/bluez/hci0/.../char000b')
props = dbus.Interface(char, 'org.freedesktop.DBus.Properties')
flags = props.Get('org.bluez.GattCharacteristic1', 'Flags')
print(flags) # ['notify'] — matches Properties bit 0x10 Next — GATT 11 Features & All Procedures
Part 2 covers the complete Table 13.2 — all 11 GATT features from Server Configuration through Characteristic Descriptor Value Write with their subprocedures.