Institutionen för datavetenskapDepartment of Computer and Information Science

Final thesis

Bluetooth Low Energy and Smartphones for Proximity-Based Automatic Door Locks

by

Tim Andersson

LIU-IDA/LITH-EX-G--14/050—SE

2014-06-08

Linköpings universitetSE-581 83 Linköping, Sweden

Linköpings universitet581 83 Linköping

Final thesis

Bluetooth Low Energy and Smartphones for Proximity-Based Automatic Door Locks

by

Tim Andersson

LIU-IDA/LITH-EX-G--14/050—SE

2014-06-08

Supervisor: Peter DaleniusExaminer: Johan Åberg

Linköpings universitetDepartment of Computer and Information Science

Bluetooth Low Energy and Smartphones forProximity-Based Automatic Door Locks

Tim Andersson

Studievagen 5 lgh 140558329, Linkoping, Sweden

tim@ndersson.me

ABSTRACTBluetooth Low Energy is becoming increasingly popular inmobile applications due to the possibility of using it for prox-imity data. Proximity can be estimated by measuring thestrength of the Bluetooth signal, and actions can then be per-formed based on a user’s proximity to a certain location orobject. One of the most interesting applications of proximityinformation is automating common tasks; this paper evaluatesBluetooth Low Energy in the context of using smartphones toautomatically unlock a door when a user approaches the door.Measurements were performed to determine signal strengthreliability, energy consumption and connection latency. Theresults show that Bluetooth Low Energy is a suitable technol-ogy for proximity-based door locks despite the large variancein signal strength.

INTRODUCTIONBluetooth Low Energy (BLE) is a relatively new technol-ogy, originally released by Nokia in 2006 under the nameWibree. In 2007, the Bluetooth Special Interest Group (SIG)announced that the Wibree Forum would be merged with theBluetooth SIG and that the Wibree specification would be-come part of the Bluetooth Core Specification Version 4.0 aswhat is today known as Bluetooth Low Energy [14]. Thelow power consumption of the BLE technology and its abil-ity to connect to smartphones makes it especially suitable forlow power sensor devices such as heart rate monitors, cyclingcomputers and thermometers [4]. It is also a suitable tech-nology for use in so called Smart Homes as it communicatesusing radio transmissions in the 2.4 - 2.485 GHz band [3]. Asa result, Bluetooth Low Energy does not suffer from the samedrawbacks as other technologies used in the home, e.g. in-frared (IR) remote controls which require line of sight to thedevice that is being controlled.

An interesting result of the fact that Bluetooth uses radiowaves for transmission is that a signal strength can be cal-culated. Using the signal strength, it should be possible toestimate the proximity between two Bluetooth devices. Thefact that it might be possible forms the basis of this thesis.

MotivationThe market for applications using Bluetooth Low Energy isconstantly growing. The Bluetooth SIG expects that by theyear 2018, more than 90 percent of all Bluetooth enabled de-vices will support Bluetooth Low Energy [11]. As more andmore smartphones gain support for Bluetooth Low Energy,

the possibilities of using the technology for new types of ap-plications increase. One of the possibilities is using BLE todetect proximity, which can then be used in a number of inter-esting areas; this paper will investigate one of them, namelyautomatic door locks.

PurposeThe aim of this thesis is to evaluate Bluetooth Low Energyas a technology by focusing on its use in door locks that au-tomatically unlock based on the proximity of a smartphone.This will be accomplished by examining different propertiesof Bluetooth and comparing the results to what can be foundin the literature. By implementing an application for a mobileoperating system, the thesis also aims to evaluate what possi-bilities and restrictions exist in using Bluetooth Low Energyon smartphones.

Research QuestionsFour questions have been formulated to aid in the evaluationof Bluetooth Low Energy. The first is a general question per-taining to how suitable of a technology BLE is for automaticdoor locks, while the remaining three are more concrete ques-tions which act as guidelines.

Is Bluetooth Low Energy a suitable technology for

proximity-based automatic door locks?

Is it possible to prevent the door from unlocking when a

person approaches the door from the inside? A securityissue may arise if the door unlocks whenever a person ap-proaches the door regardless of where the person is locatedrelative to it. It is not difficult to imagine several scenarioswhere a person would want to avoid unlocking the door auto-matically. One such scenario might be that an enraged personis trying to get through the door, in which case unlocking thedoor may result in direct danger to the person inside.The paper will discuss the possibility of solving this problemusing two Bluetooth devices located on either side of the door.

Does the implemented solution affect the smartphone’s

battery life negatively in a significant way? One of themain features of Bluetooth Low Energy is the low power con-sumption. As the implemented application is designed to runcontinuously in the background on a smartphone it is espe-cially important that it has a minimal effect on the batterylife. This paper measures the effect on battery life and com-pares the results to what can be expected based on theoreticaldata.

1

Is the Bluetooth Low Energy communication latency suf-

ficiently small to make the technology usable in practice?

