2. The Attribute Protocol (ATT)

2.1. The Bluetooth Low Energy Protocol Stack

Bluetooth BR (Basic Rate), Bluetooth EDR (Enhanced Data Rate), and Bluetooth LE (Low Energy) follow a modular structure where the controller and host layers are commonly implemented as separate components. Atop the host layer, you find the user application and operating system. To have a better understanding of the different layers, you can refer to protocol stack. The figure below depicts the BLE Protocol stack:

Bluetooth low energy protocol stack

Figure 1 Bluetooth Low Energy Protocol Stack

In Bluetooth, the main idea is to share data between devices. Think of services as the way data is shared, and when you group these services, it becomes a profile. The Generic Attribute Profile (GATT) handles these services and profiles. At the core of this setup, the Attribute Protocol (ATT) layer lets a device show its “attributes” to others. In simple terms, when two devices connect through BLE, all their data talks go through GATT.

Bluetooth Low Energy is a protocol that is built on a client/server architecture:

GATT server example

Figure 2 client/server architecture

Let’s suppose that we have connected our smartphone to a fit tracker device. The device periodically measures our heart rate and needs to pass these measurements to our smartphone. In this example, our smartphone acts as the client who wants to access this information, and the fit tracker as the server who acquires the measurements and waits to deliver them to the appropriate end.

In networking terminology, the server holds resources, like a heart rate measurement or the battery level. A client requests these resources from the server, using some predefined operations called services, and, if the request is supported, it responds with a specified format.

In this tutorial we will be mostly concerned with the protocols highlighted in LightBlue.Before diving into the practical aspects of creating a custom GATT profile using Renesas’s SDK6, we’ll explore the essential concepts behind ATT and GATT. This foundational understanding will set the stage for our hands-on exploration.

2.2. The Attribute Protocol (ATT)

2.2.1. Attributes

As we discussed in the previous section, the server holds resources to which a client needs to have access. An attribute, generally refers to a characteristic or descriptor (a piece of information or a feature associated with a device). Attributes are used to represent data and metadata in the GATT (Generic Attribute Profile) of the Bluetooth protocol stack.

An attribute is composed of four fields:
  • The attribute’s type, defined by a UUID.

  • The attribute’s handle, which is an unsigned number unique for the attribute.

  • The attribute’s permissions, which control if the client can read or modify a resource.

  • The attribute’s value (data).

Attribute’s type play a crucial role in defining the nature of data within a system. Each attribute is identified by a Universally Unique Identifier (UUID), a 128-bit value. What makes UUIDs powerful is that they can be assigned without the need for central registration.To streamline data transfer and minimize the payload, these UUIDs often have a length of 16 or 32 bits. The actual UUID is derived through a straightforward arithmetic operation involving the Bluetooth Base UUID. This process ensures a unique identifier for attributes without the complexity of central authority registration.

Why unique?

The probability that two different parties will assign the same UUID is extremely low (it’s 1/2128), and for this reason a UUID is considered unique.

Since a lot of the functionality that these devices provide is common, a range of UUID values has been reserved for predefined values, each of which exposes a set of action and data for common use cases. To aim in reducing the amount of data transferred, these values have a length of 16-bit or 32-bit and the actual UUID is computed by the use of the Bluetooth Base UUID and a simple arithmetic operation.

\[\textrm{UUID} = \textrm{16_or_32_bit_value} \cdot 2^{96} + \textrm{Bluetooth_Base_UUID}\]

The attribute’s handle in BLE is a non-zero value used to identify attributes. Attributes in a BLE server are stored in increasing order of handle values. While successive attributes don’t need to have the next integer handle, gaps are allowed, as long as handle values are in ascending order.

Attribute’s permissions define the level of access control for a resource. These permissions specify whether the resource can be read and/or written, as well as the required security level. Various security combinations are allowed, offering flexibility in access control. For instance, an attribute might allow reading without any permissions, but modification could require client authentication, enhancing security for specific operations on the resource.

Attribute’s values in BLE can be either of fixed length or variable length. For variable length attribute values, only one value is allowed to be sent in a Protocol Data Unit (PDU). If the value is too long, it may be split across multiple PDUs for transmission.

Control Point Attributes

There is a special type of attribute that is not allowed to be read, but could be written, notified, or indicated (we will discuss later the last two operations). These are called Control Point Attributes, as they are mainly used for application control rather than passing data between the devices.

2.2.2. Attribute methods

