Expectations management for IBeacons Projects - Part 1

Indoor positioning using Bluetooth Low Energy Components is a technology and trend of extreme high interest these days and IBeacons is the Apple trademark and solution enabling to easily implement indoors proximity detection Applications within IOS applications.

In this paper, the aim is not to provide (again) technical details about IBeacons as such since this is a subject that is largely covered, on a daily basis, on the internet by quite a number of excellent tutorials and articles but rather to focus on some underlying aspects that typically arise after the euphoric first phase of seeing a running IBeacons detection on a developer device (this takes roughly 20 minutes) or after a showcase demonstration event.

Expectations management for IBeacons Projects - Part 1

Some reasons to consider a "proof of concepts" and a pre-evaluation phase in beacons based projects

Author: Fabio Trentini, BTC Business Technology Consulting, August 2014

Indoor positioning using Bluetooth Low Energy Components is a technology and trend of extreme high interest these days and IBeacons is the Apple trademark and solution enabling to easily implement indoors proximity detection Applications within IOS applications.

In this paper, the aim is not to provide (again) technical details about IBeacons as such since this is a subject that is largely covered, on a daily basis, on the internet by quite a number of excellent tutorials and articles but rather to focus on some underlying aspects that typically arise after the euphoric first phase of seeing a running IBeacons detection on a developer device (this takes roughly 20 minutes) or after a showcase demonstration event.

The main purpose, to avoid any misunderstanding since the beginning, won't be here to express a negative view on this technology, nor to give the impression that IBeacons will not work as expected. There are on the Market excellent solutions and we should definitively consider to adopt this technology for our business. I will however enumerate some typical pitfalls, based on my own experience in order to emphasize that behind the easy part of the story, the efforts to achieve and implement a final and running solution are, in most of the cases, higher than what it may seem at first glance.

In short:

  • IBeacons are very easy to implement which explains the high interest to work with this technology
  • IBeacons enable an innovative way to interact with mobile devices and therefore enhance the User experience
  • Because easy to implement and working perfectly under certain conditions, the tendency may be to underestimate what you may need in the background to let them fly as you expect in your specific business case and environment (and this is the main message of this document)

It is therefore an advantage to be aware since the beginning that an IBeacons based solution may also come along with an "underwater part of an iceberg". By keeping this in mind, we will increase the chances of a more accurate and realistic estimation as far as time, feasability, efforts and related costs are concerned.

Last but not least, we deal with a trend technology. Even if fun and promising, the main goal remains of course to evaluate first where and if this technology really provides business benefits to our customers and users.

The very short (mandatory-) introduction - What are IBeacons.

IBeacons are small electronic Bluetooth devices (consuming low battery energy) that can be potentially placed "everywhere" in a given room or region and permanently emit a signal that can be detected and processed by a mobile device.

All we need to retain for this paper, to simplify, is that IBeacons will tell to your mobile :

  • Who they are i.e. they carry and send an identifier enabling your mobile device to know which IBeacon has been detected
  • A proximity indication enabling to detect if a given user is an immediate (few centimeters) , near (roughly within 5 meters) or far (roughly within 30 meters) distance from the IBeacon

Note: IBeacons are not like GPS devices. i.e. they do not know where they are located ! We need therefore to manage and keep track of their location ourselves and record in our backend system where we place them. This is a trivial statement for technical users familiar with this technology, but often misunderstood by non technical readers and thus worth to be mentioned.

Besides name and proximity, the mobile device will also receive an indication about the signal strength that, at least in theory, could enable an estimation about the effective "distance" between user and Ibeacon.

I will cover more in details this aspect later on, since usually, once we mention the "distance" facility, the tendency is to immediately pull out the requirement of detecting the exact indoors position of a user (typically "follow the user inside a room") or implement a full indoor navigation as we are used to have it from a Google Map. The reality, as we will discuss later in this document, is however not as evident as it may seem at first glance. You can of course identify the location of a user, that's one of the main advantage of this technology, but you need to be clear on when and under which conditions this can be achieved without efforts (out of the box) and when this goal may become complex to achieve. In other words, there is in this area a real need to manage the expectations.

