Fulltext01 PDF

UPTEC IT 17 023
Examensarbete 30 hp
Oktober 2017
Indoor Navigation And Personal

Tracking System Using Bluetooth
Low Energy Beacons
Adam Hernod Olevall

Mathieu Fuchs
Abstract
Indoor Navigation And Personal Tracking System
Using Bluetooth Low Energy Beacons
Adam Hernod Olevall, Mathieu Fuchs
Teknisk- naturvetenskaplig fakultet

UTH-enheten Navigation systems for outdoor purposes have been around us for several years.
Recently, it has emerged for indoor use. Thanks to techniques as Bluetooth and Wi-
Besöksadress: Fi, public places like shopping malls have come up with solutions that help their
Ångströmlaboratoriet
Lägerhyddsvägen 1 visitors navigate through the area. At the same time, an approach called crowd-
Hus 4, Plan 0 sourced localization has hit the market. It is a technique where people help each
other to track down lost assets by getting close enough to an attached device and
Postadress: register its coordinates.
Box 536
751 21 Uppsala
In this thesis, these two techniques were combined to build and evaluate an
Telefon: application which handles the indoor positioning system with a new approach. The
018 – 471 30 03 expensive part of the system is already included in the users and visitors
Telefax: smartphones. The program consists of positioning the user, while actively
018 – 471 30 00 searching the near area for lost objects. This means that the only cost for the client
is to pay for the relatively cheap beacons attached to the walls and ceiling, which
Hemsida: are used to locate the users in the building.
http://www.teknat.uu.se/student
Tests were done to evaluate how accurate the algorithm was when deciding the
position of the lost object. The practical number of smartphones required to find
the lost asset were also evaluated. Beside these technical aspects a user centered
survey was done to understand if people are willing to use such a system.
The results showed inconsistency in term of accuracy, but it also showed that it
was sufficient for finding the lost asset by this approach. By looking at the results
from the different tests that were made a conclusion can be drawn that it requires
approximately one user per every 360 to 450 m² to locate an asset below 10
seconds, all depending on the mobility of the asset.
Handledare: Per Fork

Ämnesgranskare: Edith Ngai
Examinator: Lars-Åke Nordén
ISSN: 1401-5749, UPTEC IT 17 023
Tryckt av: Reprocentralen ITC
Populärvetenskaplig sammanfattning
Navigationssystem för utomhusbruk har varit med oss under en lång tid.
Nyligen har det även slagit igenom för inomhusbruk och är mer känt under
namnet IPS, vilket är en förkortning för det engelska indoor positioning sy-
stem. Det mest vanliga sättet som IPS förekommer på idag är att användaren
kan se sin position i ett rum genom att dess smartphone tar emot information
från sändare som monterats i taket. Dessa sändare är mer kända som beacons
och är enbart till för att skicka ut information med hjälp av främst Bluetooth.
Förutom IPS har det även på senare tid slagit igenom en helt ny form av
lokaliseringsteknik som har den engelska termen crowd locating. Det är ett
koncept som bygger på att människor hjälper varandra att lokalisera förlora-
de föremål. Det fungerar genom att ägaren till ett föremål fäster en sändare
på det. Sändaren kan sedan kommunicera med en applikation som är in-
stallerad på en smartphone. Om föremålet sedan förloras kan det lokaliseras
genom att någon med applikationen installerad på sin smartphone passerar
föremålet och fångar upp sändarens signal. Denna teknik är väl beprövad
utomhus, men hittills inte applicerad inomhus.
För att lokalisera saker inomhus idag, måste det sitta smarta enheter mon-
terade i taken som kan ta emot signalen från den sändare som har fästs vid
det borttappade föremålet. Dessa enheter beräknar sedan avståndet till det
borttappade föremålet och genom att de kommunicerar med varandra kan
de positionera föremålet. Eftersom varje smart enhet måste vara kapabel att
kunna skicka och ta emot information samt beräkna data blir kostnaden för
varje enhet relativt dyr.
Denna rapport syftar till att undersöka möjligheten att kombinera tekniken
att navigera inomhus med crowd locating, vilket skulle innebära ett billiga-
re system än det ovan nämnda. Genom att kombinera dessa båda tekniker
räcker det att installera relativt billiga beacons i byggnaden istället för dyra
smarta enheter. Signalerna från dessa beacons tas istället upp av besökarnas
smartphones och på så sätt kan det borttappade föremålet lokaliseras. Vida-
re i rapporten visas att det gjorts en utvärdering av detta system för att se
hur många besökare i till exempel ett shopping-center som måste ha appli-
kationen igång för att man snabbt och smidigt ska få ett resultat med bra
noggrannhet.
Resultatet visar att detta är ett tillvägagångssätt som fungerar. Noggrann-
heten i positioneringen av det borttappade föremålet är inte exakt, men det
anses bra nog för att vara användbart. Genom att titta närmare på resultaten
blir slutsatsen att det i snitt behövs en användare av applikationen per 360 -
450 m2 , beroende på om föremålet som eftersöks är rörligt eller statiskt.
i
Declaration of Authorship
We, Adam H ERNOD O LEVALL and Mathieu F UCHS, declare that this thesis
titled, “Indoor Navigation And Personal Tracking System Using Bluetooth
Low Energy Beacons” and the work presented in it is our own. We confirm
that:
• Where we have consulted the published work of others, this is always
clearly attributed.
• Where we have quoted from the work of others, the source is always
given. With the exception of such quotations, this thesis is entirely our
own work.
• We have acknowledged all main sources of help.
• Where the thesis is based on work done by ourselves jointly with oth-
ers, we have made clear exactly what was done by others and what we
have contributed ourselves.
Signed:
Date:
ii
Acknowledgements
This thesis was supported by Valtech, Stockholm.
We would like to begin by thanking Valtech for the help and support to or-
ganize a thesis for us. They really cared for us and arranged a lot of meetings
with various people to help us find a good thesis.
A big thank you to our supervisor Per Fork (Valtech) for all the support dur-
ing this thesis. He was the one with the idea and without him this thesis
could not have been done.
Thank you, Edith Ngai (Uppsala University) for reviewing this thesis. We
are very thankful for her valuable inputs and ideas during this thesis. Also,
we want to thank her for taking her time to meet us and discuss the content
of the report, this has been really valuable for us.
iii
“True navigation begins in the human heart. It’s the most important map of all. ”
Elizabeth Kapu’uwailani Lindsey

iv
Contents
Declaration of Authorship i
Acknowledgements ii
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Related Work 6
2.1 Indoor Positioning Systems . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Indoor Positioning Systems with Bluetooth . . . . . . . 7
2.1.2 Other approaches to IPS . . . . . . . . . . . . . . . . . . 8
Wi-Fi based localization . . . . . . . . . . . . . . . . . . 8
Geomagnetic Technology . . . . . . . . . . . . . . . . . 8
Image based localization . . . . . . . . . . . . . . . . . . 8
2.2 Tracking Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Trackr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Personal Tracking via Bluetooth . . . . . . . . . . . . . 9
2.3 Crowd-sourced localization . . . . . . . . . . . . . . . . . . . . 10
3 Theory 11
3.1 Wireless technologies for IPS . . . . . . . . . . . . . . . . . . . 12
3.1.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Bluetooth Lower Energy . . . . . . . . . . . . . . . . . . 13
3.1.3 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 iBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 StepInside . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Estimote Beacons . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Positioning Methods . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Distance calculation . . . . . . . . . . . . . . . . . . . . 16
3.3.2 Triangulation . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Trilateration . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.4 Proximity . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.5 Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Positioning optimization . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Multilateration . . . . . . . . . . . . . . . . . . . . . . . 20
v
3.4.2 Least squares . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Mobile Operating Systems . . . . . . . . . . . . . . . . . . . . . 22
3.5.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Use Case Scenarios 23

4.1 Child care in shopping malls . . . . . . . . . . . . . . . . . . . 24
4.2 Asset localization at events, fairs and showrooms . . . . . . . 24
4.3 Wheelchair tracking at airports . . . . . . . . . . . . . . . . . . 24
5 Method 26
5.1 Comparison between BLE and Wi-Fi . . . . . . . . . . . . . . . 27
5.2 Comparison between positioning methods . . . . . . . . . . . 27
5.3 Hardware and software . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Accuracy Test: Estimote Beacon . . . . . . . . . . . . . . . . . . 28
5.5 Accuracy Test: Application . . . . . . . . . . . . . . . . . . . . 28
5.6 Simulation of application usage . . . . . . . . . . . . . . . . . . 29
5.6.1 Scenario 1 - Finding lost child in a mall . . . . . . . . . 30
5.6.2 Scenario 2 - Finding a lost table at a trade fair . . . . . . 30
5.7 Battery Performance of the Application . . . . . . . . . . . . . 31
5.8 User Centered Survey . . . . . . . . . . . . . . . . . . . . . . . 31
6 Implementation 32
6.1 Illustration of the IPS environment . . . . . . . . . . . . . . . . 33
6.2 Operative system . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3 Android and BLE communication . . . . . . . . . . . . . . . . 33
6.3.1 Estimote SDK . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 StepInside SDK . . . . . . . . . . . . . . . . . . . . . . . 34
6.4 Google Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.1 Firebase Realtime Database . . . . . . . . . . . . . . . . 35
6.4.2 Firebase Authentication . . . . . . . . . . . . . . . . . . 35
6.5 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.6 The BeaconInfo object . . . . . . . . . . . . . . . . . . . . . . . 37
6.7 Positioning algorithm . . . . . . . . . . . . . . . . . . . . . . . . 38
6.8 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.9 The iOS implementation . . . . . . . . . . . . . . . . . . . . . . 40
7 Results 41
7.1 Performance tests on Android . . . . . . . . . . . . . . . . . . . 42
7.1.1 Performance test 1: comparison of different TxPower
settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1.2 Performance test 2: comparison of two beacons . . . . 44
7.2 Performance Test on iPhone . . . . . . . . . . . . . . . . . . . . 45
7.3 Performance test: positioning accuracy . . . . . . . . . . . . . . 46
7.5 Performance Test: Battery Usage . . . . . . . . . . . . . . . . . 49
7.6 Survey Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
vi
8 Discussion 52
8.1 Experimental Discussion . . . . . . . . . . . . . . . . . . . . . . 53
8.1.1 Distance measurements . . . . . . . . . . . . . . . . . . 53
8.1.2 Positioning Accuracy . . . . . . . . . . . . . . . . . . . . 53
8.2 Android vs iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.4 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9 Conclusion 57
9.1 Combine an earlier known IPS approach with crowd-sourced
localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Bibliography 60
vii
List of Figures
1.1 Bluetooth beacons attached in the ceiling and a listening de-

vice can together decide the position of the user. . . . . . . . . 3
1.2 Listening devices attached in the ceiling can talk with each
other and share their distance to the sending Bluetooth bea-
con. In this way is it possible to decide where the beacon is
located. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 The users can locate themselves in relation to the room by let-
ting their smartphones listen for the sending beacons in the
ceiling. The smartphones will then register the signal from the
beacon attached to the asset and store it in a database. . . . . . 4
3.1 The structure of the iBeacon protocol. . . . . . . . . . . . . . . 15

3.2 When a device is within the range of a proximity beacon an
action is triggered. . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 The principle of triangulation where the two cellphones can
receive the transmitting signal and calculate its position. . . . 17
3.4 Trilateration illustrated for one, two and three transmitters. By
adding transmitters, possible positions will be excluded. . . . 19
5.1 The specified path. . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 A simulated test environment where the listeners and the sender
were randomly placed on the grid. They moved randomly un-
til one listener found the sender. . . . . . . . . . . . . . . . . . 30
6.1 Illustration of the IPS environment. . . . . . . . . . . . . . . . . 33

6.2 System architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Overview of the application. . . . . . . . . . . . . . . . . . . . . 37
6.4 User interface of the application. . . . . . . . . . . . . . . . . . 39
7.1 Performance tests for different values of TxPower: (a) TxPower

set to -16dB corresponds to 7m range. (b) TxPower: -12dB
(1̃5m range). (c) TxPower: -8dB (3̃0m range). . . . . . . . . . . 42
7.2 Two beacons (dotted blue and solid green lines) are compared
for different values of TxPower: (a) TxPower set to -16dB. (b)
TxPower: -12dB. (c) TxPower: -8dB. . . . . . . . . . . . . . . . 44
7.3 Performance tests on iPhone for different values of TxPower:
(a) TxPower set to -16dB corresponds to 7m range. (b) Tx-
Power: -12dB (1̃5m range). (c) TxPower: -8dB (3̃0m range). . . 45
7.4 The registered path (filled red line) in contrast to the real one
(dotted black line ). . . . . . . . . . . . . . . . . . . . . . . . . . 46
viii
7.5 Survey results represented as pie charts. . . . . . . . . . . . . . 50

ix
List of Tables
3.1 Overview of Bluetooth releases. . . . . . . . . . . . . . . . . . . 12

3.2 Power classes of Bluetooth. . . . . . . . . . . . . . . . . . . . . 12
3.3 Overview of Wi-Fi protocols. . . . . . . . . . . . . . . . . . . . 14
7.1 Scenario 1: Time elapsed for finding the lost asset for different
numbers of users. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2 Scenario 2: Time elapsed for finding the lost asset for different
numbers of users. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3 Battery performance test of smartphone during 60 minutes. . 49
x
List of Abbreviations
GPS Global Positioning Ssystem

IPS Indoor Positioning System
BLE Bluetooth Low Energy
RSSI Received Signal Strength Indicator
AP Acess Point
SDK Software Development Kit
UUID Universally Unique Identifier
dBm deciBell-milliwatt
WPAN Wireless Personal Area Networks
THz TeraHertz
GHz GigaHertz
MHz MegaHertz
1
Chapter 1
Introduction
This chapter serves as the background of this master thesis by giving a brief
summary about navigation in general. It explains how the indoor position-
ing system (IPS) is being used today and how the introduction of Bluetooth
low energy (BLE) enables so-called beacons to be used in IPS environments.
Later, it also explains how this thesis will evaluate this new approach to IPS.
Chapter 1. Introduction 2
1.1 Background
The ability to navigate has always been of great importance for humans when
discovering new and unknown territories of the world. The evolution of the
various navigation techniques has helped the human species spread across
the planet. Today, when most of the world is well explored, navigation still
remains an important part of our society. The technologies of today enable
us to use navigation in a whole new way than our ancestors could.
Since smartphones were released on the market, a lot of location based ser-
vices have been developed. It is now possible to use navigation to find your
way to a certain address or a point of interest, for example, the closest gas
station or restaurant. All these functions are available thanks to the global
positioning system (GPS) which has been integrated in those applications.
Today, GPS is most known to be a navigation system using satellites to de-
termine a receiver’s position on earth. It points out a three dimensional po-
sition in form of longitude, latitude and altitude. It consists of three different
parts. The first one is the Space Segment which is a constellation of 24 satel-
lites inclined 55 degrees from the equator on a 20,200 kilometers distance to
earth. The next are the Control Segments which are stations placed on earth
in order to monitor and maintain the satellites. The last segment is the User
Segment which is the receiver that handles the signals from the satellites and
calculates the time and position [1].
If the line of sight is good and clear, the accuracy of GPS has become good
enough to locate an object or a user within a few meters. If the GPS signals
are weak or disturbed by impenetrable obstacles, the position can become
unreliable. With these conditions in mind, it can be problematic to use GPS
indoors. Therefore, during later years, IPS has become the popular way to
design navigation indoors. Instead of using satellites, IPS uses radio waves
or magnetic fields to determinate positions. The applications that take ad-
vantage of IPS are still very few compared to the ones using GPS. There are
no standardization and many local deployments of IPS are using their own
implementation. A range of different technologies have been tested and im-
plemented, such as using infrared, ultrasounds or more commonly Wi-Fi and
Bluetooth [2].
BLE was released in 2011, along with Bluetooth 4.0. Thanks to the low power
consumption of BLE, a lot of companies started to make use of this technol-
ogy in their implementations. One of these companies is Estimote [3] which
uses BLE in the development of their beacons. A beacon is a transmitter send-
ing small amount of information about itself that other devices can read.
As mentioned above, IPS is implemented in a couple of different ways. One
approach is that a device, or listener, is used to register incoming signals
from the beacons positioned around the person. This method is used in for
example shopping centers where you only need to locate yourself relative to
the indoor environment. A user’s smartphone is able to measure the distance
to every transmitter it sees and can then calculate, with the help of some
localization techniques, its relative position to the transmitters [4].
F IGURE 1.1: Bluetooth beacons attached in the ceiling and a

listening device can together decide the position of the user.
Another approach is that the listeners are attached in the ceiling and the bea-
cons are attached on a mobile asset. The smart devices in the ceiling register
their own distance to the beacon and then communicate with each other and
share the measured data. In this way it is possible to position lost objects.
F IGURE 1.2: Listening devices attached in the ceiling can talk

with each other and share their distance to the sending Blue-
tooth beacon. In this way is it possible to decide where the bea-
con is located.
1.2 Purpose
There is a need of being able to keep track of important assets in indoor en-
vironments. By using the above two mentioned approaches, it could be ex-
pensive tracking down a single asset. It would either require attaching a rel-
atively expensive device on every asset, or installing a large number of these
tracking devices in the ceilings. The later solution would be an expensive
cost if the indoor area is large.
This thesis will evaluate if it is possible to apply a new approach to locate
lost assets in a cheap and efficient way. The idea is to combine the two earlier
mentioned approaches. Transmitting beacons are attached to the lost assets
and a couple of other transmitting beacons are attached to the ceiling. This
is a cheaper way than putting an expensive listener on every asset or in the
ceiling. The listeners are instead people’s smartphones being in the area. The
smartphone’s application could listen for a transmitting beacon attached to
a lost object. In the same time, the application can positioning itself relative
to the room with help from the beacons in the ceiling and later on store the
collected data to a database. Using this approach, the client interested in
such a system would only need to purchase the fairly cheap beacons rather
than the more expensive smart devices from the other approaches. The cost
is instead placed on the visitor’s own devices.
F IGURE 1.3: The users can locate themselves in relation to the

room by letting their smartphones listen for the sending bea-
cons in the ceiling. The smartphones will then register the
signal from the beacon attached to the asset and store it in a
database.
This approach, which involves people walking around with a listening de-
vice searching for a signal, is called crowd-sourced localization and is still
unexplored for the indoor area. For outdoor usage, this is a well known ap-
proach where Trackr is one of the leading companies [5], but for indoor usage
it is still undone.
The application will be developed for both iPhone and Android in order to
compare the results and see if one operating system is better than the other
for the purpose of this application.
Finally, an evaluation will be made in order to find out how many of the
listeners that need to catch the signal in order to get a good position of the
asset.
1.2.1 Problem Statement
The problem studied in this thesis is to evaluate if lost assets can be tracked in
indoor environments by using a couple of smartphones and beacons. In more
detail, the problem of the study is to implement a smartphone application
able to locate the beacons accurately enough at a low cost and being energy
efficient as well as user-friendly.
1.2.2 Goals
An application will be implemented and tested in order to evaluate if lost

assets can be located using smartphones and beacons. This thesis will focus
on the following parts:
• How many users will be required in order to get a good position of a
lost asset?
• Is it better to have a weaker signal from the emitting unit, implying a
lower energy consumption but a smaller coverage area? Or is it better
to have a stronger signal, consuming more energy but instead reaching
out to more listeners?
• Considering the battery consumption of the application, are people will-
ing to let the application run in background mode in order to make this
approach of IPS work?
1.3 Delimitations
A prototype application is built for Valtech’s office. It consists of some Es-

timote beacons, each attached to a given asset. Another kind of beacon
providers, SenionLabs beacons [6], are also spread around in Valtech’s build-
ing, attached to the ceiling. By using one or more smartphones we should
be able to locate these Estimote beacons within the building. Our work will
not focus on the possible scalability of the prototype. Alternative implemen-
tations, using other kind of beacons or other devices than smartphones will
not be done.
6
Chapter 2
Related Work
This chapter introduces earlier researches done in similar areas. The ap-
plication developed in this thesis is composed of two parts: an IPS system
needed to locate the users and a tracking system for locating the lost as-
sets. Works about IPS and examples of tracking systems will therefore be
reviewed. As mentioned in the introduction, since our application in based
on crowd-sourced localization, meaning that the system needs active users
in order to work, related work covering this area will also be reviewed.
Chapter 2. Related Work 7
2.1 Indoor Positioning Systems
Many scientific papers have been written about different technologies re-
garding IPS. Han Lui et al. made a in-depth survey of different techniques
and approaches to IPS. They present and discuss measuring and positioning
techniques as triangulation, fingerprinting and proximity. They also discuss
a how to evaluate IPS in term of accuracy, cost and robustness among others.
A taxonomy of different wireless technologies that can be used to build IPS
is presented and compared [7]. The large variety of techniques and solutions
presented in this survey can be valuable to know about before building an
IPS.
Papers about specific techniques are presented and reviewed in the following
sections. First are papers about Bluetooth reviewed, the technique used in
this thesis. Later on, works about other techniques that can be used within
IPS are reviewed.
2.1.1 Indoor Positioning Systems with Bluetooth
Bluetooth can utilize RSSI to be a technique for measuring positions indoors.

Sheng Zhou el at. have made such a system where they turned off the au-
tomatic transmitter power control to get a novel use of the RSSI [8]. The
distance was estimated by transmitting between a mobile receiver and a ref-
erence point. They were also using a Line-Of-Sight radio propagation model
within a single cell.
The ability to navigate indoors using BLE and a smartphones has been stud-
ied by Milan Herrera Vargas. The author set up an indoor environment com-
posed of two BLE beacons and a smartphone. He claims that the main pur-
pose of his report was to introduce indoor navigation based on BLE but that
this technology is still limited which led to unstable measurements and bad
accuracy [9]. The bad accuracy is an interesting aspect of IPS and is an known
issue. Silke Feldmann et al. have in their scientific paper tried to overcome
this problem with and optimization method least square [10]. They got a
precision of 2 meters but think it could be even better by using a Kalman
Filter.
Tengqingqing Ge made a comparable research about indoor navigation but
focused on making it available for blind people [11]. By using BLE beacons
and a smartphone, he developed and compared two different positioning
softwares. The first one, based on triangulation and fingerprinting, gave
good a static performance, but was not a reliable navigation system. In the
second software a proximity algorithm was instead used, along with a real
blind person. This experiment gave on the other hand a better output let-
ting him conclude that a blind person was able to navigate through the route
without any help from other people.
2.1.2 Other approaches to IPS
Instead of using Bluetooth, other technologies can be used to calculate posi-

tions. Examples of such approaches are presented below.
Wi-Fi based localization
Wi-Fi based localization is probably the most common technique used for
IPS. Behrang Parhizkar et al. discuss such a solution as they try to position a
user within a building [12]. Thomas J. Gallagher et al. are also utilizing the
Wi-Fi technology as they describe a campus-wide positioning system at the
University of New South Wales in Sydney, Australia, and works outdoors as
well as indoors [13].
Geomagnetic Technology
IndoorAtlas is an IPS company using the earth’s magnetic field in order to

calculate positions. By using the compass which works as a magnetic sensor,
it is possible to use the magnetic fields inside a building to accurately pin-
point and track a user’s position indoors. Geomagnetic is the foundation of
this technology but together with Wi-Fi and beacons is it possible to develop
a hybrid solution in order to reach optimization [14].
Image based localization
Today’s smartphones are equipped with many different sensors. Instead of

using Bluetooth or Wi-Fi sensors, the smartphones camera can be used for
IPS. An augmented reality kind of IPS can be done by comparing pictures
taken by the camera with a sample of pictures stored in a database. It is then
possible to position the smartphone [15].
The camera can also be used for visible light communication [16]. This ap-
proach uses the emitting light itself, and can provide very good accuracy as
well as being free from radio frequencies.
These two approaches are however dependent on the line of sight which
can be problematic for passive positioning when the smartphone camera is
obstructed (in a bag or a pocket).
2.2 Tracking Systems
Another way of using a smartphone and BLE is for tracking lost objects.
Trackr is a commercial solution using smartphones, GPS and BLE beacons
to track lost assets in outdoor environments. A recent released scientific jour-

nal is also studying this kind of system. Both are reviewed below.
2.2.1 Trackr
Trackr is a crowd-sourced localization product made by Phone Halo [17].

The idea is to put a Trackr device on a bike, key-ring or another item that
tends to get lost. Using the Trackr application, which always registers the
last known position of the Trackr device, it is possible to see where the lost
item is located. Trackr uses BLE, and when one is within Bluetooth range, it
is possible for the application to measure the distance to the lost item with
help of RSSI. If the lost item is small and hard to detect, it is possible to make
the device beep when one is within Bluetooth range.
As mentioned, Trackr is using crowd-sourced localization. This is a concept
where passive users of the application, the crowd, facilitates the search of the
lost item. This is because the Trackr application does not only register the
signal from your own belongings, but of all Trackr devices. If you lose your
item, you will get noticed as soon as another Trackr application is within
Bluetooth range of your lost object. Trackr will save the GPS position of the
user and display it in your smartphone.
In order to work properly, it is necessary that many people use the product.
If one loses an item, and nobody register its signal, the whole concept is of no
use. This means that crowd-sourced localization will work very well in large
populated cities like Los Angeles where a lot of people will have a chance
to register Trackr devices. At the same time it will not work equally good in
smaller cities where there are less people on the move and the probability to
catch the signal is smaller.
2.2.2 Personal Tracking via Bluetooth
"Never Lose! Smart Phone based Personal Tracking via Bluetooth" is a sci-
entific journal written by Saleem Ahmad, Prof. Lu Rouyu and Muhammad
Jawad Hussain [18]. The authors made a study on asset tracking where they
presented different approaches to the problem. They also reviewed existing
technologies and conducted a survey in China, UK and USA about personal
tracking systems. Later on, they discussed the benefits and drawbacks of
using BLE compared to other wireless technologies.
Choosing Bluetooth as a tracking technology provides coverage for both in-
door and outdoor usage with meter accuracy. BLE is currently installed in
most smartphones, it is battery efficient and does not requires much com-
putation power. The low installation costs also makes it the best candidate
compared to GPS, GSM, Wi-Fi and other techniques compared in the study.
The accuracy of Bluetooth can however be a limitation, but the authors pro-
pose that Bluetooth could be assisted by audio or visual aids.
The survey was answered by 1000 participants, 69% of them being unaware
of the tracking possibility of their smartphones. Almost all of them, 92%
thinks a tracking system could help finding lost assets. The authors conclude
that such systems will need to be low-cost and energy efficient in order to be
adopted at large scales.
2.3 Crowd-sourced localization
Some researches within IPS have begun to explore the concept of crowd-
sourced localization. This concept is mainly about collecting vital data from
the users of such systems. By continuously collecting user data, Yongduo
Wang et al. proposed an IPS solution based on Wi-Fi RSSI data, collected by
using the crowd. The positioning method used in their approach is finger-
printing. Fingerprinting is a common method, resulting in good positioning
accuracy but requires a lot of data to build the fingerprint database. This is
why the motivation for using crowd-sourced data is for simplifying the cre-
ation of their fingerprint database. The collected data also helps improving
and updating the database after its creation [19].
Anshul Rai et al. developed a system called Zee which is also based on
crowd-sourced localization. They investigate an hybrid solution of using
both Wi-Fi signals but also a smartphones sensors like the gyroscope and
the accelerometer. This data is also collected using the crowd and permits
to position the users without knowing their initial location, by looking at the
number of steps they have walked, the direction they are facing and the ve-
locity of the walk. Other users that needs to be located can then benefit from
the fingerprint database obtained from these previous observations [20].
Jindan Zhu et al. discussed about the main problem with crowd-sourced sys-
tems, which is the need of having active users collecting the vital data. The
lack of users is the biggest limitation of such systems, and they tried to over-
come this problem by combining Wi-Fi fingerprints with signals from BLE
beacons. This particular approach of using data from beacons to support the
lack of user data, let the authors of this paper improve the quality of their
fingerprint database. Their work however showed some weakness for posi-
tioning the users, because it requires the users to be immobile in order to get
a good accuracy and the calculations requires time and cannot be processed
in realtime [21].
11
Chapter 3
Theory
The following chapter covers the different technologies involved in this the-
sis. The main focus is about different positioning methods that are presented
and explained.
Chapter 3. Theory 12
3.1 Wireless technologies for IPS
There are a lot of wireless technologies that are being used together with IPS.
The ones found most interesting regarding this thesis have been reviewed.
3.1.1 Bluetooth
Bluetooth is a wireless communication technology based on the IEEE 802.15.1

standard. It has a low-power consumption design and is therefore primary
a short distance technology. It uses short length radio transmissions in the
2400-2483.5 MHz range within the ISM 2.4 GHz frequency band. The trans-
mitting channels are spaced 1 MHz apart, starting at 2402 MHz and finishing
at 2480 MHz, a total of 79 channels [22].
Bluetooth can be used to connect different devices with each other, such as
smartphones, headsets or speakers. The first version of Bluetooth was called
1.0 and was released in 1999.
Version Year Speed Range

1.0 1999 0.7 Mbit/s 10 m
2.0 2004 2.1 Mbit/s 10 m
3.0 2009 24 Mbit/s 10 m
4.0 2010 24 Mbit/s 60 m
5.0 2016 50 Mbit/s 240 m
TABLE 3.1: Overview of Bluetooth releases.
As seen in table 3.1, Bluetooth 5.0 has recently been released as one of the
major advancements so far [23]. It has 2x speed and 4x range compared to
its previous versions. Besides this, it also has enough bandwidth to support
two connected devices at the same time. This means you can play one song
on a connected loudspeaker and one song on another [24].
The Bluetooth technology is divided into four different power classes. Each
class has a permitted power and a corresponding range. The two major
classes are Class 1 and Class 2. Class 1 could range up to 100 meters and
are often used in industries. Class 2 are the most common one in cellphones,
used to save battery [25].
Class Max Permitted Power Range

1 100 mW, 20 dBm ~100 m
2 2.5 mW, 4 dBm ~10 m
3 1 mW, 0 dBm ~1 m
4 0 mW, -3 dBm ~0.5 m
TABLE 3.2: Power classes of Bluetooth.

There are other aspects than the output power class of the device that affects
the range. These could be environmental factors such as obstacles, antenna
malfunctions or a weak receiver [23].
In the last couple of years Bluetooth has enlarged its applications. When In-
ternet of Things (IoT) made its entrance on the market there was a need of
having as low power consumption as possible. This is why Bluetooth is to-
day used as a communication technique for small battery-powered devices.
They have a very small power source and therefore it was necessary to de-
velop Bluetooth to use less power from its belonging device. This led up to
the release of Bluetooth 4.0, also known as Bluetooth Lower Energy (BLE).
3.1.2 Bluetooth Lower Energy
BLE is a power-conserving sub-technology of Bluetooth, designed for de-

vices and machines connected to the Internet [26]. It was released 2011 along
with the new Bluetooth 4.0. Just like Bluetooth, it uses the ISM 2.4 GHz fre-
quency band to transmit signals. While Bluetooth uses 79 channels with 1
MHz bandwidth, BLE instead only uses 40 channels with 2 MHz bandwidth.
Three of them are advertising channels while the other 37 are data channels.
Advertising channels are used to discover devices and data channels are used
to communicate with the connected devices [27].
Like Bluetooth, BLE also offers the possibility of changing the output power.
For example, a low output power (between -30 dBm and -12 dBm) can be
used if the distance is short (between 1 meter and 15 meters). The most com-
mon value when setting the output power is 0 dBm which offers a distance
of up to 50 meters. When turning up the output power, the lifetime of the
battery decreases. This means it is important not to use higher output power
than needed if one wants to optimize the battery life of the device.
BLE has a modified modulation which enables it to use a 3 dBm better link
budget than Bluetooth. This means that compared to the ranges seen in table
3.2, BLE has a possible range of up to 300 meters in a clear line of sight [28].
The main difference between Bluetooth and BLE is the low power consump-
tion of BLE. This means that applications can run on the same battery for
several years.
The usage of either Bluetooth or BLE depends on the purpose. Bluetooth
can handle a lot more data, but also consumes much more battery than BLE.
BLE on the other hand is perfect to use when implementing applications
which do not exchange large amounts of data but needs the battery to last
for years [22].
3.1.3 Wi-Fi
Wi-Fi has emerged as the single most popular wireless network protocol of
the 21st century. It is mostly used to power networks at home, work or public
areas [29].
The keystone of Wi-Fi is the access point, more known as a hotspot. This is
used to let different devices connect to the network. The range of the hotspot
depends entirely of the antenna. By connecting hotspots with each other it is
possible to increase the distance significantly [30].
Wi-Fi is based on the IEEE 802.11 standard and uses radio frequency to trans-
fer data. It operates on either the 2.4 GHz or the 5 GHz frequency band de-
pending on its type.
Protocol Year Speed Frequency Band

802.11b 1999 11 Mbit/s 2.4 GHz
802.11g 2003 54 Mbit/s 2.4 GHz
802.11n 2009 300 Mbit/s 2.4 GHz , 5 GHz
802.11ac 2012 1.3 Gbit/s 5 GHz
TABLE 3.3: Overview of Wi-Fi protocols.
There are currently four types of Wi-Fi protocols used on the market. As
seen in table 3.3, the first official standard was the 802.11b protocol. Routers
that support 802.11b are not manufactured any longer but it is still the most
common protocol together with the 802.11g as they both function on the 2.4
GHz frequency band. They use transmission channels that are 22 MHz wide
which offers the 802.11b a speed of 11 Mbit/s while the 802.11g can reach 54
Mbit/s [31].
In 2008 the 802.11n protocol was designed in order to improve the 802.11g. It
allows the bandwidth to be 40 MHz wide compared to the previous 22 MHz.
This offers a speed up to 300 Mbit/s and was the first protocol to serve on
the 5 GHz frequency band. It also functions on the 2.4 GHz band since it is
backwards compatible with the 802.11g. The newest Wi-Fi protocol on the
market is the 802.11ac. It is only usable on the 5 GHz band and offers a speed
up to 1.3 Gbit/s [32].
3.2 iBeacon
The iBeacon protocol was developed and named by Apple in 2013 which is
used as a communication protocol for BLE beacons [33]. A compatible bea-
con uses BLE to transmit these advertising packets which hold information
about it. A typical packet is represented in figure 3.1.
First is a 9 bytes prefix, not enable for the user. It is followed by a proximity
UUID which are specific for the users application. It means that all beacons
F IGURE 3.1: The structure of the iBeacon protocol.
associated to a certain application share the same UUID. Later on is a Major

and Minor Value which together decide a certain beacon. The Major value
specifies a subgroup within a region while the Minor value specifies a bea-
con within a subgroup. The last part of the protocol is the Tx-Power field
which is used to calculate the distance from the beacon to the application. It
represents the Received Signal Strength Indicator (RSSI) value at 1 m. This
value depends on the hardware and changes depending on the transmission
power of the beacons [34].
3.2.1 StepInside
StepInside is a system for indoor positioning developed by Senion. Together

with their software development kit (SDK) and some beacons, it is possi-
ble to get an approximate position of smartphones indoors. The accuracy is
about 0-2 meters in 95% of the cases. This accurate positioning is calculated
by using a complex algorithm which inputs are the readings from the Blue-
tooth Beacons and other interesting data such as the smartphones sensors. A
wayfinding system can also be setup, giving a path from the user’s current
location to the wanted destination.
In order to use the StepInside system, a special kind of beacon is required.
They are small BLE devices installed on the ceiling. The lifetime of a beacon
can vary from five to eight years. If the beacon is installed in a big open
area like an airport, the signal can be of low density. The number of beacons
required is relative to the shape of the area. A large and open area with a
good line of sight only needs a few beacons. A smaller space, with corners
could need a denser coverage of beacons [35].
3.2.2 Estimote Beacons
Proximity beacons from Estimote are like the ones from Senion, small BLE
devices and are among the most popular beacons on the market [3].
F IGURE 3.2: When a device is within the range of a proximity

beacon an action is triggered.
They are transmitting continuously in small bursts. The smartphones are

constantly scanning for these signals and when it enters the range of the bea-
con, the data can be read and an action can be triggered as illustrated in figure
3.2.
3.3 Positioning Methods
When developing an IPS there are a lot of methods available to positioning

the object. The ones most used today are presented below.
3.3.1 Distance calculation
In order to calculate the distance between a smartphone and a beacon, an

equation needs to be expressed and solved. The following equation from the
Android Beacon Library [36] can be used to calculate the distance:
RSSI C2
D = C1 ∗ + C3 (3.1)
TxPower
The RSSI variable is the received signal strength indicator measured by the
smartphone when reading the beacon and the TxPower is the value of the
RSSI at one meter factory set by Estimote. The constants C1 , C2 and C3 are
dependent on the smartphones Bluetooth chip and antenna and can be calcu-
lated for a specific device [37]. The equation used in this thesis is expressed
as following:
RSSI 7.7095
D = 0.89976 ∗ + 0.111 (3.2)
TxPower
The distance D that is retrieved from the equation 3.2 is the distance from the
smartphone to the beacon used in the trilateration calculations explained in
section 3.3.3.
3.3.2 Triangulation
Triangulation is an old technique used to calculate an unknown position

given two known points. This is the same technique used by the Greeks
to calculate the radius of the Earth’s orbit around the sun [38].
This technique allows you to find your position if you know two other given
points and their belonging angles. With the knowledge of the position of a
given point it is possible to calculate the distance to it.
F IGURE 3.3: The principle of triangulation where the two cell-

