Generic proximity detection models with iBeacons

Architecture overview taken from the making of BeaconZone, the generic iBeacons platform


In this post, the focus is given to some aspects of the architecture applied in our live iBeacons platform (BeaconZone) currently running in Zurich. Since the launch in November 2014, 25 independent locations, spread around a district in Zurich, participate in the pilot phase of the project and have been equipped with BLE 4.0 components (iBeacons.)

Generic proximity detection models with iBeacons


Architecture overview taken from the making of BeaconZone, the generic iBeacons platform


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

In this post, the focus is given to some aspects of the architecture applied in our live iBeacons platform (BeaconZone) currently running in Zurich. Since the launch in November 2014, 25 independent locations, spread around a district in Zurich, participate in the pilot phase of the project and have been equipped with BLE 4.0 components (iBeacons.)

Here below is a summary of the objectives and targets of the pilot phase of the project.
  • Concretely apply proximity detection with iBeacons in a real live environment.
  • Manage the iBeacons areas from a central web and cloud base management system
  • Enabled to define and manage multiple independent iBeacons areas. The pilot runs in a district of Zurich but the platform enables to create and manage groups of independent micro locations.
  • Select for the pilot different categories of micro locations (thus not only focus on shops).
  • Include also locations that are geographically far away from each others and spread around the area.
  • Test the detection aspects using both IOS and Android (The App is available in their respective stores)
  • Design a generic architecture allowing to dynamically manage and apply on the fly different micro location constellation and use cases.
  • Provide a centralized on the fly configuration of model proximity events detection.
  • Evaluate and optimize performance aspects
  • Include external services in the landscape and map data coming from these service with in app proximity events.
  • Collect users feedback
  • Measure the activity and add dashboard / statistics on top of all this

Besides the pilot aspects of the first phase, the aim is also to use the platform today not only to directly enable iBeacons and proximity for businesses, but also use it for Workshops, Seminars or proof of concepts in this area.

Define an architecture to support proximity event modeling


What we need to consider since the beginning, is that once we solve proximity detection at low level and can cope with topology or environmental aspects, we have achieved already an important milestone, but this is just the beginning.
As we know, iBeacons gives our mobile devices the opportunity to detect proximity. The detection, at low level, and seen from a developer perspective delivers something like this :

"a proximity component (an iBeacon) having id XYZ has been detected (with an estimated distance that may be near, far or immediate) on the user's mobile device".

but the business would rather like to hear at this point something like :

"Bob device has entered our Bank in Zurich, Bob is a very good customer of us and he may be interested these days to invest on iBeacons Technology shares - Bob should now walk to Desk 10A and wait for George (Bob's advisor) that will take care of him asap"

The business analyst, or the person responsible to feed a workflow management system for example, will focus on:

Event : Enter the Bank in Zurich
Type: Manual or proximity driven
Subject :
Bob
Interests:
Likes to buy shares on beacons Technology
Action: : Let Bob know at which desk he should walk, and inform his personal advisor that he has arrived

We need therefore a first abstraction level between the proximity detection issued by the IBeacon within the App and the logical Event that we want to model from a business perspective and typically also on a centralized system (i.e. remote from the App).

Without getting in too much details, we can also mention that this abstraction layer implies another major consideration. In terms of workflow management, we can model processes, and include "proximity detection" as a new event type, independently from the underlying technology used. In other words, whether the event is issued by IBeacons, GPS or a new universal detection standard in the future, the logical (business) model will remain the same.

The iBeacons modeling layer


We may think at first glance, that all we need to do is therefore to map the technical event coming from the iBeacon with the corresponding business representation right ? Wrong !

At least in our platform, the goal was to be able to cope also with special topology constellations in a dynamic and as much as possible flexible way (and I will only describe here one among the different use case situations that may arise in practice).

We have seen so far, that the relevant logical event for business is when "Bob enters the Bank building in Zurich".

Now what about a building having 3 possible entrances A,B and C as reported in the diagram. We want to catch Bob no matter where he would enter the building

We wanted BeaconZone to be able to also configure, on the fly and from the central management system, such kind of situations by designing and adding an additional layer allowing to also model specific iBeacons topologies.

For example, in order for Bob to be detected, we may require in this particular case more than one iBeacon and/or additional fine tuning such as select the appropriate detection distance (immediate, far or near) for each individual iBeacon.
Stacks Image 3838
And the final result will have of course to reflect and emit only the logical event expected by the business ("Enter the Bank building") .

That said, topology modeling implies decisions and aspects that may vary on a case by case situation. We may want for example to allocate individual logical events for each entry point, or associate a common logical event to A and B and a specific one for C.

Such topology situations are in practice typical with iBeacons, and by putting more efforts in the design of the abstraction layer to dynamically adapt and configure these cases on the fly, we increase the chances to get the iBeacons landscape to respond as expected.

Processing of business models in the mobile App


