iBeacon: a lighthouse in your pocket?

In our last blog post, Beyond the Beacon: BLE Just Got Reel, we demonstrated an iOS7 device advertising its presence to our hardware infrastructure using Bluetooth Low Energy technology. For many reasons, as we will outline, we were very pleased to validate this functionality, which we were pleasantly surprised that Apple allowed. We spoke to Stacey Higginbotham about the possibilities of this beacon role-reversal which she summarized in her article Loophole in iBeacon could let iPhones guard your likes instead of bombard you with coupons in GigaOM.

Over a year in the making

We kicked off reelyActive at the start of 2012 with a vision to create a simple, accessible active RFID platform suitable for almost any application. Our previous experience in the field taught us that almost all of the applications we encountered boiled down to knowing the unique identity and location of the people and things in a space. This can be achieved by having the wireless devices in that space actively identify themselves to fixed infrastructure. Since the outset, we’ve been following the adoption of BLE since it enables active RFID for everything from inexpensive, low-power sensors to smart devices and beyond.

In the Fall of 2012 we participated in the FounderFuel startup accelerator where we were constantly asked “when will smartphones be compatible with your platform”. Due diligence revealed that the problems were manifold. First, even though BLE hardware was shipping in just about everything since the iPhone 4S and Galaxy S3, the operating systems of these devices provided no facility to leverage the radio for active RFID. Second, the BLE system-on-a-chip we required for our own hardware devices was only available in the form of engineering samples, delaying the development of our prototypes.

While Android 4.3 added BLE support, it did not support the peripheral role which allows the device to initiate the transmission of radio packets. However, iOS7 did support this role and introduced the iBeacon…

Enter the iBeacon

The iBeacon is analogous to a lighthouse: it represents a known location which can be uniquely identified by its signal. When iBeacons are installed in a space, they can be detected by smartphones to assist with indoor navigation or to trigger actions. The smartphone listens for iBeacons similar to how it listens for WiFi access points and GPS satellites to determine its location (see our blog post: Radio location demystified). Since GPS is poorly received by smartphones indoors, and WiFi was never designed for indoor location, beacons are a nifty way of improving the accuracy of location-aware devices like the smartphone. In the presence of beacons, the smartphone can determine its location with confidence and ease.

The interesting thing about iOS7 is that it allows the smartphone to act as an iBeacon. This means that the device can advertise its unique identity to its surroundings like a lighthouse. Of course, any BLE peripheral can advertise the services it offers, but the iBeacon is special as we will now explain.

Here’s the technical part

An iBeacon packet contains the following information:

• 48-bit random device address
• 128-bit UUID based on RFC 4122
• 16-bit major identifier
• 16-bit minor identifier

Based on our tests, the 48-bit random device address changes every 15 minutes, and there does not appear to be a means for an application to query this address. The other fields listed above are user defined. This means that an app could specify a 128-bit UUID which would be uniquely associated with the device indefinitely. Specifically, this allows the device to act as a glorified active RFID tag and requires only a few lines of code.

When run in the foreground, the app can allow the user to opt-in and enable the iBeacon with a tap. Based on our tests, this results in over 30 radio transmissions per second (per channel). However, when iBeacon is run in the background, there are two important changes. First, everything but the 48-bit random device address is dropped from the packet, and, second, the rate drops to about 5 transmissions per second (per channel). Even with the screen locked, we have found that the iBeacon continues to transmit packets indefinitely.

What does this mean?

It’s possible to create an app that allows compatible iOS7 devices to advertise their presence to their surroundings, and to be uniquely identified. The user is in complete control to opt-in or disable this feature in real-time. In the presence of BLE infrastructure like our reelceivers, the space itself can not only become aware of all the devices it contains, but also estimate their location. In other words, contextual awareness can be aggregated by the environment itself. We will present a scientific paper on this topic and the implications at the International Workshop on Identification, Information and Knowledge in the Internet of Things in Beijing in October.

If the app runs in the background, the device can still be identified and located throughout the space, generating potentially useful anonymous data. However it cannot be associated with a UUID (and hence user profile) unless the user brings the app into the foreground. The periodic random device address changes cause discontinuities which may nonetheless be stitched by a clever algorithm under favourable conditions.

How is this better than the standard iBeacons use case?

It isn’t. Both use cases have their merits. What we’ve presented concentrates contextual awareness with the space itself, rather than in the smart device. This favours interactive applications where the environment reacts to the presence and movements of the people and things it contains. It also works seamlessly even when the device loses internet connectivity, and it is battery-friendly. Periodically transmitting packets consumes a fraction of the energy required to listen for iBeacons, WiFi access points and GPS satellites, and offloads the computation of location to the fixed infrastructure.

Thinking ahead to the tens of billions of devices expected to comprise the Internet of Things, a non-negligible fraction of which may use BLE, there’s nonetheless a strong argument for installing infrastructure that provides both ambient network connectivity and beacon capability.

A quick conclusion

In a perfect world, there would be a facility for any BLE device to transmit BLE advertising packets with a UUID or accessible random device address at an appropriate rate (5-30Hz is overkill: for many applications one transmission per second is sufficient). Nonetheless, we’re pleased that Apple has enabled (whether intentionally or not) the active RFID use case we present despite the constraints we’ve identified. With any luck, soon all mobile operating systems will provide the necessary functionality for the world to enjoy interactive, contextually-aware spaces through experiences like Log in to Life.