How do they look like ? The image shows an example (one among hundreds) , an of an Ibeacon.

Besides showing the size aspects (these guys can be very very small), we also take the opportunity to mention another aspect about the potential possibilities.

We may want to place an IBeacons at a specific location but we may also have models where the IBeacons is carried by the user.
Stacks Image 328
The difference, in terms of functionalities, between the approach of "moving Ibeacons" versus static locations opens a subject that would bring us out of scope and I will treat such aspects in a separate document.

In order to already give a first flavour of what the main message of this article tries to emphasize, we may start looking at the Ibeacon above. Yes, it is small and handy to carry. Yes it may also work for a long time. But yes at a certain given point in time you will have to think about the power supply.

From a logistic perspective, if you have few beacons on place, changing the batteries of these guys will not be an issue. If however you want to deploy 20'000 of them, then you may want to opt for a more carefully evaluation of which vendor can provide you with the required hardware, may be consider emitter that will be permanently under power supply (you can find of course IBeacons of this kind on the market) and in any case think about the strategy you will be adopting as soon as the batteries of your 20000 beacons will need to be replaced.

Let's admit it, probably not a big deal, but seen from a strict logistic perspective, such activities may be related with additional costs that should also be considered in planing or evaluation phase.

Distance detection - the most important "expectations management" item for not technical oriented users

I don't know if this is a generic rule, but "indoor localization by triangulation" is one of the most common questions and requirement that I receive from Companies that are considering to adopt the technology for their own IBeacons solutions.

Great ! We measure the signal strength, we use at least 3 IBeacons in a room and we can locate and follow a user by applying a triangulation algorithm.

Without aiming that this would be impossible to achieve (some aim to offer solutions in this direction), assuming a precise localization as granted as a default and working out of the box may end up with results that could be quite far from the expectations. Retain that a precise localization is therefore a requirement to be carefully evaluated in terms of technical feasibility and efforts until you may reach reasonable results. Some of the potential hurdles in this respect are discussed with the "spot lights example" below:

A Spot lights analogy example

I usually use at this point, in particular with less technology oriented users, the "spot light" analogy to emphasize and illustrate what are the typical use cases situations in relation with Ibeacons. Spot lights are to some extent more concrete and easy to interpret as invisible signals.
Consider you as playing the role of a mobile device and each Ibeacon being represented by a source of light like on the picture.

In order to understand how your iphone works with IBeacons, imagine that the distance from a given lamp would have to be estimated by the intensity (strength) of the spot light.

In other words :
  • if the intensity is very high, we are close
  • if the intensity is medium, we are near
  • Is the intensity is low, we are far from the source
Stacks Image 345

If we consider "spot lights" as being a rough estimation of IBeacons emitting a signal (light) in a room, we may also figure out what aspects could influence or interfere with an indoor positioning detection.

In the above image, we may interpret an empty room (ideal case). In reality, we will often need to cope with different room shapes, crowded areas with obstacles or other "light sources" that may interfere.

This leads to an evaluation strategy consisting in identifying where we will have to place our "spot lights" , how will we logically group them together and how many we will need in order to achieve our detection goals.

But the image above helps to start enumerating other aspects that we may need to cope with in our project evaluation phase.

For example, a typical expectation would be to place our "spot lights" close to products and enable functionality on our mobile app as soon as a user walk closer by to a given spot light.

Easy right ? Yes ...easy... but this implies also that we will need to :

  • Identify (allocate) each individual spot light with a name (or ID)
  • Allocate each individual spot light with an action or functionality
  • Let our App know about the existence of the "spot lights" and how to deal with proximity events
  • and last but not least, set up a backend system to administer and manage the allocations of "spot light" to "functionalities".