phones can receive the transmitting signal and calculate its po-
sition.
sin(α) sin(β)
d=L (3.3)
sin(α + β)
By using the equation 3.3, which combines the side L and the two known
angles α and β, it is possible to calculate the distance d to the observer. This
means the relative position from the two known points and is illustrated in
figure 3.3 [38, 39].
3.3.3 Trilateration
Trilateration is, like triangulation, a technique used in order to calculate a po-

sition. While angles are crucial if you want to use triangulation, trilateration
is about measuring distances. This technique requires three known access
points (APs) and the measured distance from them to the searched device.
These distances can be measured by the RSSI value. When the positions and
the distances are known, the position of the searched device can be calcu-
lated [40, 41, 42].
This technique can however be used with more or less APs. As seen in fig-
ure 3.4 a position will be more accurate the more APs are used. If only the AP
A is used, the exact position cannot be calculated. It is located somewhere on
the circle with center A and radius being the distance from A to the device.
This is also known as proximity based positioning. The equation describing
this circle is:
d2 = (x − xa )2 + (y − ya )2 (3.4)
where d is the distance, {xa , ya } are the coordinates of A and {x, y} are the
unknown coordinates of the searched device.
Adding the AP B, it is possible to exclude all but two positions. Since both
APs A and B know their distance to the searched device it is possible to cal-
culate the two points, more particularly the two intersections of the circles. It
is also known as bilateration and the solution is obtained by solving:
d2a = (x − xa )2 + (y − ya )2
(3.5)
d2b = (x − xb )2 + (y − yb )2
where da , db are the two known distances, {xa , ya } and {xb , yb } the known
coordinates of A and B and {x, y} the unknown coordinates.
In order to calculate the exact position of the searched device, a third AP C
needs to be added. It is then possible to exclude one of the earlier computed
intersecting points and thus get a final position. This is done by solving these
three equations:
d2a = (x − xa )2 + (y − ya )2
d2b = (x − xb )2 + (y − yb )2 (3.6)
d2c = (x − xc )2 + (y − yc )2
where the two first equations are the same as in equation 3.5, referring to A
and B, and the third referring to C. One unique point with coordinates {x, y}
which satisfies this system.
F IGURE 3.4: Trilateration illustrated for one, two and three

transmitters. By adding transmitters, possible positions will be
excluded.
Using RSSI values, there is a good chance that the distances are erroneous
and could result in non-intersecting circles. The APs could also be placed so
that the circles are overlapping without intersecting with each other. Both
scenarios would result in an unsolvable equation system. Theoretically, it
means that the position cannot be calculated. There are some ways to over-
come this problem presented in section 3.4.
3.3.4 Proximity
Proximity based positioning is about locating a device depending on its dis-

tance to another device. The whole iBeacon protocol itself is about proxim-
ity [33]. The proximity method only indicates if a searched device is in range
of another device and cannot give an accurate position of it. It is still possible
to make this technique viable depending on how accurate the position needs
to be. By setting the signal strength of the BLE beacons to a small value, for
example only emitting up to a few meters, the position of the beacon could
become accurate enough.
3.3.5 Fingerprinting
This positioning method is widely used in IPS environments. This technique

is about having a fingerprint database full of RSSI readings from various APs
and potentially from other kind of sensors. Together with appropriate algo-
rithms, a device’s position can be calculated by matching its own current
readings to the ones already stored as fingerprints. This method can be very
accurate and have a good area coverage [43, 44]. In the context of this thesis,
this approach is however very difficult to use due to the fact that both the
smartphones and the beacons are moving assets. The fingerprint database
needs to be updated with new readings if the access points are moved. In
this case, that is the smartphones which are per definition mobile devices.
3.4 Positioning optimization
When using positioning algorithms, there is always a chance that the val-
ues may be miscalculated depending on if the signal somehow is disrupted.
Luckily, there are optimization methods available to avoid these and similar
kind of problems. Two of them are presented below.
3.4.1 Multilateration
The term multilateration refers to having more than three APs, increasing the
chance to get an intersection between circles, and thus finding a valid posi-
tion of the searched device. The equation system 3.6 can be further devel-
oped with additional APs. For 1 to n APs, a set of known distances d1 . . . dn
and known coordinates {x1 , y1 } . . . {xn , yn } are present in the equation sys-
tem. The only unknown is still the point {x, y}. The equation system can be
written as:
d21 = (x − x1 )2 + (y − y1 )2
..
. (3.7)
d2n = (x − xn )2 + (y − yn )2
Since there are more equations than unknowns, for n ≥ 3, the equation sys-
tem is said to be overdetermined resulting in either a unique solution when
all the distances and APs positions are perfectly matching or no solution at
all.
3.4.2 Least squares
When the measurements are not suitable for finding an exact solution to the
equation system 3.7, approximate solutions can be calculated and the best
matching solution can be found using the least squares approach [45]. The
equation system 3.7 can be rewritten in matrix form as:
AX = B (3.8)

x
where X = is the vector of unknown coordinates of the searched device,
 y 
ax1 ay1
A =  ...  is a n × 2 matrix which holds the coefficients of x and y and
 
a a
 xn yn
b1
 .. 
B =  .  is the vector holding all the constant values of the equations. The
bn
unique solution to this system is found for X satisfying:
AX − B = 0 (3.9)
If a solution to this equation cannot be found, certainly due to measurements

errors from the APs, the least square approximation is about finding the best
approximated value X b which minimizes this error. The new equation can be
written as:
AX
b =B (3.10)
Since X
b is an approximation, a vector of residual errors Re is generated:
b − B = Re
AX (3.11)
The best approximation of X b is then when the sum of Re is the smallest pos-
sible. Thus it is necessary to minimize kRe k.
A formula solving this least squares problem is [46]:
b = (AT · A)−1 AT · B
X (3.12)
which is obtained by multiplying both sides of the equation 3.10 with AT ,

the transpose of A, and by isolating X
b which can then be solved, giving an
approximation of the least square problem.
3.5 Mobile Operating Systems
The operating system (OS) is the most vital program running on smartphones.
Every phone must have a kind of OS in order to run other programs and ap-
plications.
3.5.1 Android
Android is a mobile OS originally developed by Google based on Linux and

Java. It is a product of the Open Handset Alliance’s vision for a wireless,
robust and open-source development environment. The main purpose of
designing Android was to encourage a free and open market that satisfied
both the application’s users and the software developers. The platform is
developed in a way to prevent crashes and be more fault-tolerant than its
predecessors [47].
The Linux kernel handles the core system services and operates as the layer
between the physical hardware and the Android software. The kernel han-
dles the threading and hardware interactions, such as accessing the Bluetooth
sensor. The hardware is abstracted by the Java API, making the manipula-
tion of for example Bluetooth easier for developers. The Java API framework
is regrouping many different components such as the View System and the
Resource Manager essential for manipulating the UI of the application [48].
3.5.2 iOS
iOS is the mobile OS developed and distributed by Apple. It was released

in 2007 and is used in iPhone, iPod Touch and Apple TV. It is the second
most used mobile OS after Android. The iOS SDK enables developers to
create mobile applications. It is free to download and is available for users
with a Mac computer. Combined with Xcode, the applications are written in
supported languages in either Objective-C or Swift [49].
23
Chapter 4
Use Case Scenarios
This chapter introduces three use case scenarios that are relevant for this the-
sis work. First is a case where the asset is mobile and constantly on the move.
The second is a scenario where the asset is static and is moved very rarely.
The last scenario is about a semi-mobile asset which means it can move but
also stand still.
Chapter 4. Use Case Scenarios 24
4.1 Child care in shopping malls
The first scenario is about mobile assets, for example children needed to be
localized. Shopping malls and other public places often offer services to
their visitors. One of these is to supervise customers children. This is of-
ten done by placing the children in a safe area, where they can play with
each other and participate in activities. There is however always a risk that a
child escapes or hides. By equipping them with a beacon, maybe shaped as a
bracelet, both the employees and the parents could have real time overview
over their children.
For the child to be shown in the application, it is necessary that someone
registers the signal from the beacon the child is wearing. In this case, the
crowded aspect of a shopping mall comes to great help. Everyone equipped
with a smartphone could help locate the children without actively being part
of the search. This by just letting the application run in the background of
their smartphone. But how many persons will need to have the application
activated in order to register the signal from the tracked beacon? Are the
employees good enough or do the customers of the mall also need to have
it running? And in that case, how many persons? Security and privacy are
very important aspects in this scenario.
4.2 Asset localization at events, fairs and showrooms
In the second scenario, situations with a static asset is handled. Imagine your-
self being in charge of holding a food fair. You are lending a couple of tables
to a salesman which he will use to put his berries on. During the setup, the
salesman realizes he has one table to much which he hands to a neighbor
salesman who needs it more. When the food fair is over at the end of the
weekend, the table has been passed around and no one knows where it is.
In this case the system will be in great use since it is very easy for the people
in charge of the fair to attach a beacon to the bottom of the table. Since there
are a lot of people walking around in the area, the likelihood that someone
walks by the table and register the beacon’s signal is very good. The table
will never get lost since it is very easy to use the application to see where the
table is located at all time.
4.3 Wheelchair tracking at airports
In the last scenario, semi-mobile assets are handled. It could regard finding
wheelchairs in huge areas, for example airports. They are usually very big
areas, visited by a large number of people. A typical airport is divided into
different security zones, where both employees and passengers are moving
Chapter 4. Use Case Scenarios 25
around. Wheelchairs are often used to transport a disabled passenger from

one of the airports entries to the gate.
Wheelchairs could easily be temporary lost and it can require time and en-
ergy to track them down. Fortunately they could be equipped with BLE bea-
cons and be positioned inside an application to make the search easier. Since
there are a lot of smartphones covering the biggest part of an airport, these
beacons could be located with the help of this big crowd. Even if the pas-
sengers do not want to use this application, the employees could at least all
have this application running on their smartphones. But as in the previous
scenario, is it enough having only the employees running the application or
does it need more users to cover the area?
26
Chapter 5
Method
This chapter covers comparisons between technologies and explains the choices
that have been made for this thesis. It is followed by a description of all the
tests that have been done.
Chapter 5. Method 27
5.1 Comparison between BLE and Wi-Fi
As seen earlier there are different ways to communicate and transfer wireless
data, particularly Wi-Fi and BLE. A deeper comparison between them was
necessary in order to get a better understanding for why Bluetooth was more
suitable for this thesis.
BLE and Wi-Fi have both their frequencies over the 2.4 GHz radio band. In
order for smartphones to discover these signals, they have to do scans. The
biggest difference here is the much lower energy consumption of BLE scans
compared to Wi-Fi, both for the APs and for the smartphone. This is why
BLE beacons can easily run on small batteries for years in contrast to Wi-Fi
APs which are most often hardwired. The scan duration on the smartphone
is also usually longer for Wi-Fi. This makes moving devices difficult to po-
sition accurately. The achievable range and the throughput of a Wi-Fi AP is
however much larger than a BLE beacon but this is not a necessary feature
to improve positioning. A BLE beacon is also cheaper than a Wi-Fi AP. How-
ever, in comparison to Wi-Fi APs it requires a larger number of beacons to
cover an area.
The key features of using BLE beacons are the possibility to attach them any-
where due to their small sizes and the fact that they are battery powered.
This made them perfect to use for the application developed in this thesis.
The only drawback here was the need to replace the batteries.
5.2 Comparison between positioning methods
In section 3.3, there was a more detailed description about some position-
ing algorithms. Triangulation which focuses on angles, trilateration which
works with distances and finally fingerprinting. Triangulation requires an-
gles which means dual antennas on the beacons which was not feasible. Fin-
gerprinting seemed to be a very good approach in terms of accuracy and
reliability but needs a lot of set up and calibration for the offline phase.
Since both the smartphones and the lost assets are mobile and therefore are
very likely to be moving, the calibration phase needs to be updated for each
new location. It could be done, especially with help of machine learning
algorithms but in this thesis the implementation only uses the trilateration
method. The least square optimization was used to get an approximate po-
sition when trilateration could not be calculated. The proximity based posi-
tioning method was also used in case of only one available observation.
5.3 Hardware and software
Two applications have been implemented, one for Android and one for iOS,
explained in chapter 6. The Android application was implemented using
Android Studio and Java. The iOS application was implemented using Xcode
and Swift. In order to test the applications and run the tests, a Samsung
Galaxy S6 [50] running the Android application and an Apple iPhone 7 [51]
running the iOS version were used.
5.4 Accuracy Test: Estimote Beacon
The beacons used in this thesis are not intended for measuring distance.
They are instead intended to work with proximity. The proximity would
be enough to use in this application since there transmission power on the
beacons are set to low in order to save battery. Since the transmission power
is low, the beacons range would be limited. This means that when someone
is within the range of the beacons transmission signal they would be close
enough to the beacon in order to find the asset it is attached to. It was im-
portant for us to test the hardware of these beacons. If a beacon is configured
to reach out to a certain range, it needed to be confirm that the actual range
was the same. Otherwise there could be complications with the calculations
of the position of the beacon. Even though the beacons were not intended to
measure a distance, experiments where comparisons between the measured
distance and the actual range of the beacon were made.
The tests were done on 3, 5, 7 and 10 meters. They were done with three dif-
ferent transmission powers: -8db, -12dB and -16dB. All these tests were also
made on two beacons to exclude the conclusion of a hardware malfunction.
Tests were also made on an Android and on iOS in order to see if one plat-
form was better suited for this kind of applications or not. The RSSI value
used to calculate the distances had the standard factory settings.
5.5 Accuracy Test: Application
In the previously mentioned test, the accuracy of the beacon alone was tested.
In this test, the focus was instead on the localization algorithm of the appli-
cation. The test was done in a 25m ∗ 15m large area with 4 smartphones
which ran the application, two iPhone 7 and two Samsung S6. The setup is
illustrated in figure 5.1.
F IGURE 5.1: The specified path.
The devices were placed in every corner of the rectangular space. A specified
path was then walked while holding the beacon. The TxPower of the beacon
was set to −12dB as a good compromise between range and battery con-
sumption. This means that the theoretical maximum range was about 15m.
The difference between the walked path and the actual path is illustrated in
section 7.3.
5.6 Simulation of application usage
To find out how many people who need to run the application in background
mode in order to catch the signal from the lost asset, a JavaScript program
was made which simulates a search for the asset. It was applied to match
two of the three different scenarios described in chapter 4, the ones with the
mobile and static asset. With the results from those tests it was possible to
make a discussion about the third use case, semi-mobile assets.
As illustrated in figure 5.2 the program consists of a grid which represented
the area of where the system was used. An important aspect is that the sim-
ulation uses a generic environment. It can be compared with an open field
with no walls, no furnitures or no other obstacles. Disturbances from other
transmitting devices that could affect the search were not considered either.
The asset and a certain number of users (representing e.g. the visitors at a
fair) were randomly placed on the grid. The program randomly moved the
users one step at a time until one of them reached the range of the asset (15
meters were chosen). The simulation started with only one user and the steps
F IGURE 5.2: A simulated test environment where the listeners

