Introduction - Getting Started with Bluetooth Low Energy (2014)

Getting Started with Bluetooth Low Energy (2014)

Chapter 1. Introduction

Bluetooth Low Energy (BLE, also marketed as Bluetooth Smart) started as part of the Bluetooth 4.0 Core Specification. It’s tempting to present BLE as a smaller, highly optimized version of its bigger brother, classic Bluetooth, but in reality, BLE has an entirely different lineage and design goals.

Originally designed by Nokia as Wibree before being adopted by the Bluetooth Special Interest Group (SIG), the authors weren’t trying to propose another overly broad wireless solution that attempts to solve every possible problem. From the beginning, the focus was to design a radio standard with the lowest possible power consumption, specifically optimized for low cost, low bandwidth, low power, and low complexity.

These design goals are evident through the core specification, which attempts to make BLE a genuine low-power standard, designed to actually be implemented by silicon vendors and used in the real world on a tight energy and silicon budget. It might be the first widely adopted standard that can realistically lay claim to running for an extended period of time off a humble coin cell, though many other wireless technologies regularly make that claim in their marketing.

What Makes BLE Different

While Bluetooth Low Energy is a good technology on its own merit, what makes BLE genuinely exciting—and what has pushed its phenomenal adoption rate so far so quickly—is that it’s the right technology, with the right compromises, at the right time. For a relatively young standard (it was introduced in 2010), BLE has seen an uncommonly rapid adoption rate, and the number of product designs that already include BLE puts it well ahead of other wireless technologies at the same point of time in their release cycles.

Compared to other wireless standards, the rapid growth of BLE is relatively easy to explain: BLE has gone further faster because its fate is so intimately tied to the phenomenal growth in smartphones, tablets, and mobile computing. Early and active adoption of BLE by mobile industry heavyweights like Apple and Samsung broke open the doors for wider implementation of BLE.

Apple, in particular, has put significant effort into producing a reliable BLE stack and publishing design guidelines around BLE. This, in turn, pushed silicon vendors to commit their limited resources to the technology they felt was the most likely to succeed or flourish in the long run, and the Apple stamp of approval is clearly a compelling argument when you need to justify every research and development dollar invested.

While the mobile and tablet markets become increasingly mature and costs and margins are decreasing, the need for connectivity with the outside world on these devices has a huge growth potential, and it offers peripheral vendors a unique opportunity to provide innovative solutions to problems people might not even realize that they have today.

So many benefits have converged around BLE, and the doors have been opened wide for small, nimble product designers to gain access to a potentially massive market with task-specific, creative, and innovative products on a relatively modest design budget. You can purchase all-in-one radio-plus-microcontroller (system-on-chip) solutions today for well under $2 per chip and in low volumes, which is well below the total overall price point of similar wireless technologies such as WiFi, GSM, Zigbee, etc. And BLE allows you to design viable products today that can talk to any modern mobile platform using chips, tools, and standards that are easy to access.

Perhaps one of the less visible key factors contributing to the success of BLE is that it was designed to serve as an extensible framework to exchange data. This is a fundamental difference with classic Bluetooth, which focused on a strict set of use cases. BLE, on the other hand, was conceived to allow anyone with an idea and a bunch of data points coming from an accessory to realize it without having to know a huge amount about the underlying technology. The smartphone vendors understood the value of this proposition early on, and they provided flexible and relatively low-level APIs to give mobile application developers the freedom to use the BLE framework in any way they see fit.

Devices that talk to smartphones or tablets also offer another easy-to-underestimate advantage for product designers: they have an unusually low barrier to adoption. Users are already accustomed to using the handsets or tablets in their possession, which means the burden of learning a new UI is limited, as long as we respect the rich visual language that people have grown accustomed to in the platforms they use.

With a relatively easy-to-understand data model, no intrusive licensing costs, no fees to access the core specs, and a lean overall protocol stack, it should be clear why platform designers and mobile vendors see a winner in BLE.

The Specification

In June 2010, the Bluetooth SIG introduced Bluetooth Low Energy with version 4.0 of the Bluetooth Core Specfication. The specification had been several years in the making and most of the controversial sections and decisions were finally ironed out by the companies involved in the development process, with a few additional concerns left to be dealt with in subsequent updates of the specification.

The first such major update, Bluetooth 4.1, was released in December 2013 and is the current reference for anyone looking to develop BLE products. Althought the basic building blocks, procedures, and concepts remained intact, this release also introduced multiple changes and improvements to smooth the experience of the user.

