3. The Generic Attribute Profile (GATT)

3.1. Profiles

As we mentioned in the previous section, the Generic Attribute Profile (GATT) uses the ATT protocol to define a higher level of abstraction on how resources on a server can be accessed. More formally it is a service framework which defines procedures and formats of services and their characteristics. Typical device use cases are standardized into profiles. For instance, a common BLE profile is the Human Interface Device (HID) Profile, which is widely used by devices such as mice and keyboards.

Profiles enable interoperability between products from different vendors. The software has to provide a predefined set of capabilities and data access points to conform to the profile, and this guarantees that the device can operate with another one that supports the same profile. Moreover, every operation or data representation is described using the ATT Protocol attributes and methods, and this consistency allows part of the software to be reused and minimize memory footprint and development effort, while at the same time improving software maintenance.

GATT Profile structure

Figure 3 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 officialy 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 is a value used in a service along with properties and configuration information about how the value is accessed and information about how the value is displayed or represented. A characteristic is defined by its characteristic definition. A characteristic definition contains a characteristic declaration, characteristic properties, and a value and may contain descriptors that describe the value or permit configuration of the server with respect to the 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.

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 4 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 DA14531 or DA14585/DA14586 device and Dialog’s SDK 6.0.12.