Lesson 2 – BLE profiles, services, characteristics, device roles and network topology

Overview

In this lesson we will dive into the  GAP and GATT  layers of the BLE architecture. GAP and GATT abstracts all the underlying BLE layers. GAP provides a standard framework for controlling a BLE device, while GATT provides a standard framework for managing data in a BLE device.  As a BLE firmware developer, these two layers are the most layers interacted with in the BLE stack, that’s why we will invest some time to master them. We will also cover BLE profiles, services, characteristics, device roles and the available network topology in BLE . In the exercise part of this lesson, we will setup the device BLE address, name, security settings(Mode and Level), and the preferred connection parameters through GAP SoftDevice API.

Communication Options in BLE

Before we dive into GAP and GATT, we need to understand and differentiate the three different options available for communication in BLE. With the latest BLE specifications, there are three different communication options which offer different topologies and use cases. Below is a comparison table in terms of typical use cases (applications), maximum number of connections, maximum payload in a single packet , and the available security options:

Bluetooth Low Energy Tutorial
BLE Communication Options
Feature Point-to-Point(1:1) Data Broadcast(1:Many) Mesh(Many:Many)
Applications This is by far the most widely used method. This is the mode used to control BLE peripherals like health monitors,  fitness trackers, smart toys, and PC peripherals and accessories. This is also known as Connection-oriented communication. This method is covered thoroughly throughout this course. Data Broadcast ( aka BLE beacons, aka connection-less communication ) used for sensors broadcasting their public data openly to any interested neighboring device. It is also used for low-accuracy ( 2meters margin of error ) location services such as retail point-of-interest information, basic indoor navigation and way finding. This method is covered in-depth in Lesson 8. BLE Mesh is used for establishing many-to-many (m:m) device communications. It enables the creation of complex large-scale device networks and is ideally suited for monitoring,  control, and automation systems where tens, hundreds, or thousands of devices need to reliably and securely communicate with one another. BLE Mesh does increase the range and coverage beyond BLE RF range, it also helps in avoiding walls and physical obstacles. This method of communication is the main focus of the Advanced Level of this course.
Max Connections Not specified in the BLE specifications, however, it is implementation specific – 20 for the latest nRF5x chips, as piconet or scatter net . Unlimited ( Technically limited by RF interference ). 32,767(max nodes in a network), with the possibility of sub-nets up to 4,096.
Max Payload size 244 Bytes. 31 Bytes, or 255 Bytes through advertisement extension (BLE5 Only). 29 Bytes.
Security available Supported by the protocol stack (128-bit AES). Most nRF5x chips have built-in cryptographic accelerators dedicated for this, as we have seen in the Foundation Level of this course. Not supported by the protocol. Nevertheless,  It can be implemented by the application layer (if needed). Supported by the protocol stack (128-bit AES).

GAP

The Generic Access Profile (GAP) provides a full standard framework for controlling a BLE device in the Point-to-Point(1:1) and Data Broadcast(1:Many) communication methods. It defines how BLE devices can discover and connect with one another and how they can establish security including privacy over the connection. It also details how devices can be broadcasters and observers and transfer data without being in a connection state(Data Broadcast). In addition to that, GAP sets the address of the device as per the design privacy constraints. So to summarize , GAP is responsible for the following  three major areas of BLE:

  • Data Broadcast.
  • Connections.
  • Connections Security.

Next, we will cover these three areas one by one.

Data Broadcast

For data broadcast we need a Broadcaster/Observer GAP roles pair. Data broadcast achieves one-to-many (1:m), connection-less data delivery. The Broadcaster sends advertisement packets that contain some data in its payload( This GAP role uses the underlying LL advertiser role), while on the Observer end , it scans for advertisement packets( This GAP role uses the underlying LL Scanner role). How much user data is in an advertisement payload, this depends on the BLE version used and the metadata set in the advertisement packet  as we will see in the exercises .

For Data Broadcast, the advertisement packets sent by the Broadcaster could be configured as scannable(As we will see in Lesson 8 ). A scannable advertisement packet (ADV_SCAN_IND)means that the packet received by the Observer can allow it to issue a Scan Request. A Scan Request is a mechanism by which the Broadcaster can know about an Observer presence( aka Active Scanning), and it also allows the Observer to request further data from the Broadcaster.

