Prototype System for Beacon Detection

In order to better understand the influence of latencies induced by the iOS operating system libraries and background location tracking tasks for the detection of nearby BLE beacons (iBeacons), we designed and conducted a controlled experiment. We utilised a controllable BLE iBeacon that provided us with the ability to accurately control the Bluetooth transmission start and end times. As a mobile device, we utilised an iPhone 6 as one of the most common mobile devices and a prototype mobile application implementing the following two distinct beacon detection mechanisms:

Monitoring: Core Location Framework Apple provides with the Core Location Frame- work the ability tomonitorfor the proximity of BLE beacons in the background, i.e.

6.3 Tacita: Client-based Tracking 136

with the mobile device in standby. In accordance to the Apple Developer Guidelines, a maximum of 20 beacons (a tuple of beacon major, minor and unique identifiers) can be registered for background location tracking – limiting the total number of supported beacons presumably to protect the resources of the user’s mobile device. The developer is only required to implement handlers for beacon entry and exit events which are called by the operating system. Fine-grained controls over the tracking frequency are not possible. We note that for beacon detection, Apple describes the Core Location Framework as the recommended implementation way – however, it requires the user to permit ‘background location tracking’ for the mobile application utilising this frame- work. The Core Location Framework also represents the technique used in the Tacita Mobile Client. We note that in the subsequent sections we refer to this technique as

monitoring.

Ranging: Core Bluetooth Framework The Core Bluetooth Framework allows develop- ers torangefor proximate Bluetooth devices – including BLE beacons. This method requires the device and the application using this technique to be active and in the foreground. In contrast to monitoring, using the Core Bluetooth Framework allows the specification of ranging frequencies and therefore provides us with the ability to develop custom entry and detection algorithms. We note that the subsequent sections we refer to this technique asranging.

We captured timestamps on the machine running the controllable beacon of the trans- mission start and end, and on the mobile device client of the subsequent beacon entry end exit detection events that were transmitted to a virtual Trusted Content Provider for logging purposes. Both the mobile device and Trusted Content Provider were located on the same local area network minimising network-related transmission delays. We performed 10 repetitions for beacon entry and exit detection each. For the monitoring mode, we compare two states of the mobile device: active (i.e. with the screen turned on and the phone unlocked) and inactive (i.e. with the screen turned off and the mobile device on standby). For the ranging mode, we only use the mobile device in active mode as active ranging in background is not permitted as per iOS developer guidelines.

Upon determining the latencies of beacon detection times on the mobile device, we designed a follow-up experiment in a realistic setting investigating the influence of physical layouts on the transmission and detection accuracy. We designed the experiment based on the typical walk-by scenarios in which the content needs to change in time for the viewer before passing by the display and therefore allowing to capture accurate analytics in a timely manner. We performed this experiment by identifying a representative display deployment within the e-Campus displays network. The display was equipped with a single BLE beacon, and typical hardware (Mac Mini late 2014, Intel Core i5 processor with 2.6 Ghz, 8GB memory and macOS 10.10.3), and the experimenter equipped with the similar prototype application and mobile device described previously. The display was located in the foyer area of an office

6.3 Tacita: Client-based Tracking 137

(a)Picture of the experimentation area annotated with the three routes.

Reception and Storage

a

b

c

(b)Layout (not to scale).

Figure 6.6:Floor plan of the controlled walk-by experiments to capture beacon entry and exit detection latencies (initially published in [Mik+18d]).

6.3 Tacita: Client-based Tracking 138

Table 6.2:Median, mean and standard deviation for enter region (beacon detected) and exit region (beacon lost) events (seconds). We note that the ranging functionality in iOS is only available with the phone inactivestate (initially published in [Mik+18d]).

Enter Region Exit Region

Condition Phone State Median Mean SD Median Mean SD

Monitoring standby 2.0 3.11 2.48 29.25 28.73 2.01

Monitoring active 0.57 0.88 0.84 30.05 29.78 0.86

Ranging active 0.73 0.71 0.30 10.37 10.33 0.27

building (Figure6.6). As shown in Figure6.6, we identified three typical ways in which viewers approach and pass by the display:

(A) The viewer approaches the display from upstairs through an open staircase introducing the difficulty of detecting the viewer as passing through floors,

(B) The viewer walks towards the display on the same floor – representing the most common form of walk-by personalisation in our display deployment, and

(C) The viewer walks towards the display on the same floor from a starting point that is separated from the display through a concrete wall.

We conducted walk-by experiments using our prototype application (i.e. capturing in- sights for both ranging- and monitoring-based detection techniques), capturing the following timestamps:

1. the viewer entering the viewable area of the display, i.e. the first opportunity the display can be seen (visualised in yellow in Figure6.6),

2. the mobile device detecting the proximate beacon (entry event), i.e. the earliest time at which the system is able to react to the viewer,

3. the viewer leaving the viewable area of the display, and

4. the mobile device detecting that the viewer has left the proximity to a beacon (exit event).

For each of the three routes, we conducted 10 repetitions with the mobile device in active mode enabling both ranging and monitoring and ensuring that a WiFi connection was established at all times.