GATT Server and Client Roles

Introduction

Bluetooth Low Energy is a powerful and complex technology. It is not like classic Bluetooth where you have a predefined set of official profiles to choose from. Although there are predefined (a.k.a. "adopted") profiles specified by the Bluetooth SIG, these are just the tip of the iceberg, a small subset of the kind of functionality you can achieve with BLE.

In many (or even most) cases, the best option is to create custom profile(s) for your application because it provides ultimate flexibility without an associated cost. In fact, it can be even easier than using one of the adopted profiles because you get to define exactly how everything works together rather than conforming your application into something that is already defined. Also, because there is no official generic "serial port profile" in the BLE world like SPP in classic Bluetooth, sometimes a custom implementation is the only option to do what you need.

To have an effective custom implementation, it is important to understand how a BLE connection works, what roles are played by the devices involved, and how data is transferred from one device to the other over the air. Many terms are used, they are usually not interchangeable, and they all mean different things: master, slave, central, peripheral, client, server, advertise, scan, read, write, notify, and indicate. Understanding the terminology will make it easier to describe and build your BLE application.

Quick Overview

This document covers the following:

To learn about master and slave, central and peripheral roles, see Master and Slave Roles.

GATT Server vs. GATT Client

An important concept in a BLE design is the difference between a GATT server and a GATT client (where GATT means Generic ATTribute profile). These roles are not mutually exclusive, though typically your device will only be a server or a client. Which role(s) your device takes depends on its intended functionality. This is a basic summary of functionalities:

Unlike the master/slave distinction defined in the corresponding user guide, it is easy to see that one device might actually be both at the same time, based on how your application defines the data structure and flow for each side of the connection. While it is most common for the slave (peripheral) device to be the GATT server and the master (center) device to be the GATT client, this is not required. The GATT functionality of a device is logically separate from the master/slave role. The master/slave roles control how the BLE radio connection is managed while the client/server roles are dictated by the storage and flow of data.

Most of the example projects in the SDK archive and online implement slave (peripheral) devices designed to be GATT servers. These are easy to test with our Blue Gecko App (available for Android and iOS). However, there are also a few examples which implement the master (central) end of the connection, designed to be GATT clients.

Receive vs. Transmit - Moving Data

In BLE projects built using the Bluetooth SDK, the GATT structure can be configured using the built-in tool from Simplicity Studio, called the Visual GATT Editor. This can be found on the General or on the Bluetooth Configurator tab of the Application Builder. The configuration file that stores the GATT structure beside other configurations can be found inside the project-folder denoted by .isc-extension. After you press Generate in the Visual GATT Editor, the gatt_db.c/.h and the gatt.xml files are generated.

The structure and flow of data is always defined on the GATT server. The client uses whatever is exposed by the server.

If you are using the IAR Embedded Workbench, see Profile Toolkit Developer Guide.

GATT Structure

A GATT database implements one or more profiles, which are made up of one or more services. Each service is made up of one or more characteristics. For example, in outline form:

You can implement as many profiles, services, and characteristics as you need. These may be entirely customized, in which case they would use your own 128-bit UUIDs generated by the Visual GATT editor. On the other hand, you can create a project which implements adopted specifications by referencing the Bluetooth SIG's online definitions of profiles, services, and characteristics. (If you do this, it usually makes the most sense to start at the profile level and drill down from there because the full list of characteristics includes many things that will undoubtedly be irrelevant to your design.) You can combine these two as well, using some adopted profiles/services and some of your own proprietary ones.

Every BLE device acting as a GATT server must implement the official Generic Access service. This includes two mandatory characteristics: Device Name and Appearance. These are similar to the Friendly Name and Class of Device values used by classic Bluetooth. This is an example definition of an absolutely minimal GATT definition as shown in the Visual GATT editor:

Attributes and Characteristics

You may occasionally hear or see the terms "attribute" and "characteristic" used interchangeably, and while this isn't entirely wrong, it isn't totally accurate and can be confusing. Remember that a service is made up of one or more characteristics. However, one single characteristic, generally the most specific level down to which we define our GATT structure, may be comprised of many different attributes.

