reliable beacon detection - uzh...reliable beacon detection robin engbersen zurich, switzerland...

Reliable Beacon Detection

Robin EngbersenZurich, Switzerland

Student ID: 08-725-202

Supervisor: Jan Berchtold, Dr. Corinna Schmitt, Dr. Thomas BocekDate of Submission: June 15, 2016

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

MA

ST

ER

-TH

ES

IS–

Com

mun

icat

ion

Sys

tem

sG

roup

,Pro

f.D

r.B

urkh

ard

Stil

ler

Master-ThesisCommunication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

Abstract

This thesis provides an architectural solution to increase the detection reliability of Bea-cons by smart phones for defined use cases. Prior an in-depth research of all hardwareand software vendors dealing with Beacons is required, elaborating Beacon setting andnetwork approaches to apply it on a subsequent solution. Before providing a solution,the ideal Beacon hardware vendor needs to be selected in terms of Beacon security, scal-ability, documentation and others. Therefor a selection matrix had to be designed inorder to choose the optimal Beacon vendor based on required use case criteria. Basedon the gathered knowledge, the elaboration of the architectural solution can be initiated.It has been developed with the objective of increasing the Beacon detection reliability.The development was based on an iterative approach, where steps consisted of a solutiondevelopment and subsequent validation. The resulted architectural solution has been im-plemented and tested by developing a prototype. It has been applied in a field study inorder to evaluate, if the detection reliability can be further increased based on the dataof signal strength. The final prototype has been compared against an existing solutionprovided by a startup company in Zurich, Switzerland in order to enhance the existingprototype and highlight improvements made with the developed prototype.

i

Zusammenfassung

Diese Arbeit präsentiert und dokumentiert den Entwicklungsprozess, wie die Erkennungvon Beacons in für definierte Anwendungsfälle zuverlässiger gestaltet werden. Im Vorder-grund wurde eine detaillierte Recherche betrieben, um den Aufbau von Beacon Netzw-erken zu verstehen und um die gewonnenen Informationen anschliessend für die Erar-beitung eines Ansatzes, der die Erkennung von Beacons durch smart phones verbessernsoll, zu entwickeln. Im Anschluss an die Recherche, wurde eine Auswahl an Beacon Hard-ware Herstellern, basierend auf Beacon Sicherheit, Beacon Skalierbarkeit und weiterenDimensionen miteinander verglichen. Aus diesem Vergleichsprozess entstand eine Matrix,die den Findungsprozess von Beacon Herstellern unterstützt. Anschliessend wurde einmögliches Beacon Design in einem mehrstufigen, iterativen Prozess entwickelt, welchesdie Erkennung von Beacons durch smart phones verbessern soll. Dabei wurde für jedeStufe eine mögliche Lösung sowie eine anschliessende Validierung dessen erarbeitet. Dasanschliessend resultierende Design wurde in einem iOS Prototypen umgesetzt, um ineiner durchgeführten Feldstudie zu evaluieren, ob die Erkennung von Beacons verbessertwerden kann. Dabei wurde das Augenmek vor allem auf die Signalstärke gelegt. Derfinale Prototyp wurde mit einer existierenden Lösung, die von einem Schweizer Statupmit Sitz in Zürich bereits aktiv läuft, verglichen. Dabei wurde der Prototyp vor allem umgewinnbringende Ansätze der existierenden Lösung erweitert, sowie die Verbesserungendes Prototyps bezogen auf die existierende Lösung aufgezeigt. Weitere Arbeiten wären,dass die Selektionsmatrix um weitere Beacon Anbieter erweitert wird oder die Improvi-sation des Prototypen um diesen um eine SDK-Version auszuweiten.

iii

Acknoledgements

I thank several people for their continuos support to allow me realizing this master thesis.First and foremost, I like to express my gratitude to my supervisor Jan Berchtold for hiscompetent assistance, patience, guidance and insightful comments during my thesis. Iappreciate Prof. Dr. Burkhard Stiller in giving me the opportunity to to write this thesisat the Department of Informatics of the University of Zurich.Furthermore, I like to express my thanks to Dr. Corinna Schmitt and Dr. Thomas Bocekfor the enlightening discussions and their competent support, which allowed me to improvethe design of my thesis significantly. Last but not least, I like to thank my family andclose friends for their support throughout this work.

v

Contents

Abstract i

Zusammenfassung iii

Acknoledgements v

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Description of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Related work 3

2.1 Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Bluetooth Low Energy (BLE) . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Bluetooth modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 Monitoring and ranging . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Beacon formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 AltBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Eddystone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 iBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Beacon security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Security threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Battery performance impact . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Apple iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vi

CONTENTS vii

3 Vendor comparison 16

3.1 Estimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Gimbal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Radius Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Kontakt.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Comparison dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5.1 Sufficient documentation . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5.2 Security features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.3 Cloud based Beacon management . . . . . . . . . . . . . . . . . . . 21

3.5.4 Scalability support . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Selection matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Architectural Beacon design 26

4.1 Use case definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Architectural design development . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Iterative development . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.3 Design validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Prototype improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 Comparison against existing solution . . . . . . . . . . . . . . . . . . . . . 45

5 Evaluation 52

5.1 Performance impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Architectural design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Summary and conclusion 54

6.1 Summary & Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Bibliography 56

viii CONTENTS

List of Figures 62

List of Tables 64

List of Listings 65

Appendix A Contents of the CD 67

Appendix B Diagrams 68

Chapter 1

Introduction

During the last few years the overall worldwide digitization increased. Mobile phones be-came smart phones, personal computers got more and more replaced by tablets. Googleintroduced their first autonomous driving car [39]. This development indicates, that theoverall interconnection between humans and digital devices increases. Digital devices - es-pecially smart phones - start to get indispensible in our every day life. Today it’s alreadypossible to use them as payment device. Apple Pay [18] or Paymit [55] already demon-strated that there exists potential in the market for those solutions. Researches evenshowed, that the interest in location based push notifications among millenials rise signif-icantly [62]. Besides all digitization approaches, location provided notifications can gainimportance in the near future. Therefor it makes sense to investigate solutions providinglocation based detection methods deeper, to identify their strengths and weaknesses inorder to find the best fit for a given use cases.

1.1 Motivation

This thesis develops a reliable Beacon detection architectural design with iBeacons. iBea-cons were introduced in 2013 by Apple and are specialized Beacons. This specializationwill be clarified later in Chapter 2.2. After Apple introduced the iBeacons, various im-plementation approaches using iBeacons emerged in industry [26]. Beacon vendors offera cloud based Beacon management platform and the assembly of the physical hardware(iBeacons). However, selecting the optimal Beacon vendor for a specific use case canbecome challenging in terms of Beacon security, Beacon scalability or Beacon vendorimplementation documentation. Those and other factors need to be taken into accountduring the Beacon vendor selection process. In this thesis an approach will be introducedto support administrators to select the optimal Beacon vendor for a specific use case.

According o the collaborating Swiss startup, detecting end-users patterns with Beaconsbecomes attractive. Nowadays it’s simple to enhance an existing App, that is widely usedin community with a Beacon detection framework (SDK). Which can provide the Appowner with specific end-user patterns. They can be used to specifically target Ads on

1

2 CHAPTER 1. INTRODUCTION

end-users based on their preferences. To reliable detect end-users movement and generatepatterns out of it, a sophisticated architectural Beacon design is required. Furthermorea prototype will be developed to verify architectural designs to increase the detectionreliability of Beacons. The architectural designs will be developed in this thesis.

For a sufficient input from the industry this thesis is conducted in cooperation with aSwiss startup in Zurich, Switzerland.

1.2 Description of Work

The contributions of this thesis are manifold. First, the an extensive research of theBeacon ecosystem is conducted. This includes the identification of Beacon vendors offeringdifferent types of Beacon products. Those vendors will be analyzed and compared to eachother according to certain dimensions, like Beacon security, pricing structure, Beaconconfiguration ease-of-use and others. Based on the findings a selection matrix will bedeveloped. This matrix is applied to select the optimal Beacon vendor. Simultaneouslythe study of the Beacon format is part of the first step.

The subsequent conducted field study consists of an iterative development of an archi-tectural design, to enhance the detection reliability of Beacons by smart phones. Thearchitectural design will be validated in a real word scenario (field study) which requiresthe development of an prototype. The gained results of the field study are comparedagainst an existing prototype developed by a cooperating Swiss startup, to determine theimprovements.

1.3 Thesis Outline

Chapter 2 explains the overall Beacon setup. Especially the format which is used to es-tablish a connection between Beacons and smart phones. It highlights existing securitythreads that arise with the Beacon ecosystem such as piggybacking, hijacking and phys-ical impact. Provides information about the available Beacon formats and states theiradvantages and disadvantages.

Chapter 3 aggregates the results of the Beacon vendor research. It introduces a matrix tosupport administrators with the selection process of finding the optimal Beacon vendorfor a dedicated use case scenario. The matrix will be applied to select the optimal Beaconvendor for the conducted field study in this thesis.

Chapter 4 introduces the developed architectural design and describes the iterative ap-proach adopted. It describes the prototype and highlights the insights gathered withtesting in a real world scenario. The architectural design is developed based on the find-ings and the insights obtained by research from Chapter 2 and 3.

Chapter 5 presents the evaluation results of the field study and summarizes future worktopics.

Chapter 2

Related work

In this chapter the conducted research of related work is documented. Due to the fastchanging economy of Beacon products, most research references are Blogs and Websites.Findings in this chapter are fundamental for further development of this thesis.

2.1 Beacons

Beacons are composed of a hardware and software component. The hardware consists ofa microcontroller with a Bluetooth Low Energy (BLE) radio chip attached and usually abattery as power supply [25]. Besides batteries, Beacons can also be powered by externalsources, i.e. a USB dongle provided by Radiusnetwork (see Chapter 3.3).

Beacons emit a Bluetooth signal on a defined interval. The signal can be detected bysmart phones if it’s within the Beacons proximity and Bluetooth is activated on thesmart phone. So Beacons can be used to create proximity areas where the boundary isdefined as the signal strength of the Beacon. These proximity areas are named Regions.An App installed on a smart phone can define up to 20 Regions [10]. If an end-usercarrying a smart phone and enters a Region, the smart phone detects the Region entryevent and can trigger events.This thesis focuses on Beacons that are designed for Apple smart phones, they are namediBeacons.

Beacons can be configured in various ways; therefore it’s necessary to understand theBeacon architectural setting in detail. The following subsection will provide a detailedinsight into the Beacon setting.

2.1.1 Bluetooth Low Energy (BLE)

Beacons use BLE [29] to broadcast their information within its proximity area. Bluetoothcapable smart phones can detect that information and trigger customized events.

3

4 CHAPTER 2. RELATED WORK

Bluetooth was first designed to compete with WiFi networks. But it did not develop astandard to replace WiFi, it became an important protocol for over the air audio transmis-sions. In 2009 Bluetooth was extended with BLE (Bluetooth Low Energy), and 2010/2011it was implemented and ready to hit the market. The key difference between Bluetoothand BLE is the reduced power consumption. Hence BLE allowed Bluetooth to enter theIoT market, because of it’s low energy consumption. However, ZigBee [68] is still one ofBLE biggest competitors in the IoT market. [27]

One of BLE’s advantages is the exchange of data between two entities with a low powerconsumption. Therefor it provides two connection modes:

Connected mode uses the GATT (Generic Attribute) layer to transfer data over a one-to-one connection. In this setting a client or server role for each entity is defined.Whereas GAP (Generic Access Profile) defines the topology of the BLE system andallocate the roles to the connected devices. Decides, if a device is a server or a client.There is a two-way data exchange possible.

Advertising mode is characterized, by emitting a Bluetooth signal. This signal canbe detected by devices within proximity and supporting the appropriate formatof the signal. There is only a one-way data exchange possible. Beacons use theadvertisement role of the GAP. [28]

Currently there exist three Beacon formats which will be introduced in detail in Chapter2.2:

iBeacon format was first established and deployed to markets in 2013 by Apple. Applekept the detailed iBeacon format specification classified. However, some detailswhich are required for the assembly of the iBeacon are release to selected vendors[16].

Eddystone was introduced by Google in 2015 [43]. In contrast to the iBeacon formatit expands the payload by an URI. Which enhance the information richness to betransferred to a smart phone. Eddystone and AltBeacon are open-source.

AltBeacon has been established and is distributed by Radius Network Inc. [58].

2.1.2 Bluetooth modes

Bluetooth uses two different kind of Bluetooth modes. The following section explainsthe basic understanding of how data is exchanged between two devices using Bluetooth.Beacons, that use Bluetooth will apply the identical mechanism.

2.1. BEACONS 5

Advertising mode

In advertising mode the GAP (Generic Access Profile) is used. This profile defines, thata smart phone can either take a central or peripheral role (see Figure 2.1). Whereaslistening devices use the central role and broadcasting devices use the peripheral role.Listening devices such as smart phones have a defined listening interval of one Second[45]. Peripheral devices such as Beacons advertise a signal in an individual defined interval.The higher the advertisement rate, the higher the battery drain of the Beacon. But ahigh advertisement rate can lead to a faster detection.

Figure 2.1: GAP (Generic Access Profile)

Connected mode

In connected mode two devices are paired and exchange data using the Generic AttributeProfile (GATT). Using the GATT one of the two devices exchanging information mustbe either be defined as a client or a server. The client acts as the requesting device whocollects information from the server device. In a Beacon / smart phone topology, theserver acts as the Beacon and the smart phone as the client. Because the smart phone(client) requests identification data from the Beacon (server).

Figure 2.2: GATT (Generic Attribute Profile)


Figure 2.2 shows the layers of GATT approach. Between the client and the server, at-tributes are being exchanged. By definition of GATT, attributes are the smallest dataentities. They contain relevant metadata, like for example Beacon temperature or Bea-con signal interval. Applying the GATT concept, the attributes are always located onthe server and the client fetches them. GATT groups conceptually identical attributes insectors and describes them with a Service definition. Each Service contains a number ofCharacteristics. They always include at least two attributes [37]:

• Characteristics declaration provides metadata (or even an explanation) aboutthe actual data the characteristic holds

• Characteristic value is an attribute containing the data

This thesis will not go into more detail concerning the explained two modes. On theApple iOS framework they are not allowed to be configured. The next section explainshow data exchange and the connection between two devices is conducted with the Appleframework used in this thesis.

2.1.3 Monitoring and ranging

The specifications on the previous section are required in order to exchange data withintwo Bluetooth enabled devices. This thesis is focusing on the iBeacon format to exchangedata. The format is applied on smart phones in order to exchange data. It is providedby Apple and explained in Chapter 2.2.

The Apple iBeacon specification document [17] states, that Beacons are enhancementsto improve the detection quality of smart phones within a defined geographic Regiontowards other methods like GPS or aGPS [2]. A Beacon Region can be defined with asingle physical Beacon but also with multiple Beacons. Beacons emit a circular signalwhich can be detected by a smart phone supporting the Beacon format. In contrast toGPS, where the location of the smart phone is identified outdoors using GPS, Beaconscan also be used for indoor localization. The power consumption of a Beacon network isless compared to a GPS based approach [24]. But GPS does not need to be activated bythe smart phone user like Bluetooth, which is required for Beacons to be detected.

An App installed on a smart phone can trigger events in two different modes:

• Background-mode

• Foreground-mode

If the end-user is not directly interacting with the App or the smart phone is locked andthe screen is dark, the App is in Background-mode. If the smart phone is not locked,the respective App is opened on the smart phone the App is in Foreground-mode. Thetype of scanning for Beacons differ depending on the mode the App currently uses. Hencethere exist two different types of scanning for Beacons:

2.1. BEACONS 7

• Monitoring

• Ranging

An App starts with Monitoring as soon as the end-user has permitted the App to useLocation-Services. The App continues Monitoring also while the end-user has openedother Apps or the smart phone is locked. On the other hand, Ranging can be initiated,if Monitoring has detected a Beacon while the App is in Background-mode or while theend-user is interacting with the App. Ranging is used to provide extra information aboutthe Beacon. This extra information can be for example temperature of a Beacon orbrightness factor. Transferring these extra information, will lead to an increase in powerconsumption and Apple suggest to reduce the Ranging activity to a minimum [19].

Regions, an App need to scan for are defined within the App source code. An App thatis running in Background-mode can monitor for a defined set of Regions. This enablesthe App, to detect if a smart phone end-user enters a Region even if the App is not inForeground-mode. Which could hypothetically lead to a total surveillance of the end-userby a third party. So Apple limited the number of defined Regions per App to a maximumof 20 [17]. However, the Regions can be changed while the App is running. According to[17], there are three combinations between UUID, Major and Minor possible to define aRegion. So a Region can be defined by [33]:

• a single UUID: A Beacon Region will be defined by an UUID.

• a combination of UUID and major: A Beacon Region will be defined by an combi-nation of UUID and major.

• a combination of UUID, major and minor: A Beacon Region will be defined by ancombination of UUID, major and minor.

This thesis will address the combination of how to define Regions in Chapter 4.2.3 inmore detail.

A UUID is used as a unique identifier. To preserve it’s uniqueness, it has to be generatedusing a specific algorithm as defined in the RFC document [66].

If the end-user has activated Location-Services, which allows the App to monitor Beacons,it will trigger events if the App enters or exits a defined Region. Monitoring allows the Appto only determine entries or exits of Regions. It can happen, that events on Monitoringmode will be triggered up to 5 Minutes [61] delayed.

In contrast to Monitoring, Ranging is more responsive. It can determine the approximatedistance between the Beacon and the smart phone and also improve the responsivenessof entry and exit events. According to [35] and [38], ranging in Background-mode is notfavored by Apple. Unless there is obvious benefit for the end-user available. Otherwisethe App might not get approved by the Apple review approval process. Ranging has ahigher battery consumption (see Section 2.4) in contrast to Monitoring and it allows totrack the movement of the end-user in detail, which can lead to privacy concerns.


Triggered exit events can arise from false-positives. E.g., when a physical object suddenlyobstructs the Beacon and its signal is not detectable for a few Seconds. To preservefalse-positives, a 30 Seconds delay is implemented.

2.2 Beacon formats

A Beacon format in this thesis is defined as the package type, a Beacon emits and thatcan be detected by smart phones having proper software implemented, which can read thepacket data. In the Beacon ecology, there exist various vendors providing their individualBeacon format in order to differentiate from their competitors. Subsequently a selectedrange of Beacon formats used in this thesis are introduced.

2.2.1 AltBeacon

AltBeacon is an open source Beacon format developed and provided by Radius NetworksInc. [60]. It was introduced in July 2014 [60]. At first Radius Network named theirBeacons iBeacon. Suddenly they had to change it to AltBeacon, because iBeacon wasprotected as trademark by Apple [4]. Not only the brand name changed, they also openedup the format for developers to increase configuration possibilities. The Radius Networkvendor, who distributes the AltBeacons, provides the possibility to advertise iBeacon andAltBeacon at the same time [4].

2.2.2 Eddystone

Eddystone is an open source Beacon advertisement format for BLE devices developed andprovided by Google [43]. It was introduced in July 2015 [60]. The advantage of Eddystoneamong other Beacon vendors is the multi-Beacon concept. Which means, that a singlehardware (E.g., a Beacon) can broadcast multiple packets that can be used independently[36]. The available packet’s are listed below:

Eddystone-UID transmits the basic UID of the Beacon. The UID consists out of anamespace and an optional instance. According to Googles Eddystone Specification[36], the namespace is used to group a specific set of Beacons, whereas the instance isset to define single Beacons. To improve performance, the scanning can be reducedto the namespace of the Beacon.

Eddystone-URL is a URL frame broadcasted, as well as using a compressed encodingformat. This URL is well formatted once it’s decoded. The URL can be used as astandard formatted URL.

The Eddystone-TLM telemetry frame broadcasts relevant information about the Bea-con itself. Such as battery status, Beacon temperature or broadcasting packets.

2.2. BEACON FORMATS 9

Stated that AltBeacon invented the multi-Beacon concept already two years ago. Googleis the first company developed a standard for multi-Beacons [60]. Nowadays almost allBeacon vendors investigated during this thesis provide a multi-Beacon concept. Theadvantages of a multi-Beacon concept will be addressed later in this thesis.

2.2.3 iBeacon

iBeacon is a standardized BLE advertisement format developed by Apple [13]. It issupported by all, in this thesis analyzed Beacon vendors. The iBeacon format uses anadvertisement package that broadcasts three data elements [60]:

• UUID (16 bytes)

• Major is a number identifying a subset of Beacons in a group (2 bytes)

• Minor is a number identifying a single Beacon (2 bytes)

Apple defined the maximum amount of available Regions per App to 20 [17]. Whichmeans an App can only scan for 20 Regions the same time. However, the Regions can beadjusted during runtime which offers the administrator to extend the amount of availableRegions per App to theoretically infinite number.There exist 216 Major and Minor values. Which leads to a theoretically total amountof 232 Regions to be defined based on one UUID. So the amount of total Regions to bedefined is quite high.

Apple has introduced a framework to detect Regions within an App. The so calledCoreLocation Framework [9]. It handles all location functionalities on an App. Geofencesdetected by GPS signals or Regions detected by Beacons are included. CoreLocationFramework is also responsible for the privacy handling on the device. Which means thesmart phone end-user can deactivate Location-services which leads to deactivation of allor a subset of services the CoreLocation Framework provides.

The fact, that Eddystone Beacons provide a lot of handy functionalities, such as URL andTLM it’s obvious that it can be used as a replacement for the iBeacons. However, one ofthe major drawbacks is, that Eddystone Beacons cannot be detected on smart phones inBackground-mode using CoreLocation Framework. To proper detect them while the Appis not in Foreground-mode, CoreLocation Framework is required. In order to apply theCoreLocation Framework to Monitor for Beacons also in Background-mode, the feature„use BLE accessoires“ needs to be enabled [34] which makes it difficult to get the Appapproved by the Apple AppStore Review process [7]. Therefor it’s not a simple task toget Eddystone working with smart phones. Whereas for Android devices, the process ofuploading an Android application to the Google Play Store [44] does not require a detailedapplication review. There are rumors [53], that a combination of Eddystone and iBeaconmight fix this issue. Using iBeacons to wake up the smart phone and start to detectEddystone Beacons using the CoreBluetooth framework on iOS. According According to[50] the Eddystone-URL can only be detected by Chromium browsers on the smart phone,


this fact makes it even less interesting for Apple devices, because the Safari browser isalready preinstalled. Most vendors support Eddystone besides iBeacon; like Estimote,Gimbal, Kontakt.io and Radius Network.

2.3 Beacon security

Beacon networks are rather insecure. Depending on the use case, it can lead to serioussecurity threads. A prime example; the CES (Consumer Technology Association) 2014scavenger hunt in Las Vegas [30]. The CES intend to encourage their visitors visitingkey areas of the show and earn so called "badges" if they have been the proximity of thearea. For this kind of setting, the Estimote Beacons used without any kind of securityalgorithm implemented. The fact, that every Beacon emits identical signals (i.e. uses thesame Region) for the complete time of the exhibition brought up the idea of piggybackingthe Beacons. So that a visitor did not have to physically visit the key areas of the CESin order to win the scavenger hunt.This example demonstrates the importance of having a sufficient pre investigation ofpossible security threads and provide solutions for them. This section will exemplifycurrent security threads and introduce solutions.

2.3.1 Security threads

There exist various vulnerabilities that can lead to Beacons getting taken over or modifiedby third parties. Subsequent several possible threads are highlighted.

Piggybacking

If a third party listens to the broadcasting signal of the Beacon, copies it and uses itat another place makes your App think you are in the Beacons proximity although youaren’t. Since most Beacons broadcast the identical signal for their lifetime, piggybackingcan become a serious thread to Beacon networks and should be paid heed to.

A solution would be to use rolling or rotating UUID’s. The approach with the rollingUUID’s requires, that the App conducts a server call for every Beacon detection. Becauseonly the server is aware of the rolling UUID list of the Beacon. Whereas with a rotatingUUID approach the Beacon repeats the identical UUID pattern. The interval for rollingor rotating UUID’s can be between Seconds and Minutes. The more often the UUID ischanged, the more secure is the Beacon, but the higher the costs are in terms of servercalls or UUID usage. Because the maximum amount of UUID’s available on a smartphone to scan for are limited to 20.

2.3. BEACON SECURITY 11

Hijacking

The Beacon firmware is required to be updated from time to time. During the updateprocess the device needs to connect with the Beacon will be authorized and gained accessby providing credentials to the Beacon. A man-in-the-middle is able to fetch or alter thetransferred data between the two device. However, the probability this case occurs is low.The hijacker must be in proximity of the Beacon or have a divide installed sniffing thetransferred data.

To prevent hijacking attacks, data sent and received from the Beacon while configuring itneeds to be encrypted. Hence encryption requires more CPU power and therefore moreenergy consumption.

Physical impact

Beacons can be exposed to the public. Strangers can gain access to the Beacons bymodifying, destroy or replace it. The probability this will happen is low, since the effortinvolved is quite high. But if the Beacon controls the opening of a garage door, the effortcan be payed off.

Furthermore due to the small size of Beacons, the probability of cracking them is low.The best protection against physical impact is to hide the Beacon inside or outside of thevenue so that crossing pedestrians cannot sight it.

To sum up on the various threads. The impact of a specific security thread always dependson the use case and environment the Beacons are used. For example sending personalizedcampaigns to customers in the proximity of a shopping mall has a lower security impactthan a Beacon opening a garage door.

Beside security threads decreasing the Beacon reliability, the energy consumption of thescanning for Beacons on the smart phone can also reduce the reliability in detection. Forexample if the end-users smart phone is powerless, it cannot be detected anymore neithercan detect any Beacons within its proximity.


2.4 Battery performance impact

Due to the fact that scanning for Beacons need continuous activity in the background ofthe phone, the overall battery drain increase. A fast draining battery can also lead to anegative performance impact of the smart phone. The smart phone starts with the powersaving mode earlier than without background activity.

Figure 2.3: Battery drain: Device comparison [3]

According to an experiment [3], in real-life scenarios the normal battery consumption ofsmart phones is below one percent for daily usage. The experiment was conducted usingApple and Android smart phones. Figure 2.3 shows the battery consumption betweenthem differ significantly. This is caused of the Beacon sampling used on BLE chipsets.Android provides smart phones with a newer BLE chipset than the Apple iPhone 5S. Forexample the Moto G BLE chipset decodes only about 25 to 33 percent of all receivedBluetooth signals. This makes them very power efficient compared to other devices.

2.4.1 Apple iPhone

The scope of this thesis deals with Apple iPhones. Android phones will not be used fortesting in this thesis. Therefore it’s crucial to have a more into depth research of the powerconsumption of iPhones. Considering Monitoring and Ranging states on the iPhone itsnecessary to investigate the energy consumption of those states. So the following threescenarios have been tested:

• Comparison between Monitoring / Ranging

2.4. BATTERY PERFORMANCE IMPACT 13

• Foreground-mode and Background-mode Ranging

• Ranging with Server-Call

The following tests were conducted using an iPhone 6 with iOS 9.0 installed, fully chargedand connected to power. Data is exchanged using WiFi.

Comparison Monitoring / Ranging

The general contrast between the energy consumption on Monitoring and Ranging isdiscussed. Figure 2.4 shows a energy consumption of an App running on a smart phone.The data is fetched from the smart phone using Xcode [67] running the App explainedin Section 4.2.1. Each square denoted one Second in time where the x-axis is the timepassed. The four rows on the y-axis defining the smart phone services CPU, Network,Location and Background denominate if a certain service is used. The blue bars on thetop mark the total energy consumption in time.

Figure 2.4: Energy consumption: Monitoring and Ranging

CPU indicates, that the CPU (Central Processor Unit) of the smart phone is used.Which imply that some calculations are going on.

Network indicates, that the smart phone is communicating with a remote server usingits built in 3G or WiFi.

Location indicates, that the Location-Service is active. It represents the smart phonedetecting the end-users current location using various services that are provided (i.eGPS, WiFi or Bluetooth).

Background indicates, that the Background-mode is currently in use.

Figure 2.4 shows the energy consumption of an App executed with initially no Beaconswithin its proximity. However, the App has one defined Region Y to Monitor for. Soinitially it starts with Monitoring which scans for the defined Region. There is no Back-ground and Location activity going on. This implies, that monitoring does not requireextra power. After about 16 Seconds, a Beacon broadcasting the Region Y appears withinthe Apps proximity. On Figure 2.4 a sudden increase of the energy consumption visualized


by the blue bars. Meaning, that the Location-services started to run in Background-modeand the App started Ranging for Beacons within its proximity. The appearance of thegray block in the Background row implies that the Background-mode is active. Thisproves, that there is a significant energy usage difference between Monitoring and Rang-ing on an iPhone.After the Ranging has started, the App is opened manually by the end-user on the smartphone. Thus the Location-services can switch from Background- to Foreground-modewhich leads to a decrease in the overall Apps energy consumption. This can be seenin the drop of the blue bars after about 32 Seconds. Simultaneously the Backgroundservice has stopped. Comparing the blue bars on top between Background-mode andForeground-mode shows on Figure 2.4, that the overall energy consumption is twice asmuch for Ranging in the Background- than for Foreground-mode.

Ranging with Server-Call

During the Ranging mode, a smart phone sometimes needs to communicate with a serverto send data like Beacon battery or health statuses to a central entity E.g., a server.Therefor HTTP calls are conducted and they often also happen while the App runs inBackground-mode. Especially if of Beacon security is applied, the amount of server callsincrease. Likewise there might be a solution to increase the reliability of the Beacon de-tection by increasing the amount of server calls to swap the application logic from theApp onto a central server entity.

Figure 2.5 shows the energy consumption timeline of an App that runs in Background-mode. After two Seconds it detects a Beacon and starts to send a simple HTTP call(approx. 100 Bytes) for every Second. The overall energy consumption of the App israted as Overhead. Hence every server call uses a lot of energy relative to all otherservices the App is using. So this implies that its not efficient, to execute a lot of servercalls while the App is in the Background-mode. Interestingly, the energy used for everyhttp call does not decrease over time. Which leads to the fact, that a few calls with a lotof data is more performant than a lot of low data calls.

Figure 2.5: Energy consumption: HTTP server call in Background-mode

All vendors SDK’s are required to have an working internet connection in order to workproperly. If the SDK is used, a lot of updates of the detected Beacon will be sent to the