There is no restriction in the BLE specifications on the number of broadcasters an observer can listen to, or the number of observers a broadcaster can broadcast to; However; you always have to remember that BLE operate in the same crowded bandwidth (2.4Ghz ISM ) as WiFi , classic Bluetooth, and other ISM-band based devices. So technically, interference might get in the way ( Mesh Topology can help here ).

nRF52 Tutorial
BLE – Data Broadcast Communication

The Data Broadcast configuration is most suitable for sensors broadcasting their public data openly to any interested neighboring device. BLE Data Broadcast is also used in Beacons for low-accuracy ( 2 meters margin of error) location services such as retail point-of-interest information, basic indoor navigation and way finding. The low-accuracy mechanism relies on the comparison of the Received Signal Strength Indication (RSSI) with the transmitted power parameter.  However, for high-accuracy location services( few centimeters margin of error ), its highly advisable to use a BLE 5.1 enabled device such as the nRF52811 SoC . BLE 5.1 doesn’t rely on the RSSI , instead, it used new core features added to it called Angle of Arrival (AoA) and Angle of Departure (AoD).

One of the drawback of BLE Data Broadcast is that the data sent is seen by all neighboring devices, you can not send directed customized data to individual devices. This might be a major issue in some applications and that is why we have the connection-based communication in BLE to tailor that(covered next).

Connections

This is the most popular communication method in BLE, it establishes a bidirectional one-to-one (1:1) connection-oriented data transfers. In order to establish a BLE connection we need to have a Peripheral/Central GAP roles pairs. The Peripheral GAP role is optimized to consume the least amount of processing power and memory footprint. This is most of the time the role chosen for the embedded device being designed. It uses the LL slave role. On the other end, we have the Central GAP role. Most of the time this role is performed by a more capable device such as a smart phone, tablet or PC. The Central GAP role uses the LL Mater role.

nRF52 DK Tutorials
BLE Connection-Oriented Communication

With Nordic Semiconductor latest Bluetooth protocol stack (SoftDevice), You could have concurrent multi-link peripheral and central, which means  you could have concurrent central, observer, peripheral, and broadcaster roles with up to 20 concurrent connections along with one Observer and one Broadcaster. Concurrent BLE configuration for an nRF5x SoC is the focus of Lesson 14.

A peripheral device can be switched to different Discovery and Connection modes to achieve a certain goal or allow the central peer to perform a certain procedure.

Possible peripheral discovery modes are listed below:

  • Non-Discoverable Peripheral : This is the default mode that a peripheral is set into, and also the mode that the peripheral is changed to by default when a connection is established. A peripheral in this mode can’t be discovered nor connected to.
  • Limited-Discoverable Peripheral (BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE): Limited in terms of time. A peripheral in this mode is assumed to be only discoverable for a period of time (Configurable by SoftDevice API and the Advertising Library as we see in the exercises  ). Limited-Discoverability helps save power by advertising for a limited amount of time. If no connection was initiated during this time, the peripheral will simply go to idle. The only way to bring back discoverability is by user intervention(Ex: Press a button).
  • General-Discoverable Peripheral (BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE): The peripheral is assumed to advertise indefinitely until a connection is establish.

The Peripheral indicate its discovery mode by setting specific Advertisement Flags ( Flags AD) in the advertisement packet, these flags can help scanners to organize and prioritize advertisement. The one byte advertisement flags are organized  as follows:

  Bit Description
  Bit0 Indicates LE (Low Energy) Limited Discoverable Mode.
  Bit1 Indicates LE General Discoverable Mode.
  Bit2 Indicates whether BR/EDR (Bluetooth Classic) is NOT supported. This is always set as the nRF5x are NOT dual-mode chips.
  Bit3 Indicates whether LE and BR/EDR Controller operates simultaneously.This is never set as the nRF5x are NOT dual-mode chips.
  Bit4 Indicates whether LE and BR/EDR Host operates simultaneously. This is never set as the nRF5x are NOT dual-mode chips.
  Bit5 Reserved. Not used.
  Bit6 Reserved. Not used.
  Bit7 Reserved. Not used.

