ifi Reliable Beacon Detection Robin Engbersen Zurich, Switzerland Student ID:

Transcription

1 MASTER-THESIS Communication Systems Group, Prof. Dr. Burkhard Stiller Reliable Beacon Detection Robin Engbersen Zurich, Switzerland Student ID: Supervisor: Jan Berchtold, Dr. Corinna Schmitt, Dr. Thomas Bocek Date of Submission: June 15, 2016 University of Zurich Department of Informatics (IFI) Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

2 Master-Thesis Communication Systems Group (CSG) Department of Informatics (IFI) University of Zurich Binzmühlestrasse 14, CH-8050 Zürich, Switzerland URL:

3 Abstract This thesis provides an architectural solution to increase the detection reliability of Beacons by smart phones for defined use cases. Prior an in-depth research of all hardware and software vendors dealing with Beacons is required, elaborating Beacon setting and network 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, scalability, documentation and others. Therefor a selection matrix had to be designed in order to choose the optimal Beacon vendor based on required use case criteria. Based on 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 solution development and subsequent validation. The resulted architectural solution has been implemented and tested by developing a prototype. It has been applied in a field study in order to evaluate, if the detection reliability can be further increased based on the data of signal strength. The final prototype has been compared against an existing solution provided by a startup company in Zurich, Switzerland in order to enhance the existing prototype and highlight improvements made with the developed prototype. i

4 ii

5 Zusammenfassung Diese Arbeit präsentiert und dokumentiert den Entwicklungsprozess, wie die Erkennung von Beacons in für definierte Anwendungsfälle zuverlässiger gestaltet werden. Im Vordergrund wurde eine detaillierte Recherche betrieben, um den Aufbau von Beacon Netzwerken zu verstehen und um die gewonnenen Informationen anschliessend für die Erarbeitung eines Ansatzes, der die Erkennung von Beacons durch smart phones verbessern soll, zu entwickeln. Im Anschluss an die Recherche, wurde eine Auswahl an Beacon Hardware Herstellern, basierend auf Beacon Sicherheit, Beacon Skalierbarkeit und weiteren Dimensionen miteinander verglichen. Aus diesem Vergleichsprozess entstand eine Matrix, die den Findungsprozess von Beacon Herstellern unterstützt. Anschliessend wurde ein mögliches Beacon Design in einem mehrstufigen, iterativen Prozess entwickelt, welches die Erkennung von Beacons durch smart phones verbessern soll. Dabei wurde für jede Stufe eine mögliche Lösung sowie eine anschliessende Validierung dessen erarbeitet. Das anschliessend resultierende Design wurde in einem ios Prototypen umgesetzt, um in einer durchgeführten Feldstudie zu evaluieren, ob die Erkennung von Beacons verbessert werden kann. Dabei wurde das Augenmek vor allem auf die Signalstärke gelegt. Der finale Prototyp wurde mit einer existierenden Lösung, die von einem Schweizer Statup mit Sitz in Zürich bereits aktiv läuft, verglichen. Dabei wurde der Prototyp vor allem um gewinnbringende Ansätze der existierenden Lösung erweitert, sowie die Verbesserungen des Prototyps bezogen auf die existierende Lösung aufgezeigt. Weitere Arbeiten wären, dass die Selektionsmatrix um weitere Beacon Anbieter erweitert wird oder die Improvisation des Prototypen um diesen um eine SDK-Version auszuweiten. iii

6 iv

7 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 his competent assistance, patience, guidance and insightful comments during my thesis. I appreciate Prof. Dr. Burkhard Stiller in giving me the opportunity to to write this thesis at the Department of Informatics of the University of Zurich. Furthermore, I like to express my thanks to Dr. Corinna Schmitt and Dr. Thomas Bocek for the enlightening discussions and their competent support, which allowed me to improve the design of my thesis significantly. Last but not least, I like to thank my family and close friends for their support throughout this work. v

8 Contents Abstract i Zusammenfassung iii Acknoledgements v 1 Introduction Motivation Description of Work Thesis Outline Related work Beacons Bluetooth Low Energy (BLE) Bluetooth modes Monitoring and ranging Beacon formats AltBeacon Eddystone ibeacon Beacon security Security threads Battery performance impact Apple iphone vi

9 CONTENTS vii 3 Vendor comparison Estimote Gimbal Radius Network Kontakt.io Comparison dimensions Sufficient documentation Security features Cloud based Beacon management Scalability support Selection matrix Architectural Beacon design Use case definition Architectural design development Prototype Iterative development Design validation Prototype improvements Comparison against existing solution Evaluation Performance impact Architectural design Summary and conclusion Summary & Conclusion Future Work Bibliography 56

10 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

11 Chapter 1 Introduction During the last few years the overall worldwide digitization increased. Mobile phones became smart phones, personal computers got more and more replaced by tablets. Google introduced their first autonomous driving car [39]. This development indicates, that the overall interconnection between humans and digital devices increases. Digital devices - especially smart phones - start to get indispensible in our every day life. Today it s already possible to use them as payment device. Apple Pay [18] or Paymit [55] already demonstrated that there exists potential in the market for those solutions. Researches even showed, that the interest in location based push notifications among millenials rise significantly [62]. Besides all digitization approaches, location provided notifications can gain importance in the near future. Therefor it makes sense to investigate solutions providing location based detection methods deeper, to identify their strengths and weaknesses in order to find the best fit for a given use cases. 1.1 Motivation This thesis develops a reliable Beacon detection architectural design with ibeacons. ibeacons were introduced in 2013 by Apple and are specialized Beacons. This specialization will be clarified later in Chapter 2.2. After Apple introduced the ibeacons, various implementation approaches using ibeacons emerged in industry [26]. Beacon vendors offer a cloud based Beacon management platform and the assembly of the physical hardware (ibeacons). However, selecting the optimal Beacon vendor for a specific use case can become challenging in terms of Beacon security, Beacon scalability or Beacon vendor implementation documentation. Those and other factors need to be taken into account during the Beacon vendor selection process. In this thesis an approach will be introduced to support administrators to select the optimal Beacon vendor for a specific use case. According o the collaborating Swiss startup, detecting end-users patterns with Beacons becomes attractive. Nowadays it s simple to enhance an existing App, that is widely used in community with a Beacon detection framework (SDK). Which can provide the App owner with specific end-user patterns. They can be used to specifically target Ads on 1

