Developing Beacons with Bluetooth Low Energy

Whitepaper

Developing Beacons with Bluetooth® Low Energy BLE Technology

This whitepaper discusses the following:

Beacon applications to help you brainstorm some of your own.
Provides a short history of Bluetooth and its derivatives, including Bluetooth low energy and beacons.
Covers leading beacon pseudo-standards at a high level, and in detail in the Appendix.
Provides references to field-hardened example code and tools to develop and deploy it.
Provides information on end-to-end solutions to get you started.

Executive Summary

At the time this document was written, Bluetooth® beacons had just started gaining popularity. Today, Bluetooth beacons are becoming a pervasive technology because of their wide-spread application. Among other things, Bluetooth beacons enable “proximity-aware applications” for customers, businesses, and industrial environments. The following are some of the benefits that Bluetooth beacons offer:

End customers benefit through instant coupons and tailored offerings based on where they are.
Businesses benefit through improved visibility to customer buying habits and increased loyalty.
Industrial companies benefit through improved asset monitoring and utilization.

The possibilities are endless and beacons are set to transform our world. However, implementing them can be challenging. Putting beacons on a product, pushing their data into the cloud, and then using it create value represent new development frontiers for many of us.

Implementation is not straightforward because Bluetooth beacons are not a Bluetooth standard. Bluetooth beacons are pseudo-standards running on Bluetooth’s low energy technology (previously known as Bluetooth Low Energy, BLE, or Bluetooth Smart), but they use proprietary beacon code beyond that.

This whitepaper discusses the following:

Examines beacon applications to help you brainstorm some of your own.
Provides a short history of Bluetooth and its derivatives, including Bluetooth low energy and beacons.
Covers the leading beacon pseudo-standards at a high level, and in detail in the Appendix.
Provides references to field-hardened example code and tools to develop and deploy it.
Provides information on end-to-end solutions to get you started.

After a beacon developer is ready to start development, they need to focus on several key items.

Select a widely-adopted, proven Bluetooth stack. Because beacons are new, there is room for FUD from new entrants. Buyer beware. Use a company that understands low-energy Bluetooth and has the market adoption to prove it.
Select a company with proven software development tools. Software development is more than just an editor and a debugger. It also needs to include mature example code for common use cases, scripting engines for common commands, and thoughtful APIs for ultimate migration from one standard revision to another. These tools will all work together to speed development.
Select a company with good customer support, which goes hand-in-hand with a market-proven stack and software tools. If the selected company is market-proven, then they have support forums with hundreds of questions and answers on hardware and software, an adequate user base and support staff to answer new ones, a broad portfolio of product variants for different applications, and so on.

Introduction

Bluetooth® beacons have already had a transformative impact on the way we interact with the physical world. They enable proximity-based contextual awareness using technology that most of the world’s population now carry in their pocket – a smartphone with applications.

Using wireless technology for proximity detection is not new, but with the introduction of Bluetooth’s low energy features¹ in 2009, beacons are now deployed on a wide-reaching scale.

This whitepaper explains how beacons work, some of the ways they can be used, and design considerations for beacon product development.

Introduction to Beacons and their Usage

A beacon is a small, battery-powered, wireless device that uses Bluetooth low energy technology (Bluetooth Smart) to advertise its presence and services. It does this by repeatedly broadcasting or advertising a beacon identifier to compatible smartphones or tablets within its proximity. The smartphone or tablet can then use the beacon’s information to determine its location and services and act accordingly.

Beacons enable proximity-based customized experiences for users.

Can’t find the Tylenol? Need a quick sandwich on the way to your flight?

Beacons can help.

Beacons are generally used for proximity-aware applications. By monitoring beacons, a device can detect when it has entered or exited a particular area and then use that information to create interactive experiences based on what’s nearby.

There is no official Bluetooth Special Interest Group (SIG) beacon standard. Instead, there are various beacon pseudo-standards from company consortiums or large operating system providers. Each pseudo-standard takes advantage of some of the Bluetooth low energy technology’s native facilities and the widespread availability of Bluetooth itself. The more prominent pseudo-standards are Apple’s iBeacon™, Google’s open source Eddystone™, and Radius Networks’ AltBeacon.

OS support for Bluetooth low energy technology and beaconing pseudo-standards

