GATT UUID & Descriptors (0x2902) Explained — BLE

GATT Deep Dive

The Generic Attribute Profile (GATT) is the application-layer framework that structures all data exchange in Bluetooth Low Energy. Every sensor reading, command, and configuration value sent over BLE travels through ATT">GATT's hierarchy of services, characteristics, and descriptors. Understanding GATT from the ground up lets you design robust, interoperable profiles and debug connectivity issues with confidence.

ATT Protocol Foundation

GATT is built directly on top of the Attribute Protocol (ATT). ATT defines a simple client-server model: the GATT Server (usually the peripheral) holds a database of attributes, and the GATT Client (usually the central) reads, writes, and subscribes to them.

Every attribute has four fields:

ATT supports seven operation types: Read, Write, Write Without Response, Notify, Indicate, Confirm, and Signed Write. Selecting the right operation is critical — Notification drops the packet if the client is slow, while Indication guarantees delivery via a confirmation handshake.

Service Structure

A GATT Service groups related attributes. The Bluetooth SIG assigns 16-bit UUIDs to standardized services (e.g., 0x180D for Heart Rate). Custom services use 128-bit UUIDs generated with the UUID Generator.

Each service contains one or more GATT Characteristics, which hold the actual data values. A characteristic declaration attribute (always the first handle in the group) exposes the properties flags: Read, Write, Notify, Indicate, etc. The value attribute immediately follows. Optional GATT Descriptors trail the value and add metadata.

Service (Heart Rate — 0x180D)
├── Characteristic: Heart Rate Measurement (0x2A37)
│   ├── Value (Notify)
│   └── Descriptor: CCCD (0x2902)
└── Characteristic: Body Sensor Location (0x2A38)
    └── Value (Read)

Use the GATT Browser to inspect live attribute tables on any BLE device without writing code.

Descriptors and CCCD

Descriptors provide supplementary information about a characteristic. The most important is the Client Characteristic Configuration Descriptor (CCCD, UUID 0x2902). Writing 0x0001 to the CCCD enables Notifications; writing 0x0002 enables Indications; 0x0000 disables both.

Without enabling the CCCD, the server silently drops outgoing notifications — a common debugging pitfall. Other standard descriptors include the Characteristic User Description (0x2901, human-readable name) and the Characteristic Presentation Format (0x2904, unit and format metadata).

EATT: Enhanced ATT

EATT (Enhanced ATT), introduced in Bluetooth 5.3, multiplexes multiple ATT bearers over L2CAP enhanced credit-based channels. Classic ATT permits only one transaction at a time; EATT allows up to 64 parallel bearers, dramatically improving throughput for data-intensive profiles like Health Device Profile (HDP).

EATT requires an encrypted connection to establish. Both peers must negotiate it via L2CAP credit-based channel establishment. Once active, each bearer independently handles Read/Write/Notify operations without blocking the others.

MTU Negotiation

The default MTU is 23 bytes, giving a payload of 20 bytes after the ATT opcode and handle overhead. Large-value transfers (firmware images, bulk sensor logs) benefit enormously from MTU exchange: a 512-byte MTU raises payload to 509 bytes, reducing packet overhead by 25×.

Always initiate MTU Exchange as part of connection setup. Log the negotiated value — if the central caps at 23 bytes, suspect an OS or SDK limitation rather than a radio issue.