IBeacons Content Management

iBeacons and BLE proximity detection belongs today to every innovative and modern business and ignoring the potential also imply missing one of the major and leading trends of the coming months.

In this document, the aim is to focus on the content management aspects of an IBeacons solution and is based on the experience and findings collected during the design and implementation of BeaconZone, an iBeacons based platform currently running in Zurich.

IBeacons Content Management


Role of proximity detection management in iBeacons projects


Author: Fabio Trentini, BTC Business Technology Consulting, January 2015

iBeacons and BLE proximity detection belongs today to every innovative and modern business and ignoring the potential also imply missing one of the major and leading trends of the coming months.

In this document, the aim is to focus on the content management aspects of an IBeacons solution and is based on the experience and findings collected during the design and implementation of BeaconZone, an iBeacons based platform currently running in Zurich.

Backround information


BeaconZone is an iBeacons generic platform designed and created by BTC Business Technology Consulting GmbH in cooperation with Sunsus GmbH and is composed of a cloud web based iBeacons content management system combined with a mobile App available in the IOS and Androids stores.

As the name of the platform suggests, BeaconZone enables to set up, manage and deploy independent proximity enabled Areas where different detection models can be activated on the fly using a generic and centralized configuration approach.

"Wiedikon Valley" is the first productive zone implementation of BeaconZone and was based on an idea and initiative of Marc Hauser (
Stratac AG) to organize, set up and apply smart technologies with iBeacons on a real environment (a district in Zurich), BeaconZone is live since November 2014.

The advantages of such an approach was(is) to progressively apply and validate proximity detection models with real life situations and businesses having different and individual requirements, size and topology. A great and ideal opportunity to measure the impact of iBeacons from a user, business and of course technology perspective.

Document purposes


This document will not enumerate all of the facilities of BeaconZone but rather focus on generic requirements that are valid for any iBeacons oriented project. In this respect, all you can read below has to be seen from a more generic perspective.

Although we are discussing about a technology, what follows is targeting
non technical oriented readers (I will stick to the basics and minimum required omitting technical details) and has the purpose to emphasize one of the main functionality (content management) that is required by most of the iBeacons landscapes.

If you are planing to consider iBeacons for your own case, or are still asking yourself what you could get out of it, you are invited to read the following not only in order to understand how this technology is functioning, but also and in particular to get an idea about one of the main requirements to be fulfilled in order to get your project up and running.

Understanding the underlying aspects of iBeacons content management is important no matter if you are planing a generic solution such as BeaconZone or a dedicated project targeting specific requirements.

Referring to the development lifecycle of BeaconZone and the experience collected by running the system, content management is a central driver for an iBeacons landscape but is of course only one aspect of a global solution.

Before analyzing what iBeacon content management is all about, and why we should take attention on how we design it, it is important to recall some basics and preliminary characteristics of proximity detection and I will use for this purpose a simple analogy with a non technical and trivial example familiar to anyone.

Check your Proximity detection skills


Assume for the sake of explanations the following analogy

1 light bulb = 1 iBeacon

A light bulb emits (in our example and as reported in the figure) a unique colored light.

Watch the figure representing the 3 rooms A,B and C and notice the bulb colors.

Which room contains the yellow bulb ? A of course , you got it !

Easy right ? Actually you already have achieved a typical task driven by a content management system but more on this will follow.

Stacks Image 3298
The first thing to retain is that iBeacons will not tell you much more than the yellow light bulb i.e. iBeacons emits an identifier (the color) but will not deliver any information about their location (as a bulb cannot emit more than light).

Can you see the bulb by walking in a given room ?
This is how detection works and represents the job of a mobile device i.e. let your App know that an iBeacon has been detected and deliver the corresponding color.

How far is the lady from the yellow bulb ?
According to the distance from a given light bulb, we can imagine the perception of a weak or strong light intensity (iBeacons are Bluetooth hardware components and a mobile device does the same by measuring the bluetooth signal strength emitted by the beacon) . All this gives the possibility to estimate the proximity (immediate, near or far) from a given source of light.

To sumarize:

A mobile device receives nothing more than informations such as :
  • Yellow light detected having near proximity
  • Red light detected having far proximity
  • etc...

Note: In reality, an Ibeacon will also deliver the signal strength that you may, on paper at least, try to transform in a concrete distance. This is a nice try but in practice you may forget about it and plan your projects to rather focus on the approximation indications. The signal strength is in fact subject of interferences and is in practice very difficult (or impossible) to use for precise distance measurements.