¹ The Bluetooth Special Interest Group (SIG) recently rebranded to remove sub-brands Bluetooth SmartReady and Bluetooth Smart to reflect only “Bluetooth” with common language to describe any relevant sub-features. For example, “Bluetooth Smart” is now referred to as “Bluetooth low energy technology.” See Bluetooth.org for more information.

Two Beacon Usage Models

Beacons are typically used in one of two scenarios. The first and most common is for a beacon to be placed either in a fixed location or on a movable object, then relying on a smartphone to correlate beacon proximity to a desired behavior such as opening an app or offering contextually-relevant content.

The second scenario uses a fixed wireless node to monitor beacons on objects that pass by or through its monitoring area. It then can report back to another application using a wired or wide-area network. This model might apply to asset tracking for expensive tools and equipment, livestock, or even people (wearing a bracelet tag for example).

Example Fixed Location Beacon

Proximity-Aware Example Applications

The two usage scenarios above rely on proximity awareness. In the first scenario, a user's smartphone comes into proximity with a beacon. In the second, beacons come into proximity with a beacon-monitoring node. Both models are finding applications in retail and commercial businesses.

The most established applications focus on retail shopping. Beacons distributed throughout a store allow loyalty apps to offer personalized experiences to its customers. The applications serve tailored messages and coupons and track the customer’s reactions for additional customization.

A smartphone can detect when it enters or exits a particular setting by monitoring beacons, then use that information to create interactive experiences based on nearby products and services.

Other applications include point-of-sale systems, such as vending machines. For example, when a customer approaches a beacon-enabled vending machine, the customer’s smartphone activates a payment app or Website to suggest favorite items or a menu of available options.

Beacons also enable more secure payments. In the vending machine example, the customer’s smartphone app can recognize the beacon-tagged machine to allow the customer to pay for their selection using the cellular network. The cellular wireless connection is more secure than a local one and they never have to reach for their wallet.

The same use case is emerging at fast-food drive-throughs. When the driver approaches the beacon-enabled drive-through equipment, their smartphone detects the beacon and activates customized offers. The same application can also optimize inventory management based on customer usage.

Beacon-Enabled Drive Through

Commercial beaconing applications are also gaining momentum. As mentioned above, beacons can track and help manage important assets, such as expensive power tools. A beacon-enabled tool allows it to “check in” to a monitoring node to determine when it is in a tool bin, on the shop floor, or not in range. The same beacon application can monitor and report tool status such as charge level, operating time, and performance. This has obvious implications to the lifetime and security of the tool as well as its optimized utilization.

Additional beaconing applications provide indoor navigation and relevant localized content in large buildings such as hospitals, shopping malls, or museums.

Beacon Proximity Accuracy

Proximity-aware applications rely upon knowing which beacons are nearby. But a beacon’s RF range can vary from under a meter, to just a few meters, to over 500 meters depending on its transmit power². This makes it impractical to determine proximity based solely on receiving a beacon identifier packet.

For this reason, beacon proximity relies on a comparison of a Received Signal Strength Indicator (RSSI) to a beacon’s transmit (TX) power to approximate the distance to the beacon. Beacons provide a calibrated transmit (TX) power figure in their advertising packets. Coupling this information with the RSSI enables a receiving device to approximate how far away the beacon is. Unfortunately, this calculation cannot be very accurate since RF signals fade unpredictably according to real-world environmental factors, such as walls, weather, and people. Luckily, approximate distance is generally good enough for proximity applications since the typical intent is just to determine whether the beacon is close by or far away (e.g., 1 meter, 10 meters, or 100 meters).

² Bluetooth low energy transmit power was limited to 10 mW until Addendum 5 was released in December 2015, increasing the maximum allowable Tx power to 100 mW, and providing up to 2.5x more range.

Bluetooth specification incorporates Angle-of-Arrival (AoA) and Angle-of-Departure (AoD) features since Bluetooth version 5.1 and later. For more information, see Bluetooth's Core Specifications. These features allow a multi-antenna Bluetooth device to accurately determine the spatial location of another Bluetooth device³. They also enhance Bluetooth’s usefulness in applications requiring high-accuracy location detection, potentially giving position accuracy to within tens of centimeters. This level of precision enhances the effectiveness of beacons when used in asset management applications.

A Short History and Technical Overview of Bluetooth Low Energy Technology

The Bluetooth SIG announced Bluetooth low energy features with version 4.0 of the Bluetooth specification in 2009. It was later re-branded as Bluetooth Smart, and has just been rebranded again in 2016 (see footnote 1 above). Consequently, the terms Bluetooth Smart, Bluetooth Low Energy, BLE, and now Bluetooth low energy technology are often used interchangeably.

Bluetooth low energy technology is a radical departure from what is known as Bluetooth Basic Rate / Enhanced Data Rate (Bluetooth BR/EDR) or Classic Bluetooth, introduced in the late 1990s and used today in handsets, speakers, earphones, car kits, etc. The SIG’s goal with Bluetooth low energy technology was to define a new version of Bluetooth, which could operate for years on a coin cell battery and was better suited for sending small bits of data on an infrequent basis.

Bluetooth BR/EDR is still the protocol of choice for voice or streaming music, but Bluetooth low energy technology is better suited to wireless sensor and control applications. Bluetooth low energy technology also reduced data latency to only 10% that of Bluetooth BR/EDR and introduced the ability for Bluetooth to broadcast data.

Like Bluetooth BR/EDR, Bluetooth low energy technology utilizes the 2.4 GHz ISM band and a frequency hopping technique to spread its RF energy between multiple channels. But in a departure from Bluetooth BR/EDR, it uses 40 2MHz-wide channels instead of 79 1MHz-wide channels. Consequently, the two versions are fundamentally incompatible over the air. Devices that can support both Bluetooth BR/EDR and Bluetooth low energy technology have been called “Bluetooth Smart Ready” up until March of 2016. Most handsets, tablets, and so on fall into this category.

³AoA and AoD features will tentatively be supported in Bluetooth v5.0

Bluetooth BR/EDR, Bluetooth Smart Ready, and Bluetooth Smart (BLE) (See footnote 1 above)

Three of Bluetooth low energy technology’s 40 channels (37, 38, and 39) are reserved for broadcasting “advertising packets” that contain information about the broadcasting node’s capabilities. These advertising packets are strategically located on frequencies between the three 2.4 GHz Wi-Fi channels to avoid interference from Wi-Fi.

Bluetooth Generic Attribute (GATT) Profile

The SIG also greatly simplified the application profiles for Bluetooth low energy technology, which now uses the GATT (Generic Attribute) profile, a structured list that defines the services, characteristics, and attributes of a given application. GATT profiles can use either SIG-defined services or custom services defined by the OEM. Each GATT profile’s service is distinguished by a Universally Unique Identifier (UUID), which is either 16 bits long for SIG-adopted services or 128 bits long for custom services defined by the developer.

A beacon can include multiple services. When a service needs to be advertised, the service UUID is broadcast in the device’s advertising packet. Subsequently, when a Bluetooth scanner receives an advertising packet, the UUID is registered by the operating system to a specific application, which takes follow-on actions.

The Bluetooth Low Energy Technology Advertising Packet

Beacons work by taking advantage of Bluetooth’s ability to broadcast packets with a small amount of customizable embedded data on its three advertising channels. A Bluetooth low energy scanner routinely scans for advertising packets and then decodes them to ascertain the content and take appropriate action.

Bluetooth advertiser nodes use advertising packets in channels 37, 38, and 39 to advertise their supported GATT profiles.

Scanners receive the advertising packets, decode them, and take action.

Both advertising packets and data packets use the same format, as shown in the figure below. Beacons follow the standard advertising packet format, but then format the embedded data payload to follow a pre-defined structure for the beacon pseudo-standard it uses. This allows the OS to treat a beacon’s advertising packet differently from other Bluetooth advertising packets.

Bluetooth low energy packet format is the same between data packets and advertising packets

Bluetooth low energy devices transmit advertising packets on a selectable interval as short as 20 milliseconds or as long as several minutes. The same packet is sent on all three of the advertising channels every time the device advertises, making it more likely that a scanner will pick it up.

Within the advertising packet, the data payload is structured as one or more [length, type, data] triplets.

The length field defines the combined size of the subsequent type and data fields;
The type field which designates whether the data is a name, a service UUID, a Universal Resource Identifier (URI), or one of many other defined data types
The packet data itself

Beacons take the structure a step further, defining a sub-structure inside the data field as shown in the following sections on the various pseudo-standards.