The main benefit of having a door lock that automatically un-locks based on the user’s proximity is that it is more timeefficient for the user than unlocking the door manually. If im-plemented well it should be faster than Radio-frequency iden-tification (RFID) locks that are common in today’s world. Ifthere exists inherent latency in using Bluetooth Low Energy,this benefit might be lost. As such, it is essential that thelatency is sufficiently small to outperform other similar tech-nologies.

LimitationsThe paper will not discuss any security aspects related to theBluetooth communication.An application will only be implemented and evaluated forApple’s mobile operating system iOS and not for any othermobile operating system such as Android or Windows Phone.

BLUETOOTH LOW ENERGYA basic understanding of what Bluetooth Low Energy is andhow it works is required to fully understand this paper. Thissection will give a brief overview of the architecture of BLEand explain a few key concepts, such as BLE beacons. Itwill also cover what sets BLE apart from previous versionsof Bluetooth and how Bluetooth can be used on iOS.

Bluetooth Low Energy Compared to Classic BluetoothBluetooth Low Energy is optimized for devices that requiremaximum battery life instead of high data rates [1]. Whileprevious versions of Bluetooth are commonly used to trans-mit a lot of data such as files or audio, BLE is used to trans-mit small pieces of data such as temperature readings. Blue-tooth Low Energy was also designed to achieve much smallerlatencies in connecting and transferring data than in ClassicBluetooth.

ArchitectureBluetooth Low Energy devices can either have a central role,or a peripheral role. Devices with a central role are devicesthat consume data from devices with a peripheral role. Draw-ing a parallel to a client-server architecture, a central devicecan be compared to a client and a peripheral device to a server.In this paper, the smartphone is a central and the Estimotes(covered in the Beacons and iBeacon subsection) are periph-erals.In order for a peripheral to be discoverable, peripherals ad-vertise continuously by transmitting advertising packets at afixed interval (usually measured in milliseconds). They ad-vertise at all times even if no other Bluetooth device is inrange. To find a device, centrals scan for peripherals by lis-tening for the peripheral’s advertisement packets. After dis-covering a peripheral, the central can establish a connectionto the peripheral. If a connection is established, data can beread from the peripheral using the Generic Attribute Profile(GATT). All use cases do not require that a connection is es-tablished between a central and a peripheral since some data– such as the local device name and manufacturer specificdata – can be retrieved from the advertisement packets. A pe-ripheral is not permitted to have a connection to more than

one central at the same time [16], but a central may have con-nections to several peripherals at once. Peripherals do notadvertise during the period a connection exists between theperipheral and a central [16].

The Bluetooth Signal and RSSIThe Bluetooth Low Energy radio operates in the unlicensed2.4 GHz industrial, scientific and medical (ISM) band [16].BLE employs frequency hopping to minimize interferencefrom other technologies in the 2.4 GHz band [2], e.g. Wi-Fi. Despite this, interference can have a significant negativeeffect on the signal strength.

Received Signal Strength Indicator (RSSI) is a measurementof the power in a received radio signal. In Bluetooth LowEnergy, RSSI is measured in the logarithmic unit decibel-milliwatts (dBm) and has a range of �127 – +20 dBm withan accuracy of ± 6 dBm [16]. Since it is a measurement ofpower, a smaller RSSI indicates a weaker signal.RSSI will be used to determine the smartphones proximity tothe door.

A concept related to RSSI is Measured Power. MeasuredPower is the RSSI as measured by the device manufacturerat a distance of one meter and is used when determining theproximity to a device. Devices that support iBeacon (for moreinfo on iBeacon, see the next subsection) broadcast the mea-sured power in their advertising packets. Since an increasedRSSI can be the result of decreased distance to the device orincreased power to the transmitting antenna, Measured Poweris used to determine which of these has occurred.

Beacons and iBeaconBluetooth Low Energy beacons are small devices that otherBluetooth devices – such as smartphones – use for context-aware applications. The beacons advertise continuously andthe smartphones can use the received advertisements to esti-mate a proximity to the beacon.There are several third-party beacons available for purchase,such as the Estimote – seen in Figure 1 – and Kontakt bea-cons. In this thesis, two Estimote beacons are used.

Revealed alongside iOS 7, iBeacon is Apple’s trademarkedindoor positioning system built on top of Bluetooth Low En-ergy. Devices that support the iBeacon protocol are callediBeacons and advertise a particular Bluetooth Low Energy-payload [10]. If a device supports iBeacon, an iOS applica-tion can use Apple’s Core Location Objective-C frameworkto interact with the beacon.Both the Estimote and Kontakt beacons support iBeacon.

Bluetooth Low Energy on iOSWith the release of iOS 5 in 2012, Apple introduced theCore Bluetooth framework which enables developers tocommunicate with Bluetooth Low Energy devices [12]. TheCore Bluetooth framework is an abstraction over the BLEprotocol stack and hides many of the low-level details of thespecification, making it easier for developers [5].There are two key classes in Core Bluetooth: CBCentral-Manager and CBPeripheralManager. For an application thatneeds to act as a central and communicate with peripherals,

2

Figure 1. A purple Estimote, as seen from above. The ruler shows cen-

timeters.

the former class shall be used. Applications that function asBluetooth Low Energy peripherals and serve data to otherdevices use the latter class. Both classes use the delegationpattern that is commonly used in iOS frameworks. Asan example, assume an application’s AppController