As with all Bluetooth specifications, 4.1 is backwards compatible with 4.0, ensuring the correct interoperability among devices implementing different specification versions. The specifications allow developers to release and qualify products against either of the versions (until deprecated), although the rapid adoption of new specification releases and the fact that the 4.1 version standardizes several common practices among devices makes it recommendable to target the latest available one.

Unless otherwise noted, this book uses the Bluetooth 4.1 specification as reference. Wherever necessary, and especially when mentioning a noteworthy change or addition, we will clarify when the previous 4.0 specification does not cover a particular area.

To obtain the latest adopted version of the Bluetooth specification, see the Bluetooth SIG’s Specification Adopted Documents page.

Configurations

The Bluetooth specification covers both classic Bluetooth (the well-known wireless standard that has been commonplace in many consumer devices for a number of years now) and Bluetooth Low Energy (the new, highly optimized wireless standard introduced in 4.0). Those two wireless communication standards are not directly compatible and Bluetooth devices qualified on any specification version prior to 4.0 cannot communicate in any way with a BLE device. The on-air protocol, the upper protocol layers, and the applications are different and incompatible between the two technologies.

Based on Specification Support

Table 1-1 shows the wireless technologies implemented for the three main device types on the market today.

Table 1-1. Specification configurations

!

Device

BR/EDR (classic Bluetooth) support

BLE (Bluetooth Low Energy) support

Pre-4.0 Bluetooth

Yes

No

4.x Single-Mode (Bluetooth Smart)

No

Yes

4.x Dual-Mode (Bluetooth Smart Ready)

Yes

Yes

As you can see, the Bluetooth Specification (4.0 and above) defines two wireless technologies:

BR/EDR (classic Bluetooth)

The wireless standard that has evolved with the Bluetooth Specification since 1.0.

BLE (Bluetooth Low Energy)

The low-power wireless standard introduced with version 4.0 of the specification.

And these are the two device types that be used with these configurations:

Single-mode (BLE, Bluetooth Smart) device

A device that implements BLE, which can communicate with single-mode and dual-mode devices, but not with devices supporting BR/EDR only.

Dual-mode (BR/EDR/LE, Bluetooth Smart Ready) device

A device that implements both BR/EDR and BLE, which can communicate with any Bluetooth device.

Figure 1-1 shows the configuration possibilities between available Bluetooth versions and device types, along with the protocol stacks that allow these devices to communicate with each other.

Configurations between Bluetooth versions and device types

Figure 1-1. Configurations between Bluetooth versions and device types

More and more BR/EDR devices entering the market include BLE as well, and the trend is expected to continue as single-mode BLE sensors become more ubiquitous. Those dual-mode devices can forward the data obtained from a single-mode BLE device to the internet using their GSM or WiFi radios, a feature that is becoming more and more common as more BLE sensors enter the market.

Based on Chip Count

Chapter 2 introduces and discusses the several protocol layers that constitute the Bluetooth protocol stack, but for now it suffices to outline the three main building blocks of every Bluetooth device:

Application

The user application interfacing with the Bluetooth protocol stack to cover a particular use case.

Host

The upper layers of the Bluetooth protocol stack.

Controller

The lower layers of the Bluetooth protocol stack, including the radio.

Additionally, the specification provides a standard communications protocol between the host and the controller—the Host Controller Interface (HCI)—to allow interoperability between hosts and controllers produced by different companies.

These layers can be implemented in a single integrated circuit (IC) or chip, or they can be split in several ICs connected through a communication layer (UART, USB, SPI, or other).

These are the three most common configurations found in commercially available products today:

SoC (system on chip)

A single IC runs the application, the host, and the controller.

Dual IC over HCI

One IC runs the application and the host and communicates using HCI with a second IC running the controller. The advantage of this approach is that, since HCI is defined by the Bluetooth specification, any host can be combined with any controller, regardless of the manufacturer.

Dual IC with connectivity device

One IC runs the application and communicates using a propietary protocol with a second IC running both the host and the controller. Since the specification does not include such a protocol, the application must be adapted to the specific protocol of the chosen vendor.

Figure 1-2 shows the various hardware configurations with the layers of the Bluetooth protocol stack.

Hardware configurations

Figure 1-2. Hardware configurations

Simple sensors tend to use SoC configurations to keep the cost and printed circuit board (PCB) complexity low, whereas smartphones and tablets usually opt for the Dual IC over HCI configuration because they usually already have a powerful CPU available to run the protocol stack. The Dual IC with connectivity device configuration is used in other scenarios, one of which could be a watch with a specialized microcontroller to which BLE connectivity is added without overhauling the whole design.