Below are the the only two possible configurations of the Advertisement Flags from an nRF5x chip.

 Bluetooth Low Energy Nordic Tutorial
Option 1: nRF5x Advertisement Flags-Limited discovery with no BR/EDR support.
Bluetooth Low Energy Nordic Training
Option 2: nRF5x Advertisement Flags – General Discovery with no BR/EDR Support.

The above screenshots are obtained using  nRF Connect which we will use frequently throughout the course for testing and debugging. The nRF Connect is studied thoroughly in the next lesson.

As for the connection modes available for a Peripheral:

  • Non-connectable Peripheral: As the name implies, a peripheral in this mode can’t be connected to. it could be either conducting Data Broadcast communication or it could be in idle radio state.
  • Directed-connectable Peripheral: Directed in terms of the receiving device. This mode is usually entered by the peripheral, for a short period of time, right after disconnecting. It attempts to reconnect to the central that was connected most recently. This is very useful to stay connected to one peer and seamlessly recover from accidental disconnects. The Peripheral sends advertisement packets of type (ADV_DIRECT_IND) which only contains the Bluetooth address of the peer central of interest .
  • Undirected-connectable Peripheral:No prejudice on the receiving end. This is the standard advertisement mode of a connectable Peripheral( packet type = ADV_IND). All nearby scanners will receive this packet, and be able to send connection requests to the peripheral. Whether the connection request will be accepted or not, that’s depends on the filtering policy”whitelist” of the peripheral as we will see in later lessons.

It’s worth mentioning that for each of these GAP mode there is a counterpart GAP procedure on the central peer to achieve the action under process

In relation with connections, GAP is also responsible for

  • Connection Parameters Update.
  • Advertising Data Formatting .

With the help of GAP, the connection parameters such as the Connection Interval, Slave Latency, Supervise timeout (covered in the previous lesson ), and even the selected PHY can be changed during the connection. This is a quite fundamental feature that makes BLE connections fixable to meet the application dynamically needs in term of data throughput and power consumption. The central always has full control of these parameters and can change it any time during the connection. On the other hand, the peripheral can suggest to the central its preferred parameters. In this case , the central needs to make the decision whether to accept, deny or even meet in the middle.

With the latest specifications, there are 8 different types of advertisement packets. The first four are the original advertisement packets, which were introduced as part of the first specifications of BLE 4.0, while the last four were introduced as part of BLE specification 5 at the last quarter of 2016. The first four are guaranteed to be supported in any BLE-enabled device. We will dive into the advertisement packets and the advertising data format once we introduced the tool to parse these packets over the air (nRF Connect) in the next lesson.

Advertisement Packet Minimum BLE Version BLE Communication method used Description
ADV_IND Legacy 4.x Connection-oriented communication Connectable undirected advertisement.
ADV_DIRECT_IND Legacy 4.x Connection-oriented communication Connectable directed advertisement.
ADV_SCAN_IND Legacy 4.x Data Broadcast Non-connectable scannable undirected advertisement.
ADV_NONCONN_IND Legacy 4.x Data Broadcast Non-connectable undirected non-scannable advertisement.
ADV_EXT_IND 5.x Data Broadcast Indicate that an advertisement will be sent on a secondary advertisement channel.
AUX_ADV_IND 5.x Connection-oriented communication Send connectable directed advertisement on a secondary advertisement channel.
AUX_SYNC_IND 5.x Data Broadcast Periodic advertisements on secondary advertisement channels.
AUX_CHAIN_IND 5.x Data Broadcast Chain advertisement packets, allowing the advertisement data to extend beyond one packet.

Connection Security

GAP manages the connections security through the help of the underlying Security Manager Protocol(SMP). It offers authentication (Protection against Man-in-the-middle attacks), pairing (generating and exchanging temporary security keys), bonding (generating and storing permanent security keys in a non-volatile memory),  encryption of data(AES 128-bit), data signing, and device privacy by providing a mechanism to generate random Bluetooth device addresses to prevent a device from being tracked by unauthorized party.

