A Brief Introduction to Bluetooth Low Energy Protocols: GAP, ATT, and GATT

The three core protocols in Bluetooth Low Energy (BLE) are GAP, ATT, and GATT. They work together to define how BLE devices are discovered, connected, and communicate. In simple terms:

GAP: Responsible for who is where. It handles device visibility, broadcasting, and connection establishment.
ATT: Responsible for how to read/write. It defines the underlying mechanisms and formats for data transmission.
GATT: Responsible for what to read/write. It builds on ATT and defines the logical structure for data organization.

1. GAP – Generic Access Profile

GAP is the top-level protocol for BLE device communication, determining how devices interact with the outside world, serving as the “gateway” for the entire BLE protocol.

Function:

- **Function**:
    Primarily defines how Bluetooth devices discover each other, establish connections, and manage those connections.

- **Device Roles**:
    In BLE, GAP defines four main roles: Peripheral, Central, Broadcaster, and Observer. The Peripheral is usually a low-power device that provides data and connects to a Central device, such as a Xiaomi band; the Central device is relatively powerful and connects to other Peripherals, like a smartphone.

- **Broadcasting and Scanning**:
    Peripherals announce their presence by broadcasting data (Advertising Data Payload) and scanning response data (Scan Response Data Payload). Each data can contain up to 31 bytes. Central devices scan to receive these broadcast packets, discovering nearby Bluetooth devices.

Device Role Definitions:

Peripheral: Typically small, resource-constrained devices, such as heart rate sensors or smart bands. They broadcast their presence and wait for a Central device to connect.
Central: Usually powerful devices like smartphones or computers. They scan for nearby broadcasting Peripherals and initiate connections.
Broadcaster and Observer: This is a connectionless model. The Broadcaster only sends data packets, while the Observer only receives, with no connection established between them.

Broadcasting:

Peripherals announce their presence by periodically sending small advertising packets.
Advertising packets can contain useful information, such as device name and supported services.
This is the primary way devices are discovered.

Discovery Process:

The Central device listens for nearby broadcast packets through scanning to discover available Peripherals.
Once discovered, users can see a list of connectable devices on their phone (e.g., “BT311”).

Connection Establishment:

The Central device can initiate a connection request to the selected Peripheral, and once accepted, a dedicated, point-to-point connection channel is established.

2. ATT – Attribute Protocol

- **Function**:
    It is the underlying transport protocol that defines how clients access attribute data from servers.

- **Attribute Structure**:
    Each attribute consists of a handle, UUID, and value. The handle is a unique identifier ranging from 0x0001 to 0xFFFF, the UUID identifies the attribute type, and the value is the actual data.

- **Operation Types**:
    Include discovery operations, read operations, write operations, notifications/indications, etc. Clients can use these operations to retrieve or modify data on the server, and the server can actively push data to the client through notifications or indications.

ATT is the foundation of GATT, defining a very simple client-server data model and a set of lightweight operation commands.

Concepts:

Attribute: The basic unit of data transmission in the ATT protocol. An attribute is a piece of data consisting of four parts:

Attribute Handle: A 16-bit unique identifier, akin to the “memory address” of the data. This is key to accessing attributes.
Attribute Type (UUID): A globally unique identifier that indicates what data this attribute represents (e.g., whether it is a “temperature reading” or “device name”).
Attribute Value: The content of the data itself.
Attribute Permissions: Defines whether the attribute is readable, writable, or requires encryption, etc.

Client-Server Model:

Server: The device that holds attribute data (usually a Peripheral). For example, a heart rate sensor holds the “heart rate measurement” attribute.
Client: The device that requests access to attribute data (usually a Central). For example, a mobile app wants to read the heart rate value.

Operation Commands: ATT defines a simple set of commands that clients use to operate on attributes on the server:

Notify: A “fire-and-forget” operation that does not require client confirmation.
Indicate: Requires a client response for confirmation, making it more reliable.