Key Limitations

Like all things in engineering, good design is all about making the right tradeoffs, and Bluetooth Low Energy is no different. BLE doesn’t attempt to be a solution to every wireless data transfer need, and classic Bluetooth, WiFi, NFC, and other wireless technologies clearly still have their place, with their own unique set of design tradeoffs and decisions.

To help understand what BLE is (and isn’t), it’s useful to recognize its key limitations (as defined in the Bluetooth 4.0 specification and later) and how these limitations translate into real-world products.

Data Throughput

The modulation rate of the Bluetooth Low Energy radio is set by the specification at a constant 1Mbps. This sets the theoretical upper limit for the throughput that BLE can provide, but in actual terms, this limit is typically lowered significally by a variety of factors, including but not restricted to bidirectional traffic, protocol overhead, CPU and radio limitations, and artificial software restrictions.

To illustrate some of these practical restrictions, consider the following basic preconditions we’ll use for a calculation:

§ A central (master) device has initiated and established a connection with a peripheral (slave) accessory.

§ While in an active connection, the specification defines the connection interval to be the interval between two consecutive connection events (a data exchange before going back to an idle state to save power), and this connection interval can be set to a value between 7.5 ms and 4 s.

Link Layer and Roles discuss the different roles within a connection in detail. For this example, we’ll use the nRF51822, a widely available SoC (system on chip) BLE IC manufactured by Nordic Semiconductor that is used in a variety of BLE accessories on the market. Nordic’s radio hardware and BLE stack impose the following data throughput limitations:

§ The nRF51822 can transmit up to six data packets per connection interval (limited by the IC).

§ Each outgoing data packet can contain up to 20 bytes of user data (set by the specification unless higher packet sizes are negotiated).

Assuming the shortest connection interval (the frequency at which the master and the slave exchange packets, described in Connections) of 7.5 ms, this provides a maximum of 133 connection events (a single packet exchange between the two peers) per second and 120 bytes per connection event (6 packets * 20 user bytes per packet). Continuously transmitting at the maximum data rate of the nRF51822 would suggest the following real-world calculation:

133 connection events per second * 120 bytes = 15960 bytes/s

or ~0.125Mbit/s (~125kbit/s)

That’s already significantly lower than the theoretical maximum of BLE, but the peer device you are pushing data to (typically a smart device such as a smartphone or a tablet) can add further limitations.

Your smartphone or tablet might also be busy talking to other devices, and vendor-implemented BLE stacks inevitably have their own limitations, which means the central device might not actually be able to handle data at the maximum data rate either. And because of multiple other factors, the actual connection interval might be spread out further or more irregularly than you had originally planned.

So, in practice, a typical best-case scenario should probably assume a potential maximum data throughpout in the neighborhood of 5-10 KB per second, depending on the limitations of both peers. This should give you an idea of what you can and can’t do with Bluetooth Low Energy in terms of pushing data out to your phone or tablet and explain why other technologies such as WiFi and classic Bluetooth still have their place in the world.

RACING TO IDLE

In a world where things usually get faster with time, 10 KB/s might seem slow and counterproductive, but it does highlight the primary design goal of Bluetooth Low Energy: low energy! Even transmitting at these relatively modest data rates, 10 KB/s will quickly drain any small coin cell battery, and the Bluetooth SIG made a clear, conscious effort not to design yet another generic wireless protocol and slap the label low power on it. Instead, they wanted to design the lowest power protocol possible, optimizing in every way possible to acheive that goal. The easiest way to avoid consuming precious battery power is to turn the radio off as often as possible and for as long as possible, and that is achieved by using short burst of packets (during a connection event) at a certain frequency (determined by the connection interval). In between those, the radio is simply powered off.

This means low amounts of data transmitted in short bursts, with connection intervals spread as far apart as possible to save battery life. The user-selectable 7.5 ms–4 s connection interval offers a sufficiently wide window to allow product designers to make the right tradeoff between responsiveness (a short connection interval) and battery life (a longer connection interval), without straying to far from the narrow design goals behind BLE.

Operating Range

The actual range of any wireless device depends on a wide variety of factors (operating environment, antenna design, enclosure, device orientation, etc.) but Bluetooth Low Energy is unsurprisingly focused on very short-range communication.

Transmit power (typically measured in dBm) is usually configurable over a certain range (usually between -30 and 0 dBm), but the higher the transmit power (better range), the more demands are placed on the battery, reducing the usable lifetime of the battery cell(s).

