ATT

What Is ATT?

The Attribute Protocol (ATT) is the wire-level protocol beneath GATT that carries every read, write, GATT & ATT">notification, and indication between a BLE client and server. While GATT defines the semantic structure -- services, characteristics, descriptors -- ATT handles the byte-level mechanics of accessing individual attributes in the server's database.

Attribute Database

An ATT server maintains a flat table of attributes. Each attribute has four fields:

• Handle -- a 16-bit integer (0x0001 -- 0xFFFF) that uniquely addresses the attribute.
• Type -- a UUID indicating what kind of attribute it is (service declaration, characteristic value, descriptor, etc.).
• Value -- the raw byte payload, up to 512 bytes.
• Permissions -- access control flags governing whether the attribute can be read, written, or requires authentication.

Request-Response Model

ATT is a strict request-response protocol running over L2CAP channel 0x0004. The client sends a request (Read Request, Write Request, Find By Type Value Request), and the server replies with a corresponding response. Only one request can be outstanding at a time on a given bearer, which makes ATT inherently sequential. Bluetooth 5.2 introduced EATT to allow multiple parallel ATT bearers over L2CAP credit-based channels, removing this bottleneck.

PDU Types

ATT defines six categories of Protocol Data Units (PDUs): requests, responses, commands (write without response), notifications, indications, and confirmations. Commands and notifications are unacknowledged, making them faster but unreliable. Indications require a confirmation PDU, guaranteeing delivery at the cost of throughput.

MTU Negotiation

The default ATT_MTU is 23 bytes (yielding 20 bytes of usable payload after a 3-byte ATT header). After connection, the client can request a larger MTU via the Exchange MTU procedure. Combined with Data Length Extension, a single ATT PDU can carry up to 509 bytes of application data, which is essential for firmware updates or bulk sensor downloads.

Error Handling

When the server cannot fulfill a request, it replies with an Error Response containing the offending handle, the request opcode, and an error code (e.g., Insufficient Authentication, Attribute Not Found, Invalid Offset). Robust client implementations should handle these errors gracefully and retry after corrective action such as initiating pairing.