Assignment of Bluetooth Low Energy (BLE) identifiers for interoperability and interpretability
Learn how we at reelyActive assign BLE identifiers based on best practices we've established.
This tutorial is organised into four parts as follows:
Links to related tutorials are provided at the end.
Just enough structure with just enough space for data.
The diagram below illustrates the structure of a BLE advertising packet with the Packet Data Unit (PDU) expanded and identifier content highlighted. The preamble, access address and CRC are typically generated/processed automatically, and are irrelevant to this discussion.
Every BLE advertising packet includes a 48-bit Advertiser Address and a single-bit txAdd flag. The latter indicates whether this address is:
A random identifier may not be static. A device may cycle a random identifier at any time.
A random identifier may not be unique. Collisions are nonetheless unlikely unless assignment is non-random.
A BLE advertising packet may include an optional payload of up to 31 bytes in which additional identifiers and/or data may reside. The Bluetooth Generic Access Protocol (GAP), documented here, affords many payload options. Below are the most common for identifiers.
Bluetooth GAP and the advertising packet payload capacity allow for one or more 16-bit or 32-bit service class UUIDs or a single 128-bit service class UUID. Only a 128-bit UUID can be user-generated, as the shorter UUIDs are assigned by the Bluetooth SIG.
A service class UUID is intended to represent a common service among a class of devices. For instance, a given model of FitBit will advertise a common service UUID.
A service class UUID is therefore not suited for the unique identification of a device.
Bluetooth GAP and the advertising packet payload capacity allow for the inclusion of up to 20 bytes of data for a specific 16-bit service class UUID.
An entity may purchase a 16-bit member service from the Bluetooth SIG and define the service data structure as the wish, either as an open or closed standard. An example is Google Eddystone which has the reserved UUID
0xFEAA and supports several different frame types defined as open standards (). Eddystone-UID is presented in detail in Part 4. Another example is Tile which has the reserved UUID
0xFEED but whose specification is proprietary and not published.
The Bluetooth SIG maintains assigned numbers for GATT Services and Characteristics. It is possible to include service/characteristic data provided it does not exceed the payload capacity. An example is reelyActive transceiver infrastructure, where each device advertises its unique EUI-64 identifier as a System ID characteristic (
Service data offers several alternatives for the unique identification of a device.
Bluetooth GAP and the advertising packet payload capacity allow for the inclusion of up to 22 bytes of use-as-you-please data for manufacturers who register (at no cost) with the Bluetooth SIG and receive a 16-bit company identifier.
For instance, iBeacon is defined as an open standard () by Apple, uses their company identifier (
0x004C), and includes a 128-bit UUID and a major and minor identifier of 16-bits apiece. This is presented in detail in Part 4.
Manufacturer data affords full freedom for the unique identification of a device, constrained only by the payload capacity.
Just because it's possible doesn't mean it's permitted by the platform or operating system.
The diagram below illustrates the processing pipeline between a raw packet over-the-air and the interface with application software under a developer's control. Although the advertising packet structure is standard, as presented in the previous section, the processed data available for a software application is not standard: it depends on the platform and OS.
Similarly, application software is constrained by the platform and OS with regard to any advertising packets it wishes to transmit.
The table below highlights the key constraints with respect to receiving and transmitting identifier data in BLE advertising packets.
|Access advertiser address|
|Access PDU elements|
|Access raw PDU|
|Specify advertiser address|
|Transmit user-defined payload|
Mobile devices use a random advertiser address which they cycle regularly (ex: every 15 minutes)
reelyActive infrastructure operates raw, without a Bluetooth stack
The objective of BLE identifier best practices being to maximise interoperability, the platform and OS constraints presented above lead to the following observations:
The following section presents existing protocols and standards which include identifiers in the BLE advertising packet payload.
Eddystone and iBeacon are among the few widely observed open standards.
In 2013 Apple unveiled iBeacon to enhance the location awareness and interactivity of their mobile devices. By strategically placing inexpensive battery-powered beacons throughout a space, mobile devices can estimate their position and/or trigger actions based on proximity.
The week of the iBeacon launch, we published this video demonstrating the potential of the inverse use case, where the mobile device itself transmits iBeacon. We expanded on this use case in this article featured in GigaOM and evangelised the concept at Bluetooth World 2014.
In 2015 Google released Eddystone, similarly intended for battery-powered beacons to transmit information to the mobile device, with Android supporting this use case. Eddystone extends the proximity beacon concept, adding the potential to transmit a (short) URL, telemetry data and encrypted identifiers.
Although both iOS and Android allow developers limited possibility to transmit BLE advertising packets, history has shown that Apple and Google are committed to the mobile-device-as-receiver model. During the brief period of Android support for Google's Physical Web project we were able to demonstrate the limits of mobile peer-to-peer discoverability in this video and accompanying blog post. In short, mobile peer-to-peer discovery with BLE is not practically supported by iOS and Android.
Although the hype around beacons for mobile has long since waned, as of 2020, hundreds of millions of beacons have nonetheless been deployed worldwide, with iBeacon and Eddystone clearly established as the prevailing standards. As a result, regardless of vendor, a battery-powered beacon purchased today is almost assured to support both iBeacon and Eddystone, often simultaneously, even if these beacons are increasingly destined for non-mobile applications such as personnel/asset tracking and environmental sensing.
The following table compares the properties of iBeacon and Eddystone-UID which together emerged as the standards for proximity identification not just of BLE, but of all active RFID technologies.
|Entity identifier||128-bit UUID||80-bit Namespace ID|
|Instance identifier||16-bit Major & 16-bit Minor||48-bit Instance ID|
|Tx Power Indication?||Yes, measured @ 1m||Yes, measured @ 0m|
|Additional data||—||16-bits RFU*|
* Reserved for Future Use
In summary, both iBeacon and Eddystone-UID share the same structural elements, although the number of bits allocated to each varies. Both have at least 80-bits (280 values) of entity identifier to indicate to which entity or organisation the device belongs, and at least 32-bits (232 values) of instance identifier to uniquely identify the device itself. Moreover, both provide an indication of transmission power to facilitate ranging and proximity estimations.
The following section presents a best practice for identification which can be implemented to equal effect in either iBeacon or Eddystone-UID.
Our best practice proposal for maximum interoperability of BLE identifiers.
As a best practice, we propose the following four elements for a BLE identifier which we shall refer to as the InteroperaBLE Identifier*. Together, these elements can be transmitted, received and interpreted across platforms and operating systems:
* If you're at all familiar with reelyActive, this name should come as no surprise.
If one does not already exist for the entity or organisation, a 128-bit Version 4 (Random) UUID should be created, observing the following form:
Each character is hexadecimal (0-9, a-f) with the following constraints:
* So long as the entire UUID is unique from that of other entities and organisations.
The InteroperaBLE Identifier is implemented as Eddystone-UID and iBeacon as detailed below:
The elided UUID has the form XXXXXXXX
-XXXX-MXXX-NXXX-XXXXXXXXXXXX where 48-bits are removed as indicated by the strikeout, as specified in the Eddystone documentation
The 32 most significant bits of the Instance are not required by the InteroperaBLE Identifier and should be set to zero, unless required for another purpose.
Continue exploring our open architecture and all its applications.