class wants to be notified when a Bluetooth peripheral isdiscovered. To accomplish this, the AppController

creates an instance of CBCentralManager and setsitself as the delegate using CBCentralManager’sdelegate property. The AppController thentells the CBCentralManager to start scanning forperipherals. When the central manager discovers a periph-eral, it will notify the AppController by calling thecentralManager:didDiscoverPeripheral:

advertisementData:RSSI: instance methodon its delegate (i.e. the AppController). Thismethod and a few others are specified in theCBCentralManagerDelegate protocol.

Application States and Their Effect on Core BluetoothAn important thing to know is that an iOS application can bein different app states [9]. The relevant states for this thesisare as follows:

Active

The application is running in the foreground and is receiv-ing events.

Background

An application in the background state is still running andexecuting code, but is not visible to the user. Applicationsusually only enter this state briefly on their way to beingsuspended.

Suspended

The application is in the background but is not executingcode. A suspended application might be purged by the sys-tem if memory is needed.

This is important to understand since several restrictions re-garding the use of Bluetooth apply to applications that run in

the background, and the application implemented in this the-sis will spend almost all of its time in the background. The re-strictions include not being able to scan for peripherals that donot advertise any services, not being able to receive all adver-tising packets, and limiting the frequency at which the centraldevice scans for peripherals [6]. These restrictions will havea large impact on how the application is implemented, whichwill be covered in the Method section on page 4.If the application is in a suspended state it is not executingcode and cannot respond to events. However, if the applica-tion uses Core Bluetooth, the system can briefly transition theapplication from a suspended state to the background whena Bluetooth Low Energy event is detected. By implement-ing support for state preservation and restoration, the sys-tem can even re-launch a previously terminated applicationin response to Bluetooth events [6]. Events include connect-ing/disconnecting from peripherals and discovering new pe-ripherals through scanning.

Core LocationApart from Core Bluetooth, Apple supplies the Core Locationframework which is used for determining a user’s position.It can also be used to define geographic regions and moni-tor when a user crosses the boundaries of those regions [7].As of iOS 7, Core Location supports region monitoring andranging using Bluetooth Low Energy devices, which meansa region can be defined around a Bluetooth device. Rangingcan be used to determine the relative range to nearby Blue-tooth devices [13]. However, in order to use Core Locationwith Bluetooth Low Energy devices, the devices must supportiBeacon.

RELATED WORKThere has been a lot of research relating to the reliability ofusing RSSI for indoor localization, most of which has cometo less than satisfactory conclusions. Qian Dong and Wal-tenegus Dargie concluded in a study done in 2012 [17] thatthe raw RSSI data is ”absolutely weak” in determining thedistance to a mobile node in an indoor environment. Theyalso found that even after running the RSSI data through al-gorithms aimed to reduce noise, e.g. a moving average algo-rithm, the localization errors were too great to ignore.

Another recent study [18] – done at Linkoping University in2013 – showed that the Bluetooth Low Energy signal strengthvaried greatly over time, even at a constant distance. Theauthors concluded that this makes it difficult to infer an exactdistance to the Bluetooth device based solely on RSSI data.

A similar study was done by Ambili Parameswaran, Moham-mad Husain and Shambhu Upadhyaya in 2009 [19]. In thestudy, the authors performed practical experiments with theaim of proving or disproving that RSSI can be used as an in-dicator of distance between sensors with a built-in 2.4GHzantenna. The experiments were performed in a close to idealenvironment in which the sensors were placed on the samesurface, there were no obstacles between the sensors and anyelectronic equipment that could cause interference was elim-inated. Despite the close to ideal environment, the authorscame to the conclusion that RSSI cannot be used as a metricfor distance measurements in localization algorithms due to

3

the difficulty in finding a correlation between RSSI and dis-tance.

A third study [15] at the SPaRC Laboratory in Slovenia con-cluded that RSSI is not a reliable measurement when precisedistance evaluation is needed. However, the authors believethat RSSI could possibly be of practical use in cases wherethe distance evaluation does not have to be very precise.

Despite a lot of research coming to the conclusion that RSSIis not well suited for indoor localization, it might work wellfor the use case evaluated in this thesis. Precise distance eval-uation is not a requirement in estimating how close a user isto the door. However, the large variance in RSSI might bea problem when determining what side of the door a user islocated on. This is discussed further under Discussion.

METHODThere are two parts to the thesis: implementing an applica-tion for Apple’s mobile operating system iOS, and perform-ing measurements on the Bluetooth Low Energy communi-cation. This section will cover how and why a certain im-plementation was chosen and what measurements were per-formed. It will also explain how the door can be unlockedfrom an application and how this was discovered.

Unlocking the Door ProgrammaticallyIf the implemented iOS application is unable to unlock thedoor, the use for the application decreases drastically. Assuch, the first step was to determine if and how the doorcould be unlocked programmatically. It was known that thelock was running a web server on the local network; the webserver served a web page that was used to configure whattimes during the day the lock required a passcode, amongstother things. The web page also contained a button for un-locking the door briefly, known as a pulse unlock. It was triv-ial to discover what HTTP request was sent to perform a pulseunlock, and then send the same request from an iOS applica-tion. This worked well with the only drawback being that theapplication cannot know if the door is unlocked or not.

