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 abstract 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 protocol stack, that is why we will invest some time to master them. We will also cover BLE profiles, services, characteristics, device roles and the available network topologies 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. In addition to that, we will cover the advertising module in the nRF5 SDK to configure all aspects of the advertising phase of a connection-oriented device. We will also learn how to configure the nRF5x BLE Physical Layer(PHY) transmission power to target your application range/power demands.

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 data throughput, and the available security 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 in BLE devices 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 data openly to any interested neighboring device. This is a one-way communication method where a device broadcasts its data to all neighbouring devices in RF range. It is also used for low-accuracy ( 1.5 meters margin of error ) location services such as retail point-of-interest information, basic indoor navigation and way finding.	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 connections are possible in the latest nRF5x chips as star, piconet or scatternet .	Unlimited (Technically limited by RF interference in the 2.4GHz band).	32,767(max nodes in a network), with the possibility of sub-nets up to 4,096.
Maximum Application Throughput	About 1.4 Mbps. It drops significantly if the number of connections >1.	N/A	About 3.45 kbps
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. Security is optional in this mode.	Not supported by the protocol stack. Nevertheless, It can be implemented by the application layer, if needed.	Supported by the protocol stack (128-bit AES). Security is mandatory in this mode.

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, one-direction data delivery. The Broadcaster sends advertising 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 advertising packets(This GAP role uses the underlying LL Scanner role). How much user data is in an advertising payload, this depends on the BLE version used and the metadata set in the advertising packet as we will see in the exercises . Keep in mind that this is a unidirectional data delivery from the Broadcaster to the Observer.

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 Wi-Fi , classic Bluetooth, and other ISM-band based wireless protocols. So technically, RF interference might get in the way (Mesh topology can help here).

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 ( 1.5 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 does not rely on the RSSI , instead, it used new core features added to it called Angle of Arrival (AoA) and Angle of Departure (AoD).

For Data Broadcast, the advertising packets sent by the Broadcaster could be configured as scannable. A scannable advertising packet (Packet type: 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 an Observer can request further data from a Broadcaster. A Scan Request packet can not contain any user data.

Keep in mind that connection-less data delivery is not as reliable as the connection-oriented by design. Also its a one direction data flow. The broadcaster can broadcast data to all Observers in radio range, however an Observer can not send any useful data to the Broadcaster. Another 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 it 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 reliable 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 pair. 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 the central role is performed by a more capable device such as a smartphone, tablet or PC. The Central GAP role uses the LL Mater role.

However, with Nordic Semiconductor latest Bluetooth protocol stacks(SoftDevices), you could have concurrent multi-link peripheral, central or both with up to 20 concurrent connections. Concurrent connections is the focus of Lesson 9.

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 not 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 section). 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.
• 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 advertising 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 only two possible configurations of the Advertisement Flags from an nRF5x chip.

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 advertising 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 advertising mode of a connectable Peripheral(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 is 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 terms 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 advertising packets. The first four are the original advertising 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 advertising packets and the advertising data format once we introduced the tool to parse these packets over the air (nRF Connect) in the next lesson.

Advertising 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 auxiliary advertisement will be sent on a certain advertisement channel.
AUX_ADV_IND	5.x	Connection-oriented communication	An auxiliary 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 security keys), bonding (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. In a BLE connection, security is optional. This means that you as a developer have the option to choose which level of security(if any) is needed for your BLE-enabled product.

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 identify 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’s privacy.

• 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. This type of address does not change during runtime. It either changes on boot up or it doesn’t.
• 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. The address changes at runtime at a certain intervals(Ex: every 15 minutes).
• 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 what’s 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 advertising packet. This can improve device privacy and also reduces power consumption, since fewer bytes are sent over the air and hence the radio is turned ON for a shorter period of time. This feature was introduced in BLE 5.

By this, we have covered sufficient details about the GAP layer. Take a look at the ble_gap.h which provides the SoftDevice API (definitions and prototypes) for the GAP layer. This files comes with the nRF5 SDK installation as shown in the screenshot below. We will use these API along with BLE libraries of the nRF5 SDK to configure the GAP as we want.

GATT

As mentioned earlier, GATT is responsible for the data exchange in the connection-oriented method of communication of BLE. It defines two device roles(GATT Server and GATT Client), 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 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. Below is a screenshot of the Heart Rate Service which has two characteristics: the Heart Rate Measurement and the Body Sensor Location. The Heart Rate service is part of the Heart Rate Sensor GATT Server, which contain other services as we will see in-depth in Lesson7.

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 field, 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 (16-bits) or a vendor specific UUID (128-bits). Below is a screenshot from the Bluetooth-SIG official website showing some of the standard UUIDs used for Characteristics. Vendor specific UUIDs are examined in Lesson 8 , where we will create our own custom Services and Characteristics.

• Characteristic value handle: The handle of the characteristic value. This is assigned dynamically by the SoftDevice. The handle is the value needed by the client to reference the value. Think about this as the address of the data.
• 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 advertising packets. This would enable nearby BLE observers devices to be able to read the data without being in connection with the device. However, keep in mind that GATT is meant for the connection-oriented method of communication in BLE; so if you enable this feature, you still need to write application-level code to take care of including the characteristic’s data in the advertising packets.
  • 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 significant 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 is 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 notify, 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). This is defined in the BLE specifications but currently not supported by the SoftDevice BLE protocol stack.

In addition to the deceleration and value, a characteristic could include a descriptor. There are several types of descriptors outlined in the BLE 5 specifications. 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).

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 issues services discovery to know what are the available services and characteristics on the server side. A client can issue the following GATT operations(transactions) :

1. Service(s) discovery: Initially, a client is not aware of 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/descriptors and their handles (addresses).

2. Read characteristic/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.

3. Writing characteristic/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. 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.

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 to fit the BLE Link Layer standard packets. The L2CAP defies only a lower bound for the ATT packet size which is the default BLE_GATT_ATT_MTU_DEFAULT of 23 bytes, the upper bound is left unset by the BLE specifications. Upon connection, the server and the client can exchange and negotiate a new value for the ATT MTU. The new value must be supported by both ends for the negotiation to succeed. Having a higher ATT MTU size can slightly help to improve the data throughput by improving the actual data/headers(metadata) ratio.

In general, the transactions between a client and a server starts by the client issuing a service(s) discovery operation as simplified in the figure below:

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.

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.

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. The complete implementation is covered in-depth in Lesson7.
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

Enroll to the Intermediate course to access full content.

References and pictures:
Nordic Semiconductor http://www.nordicsemi.com