In other words, we need , besides spreading the "spot lights", a (backend) system to manage and administer the "spot lights" positioning and the information or logic that we want to associate when users pass by to each individual location.

Another typical task that we usually will have to cope with is how we react when a user pass by a given "spot-light". Typically the first idea would be to automatically popup information on the user device. If technically feasible with few lines of programming code, there is a more complex underlying logic. What about a user that would walk close to the yellow spot light 10 times within 2 minutes ?. Shall we bomb him with Sounds and recall message every time ? only the first time ? every five minutes ? Never ? Keep track on how many times he/she passed by and apply some sort of "visitor returning" logic deciding if and when we would execute on the device a given action ?

Of course the strategy is driven by the individual use case and requirements. Retain that, besides the detection logic on the device itself, we therefore also may need to keep in mind the backend configuration system in order decide what to do with proximity detection events.

Want to ear about some more examples based on our "spot light" image ? take this one (an interesting one)

We have 2 products (Producr A and Product B) and we want of course to present to our user the characteristic, pricing and promotions when the user come close to the product.

Case 1: The product are more than 5 meters away in which case we put 2 spot lights close to the products, consider near proximity detection and we probably would be all set. Since we apply near detection and the distance is large enough, we program an automatic popup information that we automatically activate when the user come close to the product. Nice feature !

Case 2: Now take this one. The marketing department needs now to physically move the 2 products and suddenly these will be 1 meter away from each other. This new topology situation implies that when a user would walk close to either Product A or Product B an automatic notifications would be issued (but which one do we want to use ? and according to which logic ?)

Case 2 shows typical aspects that a solid IBeacons solution would need to cope with i.e. be in a position to reconfigure (map) a physical change in the landscape with a logical event handling in the whole IBeacons backend infrastructure.

I leave the reader free to imagine other potential situations but, once again, the main message remains the same:

The strict detection (near, far or immediate) remains as such trivial but the real complexity lies in the requirements (and in particular events handling logic) within the backend configuration of the whole IBeacons landscape.

Besides these rather topology related use case situations, we may also encounter other side effects that are closer to the nature and detection capability. An example is described in the following paragraph.

Typical "Spot lights " side effect

The following "side effect" is a classic one usually coming out once you start implementing an IBeacon solution for the very first time.
Consider the image below.
The 2 users A and B are both located at the same distance to an IBeacon (the source of light). The beacon is placed on one side of a box. User A is located in front of the box. User B is behind the box.

User A will perceive a stronger light intensity coming from the lamp and user B will receive the source of light indirectly by reflection to the wall.

Although User A and B are Near to the source of light, the device of A and B will detect different signal strength thus assume that User A is near (which is correct) but user B is far (which is incorrect)
Stacks Image 352
There are of course strategies to cope with such cases and one would be at first glance to place for example the "spot light" on top of the box in which case User A and B would get the same proximity (near for example) no matter where they would be staying close to the box.