2.4. BATTERY PERFORMANCE IMPACT 15

server of the vendor. Particularly if a security feature is activated a server call on everyBeacon detection is required, hence an increased battery drain is possible.

Sometimes it happens, that every second blue (see Figure 2.5) bar is just half the heightof the preceding one. This might imply that there is some sort of optimization in sendingHTTP server calls.

Conclusion

Since this thesis focuses on Apple iPhones, Ranging in Background-mode should be re-duced to a minimum. The optimum would be, if Ranging can be dynamically adapteddepending if its required to increase detection reliability or not. Or stimulating the end-user to open the App, so that the App can enter Foreground-mode which would reducethe relative energy consumption of the App.

Additionally the amount of server calls need to be minimized so that the overall energyconsumption can be reduced.

Chapter 3

Vendor comparison

During the last few years, various vendors developed their individual Beacon product andtried to distinguish themselves from other competitors with innovative features. Besideselling plain Beacons, which are hardware based devices with handy functionalities liketemperature or motion sensors, vendors pursue to keep there customers with them andgenerate Lock-In’s. It’s obvious that a product, based on hardware components is on theone hand easy to copy, and on the other hand the price is the only differentiation amongcompetitors. Time passing, vendors discovered that the management of a large amount ofinstalled Beacons in production requires a sophisticated software handling them, as wellas configuring they’re settings like UUID, Major, Minor and RSSI settings. Configuringeach Beacon by hand takes big effort. E.g., it takes about five Minutes for a Beaconadministrator, to add a 36 digit UUID, Major and Minor in order to have a Beacon con-figured and ready for production. Rolling out between 100 and 200 Beacons, will takeabout 12 Hours just for the configuration. So vendors introduced cloud based servicesallowing administrators to manage their Beacons online. Further they provide an App,which can be used to configure a Beacon within Seconds. The App, however still needsto be within the proximity of the Beacon in most cases. But it does not require enteringcomplex UUID’s, Major / Minors, signal strength settings. Besides, the vendors also pro-vide a customized SDK that can be integrated with an existing App. Some SDK’s evensupport automatic update of Beacons, without the need of a Beacon administrator to bewithin it’s proximity.There are a lot of Beacon vendors active in the market. In cooperation with a startup inZurich, focusing on a few vendors who have gained a sustainable position at the market. Itwas especially important, that they allow shipment of their products to Europe/Switzer-land for further testing and comparison of the functionalities.

The following chapters introduce the vendors being compared followed by a comparisonof them based on defined dimensions.

16

3.1. ESTIMOTE 17

3.1 Estimote

Estimote was one of the first vendors on the market after Apple introduced iBeacons in late2013 [22]. Estimote is a startup company founded 2012 in Poland by two entrepreneurs.Their vision is to reinvent the shopping experience with contactless payment solutions.Over the last few years they continuously improved they’re core product and gain marketshare with the Estimote Beacons. There exist two different versions of the EstimoteBeacons; location Beacons or proximity Beacons. As the name predicts, location Beaconsare optimized for indoor location tracking whereas proximity Beacons are optimized todetect end-users entering the proximity area of a Beacon. However, for both Beaconversions the replacement of the battery was suboptimal. The Beacon cover had to bedestroyed in order to get the battery. Estimote began to ship Beacon covers on goodwillfor customers who destroyed the Beacon cover replacing the batteries. In 2015 theystarted with the shipping of an improved Beacon in terms of the cover, so that the batteryreplacement is easier. Alongside the product development they established a remarkableonline community, where they share they’re immense knowledge about iBeacons. Besidesto their online presence, they installed Beacons at numerous places in Europe and eventhe US. [31]

3.2 Gimbal

Gimbal was founded by Qualcomm, a worldwide, stock listed operating company. Endof 2013 Qualcomm announced that it’s subsidiary, Qualcomm Retail Solutions Inc. hasreleased its Gimbal proximity Beacons to the public. Qualcomm Retail Solutions’ strategyis to „empowering brands to take mobile engagement with their customers to a whole newlevel through micro-location“ [57]. Gimbal Beacon provides solutions for location servicesfor venues, retailers, advertisers and also for individual platforms. Further they haveimplemented a sophisticated security approach, which makes it almost impossible forthird parties to piggyback they’re Beacons. [57]

In 2016 Gimbal launched a test in cooperation with Citibank in the US where customersapproaching they’re branches out of office hours, the doors automatically open. As longas the customer has the Citibank App installed on his smart phone and the detection ofthe Beacon occurs, they can open the door without the need of a debit or credit card.[42]

3.3 Radius Network

Radius Network, that was founded in 2011, develops and supports the open Beacon for-mat AltBeacon. The company’s headquarters are in Washington DC. in the US. They’rebusiness is development and distribution of a Beacon product, named AltBeacon. A prox-imity Beacon that supports multiple Beacon formats. E.g., it supports the iBeacon and

18 CHAPTER 3. VENDOR COMPARISON

Eddystone as well. Furthermore they offer a full-stack managed service for proximitytechnologies and services installation. They provide a campaign and proximity kit whichis ready to be use within their cloud-based provided service. Campaign kit offers adminis-trators to create proximity based campaigns. E.g., if a customer enters the proximity area,he gets a notification on his smart phone about the campaign. In contrast to Estimotethey focus more on business customers in order to develop tailored enterprise solutions.[58]

3.4 Kontakt.io

Kontakt.io was founded in 2013 besides Estimote with the goal of helping visually hinderedto navigate within public areas. They also - like most other vendors - have a Beaconproduct; called the Kontakt.io Beacon. Which can be bought in different versions; a smartBeacon, a thought Beacon that is optimized for outdoor usage and a cloud Beacon whichcan connect to WiFi networks and scan for WiFi devices. They provide a deeper productrange in contrast to Estimote. However, Kontakt.io is less focused on specific solutions,like for example Estimote is focused on indoor location tracking solutions. They providea service, that is more focused on the product itself than on a specific implementation.

3.5 Comparison dimensions

In this section the comparison of the various Beacon vendors will be conducted, to identifytheir strengths and weaknesses, in order to simplify the process of selecting an optimalBeacon vendor for a specific use case. Furthermore a selection matrix will be developedto simplify the selection process of Beacon vendors. For this thesis the matrix will beapplied to determine the optimal Beacon vendor used for the iOS prototype developed inthis thesis.

Four dimensions are being defined, which will be used to analyze the vendors. Thosedimension have been chosen based on the collected knowledge gathered at the researchphase. Subsequently, vendors will be compared based on the dimensions:

• Sufficient documentation

• Security features

• Cloud based Beacon management

• Scalability support

The scale used reaches from 1 to 3, where 1 is the worst and 3 the best. A 3 stands foravailable, an 2 for partially available and 1 for not available.

3.5. COMPARISON DIMENSIONS 19

3.5.1 Sufficient documentation

A sufficient, detailed and complete documentation is key for a swift integration of thevendors providing SDK integration for an existing smart phone application. Thereforethe overall explanation profoundness as well as the documentation structure needs to besufficient in order to guarantee a smooth integration by administrators.

According to 3.1 the vendor with the most favorable relative documentation is Estimotebecause of the highest summative average of 2.75.

Gimbal Kontakt.io Radius Network EstimoteIn-depth detailed installation 2 3 2 3instructions for SDKIn-depth detailed documentation 2 2 2 2for beacon managementAvailable documentation for 2 2 2 3general beacon understanding(ranging/monitoring)Support responsiveness 3 3 3 3and competencySummative average 2.25 2.5 2.25 2.75

Table 3.1: Documentation features provided by vendor

Estimote and Kontakt.io provide a detailed, good structured and comprehensive in-depthinstallation instruction for the SDK integration. Both have tutorials based on the pro-gramming language Swift [21] and Objective-C [54] in contrast to Radius Network andGimbal who only provide Objective-C tutorials. Gimbals SDK documentation is not up-todate and they do not provide CocoaPods integration [8], where the other Beacon vendorsdo. The documentation for Gimbal is not satisfying at all in terms of structure. They’redocumentation does not provide any kind of search functionality or consistent flow. How-ever, Gimbals documentation is very detailed, explaining many functionalities, how theywork and what prerequisites are required. For example to detect the dwelling time of anend-user, a specific package is required to be installed on the Beacon. Unfortunately theoverall documentation is hidden and not transparently available E.g., on the homepage.

Estimote and Kontakt.io further established an active community, dealing with iOS spe-cific Beacon configuration issues. For example they explain how to surpass the iOS specificlimit of defining only 20 regions. The community with Estimote has developed a largeknowledge base for the general Beacon understanding. Gimbal does not have any. Kon-takt.io and Radius Network have sufficient Blogs.

All vendors provide a very good and fast support responsiveness. On average an answerwithin 48 Hours is realistic. So the Support responsiveness and competency value for allvendors is 3.

According to our investigation results Estimote or Kontakt.io might be optimal to go with.They provide a sufficient documentation, a cooperative community and comprehensibledocumentation.


3.5.2 Security features

A traditional Beacon setting does not have any mechanism integrated to prevent piggy-backing, hijacking or physically capturing Beacon. Most use cases do not require a secureimplementation. Though if an approach will be used E.g., for an end-user payment trans-action at a Point of Sale, a secure connection becomes fundamental.

It can be necessary, that for some use cases the security aspect of the Beacon / vendoris crucial for the due diligence process selecting a vendor. Therefore provided securitysettings for each Beacon vendor needs to be identified. Especially approaches like UUIDrotation, MAC rotation, Major/Minor rotation and prevention of piggybacking, hijackingand physically capturing a Beacon explained in Chapter 2.3. Those approaches providesolutions in order to increase the immunity of Beacon networks.

Gimbal Kontakt.io Radius Network EstimoteUUID rotation 3 3 1 3Prevent piggybacking 3 2 1 2Prevent hijacking 3 2 2 2Prevent physically capturing 1 1 1 1a beaconSummative average 2.5 2 1.25 2

Table 3.2: Vendor provided security features

The investigated vendors cover the security features as pointed out in Table 3.2. AlthoughGimbal does not provide a full coverage of all security approaches in Table 3.2, they stillhave the most incomprehensible security implementation of all analyzed vendors. First,the exact security approach is not disclosed. Gimbal does not state any details on theirwebsite, neither they reveal any details requested by e-mail. According to conducted tests,a Gimbal Beacon broadcasts a different UUID every Second. An Estimote or Kontakt.ioBeacon with security enabled, would broadcast a rotating pattern of UUID’s. However,Gimbal must use a random UUID rolling approach. Because the Beacon changes its UUIDevery Second, and there is no rotating pattern observable. Since every App can only scanfor a maximum of 20 different UUID’s, and there is still no pattern observable within 30UUID’s fetched from a Gimbal device, meaning the Gimbal Beacon must somehow sendout fake and pure UUID’s mixed up. Those faked UUID’s are probably generated basedon an internal algorithm. How this exactly looks like and how it interrogates with theBeacon and SDK is unknown. The Gimbal Beacon uses 4 AA batteries to be poweredand leasts about 18 months, which is much more compared to other vendors who onlyneed a coin-battery to stay up approximately 24 months [47].

Kontakt.io released new Beacons in 2016 with an enhanced security implementation [49].This means Kontakt.io and Estimote become evan to Gimbal in terms of security re-quirements. They are, however not as secure as Gimbal is, but for most use cases theyprobably suffice. That’s why Kontakt.io and Estimote get a value of 2 on piggybackingand hijacking prevention in Table 3.2.

Radius Network does not provide any kind of security implementation. However, theyprovide a Beacon that can be edited remotely only. Thus it cannot be edited using BLE,

3.5. COMPARISON DIMENSIONS 21

only if its connected with a wire to the personal computer. Which means this Beaconcannot be hijacked by a third party user.

If a high-end security approach is not required, either Kontakt.io or Estimote would be agood approach. They provide an adequate security implementation which is sufficient formost use cases. However, if security is a deal killer, Gimbal is the best approach.

3.5.3 Cloud based Beacon management

Every vendor provides specific functionalities and services to improve the Beacon man-agement ease of use in their cloud based SaaS (Software as a Service) solutions. Amongvendors, those solutions can differ in functionalities and specialization. Therefore it’s sup-portive in order to select the optimal vendor, to compare and identify the functionalitiesand specializations among vendors (see Table 3.3).It would have burst this thesis scope, if all available functions and services of the SaaSsolutions would have been taken into account. Hence only a few - the one most importantin my opinion - have been selected.

Gimbal Kontakt.io Radius Network EstimoteConfigurable templates 3 1 3 1Geofencing available 3 1 3 3Beacon sharing 2 3 1 2Beacon bulk options available 1 3 1 2Supported Beacon formats single (2) dual (3) single (2) dual (3)(Eddystone and/or iBeacon)Notification of Beacon 2 2 3 1health statusRemote Beacon management 1 3 3 1API access 3 3 3 3Summative average 2.125 2.375 2.375 2

Table 3.3: Vendor provided SaaS services

Preconfigured templates can be used by administrators to bootstrap a specific use casefast, E.g., end-user notification on entering a shop. Templates reduce the complexity andsetup-costs for the administrator, because there is less configuration needed. They alsodecrease the generics, meaning that an administrator can configure individual specializeduse cases.Gimbal and Radius Network provide preconfigured templates. Radius Network supportsa complete campaign kit, where administrators can define Regions at which end-users willbe notified if they enter the Region. Administrators can add the notification text, whichwill be displayed on the end-users smart phone on entering the Region. For example acampaign is created in order to notify end-users approaching the physical shop, that thearrival of the new summer collection has arrived. If the Radius Network SDK is integratedin the existing App of the shop and the administrator configures the campaign correctly,end-users approaching the shop will be notified about the new summer collection.


Gimbal even provides services to integrate remote Push Notifications sent using APN [20]within their SDK. In general APN need to be configured separately. With Gimbal anAPN can, for example be sent to the end-users device after a predefined dwelling time ofthe end-user has passed or a defined RSSI value has been reached.Kontakt.io and Estimote do not support Preconfigured templates. Gimbal, Radius Net-work and Estimote can define GPS based areas based on longitude and latitude. These areso called Geofences - regions defined on latitude and longitude pairs. Despite Geofencingis not as accurate as the Beacon approach, it’s still a good opportunity to increase theamount of regions available per App. In theory it’s possible to dynamically change the20 Regions defined in the App source code, depending in which Geofence the end-userremains.Sharing of Beacons between user accounts of the same vendor is possible with Kontakt.ioand Estimote. However, with Estimote the process is more complex than with Kontakt.io.Gimbal provides Beacon sharing only with extra fees [40].Bulk options, like the import and export of a lot of data is only available with Kontakt.ioand Estimote. Kontakt.io provides more detailed functionalities of bulk options, espe-cially on the part of importing Beacon data than Estimote. Gimbal offers it, but only bycreating a support ticket. Radius Network does not support bulk options neither Beaconsharing among users.

