Introduction to BLE

Bluetooth Low Energy (BLE) or Bluetooth Smart was introduced as part of the Bluetooth 4.0 specification It is an exciting wireless technology that gives mobile application developers unprecedented access to external hardware and provides hardware engineers with easy and reliable access to their devices from every major mobile operating system.

What Makes BLE Different

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.

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.

Device Types on The Market Today

The Bluetooth Specification (4.0 and above) defines two wireless technologies:

1. BR/EDR (Classic Bluetooth)

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

2. 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:

1. 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.

2. 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.

The below 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.

The 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.

The below figure 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 actors, 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.

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 Idl

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 achieve 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:

1. Broadcasting

2. Connections

Each mechanism has its own advantages and limitations, and they are both subject to the guidelines established by the Generic Access Profile (GAP).

Broadcasting and Observing

Using connectionless broadcasting, you can send data out to any scanning device or receiver in listening range. 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:

• Broadcaster

  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.

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.

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 accommodate, 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 involve two separate roles:

• Central (master)

  Repeatedly scans the preset frequencies for connectable advertising packets and, when suitable, initiates 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 in‐ coming 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.

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.

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. 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.

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 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 the topmost data layer of BLE.

GAP and GATT 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 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.

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.

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.