Table of Contents

Acknowledgments
Preface
Legal Disclaimer
Main Project
Basics of Bluetooth Low Energy
BLE Peripherals and Centrals
Advertising and Scanning
Connections
Services and Characteristics
GATT Design Guidelines
GAP Design Guidelines
GitHub Repository
Introduction to the nRF5 SDK
Development Environment Setup
Main Project Structure
nRF Development and Troubleshooting Tips
The “Hello World” Example
Bluetooth 5
Power Consumption
Security
Debugging and Testing BLE Applications
Reverse Engineering a Bluetooth Lightbulb
How to Choose a BLE Module/Chipset
Navigating the Bluetooth Specification Document
The Bluetooth Certification Process
Remote Control Source Code Walkthrough
Gateway Source Code Walkthrough
Using nRF Cloud as the Internet Gateway
Glossary
References and Resources
Acknowledgments
I dedicate this work to my mother Ameena, my wife Dana, and my two sons Bassam and Yaseen. Thank you for your
endless love and support.

A special thank you to my best friend and wife Dana for being my rock, believing in me, and always inspiring me and
encouraging me to move forward. Thank you to my sons for putting up with the many long workdays and worked
weekends while remaining patient and always putting a smile on my face.

Iʼd also like to thank David Elvig for the many hours he spent in reviewing most of the content of the book. Last, but
not least, thank you to all my family members, in-laws, friends, colleagues, and followers for your continuous support.

1
Preface

Why I Wrote This Book

My interest in Bluetooth Low Energy sparked in 2014. When I first started learning about BLE and how to develop
applications on the embedded side, I spent hours, days, and weeks just researching and reading everything I can find
on the topic. The learning curve was steep and going through the Bluetooth specification document was utterly
frustrating!

Over the years, though, things started to make a lot more sense and I became much more comfortable with the
technology. Looking back, I wished there were better books and resources that targeted developers with more
practical exercises and examples.

Itʼs probably true for many technologies, but Iʼve found that many of the resources and books on BLE leave a huge gap
when going from theory to practice. I would learn something interesting about BLE from the specification, but then
find out that using it and implementing it for a given platform was very disconnected from what I read.

Finally, last year in July 2017, I decided to write a book on Bluetooth 5 and Bluetooth Low Energy to help other
developers starting on the same journey I had traveled before. I hope you will find it to be a great resource that can
make learning BLE more fun and engaging!

Who Is This Book For?

My goal with this book is to serve three main purposes:

To help embedded developers learn Bluetooth Low Energy technology by guiding them through many exercises of
implementing BLE applications on the Nordic nRF52 platform.
To help mobile developers learn BLE and how itʼs implemented on the embedded side through the many exercises
implemented for the Nordic nRF52 series platform.
To help non-developers learn the basics of BLE.
The book is very practical in nature and assumes some software
development knowledge. However, the main chapters of the book focus on the technology and the protocol — the
development exercises always come at the end of a chapter or in completely separate chapters themselves.

2
How To Read This Book

The book is best read in sequence starting from the beginning to the end.

Main Project Chapter

The book starts off with a chapter describing the Main Project referenced and used in exercises throughout the book.
It represents a simple Home Automation project that we will be referenced and implemented throughout the chapters.
This project requires a number of different hardware components that can be purchased by the reader. (A list of these
components can be found towards the end of this chapter.)

Basics of Bluetooth Low Energy Chapters

The following three chapters go over the basics of Bluetooth Low Energy. They start with a high-level overview of the
architecture of the technology, and then go deeper into the layers that are most relevant to a BLE application
developer. These chapters are titled:

Basics of Bluetooth Low Energy

The Generic Access Profile (GAP)
Advertising and Scanning
Connections
Services and Characteristics
GATT Design Guidelines
GAP Design Guidelines

Development Environment Chapters

Following the Basics of BLE chapters, we get into how to set up your development environment for the Nordic
Semiconductor nRF52 series platform. We will also give an overview of the nRF52 platform, the nRF52 SDK as well as
some “walkthroughs” of simple examples. These chapters are titled:

The Companion GitHub Repository

Introduction to the nRF52 Software Development Kit
Development Environment Setup
Main Project File Structure
nRF Development and Troubleshooting Tips
The “Hello World” Example

Advanced Topics Chapters

3
In these chapters, we will get into some more advanced aspects of Bluetooth Low Energy such as Bluetooth 5,
Debugging, Security, Power Consumption, etc.

These chapters are titled:

Bluetooth 5
Power Consumption
Security
Debugging and Testing BLE Applications
Reverse-Engineering a Bluetooth Lightbulb
How to Choose a BLE Module/Chipset
Navigating the Bluetooth Specification Document
The Bluetooth Certification Process

Main Project Details Chapters