Transmitting a single beacon packet can take up to 376μs⁴, but could be shorter depending on which beacon standard is followed. How frequently a beacon advertises is a trade-off between power consumption and the tolerable application latency.

In a more conventional, non-beaconing Bluetooth low energy application, advertising packets provide identifying information about the advertiser’s services and are then followed by a period of time in which the advertiser actively listens for a connection requests from scanners which want access to those services.

However, beaconing Bluetooth applications will typically use non-connectable advertising, essentially fire-and-forget, providing all of their useful information in the advertising packet itself. Because they generally don’t listen for connection requests, the radio can be shut off immediately after advertising, further extending battery life.

⁴ This assumes a fully utilized advertising data payload of 39 bytes.

Note that some beaconing applications include other GATT services in addition to the beacon, and those services may interleave connectable advertising packets with the non-connectable beacon packets. In this case, the beacon performs a more typical advertising cycle with transmit/listen operations.

Beaconing Pseudo-Standards (iBeacon, Eddystone, AltBeacon)

Because there is no Bluetooth SIG official beaconing standard, all beaconing implementations are pseudo-standards, implemented by one company or group of companies and adopted by other companies who want to use them. A short overview of the leading pseudo-standards is provided below with more detailed information on unique packet structures in the Appendix.

Apple’s iBeacon

Apple was an early beaconing adopter with its iBeacon. The iBeacon term is trademarked by Apple and vendors who want to sell iBeacon products or use the iBeacon logo must obtain a free license from Apple. The iBeacon specification and other developer resources can be downloaded from the Apple Developer Website.

Apple iBeacon Logo

iBeacon specifies a 30 byte packet, which must be broadcast on 100 ms intervals (although iBeacon OEMs don’t always seem to adhere strictly to the 100 ms requirement). The full iBeacon packet structure is shown and explained in detail in the Appendix.

iOS Apps, which use the Core Location framework can ask the iOS to continuously monitor for beacon-region-crossing events, i.e., entering or exiting the proximity of an iBeacon defined by the UUID, Major, and Minor fields. The iOS monitoring takes place whether the app is running or not and can even trigger a closed app to launch. Monitoring only works when the user has enabled Location Services for the corresponding app.

Google’s Eddystone

Eddystone is an open-source, cross-platform beacon format from Google. It supports both Android and iOS devices. Unlike other beacon standards, it defines several different frame types which can be used individually or in combination:

Eddystone-UID, which broadcasts a unique beacon ID
Eddystone-TLM, which can be used to broadcast telemetry (health and status) data about the beacon itself
Eddystone-URL, which broadcasts Uniform Resource Locators (URLs)

The Eddystone-URL frame enables mobile platforms to offer Web content based on proximity without requiring an app to be installed, enabling what Google has dubbed The Physical Web, or the “ability to walk up and use anything.”

Eddystone Logo

Eddystone is already supported in Chrome for iOS, and will be supported in Chrome for Android beginning with version 49. With the Chrome Today widget, users can access Web content relevant to their surroundings and receive notifications when encountering beacons.

Google’s Physical Web uses Eddystone-URL beacons to allow iOS and Android users to “walk up and use anything” in their beacon-tagged surroundings.

The Google Eddystone GitHub page provides the Eddystone Protocol Specification along with tools and open source code examples, and the Google Developers forum provides more information about the Google beacon platform. The full Eddystone beacon format is described in detail in the Appendix.

AltBeacon

Radius Networks defined the AltBeacon specification in an attempt to create an OS-agnostic, open-source standard, which wouldn’t favor any particular vendor. The specification is available on the AltBeacon website and is free to use without royalties or licensing fees. Like other beacons, it uses non-connectable, undirected advertising packets. The full packet format is described in the Appendix.

AltBeacon Logo

Considerations for Designing a Beacon Product

Beacons enable new business models in everything from vending machines to snow-blowers and weed-eaters. Many OEMs who previously never used wireless technology are now adopting Bluetooth and adding beacons to their products.

Although a beacon can be relatively simple, the designer will need to take into consideration the hardware and software building blocks, trade-offs with battery life, how the beacon will be provisioned or deployed into the field, security and privacy, and of course their vendor’s development tools and support.

Hardware Building Blocks

