Beacons are a new type of energy efficient, broadcast-only Bluetooth Low Energy (BLE) device that promises to add location awareness to our apps. These cheap, small and long lasting broadcasters transmit small packets of information at regular intervals. This data, usually a unique identifier, can then be picked up by smartphones and other Bluetooth-enabled devices to enable contextual awareness.

The concept was pioneered by Apple’s iBeacon, but now Google has jumped into the fray with the Eddystone beacon format. Whereas iBeacon only transmitted a simple UUID, Eddystone adds the ability to broadcast URL information and telemetry data. Is Eddystone a better beacon standard? Or will iBeacon rule the day?


Introduced in 2013, Apple’s iBeacons started the buzz around beacons. Taking advantage of Bluetooth Low Energy’s broadcast-only mode, a beacon is a BLE device that doesn’t pair with other devices but simply transmits data at regular intervals to all listening devices in the vicinity. While the inability to pair seems like a handicap at first, it has its benefits. Without the need for the energy-consuming pairing process, beacons can last for months or often even years without replacing batteries.

While a beacon could technically transmit data packets of any type as long as it conforms to BLE’s advertising packet format, Apple’s iBeacon standardizes the data format and transmission interval, making it easy for iBeacon hardware to be used by compatible mobile apps.


Figure 1: The main payload of an iBeacon device is its UUID, Major, Minor, and Tx Power

The iBeacon payload consists of the iBeacon prefix, a data length, then a UUID, Major, Minor and Tx Power value. The UUID usually identifies the company and store or building the beacon is located in while the Major and Minor further distinguish the specific area the beacon is located. Tx Power is used to calculate distance of the beacon from the listening device, used for ranging applications.

Even with this extremely simple payload, iBeacons can enable surprisingly powerful applications. Once the unique identifier of a specific beacon is associated with a location, apps which detect the beacon can benefit from contextual awareness.

Location can be precisely identified indoors where GPS isn’t available, allowing users to be pinpointed on a map. Restaurants can automatically identify which table placed an order by the location of the waiter’s tablet. iBeacons can also act as interfaces for home automation, turning on and off lights or air conditioners when users enter or leave a room.

Besides being mounted in stationary locations, iBeacons can also be implemented as stickers for mobile, everyday objects like bicycles or pet collars. This allows for applications like tracking or geofencing a pet using a collar with a beacon, or locking and unlocking a computer when a beacon is nearby.

While simple in design and payload, the location awareness that iBeacons provide can add a lot of value to mobile and even desktop apps by connecting the real world to the cloud.


Seeing the potential of beacons, in 2015 Google came out with EddyStone, their own, open-source beacon standard. Eddystone improves on the strengths of iBeacons, adding additional broadcast data types, and also addresses its weaknesses, allowing app-less beacon functionality and enhancing security through ephemeral IDs.

Just like iBeacon, Eddystone beacons can transmit unique identifier which can be looked up by an app to provide context, however while iBeacons are meant to be associated with location data, Eddystone’s close integration with Google’s Proximity Beacon API expands its basic UUID functionality beyond that. The API connects with a cloud-based repository that associates beacon unique identifiers with data “blobs”, which can be any kind of useful application data (within size limitations).

Besides iBeacon-style unique identifiers, Eddystone beacons can also broadcast URLs which can be interpreted natively by Android OS, or by the Chrome browser on iOS devices. This overcomes the main hurdle to iBeacon adoption, which was that users have to download an appropriate app to take advantage of a beacon.

With Eddystone’s URL broadcasting capability, a beacon at a bus station, for example, can send any user with a simple BLE compatible smartphone running Android or the Chrome browser to a page showing the next available bus.

Compared to iBeacons, Eddystone beacons are also easier to manage as they are capable of transmitting telemetry data – battery voltage, temperature, number of frames sent, and other information meant to help monitor the condition of a beacon. These TLM frames are generally interleaved with either the Eddystone UID or URL frames to provide simple, remote monitoring of beacon health.

Finally, Eddystone has recently announced support for Ephemeral IDs(EIDs) which brings a new level of security to beacons. These EIDs are a secure form of unique identifier. The encryption key used for generating EIDs is generated and exchanged at provisioning time. EddyStone beacons using this mode will regularly change the encrypted EID they transmit, preventing UID spoofing. To use the EID, an authorized application can look up the EID similarly to looking up a UID, to find usable data.


Figure 2: Laird’s BL600 Modules can be programmed with SmartBasic, making it easy to create iBeacon or EddyStone beacons

While Google has been late to the game, its EddyStone beacon standard is very well thought out, improving on iBeacons in almost every single way. The one advantage that iBeacons do certainly have over EddyStone is its first-mover status; for better or worse iBeacons have been around longer and are still seen as the face of beacons. This means, when faced with the decision to support iBeacon or EddyStone, the answer may very well be “Why not both?”