and the sender were randomly placed on the grid. They moved
randomly until one listener found the sender.
until it reached the asset were counted. One user at a time was then added at
every run until a reasonable result of the simulation was reached. Each sim-
ulation was run 100 times and the mean value of the amount of steps it took
until the first user found the asset was returned. The result was considered
good enough when the first user found the asset within 10 seconds.
5.6.1 Scenario 1 - Finding lost child in a mall
In the first scenario there was a matter of locating mobile assets. The situation
could be about a child which got lost during a visit at a mall. The users as
well as the asset representing the child were randomly moved during the
simulation. The grid size was set to represent the size of IKEA in Uppsala
which has an area of 36000 m2 [52].
5.6.2 Scenario 2 - Finding a lost table at a trade fair
In the scenario with static assets, the simulation was set to represent a visit
at a food fair where a rented table could be lost. It means that the users
were randomly moved, but the asset symbolizing the table was static during
the whole simulation. The area of Stockholm International Fairs & Congress
Center, which is the largest trade fair in Sweden, is set to 40000 m2 [53], but
the grid size was still set to 36000 m2 which was used in the mobile scenario.
By doing this, it would be easier to compare the results and make better con-
clusions.
5.7 Battery Performance of the Application
The battery time on todays smartphones is an important aspect to consider

when implementing an application. It was therefore important to have a
look at the battery usage of the application. People would not use it if the
battery consumption is too high. A performance test was done using the
application GSam Battery Monitor available at Google’s Play Store. First a
battery performance test was done with the application running and later
a test with the application shut down. The worst case scenario regarding
performance was used. That is, when the application continuously senses
a beacon and sends the gathered information to the online database. The
overall battery usage was observed, but also subparts as Wi-Fi and Bluetooth.
5.8 User Centered Survey
As mentioned before, the developed application comes in use in three differ-

ent scenarios. The keystone of the system is the crowd-sourced localization
aspect. It means that if no one uses the application, the tracking part of the
system would not work. Therefore, a survey was made with the three scenar-
ios in mind. Before answering the questions, the participants were informed
that the application would use around 10% of the battery life of the smart-
phone per hour, as seen in the results in section 7.5. With the help of social
medias as Facebook and Slack, the following questions were sent out:
• Have you ever used an application with IPS?
• Scenario 1: Would you as a visitor, at IKEA etc. be willing to start their
application and let it run in background mode during your visit in or-
der to help locate lost children?
• Scenario 2: Would you as a traveler at an airport be willing to start their
application and let it run in background mode in order to help locate
lost wheelchairs? (At airports, a lot of wheelchairs disappear, which
requires a lot of time for the staff to locate.)
• Scenario 3: Would you, as a visitor to a trade fair or department store,
be ready to start their application and let it run in background mode in
order to help other people locate their shopping carts with goods that
have been lost?
• If you not would be willing to start the application due to the energy
consumption, is there anything the company can do to get you to do so?
For example, give any kind of discount, if you start the application?
In the first questions, the participants could answer "Yes" or "No". The last
question allowed them to write a smaller text with suggestions that could
make the participants use the application.
32
Chapter 6
Implementation
This chapter handles the technical implementation of the application. First

out is an illustration of the environment where the application is used. It is
then followed by system architecture, positioning algorithm and user inter-
face.
Chapter 6. Implementation 33
6.1 Illustration of the IPS environment
The figure 6.1 illustrates a basic scenario of the IPS system. The BLE beacons
located on the ceiling are used to position the user relative to the room. The
chair represents the lost asset with a beacon attached to it. The user to the
right, holding a smartphone and running the application, is able to see the
beacon and send this information to the database represented in the center
top of the illustration. The second user to the left, willing to find the lost chair,
can then retrieve the data stored in the database. The position of the chair is
finally shown in the application running on the second user’s smartphone.
F IGURE 6.1: Illustration of the IPS environment.
6.2 Operative system
The Android operative system was used in this thesis to build the prototype
application. Android is capable of interacting with the iBeacon protocol since
BLE has been available on Android 4.3 (API level 18). An iOS version, with
less features was also made, as Android and iOS both support BLE and that
Estimote SDK and Senion SDK are available on both platforms. The iOS ver-
sion is only capable of positioning itself, listening for beacons and storing the
readings to the database. But it was sufficient in order to make a comparison
in terms of BLE and iBeacon performance between these two operative sys-
tems. The choice was made to use Android as the main application as it is
the most widely spread operating system among smartphones.
6.3 Android and BLE communication
In order for the BLE to be enabled in the Android application, it must ask the
user to accept the BLUETOOTH and BLUETOOTH_ADMIN permissions.
The application can then perform various actions as discovering BLE bea-
cons, reading iBeacon data and measuring RSSI values. This built in API has
useful functions to search for beacons. A BLE scan is an asynchronous oper-
ation and is done by using startLeScan() to start the scan and stopLeScan() to
stop it after a predefined amount of time [54].
The two different beacons providers, Senion and Estimote, are both provid-
ing their own Android SDK which includes various BLE scanning alterna-
tives optimized for their own type of beacons.
6.3.1 Estimote SDK
Estimote has developed their own SDK in order to make the use of their bea-
cons more natural for developers. The main features are beacon monitoring
and beacon ranging. These are two different ways to listen for beacons. Mon-
itoring is a passive listening mode with low energy consumption but slow
scan rates. Ranging is on the contrary fast scans to collect as much informa-
tion as possible. Ranging is therefore useful to get a more accurate localiza-
tion but monitoring can be used to detect beacons before starting ranging in
order to reduce the power consumption of the application. The scan peri-
ods for both methods can also be parametrized in terms of scan duration and
wait time between two scans. Beacon scanning is an Android service letting
it run in a background thread, thus not blocking the main thread responsible
of the UI [55].
6.3.2 StepInside SDK
StepInside is the SDK developed by Senion which is optimized for their own
beacons. The two main components used in this thesis were the Positioning
API and the Wayfinding API. The Positioning API is used to get the position
of the smartphone in term of longitude, latitude and floor number. It is also
possible to get information about the direction the user is facing or if a po-
sition is available or not. The Wayfinding API is about finding a path from
one location to another. When an Estimote beacon is located, the Wayfinding
API can calculate the shortest path from the user’s location to the beacon.
These functions were also used as an Android service, doing their work in
the background [56].
6.4 Google Firebase
Firebase is a web platform developed by Google. This system, part of the

Google Play Services, offers various features which can be put together de-
pending on the users need. Two of them were used in this thesis.
6.4.1 Firebase Realtime Database
Firebase Realtime Database is a NoSQL database hosted in the cloud which

provides developers an API that allows data to be stored and synchronized
between different users and on various platforms in realtime [57]. By sending
JSON formatted data, information can be sent and retrieved in just a few
milliseconds.
It was an important part of the application to permitting the positioning data
to be shared between users in realtime.
6.4.2 Firebase Authentication
Firebase Authentication enables developers to integrate a robust and secure

authentication system with just a few lines of code [58].
It was used in the application to register new users by using the simple
email/password registration method, and to handle their login. This was
useful to differentiate the users, one from another, in order to have the trilat-
eration algorithm working properly.
6.5 System Architecture
The system is composed of different components. One central Android ap-

plication is responsible for different activities. It is listening and reading data
from both the Senion beacons and the Estimote beacons. When data is found,
it is sent to Firebase. Later on, when data is needed, the application can re-
trieve it from the database. An overview of the system is presented in fig-
ure 6.2.
F IGURE 6.2: System architecture.
Inside the application, there are some activities responsible for different parts
of the system. The entry point of the application is the MainActivity. When
the application starts, it will first check if the user is logged in or not. De-
pending on the result, two different actions can be made. If the user is not
logged in, the LoginActivity starts. The purpose of the LoginActivity is, as
the name reveals, to authenticate the user. If the user is not registered yet,
the RegisterActivity starts to let the person create an account by entering its
email and password. Then, back to the LoginActivity, the same credentials,
email and password, have to be entered in order to be authenticated to the
application. After this, the user is able to enter the heart of the application:
the AssetFindingActivity. This activity is the second action reachable from
the MainActivity if the user already is logged in.
The AssetFindingActivity mainly tries to get a location of the user using the
StepInside SDK. It also listens for Bluetooth signals from the Estimote bea-
cons, using the Estimote SDK. An asset is said to be found when a user has
a valid location and senses an Estimote beacon signal. The DatabaseHandler
is responsible for storing and retrieving this data.
Another aspect of the AssetFindingActivity is to search for an asset and get
a route to it. The NavigationHandler regroups the functions needed to find
a path from a user to an asset.
The application’s UI is mainly a map of a building showing the user’s posi-
tion. This position is rendered by calling function on the MapView.
The main flow of the application is shown in figure 6.3.
F IGURE 6.3: Overview of the application.
6.6 The BeaconInfo object
The BeaconInfo object is used to store the information about a beacon when
it is seen.
L ISTING 6.1: The BeaconInfo object.
public class BeaconInfo {
public long lastSeen ;

public double longitude ;
public double latitude ;
public double errorThreshold ;
public String floorId ;
public String beaconColor ;
public HashMap < String , BeaconInfo > trilateration ;
}
As seen in listing 6.1, this object holds useful information for positioning a
beacon. The position of a beacon is expressed with the longitude, latitude
and floorId data fields. The errorThreshold is used to store the distance in
meters between the beacon and the user. This value is computed from the
RSSI and the TxPower read from the beacon. The time of the observation
is stored in the lastSeen field. The beaconColor field is used to differentiate
a beacon from another, in that case by its color. The trilateration field is a
hashmap used to store observations done by different users. The key is the
userID a user gets by the authentication process and the value is a BeaconInfo
object. Later on this field is used by the positioning algorithm to compute a
position with the trilateration technique. The constructor of a BeaconInfo
object needs the time of the observation, the position (latitude, longitude and
floorId) and the distance of the observation from the beacon.
6.7 Positioning algorithm
When a user wants to find a beacon, a couple of operations must be done be-
fore showing its location on the map. First the information about the beacon
stored in the database needs to be downloaded. This data is then used as an
input to the positioning algorithm shown as pseudo-code in listing 6.2.
L ISTING 6.2: Positioning algorithm.
1 i n p u t : User U, BeaconInfo . t r i l a t e r a t i o n BeaconList , Time T , Map M
2 output : Path from User t o Beacon
3 begin
4 s e t T t o c u r r e n t time
5 set validObservations to { }
6 set Destination to null
7 s e t Path t o n u l l
8
9 f o r e a c h BeaconInfo B o f B e a c o n L i s t
10 i f B . l a s t S e e n > T + 10
11 exit
12 else
13 v a l i d O b s e r v a t i o n s . Add( B )
14 end i f
15 end f o r e a c h
16
17 i f l e n g t h v a l i d O b s e r v a t i o n s == 1
18 s e t D e s t i n a t i o n t o p ro xi mi ty ( v a l i d O b s e r v a t i o n s )
19 else i f length validObservations > 1
20 set Destination to t r i l a t e r a t i o n ( validObservations )
21 end i f
22
23 i f D e s t i n a t i o n not n u l l
24 s e t Path t o Wayfinding (U, D e s t i n a t i o n )
25 end i f
26
27 i f Path not n u l l
28 M. Draw ( Path )
29 end i f
30
31 end
The beacon data is used to decide which positioning technique that will be
used, depending on how many valid BeaconInfo objects the beacon has at
that moment. A BeaconInfo is valid if the time of the observation is not too
old. The time window is represented as a variable that should be adjusted
depending on the scenario. For example, with a time window of 10 seconds,
all observations done within the current time + 10 seconds will be used by
the algorithm. Depending on the number of valid observations different ap-
proaches are taken. If only one observation is available, the proximity func-
tion is used as explained in section 3.3.4. For two or more observations, tri-
lateration is used to improve the position accuracy of the beacon. The trilat-
eration function was implemented as the multilateration method explained
in section 3.4.1. The least square optimization explained in section 3.4.2 was
used to get an approximate position when the real position could not be cal-
culated by using only the multirateration formula.
After getting a position from one of these approaches, a path from the user’s
position to the beacon is computed by the the wayfinding function available
in the StepInside SDK. It generates an array of coordinates that can be drawn

