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.

Beyond the Beacon: BLE Just got Reel

We are very pleased to announce the successful integration of mobile devices with reelyActive infrastructure using Bluetooth Low Energy (BLE) technology. Watch the video above to see an iPod advertising its presence to our new BLE reelceivers, allowing it to be located and uniquely identified, exactly like our existing active RFID tags.

This means that any device with BLE hardware and, critically, the software support to send unsolicited advertising packets, can integrate seamlessly with the reelyActive platform and participate in the Log in to Life experience [EDIT: rebranded as smartspac.es as of 2014]. No longer will a reelyActive tag be required, the smartphone in your pocket will soon take its place. Taking advantage of a reelyActive-enabled space will require no more than running an application in the background.

This demonstration has been a long time in the making. One year ago, Nokia announced the launch of the In-Location Alliance with 22 industry partners, touting BLE as an essential ingredient. However, only last week did we see major indoor location announcements by Estimote and PayPal. The reason is simple: while BLE hardware has been around since the iPhone 4S and Galaxy S3, full OS-support is only just emerging. This summer’s release of Android 4.3 brings partial BLE support, but does not yet implement the functionality we require. However, soon-to-be-released iOS7 embraces BLE and is the first mobile OS to support the unsolicited advertising functionality our platform requires. And, fortunately, the Texas Instruments chip we selected for our reelceiver is versatile enough to support these (arguably) non-standard packets. As we learned from attending the Bluetooth SIG working group in Montreal last week, the establishment of standards among competing vendors is far from an elegant process!

Earlier this year we blogged about the two approaches to radio location. For the reasons cited, we have taken the opposite approach to the companies building beacons, which further include Tod and Tile. Nonetheless, our hardware can implement both approaches simultaneously. In other words, each BLE reelceiver can advertise its own geolocation to mobile devices in range, making them location-aware. At the same time, the reelceiver listens for devices in range which advertise their presence and identity, relaying that information with either the cloud or a local server. It’s the best of both worlds. And, since our reelceivers have perpetual power and network-connectivity, they have the advantage of requiring no maintenance and supporting real-time updates, unlike many of the aforementioned beacons.

Next month we will present a live demo at the 38th IEEE Conference on
Local Computer Networks (LCN)
in Sydney, Australia in conjunction with the scientific article we are presenting on the subject as part of M2MCIP 2013. The reel architecture has proven its versatility by simultaneously supporting heterogeneous radio communication protocols and providing plug-and-play extension of coverage. While we’re excited about the future applications for smartphones, they are nonetheless only a subset of all the devices which support BLE. Many of the billions of low-power wireless devices that will make up the Internet of Things will employ BLE technology, and our reels will be ready to provide them with the low-power ambient connectivity they require.

Bluetooth Low Energy Reelceiver Love