In the final chapters we go through and explain the source code used to implement the Main Project described in the
first chapter of the book. It will go over the parts that are developed using the nRF52 series platform. These chapters
are titled:

The "Remote Control" Source Code Walkthrough

The "Gateway" Source Code Walkthrough
Using nRF Cloud as an Internet Gateway

Glossary and References

Finally, we will list a glossary of the most important terms used in the book. We will also list some references and
useful resources that the reader can refer to for continued learning of Bluetooth Low Energy.

Hardware and Software Components

Throughout the book, we utilize a few software and hardware components that can make developing and testing BLE
applications a much smoother process.

The following components are required/recommended to get the most benefit out of the practical portions of the book
including exercise and the Main Project implementation:

A computer running macOS, Windows, or Linux (required)

An internet connection to download various software packages (required)
Two nRF52840 development kits (required)
A Playbulb Candle (highly recommended)

4
 A Thingy:52 IoT sensor kit (highly recommended)
Another nRF52 or nRF51 development kit for the sniffer exercises (recommended)
A USB hub to connect the various development kits (recommended)
An Ellisys Bluetooth Tracker (optional)

About the Author

Mohammad Afaneh has been developing embedded software and firmware for over 12 years. He has worked at and
consulted for multiple large companies including: Allegion, Motorola, Technicolor, Audiovox, and Denon & Marantz
Group. Throughout his career, he has worked on multiple IoT (Internet of Things) products including: connected
electronic door locks, satellite receivers, a wireless doorbell, and many other side projects.

In August 2015, he decided to leave his full-time job to start his own company Novel Bits, LLC. At Novel Bits, he
focuses on providing consulting services, on-site training, and online education, all primarily focused on Bluetooth
Low Energy technology.

You can reach Mohammad directly at his email [email protected], or by connecting with him on LinkedIn.

Feedback

No work piece is perfect, so I would love to get your feedback on the contents of the book and how it can be improved
to provide more value to you!

This book will continue to be updated, and I am committed to delivering more content to supplement it in the future.
Best of all, these updates, revisions, and enhancements will all be provided to you, the reader, for free.

Feel free to connect with me with any questions, comments or feedback:

Email: [email protected]
LinkedIn: Mohammad's Profile
Twitter: Mohammad's Twitter Handle

5
Legal Disclaimer
All rights reserved. This publication is protected by copyright, and permission must be obtained from the author prior
to any reproductions, transmissions, copying, and resale or likewise. To obtain permission to use major portions of this
book, please contact the author via e-mail at [email protected]. The content and source code within this e-
book is meant for educational purposes only. Any other purpose or use is at the discretion of the user.

The material is provided “AS IS,” without a warranty of any kind, express or implied, including but not limited to the
warranties of fitness for a particular purpose and merchantability. In no event shall the author be liable for any claim,
damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with
the publication, source code, or the use or other dealings with the materials within this book.

Source Code Licenses

All source code provided with the book (in the GitHub repository as well as in the text) is either licensed with the MIT
license or a modified version of source code provided by Nordic Semiconductor.

Nordic Semiconductorʼs license information states:

