Bluetooth Low Energy (BLE) is almost certainly the future technology for indoor navigation. This is not due to any technological superiority: rather, it stems from the design choices of one device maker. But BLE implementations are already diverging into two competing camps, splitting the market and forcing difficult choices on app and infrastructure developers.
We need an indoor location technology for mobile devices in order to enable mapping and navigation apps, and also many other apps requiring location context. Early smartphones used Wi-Fi for indoor location, identifying nearby access points by their periodic beacons and estimating distance from signal strength measurements. This allowed startup companies to build some good turn-by-turn navigation apps for Android and iOS.
But in 2010, Apple shut off the APIs that apps used to access Wi-Fi scan information. iPhone apps are now blind to the Wi-Fi environment. This appears to be a deliberate commercial decision: it is difficult to see any privacy or security justification.
To fill the navigation gap, Apple introduced the iBeacon in 2014, the first standardized implementation of a BLE beacon. Sensing an iBeacon on a mobile device is similar to sensing a Wi-Fi access point: it uses signal strength, and the signal-distance characteristics are quite similar to Wi-Fi signals. But it’s the commercial considerations that are perhaps more interesting than the technical.
iBeacons are bound to specific apps. When a beacon is placed, the owner knows what it is to mark and logs that information, usually in a private database in the cloud, binding its context to a beacon ID number. Only the ID is transmitted over the air: an app must consult its private database to find what its beacon is marking. A different app seeing the beacon would be able to read the ID number but not find any context information.
This has the effect of giving an individual iBeacon significance to a single app. If several different navigation apps are used in a given space, they will each need a set of iBeacons, as information about the beacons is not globally available. This is just one example of wrapping proprietary features around the underlying standard BLE technology. One could argue that something like the iBeacon standard was necessary to lift the whole market, but the number of wrinkles and caveats in the iPhone implementation is large.
Meanwhile Google has taken a different tack with BLE beacons. Using the same underlying BLE technology, the Eddystone beacon can transmit more information than an iBeacon, specifically a URL which has global context. But Eddystone has its own set of limitations and there are signs it will become entangled in Google’s other properties, including Maps and the Nearby discovery and proximity framework.
So in order to implement good turn-by-turn navigation apps for a broad user population, a developer must discard Wi-Fi because there is no iPhone support, and then decide which of the two BLE beacon models to implement, given their different characteristics and uneven support on iOS and Android.
Meanwhile the Wi-Fi Alliance will launch its new location certification at the end of 2016, and this should be an attractive alternative technology for indoor location. But it is uncertain whether both major OS vendors will extend support and provide app APIs for this new capability. It is surely a pity that promising technology may not become widespread due to commercial and competitive considerations rather than technical merits.
What does all this mean for networks and WLAN vendors? The inexorable drive for navigation apps to use iBeacons and Eddystone beacons suggests enterprise wireless infrastructure must quickly embrace BLE. Expect to see BLE beacons, beacon management systems and BLE-assisted navigation apps from the major WLAN vendors and their ecosystems. But this still leaves significant implementation choices in terms of beacon protocols and their respective ancillary ecosystem capabilities.
This article is published as part of the IDG Contributor Network. Want to Join?