• End customers benefit through instant coupons and tailored offerings based on where they are.
• Businesses benefit through improved visibility to customer buying habits and increased loyalty.
• Industrial companies benefit through improved asset monitoring and utilization.

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:

• Apple’s iBeacon;
• Google’s Eddystone; and
• Radius Networks’ AltBeacon.

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.

• 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.

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’s iBeacon

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 theApple 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.

Google’s Eddystone

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:

• Eddystone-UID which broadcasts a unique beacon ID;
• Eddystone-URL which broadcasts Uniform Resource Locators (URLs);
• Eddystone-TLM which can be used to broadcast telemetry (health and status) data about the beacon itself; and
• Eddystone-EID which uses ephemeral (short lived) identifiers for beacon applications requiring more security. The specification for this frame format has not yet been released.

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.

AltBeacon

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:

• We examine beacon applications to help you brainstorm some of your own.
• We provide a short history of Bluetooth and its derivatives, including Bluetooth low energy and beacons.
• We cover the leading beacon pseudo-standards in detail.
• We provide references to field-hardened example code and tools to develop and deploy it.
• And we provide information on end-to-end solutions to get you started.