In its most basic form, a beacon can be implemented with a wireless System-on-Chip (SoC) or a module, along with a battery and a mechanical enclosure. More typically, a beacon will include other components that provide functional user interaction, such as pushbuttons, LEDs, piezo buzzers, and/or reed switches. If a beacon is embedded into a product with other features, it might include additional sensors such as temperature, light or hall- effect sensors, which can interface directly to the wireless SoC.

A pre-certified module provides the fastest time to market, avoiding significant up-front engineering investments and RF compliance testing, while a discrete SoC design might provide size or cost savings.

Typical pre-certified Bluetooth low energy beaconing module and Bluetooth SoC reference design

The whitepaper Six Hidden Costs in a 99 Cent SoC provides a good discussion of the trade-offs to consider when choosing a module or SoC for a Bluetooth beacon.

Software

It’s fundamentally important to choose a widely-deployed and field-proven Bluetooth stack. Most often, this market success is more important than any promises of new cutting edge features. Market success indicates good customer support and a stable stack, both of which help get to market quickly.

For beacons in particular, it’s very important that the protocol efficiently manages sleep modes. When a beacon broadcasts on 100 ms intervals, it only transmits for about 1 ms and sleeps for the other 99, therefore spending 99% of its life in sleep mode.

Some proven protocol stacks include special features designed specifically to make Bluetooth and beacons more power efficient. One example is the ability to define multiple beacon frame types (iBeacon, Eddystone-URL, etc.) along with their timing parameters, which the stack can then interleave autonomously without the more power-hungry application code running.

Other important software features include Watchdog timers as a fail-safe mechanism, real-time clocks to set beacon on/off cycles to preserve power, and the ability to support firmware updates.

Beacon Application Code

Beacon application code can be relatively simple and implemented with a high-level programming language, such as BGScript® from Silicon Labs. BGScript is a simple, high-level, BASIC-like programming language that’s human readable and allows Silicon Labs devices to run standalone without an external processor.

The benefit of this type of high-level programming language is that the developer can focus on the application itself without concerning himself/herself with the timing and complexities of the protocol stack underneath. See below for a simple commented code example for implementing an iBeacon in BGScript.

BGScript iBeacon example code for the BGM111 Bluetooth low energy module

This example code supports the BGM111 module and is implemented with only 38 lines (most of it comments). The code’s advertising packet is constructed to use the Apple AirLocate Service UUID of 74278bda-b644-4520- 8f0c-720eaf059935, with major and minor fields of 0x00, meaning they are unset. The calibrated TX Power value of 0xD0 correlates to -48 dBm at one meter. (The BGM111 has +8 dBm of TX power.)

This is a very basic example of an iBeacon implementation, but a more robust implementation might include the ability to change the beacon’s UUID and major/minor values through the over-the-air interface, and possibly include provisions for updating the beacon’s firmware.

Battery Life

As with any product, the size of the battery versus its power consumption will determine its operating life. Battery size is sometimes dictated by the beacon industrial design, so a compromise must be made between battery life and the physical constraints of the final product.

The beacon’s transmit power and beaconing interval also play an important role in battery life. These parameters are typically trade-offs against the desired range and proximity accuracy. Higher transmit power provides longer range and a wider coverage area, but the transmitter will draw more power from the battery for each beacon event. The application usage model needs to be considered. For example, whether the application benefits from a larger coverage area or whether it is better to have its proximity limited to a few square meters.

Likewise, the beaconing interval is an important factor in determining a beacon’s battery life. A beacon’s power consumption peaks at several milli-amps while transmitting. Otherwise, it only draws micro-amps while in deep sleep.

A beacon’s average battery life is determined by transmit power and its transmit / sleep duty cycle

There are important trade-offs for short versus long transmit cycles, including operating life and location accuracy.

With transmit power constant, short cycles provide more data points for better location, while longer cycles provide worse location accuracy but longer battery life.

In terms of performance, a shorter beaconing interval indicates that there are more beacon events to capture, providing more motion resolution and therefore better location accuracy. A longer interval indicates that the beacon will have longer battery life but fewer opportunities to get captured, especially by a moving smartphone.

Beacon interval also plays a role in smartphone application response times. When apps are in the background, the OS scans for beacons less frequently, so a more frequent beacon interval increases the likelihood of detection and resulting activity.

