3. The Generic Attribute Profile (GATT)

3.1. Profiles

In the Generic Attribute Profile (GATT), the Attribute Protocol (ATT) serves as the foundation for creating a higher level of abstraction. GATT essentially acts as a service framework, defining how resources on a server can be accessed. This involves outlining procedures and formats for services and their characteristics.

GATT simplifies device interaction by organizing typical use cases into standardized sets called profiles. For example, the Human Interface Device (HID) Profile is a common BLE profile used by devices like mice and keyboards.

Profiles foster interoperability across products from different vendors. To adhere to a profile, software must offer a predefined set of capabilities and data access points. This ensures that devices conforming to the same profile can seamlessly operate with one another.

Every operation or data representation is described using the ATT Protocol, maintaining consistency and allowing for the reuse of software components. This not only minimizes memory usage and development effort but also facilitates easier software maintenance.

In essence, GATT simplifies and standardizes the way devices communicate, fostering compatibility and efficiency in the development and maintenance of Bluetooth-enabled products.

GATT Profile structure

Figure 4 GATT Profile structure

3.2. Services

GATT defines a hierarchical model of a BLE server’s database. On top are the profiles, which dictate the use case that the device supports. Profiles contain services, which describe a particular function that the server supports. Services also provide a grouping mechanism, and by referencing them they can be included by other services. In this way two or more profiles can reuse the same service. Services are either mandatory or optional. Every device that conforms to a particular profile must implement all of the mandatory services.

Services are categorized in two types:
  • Primary services, which expose the main functionality of the device. Primary services can be discovered using the Primary Service Discovery procedure.

  • Secondary services, which are intended for auxiliary functionality.

Each service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID (UUID). For officially adopted BLE services the UUID has a length of 16 bits, whereas for custom services the length is 128 bits.

3.3. Characteristics

A characteristic refers to user or application data that is sent from one device to another over the network. A characteristic in a service includes a value, properties, and configuration information. It’s defined by a declaration, and descriptors may be present for additional details or server configuration related to that characteristic.

The attribute of a characteristic is set to the following parameters:
  • Attribute type is set to Characteristic (the double angle quotation marks indicate that this is a UUID defined by Bluetooth SIG).

  • Attribute value is composed of three bitfields: Characteristic Properties (1 octet), Characteristic Value Handle (2 octets), and Characteristic UUID (2 or 16 octets).The Characteristic Properties bitfield shows how the Characteristic Value can be used or how the its descriptors can be accessed. It can be Broadcast, Read, Write Without Response, Write, Notify, Indicate, Authenticated Signed Writes, or Extended Properties. The Characteristic Value Handle is the attribute handle that will be used to access the Characteristic Value.The Characteristic UUID is the UUID of the Characteristic Value.

  • The attribute permissions must be readable and not require authentication or authorization.

Right after the Characteristic Declaration comes the Characteristic Value Declaration. For this attribute, we set its fields to:
  • Attribute type is the same UUID as the one in the Characteristic Declaration.

  • Attribute value is the Characteristic Value.

  • Attribute permissions are implementation specific.

Below you can see an example to have a better view of how a characteristic can be exist in a service:

example Characteristics in an example service

Figure 5 example Characteristics in an example service

The Characteristic descriptors are optional and are used to provide additional information on the characteristic. More information can be found in the Bluetooth Core Specification, Vol. 3, Part G, Section 3, Chapter 3.3.

3.4. Putting it all together

GATT server example

Figure 6 Profiles, services, and characteristics

Building on our fitness tracker analogy, let’s suppose we want to design our server’s GATT database for this product. A suitable choice would be to implement the Heart Rate Profile, as our device would measure an athlete’s heart rate and send it to a smartphone for presentation or storage. The Heart Rate Profile defines two roles, a Collector and a Sensor, and since the fitness tracker contains the sensing element we would pick the second role. As we can see in the profile (you can find the specification document here)

there are two mandatory services, the Heart Rate Service and the Device Information Service (DIS), and these two services must be available to conform to the profile. The Heart Rate Service provides four characteristics, two of which are mandatory: the Heart Rate Measurement and the Heart Rate Measurement Characteristic Configuration Descriptor. The first characteristic would be used as an access point for the heart rate.

We could set the permissions to Read and expect the user to be authenticated in order to have access to the measurement. Following the above logic, you can see how GATT abstracts away a lot of implementation details so that the developer can focus their work in application specific tasks. In the following part we will see how we can build our custom BLE Service using a DA1453x or DA1458x device and Renesas’s SDK6.