According to a release by Kontakt.io it is possible that a Beacon broadcasts the iBeacon orEddystone formats in dual (concurrent) mode [48]. This makes it theoretically possible,to use the Eddystone concept with Apple smart phone. The Eddystone Beacon formatcan only be discovered while an Apple smart phone is Ranging, which means eitherthe end-user must have started the Ranging manually or the smart phone must havedetected a Region. But only an iBeacon format can be detected by Apple smart phonesin Background-mode. Thus to detect a Region, a Beacon emitting an iBeacon formatmust be within proximity. Now, that there are Beacons available emitting both formats,it’s possible to detect a Region using the iBeacon format, start Ranging and detect theEddystone Beacon. However, only Kontakt.io and Estimote provides dual Beacon formats(Multi-Beacon concept).To track the Beacon battery status, vendors have various approaches. Gimbal displaysthe battery status but does not notify the administrator on a critical battery nor showsthe last time the Beacon battery status was fetched from the device. Kontakt.io providessetting up a personalized Push Notification service in order to notify the administrator ifthe battery status of a Beacon goes below a defined boundary. With Radius Network theuser can define notifications if the battery level drops a specified threshold or the Beaconwas not seen for certain amount of days, which makes it the most flexible approach forBeacon notifications among all vendors.Radius Network further offers a Beacon that can be managed remotely, which means thesettings on the Beacon can be edited without the need of a smart phone in its proximityor a running personal computer the Beacon is attached to. Kontakt.io has released a USBBeacon dongle that can be updated if the personal computer is connected and dedicatedsoftware is installed. Furthermore they sell a Cloud Beacon which is able to connectwith a WiFi network by itself in order to get updated remotely.All four vendors provide a RESTful API endpoint to manage Beacons, venues and moreusing an API.

3.6. SELECTION MATRIX 23

3.5.4 Scalability support

To provide a sustainable growth with a selected Beacon vendor it’s necessary to elaboratethe scalability availability of the respective vendor. In this section the cost factors of theinvestigated vendors will be especially reviewed.

Table 3.4 points out the cost structure of the examined vendors. Administrators need topay USD 10.00 to 33.00 to purchase a Beacon. The price per Beacon usually depends onits embedded hardware. Beacons with integrated sensors are more expensive than simpleBeacons with no extraordinary hardware.

Gimbal and Radius Network monthly fees are relatively high. Radius Network doesnot provide a plan with more than 25 Beacons installed [59]. Which does not allowadministrators to scale their Beacon network. Important to notice is the limitation of socalled Active Installs mentioned on the website [59]. For example if there are 5000 ActiveInstalls available for a specific plan, only 5000 smart phone end-users can be detectedby Beacon per month. The monthly fees of USD 9.00 and USD 49.00 are relativelyhigh compared to, for example Gimbal. Gimbals service is free to use below 49 installedBeacons or more than 5000 Active Installs [40]. The explicit fees incur are not mentionedon the website. Radius Network limits the amount of Active Installs to 25’000 whereasGimbal has no limitation, this makes the Gimbal fee system more scalable in contrast toRadius Network and thus Gimbal got a value of 3 and Radius Network of 2.

Gimbal Kontakt.io Radius Network EstimoteMonthly fees 1 3 1 3Scalable fees 2 3 1 3Initial fees 2 2 2 2Initial price USD 25.00 - 30.00 USD 33.00 USD 10.00 - 27.00 USD 33.00Summative average 1.7 2.7 1.3 2.7

Table 3.4: Vendor provided scalability factors

Kontakt.io and Eddystone do not have any recurring monthly fees. This makes them veryattractive in therms of scalability so they both get a value of 3.

3.6 Selection matrix

In order to simplify the selection process of the Beacon vendor, the vendor comparisonhas been conducted. The result of it is a selection matrix based on the determined resultsof each dimension compared among the vendors in Section 3.5.

Table 3.5 indicates the evaluated dimension value relative to the vendors. For exampleEstimote has a value of 2.75 in the dimension of Sufficient documentation, wich is thehighest relative value within this dimension. So if a company starts a Beacon projectbut has limited knowledge with Beacon technology, it should stick to the vendor with themost sufficient documentation; Estimote.


Sufficient Security Cloud based Beacon Scalabilitydocumentation features management support

Gimbal 2.25 2.50 2.25 1.70Kontakt.io 2.50 2 2.375 2.70Radius Network 1.25 2.375 2.25 1.30Estimote 2.75 2 2 2.70

Table 3.5: Selection matrix: Weighted vendors relative to dimensions

In most cases, a use case weights the four dimensions differently. For example, a specificuse case, where customers will be payed automatically, if they enter a specific proximityarea, E.g., a train. So the customers’ bank account will be automatically deducted as soonas he enters the proximity area of the Beacon. This implies, that piggybacking of Beaconsis a serious thread. So Security features will be weighted with 4. Due to the fact, the thecompany implementing the Beacon network has already gained a lot of know-how, theSufficient documentation will be weighted with 1. The Cloud based Beacon managementwill be weighted with 2 because the company needs customized notifications and a remoteBeacon management in order to get notified if Beacons don’t work properly anymore andtrain guests stop getting billed accordingly. Because the project is a market validationonly a few trains need to be equipped with Beacons, so Scalability support is not necessary.

The column of the Security features show the product of the vendor dimension values ofTable 3.5 and the weighting factor of Table 3.6 on the dimension Security features. Forexample the value 10 is the product of 2.50 and 4. The average weight displayed in thelast column, is the average of all dimensions for the specific vendor.

Sufficient Security Cloud based Scalability Avg.documentation features Beacon support weight

managementWeighting factor 1 4 2 1Gimbal 2.25 10 5 1.70 4.74Kontakt.io 2.50 8 4.75 2.70 4.49Radius Network 1.25 9.50 5 1.30 4.26Estimote 2.75 8 4 2.70 4.36

Table 3.6: Selection matrix: Security solution vendor selection

According to Table 3.6 the Gimbal vendor with a total average weight of 4.75 is the one tobe selected for this use case. This makes sense, because our use case deals with importantsecurity aspects, that need to be covered.

Vendor selection

In this thesis a Beacon vendor is required in order to conduct tests and optimize thearchitectual design. Therefore the best beacon vendor according to Table 3.5 was selected.

For this thesis, there are no special requirements required for a dimensions. So there isno need in giving them a specific weighting factor.

3.6. SELECTION MATRIX 25

Sufficient Security Cloud based Scalability Avg.documentation features Beacon support weight

managementWeighting factor 1 1 1 1Gimbal 2.25 2.50 2.25 1.70 2.18Kontakt.io 2.50 2 2.375 2.70 2.39Radius Network 1.25 2.375 2.25 1.30 1.79Estimote 2.75 2 2 2.70 2.36

Table 3.7: Selection matrix: Thesis vendor selection

Table 3.7 states, that the vendor with the highest total average weight value is Kontakt.iowith 2.39. So for this thesis the Kontakt.io Beacons are selected in order to test andverify our architectural approach.

Chapter 4

Architectural Beacon design

This chapter explains the purpose of an architectural design within this thesis and willprovide a specific architectural design solution based on a Beacon network. In order tocreate a Beacon network, the arrangement of Beacons is crucial so that the detectionreliability of the end-user can be optimized. The architectural design will define, how theBeacons need to be arranged, facilitating an optimized detection reliability. This thesiswill identify the optimized beacon arrangement for specific use cases. At first an architec-tural design is developed by support of a developed prototype. The prototype supportsoptimizing the Beacon setting. Subsequently it will be used to verify the architecturaldesign. This architectural design is developed using the iBeacon format.

4.1 Use case definition

An architectural design of Beacons can cover various types of use cases. It’s essential todefine a set of use cases need to be covered beforehand, so that a designated architecturaldesign can be developed. The use cases define constraints the architectural design is basedon. A possible constraint could be, that all end-users passing a venue need to be detected,regardless if they enter or just pass by the venue.

The following subsections will define the use cases used in this thesis.

UC A: end-user enters venue

Simulates the end-user approaching a venue and he might subsequently enter it or justpass it. Therefor it needs to be distinguished, if the end-user enters or just passes by thevenue. Entering the venue will generate a successful enter event, whereas a passing infront of the venue does not trigger an enter event, but might generate a pass by event.A possible real world setting would be a small shop in the city. The owner want’s todistinguish between walk-by and walk-in customers. If for example most of the customersdo not enter he might need to consider adding some attractive discounts in his shopwindow in order to animate customers to enter his shop.

26

4.2. ARCHITECTURAL DESIGN DEVELOPMENT 27

UC B: end-user walks by Ad-poster

In this use case, the end-user passes by the venue and cannot enter it. The venue hasno interior like the use case described before. It’s rather like an advertisement poster(Ad-poster). An identification happens if an end-user passes by the Ad-poster within theproximity of the Beacon. Moreover the direction of the end-user E.g., if he’s passing theAd-poster from left to right or from right to left, needs to be determined. Furthermoreit’ll be investigated, if there exists a possible solution to identify if the end-user is actuallylooking at the Ad-poster or just passing by. According to the cooperating Swiss startup,this approach has high demand from major advertisement firms in Switzerland.

4.2 Architectural design development

In order to develop an architectural design, that provides sufficient reliability of the Beacondetection, testing and validation is required. There is no confidence, that Beacon

Figure 4.1: Explanation of architectural design visualization

28 CHAPTER 4. ARCHITECTURAL BEACON DESIGN

networks do not suffer from interferences, which can deform results. To provide a sufficientresult, an iterative approach is chosen. A first architectural design is developed andsubsequently revised and validated. The insights gained will be applied to develop anotherarchitectural design in a subsequent iteration.

To visualize the complex architectural design of a Beacon network in detail, a graphicalsimplification is used for abstraction. On Figure 4.1 the venue (square box) and theBeacon proximity is shown from a top-down view. The dotted circle represents the Beaconemitted signal and shows the proximity area in form of a circle. Please note, that this isan abstraction of the reality. In reality, the signal edge is not a perfect circle. In context ofthis architectural design, the end-user can enter the venue thru the entry door. However,the Beacon in the center will detect the end-user already before he entered the venue,because the Beacon proximity circle covers the complete venue and more. The label 1 /{2} / {0} of the Beacon has a specific importance to understand the architectural design.The first number denotes the UUID, the second the Major and the third the Minor theBeacon is emitting. A combination of these three numbers allow us, to define a Region.However, a Region can also be defined using only a UUID or a combination of UUID andMajor. On Figure 4.1 the Region is defined using only a UUID (UUID is 1). The Majorand Minor in curly brackets will only be detected, using Ranging.

The following subchapters will apply the explained setting on Figure 4.1 in order tovisualize the architectural design. They’ll further show the progress of developing anoptimized solution. The prototype used has been developed explicitly for this thesis.

4.2.1 Prototype

The developed prototype uses the standard iOS programming language Objective-C [54].It is designed to work on smart phones operating at least iOS 9.0 operating system. It isdeveloped, using a ViewController class providing all relevant delegate function requiredby the CoreLocation [9] framework. The delegate functions will be triggered if the smartphone enters or exits a Region, that has been defined in the source code. Regions aredefined using a CLBeaconRegion object provided by the CoreLocation framework. SeeListing 4.1 where the UUID and Major are allocated to the respective variables on lineone and three. In this example the Region consists of an UUID and a Major value.Lines five to eight illustrate the instantiation of the CLBeaconRegion object where theUUID and the Major are used. On line ten a function of the _locationManager iscalled in order to start Monitoring for the subsequent defined Region.

Listing 4.1: Source: Define a Beacon Region and start Monitoring1 NSStr ing ∗ uu id = @"2F234454−CF6D−4A0f−ADf2−F4911BA9FFA6" ;2 NSStr ing ∗ i d e n t i f i e r = @" Region i d e n t i f i e r " ;3 NSIntege r major = 1 ;4

5 CLBeaconRegion ∗ _beaconRegion = [ [ CLBeaconRegion a l l o c ]6 i n i tWi thProx im i tyUUID : [ [ NSUUID a l l o c ] i n i tWi thUUIDSt r i ng : uu id ]7 major : major8 i d e n t i f i e r : i d e n t i f i e r ] ;


9

10 [ _ locat ionManager s t a r t M o n i t o r i n g F o r R e g i o n : _beaconRegion ] ;

In order to use the prototype to collect proper data, which can be used to improve theiterative process of finding the optimized architectural design, the prototype requiresvarious functionalities as well as a server with a persistent database to store collecteddata for evaluation.

Figure 4.2: iOS prototype screen

Client-device: iOS App

The prototype is developed for the end-users smart phone. In order to provide usefulinformation for testing the Beacon settings, a few additional integrations beside the Bea-con detection are required. This consists of the support of native Push Notifications (i.e.end-users’ notifications, that are triggered on the smart phone). Those notifications needto be displayed on the smart phone every time the end-user enters or exits a proximityregion in Background- or Foreground-mode.Further, the prototype is required to provide an automatically updating Beacon detectionlog, displaying the Beacons currently in proximity and the received signal strength of theBeacon in RSSI. Figure 4.2 shows the prototype with the detection log. The list updatesautomatically every second. A line consists of the exact date and time, the Major, Minorand the RSSI value. The log provides real time information of Beacons within the smartphones proximity. This supports the process of evaluation, where the optimal position ofa Beacon is, in order to achieve a reliable detection.Further the prototype needs a technical interface to a persistent server for the purpose


of storing the log-data, while receiving proximity data in Background-mode. Therefor aserver has been setup and a HTTP connection configured, using to send the log-data.

Listing 4.2 shows an outline of the prototype source code. It’s the relevant code requiredfor the detection of Beacons. However, user authorization, notification and remote HTTPcalls as well as GUI functionalities are omitted to sustain clarity. The first function withthe name viewDidLoad is already explained in Listing 4.1 but for the _locationManager,which is a type of CLLocationManager, no explanation has been made. So it is used todefine the delegate class on line four. Later on it will initiate the Monitoring by triggeringthe startMonitoringForRegion function passing the beaconRegion as parameter.

Listing 4.2: Objective-C code for Beacon detection1 − ( vo i d ) v iewDidLoad2 {3 _locat ionManager = [ [ CLLocat ionManager a l l o c ] i n i t ] ;4 _locat ionManager . d e l e g a t e = s e l f ;5

6 CLBeaconRegion beaconReg ion = [ [ CLBeaconRegion a l l o c ]7 i n i tWi thProx im i tyUUID : [ [ NSUUID a l l o c ] i n i tWi thUUIDSt r i ng :@" Region 1" ]8 i d e n t i f i e r :@" f7826da6 −4fa2 −4e98 −8024−bc5b71e0893e " ] ;9

10 [ _ locat ionManager s t a r t M o n i t o r i n g F o r R e g i o n : beaconRegion ] ;11 }12