Choosing an Approach for the ImplementationBefore deciding on an approach, several alternatives wereevaluated based on how well they would perform in an iOSapplication that would mostly be run in a backgrounded state.The alternatives mainly differ in how Bluetooth is used.A decision also needed to be made whether to use Core Lo-cation or Core Bluetooth.

Core Location or Core Bluetooth?The first choice made was whether to use Core Location orCore Bluetooth. As Core Location can only be used withBluetooth devices that support the iBeacon protocol, it wasdecided that Core Bluetooth would be used to make the im-plementation more general.

Approach A: ScanningThe first approach used scanning as the main component. Asseen in Figure 2, the application would act as a central andcontinuously scan for advertising packets from peripherals.Whenever an advertising packet was received, an updated

signal strength could be retrieved. Based on the retrievedsignal strength, the application would decide whether or notto unlock the door.As scanning is simply the process of listening for packets,this approach had the benefit of working with any number ofsmartphones scanning simultaneously.The approach seemed feasible until it was discovered thatwhen running in the background, Core Bluetooth doesnot allow individual advertising packets to be received.Instead, multiple discoveries of an advertising peripheralare coalesced into a single discovery event [6]. As such,a signal strength would only be retrievable once – the firsttime a peripheral was discovered. This made the approachinfeasible and the approach was discarded.

Figure 2. An illustration of Approach A, showing two advertising Esti-

motes and a smartphone.

Approach B: Acting as a PeripheralThe second approach moved all the logic from the iOS appli-cation to the Estimotes. Instead of the application acting as acentral it would act as a peripheral and advertise, as seen inFigure 3. The Estimotes would then listen for the advertisingpackets from the application and determine whether or not tounlock the door.An iOS application is allowed to advertise data in the back-ground; however, if all applications that are advertising are inthe background, the frequency at which advertising packetsare sent may decrease [6]. The minimum frequency is not de-tailed in the documentation.This approach was deemed infeasible due to the fact that theBluetooth devices used – the Estimotes – could not be pro-grammed. If other Bluetooth devices could be used, e.g. anRFduino, this approach would most likely be the most practi-cal.

Figure 3. An illustration of Approach B, showing two Estimotes and an

advertising smartphone.

Approach C: Connecting to the PeripheralsThe third and chosen approach, seen in Figure 4, was sim-ilar to the first approach in that the application would actas a central. Instead of scanning for devices, the applica-tion would connect to the Estimotes and read their signalstrength using the readRSSI instance method defined onCBPeripheral in the Core Bluetooth framework.

4

By exploiting the fact that the Estimotes cancel the connec-tion after ten seconds, the application could be woken up froma backgrounded or suspended state by the system every tenseconds. Upon being woken up, an application has around 10seconds to complete a task [6]. The application could use thistime to re-connect to the Estimote and read the RSSI severaltimes.There are two disadvantages with this approach: the RSSI canonly be read once every second, and a Bluetooth Low Energyperipheral can only be connected to a single central at any onetime. This means that if a person inside the building is suffi-ciently close to the Estimote to keep constantly connecting toit, a person approaching the door from the outside will not beable to unlock the door automatically.Despite these shortcomings, this approach was deemed thebest of the three.

Figure 4. An illustration of Approach C, showing the connections be-

tween two Estimotes and a smartphone.

Implementing the Chosen ApproachAfter an approach was chosen it was implemented in the formof an iOS application; this section will briefly explain the pro-cess of implementing the application.For technical details on the application architecture, pleaserefer to the Results section.

Tools and Programming LanguageThe application was written in the object-oriented program-ming language Objective-C using Apple’s integrated develop-ment environment (IDE) Xcode. It was tested on an iPhone5S running iOS 7.1.

Application OverviewBefore the chosen approach was incorporated into the finalapplication, the chosen approach was tested in a standaloneapplication to verify that it would work. After the approachwas verified, work was started on the final application. How-ever, when verifying the chosen approach it was discoveredthat the user would need a way to choose which Estimotesto use. As such, a solution that used scanning to display alist of Estimotes was developed. When this part of the appli-cation was completed, the chosen approach was incorporatedinto the application and modified to work with the Estimoteselection.

Performing MeasurementsSeveral measurements were performed during the thesis toevaluate the Bluetooth technology. This section will describeand motivate all performed measurements.

Signal Strength Variance at a Constant DistanceThe signal strength (RSSI) is used to determine the user’sproximity to the door and as such it is important to understand

how the signal strength behaves. Two sets of measurementswere performed to investigate how the signal strength variesover time at a constant distance between the smartphone andEstimote. If the signal strength varies significantly even whenthe distance between devices does not change, it might be dif-ficult to determine a proximity from the raw RSSI data.Both sets of measurements were performed in an office envi-ronment and used the same Estimote, which had an advertis-ing interval of 200 milliseconds and a transmit power of �12dBm.

