A view on Bluetooth Low Energy stack roles

[bogdanalexandru]

Since I have noticed some confusion regarding the roles of the two devices sharing a BLE connection on different layers of the stack, I believe it is useful to centralize a few aspects on this matter.

Find attached a table I have created which shows two devices, a Central and a Peripheral, and the roles each of them has on each layer during (and also while establishing) a connection.

The most important distinction to be made regards the GAP and GATT roles.

GAP is the layer that defines the topology of the BLE system. There are actually 4 roles defined by GAP: Central, Peripheral, Broadcaster and Observer.

A device in the Broadcaster role does nothing more than transmitting data to its surroundings. It does so by constantly advertising, and usually has useful data in the advertising packet, data that is meant for everyone to see. Such a device does not require a receiver, as its only role is to broadcast to others, so it never accepts connections. The Observer is the opposite of the Broadcaster: it passively listens to BLE devices in its area and processes the data from the advertising packets it receives. It does not need a transmitter, as it sends nothing and is never meant to enter a connection.

As you can see from these two examples, the GAP role defines how the device interacts with others.

So let’s move on to the most important roles: the Central and the Peripheral.

The Peripheral, as its name suggests, is a device that usually occupies the outside layers of a topology. It is not meant to make decisions regarding connections, but rather sits there advertising, letting anybody know it has some meaningful data for whoever wants it. Generally, the Peripheral is meant to stay put until someone decides to connect with it. It may stay there for a very long time doing its job, so it must be optimized for low power (the core of the BLE technology actually!).

A good example of a Peripheral is a temperature sensor located in a bus station. Anyone can come with a smartphone, see it while scanning for devices, then connect and get the data (the temperature value) from it.

The Central is in the “middle” of the topology. It is surrounded by Peripherals it can connect to, and it is the one that decides which Peripheral to connect to. In a way, it can be regarded as the active role in this topology.

As you can see from the table attached, the Central device will be the LL Master, thus commanding almost every aspect of the connection. At SMP level, it is the Initiator – the one who commands the beginning of all SMP procedures. On the other end, the Peripheral is the LL Slave and SMP Responder. It only dances as the Central commands it to.

Now that we have a good understanding of what Central and Peripheral means, let’s move on to the GATT level (ATT is tightly connected to GATT so the roles are the same on these two levels). Here the two roles are: Client and Server.

As the names suggest, the GATT Server is the device that holds a GATT database, which is a structured collection of data that the GATT Clients may want to obtain.

The GATT Client, once connected to the Server, sends requests for data, at which the Server responds according to the security settings. The Server does not send data on its own, but only when a Client requests so. The only exception are the Notifications and Indications – operations initiated by the Server whenever a value in the database changes. Still, even these two types of Server-initiated communication must be enabled by the Client in advance!

Confusion sometimes arises between the GAP and GATT roles, in the sense that one may have the tendency of making these assumptions:

GAP Central =? GATT Client

GAP Peripheral =? GATT Server

The reason is that probably most of the time this will be true given the nature of the topology. If your smartphone is a Central device in a BLE ecosystem, and it connects to Peripherals (such as sensors with data or devices to control), a lot of the time it does so in order to be a GATT Client for these devices which usually contain GATT databases and want to act as Servers.

While that may happen often, it is only one of many possibilities!

A Central device may contain a GATT database itself, thus acting as a GATT Server during connections.

Also, to make things even more interesting, two BLE devices may both act as Server and Client for each other at the same time!

Why? Simply because both devices may have data that the other one needs!

For example, maybe the temperature sensor we discussed about wants to keep track of all devices that have connected to it in its lifetime (let’s ignore for a moment potential security issues). In that case, the Central should contain a GATT database itself. There, inside the GAP Service (a special Service, with a well defined UUID, that any GATT database is required to have), the Peripheral may find the Device Name characteristic, which it may read by temporarily assuming the Client role.

[richardwheatley]

Years later definitely but if the data can be broadcast, why would someone put a device in peripheral mode?