Indication
A server-initiated update that requires client acknowledgment, providing reliable delivery at the cost of lower throughput.
What Is a BLE Indication?
An ATT">GATT & ATT">Indication is a server-initiated GATT operation that pushes a characteristic value update to a connected client and waits for an explicit acknowledgment before proceeding. Unlike notifications, indications guarantee that the client has received the data, making them suitable for critical or stateful exchanges.
How Indications Work
The indication flow mirrors notifications with one additional step. The client first enables indications by writing 0x0002 to the CCCD. When the server sends a Handle Value Indication PDU, the client must respond with a Handle Value Confirmation. The server blocks further indications on that ATT bearer until the confirmation arrives or a 30-second timeout expires, at which point the server typically disconnects.
When to Use Indications
Indications are the right choice when data loss is unacceptable and the update rate is low. Common use cases include:
- Firmware update progress -- losing a progress report could cause the host app to stall.
- Configuration acknowledgments -- confirming that a written setting has been applied.
- Alert and alarm state changes -- ensuring the client is aware of safety-critical events.
- Authentication challenge-response -- exchanging tokens where every step must succeed.
For high-frequency data (sensor readings above 1 Hz), indications are generally too slow because the round-trip confirmation limits throughput to roughly one indication per connection event.
Throughput Comparison
With a 15 ms connection interval, a single indication can be sent and confirmed per event, yielding a maximum of about 66 indications per second. By contrast, notifications can pack multiple PDUs per event, achieving 10 -- 50 times higher throughput. This stark difference is why sensor-streaming applications overwhelmingly use notifications with application-layer sequence numbers for gap detection, reserving indications for occasional control-plane messages.
Implementation Patterns
A robust indication sender should implement a simple state machine: IDLE, PENDING (indication sent, awaiting confirmation), and TIMEOUT (confirmation not received). If the confirmation times out, the server should disconnect because the ATT specification states that no further ATT traffic is permitted after a timeout. Client-side, the BLE stack usually handles the confirmation automatically, but application code must still process the incoming indication payload promptly to avoid delaying the confirmation and causing unnecessary back-pressure.
Mixing Notifications and Indications
A single GATT server can use both mechanisms on different characteristics simultaneously. A heart-rate characteristic might use notifications while a control-point characteristic on the same service uses indications. The two mechanisms operate independently, so notification throughput is unaffected by a pending indication on another characteristic, provided they are on separate ATT bearers or the stack handles interleaving correctly.
Related Terms
Related Content
BLE GATT Server Implementation Guide
Development…must write to the CCCD (UUID 0x2902) to enable them. Indication requires client acknowledgment and retransmits on failure…
Web Bluetooth API: BLE from the Browser
DevelopmentPython BLE with Bleak: Cross-Platform BLE Scripting
Developmentflutter_blue_plus: Read, Write & Notify in Flutter
DevelopmentGATT UUID & Descriptors (0x2902) Explained — BLE
Protocols & Profiles…Notification drops the packet if the client is slow, while Indication guarantees delivery via a confirmation handshake. Service…
Frequently Asked Questions
Our glossary covers 90+ BLE technical terms organized by category. Each term includes a definition, related terms, and links to relevant chips and guides.