The first set of measurements was performed by placing thesmartphone and Estimote one meter apart on a flat surfacewith no obstacles between the devices. An application onthe smartphone listened for all incoming advertising packetsfrom the Estimote during a period of 60 seconds and recordedtheir signal strength and time of arrival to a comma-separatedvalues (CSV) file. The measurement was repeated five timesat an interval of three minutes, and the standard deviation wascalculated for each measurement.

The second set of measurements was performed with thesame setup as the previous set. However, instead of usingthe advertising packets to retrieve a signal strength, the ap-plication connected to the Estimote and used the readRSSIinstance method. This was done to determine if the signalstrength would be more reliable when a connection was es-tablished.

The mean standard deviation was then calculated for each setof measurements.

Energy UsageAs the application is designed to run constantly in the back-ground, it is of great importance that the effect on battery lifeis minimal. When using an iOS device for development, it ispossible to record energy usage for later inspection. This fea-ture was used to record energy usage over a period of eighthours while the implemented application was running. Toprevent any other application from affecting the energy usage,the iPhone was rebooted before the measurement was per-formed. The implemented application was then launched andimmediately put into a backgrounded state, and the iPhonewas locked. An Estimote was in close proximity and the ap-plication continuously connected and read the RSSI from theEstimote during the entire eight hour period. No other Blue-tooth Low Energy devices were in the vicinity.Following the measurement, the recorded data was importedfrom the device into Apple’s performance, analysis and test-ing tool Instruments.

Connection LatencyThe connection latency is defined to be the time it takes theapplication from initiating a connection until a connectionhas been established to the device. If this takes a long time,it might not be practical to rely on establishing a connectionto retrieve a signal strength. By the time the connection isestablished, the user might already have arrived at the door.A measurement of the connection latency was performedby writing a small application that connects and discon-nects from an Estimote several times. The application

5

stores the time of the call to -[CBCentralManager

connectPeripheral:options:] and cal-culates how much time has passed when thecentralManager:didConnectPeripheral:

delegate method is called. The application then disconnectsfrom the Estimote, waits 60 seconds and then performs thenext connection measurement.The mean connection latency was then calculated from 60measurements.

Signal Strength When Walking Past Two EstimotesOne problem with proximity-based door locks that this thesistries to solve is preventing the door from unlocking when aperson approaches the door from the inside. The approachtaken in this thesis was using two Estimotes – one on eitherside of the door – to determine what side of the door the useris on. It was hypothesized that if the user is on the inside ofthe door, the signal strength from the interior Estimote shouldbe greater and vice versa. To determine if this hypothesis wascorrect, five measurements were performed when the userwalked past the door. Each measurement lasted 15 seconds– which was enough time for the user to pass the door – andduring this time, an application on the user’s iPhone recordedthe signal strength of both Estimotes. The data was then ana-lyzed to see if any false positives were present (i.e. the signalstrength of the exterior Estimote was greater than that of theinterior Estimote, despite the user constantly being inside theoffice). Figure 5 shows the layout of part of the office, thelocation of the two Estimotes and the approximate path theuser walked.

A

B

Figure 5. An illustration of the office layout. The user walked from

point A to point B while the application recorded the signal strength

from both the interior (right) and exterior (left) Estimote. The cross will

be explained in the Discussion.

RESULTSThis section details how the iOS application is implementedand presents the results from the performed measurements.

Application ArchitectureThere are two parts to the application: choosing what Esti-motes to use, and using the selected Estimotes to determinewhen to unlock the door.When the application is first launched, the user isprompted to choose two Estimotes – one interior andone exterior. This user interaction is handled by thePLKEstimoteSelectionTableViewController

class which presents a table view1 of nearby Estimotesrepresented by instances of the PLKBluetoothDevice

class. The table view controller uses an instance ofPLKDeviceScanner to populate the table view usingscanning. By continuously scanning for devices, the RSSIfor each Estimote can be kept up-to-date as the user movesaround. Since all Estimotes broadcast the same devicename (estimote), the Estimote with the greatest RSSIis highlighted to help the user differentiate between theEstimotes.

When two Estimotes have been selected, an instance ofthe PLKMainViewController class is created. Thisclass is responsible for observing the RSSI of the twoEstimotes and determining whether or not to unlock thedoor. PLKMainViewController uses an instance ofPLKEstimoteConnectionManager to keep the RSSIof the Estimote model objects updated; this is accomplishedthrough continuously connecting to the Estimote devices andreading their RSSI.When the RSSI of an Estimote is updated, the view controllerdetermines if the door should be unlocked by comparing theRSSI of the interior and the exterior Estimote. If the RSSI ofthe exterior Estimote is greater, the user is assumed to be out-side the door and the view controller unlocks the door. Theunlocking is handled by an instance of TADoorUnlockerwhich communicates with the door lock.

MeasurementsThis subsection will present the results from all the measure-ments performed during the thesis.

Signal Strength Variance at a Constant DistanceThe results from both sets of measurements show large stan-dard deviations, with the results from measurements per-formed using readRSSI being the largest. Table 1 containsthe standard deviation for all five measurements in each set,as well as the mean standard deviation calculated from eachset.

