We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

BACK TO SEQUENCE.COM

On the Possibilities and Challenges of BLE Beacons: Part 2

In Part 1, we laid the groundwork for a thorough analysis of the challenges to designing experiences utilizing BLE beacon and iBeacon technology. Without further ado, here are seven “realities” that surfaced in our exploration and experimentation with beacons.

Reality #1BLE Beacons and iBeacon aren’t the same thing.

For some of you this is obvious, but for many it’s not. iBeacon is not a piece of hardware you can buy from Apple, but rather a proprietary technology that developers can use when building iOS apps to trigger unique functionality. Put simply, when a special iBeacon-formatted signal encounters an iPhone running an iBeacon app, special iBeacon things get triggered.

In contrast, a BLE beacon is a type of hardware you install that transmits a Bluetooth signal. They are made by large electronics manufacturers (Qualcomm just spun off its “Gimbal” line of beacons as its own business) or small start-ups such as Estimote and Footmarks. Or you can make them yourself; we acquired ours from some smart hardware/firmware designers we’re lucky to know.

In short:
All BLE beacons send Bluetooth signals.
Some BLE beacons transmit Bluetooth signals that use the iBeacon technology.
Experiences that use iBeacon technology are able to trigger proprietary events on iPhones and iPads that non-iBeacons signals cannot.

The key word here is “accurate.” Most BLE beacon use cases we envision deal with the immediate space around a body, often indoors in a specific room. We expect experiences that employ BLE beacons to work effectively in both a round space that’s a few feet in radius and in a space that’s a dozen meters square.

The broadcast radius of a BLE beacon typically defines a “zone.” An open smartphone can use the BLE signal to determine its distance from the beacon. The iBeacon service on the phone can note a user’s entrance or exit from a zone (and have an “I see you!” style of reaction), but without a directional antenna, does not know whether the user is behind or in front of the beacon. If there are multiple micro-zones within a store, for example, the user’s phone, which can sense all beacons in range, must discern which zone a user is in in order to trigger the appropriate behavior. This is difficult to do accurately for a couple reasons.

Broadcast circles don’t define squares very well
The zone set-up presents challenges. Most retailers and residents define space in rectangles (rooms, aisles, departments, whole floors). The majority of BLE beacons broadcast in a radius with the beacon at the center, not in right angles. So either a beacon’s coverage extends outside of the actual rectangular space it’s meant to cover, or it doesn’t cover far enough. Chances are there will be blind spots and false positives.

Beacons signals are really erratic
Due to a litany of variables that can either absorb or reflect a Bluetooth signal (building materials, competing signals in the same frequency range, the number of bodies in a space, etc.), the broadcast circle looks more like a splash of ketchup, with some edges stretching farther than others. And this broadcast distortion is constantly shifting.

So the process to accurately determine a person’s location, already made difficult by the simplistic “zone” method of beacons, becomes even more problematic when those zones are shifting, overlapping, and disappearing at a moment’s notice.

In a scenario like a grocery store, you would like to see a user open his shopping app while at the deli counter and have a BLE beacon in that area of the store react by triggering relevant deli information and coupons. But because of a beacon’s limitations in determining a user’s location, the deli information might be triggered when the user is across the aisle in the bread section.

Reality #3BLE beacons can support real-time experiences, but with a delay.

Compounding the challenge of getting an accurate location is how long it can take a phone to recognize a nearby beacon: a few seconds to almost a minute. In an age where milliseconds can make an internet connection or mobile phone call feel slow, our expectations around “real-time” are high. Our research indicates that beacons don’t respond as quickly as we would like.

Many BLE beacon installations attempt a simple “Welcome” message when a customer enters a store, but more often than not, that message is received 10 seconds or more after the customer enters. By that point, a customer is already occupied with shopping. Receiving a delayed “Welcome” message is disruptive and out of context.

The aforementioned fluctuating signal strength factors into this delay, creating unpredictable recognition. There is also speculation that the iBeacon service (and other beacon platforms) collects multiple readings from BLE beacons to return a reading that’s more accurate than a single reading. That filtering adds time as well.

Other reasons for the delay have to do with power management. The “low energy” aspect of the Low Energy Bluetooth specification means a coin-size battery is meant to last for months or years. To achieve this power efficiency, BLE beacons can broadcast very infrequently.

When the BLE beacon is not broadcasting, the intended experience is essentially turned off. And as we have all experienced, mere seconds are the difference between immediate delight and awkward frustration.

Just like BLE beacons, phones attempt to save battery power by turning on their Bluetooth antennas only occasionally. Because BLE doesn’t have a standard on/off interval, a phone doesn’t know how to efficiently turn on its antenna to look for beacons. So it’s hit or miss whether a beacon and phone will be on at the same time and see each other.

Even a phone’s age factors into how often it wakes up to look for beacons. Older models tend to check for beacons less frequently then newer ones due to more restrictive controls around battery usage.

Reality #4The magic is in the system, not the beacons.

Beacons sold by the major electronic companies typically do not have the smarts to do all the cool stuff you dream of doing with BLE beacons, such as calibrating your beacons to a specific zone, using sophisticated algorithms to determine with a high level of confidence a person’s location, or containing the business logic for triggering specific events when a particular customer enters into range.

For most use cases, BLE beacons are meant to do one thing: be seen by your phone or some other receiver. Beacons broadcast a signal and can perform some simple recognition functions, but that’s about it. All the amazing things that we want to magically happen are triggered because the BLE beacon is attached to a larger system that contains the complex logic required to handle the things.

The proximity awareness provided by a BLE beacon is an important part of the overall experience, but it’s only a part.

Reality #5You still need a data connection for most interactions.