13 −( vo i d ) l o ca t i onManage r : ( CLLocat ionManager ∗) manager14 didRangeBeacons : ( NSArray ∗) beacons15 i nReg i on : ( CLBeaconRegion ∗) r e g i o n16 {17 // Get ’ s c a l l e d i f Ranging d e t e c t e d beacons18 }19

20 − ( vo i d ) l o ca t i onManage r : ( CLLocat ionManager ∗) manager21 d idEn t e rReg i on : ( CLRegion ∗) r e g i o n22 {23 // Get ’ s c a l l e d i f smart phone e n t e r r e g i o n24

25 [ _ locat ionManager s t a r tRang i ngBeacon s I nReg i on : ( CLBeaconRegion ∗) r e g i o n ] ;26 }27

28 − ( vo i d ) l o ca t i onManage r : ( CLLocat ionManager ∗) manager29 d i d E x i t R e g i o n : ( CLRegion ∗) r e g i o n30 {31 // Get ’ s c a l l e d i f smart phone e x i t r e g i o n32

33 [ _ locat ionManager s topRang ingBeacons InReg ion : ( CLBeaconRegion ∗) r e g i o n ] ;34 }

As soon as the end-user has physically entered the proximity area of a Beacon, and theBeacon emits the Region which is defined in the _locationManager, a didEnterRegion


call will be triggered on line 20 ff.. The function calls startRangingBeaconsInRegion inorder to initiate the Ranging process. If the App is in Background-mode and there is nobackground task configured, Ranging leasts for about ten Seconds before it stops. In thiscode outline, no background task is defined.During Ranging, all Beacons within the proximity of the smart phone will be detectedand passed as an NSArray on the function didRangeBeacons on line 13. Beside thedetected Beacons, also the detected Region is passed.If the end-user leaves the proximity area of the Beacon and therefore also the Region, thedidExitRegion function is triggered.

Server-side database

On the server-side a PHP framework called Lumen [56] is used, to bootstrap the entireapplication providing basic processing logic of the requests. A MySQL database and asmall API to fetch the HTTP calls from the prototype. The PHP based application runson a cloud-based Ubuntu server with an installed LEMP-stack [52]. The source code ofthe application is provided in appendix A.

Real world setting

To properly test the defined use cases an essential setting is required. In order to simulatea real world scenario with people passing by, and proper place needs to be selected.Therefor the offices of the collaborating startup in Zurich were selected to conduct thetesting and field study. Their office is based on a street with obstacles and can be usedto simulated the use cases.

Limited region monitoring

The maximum global number of Regions that can be monitored in Background-mode on anApple iOS smart phone are limited. There is no official statement from Apple concerningthe maximum amount of Regions that can be monitored concurrently in the background.According to investigations from Radius Network [61], there is a priority and a besteffort group defined. For the Regions defined in the Priority Group, didEnterRegionwill be triggered almost immediately after the end-user entered the Region. Regionsthat are defined in the Best effort Group can lead to a long delay or even never trigger adidEnterRegion. Though the end-user is clearly within the Beacon proximity. Accordingto tests by [61], the Priority Group can scan up to 30 regions at a time. So if two installedapplications on an Apple iOS smart phone respectively register 20 Regions, some Regionswill be added into the Best effort Group and therefore their didEnterRegion will not betriggered immediate.


4.2.2 Iterative development

The field study consists of two slightly different real world use cases. They are designedto simulate the Beacon detection at a small city shop and at an Ad-poster venue. Theyare described in detail in Chapter 4.1.

The following section describes the iterative development of the architectural design forboth use cases. Beforehand, requirements for each use case are defined, which need tobe fulfilled by the final architectural design. The design is developed, applying a two- orthree-steps iterative approach.

UC A: end-user enters venue

This use case is described in detail in Chapter 4.1. To distinguish if a user walks-by orenters the venue, it requires to detect the end-users movement. If this will be achievedusing a triangulation mechanism or a pattern based approach using the signal strength(RSSI) to determine the distance of the Beacon and the smart phone, needs to be obtained.As stated in Chapter 2.4, background activities like Ranging require a lot of battery power.Therefore energy savings approaches need to be taken into account. In order to providescalability in setup and expansion, a simple setup of the Beacon hardware is assumed anda scalable design required. The requirements thereby arising are the following.

Simple setup in order to setup a new venue easily and fast without a lot of configurationwork. For example simple Beacon configuration in terms of signal strength anddefining optimal location to place it.

Minimize performance impact requires to develop an energy optimized design inorder to preserve energy, especially for running tasks in Background-mode.

Scalable design provides an architectural design ensuring subsequent expansion with-out major limitations. Like for example a design that cannot define more than 20different venues.

Optimize detection reliability distinguishes walk-in’s and walk-by’s of venues. Ad-ministrators are eager to detect the rate of end-users entering the venue if extrastimulus has been installed in order to attract them to enter the venue.


First iteration

Figure 4.3: Design development: First iteration

In an initial setting, a basic architectural design is presented, which covers the simplicityrequirement. The Beacon positions are defined by the architectural design and all threeBeacons have the same signal strength, which requires only one Beacon to be configuredand validated. The following two can be duplicated based on the first one in therms ofconfiguration.In Figure 4.3 two venues are pictured in a top-down view. A venue for example, canbe a shop in the city selling products. Venues are marked by a solid line indicating theedge. The line is interrupted by a rectangle showing the door. Inside of the venue, thereare three dotted circles. Every circle has a smaller, gray circle inside. The inner circlesymbolizes the location of the Beacon. In this setting, three Beacons are present withinone venue. The dotted bigger circle indicates roughly the border of the Beacon signal.The numbers below the grey circle represent the Beacon broadcasting information. OnFigure 4.3 the Region is defined using only the UUID, 1 at Venue 1 and 2 at Venue2. Thus the Major and Minor values are not used to define the Region and will notbe detected during Monitoring and that’s why they are written within curly brackets.However, with Ranging they will be detected. If the end-user entered the venue, thenearest Beacon to the end-suer can be determined, by detecting the Minor value. Thusthe approximate location of the end-user can be estimated as well.

Unfortunately providing scalability with this design is not possible. Since a region needsto be defined for every venue, the maximum amount of venues, that can be defined is 20.Which makes the entire approach not scalable. Furthermore passing end-users, who do


not enter the venue will not be detected. In order to detect end-users passing the venue,a Beacon needs to be installed outside or next to the door of the venue so that they canbe detected. Leading to the second iteration, which will provide solutions to some of theidentified problems determined in the First iteration.

Second iteration

A problem addressed at the First iteration that end-users passing the venue are notdetected will be taken into account.

Figure 4.4: Design development: Second iteration

In Figure 4.4 an approach is provided with an installed Beacon outside of the venue.Note, that this Beacon can be exposed to environmental impacts like extreme weatherconditions, which can result Beacons damaged caused by water. Therefor it’s preferredto install the Beacon close by the main entry door in a dry place in order to reduce theexposure of environmental impacts. The three Beacons placed inside of the venue areused to detect the end-users movement indoors. All four Beacons of Venue 1 define oneRegion with the UUID = 1. So for every venue a proper region needs to be defined.

The Beacon positioned outside of the venue detects not only entering, but also passingpedestrians. So this setting can distinguish between walk-by’s and walk-in’s. In order toachieve a sufficient detection reliability, every Beacon placed outside defines a Region for


each venue. On Figure 4.4 Venue 1 defines the Region 1 and Venue 2 defines the Region2. Hence only a maximum of 20 venues can be defined applying this design which doesnot fulfill the Scalable design requirement. However, the design does cover the Optimizedetection reliability and the Simple Setup requirement.

Final iteration

Based on the findings of the First iteration and Second iteration, the Final iteration isdeveloped. In order to provide the differentiation of walk-by’s and walk-in’s, the outsideplaced Beacon will be added again. To provide a Scalable design, this setting in Figure 4.5has a slightly different approach comparing the Second iteration, in terms of the definitionof Regions. Every venue (E.g., 1, 2, 3, ...) defines two distinct, but beyond all identicalregions. For example Venue 1 defines two Regions: 1 and 2. Region 1 is defined bythe outside Beacon. Region 2 is defined using the three inside Beacons. This specificapproach provides scalability for the design. Because the design requires to define onlytwo distinct Regions for all venues defined. To identify the venue, the Major value isrequired to be detected by the smart phone during Ranging. This happens as soon asMonitoring identified Region 1 or 2 and starts with Ranging. Thus, approximately up to65’000 venues can be defined which makes the design relatively scalable.

Figure 4.5: Design development: Final iteration

The design setup is simple as mentioned in the iterations before. Walk-by’s and walk-


in’s are being detected and can be distinguished. So the requirement Simple setup andOptiomize detection reliability is provided.

In order to Minimize performance impact the design will use a dynamic adaption of theranging time in the Background-mode based on the detected end-users distance to theBeacon. The distance will be detected using the Receive Signal Strength Indicator (RSSI).For example, if the RSSI values increase (E.g., the distance between Beacon and smartphone increases) and do not fall below a certain threshold after a defined amount of time,the remaining Ranging time in Background-mode will be reduced or even set to zero.If the RSSI values decrease (E.g., distance between Beacon and smart phone decrease),the Ranging time in Background-mode will be increased. This approach ensures to fetchlocation based end-user data only if it’s necessary and the high energy consumption ofexecuted tasks in Background-mode can be minimized.

UC B: end-user pass venue

This use cases requires the identical requirements like the first use case UC A. Except forthe Optimize detection reliability use case.

Optimize detection reliability in order to determine, if an end-user is passing theAd from left to right or right to left and if it’s possible to identify, if the end-user islooking at the Ad or just passing.

Based on the findings regarding UC A, most of them can be adopted on UC B in orderto provide a Scalable design.

Figure 4.6 visualizes the Ad-poster in a top-down view as a rectangular box. It has aBeacon installed in the center on the top of the box. The Beacon signal edge is visualizedby the dotted line. The red and blue line illustrate a possible user movement passing theAd-poster.

First iteration

The Region is defined by the UUID. Major and Minor are used to detect the venue. Justas designed in UC A, this approach allows to define up to 65’000 venues by using onlyone region. This ensures a Scalable design.The setup, configuration and installation of the Beacon is simple and does not requireany additional configuration work. So this design does also fulfill a Simple setup.


Figure 4.6: Architecture design: First iteration

Concerning the Optimize detection reliability, there has no possibility been identified inorder to determine if the end-user moves from left to right or right to left. Thus the designneeds further improvement, which will be discussed in the next iteration.

Final iteration

According to the insights of the first iteration, the heading direction of the end-user needsto be detected. In order to make this possible, a second Beacon has been added to theAd-poster.

Figure 4.7: Architecture design: Final iteration


Two Beacons, one on each edge of the Ad-poster, are positioned like shown in Figure 4.7.

Figure 4.7 is defined by one Region, Region 1. The Beacon proximity areas are overlap-ping, but defining one identical Region. The Major value is used to identify the venue,the Minor value is used to identify the Beacon. Though Major and Minor values are onlydetected with Ranging. Region 1 is detected with Monitoring. The Minor value is used toidentify the Beacon, denoting if the left or right Beacon is detected. In order to determinethe direction, it’s crucial to differentiate between the right and left Beacon.

This design approach ensures, that a part of the Optimize detection reliability is fulfilled.Identifying the direction of the end-user is possible. However, there was no feasible ap-proach in order to identify if an end-user does look at the Ad-poster or not. It is, howeverpossible to use the CoreLocation framework of Apple iOS in order to get the end-usersheading [14]. Though determining the heading is mostly only achievable if the smartphone points in the specific direction - which is mostly not the case if the smart phone iswithin the end-users’ pocket.

To Minimize performance impact the same approach will be applied as described in UCA, using the RSSI values to dynamically adapt the Ranging times in Background-mode.

Optimize signal direction

During the use case investigation of the Ad-poster it has been discovered, that end-userspassing behind the Ad will also be detected. But will not have seen the Ad. Thereforan approach of a directional signal propagation has been developed. In order to directthe Beacon signal in a specific direction, aluminium foil was placed around the Beacon toshield the signal. Hence the Beacon was wrapped into aluminium foil and a small holewas left open.

Figure 4.8: Funnel shielding Beacon signal

Figure 4.8 shows the Beacon wrapped in aluminium foil with funnel pointing up. Thismeans, the front of the Beacon is pointing up. When approaching the funnel from the


back side of the funnel and using a signal strength of -30dBm the Beacon is detected ina distance of about 25 centimeters. However, swiping the funnel to point in the otherdirection leads to a signal detection of approximately 30 centimeters away. Despite with-out any shielding the signal will be detected in 5 meters distance. Adding the aluminiumfoil around the Beacon leads to a high decrease in the overall signal strength. Also if theend-user is standing in front and the funnel pointing at him. Moreover, the difference insignal strength between the front and the back of the funnel results in 15

4.2.3 Design validation

In order to validation the architectural design in a real world setting, a field study isconducted. The prototype explained in Chapter 4.2.1 is used to validate the architecturaldesign developed in Chapter 4.2.2.

Figure 4.9: Venue used: Shop and Ad-poster

The field study is conducted, using two different approaches of venues. Related to thearchitectural design decision in Chapter 4.2.2 one field study is addressed where an end-user will enter a venue. And a second is addressed where an end-user will pass a venue.Those described approaches are referred with Enter venue and Pass venue subsequent.The aim of this field study is to validate the detection reliability of the two architecturaldesigns developed for the use cases. In order to distinguish the end-users direction and ifthere arises a pattern of the signal strength, detected by the smart phone prototype.

Field study setting

The field study testing of entering the venue is conducted at a place in the city of Zurich.The venue consists of a shop-window and a street in front. It provides a similar settingin contrast to existing shops, which might be used to apply the setting. See Figure 4.9showing a picture of the venue used. Both use cases have been conducted, using this


location. For the Enter venue use case, a Beacon was placed in front of the building (atthe staircase next to the door) and one inside. A pedestrian crossing the venue within thedistance of the person who shot the picture, he would have been detected by the outsideBeacon. The inside Beacon did only detect a person who entered the venue. For the Passvenue use case, two Beacons were placed on every corner of the house on left and rightside.The field study was conducted outside by human holding a smart phone in hands withthe installed prototype App. The smart phone was in hibernation mode approaching thevenue with the installed Beacons. The Beacon setting varies between each venue. Allthe data collected, while the smart phone was in hibernation mode, was sent to a remoteserver using HTTP calls. As hardware an iPhone 6S with iOS 9.0 installed, fully chargedand not connected to power was used. Data is exchanged using 3G with approximately70% signal quality on the smart phone.

Enter venue

The field study setting consists of two Beacons. One was positioned in front of the venuenext to the entry door. According to the architectural design developed for UC A. TheBeacon next to the door had a relative high signal strength (RSSI) of -4 dBm. Theother Beacon positioned inside of the venue had a reduced signal strength of -20 dBm.The distance between the Beacons is approximately 3 meters. The difference in signalstrength has been determined manually in order to distinguish between walk-by’s andwalk-in’s. Providing a higher signal strength will improve the detection radius of theBeacon installed outside whereas the Beacon installed inside of the venue detects onlysmart phones which are inside. All introduced diagrams are provided in higher resolutionin the appendix B.

Figure 4.10: Low signal strength: Signal strength detected by prototype

The data for all diagrams created in this thesis, is detected by the prototype developed inthis thesis. The prototype logs the signal strength collected from Beacons every Second.This data has been stored on the server database and has been formatted, in order to be


presented within a diagram. The raw data collected on the server was transferred intoan MS Excel Sheet (Excel files are provided on the CD, see appendix A). Out of theformatted data in Excel, graphs have been created in order to show the effects visualized.Erroneous RSSI detections characterized by a value of 0, are removed and interpolationapplied in order to preserve a straight line.

Figure 4.10 visualizes four approaches of an end-user entering a venue. However, only thecurve of the relative strong Beacon (-4 dBm) is provided. The curve of the Beacon insideis neglected in order to simplify the graphic. The y-axis represents the detected signalstrength (RSSI) received by the smart phone emitted by the Beacon. A high RSSI implies,that the detected signal is rather weak and therefore the physical distance between smartphone and Beacon is high. The x-axis represents the passing time in Seconds. During thefield study, four detection approaches have been conducted, named Detection 1 - 4. Everydetection is visualized by a curve. The volatility of the curves is high in Figure 4.10. Thisleads to the implication, using RSSI for with this signal strength is not reliable. SECTOR1 is the process, where the end-user enters the venue. In SECTOR 1 a decrease of theRSSI value should be clearly recognisable. SECTOR 2 shows the time, where the end-useris exiting the venue. On the diagram, there is no pattern clearly identifiable. Due to thefact, that the end-user is approaching the venue (Beacon) and leaving it again, the curvesin Figure 4.10 should form sort of a U-curve. Because the distance between end-user andBeacon is initially relatively high and reduces with the time until the turning point isreached and the end-user is leaving the venue (Beacon) again. However, a U-typed formcannot be observed in Figure 4.10 which leads to the implication, that it’s not possible toapply RSSI values in this setting in order to track the users movement reliable.

The graph in Figure 4.11 occurs from an identical approach like Figure 4.10, except for thesignal strength of the Beacons involved. The overall duration of the detection increases,because the signal radius is larger and therefore the signal border is farer away than withthe low signal, which results in more detection data. The result is Figure 4.11. The onlydifference between the two approaches consist in the signal strength of the Beacons. TheBeacon installed outside has a signal strength of -0 dBm which leads to a higher andimproved Beacon signal quality. In Figure 4.11 the U-form of the curve can be identified.

Figure 4.11: High signal strength: Signal strength detected by prototype


Starting with a high, by the prototype detected RSSI value around -90 dBm, whichindicates that the end-user is far from the Beacon. With the end-user approaching theBeacon, the RSSI value decreases until it levels with an RSSI value around 75 to 80, wherethe end-user arrives at the venue and enters it, which happens in SECTOR 1. After about30 Seconds the end-user leaves the venue (SECTOR 2 ), which is demonstrated with anoverall increase of all five curves. The data is collected, conducting five venue approaches.RSSI values of every approach are elaborated and visualized in the graph in Figure 4.11.

Figure 4.12: High signal strength: Inside & outside Beacon detection

During the field study the distinction between inside and outside detection of the twoinstalled Beacons works as expected. Figure 4.12 shows two curves which consist of theaverage value of all detections (1 - 4). The green line indicates the average RSSI valuesof the inside Beacon detection, whereas the blue line indicates the RSSI values of theoutside Beacon detection with the stronger relative signal. On the graphic there exist twoSECTORS ; SECTOR 1 indicating the end-user entering the venue, where the blue line’sRSSI value drops to an RSSI between 70 and 75. The RSSI remains at this signal strengthuntil SECTOR 2 is reached, and the blue as well as the green line are increasing, meaningthe detected signal strength by the prototype decreases, hence the end-user is leaving thevenue again. In fact, during testing, the end-user entered respectively exited the venuewithin both SECTORS. However, due to the weak signal of the inside Beacon (greenline), the volatility is higher in contrast to the outside Beacon (blue line). Moreover, theeffective detection of the inside Beacon on venue entry is delayed of about ten Seconds.Both insights lead to the implication, that a low signal strength tends to less reliabilitythan a higher signal strength in terms of distance estimation.The delay in detection of the inside Beacon can be taken as advantage to improve thereliability of the detection of walk-in’s and walk-by’s. According to Figure 4.12 detectingan inside Beacon will not occur as long as the signal strength of the outer Beacon dropsbelow an RSSI value of about 80. Moreover, the end-user needs to remain there for morethan 10 - 20 Seconds in order to detect the inner Beacon. Hence walk-in’s and walk-by’scan be distinguished reliable.


Pass venue

The field study setting of passing a venue consists of two Beacons, which are approximately5 meters away from each other. In this field study the Ad-posters length is about 5 meters.In parallel, a road is passing, where people can walk along. According to the track onFigure 4.7 both Beacons can be passed parallel.It needs to be tested, if people passing by the Beacon are being detected reliable and iftheir direction can be identified. Further an approach is setup in order to investigate ifit’s possible to determine if end-users do stand in front of the Ad-poster or not.

Based on findings in the first field study it has been identified, that high RSSI valuesare required in order to collect reliable data to make confident decisions of the distancebetween the end-user and the Beacon. Figure 4.13 presents data modeled by a graphwhere the signal strength of both Beacons is set to -0 dBm.The graph consists of two axes. The x-axis is the time passed. The y-axis is the detectedsignal strength (RSSI) within the specific time. There are two lines. A blue and a brownone. The blue line reflects the signal strength of Beacon 1 and the brown one the signalstrength of the Beacon 2. In this scenario Beacon 1 has been passed before Beacon 2.

Figure 4.13: Ad-poster: Direction detection reliable

Figure 4.13 visualizes, depending on the RSSI which Beacon the end-user has passed firstand which after. The brown curve (Beacon 2) starts at a very high RSSI value, indicatingthat the end-user is farer away from Beacon 2 than Beacon 1 (blue curve). This implies,that Beacon 1 is nearer to the end-user than Beacon 2, thus Beacon 1 will be passedbefore Beacon 2.

On the right side of Figure 4.13 the blue line (Beacon 1) stops at a much higher RSSIvalue than the brown line (Beacon 2). This implies, that Beacon 2 is still in sight, whileBeacon 1 already disappeared and is not being detected anymore.

In the center of Figure 4.13 the blue and the brown line cross each other, which indicatesthat at this point, the end-user’s distance to either of the two Beacons is equal. Therefore


the implication that he’s in the center and thus standing in front of the Ad-poster can bemade.The data collected in Figure 4.13 is very accurate. Unfortunately this is not always thecase and among five detections, the curves are not always that clear. For example Figure4.14 was also a result of the identical setting but with a different outcome in terms of RSSIvalues. Important to notice is, that this detection is vice-versa. Meaning the end-userdoes not pass Beacon 1 first and than Beacon 2 as before, but passes Beacon 2 (brownline) first and than Beacon 1 (blue line). So on the left side of the Figure, both lines arealmost overlapping, pointing out, that the end-user’s distance from Beacon 1 and 2 mustbe equal. Which is not the case during the field study.

Figure 4.14: Ad-poster: Direction detection not reliable

Based on all five detections, the outcome that it’s not possible to rely entirely on theRSSI values and compare them to detect whether the end-user passes from left to rightor from right to left, is disappointing at first. But the fact, that after the end-user haspassed both Beacons one curve starts to stop before the other implies, that it’s stillpossible to distinguish which Beacon has been sighted first. The RSSI values of theBeacon passed last, have been detected for longer time than the values of the first Beaconpassed. Therefore it can be reliable determined from which side an end-user is passingthe Ad-poster.

Results of field study

The field study shows, that the reliability of the RSSI values correlates with the signalstrength. A high signal strength leads to an improved detection quality. Especiallycomparing Figure 4.10 and 4.11 highlights the enhanced signal. Furthermore it has beenproven, that the end-users heading direction can be detected, if he passes an Ad-poster.

The architectural design has been validated in a real world setting and has been beapplied on a use case. However, in order to setup the venue with Beacons, an accurateconfiguration of the Beacons in terms of signal strength is required E.g., defining thesignal strength of the Beacon.

4.3. PROTOTYPE IMPROVEMENTS 45

4.3 Prototype improvements

Based on the findings in the field study, its possible to apply a pattern to increase de-tection reliability in walk-by’s, E.g., having a low signal strength at the beginning andend of a detection can point out a detection. The prototype is extended by the followingfunctionalities:

End-user passing a venue if the average RSSI values of the interval 1 - 2 and 8 -9 of the collected RSSI values have a lower average value than the average of thevalues collected within the interval of 4 - 6. These intervals are selected based onthe findings in Figure 4.11. there is an timely limit of 300 Seconds defined, withinthe complete passing from first Beacon sight till last sight, needs to be detected.The interval boundaries are go from 1 to 10. So 1 would be the first sighted Beaconsignals and 10 is the last one. If within that time interval the scenario is detected,it’s sent to the server and the Background-mode is stopped.

End-user entering is enhanced, if the outer and inner Beacon is detected afterwards.Which implies that the end-user has to be inside of the venue. If the inner Beaconis detected without an preceding detection of the outer Beacon, the detection is notsufficient. A sufficient detection is sent to the server and the Background-mode isstopped.

End-user passing an Ad-poster is detected if two Beacons, defined as Ad-poster typewithin 300 Seconds time are detected. Subsequent the detection will be sent to theserver and the Background-mode will be stopped.

4.4 Comparison against existing solution

This thesis was conducted in collaboration with a Swiss start-up which has already de-signed and implemented a solution to detect Beacons. In order to grow they’re business,they need to improve their detection reliability to distinguish between different types ofwalk-by’s. The existing solution by the startup is used to compare it against the developedprototype in this thesis to detect conducted improvements or benefit from the existingsolution in terms of experience running in a production environment. Subsequent, theexisting solution will be referred to as solution A and the developed prototype in thisthesis solution B.

For an optimal result of the comparison, the code of solution A is analyzed in order toidentify the implemented functionalities used and compare them against solution B. Dueto the fact, that solution A has various other active functionalities beside the Beacondetection, comparing them App-to-App in a field study would result in biased results.Because the other functionalities of solution A do consume battery power as well asscan for Beacons. Therefor it was decided to compare the relevant source code of bothapplications, focusing on the Beacon detection source code of solution A.


Solution A

Listing 4.3 is an excerpt of solution A’s source code for Beacon detection. This codefragment shows the action when Ranging detects one or more Beacon(s). Monitoringhas already detected a Region beforehand, hence the smart phone has started to Rangefor Beacons. When one or more Beacons are being detected within the smart phonesproximity the delegate function didRangeBeacons is triggered, passing an NSArrayof Beacons detected and the detected Region of the type CLBeaconRegion.

On line five in Listing 4.3 solution A checks, if Beacons are available. If the condi-tion is true, the applicationState will be determined. Which defines if the App is inForeground-mode, E.g., the end-user is actively interrogating with it. If this is the case,all detected Beacons will be added to a stored list internally on the App. The list isdefined in the class DRELocationManager. The DRELocationManager defines theCLBeaconRegion that are scanned for and manages the Monitoring and Ranging stateof the App. Further it hosts a function called beaconProcessing which will be triggeredon every startup of the App, and once a didExitRegion event is triggered, which statesthat the end-user has left the Region. This function sends all stored Beacons on the list,to a server.

Listing 4.3: Solution A Beacon detection: Part A1 − ( vo i d ) l o ca t i onManage r : ( CLLocat ionManager ∗) manager2 didRangeBeacons : ( NSArray ∗) beacons3 i nReg i on : ( CLBeaconRegion ∗) r e g i o n4 {5 i f ( beacons . count > 0) {6

7 ( . . . )8

9 i f ( [ [ U I A p p l i c a t i o n s h a r e d A p p l i c a t i o n ] a p p l i c a t i o n S t a t e ] ==10 U I A p p l i c a t i o n S t a t e A c t i v e ) {11 /∗12 While the App i s a c t i v e − meaning the u s e r has the App opened13 on the smart phone , no Beacon d e t e c t i o n n o t i f i c a t i o n s w i l l be14 s en t to the s e r v e r .15 ∗/16 [ [ DRELocationManager s h a r e d I n s t a n c e ] addBeacons : beacons ] ;17 }18 }19 }

This approach, of not sending any Beacon detection data to the server, while the App isin Foreground-mode, is interesting. Implying that the developer of Solution A wanted tomaximize the user experience by exchanging only required data for the end-suer to andfrom the server.

Listing 4.4 defines what happens if the App is not in Foreground-mode and Beacons arebeing detected. The if -condition distinguishes between three sets of disjunctions. If one

4.4. COMPARISON AGAINST EXISTING SOLUTION 47

of the set is true, the whole condition is true. The three sets are explained in detail andcan be tracked in Listing 4.4. Please note, that identifier definitions have been neglected,in order to increase clarity.

lastUpdateIdentifier is equal to the current identifier, the Beacon detection will notbe sent to the server. This check is required, in order to dispose identical Regiondetections. For example if an end-user stays within a Beacon proximity for someHours, it’s possible that detections will be executed twice based on interferences.

lastUpdateIdentifier is not defined, E.g., it’s the first detection after the App has beeninstalled on the end-users smart phone. The detection will be sent to the server.

lastUpdateDate is smaller than the current timestamp minus 60 Seconds in order toprevent a high amount of calls to the server and to preserve the end-users privacy.

Listing 4.4: Solution A Beacon detection: Part B1 e l s e {2 NSStr ing ∗ l a s t I d e n t i f i e r = /∗ ( de f . o f l a s t I d e n t i f i e r ) ∗/3 ( . . . )4 NSStr ing ∗ l a s t U p d a t e I d e n t i f i e r = /∗ ( de f . o f l a s t U p d a t e I d e n t i f i e r ) ∗/5 NSDate ∗ l a s tUpdateDate = /∗ ( de f . o f l a s tUpdateDate ) ∗/6 i f ( ! l a s t U p d a t e I d e n t i f i e r | |7 ! [ l a s t U p d a t e I d e n t i f i e r i s E q u a l T o S t r i n g : l a s t I d e n t i f i e r ] | |8 l a s tUpdateDate && [ l a s tUpdateDate t im e I n t e r v a l S i n c e Now ]9 ∗ −1 > 60)) {

10 /∗11 No s e r v e r c a l l s i f12 − i d e n t i f i e r i s same as l a s t t ime13 − l a s t U p d a t e I d e n t i f i e r i s not s e t ( f i r s t t ime )14 − t ime i n t e r v a l s i n c e l a s t update i s s m a l l e r than 60 sec15 ∗/16 ( . . . )17 [ DREServerConnect ion r e g i s t e r B e a c o n s O n S e r v e r : beacons back l og : n i l ] ;18 }19 }