How can we identify if someone has entered (or exited) the region represented by A, B and C ?
Here also the answer is straightforward. Assume first that you can logically group together the red,yellow and white bulbs and associate these bulbs to a a name (let's call it region "ABC" for example).
As soon as we detect one of the 3 lights (no matter which one) we can state that a user device entered the "ABC" region. If we suddenly do not see any of the bulbs anymore, we can deduct that we have left ABC.

The iBeacons standard of Apple (at least at the time this document was written- January 2015), focuses, in short, on the above "light bulb" model. It enables a device to detect the "color" (identifier) , provides an indication about the distance (immediate, near, far or not detected) and will also indicate if a mobile device enters or exits a given zone (represented by the Areas A,B or C in the diagram).

Note; The examples and assumption refers to the iBeacons standard specifications of Apple. Proprietary solutions on the market actually also offers "non standard" variations that may deliver additional information such as temperature or humidity values just to mention 2 examples.
We stick in this document to the standard specifications. Just retain that proprietary solutions delivering more than "color" and proximity are also potentially available.

Interesting stuff, but where is the real benefit of all this ?


It would be a mistake to discard the potential offered by iBeacons as a default and in any case worth to take the time to understand first the underlying mechanisms.

Our experience shows that ideas and potential business models among users naturally start emerging once the technology is running in a live environment.

By designing BeaconZone as being flexible, configurable and dynamically supporting on the fly different constellation, we could setup and validate a variety of such models and also cope with typical open questions and situations.

For example :

Will iBeacons spam us ?
As we know, spam is a context driven perception. We "accept" somehow to see a shampoo publicity on a wall but if we receive the same shampoo publicity via email, we perceive it as annoying and we usually put the email in our spam list (although we talk about the same product).

But if we are walking out from a shopping center and get reminded that we forgot to buy the shampoo that our girl friend is desperately expecting you to bring home, we will put the App on our golden list and mention it in the hall of fame.

We can think or refer at a variety of approaches to cope with the load of push notifications on a user device going from user profiling up to options giving the user the choice to switch off notifications at any time (which belongs in any case in the mobile app).

But do we really want our users to switch off proximity detection ?

We designed BeaconZone to be centrally driven and generic (primarily because we did not want the platform to be focusing just on shopping but also enable it for other areas) and thus included, since the beginning, a centralized facility to keep under control, and on the fly, aspects such as, among others, the flow of notifications to be issued by the App in a given area.

From a marketing perspective, business wants of course to issue coupons or promotional messages. This may perfectly work in certain areas but become a killer on others.

The decision to issue (or not) promotional messages is not necessarily driven by the wishes of each individual business. There is a necessity, in some cases, to evaluate the landscape and topology as a whole i.e. consider also surrounding requirements.

Example:
Shop ABC, if located in an more or less "isolated" area, may afford to push promotional coupons. The same shop, or a subsidiary, if located in a shopping mall, will have to cope with 100 other surrounding businesses also wishing to push their products. This may lead to a general contra productive situation for all the businesses in the area since users may tend to switch off detection (best case- but this is not what we want) or kill and delete the App (or Apps , since this may affect more than one single iBeacons enabled application).

iBeacons will probably force vendors and business to find "cooperation" models and solutions to cope with such kind of situations. And if an area becomes too much crowded with iBeacons, the facility to have options on a central system to control the behavior up front , and on the fly, may save your App.

This bring us to the following, somehow related, subject i.e. where can I place my iBeacons.

In my business I do not have space to spread iBeacons and customers are not coming in my office anyway. Why should I care about proximity ?
What may not be apparent at first glance is that iBeacons do not necessarily have to be located in near proximity. An hypothetical use case : If we have a very small office based in Paris (or work from home), but most of the interesting customers usually visit the top of the Empire State building , the right "bulb" placed on top of the building in New York may still bring us additional business in Paris.

Since iBeacons, as we know by now, are logically bound to a central system but can be placed everywhere, they can also enable synergy models among business and locations far away from each others.

And where do we store and maintain such kind of constellations ? You got it, in a central iBeacons content management system.

To summarize we should think at proximity detection with iBeacons in a more generic way and forget distances or strict physical locations. A proximity detection may open up opportunities or services even if located far away in terms of geographical locations




IBeacons Models with moving targets


Another interesting iBeacons use case are moving targets.
iBeacons are often perceived in relation with indoor and static locations (such as shops or museums for example) but actually we can think at models where iBeacons are moving .

Let's consider the following example (and question):

The bulbs are now placed on planes

Is the woman already sitting on a plane ?
Which one ?


We may notice that we apply to answer the question exactly the same proximity detection approach as we did before, but in this case, we simply need to know that the light bulb is not actually mapped to a static room location but to a specific plane and a flight from Zurich to Geneva.

This simple example re-emphasize that the bulb (beacon) as such sends the same identifier (yellow color) as it did before but in this case we use it in another context than static indoor locations.

And the difference is not actually lying in where we place the yellow light bulb, but on which information is associated in the content management system behind the scene
Stacks Image 10414

Managing the iBeacons configuration landscape


The room and planes examples above showed that the location of an iBeacon as such may play different roles according to the business context and situation.

A content management system has to be in a position to configure in a flexible way the detection events arising in the app. Typically the information kept in a centralized system is deployed (distributed) to the mobile App that will have to react accordingly.

The way this is done depends on the business case. For example, if we can assume that the user will be in an area with excellent wifi / internet connection, the app may access a remote service upon a proximity detection in real time.

This approach may become impossible however for situations where the user would enter "zones" with poor or no internet connection. In this case, the model may be based on the approach of "pre-collecting" and "post updating" all the required information that would be used to process the proximity events.

To summarize :

The diagram summarizes the role of content management systems in a very simplified form but shows the idea behind platforms such as BeaconZone.

iBeacons can be easily spread and give basic detection information to a mobile App.
Ibeacons do not know actually how they will be used, and where they are located.

The content management system contains the relationships between each individual iBeacon, and iBeacon detection and associates this information with one or more Events that the App will have to run.

The App will need therefore to communicate with the central system in order to collect the information required to take actions once in proximity of a given IBeacon (bulb)


Stacks Image 10401
We could of course not cover in this document all the possible constellations (those who already work on iBeacons projects may appreciate the variety of situations to cope). On the other hand, by simply thinking at light bulbs spread at some locations, keeping in mind that we need to manage bulbs and associate these to specific actions (events) and , last but not least, design the mobile Application to cope with these associations and react accordingly, we may already get a first idea of what we can do, and what we have to think about in order to use iBeacons in a project.

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.
contact

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