Bluetooth beacons are taking off. They enable “proximity-aware applications” for customers, businesses, and industrial environments.
The possibilities are endless, and beacons are set to transform our world. But before they do…How are they standardized and how do their advertising packets work? Bluetooth beacons are not actually a Bluetooth SIG standard. Instead they are what could be called “Pseudo-Standards,” or formalized formats for beacon applications headed up by a large provider or group of companies.
Today three “pseudo-standards” have critical market momentum:
All three pseudo-standards use the BLE broadcast methodology of putting advertising packets on BLE’s channels 37, 38 and 39 to avoid conflicting Wi-Fi traffic in the 2.4 GHz Industrial, Scientific and Medical (ISM) unlicensed band.
Further, each pseudo-standard then uses the structure of the BLE advertising to embed their own formats and data. The same packet is generally sent on all three of the advertising channels every time the beaconing device advertises, making it more likely that a BLE receiver / scanner will pick it up. Once received, the scanner determines if the packet content is decodable and relevant, and then takes corresponding actions.
Within the advertising packet, the data payload is structured as one or more [length, type, data] triplets.
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.
Apple was an early beaconing adopter with its iBeacon. The iBeacon term is trademarked by Apple, and vendors who want to sell iBeacon products or use the iBeacon logo must obtain a free license from Apple. The iBeacon specification and other developer resources can be downloaded from the Apple Developer website.
iBeacon specifies a 30 byte packet which must be broadcast on 100 ms intervals (although iBeacon OEMs don’t always seem to adhere strictly to the 100 ms requirement). iOS Apps which use the Core Location framework can ask the iOS to continuously monitor for beacon-region-crossing events, i.e., entering or exiting the proximity of an iBeacon defined by the UUID, Major and Minor fields. The iOS monitoring takes place whether the app is running or not, and can even trigger a closed app to launch. Monitoring only works when the user has enabled Location Services for the corresponding app.
Eddystone is an open-source, cross-platform beacon format from Google. It supports both Android and iOS devices. Unlike other beacon standards, it defines several different frame types which can be used individually or in combination:
The Eddystone-URL frame enables mobile platforms to offer web content based on proximity without requiring an app to be installed, enabling what Google has dubbed The Physical Web, or the “ability to walk up and use anything.” Eddystone is already supported in Chrome for iOS, and will be supported in Chrome for Android beginning with version 49. With the Chrome Today widget, users can access web content relevant to their surroundings, and receive notifications when encountering beacons.
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.
Radius Networks defined the AltBeacon specification in an attempt to create an OS-agnostic, open-source standard which wouldn’t favor any particular vendor. The specification is available on the AltBeacon website and is free to use without royalties or licensing fees. Like other beacons, it uses non-connectable, undirected advertising packets.
Whitepaper on Developing with Bluetooth BLE Beacons
Our experts have put some very relevant information in a whitepaper on developing with Bluetooth beacons. The goal is to help you get to market quickly with the right, stable solution.
It covers a lot of territory: