Comparing Google’s Eddystone beacon technology to Apple’s iBeacon
The main driver for beacons is the search for a suitable indoor positioning technology for mobile devices, enabling real-time navigation and location awareness for mobile apps. Through the iPhone era, we have tested the limits of the established handset technologies: GPS, inertial navigation, cell tower triangulation, and Wi-Fi (Basic Service Set Identifier -- BSSID) scanning. We know their capabilities, both individually and as a group. Indoors, Wi-Fi technology can provide adequate location presence but for use cases requiring real-time, precise location updates, another solution is needed.
Then along came Apple’s iBeacon, the first standardized implementation of a BLE beacon. Sensing an iBeacon on a mobile device is in many ways similar to sensing a Wi-Fi access point; we use signal strength and the signal-distance characteristics to calculate location. However, the substantive differences in approach relates to packaging and implementation. BLE beacons are portable, fully cordless and inexpensive. As a result, a BLE beacon solution designed for location is significantly cheaper and less complex to install compared to an equivalent Wi-Fi based solution.
Additionally, beacons present a huge real-time accuracy advantage, since location is calculated by the app monitoring beacons that continuously transmit, instead of a Wi-Fi infrastructure waiting for a handset to awaken from variable power-save windows.
Because of these inherent advantages, iBeacons have quickly gained traction for indoor positioning. Not to be outdone, Google recently entered the Beacon arena with Eddystone, which claims to extend capabilities supported in Apple’s widely adopted iBeacon protocol.
With Eddystone, Google was looking for a better way to push notifications to clients without the need for an app, as well as the ability to manage beacon deployments. To achieve this, Eddystone is designed to support multiple new data packet types, including Eddystone-UID, Eddystone-URL, and Eddystone-TLM.
Eddystone-UID is similar to iBeacon in that it identifies a beacon and allows an app on a device to trigger a desired action. Eddystone-UID is somewhat different from iBeacon in that it is 16 bytes long (iBeacon is 20) and is split into two parts (iBeacon is 3).
Eddystone-URL sends a compressed URL to the mobile device, relying on Android 5.0 or higher to process push events instead of a dedicated app. On iOS devices, users must install the Chrome browser and enable notifications, so an app is still required. As of now, Android users have to open the notification center to check for nearby Eddystone-URL beacons, making it more of a Pull rather than Push notification. Unsolicited, push-based notifications can present phishing risks, although Google mitigates the risk by brokering all transactions, retrieving site titles and description meta tags and embedding them in the notification. This ensures that users know what site they are about to visit before clicking through a notification link.
While Eddystone-URL may seem interesting, its cross-platform caveats and recent privacy concerns around potential implementations, as highlighted in Google’s Here project, will limit its appeal.
The third data packet type is Eddystone-TLM. Short for telemetry, TLM sends health and statistics data such as battery voltage, beacons temperature, uptime, and number of packets sent to the applications developer. This is a one-way, best-effort communication and could help venues monitor their beacon deployments. Presumably, an Android client must be in direct proximity to the beacon for Eddystone-TLM to update the cloud with health telemetry. While it does not allow you to update or modify the data being sent by the beacon remotely, it is a step in the right direction.
Google’s first crack at Eddystone tells us that more BLE innovations will likely be coming. For early adopters looking to reap the massive benefits from micro location-based services, a BLE beacon infrastructure that can be centrally monitored and managed with firmware updates is an absolute necessity. Most significant is Google’s acknowledgement that indoor location positioning based on BLE technology is no longer a fad and is here to stay. With some prominent BLE beacon deployments in existence, Google can no longer have Apple solely control the future of this space.
Ni leads the vertical marketing solutions team at Aruba Networks and has 15 years of experience with mobile technology. He joined Aruba in 2014 from Goldman Sachs where he had global responsibility for the firm’s mobile infrastructure and computing platforms. ani@arubanetworks.com, Twitter: @alanjni