Bluetooth Low Energy
Advertising:
By definition the Central and Peripheral are in a connection from the first data exchange.A central device must know that a peripheral device exists to be able to connect with it. A peripheral will therefore advertise its presence using the BLE advertising mode. In this mode, the device uses theGeneric Access Profile (GAP) to send out a bit of information - an advertisement - at a steady rate. This advertisement is what other devices, like your phone, pick up. It tells them about the presence of a BLE device in the neighbourhood, and whether that device is willing to talk to them.
Advertising mode is one-to-many, whereas connected mode is one-to-one
Advertisements are very limited in size. The general GAP broadcast's data breakdown is illustrated in this diagram:
.png)
The BLE stack eats part of our package's 47B, until only 26B are available for our data
Every BLE package can contain a maximum of 47 bytes (which isn't much), and we don't get to use all of it:
- The BLE stack require 8 bytes (1 + 4 + 3) for its own purposes.
- The advertising packet data unit (PDU) therefore has at maximum 39 bytes. But the BLE stack once again requires some overhead, taking up 8 bytes (2 + 6).
- The PDU's advertising data field has 31 bytes left, divided into advertising data (AD) structures. Then:
- The GAP broadcast must contain flags that tell the device about the type of advertisement we're sending. The flag structure uses three bytes in total (one for data length, one for data type and one for the data itself). The reason we need the first two bytes - the data length and type indications - is to help the parser work correctly with our flag information. We have 28 bytes left.
- Now we're finally sending our own data in its own data structure - but it, too, requires an indication of length and type (two bytes in total), so we have 26 bytes left.
All of which means that we have only 26B to use for the data we want to send over GAP.
For many applications, advertisements may be all that's needed. This may be when:
- A peripheral only wants to periodically broadcast a small amount of information that can fit in an advertisement.
- It's also okay for this data to be available to any central device within range, regardless of authentication.
But sometimes you'll want to provide more information or more complex interactions than one-way data transfers. For that you'll need to set up a "conversation" between your BLE device and a user's phone, tablet or computer. This conversation is based on connected mode, which describes a relationship between only two devices: the peripheral BLE device and the central device.
For now, advertising and connected modes cannot co-exist. This is because a BLE peripheral device can only be connected to one central device (like a mobile phone) at a time. The moment a connection is established, the BLE peripheral will stop advertising. At that point, no other central device will be able to connect to it, since they can't discover that the device is there if it's not advertising. New connections can be established only after the first connection is terminated and the BLE peripheral starts advertising again.The latest Bluetooth standard allows advertisements to continue in parallel with connections, and this will become a part of mbed's BLE_API before the end of 2015.
Connection
When in a connection, the Central will request data from the Peripheral at specifically defined intervals. This interval is called the connection interval. It is decided and applied to the link by the Central, but a Peripheral can send Connection Parameter Update Requests to the Central. The connection interval must be between 7.5 ms and 4 s according to the Bluetooth Core Specification.
If the Peripheral doesn’t respond to packages from the Central within the time-frame called connection supervision timeout, the link is considered lost. It is possible to achieve higher data throughput by transmitting multiple packets in each connection interval. Each packet transferred can be up to 20 bytes.
However, if current consumption is important and a Peripheral has no data to send, it can choose to ignore a certain number of intervals. The number of ignored intervals is called the slave latency. While in a connection, the devices will hop through all the channels in the frequency band, except for the advertising channels, in a way that is completely transparent to the application.
- Generic Attribute profile (GATT)
GATT is the layer where the data values are actually transferred.
Roles
In addition to the roles in GAP, BLE also defines two roles, a GATT Server and a GATT Client, that are completely independent of the GAP roles. The concept is the device containing data is a Server, while the one accessing it is a Client.
For the LED Button example, the Peripheral device (with its LED and button) is in the role of Server and the Central is in the role of Client.
GATT hierarchy
A GATT Server organizes data in what is called an attribute table and it is the attributes that contain the actual data.
Attribute
An attribute has a handle, a UUID, and a value. A handle is the index in the GATT table for the attribute and is unique for each attribute in a device. The UUID contains information on the type of data within the attribute, which is key information for understanding the bytes that are contained in the value of the attribute. The UUID will not be unique within a device and there may be attributes with the same UUID.
Characteristic
A characteristic consists of at least two attributes: a definition of the characteristic and an attribute that holds the value for the characteristic.
For the LED Button example, we use a characteristic for the current button state and one for the current LED state.
Descriptors
Any attribute within a characteristic declaration that is not the characteristic value, is by definition a descriptor. A descriptor is something that provides more information about a characteristic, for instance a human-readable description of the characteristic.
However, there is one special descriptor that is worth mentioning in particular: the Client Characteristic Configuration Descriptor (CCCD). This descriptor is added for any characteristic that supports the Notify or Indicate properties.
Writing a ‘1’ to the CCCD enables Notify, while writing a ‘2’ enables Indicate. Writing a ‘0’ disables both Notify and Indicate.
Service
A service consists of one or more characteristics, and is a logical collection of related characteristics.
For the LED Button example, both characteristics will be grouped into one service.
Profile
A profile can be defined to collect one or more services into a use case description. A profile document includes information on services that are available and how they are used. Therefore, this document will often contain information on what kind of advertising and connection intervals should be used, whether security is required, and similar. It should be noted that a profile does not have an attribute in the attribute table.
For the LED Button example, we use a characteristic for the current button state and one for the current LED state.
- Standard versus custom services and characteristics
The Bluetooth SIG has defined a number of profiles, services, characteristics, and attributes based on the GATT layer of the stack. However, with Bluetooth low energy all service implementations are part of the application and not the stack, meaning it is possible for an application to support whichever profiles or services it wants to, as long as the stack supports GATT. Because support for profiles and services is in the application, it is possible to create custom services in the application.
For the LED Button example, there is no Bluetooth SIG service that covers this use case, so it will be implemented as a custom service, with two custom characteristics.
UUIDs
All attributes have a UUID. A UUID is a 128 bit number that is globally unique. The Bluetooth Core Specification separates between a base UUID and an alias.
Base UUID
The following Base UUID is used by Bluetooth SIG for all their defined attributes, and with all Bluetooth SIG attributes, the last 16 bits (the alias) is enough to identify them uniquely.
Full UUID — 0x00001234-0000-1000-8000-00805F9B34FB
Corresponding Base UUID — 0x0000xxxx-0000-1000-8000-00805F9B34FB
Do not use the Bluetooth SIG Base UUID for any custom development. Instead, generate your own Base UUID to create new UUIDs.
For the LED Button example, 0x0000xxxx-1212-EFDE-1523-785FEABCD123 will be used as the base.
Alias
The alias is the remaining 16 bits that are not defined by the Base UUID. The Bluetooth Core Specification does not include any rules or recommendations for how to assign aliases, so you can use any scheme you want for this.
For the LED Button example, 0x1523 is used for the service, 0x1524 for the LED characteristic, and 0x1525 for the button state characteristic.
- On-air operations and properties
All on-air operations happen by using the handle, since this uniquely identifies each attribute.
Use of the characteristic is dependent on its properties. Possible properties are:
• Write
• Write without response
• Read
• Notify
• Indicate
More properties are defined in the Bluetooth specification, but these are the most commonly used.
Write and Write without response
Write and Write without response allow the GATT Client to write a value to a characteristic in a GATT Server. The difference between them is that Write without response happens without any application level acknowledgment, only radio acknowledgments.
Read
The Read property makes it possible for the GATT Client to read the value of a characteristic in a GATT Server.
Notify and Indicate
Notify and Indicate allow a GATT Server to make the GATT Client aware of changes to a characteristic. The difference between Notify and Indicate is that Indicate has application level acknowledgment, while Notify does not.
For the LED Button example, the characteristic to control the LED and the characteristic for the current button state are the two custom characteristics used in the LED Button service.
For the LED characteristic, the Central needs to be able to set its value, and possibly read it back. Since the application level acknowledgments aren’t needed, you can use the Write without response and Read properties. For the button characteristic, the Client needs to be notified when the button changes state, but application level acknowledgment isn’t needed. Only the Notify property is needed for this.
The characteristic to control the LED and the characteristic for the current button state are the two custom characteristics used here in the LED Button service. For the LED characteristic, the Central needs to be able to set its value, and possibly read it back. Since the application level acknowledgments aren’t needed, you can use the Write without response and Read properties. For the button characteristic, the Client needs to be notified when the button changes state, but application level acknowledgment isn’t needed. Only the Notify property is needed for this.
- BLE Stack
The BLE stack implements the core BLE functionality as defined in the Bluetooth Core Specification 4.1. The stack is included as a precompiled library and it is embedded inside the BLE Component.
The BLE stack implements all the mandatory and optional features of Low Energy Single Mode compliant to Bluetooth Core Specification 4.1. The BLE Stack implements a layered architecture of the BLE protocol stack as shown in the following figure.
.png)
Generic Access Profile (GAP)
The Generic Access Profile defines the generic procedures related to discovery of Bluetooth devices and link management aspects of connecting to Bluetooth devices. In addition, this profile includes common format requirements for parameters accessible on the user interface level.
The Generic Access Profile defines the following roles when operating over the LE physical channel:
- Broadcaster role: A device operating in the Broadcaster role can send advertising events. It is referred to as a Broadcaster. It has a transmitter and may have a receiver.
- Observer role: A device operating in the Observer role is a device that receives advertising events. It is referred to as an Observer. It has a receiver and may have a transmitter.
- Peripheral role: A device that accepts the establishment of an LE physical link using any of the connection establishment procedures is termed to be in a "Peripheral role." A device operating in the Peripheral role will be in the "Slave role" in the Link Layer Connection State. A device operating in the Peripheral role is referred to as a Peripheral. A Peripheral has both a transmitter and a receiver.
- Central role: A device that supports the Central role initiates the establishment of a physical connection. A device operating in the "Central role" will be in the "Master role" in the Link Layer Connection. A device operating in the
Generic Attribute Profile (GATT)
The Generic Attribute Profile defines a generic service framework using the ATT protocol layer. This framework defines the procedures and formats of services and their Characteristics. It defines the procedures for Service, Characteristic, and Descriptor discovery, reading, writing, notifying, and indicating Characteristics, as well as configuring the broadcast of Characteristics.
GATT Roles
- GATT Client: This is the device that wants data. It initiates commands and requests towards the GATT Server. It can receive responses, indications, and notifications data sent by the GATT Server.
- GATT Server: This is the device that has the data and accepts incoming commands and requests from the GATT Client and sends responses, indications, and notifications to a GATT Client.
The BLE Stack supports both roles simultaneously for a custom profile use case.
Attribute Protocol (ATT)
The Attribute Protocol layer defines a Client/Server architecture above the BLE logical transport channel. The attribute protocol allows a device referred to as the GATT Server to expose a set of attributes and their associated values to a peer device referred to as the GATT Client. These attributes exposed by the GATT Server can be discovered, read, and written by a GATT Client, and can be indicated and notified by the GATT Server. All the transactions on attributes are atomic.
Security Manager Protocol (SMP)
Security Manager Protocol defines the procedures and behavior to manage pairing, authentication, and encryption between the devices. These include:
- Encryption and Authentication
- Pairing and Bonding
- Pass Key and Out of band bonding
- Key Generation for a device identity resolution, data signing and encryption
- Pairing method selection based on the IO capability of the GAP central and GAP peripheral device