ATT and GATT—How Bluetooth LE Devices Store Data

My mom recently celebrated her 50th birthday, and she's all about staying healthy. So, I gifted her a boAt fitness tracker (Figure 1). This sleek, sophisticated watch doesn't just look great on her wrist. It tracks steps, monitors heart rate, measures blood pressure, and collects sleep patterns. The watch's high-performance sensors gather data around the clock and send it to her smartphone via Bluetooth LE.

This fitness tracker of my mom’s is just one example of the many Bluetooth LE devices that collect and store data. But, have you ever wondered how these Bluetooth LE devices store and manage all the data they collect? How about interoperability?

 

Figure 1. Features of one of boAt’s fitness tracker wearables. Image used courtesy of boAt

 

Have you ever considered how the data stored in a boAt brand fitness tracker can be transferred and shared with a Samsung phone? This is precisely where the ATT (Attribute Protocol) and GATT (Generic Attribute Profile) protocols come into play.

 

The Foundation: Attribute Protocol (ATT)

ATT serves as the foundation for data management and organization in BLE devices. It is responsible for defining how data is structured, stored, and accessed, forming the basic framework for data representation in Bluetooth LE communication.

The ATT protocol defines standard messages, message sequences, and procedures needed to execute GATT operations. 

In ATT, data is organized into attributes, the smallest units of information. Each attribute has a unique identifier (UUID), a value, and a set of properties, such as read, write, or notify. The UUID is either 16-bit or 128-bit and helps devices recognize specific attributes. For example, imagine a BLE-enabled smartwatch that measures your heart rate. The heart rate data is an attribute, identified by a specific UUID, and has properties such as read and notify.

Now, let's discuss how ATT operates. It uses a client-server model, where one device (the server) holds the data, and another device (the client) requests or updates this data. This model allows for efficient communication and supports multiple clients connecting to a single server simultaneously. In our smartwatch example, the smartwatch acts as the server, holding the heart rate data, while your smartphone acts as the client, requesting the data and displaying it on an app.

 

Building Upon ATT: Generic Attribute Profile (GATT)

While ATT provides the foundation for data organization, GATT builds on top of it by defining how devices should interact with the data stored as attributes. GATT establishes a set of rules and operations or procedures that dictate how clients and servers communicate, ensuring consistent data exchange and interoperability between devices.

First, let’s break down the GATT name. The “profile”  refers to a set of rules and procedures that define how devices will interact with each other. These rules provide clear instructions on the roles and responsibilities of each device during connection-oriented communication.

The term "generic" highlights the comprehensive nature of GATT, which covers all attributes involved in the communication between devices. This means that GATT is not limited to specific use cases or applications but can be applied across all scenarios. GATT organizes attributes into a hierarchical structure of profiles, services, and characteristics.

 

Description of the GATT Hierarchy

Why use a hierarchical structure to organize data? Organizing data in a hierarchy, such as the file-folder system, is often used for the following reasons:

• Intuitive Organization: Hierarchical structures are intuitive and easy to understand, as they closely resemble real-world systems, like organizational charts or family trees. This makes it easier for developers and users to navigate and locate specific information.
• Logical Grouping: Hierarchical organization groups related data elements together, allowing users to quickly identify relationships between different items. This logical grouping improves the overall organization and coherence of the data. It also enables more efficient discovery and interaction with the data, as devices can quickly navigate through the hierarchy to find the desired services and characteristics.
• Better Maintainability: A well-organized hierarchy simplifies data management and maintenance. It is easier to update or modify specific elements within the hierarchy without causing unintended side effects or impacting unrelated data.
   

Enhanced Security and Access Control: Organizing data in a hierarchy allows for more granular access control and permissions. By assigning different access levels to services, and characteristics, it becomes easier to manage data access and ensure that only authorized devices can interact with specific data elements.

Figure 2 shows the components of GATT’s Hierarchical structure.

 

Figure 2. Components of GATT’s Hierarchical structure

 

Now let's examine each of the components.

 

Profile