Measurement Using advertising

packets

Using readRSSI

#1 3.028 5.713#2 3.247 4.335#3 4.270 4.530#4 3.594 4.682#5 3.731 5.878

Mean 3.574 5.028

Table 1. Standard deviation for all RSSI measurements at a distance of

one meter.

1A table view is a user interface element used in iOS applications todisplay hierarchical lists of items.

6

0 10 20 30 40 50 60

−95

−90

−85

−80

−75

−70

Time (seconds)

RSS

I (dB

m)

Figure 6. RSSI plotted over time during a period of 60 seconds.

To get a feel for what the RSSI looks like over time, Figure6 plots the data from the third measurement using advertis-ing packets. The highlighted rectangle is within one standarddeviation of the mean RSSI.

Energy UsageUsing the logging built into iOS, energy usage is reported asa relative value on the scale 0 — 20 [8]. The energy usage inthe recorded data is consistently reported as 1/20, with onlya few irregular spikes. This suggests that the application hasa negligible effect on energy usage.

Connection LatencyThe mean connection latency calculated from the first 60measurement samples was 324 milliseconds.

Signal Strength When Walking Past Two EstimotesIn three out of five measurements, the RSSI of the exteriorEstimote was reported to be greater than that of the interiorEstimote at least once. One of these measurements is shownas a plot in Figure 7. If a red point is above the black line,the RSSI of the exterior Estimote is greater than the RSSI ofthe interior Estimote. This can be seen at approximately 10seconds.

DISCUSSIONIn which the method and results are discussed and analyzed.

ResultsThe following subsections discuss the results from this thesis.This includes the results from all performed measurements, aswell as a discussion about the architecture of the implementedapplication.

Application ArchitectureWhen implementing the final application, care was takento make the implementation modular and reusable – some-thing that was made easy since Core Bluetooth is a high-level framework. As such, the majority of the classes aresmall and responsible for only one thing, e.g. unlocking the

door. The classes that could be made general without in-creasing the complexity were made general. A good exam-ple of this is the PLKDeviceScanner class which is usedto find Bluetooth Low Energy devices through scanning. Inthe implemented application, this class is only used to findEstimotes. However, scanning for devices is a very commonthing to do in a Bluetooth application. With this in mind,PLKDeviceScanner was not hard coded to scan for de-vices with a local device name of "estimote". Instead,the programmer supplies a block (a.k.a. anonymous func-tion) that acts as a filter; if the filter returns true for a supplieddevice, the device is kept.The fact that it is relatively simple to write good, reusableBluetooth code using Core Bluetooth is an indication of iOSbeing a mature platform for developing Bluetooth Low En-ergy applications.

Signal Strength VarianceBased on the related work and what is written about RSSI inthe Bluetooth Core Specification, the results from measuringthe signal strength were expected. The Bluetooth specifica-tion states that the reported RSSI has an accuracy of ±6 dBm.When measuring the RSSI at a constant distance of one me-ter, a mean standard deviation of 3.574 dBm and 5.028 dBmwere calculated – well within the mentioned accuracy. Anexplanation to why the standard deviation is greater for themeasurements that used readRSSI might be that the mea-surements were not performed at the exact same location inthe office. It is not unlikely that the new location simply hadmore interference in the form of WiFi. If anything, this showshow sensitive the RSSI is to the environment.

Signal Strength When Walking Past Two EstimotesThe results that showed a higher RSSI being retrieved fromthe exterior Estimote when walking past the door were un-expected. Even though Bluetooth uses radio waves to com-municate and does not require line-of-sight to operate, thesignal can be attenuated by obstacles such as walls. With thisin mind, the expected result was for the exterior Estimote’ssignal strength to always be less than that of the interior Es-

7

●

●

● ●

● ●

●

−100

−95

−90

−85

−80

−75

−70

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15Time (seconds)

RSS

I (dB

m)

RSSI over time

Figure 7. RSSI over time plotted for the interior (black line) and exterior (red points) Estimote.

timote. Despite this, there were false-positives reported inthree out of five measurements. After having analyzed thedata thoroughly, it was noted that this always happened at theend of the walk close to the cross in Figure 5. A plausibleexplanation to this phenomenon is that at that point, there isonly a window (the blue line segment in Figure 5) betweenthe smartphone and the exterior Estimote, but the corner of awall between the smartphone and the interior Estimote. Thewindow does not attenuate the Bluetooth signal as much asthe wall, which would explain the exterior Estimote having agreater signal strength despite the user always walking pastthe door on the interior side.This shows that developing a solution that works in any en-vironment will be difficult. The most reliable solution wouldmost likely be to simply use one Bluetooth device instead oftwo, and to make sure the device is not discoverable from theinside. This can probably be accomplished either by placingthe device a short distance from the door and configuring itto use a very weak signal, or by placing the device closer tothe door and preventing the radio signal – through the use ofshielding – from reaching inside.

