What is…a GATT Service?

Time for another in our What Is…? series.

Not specifically part of Android, maybe, but definitely now relevant to Android.

In a nutshell, the Generic Attribute Profile is a core definition of Bluetooth functionality that is built upon by other specific profiles and services, and these enable devices to co-operate predictably in particular environments. For example, the “Current Time Service” (CTS) defines how the current time should be used.

Crucially, there is native support for Bluetooth Smart and Smart Ready not only in Android but also Apple iOS and OS X, Blackberry 10, and Microsoft Windows 8. In theory this means developers can concentrate on their application’s use of Bluetooth comms, and common driver support can be assumed for a variety of platforms.

As often is the case, the following relies on heavily on Wikipedia but even more heavily on the Bluetooth.org Developer Portal.

Bluetooth Smart

So, first things first, what exactly is Bluetooth Smart? It is the radio communications protocol once known as Bluetooth Low-Energy, and once known as Wibree, before that…

According to the Bluetooth SIG:

Bluetooth Smart devices are designed to gather a specific piece of information – are all the windows on my house locked, what is my blood glucose level, how much do I weigh today? – and send it to a Bluetooth Smart Ready device.

Examples include heart-rate monitors, blood-glucose meters, smart watches, window and door security sensors, key fobs for your car, and blood-pressure cuffs – the opportunities are endless.

From an official Bluetooth viewpoint (I am quoting from an FAQ of the Bluetooth SIG):

Bluetooth Smart Ready devices are built to Bluetooth v4.0 specifications with Generic Attribute Profile (GATT) based architecture.

From Wibree roots

Back at the beginning of this century, Wibree was intended to address power-constrained scenarios not catered for by current wireless technologies, for example in healthcare and security areas. With its inclusion in the Bluetooth specification it was rebranded as Bluetooth low energy technology, but as of 2011 it was re-branded to became Bluetooth SMART…

It is a radio technology for small, button cell battery-powered devices, such as watches, wireless keyboards, and gaming and sports sensors. These objects can then connect to Bluetooth-enabled host devices, whether computers or mobile phones.

Developed by Nokia from 2001, and released publicly in 2006, it was intended to drive growth in the mobile device market.

Now, Bluetooth Smart uses a 2.4 GHz frequency, it supports a bit rate of 1 Mbit/sec, and a range of 50m (160ft). Security? The spec is for “128-bit AES with Counter Mode CBC-MAC” with the application layer user defined. The network topology it uses is the Star-bus (“two or more star topologies connected using a bus trunk (the bus trunk serves as the network’s backbone)”), but support for mesh networks that propagate messages from node to node is coming.

There are three essential phases to a Bluetooth application:

1. scanning & connecting,
2. establishing which services and characteristics are available, and then
3. reading or writing values.

In terms of power, consumption will probably range between 0.01 to 0.5 with classic Bluetooth a reference of 1, and with peak current consumption defined as <15 mA. However, note that power consumption is not part of the Bluetooth specification.

How does it compare with Zigbee, another close range wireless system? Arguably the low-power variant of Bluetooth and ZigBee were complementary technologies – ZigBee technology being a low-power networking technology supporting thousands of nodes, while Bluetooth Smart links a small number of nodes to devices such as computers and mobile phones.

The full definition of GATT is to be found in Volume 3, Part G of the Bluetooth 4.0 Core Specification, states Wikipedia.

Bluetooth Profiles

“A profile has services, which have characteristics“, Vincent Gao of the Bluetooth SIG, speaking at a recent Bluetooth SIG Innovation Training day. 

Bluetooth has a concept of profiles, and there are specific profiles for Low Energy devices detailing how a device should work in a particular application. Manufacturers are expected to implement the appropriate specification(s) for their device in order to ensure compatibility. Bluetooth 4.0 provides low power conception with higher baud rate.

The GATT profile is a way of specifying the transmission – sending and receiving – of short pieces of data known as ‘attributes’ over a Bluetooth smart link. All current Low Energy application profiles are based on GATT, states Wikipedia.

Attribute protocol

One of the many Bluetooth sub-protocols is SDP – service discovery protocol. This allows devices to discover what services another device supports (with details of how to best connect). It seems the first stage in comms, after having negotiated a connection, is to find out what profiles (i.e. functionality) a device supports – you can talk Bluetooth, but do you support hands-free use? For example, according to Wikipedia:

When connecting a mobile phone to a Bluetooth headset, SDP will be used to determine which Bluetooth profiles are supported by the headset (headset profile, hands free profile, advanced audio distribution profile, etc.) and the protocol multiplexer settings needed to connect to each of them. Each service is identified by a Universally Unique Identifier (UUID), with official services (Bluetooth profiles) assigned a short form UUID (16 bits rather than the full 128).

The GATT Attribute Protocol (ATT) behaves in a similar way, but specially adapted for Low Energy Bluetooth, i.e. to operate in a low-power friendly manner.

Bluetooth has the concept of master and slave relationships at the link layer, central and peripheral relationships at the GAP level and client and server relationships at GATT level, all of which can be independent of each other. Via a .db file, a GATT server maintains a database of services and characteristics, which can be queried.

Bluetooth Developer Portal

The Bluetooth Developer Portal details GATT Specifications and Profiles.

(1) GATT Specifications

Bluetooth profiles and services are based on the Generic Attribute Profile (GATT). According to Bluetooth.org:

The profile describes a use case, roles and general behaviors based on the GATT functionality. Services are collections of characteristics and relationships to other services that encapsulate the behavior of part of a device. This also includes hierarchy of services, characteristics and attributes used in the attribute server. By following the guidance provided by the Bluetooth specification, developers can create applications to work with other Bluetooth devices.

(2) Profiles

What profiles and services are defined by the Bluetooth SIG, building on GATT?

Currently they range from an Alert Notification Profile (ANP) to a Tx Power Service (TPS). For example, the Proximity Profile (PXP) allows one device to detect whether another is within close range and, depending on an application, an alarm may be sounded at a particular threshold…

The full list of GATT-based profiles and services (there are also BR/EDR profiles):

• Alert Notification Profile ANP (The Alert Notification Profile (ANP) enables a client device to receive different types of alerts and event information, as well as information on the count of new alerts and unread items, which exist in the server device.)
• Alert Notification Service ANS (The Alert Notification Service (ANS) exposes different types of alerts.)
• Battery Service BAS (Battery Service exposes the state of a battery within a device.)
• Blood Pressure Profile BLP (Blood Pressure Profile enables a device to connect and interact with a Blood Pressure Sensor device for use in consumer and professional health care applications.)
• Blood Pressure Service BLS (Exposes blood pressure and other data from a blood pressure monitor for use in consumer and professional healthcare applications.)
• Current Time Service CTS (The Current Time Service (CTS) defines how the current time can be exposed using the Generic Attribute Profile (GATT).)
• Device Information Service DIS (The Device Information Service (DIS) exposes manufacturer information about a device.)
• Find Me Profile FMP (The Find Me profile (FMP) defines the behavior when a button is pressed on one device to cause an alerting signal on a peer device.)
• Health Thermometer Profile HTP (The Health Thermometer Profile (HTP) enables a Collector device to connect and interact with a Thermometer sensor for use in healthcare applications.)
• Health Thermometer Service HTS (The Health Thermometer Service (HTS) exposes temperature and other data from a Thermometer intended for healthcare and fitness applications.)
• Heart Rate Profile HRP (The Heart Rate Profile (HRP) enables a Collector device to connect and interact with a Heart Rate Sensor for use in fitness applications.)
• Heart Rate Service HRS (he Heart Rate Service (HRS) exposes heart rate and other data from a Heart Rate Sensor intended for fitness applications.)
• HID Over GATT Profile HOGP (HOGP defines how a device with Bluetooth low energy wireless communications can support HID services over the Bluetooth low energy protocol stack using the Generic Attribute Profile).
• Immediate Alert Service IAS (The Immediate Alert Service (IAS) exposes a control point to allow a peer device to cause the device to immediately alert.)
• Link Loss Service LLS (The Link Loss Service (LLS) defines behavior when a link is lost between two devices.)
• Next DST Change Service NDCS (The Next DST Change Service (NDCS) defines how the information about an upcoming DST change can be exposed using the Generic Attribute Profile (GATT).)
• Phone Alert Status Profile PASP (The Phone Alert Status Profile (PASP) enables a PUID device to alert its user about the alert status of a phone connected to the PUID device.)
• Phone Alert Status Service PASS (The Phone Alert Status Service (PASS) exposes the phone alert status when in a connection.)
• Proximity Profile PXP (The Proximity profile (PXP) enables proximity monitoring between two devices.)
• Reference Time Update Service RTUS (The Reference Time Update Service (RTUS) defines how a client can request an update from a reference time source from a time server using the Generic Attribute Profile (GATT).)
• Time Profile TIP (The Time profile enables the device to get the date, time, time zone, and DST information and control the functions related the time.)
• Tx Power Service TPS (The Tx Power Service (TPS) exposes a device’s current transmit power level when in a connection.)