The ATT protocol also defines methods by which attributes can be read or written. The methods supported are six and consequently they define six Protocol Data Units (PDU). A PDU, as regards the ATT protocol, is the packet that will be forwarded to (or received from) the lower layer, namely the Logical Link Control and Adaptation Protocol (L2CAP) layer, and will then be encapsulated to be sent over the physical link (or respectively be sent to the upper layers).

These six methods and their PDU types are:
  • Commands: Sent to a server by a client and do not invoke a response

  • Requests: Sent to a server by a client and invoke a response

  • Responses: Sent to a client by a server when a request is received.

  • Notifications: Sent to a client by a server without invoking a response. They are sent without the client requesting them (User only need to subscribe).

  • Indications: Sent to a client by a server and they invoke a response. They are sent without the client requesting them (User only need to subscribe).

  • Confirmations: Sent to a server by a client as an acknowledgment to an indication.

ATT Protocol PDU

Figure 3 ATT Protocol PDU

The Attribute Protocol Data Unit (PDU) format contains an “attribute opcode” field that carries information about the operation, along with flags indicating whether it’s a command and whether authentication is needed. If no authentication is required, the authentication signature field is omitted.

When everything goes smoothly, the protocol guides the expected actions on the other end. In case of an error, an error response is sent, detailing the source of the issue. You can refer to the Bluetooth Core Specification, Vol. 3, Part F, Section 3, Chapter 3.4 for more details.

Table 1 Advertising Packets

Attribute PDU Method

Successful Response

Error Response Allowed

Error Response Error Codes

Exchange MTU Request

Exchange MTU Response

Yes

Request Not Supported

Find Information Request

Find Information Response

Yes

Invalid Handle, Attribute Not Found

Find By Type Value Request

Find By Type Value Response

Yes

Invalid Handle, Request Not Supported, Attribute Not Found

Read By Type Request

Read By Type Response

Yes

Invalid Handle, Request Not Supported, Attribute Not Found, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Read Not Permitted, Application Error

Read Request

Read Response

Yes

Invalid Handle, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Read Not Permitted, Application Error

Read Blob Request

Read Blob Response

Yes

Invalid Handle, Request Not Supported, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Read Not Permitted, Invalid Offset, Attribute Not Long, Application Error

Read Multiple Request

Read Multiple Response

Yes

Invalid Handle, Request Not Supported, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Read Not Permitted, Application Error

Read by Group Type Request

Read By Group Type Response

Yes

Invalid Handle, Request Not Supported, Attribute Not Found, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Read Not Permitted, Unsupported Group Type, Application Error

Write Request

Write Response

Yes

Invalid Handle, Request Not Supported, Insufficient Authorization, Insufficient Authentication, Insufficient Encryption, Insufficient Encryption Key Size, Write Not Permitted, Invalid Attribute Value Length, Application Error

Write Command

N/A

No

Signed Write Command

N/A

No

Prepare Write Request

Prepare Write Response

Yes

Invalid Handle, Request Not Supported, Insufficient Authorization, Insufficient Authentication, Write Not Permitted, Prepare Queue Full, Insufficient Encryption, Insufficient Encryption Key Size, Application Error

Execute Write Request

Execute Write Response

Yes

Application Error, Invalid Offset, Invalid Attribute Value Length

Handle Value Notification

N/A

No

Handle Value Indication

Handle Value Confirmation

No

Difference between Notifications and Indications

Confirmation Requirement:

Notification: It is a one-way communication from the server (the device providing data) to the client (the device receiving data). No explicit confirmation is required from the client upon receiving a notification.

Indication: It is a two-way communication. After sending an indication, the server expects a confirmation (ACK) from the client to ensure that the data was received successfully.

Flow Control:

Notification: Multiple notifications can be sent by the server without waiting for acknowledgment from the client. This allows for faster transmission but lacks confirmation of successful reception.

Indication: The server must wait for acknowledgment from the client before sending another indication. This ensures a more reliable and ordered data exchange.

Use Cases:

Notification: Used when real-time updates are required, and occasional data loss is acceptable (e.g., sensor data updates).

Indication: Used when reliable delivery is crucial, and the server needs confirmation of the client’s receipt (e.g., critical configuration changes).

2.3. In a nutshell

What is important to remember is that the ATT protocol is concerned with the representation of data (attributes) in a BLE server database and defines the transaction activities on them, either when they are delivered successfully or not. This provides a basis for packet fragmentation and encapsulation for the lower stack protocols, and in the same time the building blocks that will be used by the GATT protocol to define a higher level of abstraction for data access.