Successful beacon integration often requires customers to have data connectivity in the store or home. Data connection inside a building isn’t a sure thing. In the home, you can probably rely on Wi-Fi but home automation currently makes up only 5% of beacon-centric usage. In a retail store (the environment where about 70% of BLE beacons find a use), the process to get a customer to connect to Wi-Fi is prohibitive. In these cases, relying on cell coverage is the most realistic route. But we have all experienced spotty reception inside stores.

In our experimentation, we explored leaning more heavily on the Bluetooth signal itself to provide content and data. Unfortunately, the protocol allows only a very small amount of information to be passed to a user’s device. It’s enough to support a few very limited use cases (like asking for help or submitting a deli order) but the majority of use cases require a more robust connection.

Reality #6You’re limited even more by phones in pockets.

Getting a locked phone to consistently and dependably see a BLE beacon is fraught with complications. When locked, a phone’s Bluetooth antenna turns on even less frequently than if the phone is unlocked and running the relevant app in the foreground. And while a beacon could successfully perform its duties when a user has his phone in his hand and open for use, the reality is that most people’s phones are in their pockets in a lock state. It takes significantly longer for a phone in a pocket to see a nearby beacon, and there’s a good chance that the phone will miss it altogether.

Currently, Apple is noticeably driving developers toward iBeacon. After the iOS7.1 update, we noticed that iBeacon is the only BLE service that stays active when a phone is locked. That’s not a big deal except that Apple has kept iBeacon very limited in capabilities when a phone is in that state. Instead of recognizing more specific ranges like immediate, near, and far, iBeacon only tracks a locked phone’s entry into a zone, meaning that those designing the experience have only one “entrance” opportunity to trigger an action.

What’s more, a locked phone will only notice a new iBeacon once during a specific session, limiting the ability to track people as they move between zones. (This may have something to do with locked phones not recognizing when a user leaves a zone, but it’s unclear. There are hacks, but Apple will probably not allow those tricks into the App Store.) When your iPhone does see a new beacon, the relevant app has only 10 seconds to do something, which is not much time to confirm a user’s location, let alone trigger an action.

Apple claims it’s restricting how apps can use BLE beacons in a locked state because it doesn’t want apps using devices to spam the device owners. That philosophy appears to be present in the beta of iOS8 with its passive content pushes and more self-initiated discovery of nearby iBeacons.

Reality #7We’re all at the mercy of the phone manufacturers.

The success of an experience that requires a customer to use his or her smartphone to interact with a beacon hinges on Apple or Google’s OS updates, which could drastically impact your intended functionality.

Back in 2011, Apple introduced the CoreBluetooth framework that allowed the iPhone to talk to BLE devices even in a locked state. It was the standard open framework that all apps used. In 2013 iBeacon was introduced with iOS7, and in 2014, without prior announcement, the iOS7.1 update seemed to do away with CoreBluetooth, leaving only iBeacon as an option. This illustrates how vulnerable BLE beacon products are if they want to include a 3rd party device, like an iPhone, into their experience.

On the Android side, manufacturers of some of the more recent phones like the Moto G are opting to turn on the Bluetooth antenna less to conserve battery life, which would indicate a decline in Android’s responsiveness to BLE beacons. On the other hand, Android 5.0 reportedly has a new “fast background detection” service that could improve responsiveness.

At this point you could be asking “Well, are you saying to NOT use BLE Beacons?” and the answer to that is an emphatic “No! We are not saying that.” BLE Beacons are a great tool for the right job. If there is an overarching goal of these blog posts it is to set the appropriate expectation for this technology. Which leads to our final upcoming post.

4 Comments

John Donohoe

February 18, 2015 at 8:18 pm

Hi GBau,

I haven’t seen anything that indicates that iOS 8.1.2 has changed the rules around phones better recognizing beacons will in a locked state. I’ve read that they made improvement with the Core BlueTooth stack more a more stable peripheral management for paired devices (your car, headsets, etc.) but it doesn’t seem like it affects scanning for BLE beacons.

Chris

February 11, 2015 at 12:40 pm

I honestly don’t think you understand how beacons work. The beacons do not do any sensing themselves. They are purely transmitters of some fixed basic data. Making sense of the information is is the function of the app running on the mobile device.

In Reality #5 you mention “we explored leaning more heavily on the Bluetooth signal itself to provide content and data”. Beacon protocol is fixed with a UUID, Major & Minor ID. It is up to the app and web service to determine what that information means.

I really get the sense that you wrote this article and them someone proof read it for you and told you how it actually worked and so you made a few changes in a few places.

John Donohoe

February 17, 2015 at 5:20 pm

Hey Chris,

Thanks for commenting. If your definition of BLE beacons is limited strictly to the more well-known products that are in the marketplace (Gimbal, Estimote, etc.) then yes you are correct, these Beacons are only transmitters (UUID, Major ID, Minor ID) and for those products, you need to use their API (which typically includes a cloud based service. Which reinforces the need to maintain at strong data connection).

I’m glad you brought up that reference in Reality #5. Its one of many experiments we did that we cut out of the article for the sake of brevity. (I know its still a long blog post but hey, we really got into this!) What that references is an early experiment we ran to try to overcome the data connection issue. If we couldn’t rely on cell reception at many locations and getting customers onto store wifi seemed too problematic, then possibly we could build beacons that were both broadcasters and receivers. We used iPhones as beacons to mock up some quick demos (We knew that creating that type of specialty beacon hardware was going to be a chore so first we wanted to see if if the BLE technology could support the amount of data we wanted to transmit). The theoretical throughput of the BLE spec is 1 Mbps but our tests showed a much much lower actual throughput (in the 2 Kps range!). In the end it we decided to stop exploring that avenue as it seemed like it wouldn’t support the level on-demand content we needed.