Current profile in a typical Bluetooth low energy advertising event (ADV PDU)

Privacy and Security Issues

Note that typical beacons do not collect data because they are one-way devices—they only broadcast.

They do however, enable a smartphone to know when it's near a known beacon, and in some cases (if the beacon is stationary), the smartphone might have access to information about the location of that beacon. The smartphone translates this information to provide location and usage-based services, either through an app or in the case of the Physical Web, with contextually-relevant search results.

It’s important to note that the same smartphone can provide the same services based on GPS, Wi-Fi, or cell towers, so beacons are not exposing new concerns, just making them more widespread through their success. In all cases, smartphone users can simply enable or disable proximity services in their settings.

Smartphones can use GPS, Wi-Fi, cellular, and Bluetooth beacons for proximity-aware applications.

And users can disable them all in settings.

Similarly, concerns have been raised about beacons creating added security risks for IT systems. But this again implies capabilities that most beacons do not have. The typical beacon is a standalone device with no connection to any other network, wired or wireless.

However, some beacons are designed with infrastructure network access, which allows for central management of a beacon fleet. In these cases, the beacon manufacturer provides the same level of tamper security as they would for any other device attached to their IT network. On the beaconing side, the beacon’s data is, by design, broadcast for all to hear so does not necessarily need to be encrypted or protected in any way.

In beaconing applications where proximity to the beacon may have tangible value, such as reward points for example, the beacon OEM will implement additional safeguards against beacon spoofing. Without them, spoofed beacons might fool the system into crediting events too often or to the wrong person. The safeguards could include simple timestamps for each proximity event with a test for an improbable or unanticipated frequency, the use of ephemeral IDs, or the use of randomized security keys, generated with each proximity event and validated by the back-end system.

Security for Device Management Functions

In general, Bluetooth security isn’t a concern with beacons since, by definition, they are broadcast devices with the intent that any listener can receive data.

But if the device includes other internal services, such as device management functions, those services might be protected and require authentication before allowing access. In those cases, the beacon will use the security features built into the Bluetooth protocol (i.e., pairing, authentication, encryption, etc.) and other security measures implemented by the beacon OEM such as strong password protection.

The most common device management functions are used to configure the beacon during the provisioning and access to those services may be limited to a short window of time after the device is reset. After the access window expires, the device becomes a normal broadcast beacon and no longer advertises its internal services.

Provisioning / Deploying the Beacon

When beacons are deployed in the field, the installer often has to configure the beacon to the installation, for example by writing a unique major/minor value or instance ID. The most obvious (and most desirable) way to do this is to take advantage of the over-the-air interface. But exposing the configuration services over Bluetooth can provide a potential channel for unauthorized access and the extra advertising packets for the configuration services can have a significant impact on battery life.

A simple, commonly-used solution is to limit exposure of these services to a short window of time either just after power-up, or after a trigger from a physical input such as a pushbutton or reed switch. This is illustrated below.

During the configuration window, the beacon is connectable (with appropriate authentication) so that the provisioning configuration can be written into it. After the timer expires, it reverts to only advertising the non-connectable beacon packets, effectively hiding the configuration services.

Flowchart for a time-limited provisioning window

Summary

It’s easy to imagine that beacon applications will become even more prevalent in the near future. Product designers across hundreds of industries will have lots of new challenges to address as they move to adopt wireless. Choosing the right vendor with innovative technology, a market-proven stack, and great customer support will help ensure the developer has a smooth experience and a superior final product.

Silicon Labs is an established leader in Bluetooth low energy and beaconing technology, development tools, and a broad portfolio of Bluetooth beacon-capable SoCs and pre-certified Bluetooth modules.

Get Started here with Blue Gecko Bluetooth low energy modules and SoCs.

Appendix 1 – Example Code and Further Reading

Code examples for various beacon implementations are provided on the Silicon Labs Website, including an iBeacon example with parameters that are configurable over the air, or through a wired host interface, and an example which implements interleaved iBeacon and Eddystone-URL beacons in the same device. All examples are written in BGScript code and provided as full project files with source code, which can run on any Silicon Labs Bluetooth product:

Video: Introduction to Bluetooth low energy
Video: Blue Gecko Getting Started
Users Guide: UG103.14: Bluetooth LE Fundamentals