At the beginning of the week Google launched Eddystone, an open source and cross-platform Bluetooth LE beacon standard. At first glance it looks a lot like Apple’s iBeacon, but there’s more going on here than meets the eye.
Two years ago at WWDC Apple quietly introduced the iBeacon as a way to add real world context to smart phone applications.
The iBeacon does exactly what you’d expect, it acts as a beacon, broadcasting a universal unique identifier (UUID) that can be picked up by a phone or other Bluetooth LE device. This identifier can be used to trigger a location-based action, such as generating a push notification on the user’s device. While not providing true indoor location capabilities, the beacons can therefore act as a proximity notification service.
However the beacons are limited, it can’t broadcast arbitrary information, just its UUID and a Major and Minor ID number — together the three numbers uniquely identify the beacon hardware — which must be mapped by your smart phone application to a location associated with that identity.
While there have been some interesting attempts to generate novel use cases for beacon hardware, some less successful than others, for the most part the beacons haven’t been used that much outside retail environments. Despite the intense interest surrounding the iBeacon technology, it hasn’t really gone mainstream.
In part this is because of the Apple’s infamous MFi Program. This is Apple’s licensing program for third party developers and manufacturers wanting to build accessories for the iPhone, while it doesn’t include Bluetooth LE accessories that use standard Bluetooth profiles, it does include HomeKit devices and Apple’s iBeacon technology.
Despite this, everything you need to replicate an iBeacon is right out in the open, as it broadcasts all the information you need to reverse engineer the beacon specification. As a result a lot of people sat down and wrote Android libraries to support the standard. However as time moved on, Apple cracked down on these developers and forced them to make changes and remove Android support. They’ve also forced hardware companies to sign up for licenses before distributing beacons — for instance iBeacon support for TI’s SensorTag hardware was yanked by the company soon after it was announced.
This in turn led to various initiatives, such as the AltBeacon standard from Radius Networks. However all of these basically copied the iBeacon, Eddystone — named after the Eddystone Lighthouse off the coast of Devon in England — does something different.
Eddystone is cross-platform, and open source, distributed under the Apache v2.0 license. While support is built into Google Play Services’ Nearby API on Android, it also has library support for iOS.
Perhaps more interestingly, it doesn’t work quite the same way as Apple’s iBeacon. Instead of just advertising a unique identifier, Eddystone also offers a second type of advertisement, a URL. Effectively, Google have created a broadcast version of the QR code, one at which you don’t have to point your phone, but instead one which can be passively consumed by everyone within range of the beacon.
The URL frame type is a lot more flexible than the unique identity, because instead of being a pointer to a back end database, uninterpretable by anyone except the company — and the app — that the beacon is associated with, a URL can be interpreted by any piece of software that can see the beacon.
But unlike Google’s previous attempt at a beacon standard, their Physical Web project, it doesn’t just advertise the URL frame. Alongside the UUID and URL frames, Google’s Eddystone can also be configured to broadcast two other types of information, an Ephemeral Identifier (EID) and a telemetry stream.
Information about these last two frame types is still a little bit thin on the ground, however the telemetry stream is supposed to help companies deploy a large number of beacons and then find,
Despite it being incompatible with Apple’s iBeacon, hardware manufacturers like Radius Network, bluvision and Estimote have rushed to support the new standard, and it’s going to be interesting to watch how this develops. Especially as the security implications of URL broadcast are more severe than broadcasting simple unique identifiers, and in the past some manufacturers’ beacons haven’t been that hard to reverse engineer and modify.
ADVERTISEMENT
