Notification

What Is a BLE Notification?

A ATT">GATT & ATT">Notification is a server-initiated GATT operation that pushes a characteristic value update to a connected client without requiring an acknowledgment. Notifications are the primary mechanism for real-time data streaming in BLE -- heart rate monitors, environmental sensors, and motion trackers all rely on them to deliver data efficiently.

How Notifications Work

The notification flow begins when the client writes 0x0001 to the CCCD of the target characteristic. From that point, whenever the server updates the characteristic's value, it sends a Handle Value Notification PDU to the client. The PDU contains the characteristic's ATT handle and the new value bytes. Because no acknowledgment is returned, the server can immediately queue the next notification without waiting.

Notification vs. Indication

The key difference between notifications and indications is reliability. Notifications are fire-and-forget: if the PDU is lost due to interference or buffer overflow, the data is gone. Indications require the client to send a Handle Value Confirmation before the server can send another, guaranteeing delivery but halving throughput at best. For periodic sensor data where occasional loss is acceptable (heart rate, accelerometer), notifications are the standard choice. For critical state changes (firmware update progress, alarm acknowledgments), indications provide the necessary reliability.

Throughput Considerations

Notification throughput depends on several interrelated parameters:

• Connection interval -- shorter intervals allow more events per second.
• MTU -- a larger MTU means more payload per notification PDU.
• DLE -- Data Length Extension allows larger link-layer packets, reducing per-packet overhead.
• PHY -- LE 2M PHY doubles the air-interface bit rate.

Under optimal conditions (7.5 ms connection interval, 251-byte DLE, LE 2M PHY), BLE can sustain over 1.4 Mbps of notification throughput, though real-world numbers are typically 200 -- 800 kbps depending on the stack and radio environment.

Multiple Notifications per Connection Event

Modern BLE stacks can queue multiple notification PDUs within a single connection event. The number of PDUs that fit depends on the connection interval duration and the packet size. Firmware should batch data efficiently -- for example, packing 20 sensor samples into a single 200-byte notification rather than sending 20 individual 10-byte notifications -- to maximize throughput and minimize radio on-time.

Error Scenarios

Since notifications lack acknowledgment, the client has no mechanism to detect missed updates. Applications that require gap detection should include a sequence number or timestamp in the notification payload. The server should also monitor its notification queue: if the BLE stack's internal buffer fills up, subsequent calls to send a notification will return an error, and the firmware must decide whether to drop or retry.