Google’s Eddystone: Cross Platform Beacon Technology

Jul 31, 2015
Google Eddystone

Google recently launched Eddystone, an open source and cross-platform Bluetooth LE beacon standard, changing the mechanics of the Internet of Things (IoT). This technology is named after a historically famous lighthouse in English coast in the county of Cornwall.

What is the connection between beacons and lighthouse?

Think about it in real-world beacons guide users in the same way lighthouses guide ships and captains in the night. Beacons are transmitters that send information about a specific point of interest. This information is picked up by a smartphone or tablet in range of the transmitter.

But what is new about this technology? We have already got iBeacon, Apple’s iBeacon standard launched two years back. At the face, Google’s Eddystone looks like Apple’s iBeacon. However, Apple’s proprietary iBeacon technology works only for iPhones and other iOS devices in the same BLE space. On the other hand, Eddystone is open source and cross-platform capable of providing support to Android, iOS or any platform that supports BLE beacons. It’s available on GitHub under the open-source Apache v2.0 license for anyone to use and improve.

The open nature of Eddystone makes it a technology with the potential of being a game-changer.

Eddystone: Openness and Flexibility

Well, it is not just the open nature; Eddystone supports multiple frame types for different use cases, making it easy to introduce new functionality easily. Historically, Bluetooth beacons signify one-way communications with the primary goal of sending a notification capable of displaying or transferring information upon a tap. Due to support of multiple frameworks, vendors will be able to use Eddystone for different functionality or purpose.

It can broadcast three signal types: UUID (similar to the iBeacon standard), URL (a successor to the UriBeacon standard) and TLM (a new telemetry signal).

Universally Unique Identifier (UUID): This is a 128-bit value that can separately identify every specific beacon in the world, which an app can listen and perform actions for. For instance, you can walk in WalMart, your favorite retail store. WalMart could deploy beacons in its store. The Walmart app could be programmed to listen for specific beacons and send special coupons or such information.  The downside to UUIDs is that you need the appropriate app do anything with the information. This brings us to the second frame type.

URLs: With this capability, users don’t need to download app. The store can send a URL to the user’s phone and the consumer can look up the coupon or relevant information on a web browser. URL instead of UUID looks like a feasible option with universal appeal.  It works best for small businesses without a dedicated app.

Ephemeral Identifiers (EIDs): Privacy and security are the center point of this new technology. With Ephemeral Identifiers (EIDs), you can allow only authorized clients to decode them. While the technical specification of this feature will be released soon, we can be rest assured that this feature will allow users to do tasks in a secure manner.

Telemetry Data: This frame type would allow organization to manage their vast fleets of beacons. Beacons are battery driven and need batteries changed or fixed frequently. Telemetry frame type in sync with Proximity Beacon API can help deployers monitor beacons’ battery health and displacement.

Eddystone and Hardware Scenario

Due to extensible frame formats, Beacon hardware manufacturers can support multiple mobile platforms and applications with single hardware. Just with a simple hardware update, an existing BLE beacon can be converted into Eddystone compliant beacon. Eddystone is not just open, flexible and extensible, but also interoperable.  While there are several Eddystone-compliant beacon manufacturers, Google is also working on an Eddystone certification process.

Eddystone, Google, and APIs

Get ready for some highly contextual information from Google’s own products and services with beacons. Google Maps will use beacon-based transit notifications to provide faster access to real-time transit schedules for specific stations. Google Now will provide contextual information to prioritize the most relevant cards, like showing you flight times when you’re at an airport.

Now coming to APIs, Google will be launching a new cloud API called the Proximity Beacon API. This API allows you to manage and update the information associated with each beacon even after the beacons are deployed. This API also includes a diagnostics component to monitor beacon fleet and identify beacons.

Nearby API: This allows finding and seamlessly communicating with nearby devices and beacons. It uses BLE, Wi-Fi and even inaudible sound to establish proximity.

Eddystone and iOT revolution

Eddystone seems to align with Google’s emerging iOT ecosystem.

Weave – IoT protocol designed for the house. Uses Bluetooth LE or Wi-Fi for direct or cloud-based communication.

Thread – IP-based wireless communication protocol.

The Physical Web – Open Web specification for a beacon-delivered URL to interact with a nearby device in a Web browser.

Brillo – Android-based operating system for IoT devices.

Eddystone certainly is the step in the right direction from Google. Finally, an open-source and cross platform beacon technology. Let’s hope that companies and manufacturers invest in the hardware to generate value.

Written by Albert Smith

Albert Smith

Albert Smith is Digital Marketing Manager at Hidden Brains . An experienced search engine specialist, content, social media marketer and a technical enthusiast, Albert frequently writes on diverse topics such as social media marketing trends, web & mobile app development best practices. He has worked with some of leading brands to build their online presence and scale their businesses.