How to quickly implement BLE beacons

BY JOE TILLISON,
Senior Manager, Field Marketing, Silicon Labs
www.silabs.com

Bluetooth beacons enable proximity-based contextual awareness, but implementing beacons on a product can present some interesting design and development challenges. First, there is no official Bluetooth Special Interest Group (SIG) beacon standard; instead, a number of pseudo standards are emerging. Then there is the issue of range determination, impact on the overall power budget, and ensuring security.

After defining beacons and presenting a quick look at competing beacon approaches from Apple, Google, and Radius Networks, we will discuss how best to go about implementing beacons to address these design challenges.

What is a beacon?
A beacon is a small, battery-powered, wireless device that uses Bluetooth Low Energy (BLE) to advertise its presence and services. It does this by broadcasting (advertising) a beacon identifier to compatible devices, such as smartphones, within its proximity. That identifier also contains a small amount of customizable embedded data. A BLE scanner on a smartphone, for example, routinely scans for advertising packets and then decodes them to determine the beaconing device’s location and services and interact accordingly.

The emerging pseudo-standards take advantage of some of BLE’s native facilities and the widespread use of Bluetooth. The more prominent ones are Apple’s iBeacon, Google’s open-source Eddystone, and Radius Networks’ AltBeacon (see Table 1 ).

Table 1: OS support for BLE technology and beaconing pseudo-standards.

Proximity-aware applications rely on knowing which beacons are nearby. But a beacon’s RF range can vary from Beacon services and packet structure
A beacon can include multiple services. When a service needs to be advertised, its universally unique identifier (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 format of advertising and data packets is the same (Fig. 1 ). Beacons follow the standard advertising packet format and embed the data payload in the pseudo-standard’s pre-defined structure. This allows the OS to treat a beacon’s advertising packet differently from other Bluetooth advertising packets.

Fig. 1: BLE packet format is the same for both data packets and advertising packets.

BLE devices transmit advertising packets on a selectable interval, from 20 ms up to 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. This is followed by 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 data packet comes next.

Transmitting a single beacon packet can take up to 376 µs, but could be shorter, depending upon the pseudo-standard, and the frequency with which this happens is a trade-off between power consumption and acceptable application latency.

Considerations for designing a beacon product
In its most basic form, a beacon can be implemented with a wireless system-on-chip (SoC) device or a module, along with a battery and a mechanical enclosure. More typically, a beacon will include other components that provide functional user interaction as well as sensors. The pre-certified module approach provides the fastest time-to-market, avoiding significant upfront engineering investments and RF compliance testing, while a discrete SoC design might provide size or cost savings (Fig. 2 ).

Fig. 2: Typical pre-certified BLE beaconing module and Bluetooth SoC reference design.

Selecting a field-proven BLE stack that actively manages sleep modes is crucial for power-management reasons: broadcasting for just 1 ms every 100 ms means that, for 99% of the time, it should be sleeping. Also, it’s best to use a stack that can, for example, define multiple beacon frame types (iBeacon, Eddystone-URL, etc.) along with their timing parameters. The stack can then interleave these autonomously, without running the more power-hungry application code.

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 can be relatively simple and implemented with a high-level programming language such as BGScript (Fig. 3 ). The benefit of this approach is that the developer can focus on the application instead of the timing and complexities of the protocol stack underneath.

Fig. 3: BGScript iBeacon example code for the BGM111 BLE module.

This example code supports the BGM111 module. 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 that they are unset. The calibrated Tx Power value of 0xD0 correlates to –48 dBm at one meter.

The beacon’s transmit power and beaconing interval play an important role in battery life and trade off desired range and proximity accuracy (Fig. 4 ). Higher transmit power provides longer range and a wider coverage area, but the transmitter will draw down the battery more quickly with each beacon event.

Fig. 4: A beacon's average battery life is determined by transmit power and its transmit/sleep duty cycle.

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

Security
Beacons broadcast only, so they don’t collect data. An in-range smartphone then accesses the broadcasted services, typically over Wi-Fi or its cellular network. As such, beacons do not pose any additional security threats or attack surfaces. For the beaconing provider, when attaching to the beacon has a monetary value through, for example, reward points, care must be taken to reject constant requests from the same device. This is accomplished using time-stamping and other techniques. The same applies to a beacon’s device-management functions, in which standard BLE security features, such as pairing and authentication, are used to restrict access to internal functions.

Conclusion
It’s hard to imagine that we all won’t be touched by beacon applications in the near future. Indeed, they may be the next killer app. 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 to ensure that the developer has a smooth experience and a superior final product.