on the map to help the user get to its destination.
The final step of the positioning algorithm is to draw the beacon’s position
and the path to it on the map.
6.8 User Interface
The application’s main user interface is a map of Valtech’s building. There

are also a start view, a login view and a register view.
( A ) Start view. ( B ) Login view. ( C ) Register view.
( D ) Main view. ( E ) Item selection menu. ( F ) Position of beacon.
F IGURE 6.4: User interface of the application.

The map can be moved and rotated by touch events. Three different modes
are also available: one when the map auto-rotates with the smartphones gy-
roscope, another following the user’s location without auto-rotation, and a
third fixed mode which lets the user move and rotate the map by himself.
A menu located at the application’s TopBar provides actions for finding bea-
cons as well as logout.
6.9 The iOS implementation
The iOS implementation was done in Swift since both Senion and Estimote
provided their SDK for Swift. This application was implemented in order to
test the accuracy of the distance measurements in comparison to the Android
version. The application is able to locate the user using Senion’s SDK, listen
and read from the tracked beacon using Estimote’s SDK and to calculate the
distance between the smartphone and the beacon. The distance was then
sent to the Google Firebase with the same structure as the BeaconInfo Object
presented in section 6.6. The Google Authentication and Firebase database
were the anchors for letting us create this cross platform environment. Both
applications could easily store and retrieve data from both Android and iOS
users. The positioning algorithm was not implemented on iOS, neither were
the login and register functions. They were only implemented on the An-
droid application since Android was the main focus.
41
Chapter 7
Results
This chapter presents the results from the various tests done in the method.
First, the accuracy result of the Estimote beacon is presented. It is followed by
the accuracy test of the application itself. Later on, the result of the tracking
simulation is shown. The battery usage is reviewed before the result from
the user survey is presented.
Chapter 7. Results 42
7.1 Performance tests on Android
In order to evaluate how the Estimote beacons performed, eleven measure-

ments with different parameters were done as explained in section 5.4. Three
different TxPower values corresponding to the maximum ranges that the
beacons can achieve in theory were used. From the lowest to the highest:
-16dB corresponding to 7m range, -12dB to 15m and -8dB to 30m. The bea-
con was placed at four different distances from the smartphone: 3m, 5m, 7m
and 10m. All tests were running for 2 minutes each. The test application was
reading data from the beacon each second.
7.1.1 Performance test 1: comparison of different TxPower

settings
The first test is shown in figure 7.1. The dashed red horizontal lines are show-
ing the real distance between the smartphone and the beacon. The dashed
red vertical lines indicates when a new test was done, increasing the distance
between the smartphone and the beacon.
( A ) TxPower: -16dB. ( B ) TxPower: -12dB.
( C ) TxPower: -8dB.
F IGURE 7.1: Performance tests for different values of TxPower:

(a) TxPower set to -16dB corresponds to 7m range. (b) TxPower:
-12dB (1̃5m range). (c) TxPower: -8dB (3̃0m range).
In the first test, it is possible to distinguish that the measured distance be-
tween the smartphone and the beacon, represented by the solid blue curve,
was not matching the real distance. The distance was almost always underes-
timated which could be explained by the fact that the standard RSSI settings
provided by Estimote Beacon was used. The value of RSSI at one meter could
be calibrated thus improving the results [59].
The other interesting observation that could be done was the number and
intensity of the fluctuations. This showed that the measurements were quite
instable which also impacted the accuracy negatively. The fluctuations could
be explained by the fact that the Bluetooth signal could be affected by mul-
tipath and path loss [60]. In this scenario though, the smartphone and the
beacon were in line of sight, without any obstacles between them, so path
loss should not be present. The room used when doing the measurements
was however quite small which could be leading to multipath propagation
problems.
7.1.2 Performance test 2: comparison of two beacons
In the second scenario, the tests had the same setup as the previous ones but
each test was done on two different beacons. Figure 7.2 shows how the two
beacons differ one from the other.
F IGURE 7.2: Two beacons (dotted blue and solid green lines)
are compared for different values of TxPower: (a) TxPower set
to -16dB. (b) TxPower: -12dB. (c) TxPower: -8dB.
The second test was done in order to evaluate the beacons performance com-
pared to each other. If one beacon would perform much better than another,
it could point out a possible hardware failure. As seen on the graphs that
was not the case, even if the curves differs a bit. The differences can be ex-
plained by the fact that the measurements were not done simultaneously, but
one beacon after the other. Taking median and mean values of the measure-
ments with durations longer than the actual 2 minutes could remove noise
and make the two beacons more alike.
7.2 Performance Test on iPhone
The tests were also done on the iPhone application. Figure 7.3 shows how
the iPhone performs for the different TxPower values.
F IGURE 7.3: Performance tests on iPhone for different values

of TxPower: (a) TxPower set to -16dB corresponds to 7m range.
(b) TxPower: -12dB (1̃5m range). (c) TxPower: -8dB (3̃0m
range).
The third test was the one giving the best results even if the measured dis-
tance was still underestimated overall. The measured distance was increas-
ing in relation to the real distance notably in figure 7.3b. The fluctuations
were also less intense, which gave more stable distance estimations. The dif-
ferences in performance compared to Android in the first test is discussed
later on in section 8.2.
7.3 Performance test: positioning accuracy
The accuracy of the positioning algorithm is shown in this test. The figure 7.4
illustrates the real walked path with the beacon in hand, compared to the
measured path registered in the application. The beacon was walked from
the point 0 followed by passing 1, 2, 3 and 4 before heading back to 0 at
a constant slow walking speed, represented by the dotted black line. The
readings were saved continuously resulting in the solid red line on the figure.
F IGURE 7.4: The registered path (filled red line) in contrast to

the real one (dotted black line ).
It is possible to distinguish that the registered path is not reflecting the real
path. The walked path was done in a 25x15m large area with walls and fur-
nitures impacting the quality of the readings between the smartphones and
the beacon. The smartphones located at point 1 and 4 were able to read from
the beacon at larger distances than expected, resulting in the inaccurate path
between point 2 and 3.
One of the main goals in this thesis was to try estimating how many users
that would have to use the application in order to find the lost asset. Try-
ing to answer that question, a simulator using JavaScript was created. The
simulator consists of a grid with randomly placed users and a lost asset. The
concept was to count the numbers of steps it took for the users to reach the
asset. Users were added until the first one could find the asset in a reasonable
amount of time (within 10 seconds). Two different scenarios was used, one
with a mobile asset and one with a static asset.
When converting the steps to time, it was needed to do some assumptions.
According to Raymond C. Browning, people tend to walk in a speed of 5.0
km/h [61]. This is equal to 1.2 m/s. Knowing that a normal step is a little
less than a meter, and that people probably do not reach the speed of 1.2
m/s when shopping in malls (they stop pretty often to look at clothes and
other goods), it was safe to assume that 1 step corresponds to 1 second in the
simulations.
Scenario 1: Finding a lost child in a mall - Mobile asset

Number of users Number of Steps Corresponding time
1 20 321 338 min 40 sec
5 2436 40 min 36 sec
10 1053 17 min 33 sec
15 524 8 min 44 sec
20 309 5 min 9 sec
30 219 3 min 39 sec
40 70 1 min 10 sec
50 36 36 sec
60 18 18 sec
80 8 8 sec
TABLE 7.1: Scenario 1: Time elapsed for finding the lost asset
for different numbers of users.
Scenario 2: Finding a lost table at a trade fair - Static asset.

Number of users Number of Steps Corresponding time
1 36588 609 min 48 sec
5 6130 102 min 10 sec
10 2082 34 min 42 sec
15 765 12 min 15 sec
20 530 8 min 50 sec
30 359 5 min 59 sec
40 172 2 min 52 sec
50 78 1 min 18 sec
60 58 58 sec
80 22 22 sec
100 9 9 sec
TABLE 7.2: Scenario 2: Time elapsed for finding the lost asset
for different numbers of users.
As seen in table 7.1, the application required 80 users to get a good result if
the lost asset was moving. If the asset was static, the application required 100
users to find the asset in the same area, as seen in table 7.2.
These results can be visualized in another more general way, with the help of
the following calculations:
• 36000/80 = 450m2
• 36000/100 = 360m2
showing that the system would need 1 user per 450m2 for locating a mobile
asset and 1 user per 360 m2 for a static asset.
7.5 Performance Test: Battery Usage
To promote the application it was important that the battery usage was good.
Therefore, two tests were made. One with the application running and one
where it was not running. The tests were ongoing for 60 minutes. The overall
battery usage of the smartphone was measured, but also subparts as Wi-Fi
and Bluetooth. The results are presented in table 7.3.
Battery Usage Application Running Application Not Running

Overall ~12% ~3%
Wi-Fi 6% <1%
Bluetooth <1% <1%
Screen 2% 2%
Applications 3% <1%
TABLE 7.3: Battery performance test of smartphone during 60

minutes.
The results showed that the application used 9 % more battery per hour if the
application was running compared to if it was not. It was also possible to see
that it was the Wi-Fi that consumed the most battery during the tests, which
are mainly used for the database storage and retrieving operations.
7.6 Survey Results
An important aspect of this thesis was to get an input from smartphone users.
Would a user be willing to start the application and let it run in background
mode in order to help gather positions of the lost assets? The survey was
shared fon social medias like Facebook and Slack. 81 participants completed
the survey. The results are displayed in figure 7.5.
No No
23.5%
76.5%
76.5%
23.5%
Yes Yes
( A ) Have you ever used an applica- ( B ) Are you willing to run the appli-
tion with IPS? cation in order to help locate lost chil-
dren?
No No
56.8% 53.1%
43.2% 46.9%
Yes Yes
( C ) Are you willing to run the ap- ( D ) Are you willing to run the ap-
plication in order to help locate lost plication in order to help locate lost
wheelchairs at e.g. airports? shopping carts with goods in malls?
F IGURE 7.5: Survey results represented as pie charts.
The last question of the survey was the following: "If you are not willing
to start the application due to the energy consumption, is there anything a
company could do to change your mind?"
A lot of different answers and ideas to this last question were received. They
are summarized them below:
• Lower the battery consumption.
• The company should offer some kind of discount to the users running
the application.
• Offer free Wi-Fi to the ones using the application.
• Expand the application to show where e.g. groceries are placed in a

