Google takes on iBeacon with open-source Eddystone

Google has announced Eddystone, an open-source platform for Bluetooth LE devices that will enable communication capabilities with smartphones and other smart devices – and will also directly compete with Apple’s iBeacon. Beacons are an important piece of the IoT puzzle, and have the potential to enable vastly more contextual services in the physical world. Beacon technology essentially allows low-power Bluetooth devices to transmit information to smart devices. Beacons cannot track your smartphone, but your smartphone can detect the beacon and receive data from it. Depending on what you’ve allowed and your apps, the beacon information can trigger something to happen.
When Apple became the first ecosystem player to integrate beacon capability into iOS 7, the initial uses were primarily retail-oriented, and analysts were heralding potential “revolutions” in brick and mortar retail. Indeed, iBeacon has seen adoption in retailers like Macy’s and Lord and Taylor’s, as well as select Starbuck’s and McDonald’s locations. In most of these applications, the beacons are used to transmit information about location and perhaps time specific specials or other information.
The results have been mixed so far. McDonald’s noted success in uptake of offers for specials on chicken sandwiches. Starbuck’s customers with iOS 8 could see an icon on the lock screen for their Starbuck’s app, which they can then swipe up to go directly to the app and pay for their purchase. In more interesting contextual applications, Virgin Atlantic Air ran a trial at Heathrow airport using iBeacon to detect customers approaching the gate, and their phones could automatically display the boarding pass in their app. They also offered deals on inflight entertainment and currency exchange services. In general consumers may not notice that beacon technology is being used. And the consumer has to opt in a number of permissions for these things to work, be it using a specific app, giving it permission to display offers, and sharing location data.
Like Apple, Google is taking a platform approach with Eddystone, but as it’s open source it makes it accessible to use on any platform. While the beacon hardware is available from various vendors and Apple doesn’t make any (yet), Apple has restricted iBeacon to iOS. Given the obviously huge market share of Android mobile devices, iBeacon is missing a large addressable market. This isn’t Google’s first attempt at it; the open source Physical Web project enabled beacons to transmit URLs. These URLs could be used by any browser and could provide various forms of contextual information.
Both Apple’s iBeacon and Google’s Eddystone work similarly in that beacon devices transmit information. In iBeacon, Bluetooth LE devices transmit a 128-bit UUID (Unique Universal ID) which is unique to each device in the world. The apps can then use this information to present contextual information or do something, depending on the permissions the user has allowed. Beacons don’t track users or have the ability to receive any data from users, apps in a smartphone (or smart enough wearable) detect the beacons, receive data broadcasted from it, and do all the work connected to cloud based services.
Eddystone goes a step beyond iBeacon by defining a protocol implementation that allows for several frame types. Eddystone-UID is the format for defining the unique device ID, allowing applications to map that beacon to specific services or information. Eddystone-URL defines a frame for sending compressed URL information to a device. The URL method allows for a very open approach that allows for contextual information without the need for a specific app. Eddystone-TLM allows the beacon device to broadcast information about itself, like its battery status, temperature, and the amount of packets sent. Google has developed a REST Proximity Beacon API that allows for managing the beacons, including associating data with each beacon or groups of them, and allowing access to the telemetry data for management. For Android and iOS applications, the Nearby and Places APIs will be able to access beacon data like latitude and longitude, indoor floor location, and Google Places ID.
With its open-source approach, Google is allowing for more flexible approaches. One example it used was when you are looking at a piece of art in a museum. With a beacon, you could be alerted to more information about that art. If implemented with Eddystone URL, the user could have an easy way to access that contextual information in a browser without cluttering up his or her device with yet another app. Since it’s open source, the developer community can add to the specification and increase its capabilities.
Can Eddystone become the de facto standard for contextual information and services? Time will tell as developers start building applications. With firmware updates, beacon device manufacturers like Radius Networks, Kontact.io, and Estimote will support both formats. The real competition isn’t in defining the information formats that these devices will transmit; it will be in the APIs and services offered in the platforms both on iOS and Android and in the cloud services. In that sense, it’s possible that Apple could simply take advantage of the open source nature of Eddystone and work within it, while both Google and Apple keep other parts of beacon technology proprietary.
Google’s entry into this area will promote more competition and stimulate adoption, which should mean more and better contextually aware applications and services becoming available. For the most part, we probably won’t notice there are beacons around – our apps will just work better, and information will be easier to find when we want and need it.