12 2 CHAPTER 1. INTRODUCTION end-users based on their preferences. To reliable detect end-users movement and generate patterns out of it, a sophisticated architectural Beacon design is required. Furthermore a prototype will be developed to verify architectural designs to increase the detection reliability 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 a Swiss startup in Zurich, Switzerland. 1.2 Description of Work The contributions of this thesis are manifold. First, the an extensive research of the Beacon ecosystem is conducted. This includes the identification of Beacon vendors offering different types of Beacon products. Those vendors will be analyzed and compared to each other according to certain dimensions, like Beacon security, pricing structure, Beacon configuration ease-of-use and others. Based on the findings a selection matrix will be developed. This matrix is applied to select the optimal Beacon vendor. Simultaneously the study of the Beacon format is part of the first step. The subsequent conducted field study consists of an iterative development of an architectural design, to enhance the detection reliability of Beacons by smart phones. The architectural design will be validated in a real word scenario (field study) which requires the development of an prototype. The gained results of the field study are compared against an existing prototype developed by a cooperating Swiss startup, to determine the improvements. 1.3 Thesis Outline Chapter 2 explains the overall Beacon setup. Especially the format which is used to establish a connection between Beacons and smart phones. It highlights existing security threads that arise with the Beacon ecosystem such as piggybacking, hijacking and physical impact. Provides information about the available Beacon formats and states their advantages and disadvantages. Chapter 3 aggregates the results of the Beacon vendor research. It introduces a matrix to support administrators with the selection process of finding the optimal Beacon vendor for a dedicated use case scenario. The matrix will be applied to select the optimal Beacon vendor for the conducted field study in this thesis. Chapter 4 introduces the developed architectural design and describes the iterative approach adopted. It describes the prototype and highlights the insights gathered with testing in a real world scenario. The architectural design is developed based on the findings and the insights obtained by research from Chapter 2 and 3. Chapter 5 presents the evaluation results of the field study and summarizes future work topics.

13 Chapter 2 Related work In this chapter the conducted research of related work is documented. Due to the fast changing 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 of a microcontroller with a Bluetooth Low Energy (BLE) radio chip attached and usually a battery as power supply [25]. Besides batteries, Beacons can also be powered by external sources, 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 by smart phones if it s within the Beacons proximity and Bluetooth is activated on the smart phone. So Beacons can be used to create proximity areas where the boundary is defined 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-user carrying a smart phone and enters a Region, the smart phone detects the Region entry event and can trigger events. This thesis focuses on Beacons that are designed for Apple smart phones, they are named ibeacons. Beacons can be configured in various ways; therefore it s necessary to understand the Beacon architectural setting in detail. The following subsection will provide a detailed insight into the Beacon setting Bluetooth Low Energy (BLE) Beacons use BLE [29] to broadcast their information within its proximity area. Bluetooth capable smart phones can detect that information and trigger customized events. 3

14 4 CHAPTER 2. RELATED WORK Bluetooth was first designed to compete with WiFi networks. But it did not develop a standard to replace WiFi, it became an important protocol for over the air audio transmissions. In 2009 Bluetooth was extended with BLE (Bluetooth Low Energy), and 2010/2011 it was implemented and ready to hit the market. The key difference between Bluetooth and BLE is the reduced power consumption. Hence BLE allowed Bluetooth to enter the IoT market, because of it s low energy consumption. However, ZigBee [68] is still one of BLE biggest competitors in the IoT market. [27] One of BLE s advantages is the exchange of data between two entities with a low power consumption. Therefor it provides two connection modes: Connected mode uses the GATT (Generic Attribute) layer to transfer data over a oneto-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 and allocate 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 can be detected by devices within proximity and supporting the appropriate format of the signal. There is only a one-way data exchange possible. Beacons use the advertisement role of the GAP. [28] Currently there exist three Beacon formats which will be introduced in detail in Chapter 2.2: ibeacon format was first established and deployed to markets in 2013 by Apple. Apple kept the detailed ibeacon format specification classified. However, some details which 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 format it expands the payload by an URI. Which enhance the information richness to be transferred to a smart phone. Eddystone and AltBeacon are open-source. AltBeacon has been established and is distributed by Radius Network Inc. [58] Bluetooth modes Bluetooth uses two different kind of Bluetooth modes. The following section explains the basic understanding of how data is exchanged between two devices using Bluetooth. Beacons, that use Bluetooth will apply the identical mechanism.

15 2.1. BEACONS 5 Advertising mode In advertising mode the GAP (Generic Access Profile) is used. This profile defines, that a smart phone can either take a central or peripheral role (see Figure 2.1). Whereas listening 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 a high 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 Attribute Profile (GATT). Using the GATT one of the two devices exchanging information must be either be defined as a client or a server. The client acts as the requesting device who collects information from the server device. In a Beacon / smart phone topology, the server 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)

16 6 CHAPTER 2. RELATED WORK Figure 2.2 shows the layers of GATT approach. Between the client and the server, attributes are being exchanged. By definition of GATT, attributes are the smallest data entities. They contain relevant metadata, like for example Beacon temperature or Beacon signal interval. Applying the GATT concept, the attributes are always located on the server and the client fetches them. GATT groups conceptually identical attributes in sectors and describes them with a Service definition. Each Service contains a number of Characteristics. They always include at least two attributes [37]: Characteristics declaration provides metadata (or even an explanation) about the 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 the Apple ios framework they are not allowed to be configured. The next section explains how data exchange and the connection between two devices is conducted with the Apple framework used in this thesis Monitoring and ranging The specifications on the previous section are required in order to exchange data within two Bluetooth enabled devices. This thesis is focusing on the ibeacon format to exchange data. The format is applied on smart phones in order to exchange data. It is provided by Apple and explained in Chapter 2.2. The Apple ibeacon specification document [17] states, that Beacons are enhancements to improve the detection quality of smart phones within a defined geographic Region towards other methods like GPS or agps [2]. A Beacon Region can be defined with a single physical Beacon but also with multiple Beacons. Beacons emit a circular signal which can be detected by a smart phone supporting the Beacon format. In contrast to GPS, where the location of the smart phone is identified outdoors using GPS, Beacons can also be used for indoor localization. The power consumption of a Beacon network is less compared to a GPS based approach [24]. But GPS does not need to be activated by the 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 and the 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. The type of scanning for Beacons differ depending on the mode the App currently uses. Hence there exist two different types of scanning for Beacons:

17 2.1. BEACONS 7 Monitoring Ranging An App starts with Monitoring as soon as the end-user has permitted the App to use Location-Services. The App continues Monitoring also while the end-user has opened other 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 the end-user is interacting with the App. Ranging is used to provide extra information about the Beacon. This extra information can be for example temperature of a Beacon or brightness factor. Transferring these extra information, will lead to an increase in power consumption 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 that is running in Background-mode can monitor for a defined set of Regions. This enables the App, to detect if a smart phone end-user enters a Region even if the App is not in Foreground-mode. Which could hypothetically lead to a total surveillance of the end-user by a third party. So Apple limited the number of defined Regions per App to a maximum of 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 a Region. 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 combination of UUID and major. a combination of UUID, major and minor: A Beacon Region will be defined by an combination of UUID, major and minor. This thesis will address the combination of how to define Regions in Chapter in more detail. A UUID is used as a unique identifier. To preserve it s uniqueness, it has to be generated using 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 App to only determine entries or exits of Regions. It can happen, that events on Monitoring mode will be triggered up to 5 Minutes [61] delayed. In contrast to Monitoring, Ranging is more responsive. It can determine the approximate distance between the Beacon and the smart phone and also improve the responsiveness of entry and exit events. According to [35] and [38], ranging in Background-mode is not favored by Apple. Unless there is obvious benefit for the end-user available. Otherwise the App might not get approved by the Apple review approval process. Ranging has a higher battery consumption (see Section 2.4) in contrast to Monitoring and it allows to track the movement of the end-user in detail, which can lead to privacy concerns.