But this may not be necessarily be always possible (imagine that instead of a box, we would have a column from the bottom up to the ceiling in which case we may consider to place the light on the ceiling or use 4 source (1 per side) and detect the proximity on each face of the box.

The latter situation emphasize another aspect. You may need more IBeacons than you may have planned at the beginning to cope with such kind of situations (and of course, what else ?, a backend infrastructure enabling to deal and configure these situations accordingly since we would need to allocate the 4 Ibeacons to the same physical location and let the mobile application know how to react accordingly.

IBeacons and Hardware Vendor considerations

Well... do not expect here the magic answer. My approach in this respect is rather pragmatic consisting in planing a test evaluation phase and validate in a feasibility study (with running concrete examples, preferably using the customer specific data) if the expected functionalities really runs on the field by using different Hardware products (and there is more than one good reasons to carefully evaluate first which vendor and hardware we are going to pick up for the final project rollout).

The deliverables of this preliminary phase are among others:

  • How is the detection in your specific environment
  • What use cases do you intent to apply
  • What is realistic feasible and what will need additional efforts
  • Which hardware is the most appropriate ? Battery ? power supplied ?
  • Which areas of your target indoor location works well and which ones may need additional attention ?
  • How many IBeacons will you need ?
  • What are the required functionalities of the backend infrastructure ?
  • Which vendor do we need ?
  • last bout not least. define the implementation plan and phases that will progressively add the required functionalities

As far as the vendors are concerned, I will not mention any names in this document since , again, the choice that will fit at best is dependent from many parameters and of course the specific use case situation.

We may choose, to simplify, among the following options

  1. We may buy from vendors that will provide us with Hardware only. In this case we will typically receive "row" IBeacons (we need to ensure first that these are Apple certified/compliant) and a set of utilities, more or less advanced, allowing us to configure each individual IBeacon before usage. Let's not underestimate this part since it may be also time consuming. In our "spot light example" above we mentioned that each IBeacon will have to be allocated with a name (ID). In fact, we need to configure each beacon with 3 parameters called Proximity-UUID, major and minor in order to be recognized by our App according to the standard Apple API's.
  2. We may opt for vendors providing Hardware and a backend infrastructure allowing us to manage and configure our Ibeacons. Typically, this category of vendors will also provide a software development kit (SDK) that although being "proprietary" , may have the advantage to enable the access of additional information (such as battery level and/or temperature on each individual IBeacon... just to mention 2 examples) and thus expand the set of options that we may offer to our users in our specific business case. In order to take advantage of these additional facilities, the IBeacons may however require to be configured in a "proprietary" mode i.e. they may be recognized via the specific vendor SDk, but may not be detected anymore by applications implemented with the Apple Standard set of API's
  3. We may opt for a sort of combination of 1 and 2 consisting in opting for a vendor , not use the "proprietary" options but still configure the IBeacons to remain Apple compliant.

We may wonder what would be the benefit of using approach 3 instead of 1 and the difference may lie in the facilities provided by the backend infrastructure to configure and maintain each individual IBeacon configuration. In some cases, this may be enough to avoid an own (understand in house) implementation of an IBeacons backend administration platform.

Besides what we covered in this paper, there are also additional and more technical calibration aspects (in short low level parameters that we may also need to set on the iBeacon itself besides the "ID's" that may influence for instance signal strength and/or the battery lifetime). According to the vendor selection approach we may have more or less comfortable ways to access and calibrate these parameters and this should also belong to the evaluation process.


I mostly used for the proof of concepts approach 1 and 3 with an own IBeacons environment and test infrastructure that was build at BTC to specifically configure and run simple and basic IBeacons use cases such the ones mentioned in this paper.

The results showed in one case differences among vendors hardware. By letting run at the same time IBeacons from different vendors, we encountered situations going from "work as expected" up to a set of IBeacons, activated at the same time and promising a lifecycle of some months, that all stopped working (at the same point in time) after 30 days.

What was the reason ? Without entering in too technical details, the answer was in the Calibration and low level Hardware settings of the beacons involved that, in the specific case situation, were influencing the battery lifetime.

A last word about "Planing your IBeacons based solution"

We have enumerated a couple of potential side effects (there are others of course but this would have brought us out of scope).

The goal was in this document not to discourage in using this technology of course but rather to suggest a progressive approach if in introducing IBeacons in your business.

A proof of concepts is in this area is more than justified if compared to other "traditional" software solutions since potential hurdles, and related side effects are, by definition, often detected on the field and at runtime.

Fabio Trentini, BTC Business Technology Consulting; August 2014.

who we are
BTC Business Technology Consulting offers high level services since 1998

Large consulting expertise in Analysis, Design and Implementation at large customer site.

Fabio Trentini
Email: info@btconsulting.ch
Linkedin Xing

What we do
Consulting services and project coaching for IT-Architectures and Strategy in the Web Mobile and Business Service integration areas