Connection LatencyThe connection latency was higher than expected, yet it wasdeemed sufficiently low to not impact the user experience.According to the Bluetooth SIG, BLE can support connec-tion setup in as low as 3 milliseconds [2]. According to theresults, the mean connection latency was 324 milliseconds –a difference of two orders of magnitude! Since the connec-tion attempts were performed 60 seconds apart, this could beexplained by iOS putting the Bluetooth radio in a suspendedstate. That would mean the radio has to be powered on be-fore a connection can be initiated, and it would not come as asurprise if this took several hundred milliseconds.

When measuring the connection latency, the application wasin the foreground and the Estimote was within range of theiPhone. Thus, the measurements showed how quickly a con-nection can be established when the application is runningin the foreground and the Estimote is within range. How-ever, the most common scenario is for the application to bein a suspended state and for the Estimote to be out of range.As such, it would be interesting to perform a measurementwhich would measure the time it takes from the moment the

Estimote comes within range until a connection has been es-tablished. This would include connection latency, as well asthe time it takes for the iPhone to discover the Estimote. Un-fortunately, due to the difficulty in performing such a mea-surement, this kind of measurement was not performed.

Energy UsageBluetooth Low Energy was developed with the goal of havingultra-low power consumption. As such, the results from theenergy usage measurement were expected.The irregular spikes in the measurement data are most likelythe result of the operating system performing tasks unrelatedto the application. Unfortunately, the measurement data couldnot be exported from Instruments in any way, which made itdifficult to perform any real analysis of the data.

MethodA discussion about how the chosen approach was imple-mented and how the measurements were performed will fol-low in the coming subsections. A short paragraph on sourcecriticism is also included.

ImplementationWhen implementing the final application and evaluating thethree different approaches, a form of learning-by-doing wasapplied. The majority of what the author knows about theBluetooth Low Energy technology was gained from hands-on experience throughout working on the thesis. This methodworked well as there was a lot of practical work. However,it did have some drawbacks, and if the thesis work was tobe redone there would be some changes to the method. Themost significant drawback was that by not doing most of thetheoretical research about Bluetooth Low Energy and Apple’sframeworks before the practical work, the risk of coming tofaulty conclusions increased. One faulty conclusion madewas that it was not possible to scan for Bluetooth deviceswhen the application was in a backgrounded state, even if thedevices advertise services. As it turns out, this was possiblebut the application was restricted to only being notified oncewhen a device is found – as detailed in the documentation. Inthis case, the end result was the same for the implemented ap-plication, but it resulted in the author having an incorrect un-derstanding of the Core Bluetooth framework. By doing the

8

research beforehand – and being thorough – a lot of wastedtime can be avoided.

MeasurementsAll measurements have been performed with replicability andreliability in mind; each one – except for the battery usagemeasurement – has been performed multiple times and statis-tical methods have been used on the results to increase relia-bility. Despite this, it will be difficult to perform the measure-ments again and get exactly the same results. The Bluetoothsignal is relatively sensitive to interference, and all measure-ments relating to signal characteristics were performed in anoffice environment without making any effort to eliminate in-terference. As such, the measurement result values (such asaverage RSSI) will most likely differ. That being said, anydifference in results will probably not be great enough to al-ter any conclusions.The signal strength measurement using two Estimotes will bevery difficult to reproduce as the results are tightly coupled tothe location at which the measurements were performed. Thisdoes not make the measurements less valid, however; there isdefinite value in showing how Bluetooth behaves in a locationsuch as the one were the measurements were performed.

The only measurement that should have been done differentlyis the energy usage measurement. Energy usage was onlymeasured during one eight hour period, which reduces thereliability of the results. Even if the results were constantthroughout the measurement period, it would be a good ideato verify the results with a second measurement.

Source CriticismCare has been taken to only cite reputable and crediblesources, such as the official Bluetooth SIG website and pa-pers published at well-known conferences. Verifying all in-formation is very difficult, but facts presented in this thesisare based solely on information gathered from more than onesource.

The Work in a Larger ContextIt is important for users to be aware of and understand theprivacy aspect of automation as technologies such as BLEbecome more widespread. Automating common tasks – suchas unlocking doors – can have an impact on user privacy. Us-ing technology to automate tasks makes it easier to collectusage data without the user being notified, which can be seenas a form of privacy invasion. In the case of automatic doorlocks, information regarding who has unlocked the door andat what time it was unlocked can be stored; this data can thenbe used to approximate a persons location over time. Whenusing Bluetooth to approximate distance, an application canstore the distance data and transmit it to another party.A user that is aware of possible scenarios can make more in-formed decisions regarding the use of automation technology.

CONCLUSIONSAn iOS application for unlocking a door based on a usersproximity has been implemented, and several measurementshave been performed to evaluate Bluetooth Low Energy in thecontext of automatic door locks. From this, a lot of knowl-edge has been gained pertaining to how suitable Bluetooth

Low Energy is for automatic door locks, as well as what re-strictions and possibilities exist on the iOS platform for de-veloping Bluetooth Low Energy applications. As such, it canbe concluded that the purpose of this thesis has been fulfilled.