18 8 CHAPTER 2. RELATED WORK Triggered exit events can arise from false-positives. E.g., when a physical object suddenly obstructs the Beacon and its signal is not detectable for a few Seconds. To preserve false-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 that can be detected by smart phones having proper software implemented, which can read the packet data. In the Beacon ecology, there exist various vendors providing their individual Beacon format in order to differentiate from their competitors. Subsequently a selected range of Beacon formats used in this thesis are introduced AltBeacon AltBeacon is an open source Beacon format developed and provided by Radius Networks Inc. [60]. It was introduced in July 2014 [60]. At first Radius Network named their Beacons ibeacon. Suddenly they had to change it to AltBeacon, because ibeacon was protected as trademark by Apple [4]. Not only the brand name changed, they also opened up the format for developers to increase configuration possibilities. The Radius Network vendor, who distributes the AltBeacons, provides the possibility to advertise ibeacon and AltBeacon at the same time [4] Eddystone Eddystone is an open source Beacon advertisement format for BLE devices developed and provided by Google [43]. It was introduced in July 2015 [60]. The advantage of Eddystone among other Beacon vendors is the multi-beacon concept. Which means, that a single hardware (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 a namespace and an optional instance. According to Googles Eddystone Specification [36], the namespace is used to group a specific set of Beacons, whereas the instance is set to define single Beacons. To improve performance, the scanning can be reduced to the namespace of the Beacon. Eddystone-URL is a URL frame broadcasted, as well as using a compressed encoding format. This URL is well formatted once it s decoded. The URL can be used as a standard formatted URL. The Eddystone-TLM telemetry frame broadcasts relevant information about the Beacon itself. Such as battery status, Beacon temperature or broadcasting packets.

19 2.2. BEACON FORMATS 9 Stated that AltBeacon invented the multi-beacon concept already two years ago. Google is the first company developed a standard for multi-beacons [60]. Nowadays almost all Beacon vendors investigated during this thesis provide a multi-beacon concept. The advantages of a multi-beacon concept will be addressed later in this thesis ibeacon ibeacon is a standardized BLE advertisement format developed by Apple [13]. It is supported by all, in this thesis analyzed Beacon vendors. The ibeacon format uses an advertisement 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]. Which means an App can only scan for 20 Regions the same time. However, the Regions can be adjusted during runtime which offers the administrator to extend the amount of available Regions per App to theoretically infinite number. There exist 2 16 Major and Minor values. Which leads to a theoretically total amount of 2 32 Regions to be defined based on one UUID. So the amount of total Regions to be defined is quite high. Apple has introduced a framework to detect Regions within an App. The so called CoreLocation Framework [9]. It handles all location functionalities on an App. Geofences detected by GPS signals or Regions detected by Beacons are included. CoreLocation Framework is also responsible for the privacy handling on the device. Which means the smart phone end-user can deactivate Location-services which leads to deactivation of all or a subset of services the CoreLocation Framework provides. The fact, that Eddystone Beacons provide a lot of handy functionalities, such as URL and TLM it s obvious that it can be used as a replacement for the ibeacons. However, one of the major drawbacks is, that Eddystone Beacons cannot be detected on smart phones in Background-mode using CoreLocation Framework. To proper detect them while the App is not in Foreground-mode, CoreLocation Framework is required. In order to apply the CoreLocation 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 App approved by the Apple AppStore Review process [7]. Therefor it s not a simple task to get Eddystone working with smart phones. Whereas for Android devices, the process of uploading an Android application to the Google Play Store [44] does not require a detailed application review. There are rumors [53], that a combination of Eddystone and ibeacon might fix this issue. Using ibeacons to wake up the smart phone and start to detect Eddystone 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,

20 10 CHAPTER 2. RELATED WORK this fact makes it even less interesting for Apple devices, because the Safari browser is already 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 serious security threads. A prime example; the CES (Consumer Technology Association) 2014 scavenger hunt in Las Vegas [30]. The CES intend to encourage their visitors visiting key areas of the show and earn so called "badges" if they have been the proximity of the area. For this kind of setting, the Estimote Beacons used without any kind of security algorithm implemented. The fact, that every Beacon emits identical signals (i.e. uses the same Region) for the complete time of the exhibition brought up the idea of piggybacking the Beacons. So that a visitor did not have to physically visit the key areas of the CES in order to win the scavenger hunt. This example demonstrates the importance of having a sufficient pre investigation of possible security threads and provide solutions for them. This section will exemplify current security threads and introduce solutions Security threads There exist various vulnerabilities that can lead to Beacons getting taken over or modified by 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 it at another place makes your App think you are in the Beacons proximity although you aren t. Since most Beacons broadcast the identical signal for their lifetime, piggybacking can 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 rolling UUID s requires, that the App conducts a server call for every Beacon detection. Because only the server is aware of the rolling UUID list of the Beacon. Whereas with a rotating UUID approach the Beacon repeats the identical UUID pattern. The interval for rolling or rotating UUID s can be between Seconds and Minutes. The more often the UUID is changed, the more secure is the Beacon, but the higher the costs are in terms of server calls or UUID usage. Because the maximum amount of UUID s available on a smart phone to scan for are limited to 20.

21 2.3. BEACON SECURITY 11 Hijacking The Beacon firmware is required to be updated from time to time. During the update process the device needs to connect with the Beacon will be authorized and gained access by providing credentials to the Beacon. A man-in-the-middle is able to fetch or alter the transferred 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 the transferred data. To prevent hijacking attacks, data sent and received from the Beacon while configuring it needs to be encrypted. Hence encryption requires more CPU power and therefore more energy consumption. Physical impact Beacons can be exposed to the public. Strangers can gain access to the Beacons by modifying, destroy or replace it. The probability this will happen is low, since the effort involved is quite high. But if the Beacon controls the opening of a garage door, the effort can 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 the venue so that crossing pedestrians cannot sight it. To sum up on the various threads. The impact of a specific security thread always depends on the use case and environment the Beacons are used. For example sending personalized campaigns to customers in the proximity of a shopping mall has a lower security impact than a Beacon opening a garage door. Beside security threads decreasing the Beacon reliability, the energy consumption of the scanning for Beacons on the smart phone can also reduce the reliability in detection. For example if the end-users smart phone is powerless, it cannot be detected anymore neither can detect any Beacons within its proximity.

22 12 CHAPTER 2. RELATED WORK 2.4 Battery performance impact Due to the fact that scanning for Beacons need continuous activity in the background of the phone, the overall battery drain increase. A fast draining battery can also lead to a negative performance impact of the smart phone. The smart phone starts with the power saving 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 of smart phones is below one percent for daily usage. The experiment was conducted using Apple and Android smart phones. Figure 2.3 shows the battery consumption between them 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. For example the Moto G BLE chipset decodes only about 25 to 33 percent of all received Bluetooth signals. This makes them very power efficient compared to other devices Apple iphone The scope of this thesis deals with Apple iphones. Android phones will not be used for testing in this thesis. Therefore it s crucial to have a more into depth research of the power consumption of iphones. Considering Monitoring and Ranging states on the iphone its necessary to investigate the energy consumption of those states. So the following three scenarios have been tested: Comparison between Monitoring / Ranging

