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.
| 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:
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.
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:
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.
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.
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 3 describes 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.
Broadcasting defines two separate roles:
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.
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.
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).
Get Getting Started with Bluetooth Low Energy now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