GAP is responsible for setting the Bluetooth Low Energy device address,which is similar to an Ethernet Media Access Control (MAC) address. It is a 48-bits value (6 Bytes in the form of 12 hexadecimal digits XX:XX:XX:XX:XX:XX ), which is supposed to uniquely identifies a device. There are five possible configurations for a BLE device address. The type of address used for a BLE-enabled product affects the product security capabilities, as we will see thoroughly in Lesson 13

nRF5 SDK Tutorials
Examples of a BLE Device Address ( Captured using nRF Connect)
nRF52 DK Tutorials
Bluetooth Low Energy Device Address Configuration
  • Public Device Address(BLE_GAP_ADDR_TYPE_PUBLIC): Usually this is used when the product being designed has no device privacy constraints. A company wishing to use such address for their products must  obtain it  from the IEEE Registration Authority. This address is fixed throughout the lifetime of the product. A Public address follows the IEEE 802-2001 standard, and thus has two parts : 24-bit IEEE-assigned Company ID and 24-bit company-assigned device ID .
  • Random Static Device Address(BLE_GAP_ADDR_TYPE_RANDOM_STATIC): As the name implies, this type of address is randomly generated. It could be either configured to stay fixed through the lifetime of the device ( similar to a public address) or it could be configured to change on each device boot up.
  • Random Resolvable Private Address(BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE): The type of addresses offers great privacy to the device and prevent it from being tracked.  It is generated using a random number and the secret Identity Resolving Key (IRK). This IRK is exchanged  between two devices at the time of pairing and stored in the device’s internal memory during bonding, hence, to use such an address pairing and bonding must be enabled.
  • Random Non-Resolvable Private Address(BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_NON_RESOLVABLE): Randomly generated address that changes every period of time or at every connection.

For an advertising device (Data Broadcast), it is possible to advertise in whats known as anonymous advertising where the address is not set at all (BLE_GAP_ADDR_TYPE_ANONYMOUS). When a device uses this feature of anonymous advertising, it does not include its address in the advertisement packet. This can improve device privacy and also reduces power consumption, since fewer bytes are sent over the air. This feature was introduced in BLE 5.

Connections security, including setting the device address, security levels,  pairing, bonding, key types, and data encryption are all covered in-depth with hands-on exercises in a dedicated lesson  (Lesson 13).

By this we have provided a fairly good introductory to the GAP layer. Take a look at the ble_gap.h which provides the SoftDevice API (Definitions and prototypes ) for the GAP interface. This files comes with the nRF5 SDK installation as shown in the screenshot below. We will use these API along with the BLE libraries of the nRF5 SDK to configure the GAP as we want.

nRF5 SDK Tutorial
SoftDevice headers ( API) for the GAP layer ( Covered thoroughly in Lesson 4)
SoftDevice Tutorial
Small Snippet of the SoftDevice API for the GAP Layer

GATT

As mentioned earlier, GATT is responsible for the data exchange between between BLE devices. It defines two device roles, which a BLE device can choose to implement either or both at the same time.

GATT Server: We usually implement this role on the embedded device side. The server implements the attributes table structured in the form of Services and Characteristics. In other words, it holds the useful data to be accessed/monitored by a remote client. A GATT server contains one or more GATT services.  A service encapsulates zero or more functionally-related user data containers called characteristics.

nRF52832 Tutorial
Example of a GATT service(Heart Rate Service- HRS ) containing two characteristics ( Heart Rate Measurement – HRT and Body Sensor Location – BSL) – Captured and parsed using nRF Connect

A characteristic encapsulates at least two attributes, the characteristic declaration attribute and the value attribute. The value attribute contains the user data in its value filed, while the characteristic declaration contains metadata about the characteristic. The metadata is as follows:

  • Characteristic value UUID:  The UUID ( type) of the characteristic value.Being an attribute, the UUID could be either a standard Bluetooth-SIG defined UUID ( 32-bits) or a vendor specific  UUID (128-bits). Below is a screenshot from the Bluetooth-SIG offical website showing some of the standard UUIDs used for Characteristics. Vendor specific UUIDs are examined in Lesson 9 , where we will create our own custom Services and Characteristics.