store.
• Save the map of an airport in order to use it in offline mode when low
on battery. This would enable to guide yourself around the airport even
when offline.
• Malls can offer free charging stations.
• The company could give away money to charity if people would use
the application.
52
Chapter 8
Discussion
In this chapter, various aspects of the results are discussed. First, the accu-
racy results from the experiments are discussed. It is followed by discussions
about the differences between Android and iPhone. After that, the discus-
sions about the output from the tracking simulation are made. Last, the user
survey is discussed.
Chapter 8. Discussion 53
8.1 Experimental Discussion
Two different kind of accuracy measurements were made. The first test only
had focus on the beacon itself, while the second test was about the accuracy
of the application. The results are discussed below.
8.1.1 Distance measurements
The experiments with the Estimote beacons showed that they are unreliable
for getting the distance between the smartphone and the beacon. First we
tested the application on the Android platform. Moving the beacon at dif-
ferent ranges from the smartphone did not affect the measurements as much
as we hoped for. It stayed on a certain level even if the distance is chang-
ing from 3 to 10 meters. We tried two different beacons in order to exclude a
hardware malfunction but the results were also unreliable on the second one.
The results were a little bit improved when running the tests on an iPhone.
When we moved the beacon further away from the phone, it also increased
the calculated distance. Even though it was not a good output, it gave us at
least some kind of information that the beacons were moved and the calcu-
lated graph followed the same shape as the actual distance graph.
These results prove that the beacons are preferably used for proximity. The
application can sense the beacon but cannot provide a good accuracy. The
most important thing in our application, is that the smartphone senses the
beacon. If the beacon is set to transmit signals up to 10 meters, it is necessary
that the smartphone is able to sense the beacon up to that distance. According
to our result, the smartphone always sense the beacon, which is what we are
looking for. This is good enough since we want to get noticed when someone
is close enough to the beacon. When reading from several users, it is possible
to use trilateration to get a more accurate position.
8.1.2 Positioning Accuracy
Another test was made, walking with the beacon in hand for a decided path.
This test was meant to test the accuracy of the implemented positioning al-
gorithm. As seen in the results, the accuracy was a bit uncertain. This is due
to the uncertain distance measurements from the beacon. Depending on the
scenario, if the tracked asset is big enough, we think that the accuracy pre-
sented here could be sufficient to find the asset by visually looking at it when
being close enough. In other scenarios, it could be problematic.
If the program gets three wrong values, the resulting trilateration position
is hard to calculate. The least square optimization still helped a lot for cal-
culating the positions, without it, many calculation were resulting in very
erroneous results.
Instead of showing a point on the map, which could be misplaced, the ap-
plication could show a zone where the beacon could be located. By using
a graphical aid, the user could search a zone rather than going to a wrong
position. The trilateration algorithm would need to be rewritten to calculate
a zone instead of a single coordinate. The size of this zone could be adjusted
depending on the number of observations and the likelihood of getting in-
correct measurements.
8.2 Android vs iOS
A recent study [62] shows that Android RSSI readings tends to fluctuate
more than for iOS, impacting the accuracy of positioning negatively. On the
other hand, iOS has RSSI drops corrupting distance estimations. These ef-
fects could be hardware and software related.
In our tests, we could observe similar fluctuations on Android but we did
not get noticeable RSSI drops on iOS. It would be interesting to conduct a
deeper hardware and software study to understand why these effects exist
but it will require a large number of different devices and test scenarios.
As stated in chapter 4, our application is intended to handle three different

scenarios, all depending of the mobility of the asset. To understand how the
scenarios are impacting the amount of users needed, we simulated a search
for a lost asset by using a JavaScript program. The results given in section
7.4 shows us that when looking for a mobile asset, 80 users need to be using
the application for a search area of 36000m2 to get a fast enough response,
corresponding to 1 user per 450m2 . When it is a matter of a static asset, 100
users are needed, or 1 user per 360m2 . These results proves that it is a larger
probability to find a mobile asset than a static, which is something we found
interesting.
As we mentioned in section 5.6, we only simulated the scenarios with a mo-
bile and static assets. It was hard to do a simulation which handled the sce-
nario with a semi-mobile asset which was randomly moving or being static.
We think that it was easier to compare the mobile and static results, and in
that way get an estimated result regarding the semi-mobile asset. Since the
results showed differences between mobile and static assets, we can state that
the semi-mobile asset scenario would need an amount of users between 80
and 100.
Another important aspect to consider when observing the results is that the
number of users needed is a worst case scenario. The simulation starts from
scratch with the users and the asset randomly placed. Considering the sce-
nario of a lost child, when a parent notice that their child is missing, they
would start our application to find out where the child is located. According
to our results, from the moment they open the application, there are required
to be 80 users running the application in order to find the child in about 10
seconds. However, in a real life situation the child would probably have
crossed some users before it got lost. The parents can therefore always see
the last known position of the child as soon as they start the application. To
sum up, the parent can probably get an instant hint about where the child
is. But in a worst case scenario, it would take about 10 seconds to get infor-
mation about the child’s whereabouts, which is stated from the result of the
simulation.
The number of users that needs to use the application can be increased as
well as decreased depending on the beacon’s range. Setting the beacon’s
signal to a greater range, less users would be needed but the accuracy of the
readings and the battery life of the beacons would be impacted negatively.
This trade-off is important to have in mind depending on where the system
is intended to be used.
As mentioned earlier, the simulation uses a generic environment with no ob-
stacles such as walls and furnitures. Disturbances that could affect the cal-
culations of the distance to the asset, such as other radio waves, is not con-
sidered either. This means that the environment of the simulation can not
be compared to the environment in a real life situation at a mall or a fair etc.
With this in mind can the number of users mentioned above be accurate if we
want to track down lost items at an open field, but otherwise are they quite
meaningless. The only thing the numbers are telling us, is that it takes more
users to find a static item than a mobile one.
8.4 Survey
From our survey it is first possible to see that about 1 out of 4 are familiar
with an IPS and have used an application which applies that technology.
Later on it is clear that people are more willing to let the application run
in the background if it serves to help other people rather than a company.
As seen in Scenario 1, 3 out of 4 are ready to use this application if it could
prevent children to get lost in malls etc. If the intention of the application
instead is to help the company, the rate drops significantly and only a little
bit more than 4 out of 10 would be willing to start the application.
There are yet actions the companies can do to make their customers help
them locate their goods. By reading the comments from the survey it is clear
that people could change their minds regarding using the application if they
could get some profit from it. For example, a lot of the people who answered
"No" would start using the application if they get a discount, get access to
free Wi-Fi or could get any other kind of advantages. We believe that the
companies are ready to offer such advantages to the users of the application.
By doing that, we think that the number of people who are willing to use our
application can increase to 8 out of 10 people.
As we mentioned in section 5.8, the survey was posted on Facebook and
Slack. This means that the participants who answered the survey were friends
and colleagues. Two important demographic information impacting the sur-
vey is that the participants age ranged from 20 to 60 and that at least half of
them have IT background. The survey can therefore not be that representa-
tive.
57
Chapter 9
Conclusion
This chapter concludes this thesis by looking back at the problem statement
and attempting to draw conclusions according to it. Some ideas of future
work are also discussed.
Chapter 9. Conclusion 58
9.1 Combine an earlier known IPS approach with

crowd-sourced localization
The aim of this master thesis was to investigate and develop a new approach
of an IPS which tracks down a lost object and relies on the users of the appli-
cation. Was it possible to use only cheap BLE beacons and then let the more
expensive parts of the system be the users smartphones? To make this pos-
sible, we needed to combine an earlier approach of an IPS, where a user can
be positioned relative to the room, and combine it with the crowd-sourced
localization technique. In addition to this, we needed to evaluate how many
users were required to run the application in order to get a fast and reliable
result.
By measuring the accuracy of the beacons, it was possible to see how accurate
the application would turn out to be. Unfortunately, the beacons used in
this master thesis are intended for proximity and not range, which gave us
uncertain results.
Besides testing the accuracy of our application, we also needed to find out
how many users it would take to find the lost asset in a reasonable amount of
time. It would be hard for us to find enough volunteers to help us accomplish
the tests in a real environment. Instead, we built a program which simulated
the search. We found out from the simulation that it required 80 users in a
36000m2 area, which is equal to 1 user per every 450 m2 , to get a position
of a lost mobile asset in less than 10 seconds. If the asset instead was static,
it required 100 users, which is equal to 1 user per every 360 m2 . Worth to
mention is that the environment in the simulation is generic and have no
obstacles at all. This means that the number of users needed to find the asset
can be accurate if the system is used in an open field, but otherwise not.
In addition to testing the software of our application, it was also necessary to
do a user survey to see if people would be willing to run the application in
background mode on their smartphones. If no one would use it, the whole
concept of our work falls apart. The result showed that about 8 out of 10
would be willing to run the application, if its cause was to help other people
finding things they had lost. If the cause of the tracking was instead to help
a company find their lost assets, only a little less than the 50% would run
the application. However, if the company started to give advantages to the
users using the application, most of them who answered "no" in the first place
could change their minds. Important to remember is that the results from the
survey are not representative since the people answering to it are in our own
age and have similar interests.
Our conclusion is that we know that the application works and fulfills our
preconditions, if enough people use it. Even though it does not always give
an exact position due to unreliable accuracy, it is good enough to give the
user a hint of where the lost asset is located.
Chapter 9. Conclusion 59
9.2 Future Work
The accuracy to get a user’s position relative to the room is very good thanks
to existing technology. The hard part has been to get a good accuracy of a lost
asset relative to the user. As stated earlier, the beacons attached to the assets
are not meant to return an exact distance, they instead work with proximity.
This is the main cause of the unreliability of the accuracy in our tests.
Besides this proximity beacon, Estimote also provides location beacons. This
leads to the first possible extension of this thesis, replacing the current bea-
cons with these location beacons. Since they are developed to track real-time
positions, it would most certainly give us a more accurate position of our lost
assets.
Further on, the application has only been developed as a prototype which
only has maps of our office. Since the area is small, it has been hard to make
accurate conclusions about how many people who have to to use the appli-
cation in order to get the system work properly. This is why we created a
program which simulated the use of the application.
The simulator was built in a generic way which generated unrealistic results
for real life situations. An improvement here could be to use existing network
simulators combined with different human mobility models. For example
the simulation could take into account additional parameters impacting the
wireless signals such as walls and interferences combined with a human mo-
bility model simulating a walk in a store with a predefined path but with
random stops and pace. The resulting simulation would be more realistic
and different scenarios could be simulated and tested. Instead of simulating,
another way is to test the application in a real environment with real users.
This is an interesting and important investigation to make that will provide
additional results to the ones from the simulations.
In order to help overcome the accuracy problems of the system, audio or
visual helps could be installed on the lost assets. Instead of searching for the
object only with the help of the application, a signal like an alarm or flashes
could be triggered when the user searching for the asset is close enough to it.
The usability of the system could be greatly increased without having to find
a way to increase the accuracy.
60
Bibliography
[1] GPS. Accessed: 2017-06-14. 2017. URL: http://www.gps.gov/.

