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.
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.
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.
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.
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|
4.x Single-Mode (Bluetooth Smart)
4.x Dual-Mode (Bluetooth Smart Ready)
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:
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.
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 are the three most common configurations found in commercially available products today:
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.
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.
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:
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:
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.
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.
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.
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.
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:
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.
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.
Chapter 2 covers protocols in detail, but the following sections provide a quick introduction to profiles and what they mean for an application developer.
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 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.
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:
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.
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).