BLE nRF5 tutorials
Example of Bluetooth-SIG defined UUIDs ( Source: Bluetooth-SIG Official Website)
  • Characteristic value handle: The handle of the characteristic value.This is assigned by the SoftDevice. The handle is the value needed by the client to reference the value. Like an address.
  • Characteristic properties: Lists the GATT operation(s) allowed on the characteristic value. The list is elaborated below:
    • Broadcast: This is an interesting property that allows to include a characteristic value(or part of it) to be available part of advertisement packets. This would enable nearby  BLE observers devices to be able to read the data without being in connection with the device.
    • Read: If enabled, the client can read the characteristic value.
    • Write with no response: When this property is set, the client can write to the characteristic value. No response (acknowledgment) is sent from the server. This type of write may be seen as unreliable but it saves a signification amount of power on the server side.
    • Write: When this property is set, the client can write to the characteristic value and it should expect a response(acknowledgment ) from the server side.
    • Notify:  This property enables the server to send data to the client at any time it wishes to. It’s also known as Server-initiated data transfers. No response (acknowledgment ) is sent by the client. Server-initiated transfers  requires a descriptor (covered below )
    • Indicate: Same as notification, except that the client has to send a response (acknowledgment ) on data arrival.
    • Authenticated Signed Write: If enabled, allows the server to verify the Authenticity  “signature ” of the data and confirm its source. Pairing and bonding is required here to generate & exchange the Connection Signature Resolving Key(CSRK).
nRF52 DK Tutorial
GATT Characteristic Properties defined as a structure of bit fields by the SoftDevice API ( ble_gatt.h)

In addition to the deceleration and value, a characteristic could include a descriptor. There are several types of descriptors outlined in the BLE 5 specification. In general,  a descriptor is used for one of the following two purposes. The first use is to include more metadata about the characteristic, for example you could use it to add a text stating the unit used for the measurement. The second use for the descriptor, which is the most commonly used is to use it as a switch to turn  ON/OFF indication and notification ( Server-initiated updates). This type of descriptors is known as Client Characteristic Configuration Descriptor(CCCD).

nRF52832 tutorials
GATT Characteristic Example ( Heart Rate Measurement – HRM)
nRF52832 training
GATT Service Example( Heart Rate Service -HRS)

GATT Client: We usually implement this role on a smartphone, tablet or a computer. The client is the side interested in accessing the data. It does not have its own attributes table. Instead when a client wishes to communicate with a server, it first issue services discovery to know what are the available services and characteristics on the server side. A client can issue the following GATT operations :

1. Service(s) Discovery: Initially, a client is not aware the available services, characteristics and their potential descriptors on the server side. Therefore , a service(s) discovery is needed at the beginning to obtain the structure of all available services and characteristics on the server side. In addition of knowing the structure, the client will know what are the operations supported on the discovered characteristics and descriptors.

2. Read characteristics/descriptor: This operation allows a client to read the current value of a characteristic value or a descriptor. Most of the time the read is performed per handle. Part of the read command is the handle of the characteristic or the descriptor to be read. A client can also issue a read request based on type. For instance, it can issue a read request to all characteristic of type (UUID = 0x2A38) on the server side. The read operation depends on the current established security level and the permissions of the  characteristics/descriptor set on the server. The server can deny access if the security level is not matching the requirements as we will see in Lesson 13 when we cover security in-depth .

3. Writing Characteristics/descriptor: This operation allows a client to write to a characteristic value or a descriptor. Most of the time the write is performed per handle. Part of the write command is the handle of the characteristic or the descriptor, and the value to be written. A client can also issue a write request based on type. Similar to read operation, the write operation depends on the current established security level and the permissions of the  characteristics/descriptor set on the server. The server can deny the write operation if the security level is not matching the requirements as we will see in Lesson 13 when we cover security in-depth .

Depending on the characteristic permissions, a client can issue a write without response commands. A write without response will not be acknowledged by the server. This type of writes is only supported on characteristic with “Write with no response” permission set.

There is also an authenticated Signed Write operation. This operation is only permitted on characteristic with “Authenticated Signed Write” permission set, and when bonding is enabled with certain security levels ( Lesson 13 )