Read Request: The client requests to read the value of an attribute (specified by handle).
Write Request: The client requests to write a value to an attribute.
Notify / Indicate: The server actively sends a value of an attribute to the client (the server actively pushes data). This is a key mechanism for achieving low-power real-time data transmission (e.g., sensor data streams) in BLE.

3. GATT – Generic Attribute Profile

- **Function**:
    Defines how two BLE devices communicate through entities called Services and Characteristics.

- **Connection Characteristics**:
    GATT connections are exclusive, meaning a BLE Peripheral can only be connected to one Central device at a time. Once connected, the Peripheral immediately stops broadcasting, and when disconnected, it resumes broadcasting.

- **Communication Mode**:
    GATT communication is a C/S relationship. The Peripheral acts as the GATT server, while the Central device is the GATT client, with the client initiating requests to the server.

- **Structure**:
    GATT transactions are built on nested Profiles, Services, and Characteristics. A Profile is a predefined set of Services, a Service contains one or more Characteristics, and a Characteristic is the smallest logical data unit in GATT.

GATT is built on the ATT protocol, utilizing the mechanisms defined by ATT to specify how data is organized and presented to users. If ATT defines the syntax, GATT defines the semantics.

GATT employs a hierarchical data structure to organize attributes, making the data more meaningful, easier to understand, and access. This structure is as follows:

Service:

A service represents a specific function or a group of related data.
Each service is identified by a unique UUID.
For example: “Battery Service”, “Heart Rate Service”, “Device Information Service”.
A device can contain multiple services.

Characteristic:

A Declaration: Describes this characteristic (e.g., permissions, handle).
A Value: The actual data (this is an ATT attribute).
Zero or more Descriptors: Provide additional information about the characteristic.

A characteristic exists within a service and is the unit for actual data exchange. It can also be understood as a specific “data point” under a service.
Each characteristic is also identified by a unique UUID.
A characteristic contains:

Descriptor:

Descriptors provide additional metadata about the characteristic.
The most commonly used descriptor is the Client Characteristic Configuration Descriptor (CCCD). When the client writes 0x0001 to this descriptor, it enables the Notify feature of that characteristic; writing 0x0002 enables the Indicate feature.

GATT transactions are built on nested Profiles, Services, and Characteristics. A Profile is a predefined set of Services, a Service contains one or more Characteristics, and a Characteristic is the smallest logical data unit in GATT.

A typical data access process (using heart rate reading as an example):

The phone (GATT Client) connects to the band (GATT Server).
The phone browses the band’s GATT database and discovers a service with UUID 0x180D (this is the standard UUID for heart rate service).
The phone finds a characteristic under that service with UUID 0x2A37 (this is the standard UUID for heart rate measurement).
The phone reads the heart rate once using the Read Request command of ATT (using the handle of that characteristic value attribute).
Alternatively, the phone writes 0x0001 to the CCCD descriptor under that characteristic to enable the Notify feature for heart rate values. Thereafter, the band will periodically and automatically send the latest heart rate data to the phone without the phone needing to repeatedly ask, which is very energy-efficient.

Summary and Relationships

Protocol	Full English Name	Core Responsibilities	Analogy
GAP	Generic Access Profile	How devices are discovered and connected (broadcasting, scanning, roles)	Social Etiquette: How to introduce oneself and meet others
ATT	Attribute Protocol	How data is transmitted (client/server model, read/write commands)	Borrowing Rules: How to borrow and return books
GATT	Generic Attribute Profile	How data is organized (hierarchy of services, characteristics, descriptors)	Book Classification: How to categorize books on different shelves

Relationships:

GATT depends on ATT: GATT uses commands defined by ATT (read, write, notify, etc.) to operate on data.
GATT and ATT depend on GAP: Communication between ATT and GATT can only begin after GAP has completed device discovery and connection establishment.
In practical development (e.g., using Bluetooth APIs), the main interaction is with the GATT layer (discovering services, reading/writing characteristics), while the details of ATT and GAP are typically handled by the Bluetooth protocol stack and operating system.