It’s possible to create and configure a BLE device that can reliably transmit data 30 meters or more line-of-sight, but a typical operating range is probably closer to 2 to 5 meters, with a conscious effort to reduce the range and save battery life without the transmission distance becoming a nuisance to the end user.

Network Topology

A Bluetooth Low Energy device can communicate with the outside world in two ways: broadcasting or connections. Each mechanism has its own advantages and limitations, and they are both subject to the guidelines established by the Generic Access Profile (GAP), which Chapter 3describes in detail.

Broadcasting and Observing

Using connectionless broadcasting, you can send data out to any scanning device or receiver in listening range. As illustrated in Figure 1-3, this mechanism essentially allows you to send data out one-way to anyone or anything that is capable of picking up the transmitted data.

Broadcast topology

Figure 1-3. Broadcast topology

Broadcasting defines two separate roles:

Broacaster

Sends nonconnectable advertising packets periodically to anyone willing to receive them.

Observer

Repeatedly scans the preset frequencies to receive any nonconnectable advertising packets currently being broadcasted.

Broadcasting is important to understand, because it’s the only way for a device to transmit data to more than one peer at time. You broadcast data out by taking advantage of the the advertising features of BLE, as discussed in more detail in Advertising and Scanning and Broadcast and Observation.

The standard advertising packet contains a 31-byte payload used to include data that describes the broadcaster and its capabilities, but it can also include any custom information you want to broadcast to other devices. If this standard 31-byte payload isn’t large enough to fit all of the required data, BLE also supports an optional secondary advertising payload (called the Scan Response), which allows devices that detect a broadcasting device to request a second advertising frame with another 31-byte payload, for up to 62 bytes total.

Broadcasting is fast and easy to use, and it’s a good choice if you want to push only a small amount of data on a fixed schedule or to multiple devices. Chapter 9 provides a practical example of BLE’s connectionless broadcasting in action with iBeacon.

A major limitation of broadcasting, when compared to a regular connection, is that there are no security or privacy provisions at all with it (any observer device is able to receive the data being broadcasted), so it might not be suited for sensitive data.

Connections

If you need to transmit data in both directions, or if you have more data than the two advertising payloads can accomodate, you will need to use a connection. A connection is a permanent, periodical data exchange of packets between two devices. It is therefore inherently private (the data is sent to and received by only the two peers involved in a connection, and no other device unless it’s indiscriminately sniffing). Connections provides more information about connections at the lower level, and Roles discusses the corresponding GAP roles.

Connections involve two separate roles:

Central (master)

Repeatedly scans the preset frequencies for connectable advertising packets and, when suitable, initates a connection. Once the connection is established, the central manages the timing and initiates the periodical data exchanges.

Peripheral (slave)

A device that sends connectable advertising packets periodically and accepts incoming connections. Once in an active connection, the peripheral follows the central’s timing and exchanges data regularly with it.

To initiate a connection, a central device picks up the connectable advertising packets from a peripheral and then sends a request to the peripheral to establish an exclusive connection between the two devices. Once the connection is established, the peripheral stops advertising and the two devices can begin exchanging data in both directions, as shown in Figure 1-4.

Connected topology

Figure 1-4. Connected topology

A connection is therefore nothing more than the periodical exchange of data at certain specific points in time (connection events) between the two peers involved in it. It is important to note that, although the central is the device that manages the connection establishment, data can be sent independently by either device during each connection event, and the roles do not impose restrictions in data throughput or priority.

Beginning with version 4.1 of the specification, any restrictions on role combinations have been removed, and the following are all possible:

§ A device can act as a central and a peripheral at the same time.

§ A central can be connected to multiple peripherals.

§ A peripheral can be connected to multiple centrals.

Previous versions of the specification limited the peripheral to a single central connection (although not conversely) and limited the role combinations.

The biggest advantage of connections (when compared to broadcasting) is the ability to organize the data with much finer-grained control over each field or property through the use of additional protocol layers and, more specifically, the Generic Attribute Profile (GATT). Data is organized around units called services and characteristics (discussed in more detail in Chapter 4).

The key thing to keep in mind is that you can have multiple services and characteristics, organized in a meaningful structure. Services can contain multiple characteristics, each with their own access rights and descriptive metadata. Additional advantages include higher throughput, the ability to establish a secure encrypted link, and negotiation of connection parameters to fit the data model.

