Google’s recent Eddystone announcement adds another heavyweight to the indoor
location-based services market. With beacon location support from the two
largest mobile ecosystem providers, Bluetooth Low Energy (BLE) beacons have
become the de facto standard for indoor micro-location applications. Let’s
investigate some of the nuances of the Eddystone format compared to Apple’s
iBeacon and highlight key items that organizations should consider while
deploying a nascent solution.
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.
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.
