Beacons use BLE’s broadcast/advertising packets with a small amount of customizable embedded data on its three advertising channels (37, 38 and 39). A BLE scanner routinely scans for advertising packets and then decodes them to ascertain the content and take appropriate action. When a beacon packet is detected, the mobile OS and / or its applications know what to do with it.
Both advertising packets and data packets use the same format. Beacons follow the standard advertising packet format, but include an embedded data payload for one or more of the pseudo-standards.
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 generally 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 designates whether the data is a name, a service UUID, a Universal Resource Identifier (URI), or one of many other defined data types; and
- The packet data is where beacons take the structure a step further, defining a sub-structure inside the data field to determine the various pseudo-standards.
This section on Beacon Pseudo-Standards...
…is very brief. There is a lot more detail in our whitepaper on developing with beacons .
Apple was an early adopter with its iBeacon. 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.
iOS apps can query iOS to continuously monitor for beacon-region-crossing events, or close encounters of the beacon kind. The monitoring takes place whether the app is running or not, and can trigger a closed app to open.
Eddystone is an open-source, cross-platform beacon format from Google. It supports both Android and iOS devices, although it only supports Eddystone “natively,” and supports iBeacon through various open-source initiatives.
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; and
- Eddystone-URL which broadcasts Uniform Resource Locators (URLs). The Eddystone-URL frame enables platforms to offer proximity-based web content without requiring an app to be installed. This is will enable Google’s vision to “ walk up and use anything .” Google calls this The Physical Web .
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.
Our experts have put some very relevant information in a whitepaper on