/**
* Copyright (c) 2014 - 2017, Nordic Semiconductor ASA
*
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form, except as embedded into a Nordic
* Semiconductor ASA integrated circuit in a product or a software update for
* such product, must reproduce the above copyright notice, this list of
* conditions and the following disclaimer in the documentation and/or other
* materials provided with the distribution.
*
* 3. Neither the name of Nordic Semiconductor ASA nor the names of its
* contributors may be used to endorse or promote products derived from this
* software without specific prior written permission.
*
* 4. This software, with or without modification, must only be used with a
* Nordic Semiconductor ASA integrated circuit.
*
* 5. Any software provided in binary form under this license must not be reverse
* engineered, decompiled, modified and/or disassembled.

6
*
* THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
* OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
* GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/

7
Main Project

Introduction

Rather than going through the different aspects of BLE and not understanding how they relate to real-world
applications, I thought it'd be great to start with an overview of the project that will be used referenced throughout the
book.

In my search for a project that would be suitable as the book's main exercise, I wanted to choose one that any reader
would relate to. Because of this, I thought: thereʼs no better project than a home automation project. We all live in a
home in one way or another — whether itʼs an apartment, house, condo (or even a trailer)!

Home automation is one of the major consumer applications for the Internet of Things (IoT) and Bluetooth Low Energy
(especially with the recent release of Bluetooth mesh in July 2017). Weʼve all seen and read about those magical
scenarios where a user walks into the home and magical things happen with minimal or no user interaction — almost
like our homes can read our minds! It may sound a bit far fetched, but realistically, in the future with all the
advancements in technology these scenarios may actually become feasible.

For the sake of simplicity and being to the point, the project weʼll build in this book will be a simple, yet powerful, one
that showcases the possibilities of Bluetooth Low Energy and how it relates to you, the reader, in your own personal
environment as well.

Project and System Components

Note: To get the most benefit from the book — especially in terms of practical knowledge and going from theory to
implementation — make sure you have access to all the hardware components listed for the main project.

8
 Figure 1: Main project system diagram

The components, hardware, and environment required for the project include:

A computer for development (all three operating systems are supported: macOS, Windows, and Linux).
A mobile phone for connecting to the Nordic nRF Cloud (to run the iOS app or Android app).

An alternative is to use a Raspberry Pi 3 for connecting to nRF Cloud — for instructions refer to this article and this
one.

Two nRF52 Development Boards

Weʼll be using two nRF52840 development kits. Alternatively, the nRF52832 development kit could be used but
will not be able to utilize the Bluetooth 5 long range feature (LE Coded PHY) in any examples that utilize this
feature. Additionally, the project files included alongside the book only support the nRF52840 — they would need
to be modified to build for the nRF52832 instead.

9
 Figure 2: nRF52840 development kit

Thingy:52 IoT Sensor Kit

From Nordic's product page for the Thingy:52:

The Nordic Thingy:52® is a compact, power-optimized, multi-sensor development kit. It is an easy-to-use

development platform, designed to help you build IoT prototypes and demos, without the need to build
hardware or write firmware.

Figure 3: Nordic Thingy:52 sensor kit

Playbulb Candle

Any Bluetooth lightbulb may be used. However, the steps for reverse-engineering the protocol used by the device
will probably differ from the exercises provided in the book.

10
 Figure 4: Playbulb candle Bluetooth light bulb

A USB power plug (used to power one of the nRF52 development kits — the Gateway device), or simply
connected to a PC

A coin cell battery (CR2032)

An Internet connection for connecting to the nRF Cloud service

An nRF Cloud account

User Scenarios

When you start work on a project — whether it is a commercial or a simple hobby project — it is good practice to
describe it from the userʼs perspective. This allows you to put yourself in their shoes, think of the system use cases at
a high-level, and achieve the best user experience.

Letʼs go ahead and describe the main user scenarios for our home automation system:

k. The homeowner can use a remote control device to turn on/off the Playbulb candlelight.
Technical details: The remote device is one of the nRF52 development kits — the one powered by a coin cell

11
 battery.

l. The homeowner can monitor changes in the temperature in the area where the environment sensor is placed —
via connecting to the Gateway (directly from a smartphone or via the nRF Cloud service).

In my testing and development, I used the garage as the environment for placing the sensor, so you may come
across the word "garage" in the terminology. This is simply an example and can obviously be changed to anything
else.In the Main Project source code in the companion GitHub repository (refer to the chapter titled "GitHub
Repository"),

Technical details: The Gateway device will have notifications turned on for the temperature characteristic on the
Thingy:52 device that is placed in an area of interest.

m. The homeowner can monitor changes in the humidity in the area where the environment sensor is placed — via
connecting to the Gateway directly (from a BLE Central, or via the Cloud service).

Technical detail: The Gateway device will have notifications turned on for the humidity characteristic on the
Thingy:52 device that is placed in an area of interest.

n. The homeowner is notified of the battery levels of the Remote Control, Playbulb candlelight, and Thingy:52.

Technical detail: The Gateway device will have notifications enabled on the battery level characteristics of the
Remote Control, Playbulb candlelight, and the Thingy:52.

Hardware Components

Gateway device (implemented on the nRF52840 development kit)

Simultaneous central and peripheral roles.
Monitors the devices in the home and receives status updates from the Remote Control, Thingy:52, and
Playbulb candlelight.
Allows data to be sent up to the nRF Cloud service.
Stationary.
Live power (via the micro USB connection on the development kit).
Remote Control device (implemented on the nRF52840 development kit)
Peripheral role only.
Used as a remote control for the Playbulb Candle light.
Coin cell battery (CR2032).
Non-stationary.
Playbulb light (off-the-shelf device)
Controlled from the Remote Control via the Gateway.
Light status changes reported to the Gateway.
Battery level reported to the Gateway.

12
 Nordic Thingy:52 (off-the-shelf device)
Used as an environment sensor to report:
Temperature reading.
Humidity reading.
Battery level.
Smartphone (connected to the nRF Cloud service)
nRF Connect Gateway application on a mobile phone that relays data up to the nRF Cloud service.

Summary

In this chapter, we went over the project that will be used as the main exercise for the book. This is simply a starting
point, though youʼll have learned a great deal about the features of Bluetooth Low Energy. You can then easily expand
the functionality and features to suit your need.

13
Basics of Bluetooth Low Energy

What is Bluetooth Low Energy?

Bluetooth started as a short-distance cable-replacement technology to replace wires in devices such as a mouse, a
keyboard, or a PC. If you own a modern car or a smartphone, chances are youʼve used Bluetooth at least once in your
life. It's everywhere: in speakers, wireless headphones, cars, wearables, medical devices, and even flip-flops!

The first official version of Bluetooth was released by Ericsson in 1994. It was named after King Harald “Bluetooth”
Gormsson of Denmark who helped unify warring factions in the 10th century CE.

There are two types of Bluetooth devices: one is referred to as Bluetooth Classic (BR/EDR), used in wireless
speakers, car infotainment systems, and headsets, and the other is Bluetooth Low Energy (BLE). BLE, introduced in
Bluetooth version 4.0, is more prominent in applications where power consumption is crucial (such as battery-
powered devices) and where small amounts of data are transferred infrequently (such as in sensor applications).

These two types of Bluetooth devices are incompatible with each other even though they share the same brand and
even specification document. A Bluetooth Classic device cannot communicate (directly) with a BLE device. This is why
some devices such as smartphones have chosen to incorporate both types of Bluetooth (also referred to as Dual
Mode Bluetooth devices), allowing them to communicate with both types of devices.

Figure 5: Types of Bluetooth devices

Here are a few important notes about BLE:

The official Bluetooth specification document combines both types of Bluetooth (Bluetooth Classic and BLE),
sometimes making it difficult to locate BLE-specific specifications.
BLE was introduced in the 4.0 version of the Bluetooth specification, released in 2010.
BLE is sometimes referred to as Bluetooth Smart or BTLE, and sometimes mistaken as Bluetooth 4.0 (since this
version really included both types of Bluetooth).
Both Bluetooth Classic and BLE operate in the same frequency spectrum (the 2.4 GHz Industrial, Scientific, and
Medical (ISM) band).

Since many Internet of Things (IoT) systems involve small devices and sensors, BLE has become the more common

14
protocol of the two (versus Bluetooth Classic) in IoT. In December 2016, the Bluetooth Special Interest Group (SIG),
the governing body behind the Bluetooth standard, released Bluetooth version 5.0 (for marketing simplicity, the point
number is removed and the official name is Bluetooth 5). A majority of the enhancements and features introduced in
this version focused on BLE, not Bluetooth Classic.

You may have also heard of another term related to Bluetooth: Bluetooth mesh. Bluetooth mesh was released in July
2017. It builds on top of BLE and it requires a complete BLE stack (a software that acts as an interface for another
piece of software or hardware) to work, but itʼs not part of the core Bluetooth specification.

To summarize, here's a figure showing the progression of BLE over the years:

Figure 6: History of BLE

15
Technical Facts About BLE

Some of the most important technical facts about BLE include:

The frequency spectrum occupied is 2.400 - 2.4835 GHz.

The frequency spectrum is segmented into 40 “2 MHz”-wide channels.
The maximum data rate supported by the radio (introduced in Bluetooth version 5) is 2 Mbps.
The range varies significantly depending on the environment surrounding the communicating BLE devices as well
as the mode used (for example, in long-range mode, the range will be significantly longer than in the 2M/high-
speed mode). A typical range is 10-30 meters (30-100 feet).
Power consumption also varies widely. It depends on the implementation of the application, the different BLE
parameters, and the chipset used. The peak current consumption of a BLE chipset during radio transmission is
typically under 15 mA.
Security is optional in BLE communication, and it is up to the device and applications developers to implement it.
That said, though, there are also varying levels of security that can be implemented.
For all encryption operations, BLE uses AES CCM with a 128-bit key.
BLE is designed for low-bandwidth data transfer applications. Implementing BLE for high-bandwidth applications
will significantly compromise the low power consumption promise. So, minimizing radio usage as much as
possible achieves the optimal power consumption.
Bluetooth versions are backwards compatible with each other. However, the communication may be limited to
the features of the older version of the two communicating devices.
For example, a Bluetooth 5 BLE device can communicate with a Bluetooth 4.1 BLE device, but 5-specific features
wonʼt be supported. On the other hand, Connections, Primary Advertisements, discovering Services, discovering
Characteristics, and reading/writing to these Characteristics are all possible between two BLE devices regardless
of their supported Bluetooth version (since they were supported by the initial version of BLE).

16
Bluetooth Classic vs. BLE

Itʼs important to note that thereʼs a big difference between Bluetooth Classic and Bluetooth Low Energy in terms of
technical specification, implementation, and the types of applications to which theyʼre each suited. This is in addition
to the fact that they are incompatible with each other.

Some of the notable differences are summarized in the following table:

Bluetooth Classic BLE

Used for streaming applications such as audio Used for sensor data, control of devices, and low-
streaming, file transfers, and headsets bandwidth applications

Not optimized for low power, but has a higher data

Meant for low power, low duty data cycles
rate (3Mbps maximum compared to 2Mbps for BLE)

Operates over 79 RF (radio frequency) channels Operates over 40 RF channels.

Discovery occurs on 3 channels, leading to quicker

Discovery occurs on 32 channels
discovery and connections than Bluetooth Classic

Table 1: Bluetooth Classic vs. BLE

BLE has gone through some major revisions and changes in the short time since its official release in 2010, with the
most recent major update being Bluetooth 5 released in December 2016. Bluetooth 5 introduced many important
upgrades to the Bluetooth specification, most of which were focused on BLE. Some of the most important
enhancements include twice the speed, four times the range, and eight times the advertising data capacity.

Advantages and Limitations of BLE

Every technology has its limitations, and BLE is no exception. As we mentioned earlier, BLE is most suitable for
applications with relatively short range and infrequent low-bandwidth data transfers.

Limitations of BLE

Data Throughput

The data throughput of BLE is limited by the physical radio data rate, which is the rate at which the radio transmits
data. This rate depends on the Bluetooth version used. For Bluetooth 4.2 and earlier, the rate is fixed at 1 Mbps. For
Bluetooth 5 and later, however, the rate varies depending on the mode and PHY (discussed later in the Physical Layer
section) being used. The rate can be at 1 Mbps like earlier versions, or 2 Mbps when utilizing the high-speed feature.
When utilizing the long-range feature, the rate drops to either 500 or 125 Kbps. Weʼll discuss each of these in more

17
detail in the section on Bluetooth 5.

At the application layer and for the end-user, the data rate is much lower than the radio data rate due to the following
factors:

Gaps in between packets: The Bluetooth specification defines a gap of 150 microseconds between packets being
transmitted as a requirement for adhering to the specification. This gap is time lost with no data being exchanged
between two devices.
Packet overhead: All packets include header information and data handled at levels lower than the application
level, which count towards the data being transmitted but are not part of the data utilized by your application.
Slave data packets requirement: The requirement to send back data packets from the slave, even when no data
needs to be sent back and empty packets are sent.
Retransmission of data packets: In the case of packet loss or interference from devices in the surrounding
environment, the lost or corrupted data packets get resent by the sender.

Range

BLE was designed for short range applications and hence its range of operation is limited. There are a few factors that
limit the range of BLE including:

It operates in the 2.4 GHz ISM spectrum which is greatly affected by obstacles that exist all around us such as
metal objects, walls, and water (especially human bodies).
Performance and design of the antenna of the BLE device.
Physical enclosure of the device which affects the antenna performance, especially if itʼs an internal antenna.
Device orientation, which effectively relates to the positioning of the antenna (e.g., in smartphones).

Gateway Requirement for Internet Connectivity

In order to transfer data from a BLE-only device to the Internet, another BLE device that has an IP connection is
needed to receive this data and then, in turn, relay it to another IP device (or to the internet).

Advantages of BLE

Even with the previously mentioned limitations of BLE, it has presented some significant advantages and benefits over
other similar technologies in the IoT space. Some of these advantages include:

Lower power consumption

Even when compared to other low-power technologies, BLE achieves a lower power consumption than its
competitors. It's optimized, and less power consumed, by turning the radio off as much as possible, in addition to
sending small amounts of data at low transfer speeds.
No cost to access the official specification documents
With most other wireless protocols and technologies, you would have to become a member of the official group or

18
 consortium for that standard in order to access the specification. Becoming a member of those groups can cost a
significant amount (up to thousands of dollars per year). With BLE, the major version (4.0, 4.1, 4.2, 5) specification
documents are available to download from the Bluetooth website for free.
Lower cost of modules and chipsets when compared to other similar technologies.
Last but not least, its existence in most smartphones in the market. This is probably the biggest advantage BLE
has over its competitors such as ZigBee, Z-Wave, and Thread.

Applications Most Suitable for BLE

Based on the limitations and benefits we mentioned earlier, there are a number of use cases where BLE makes the
most sense:

Low-bandwidth data
For cases where a device transfers small amounts of data representing sensor data or for controlling actuators,
BLE has proven to be a suitable wireless protocol to utilize.
Device Configuration
Even in cases where BLE doesnʼt satisfy the main requirements of a system, it can still be used as a secondary
interface to configure a device before the main wireless connection is established.
For example, some WiFi-enabled devices are adding BLE as a means to configure and establish the WiFi
connection of the device instead of using a technology such as WiFi direct (a technology that allows two WiFi
devices to connect directly without going through a WiFi router. You can Learn more about it at its Wikipedia page
here).
Using a smartphone as an interface
Small, low-power devices usually donʼt have large screens and are only capable of displaying limited amounts of
data to the end user. Due to the proliferation of smartphones nowadays, BLE can be utilized to offer an alternate,
much richer user interface to these small devices (even if just for this sole purpose). Another by-product benefit
of using a smartphone is that the data can be relayed up to the cloud.
Personal and wearable devices
For use cases where a device is portable and can be located in areas where no other persistent wireless
connections exist (such as WiFi), BLE can be used (since itʼs a direct peer-to-peer connection).
Broadcast-only devices
Youʼve probably heard of, and maybe seen, Beacon devices before. These devices have one simple task: to
broadcast data so other devices may discover them and read their data. There are other technologies that have
been used for this kind of application. However, BLE is becoming more and more popular because most people
carry smartphones which already support BLE out-of-the-box.

These are all great use cases that could benefit from utilizing BLE. On the other hand, use cases that are not
(generally) suitable for BLE include:

Video streaming.
High-quality audio streaming.
Large data transfers for prolonged periods of time (if battery consumption is a concern).

19
Architecture of BLE

The following figure shows the different layers within the architecture of BLE. The three main blocks in the
architecture of a BLE device are: the application, the host, and the controller.

Figure 7: Architecture of BLE

In this book, weʼll focus on the upper level layers of the architecture, while briefly covering the lower levels of the
architecture. Weʼll go over each of the lower-level layers in this chapter and then look at each of the upper layers (the
Generic Access Profile, the Generic Attribute Profile, the Attribute Protocol, and the Security Manager) each in
their own chapter.

Application

The application layer is use-case dependent and refers to the implementation on top of the Generic Access Profile
and Generic Attribute Profile — itʼs how your application handles data received from and sent to other devices and the
logic behind it.

20
This portion is the code that you would write for your specific BLE application and is generally not part of the BLE
stack for the platform which you develop. This part will not be covered in the book, since it depends on the specifics
of your application and use case.

Host

The host contains the following layers:

Generic Access Profile (GAP)

Generic Attribute Profile (GATT)
Attribute Protocol (ATT)
Security Manager (SM)
Logical Link Control and Adaptation Protocol (L2CAP)
Host Controller Interface (HCI) — Host side

Controller

The controller contains the following layers:

Physical Layer (PHY)

Link Layer
Direct Test Mode
Host Controller Interface (HCI) — Controller side

Layers of the BLE Architecture

Physical Layer (PHY)

The physical layer (PHY) refers to the radio hardware used for communication and for modulating/de-modulating the
data. BLE operates in the ISM band (2.4 GHz spectrum), which is segmented into 40 RF channels, each separated by
2 MHz (center-to-center), as shown in the following figure:

21
 Figure 8: Frequency spectrum and RF channels in BLE

Three of these channels are called the Primary Advertising Channels, while the remaining 37 channels are used for
Secondary Advertisements and for data transfer during a connection. Weʼll cover these concepts in detail in the
chapter titled “Advertising and Scanning”, but letʼs briefly cover the concepts here.

Advertising always starts with advertisement packets being sent on the three Primary Advertising Channels (or a
subset of these channels). This allows the devices scanning for advertisers to find them and read their
advertisement data. The scanner can then initiate a connection if the advertiser allows it. It can also request whatʼs
called a scan request, and if the advertiser supports this scan request functionality, it will respond with a scan
response. Scan requests and scan responses allow the advertiser to send additional advertisement data to devices
that are interested in receiving this data.

Here are some other important technical details pertaining to the Physical Radio:

It uses Frequency Hopping Spread Spectrum (FHSS), which allows the two communicating devices to switch to
randomly (agreed-on) selected frequencies for exchanging data. This greatly improves reliability and allows the
devices to avoid frequency channels that may be congested and used by other devices in the surrounding
environment.

The transmission power levels are:

Maximum: 100mW (+20 dBm) for version >= 5, 10mW (+10 dBm) for version <= 4.2
Minimum: 0.01 mW (-20 dBm)

In older versions of Bluetooth (4.0, 4.1, and 4.2), the data rate was fixed at 1 Mbps. The physical layer radio (PHY)
in this case is referred to as the 1M PHY and is mandatory in all versions including Bluetooth 5. With Bluetooth 5,
however, two new optional PHYs were introduced:

2Mbps PHY, used to achieve twice the speed of earlier versions of Bluetooth.
Coded PHY, used for longer range communication.

Note: Weʼll be covering these two new PHYs as well as the concept of coding in more detail in the chapter on
Bluetooth 5.

Link Layer

The link layer is the layer that interfaces with the physical layer (radio) and provides the higher-level layers an
abstraction and a way to interact with the radio (through an intermediary level called the HCI layer which weʼll discuss
shortly). It is responsible for managing the state of the radio as well as the timing requirements necessary for
satisfying the BLE specification. It is also responsible for managing hardware accelerated operations such as: CRC,
random number generation, and encryption.

The three main states in which a BLE device operates in are:

The Advertising state

22
 The Scanning state
The Connected state

When a device advertises, it allows other devices that are scanning to find the device and possibly connect to it. If the
advertising device allows connections and a scanning device finds it and decides to connect to it, they each enter
into the connected state. The link layer manages the different states of the radio, shown in the following figure:

Figure 9: Link layer states

(Source: Bluetooth 5.0 specification document)

Standby: the default state in which the radio does not transmit or receive any data.
Advertising: the state in which the device sends out advertising packets for other devices to discover and read.
Scanning: the state in which the device scans for devices that are Advertising
Initiating: the state in which a scanning device decides to establish a connection with a device that is advertising.
Connected: the state in which a device has an established link with another device and regularly exchanges data
with this other device. This applies to both a device that was in the advertising state or one that was scanning for
advertisements and then decided to initiate a connection with the advertising device. In this connected state, the
device that initiates the connection is called the master, and the device that was advertising is now called the

23
 slave.

Weʼll be covering advertising, scanning, and connected states in more detail in the later chapters.

Bluetooth Address

Bluetooth devices are identified by a 48-bit address, similar to a MAC address. There are two main types of
addresses: Public Addresses and Random Addresses.

Public Address

This is a fixed address that does not change and is factory-programmed. It must be registered with the IEEE (similar to
a WiFi or Ethernet device MAC address).

Random Address

Since manufacturers have a choice on what type of address to use (Random vs. Public), Random addresses are more
popular since they do not require registration with the IEEE. A random address is programmed on the device or
generated at runtime. It can be one of two sub-types:

Static Address
Used as a replacement for Public addresses.
Can be generated at boot up OR stay the same during lifetime.
Cannot change until a power cycle.
Private Address
This one is also split up into two additional sub-types:
Non-resolvable Private Address:
Random, temporary for a certain time.
Not commonly used.
Resolvable Private Address:
Used for privacy.
Generated using Identity Resolving Key (IRK) and a random number.
Changes periodically (even during the lifetime of the connection).
Used to avoid being tracked by unknown scanners
Trusted devices (or Bonded, which is described later in the chapter on Security) can resolve it using the
previously stored IRK.

Direct Test Mode

Direct Test Mode (DTM) is only needed for performing RF tests and used during manufacturing and for certification
tests. This layer is beyond the scope of this book, so we wonʼt get into it in any detail.

24
Host Controller Interface (HCI) Layer

The HCI layer is a standard protocol defined by the Bluetooth specification that allows the host layer to communicate
with the controller layer. These layers could exist in separate chipsets, or they could exist in the same chipset. In this
sense, it also allows interoperability between chipsets, so a device developer can choose two Bluetooth certified
devices, a controller and a host, and be 100% confident that they are compatible with each other in terms of
communication between the host and controller layers.

In the case where the host and controller are in separate chipsets, the HCI layer will be implemented over a physical
communication interface. The three officially supported hardware interfaces by the spec are: UART, USB, and SDIO
(Secure Digital Input Output). In the case where the two layers (host and controller) live on the same chipset, the HCI
layer will be a logical interface instead.

The job of the HCI layer is to relay commands from the host down to the controller and send events back up from the
controller to the host. Following is an example of a capture of HCI commands, HCI events, and ATT commands being
exchanged between the host and controller layers:

Figure 10: Capture of HCI packets

Examples of the messages include: command packets, configuring the controller, requesting actions, controlling the
connection and connection parameters, event packets, command completion and status events.

Logical Link Control and Adaptation Protocol (L2CAP) Layer

The Logical Link Control and Adaptation Protocol (L2CAP) layer acts as a protocol-multiplexing layer. It is borrowed
from the Bluetooth Classic standard, and performs the following tasks in the case of BLE:

Takes multiple protocols from the upper layers and places them in standard BLE packets that are passed down to
the lower layers beneath it.
Handles fragmentation and recombination. It takes the larger packets from the upper layers and splits them into
chunks that fit into the maximum BLE payload size supported for transmission. On the receiver side, it takes

25
 multiple packets and combines them into one packet that can be handled by the upper layers.

For BLE, the L2CAP layer handles two main protocols: the Attribute Protocol (ATT) (covered in the chapter on GATT),
and the Security Manager Protocol (SMP) (covered briefly in the chapter on Security).

Upper Level Layers

The Attribute Protocol (ATT), Generic Attribute Profile (GATT), Security Manager (SM) and Generic Access Profile
(GAP) will all be covered in detail in the following chapters.

26
BLE Peripherals and Centrals
There are a few important terms that youʼll come across while learning about BLE. Two of the most important are: BLE
central and BLE peripheral. These two terms relate to the role of a BLE device, but they can be confusing sometimes.
Letʼs go over each of these terms in a bit more detail.

Peripherals

A peripheral device is a device that announces its presence by sending out advertising packets and accepts a
connection from another BLE device (the BLE central — which will be explained shortly). Another related term is a BLE
broadcaster. A broadcaster is a device that sends out advertising packets as well, but with one difference from a
peripheral: the broadcaster does not allow a connection from a central device. On the other hand, an observer device
only discovers advertising devices, but does not have the capability to initiate a connection with the advertiser.

A typical example of an application that involves a broadcaster is in Beacon technologies. Beacons are devices that
have the sole purpose of advertising and broadcasting their existence, while not accepting connections from other
devices. They are becoming popular in two main use cases: retail marketing and indoor location services.

For example, some department stores utilize a smartphone app that can detect Beacons in certain locations within the
store. If a customer who has the storeʼs app installed on their smartphone (and has enabled location services)
approaches a Beacon, the app displays a special offer to the customer on their phone.

The way a Broadcaster is differentiated from a peripheral device is by the advertising packets that get transmitted by
the device. There are different types of advertising packets: some indicate the capability to accept a connection and
others are simply for broadcasting presence. When the BLE central discovers the advertising packets of another BLE
device (whether broadcaster or peripheral), it knows whether it can initiate a connection or not based on the type of
advertising packets.

Once a peripheral gets connected to a BLE central, it also becomes known as the slave in that connection. The central
device, in this case, gets called the master. These are roles defined within the link layer, whereas the peripheral and
central roles are defined within the GAP layer.

Centrals

Weʼve briefly mentioned the BLE Central, but to formally define it: A Central is a device that discovers and listens to
other BLE devices that are advertising. It is also capable of establishing a connection to BLE peripherals (usually
multiple at the same time).

An Observer, on the other hand, is a similar type of BLE device, but one that is not capable of initiating a connection
with a peripheral device.

27
Observers and Broadcasters vs. Centrals and Peripherals

Letʼs go over some advantages and disadvantages of the four different types of device: Observers, Broadcasters,
Centrals, and Peripherals.

Broadcaster Peripheral Observer Central

Needs both a Needs both a

No need for a radio
receiver and No need for a transmitter receiver and
receiver
transmitter transmitter

Supports bi- Supports bi-

No bi-directional data No bi-directional data
directional data directional data
transfer transfer
transfer transfer

Reduced hardware, Reduced hardware,

Requires the full BLE Requires the full BLE
reduced BLE software reduced BLE software
software stack software stack
stack stack

Table 2: Comparison between Observers, Broadcasters, Peripherals, and Centrals

Power Consumption and Processing Power Considerations

BLE is asymmetrical by design. Much of the heavy lifting regarding connection management, time management, and
processing responsibilities lies on the central side. This helps reduce power consumption and processing power
requirements on the peripheral side, thus, making it possible to integrate BLE into smaller and more resource-
constrained devices (e.g., battery-powered devices).

A BLE central device can still be battery powered, but will usually have a relatively large battery thatʼs rechargeable.
Most commonly, in a BLE system, the central device is a smartphone, tablet, or a computer.

A central device also supports connecting to multiple Peripherals at the same time. A typical example of this is a
smartphone that maintains a connection to a smartwatch, a smart-home thermostat, and a fitness tracker, all at the
same time.

Multi-Role BLE Devices

In some use cases, a BLE device would benefit from acting in multiple roles simultaneously. For example, a device may
want to monitor multiple sensors (peripheral devices), and at the same time be able to advertise its presence to a
smartphone to allow access to sensor data from a mobile app interface.

28
 Figure 11: Multiple roles in BLE

The Role of Smartphones in BLE

One of the biggest advantages of BLE over other competing low-power wireless technologies (such as ZigBee, Z-
Wave, Thread, etc.) is its existence in the majority of smartphones in the market. Most (if not all) smartphones already
included Bluetooth Classic since the very early days, and most Bluetooth chipset vendors are now integrating BLE
support along with Bluetooth Classic in their chipsets. The result is that the vast majority of smartphones nowadays
support BLE.

Having the capability for a smartphone to interact and connect to BLE devices provides a couple of significant
advantages:

Smartphones provide a familiar user interface for consumers, offering a rich user experience when using a mobile
app to interface with a BLE device (compared to interfacing with the BLE device directly).
Smartphones are usually connected to the Internet. This means that the data transmitted from the BLE device can
be sent up to the cloud and stored somewhere else for later access or analysis.

Challenges with BLE Development on Smartphones

There are two major mobile operating systems: Android and iOS. Android introduced native support for BLE APIs in
Android 4.3 (released July 2012), while iOS provided native BLE support a bit earlier in iOS 5 (released October 2011).

One important thing to note is that this also depends on the hardware running the operating system. For iOS, this
included all iOS devices starting with the iPhone 4s. For Android, itʼs a completely different story: Android runs on
devices manufactured by many different vendors, so thereʼs no easy way to determine which devices first started
supporting BLE. This Android fragmentation problem introduces a big challenge with developing Android BLE
applications that behave consistently across the dozens of existing Android phones.

29