A profile is a document or specification that provides a high-level definition of how a GATT client and server should interact to support a specific use case or application in the Bluetooth LE ecosystem. It lists the services that work together to fulfill the requirements of that use case. Profile specifications ensure standardized behavior and interoperability between devices supporting the same application, even if they are from different vendors.

 

Service

A service is a collection of related attributes (characteristics and descriptors) that serve a particular functionality within a profile. Services encapsulate a specific aspect of the device's behavior, making it easier for other devices to discover and interact with related data.

When a client discovers its peer's services, it learns about the data the device offers, how to access that data, and the security measures used to protect it.

There are two types of services in a GATT profile: primary services and secondary services. Primary services are the main services offered by a GATT Server. They are discoverable by a GATT Client and define the primary functionality of a device, such as a heart rate monitor having a heart rate service and a battery level service.

Secondary services, on the other hand, provide additional or supplementary functionality to primary services. They are not directly discoverable by a GATT Client but are referenced by primary services or other secondary services. 

Secondary services are used to logically group related characteristics or extend the functionality of primary services, such as a cycling sensor primary service referencing a secondary service with additional characteristics like cadence or power measurements.

 

Characteristic

A characteristic is an attribute within a service that represents a particular data value or piece of information. It has a unique UUID, a value, and a set of properties (for example, read, write, or notify) that define how it can be accessed or modified and a declaration describing the properties of the characteristic.

 

Descriptor

A descriptor is an optional attribute associated with a characteristic that provides additional information or configuration options. Descriptors can be used to specify metadata, such as a human-readable description or presentation format, or to configure how the characteristic behaves (for example, enabling notifications).

 

Example of a Health Thermometer Profile

Now let’s look at a profile of an example heath thermometer device.

 

Figure 3. Relationship between profile, services, and characteristics in a health thermometer profile. Image used courtesy of Silabs AN983. (Click image to enlarge)

 

Specified below are the profile and services of this health thermometer device example. See also Figure 3 above.

• Profile: Health Thermometer profile

  • This profile is designed for devices that measure and transmit temperature measurements.

• Services:

  • GAP Service: The GAP service is responsible for device discovery, connection establishment, and security.

  • Primary Service: Health Thermometer Service (UUID: 0x1809) : This service is the main service of the Health Thermometer GATT profile and contains the following characteristics:

    • Temperature Measurement (UUID: 0x2A1C) This characteristic represents the measured temperature value along with additional information, such as timestamp and temperature type. It has a declaration, a value, and a Client Characteristic Configuration Descriptor (CCCD) for enabling notifications.

    • Temperature Type (UUID: 0x2A1D) This read-only characteristic indicates the location on the body where the temperature was measured, such as oral, ear, or armpit.

    • Intermediate Temperature (UUID: 0x2A1E) This characteristic represents an intermediate temperature value and has a value and a CCCD for enabling notifications.

  • Primary Service: Device Information Service (UUID: 0x180A) : This service provides information about the health thermometer device, such as the manufacturer name, model number, and hardware revision. It contains several characteristics, like Manufacturer Name String (UUID: 0x2A29), Model Number String (UUID: 0x2A24), and Hardware Revision String (UUID: 0x2A27).

As you can see, the GATT hierarchy organizes data in a structured and logical manner, making it easier for devices to discover and interact with each other's data. 

 

GATT Roles and Procedures 

To further understand how GATT works, let's explore the different roles (Figure 4) and procedures involved in data exchange.

 

Figure 4. GATT roles

 

GATT builds on the client-server roles defined by the ATT protocol: 

• GATT Server: The device that holds the data as a table in its memory (for example, the smartwatch).

• GATT Client: The device that requests or updates data (for example, the smartphone).

The attributes are stored in an attribute database or table in the server’s memory. Each attribute is given an address called a handle as shown in Figure 5 below.

 

Figure 5. Example of data stored in the server’s attribute database. Image used courtesy of Microchip Technology. (Click image to enlarge) 

 

Differentiating between GAP Roles and GATT Roles 

GAP roles (Peripheral and Central) relate to device discovery, connection establishment, and security. On the other hand, GATT roles (Client and Server) deal with data organization and communication between connected devices.

