Optimal Object Retrieval Paths in Indoor Spaces
Rafael Jorge Barreira
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisors: Prof. Joao Coelho Garcia
Examination Committee
Chairperson: Prof. Francisco Joao Duarte Cordeiro Correia dos SantosSupervisor: Prof. Joao Coelho Garcia
Members of the Committee: Prof. Paulo Jorge Pires Ferreira
May 2018
Agradecimentos
Em primeiro lugar, gostava de agradecer ao meu orientador, o Professor Joao Coelho Garcia por ter
aceitado em embarcar comigo no desafio que foi a realizacao deste projecto. Foi o professor que me
permitiu realizar um trabalho em que eu realmente acreditava e sempre guiando-me da melhor maneira
possıvel.
Pelas reunioes tardias, conselhos, inumeras revisoes e paciencia, o meu mais sincero obrigado.
Gostava tambem de agradecer aos meus pais, que tanto sacrificaram para que eu pudesse ter esta
pequena aventura que e tirar um curso superior. Foram voces que me deram a oportunidade, de um dia
ser que eu sonhava ser. Por todo o amor incondicional ao longo destes anos e por tudo o resto, muito
obrigado.
Quero tambem agradecer ao resto da minha famılia, em especial a minha irma Vera, que sempre me
apoiou em tudo o que fiz, mesmo quando isso significava nao puder passar tempo com toda a famılia.
Pela compreensao e apoio incondicional, obrigado.
Ao Pedro, ao Fabio, ao Ricardo, ao Ruben, ao Francisco, ao Manuel, a toda a IC, a CPLEIC e a
todos os restantes que nao estao nesta lista mas que de alguma forma fizeram parte da minha vida
academica. Obrigado pela vossa amizade, pelas noitadas, conversas, risos e lagrimas. Obrigado por
terem feito parte desta parte da minha vida e por virem a fazer parte das restantes.
Finalmente, a Carina. Por todo o apoio incondicional que me desta durante todos estes anos, por
seres o meu abrigo, por me aturares e por me amares como eu te amo a ti.
Life needs things to live.
Abstract
Over the last decade, indoor localization has been the focus of extensive research and development. Its
applications have become widely popular, from museums to colleges to airports. Although most imple-
mentations of this technology are associated with tasks people don’t perform very often, more mundane
tasks could benefit from an application that used this technology to make the overall user experience
more rewarding when performing that task. The objective of this dissertation is to implement a system,
that using modern technologies, can calculate an optimal path through the supermarket, based on a
shopping list a user must take while grocery shopping. We present and describe an implementation of
such a system, using a Bluetooth Low Energy beacon network and an optimal path algorithm based on
the Lin-Kernighan heuristic.
Keywords
Indoor Localization; Bluetooth Low Energy; Beacons; Shopping; Optimal Path.
iii
Resumo
Durante a ultima decada, a localizacao em espacos fechados tem sido o foco de extensa pesquisa e
desenvolvimento. Aplicacoes que usam esta tecnologia, tornaram-se extremamente populares, desde
aplicacao para museus a faculdades e aeroportos. Embora a maioria das implementacoes desta tec-
nologia estejam associadas a tarefas que as pessoas nao executam com muita frequencia, tarefas mais
comuns poderiam beneficiar de aplicacoes que usassem esta tecnologia para tornar a experiencia geral
dos utilizadores mais recompensadora ao realizar dita tarefa. O objetivo desta dissertacao e implemen-
tar um sistema que, utilizando tecnologias modernas, possa calcular um caminho otimo no supermer-
cado, baseado numa lista de compras, que um utilizador deve realizar enquanto realiza as suas com-
pras. Apresentamos e descrevemos uma implementacao de tal sistema, usando uma rede de beacons
Bluetooth Low Energy e um algoritmo de caminho optimo baseado na heurıstica Lin-Kernighan.
Palavras Chave
Localizacao em espaco fechados; Bluetooth Low Energy; Beacons; Compras; Caminho optimo.
v
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Related Work 7
2.1 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 iBeacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1.A Estimote Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Indoor positioning using a network of Bluetooth Low Energy (BLE) beacons . . . . 11
2.2.3 Indoor localization using smartphone sensors and iBeacons . . . . . . . . . . . . . 14
2.2.3.A Pedestrian Dead Reckoning . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3.B Fusion Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Hybrid - WiFi + Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Hybrid indoor positioning with Wi-Fi and Bluetooth . . . . . . . . . . . . . . . . . . 17
2.3.1.A Frequency Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1.B Weighted Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 A hybrid BLE and Wi-Fi localization system for the creation of study groups in
smart libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2.A Bluetooth-only localization . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2.B WiFi fingerprint localization . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2.C Hybrid Bluetooth and WiFi localization . . . . . . . . . . . . . . . . . . . . 22
2.4 Optimal Path Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Dijkstra’s Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2 Floyd–Warshall Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.3 Johnson’s Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii
2.4.4 Traveling Salesman Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.4.A Lin-Kernighan Traveling Salesman Heuristic . . . . . . . . . . . . . . . . 28
A – Original Lin-Kernighan Heuristic . . . . . . . . . . . . . . . . . . 28
B – Modified Lin-Kernighan Algorithm . . . . . . . . . . . . . . . . . 29
2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Solution Architecture 35
3.1 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 BLE Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Implementation 41
4.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2 Optimal Path Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Direction Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 BLE Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Evaluation 59
5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Optimal Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Precision and Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Other Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 Evaluation Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6 Conclusions 69
6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
viii
List of Figures
1.1 Example of a possible supermarket layout. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 The different types of BLE beacons created by Estimote Inc. . . . . . . . . . . . . . . . . 11
2.2 Dickinson’s setup using one-dimensional positioning approach. The beacons are repre-
sented as circles, and the red line represents the axis on which estimated positions are
found. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Layout of the office zone from [1]. The red stars are the locations of the beacons. . . . . . 17
2.4 Test results from [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Positioning accuracy in environment A from [2]. . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Positioning accuracy in environment B from [2]. . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 The indoor area used for the experiments from [3]. 23 desks are present (each one with
a BLE beacon), represented as blue dots. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Accuracy of different localization methods on the test set [3]. . . . . . . . . . . . . . . . . 25
2.9 Accuracy of hybrid localization when using different WiFi fingerprints database from [3]. . 26
2.10 A 2-opt move example given by Helsgaun [4]. . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.11 A 1-tree example given by Helsgaun [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Our system’s architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Possible beacons layout on an aisle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Server’s thread system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Server’s database model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Example content of the products, beacons and products to Beacons tables. . . . . . . . . 45
4.4 Example content of the beacon nodes, graph paths and graph augmented paths tables. . 45
4.5 Mobile operating system market share in Portugal from April 2017 - April 2018. . . . . . . 50
4.6 Screen of the MainActivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Screen of the ListActivity with unselected items. . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Screen of the ListActivity with selected items. . . . . . . . . . . . . . . . . . . . . . . . . . 52
ix
4.9 Screen of the PathActivity when the user starts its shopping. . . . . . . . . . . . . . . . . 52
4.10 Screen of the PathActivity when the use is at the staring point. . . . . . . . . . . . . . . . 52
4.11 Screen of the PathActivity when not in the proximity region of the beacon. . . . . . . . . . 53
4.12 Screen of the PathActivity when the user is in the proximity region of the beacon. . . . . . 53
4.13 Screen of the PathActivity when the beacon is the closest one to the user. . . . . . . . . . 53
4.14 Diagram that shows how the application behaves when entering a proximity zone of a
beacon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.15 Angle between Real North and Supermarket North. . . . . . . . . . . . . . . . . . . . . . 56
4.16 Possible beacon deployment in a supermarket surface. The yellow squares represent the
beacons position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1 Results of the scalability tests. The different colors represent the number of nodes in the
graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Representation of the optimal and calculated paths in the first scenario. The beacons are
represented by the yellow squares, the ones that would be on the client shopping list are
highlighted with a red circle around them. The optimal path is presented in blue and the
calculated path in green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Representation of the optimal path in the second scenario. The beacons are represented
by the yellow squares, the ones that would be on the client shopping list are highlighted
with a red circle around them. The optimal path is presented in blue. . . . . . . . . . . . . 64
5.4 Representation of the calculated path in the second scenario. The beacons are rep-
resented by the yellow squares, the ones that would be on the client shopping list are
highlighted with a red circle around them. The calculated path in green. . . . . . . . . . . 64
5.5 Representation of the optimal and calculated paths in the third scenario. The beacons are
represented by the yellow squares, the ones that would be on the client shopping list are
highlighted with a red circle around them. The optimal path is presented in blue and the
calculated path in green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6 Results from the precision and accuracy evaluation. . . . . . . . . . . . . . . . . . . . . . 67
x
List of Tables
2.1 Battery Life and Maximum Range of every type of beacon created by Estimote Inc. . . . . 11
2.2 Test results from [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Architecture options from [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
xi
xii
Listings
4.1 .tsp file example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 .par file example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Tour file example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
xiii
xiv
Acronyms
AOA Angle Of Arrival
BLE Bluetooth Low Energy
CSI Channel State Information
GPS Global Positioning System
IPS Indoor Positioning System
LKH Lin-Kernighan Heuristic
OS Operating System
PCA Principal Component Analysis
PDR Pedestrian Dead Reckoning
RSS Received Signal Strength
RSSI Received Signal Strength Indication
SDK Software Development Kit
SIG Bluetooth Special Interest Group
SIR Sequential Importance Re-sampling
SQL Structured Query Language
TOA Time Of Arrival
TSP Traveling Salesman Problem
UUID Universal Unique Identifier
UWB Ultra-Wideband
xv
xvi
1Introduction
Contents
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1
2
1.1 Motivation
Since the beginning of the 20th century, cell phones have become a big part of all our lives and have
become the main way we communicate with other people. With the appearance of smartphones, cell
phones are no longer just a means of communication but also a tool in our day to day activities.
From sharing photos and videos to online shopping directly from your phone, in almost every task
we do every day, our phones can now take a part in it. For example, using our cell phone as a Global
Positioning System (GPS) device has become a common practice for most users. It is used for big road
trips and for finding places when walking around town. It is a very versatile feature that has become a
big part of our lives. Although this feature comes with big advantages, it also comes with some setbacks.
It only works well in outdoor spaces. This means, that if you want to find your way around an indoor
space, GPS is not the way to go, because in most indoor spaces its signal is not strong enough.
To solve this problem we can use indoor localization. Indoor localization is a technology on which
there has been extensive research in the last decade [6]. From guided museum visits to simply finding
the right room in a building, there are many ways that indoor localization can be used in our day to
day lives. Some companies already use this technology to make the user experience simpler and more
rewarding [7]. For example in some airports this technology is already in place to help users get to their
gate.
However, this technology can be applied to even more mundane tasks, for example, grocery shop-
ping. Most people do this task at least once or twice a month and most of them do it in large commercial
areas, known as supermarkets. Supermarkets are known for having a wide range of products available
in only one place. For this reason, sometimes the number of aisles and shelves makes it hard to find
the product you are looking for. Due to their size, it is very hard to memorize where all the products are.
Adding to the fact that most people do not usually do a shopping list and the ones that do, do not orga-
nize it, adding products at random, makes people walk around the supermarket without really knowing
where to go, making them feel frustrated every time they do not find the product they are looking for.
1.2 Objectives
Is it possible, using indoor localization, to improve user experience by helping them find their products
more easily? Can we create a mobile application that, given a shopping list created by the user and a
supermarket with an indoor location system, can calculate the optimal path or a path close to it for the
user?
With this project, we intend to create a mobile application that together with a network of BLE beacons
can use indoor localization to improve the user overall shopping experience.
In a more specific scope, we intend to create a network of BLE beacons that can identify not only the
3
Figure 1.1: Example of a possible supermarket layout.
user position but also the location of the products in the supermarket. Together with a mobile application,
that will allow the user to create his own shopping list and an algorithm that will calculate the optimal
path or one close to it, this system shall implement an indoor navigation system, that the user will use to
navigate through the supermarket aisles.
The main objective of this project is to create a system that can calculate the optimal or almost
optimal path through the supermarket based on the position of the products on the user’s shopping list
and also be scalable, precise and accurate.
• Optimal Path: The path calculated by the system must be the optimal one or at least very close
to it.
• Scalable: The system we create must operate efficiently with a high number of concurrent users,
with a large number of beacons and large shopping lists.
• Precise and Accurate: The system must be precise and accurate when pinpointing the user’s
location and the products locations.
4
1.3 Evaluation
We evaluated our project on four major fronts: scalability, optimal path, precision, and accuracy.
To evaluate scalability, the server faced a growing number of concurrent clients, so we could evaluate
the impact in the performance that this would have on the server.
The capacity for our project to calculate viable paths was tested, by creating three scenarios, and
then comparing the calculated path and the optimal path for those scenarios.
Precision and accuracy were tested at the same time, by creating a cluster of BLE beacons and
registering the signal strength (dBm) received from each one.
1.4 Document Outline
The rest of this document is organized as follows. In Chapter 2, Related Work, we describe some
systems that already exist that use indoor localization, utilizing different types of technology, and some
known shortest path algorithms. Our goal in this chapter is to find the best technology that would
allow us to utilize indoor localization with mobile devices in the best way possible and to find the best
shortest path algorithm that we can apply to our solution. In Chapter 3, the Solution’s Architecture, we
describe the system’s architecture. Chapter 4, Implementation, describes exactly how that architecture
was implemented in depth.
Chapter 5 presents the results of our evaluation. Finally, Chapter 6 describes what we concluded
with this project by summarizing its main points and future work.
5
6
2Related Work
Contents
2.1 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Hybrid - WiFi + Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Optimal Path Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7
8
There is a growing body of research work concerned with indoor positioning, driven primarily by the
desire to improve or personalize the experience of users in a range of contexts like the works by Faragher
[8], Zhao [9], Hansen [10] and He [11] to name a few.
Although recent work in this field has been quite promising the problem of providing reliable posi-
tioning through mobile devices and other technologies still remains. Most research focuses on already
existing hardware infrastructures, like WiFi, and on processing techniques that can determine the lo-
cation from asynchronous sensor data, like techniques that are based on Time Of Arrival (TOA) and
Angle Of Arrival (AOA) and others that simply use the existing sensors on the mobile devices, like the
accelerometer.
Some of the work that has been made in this area used techniques based on known signal strength
attenuation, like trilateration techniques [12]. Which according to Deepesh [13], is unreliable due to being
highly sensitive to environmental factors. Due to this, most of the recent work is based on improving
fingerprint methods, that are based on measuring actual signal strengths from surrounding access points
[14], [10].
The system we want to create needs to be accurate, precise, and scalable as possible. As a con-
sequence, it is important to take a look at what technologies are currently available to us. To do this
we surveyed a wide range of indoor location systems. Using Xiao’s work [6], we were able to look into
several of these systems, reviewing them and then categorizing them in all of the features mentioned
above. After careful analysis and research, we concluded that the most promising technologies were
WiFi and Bluetooth, specifically BLE beacons. While other described technologies had better accuracy
results, like a hybrid system with WiFi and acoustic, we think that taking into account that it is a super-
market environment, these would not work properly, due to the noise that is generated by the shoppers
and the employees.
Upon our decision, we took a look at what systems use WiFi, BLE beacons, and systems that use a
hybrid infrastructure between the two.
In this section, we also take a look at some shortest path algorithms with the objective of finding the
best one to apply to our solution.
2.1 WiFi
Due to its wide availability and prevalent infrastructure, WiFi-based indoor positioning has become an
attractive approach of supreme importance. Most of the positioning systems that use this technology
use TOA, AOA, Received Signal Strength (RSS) or Channel State Information (CSI).
There has been a lot of work based in WiFi indoor positioning, like Lashkari’s work [15] and Yang’s
[16] for example, however, solutions using this technology usually have low accuracy or are very de-
9
pendable of environmental factors. These limitations make solutions that use this technology to have a
very low probability of working correctly with the system we have in mind.
To solve this we turned to Bluetooth, more specifically BLE and to systems that work with a hybrid
infrastructure of the two.
2.2 Bluetooth Low Energy
Bluetooth Low Energy [17] is a wireless technology developed by the Bluetooth Special Interest Group
(SIG) for short-range communication. In contrast with previous Bluetooth flavors, BLE has been de-
signed as a low-power solution for control and monitoring applications.
2.2.1 iBeacon
This technology was introduced by Apple in 2013. It is important to note that iBeacon is only a protocol
based on BLE. Most of the hardware, that uses this protocol, is developed by third-party companies with
and have a variety of technical specifications. Every time an iBeacon broadcasts a Bluetooth signal it
sends a packet, we call this the iBeacon packet. The iBeacon packet contains the following sets of data:
• iBeacon Prefix: Contains manufacturer specific data, and also the length of the packet.
• Proximity Universal Unique Identifier (UUID): An identifier that is used to identify all beacons
used in a particular context. All beacons in an Indoor Positioning System (IPS) should have the
same proximity UUID.
• Major number: It is used to group beacons into smaller partitions. For example, all beacons in a
specific supermarket should use the same major number.
• Minor number: It is used to identify a single beacon.
• Tx Power: It is used to determine the distance from the beacon. This value is defined as the
strength of the signal exactly one meter from the device. It must be calibrated and hardcoded in
advance. Devices can then use this value as a baseline to give a rough distance estimation.
2.2.1.A Estimote Beacons
Estimote beacons are BLE beacons created by Estimote Inc.1, they utilize the iBeacon protocol to broad-
cast their messages. Estimote provides five different types of beacons, all with different specifications
and tailored for different ends.1https://estimote.com
10
Figure 2.1: The different types of BLE beacons created by Estimote Inc.
• Video Beacon or Estimote Mirror: These beacons are connected to screens via USB and use
the Estimote Mirror Software Development Kit (SDK) to display personalized content. They scan
for signals from user’s phones and display contextual content on the screen they are connected to.
• Sticker Beacon: These beacons are glued on to objects and will display content associated with
the objects that people touched or interacted with.
• Proximity Beacon: These beacons are placed in locations and use the Estimote Proximity SDK to
display entry and exit events and it will allow to authenticate presence, send contextual notifications
and display proximity-based content.
• Location Beacon: These beacons are also placed in specific locations and use the Estimote
Location SDK to locate users, register their real-time position on a specific location, collect atten-
dance data, or deliver way-finding instructions to the users. Estimote Inc. provides two types of
Location Beacons, one of them with a Ultra-Wideband (UWB) chip that can map the space au-
tomatically and the other without this chip that needs the developer to map the space manually.
These beacons can also be used as Proximity Beacons adding an extended battery life, as seen
in table 2.1.
Table 2.1: Battery Life and Maximum Range of every type of beacon created by Estimote Inc.
Location Beacon Proximity Beacon Sticker Beacon Video Beacon
Battery Life 5 years 2 years 1 year Endless (USB-powered)Maximum Range 200 meters 70 meters 7 meters 10 meters
2.2.2 Indoor positioning using a network of BLE beacons
In our research, we came across a recent work that tackles part of our problem using this technology [5].
Dickinson proposes a system for indoor positioning in an all wholesale store and focuses on the user’s
11
position, mainly pinpointing in which aisle the user is in, and, as accurately as possible, their position
along the aisle, providing at the same time enough information to determine which product(s) categories
are adjacent to the user. It does this by deploying the beacons along one side of the aisle, at regular
(but not always equal) intervals corresponding to the ends of shelving units. The positioning problem
was simplified from two-dimensional to one-dimensional because the user’s position with regard to the
width of the aisle is not considered important, so the idea is to locate the user on a defined axis parallel
to the aisle, figure 2.2.
Figure 2.2: Dickinson’s setup using one-dimensional positioning approach. The beacons are represented as cir-cles, and the red line represents the axis on which estimated positions are found.
The author then tests and compares three different approaches for positioning. The first one being
the simplest of three, Nearest Beacon, consists in deciding which beacon is the closest to the user and
show the user’s position as the point closest to the beacon on the axis parallel to the aisle, these points
are represented as yellow squares in Fig 2.2. Given a series Rb,t of k readings of the Received Signal
Strength Indication (RSSI) for a every specific beacon b at an instance t over a time window wt
Rb,t = rk, rk−1, rk−2, ..., r1 (2.1)
The author implemented two different methods for calculating the signal value Sb,t for beacon b at a
time t based on the readings made before:
Sb,t = ark + (1− α)Sb,t−1 (2.2)
12
Sb,t = maxi(maxi ∈ Rb,t) (2.3)
where α is a learning rate parameter for the exponential moving average. The closest beacon is
considered to be the one with the highest signal Sb,t at the instant t.
The second positioning approach, Weighted Beacon-Pair Range Estimates, uses the readings of
neighboring beacons in this estimation. Then, the closest beacon is calculated, followed by the next
closest(that is usually close to the first), then given the positions p1 and p2 and corresponding distances
d1 and d2 (calculated according to Euclidean Distance Estimation), the target pt is calculated:
pt = p1 + (p2 − p1)( d1d1 + d2
) (2.4)
Finally, the third approach, Particle Filter, uses a particle- filtering algorithm known as Sequential
Importance Re-sampling (SIR) filter. These particles leave the user’s mobile device and move along the
axis until reaching a node(beacon). Then, a new path is chosen at random. The next state of the particle
is predicted by:
pi,t = vi,tts (2.5)
where ts is the time passed since the last update and vi,t is the velocity. The initial position of particle
p corresponds to the beacon position, and the signal strength sd is calculated using:
Maximize∑∀i∈T
max∀i∈R
(SijPij) (2.6)
Then the weight is defined as the probability of the measured RSSI, and calculated using the follow-
ing algorithm:
wi,t = 1√2πσ2
p
ε− 1
2 (sm − sdσp )2
(2.7)
The weight is then normalized, and Np new particles are created by randomly selecting particles
from the current distribution. The weight decides the likelihood of each particle being created. The
user’s position at a time t is calculated according to:
pu =∑Npi=1 wi,tpi,t (2.8)
The three positioning approaches were then tested. The results can be seen in table 2.2.
All the experiments were done in an area of 800 m2 using 25 beacons, with a pathway length of 85
meters, and data was collected in three separate tests. The table shows the mean error, as well as the
13
Table 2.2: Test results from [5]
Positioning Method Run Total1 2 3NearestBeacon
Mean(m) 2.15 2.01 1.82 2.01Std. dev. 1.49 1.47 1.35 1.44
Beacon-PairRange
Mean(m) 1.53 1.78 2.03 1.76Std. dev. 1.45 1.62 1.72 1.59
ParticleFilter
Mean(m) 1.04 1.07 1.44 1.16Std.dev. 0.97 1.24 1.31 1.18
standard deviation, from all methods and tests. When comparing the results, Particle Filter proves to be
the superior method of the three.
2.2.3 Indoor localization using smartphone sensors and iBeacons
Now we present the solution created by Chen [1]. This paper presents a framework for fusing Pedestrian
Dead Reckoning (PDR) and iBeacon. First, we present the concept of PDR and the framework proposed
by the paper.
2.2.3.A Pedestrian Dead Reckoning
This process of calculating one’s current position uses the user’s previous known position, current walk-
ing length and walking direction to calculate the new position. With the increased sensor offering in
smartphones, built-in accelerometers, built-in magnetometer, etc. It is possible to use this process us-
ing only one of these sensors. However some critical issues need to be addressed, including Step
setection, Walking Length Estimation and Walking Direction Estimation.
• Step Detection can be achieved based on the periodic pattern of vertical accelerations during
walking. In truth, due to the low quality of smartphone accelerometers and random vibrations dur-
ing walking, the raw acceleration data becomes very noisy. Therefore, to solve this shortcoming,
Chen puts the data through a smoothing function. Then, a simple threshold method is applied for
identifying each step.
• Walking Length varies for different subjects and in different times during walking, therefore, it is
not sufficient assuming constant step lengths for walking, jogging and running or constructing a
linear relationship between step length and the height of a pedestrian. To solve these problems,
Chen uses a new model that takes varying step length during walking into consideration.
L = β(αmax − αmin)14 (2.9)
14
where L is the walking length, α is the acceleration, and β is the coefficient.
• Walking Direction Estimation can be provided, intuitively, by magnetometer readings. However,
these readings can be affected by electronic devices in indoor environments. Another way to obtain
walking direction is based on the double integration of gyroscope readings. But, due to the noise
effect, the integration will drift from the corrected position if it is not corrected. The paper ends up
constructing a Kalman filter to combine these two sensors.
2.2.3.B Fusion Algorithm
Chen argues that the PDR approach can provide a high localization accuracy in a short range, but then
slowly drifts with walking distance and that this drift can be corrected by iBeacon measurements.
The solution that Chen presents is based on the particle filter algorithm SIR which approximates the
posterior distribution by a weighted set of particles. It consists of six phases:
• Initialization: Given the initial position X0, the positions of particles are randomly generated
around the initial point, which is shown as Xi
Xi0 ∼ N(X0, σ
2), i = 1, 2, . . . ,K (2.10)
where Xi0 is the position of i-th particle at time step 0, K is the total number of particles.
• Propagation: Based on smartphone sensors, we can obtain walking direction,θt, and walking
length, Lt, in each step. Then, the propagation model for each particle at time step t is shown as
Xit = Xi
t−1 + Lt
[sin(θt)cos(θt)
](2.11)
• Observation: When a user moves into a calibration range, the distance, dt, between a device and
an iBeacon can be calculated based on the RSS. Since the location of the iBeacon is known, the
distance, dit, between the iBeacon and i-th particle is calculated, using:
dit = ||P −Xit || (2.12)
where P is the location of the iBeacon, Xit is the location of i-th particle.
• Weight Calculation: Since the SIR algorithm is applied for the particle filter, the importance func-
tion is chosen as the transition prior probability distribution. This will simplify the calculation of
particle weights. Based on the configuration, particle weights are calculated as
15
wti = wit−1P (dt|dit) (2.13)
P (dt|dit) =1√
2πσ2ε−
(dt−dit)2
2σ2 (2.14)
then, the normalized weights are calculated using:
wit =wit∑Ki=1 w
it
(2.15)
• Position Update: The final position of the user is expressed as
Xt =K∑i=1
wtiXti (2.16)
• Re-sampling: One of the biggest problems in a particle filter is the degeneracy of the algorithm,
which means that a small portion of particles have large weights, and the weights of the rest are
negligible. In the case presented in [1], the final position will only depend on the small portions of
particles, which impairs the generalization ability of the algorithm. In order to check the degeneracy
of the algorithm, the following criterion is applied
Neff =1∑K
i=1(wit)2
(2.17)
if Neff < Nthr, where Nthr is the degeneracy threshold, a re-sampling process is applied. K par-
ticles proportional to the weights of the current particles are drawn, and then the current particles
are replaced with the new ones and the weights of all particles are set to 1K .
Chen concludes with the experiments that evaluate the proposed system. The experiments were
conducted in an office zone. The size of the zone is 47.3m by 15.9m. The layout of the office zone can
be seen in figure 2.3.
Two scenarios were tested. In the first scenario, it is assumed that the initial point is known. In order
to evaluate the effect of the estimation error of the initial point, it was added a random error to the initial
point and the algorithms were re-performed. In the second scenario, it was added, manually, a random
bias into the initial point, and the algorithms were re-performed. In figure 2.4 it is possible to see that the
solution is not perfect; however, it is possible to see the BLE beacons correcting the user position, by
following the red line and seeing how it gets closer to the true path when it gets closer to each beacon.
If we take into account the behavior the beacons shown in this paper, especially as shown in figure 2.4,
16
Figure 2.3: Layout of the office zone from [1]. The red stars are the locations of the beacons.
it is possible to deduce that if more beacons had been deployed, in the corners of the office zone, for
example, the system could have been much more accurate.
2.3 Hybrid - WiFi + Bluetooth
Both WiFi and Bluetooth have their limitations of their own, however when combined the resulting accu-
racy and scalability is much greater [6]. Some previous work has already been made using this hybrid
solution [2], [3]. Both authors use WiFi to cover the limitations in the range that Bluetooth has, specifi-
cally when the user is not in range of any BLE beacon, WiFi is used to cover that fault, that way, fewer
beacons are needed and since WiFi access points are widely deployed and available, it is easy to use
this technique.
2.3.1 Hybrid indoor positioning with Wi-Fi and Bluetooth
The solution proposed by Baniukevic [2] starts by tackling the problem of the Bluetooth hotspots de-
ployment. In previous work, topological connections like doors, staircases, and narrow passages are
proposed as candidate places for deployment of Bluetooth hotspots. Those specific choices of hotspot
deployment can lead to a quite different performance of the resulting positioning system. So Baniukevic
created a deployment algorithm, which separates the radio map for the entire indoor space in different
partitions resembling reference positions, dividing their WiFi fingerprints into different radio map parts.
Thus, subsequent position estimation is less likely to encounter resembling reference positions, which
then improves the positioning accuracy.
The algorithm receives the original WiFi radio map, R, the graph g of all reference positions in R, and
the number n of available Bluetooth hotspots as parameters. Then, the algorithm does a loop to select
17
Figure 2.4: Test results from [1].
n points from the graph g, which they call pivots, for deploying the n available hotspots, each pivot then
partitions the (sub)graph into two subgraphs. Each iteration of the algorithm consists of three steps:
• Using a max-heap, the subgraph gi (initially g) with the largest number of reference positions is
chosen to be partitioned. For the gi, N WiFi based position estimates are obtained by simulation
or real runs.
• Then, estimated results are evaluated. For each wrong estimate, the error distance together with
the true and estimated positions are recorded. Subsequently, the average error distance is calcu-
lated for each unique pair of true and estimated positions, and the pair (p1 and p2) that leads to the
maximum average error distance is obtained.
• Positions in gi are clustered with respect to p1 and p2. Subsequently, a boundary position is found
18
for either cluster, and the one with the higher average error distance in the estimate is chosen as
the pivot pv. Finally, a Bluetooth hotspot is deployed at pv, and the current subgraph’s radio map is
partitioned accordingly. Then after every Bluetooth hotspot has been deployed the algorithm ends.
Then, after dealing with the Bluetooth hotspots deployment Baniukevic talks about how to improve
partition switching, i.e. improving how the solution identifies the partition of a moving user who is leaving
the range of a Bluetooth hotspot. The author proposes two methods that improve the naive approach to
this problem used by previous work by reducing computation cost by only identifying a single partition
without jeopardizing accuracy. The proposed methods, Frequency Method and Weighted Method,
make n(n ≥ 1)3 estimates. Each method scans WiFi signals, followed by a corresponding position
estimate, a total of n times. It then selects the next partition. The methods differ in how they make use
of the n estimates to select the next partition.
2.3.1.A Frequency Method
This method just counts how frequent a reference position, i.e. the estimated user position based on the
radio map of the indoor location, occurs in the n estimates and uses the most frequent one to select the
next partition. Ties are resolved by a random choice.
2.3.1.B Weighted Method
Different weights are assigned to the n estimates, and the corresponding partition is decided for each
of the n estimates. Then, a weighted score is calculated for each possible partition, and the partition
with the highest score is selected. Supposing that the n estimated positions are p1, p2, . . . , and pn in this
temporal order. Weights wi(i ∈ 1, 2, . . . , n) are assign to them accordingly. Each estimated position ni
falls into a particular partition rj . For each possible partition rj that appears in the n estimates, its score
is calculated according to:
score(rj) =
∑pi ∈ rjn · rj (2.18)
Baniukevic created three different system architectures; we present them in Table 2.3.
Table 2.3: Architecture options from [2]
Bluetooth Scanning Online Position Estimation
Thin client Client side Server sideThick client Client side Client side
Medium client Bluetooth hotspots Client side
19
Experiments were conducted in two different environments, a relatively small multi-floor apartment
building, where each floor occupies 50m2, environmentA, and large shopping and entertainment center,
environment B, one floor in B exceeds 500 m2. The paper ends up concluding that both the Bluetooth
hotspot deployment algorithm and the methods that improved partition switching reached the desired
objectives. The deployment algorithm getting an average error distance of 7.57 meters against the 9.75
meters from the manual deployment. The results from the partition switching improving methods can be
seen in figures 2.5 and 2.6.
Figure 2.5: Positioning accuracy in environment A from [2].
Figure 2.6: Positioning accuracy in environment B from [2].
20
2.3.2 A hybrid BLE and Wi-Fi localization system for the creation of study groups
in smart libraries
In even more recent work, the solution proposed by Antevski [3] uses WiFi and BLE to create a local-
ization system to pinpoint the location of study groups in a smart library. The author proposes three
approaches, Bluetooth-only localization, WiFi fingerprints localization and hybrid Bluetooth and
WiFi localization; we describe them below.
2.3.2.A Bluetooth-only localization
This approach is based on the presence of N BLE beacons in the library. The beacons broadcast
beacon messages which are received by any BLE-enabled mobile device in their communication range.
A proximity algorithm is used and the estimated location of a user carrying a mobile device is considered
to be side by side with the BLE beacon from which it receives the strongest signal.
2.3.2.B WiFi fingerprint localization
This approach is used when the mobile device carried by the user is not Bluetooth-enabled or the user is
not near any BLE beacons. Given the widespread availability of WiFi networks (both public and private),
a mobile device in any location receives a great number of access point frames from L different access
points, denoted with l = 1, . . . , L.
Depending on the relative position of the l-th access point compared to the mobile device, its signal
will be received with a signal strength sl. The m-th location of the set X can be therefore described
with one or more signal strength vectors, or fingerprints, sm,i = sl, . . . , sLT , where i is used to denote
different signal strength measurements taken at the same location. In an offline phase, those measure-
ments are collected and stored in a database, together with the location of where they were collected.
Then, in the online phase, the user measures a signal strength vector s, known as a query, and transmits
it to the database. Then, Antevski tested three strategies to estimate the user location, that we describe
next.
• k-Nearest Neighbor (k-NN): In this strategy, the Euclidean distance between the query s and each
entry sm,i in the database is computed. The k vectors with shortest distances are retained and
the estimated user location, x, is assigned to the most common location among the k nearest
neighbors.
• k-Means Clustering: first, the fingerprint database is partitioned into k different clusters where
fingerprints are characterized by the nearest mean. Each cluster has a cluster-head fingerprint,
which serves as a “prototype” for the cluster itself. Then, k is set to M , the number of known
21
locations in the library, and cluster-heads are created by averaging together different observations
belonging to the same location, using:
sm = 1Nm
∑i sm,i (2.19)
where Nm is the number of observation corresponding to the m-th location. The objective of this
operation is the reduction of noise in the observations and of the size of the database. After this
step, Nearest Neighbor, 1-NN, is performed on the reduced database composed by cluster-heads
only, and the estimated location x is returned.
• PCA-based fingerprinting: Principal Component Analysis (PCA) can be applied to the fingerprint
database to overcome the fact that some measurements may be very low(or even nonexistent) or
very similar(two access points will generate correlated entries in the fingerprints).
PCA finds an orthogonal transformation that converts the original observations in a set of linearly
uncorrelated principal components. Those principal components are sorted in decreasing order of
their variance, identifying a “ranking” among them. We learn the PCA transformation T from the
fingerprint database after the offline phase and communicate it to the mobile devices. In the online
phase, a mobile device transforms the query s in the PCA domain by multiplication with T , that is:
w = T s (2.20)
Then, either k-NN matching or k-Means clustering can be applied on the PCA-transformed and
reduced database.
2.3.2.C Hybrid Bluetooth and WiFi localization
When both technologies are accessible, it is possible to set up a hybrid localization framework that fuses
together the information coming from the two systems.
In his work, Antevski notices that the error probability density function P (E) of the BLE or WiFi sys-
tems is not uniform with respect to space, but estimation errors of the two systems always occur in
particular locations. The author considers the reason of this to be the particular propagation character-
istics of the environment under consideration, paired with the specific deployment of the BLE beacons
and WiFi access points.
Antevski then, proposed a solution for the problem, considering that the position of beacons and
access points is generally fixed and does not change after the first deployment and that one may estimate
the spatial distribution of the location errors P (E | x) in an offline phase, and use it afterwards to correct
the estimation. This is done by two users’ locations xBLE and xWiFi are estimated independently using
22
Bluetooth and WiFi, respectively. Then, a new location estimation xH is produced according to the
following:
xH =
xBLE if P (E|xWiFi)xWiFi otherwise.
(2.21)
Hybrid localization can be used to alleviate the cumbersome task of updating the fingerprints database
because the query vector transmitted by a user is added to the database and labeled with the estimated
location returned by the Bluetooth-only system. Also, in order to facilitate the task even more, a location
label is appended to the fingerprint, Antevski says that the system may explicitly ask the mobile device
owner to confirm the estimated location.
The author then tests all three approaches in a realistic indoor scenario. A proof-of-concept was
implemented in an 100 m2 indoor space with 23 desks positioned as shown in figure 2.7.
For each desk, 40 received signal strength measurements were performed for a total of 920 mea-
surements: each measurement lasted one second and two consecutive measurements were spaced
by 100ms. Multiple received signal strength measurements from the same WiFi access point or BLE
beacon device were averaged during the same one-second measurement interval.
Figure 2.8 shows the performance of the different localization methods, where the number of access
points or principal components to be used for fingerprints, i.e., the fingerprint vector dimension, were
varied. Also from figure 2.8, we can conclude that:
• the performance of the Bluetooth-only system are surprisingly good, with a correct position re-
turned almost 87% of the times;
• the accuracy of WiFi methods generally increases as the size of the fingerprints increase;
• the PCA-based methods outperform methods in the original RSS domain in terms of maximum
accuracy for the small size of the fingerprints. This means that the PCA transformation learned
from the available data is able to identify the most important components and to filter out the noisy
and correlated ones;
• k-nearest neighbors matching generally outperforms k- Means based matching in terms of local-
ization accuracy. The drawback of k-NN methods compared to k-Means is their high complexity:
Antevski takes this issue into account when he developed his system by using a larger fingerprint
database;
• hybrid methods always show the best performance, demonstrating that fusing together the infor-
mation coming from the two independent systems allows for almost perfect location estimation.
The method of obtaining the best performance is the one fusing BLE with PCA fingerprints and
23
Figure 2.7: The indoor area used for the experiments from [3]. 23 desks are present (each one with a BLE beacon),represented as blue dots.
k-NN matching, which allows obtaining almost perfect location estimation (99.74%) with as few as
10 principal components.
Antevski concludes by testing the performance of the method that fuses BLE with PCA fingerprints
and k-NN matching, obtained in two cases in which the information in the fingerprint database is up-
to-date or 2 weeks old. Instead of repopulating the database with updated ground truth fingerprints,
a new database obtained with the fingerprints coming from the hybrid localization system was used.
Although these fingerprints were affected by the error of the Bluetooth-only system, figure 2.9 shows
that using such an approach allows avoiding the cumbersome procedure of repopulating the database,
still achieving acceptable accuracy performance.
24
Figure 2.8: Accuracy of different localization methods on the test set [3].
2.4 Optimal Path Algorithm
To implement an indoor navigation system we will need to implement an algorithm, that will help us
calculate the optimal path for the user, taking into account the requirements described in section 1.2. By
utilizing the BLE beacons network we will be able to transform the supermarket floor into a graph, where
the nodes will be the beacons themselves. This will facilitate the application of an algorithm that finds a
possible optimal path. There are several possible algorithms that can be used, we describe some them
next.
2.4.1 Dijkstra’s Algorithm
The Dijkstra’s Algorithm [18] finds the shortest path between nodes in a graph. It was created by Edsger
W. Dijkstra in 1956. Currently, exist several versions of this algorithm; the original version found the
shortest path between two nodes, but the most common version of the algorithm fixes a single node as
25
Figure 2.9: Accuracy of hybrid localization when using different WiFi fingerprints database from [3].
the ”source” node and finds the shortest paths from this node to all other nodes in the graph, producing
a shortest-path tree.
This algorithm can also be used for finding the shortest paths from a single node to a single destina-
tion node by stopping the algorithm once the shortest path to the destination node has been determined.
For example, if the nodes of the graph represent cities and edge path costs represent driving distances
between pairs of cities connected by a direct road, Dijkstra’s algorithm can be used to find the shortest
route between one city and all other cities. Dijkstra’s algorithm runs in time O(|V |2), where |V | is the
number of nodes.
2.4.2 Floyd–Warshall Algorithm
The Floyd-Warshall Algorithm [19] is an algorithm for finding shortest paths in a weighted graph with
positive or negative edge weights (but with no negative cycles). This algorithm was published by Robert
Floyd in 1962. One single execution of this algorithm finds the lengths (summed weights) of the shortest
paths between all pairs of nodes.
This algorithm compares all possible paths through the graph between each pair of nodes. It is able
to do this with Θ(|V |3) comparisons in a graph. Quite remarkable considering that there may be up to
Ω(|V |2) edges in the graph, and every combination of edges is tested. It does this by incrementally im-
26
proving an estimate of the shortest path between two nodes until the estimate is optimal. Floyd–Warshall
algorithm runs in time O(|V |3), where |V | is the number of nodes.
2.4.3 Johnson’s Algorithm
The Johnson’s Algorithm [20] is an algorithm to find the shortest paths between all pairs of nodes in a
sparse, edge weighted, directed graph. It is named after Donald B. Johnson, who first published it in
1977. The algorithm allows some of the edges weights to be negative, but no negative-weight cycles
may exist. It uses the Bellman-Ford’s algorithm [21] to transform the input graph in a graph with no
negative weights, allowing Dijkstra’s algorithm to be used on the transformed graph.
Johnson’s algorithm time complexity, using Fibonacci heaps in the implementation of Dijkstra’s algo-
rithm, is O(|V |2log|V |+ |V ||E|).
2.4.4 Traveling Salesman Problem
Traveling Salesman Problem (TSP) [22] is a classic algorithmic problem, focused on optimization. It
was defined in the 1800s by the Irish mathematician W. R. Hamilton and by the British mathematician
Thomas Kirkman.
TSP describes the problem of finding the optimal path from a node, passing through all of the others
nodes in the graph and returning to the starting node. A common abstraction of the TSP is that of the
salesman who must travel between N cities. The order in which he does so is something he does not
care about, as long as he visits each one during his trip, and finishes where he was at first. Each city is
connected to other cities, or nodes, by airplanes, or by road or railway. Each of those links between the
cities has one or more weights (or the cost) attached. The cost describes how ”difficult” it is to traverse
this edge on the graph, and may be given, for example, by the cost of an airplane ticket or train ticket,
or perhaps by the length of the edge, or time required to complete the traversal. The salesman wants to
keep the travel costs as low as possible.
The Traveling Salesman Problem, is one of the most widely studied problems in combinatorial opti-
mization [23]. Mathematically, TSP may be presented as follows: Given a cost matrix C = (cij), where
cij) represents the cost of going from city i to city j, (i, j = 1, . . . , n), find a permutation (i1, i2, . . . , in) of
values from 1 through n that minimizes the value ci1i2 + ci2i3 + . . .+ cini1 .
The properties of the cost matrix C are used to classify problems.
• When cij = cji for all i and j, the problem is said to be symmetric; otherwise it is asymmetric.
• When the triangle inequality holds (cik ≤ cij+cjk for all i, j and k), the problem is said to be metric.
27
• When cij are Euclidean distances between points in the plane, the problem is said to be Euclidean.
A Euclidean problem is both symmetric and metric.
Given the problem we present in this document, we are only interested in solutions that try to solve the
symmetric problem version of the TSP.
Many people have studied this problem. The easiest (and most expensive solution) is to simply
try all possibilities. The problem with this is that for N cities you have (N − 1) factorial possibilities.
This means that for only 10 cities there are over 180 thousand combinations to try (since the start city
is defined, there can be permutations on the remaining nine). Exact solutions to the problem can be
found, using branch and bound algorithms. This is currently possible for up to 85,900 cities. Heuristics
approaches use a set of guiding rules for selection of the next node. However, since heuristics result in
approximations, they will not always give the optimal solution, although high-quality admissible heuristics
can find a useful solution in a fraction of the time required for a full brute force of the problem. We now
present an effective implementation of such a heuristic, the Lin-Kernighan Heuristic (LKH) [24], to the
Traveling Salesman Problem.
2.4.4.A Lin-Kernighan Traveling Salesman Heuristic
The LKH [24] is often considered to be one of the most effective methods for generating optimal or
near-optimal solutions for the symmetric Traveling Salesman Problem. We now give a small overview of
the original heuristic created by Lin and Kernighan and then we discuss the modifications to it and the
implementation created by Helsgaun [4].
A – Original Lin-Kernighan Heuristic The LKH is a tour improvement algorithm. A simple example
of this type of algorithms is the 2-opt algorithm: Start with a given tour. Replace two links of the tour
with other links in such a way that the new tour length is shorter. Continue in this way until no more
improvements are possible.
Fig. 2.10 illustrates a 2-opt exchange of links, a 2-opt move. Note that this exchange keeps the tour
possible and corresponds to a reversal of a subsequence of the cities.
The LKH is based on the generalization of this principle. The 2-opt algorithm is a special case of the
λ-opt algorithm [25], where in each step λ links of the current tour are replaced by λ links in such a way
that a less costly tour is achieved.
Lin and Kernighan introduced a powerful variable λ-opt algorithm. At each iteration step, the algo-
rithm examines, for ascending values of λ, whether an interchange of λ link may result in a shorter
tour.
The algorithm is specified in terms of exchanges (or moves) that can convert one tour into another.
Given a feasible tour, the algorithm repeatedly performs exchanges that reduce the length of the current
28
Figure 2.10: A 2-opt move example given by Helsgaun [4].
tour, until a tour is reached for which no exchange yields an improvement. This process may be repeated
many times from initial tours generated in some randomized way.
Let T be the current tour. At each iteration step the algorithm attempts to find two sets of links, X
and Y , such that, if the links of X are deleted from T and replaced by the links of Y , the result is a better
tour. This interchange of links is called a r-opt move.
The two setsX and Y are created element by element, the search necessary to fill these sets creates
a bottleneck on the algorithm. In order to increase efficiency, Lin and Kernighan made some refinements
to the algorithm by introducing five new rules. Some of the new rules are created to optimize running
time, sometimes at the expense of not achieving the best possible solution. Other rules are introduced
to direct the search, by giving priorities to certain alternatives when the algorithm is presented with a
choice of alternatives.
The last refinement, Lin and Kernighan, included was a limited defense against the situations where
only non-sequential exchanges may lead to a better solution. After a local optimum has been found,
the algorithm tests, among the links allowed to be broken, whether it is possible to make a further
improvement by a non-sequential 4-opt change.
B – Modified Lin-Kernighan Algorithm We now present the modifications made by Helsgaun [4] to
the original Lin-Kernighan Algorithm [24]. Helsgaun takes the LKH algorithm and improves upon it, by
revising its rules for restricting and directing the search.
A central rule in the original algorithm is the heuristic rule that restricts the inclusion of links in the
tour to the five nearest neighbors to a given city. This rule directs the search and reduces the search
29
effort substantially. However, this rule may prevent the optimal solution from being found. If an optimal
solution contains a link that is not connected to the five nearest neighbors of its two end cities, then the
algorithm will have difficulties in obtaining the optimum.
The shortcoming of this rule manifests itself clearly in large problems. Taking, for example, a 532-city
problem [26] one of the links in the optimal solution is the 22nd nearest neighbor for one of its endpoints.
So to find the optimal solution to this problem, the number of nearest neighbors to be considered should
be at least 22. Unfortunately, this enlargement of the set of candidates results in a substantial increase
in running time.
To counter this shortcoming, Helsgaun creates a measure of nearness, α-nearness, that is based on
sensitivity analysis using minimum spanning 1-trees.
LetG = (N,E) be a undirected graph whereN = 1, 2, . . . , n is the set of nodes andE = (i, j)|i ∈ N, j ∈ N
is the set of edges and where each edge (i, j)has associated a cost c(i, j). Considering G to be a con-
nected graph, i.e. a graph where for any pair of nodes exists a path connecting them. A tree is a
connected graph without cycles. A spanning tree of a graph G with n nodes is a tree with n − 1 edges
from G. A minimum spanning tree is a spanning tree of minimum length. A 1-tree for a graph G = (N,E)
is a spanning tree on the node set N \1 combined with two edges from E incident to node 1. A minimum
1-tree is a 1-tree of minimum length.
Let T be a minimum 1-tree of length L(T ) and let T+(I, J) be a minimum 1-tree required to contain
the edge (i, j). The α-nearness of an edge (i,j) is defined as the quantity
α(i, j) = L(T+(i, j))− L(T ). (2.22)
That is, given the length of any minimum 1- tree, the α-nearness of an edge is the increase of length
when a minimum 1-tree is required to contain this edge.
The α-measure introduced by Helsgaun can be used to systematically identify the edges that could
be included in an optimal tour, and disregard the rest. The author calls these edges, ”candidate set”.
Usually, the candidate set is smaller and does not degrade the quality of the solution.
The α-values calculated by the α-nearness provide a good estimate of the edge’s chances of be-
longing to an optimal tour. The smaller α is for an edge, the more likely is this edge to be added to the
candidate set. The edges in the candidate set of each node are sorted in ascending order of their α-
values, if two edges have the same α-value, the one with the smallest cost, cij , comes first. This ordering
makes that the candidate edges are considered for inclusion in a tour according to how ”promising” they
are to belong to an optimal tour. Thus, the α-measure is not only used to limit the search, but also to
focus the search on the most promising areas.
Additionally, Helsgaun takes the basic move from the original LKH [24] and turns it into a 5-opt move
instead of the previous 2- or 3-move. Making the moves considered by the algorithm as sequences of
30
Figure 2.11: A 1-tree example given by Helsgaun [4].
one or more 5-opt moves. However, the construction of a move is stopped immediately if it is discovered
that a close up of the tour results in a tour improvement.
As a final modification to the original LKH, Helsgaun creates a construction heuristic to construct the
initial tours of the algorithm.
In the original work by Lin and Kernighan, the initial tours are chosen at random because the authors
concluded that the use of a construction heuristic only wasted time. However, after analyzing the works
by Adrabinsky and Syslo [27], Perttunen [28] and Reinelt [29], Helsgaun argues that a significant reduc-
tion in runtime may be achieved by choosing initial tours that are close to being optimal. So the following
construction heuristic was created:
1. The heuristic picks a random node i.
2. The heuristic picks a node j, that has not been chosen before, as follows:
If possible, the heuristic chooses j so that
(a) (i, j) is a candidate edge,
31
(b) α(i, j) = 0,
(c) (i, j) belongs to the current tour.
Otherwise, if possible, the heuristic chooses j such that (i, j) is a candidate edge.
Otherwise, the heuristic chooses j among those nodes not already chosen.
3. Let i = j. If not all nodes have been chosen, then go to Step 2.
When more than one node may be chosen at Step 2, the node is chosen at random among the
alternatives. The sequence of chosen nodes constitutes the initial tour.
All these modifications made by Helsgaun to the original LKH made a considerable improvement to
the original algorithm. For example, considering a 318-city problem the optimal solution is now found in
approximately 2 trials and in a very short time (about one second on a 300 MHz G3 Power Macintosh).
2.5 Discussion
There are several aspects that an indoor localization system must take into consideration, the most
important of which, accuracy, precision, and scalability. Throughout the previous sections, we have
looked at several systems that implement indoor positioning systems using two technologies WiFi and
BLE beacons, others that used a hybrid infrastructure of the two and at some algorithms that would
possibly help us calculate the optimal path for the user, given his shopping list.
The solution by Chen [1] utilizes the sensors embedded in the smartphone to perform Pedestrian
Dead Reckoning. These sensors are not quite accurate enough for an indoor positioning system, so
the paper uses BLE beacons to correct the ”error” of the PDR approach, which does work, but due
to the use of few beacons, the system presents some limitations. Then the systems by Baniukevic [2]
and Antevski [3], are the ones based on a hybrid network using BLE beacons and WiFi, proving that
this approach is definitely viable in small to medium spaces. Antevski’s paper had better results than
Baniukevic’s but that is mainly due to the fact that the system created by Antevski was intended to work
in a small room when compared with Baniukevic’s system that was intended to work in a shopping mall.
Baniukevic’s system although created for big surfaces does not get the accuracy results we expected to
see on our project.
The solution by Dickinson [5] is by far the closest one to our project. By abstracting the wholesale
store as a graph, Dickinson was able to simplify the positioning problem from a two-dimensional problem
to a one-dimensional problem, since the location of the user with regard to the width of the aisle does
not matter. Since the solution uses solely BLE beacons, a particle-filtering algorithm was implemented
to improve the accuracy, managing to get very good results.
32
For the optimal path algorithm, we presented four possible solutions, three of them, shortest path
algorithms. Although, these algorithms are known for their efficiency, they only calculate the shortest
path between one node and all other nodes, as opposed to the solutions of the traveling salesman
problem that calculate the optimal path from one node X to one node Y, passing through all the others
nodes the algorithm says he has to visit.
To summarize, these works have all contributed to the design of the solution to our problem that
we present in the next section. However, two works stand out the most, Dickinson’s paper: Indoor
Positioning of Shoppers Using a Network of Bluetooth Low Energy Beacons and Helsgaun’s: An effective
implementation of the Lin-Kernighan traveling salesman heuristic. The architecture we present next is
heavily based on these two works.
33
34
3Solution Architecture
Contents
3.1 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 BLE Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
35
36
In this chapter, we present the proposed architecture for our project. Then, we discuss the main com-
ponents of the proposed architecture, namely the mobile application, the online server, the BLE beacon
network.
Our project features an online architecture, which means that its main functionalities are only avail-
able if the user is connected to the Internet. We have chosen this type architecture because of its
popularity in modern mobile applications, it facilitates further ports of the mobile application to other
operating systems since the main logic is performed server-side and due to the fact that in most super-
markets Internet connectivity is guaranteed. Furthermore, we can leverage the computational power of
online servers to perform performance heavy tasks.
Figure 3.1: Our system’s architecture.
As seen in figure 3.1, our project is based on a mobile application, an online server, a BLE beacon
network. We describe all these components of our work in the next three sections.
3.1 Mobile Application
Our mobile application allows the user to create a personalized shopping list with the products he desires
to buy and it is responsible for measuring the signals coming from the BLE beacons. After the user
creates the shopping list, the list is sent to the server that then takes the list and uses it to calculate
37
the optimal path and returns it to the user, i.e. to the mobile application. The application takes the path
calculated by the server and uses it to show the direction in which the user must move.
The mobile application is divided into two different layers: the Presentation Layer and the Business
Layer. The Presentation Layer provides a user interface where the input of the application is specified
(inputs, buttons, etc.) and its output is shown. The Business Layer contains all the libraries that our
application uses. In fact, it makes the necessary requests to perform all the business logic, like server
communication and directions logic.
The direction displayed is based on a compass, i.e. an arrow is shown to the user indicating the
direction in which he must move until he reaches the next product on his list. We explain how this
compass system was implemented in section 4.2.1.
It is important to mention that at any time while shopping the user can add or remove items from his
list. When this happens, a new list is sent to the server and a new path is calculated and returned to the
application. This path, instead of having its starting point in the supermarket entrance, its starting point
is the location in which the user was when requesting a new path.
3.2 BLE Beacon Network
We propose a network infrastructure where N BLE beacons are deployed along the aisles of the su-
permarket, similar to what was done by Dickinson [5]. This network works in a way that allows us to
transform the supermarket surface into a connected graph, i.e. the beacons are placed along the aisles
of the supermarket in such a way that they act as the nodes of the graph. An example of the placement
of the beacons along an aisle can be seen in figure 3.2.
Figure 3.2: Possible beacons layout on an aisle.
38
The beacons are deployed along one side of the aisle, at regular (but not always equal) intervals
corresponding to the ends of shelving units. We use Dickinson [5] approach to simplify the positioning
problem from a two-dimensional problem to a one-dimensional problem, by discarding the user’s position
regarding the width of the aisle. The idea is to be able to locate the user on a defined axis parallel to the
aisle. This axis is identified in red in figure 3.2.
3.3 Server
The server is the core of the system and it is responsible for calculating the optimal path for the user
based on his shopping list and for managing all the information from the BLE beacon network, like the
beacon coordinates, what products are associated with which beacon and all the graph specifications
(nodes and edges).
After the user sends the shopping list to the server, the server access the Structured Query Language
(SQL) database, where all the BLE beacon network information is stored, to retrieve the information
necessary to calculate the optimal path based on the shopping list the user sent.
The optimal path is calculated using the solution for the traveling salesman problem created by
Helsgaun [4] where the author applies the Lin-Kernighan heuristic effectively to TSP.
The server keeps in its SQL database all the information necessary from the BLE beacon network to
calculate the optimal path and returned it to the user. This functionality is key for the people managing
the supermarket layout because by having all the information from the BLE beacon network it makes this
network highly customizable. This means, that new products can be added and products can change
location on the supermarket without having to update the mobile application.
39
40
4Implementation
Contents
4.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 BLE Beacon Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
41
42
In this chapter we describe the implementation of our project. We start by describing the implementation
of the server. In particular, how we implemented the optimal path algorithm and what information is
stored in the MySQL database. Next, we describe the implementation of the mobile application, in par-
ticular how the direction that is shown to the user is calculated. Finally, we describe the implementation
of the BLE beacon network.
4.1 Server
As discussed previously, the online server is the core of our system and it is responsible not only for
calculating the optimal path but also for storing the MySQL database, that contains all the data from the
BLE beacon network necessary to calculate the optimal path.
The server creates a new thread for each client connection. This is done so every client request is
independent of every other client requests, i.e. a client does not need a request from another client to
end so that his request can be treated. This also affects the scalability of the system. By having a thread
for each client, the system can withstand a greater number of clients without having a major decrease in
performance. A diagram of the thread system used by the server can be seen in figure 4.1.
Figure 4.1: Server’s thread system.
When the server starts, the information in the database that concerns the graph, that abstracts the
supermarket layout, is retrieved and the graph is created and all the data structures necessary to run the
optimal path algorithm are initiated. Then, the server creates the socket that will receive the connections
from the clients and from that point on the main thread of the server stays in a loop waiting for client
connections
43
After a client connects to the server and a thread has been assigned to it, the server receives the
shopping list sent by the client. This list is then treated, so it is in a format that can be passed to the
algorithm.
4.1.1 Database
We now present the online database created, since it’s features will be needed to explain the remainder
implementation of the system. The database available on the server is in MySQL format. We wanted
to simplify the process of editing the BLE beacon network as much as possible, like adding or removing
products, adding or removing beacons and changing products locations. We implemented a database
that reflects those requirements. Its model can be seen in figure 4.2.
Figure 4.2: Server’s database model.
We begin by explaining the tables that are only connected to the deployment of the BLE beacons
and the products associated with them. The products table, contains only the products present in the
supermarket, making it simpler to add or remove products. The beacons table contains information
from each of the beacons deployed in the supermarket, their UUID and their major and minor numbers,
the last two work as their coordinates in the supermarket as well. It is also important to note that in
the current state, the database allows for a single node to have more than one product associated to it
and allows for a single product to be in more than one beacon at once. We implemented the database
this way, because it is common for supermarkets to have the same product in multiple locations, due to
44
promotions.
Figure 4.3: Example content of the products, beacons and products to Beacons tables.
The next three tables contain information that is directly connected with the optimal path algorithm,
i.e. these tables contain information about the graph that abstracts the beacon deployment in the super-
market. The beacon nodes table, reflects the relationship between a node of the graph and a beacon
from the BLE beacon network, i.e. for each beacon, it saves the node associated with it, since a beacon
corresponds to one and only one node. The graph paths table, contains each edge, that connects two
nodes directly, of the graph, i.e. contains a source node and a destination node and the cost to go from
one to another. Finally, the graph augmented paths table, contains, similar to the graph paths, contains
the information about edges in the graph used by the optimal path algorithm. However, in this case, the
edges represented in this table, are augmented edges, i.e. edges that connect two nodes that are not
directly connected. This is needed due to the fact that the TSP assumes that the salesman will only
pass through a city (node) once and only once, but in our project, we want that the client to have the
possibility to pass through the same node more than once.
The augmented edges are created for this end. Consider the nodes A,B and C, we want to get from
A to C, but to do that we have to go through node B. We create and augmented edge from A to C,
where its cost is the sum of the cost from A to B and the cost from B to C. This way, every single node
from the graph is connected to every other node either by a direct edge or an augmented edge. The
augmented edges are calculated by running Dijkstra’s algorithm in every node and calculate the shortest
path from those nodes to every other node to which they are not directly connected.
In summary, the graph augmented paths table, contains the information about augmented edges,
i.e. the source node, the destination node, the total cost and the path necessary to go from the source
node to the destination node.
Figure 4.4: Example content of the beacon nodes, graph paths and graph augmented paths tables.
45
4.1.2 Optimal Path Algorithm
As we discussed before, in section 3.3, our solution is based on the solutions for the traveling salesman
problem, in particular, the solution created by Helsgaun [4]. However, this is not the only solution we
use in our system, we also use an implementation of the Dijkstra’s algorithm [18] and a implementation
of a solution to the TSP that uses the nearest-neighbor approach. We explain how we implement these
solutions and when they are used throughout this section.
It is important to note, before we explain the actual algorithm, that when the server is initiated, all
the information needed, from the database, for the algorithm to be executed is retrieved and stored in
variables. This is done, to simplify the access to the information when the algorithm is being executed.
When the data is retrieved from the database, a cost matrix, C, is created where c(i, j) is the cost of
the edge that connects node i and node j. Two maps are also created, one that maps every product to
the beacon UUID where it is located and the other that maps every product to the node in the graph.
The algorithm starts by receiving the shopping list created by the client, this list has already been
parsed and is now ready to be used by the algorithm. Another information that the algorithm receives
from the client, is if this list is an edited to a previous list or not. This is done, so the algorithm knows if it
must use the starting point as the entrance of the supermarket or the current location of the client.
Then, depending on the size of the list, one of three possible solutions are used. If the list sent by
the client only has one element, the Dijkstra’s algorithm is used. If the list has two to five elements, a
solution to the TSP using a nearest-neighbor approach is used. If the list has more then five elements
the solution created by Helsgaun is used. These three solutions are used at different times so that when
it is not necessary to use resource heavy process, simpler process are used.
The solution created by Helsgaun, needs two specific files to be executed, the parameter file, .par,
and the problem file, .tsp.
The problem file contains a specification of the problem instance to be solved. The file format is
the same as used in TSPLIB [30]. The current version of the software allows specification of symmet-
ric, asymmetric, as well as Hamiltonian tour problems. Distances (costs, weights) may be given either
explicitly in matrix form (in a full or triangular matrix), or implicitly by associating a 2- or 3-dimensional
coordinate with each node. In the latter case, distances may be computed by either a Euclidean, Man-
hattan, maximum, geographical or pseudo-Euclidean distance function. In our implementation, we give
the distances in an explicit full matrix.
46
Listing 4.1: .tsp file example.
1 NAME : client556707052018174015
2 TYPE : TSP
3 DIMENSION : 17
4 EDGE WEIGHT TYPE : EXPLICIT
5 EDGE WEIGHT FORMAT: FULL MATRIX
6 EDGE WEIGHT SECTION
7 0 170 180 190 230 190 140 160 180 160 140 160 210 150 150 210 100
8 170 0 110 160 80 160 110 90 110 130 30 90 140 170 160 80 70
9 180 110 0 190 110 190 120 100 120 140 80 100 120 180 180 30 80
10 190 160 190 0 80 0 180 150 130 200 180 200 250 60 40 160 140
11 230 80 110 80 0 80 170 70 50 190 110 150 170 100 80 80 130
12 190 160 190 0 80 0 180 150 130 200 180 200 250 60 40 160 140
13 140 110 120 180 170 180 0 100 120 20 80 100 150 140 140 150 40
14 160 90 100 150 70 150 100 0 20 120 60 80 130 160 150 130 60
15 180 110 120 130 50 130 120 20 0 140 80 100 150 150 130 130 80
16 160 130 140 200 190 200 20 120 140 0 100 120 170 160 160 170 60
17 140 30 80 180 110 180 80 60 80 100 0 60 110 140 140 110 40
18 160 90 100 200 150 200 100 80 100 120 60 0 50 160 160 110 60
19 210 140 120 250 170 250 150 130 150 170 110 50 0 210 210 90 110
20 150 170 180 60 100 60 140 160 150 160 140 160 210 0 20 180 100
21 150 160 180 40 80 40 140 150 130 160 140 160 210 20 0 160 100
22 210 80 30 160 80 160 150 130 130 170 110 110 90 180 160 0 110
23 100 70 80 140 130 140 40 60 80 60 40 60 110 100 100 110 0
24 EOF
The parameter file contains control parameters for the solution process. This file allows us to per-
sonalize many of the specifications of the Helsgaun solution, but since the default values, as shown by
the paper presented by the author [4], get good results in almost every application, we used them in our
implementation.
Listing 4.2: .par file example.
1 PROBLEM FILE=D:/work/Tese/LKH-2.0.7/LKH-2.0.7/556707052018174015/client556707052018174015.tsp
2 TOUR FILE=D:/work/Tese/LKH-2.0.7/LKH-2.0.7/556707052018174015/client556707052018174015Tour.txt
3 OPTIMUM = 2147483647
4 STOP AT OPTIMUM = NO
5 RUNS = 1
47
To create and save this two files, a directory is created for each user that connects to the server, the
name given to this directory is based on a randomly generated integer and a time stamp, both calculated
when the clients connect to the server.
The problem file is created, using the cost matrix C. Every cost value, c(i, j), that represents the cost
of an edge or augmented edge that connects two nodes that are related to products in the shopping
list created by the client, is inserted in the file as a value of the distances matrix, D. This matrix works
exactly like matrix C, i.e. d(i, j) represents the value of the cost of the edge between node i and node j.
The file is then saved in the directory created before.
After the problem file has been created, the parameter file is needed, to specify to the LKH which
problem file is trying to resolve. In the parameter file, we specify the problem and tour files, the tour
file is simply the file where the LKH will write the calculated path. Other specifications are made in the
parameter file, such as the number of runs, that we set as 1, the optimum and if the LKH should stop
or not when this optimum is found. Since the problems we pass to the LKH are not know problems,
i.e. they do not have an already calculated optimums, we set the optimum as a much higher value that
can be achieved by adding all of the costs in C and set the STOP AT OPTIMUM to NO. This two last
specifications ensure that we calculate the best possible path.
The solution created by Helsgaun, takes this two files and calculates the best path using the modified
Lin-Kernighan Heuristic created and writes it in the aforementioned tour file. This tour file is then read
by our algorithm, that retrieves the path calculated and starts prepping it to send it to the client.
Listing 4.3: Tour file example.
1 NAME : client556707052018174015.1010.tour
2 COMMENT : Length = 1010
3 COMMENT : Found by LKH [Keld Helsgaun] Mon May 7 17:39:05 2018
4 TYPE : TOUR
5 DIMENSION : 17
6 TOUR SECTION
7 1
8 14
9 15
10 6
11 4
12 5
13 9
14 8
15 11
48
16 2
17 3
18 16
19 13
20 12
21 10
22 7
23 17
24 -1
25 EOF
Two paths are sent to the client, the real path and the view path. The real path contains all the nodes,
even those that come form the augmented paths, unlike the view path that only contains the nodes that
derive directly from the products in the shopping list sent by the client.
In addition to the two paths, two more maps are sent to the client, beaconIdToProducts and bea-
conIdToCords. The first map represents the direct relation between a beacon UUID and the product
that is associated with it. The second map, on the other hand, represents the direct relation between a
beacon UUID and its coordinates in the supermarket, i.e. it’s major and minor numbers. These maps
are used by the mobile application for calculating the direction in which the user must go and to correctly
see if the user has reached the next beacon on the list. It is also important to note, that the maps sent
to the client only contain the information relevant to the list the client sent to the server.
4.2 Mobile Application
The mobile application is an essential component of our system, so it was important to make sure that
we implemented it in a mobile Operating System (OS) that made sense. To achieve that we looked at
mobile operating system market share from last year until now and clearly one OS stands out as seen
in figure 4.5.
The mobile operating system Android, according to StatCounter1, at the time of writing of this doc-
ument, April of 2018, represents approximately 75% of the market share in Portugal. Therefore, we
believe that this is the mobile platform in which made sense to implement our project.
The Estimote Proximity SDK only works on the version 5.0 of Android (SDK 21) or above. Therefore,
our application was implemented to work on devices with Android SDK 21 or above. The application
was developed in Java language, using Android’s SDK.
The mobile application, allows the user to create a personalized shopping list and send it to the
server, so the server can calculate the optimal path based on the list, then, after the online server has1http://gs.statcounter.com
49
Figure 4.5: Mobile operating system market share in Portugal from April 2017 - April 2018.
calculated the optimal path based on the list created, the application shows the user the direction in
which he must move to reach every product on the list he created.
The application contains only three activities. Again we implemented the system with only the main
features in mind, the MainActivity, the ListActivity and the PathActivity. These activities implement two of
the main features of our system, the creation of the shopping list and the orientation of the user through
the supermarket.
The MainActivity is the first activity the user comes across when opening the application. This activity
functions as a home activity, i.e. it would be here that the user would access most of the functionalities
of the application, for this project the only functionality accessible through here is the creation of the
shopping list, via a button that leads the user to the ListActivity.
When in the ListActivity, the user is presented with a list of products, this list allows the user to select
and deselect each and every one of the products in the list. After the user considers the list finished, the
user can send it to the server so the optimal path can be calculated.
After the path has been calculated and the server sends the path to the application, the application
starts the PathActivity. This activity takes the data sent by the server, the real path, the view path, the
beaconIdToProducts and thebeaconIdToCords, and uses it to start showing the direction in which the
user must move to reach the next product on the list.
50
When the PathActivity is initiated, multiple variables are initiated as well and the views are set. A
beacon region is initialized using the proximity UUID of the beacons, we explain how this UUID works in
section 4.3, but for now just assume that is an identifier and that every beacon in the supermarket has
the same one. This region will be used by the application to know if it is in the range of any beacon. The
compass used to direct the user in the right direction is also initialized, we explain how this compass
further in section 4.2.1.
After all the variables have been initialized and the application is ready to direct the user, the user is
asked to move to the starting point, in most cases this will be the entrance of the supermarket. From
here the user will be shown directions to the first node in the real path, although in the screen it appears
the first node of the view path. During the shopping process, the application will display in the screen an
arrow, which indicates the direction in which the user must move, and a product. This product is always
the first element in the view path. This is done to not confuse the user by showing on screen products
the user did not add to the shopping list.
In the following images, we present examples of the screens of the mobile application.
Figure 4.6: Screen of the MainActivity.
51
Figure 4.7: Screen of the ListAc-tivity with unselecteditems.
Figure 4.8: Screen of the ListActiv-ity with selected items.
Figure 4.9: Screen of the PathAc-tivity when the userstarts its shopping.
Figure 4.10: Screen of the PathAc-tivity when the use isat the staring point.
52
Figure 4.11: Screen of the PathAc-tivity when not in theproximity region of thebeacon.
Figure 4.12: Screen of the PathAc-tivity when the user isin the proximity regionof the beacon.
Figure 4.13: Screen of the PathAc-tivity when the beaconis the closest one tothe user.
53
While shopping, if the user enters the region of a beacon one of three things can happen
• Beacon is not an element of the real path: This event is ignored and nothing happens.
• Beacon is only an element of the real path : This node is removed from the real path and the
direction to the new first element of the real path is shown to the user.
• Beacon is an element of both the real path and the view path: When this happens, it means
that at least one of the products associated with the beacon is one of the products in the user’s
shopping list. In this case, the arrow showing the direction will turn green, signifying to the user that
the next product it’s getting closer, and a new thread is launched. This thread has only objective
to run a ranging listener until the closest beacon detected by it is the beacon associated with the
product in question, i.e. the first element of both the real path and the view path. After the ranging
listener detects the beacons as the closest beacon, the user must click a button to ensure the
application that the product has been collected the, the node is removed from both paths and the
direction to the first element of the real path is shown to the user (with the arrow grey again).
Figure 4.14: Diagram that shows how the application behaves when entering a proximity zone of a beacon.
It is important to note that when the application, since the application saves the last five beacons
whose regions the application had entered, detects that the user is straying from the path calculated, a
pop up will show on the screen notifying the user that he is straying from the path. When this happens,
two options are given to the user, try to get back to the path or recalculate the path using the current
position as the starting point.
54
It is also possible that the user wants to add or remove products while shopping, we support this
feature by letting the user access the shopping list created and adding or removing products. When the
user edits the list while shopping, a pop up will appear on screen, similar to the one when the user strays
from the path, asking the user to stay still so the closest beacon can be used as the starting point. Then,
the new list is sent to the server, that calculates the path and returns it to the application. When the path
is returned, the PathActivity is initiated as normal using the new path and using the current user location
as the starting point.
As the user finishes shopping, i.e. when the user has gone through all of the products on the
shopping list, the application shows the direction to the checkout area.
4.2.1 Direction Manager
To be able to calculate the direction in which the user must move, we needed to be able to know the
exact position of each product in the supermarket. To achieve this, we create a Cartesian coordinate
system, i.e. a coordinate system that specifies each point uniquely in a plane by a pair of numerical
coordinates, which are the signed distances to the point from two fixed perpendicular directed lines,
measured in the same unit of length, that attributes two coordinates, (x, y), to each node of the graph,
we explain how these coordinates are implemented in section 4.3.
Since the coordinate system allows us to know the exact location in the supermarket of each node of
the graph, we needed a system that based on those coordinates could calculate the direction in which
the user should move to reach the products. Since the most common way to know in which direction you
must move, is with the use of a compass, we decided to abstract how our system calculates and shows
the direction as a compass.
We then implemented a simple compass, using two of the built-in sensors in most mobile devices, the
accelerometer, and the magnetometer, implementing a noise filter (Low-pass filter) as well to keep the
arrow, that indicates which way is north, more stable. But since we need our compass to indicate the di-
rection to each product and not in which direction is north, like a normal compass does, we implemented
some changes to the ”normal” compass to achieve our goal.
Before we explain the changes we implemented to the compass, it is important to remember that
a compass face is split into 360 marks called degrees. The degrees indicate in which direction the
compass is pointing, north is at 0 degrees, east at 90 degrees, south at 180 degrees and west at 270
degrees.
Considering the point to which a ”normal” compass points, the true north (0 degrees), and con-
sidering as the supermarket north, the direction in which a compass would point, if the compass was
positioning in the supermarket entrance pointing forward towards the supermarket surface and the de-
gree value registered by the compass, α, was added to the degree value of true north. The relation
55
between true north and supermarket north can be better seen in figure 4.15.
Figure 4.15: Angle between Real North and Supermarket North.
We calculate the supermarket north and use it as the default value in which our compass will be
pointing. In this project, we have only one supermarket, so the supermarket north is a fixed value, but
the idea is that this value could change based on the supermarket the user chooses to visit.
Since the coordinates associated with each node of the graph are calculated based on the supermar-
ket north, every time a new direction needs to be calculated, the application takes the coordinates from
the node the user is at (source node) and the coordinates from the next node to visit (destination node)
and calculates the angle, β, in degrees, between the vector between the two points and the positive
x-axis, using
atan2(δY, δX) ∗ 180π (4.1)
where δY = P2y − P1y, δX = P2x − P1x, P1 and P2 being the source node and the destination
node respectably.
The calculated angle, β, is then added to the value of the supermarket north, showing now the
direction in which the user must move to reach the next product.
It is also important to note that the direction shown to the user, always takes into account the user’s
orientation in relation to the supermarket north.
56
4.3 BLE Beacon Network
To implement our BLE beacon network we use Estimote localization beacons, that use the iBeacon
protocol (Section 2.2.1). The choice of this beacons was influenced by the fact that these beacons are
very easy to use due to the different SDK’s provided by Estimote Inc. and by the popularity of these
beacons.
The choice of the location beacons instead of the proximity beacons was influenced by the fact that
when testing the proximity beacons with Android, these beacons were not recognized by the Android
mobile application. So we decided to use the location beacons taking advantage of the fact that these
beacons can be used as proximity beacons with extended battery life.
These beacons when broadcasting their Bluetooth signal send the iBeacon packet, that we described
previously. We use the contents of the iBeacon packet, more specifically the major and minor numbers,
to divide the supermarket surface into sections, using them to implement the Cartesian coordinate sys-
tem we described in previous sections.
Let the major number be the identifier of the aisle and the minor number be a certain section of
that aisle, we can then, like in figure 3.2, have a well section out supermarket surface. In figure 3.2,
is represented only one aisle and the letter A represents the major number and the minor number is
represented by the different numbers representing the different sections of that aisle.
Every beacon is set with the same proximity UUID. This works as the identifier for the beacon region
described in section 4.2. The idea is that this proximity UUID will work as a supermarket identifier, i.e.
every beacon from the same supermarket will have the same proximity UUID but beacons in different
supermarkets will have different proximity UUIDs.
57
Figure 4.16: Possible beacon deployment in a supermarket surface. The yellow squares represent the beaconsposition.
58
5Evaluation
Contents
5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Optimal Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Precision and Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Other Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 Evaluation Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
59
60
This chapter describes the experiments we conducted to evaluate our system. The evaluation was
divided into four parts: system’s scalability, optimal path, precision, and accuracy. The objective of the
system’s scalability evaluation is to ensure that the server implemented is handling the user’s requests
properly, and also to see if the algorithm takes a large toll on the server’s performance. The optimal path
evaluation objective is to help us understand if the algorithm implemented is calculating paths that are
optimal or one at least close to it. Finally, the precision and accuracy evaluation is to ensure that the
beacons used can pinpoint the user location fairly accurately and precisely.
5.1 Scalability
In this section, we detail the experimental tests to evaluate the performance of our server. We wanted
to test how the number of nodes and number of concurrent clients would affect the performance of the
system.
To test the performance of the system, taking into account the number of nodes in the graph and the
number of concurrent clients, we implemented a function that created connected graphs whose nodes
are all connected by edges with the same cost. This was done to simplify the creation of graphs and to
allow us to create graphs with a bigger number of nodes.
Then, a java client application was created to mimic the behavior of the mobile client application, so
we could test also a bigger number of concurrent clients. This application launches n threads that all
connect to the server and send a shopping list containing every single node of the graph. By doing this,
we were able to see what had more impact on the performance of the system, the number of nodes or
the number of concurrent clients.
The tests were performed in an Asus X550L laptop, with an Intel Core i7-4500U CPU @1.80GHz
and 8 GB of RAM. The results of the tests can be seen in figure 5.1.
By analyzing the graph it is easy to see that, what had more impact on the performance of the server
was the number of concurrent clients. This drop in performance, due to the number of concurrent clients,
can be because of the machine used to run the tests or even because of the fact that both the server
and client applications were running in the same machine.
Either way is easy to see that the increasing number of concurrent clients has a big toll on the
performance of the system. The number of nodes, despite some spikes in execution time, don’t seem to
have such a toll on performance. Even with one thousand nodes and fifty concurrent clients, the path is
calculated in less than a second.
We believe that with a better machine, and with the server and client applications running on separate
machines, the performance would be better.
61
Figure 5.1: Results of the scalability tests. The different colors represent the number of nodes in the graph.
5.2 Optimal Path
In this section, we detail the experimental tests to evaluate the quality of the paths calculated by the
algorithm.
To test the quality of the paths calculated, we created three possible scenarios, that we believe will
test the quality of the paths. The scenarios we created consist in choosing nodes at certain locations
of the supermarket and analyzing the paths calculated by the algorithm, assuming the selected nodes
as the nodes chosen by a client. The scenarios were based on the representation of a supermarket
floor, presented in figure 4.16. Two small modifications were made to this representation. Instead of
two beacons, that could function as the starting point, now we have only one, and instead of having a
beacon in every checkout, now we have one in the most central one, allowing the user to choose the
checkout it wants.
It is also important to say that the optimal paths represented in this scenarios are paths that we
believe function as optimal, they are not calculated optimal paths.
The first scenario consists of choosing nodes that are in each of the corners of the supermarket. The
objective of this scenario is seeing if the algorithm calculates a path that will stay by the edges of the
62
supermarket and not go through nodes that are in the center. The results of the test performed in this
scenario can be seen in figure 5.2.
Figure 5.2: Representation of the optimal and calculated paths in the first scenario. The beacons are representedby the yellow squares, the ones that would be on the client shopping list are highlighted with a red circlearound them. The optimal path is presented in blue and the calculated path in green.
Looking at the results from the first scenario, figure 5.2, we can see that the difference between
what we consider to be the optimal path and the calculated path is practically nonexistent. Proving the
effectiveness of our algorithm.
The second scenario consists of choosing two clusters of nodes that are in opposite ends of the
supermarket. The objective of this scenario is seeing if the algorithm calculates a path that would go
through all of the nodes in a cluster and then move on to the next, instead of going back and forth
between them. The optimal and calculated paths for this scenario can be seen in figure 5.3 and figure
5.4 respectively.
63
Figure 5.3: Representation of the optimal path in the second scenario. The beacons are represented by the yellowsquares, the ones that would be on the client shopping list are highlighted with a red circle around them.The optimal path is presented in blue.
Figure 5.4: Representation of the calculated path in the second scenario. The beacons are represented by theyellow squares, the ones that would be on the client shopping list are highlighted with a red circlearound them. The calculated path in green.
64
Looking at the two paths, it is clear that the two are totally different. However, the calculated path
it is not a bad solution to this scenario. Although it would be more efficient to start from the left side
of the supermarket, instead of the right side, and that there is no reason for the path to go so close
to the top edge of the supermarket, the calculated path still meets the objectives that we set with this
scenario. The calculated path still goes through all of the nodes in a cluster and then moves on to the
next, instead of going back and forth between them, so we consider the calculated path a proper solution
to the scenario.
Finally, the third scenario consists of choosing nodes that are in the central aisles of the supermarket.
The objective of this scenarios is seeing if the algorithm calculates a path that goes through all the nodes
effectually. The results for this scenario can be seen in figure 5.5.
Figure 5.5: Representation of the optimal and calculated paths in the third scenario. The beacons are representedby the yellow squares, the ones that would be on the client shopping list are highlighted with a red circlearound them. The optimal path is presented in blue and the calculated path in green.
Similar to what happened with the results of the second scenario, the optimal path and the calculated
path are different. However, the two paths are possible solutions to the scenario and both meet the
objectives set for this scenario. So again, we consider the calculated path a proper solution to the
scenario.
65
5.3 Precision and Accuracy
In this section, we detail the experimental tests to evaluate the precision and accuracy of the system.
To test the precision and accuracy of the system, we created a cluster of six beacons, about 1.5
meters away from each other, with the intent to test how accurate and precisely the system can detect
to which beacon the user is closer.
We had access to eight Estimote location beacons. However, this test was executed with only six of
them, since this six were the ones that were the most recent, having the F3.3 hardware version, unlike
the other two that were older and had the F2.3 version of the hardware.
The newest version of the hardware, allowed us to set the broadcasting power even lower, to −40
dBm. Having a lower broadcasting power ensures the stability and quality of the signal and lowers the
maximum range reach by the signal since we want that the proximity zone of every beacon is around
1 meter from the beacon, this is ideal for our setup. The advertising interval was also set to the lowest
possible value, 100 ms, to ensure the stability and quality of the signal. During the test, every beacon
was positioned about waist height.
A simple mobile android application was created, to record the signal strength of each beacon at dif-
ferent distances. This application implemented a ranging listener that recorded all nearby BLE beacons
and put them in a list, organized from closest to farthest away.
Three distances were tested, 0.5m, 1m and 1.5m. We tested this values because we wanted to
simulate when the user is immediately close to the beacon, when the user starts to walk away from the
beacon and when the user is close to leaving the beacon’s range. The results of the tests can be seen
in figure 5.6.
By looking at the graph, the first thing we notice is the massive difference, in signal strength, from
0.5m to 1m, this can may be justified due to noise in the room where the tests were realized.
We also notice that, at each distance, the values for signal strength for each beacon are fairly close,
signifying that the system is quite precise at determining how close the user is to a certain beacon.
In relation to the accuracy of the system, we can say that the system is quite accurate at determining
of the user is immediately close to a beacon or is starting walk away from it. Since the difference in
signal strength, in this two instances, is so significant. However, in the difference between 1m and 1.5m
is close to minimum, so we can say that the system is not very accurate at determining if the user is
leaving the beacon’s range or just barely walking away from it.
66
Figure 5.6: Results from the precision and accuracy evaluation.
67
5.4 Other Results
In this section, we detail other results besides the ones mentioned in previous sections. These results
reflect other features besides the ones mentioned in the objectives, section 1.2. However, we think that
they are still worth to discuss.
During the precision and accuracy evaluation, we also tested if the feature we implemented in the
application, that allowed the application to warn the user if he starts to stray from the calculated path.
With a simple test, we ensured that this feature was indeed working.
The test simply involved, having three beacons, as beacons that belonged to the path, and the other
five not belonging. From there, was simply a question of seeing if, when we strayed from the path and
were only close to the five beacons that did not belong to the path if a pop up showed up, and indeed
it did. This feature is important to mention because it will be common for a user using an application
like ours, that tries to direct the user in a certain direction, to become distracted and deviate from the
direction intended. So we wanted to be able to warn the user that this was happening and give the
option to the user to correct it.
It is also important to note that the algorithm, when a client sends a list with a product that is in more
than one node, due to promotions, for example, returns the path with the node that results in the path
with the lower cost. Since every edge of the graph has a cost, the algorithm calculates a number of
paths equal to the number of nodes where the product in question is located, each path containing only
one of those paths, and returns the one with the lowest cost. This feature is working and it was tested.
The test involved having three beacons with the same product associated and different cost and
analyzing what path the algorithm returned.
5.5 Evaluation Conclusions
The evaluation of the system, overall, went as expected and with results that satisfy our goals.
Although the server performance could have been better, the capacity of the algorithm to calculate
paths that are accepted as good solutions in most scenarios compensates for that. The evaluation of
system accuracy and precision, also gave us very good results, since, in terms of precision, the system
is right where we need it to be, i.e. the system can systematically detect if a user is close to a beacon
or not. In terms of accuracy, the results could have been better at 1m and 1.5m, but the fact that the
system can detect fairly accurately if a beacon is immediately close or just nearby, is a big plus, since
our system only works if beacons that are in those two types of instance.
68
6Conclusions
Contents
6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
69
70
In this dissertation we suggested a system, that could take advantage of the fact that most people nowa-
days possess a smartphone, to use these devices as a tool in mundane tasks, like grocery shopping.
Firstly, we looked at how this could be done, what technologies we could use and what type of system
we could create. We looked, mainly, at two technologies in specific, WiFi and Bluetooth. We researched
whether something of the type had already been done and in fact, some work had already been done in
this area, but still, we thought we could do more.
We took some inspiration from previous academic works and tried to improve on it. Our idea was, to
create a system that by combining indoor positioning and an algorithm that could calculate an optimal
path, or one close to optimal, given a shopping list created by a user, could navigate said user through
the supermarket and help him reach his products much more effectively.
In order to implement this system, we chose to use a BLE beacon network for our indoor positioning
needs and a solution to traveling salesman problem using the LKH as our optimal path algorithm.
We implemented the system, abstracting the BLE beacon network as a connected graph to be used
by our optimal path algorithm. We also implemented an Android mobile application, to allow the user to
create his shopping list and to be the Bluetooth receiver of the Bluetooth signals sent by the beacons in
our BLE beacon network.
We then evaluated our work, by testing its scalability, its capacity of creating optimal paths given a
personalized shopping list, its precision, and accuracy when pinpointing the user position in our BLE
beacon network. We got pretty good results with our evaluation, but still, we believe there is space for
improvement in certain areas.
6.1 Future Work
As this work stands, it allows for a user to create a personalized shopping list so that an optimal path can
be calculated and returned to him, so the user uses this path to navigate through a supermarket surface
in a much more effective manner. However, the platform has a big potential if some improvements are
made.
• Save shopping lists. The ability to save personalized shopping lists, so they can be used later is
pretty much a must-have in a system like this. We did not implement this feature, just because we
focused on the main features of the system.
• Integration with the tickets from the supermarkets stands. Most supermarkets nowadays have
tickets for most of their stands, butcher, fishmonger, etc. It would be a nice addition to the system’s
mobile application, being able to pick your ticket directly from the application and then know when
it is almost your ticket coming up.
71
• Augmented reality. Augmented reality has been used in a various number of ways, especially
now that smartphones allow for this feature in their applications. By having an augmented reality
in the system’s mobile application, the compass like feature to show the user in which direction
we must move would not be necessary, because the path would be shown to the user directly.
The augmented reality could also be used to show promotions, right when the user passes the
products affected by those promotions. The possibilities in implementing augmented reality in a
system like these are almost endless.
72
Bibliography
[1] Z. Chen, Q. Zhu, H. Jiang, and Y. C. Soh, “Indoor localization using smartphone sensors and
iBeacons,” 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA), pp.
1723–1728, 2015. [Online]. Available: http://ieeexplore.ieee.org/document/7334389/
[2] A. Baniukevic, C. S. Jensen, and H. Lu, “Hybrid indoor positioning with Wi-Fi and Bluetooth: Archi-
tecture and performance,” Proceedings - IEEE International Conference on Mobile Data Manage-
ment, vol. 1, pp. 207–216, 2013.
[3] K. Antevski, A. E. C. Redondi, and R. Pitic, “A hybrid BLE and Wi-Fi localization system for the cre-
ation of study groups in smart libraries,” 2016 9th IFIP Wireless and Mobile Networking Conference,
WMNC 2016, pp. 41–48, 2016.
[4] K. Helsgaun, “Effective implementation of the Lin-Kernighan traveling salesman heuristic,” Euro-
pean Journal of Operational Research, vol. 126, no. 1, pp. 106–130, 2000.
[5] P. Dickinson, G. Cielniak, O. Szymanezyk, and M. Mannion, “Indoor positioning of shoppers using
a network of Bluetooth Low Energy beacons,” 2016 International Conference on Indoor Positioning
and Indoor Navigation, IPIN 2016, no. October, pp. 4–7, 2016.
[6] J. Xiao, Z. Zhou, Y. Yi, and L. M. Ni, “A Survey on Wireless Indoor Localization from the
Device Perspective,” ACM Computing Surveys, vol. 49, no. 2, pp. 1–31, 2016. [Online]. Available:
http://dl.acm.org/citation.cfm?doid=2966278.2933232
[7] P. Kriz, F. Maly, and T. Kozel, “Improving Indoor Localization Using Bluetooth Low Energy Beacons,”
Mobile Information Systems, vol. 2016, 2016.
[8] R. Faragher and R. Harle, “Location Fingerprinting With Bluetooth Low Energy Beacons,” vol. 33,
no. 11, pp. 2418–2428, 2015.
[9] Z. Zhao, J. Fang, G. Q. Huang, and M. Zhang, “iBeacon Enabled Indoor Positioning for Warehouse
Management,” pp. 21–26, 2016.
73
[10] R. Hansen, B. Thomsen, L. L. Thomsen, and F. S. Adamsen, “SmartCampusAAU - An open plat-
form enabling indoor positioning and navigation,” Proceedings - IEEE International Conference on
Mobile Data Management, vol. 2, pp. 33–38, 2013.
[11] Z. He, B. Cui, W. Zhou, and S. Yokoi, “A proposal of interaction system between visitor and collection
in museum hall by iBeacon,” 10th International Conference on Computer Science and Education,
ICCSE 2015, no. Iccse, pp. 427–430, 2015.
[12] N. S. Kodippili and D. Dias, “Integration of fingerprinting and trilateration techniques for improved
indoor localization,” in 2010 Seventh International Conference on Wireless and Optical Communi-
cations Networks - (WOCN), Sept 2010, pp. 1–6.
[13] P. C. Deepesh, R. Rath, A. Tiwary, V. N. Rao, and N. Kanakalata, “Experiences with
using ibeacons for indoor positioning,” in Proceedings of the 9th India Software Engineering
Conference, ser. ISEC ’16. New York, NY, USA: ACM, 2016, pp. 184–189. [Online]. Available:
http://doi.acm.org/10.1145/2856636.2856654
[14] Y. Zhuang, J. Yang, Y. Li, L. Qi, and N. El-Sheimy, “Smartphone-based indoor localization with
bluetooth low energy beacons,” Sensors, vol. 16, no. 5, 2016.
[15] A. H. Lashkari, B. Parhizkar, and M. N. A. Ngan, “WIFI-based indoor positioning system,” 2nd
International Conference on Computer and Network Technology, ICCNT 2010, no. January, pp.
76–78, 2010.
[16] C. Yang and H. R. Shao, “WiFi-based indoor positioning,” IEEE Communications Magazine, vol. 53,
no. 3, pp. 150–157, 2015.
[17] C. Gomez, J. Oller, and J. Paradells, “Overview and evaluation of bluetooth low energy: An
emerging low-power wireless technology,” Sensors, vol. 12, no. 9, pp. 11 734–11 753, 2012.
[Online]. Available: http://www.mdpi.com/1424-8220/12/9/11734
[18] R. E. Ahuja, R. K., Mehlhorn, K., Orlin, J. B., and Tarjan, “Faster Algorithms for the Shortest Path
Problem,” Journal of Association of Computing Machinery, vol. 37, no. 2, pp. 213–223, 1990.
[19] A. Aini and A. Salehipour, “Speeding up the Floyd-Warshall algorithm for the cycled shortest
path problem,” Applied Mathematics Letters, vol. 25, no. 1, pp. 1–5, 2012. [Online]. Available:
http://dx.doi.org/10.1016/j.aml.2011.06.008
[20] J. Chen, D. K. Friesen, and H. Zheng, “Tight bound on Johnson’s algorithm for maximum satisfia-
bility,” Journal of Computer and System Sciences, vol. 58, no. 3, pp. 622–640, 1999.
74
[21] B. M. Sathyaraj, L. C. Jain, A. Finn, and S. Drake, “Multiple UAVs path planning algorithms: A
comparative study,” Fuzzy Optimization and Decision Making, vol. 7, no. 3, pp. 257–267, 2008.
[22] K. L. Hoffman, M. Padberg, and G. Rinaldi, Traveling Salesman Problem. Boston, MA: Springer
US, 2013, pp. 1573–1578. [Online]. Available: https://doi.org/10.1007/978-1-4419-1153-7 1068
[23] E. L. Lawler, The Traveling salesman problem: a guided tour of combinatorial optimization. Wiley,
1985.
[24] S. Lin and B. W. Kernighan, “An Effective Heuristic Algorithm for the Traveling-Salesman Problem,”
pp. 498–516, 1973. [Online]. Available: http://pubsonline.informs.org/doi/abs/10.1287/opre.21.2.
498
[25] S. Lin, “Computer solutions of the traveling salesman problem,” The Bell System Technical Journal,
vol. 44, no. 10, pp. 2245–2269, Dec 1965.
[26] M. Padberg and G. Rinaldi, “Optimization of a 532-city symmetric traveling salesman problem by
branch and cut,” Operations Research Letters, vol. 6, no. 1, pp. 1 – 7, 1987. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/0167637787900022
[27] A. Adrabinski and M. Syslo, “Computational experiments with some approximation algorithms for
the traveling salesman problem,” pp. 91–95, 1983.
[28] J. Perttunen, “On the significance of the initial solution in travelling salesman heuristics,” Journal
of the Operational Research Society, vol. 45, no. 10, pp. 1131–1140, 1994. [Online]. Available:
https://doi.org/10.1057/jors.1994.183
[29] G. Reinelt, The traveling salesman : computational solutions for TSP applications, 1994. [Online].
Available: http://link.springer.com/content/pdf/10.1007/3-540-48661-5.pdf
[30] ——, “Tsplib—a traveling salesman problem library,” ORSA Journal on Computing, vol. 3, no. 4,
pp. 376–384, 1991. [Online]. Available: https://doi.org/10.1287/ijoc.3.4.376
75
76
