# 2. The Attribute Protocol (ATT)

## 2.1. The Bluetooth Low Energy Protocol Stack

Bluetooth Low Energy is a protocol that is built on a 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 on 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.

The figure below depicts the BLE Protocol stack:

Figure 1 Bluetooth Low Energy Protocol Stack

In this tutorial we will be mostly concerned with the protocols highlighted in light blue: the Attribute Protocol (ATT) and the Generic Attribute Profile (GATT). These protocols designate how data are represented in a server’s database and the respective actions that a client has to perform to access these data. We will cover some prerequisite theory of the ATT and GATT protocols and we’ll proceed to building our custom GATT profile using Dialog Semiconductor’s SDK 6.0.12.

## 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. These data are stored as attributes on the BLE server.

An attribute is a data representation format which is composed of four fields:

• The attribute type, defined by a UUID.

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

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

• The attribute value.

The attribute type specifies what this attribute represents. This is accomplished by the use of a Universally Unique Identifier (or UUID for short). A UUID is a 128-bit value which someone can assign to an attribute without registering it to a central authority. 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 handle is a non-zero value and is used to reference the attribute. All attributes of a BLE server are stored in its database by increasing attribute handle value. It’s not mandatory for a successive attribute to have the next integer handle value. Gaps are permitted between attribute handle values, but the handle values must be in increasing order.

Attribute permissions specify if the resource can be read and/or written, as well as the security level that is required for this. Different security combinations are allowed. For example, an attribute may require no permissions for reading, but the client may have to authenticate to be able to modify the resource.

Attribute values may either be of fixed length or of variable length. For variable length attribute values, only one attribute value is allowed to be sent in a PDU. If the value is too long, it may be split across multiple PDUs.

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 consequentially 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.

• Indications: Sent to a client by a server and they invoke a response. They are sent without the client requesting them.

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

Figure 2 ATT Protocol PDU

Above you can find the format of the ATT Protocol PDU. The attribute opcode field provides information about the method performed, as well as a flag that indicates if the PDU is a command, and a flag used when authentication is required. If no authentication is required, then the authentication signature field is left out.

If all goes well and the packet is received as expected, the protocol dictates the action that the other end has to take on success. In case of error, there is also provision for an error response which indicates what was the source of the error. These exchange flows are summarized in the table below. You can find more information about them in the Bluetooth Core Specification, Vol. 3, Part F, Section 3, Chapter 3.4.

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

Find By Type Value Request

Find By Type Value Response

Yes

Yes

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

Yes

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

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

Yes

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

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

N/A

No

Handle Value Indication

Handle Value Confirmation

No

## 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.