Each attribute is given a unique numerical handle which the GATT client may use to reference, access, and modify it. Every characteristic has one main attribute which allows access to the actual value stored in the database for that characteristic. When you read about "writing a value to this characteristic" or "reading that characteristic's value," the read/write operations are done to the main data attribute.

Other related attributes are read-only (such as a Characteristic User Description attribute), some control the behavior of the characteristic (such as the Client Characteristic Configuration attribute which is used to enable notify or indicate operations). The BLE stack and SDK tools generate these as necessary based on the settings configured in the Visual GATT Editor.

Every attribute has a UUID. These may be either 16 bits (e.g., "180a") or 128 bits (e.g., "e7add780-b042-4876-aae1-112855353cc1"). All 16-bit UUIDs are defined by the Bluetooth SIG and are known as adopted UUIDs. All 128-bit UUIDs are custom and may be used for any purpose without approval from the Bluetooth SIG. Two very common 16-bit UUIDs that you will see are 2901, the Characteristic User Description attribute (defined in the User description field of the GATT Editor), and 2902, the Client Characteristic Configuration attribute (created by our SDK when either "notify" or "indicate" is enabled on a characteristic).

Note that some attribute UUIDs do not technically need to be unique. Their handles are always unique, but the UUIDs occasionally overlap. For example, every Client Characteristic Configuration attribute has a UUID of 0x2902, even though there may be a dozen of them in a single GATT database. You should always give your own custom characteristics fully unique UUIDs, but don't be alarmed if you are testing out your prototype with BGTool, you perform a Descriptor Discovery operation, and suddenly see multiple instances of the same UUID for certain things. This is normal.

Data Transfer Methods

read, write, notify, and indicate are the four basic operations for moving data in BLE. The BLE protocol specification allows maximum data payload of 247 bytes for these operations. However, for read operations, the supported size is 249 bytes. BLE is built for low-power consumption and for infrequent short-burst data transmissions. Sending large amounts of data is possible, but usually ends up being less efficient than classic Bluetooth when trying to achieve maximum throughput. The following are a few general guidelines about the types of data transfer you will need to use:

The above four BLE data transfer operations are described here. Commands which you must send are shown separately from the events which the stack generates. Complete API reference can be found for example through Simplicity Studio Launcher on the Documentation tab.

Read

Read operation is requested by the GATT client on a specific attribute exposed by the GATT server. The server then responds with the requested value. In our BLE stack, these API methods are typically involved in read operations:

Write

This operation is requested by the GATT client on a specific attribute exposed by the GATT server, and a new value to write is provided at the same time. The server then stores the new value and (optionally) acknowledges the write operation back to the client. In our BLE stack, these API methods are typically involved in write operations:

The following is an example of the flow of queuing writes:

  1. gecko_cmd_gatt_prepare_characteristic_value_write

  2. Wait for gecko_cmd_gatt_prepare_characteristic_value_write response

  3. Wait for gecko_evt_gatt_procedure_completed event

  4. gecko_cmd_gatt_prepare_characteristic_value_write

  5. Wait for gecko_cmd_gatt_prepare_characteristic_value_write response

  6. Wait for gecko_evt_gatt_procedure_completed event

  7. gecko_cmd_gatt_execute_characteristic_value_write (1)

  8. Wait for gecko_cmd_gatt_execute_characteristic_value_write response

  9. Wait for gecko_evt_gatt_procedure_completed event

Notify

This operation is initiated by the server when a new value is written to a notify-enabled characteristic. If the client has subscribed to notifications on that characteristic, the new value is pushed to the client when it is written. Notifications are not acknowledged, hence you may send more than one notification in a single connection interval, which can be helpful maximizing throughput. Notifications can't be enabled by the server; they must be enabled by the client to ensure data transmission. In our BLE stack, these API methods are typically involved in notify operations:

Indicate

An indicate operation is identical to a notify operation except that indications are acknowledged, while notifications are not. This increases reliability at the expense of speed. In our BLE stack, these API methods are typically involved in indicate operations:

Typically, the GATT server functionality is provided by one device and the client functionality by a different device, but it can happen that both devices provide both kinds of functionality. This does not usually pose any advantages for a well-designed and efficient BLE project. On the contrary, it usually complicates the implementation needlessly and is therefore not discussed here.