Beacon Advertising Data Formats

Much has been written about beacons and, specifically, about iBeacon, Apple’s proprietary format for beacon advertising data. iBeacon is supported natively by iOS devices but, in some instances, there are some licensing requirements which need to be satisfied. You can read all about iBeacon at Apple.com.

However, there are other beacon advertising format specifications like the AltBeacon from Radius Networks. AltBeacon is open source and can be used across any platform without restriction. An open source API for Android has also been released.

I recently spent some time working with the AltBeacon format and the Android API and decided to share my experiences. I’m starting with some “developer beacon basics.” For some of you this will be familiar so feel free to skip ahead.

Applications and Beacons

Beacons typically (e.g. those deployed by a store) have an associated application for each smartphone platform designed to exploit it in a certain way. The purpose of those beacons and, as such the way the application should respond, is defined by the organization. For example, the marketing department can set the application to pop up a 20% off coupon for the stereo the user is standing in front of.

Right now a single, generalized beacon application cannot understand the intent behind a particular beacon it encounters and behave in a sensible way. One day this may change though. Google’s Physical Web experiment is, to a degree, concerned with this issue.

Determining Location

The primary purpose of any beacon is to allow an application to determine its current proximity with respect to a beacon and from this take an action that leverages that location information in some way. The application must have access to data which maps beacon IDs received in Bluetooth advertising packets to physical, geographical locations expressed in a way which makes it as easy as possible for the application to do its job. For example, one application may be best served by mapping beacon IDs to longitude/latitude coordinates whilst for another application it might be better to derive a store and department ID from the beacon ID so that the applications knows the user just walked into the sporting goods department of a London store.

Mapping beacon IDs in beacon advertising packets to some kind of location information is key to opening up the power of beacons. Beacon ID data can be mapped locally by an application on a device, or sent to the cloud/network for resolution remotely. Local data storage has an advantage because it is quick to access and available even when there is no network. Storing the data remotely means all applications are using the same data since there’s only one copy but network access will inevitably take more time and care needs to be taken to ensure the user experience is not impacted. In some cases, the best approach is a hybrid one where there’s a central copy of the location data held remotely and synchronized to an application’s local data store whenever it changes. That way the application can use the most recent copy of the data even when there’s no network available.

Lurking in the Background

Users shouldn’t need to explicitly launch an application for beacons to be detected. A good beacon application automatically runs in the background with no user intervention required. Care needs to be taken to ensure system resources, especially battery power, are used sparingly by any background processing which takes place.

How Near is Near?

This is a question which all beacon application developers need to consider and it has two aspects to it. On the one hand, the application requirements need to indicate the conditions which trigger action and those conditions must include something which concerns distance from the beacon or beacons. For some applications, just being in range of one or more beacons (several beacons collectively might define a “region”) might be sufficient to warrant triggering an action. This might be the case if you want to trigger an action when a customer walks into a particular department of a store or when a passenger enters the check-in area at the airport.

For other applications, perhaps the user needs to be quite close to a specific beacon before the application notifies the user. A museum or art gallery guide might only want to notify the user when they get quite close to specific, major exhibits.

It’s possible to estimate the distance that the user is from a beacon. The basis of such an estimate is the signal strength measured by the receiver (the smartphone) and data included within the advertising packet which indicates what the signal strength should be when measured at some standard distance—like 1 meter—from the beacon. If you’re using an API, you may find the API easily provides distance estimates. However you arrive at the estimated distance it is still only an estimate, albeit one accurate enough for most purposes.

Taking Action

Having determined the user’s location from the beacon ID, what should the application do next? The answer is “it all depends.” Marketing is a popular application of beacons by bringing products and special offers to the user’s attention. Museums and galleries are creating applications that automatically inform users about the room they just entered and its primary exhibits. Airports leverage beacons to track the progress of passengers throughout the airport. In this latter case, the action taken by the airport beacon application may be invisible to the user. There’s no “one size fits all” answer.

What we can say is that application designers must be cautious to ensure the way beacon apps get the user’s attention does not become intrusive or annoying. Users know how to uninstall applications after all!

The AltBeacon Format

So let’s move on to AltBeacons. AltBeacon advertising data is encoded in the manufacturer specific advertising data (AD) structure within Bluetooth advertising packets. This is the case with other advertising data formats too.

The full specification for the AltBeacon format can be found athttps://github.com/AltBeacon/spec along with the following two diagrams:

As you can see, inside the advertising data structure we have a code indicating this is an AltBeacon advertising packet known as BEACON CODE, a 20 octet BEACON ID that uniquely identifies a particular beacon, and a REFERENCE RSSI value that contains the average expected signal strength when measured at one meter from the beacon.

BEACON CODE, rather playfully, has the fixed hexadecimal value of 0XBEAC. Isn’t that cute?

The AltBeacon specification recommends the first 16 bytes or more of the BEACON ID should be the same for all beacons deployed by a given organizational unit. The remainder may be subdivided and used any way you like but the overall result must be for each beacon to retain a unique identifier.

Part 2

In part 2, I’ll focus on the AltBeacon Android API and describe a prototype museum guide application I wrote using the API.

(Credit: Martin Woolley)