Solution B

The developed prototype in this thesis uses an adaptive background task. Backgroundtasks execute tasks while the App is not in Foreground-mode. Due to a posting by Es-timote, using energy consumptive background tasks are heavily restricted by Apple [35].Estimote suggests to reduce the need of running background tasks to a minimum. Espe-cially the Ranging task would be a task with high energy consumption. Hence solution Breduces the background-execution-time if the end-user moves away from the Region auto-matically in order to optimize the energy consumption. Ranging in the background-taskis required so that the movement of the end-user get detected.


Prior to creating a new background task as shown in Listing 4.5, it needs to be checkedif such a task is not already running. Solution B defines a variable _backgroundTaskof the type UIBackgroundTaskIdentifier. This variable is used to create, check status andterminate a background task. Therefor an initial check is conducted on Listing 4.5 line 1if it’s save or not to create a new one.

In order to start a background task the iOS specific Grand Central Dispatch (GDC)queues [15] are used. They can be used to execute defined code blocks asynchronouslyor synchronously. But it’s required to define its priority within the global App executionqueue. There exist four different global App execution queue priorities [64]:

• DISPATCH_QUEUE_PRIORITY_HIGH

• DISPATCH_QUEUE_PRIORITY_DEFAULT

• DISPATCH_QUEUE_PRIORITY_LOW

• DISPATCH_QUEUE_PRIORITY_BACKGROUND

In order to run our background task, the decision to useDISPATCH_QUEUE_PRIORITY_HIGH orDISPATCH_QUEUE_PRIORITY_DEFAULT has to be made. Remembering, that itis a global running queue, theDISPATCH_QUEUE_PRIORITY_DEFAULT was selected, because the backgroundtask in the defined use cases do not reduce the end-users App experience if they don’twork properly. Hence the highest priority is not required.