Despite the restrictions that apply to backgrounded appli-cations, Apple’s mobile operating system iOS is a matureplatform for developing Bluetooth Low Energy applications.With the updates to Core Bluetooth in iOS 7 allowing appli-cations to be re-launched by the system even after being ter-minated, it is possible to write applications that the user canlaunch once and then forget. This is especially suitable forapplications that automate tasks based on Bluetooth activity.Even though Core Bluetooth works very well for most tasks,it can be too high-level in some cases, e.g. by not exposingthe raw advertising packets.

The following subsections will present the conclusions for theresearch questions discussed in the Introduction.

Is it possible to prevent the door from unlocking when aperson approaches the door from the inside?Measurements show that the signal strength varies too greatlyover time and is too easily affected by the environment to cor-rectly differentiate between what side of the door the user islocated on using the approach discussed in this thesis. How-ever, as discussed in the previous chapter, it should be possi-ble to solve this problem by only using a single peripheral onthe exterior side of the door.

Does the implemented solution affect the smartphone’sbattery life negatively in a significant way?By measuring the energy usage of the implemented applica-tion during a period of eight hours, it was concluded that theapplication’s affect on the battery life was negligible.

Is the Bluetooth Low Energy communication latency suf-ficiently small to make the technology usable in practice?The average connection latency discovered through measure-ments (324 milliseconds) was two orders of magnitude higherthan expected. Despite the large difference in the expected la-tency and the actual latency, the connection latency was con-cluded to be sufficiently small to not make the technologyunusable.

Is Bluetooth Low Energy a Suitable Technology forProximity-based Automatic Door Locks?Bluetooth Low Energy provides ultra-low power consump-tion, sufficiently low latencies in establishing connections and– with a bit more time and work – the possibility of only un-locking the door when a user approaches the door from theoutside. Based on this, the conclusion is that Bluetooth LowEnergy is a suitable technology for proximity-based doorlocks. The difficulty in determining a user’s location rela-tive to the door is not a big problem since it is not necessarilya requirement, and it should be relatively simple to solve, aspreviously discussed.

9

Future WorkThe most important aspect to improve upon in the imple-mented solution is the fact that only one application can beconnected to the Bluetooth device at once. For the solutionto be truly useful, there cannot be a limit on how many peo-ple can be in close proximity to the lock simultaneously. Thiswill most likely require that an entirely new solution be devel-oped as the limit is a result of the connection-oriented solutionimplemented in this thesis.

REFERENCES1. A Look at the Basics of Bluetooth Technology.

http://www.bluetooth.com/Pages/Basics.aspx.2. About Bluetooth Low Energy Technology. http://www.

bluetooth.com/Pages/low-energy-tech-info.aspx.3. Bluetooth Fast Facts.

http://www.bluetooth.com/Pages/Fast-Facts.aspx.4. Bluetooth Smart Technology: Powering the Internet of

Things. http://www.bluetooth.com/pages/bluetooth-smart.aspx.

5. Core Bluetooth Programming Guide: About CoreBluetooth. https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html.

6. Core Bluetooth Programming Guide: Core BluetoothBackground Processing for iOS Apps.https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1.

7. Core Location Framework Reference.https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/_index.html.

8. Instruments User Reference: Energy Usage Instrument.https://developer.apple.com/library/ios/documentation/AnalysisTools/Reference/Instruments_User_Reference/EnergyUsageInstrument/EnergyUsageInstrument.html.

9. iOS App Programming Guide: App States andMultitasking. https://developer.apple.com/

library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html.

10. Location and Maps Programming Guide: RegionMonitoring and iBeacon. https://developer.apple.com/library/ios/documentation/userexperience/conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html.

11. Skyrocketing demand for Bluetooth appcessories forlatest phones. http://www.bluetooth.com/Pages/Mobile-Telephony-Market.aspx.

12. What’s New in iOS: iOS 5.0. https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS5.html.

13. What’s New in iOS: iOS 7.0 - Core LocationFramework.https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS7.html#//apple_ref/doc/uid/TP40013162-SW28.

14. Wibree Forum Merges with Bluetooth SIG.http://www.bluetooth.com/Pages/Press-Releases-Detail.aspx?ItemID=51, June 2007.

15. Benkic, K., Malajner, M., Planinsic, P., and Z. Cucej.Using RSSI value for distance estimation in wirelesssensor networks based on ZigBee. In Systems, Signalsand Image Processing, 2008. IWSSIP 2008. 15thInternational Conference on, IEEE (2008), 303–306.

16. Bluetooth SIG. Bluetooth Specification version 4.0, June2010.

17. Dong, Q., and Dargie, W. Evaluation of the reliability ofRSSI for indoor localization. In WirelessCommunications in Unusual and Confined Areas(ICWCUCA), 2012 International Conference on, IEEE(2012), 1–6.

18. Englund, A., and Suther, M. Bluetooth Low Energy somtradlos standard for hemautomation, Bachelor’s Thesis,Linkopings universitet, 2013.

19. Parameswaran, A. T., Husain, M. I., and Upadhyaya, S.Is RSSI a reliable parameter in sensor localizationalgorithms: An experimental study. In Field FailureData Analysis Workshop (F2DA09) (2009).

10

På svenskaDetta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In EnglishThe publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Tim Andersson