It's important to note that a single device can take on multiple roles depending on the specific use case. Normally, a GAP Peripheral device (which advertises and accepts connections) may act as a GATT Server, providing data to connected devices. 

Conversely, a GAP Central device (which initiates connections) can serve as a GATT Client, requesting and receiving data from a GATT Server. For instance, a GAP Central device like a smartphone typically acts as a GATT Client, requesting data from connected devices. 

However, during a firmware update, the smartphone may act as a GATT Server, providing the update data to a GAP Peripheral device, such as a smartwatch, which serves as a GATT Client in this scenario. This example demonstrates how GATT roles and GAP roles are independent of each other as they serve different purposes.

 

GATT Client and Server Procedures

The following are a set of predefined operations used by the GATT Client to interact with the GATT Server.

• Service Discovery: Initially, the peer devices do not know the services of each other so the client must first discover the available services on the server's attribute database. Essentially, the client asks the server, "Hey, what services do you support?" The server then checks its database and responds, "I support services A and B." This process is known as service discovery.

• Characteristic Discovery: After discovering the available services, the client proceeds to explore the characteristics of each service. This process allows the client to identify the specific data elements associated with each service, along with their properties and handles.

Following service and characteristic discovery, data transfer can occur. There are four types of GATT data transfer operations (Figure 6). They are categorized based on whether they are client-initiated or server-initiated. Client-initiated operations involve the client communicating with the server, while server-initiated operations occur when the server initiates communication with the client as needed.

Figure 6. Four GATT data transfer operations

 

Here are the details of the four data transfer operations:

• Read Characteristic Value: Once the client knows the available characteristics, it can request to read the value of a specific characteristic from the server. The server will then provide the requested data if the client has the necessary permissions. The read operation allows the client to get data from the server.

• Write Characteristic Value: Similarly, the client can request to write a new value to a specific characteristic on the server. The write operation allows the client to push data to the server. The server will update the characteristic's value if the client has the appropriate permissions and the characteristic supports writing.

• Notifications and Indications: The client can also configure the server to send notifications or indications when a characteristic's value changes. Both notifications and indications allow the client to push data to the client. They both enable the client to receive real-time updates from the server without having to repeatedly request the latest data. Notifications are sent without confirmation from the client, while indications require acknowledgment from the client. Thus, indications increase reliability at the cost of speed and battery life. 

 

Frequently Asked Questions About ATT and GATT

 

1. How does the GATT profile enable interoperability?

The GATT profile enables interoperability between devices from different manufacturers by providing a standardized framework for organizing and exchanging data. When devices support the same GATT profile, they can exchange data easily with each other, no matter who made them.

 

2. GATT uses the ATT protocol as the transport layer. What does this mean?

When GATT uses the ATT protocol as the transport layer, it means that GATT relies on ATT for transferring data between devices. 

The ATT protocol defines standard messages, message sequences, and procedures needed to execute GATT operations. For example, during the initial connection, devices don't know what the other supports. To perform service discovery, the client sends an ATT Find Information Request message to the GATT server, which responds with the appropriate ATT message.

Similarly, during a GATT read operation, the client sends an ATT Read Request message containing the handle (or address) from the server's attribute table. The server then responds with either an ATT Read Response or ATT Error Response. To carry out these GATT operations, ATT messages or PDUs are exchanged, with the ATT protocol defining the format and sequence of the PDUs in GATT transactions. As you can see, the ATT protocol handles the exchange of messages and PDUs that facilitate GATT operations, which is why it's often said that GATT uses ATT as its transport layer.
 

3. How can the GATT client get notifications or indications from the GATT server?

To receive notifications and indications, the client must explicitly subscribe to them. This is because, although notifications and indications allow the server to push data when it's ready, the client may only want data upon request. As a result, clients need to subscribe to notifications and indications before receiving them.

To subscribe, the client must first discover the associated Client Characteristic Configuration Descriptor (CCCD) for the desired characteristic. The CCCD is a standard descriptor that controls notifications and indications. By writing the appropriate value to the CCCD, the client can enable notifications or indications. Writing 0x0001 to the CCCD enables notifications while writing 0x0002 enables indications.