In Bluetooth Low Energy (BLE) technology, GATT (Generic Attribute Profile) is the core framework that defines how devices transmit data over Bluetooth. It is not only the “syntax” of BLE communication but also the foundation for standardized interactions between devices. Whether it is a smartwatch synchronizing health data, sensors uploading environmental information, or smartphones controlling smart home devices, GATT quietly supports the efficient operation of these scenarios.
The Essence of GATT: A “Data Dictionary” Based on ATT
GATT is built on top of the lower-level ATT (Attribute Protocol). ATT abstracts all accessible data in a device into “attributes,” each identified by a unique handle (Handle, a 16-bit number), type (UUID), and value (Value). For example, the “current heart rate value” of a heart rate sensor may correspond to an attribute with a handle of 0x002A, its type being the UUID for heart rate measurement (e.g., 0x2A37), and the value being the specific number (e.g., 72 BPM). This design allows devices to focus on the logical representation of data rather than its physical storage location, enabling precise targeting of information through handles and UUIDs.
Building on this, GATT further standardizes the organization of attributes into a three-layer structure: “Services,” “Characteristics,” and “Descriptors,” forming a clear “data dictionary.” This layered model is the core innovation of GATT—it allows devices from different manufacturers to describe their functionalities according to unified rules, thus achieving interoperability across devices.
Three-Layer Architecture: Collaboration of Services, Characteristics, and Descriptors
Services: Logical Containers of Functionality
Services are the top-level logical units in GATT, representing a complete category of functionality provided by a device. For example, a heart rate sensor may include a “Heart Rate Service” (UUID: 0x180D), while an environmental monitoring device may include a “Temperature Service” (UUID: 0x181A) and a “Humidity Service” (UUID: 0x181B). Each service is identified by a unique 128-bit or 16-bit UUID (16-bit UUIDs are predefined standard UUIDs by the Bluetooth Special Interest Group, such as 0x180D; 128-bit UUIDs are used for vendor-defined services) and contains one or more characteristics.
Characteristics: The Minimum Operational Unit of Data
Characteristics are the specific readable and writable data items within a service and are the smallest operational unit of GATT communication. They consist of three key parts:
-
Declaration: Defines the properties of the characteristic (e.g., whether it is readable, writable, or notifiable) and is identified by a fixed UUID (0x2803);
-
Value: The actual stored data content (e.g., current heart rate of 72 BPM);
-
Descriptor (optional): Supplementary information about the characteristic (e.g., measurement range, accuracy, etc.).
For example, in the heart rate service, the “Heart Rate Measurement” is a characteristic (UUID: 0x2A37) whose value directly stores the heart rate number; while the “Heart Rate Measurement Configuration” may be another characteristic (UUID: 0x2A38) used to set whether to enable heart rate alerts.
Descriptors: Metadata of Characteristics
Descriptors are additional information attached to characteristics, typically used to provide configuration or explanatory content. Common standard descriptors include:
-
Client Characteristic Configuration Descriptor (CCCD, UUID: 0x2902): Used to control the notification/indication functionality of characteristics (for example, when a user enables “real-time heart rate push,” the device will enable notifications via CCCD);
-
Format Descriptor (UUID: 0x2904): Describes the encoding format of the characteristic value (e.g., integer, floating-point, units, etc.).
These descriptors allow characteristics to not only carry data but also flexibly adapt to the needs of different scenarios.
Communication Mode: Role Division of Client and Server
GATT communication strictly follows the “Client-Server” model:
-
GATT Server: Typically the device providing data (e.g., sensors, smart wearables), responsible for storing the attribute table and responding to read/write requests from clients. For example, a heart rate monitor acts as a server, storing current heart rate values, historical data, and other characteristics;
-
GATT Client: Typically the active party initiating operations (e.g., mobile apps, control panels), which connects to the server to read or modify characteristic values. For example, a user’s smartphone acts as a client, sending requests to the heart rate monitor to obtain real-time heart rate data.
This role is not fixed— the same device may switch roles in different connections. For instance, a BLE-enabled smartwatch can act as a server to sync data to a smartphone (e.g., sending exercise records) and also as a client to control other devices (e.g., remotely controlling smart home devices).
Data Interaction Process: Typical Scenarios of Read, Write, and Notification
GATT supports various communication methods, the most common of which include:
1. Read Operation
The client directly requests the value of a specific characteristic from the server (by specifying the handle of the characteristic). For example, after connecting the heart rate monitor, the mobile app sends a request to “read the value of handle 0x002A,” and the server returns the current heart rate value (e.g., 72 BPM).
2. Write Operation
The client writes new data to the characteristic value of the server (the characteristic must support write permissions). For example, a user sets the alarm threshold for a temperature sensor through the app, writing a new value (e.g., 30°C) to the server’s “threshold characteristic.”
3. Notification and Indication
This is a core function in BLE low-power scenarios— the server actively pushes data updates to the client without requiring frequent polling from the client.
-
Notification: The server sends data unidirectionally (the client does not need to confirm successful receipt), suitable for scenarios requiring high real-time performance but strong fault tolerance (e.g., continuous heart rate monitoring);
-
Indication: The server waits for confirmation from the client after sending data (similar to reliable transmission in TCP), suitable for critical data (e.g., emergency alerts from medical devices).
For example, when a user enables the “real-time heart rate display” feature in the mobile app, the app first writes an instruction to enable notifications to the heart rate monitor’s CCCD (Client Characteristic Configuration Descriptor) (e.g., 0x0001), and then the heart rate monitor will automatically push the value each time a new heart rate is measured, updating the mobile interface in real-time.
Standard Services and Custom Extensions
The Bluetooth Special Interest Group (SIG) defines a series of standard services (e.g., Heart Rate Service 0x180D, Battery Service 0x180F, Device Information Service 0x180A), whose UUIDs and characteristic structures are public, ensuring seamless compatibility between devices from different manufacturers. For example, any device supporting the standard heart rate service will necessarily use UUID 0x2A37 for its “Heart Rate Measurement” characteristic, allowing mobile apps to read data without adaptation.
For special needs, manufacturers can also define custom services and characteristics using 128-bit UUIDs. For example, an agricultural sensor manufacturer may create a “Soil pH Value Service” (UUID: 0xABCD1234), which includes characteristics such as “pH Measurement” (UUID: 0xABCD5678) and “Calibration Parameters” (UUID: 0xABCD90EF) for the accompanying app to parse and use.
Conclusion: Why GATT is the “Soul” of BLE
GATT addresses the core issues of “how to describe data” and “how to transmit it efficiently” between BLE devices through a structured data model (services-characteristics-descriptors), standardized communication rules (client-server model), and flexible interaction methods (read/write/notification). It is not only the cornerstone of BLE functionality but also a key bridge for the interconnectivity of IoT devices—from health monitoring to smart homes, from industrial sensors to automotive accessories, GATT quietly defines the flow of data behind almost all BLE applications. Understanding GATT is to master the “universal language” of BLE development.