In a traditional intranet environment, understand here a typical enterprise backend with a business layer and a fronted browser, rules changes arising on the backend are implicitly reflected in the user interface . In other words, when we change something on the business logic (backend model), we do it at one place and the browser will (should) reflect it for the user.

Proximity detection adds an additional "challenge" . The mobile App is actually collecting the physical detection events on the device.

The App must be therefore in a position to react based on rules (including the business events) and configuration aspects that are maintaned and defined in the central cloud based management system.

In other words, the App needs to know how to detect Bob based on the iBeacons model layer and then react accordingly based on the business Event model.

This requires therefore a mechanism to exchange meta information (the model) with actions to be processed for the user.
Stacks Image 3852

As the diagram above shows, model and configuration layers need to be aligned and synchronized between the central management system and the app. As opposed to a browser intranet solution, a model abstraction layer is therefore in our case required on both sides (In the App and in the Cloud)

Why we should start considering iBeacons and proximity in our strategy ?


By the time of writing, we hear, besides daily announcements of companies already using proximity detection with iBeacons, also comments such as :
  • Proximity detection needs an App to be downloaded on the device and the user must explicitly enable bluetooth and locations services to use it. A reason to give up ? If a user sees an interest in using the App he will download, install and activate.
  • Proximity detection needs to work on all platforms, thus we may prefer to wait until a universal approach will be available in the future.
  • Ideally, proximity detection should work directly on the browser and thus not be App dependent
  • Do we really need proximity detection ?

My two cents on this: The question is not if we are going to see proximity detection in the future but rather how.

The experience collected so far with the pilot project in Zurich is that the model approach as discussed in the previous paragraphs leaves a degree of independence on the question related to how we will detect proximity in the future since this is defined in the business workflows running on it, and not by the underlying iBeacons layer.

The efforts are in particular going towards an optimization and implementation of the models and workflows (not only the strict technical detection) so the main question, in terms of strategy, is if we want to jump on the train today (and get prepared) or if we prefer to wait until the concurrence will do it for us.

By defining proximity detection with the iBeacons standard, Apple pushed worldwide a variety of activities:
  • Vendors are working in improving detection facilities (improved iBeacons device models)
  • Developers can implement proximity detection on their Apps based on a common standard.
  • The "proximity trend" is launched and is a reality. Some businesses are, thought, not focusing on it yet (or simply cannot yet appreciate what they could get out of it) while others are already flying.
  • Some vendors are working on their proprietary solutions and offers enhanced detection features and options
  • Companies have the chance today to at least test proximity detection concretely.
  • Companies have the possibility to start working and adapting their workflows models focusing on solutions that can also include proximity detection events.
  • Models combining proximity detection with own (big) data and services for example are today technically possible and can be approached/tested with real time situations

In other words, the underlying technology is available and businesses have the chance to move towards proximity detection solutions.

Seen from another angle, we maybe are experiencing with iBeacons today what companies where wondering 20 years ago when, at that time, the question was if a company absolutely needed an internet homepage or not to remain on the trend.

Some lessons learned

Putting iBeacons in practice as we are doing it in Zurich is an exciting experience (and a confirmation about the feasibility).

By keeping the abstraction as described above in the events and iBeacons layers , we could also validate constellations that we even did not expect or think about at the beginning, but raised once the project was running.

An interesting aspect is also that requirements are not expressed only from the customers (locations) participating in the pilot phase of the project, but ideas are also coming from users that, after downloading the App, gave feedbacks and suggestions that we could re-inject for validation purposes in the platform.

Proximity detection opens a variety of possibilities and models that can also become apparent to users once they get to see concretely what such a technology can offer. iBeacons are, besides their currently popularity and trend worldwide, still unknown to a large community (including a large part of the IT world) and this will probably change within the next month.

Where are we going with BeaconZone ?


The platform was not implemented in few weeks but following a lifecycle that, at least as far as our experience i concerned, has been more than confirmed in terms of efficiency.

The chronology of the events that brought us to set up the platform as it is today is a clear confirmation on how a generic platform can also be efficiently used to evaluate, analyze and finalize more complex constellations or simply as a mean to carry on an iBeacons based project.

BeaconZone was originally a generic testing environment for iBeacons consisting in a web and cloud based administration application combined with an IOS App used in order run on the fly, and on the Field, typical use cases by applying the model independence as described above.

This enabled the first feasibility study directly on the target field in Zurich i.e. start mapping basic user data with proximity detection models to have a first evaluation of topology and detection on site.

In a second step we tackled the design and final implementation of the BeaconZone as a generic platform and enabled it for the IOS and Android stores. In this phase, besides improving and finalizing the models layers, we also improved the integration of micro sites and performance.

We still use today the original testing environment following the same life cycle. We validate first individual specific approaches and inject, when and if required, new facilities in the BeaconZone platform accordingly.

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