An open specification by reelyActive to maximise the interoperability of radio-identifiers across protocols, platforms and operating systems.
One identifier to rule compatible with them all.
The identifier consists of four elements which facilitate identification, ranging/location and the lookup of digital twins.
An InteroperaBLE Identifier consists of an Entity UUID, an Instance ID, a transmission power estimation (Tx Power) and an optional Class.
Element | Size | Role | |
---|---|---|---|
Entity UUID | 128-bits | Identifies the entity or organisation responsible for the device (see Entity UUID subsection below) |
|
Instance ID | 28-bits | Uniquely identifies the individual device (which itself may identify a person, product or place) |
|
Class | 4-bits | OPTIONAL Implicitly indicates what is associated with the device, and/or its hierarchy | |
Tx Power | — | Facilitates the estimation of proximity, range and/or location |
The Entity UUID is a 128-bit Version 4 (Random) UUID which observes the following form:
XXXXXXXX-XXXX-MXXX-NXXX-XXXXXXXXXXXX
Each character is hexadecimal (0-9, a-f) with the following constraints:
The InteroperaBLE Identifier is implemented as Eddystone-UID or iBeacon as detailed below:
The elided UUID has the form XXXXXXXX-XXXX-MXXX-NXXX-XXXXXXXXXXXX where 48-bits are removed from the 128-bit Entity UUID as indicated by the strikeout, as specified in the Eddystone documentation.
How to look up a device's digital twin from the elements of its InteroperaBLE Identifier.
An InteroperaBLE Identifier may be interpreted as a Uniform Resource Identifier (URI), which may be used to identify anything.
Interpret as a local .mp3 file of the form "file:/xxxxxxx.mp3".
The Instance ID is interpreted as 7-character-long, leading-zero-padded hexadecimal string (ex: "0123abc"). This is prefixed with "file:/" and suffixed with ".mp3" to complete the URI.
An InteroperaBLE Identifier may alternatively be interpreted as something other than a URI. In this case, the 28-bit identifier typically represents an index into a table associated with the Entity UUID.
Interpret the Instance ID as a single Unicode code point (i.e. as UTF-32). The Unicode standard includes over 144,000 characters, including a growing list of emojis, which can be encoded in an InteroperaBLE Identifier, provided they consist of a single code point.
For example, Instance ID 0x001f989 would be interpreted as 🦉 (owl emoji)
Interpret as a DirAct proximity beacon.
The Instance ID is the 32-bit DirAct instance.
Interpret as a motion detection event. Devices with accelerometers (or other motion sensors) may not transmit motion detection status explicitly in a packet payload, but rather can be configured to transmit a predefined packet (ex: iBeacon or Eddystone) upon a given threshold or trigger.
The Instance ID may be ignored. The interpretation is that the device transmitting this Entity UUID is signalling a motion detection event.
Interpret as a button press event. Devices such as Minew button wristbands do not transmit button status explicitly in a packet payload, but rather can be configured to transmit a predefined packet (ex: iBeacon or Eddystone) following a button press.
The Instance ID may be ignored. The interpretation is that the device transmitting this Entity UUID is signalling a button press event.
Interpret as a BlueUp "Safety" packet. BlueBeacon series devices from BlueUp embed real-time personal safety data, such as button presses, in the minor identifier of an iBeacon packet. By configuring such devices to use the Entity UUID below as the iBeacon UUID, this data can be interpreted from the Instance ID.
For example, Instance ID 0x0008001 would be interpreted as a short button press and a battery level of 2.99V (consult the BlueUp technical documentation for details).
Continue exploring our open architecture and all its applications.