Meet Google’s “Eddystone” — a flexible, open source iBeacon fighter
By Ron Amadeo, ARSTechnical.com
Move over iBeacon—today Google is launching "Eddystone," an open source, cross-platform Bluetooth LE beacon format. Bluetooth beacons are part of the Internet of Things (IoT) trend. They're little transmitters (usually battery powered) that send out information about a specific point of interest, and that info is then passively picked up by a smartphone or tablet in range of the transmitter. A beacon-equipped bus stop could send out transit times, stores could send promotions to the customers currently in the store, or a museum could send people information about the exhibit they're standing in front of.
The name "Eddystone" might sound a little weird, but Google says it's named after the Eddystone Lighthouse in the UK. The motif is that beacons guide users and apps in the real world the same way lighthouses guide ship captains in the night. Being an open source project, they wouldn't want to name it "Google Beacon." It fits in well enough with the other non-obviously-branded open source Google projects like Android, Chromium, or Dart. This also isn't something they need to sell to the general public, just beacon OEMs and app developers.
We were able to talk with Eddystone's Product Manager, Matthew Kulick, and the Engineering Director, Chandu Thota, about the project. They described Eddystone as a "robust, extensible" beacon standard. "We have been working with many of the ecosystem partners to figure out the actual use cases, and we realized that existing solutions only partially address what is being asked for. We wanted to pull in businesses, developers, and the manufacturers and create an ecosystem that they can rally behind," Thota said. "There was a real desire from talking to them for a unified common ground that could be openly discussed, improved, and built on top of," Kulick told Ars.
Like iBeacon, but more open
At this point some of you are likely saying, "This already exists! It's called iBeacon!" Apple's two-year-old iBeacon standard has a number of problems though, the main one being that it's a proprietary standard that only works with iDevices. This mean it's cutting out half of the US smartphone market and 80 percent of the worldwide smartphone market. When you're hoping to recruit companies to use this to advertise to their customers, immediately missing 50-80 percent of the possible customer base is a tough sell.
Eddystone is cross-platform—support is built into Google Play Services' Nearby API on Android, and it can be used via a library on iOS. Eddystone is also open source and is available on GitHub under the Apache v2.0 license (we'll update with links later once this all goes live).
The openness of Eddystone is the big differentiator. In contrast, Apple is so protective of iBeacon that when one company, Radius Networks, got iBeacon support up and running on Android, Apple contacted them and had the product shut down.
Frame Types: Eddystone gets flexible
Eddystone's other big differentiator is that it supports multiple "frame types"—basically data payloads—that can perform a variety of functions. Previous solutions from Apple (iBeacon) and Google (The Physical Web) have only served one purpose.
Bluetooth beacons are one-way communications, so usually the goal is sending a notification that, when tapped on, will launch a more capable form of displaying or transferring data. "Because Eddystone is comprised of these different frame types, you'll see different beacon vendors using Eddystone for slightly different purposes," the Eddystone team told us.
Universally Unique Identifier (UUID)—A UUID is a 128-bit value that separately identifies every specific beacon in the world, which an app can listen for and perform certain actions for. For instance, imagine if Starbucks deployed beacons to all its stores. The Starbucks app could be programed to listen for these specific beacons that Starbucks owns, knowing which store (and sometime where in the store) the user is at from the beacon ID in order to then do something—send coupons, connect to Wi-Fi, or whatever else you can think of (and have user permission for).
A UUID is exactly what Apple's iBeacons send out, but iBeacon can only send this type of information. Eddystone's other frame types make it much more flexible. The downside to UUIDs is that they are tied to developers (like Starbucks) so you need the appropriate app do anything with the information. This brings us to the second Eddystone frame type.
URLs—Sending a URL instead of a UUID is much more universal and friction free—it just opens in a Web browser. While a loyal Starbucks customer may have no problem keeping the Starbucks app installed, a user standing in front of a soda machine really doesn't want to install a special app to just buy a soda. For those one-time data transactions, you'd want a URL.
URLs are basically the "QR Code" version of a beacon. The advantage over a QR code is that you don't need a QR Code reader app, and you also don't need to see, target, and take a picture of a QR code. With beacons, the URL finds you. A beacon-delivered URL could be broadcasted to everyone in a restaurant without needing a million QR codes plastered over the restaurant.
Google has a project called "The Physical Web," which accomplishes a similar thing—broadcasting URLs from a Bluetooth beacon. This has the same inflexibility problem as iBeacon, in that it only sends this one frame type. Again Eddystone is a more flexible, unifying standard that also covers this use case. The Physical Web project will actually be switching from its current "UriBeacon" standard to the new Eddystone-URL frame type.
Ephemeral Identifiers (EIDs)—An EID is a secure frame type—imagine a personal beacon that only authorized users can read. Google doesn't offer many details about this new frame type other than to say will "change frequently and allow only authorized clients to decode them." The company says this would be for things like finding your luggage when you get off the plane or finding your lost keys.
Beacon technology can tell how far away the user is from a beacon, making this a more high tech version of the Motorola Keylink, which just helps you find your keys by beeping really loud.
Telemetry Data—This last frame type is for companies that need to manage vast fleets of beacons. Beacons often run on battery power, meaning the batteries need to be changed, so the telemetry frame type would send diagnostic data and remaining battery power to your friendly neighborhood IT person. They could then hunt down the broken beacons and fix them.
The Beacon Ecosystem
If you're going to make a beacon standard, you're going to actually need manufacturers on board, and Google already has a several companies signed up to use Eddystone. To get the ecosystem side of the story, we talked to Marc Wallace, the Co-Founder & CEO of Radius Networks. Radius is the very company that saw the need for a cross platform solution, implemented the "iBeacon for Android" library, and drew Apple's (temporary, we're told) ire.
As for the big difference between Eddystone and the other beacon technologies, Wallace said, "The difference with Google... there's some technical differences. They're supporting some other frames in the advertisement of the beacon, which can support other use cases. There are the URL components, app support, and telemetry support."
Wallace told us that developers and companies won't need a bunch of different boxes to support Apple and Google's competing beacon standards. All of Radius Networks' devices will supports iBeacon, Eddystone, and AltBeacon, Radius's own open source beacon standard. In fact, current beacon devices could work with Eddystone with just a firmware update—it's all just Bluetooth. The downside is that you won't be able to run iBeacon and Eddystone at the same time from a single beacon.
While Google is developing the beacon format, it is leaving things like beacon hardware, management software, and other solutions up partner companies like Radius Networks. Simple beacons cost as little as $10 or you can download an app to turn your smartphone into a beacon.
The fun stuff: Eddystone support in Google's Ecosystem
Hardware and communication standards are nice and all, but they're nothing unless you have some cool software that does something with it. Google will be leading the charge with Eddystone app support.
Google Maps already ran a pilot program earlier this year in Portland that used beacon-based technology to pull in real-time transit schedules and notifications, and now it will be able to expand the program. The notification would jump the user directly to the transit schedule in Google Maps.
These beacon notifications, by the way, aren't the same type of loud, beeping, vibrating notifications you would get for a text message. They're silent notifications, which Android currently uses for passive things like weather info from Google Now. The messages would quietly show up in your notification panel and could be swiped away if you weren't interested (Apple's beacon notifications in iOS are similarly passive, showing up in the lower-left corner of your lock screen when you're within range of a beacon).
The company also says that "soon" Google Now will be able to use contextual information from beacons to surface the most relevant cards, like restaurant menus when you're inside a restaurant. This is something that Google Now could sort of guess at with GPS location, but it's very power hungry, doesn't work indoors, and isn't very accurate in business-dense cities. Imagine two bus stops across the street from each other; GPS wouldn't know which stop you were at, while beacons are precise enough to know which you are closest to.
As for the API side of things, Google will be launching a new cloud API called the "Proximity Beacon API," which allows them to register beacons and associate data to the beacons in the cloud. On the client side, Eddystone support will be rolled into Google's Nearby API which, along with picking up Eddystone's Bluetooth LE signals, will implement the packet parsing, frame formats, and all the necessary reception "glue" to make the system work. In Android, the Nearby API is part of Google Play Services, so every Android phone running Android 2.3 and higher able to listen to Google's beacons. For iOS, Google has a Nearby API library that developers can include with their app.
"With the Nearby API, just like we could unify and build consistency on the hardware side, we are hoping with Nearby to do the same thing on the client site." Kulick told Ars. "We wanted to offer something a little higher level, which everyone has to spend time doing anyway, which isn't really what they're differentiating on, like parsing packets, setting up background listeners, and stuff like that."
While Eddystone, the beacon format is open source. However, Google's recommended method of receiving these frame formats is not. Google Play Services, the Nearby API, and the Proximity Beacon cloud service are all proprietary. It seems that Google is again following the Android/Google Play Services model, where the platform is open source, but for the best experience you also need some proprietary bits from Google. Besides the ready-made APIs, going the Google Play Services route gets the bonus of better battery life. Play Services serves as a single app that monitors the Bluetooth connection for beacons and alerts the appropriate apps, as opposed to every single app individually lighting up the Bluetooth connection to search for beacons.
Google gets the best of both worlds here. As an open source project, Eddystone gets lots of hardware support from vendors, but if developers want to give users the best experience and have an easier time themselves, they have to submit to the walled garden. Eddystone doesn't need to be tied to Google though, and if developers want to use their own cloud solution or client API, they can. It's Bluetooth, so really anyone could listen to Eddystone devices, but living outside of the Google Ecosystem just means doing a little more work.
The big picture: Google's IoT lineup
- Eddystone—An open-source beacon format designed primarily for public use and to blast out information to everyone in range. Uses Bluetooth LE (Low Energy) for direct, point-to-point communication.
- Weave—A proprietary IoT protocol designed primarily for the house and to be secure and private. Uses Bluetooth LE or Wi-Fi for direct or cloud-based communication.
- Thread—An IP-based wireless communication protocol. Competes with Bluetooth LE, ZigBee, and Z-Wave for direct communication.
- The Physical Web—An open Web specification for a beacon-delivered URL that lets you interact with a nearby device in a Web browser. The Physical Web will switch from its own UriBeacon technology to Eddystone URLs, so these are kind of merging.
- Brillo—An upcoming Android-based operating system for IoT devices. This lightweight OS would run on smart door locks, light bulbs, and other home appliances. From what little we know about Brillo, it seems like it could theoretically run on a beacon.
Remember this is Google, so we're probably not looking at a cohesive group of projects that are all supposed to work together. The company has consistently built two of everything, after all. But Eddystone sounds like a very promising project. We'll finally have a well-supported, cross platform beacon technology. Now we just need businesses, transit authorities, and other companies to invest in the hardware.