The while-loop will be aborted, if the condition on Listing 4.5, line 15 and 16 is true. So-lution B allows to dynamically adjust the background running time. So it will be set using_backgroundRunningTimeInSeconds. If the _backgroundRunningTimeInSec-ondsIncrementor reaches the available _backgroundRunningTimeInSeconds thebackground task will be aborted which is checked by the if-condition.

If the condition on Listing 4.5, line 29 is true means that the remaining background timeis still smaller than the allowed background task running time. So the background taskcan keep on running. The remainingBGTime decreases over time, the background taskis running. If the background task runs longer than remainingBGTime allows, it willbe terminated by the operating system. So this condition ensures, that there will be noforced termination of the background task by the operating system.

In order to minimize the amount of server calls, the prototype will only send three differenttypes of calls to the server if one of the three complete detections occur:

Venue walk-in detection occurs, if the outer and inner Beacons are detected withina defined timeframe. The timeframe can be set for each venue independently, sincevenues can differ in size and so can the passing time between outer and inner de-tection. A server call consists out of a user identification, venue identification, type(in this case walk-in) and timestamp.


Venue walk-by detection occurs, if within the defined timeframe the inside Beacon isnot detected. A server call consists out of a user identification, venue identification,type (in this case walk-by) and timestamp.

Ad walk-by detection occurs, if Ad Beacons are detected. In order obtain a complete adetection, both of the corresponding Ad-poster Beacons need to be detected. Basedon the RSSI values received, the direction of the end-user can be determined. Aserver call consists out of a user identification, venue identification, direction andtimestamp.

In order to provide scalability, the prototype applies the developed architectural design,which means that the prototype is Monitoring for a specific Region and evaluates thevenue based on the detection of the Major value as described in Chapter 4.2.2.