23 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 charged and connected to power. Data is exchanged using WiFi. Comparison Monitoring / Ranging The general contrast between the energy consumption on Monitoring and Ranging is discussed. 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 explained in Section Each square denoted one Second in time where the x-axis is the time passed. 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 the top 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 using its built in 3G or WiFi. Location indicates, that the Location-Service is active. It represents the smart phone detecting the end-users current location using various services that are provided (i.e GPS, 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 Beacons within its proximity. However, the App has one defined Region Y to Monitor for. So initially it starts with Monitoring which scans for the defined Region. There is no Background and Location activity going on. This implies, that monitoring does not require extra power. After about 16 Seconds, a Beacon broadcasting the Region Y appears within the Apps proximity. On Figure 2.4 a sudden increase of the energy consumption visualized

24 14 CHAPTER 2. RELATED WORK by the blue bars. Meaning, that the Location-services started to run in Background-mode and the App started Ranging for Beacons within its proximity. The appearance of the gray block in the Background row implies that the Background-mode is active. This proves, that there is a significant energy usage difference between Monitoring and Ranging on an iphone. After the Ranging has started, the App is opened manually by the end-user on the smart phone. Thus the Location-services can switch from Background- to Foreground-mode which leads to a decrease in the overall Apps energy consumption. This can be seen in the drop of the blue bars after about 32 Seconds. Simultaneously the Background service has stopped. Comparing the blue bars on top between Background-mode and Foreground-mode shows on Figure 2.4, that the overall energy consumption is twice as much 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 server to 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 in Background-mode. Especially if of Beacon security is applied, the amount of server calls increase. Likewise there might be a solution to increase the reliability of the Beacon detection by increasing the amount of server calls to swap the application logic from the App onto a central server entity. Figure 2.5 shows the energy consumption timeline of an App that runs in Backgroundmode. 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 is rated as Overhead. Hence every server call uses a lot of energy relative to all other services the App is using. So this implies that its not efficient, to execute a lot of server calls while the App is in the Background-mode. Interestingly, the energy used for every http call does not decrease over time. Which leads to the fact, that a few calls with a lot of 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 work properly. If the SDK is used, a lot of updates of the detected Beacon will be sent to the

25 2.4. BATTERY PERFORMANCE IMPACT 15 server of the vendor. Particularly if a security feature is activated a server call on every Beacon 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 height of the preceding one. This might imply that there is some sort of optimization in sending HTTP server calls. Conclusion Since this thesis focuses on Apple iphones, Ranging in Background-mode should be reduced to a minimum. The optimum would be, if Ranging can be dynamically adapted depending if its required to increase detection reliability or not. Or stimulating the enduser to open the App, so that the App can enter Foreground-mode which would reduce the relative energy consumption of the App. Additionally the amount of server calls need to be minimized so that the overall energy consumption can be reduced.

26 Chapter 3 Vendor comparison During the last few years, various vendors developed their individual Beacon product and tried to distinguish themselves from other competitors with innovative features. Beside selling plain Beacons, which are hardware based devices with handy functionalities like temperature or motion sensors, vendors pursue to keep there customers with them and generate Lock-In s. It s obvious that a product, based on hardware components is on the one hand easy to copy, and on the other hand the price is the only differentiation among competitors. Time passing, vendors discovered that the management of a large amount of installed Beacons in production requires a sophisticated software handling them, as well as configuring they re settings like UUID, Major, Minor and RSSI settings. Configuring each Beacon by hand takes big effort. E.g., it takes about five Minutes for a Beacon administrator, to add a 36 digit UUID, Major and Minor in order to have a Beacon configured and ready for production. Rolling out between 100 and 200 Beacons, will take about 12 Hours just for the configuration. So vendors introduced cloud based services allowing 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 needs to be within the proximity of the Beacon in most cases. But it does not require entering complex UUID s, Major / Minors, signal strength settings. Besides, the vendors also provide a customized SDK that can be integrated with an existing App. Some SDK s even support automatic update of Beacons, without the need of a Beacon administrator to be within it s proximity. There are a lot of Beacon vendors active in the market. In cooperation with a startup in Zurich, focusing on a few vendors who have gained a sustainable position at the market. It was especially important, that they allow shipment of their products to Europe/Switzerland for further testing and comparison of the functionalities. The following chapters introduce the vendors being compared followed by a comparison of them based on defined dimensions. 16

27 3.1. ESTIMOTE Estimote Estimote was one of the first vendors on the market after Apple introduced ibeacons in late 2013 [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 market share with the Estimote Beacons. There exist two different versions of the Estimote Beacons; location Beacons or proximity Beacons. As the name predicts, location Beacons are optimized for indoor location tracking whereas proximity Beacons are optimized to detect end-users entering the proximity area of a Beacon. However, for both Beacon versions the replacement of the battery was suboptimal. The Beacon cover had to be destroyed in order to get the battery. Estimote began to ship Beacon covers on goodwill for customers who destroyed the Beacon cover replacing the batteries. In 2015 they started with the shipping of an improved Beacon in terms of the cover, so that the battery replacement is easier. Alongside the product development they established a remarkable online community, where they share they re immense knowledge about ibeacons. Besides to their online presence, they installed Beacons at numerous places in Europe and even the US. [31] 3.2 Gimbal Gimbal was founded by Qualcomm, a worldwide, stock listed operating company. End of 2013 Qualcomm announced that it s subsidiary, Qualcomm Retail Solutions Inc. has released its Gimbal proximity Beacons to the public. Qualcomm Retail Solutions strategy is to empowering brands to take mobile engagement with their customers to a whole new level through micro-location [57]. Gimbal Beacon provides solutions for location services for venues, retailers, advertisers and also for individual platforms. Further they have implemented a sophisticated security approach, which makes it almost impossible for third parties to piggyback they re Beacons. [57] In 2016 Gimbal launched a test in cooperation with Citibank in the US where customers approaching they re branches out of office hours, the doors automatically open. As long as the customer has the Citibank App installed on his smart phone and the detection of the 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 format AltBeacon. The company s headquarters are in Washington DC. in the US. They re business is development and distribution of a Beacon product, named AltBeacon. A proximity Beacon that supports multiple Beacon formats. E.g., it supports the ibeacon and

28 18 CHAPTER 3. VENDOR COMPARISON Eddystone as well. Furthermore they offer a full-stack managed service for proximity technologies and services installation. They provide a campaign and proximity kit which is ready to be use within their cloud-based provided service. Campaign kit offers administrators 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 Estimote they 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 hindered to navigate within public areas. They also - like most other vendors - have a Beacon product; called the Kontakt.io Beacon. Which can be bought in different versions; a smart Beacon, a thought Beacon that is optimized for outdoor usage and a cloud Beacon which can connect to WiFi networks and scan for WiFi devices. They provide a deeper product range 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 provide a 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 identify their strengths and weaknesses, in order to simplify the process of selecting an optimal Beacon vendor for a specific use case. Furthermore a selection matrix will be developed to simplify the selection process of Beacon vendors. For this thesis the matrix will be applied to determine the optimal Beacon vendor used for the ios prototype developed in this thesis. Four dimensions are being defined, which will be used to analyze the vendors. Those dimension have been chosen based on the collected knowledge gathered at the research phase. 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 for available, an 2 for partially available and 1 for not available.

29 3.5. COMPARISON DIMENSIONS Sufficient documentation A sufficient, detailed and complete documentation is key for a swift integration of the vendors providing SDK integration for an existing smart phone application. Therefore the overall explanation profoundness as well as the documentation structure needs to be sufficient in order to guarantee a smooth integration by administrators. According to 3.1 the vendor with the most favorable relative documentation is Estimote because of the highest summative average of Gimbal Kontakt.io Radius Network Estimote In-depth detailed installation instructions for SDK In-depth detailed documentation for beacon management Available documentation for general beacon understanding (ranging/monitoring) Support responsiveness and competency Summative average Table 3.1: Documentation features provided by vendor Estimote and Kontakt.io provide a detailed, good structured and comprehensive in-depth installation instruction for the SDK integration. Both have tutorials based on the programming language Swift [21] and Objective-C [54] in contrast to Radius Network and Gimbal who only provide Objective-C tutorials. Gimbals SDK documentation is not up-to date and they do not provide CocoaPods integration [8], where the other Beacon vendors do. The documentation for Gimbal is not satisfying at all in terms of structure. They re documentation does not provide any kind of search functionality or consistent flow. However, Gimbals documentation is very detailed, explaining many functionalities, how they work and what prerequisites are required. For example to detect the dwelling time of an end-user, a specific package is required to be installed on the Beacon. Unfortunately the overall documentation is hidden and not transparently available E.g., on the homepage. Estimote and Kontakt.io further established an active community, dealing with ios specific Beacon configuration issues. For example they explain how to surpass the ios specific limit of defining only 20 regions. The community with Estimote has developed a large knowledge base for the general Beacon understanding. Gimbal does not have any. Kontakt.io and Radius Network have sufficient Blogs. All vendors provide a very good and fast support responsiveness. On average an answer within 48 Hours is realistic. So the Support responsiveness and competency value for all vendors 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 comprehensible documentation.

30 20 CHAPTER 3. VENDOR COMPARISON Security features A traditional Beacon setting does not have any mechanism integrated to prevent piggybacking, hijacking or physically capturing Beacon. Most use cases do not require a secure implementation. Though if an approach will be used E.g., for an end-user payment transaction 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 / vendor is crucial for the due diligence process selecting a vendor. Therefore provided security settings for each Beacon vendor needs to be identified. Especially approaches like UUID rotation, MAC rotation, Major/Minor rotation and prevention of piggybacking, hijacking and physically capturing a Beacon explained in Chapter 2.3. Those approaches provide solutions in order to increase the immunity of Beacon networks. Gimbal Kontakt.io Radius Network Estimote UUID rotation Prevent piggybacking Prevent hijacking Prevent physically capturing a beacon Summative average Table 3.2: Vendor provided security features The investigated vendors cover the security features as pointed out in Table 3.2. Although Gimbal does not provide a full coverage of all security approaches in Table 3.2, they still have the most incomprehensible security implementation of all analyzed vendors. First, the exact security approach is not disclosed. Gimbal does not state any details on their website, neither they reveal any details requested by . According to conducted tests, a Gimbal Beacon broadcasts a different UUID every Second. An Estimote or Kontakt.io Beacon 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 UUID every Second, and there is no rotating pattern observable. Since every App can only scan for a maximum of 20 different UUID s, and there is still no pattern observable within 30 UUID s fetched from a Gimbal device, meaning the Gimbal Beacon must somehow send out fake and pure UUID s mixed up. Those faked UUID s are probably generated based on an internal algorithm. How this exactly looks like and how it interrogates with the Beacon and SDK is unknown. The Gimbal Beacon uses 4 AA batteries to be powered and leasts about 18 months, which is much more compared to other vendors who only need 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 requirements. They are, however not as secure as Gimbal is, but for most use cases they probably suffice. That s why Kontakt.io and Estimote get a value of 2 on piggybacking and hijacking prevention in Table 3.2. Radius Network does not provide any kind of security implementation. However, they provide a Beacon that can be edited remotely only. Thus it cannot be edited using BLE,

31 3.5. COMPARISON DIMENSIONS 21 only if its connected with a wire to the personal computer. Which means this Beacon cannot be hijacked by a third party user. If a high-end security approach is not required, either Kontakt.io or Estimote would be a good approach. They provide an adequate security implementation which is sufficient for most use cases. However, if security is a deal killer, Gimbal is the best approach Cloud based Beacon management Every vendor provides specific functionalities and services to improve the Beacon management ease of use in their cloud based SaaS (Software as a Service) solutions. Among vendors, those solutions can differ in functionalities and specialization. Therefore it s supportive in order to select the optimal vendor, to compare and identify the functionalities and specializations among vendors (see Table 3.3). It would have burst this thesis scope, if all available functions and services of the SaaS solutions would have been taken into account. Hence only a few - the one most important in my opinion - have been selected. Gimbal Kontakt.io Radius Network Estimote Configurable templates Geofencing available Beacon sharing Beacon bulk options available Supported Beacon formats single (2) dual (3) single (2) dual (3) (Eddystone and/or ibeacon) Notification of Beacon health status Remote Beacon management API access Summative average Table 3.3: Vendor provided SaaS services Preconfigured templates can be used by administrators to bootstrap a specific use case fast, E.g., end-user notification on entering a shop. Templates reduce the complexity and setup-costs for the administrator, because there is less configuration needed. They also decrease the generics, meaning that an administrator can configure individual specialized use cases. Gimbal and Radius Network provide preconfigured templates. Radius Network supports a complete campaign kit, where administrators can define Regions at which end-users will be notified if they enter the Region. Administrators can add the notification text, which will be displayed on the end-users smart phone on entering the Region. For example a campaign is created in order to notify end-users approaching the physical shop, that the arrival of the new summer collection has arrived. If the Radius Network SDK is integrated in 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.

32 22 CHAPTER 3. VENDOR COMPARISON 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 an APN can, for example be sent to the end-users device after a predefined dwelling time of the end-user has passed or a defined RSSI value has been reached. Kontakt.io and Estimote do not support Preconfigured templates. Gimbal, Radius Network and Estimote can define GPS based areas based on longitude and latitude. These are so called Geofences - regions defined on latitude and longitude pairs. Despite Geofencing is not as accurate as the Beacon approach, it s still a good opportunity to increase the amount of regions available per App. In theory it s possible to dynamically change the 20 Regions defined in the App source code, depending in which Geofence the end-user remains. Sharing of Beacons between user accounts of the same vendor is possible with Kontakt.io and 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.io and Estimote. Kontakt.io provides more detailed functionalities of bulk options, especially on the part of importing Beacon data than Estimote. Gimbal offers it, but only by creating a support ticket. Radius Network does not support bulk options neither Beacon sharing among users. According to a release by Kontakt.io it is possible that a Beacon broadcasts the ibeacon or Eddystone formats in dual (concurrent) mode [48]. This makes it theoretically possible, to use the Eddystone concept with Apple smart phone. The Eddystone Beacon format can only be discovered while an Apple smart phone is Ranging, which means either the end-user must have started the Ranging manually or the smart phone must have detected a Region. But only an ibeacon format can be detected by Apple smart phones in Background-mode. Thus to detect a Region, a Beacon emitting an ibeacon format must 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 the Eddystone 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 displays the battery status but does not notify the administrator on a critical battery nor shows the last time the Beacon battery status was fetched from the device. Kontakt.io provides setting up a personalized Push Notification service in order to notify the administrator if the battery status of a Beacon goes below a defined boundary. With Radius Network the user can define notifications if the battery level drops a specified threshold or the Beacon was not seen for certain amount of days, which makes it the most flexible approach for Beacon notifications among all vendors. Radius Network further offers a Beacon that can be managed remotely, which means the settings on the Beacon can be edited without the need of a smart phone in its proximity or a running personal computer the Beacon is attached to. Kontakt.io has released a USB Beacon dongle that can be updated if the personal computer is connected and dedicated software is installed. Furthermore they sell a Cloud Beacon which is able to connect with a WiFi network by itself in order to get updated remotely. All four vendors provide a RESTful API endpoint to manage Beacons, venues and more using an API.

33 3.6. SELECTION MATRIX Scalability support To provide a sustainable growth with a selected Beacon vendor it s necessary to elaborate the scalability availability of the respective vendor. In this section the cost factors of the investigated vendors will be especially reviewed. Table 3.4 points out the cost structure of the examined vendors. Administrators need to pay USD to to purchase a Beacon. The price per Beacon usually depends on its embedded hardware. Beacons with integrated sensors are more expensive than simple Beacons with no extraordinary hardware. Gimbal and Radius Network monthly fees are relatively high. Radius Network does not provide a plan with more than 25 Beacons installed [59]. Which does not allow administrators to scale their Beacon network. Important to notice is the limitation of so called Active Installs mentioned on the website [59]. For example if there are 5000 Active Installs available for a specific plan, only 5000 smart phone end-users can be detected by Beacon per month. The monthly fees of USD 9.00 and USD are relatively high compared to, for example Gimbal. Gimbals service is free to use below 49 installed Beacons or more than 5000 Active Installs [40]. The explicit fees incur are not mentioned on the website. Radius Network limits the amount of Active Installs to whereas Gimbal has no limitation, this makes the Gimbal fee system more scalable in contrast to Radius Network and thus Gimbal got a value of 3 and Radius Network of 2. Gimbal Kontakt.io Radius Network Estimote Monthly fees Scalable fees Initial fees Initial price USD USD USD USD Summative average Table 3.4: Vendor provided scalability factors Kontakt.io and Eddystone do not have any recurring monthly fees. This makes them very attractive in therms of scalability so they both get a value of Selection matrix In order to simplify the selection process of the Beacon vendor, the vendor comparison has been conducted. The result of it is a selection matrix based on the determined results of each dimension compared among the vendors in Section 3.5. Table 3.5 indicates the evaluated dimension value relative to the vendors. For example Estimote has a value of 2.75 in the dimension of Sufficient documentation, wich is the highest relative value within this dimension. So if a company starts a Beacon project but has limited knowledge with Beacon technology, it should stick to the vendor with the most sufficient documentation; Estimote.

34 24 CHAPTER 3. VENDOR COMPARISON Sufficient Security Cloud based Beacon Scalability documentation features management support Gimbal Kontakt.io Radius Network Estimote Table 3.5: Selection matrix: Weighted vendors relative to dimensions In most cases, a use case weights the four dimensions differently. For example, a specific use case, where customers will be payed automatically, if they enter a specific proximity area, E.g., a train. So the customers bank account will be automatically deducted as soon as he enters the proximity area of the Beacon. This implies, that piggybacking of Beacons is a serious thread. So Security features will be weighted with 4. Due to the fact, the the company implementing the Beacon network has already gained a lot of know-how, the Sufficient documentation will be weighted with 1. The Cloud based Beacon management will be weighted with 2 because the company needs customized notifications and a remote Beacon management in order to get notified if Beacons don t work properly anymore and train guests stop getting billed accordingly. Because the project is a market validation only 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 of Table 3.5 and the weighting factor of Table 3.6 on the dimension Security features. For example the value 10 is the product of 2.50 and 4. The average weight displayed in the last column, is the average of all dimensions for the specific vendor. Sufficient Security Cloud based Scalability Avg. documentation features Beacon support weight management Weighting factor Gimbal Kontakt.io Radius Network Estimote 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 to be selected for this use case. This makes sense, because our use case deals with important security aspects, that need to be covered. Vendor selection In this thesis a Beacon vendor is required in order to conduct tests and optimize the architectual 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 is no need in giving them a specific weighting factor.

35 3.6. SELECTION MATRIX 25 Sufficient Security Cloud based Scalability Avg. documentation features Beacon support weight management Weighting factor Gimbal Kontakt.io Radius Network Estimote Table 3.7: Selection matrix: Thesis vendor selection Table 3.7 states, that the vendor with the highest total average weight value is Kontakt.io with So for this thesis the Kontakt.io Beacons are selected in order to test and verify our architectural approach.

36 Chapter 4 Architectural Beacon design This chapter explains the purpose of an architectural design within this thesis and will provide a specific architectural design solution based on a Beacon network. In order to create a Beacon network, the arrangement of Beacons is crucial so that the detection reliability of the end-user can be optimized. The architectural design will define, how the Beacons need to be arranged, facilitating an optimized detection reliability. This thesis will identify the optimized beacon arrangement for specific use cases. At first an architectural design is developed by support of a developed prototype. The prototype supports optimizing the Beacon setting. Subsequently it will be used to verify the architectural design. 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 to define a set of use cases need to be covered beforehand, so that a designated architectural design can be developed. The use cases define constraints the architectural design is based on. 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 just pass it. Therefor it needs to be distinguished, if the end-user enters or just passes by the venue. Entering the venue will generate a successful enter event, whereas a passing in front 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 to distinguish between walk-by and walk-in customers. If for example most of the customers do not enter he might need to consider adding some attractive discounts in his shop window in order to animate customers to enter his shop. 26

37 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 has no 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 the proximity of the Beacon. Moreover the direction of the end-user E.g., if he s passing the Ad-poster from left to right or from right to left, needs to be determined. Furthermore it ll be investigated, if there exists a possible solution to identify if the end-user is actually looking 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 Beacon detection, testing and validation is required. There is no confidence, that Beacon Figure 4.1: Explanation of architectural design visualization

38 28 CHAPTER 4. ARCHITECTURAL BEACON DESIGN networks do not suffer from interferences, which can deform results. To provide a sufficient result, an iterative approach is chosen. A first architectural design is developed and subsequently revised and validated. The insights gained will be applied to develop another architectural design in a subsequent iteration. To visualize the complex architectural design of a Beacon network in detail, a graphical simplification is used for abstraction. On Figure 4.1 the venue (square box) and the Beacon proximity is shown from a top-down view. The dotted circle represents the Beacon emitted signal and shows the proximity area in form of a circle. Please note, that this is an abstraction of the reality. In reality, the signal edge is not a perfect circle. In context of this 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 the Beacon 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 and Major. On Figure 4.1 the Region is defined using only a UUID (UUID is 1). The Major and Minor in curly brackets will only be detected, using Ranging. The following subchapters will apply the explained setting on Figure 4.1 in order to visualize the architectural design. They ll further show the progress of developing an optimized solution. The prototype used has been developed explicitly for this thesis 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 is developed, using a ViewController class providing all relevant delegate function required by the CoreLocation [9] framework. The delegate functions will be triggered if the smart phone enters or exits a Region, that has been defined in the source code. Regions are defined using a CLBeaconRegion object provided by the CoreLocation framework. See Listing 4.1 where the UUID and Major are allocated to the respective variables on line one 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 the UUID and the Major are used. On line ten a function of the _locationmanager is called in order to start Monitoring for the subsequent defined Region. Listing 4.1: Source: Define a Beacon Region and start Monitoring 1 NSString uuid 2F CF6D 4A0f ADf2 F4911BA9FFA6" ; 2 NSString i d e n t i f i e r Region i d e n t i f i e r " ; 3 NSInteger major = 1 ; 4 5 CLBeaconRegion _beaconregion = [ [ CLBeaconRegion a l l o c ] 6 i n i t W i t h P r o x i m i t y U U I D : [ [ NSUUID a l l o c ] i n i t W i t h U U I D S t r i n g : uuid ] 7 major : major 8 i d e n t i f i e r : i d e n t i f i e r ] ;

39 4.2. ARCHITECTURAL DESIGN DEVELOPMENT [ _locationmanager 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 the iterative process of finding the optimized architectural design, the prototype requires various functionalities as well as a server with a persistent database to store collected data 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 useful information for testing the Beacon settings, a few additional integrations beside the Beacon 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 need to be displayed on the smart phone every time the end-user enters or exits a proximity region in Background- or Foreground-mode. Further, the prototype is required to provide an automatically updating Beacon detection log, displaying the Beacons currently in proximity and the received signal strength of the Beacon in RSSI. Figure 4.2 shows the prototype with the detection log. The list updates automatically every second. A line consists of the exact date and time, the Major, Minor and the RSSI value. The log provides real time information of Beacons within the smart phones proximity. This supports the process of evaluation, where the optimal position of a Beacon is, in order to achieve a reliable detection. Further the prototype needs a technical interface to a persistent server for the purpose

40 30 CHAPTER 4. ARCHITECTURAL BEACON DESIGN of storing the log-data, while receiving proximity data in Background-mode. Therefor a server 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 required for the detection of Beacons. However, user authorization, notification and remote HTTP calls as well as GUI functionalities are omitted to sustain clarity. The first function with the 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 to define the delegate class on line four. Later on it will initiate the Monitoring by triggering the startmonitoringforregion function passing the beaconregion as parameter. 1 ( v o i d ) viewdidload 2 { Listing 4.2: Objective-C code for Beacon detection 3 _locationmanager = [ [ CLLocationManager a l l o c ] i n i t ] ; 4 _locationmanager. d e l e g a t e = s e l f ; 5 6 CLBeaconRegion beaconregion = [ [ CLBeaconRegion a l l o c ] 7 i n i t W i t h P r o x i m i t y U U I D : [ [ NSUUID a l l o c ] i n i t W i t h U U I D S t r i n g Region 1 " ] 8 i d e n t i f i e r f7826da6 4fa2 4e bc5b71e0893e " ] ; 9 10 [ _locationmanager 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 } ( v o i d ) l o c a t i o n M a n a g e r : ( CLLocationManager ) manager 14 didrangebeacons : ( NSArray ) beacons 15 i n R e g i o n : ( CLBeaconRegion ) r e g i o n 16 { 17 // Get s c a l l e d i f Ranging d e t e c t e d beacons 18 } ( v o i d ) l o c a t i o n M a n a g e r : ( CLLocationManager ) manager 21 d i d E n t e r R e g i o n : ( CLRegion ) r e g i o n 22 { 23 // Get s c a l l e d i f smart phone e n t e r r e g i o n [ _locationmanager s t a r t R a n g i n g B e a c o n s I n R e g i o n : ( CLBeaconRegion ) r e g i o n ] ; 26 } ( v o i d ) l o c a t i o n M a n a g e r : ( CLLocationManager ) manager 29 d i d E x i t R e g i o n : ( CLRegion ) r e g i o n 30 { 31 // Get s c a l l e d i f smart phone e x i t r e g i o n [ _locationmanager s toprangingbeaconsinregion : ( CLBeaconRegion ) r e g i o n ] ; 34 } As soon as the end-user has physically entered the proximity area of a Beacon, and the Beacon emits the Region which is defined in the _locationmanager, a didenterregion

41 4.2. ARCHITECTURAL DESIGN DEVELOPMENT 31 call will be triggered on line 20 ff.. The function calls startrangingbeaconsinregion in order to initiate the Ranging process. If the App is in Background-mode and there is no background task configured, Ranging leasts for about ten Seconds before it stops. In this code outline, no background task is defined. During Ranging, all Beacons within the proximity of the smart phone will be detected and passed as an NSArray on the function didrangebeacons on line 13. Beside the detected Beacons, also the detected Region is passed. If the end-user leaves the proximity area of the Beacon and therefore also the Region, the didexitregion function is triggered. Server-side database On the server-side a PHP framework called Lumen [56] is used, to bootstrap the entire application providing basic processing logic of the requests. A MySQL database and a small API to fetch the HTTP calls from the prototype. The PHP based application runs on a cloud-based Ubuntu server with an installed LEMP-stack [52]. The source code of the application is provided in appendix A. Real world setting To properly test the defined use cases an essential setting is required. In order to simulate a 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 the testing and field study. Their office is based on a street with obstacles and can be used to simulated the use cases. Limited region monitoring The maximum global number of Regions that can be monitored in Background-mode on an Apple ios smart phone are limited. There is no official statement from Apple concerning the 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 best effort group defined. For the Regions defined in the Priority Group, didenterregion will be triggered almost immediately after the end-user entered the Region. Regions that are defined in the Best effort Group can lead to a long delay or even never trigger a didenterregion. Though the end-user is clearly within the Beacon proximity. According to tests by [61], the Priority Group can scan up to 30 regions at a time. So if two installed applications on an Apple ios smart phone respectively register 20 Regions, some Regions will be added into the Best effort Group and therefore their didenterregion will not be triggered immediate.

42 32 CHAPTER 4. ARCHITECTURAL BEACON DESIGN Iterative development The field study consists of two slightly different real world use cases. They are designed to simulate the Beacon detection at a small city shop and at an Ad-poster venue. They are described in detail in Chapter 4.1. The following section describes the iterative development of the architectural design for both use cases. Beforehand, requirements for each use case are defined, which need to be fulfilled by the final architectural design. The design is developed, applying a two- or three-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 or enters the venue, it requires to detect the end-users movement. If this will be achieved using 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 provide scalability in setup and expansion, a simple setup of the Beacon hardware is assumed and a 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 configuration work. For example simple Beacon configuration in terms of signal strength and defining optimal location to place it. Minimize performance impact requires to develop an energy optimized design in order to preserve energy, especially for running tasks in Background-mode. Scalable design provides an architectural design ensuring subsequent expansion without major limitations. Like for example a design that cannot define more than 20 different venues. Optimize detection reliability distinguishes walk-in s and walk-by s of venues. Administrators are eager to detect the rate of end-users entering the venue if extra stimulus has been installed in order to attract them to enter the venue.

43 4.2. ARCHITECTURAL DESIGN DEVELOPMENT 33 First iteration Figure 4.3: Design development: First iteration In an initial setting, a basic architectural design is presented, which covers the simplicity requirement. The Beacon positions are defined by the architectural design and all three Beacons have the same signal strength, which requires only one Beacon to be configured and validated. The following two can be duplicated based on the first one in therms of configuration. In Figure 4.3 two venues are pictured in a top-down view. A venue for example, can be a shop in the city selling products. Venues are marked by a solid line indicating the edge. The line is interrupted by a rectangle showing the door. Inside of the venue, there are three dotted circles. Every circle has a smaller, gray circle inside. The inner circle symbolizes the location of the Beacon. In this setting, three Beacons are present within one venue. The dotted bigger circle indicates roughly the border of the Beacon signal. The numbers below the grey circle represent the Beacon broadcasting information. On Figure 4.3 the Region is defined using only the UUID, 1 at Venue 1 and 2 at Venue 2. Thus the Major and Minor values are not used to define the Region and will not be 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, the nearest Beacon to the end-suer can be determined, by detecting the Minor value. Thus the approximate location of the end-user can be estimated as well. Unfortunately providing scalability with this design is not possible. Since a region needs to 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

44 34 CHAPTER 4. ARCHITECTURAL BEACON DESIGN 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 can be detected. Leading to the second iteration, which will provide solutions to some of the identified problems determined in the First iteration. Second iteration A problem addressed at the First iteration that end-users passing the venue are not detected 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 weather conditions, which can result Beacons damaged caused by water. Therefor it s preferred to install the Beacon close by the main entry door in a dry place in order to reduce the exposure of environmental impacts. The three Beacons placed inside of the venue are used to detect the end-users movement indoors. All four Beacons of Venue 1 define one Region 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 passing pedestrians. So this setting can distinguish between walk-by s and walk-in s. In order to achieve a sufficient detection reliability, every Beacon placed outside defines a Region for

45 4.2. ARCHITECTURAL DESIGN DEVELOPMENT 35 each venue. On Figure 4.4 Venue 1 defines the Region 1 and Venue 2 defines the Region 2. Hence only a maximum of 20 venues can be defined applying this design which does not fulfill the Scalable design requirement. However, the design does cover the Optimize detection reliability and the Simple Setup requirement. Final iteration Based on the findings of the First iteration and Second iteration, the Final iteration is developed. In order to provide the differentiation of walk-by s and walk-in s, the outside placed Beacon will be added again. To provide a Scalable design, this setting in Figure 4.5 has a slightly different approach comparing the Second iteration, in terms of the definition of Regions. Every venue (E.g., 1, 2, 3,...) defines two distinct, but beyond all identical regions. For example Venue 1 defines two Regions: 1 and 2. Region 1 is defined by the outside Beacon. Region 2 is defined using the three inside Beacons. This specific approach provides scalability for the design. Because the design requires to define only two distinct Regions for all venues defined. To identify the venue, the Major value is required to be detected by the smart phone during Ranging. This happens as soon as Monitoring identified Region 1 or 2 and starts with Ranging. Thus, approximately up to 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-

46 36 CHAPTER 4. ARCHITECTURAL BEACON DESIGN in s are being detected and can be distinguished. So the requirement Simple setup and Optiomize detection reliability is provided. In order to Minimize performance impact the design will use a dynamic adaption of the ranging time in the Background-mode based on the detected end-users distance to the Beacon. 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 smart phone 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 fetch location based end-user data only if it s necessary and the high energy consumption of executed 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 for the Optimize detection reliability use case. Optimize detection reliability in order to determine, if an end-user is passing the Ad from left to right or right to left and if it s possible to identify, if the end-user is looking at the Ad or just passing. Based on the findings regarding UC A, most of them can be adopted on UC B in order to provide a Scalable design. Figure 4.6 visualizes the Ad-poster in a top-down view as a rectangular box. It has a Beacon installed in the center on the top of the box. The Beacon signal edge is visualized by the dotted line. The red and blue line illustrate a possible user movement passing the Ad-poster. First iteration The Region is defined by the UUID. Major and Minor are used to detect the venue. Just as designed in UC A, this approach allows to define up to venues by using only one region. This ensures a Scalable design. The setup, configuration and installation of the Beacon is simple and does not require any additional configuration work. So this design does also fulfill a Simple setup.

47 4.2. ARCHITECTURAL DESIGN DEVELOPMENT 37 Figure 4.6: Architecture design: First iteration Concerning the Optimize detection reliability, there has no possibility been identified in order to determine if the end-user moves from left to right or right to left. Thus the design needs 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 needs to be detected. In order to make this possible, a second Beacon has been added to the Ad-poster. Figure 4.7: Architecture design: Final iteration

48 38 CHAPTER 4. ARCHITECTURAL BEACON DESIGN 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 overlapping, 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 only detected with Ranging. Region 1 is detected with Monitoring. The Minor value is used to identify the Beacon, denoting if the left or right Beacon is detected. In order to determine the 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 approach in order to identify if an end-user does look at the Ad-poster or not. It is, however possible to use the CoreLocation framework of Apple ios in order to get the end-users heading [14]. Though determining the heading is mostly only achievable if the smart phone points in the specific direction - which is mostly not the case if the smart phone is within the end-users pocket. To Minimize performance impact the same approach will be applied as described in UC A, 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-users passing behind the Ad will also be detected. But will not have seen the Ad. Therefor an approach of a directional signal propagation has been developed. In order to direct the Beacon signal in a specific direction, aluminium foil was placed around the Beacon to shield the signal. Hence the Beacon was wrapped into aluminium foil and a small hole was left open. Figure 4.8: Funnel shielding Beacon signal Figure 4.8 shows the Beacon wrapped in aluminium foil with funnel pointing up. This means, the front of the Beacon is pointing up. When approaching the funnel from the

49 4.2. ARCHITECTURAL DESIGN DEVELOPMENT 39 back side of the funnel and using a signal strength of -30dBm the Beacon is detected in a distance of about 25 centimeters. However, swiping the funnel to point in the other direction leads to a signal detection of approximately 30 centimeters away. Despite without any shielding the signal will be detected in 5 meters distance. Adding the aluminium foil around the Beacon leads to a high decrease in the overall signal strength. Also if the end-user is standing in front and the funnel pointing at him. Moreover, the difference in signal strength between the front and the back of the funnel results in Design validation In order to validation the architectural design in a real world setting, a field study is conducted. The prototype explained in Chapter is used to validate the architectural design developed in Chapter Figure 4.9: Venue used: Shop and Ad-poster The field study is conducted, using two different approaches of venues. Related to the architectural design decision in Chapter one field study is addressed where an enduser 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 architectural designs developed for the use cases. In order to distinguish the end-users direction and if there 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 setting in contrast to existing shops, which might be used to apply the setting. See Figure 4.9 showing a picture of the venue used. Both use cases have been conducted, using this