4.Exchange ATT MTU: The ATT MTU stands for the Attribute Protocol Maximum Transmission Unit, which is the maximum size of an ATT packet in bytes. Recalling the BLE architecture diagram. The L2CAP fragment and assembly ATT packets, the L2CAP defies only a lower bound for the ATT packet size which is default  BLE_GATT_ATT_MTU_DEFAULT of 23 bytes, the upper bound is left unset by the BLE specifications . Upon connection, the client or the server can exchange and negotiate a new value for the ATT MTU.

In general, the transactions between a client and a sevver starts by the client issuing a …

BLE nRF52 Tutorial
GATT Client/Server Interactions

The SoftDevice GATT APIs are mainly distributed in three header files as shown in the screenshot below, we will use these API along with the BLE libraries shipped with the nRF5 SDK to configure the GATT layer as we want.

nRF51 tutorials
SoftDevice GATT API

BLE Profiles

A BLE profile serves as an application layer for specific and already defined use cases.Generally speaking, a  BLE profile is a standard collection of services for a specific use case. The standard which is most of the time  set by SIG, or sometimes by other companies like Apple, describes the roles, requirements, and the structure of the attribute tables(i.e. the services and characteristics ). For instance, The Heart Rate Profile (HRP)  is used for medical and sport equipment with heart rate sensors . The HRP profile consists of five services :

  • The Generic Access Service(GAP Service).
  • Generic Attribute Service(GATT Service).
  • Heart Rate Service – HRS (Covered previously).
  • Battery Service(The current level of the battery).
  • Device Information Service.

We will dive into the HRP profile in-depth in Lesson 7, and understand the purpose of each of these services.

nRF5 SDK SES Tutorial
HRP Profile – Captured using nRF Connect

Below are some other examples of BLE profiles which are supported by well-written examples shipped with the nRF5 SDK:

Profile Documentation nRF5 SDK Example Description
Heart Rate Profile (HRP) HRP By Bluetooth-SIG. examples\ble_peripheral\ble_app_hrs Used for medical and sport equipment with heart rate sensors. The heart rate reading in beats per minutes (bpm) , the location of the sensor, and the battery level of the sensor are accessible.
Health Thermometer Profile (HTP) HTP By Bluetooth-SIG. examples\ble_peripheral\ble_app_hts Used for medical and sport equipment with  body temperature sensors. The temperature reading in Celsius or Fahrenheit , and the battery level of the sensor are accessible.
Proximity Profile (PXP)
PXP By Bluetooth-SIG. examples\ble_peripheral\ble_app_proximity Used for Find Me tags that can be attached to objects like car keys and help in finding them . Alert(Usually sound) can be triggered remotely using a mobile phone or a tablet to physically locate the object(Immediate Alert).

An alert could be also set if the object becomes too far from the phone or the tablet (Link Loss).

Cycling Speed and Cadence Profile(CSCP) CSCP By Bluetooth-SIG. examples\ble_peripheral\ble_app_cscs Used for biking equipment. Bike speed, total distance traveled, cadence , and gear ratio information are accessible.
Running Speed and Cadence Profile(RSCP) RSCP By Bluetooth-SIG. examples\ble_peripheral\ble_app_rscs Used for sport equipment, activity trackers, wireless-enabled wearable. The speed, cadence, distance, and steps are accessible
Apple Notification Center Service (ANCS) ANCS By Apple Inc. examples\ble_peripheral\ble_app_alert_notification Used to establish a connection to an iOS device and access notifications generated on the iOS device such as missed calls , voice mails , emails, etc..
Internet Protocol Support Profile (IPSP) IPSP By Bluetooth-SIG. examples\ble_peripheral\ble_app_ipsp_acceptor Used to establish an IPv6 connectivity over BLE. IPSP enables 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks). The nRF5x chip  will have an IPv6 address and IP packets can be sent and received by the device.

The IPSP is a special kind of profiles that uses the L2CAP directly. More information can be found here by Bluetooth-SIG.

Lesson 2  – Exercises

Exercise 1 – Setting up the BLE device address, name, security settings, and the preferred connection parameters

Contact us on consult@embeddedcentric.com for inquires about the full materials of Nordic nRF5x BLE In-Depth Training Course (Intermediate Level).

 

error: Content is protected !!