A detailed example – the Bluetooth Proximity Profile

Example products could be a watch, laptop, tablet, car or mobile phone.

The Proximity Reporter would be a GATT server and the Proximity Monitor would be a GATT client.

A usage scenario? Bluetooth.org writes:

“The Proximity profile defines the behavior when a device moves away from a peer device so that the connection is dropped or the path loss increases above a preset level, causing an immediate alert. This alert can be used to notify the user that the devices have become separated. As a consequence of this alert, a device may take further action, for example to lock one of the devices so that it is no longer usable.”

The Proximity profile can also be used to define the behavior when the two devices come closer together such that a connection is made or the path loss decreases below a preset level.

Note that one profile can combine multiple services, so a Proximity Reporter (a watch, perhaps) could use the Immediate Alert Service or the Link Loss Service or the TX Power service to report to the Proximity Monitor (a laptop, perhaps).

XML and profiles

GATT Services use XML, with profiles, services, characteristics, descriptors and declarations defined in an XML format.

Units, Format Types, Declarations, Descriptors, Characteristics, and Services are defined.

You can view the full details at https://developer.bluetooth.org/gatt/Pages/Definition-Browser.aspx

Continuing in detail with the Proximity example, the Proximity profile is defined below. If you can read XML, you can see the tags for the Immediate Alert Service, the Link Loss Service, and TX Power service (mentioned previously as possible sub-elements of the profile)…

<?xml version=”1.0″ encoding=”UTF-8″?>

<!– Copyright 2011 Bluetooth SIG, Inc. All rights reserved. –>
-<Profile name=”Proximity” type=”org.bluetooth.profile.proximity” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”http://schemas.bluetooth.org/Documents/profile.xsd”>

-<InformativeText>
<Abstract> The Proximity profile enables proximity monitoring between two devices. </Abstract>
-<Summary> The Proximity profile defines the behavior when a device moves away from a peer device so that the connection is dropped or the path loss increases above a preset level, causing an immediate alert. This alert can be used to notify the user that the devices have become separated. As a consequence of this alert, a device may take further action, for example to lock one of the devices so that it is no longer usable. <p> The Proximity profile can also be used to define the behavior when the two devices come closer together such that a connection is made or the path loss decreases below a preset level. </p> </Summary> </InformativeText>
-<Role name=”Proximity Reporter”>
-<Service type=”org.bluetooth.service.link_loss”>
<Declaration>Primary</Declaration>
<Requirement>Mandatory</Requirement>
</Service>
-<Service type=”org.bluetooth.service.immediate_alert”>
<Declaration>Primary</Declaration>
<Requirement>Optional</Requirement> </Service>
-<Service type=”org.bluetooth.service.tx_power”>
<Declaration>Primary</Declaration>
<Requirement>Optional</Requirement>
</Service>

-<Conditional condition=”if_any_supported_all_must_be_supported”>
<Type>org.bluetooth.service.immediate_alert</Type>
<Type>org.bluetooth.service.tx_power</Type> </Conditional>
</Role>
-<Role name=”Proximity Monitor”>
-<Client type=”org.bluetooth.service.link_loss”>
<Requirement>Mandatory</Requirement> </Client>
-<Client type=”org.bluetooth.service.immediate_alert”>
<Requirement>Mandatory</Requirement> </Client>
-<Client type=”org.bluetooth.service.tx_power”>
<Requirement>Mandatory</Requirement> </Client>
</Role>
</Profile>

Client – Server – Peripheral – Hub – Dual-mode

In terms of software, a client device – for example a smartphone – can initiate GATT commands and requests, and also accept responses.

A server, by contrast – for example, a pressure sensor, maybe – receives GATT commands and requests, and returns responses.

Note that with Bluetooth 4.1 (released December 2013), a single device can act as both a Bluetooth Smart peripheral and a Bluetooth Smart Ready hub at the same time, said the SIG (this is dual-mode, in Bluetooth terms).

“For example, a smart watch acts as a hub gathering information from a Bluetooth Smart heart rate monitor while simultaneously acting as a peripheral to a smartphone — displaying new message notifications from the phone. As the Bluetooth Smart ecosystem grows, the Bluetooth SIG expects more solutions to play both a hub and peripheral role.”

See also:

Nordic Semiconductor nRF51822 (a multi-protocol SoC for Bluetooth low energy)

CSR µEnergy Bluetooth Smart family

What is… Bluedroid?