Listing 4.5: Solution B: Background task1 i f ( _backgroundTask != UIBackg roundTask Inva l i d ) {2 // Task i s a l r e a d y d e f i n e d ; don ’ t r e s t a r t i t .3 r e t u r n ;4 }5

6 d i spa t ch_async (7 d i spa tch_get_g loba l_queue (DISPATCH_QUEUE_PRIORITY_DEFAULT, 0) , ^{8 Boolean backgroundTask I sRunn ing = t r u e ;9 w h i l e ( backgroundTask I sRunn ing ) {

10 ( . . . )11

12 NSIntege r remainingBGTime =13 [ U I A p p l i c a t i o n s h a r e d A p p l i c a t i o n ] . backgroundTimeRemaining ;14

15 i f ( _backgroundRunn ingTimeInSeconds Incrementor >16 _backgroundRunningTimeInSeconds ) {17 /∗18 _backgroundRunn ingTimeInSeconds Incrementor deno te s the19 pas sed time , the background ta s k i s a l r e a d y runn ing ; i f i t ’ s20 g r e a t e r than the backgroundTaskRunning t ime − s top i t .21 ∗/22 _backgroundRunn ingTimeInSeconds Incrementor = 0 ;23 [ [ U I A p p l i c a t i o n s h a r e d A p p l i c a t i o n ]24 endBackgroundTask : _backgroundTask ] ;25 backgroundTask I sRunn ing = f a l s e ;26 _backgroundTask = UIBackg roundTask Inva l i d ;27 }28

29 i f ( remainingBGTime >= _backgroundRunningTimeInSeconds ) {30 /∗31 Make s u r e tha t the r ema in i ng background t ime i s g r e a t e r than32 the d e f i n e d r ema in i ng dynamic background t ime .33 ∗/34 _backgroundRunn ingTimeInSeconds Incrementor++;


35 } e l s e {36 /∗37 I f the d e f i n e d r ema in i ng dynamic background t ime i s g r e a t e r38 than the r ema in i ng BG a l l owed by iOS , s e t i t to t h i s .39 => Ensu re s to not run i n t o an iOS based BG−t a s k t e r m i n a t i o n .40 ∗/41 _backgroundRunningTimeInSeconds = t ime ;42 }43 }44 } ) ;

Findings of comparison

Solution A provides a sophisticated approach in terms of handling the detections of regionsand Beacons within a region. Moreover it evaluates, if a detection is relevant in order tosend it to the server. As stated in this thesis in Chapter 2.4, background server calls doneed a lot of energy relative to the other tasks running. However, Solution A does notmake use of extending the background task in order to gain enhanced detection results.If a region is being detected, the maximum amount of time Ranging is active, is tenSeconds [11]. Therefor it’s quite impossible, to detect two or more Beacons within oneRanging Period. If an end-user walks by an Ad-poster it might work, depending on thesignal strength of the Beacon and the size of the Ad. But there is no sufficient reliabilitygiven. If the signal strength is very low, it’s possible to detect both Beacons within theten Seconds interval. Although is was discovered, that the reliability of the RSSI valuesincrease with the signal strength of the Beacon. Which leads to a wider proximity areaand thus longer Ranging than ten Seconds is required.The approach of the implemented Beacon detection process, E.g., checking if the detectionhas already occurred within a specific timeframe reduces the amount of data required totransfer between server and smart phone, which reduces the energy consumption. This isa good approach.

Solution B provides an adaptive background task execution. Hence, the time the back-ground task is running can be dynamically changed based on altering environmentalinfluences. This allows to dynamically adapt the background ranging time, E.g., theend-user approaches a beacon and the signal strength detected increases, which impliesthat Ranging should be extended in order to improve the detection reliability by continuewith Ranging. In the other case, if an end-user moves away from the Beacon and thesignal strength becomes weaker, it makes no sense to continue Ranging and waste energy.Moreover, solution B only conducts a server call, if there has been a complete detectionof the end-user at a venue. A venue detection normally consists out of multiple Beacondetections. Depending on the venue, the implemented logic on the prototype decides ifan end-user has been detected or not. This saves energy because less server calls need tobe conducted.

Furthermore solution B provides an approach to improve the detection reliability of Bea-cons. The architectural design developed in this thesis points out that a proper arrange-ment of the Beacons is essential, in order to ensure a reliable detection. Moreover, the


integration of the detection logic onto the App reduces the amount of server calls in con-trast to solution A. Solution B executes a server call if it detects a Beacon Region whereassolution B only executes one if an entire detection has occurred.

Chapter 5

Evaluation

Reliable Beacon detection - the title of this thesis. The aim of this thesis was to provide asolution to improve the Beacon detection. According to our findings and field study, thedetection of a Beacon and venue can be improved by applying an individual approach interms of an architectural Beacon design. The arrangement and configuration of Beaconsis crucial in order to establish a reliable Beacon setting that provides solid results. Thischapter will consolidate the results and insights gained during the thesis. It highlightsmajor insights and drawbacks that have been detected during the field study and thesubsequent validation of it.

5.1 Performance impact

In Chapter 2.4 the energy consumption of the smart phone was investigated. It wasshown, that Monitoring uses relatively less energy in contrast to Ranging on a smartphone. Therefor Ranging should be reduced to a minimum for a solution trying to reducethe performance impact in terms of energy. While the smart phone is in Background-mode and no background task is defined, Ranging will be limited to a maximum of tenSeconds. Unless there is a background task defined so that Ranging can be extended[11]. Moreover, Foreground-mode is preferred on Background-mode in terms of energyconsumption. As shown in Figure 2.4 Foreground-mode requires less relative energy thanBackground-mode. This, however is based on the relativity. In Foreground-mode, thesmart phone uses a lot of energy for lightning the display and more importantly there isno Background-mode required, because everything can run in the thread of the App.

During the investigation it was discovered, that HTTP server calls do require a lot ofenergy if they are executed in Background-mode. Even though multiple, almost identicalHTTP calls are triggered every Second as shown in Figure 2.5 the energy overhead re-mains. Which indicates, that server calls should be reduced to a minimum - especially ifthey are conducted in Background-mode. Therefor the developed prototype reduced theamount of server calls drastically in order to preserve energy.

52

5.2. ARCHITECTURAL DESIGN 53

In Chapter 3 is has been shown, that applying a strategic approach in selecting the optimalBeacon vendor for a specific use case can be conducted. However, the matrix itself willprobably not be valid within a few months after the completion of this thesis. But thedefined dimensions will obtain relevant and can still be applied on Beacon investigations.Beside the dimensions, the approach in comparing Beacon vendors is documented in thisthesis and can be reused as well.

5.2 Architectural design

As defined in Chapter 1.2, the architectural design will be validated conducting a fieldstudy. Ensuring, that the abstract architectural design can be applied in a real worldsetting and does not only exist on paper. The field study pointed out, that the distinctionbetween walk-in’s and walk-by’s can be detected with an appropriate Beacon design.Furthermore the signal strength became an important factor in order to improve thedetection reliability. However, the developed architectural design did not emphasis adifference in signal strength can lead to an overall improvement of the detection reliability.But according to test results in Chapter 4.2.3, the signal strength is crucial in order to gainan improved reliable Beacon detection, especially in terms of distance estimation usingRSSI. Since background Ranging will be automatically adapted based on the detectedsignal strength of the Beacon, a sufficient signal strength cannot be neglected.

The fundamental use case Enter venue described in sector 4.1 can be applied on thedeveloped architectural design. The differentiation between walk-by’s and walk-in’s ispossible and has been validated. Given that the signal strength of the Beacon inside thevenue must be considerable lower to not interfere with the Beacon signal outside of thevenue. In order to setup a venue with the developed approach an initial testing of theBeacon signal strength is required.

Chapter 6

Summary and conclusion

This chapter summarizes the approach and insights of this thesis. Subsequently an outlookon future investigations in therms of Beacon reliability is given.

6.1 Summary & Conclusion

This thesis introduced a possible solution to enhance the reliability of a Beacon network.Understanding the complex architectural Beacon design requires an in-depth research. De-veloping an architectural design of a Beacon network, Ranging, Monitoring and Beaconconfiguration need to be addressed. Based on the gathered information, an architecturaldesign is developed for two defined use cases. The design was optimized in terms of de-tection reliability and performance impact. A subsequent conducted field study validatedthe design and brought up insights to further increase the detection reliability. In orderto conduct the field study, a prototype was developed. The results from the field studywere collected and applied on the prototype for additional improvement. The resultingprototype has been compared again an existing App solution implemented by a Swissstartup in Zurich. The complete thesis was realized in collaboration with the startup.

The special fast moving nature of the Beacon ecology is makes it difficult to develop asolid approach for a vendor selection. While conducting this thesis, various new productsof Beacon vendors came up. Such as the Smart Beacon Two by Kontakt.io [51]. Itprovides two batteries with a lifetime of up to four years and can broadcast Eddystoneand iBeacon format concurrent. However, the research and evaluation of the architecturaldesign provides an approach of how to increase the detection reliability of of Beacons,especially iBeacons.

6.2 Future Work

During the thesis various new vendors appeared. They are springing up like mushrooms.There is the possibility to expand the number of vendors in the matrix. Especially there

54

6.2. FUTURE WORK 55

are solutions coming up, providing an open source Beacon management platform. Oneof those platforms caught my eyes. It’s called beaconcontrol.io [23] and is developed inRuby in Rails, provides various templates and a complete SDK that can be integrated toan existing App.

This thesis focused on the Apple iOS smart phone in order to increase the detectionreliability. However, according to [63] the distribution between smart phones runningAndroid an iOS differentiate substantial. In Q2 2015 Android holds a market share of82.8% whereas iOS is used by 13.9% of all smart phone owners. This implies that im-proving the detection reliability with smart phones running Android as operating systemis important. Moreover, it should be investigated, where do iOS and Android differ interms of detection reliability.

As mentioned before, the fast moving nature of the Beacon ecology will lead to improveddetection reliability with enhanced solutions presented by Beacon vendors in the next fewyears. In order to preserve a sustainable overview of the Beacon ecology it’s essentialto conduct regular investigations of the available vendors and approaches being utilizedin industry. This ensures to not reinvent the wheel if a specific use case needs to beimplemented.

The actual developed prototype is hardly integrable into an existing App. This shouldbe improved, in order to use the developed prototype functionalities easily within otherapplications. The final result should be an SDK package, which is easy to integrate intoexisting Apps.

Bibliography

[1] 20Minuten App, URL https://itunes.apple.com/ch/app/20-minuten-ch/id285688859, last visted May 17, 2016

[2] aGPS, URL http://www.windowscentral.com/gps-vs-agps-quick-tutorial,last visited May 3, 2016

[3] iBeacon Battery Drain on Apple vs Android: A Technical Report - Aislelabs, URLhttp://www.aislelabs.com/reports/ibeacon-battery-drain-iphones/, lastvisited Apr. 1, 2016

[4] AltBeacon vs. iBeacon, isn’t this just fragmenting things fur-ther?, URL https://community.aerohive.com/aerohive/topics/altbeacon-vs-ibeacon-isnt-this-just-fragmenting-things-further-ibeaconwebinar,last visited Feb. 9, 2016

[5] Android, URL http://www.android.com, last visited Feb. 3, 2016

[6] Apple, URL http://www.apple.com, last visited Feb. 3, 2016

[7] App Review - App Store - Apple Developer, URL https://developer.apple.com/app-store/review/, last visited May 22, 2016

[8] Dependency management for iOS applications, URL https://cocoapods.org/, lastvisited May 22, 2016

[9] Core Location Framework Reference, URL https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/, last visited May 6, 2016

[10] CLBeaconRegion Class Reference, URL https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLBeaconRegion_class/#//apple_ref/occ/instm/CLBeaconRegion/initWithProximityUUID:identifier:,last visited May 24, 2016

[11] Background Execution, URL https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html, last visited May 20, 2016

56

BIBLIOGRAPHY 57

[12] How long does Apple permit a background task torun?, URL http://stackoverflow.com/questions/28275415/how-long-does-apple-permit-a-background-task-to-run, last visited June 3,2016

[13] Bluetooth for Developers, URL https://developer.apple.com/bluetooth/, lastvisited May 31, 2016

[14] Getting the Heading and Course of a Device, URL https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/GettingHeadings/GettingHeadings.html, last visitedMay 18, 2016

[15] Dispatch Queues, URL https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html, last visited May 22, 2016

[16] Apple Releases iBeacon Specification, URL http://beekn.net/2014/02/apple-releases-ibeacon-specification/, last visited May 27, 2016

[17] Region Monitoring and iBeacon, URL https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html, last visited Feb. 3, 2016

[18] Apple Pay, URL http://www.apple.com/apple-pay/, last visited Apr. 28, 2016

[19] About iOS App Architecture, URL https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007072, lastvisited May 6, 2016

[20] Apple Push Notification, URL https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html, last visited May 12, 2016

[21] Swift, URL https://developer.apple.com/swift/, last visited May 22, 2016

[22] WWDC 2013 , URL https://developer.apple.com/videos/wwdc2013/, last vis-ited Feb. 4, 2016

[23] beaconcontrol.io, URL https://beaconcontrol.io/, last visited, June 6, 2016

[24] ios - Beacon Ranging vs GPS tracking battery usage, URL http://stackoverflow.com/questions/29185576/beacon-ranging-vs-gps-tracking-battery-usage.last visited May 5, 2016

[25] The Hitchhikers Guide to iBeacon Hardware: A Comprehensive Report by Aislelabs(2015) - Aislelabs, URL http://www.aislelabs.com/reports/beacon-guide/, lastvisited Feb. 3, 2016

[26] List of the 9 biggest Beacon manufacturers, URL http://www.nodesagency.com/list-9-biggest-beacon-manufacturers/, last visited May 6, 2016

58 BIBLIOGRAPHY

[27] What are the pros and cons of Bluetooth Low En-ergy versus Zigbee?, URL https://www.quora.com/What-are-the-pros-and-cons-of-Bluetooth-Low-Energy-versus-Zigbee,last visited Feb 3. 2016

[28] Members of Bluetooth SIG, Inc., Bluetooth Core Specification v.4.2, 2014

[29] Bluetooth Low Energy | Bluetooth Technology Website, URLhttps://www.bluetooth.com/what-is-bluetooth-technology/bluetooth-technology-basics/low-energy, last visited May 16, 2016

[30] Hacking the CES Scavenger Hunt, URL http://makezine.com/2014/01/03/hacking-the-ces-scavenger-hunt/, last visited Feb. 3, 2016

[31] Estimote Beacons — real world context for your apps, URL http://estimote.com/,last visited Feb. 4, 2016

[32] What’s the battery life of Estimote Beacons? Can I optimizeit?, URL https://community.estimote.com/hc/en-us/articles/202552866-What-s-the-battery-life-of-Estimote-Beacons-Can-I-optimize-it-,last visited Apr. 10, 2016

[33] What is a beacon region?, URL https://community.estimote.com/hc/en-us/articles/203776266-What-is-a-beacon-region, last visited Feb. 11, 2016

[34] Is Eddystone for iOS capable of monitoring or scanning (run-ning in background)?, URL https://forums.estimote.com/t/is-eddystone-for-ios-capable-of-monitoring-or-scanning-running-in-background/1587, last visited Feb. 9, 2016

[35] Is it possible to use beacon ranging in the background? ,URL https://community.estimote.com/hc/en-us/articles/203914068-Is-it-possible-to-use-beacon-ranging-in-the-background-,last visited Feb. 4, 2016

[36] Eddystone Protocol Specification, URL https://github.com/google/eddystone/blob/master/protocol-specification.md, last visited Feb. 10, 2016

[37] Getting Started with Bluetooth Low Energy, URL https://www.safaribooksonline.com/library/view/getting-started-with/9781491900550/ch04.html, last visited May 24, 2016

[38] Apple Inc., Getting Started with iBeacon v.1.0, 2014

[39] Google Self-Driving Car Project, URL https://www.google.com/selfdrivingcar/, last visited May 18, 2016

[40] Gimbal Fee Schedule, URL https://manager.gimbal.com/fee-schedule, last vis-ited Apr. 10, 2016

[41] Gimbal Beacon Installation Best Practices, URL https://docs.gimbal.com/beacon_installation.html, last visited Apr. 13, 2016

BIBLIOGRAPHY 59

[42] Citibank ‘Opens the door’ with Gimbal Beacons, URL http://xorox.io/citibank-opens-the-door-with-gimbal-beacons/, last visited May 18, 2016

[43] Beacons | Google Developers, URL https://developers.google.com/beacons, lastvisited Feb. 9, 2016

[44] Google Play Store, URL https://play.google.com/store?hl=de, last visited May24, 2016

[45] iOS Beacon Scanning Interval, URL http://stackoverflow.com/questions/32006985/ios-beacon-scanning-interval, last visited Feb. 11, 2016

[46] Beacons and beyond, URL https://kontakt.io, last visited Apr. 10, 2016

[47] Replacing the battery in your Kontakt.io Smart Bea-con, URL https://support.kontakt.io/hc/en-gb/articles/201620831-Replacing-the-battery-in-your-Kontakt-io-Smart-Beacon, lastvisited Apr. 13, 2016

[48] Kontakt.io Launches USB Beacon Beta Program and You Can Join!, URL https://kontakt.io/blog/kontakt-usb-beacon-beta-launches/, last visited Apr. 10,2016

[49] Beacons Have Been Vulnerable For Too Long. It’s Time We Fixed It., URL https://kontakt.io/blog/beacon-security/, last visited Apr. 12, 2016

[50] Eddystone Q&A—27 Frequently Asked Questions Answered, URL http://kontakt.io/blog/eddystone-faq, last visited Feb. 10, 2016

[51] Kontakt.io Smart Beacon Two: Double Battery Life to Empower You to Do More,URL https://kontakt.io/blog/smart_beacon_two/, last visited Jun. 10, 2016

[52] LEMP Stack Info (Linux, Nginx, MariaDB/MySQL, PHP), URL https://lemp.io/, last visited May 3, 2016

[53] Lightcurb beacon platform supports Google Eddystonebeacon standard, URL https://www.lightcurb.com/en/lightcurb-beacon-platform-supports-google-eddystone-beacon-standard,last visited Feb. 10, 2016

[54] About Objective-C, URL https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html, last visited May 3, 2016

[55] Payments made easy with the Swiss mobile payment solution., URL http://www.paymit.com/en/home/individuals.html, last visited Apr. 28, 2016

[56] Lumen - PHP Micro-Framework By Laravel, URL https://lumen.laravel.com,last visited May 3, 2016

60 BIBLIOGRAPHY

[57] Qualcomm Announces Availability of its Gimbal Proximity Bea-cons to Enable Customer Engagement Based on Micro Loca-tion, URL https://www.qualcomm.com/news/releases/2013/12/09/qualcomm-announces-availability-its-gimbal-proximity-beacons-enable,last visited Feb 4. 2016

[58] We Make Proximity Work, URL http://www.radiusnetworks.com/, last visitedApr. 10, 2016

[59] Plans and Pricing, URL https://account.radiusnetworks.com/plans, last visitedApr. 14, 2016

[60] Introducing Eddystone; The New Beacon Format From Google, URL http://developer.radiusnetworks.com/2015/07/14/introducing-eddystone.html,last visited Feb. 10, 2016

[61] Background Monitoring of Beacon Regions on iOS, URL http://developer.radiusnetworks.com/2015/04/21/max-beacon-regions-ios.html, last visitedMay 3, 2016

[62] 84 Percent of Millennials Act on Push Notifica-tions, URL http://www.dmnews.com/marketing-strategy/84-percent-of-millennials-act-on-push-notifications/article/448580/,last visited Apr. 28, 2016

[63] Smartphone OS Market Share, 2015 Q2, URL http://www.idc.com/prodserv/smartphone-os-market-share.jsp, last visited June 10, 2016

[64] What’s the difference between the “global queue” and the “mainqueue” in GCD?, URL http://stackoverflow.com/questions/9602042/whats-the-difference-between-the-global-queue-and-the-main-queue-in-gcd,last visited May 24, 2016

[65] objective c - What’s the maximum value for major and minor for iBea-con transmitter?, URL http://stackoverflow.com/questions/29505807/whats-the-maximum-value-for-major-and-minor-for-ibeacon-transmitter,last visited March. 31, 2016

[66] A Universally Unique Identifier (UUID) URN Namespace, URL https://tools.ietf.org/html/rfc4122, last visited Feb. 11, 2016

[67] Xcode - What’s New - Apple Developer, URL https://developer.apple.com/xcode/, last visited May 5, 2016

[68] The ZigBee Alliance | Control your World, URL: http://www.zigbee.org/, lastvisited May 7, 2016

Glossary

App is a software based application that can be installed and run on a Apple iOS smartphone.

Administrator is in charge of the Beacon management, deployment and sourcing. Inaddition he needs to define an adequate architectural design to optimize the detec-tion reliability of the Beacons.

Architectural design is defined as the architectural setting of iBeacons. E.g., howdo they need to be arranged in order to work properly and increase the detectionreliability.

Beacon is small device with approx. five centimeters in diameter. It consists of ahardware that emits a Bluetooth signal. It can host a battery as power source orcan be powered externally.

Beacon ecology contains all economy sectors in industry, dealing with Beacons pro-ducing hard- or software products.

Beacon format is a package type, which a Beacon emits and that can be read by smartphones having software implemented, which can read the packet data / Beaconformat.

Developed prototype is an iOS based prototype, developed based on the findings inthis thesis in order to increase the Beacon detection reliability.

End-user are defined as the humans actor interacting directly with the smart phonewhich is defined as an Apple iOS based device.

Hibernation mode is a mode of the smart phone. In this mode the phone is not turnedoff, but hibernating, so the screen is turned off and it can wake up if notificationsarise.

Location-service, which are provided by a smart phone an end-user can be activatedor deactivated. If it’s activated, the end-users movement will be tracked. In theother case it won’t. In this thesis it’s assumed, that Location-services are activatedby default on the end-users smart phone.

Monitoring state occurs on a smart phone, if it’s scanning for Beacons in the Back-ground mode. Monitoring is only used on Apple [6] smart phones, Android [5]devices do not make any use of Monitoring. Monitoring is used on Apple [6] smart

61

62 BIBLIOGRAPHY

phones to detect Beacons while the smart phone is in Background mode. This canbe used to detect Beacons while the smart phone is locked and in the pocket of theuser.

Ranging is the process where a smart phone is scanning for Beacons within its proximity.At Ranging - in contrast to Monitoring - the device gathers the complete stack ofthe broadcasted informations by the Beacons. Ranging only works for a limited timein Background mode (approx. 10 - 30 Seconds and a maximum of 180 Seconds). Ifthe App is in Foreground mode the Ranging time is not limited.

Regions are used to defined geographic boundaries. A Region can be defined by one ormultiple Beacons. An end-users holding a device that can detect Beacons can enteror exit a region and the devices identifies if the End-users is entering or exiting theregion.

Smart phone in this thesis is generally an Apple iPhone running at least iOS version9.0 on it.

SDK (Software development kit) is a software code package, which will be integratedwithin an existing application. In this thesis it is used in the context of a smallpart of the smart phone application. The SDK provides methods and functions tointerrogate with the Beacon software functionalities.

Beacon vendors are selling Beacons with the required soft- and hardware. Besides thehard- and software Beacon vendors also provide a complete cloud based system tomanage the Beacon fleet.

Proximity UUID is a unique identifier, which is required to identify a Beacon region.

Major and Minor are numerical values of 16 Bits, so they have 65’535 possible values.They are used to distinguish between groups of Beacons. For example all Beaconson a specific floor within one region have a specific value [65].

Background mode / scanning allows the App to detect Beacons within the end-userssmart phones proximity. Also if the end-user has not opened the App on his smartphone and does not directly interacts with it.

Foreground mode / scanning allows the App to detect Beacons within the end-userssmart phones proximity. Only if the end-user has opened the App on his smartphone and directly interacts with it.

Push Notifications can be received by smart phone end-users. Push Notificationscontain a simple text message that will be displayed on the smart phone of theend-user.

Geofencing can be used to define a geographic boundary. In contrast to define aRegion, Geofencing uses GPS or RFID (Radio Frequency Identification) to createboundaries. If an end-user crosses the boundary with his smart phone, it triggersan entry-event which can be used to send E.g., Push Notifications.

List of Figures

2.1 GAP (Generic Access Profile) . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 GATT (Generic Attribute Profile) . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Battery drain: Device comparison [3] . . . . . . . . . . . . . . . . . . . . . 12

2.4 Energy consumption: Monitoring and Ranging . . . . . . . . . . . . . . . . 13

2.5 Energy consumption: HTTP server call in Background-mode . . . . . . . . 14

4.1 Explanation of architectural design visualization . . . . . . . . . . . . . . . 27

4.2 iOS prototype screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Design development: First iteration . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Design development: Second iteration . . . . . . . . . . . . . . . . . . . . . 34

4.5 Design development: Final iteration . . . . . . . . . . . . . . . . . . . . . . 35

4.6 Architecture design: First iteration . . . . . . . . . . . . . . . . . . . . . . 37

4.7 Architecture design: Final iteration . . . . . . . . . . . . . . . . . . . . . . 37

4.8 Funnel shielding Beacon signal . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.9 Venue used: Shop and Ad-poster . . . . . . . . . . . . . . . . . . . . . . . 39

4.10 Low signal strength: Signal strength detected by prototype . . . . . . . . . 40

4.11 High signal strength: Signal strength detected by prototype . . . . . . . . 41

4.12 High signal strength: Inside & outside Beacon detection . . . . . . . . . . . 42

4.13 Ad-poster: Direction detection reliable . . . . . . . . . . . . . . . . . . . . 43

4.14 Ad-poster: Direction detection not reliable . . . . . . . . . . . . . . . . . . 44

B.1 Low signal strength: Signal strength detected by prototype . . . . . . . . . 69

63

64 LIST OF FIGURES

B.2 High signal strength: Signal strength detected by prototype . . . . . . . . 70

B.3 High signal strength: Inside & outside Beacon detection . . . . . . . . . . . 71

B.4 Ad-poster: Direction detection reliable . . . . . . . . . . . . . . . . . . . . 72

B.5 Ad-poster: Direction detection not reliable . . . . . . . . . . . . . . . . . . 73

List of Tables

3.1 Documentation features provided by vendor . . . . . . . . . . . . . . . . . 19

3.2 Vendor provided security features . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Vendor provided SaaS services . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Vendor provided scalability factors . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Selection matrix: Weighted vendors relative to dimensions . . . . . . . . . 24

3.6 Selection matrix: Security solution vendor selection . . . . . . . . . . . . . 24

3.7 Selection matrix: Thesis vendor selection . . . . . . . . . . . . . . . . . . . 25

65

Listings

4.1 Source: Define a Beacon Region and start Monitoring . . . . . . . . . . . . 284.2 Objective-C code for Beacon detection . . . . . . . . . . . . . . . . . . . . 304.3 Solution A Beacon detection: Part A . . . . . . . . . . . . . . . . . . . . . 464.4 Solution A Beacon detection: Part B . . . . . . . . . . . . . . . . . . . . . 474.5 Solution B: Background task . . . . . . . . . . . . . . . . . . . . . . . . . . 49

66

Appendix A

Contents of the CD

The attached CD contains the following files and directories:

• Abstract.txt: A plain text of the English abstract.

• Thesis.pdf: PDF version of the thesis.

• Zusammenfassung.txt: A plain text of the German abstract.

• client-code: Directory containing source code.

• documents: Directory containing documents.

• server-code: Directory containing source code.

• documents/presentations: Directory containing the mid-term presentation (finalpresentation will be handed in after it has been held).

• documents/thesis: Directory containing the LaTeX source of this thesis.

Note the manual.pdf in the root directory of the CD with additional informations con-cerning the data on the CD.

67

Appendix B

Diagrams

The used diagrams are presented on the following pages in full resolution.

68

69

Figu

reB.1:

Low

signa

lstrength:

Sign

alstreng

thdetected

byprototyp

e

70 APPENDIX B. DIAGRAMS

FigureB.2:

High

signalstrength:Signalstrength

detectedby

prototype

71

Figu

reB.3:

Highsig

nals

trength:

Insid

e&

outsideBe

acon

detection

72 APPENDIX B. DIAGRAMS

FigureB.4:

Ad-poster:

Direction

detectionreliable

73

Figu

reB.5:

Ad-po

ster:Dire

ctiondetectionno

trelia

ble

reliable beacon detection - uzh...reliable beacon detection robin engbersen zurich, switzerland...

Documents