This article kicks off a series of blog posts that will focus on the possibilities and limitations of Apple’s iBeacon system. Introduced in iOS7, the Bluetooth Low Energy based micro location system is available for all iOS devices (starting from the iPhones 4S, 3rd generation iPad).
As I wrote back in August 2013, Apple’s new iBeacon system promises to offer developers an easy (fast to develop) and cheap (hardware) solution for adding contextual information to micro locations. The hardware components (“beacons”) are small Bluetooth Low Energy (BLE) transmitters which can be put anywhere you want to provide the contextual information. Since the underlying technology only relies on BLE, any compatible device can actually detect the beacons (BLE is also supported by Android 4.3 and higher). However, we will focus on the Apple implementation, as besides the hardware beacons themselves, the main part of iBeacon is on the software side in iOS.
The reported potential use cases for iBeacon typically span a wide range of interactive applications for museums, city tours and shopping experiences. Without the need for GPS, app users could view location relevant information on exhibits, be guided around a city tour, and get notifications for deals while walking into or past stores. Well, that’s the theory…
We’ve read a lot of articles covering these different potential use cases. They tempt the reader with attention grabbing headlines like “How iBeacons could change the world forever”, but offer very little in the way of hard facts relating to the real-world usability for the iBeacon system. Perhaps it’s too early to know, as the larger projects are only just starting to roll-out now. But at the moment, we just don’t know how well they will work in practice, especially as the current public version of iOS (7.0.4) has some issues surrounding the iBeacon framework.
To evaluate which of the often cited use cases are really possible for an iBeacon system, it’s important to identify the current capabilities and limitations of the technology.
That’s why in this series of articles we want to look in detail at some specific use cases and determine the right ways of using the system, and reveal what is realistically possible and what is not.
First, we will focus solely on giving you an overview of the iBeacon system and where the different emerging beacon providers, with their custom SDKs come into play. When talking about the advantages and selling points we will also give you an idea about what limitations might influence the usability of the system for different use cases.
1. iBeacon System
The iBeacon system from Apple can be broken down into three parts:
A piece of hardware – the “beacon”, which constantly broadcasts a Bluetooth Low Energy signal. This transmits a unique identifier (UUID) and two further identifiers; major and minor (unsigned 16 bit integer values), which can be used to identify the beacon.
API additions to the CoreLocation API to search for beacons with a certain UUID and optionally a specific major and minor value. iBeacon adds the possibility for the developer to subscribe to beacons like you would subscribe to geolocations. This enables the app to get notifications (whether the app is currently running or not) when the user gets within range of a specific beacon.
Possibility to use CoreBluetooth API to broadcast as a beacon – with a specific UUID, major and minor values. So, besides the separate hardware beacons, any iOS 7+ device (iPhone 4S and newer) can also act as a beacon (although only while the app is running in the foreground).
The hardware beacons come in various shapes and sizes. Whilst there’s still a fairly limited number of manufacturers, there’s already a variety of designs. We’ve managed to get our hands on some – here’s one of each type we have, ready for testing:
From left to right: Two different examples of unbranded beacons we ordered directly from Chinese manufacturers, the second of which appear to be the same as the ones Sensorberg are using. Next are the Qualcomm Gimbal Beacons, and last in line: our long awaited Estimote beacon.
2. iBeacon’s advantage over existing technologies
You may be wondering what the fuss is about? There are already solutions for finding the location of a mobile device, right? For example, GPS immediately comes to mind. However, GPS does not work well indoors and when running at it’s most accurate position level, consumes a lot of power without reliable enough data for micro location. Alternatives like WiFi and NFC already offer a way to gather the device’s position at a micro location level. But this is where two very important characteristics of BLE come into play: BLE’s very low power consumption, compared to the rather energy hungry WiFi, and the wide signal range (around 50m) when compared to NFC (around 5cm). A detailed study can be found here.
But that’s only part of the story. The more important part is that the iBeacon system offers the possibility to subscribe to beacons (micro locations) and get notified even when the app is not running in the foreground and the device is not even active (sitting locked in your pocket). Thats something no other micro location technology (in the restrictive iOS world at least) is capable of.
So, the main selling points of the iBeacon system can be split into two categories:
Determining when a user is within range (up to ~50m) of a specific beacon indoors or outside, whilst the app is running in the background.
Generating an approximation of the distance to one or more beacons, whilst the app is in the foreground or background.
However, in reality…
Both categories above depend on certain factors to determine which use cases they are appropriate for. The near field positioning part depends on the ranging precision and the time it takes to determine the current position. When the precision for determining the distance is not good, the use is limited to rough estimation, and one could not tell whether a user is standing in front of a particular product on a shelf for example. If it takes too long to get the position, the user might walk past a location or item before he can be notified of its existence.
The reliability of notifying the user when he gets close to a certain beacon is a crucial question, and comes down to how reliable and fast an app gets notified – especially when running in the background.
3. Where the beacon providers’ services come into play
If you want to integrate business rules for the interaction with your beacons you can hard code these inside your app, which obviously means you cannot change these rules and notification messages without updating your app.
This is fine if the information you want each beacon to represent does not change over time in a way you cannot predict beforehand.
If this is not the case, you need a backend to manage the business rules for the beacon interactions. This has the advantage that you can constantly change the way the user interacts with the beacons. For example you can change the notifications the user gets at certain beacons or whether he gets notified at all. The disadvantage of this is of course your user needs a connection to your server for the app to receive the current information for the beacon.
Several of the beacon hardware providers (Qualcomm with their Gimbal beacons, or startups like Sensorberg and Estimote) are providing their own SDK and backend for this configuration. This of course makes them the required mediator for your interaction with the beacons. The way they would like the beacon interaction to happen is depicted below:
The orange parts are beacon provider specific, whereas the red parts are client logic within the app and also on the backend server side, where the client can configure the business rules for the interaction with each beacon.
Since every interaction runs through their backend, they can gather a lot of information and can potentially offer user profiles for even more specific targeting (Qualcomm on their Gimbal website call it “Interest sensing”).
Public vs. private beacons
Depending on your app and what you are using your beacons for, you might want to either make your beacons openly available (to enable other apps to also interact with them) or restrict the access only to your app.
Each beacon can thus either be private (non-openly published identification) or public (openly published identification). For the public type, anyone can subscribe to, and add logic for interaction with the beacon. For example, a fast food chain would most likely use on-site beacons to trigger promotions in it’s own app, but also enable other apps (like social networking) to use the beacons to determine that the user visited a specific location.
For the beacon provider, having a big network of openly available beacons and offering a hub for the information about them, adds a big advantage for developers who not only want to add interactions on their own but also on other openly available beacons.
For most use cases we can think of, the most interesting and unique selling point is being able to trigger a user notification based on their location – indoors or outside, whilst the device is locked.
The second one is the ability to determine the user’s position indoors, which could be achieved before, but iBeacon offers advantages since the hardware beacons can be produced quite cheaply and installed anywhere with ease.
I mentioned that the usability of the notification part depends upon the timely response of the app when it gets within, or out of range of a beacon. Also, determining more precisely the user’s position depends upon the quality of the distance information you get.
In the next article we will take a look at how well these two features are supported using our selection of hardware beacons. This will help gather some real evidence on whether the iBeacon hype is deserved.
So stay tuned – we’re already cooking up some interesting tests with our beacons! We’ll also explain why we had to put this Estimote beacon in the office Microwave
(This blog post is also available in German)