Connections allow for a much richer, layered data model. They also have the potential to use much less power than broadcast mode because they can extend the delay between connection events further out, or push large chunks of data out only when new values are available, rather than having to continually advertise the full payload at a specific rate without knowing who is listening or how often. Not only that, but the fact that both peers know when the connection events are going to take place in the future allows the radio to be turned off for longer, potentially saving battery power when compared to broadcasting.

Finally, these topologies can be mixed freely in a wider BLE network, as shown in Figure 1-5. A BR/EDR/LE-capable device can bridge together BLE and BR/EDR connections, and the number of combinations and participants on the network is constrained only by the limitations of the radios and protocol stacks of each device taking part in it.

Mixed topology

Figure 1-5. Mixed topology

More advanced dual-mode and single-mode devices are starting to appear, devices that are able to combine multiple roles concurrently. This allows them to participate in several connections at a time, while also using advertising to broadcast data.

Protocols versus Profiles

From its inception, the Bluetooth specification introduced a clear separation between the distinct concepts of protocols and profiles:

Protocols

Building blocks used by all devices conformant to the Bluetooth specification, protocols are the layers that implement the different packet formats, routing, multiplexing, encoding, and decoding that allow data to be sent effectively between peers.

Profiles

“Vertical slices” of functionality covering either basic modes of operation required by all devices (Generic Access Profile, Generic Attribute Profile) or specific use cases (Proximity Profile, Glucose Profile), profiles essentially define how protocols should be used to achieve a particular goal, whether generic or specific.

Chapter 2 covers protocols in detail, but the following sections provide a quick introduction to profiles and what they mean for an application developer.

Generic Profiles

Generic profiles are defined by the specification, and it’s important to understand how two of them are fundamental to ensuring interoperability between BLE devices from different vendors:

Generic Access Profile (GAP)

Covering the usage model of the lower-level radio protocols to define roles, procedures, and modes that allow devices to broadcast data, discover devices, establish connections, manage connections, and negotiate security levels, GAP is, in essence, the topmost control layer of BLE. This profile is mandatory for all BLE devices, and all must comply with it.

Generic Attribute Profile (GATT)

Dealing with data exchange in BLE, GATT defines a basic data model and procedures to allow devices to discover, read, write, and push data elements between them. It is, in essence, the topmost data layer of BLE.

GAP (discussed in more detail in Chapter 3) and GATT (discussed in more detail in Chapter 4) are so fundamental to BLE that they are often used as the foundation for application programmer interfaces (APIs) as the entry point for the application to interact with the protocol stack.

Use-Case-Specific Profiles

Use-case-specific profiles in this section and elsewhere are limited to GATT-based profiles. This means that all of these profiles use the procedures and operating models of the GATT profile as a base building block for all further extensions.

No non-GATT profiles exist at the time of this writing, but the introduction of L2CAP connection-oriented channels in version 4.1 of the specification might mean that GATT-less profiles might start to appear in the future.

SIG-defined GATT-based profiles

The Bluetooth SIG goes beyond providing a solid reference framework for the topmost control and data layers of devices involved in a BLE network. Just like the USB specification, it also provides a predefined set of use-case profiles, based on GATT, that completely cover all procedures and data formats required to implement a wide range of specific use cases, including the following:

Find Me Profile

Allows devices to physically locate other devices (use a keyring to find the phone or vice versa).

Proximity Profile

Detects the presence or absence of nearby devices (beep if an item is forgotten when leaving a room).

HID over GATT Profile

Transfers HID data over BLE (keyboards, mice, remote controls).

Glucose Profile

Securely transfers glucose levels over BLE.

Health Thermometer Profile

Transfers body temperature readings over BLE.

Cycling Speed and Cadence Profile

Allows sensors on a bicycle to transfer speed and cadence data to a smartphone or tablet.

A full list of SIG-approved profiles is available at the Bluetooth SIG’s Specification Adopted Documents page. Additionally, you can browse Bluetooth services and characteristics directly at the Bluetooth Developer Portal and, more specifically, the list of all currently adopted services.

Vendor-Specific Profiles

The Bluetooth specification also allows vendors to define their own profiles for use cases not covered by the SIG-defined profiles. Those profiles can be kept private to the two peers involved in a particular use case (for example, a health accessory and a smartphone application), or they can also be published by the vendor so that other parties can provide implementations of the profile based on the vendor-supplied specification.

Some examples of the latter include Apple’s iBeacon (see iBeacon for more detail) and Apple Notification Center Service (see Apple Notification Center Service with an External Display).