[2] Juan Pablo García-Vázquez Ramon F. Brena et al. “Evolution of Indoor
Positioning Technologies: A Survey”. In: Journal of Sensors, vol. 2017
(2017).
[3] Estimote Beacons. Accessed: 2017-07-02. URL: https://estimote.com.
[4] Indoor positioning system. Accessed: 2017-06-14. URL: https://senion.
com/indoor-positioning-system/.
[5] Trackr. Accessed: 2017-06-14. URL: https://www.thetrackr.com/.
[6] Senion. Accessed: 2017-07-08. URL: https://senion.com.
[7] Pat Banerjee Hui Liu Houshang Darabi and Jing Liu. “Survey of Wire-
less Indoor Positioning Techniques and Systems”. In: IEEE TRANSAC-
TIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLI-
CATIONS AND REVIEWS, VOL. 37, NO. 6, NOVEMBER 2007 (2007).
[8] John K. Pollard Sheng Zhou. “Position Measurement using Bluetooth”.
In: IEEE Transactions on Consumer Electronics ( Volume: 52, Issue: 2, May
2006 ) (2006).
[9] Milan Herrera Vargas. “INDOOR NAVIGATION USING BLUETOOTH
LOW ENERGY (BLE) BEACONS”. In: TURKU UNIVERSITY OF AP-
PLIED SCIENCES (2016).
[10] Kyandoghere Kyamakya Silke Feldmann et al. “An indoor Bluetooth-
based positioning system: concept, Implementation and experimental
evaluation”. In: International Conference on Wireless Networks (2003).
[11] Tengqingqing Ge. “Indoor Positioning System based on Bluetooth Low
Energy for Blind or Visually Impaired Users”. In: KTH Royal Institute of
Technology (2015-10-19).
[12] Behrang Parhizkar Arash Habibi Lashkari and Mike Ng Ah Ngan. “WIFI-
Based Indoor Positioning System”. In: Second International Conference on
Computer and Network Technology (2010).
[13] Binghao Li Thomas J. Gallagher et al. “A sector-based campus-wide
indoor positioning system”. In: 2010 International Conference on Indoor
Positioning and Indoor Navigation (IPIN) (2010).
[14] IndoorAtlas. Accessed: 2017-08-21. 2017. URL: http://www.indooratlas.
com/.
[15] Luis Weruaga Buti Al Delail et al. “Indoor localization and navigation
using smartphones augmented reality and inertial tracking”. In: 2013
IEEE 20th International Conference on Electronics, Circuits, and Systems
(ICECS) (2013).
BIBLIOGRAPHY 61
[16] Liying Fan Junhai Luo and Husheng Li. “Indoor Positioning Systems
Based on Visible Light Communication: State of the Art”. In: IEEE Com-
munications Surveys & Tutorials (2017).
[17] Trackr. Accessed: 2017-07-17. URL: https://www.thetrackr.com.
[18] Muhammad Jawad Hussain Saleem Ahmad Prof. Lu Rouyu. “Never
Lose! Smart Phone based Personal Tracking via Bluetooth”. In: Interna-
tional Journal of Academic Research in Business and Social Sciences March
2014, Vol. 4, No. 3 (2014).
[19] Albert Kai-Sun Wong Yongduo Wang and Roger Shu-Kwan Cheng.
“Adaptive Room-level Localization System with Crowd-sourced WiFi
Data”. In: SAI Intelligent Systems Conference 2015 (2015).
[20] Venkata N. Padmanabhan Anshul Rai Krishna Kant Chintalapudi and
Rijurekha Sen. “Zee: Zero-Effort Crowdsourcing for Indoor Localiza-
tion”. In: MobiCom’12 (2012).
[21] Kyu-Han Kim Jindan Zhu Kai Zeng and Prasant Mohapatra1. “Im-
proving Crowd-Sourced Wi-Fi Localization Systems using Bluetooth
Beacons”. In: 2012 9th Annual IEEE Communications Society Conference
on Sensor, Mesh and Ad Hoc Communications and Networks (SECON) (2012).
[22] Bluetooth Vs. Bluetooth Low Energy: What’s The Difference? Accessed: 2017-
06-15. 2015. URL: https://www.link- labs.com/blog/bluetooth- vs-
bluetooth-low-energy.
[23] Things you should know about Bluetooth range. Accessed: 2017-06-15. 2016.
URL : http : / / blog . nordicsemi . com / getconnected / things - you -
should-know-about-bluetooth-range.
[24] BLUETOOTH 5.0 SHOWS US THE FUTURE OF WIRELESS TECH. Ac-
cessed: 2017-06-15. 2017. URL: http : / / blog . vtsl . net / vtsl - blog /
bluetooth- 5.0- voip- business- phone- system- london- uk- mobile-
phone.
[25] Bluetooth Power Classes. Accessed: 2017-06-15. 2008. URL: http://bluetoothinsight.
blogspot.se/2008/01/bluetooth-power-classes.html.
[26] Bluetooth Low Energy (Bluetooth LE). Accessed: 2017-06-15. 2014. URL:
http://internetofthingsagenda.techtarget.com/definition/Bluetooth-
Low-Energy-Bluetooth-LE.
[27] Technical Considerations. Accessed: 2017-06-17. URL: https://www.bluetooth.
com / specifications / bluetooth - core - specification / technical -
considerations.
[28] Bluetooth Low Energy for Wireless Sensors and Actuators. Accessed: 2017-
06-21. 2011. URL: https://www.digikey.com/en/articles/techzone/
2011 / mar / bluetooth - low - energy - for - wireless - sensors - and -
actuators.
[29] Introduction to Wi-Fi Wireless Networking. Accessed: 2017-06-21. 2017.
URL : https : / / www . lifewire . com / g00 / introduction - to - wi - fi -
wireless-networking-818265.
[30] Introduction to Wi-Fi Technology. Accessed: 2017-06-21. 2017. URL: http:
//smallbusiness.chron.com/introduction-wifi-technology-62018.
html.
BIBLIOGRAPHY 62
[31] Understanding 20 MHz Versus 40 MHz 802.11n Channel Configuration.

Accessed: 2017-06-21. 2017. URL: http://www.connect802.com/.
[32] Wireless B vs G vs N vs AC | What Is The Difference? Accessed: 2017-06-
21. 2017. URL: http://homenetworkadmin.com/wireless-b-vs-g-vs-n-
vs-ac-difference/.
[33] Apple, “Getting started with iBeacon”. Accessed: 2017-06-25. 2014. URL:
https : / / developer . apple . com / ibeacon / Getting - Started - with -
iBeacon.pdf.
[34] iBeacon advertising packet structure. Accessed: 2017-06-22. 2014. URL: https:
/ / support . kontakt . io / hc / en - gb / articles / 201492492 - iBeacon -
advertising-packet-structure.
[35] StepInside. Accessed: 2017-07-08. URL: https://senion.com/products-
services/.
[36] Android Beacon Library: Distance estimates. Accessed: 2017-08-27. 2015.
URL : https : / / altbeacon . github . io / android - beacon - library /
distance-calculations.html.
[37] Android Beacon Library: Calculating Formula Constants. Accessed: 2017-
08-27. 2015. URL: https : / / altbeacon . github . io / android - beacon -
library/distance-calculations2.html.
[38] Triangulation, Trilateration, or Multilateration? Accessed: 2017-06-23. 2014.
URL : http://circuitcellar.com/ee-tips/triangulation-trilateration-
or-multilateration-ee-tip-125/.
[39] Calculate the Distance between Objects, Triangulation. Accessed: 2017-06-
23. 2017. URL: https://rechneronline.de/sehwinkel/distance.php.
[40] Mohammad Ali Mohd Ezanee Rusli et al. “An Improved Indoor Posi-
tioning Algorithm Based on RSSI-Trilateration technique for Internet of
Things”. In: 2016 International Conference on Computer & Communication
Engineering (2016). http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7808286.
[41] Aniedu A.N Oguejiofor O.S et al. “Trilateration Based localization Al-
gorithm for Wireless Sensor Network”. In: International Journal of Sci-
ence and Modern Engineering (IJISME) (2013).
[42] Renbo An Song Chai and Zhengzhong Du. “An Indoor Positioning Al-
gorithm Using Bluetooth Low Energy RSSI”. In: International Confer-
ence on Advanced Material Science and Environmental Engineering (AM-
SEE 2016) (2016).
[43] Yi Liu Shixiong Xia et al. “Indoor Fingerprint Positioning Based on Wi-
Fi: An Overview”. In: International Journal of Geo-Information (2017).
[44] Stefan Poslad Zixiang Ma et al. “A BLE RSSI Ranking based Indoor
Positioning System for Generic Smartphones”. In: Wireless Telecommu-
nications Symposium (WTS), 2017 (2017).
[45] Approximate Solution of an Overdetermined System of Equations. Accessed:
2017-08-31. URL: https : / / link . springer . com / content / pdf / bbm %
3A978-1-4471-2227-2%2F1.pdf.
[46] G. Strang. Introduction to Linear Algebra. 2016. Chap. 4.3, pp. 218, 219.
ISBN: 9780980232776. URL : http://math.mit.edu/~gs/linearalgebra/
ila0403.pdf.
BIBLIOGRAPHY 63
[47] Introducing Android. Accessed: 2017-08-22. URL: http://media.techtarget.

com/searchMobileComputing/downloads/Introducing_Android.pdf.
[48] Platform Architecture. Accessed: 2017-07-13. URL: https://developer.
android.com/guide/platform/index.html.
[49] iOS Application Development. Accessed: 2017-08-22. URL: https://www.
tutorialspoint.com/ios/ios_tutorial.pdf.
[50] Samsung Galaxy S6 - Full phone specification. Accessed: 2017-09-01. 2017.
URL : http://www.gsmarena.com/samsung_galaxy_s6-6849.php.
[51] Apple iPhone 7 - Full phone specification. Accessed: 2017-09-01. 2017. URL:
http://www.gsmarena.com/apple_iphone_7-8064.php.
[52] Ikea. Accessed: 2017-09-01. URL: http://www.ikea.com/se/sv/about_
ikea/newsitem/nya_ikea_uppsala_2009.
[53] Stockholmsmassan. Accessed: 2017-09-01. URL: http://www.stockholmsmassan.
se/om-stockholmsmassan/verksamhet-sedan-1942.
[54] Bluetooth Low Energy. Accessed: 2017-07-13. URL: https://developer.
android.com/guide/topics/connectivity/bluetooth-le.html.
[55] Estimote SDK for Android. Accessed: 2017-07-02. URL: https://github.
com/Estimote/Android-SDK.
[56] Wayfinder. Accessed: 2017-07-08. URL: https://senion.com/products-
services/wayfinding/.
[57] Firebase Realtime database. Accessed: 2017-07-14. URL: https://firebase.
google.com/products/database/.
[58] Firebase Authentication. Accessed: 2017-07-14. URL: https://firebase.
google.com/products/auth/.
[59] Lei Nan Xuming Fang et al. “Fingerprint localisation algorithm for
noisy wireless sensor network based on multi- objective evolutionary
model”. In: The Institution of Engineering and Technology 2017 (2017).
[60] Jun Yang Yuan Zhuang et al. “Smartphone-Based Indoor Localization
with Bluetooth Low Energy Beacons”. In: Sensors 2016 (2016).
[61] Emily A. Baker Raymond C. Browning et al. “Effects of obesity and
sex on the energetic cost and preferred speed of walking”. In: Journal of
Applied Physiology (2006-02-01).
[62] JeongGil Ko Jeongyeup Paek and Hyungsik Shin. “A Measurement
Study of BLE iBeacon and Geometric Adjustment Scheme for Indoor
Location-Based Mobile Applications”. In: Hindawi Publishing Corpora-
tion Mobile Information Systems (2016).

Fulltext01 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fulltext01 PDF

Uploaded by

Copyright:

Available Formats

UPTEC IT 17 023

Indoor Navigation And Personal

Adam Hernod Olevall

Teknisk- naturvetenskaplig fakultet

Handledare: Per Fork

Elizabeth Kapu’uwailani Lindsey

3.4.2 Least squares . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Use Case Scenarios 23

1.1 Bluetooth beacons attached in the ceiling and a listening de-

3.1 The structure of the iBeacon protocol. . . . . . . . . . . . . . . 15

5.1 The specified path. . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 Illustration of the IPS environment. . . . . . . . . . . . . . . . . 33

7.1 Performance tests for different values of TxPower: (a) TxPower

7.5 Survey results represented as pie charts. . . . . . . . . . . . . . 50

3.1 Overview of Bluetooth releases. . . . . . . . . . . . . . . . . . . 12

GPS Global Positioning Ssystem

F IGURE 1.1: Bluetooth beacons attached in the ceiling and a

F IGURE 1.2: Listening devices attached in the ceiling can talk

F IGURE 1.3: The users can locate themselves in relation to the

1.2.1 Problem Statement

An application will be implemented and tested in order to evaluate if lost

A prototype application is built for Valtech’s office. It consists of some Es-

2.1 Indoor Positioning Systems

2.1.1 Indoor Positioning Systems with Bluetooth

Bluetooth can utilize RSSI to be a technique for measuring positions indoors.

2.1.2 Other approaches to IPS

Instead of using Bluetooth, other technologies can be used to calculate posi-

Wi-Fi based localization

IndoorAtlas is an IPS company using the earth’s magnetic field in order to

Image based localization

Today’s smartphones are equipped with many different sensors. Instead of

2.2 Tracking Systems

to track lost assets in outdoor environments. A recent released scientific jour-

Trackr is a crowd-sourced localization product made by Phone Halo [17].

2.2.2 Personal Tracking via Bluetooth

2.3 Crowd-sourced localization

3.1 Wireless technologies for IPS

Bluetooth is a wireless communication technology based on the IEEE 802.15.1

Version Year Speed Range

TABLE 3.1: Overview of Bluetooth releases.

Class Max Permitted Power Range

TABLE 3.2: Power classes of Bluetooth.

3.1.2 Bluetooth Lower Energy

BLE is a power-conserving sub-technology of Bluetooth, designed for de-

Protocol Year Speed Frequency Band

TABLE 3.3: Overview of Wi-Fi protocols.

F IGURE 3.1: The structure of the iBeacon protocol.

associated to a certain application share the same UUID. Later on is a Major

StepInside is a system for indoor positioning developed by Senion. Together

3.2.2 Estimote Beacons

F IGURE 3.2: When a device is within the range of a proximity

They are transmitting continuously in small bursts. The smartphones are

3.3 Positioning Methods

When developing an IPS there are a lot of methods available to positioning

3.3.1 Distance calculation

In order to calculate the distance between a smartphone and a beacon, an

Triangulation is an old technique used to calculate an unknown position

F IGURE 3.3: The principle of triangulation where the two cell-

Trilateration is, like triangulation, a technique used in order to calculate a po-

F IGURE 3.4: Trilateration illustrated for one, two and three

Proximity based positioning is about locating a device depending on its dis-

This positioning method is widely used in IPS environments. This technique

3.4 Positioning optimization