mobile ticketing system for public transport based …...mobile ticketing system for public...
TRANSCRIPT
Mobile Ticketing System For Public Transport Based OnBluetooth Low Energy
João Guilherme Cardoso Serra Martins
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisor(s): Prof. José Manuel da Costa Alves MarquesEng. Hugo Miguel de Jesus Bicho
Examination Committee
Chairperson: Prof. João Emílio Segurado Pavão MartinsSupervisor: Prof. José Manuel da Costa Alves Marques
Member of the Committee: Prof. Luís Manuel Antunes Veiga
November 2017
ii
Acknowledgments
First of all I would like to thank my supervisors Prof. Jose Alves Marques and Eng. Hugo Bicho, for
their knowledge and experience, who have offered me the necessary accompaniment to perform a great
work. I would also like to thank SmartCities team of LinkConsulting, for all the support and company.
I would like to show my gratitude to all my friends for the support they gave me during this stage of
my life. They gave me motivation to never give up, and happiness in the most difficult moments. Even
failing with my presence in so many events, they have always demonstrated affection and I would like to
share all my success with them.
Finally, to all my family, father, mother and sister, for all the love and sacrifice so that I could always
give my best. All I am is thanks to them, and every contribution I may make in this world will always be
their contribution. Thanks for everything.
iii
iv
Resumo
Os sistemas de bilhetica para transportes publicos tem evoluıdo, de acordo com as mais recentes
tecnologias, de forma a fornecer uma melhor experiencia de viagem aos passageiros. A maioria dos
sistemas de bilhetica utilizam tecnologias que requerem muitas interacoes manuais por parte dos pas-
sageiros. Entretanto, os smartphones tem ganho cada vez mais aceitacao, e as suas potencialidades
podem ser exploradas na area dos transportes. Isto leva-nos ao Mobile Ticketing, permitindo utilizar os
smartphones para viajar nos transportes publicos.
Propomos um sistema de bilhetica implıcito baseado em Bluetooth Low Energy para viajar em trans-
portes publicos. Este sistema deteta a presenca de passageiros dentro do veıculo, utilizando a tecnolo-
gia BLE disponıvel nos smartphones. A precisao na detecao de passageiros e crucial para a aceitacao
por parte das companhias de transportes publicos e por parte dos passageiros.
Este trabalho aborda questoes relacionadas com a computacao movel como o desempenho, o con-
sumo de bateria, a seguranca e a conectividade. Tambem tem preocupacoes relacionadas com Mo-
bile Ticketing, como o metodo de calculo de tarifas e o processo de validacao. Um prototipo com
a implementacao discutida foi desenvolvido e testado, com resultados comprovativos do potencial da
solucao.
Palavras-chave: Bilhetica, Mobile Ticketing, Smartphone, Bluetooth Low Energy, Transporte
Publico
v
vi
Abstract
Ticketing systems for public transport have evolved, according to the latest technologies, to provide a
better travel experience for passengers. Most of the ticketing systems use technologies that require a lot
of manual interactions from passengers. Meanwhile, smartphones have gained increasing acceptance,
and their potentialities can be exploited in the transport area. This brings us to Mobile Ticketing, allowing
to use our mobile phones to travel in public transport.
We propose an implicit ticketing system based on Bluetooth Low Energy when travelling on public
transport. Our system detects the presence of passengers inside a public transport vehicle, using BLE
technology available on mobile phones. The accuracy in passenger detection is crucial to the accep-
tance by the public transport companies and passengers.
This work addresses mobile computing issues like performance, battery consumption, security and
connectivity. It also concerns about mobile ticketing topics as the fare calculation method and the vali-
dation process. A prototype with the discussed implementation was developed and tested, with results
that prove the potential of the solution.
Keywords: Mobile Ticketing, Ticketing System, Smartphone, Bluetooth Low Energy, Public
Transport
vii
viii
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Topic Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 5
2.1 Ticket acquisition and storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Ticket payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Ticket fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Fixed amount per journey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Distance travelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 Source/Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.4 Zones crossed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Ticket validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Conventional method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Check-in only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 Check-in/Check-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Walk-in/Walk-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.5 Check-In/Be-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.6 Be-in/Be-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Ticket inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Communication technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ix
2.6.2 Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.3 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Previous projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7.1 ALLFA (2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7.2 Esprit (2005/2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.3 Johannes Kepler University (2014-Actuality) . . . . . . . . . . . . . . . . . . . . . . 16
2.7.4 Link Consulting Summer Internship (2016) . . . . . . . . . . . . . . . . . . . . . . 18
3 Implementation 21
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4 Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Fraud and failure cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Mobile Application 31
4.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Login/Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2 Charging money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 State visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.4 Trip history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.5 Inspection mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Counting beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Location and movement recognition . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Communication with back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 State machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Back-end Server 43
5.1 User registration and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Fare calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Trip log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Transport route and stops database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Evaluation 49
6.1 Travelling simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Obtained results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
x
6.3 Battery consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7 Conclusions 55
7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bibliography 59
A Table with comparison between previous projects 61
B Time Measurements 63
xi
xii
List of Tables
3.1 Carris (Lisbon) bus dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1 Metrics collected in each state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.1 Comparison of features between previous projects . . . . . . . . . . . . . . . . . . . . . . 61
B.1 Out to Near times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.2 Out to Near times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.3 Near to In times (when not detecting movement in check-in) (1). . . . . . . . . . . . . . . 65
B.4 Near to In times (when not detecting movement in check-in) (2). . . . . . . . . . . . . . . 66
B.5 Near to Checking-in times (when detecting movement in check-in). . . . . . . . . . . . . . 67
B.6 Checking-in to In times (when detecting movement in check-in). . . . . . . . . . . . . . . . 68
B.7 In to Checking-out times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.8 In to Checking-out times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.9 Checking-out to Out/Near times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.10 Checking-out to Out/Near times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
xiii
xiv
List of Figures
2.1 Overview of the ALLFA system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Overview of the Esprit system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Overview of the Johannes Kepler University system architecture. . . . . . . . . . . . . . . 17
2.4 State Machine Diagram of Link Consulting Project. . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Overview of the proposed system architecture. . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Components and their relationships of the proposed solution. . . . . . . . . . . . . . . . . 24
3.3 Beacon deployment diagram in a Carris standard bus. . . . . . . . . . . . . . . . . . . . . 25
3.4 Beacon deployment diagram in a Carris articulated bus. . . . . . . . . . . . . . . . . . . . 26
4.1 Registration window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Near state window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 In state window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Summary dialog window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Trip history window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Map window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Inspection mode window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Beacon regions example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Implementation State Machine diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Communication exchanged in registering process. . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Communication exchanged in travelling process. . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Entity model of transport route and stops database. . . . . . . . . . . . . . . . . . . . . . 48
6.1 Test scenario diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 State transitions graph with average durations. . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Checking-in to In times graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 In to Checking-out average duration graph. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
xv
xvi
Acronyms
API Application Programming Interface.
BIBO Be-in/Be-Out.
BLE Bluetooth Low Energy.
CIBO Check-in/Be-Out.
CICO Check-in/Check-Out.
GPRS General Packet Radio Service.
GPS Global Positioning System.
GSM Global System for Mobile Communications.
JSON JavaScript Object Notation.
NFC Near Field Communication.
OBS On-Board System.
PKI Public Key Infrastructure.
QR Quick Response.
RFID Radio Frequency Identification.
RSSI Received Signal Strength Indicator.
SMS Short Message Service.
URI Uniform Resource Identifier.
UUID Universally Unique Identifier.
WIWO Walk-in/Walk-Out.
WLAN Wireless Local Area Network.
xvii
xviii
Chapter 1
Introduction
1.1 Motivation
Public transport systems have centuries of history and have gone through many changes, providing
better conditions and commodities to passengers. Public transport supplies billions of people every day,
what requires excellent quality, to satisfy a vast number of users. However, the technical improvement of
ticketing only started recently. Early systems were based on paper tickets, usually bought on site. With
the technological advances, ticketing systems began to provide better services to passengers in order
to meet their needs. Nowadays it is possible to verify seat availability, as well as reserve and purchase
a ticket online. The time-consuming task of acquiring a ticket is becoming easier and more intuitive,
therefore less and less a barrier to public transport.
The adoption of mobile phones has become so widespread, and mobile Internet access affordable
to the masses, what enables public transport providers to explore new ways of help users to purchase
and carry electronic tickets using their smartphones, introducing a mobile ticketing approach. Mobile
ticketing is the process whereby customers can reserve, purchase and/or validate tickets using mobile
phones or other mobile handsets. It is becoming the future of ticketing services in public transport,
allowing passengers to buy tickets in advance and from anywhere. Nowadays is becoming more usual to
everyone carrying a smartphone throughout the day, becoming a fundamental need for humanity. In this
digital era it very common for the public transport providers to have a digital form of the ticket, allowing
to carry it on the smartphone or tablet. This digital capability also allows the transportation providers to
inspect travelling patterns, and therefore to adjust the provided services, for example, the organisation
during rush hours or less frequented areas, which led to an improvement in the efficiency, making
possible to lower the cost for the customers. Mobile ticketing is designed to enable a more convenient
public transport experience. Users can avoid long lines to buy a ticket, as well as the inconvenience of
holding a ticket or a card between stations. Instead, the passengers can purchase tickets through their
mobile phones and use the information stored to access public transports. From the providers’ side, it
allows them to gain insight into the behaviour of the system, providing improvements according to usage.
It can also avoid the costs of ticket printing and distribution, since it is digital, eliminating commissions
1
paid to distributors.
All check-in/check-out actions taken in just one trip are a time-consuming task, especially if there is
a flaw in the reading, which could lead to pay too much or less for the journey. However, these actions
are very relevant to public transport companies, once they provide information about the service occu-
pation. This way, it is essential not only to reduce the check-in/check-out actions but also to provide the
information required for the public transport operators to study possible improvements in the system.
Therefore, we propose an alternative to the traditional methods, to simplify the validation process follow-
ing the principle that enables people to implicitly interact with a technical system to make a transparent
check-in/check-out. Passengers may enter and leave public means of transport without the need to
present the ticket. It only needs to carry a mobile phone that, communicating with the public transport
vehicle devices, automatically takes care of billing for the journey.
1.2 Topic Overview
Mobile ticketing systems are commonly implemented based on active Radio Frequency Identifica-
tion (RFID) [1, 2, 3]. However, to explore all the capabilities of the smartphones, as an alternative and
potentially more powerful technology, Bluetooth Low Energy (BLE) is proposed. With the first BLE stan-
dard defined in 2010, this technology evolved in the low-power short-range data transfer. The BLE has
been gradually replacing RFID in indoor positioning systems and can be considered a greater solution
[2, 4, 5, 6].
In order to meet the passenger needs, a new ticketing system is proposed, according to the latest
technologies. Users can acquire and validate their tickets in an automated way using a daily device, the
smartphone. This solution eliminates many time-consuming tasks as obtaining tickets at vending stores
and checking-in and out the ticket in public transport. BLE is available in every modern smartphone,
and its capabilities can be explored to develop a passenger detection system that can be used in a new
mobile ticketing system. This project stands out for its deploying simplicity because it is not necessary to
have an on-board computer to process the check-in/out information. It only needs to deploy a set of BLE
beacons inside the public transport vehicle and a client-side smartphone application. This application
performs all the necessary processing, including the communication to a central server. The develop-
ment of this mobile ticketing system is within this master’s thesis. However, it has not only academic
content but can also be deployed in a real public transport operator infrastructure.
1.3 Objectives
Accuracy in passenger detection
One of the main goals is to achieve a good accuracy when detecting a passenger on board. It is
imperative to avoid false positives, charging people that are not really on board, or false negatives, not
billing passengers that completed a journey. The reliability of the detection is crucial to the acceptance
2
of the service by the stakeholders since the system must not lead to a monetary loss for customers
neither for public transport companies. The system should detect correctly a user inside the vehicle,
independent of the number of passengers on board, the conditions of smartphone (where is placed, if it
is covered, for example), or other constraints. If a user owns a right ticket, it should be charged, and if a
user is in the vehicle illegally should be detected by an inspector. The accuracy of the detection depends
on the quality of the communication established between the mobile device and the beacons inside the
vehicle.
Ease of use
The system should facilitate the public transportation experience. One of the main goals is to provide
the passenger with an easier way of travel in a public transport vehicle, without using more devices than
usual. The system must simplify the entire process of acquiring a ticket. It should be as simple as buying
a ticket using the smartphone, wait for the vehicle inside a station, enter the vehicle, travel, and exit the
vehicle at another station. The system automatically calculates the fare of the journey and charges it
from the user account.
Battery consumption
Smartphone batteries have limited capacity and common applications already spend much battery.
It is crucial that the system achieves the lowest energy consumption, exploring the communication pro-
tocol. Communication is the main source of battery drain and should be controlled. Connection intervals
can be tuned specifically to develop a system with low energy consumption without losing accuracy. The
use of our system should not drain the battery significantly throughout the day, being possible to use it
along with the typical applications.
Security and privacy
Since wireless communication happens at open air, everyone can eavesdrop the communication or
impersonate a legit device. Issues like these means that security and privacy measures have to be taken
to prevent abuse of the system. The traveller’s privacy must be ensured and never be tracked by another
person. Also, there should not be possible to erase or change data from the mobile device, to deceive
the system to pay less for a journey. These occurrences should be detected and prevented with secure
mechanisms, to ensure security and privacy of the data.
Minimizing costs
In order to provide a great solution to public transport companies, the system should consist in just a
few changes in the infrastructure. It should not be necessary to change the vehicle construction (cables,
on-board computer) or even stations. The goal is just to install a few small devices in each vehicle, to be
detected by the smartphone. One of the major innovations of this project is that there is not necessary
an on-board computer.
3
Multi device
The system should be available in every smartphone whatever its capabilities, except BLE and Global
Positioning System (GPS). The application has to be available to all users that carry a smartphone
independent of the manufacturer or technology. As a BLE-based system, it needs BLE, that can be
found on most major mobile platforms, such as [7]:
• iOS5 and later [8]
• Android 4.3 and later [9]
• Windows Phone 8.1 and later [10]
Therefore BLE is available in every modern smartphone since iOS5 was released in 2011, Android 4.3 in
2012, and Windows Phone 8.1 in 2014. Many of platform updates for earlier phones has been released
and are now ready to use. Although our prototype being developed in Android, this does not mean that
is platform specific, and similar solutions for other platforms can be developed.
1.4 Thesis Outline
The remainder of the document is organised as follows. Chapter 2 provides a background on the
mobile ticketing systems, referring the evolution of each related aspect. Chapter 3 presents the architec-
ture of the solution, describing the inner workings of a prototype that implements this solution. Chapter
4 explains in a more detailed way how the mobile application was developed and the technical aspects
of each functionality. Chapter 5 focuses on server implementation details, describing its structure and
algorithms used. Chapter 6 describes how the prototype was evaluated and summarises the results
obtained. Finally, Chapter 7 concludes the document and proposes future work to improve this system.
4
Chapter 2
Related Work
Ticketing services in public transport have always tried to follow the evolution of new technologies,
developing new approaches that can be adapted to user needs. The methods of acquiring a ticket to
start a journey in public transport have evolved, not only the different ways of storing a ticket (e.g. in a
paper, smartcards), but also the fare calculation methods (e.g. by travel, distance). The public transport
operators also began to develop automated ways of checking the validity of tickets carried by the users
inside a vehicle. In order to make the ticket validation more natural from the user side, new technologies
and approaches have been used, to abstract the user of this time-consuming task, but ensuring that
the system always detects an invalid ticket. Communication is crucial for the automatized systems, and
the ways of exchanging information between ticketing system components have also improved with new
technologies. The different approaches of the described features in ticketing systems are addressed
below, such as the pros and cons of each one. Lastly, previous projects relevant for this case are
presented, such as their architectures and protocols, to provide an overview of a typical global system.
2.1 Ticket acquisition and storage
In the conventional payment system for public transport, when the user intends to travel in a specific
public transport, he needs to buy a paper ticket in a store manually. In early systems, the user enters
in a ticket store, where an assistant is selling a paper (ticket) with the source, destination and hour of
the travel printed. It is also possible to buy a ticket inside the vehicle (on-board) [11], which is still being
used in some systems, like Carris in Lisbon, Portugal. Later, automatic vending machines were intro-
duced, doing the repetitive task performed by the salesmen. In this case, the user selects the source
and destination, requiring a tariff knowledge of the service. Companies need information about routes
occupation, bus traffic, and users validations, to track the utilisation of the services and improve specific
sectors, such as bus commodities, scheduling or prices. This need led us to the information era, where
every task is registered on a log held on a computer, also helping to prove that a user has bought the
ticket, even if he lost the printed paper [11].
5
With the idea of reusing the same ticket in various travels, in order to reduce the time-consuming task
of buying several tickets with the same characteristics and avoiding the disposable tickets (and physical
resources), the companies started to develop smartcards with the capacity of storing tickets. The user
can buy one of this cards in a vending store or machine, load it with several tickets and use this card to
make different trips. These smartcards typically use RFID to communicate with a set of readers [12, 13].
Finally, the evolution of electronic fare management conducts to mobile ticketing, making possible for
the user to obtain the ticket using a mobile handset, like a smartphone [2, 12, 14, 15]. In this last case,
the user uses its smartphone in order to obtain and/or validate the ticket. It can be made through short
text message, or even using an application Near Field Communication (NFC) or BLE-based to establish
communication between devices and readers.
2.2 Ticket payment
The conventional payment system in ticketing for occasional users consists of paying the correspon-
dent fare for each journey. It is still possible for regular users to pay an amount for a day, week or month
and have free access to the public transport, avoiding the time-consuming task of buying a ticket every
time the user wants to make a journey. Usually, this periodic pass is cheaper than purchasing a ticket for
each trip, to make the pass more attractive for users. It also allows public transport companies to have
a fidelity from the user side. Another possibility is to have a smartcard with a modality that functions as
a purse, where the user can load it with an amount of money, and each time a journey is made, the fare
is deducted from the purse (pay-as-you-go) [11].
With the release of products like Apple Pay, Google Wallet or even PayPal, it became usual to have
a credit card associated with a smartphone application [12]. Using an NFC-enabled smartphone is
possible to have a specific application to pay for a journey using the smartphone within the near field
of a ticket reader or a payment station. Then smartphone application uses payment interface to charge
the journey correspondent money from the bank account. Another possibility is to have a smartphone
application with the feature that works like a wallet, and using NFC or other communication protocol to
interact with the reader and deduct the money.
2.3 Ticket fares
Apart from the payment method, there are several tariff calculation modes for journeys:
2.3.1 Fixed amount per journey
The simplest approach is to charge a fixed amount for each travel [11], independently of the source
or destination. This calculation is straightforward because each user that enters and exits the vehicle
pays the same fare, regardless of the entry or exit stations. This way, it is not relevant where the user
entered or exited the vehicle, and does not require a tariff knowledge from the user.
6
2.3.2 Distance travelled
Another method of fare calculation is based on the distance travelled. This method requires location
awareness of the user, to be able to perform the trip cost calculations [11]. With this distance-based
approach, a user that enters in the middle of the vehicle route pays a smaller amount than another user
that enters at the beginning of the route and exits in the same stop or after. However, the first kilometres
may be more expensive than the following, creating more flexible fares.
2.3.3 Source/Destination
Regarding the location awareness, it can be possible to calculate the fare based on the station where
the user enters and exits. This approach is very similar to the previous one (distance-based), but does
not concern about the vehicle distance, but only about the number of stations crossed. Each route has
its own fare. If a user travels between three stations, should pay a smaller cost than a user that travels
between five stations, even if the five stations are closer than the three stations.
2.3.4 Zones crossed
Another approach is to aggregate several stations in zones and calculate the fare using the number
of zones crossed by the passenger [11]. Within the same zone the fare would be minimal, but travelling
from one zone to another would increase the price. With this zone-based concept, the distance travelled
by the vehicle is not necessary, but the zones that the vehicle crossed between the entry and exit
stations. In this last three cases (distance-based, station-based and zone-based), the entering and
exiting procedures are crucial to fare, because the location of the entry and exit stations are taken into
account in the calculation.
2.4 Ticket validation
Concerning about the ways to validate a ticket, different methods are being thought and developed.
There are several different types of interaction with the validator and various types of verifying if the ticket
is correctly validated when travelling.
2.4.1 Conventional method
Most of the systems do not have an explicit validator. The system is like an open network, where there
are no ticket readers. So the validation can be made by an inspector that verifies if passengers validate
their tickets, or is not necessary to validate the ticket and the inspector only checks if the passenger
has a right ticket. In this last case, the ticket is validated when it is paid. This method led us to many
irregularities since the control over the validation is not strict. This system is based on a high confidence
of the public transport operators in the passengers. If the inspector does not appear, the validation
is not done, and the fare is not deducted. The system assumes that all the passengers validate the
7
ticket. Although it is the simplest system to implement, it conducts to a monetary loss to the transports
operators that in some cases is not bearable.
2.4.2 Check-in only
One of the most basic ways of interaction with ticket readers is the check-in only. With this approach,
the user just has to present the ticket at the entrance of the public transport. This way the intention
of travelling is signalled and the fare is deducted. When the user exits the transport does not have to
advertise the system that the journey is over.
2.4.3 Check-in/Check-Out
When using method Check-in/Check-Out (CICO), the user should have a ticket, like a smartcard,
which explicitly presents at a ticket reader, when entering and exiting the public transport [2]. This
approach requires the user to formalise their intention to interact with the system. Usually, the ticket
readers are in the entrances/exits of each station, where the user has the obligation of check-in or check-
out the ticket when initiates or finalises his travel. For example, Metro in Lisbon, a subway operator where
every station has gates at the entrance and only open when the passenger checks-in/out a valid ticket
[1]
2.4.4 Walk-in/Walk-Out
With the Walk-in/Walk-Out (WIWO) approach, usually, there are virtual gates at the entrance doors
that detect boarding activities through the direction of the movement [2]. This method is similar to the
CICO but does not require explicit user interaction. However, in previous projects developed using
this approach, there was a low detection reliability, that is not acceptable in the public transport case.
The main projects implementing systems using WIWO was ”EasyRide” in Switzerland (2001) and ”CA-
LYPSO” in some cities of Europe, including Lisbon and Paris (1997-2000) [1, 2, 5].
2.4.5 Check-In/Be-Out
Several hybrid approaches are still possible, combining the already mentioned methods, like Check-
in/Be-Out (CIBO), where there is an antenna that does periodic verifications if the ticket is still in the
field to make sure that the passenger is inside the vehicle. When the antenna does not detect the ticket,
the passenger is considered to be outside the vehicle, and the journey is considered over. However,
the user still has to make an implicit check-in interaction. The first main project implementing CIBO was
ATRON in Switzerland (2004) [1].
8
2.4.6 Be-in/Be-out
Be-in/Be-Out (BIBO) is a hands-free scheme that detects and registers the presence of a device
inside a public transport automatically [5, 15]. The vehicle detects the presence of the ticket carried by
the user through the communication between the ticket and the readers installed inside the vehicle and
considers that a journey has started. When the readers stop to detect the ticket, the end of the journey
is assumed. This ticket should be able to communicate with the readers, which can be a smartcard or
a smartphone. A BIBO system needs a communication technology capable of detecting the ticket at
a distance, installed in the vehicles or at stops and stations, and a back-office to process the journey
data [1, 5, 14, 15]. The first BIBO concept was introduced by Ericsson Consulting in 2001. The first
projects implementing BIBO approach was ”Esprit” by Scheidt & Bachmann in Germany (2005-2006)
and ”ALLFA” in Dresden, Germany (2005). This two projects will be addressed in 2.7.
2.5 Ticket inspection
It is critical for the public transport companies to ensure their income by verifying if the fare was paid.
In systems where physical fences are installed, the user should only be inside the vehicle if the ticket
was successfully validated when entering. Nevertheless, it is still necessary to confirm that there are no
intruders. However, in open environments (without fences), it is always necessary to track the validation
of all the tickets. In early systems, using a paper ticket or even a simple smartcard (without continuous
communication with a remote server), the inspection is made by an inspector that eventually enters in
the vehicle and checks the tickets of each occupant [14]. If the user carries a paper ticket, the inspector
has to check each field of the ticket and validates the information. However, if a smartcard is being
used by the user, the inspector should have a device with the capability of reading the smartcard stored
information, such as the hour of last validation, to check if it is correct for that journey.
2.6 Communication technology
Concerning the mode of communication between the ticket and the reader, different projects use
different technologies, related to the type of interaction. The systems based on paper tickets only need
verbal communication between the users, the salesmen, and the inspectors. However, when using
electronic fare management, like smartcard-based systems, the communication between the card and
the readers is crucial to the correct operation of the system.
Early systems are based on the available radio frequency technology, where the smartcard has a
RFID embedded that interacts with the reader and exchange the necessary information to the system
[2, 5, 13, 15]. The guard can, with a portable RFID reader, verify if each passenger has correctly
checked-in the card when entering a vehicle. This approach marks the first steps of the electronic fare
management.
9
Recent papers debate the advantages of using BLE or NFC. BLE is used by [2, 12, 15] in implicit
ticketing for public transportation, and by [4] in a occupancy detection system, when a one-to-many
interaction is necessary due to large number of occupants and the signal strength can be used to
calculate an approximate distance. NFC is used by systems that search for a one-to-one interaction, like
a near check-in, because the device is only detected when very closer to the reader (4-10cm) [6].
2.6.1 Wi-Fi
This technology is widely used due to its high data transfer data rates. This technology is a possible
candidate to the communication protocol since several public transport companies already have Wi-Fi
infrastructures deployed in their vehicles. Although providing data transfers than BLE, its power overhead
is too high for continuous operation, and that is not affordable for current smartphone batteries [16].
2.6.2 Near Field Communication
NFC is a short-distance wireless technology, which comes embedded in some smartphones. This
technology allows the smartphone to read an NFC tag or other NFC devices. An NFC tag contains a
passive NFC chip that can be read by an active NFC device, called the reader. Although the NFC tag
has a very low price, it is necessary to tap the phone on the intended tag to read its information, so it
is used in touch-to-pay approaches and not implicit interaction. Also, it has the disadvantage of being a
technology that is not available in every smartphone. [16]
2.6.3 Bluetooth Low Energy
BLE is a wireless technology that exchanges data over a short distance using radio transmissions.
It consists of an improvement of the Bluetooth Standard. The main advantages over the traditional
standard are low power consumption and enhanced range. Also, BLE has low bandwidth and low
latency, providing a very energy efficient communication [17]. Nowadays every recent released mobile
phone contains a chipset implementing one of the versions of BLE. It was merged into the main Bluetooth
standard in 2010 with the adoption of the Bluetooth Core Specification Version 4.0. BLE follows active
RFID approach, although coupled with battery on the tag side. Active RFID systems are suffering
a gradual replacement by BLE [4]. BLE is also being used in BIBO-based ticketing systems for public
transport, considered an enabling technology when using mobile devices [12, 14, 15]. Many applications
use the smartphone as a querying device, with the ability to scan for advertisements from nearby BLE
devices, or connecting with BLE devices to exchange information.
Beacons are devices capable of broadcasting wireless signals. Typically BLE beacons consist of
small devices that periodically emits Bluetooth signals, containing programmable information, whether
it is an identifier number or environmental, orientation or location data [18]. Using specific tools or
frameworks provided by beacon manufacturers, it is possible to program specific actions regarding the
received Bluetooth signal. It is also feasible to determine the approximate distance to the beacon, called
10
ranging; or to determine when another device enters or exits the beacon’s range area, called monitoring
[16]. Ranging and monitoring trigger actions just by detecting another device, which does not need user
interaction. These two mechanisms are detected in scan intervals, that are scheduled time windows
when the beacon detects the devices within its range. This scan interval is configurable, which enables
a higher energy control, optimising the transmission control for small amounts of data. BLE is optimized,
regarding power consumption, for short messages, such as identifiers or status messages [4].
The small sizes and low energy required by BLE beacons make them easy to deploy in various
locations. It can be powered by little power sources, such as USB power supplies or small coin cell
batteries, still providing a long lifetime. The theoretical battery life of a BLE beacon can range from 2
days to 14 years, depending on the interval between connections (tested beacons equipped with Texas
Instruments CC2540 Bluetooth chip, and powered by a coin cell battery with approximately 230mAh)
[19].
Concerning security, BLE provides authentication and confidentiality based on AES-128 in Counter
with CBC-MAC (CCM) mode [14].
BLE beacons roles
Communication between BLE beacons and other devices can either be connection-based, where
it is established a communication between the intervenient devices; or one-directional where there are
devices responsible for sending data and other devices capable of receiving that information. Depending
on the role, devices have different behaviours [18]. In one-directional communication we have two roles:
• Broadcaster - non-connectable device that simply broadcasts data packets, called advertise-
ments.
• Observer - device that scans for advertisements without initiating connections.
Considering the connection-based communication, we have other two different roles:
• Peripheral device - it works as an advertiser in the manner of a broadcaster but is connectable
as a slave in connection with a central device.
• Central device - device that scans for advertisers, operating as a master in one or more connec-
tions with peripheral devices.
BLE beacons’s take place as a broadcaster and peripheral devices in the communication process,
while devices such as smartphones and computers, act as observers and central devices.
11
BLE beacons protocols
Currently there are two proximity communication protocols with support for BLEavailable: iBeacon,
announced by Apple at 2013 Worldwide Developers Conference; and Eddystone released by Google in
2015 [20].
• iBeacon - Beacons using this protocol broadcast a single packet containing three different values:
a unique identifier, a major value and a minor value (16, 2 and 2 bytes, respectively). The iBeacon
protocol measures accuracy and proximity using the Received Signal Strength Indicator (RSSI).
Although it has been developed and presented by Apple, it is supported by any BLE-capable.
• Eddystone - This protocol supports three different types of broadcast data that can be used indi-
vidually or in combination: Eddystone-UID, which is the corresponding functionality of iBeacon, ad-
vertising a simple ID; Eddystone-URL, that instead of an ID broadcasts a URL that can be opened
on mobile devices; and Eddystone-TLM, that transmits a telemetry frame, to provide information
about the beacon, such as battery power, coordinates or temperature.
Although iBeacon is a more mature protocol with more documentation, Eddystone has more features
allowing to send more information, which also led to a more complex implementation.
2.7 Previous projects
2.7.1 ALLFA (2005)
Developed by Fraunhofer IVI and Siemens VDO, ALLFA was the first big innovative fare manage-
ment system for public transport tested in a real environment. This project was inserted into the ”inter-
mobil Region Dresden” lead project, which was funded by the German Federal Ministry of Education
and Research [1, 3]. The main goals were to detect the presence of passengers in buses and trams
automatically, practising an automatic fare collection based on a flexible tariff model [3]. The project
consists in detect passengers inside vehicles using ”ALLFA Tickets”, special electronic cards or mobile
phones. This Ticket contains a small battery, a display, two buttons to select the different fare parameters
(additional passengers, first class, bicycles) and a radio frequency communication interface. This inter-
face communicates with the antennas installed inside the vehicles. There are two types of antennas:
”wake-up” antennas, that sends an initial wake-up signal to the ALLFA ticket, and an access antenna,
to communicate with the on-board computer. The two types of antennas enable a two-step detection
process with different types of communication when entering or inside the vehicle, which guarantees
that only passengers who actually travel inside the vehicle are registered. When the user is outside the
bus, the ticket is in a sleep mode, saving energy when the electronic ticket is not being used [1, 3].
An architecture scheme of ALLFA can be seen in Fig. 2.1. At the entrance of the vehicle, the station
ticket receives a wake-up signal from the wake-up antenna, and the ticket is activated, i.e. switch from
the sleep mode to the performance mode. As soon as the vehicle starts moving, begins the second step
—access phase —where every ticket inside the vehicle starts communicating with the vehicle access
12
antenna [1]. This communication with the access antenna is only possible if the ticket has received the
correct vehicle identification code at the wake-up phase. If the ticket has the right code, will authenticate
himself on the vehicle, sending its identification code and the user-selected fare parameters. As soon as
the user is authenticated, it is registered as a passenger in that vehicle. This phase lasts as long as the
vehicle is moving and the position of the vehicle is tracked by GPS. The bi-directional communication
process with the access antenna is repeated between each pair of stops. Therefore the journey of all
passengers on board is recorded. When the user leaves the vehicle, the communication ends, and the
trip is finished [1].
All data transmitted from the ticket to the antenna is transferred to an on-board computer, which con-
trols the system and keeps the information of all passengers. This stored data is continuously transmitted
to a remote back-office system by Global System for Mobile Communications (GSM)/General Packet Ra-
dio Service (GPRS). All data sent inside the vehicle and to the remote office is secured against intruders
using electronic signatures (symmetric scheme, 3DES), and Public Key Infrastructure (PKI) [1].
The registered travel data make automatic fare calculation possible. The fare is calculated centrally
in a background system (tariff server), for each electronically registered journey, using algorithms de-
veloped by Fraunhofer IVI. The amount is computed offline, and with a ”one-step” approach, i.e. at one
point of the time, like the end of the journey, the week or the month, for example. All information is
processed, and the fare is calculated and deducted from the user. This offline and centralised calcula-
tion led us to a higher flexibility, allowing to adjust the tariffs agilely. Having access to all information is
easier to take into account rebates for marketing purposes or by the individual user behaviour [3]. This
information can be used to short-term discounts on selected lines, sections of lines or even specific vehi-
cles. The fare calculation was designed to include a two-part tariff —basic price and journey price, with
different purposes regarding the utilisation frequency. Basic price is a fixed amount per travel. Journey
price usually depends on service parameters like distance covered, type of passenger (adult, student,
child, elderly,.), time of the day or weekends, for example. The recorded rides can provide information
regarding traffic and operations, which enables a continuous optimisation of public transport services,
ensuring the privacy of the user private data [1].
The ALLFA project was tested during six months, in a public pilot trial in the integrated public transport
network of the city of Dresden and the surrounding Upper Elbe Valley region, in Germany. This pilot
had about 2000 participants and 54 vehicles using 11 routes. The vehicles were modern urban and
regional buses, low-floor trams and double-deck trains. During the pilot, the background system was
used almost 5000 times by the project professionals, and about 6000 times by the individual participants
of the pilot. The system processed over 12000 public transport rides and automatically calculated the
fare according to the new tariff model. Four different public transport operators were involved in the
pilot trial – Regionalverkehr Dresden, Verkehrsverbund Oberelbe, Dresdner Verkehrsbetriebe and DB
Regio Verkehrsbetrieb Sachsen. A customer survey before and after the test pilot indicated that 68% of
the participants want the introduction of the ALLFA system in the public transport network, 20% of the
participants are not sure, and only 12% do not want a system like ALLFA. Almost half of the participants
(42%) indicated that would use public transport more frequently with a system like ALLFA [1].
13
The system had a sophisticated customer support allowing the user to access all the information
about the journeys and distribution of tickets. The client’s support communicates via Internet with the
back-office, where all the information is processed and stored. This way, customers could retrieve
their individual BIBO-recorded journeys at public terminals or personal computers, through a ubiquitous
password-protected system [3].
Figure 2.1: Overview of the ALLFA system architecture.
2.7.2 Esprit (2005/2006)
Scheidt & Bachmann, a company with a long tradition in fare collection systems, decided to follow the
developments of BIBO technology, designing a fare collection system with implicit interaction. ”Esprit” is
a BIBO ticketing system, which stands for ”Encoding scheme for programmable intelligent tickets”. The
concept is based on an electronic user device, in a key fob format, which operates as a smart card.
It has a radio-based communication interface, a microprocessor and a memory chip where money or
tickets can be stored to provide its BIBO functionality. The device has a display to show the battery level,
the monetary value stored or tickets left in the device, and if the journey is validated. The display can
also operate as an ”add-on service display”, which allow fare adjustments, like adding bicycles, dogs,
first class that will be taken into account when the fare is being calculated. The vehicle is equipped with
an antenna to communicate with the user devices and an on-board computer that controls the data that
is sent to the user devices and also send all the information to a remote back-office server [1].
An architecture scheme of Esprit can be seen in Fig. 2.2. When the passenger enters in a public
transport vehicle, the on-board antenna broadcasts a signal to all users inside the vehicle to activate
the user devices from the sleep mode. The tickets keep activated within the range of the vehicle signal,
and up to 15 minutes after the last vehicle antenna detection, when switches to the sleep mode to save
battery. When inside the vehicle, the user device is periodically receiving information from the vehicle
antenna, with enough information to calculate the fare. Communication between the on-board computer
and user device is always made through the vehicle antenna, uni-directionally from the computer to the
user device, using broadcasting with the same information to all user devices inside the vehicle. Fare
14
processing is carried out in the user device, in an incremental way and in real time, between each pair of
stations, during the entire journey. The on-board computer contains a fare engine, which describes the
tariff systems and broadcasts a radio signal with all information required by the user device to compute
the exact fare. The stored value on the user device will be deducted accordingly with the calculated fare,
up to the maximum amount defined by the applicable fare rules. The user device can always transfer
data to the on-board computer to obtain statistical information, such as deducted fare or ticket type. The
data from the vehicle to the background system can be transferred using GSM/GPRS or Wireless Local
Area Network (WLAN) [1].
When a ticket inspector enters in a vehicle, the driver activates the inspection mode using a vehicle
specific button. This method triggers a broadcast signal from the vehicle antenna to all user devices
inside the vehicle. When the user device receives the inspection signal, a control number is displayed,
which allows the inspector to check the validity of the ticket. An ”OK” message is displayed, meaning
that the ticket stored on the device is functioning correctly. There is also the possibility of sending a black
list to the on-board component, with the devices that are not successfully validated, but this was part of
future work.
In order to minimise external radio interference, caused by other devices or inside the transport
vehicle, the on-board antenna operates on two of 32 available radio channels in parallel, using 16 chan-
nels dedicated to broadcasting and additional 16 channels to receive data. The approach of sending
broadcast signals with all the relevant fare information has an advantage over the bi-directional com-
munication, according to Scheidt & Bachmann, because do not require anti-collision mechanisms. The
Esprit also use a PKI with asymmetric RSA and ECC data encryption, to ensure authentication and
privacy of the data.
Figure 2.2: Overview of the Esprit system architecture.
15
2.7.3 Johannes Kepler University (2014-Actuality)
The Department of Business Informatics —Software Engineering of Johannes Kepler University
in Linz, Austria has an investigation team, headed by Wolfgang Narzt, focused on developing new
paradigms and technical systems to improve mobility in public transports. The investigations are be-
ing conducted since 2014 to 2016 in the course of an Austrian research project ”Mobility of the Future”
within the initiative IV2Splus (Intelligent Traffic Systems and Services) funded by the Austrian govern-
ment, cooperating universities, several public transportation operators and NGOs [5].
Johannes Kepler University’s investigation team aims to develop a BIBO system to improve the mo-
bility in public transport mainly for people with physical disabilities as well as children, older adults or
cognitive debilitated. Based on the previous projects like Esprit and ALLFA, and with the improvements
of BLE, they decided to implement a mobile fare collecting system, based on BLE and BIBO technolo-
gies, to conceive a simple and faster usage of public transportation for all users. They considered BLE
would be a good alternative for implementation since most of the people nowadays own a BLE-enabled
mobile phone all the time [5].
The architecture of their solution includes a BLE beacon or a BLE-enabled smartphone carried by
the user, an On-Board System (OBS) controlling the communication with the user device and with a
remote server. A scheme with this architecture can be seen in Fig. 2.3. The user device broadcasts its
unique ID when entering the vehicle, which is received by the OBS. This OBS is installed on the roof of
each vehicle to be accessible to all users. It consists of a processing unit (like a Raspberry Pi) and a
BLE dongle to communicate with the user devices. This device is connected to the electronic circuits of
the vehicle (including doors close controller), and with access to the route and schedule database of the
vehicle [2, 5, 15]. This way, the OBS have the knowledge of the user accesses with timestamps, route
sections, and locations. The registration process is detached of any personal assignment since user
data are mapped remotely in a decoupled system. This remote system consists in a server responsible
for accounting, linking personal user data and all transferred route data [2, 5, 15].
In order to accurately detect only the presence of the passengers inside the vehicle, OBS performs
scheduled BLE scans to remove unintentional ambiguousness. Capturing a BLE beacon at all scans
indicates the presence of a passenger inside the vehicle. A combination of the electronic signals of
the public transport, e.g. doors closing, triggers the scan procedure. The first scan is performed in
a significant distance to the last stop to avoid the detection of people outside the vehicle. After the
first scan, the OBS registers the user as probably travelling inside the vehicle and transmits a sleep
command until the next scan. Between a pair of scans, the smartphone is in sleep-mode, saving energy
and not creating unnecessary noise, allowing other clients of being correctly detected. The application
will wake up at next full scan process. The scan repeats until no more clients are detected [2, 5, 15].
The scanning process is an almost unidirectional communication from the OBS, since BLE beacons
are only designed to broadcast their advertising signals. The scan process begins with the broadcast
of the user beacon ID. This ID is just a configurable name, and can only be mapped to the real user ID
through the remote server, responsible for accounting. The OBS then establishes a security handshake
with the beacon, using AES 128bit encryption. The OBS sends an encryption key to the user beacon,
16
which encrypts its unique ID. This last value is read by the OBS and decrypted again to register the user
has a valid passenger. To allow this encryption by the BLE beacon, the investigation team modified the
Nordic Semiconductor nRF51822 beacon’s firmware [2, 5, 15].
In order to allow the passenger to be the only person who knew where and when travelled and the
amount paid, they also developed a transparent passenger approach. This method uses the bank as a
mediator between the client and the public transport company. Passengers inform their bank that they
want to use the system, providing their data. The bank encodes this data and generates an encrypted
key and provides it to the user, allowing to use the public transport. For transit companies, passengers
are anonymous, and their personal data is not possible of tracking. At the end of each month, for
example, the costs are transferred to the bank and deducted from the user account. As the bank never
receives the movement information, but only the amount to deduct, the personal data is separated from
the dynamic data and is harder to match [5].
The investigation team installed a prototype of the system in two buses of their transportation partner,
and performed user acceptance tests in December 2015, to gain first insights into usability and privacy
concerns. The test counted with 16 persons whereby one person was visually impaired, and one person
had cognitive limitations, to show how a system like this would improve their journey experience [5].
The results were very positives, with a System Usability Score of 86 out of 100, even if the number of
participants was not representative of a population. The main positive aspects for the test persons were
simplicity, ease of use, time-saving, and the inclusion of individuals with disabilities. The main negative
factors aim to a lack of trust regarding the security of personal data, empty batteries and special cases
with cars or cyclists near the buses. This test also indicates that the majority of travellers prefer to use
their smartphones instead of a beacon [5].
Figure 2.3: Overview of the Johannes Kepler University system architecture.
17
2.7.4 Link Consulting Summer Internship (2016)
Link Consulting is a company established in Lisbon, Portugal. Founded in 1999, is a consulting and
services company that acts in the areas of consulting, development and support of electronic business
models. Link Consulting has a group specialised in electronic ticketing systems, named Smart Cities,
with deep expertise in public transport operations and great knowledge of enabling technologies, such
as smartcards, RF/contactless or mobile phones [21]. In the summer of 2016, Link conducted a summer
internship program for two months, in which a mobile ticketing project using BLE was proposed. The
main goal was to create a commercial demonstrator for a mobile ticketing application based on BLE,
which provides a simple and low cost solution for public transport without complex on-board equipment
and enabling automatic check-in/out of passengers. It also allows to check-in manually.
The prototype developed by Andre Aguas, the intern responsible for the summer project, aimed to
the automatic detection of user position relative to the bus, using BLE and other sensors (location and
activity recognition), i.e. if the passenger is inside, outside or near the vehicle. The prototype enables
not only to purchase the ticket but also to validate it through an automatic check-in/check-out, without
an on-board computer.
This project uses BLE beacons, deployed inside the public transport vehicles, to interact with the
mobile user device. The user has to install the developed application in the mobile phone. Then,
the application starts seeking for beacons with a defined interval. Afterwards, the solution follows the
behaviour described in the state machine diagram represented in Fig. 2.4. When the user is outside the
vehicle, the application is scanning for beacons. When it detects a set of beacons from the same bus, it
turns on the location and starts recognising if the passenger is moving, using the smartphone GPS and
activity/movement detection. When there are not enough beacons detect from the same bus, the user
should have exited the bus, and it is checked-out.
Figure 2.4: State Machine Diagram of Link Consulting Project.
18
One of the concerns was also the battery usage. Beacon scanning interval time is wide when do not
detect a single beacon, to avoid battery drain. When a beacon is detected, this period is decreased, to
become more frequent, and quickly identify when the passenger exits the vehicle. Also, the GPS is only
enabled when the user is near a vehicle because it is the only moment where movement detection is
necessary. Finally, the application works when screen off, allowing to save more battery.
This project has some constraints, since it does not have integration with sales/payments system
and check-in/out is not synchronised. Ticket acquisition is just a mock. Also, inspection application and
back-end server are not implemented.
Since this master thesis is supported by Link Consulting, some of the ideas used by Andre in his
summer project were adopted in the development of the system.
19
20
Chapter 3
Implementation
3.1 Overview
The main goal of this project is to develop a mobile ticketing platform for public transport, proving the
viability of using BLE beacons in this domain. In our solution the user owns a BLE-enabled smartphone
with the developed application installed. A set of BLE beacons are deployed inside public transport
vehicles. Beacons have unique identifiers that indicates which vehicle they belong. The applications
detect user presence using the communication between the user smartphone and the beacons, through
BLE. GPS and smartphone sensors are also used to detect movement and location, helping on the fare
calculation.
This system is based on a hybrid approach combining BIBO and CIBO. It uses a ”check-in” perspec-
tive because the user has to manually confirm their presence inside the public transport vehicle with a
check-in action in the application. However this check-in it is not made explicitly in a reader, it can be
made at the passenger seat. Furthermore, the need of a check-in action is detected when the passen-
ger is near the vehicle, so the system is able do detect that the user is (probably) inside the vehicle,
introducing the ”be-in” concept. The check-in action is only necessary to eliminate doubts about the
user presence inside the vehicle. The system is also able to detect that a user is outside the vehicle,
experiencing the ”be-out” idea. To perform these detections, we use BLE communication technology,
due to its advantages, as referred in section 2.6.
A schematic overview of the system can be found in Fig. 3.1. In this use case, there are two valid
travellers (Alice and Bob), an inspector (Sherlock) and a probable intruder (Jack) in the vehicle.
At any time, an inspector can enter the vehicle to verify the tickets legitimacy. This inspector, like
Sherlock in Fig. 3.1, have a different application installed in a mobile phone or a specific device, with
the ability to confirm if a traveller claiming to pay is indeed using the system and if he is successfully
checked-in. The inspectors are responsible for ensuring the proper functioning of the system. Its role
will be described in detail in section 3.2.
21
Figure 3.1: Overview of the proposed system architecture.
The blue arrows in Fig. 3.1 represent the information exchanged between the set of beacons and
the passengers’ smartphone to detect presence. In order to communicate with the back-end, the mobile
phone application sends information through mobile operator internet or using the vehicle Wi-Fi to notify
the journey. The back-end server contains information about all the users, storing all user data provided
when the application started. This back-end is from the public transport operator side, so it is the only
entity that has access to this information. It also has information about every journey that is made. This
allows a better knowledge of the service usage from the operator side, enabling improvements. The
back-end server also has access to route information of every vehicle and every station to calculate the
fare based on the source and destination stations identified by the smartphone GPS.
One of the most innovative points of this system is that is not necessary an on-board computer
to control the passenger detection or to communicate with the server. With our architecture is the
mobile application that detects the beacons and communicates the information to a back-end server
that takes care of all processing. This is an advantage to public transport operators since it avoid a huge
modification in the public transport infrastructure.
The process of using the system is divided into 4 procedures: registration, ticket acquisition, en-
trance, and exit.
1. Registration: When starting the application for the first time, the user provides identification and
payment information to the application, which is forwarded to the back-end to register the user. A
credit card must be associated with the user account to purchase tickets.
2. Ticket acquisition: The user has to buy a trip through the application, to be able to start a journey.
The application turns on BLE and starts scanning for BLE beacons.
22
3. Entrance: When a set of beacons from the same vehicle is detected, the application turns on
GPS. The detection of several beacons of the same bus indicates that a public transport vehicle is
near. GPS provide information about the source station, where the journey started and the current
location is stored. This information is important to fare calculation. When the passenger enters
has to confirm his intention to travel, pressing a button in the application. This explicit confirmation
works as a check-in, reducing the false detections. Although the user still needs to interact with
the system, it is not so time-consuming than checking-in using a ticket reader. The user has the
responsibility and obligation to confirm his presence. Otherwise, the journey is not considered,
and he is travelling illegally. Movement can be identified using activity recognition provided by
smartphone sensors. When smartphone is identifying movement and detecting beacons, the user
is inside the vehicle and GPS can be turned off, to save battery. The check-in information is then
sent to back-end to register the entering information.
4. Exit: In performance mode, more scans in a smaller period allow detecting when the passenger
leaves the vehicle quickly. When there are not enough beacons from the current vehicle being
detected, GPS is turned on to register the last station (destination), the user is checked-out and
the journeys is over. The travel information is then sent to the back-end that accessing the vehicle
route calculates the fare, based on the zones crossed within the trip, and charges it from the
application tickets.
3.2 Architecture
In Fig. 3.2 are represented the modules that composes the system and the relationships between
them. The only user side entity is the mobile application, where the user can interact with the envi-
ronment of the platform. In this application the user can check the current state, i.e. if is far or near a
vehicle, or if a trip is currently in course or it is already finished. It is also possible to view the past trips
and generate validation codes. This mobile application does not store sensible information, such as
payment balance, user detailed information or vehicles routes. All this data is controlled by the back-end
that also performs the sensible tasks like fare calculation, charging money and management of every
trip information.
3.2.1 Vehicle
BLE Beacons
One of the aims of this solution is to reduce as possible the changes in the already existing infras-
tructure of the vehicles fleet. That way we decided to only deploy a set of beacons inside each vehicle.
These devices are BLE-capable of advertising a unique ID, which can be configured only by the owner,
as referred in section 2.6.3 This ID indicates in which vehicle the passenger is travelling. So to deploy a
beacon inside a vehicle is only necessary to change the advertising ID to the corresponding vehicle and
place it inside a protected compartment in the vehicle, so it is not physically accessible to an attacker.
23
Figure 3.2: Components and their relationships of the proposed solution.
The beacons advertise their ID within a time interval that can be set and must be defined to perform
multiple scans between any two stations. However, beacon battery must be taken into account and this
time interval should not be too tight. The possibility of having a BLE beacon at the entrance and the exit
of the vehicle is used by [14] and [2, 15], providing some test cases supporting an improvement when
having more than one beacon deployed.
As we are using as example the case of Carris (Lisbon) public transport, we made a study of their
bus sizes, in order to conclude which would be the best configuration for beacons interval time and
broadcasting power, as well as the configuration of the beacon set inside the vehicle. The values of the
bus sizes can be observed in Table 3.1 [22].
We used three sets of Estimote R©Proximity Beacons (hardware version G1.8 and firmware version
4.9.1). These beacons can either operate in iBeacon or Eddystone protocols, but we used iBeacon
due to its simplicity and documentation abundance. To achieve a good balance between detection
reliability and battery consumption, we decided to use the following values that allow a battery lifetime
of approximately 18 months:
• Broadcasting Power: -20dBm, which allows an approximate ranging of 4 meters
• Advertising Interval: 500ms
With this values well defined, we found the best way to deploy a set of beacons inside a typical vehicle of
Carris, according to the sizes already referred in Table 3.1. We used the vehicles with the most common
configuration: 12m length and 2,5m width for standard models and 17,95m length and 2,550m width for
articulated models. This configuration can be observed in the scale Figures 3.3 and 3.4.
24
Table 3.1: Carris (Lisbon) bus dimensions.Standard
Model Activeunits
Seatingplaces
Standingplaces
Length(mm)
Width(mm)
Volvo B7L 20 30 55 11960 2500
Volvo B7R LE 33 34 50 12000 2500
Volvo B10L GNC 37 34 50 11940 2550
Volvo B 7 R ”LE” MK3 40 35 47 12000 2500
MAN 18.310 HOCL-NL GNC 20 35 47 12000 2500
MAN 18.310 HOCL-NL 127 35 40 12000 2500
MAN 18.280 LOH 02 100 35 50 12000 2500
Mercedes Benz O405 N2 109 32 52 11875 2460
Mercedes Benz O530 Citaro 29 30 56 12000 2550
Mercedes Benz OC500 LE 67 35 52 12000 2550
Average 34 50 11978 2511Most common 35 50 12000 2500
Articulated
Model Activeunits
Seatingplaces
Standingplaces
Length(mm)
Width(mm)
Volvo B10M 40 46 112 17950 2460
Mercedes Benz OC530 G 50 46 101 17940 2550
In this two figures, we can observe the placement of the beacons inside the vehicle. The blue dots
represent the beacon, and the blue circles represent the range of the beacons. The circles become
darker when they intersect each other. Our goal was to ensure that if the user is near the vehicle, the
system should detect it without doubts, and reduce at most the detections when the user is far from the
bus. To do this, we ensure that the disposition of beacons must be such that within the vehicle area it is
always possible to detect at least two beacons with the same identifier. As we can see, all the vehicle
area is covered by at least two beacons and near the entrances of the vehicle, even outside it, is possible
to detect at least two beacons, which is the required since it is when the check-in is made.
Figure 3.3: Beacon deployment diagram in a Carris standard bus.
25
Figure 3.4: Beacon deployment diagram in a Carris articulated bus.
We are using iBeacon protocol, so we have three different values to define: Universally Unique
Identifier (UUID), major and minor. This way we can set different values for each service, filtering the
existing beacons and only retrieving the relevant for our purpose. We use UUID to define that all the
beacons that have our UUID are detected by the application. Then we have major to link each beacon to
a different public transport operator. For example, major with value valueX is linked to buses operator,
major valueY to trains operator, etc. Finally, minor values differentiate the vehicles from the same
operator. For example, minor valueA lead to busX from Carris and minor valueB lead to busY, also from
Carris. In this document, we will refer to beacon identification as the combination of UUID, major and
minor, so two beacons have the same identification if the three values are equal.
Wireless internet
It is assumed that all users have access to internet, either provided by the vehicle or through mobile
operator data. This way, the mobile application can use this connection to communicate with the back-
end. This will be addressed in section 3.3.
3.2.2 Mobile Application
The traveller’s device is a smartphone and is indispensable to use the system. Smartphone applica-
tion controls all the system’s logic. The traveller is responsible if the ticket is not checked-in because the
smartphone is out of battery, no GPS signal or without internet connection, or also if the check-in button
was not pressed when entering the vehicle. Every implementation detail of the mobile application will be
addressed in chapter 4.
Passenger detection
The mobile application is responsible for detecting the presence of a vehicle, therefore the presence
of a passenger. Passenger detection component process the journey information, using the communica-
tion with the vehicle’s beacons. This passenger detection is based on the detected beacons and activity
recognition. It consists of the state machine that will be addressed in section 4.3, when this passenger
detection will be succinctly described.
26
GPS
This component is responsible for detecting the source and destination stations of the trip. The
”check-in” button pressed inside a vehicle triggers GPS to register the current location as the station of
origin, to use in fare calculation. Then GPS is turned off to save battery. When there are not enough
current vehicle beacons detected, the GPS is turned on again to store the destination station and the
trip is over, and GPS is turned off.
Inspection generator
When an inspector enters the vehicle to check the validity of the passenger tickets, the passenger
has to generate a Quick Response (QR) code. To do this, the user only has to press ”inspection” button,
that automatically generates and shows a code that contains the user information and current trip data.
Then the inspector, with a specific device, can read the code and confirm the validity of the traveller’s
journey. If the source station was not correctly obtained or user information is incorrect, the inspector
detects it and acts according to the failure. How the code is generated and with each information will be
described in section 4.1.5.
User information
User information is always stored in the mobile application to identify the passenger when sending
the travel information to the back-end server. This user information contains only a unique identification
token. This way the back-end user information can be indexed using this token. More information
relevant for public transport operator is available at the back-end.
3.2.3 Back-end
User register
This register contains the user information of all users. Each user entry has the unique identification
token that is stored by the mobile application and used to index each entry in this register. Also, it con-
tains information relevant for public transport operator such as full name, tax number, contact number,
date of birth, for example.
Journey register
The journey register works as a log, where all the journeys made are registered to build a history
of each user. This information is crucial to public transport companies, to improve their services. The
users can also observe the last journeys that they made.
27
Beacons register
Having beacons information is crucial for the correct functioning of the system since they are the main
role in passenger detection. In this register can be matched the beacon identifier to the corresponding
vehicle.
Route information
Information about routes is important to perform the fare calculation. This information is provided by
the public transport operator. There is a database with all the stations, buses and their routes, that will
be described in section 5.4.
Fare calculation
Back-end receives the journey information from the mobile application when it is over. This journey
information contains the source and destination stations. With this information, and accessing the route
information also available, the back-end is able to count the number of stations crossed within the trip
and calculate the fare. This calculation will be deeply described in section 5.2.
3.2.4 Inspector
Quick Response code reader
An inspector can inspect the validity of each passenger ticket. Inspectors have a different device,
which connecting to back-end server has the capability of evaluate if the ticket is valid. The inspector’s
role is to ensure the correct operation of the system. This inspection application can read the QR code
generated by the user application and, accessing user information on the back-end server, confirm that
the user is correctly checked-in on that vehicle. This is made verifying the trip information provided by
the user and the registered in the back-end. We choose a QR code to represent the validation code
because it is rapid to generate and to read. Therefore, the validation process is a quick task for both the
user and inspector.
3.3 Assumptions
This project has a main focus on the accurate detection of passengers, to achieve a good travelling
experience, reducing the check-in/check-out manual interactions. Therefore some of the capabilities
of the system are not going to be explored, allowing greater flexibility in future when continuing the
development of the project. To simplify the system and to give priority to the most crucial points, the
following assumptions are made:
• Internet Availability: We assume that internet is available in all smartphones and inside every
public transport vehicles. Whether via on-board vehicle Wi-Fi or through mobile operator data,
28
the smartphone can connect to the internet, therefore to the back-end server. Nowadays it is
widespread to have public transport vehicles with internet wireless available on-board, so it is a
reasonable assumption.
• Fare calculation: Although there are different possibilities to calculate the fare due to system
flexibility, the calculation method is not a concern of this system, and several approaches can be
explored. In this project, we assume a station-based fare, where the price is determined according
to the number of stations crossed by the passenger. This choice is due to its simplicity. However,
it is possible to adapt to different methods of fare calculation, such as zone-based, aggregating
stations, or fixed-price.
• Payment process: In this implementation due to time constraints the payment system integration
will not be addressed. In section 7.1 some of the possibilities will be discussed. Although it is
assumed that the user has a purse associated with the application, which can be charged with
money, and the fare of every trip will be deducted from that purse.
3.3.1 Fraud and failure cases
- What happens if a user does not own a smartphone?
It should be possible to travel with another payment method, like a paper ticket bought on board, for
example. Just like when the smartcards were introduced, this new mechanism does not exclude other
payment methods.
- What if the user tries to turn off GPS, BLE or internet?
The application will detect that the user is turning off important features that are needed to travel. From
the moment one feature is turned off, the application gets inactive, and the user will travel illegally. There-
fore any inspector can verify that the journey will not be legally valid.
- What if the smartphone turns off during the travel?
If the user is with a trip in course, the check-in is already made, and that information is stored on the
server. In back-end, a periodically routine is called that verifies if every check-in has its correspondent
check-out within a timeout window. If a check-in has already timed out, the server detects that there is
an error and several methods can be applied, according to the business model of the public transport
operator:
• Deduct a fixed value for the journey
• Deduct the maximum value of the checked-in vehicle route
• Deduct the average value of a journey in the checked-in vehicle route
If the user can prove the exit station later, this value can be regularised.
29
- What if a user tries to start a journey with negative balance (or not enough to travel)?
The application will warn the user that should load balance. However, in background, every event should
be registered in order to detect a fraud.
- What if the user does not perform the check-in when entering the vehicle, but only when/if the
inspector appears?
When the application detects both beacons and movement, it assumes that the user has to check-in, so
it is possible to store the timestamp in which the user should have checked-in and did not. Therefore,
the inspector when validating the journey can observe this notification and invalidate that trip.
30
Chapter 4
Mobile Application
The mobile application is a prototype that has been developed in order to apply the ideas discussed
in the implementation (chapter 3). Therefore we developed an Android application to test and prove that
the project is feasible. To build the application we set up an environment with Android Studio v2.3.3 and
using Gradle build tool v3.3. The application was developed using the following configurations:
• Min SDK Version: API 18 - Android 4.3 (Jelly Bean)
• Target SDK Version: API 24 - Android 7.0 (Nougat)
• SDK Build Tools 25
• Google Play Services 11.0.2
Although it was tested successfully on different devices such as Samsung Galaxy S5 SM-G900F
(Android 6.0.1 Marshmallow, API 23), Samsung Galaxy J1 (2016) (Android 5.1.1, API 22) and LG L90
D405 (Android 5.0.2 Lollipop, API 21).
4.1 Features
4.1.1 Login/Registration
To start using the application, the user needs to be registered in the platform. The system must
be able to unequivocally identify users based on their information, in order to register trips and charge
money in the right user account. The registration window can be observed in Figure 4.1.
To identify the user, we use the phone number, because as this is unique, there is no possibility of
ambiguity. The full name and tax number should also be provided by the user to verify their legitimacy
and to the system be able to charge money from the provided account number. Besides, is required a
password to protect the account.
After all required information filled in the correct places, the user can submit the form. If the infor-
mation is accepted by the back-end, i.e. the data is valid, the back-end answers with a random 4-digit
code. This code ideally is sent by an Short Message Service (SMS) to the phone number provided by
31
the user. Although, due to the difficulty of access to free SMS system, this message is simulated as
a pop-up message appearing in the application with the generated code. Then the user only needs
to insert the received code and confirm. If the entered code matches the generated by the back-end
for that phone number the user is now logged in the application and is able to charge the account with
money and start travelling.
After the user is registered, it is possible to logout and login, just using phone number and password
inserted in the registration to enter in the application.
Figure 4.1: Registration window.
4.1.2 Charging money
To be able to travel using the application, the user needs a positive balance, either tickets or money,
depending on the current business model. As assumed in section 3.3, we will use a money balance, like
a purse, that can be charged and from where the travel fares are deducted. At any time the user can
ask to charge the account with money, in a quick task where only has to choose the amount to charge,
fill the tax information (if required), and submit. This process should be made when the user predicts
that does not have enough money to complete the intended journey. If the current balance is not higher
than the minimum fare, the application does not allow to start a new trip.
32
4.1.3 State visibility
The main feature of this mobile application is the possibility to view the state of the user at any time.
The states have different behaviour and representation, with distinct colours and figures that made the
state visibility easy to distinguish. State transitions will be addressed in section 4.3 with a state machine
diagram. Here we present the five states in which the application can operate:
• Out: No beacons are found. Neither check-in nor check-out can be made, so the user cannot
interact with the state. GPS is turned off, in order to reduce energy consumption. This state is
represented in red, with a figure of a user far from a vehicle.
• Near: Minimum number of beacons from the same vehicle is found. GPS and activity recognition
is turned on, so it is possible to detect movement and register the current location. In this state,
we can see which vehicles are being identified, as we can observe in Figure 4.2. If the application
is not automatically selecting the closest bus, since it uses RSSI to estimate distance and this is a
very depending factor, we can also easily choose in which vehicle we are going to enter. Pressing
the ”Check-in button” is allowed and triggers the entrance transition. The ”Near” state is repre-
sented in dark blue, with a figure of a user at a bus stop, as shown in Figure 4.2.
Figure 4.2: Near state window.
33
• Checking in: Not also the minimum number of beacons of the same vehicle are detected but also
movement, through the GPS and Activity Recognition module. Therefore the user must press the
”Check-in button” to confirm that is inside the vehicle. This state is represented in orange, with a
user entering a bus.
• In: When the user press the ”Check-in button”, the application enters in this state. The location
is stored and also a list of every possible bus to check-in, in case the bus automatically chosen
was not the right one. While the application is detecting the minimum number of beacons, GPS is
turned off to reduce battery consumption because it is not necessary during the journey. The ”In”
state is represented in green, with a user inside a bus. An example of this state representation can
be observed in Figure 4.3.
Figure 4.3: In state window.
• Checking out: When the application stops detecting the minimum number of beacons of the
current vehicle, it enters in this state. Here the application checks if any alternative buses have
been detected since the entrance in which it was also possible to check in. If yes, the application
updates the current bus and enters again into the ”In” state. Otherwise, the journey is finished,
and a summary is shown, with the entrance and exit information, as well as the cost. A summary
example can be observed in Figure 4.4. After showing the summary (whether the user presses
the button or the timeout of 10 seconds expires), the application transits to ”Out” state, trying to
detect new beacons. If the application is running in background, the summary is not shown, and
the application transits fast.
34
Figure 4.4: Summary dialog window.
4.1.4 Trip history
At any time it is possible to check all the past trips that were made by the currently logged user, as
we can see in Figure 4.5. In this window, we can observe the relevant information about each trip, like
the dates of check-in and check-out, the bus in which the passenger travelled, as well as the entrance
and exit stations. Each entry in this trip history contains a list of stations crossed during the entrance
and the exit, so when the user clicks on a trip, a map is shown with marks in all the stations within that
journey. We can observe an example in Figure 4.6. A green marker indicates the entrance station; the
red marker shows the exit stations and all the yellow stations are the stops performed by the vehicle
during the journey. It is possible to know the station’s name clicking on the markers. It is also possible to
generate inspection codes for each trip, at the specific inspection button, as can be observed in Figure
4.5 and as it will be addressed in section 4.1.5.
35
Figure 4.5: Trip history window. Figure 4.6: Map window.
4.1.5 Inspection mode
When a travel is in course, it is possible to generate a validation code. This is necessary when an
inspector enters the vehicle to check if all passengers have validated that travel. When inside the vehicle
and within a travel, it is visible an ”Inspection button”, as can be observed in Figure 4.3, that generates
and opens a QR code with the information of the current journey. An example of a validation code can
be seen at Figure 4.7 The code generated contains the following information:
{ user-ID } // { bus-ID } // { travel-ID }
• {user-ID}: identification token stored in application to index user in back-end
• {bus-ID}: beacon identification that is detected by application
• {travel-ID}: identification of the relevant trip
To generate the validation code we use ZXing (Core v3.2.1). ZXing (”Zebra Crossing”) is an open-
source barcode image processing library implemented in Java. This provides an easy to implement
interface to generate QR codes and show them in bitmap format.
Also, when in Trip History it is possible to generate validation codes of past trips, to check if all the
information was stored correctly in the back-end. To do this, trip history also has an inspection button to
generate a code with the past trip information, as we can observe in Figure 4.5.
36
Figure 4.7: Inspection mode window.
4.2 Solution architecture
4.2.1 Counting beacons
iBeacon protocol introduced the beacon region concept. A region can be described as the entire
area reachable by beacons that match the region specification. These values are the same as those
used by beacons: UUID, major and minor. A region can be defined using three different combinations:
• Only UUID: Consists of all beacons with the given UUID, independently of major and minor values.
• UUID + Major: All beacons with not only the given UUID, but also given major value.
• UUID + Major + Minor: More specified region that consists of all beacons with given UUID, major
and minor values.
In Figure 4.8 we can observe an example of two regions: RegionA (blue) specific for UUID with value
uuid-A and major value 5000; and RegionB (orange) only with UUID uuid-B.
A region is defined by the union of range areas of beacons with the same values as the specified
in the region specification. Both blue and green beacons have values uuid-A and 5000 as UUID and
major, respectively. Although they have different minors, the region is not minor-level detailed, so both
beacons match the region values specification. Therefore the union of the green beacon range and blue
beacon range composes RegionA, represented in the figure as the blue area. RegionB, seen as the
orange area, is only composed of the orange beacon range since it is the only beacon with the same
UUID as defined in the RegionB specification.
37
Figure 4.8: Beacon regions example.
In this implementation, as we are using Carris vehicles as example, we are looking for a region with
the following configuration:
• UUID: B9407F30-F5F8-466E-AFF9-25556B57FE6D
• Major: 50550
The defined UUID is relative to our application and major value is set for all the Carris vehicles.
There are two distinct methods for mobile applications to detect and interact with regions and bea-
cons within this regions:
• Monitoring: triggers actions when a device is entering or exiting the range of beacons defined
by the region. It works whether the application is running, suspended, or killed, which means that
actions can happen even if the user has their phone locked in the pocket.
• Ranging: actions are triggered according to the proximity to a region, indicating if the device is
immediate, near or far from that region. It only works if the application is running.
Although the proximity of a beacon could help us decide if the user is inside the vehicle or not, it is not
very reliable to use ranging. This method uses RSSI to estimate distance and these values depend on
the placement of beacons and whether the mobile device is in-hand, in a bag, or in a pocket. Besides,
as already mentioned, ranging does not work if the application is in the background, and our goal is to
be able to detect the presence of a passenger even if the smartphone is inside the pocket. Also, if we
define a region that includes all vehicle area and surroundings, we can monitor the entrances and exits
in the region. Therefore, we decided to use monitoring to trigger entrance/exit actions and then ranging
to identify and count how many beacons from the same vehicle are being detected.
It is important to know that once the beacon is out of range, it still takes to the mobile operative system
up to 30 seconds to truly recognise that fact. This built-in, non-adjustable delay is there to prevent false
38
”exit” events, like when a crowd temporarily obstructs the beacon, and it stops being detectable for a few
seconds.
The monitoring task is not continuous, i.e. it is not always detecting entering and exiting occurrences.
There is a predefined time interval between each scan of beacons. If on two consecutive scans the set
of detected beacons changes, it triggers the correspondent entrance/exit action. Monitoring is defined
based on two values: the scan period and the interval between scans. We set the values to perform
2 seconds scanning with 10 seconds of interval, which gives us a good balance between battery con-
sumption and expected results, based on tests conducted.
After monitoring task detect the presence inside the region, ranging task aggregates discovered
beacons by minor value and count the number of occurrences for each minor, which indicates that they
belong to the same vehicle. Ranging is also defined based on the scan period value and the interval
between scans. Based on the same tests conducted for monitoring, we set the values to perform ranging
scans with 2 seconds duration and with intervals of 2 seconds too.
A list is created with the aggregated beacons, with the information from when it began to be detected,
and is ordered by signal strength. After that the service broadcasts this list to the rest of the application
so that it has access to the detected buses in a proximity order.
4.2.2 Location and movement recognition
The mobile application has a movement recognition service to detect if the user is moving at a
certain speed or if it is stopped. If the application detects that the user is detecting the required number
of beacons and is moving, it indicates that is probably inside the vehicle and must perform the check-in.
To detect activity, we use a Google Application Programming Interface (API) for Android: Activity
Recognition API. This API uses sensors available in a device like accelerometer or gyroscope, among
others. It automatically detects activities by periodically reading bursts of sensor data and processing
them using machine learning models. Then it provides a list of detected activities, each of which includes
the type of activity relative to entities in the physical world, like riding a bicycle, running or in a vehicle,
for example, and a confidence level that indicates the likelihood that the user is performing the activity
represented. We are only accepting activities with a confidence level over 75%, so we are discarding all
activities that do not give us guarantees.
If the activity recognition detects that the user is aboard a vehicle, it is considered that the user is
moving inside the public transport vehicle. Although, it is possible that the activity recognition detects
movement but does not assume that is inside a bus. For such cases we have a movement detection
service that calculates if the user is moving based on the travelled distances measured using GPS.
In this function we consider that the user is moving aboard a public transport if three conditions are
simultaneously reunited:
• the beacons of that vehicle are being detected for more than the minimum detection time (15
seconds)
• if movement is being tracked for more than the minimum threshold (10 seconds)
39
• if the average speed of the user matches a vehicle speed (assuming that a minimum of a vehicle
is about 21.6 km/h).
Notice that activity recognition and movement detection is only used to identify that a check-in is
required to notify the user to do it. If the user is inside the vehicle and the application does not detect
activity/movement, it is always possible to perform a check-in, and the user should do it.
4.2.3 Communication with back-end
In the mobile application, every sensible information is computed in back-end side, to guarantee that
there are no inconsistencies or fraud. Every information about user or travels is stored in the back-
end. Tasks like translating beacon identification to its respective vehicle or balance charging, are always
made in the back-end, so we have to establish a secure and fast communication with the back-end. The
vehicle transport routes and the assignment of beacon identifications to the correspondent vehicle are
only known in back-end side. This way, every time that a different assignment or a route is changed the
application does not necessarily have to be changed.
The back-end is implemented in order to provide its services through a REST (Representational
State Transfer) architecture style. The webservice exposes resources in the form of Uniform Resource
Identifier (URI) to be easily understood. Clients can interact with the service using HTTP methods, for
example GET, POST, PUT, and DELETE. When exchanging data between client and server, the data
can only be in text. Therefore, data objects and attributes are represented using JavaScript Object
Notation (JSON). This is a syntax for storing and exchanging data in text format. This way we can work
with the data as objects, with no complicated parsing and translations.
To consume the services provided by the back-end, we use Retrofit (v2.3.0), a REST client for An-
droid (and Java) developed by Square. This provides a robust framework that makes it easy to retrieve
and upload data from and to the server. With Retrofit it is possible to serialise data to different formats.
However, due to simplicity, we are using JSON format, so we selected Gson library (Retrofit 2 Converter
Gson v2.3.0).
4.3 State machine
Travel processing is controlled by a state machine dependent on several factors, such as the number
of beacons detected, whether a movement is detected, a button is pressed, or even if the user has
sufficient balance to make a trip. A state machine diagram with all the possible states, tasks performed
and transitions between them can be observed in Figure 4.9. The explanatory notes of each element
can be seen in the dashed rectangle at the bottom right corner of the figure. States are represented by
rounded rectangles with the title in bold and green background, Tasks are simple boxes, conditions are
diamonds with grey background and indicate a question, and transitions are represented by arrows.
40
Figure 4.9: Implementation State Machine diagram.
1. The application starts in the ”Out” state. When it starts detecting the minimum number of beacons
(2) with the same identification, it transits to ”Near” state. Otherwise, it stays in ”Out” state.
2. While it is detecting the minimum number of beacons it stays in ”Near”. If at any point, the appli-
cation detects that the user is moving, using the activity recognition, the current location is stored.
Then, if the user has a positive balance, the application changes to ”Checking In” state. Otherwise,
the application does not allow to check-in and warns the user to charge it. It is possible to transit
directly to ”In” state if the user clicks on the ”check-in button”. Although it only changes to this state
after storing the current location. If the minimum number of beacons are not being detected the
application goes to ”Out” state.
3. In this state, the current location is always getting stored with four seconds of interval. This state
41
is waiting for the user to press the check-in button, in order to change to ”In” state, indicating the
beginning of a journey. When the button is clicked, the ”Check-In” process begins, in which the
application communicates to the back-end that a journey started, indicating not only the current
location but also the beacons where it is possible to check-in (more than two beacons from the
same bus are being detected). The back-end returns the identification number of that journey.
Again, if the minimum number of beacons are not detected transits to ”Out” state.
4. When ”In” it is only possible to change to state ”Checking Out” when the minimum beacons of
the bus in which the check-in was made, and there are no alternatives to update the check-in. If
the application stopped detecting the current bus beacons but continues to detect the beacons
from an alternative bus, it starts the ”Update Check-in” task, in which the app communicates to
the back-end that occurred a change in the vehicle. Notice that it does not indicate that the user
changed from one bus to another, but that the initial check-in was made in the wrong bus, so the
application detects that it should have been done in another and changes to it.
5. When in ”Checking Out” state, the current location is stored in order to communicate it to the back-
end, along with journey and user identifications, to perform the ”Check-out” and change to ”Out”
state. This is an automatic transition that has not related conditions. In back-end side, the amount
to pay for the complete journey is calculated, and it is deducted from the user balance.
4.4 Security
To make the application as attractive as possible and increase its reliability is very important to ensure
the security of the data, and consequently of the user. Therefore, the main security concern was to rely
every sensible information and processing to the back-end. In this way, the back-end stores all user and
travel information, and the mobile application only holds tokens that index the information on the server.
We decided to decouple this information from the application to avoid modifying the information in order
to deceive the system. With this architecture, if an intruder modifies the application and changes the
user token or the journey token it will not be able to index the information in the back-end and cannot
change it.
In the same way, all tasks that directly changes the balance are performed in the back-end, and the
result is sent to the application. This method is better than making the same calculations in both sizes,
which could lead to inconsistencies in one side, or calculating only in application side which does not
avoid that someone changes the application, and therefore the calculation method.
Finally, since there is sensible information exchanged between the application and the back-end is
essential that this communication is secure. With this in mind, every communication is made using
HTTPS (Hyper Text Transfer Protocol Secure), which allows data to be transmitted over an encrypted
connection, and verifying server and client authenticity.
42
Chapter 5
Back-end Server
The back-end server is a remote site where all the information related to the system is processed and
stored. In a ”client-server” architecture, the main goal of a server is to provide functionality for several
clients. Usually, in mobile computing, servers are devices with more processing capability and storage,
allowing to execute compute-intensive tasks much faster on remote infrastructure than on mobile de-
vices. In the same way, delegating data carrying to a cluster in the cloud provides access to much more
storage than a mobile computer has available locally. Also, by offloading computation or data storage
from a battery-powered device to a remote computer with wall power, the operational lifetime of the
mobile device can be extended without degrading the user experience.
Although the processing is made remotely, the user should not notice it, i.e. on the application side,
the interaction with the server should be invisible. To achieve this is very important that the connection
between the back-end and the mobile device be wide and fast enough to prevent the user having long
waiting times for the responses.
We developed a back-end that should be managed by the public transport operator. This server
can control all information about the system, such as journeys and users. It is possible to the operator
to make adjustments to its services based on the information held by the back-end, like vehicle route
modifications or even changing the fare calculation. The back-end will not only interact with the mobile
user applications to track their travels but also with the inspector application, to verify the validation
codes of the user applications. This server also processes the fare calculation of each trip. To do this, it
is connected to a transport buses and route database that has the information about all the vehicles in
transit and what their possible routes.
Therefore, we developed a server based on the ”Card Engine - Host Card Emulation”, a product
designed by Link Consulting. Our server as an identical structure of this already existing system, which
allows an easy portability of our system to an already operating server. However, all the services pro-
vided by our back-end were implemented from scratch. Therefore only the way to offer them to the clients
is the same. The server was implemented using ”Java Enterprise Edition 7” (JavaEE 7) and WildFly 8
(formerly known as JBoss). Wildfly is an application server, which facilitates the creation of web appli-
cations and provides a server environment to run them. This way we can expose the webservices for
43
the clients to use them as they wish. It is used Java API for RESTful Web Services (JAX-RS) to simplify
the development and deployment of web service endpoints. To expose the webservices in a RESTful
service, we used Jersey, a JAX-RS API to simplify the exposition of data in a variety of representation
media types, abstracting away the low-level details of the client-server communication.
5.1 User registration and authentication
One of the features of the back-end server is storing all information about all the users. To start to use
the application a user has to be registered in the back-end, giving all the relevant information to travel
using the system. Each user has an account, in which is stored the personal information, trip history
and balance. All users are identified by their phone number, which is unique and personal. A password
protects each account, to prove that the person who is trying to use the application is who claims to be.
When the user is registering in the application, is necessary to fill the form with the personal informa-
tion, as demonstrated in Figure 4.1. After completing all fields, the user needs to ask for a code, clicking
the button. This will send the information to the back-end, which validates the entered data. If all data
is valid, the back-end generates a random 4-digit code that communicates with the application. Ideally,
this random code is sent through SMS, to prove that the user owns the provided phone number, but due
to the problematic access to free SMS service, it is simulated by a message appearing on the mobile
application. The registering process ends when the user correctly inserts this code and gets a token.
This token is randomly generated code that unequivocally indexes the user in the back-end. This way,
each time the mobile application interacts with the back-end, to identify the logged user just needs to
send the user token, and the back-end can associate that information with the correspondent user. An
illustration of the registering process, with the information exchanged between mobile application and
back-end, can be seen in the Figure 5.1.
Every time that a user wants to login in the application and is already registered, it is only necessary
to enter the phone number and the associated password.
5.2 Fare calculation
One of the main focus of the back-end server is to calculate how much to pay for a journey.
The fare is calculated based on the following steps:
1. Identify the bus in which the passenger is travelling. Then, get that bus route, which includes all
the stations it stops from the origin to the destination.
2. Identify the entrance location stored in the check-in information. Then, compare each station
coordinates with the user location when the check-in was performed, to select the nearest station.
To do this, we use Haversine formula (Equation 5.1) to calculate the distance between two points
on Earth surface. If we have Point1 with coordinates lat1 and lon1 and Point2 with coordinates
44
Figure 5.1: Communication exchanged in registering process.
lat2 and lon2, using R as the mean radius of Earth (mean value used: 6371.008 m), the distance
between the two points is given by the variation of Haversine formula:
dLat = (lat2− lat1) ∗ π180
dLon = (lon2− lon1) ∗ π180
a = sin2(dLat2 ) + cos(lat1 ∗ π180 ) ∗ cos(lat2 ∗
π180 ) + sin2(dLon2 )
distance = 2 ∗R ∗ arcsin(min(1,√a))
(5.1)
Comparing all bus route stations with check-in location, the minimum distance obtained refers the
nearest station from where the check-in was performed, therefore the entrance station to use in
the calculation.
3. After that, we need to know the exit station of the travel. Now we just have to compare the check-
out location with the stations in the route that follows the already selected entrance station, using
Haversine formula (Equation 5.1) again to calculate the distances.
4. Finally, as we have already obtained the stations of entry and exit, we can now count the number
of stations between them and calculate the price to pay for the trip.
In this prototype we are using a fixed price for starting a trip plus a fixed price for each number of
intermediate stations, so we calculate the fare based on the following formula:
Cost = TravelBase+ StationBase ∗NumberOfStations (5.2)
45
However, the public operator transport can choose a different fare calculation method, just by chang-
ing the formula. The stations are already being tracked, so any station-based calculation is acceptable
by our system, and adaptable to zone-based and fixed prices methods.
5.3 Trip log
Back-end server is responsible for storing every trip that is made using the system. It is important to
record every relevant information about the moments where the check-in is made and when the check-
out is detected. During a journey, there are four important moments in which is important to record the
application context. The data exchanged in these moments can be seen in Figure 5.2.
1. When the application starts detecting a minimum number of beacons from the same bus, it is
necessary to translate the beacon identification to the correspondent bus number.
2. When the check-in button is pressed, the application sends the user token, to identify which user
is starting the journey, the identification of the beacons in which is checking-in, a list of beacon
IDs of all other possibilities to check-in, and finally the current latitude and longitude. The back-
end creates a new journey entry with this received information, generates an identification of this
journey entry and returns it to the application.
3. When the application stops detecting the minimum number of beacons of the given beacon ID in
the check-in, it will verify if any of the alternatives is being identified. If yes, an ”Update check-in”
is performed, in which the application sends the journey identification to say which trip is being
updated, as well as the coordinates (latitude and longitude) of the point in which this update is
performed. The back-end returns the journey identification to confirm that the update was done.
4. Finally, when no more beacons are being detected, the applications performs a ”Check-out”, and
sends the journey identification that is being finished, the user token to identify the passenger and
the current location (latitude and longitude) where the check-out is done. The back-end calculates
the price to pay for the travel and returns the new user balance, and a journey summary with the
check-in and check-out dates, the cost of the finished trip, the bus number and the list of stations
crossed within the travel.
46
Figure 5.2: Communication exchanged in travelling process.
5.4 Transport route and stops database
It is essential for the back-end to have full knowledge about all the stations, buses and routes of the
public transport operator. Since the fare calculation is based on the number of stations crossed during
the travel, it is important to know the check-in and check-out stations, as well as all the stations in which
the bus stops during the journey. Regarding this issue, we implemented a database with information
of several stations, buses and routes of Carris, our use case for this prototype. This database was
populated with data collected from Carris website [22]. The database has the entity model represented
in Figure 5.3. We have three main entities:
1. Stop: A stop station. Each stop is unequivocally identified by a code. Also, it has a name associ-
ated, and the coordinates (latitude and longitude) to compare with the user location.
47
Figure 5.3: Entity model of transport route and stops database.
2. Line: The route of a bus. It has a unique name that indicates the correspondent bus, and the
destination that refers the last station of that route. The direction is also provided (upward or
downward) to identify precisely the bus line.
3. LineStop: A stop in the bus line. The intermediate entity that connects the other two entities. Each
line has several stops. But a stop can also belong to different lines. This way, we can identify the
stop of a line unequivocally without referring the other lines. Each lineStop is identified by the line
name and the stop code. It also has a reference to the destination of the line it belongs.
Accessing this database we can track user location based on the stations where the check-in and
check-out tasks are made, and therefore calculate the price to pay for a journey.
48
Chapter 6
Evaluation
The evaluation of this work focuses on measuring the times of the system critical tasks, such as
entrance and exit detection times; the differences between the internal state transitions; and the visibility
of the new state to the user. In this chapter, we will present the metrics collected through the use made
by users aware of the service operation and discuss the results. We found this values indicative of
the system performance since it allows to verify some failure cases, related to the detection reliability.
Notice that the values in this evaluation were obtained in a simulation environment and not in a real
public transport vehicle. Therefore, the times collected are approximate to the real-time operation of the
system. It would be advantageous and more accurate to test in a real environment, with real vehicles
causing interference, to verify the scalability of the solution.
6.1 Travelling simulation scenario
We decided to perform tests in a wide open room, large enough to include the standard bus dimen-
sions and a margin for the user to move inside/outside the beacon range. In this test case, the bus
remains still and is the user who moves away from the ”vehicle” (beacon range). We performed it in a
wide open room inside Instituto Superior Tecnico, with access to a corridor through a door (opened),
that allows the user to move freely in/out of the beacon range. We used the standard bus dimensions,
because there are a lot more vehicles circulating than the articulated (582>90), as referred in section
3.1. The test scenario can be observed in Figure 6.1. The beacons were placed with the same config-
uration as inside a standard bus. The red lines indicate where the application should stop detecting the
beacons. One of the red lines is placed at the room entrance/exit, to give the user the sense of when
got in/out the range and. Inside the room, there were more people, with several devices connected to
the wireless internet and some BLE devices, which approximates the real environment.
Three different users were invited to participate in the test set, in order to measure how much time
takes each step in the travel process. We have explained the purpose of the system and its mode of
operation to users. Therefore the application was not strange to them. Although it was the first time they
were using the mobile app, its functionality had already been shown.
49
Figure 6.1: Test scenario diagram.
The smartphone used to perform the tests was an LG L90 D405 (Android 5.0.2 Lollipop, API 21) with a
2540mA battery.
Users could perform travels in two modes: clicking in ”check-in button” when in ”Near” state; or
simulating movement using a third-party application to simulate the navigation between two points on
the map, and finally clicking on ”check-in button” when our application detected movement. We used an
app called ”Mock Locations (fake GPS path)” developed by Dvaoru, to simulate the positions.
An auxiliary button (”Simulation button”) in the application was created for the user to warn when left
the room (passing through the door), and therefore move out from the beacon range, to calculate the
delay compared to the time detected by the application. Each user was asked to simulate a journey,
depending on the mode and according to the following steps:
• Not simulating movement (Experiment 1):
1. Move away from the beacon range (wait for state ”Out”)
2. Move inside the beacon range (wait for state ”Near”)
3. Click on ”check-in button” (wait for state ”In”)
4. Move out from room and click the ”simulation button” when passing the door
5. Wait for the end of the journey (state ”Checking-out”) and confirm the summary shown or wait
for the timeout.
• Simulating movement (Experiment 2):
1. Move away from the beacon range (wait for state ”Out”)
2. Move inside the beacon range (wait for state ”Near”)
50
3. Open auxiliary app (”Mock Locations”) and initiate stored simulation. Return to our applica-
tion and click ”simulation button” to indicate that the movement has initiated (wait for state
”Checking-in”)
4. Click on ”check-in button” (wait for state ”In”)
5. Move out from room and click the ”simulation button” when passing the door
6. Wait for the end of the journey (state ”Checking-out”) and confirm the summary shown or wait
for the timeout.
6.2 Obtained results
After setting up the test environment and providing the experiment instructions to users, 72 travels
were simulated: 56 using the process of Experiment 1, in which is not detected movement before the
check-in, and 16 following the instructions of Experiment 2, in which the movement is mocked using the
auxiliary application. We decided to test this difference to verify if there is a delay between checking-in
when entering the bus or checking-in when already inside the bus and moving, waiting for application
check-in warning due to motion detection.
The metrics were obtained by storing log files of system functionalities, indicating the timestamps of
each task. Therefore for each state, we obtained the timestamps referred in Table 6.1.
Table 6.1: Metrics collected in each state.
51
First, we calculated the average duration of every transition for each experiment and elaborated the
graph shown in 6.2.
Figure 6.2: State transitions graph with average durations.
The times shown are calculated between the event that triggers the state transition and the moment
when the state becomes visible or the information gets stored in the back-end, depending on the last
event produced:
1. Out - Near: Time is calculated using the time when beacons are detected and the time when new
state gets visible for the user
2. Near - Checking-in: If movement is simulated, time between when simulation starts and new state
gets visible; if not simulated, time passed since the ”check-in button” is clicked to when the new
state gets visible
3. Checking-in - In: If movement is simulated, is shown the time between the last location saved and
when the response of the check-in information is received from back-end, ensuring that the journey
is started in the back-end
4. In - Checking-out: Time elapsed since when the user moves away from the beacon range to when
the journey summary is received from back-end, ensuring that the trip is terminated
5. Checking-out - Out/Near: Time is calculated using the time when the summary window gets
closed, and the new state is shown
52
As we can observe, transitions ”Out to Near” (1), ”In to Checking-out” (4) and ”Checking-out to
Out/Near” (5) have similar values in both experiments. The difference between the two testing processes
is at the check-in moment, so only the transitions that include the ”Checking-in” state are affected.
Therefore, as we can see, in Experiment 1, transition ”Near to Checking-in” (2) takes much less time
than in Experiment 2. In contrast, transition ”Checking-in to In” takes almost twice (180%) as long as in
Experiment 2. This difference is due to the delay caused by the motion detection in Experiment 2. As
we already mentioned, to detect movement it is necessary that the vehicle moves at a velocity over 36
km/h in the past 10 seconds.
According with the graph in Figure 6.3, which specifically shows the time spent on each task of
transition 3, we can see that in the first experiment, the transition duration is due to the lengthy process
of obtaining the location. This location delay is the time spent between the last position saved and the
moment when the check-in information (including the location) is sent to the back-end. This delay may
be due the interval between each location collection be specified for 4 seconds, which is a reasonable
value that does not compromise the fare calculation.
In experiment 2, there is a movement detection delay of 05,313 seconds that affect the total transition
duration in the second testing process. This movement delay causes an increase of 04,942 seconds
in relation to the first experiment. Notice that the movement detection only verifies if it is necessary to
warn the user that a check-in must be performed, so it is possible to check-in as soon as the user is near
the vehicle (following experiment 1). On the other hand, when checking-in, as soon as we obtain the
location, the more accurate is the station selection, and consequently the fare calculation. Therefore we
found this value acceptable, as long as it provides a more precise calculation in exchange of an average
delay of fewer than 5 seconds presenting the state to the user that is not forced to wait since it is possible
to check-in when in ”Near” state.
Communication delay is the difference between sending the check-in information and the response
from the back-end. This value depends on the internet bandwidth, so the value is similar in both cases
with an average value of 00,841 seconds.
Figure 6.3: Checking-in to In times graph.
53
Observing again Figure 6.2 we can conclude that the transition that takes most of the time is ”In to
Checking-out” (4). We can observe each task duration of transition 4 in Figure 6.4.
Figure 6.4: In to Checking-out average duration graph.
The time spent in transition four is also influenced by the location delay. However, in this case, the
location delay is much higher, with average values of 19,947 seconds. This increase is due to the out of
range delay up to 30 seconds, that is associated with the beacon protocol to avoid false positives when
monitoring exits from beacon region area, as already referred in Section 4.2.1. Therefore, we measured
an average delay of 19,820 seconds between the moment the user moves out from the beacons and
the moment detected by the beacon protocol. As the application recognises it later, the location is also
obtained later. This value can compromise the fare calculation since it occurs in a delay that can lead to
the difference between two stations, and therefore the system may harm or benefit the user. Also, users
have to wait almost 20 seconds to verify in the application that the check-out was performed, which
leads to confusion, as the participants in the test informed. However, this item can be solved adapting
the public transport operator business model to accept a margin, i.e. since the location is obtained too
late, discount one station (margin), for example. Other solution would be to use another beacon protocol
that avoids this delay related to false positives.
6.3 Battery consumption
During the test battery, we used AccuBattery, an Android application developed by Digibites that can
monitor the battery consumption of all the application running on the smartphone. With an intensive
usage of the application running on the testing smartphone (with a 2540 mA battery) during two hours,
while the tests were being performed, AccuBattery indicated a battery usage of 138,4 mAh, which
represents 5,45%/h of battery usage. During 4 hours in passive mode, i.e. detecting beacons but without
performing any travel, the application indicated a battery usage of 12,5 mAh, which indicates less than
0,05% of battery per hour. These values indicate that the application has a low battery consumption,
allowing an intensive usage of approximately 18 hours on a regular smartphone.
54
Chapter 7
Conclusions
Society is increasingly aware of using public transport to reduce pollution and family costs. Nowa-
days, billions of people use public transport to move to their destinations. Therefore it is becoming
imperative to develop new ways of travelling to serve new users needs. With the technologies advances
is now possible to make public transport travelling more attractive to users, making the service more
straightforward and intuitive, leading users to discard their personal vehicles.
One of the main problems when using public transport is the time-consuming task of acquiring tickets
before starting a trip; or when the user needs to present the ticket to a validator or inspector to confirm its
validity. This led us to look for a solution that allows to reduce the waiting lines in that crucial moments,
simplifying all the travel process. Also, the usage information of the public transport services is essential
for the operator and nowadays is not easy to automatically monitor the public transport traffic based on
the current statistics. Our solution suggests a global visualisation of the public transport service usage,
providing information about the past and current travels.
The advances in BLE technology have led to a high adoption to this mode of communication for
Internet of Things systems, such as home automation and network sensors. Also, as referred in Related
Work (chapter 2), several research groups have been trying for some time to develop BLE solutions for
public transport, with some relevant results. After a deep analysis of the current market and the related
projects being matured in this area, we identified some of the flaws that could be improved. Some
approaches had complex architectures or required extensive modifications in the system deployment,
as an on-board computer that monitors all the communication protocol to detect the passenger presence.
Therefore, we found our opportunity to embrace the change and help provide a mobile ticketing solution,
location-aware and based on BLE iBeacon technology. One of the main innovations of our approach is
that the mobile application is responsible for coordinating the beacon detection and sending the travel
information to the back-end, without needing any other device. Only the beacons are necessary to be
deployed inside the vehicle, but these are cheap, have their own power supply (battery) and are very
easy to deploy.
The work presented had to deal with a typical distributed system, in which we developed a mobile
application and a back-end server. Thus, we had to consider issues related to mobile computing, such
55
as memory requirement, battery consumption, interactivity, connectivity, and security. As we are faced
with a mobile application for a smartphone, it is essential to ensure its interoperability, i.e. that the
application is able to run on any smartphone. Although the prototype has been developed for Android,
all of the functionalities used are also available on any other platform. Therefore a similar application for
iOS with the same capabilities should be possible.
One of the main challenges in this development was to coordinate the location obtain, with the
beacon detection and the communication to the back-end. Ideally, the faster we detect the beacons and
the more frequent we obtain the current location, more accurate are the values communicated to the
back-end. However, these tasks have battery consumption issues that had to be dealt, so we had to find
a balance between the acceptable values for location and detection delay and the energy consumed.
To evaluate the performance of our system we measured the time consumed by each process per-
formed by the application, to verify if the results were acceptable in a mobile ticketing system for public
transport. We found most of the values satisfactory, with acceptable delays that do not compromise the
correct system behaviour. However, the checking-out duration caused by the beacon protocol monitoring
should be reduced to detect with more accuracy the exit station of the travel.
The developed system allows reducing user interaction when travelling inside public transport ve-
hicles, providing a new and simpler travel experience using a daily device such as the smartphone.
Besides that, public transport operator can obtain real-time statistics of the system behaviour, allowing
them to adapt their services to the user needs. Our solution meets the initially proposed goals, with
some innovation and a progression margin for improvements.
7.1 Future Work
The present work consists of a prototype that is susceptible to improvement since there is still some
issues that can be deeply developed in this context. Despite this work focus being the passenger
detection and the possibility of adapting the fare calculation to the operator business model, some points
can be improved. We present some of the main ideas that can be explored in the future:
• Provide an external API
It would be profitable to publish an interface to access some services of the back-end, allowing
users to manage their account, for example. This way, it would be possible to develop a self-service
portal in which users could check their trip history or charge their account. Also, it would allow
having build applications able to verify the current statistics of the operator resources (vehicles
occupation, users currently travelling, etc.)
• Perform more tests to validate the solution
To confirm the benefits of the system, it would be better to test more, especially to the location
accuracy, battery consumption. But most importantly, the tests should be made in a real environ-
ment, inside a real vehicle with some users generating interferences, to give a better overview of
system operation.
56
• Explore more security issues
Although some of the leading security concerns being addressed in this work, like the crucial
information decoupling from the mobile application, some issues need more attention. In a real
deployment of a system like the described, should be necessary to have more security concerns
like the authenticity of users, preventing an intruder to impersonate other user and perform travels
without paying, using the other user’s identification.
57
58
Bibliography
[1] H. Lorenz, D. T. Grundel, P. W. Tomlinson, K. Philipp, and J. Acklam. Be-in-be-out payment systems
for public transport. Report, UK Department for Transport, July 2009.
[2] W. Narzt, S. Mayerhofer, O. Weichselbaum, S. Haselbock, and N. Hofler. Bluetooth low energy as
enabling technology for be-in/be-out systems. In 13th IEEE Annual Consumer Communications &
Networking Conference, Jan. 2016.
[3] Fraunhofer Institute for Transportation and Infrastructure Systems IVI. ALLFA Ticket.
URL http://www.ivi.fraunhofer.de/en/research-fields/intelligent-transport-systems/
ticketing-and-fares/archive/allfa-ticket.html. (Accessed: 2016-11-10).
[4] G. Conte, M. D. Marchi, A. A. Nacci, V. Rana, and D. Sciuto. Bluesentinel: a first approach using
ibeacon for an energy efficient occupancy detection system. In editor, editor, BuildSys ’14: Pro-
ceedings of the 1st Association for Computing Machinery Conference on Embedded Systems for
Energy-Efficient Buildings, pages 11–19, Nov. 2014.
[5] W. Narzt, S. Mayerhofer, O. Weichselbaum, G. Pomberger, A. Tarkus, and M. Schumann. Design-
ing and evaluating barrier-free travel assistance services. In HCI in Business, Government, and
Organizations: Information Systems, pages 434–445, July 2016.
[6] W. Narzt, L. Furtmuller, and M. Rosenthaler. Is bluetooth low energy an alternative to near field
communication? Journal of Mobile Multimedia, Vol. 12(No. 1&2):76–90, Apr. 2016.
[7] C. Hughes. Bluetooth low energy for use with mem sensors. Master’s thesis, Arizona State Univer-
sity, Dec. 2015.
[8] Apple Inc. US. iOS 5.0. URL https://developer.apple.com/library/content/releasenotes/
General/WhatsNewIniOS/Articles/iOS5.html. (Accessed: 2016-12-12).
[9] Android Developers. Bluetooth Low Energy. URL https://developer.android.com/guide/
topics/connectivity/bluetooth-le.html. (Accessed: 2016-12-12).
[10] Microsoft Developer Network. What’s New in Windows Phone 8.1. URL https://msdn.microsoft.
com/en-us/library/windows/apps/dn632424.aspx. (Accessed: 2016-12-12).
[11] M. Mezghani. Study on electronic ticketing in public transport. Report, European Metropolitan
Transport Authorities, May 2008.
59
[12] S. Kuchimanchi. Bluetooth low energy based ticketing systems. Master’s thesis, Aalto University,
School of Electrical Engineering, Feb. 2015.
[13] T. McDaniel and F. Haendler. Advanced rf cards for fare collection. In ’Commercial Applications
and Dual-Use Technology’, Telesystems Conference Proceedings, pages 31–35, July 1993.
[14] J. J. Treurniet. From check-in/check-out to be-in/be-out: Ble-based automated journey payment in
public transportation. Master’s thesis, Delft University of Technology, Faculty of Electrical Engineer-
ing, Mathematics and Computer Science, Jan. 2015.
[15] W. Narzt, S. Mayerhofer, O. Weichselbaum, S. Haselbock, and N. Hofler. Be-in/be-out with blue-
tooth low energy: Implicit ticketing for public transportation systems. In IEEE 18th International
Conference on Intelligent Transportation Systems, Sept. 2015.
[16] M. Radhakrishnan, A. Misra, R. Balan, and Y. Lee. Smartphones & ble services: Empirical insights.
In IEEE 12th International Conference on Mobile Ad Hoc and Sensor Systems, pages 226–234,
Oct. 2015.
[17] J. Leal, R. Couto, P. Costa, and T. Galvao. Exploring ticketing approaches using mobile technolo-
gies: Qr codes, nfc and ble. In IEEE 18th International Conference on Intelligent Transportation
Systems, pages 7–12, Sept. 2015.
[18] J. Lindh. Bluetooth R© low energy beacons. Application report, Texas Instruments Incorporated,
Oct. 2016.
[19] C. Gomez, J. Oller, and J. Paradells. Overview and evaluation of bluetooth low energy: An emerging
low-power wireless technology. Sensors, 12(9):11734–11753, Aug. 2012.
[20] J. Arvidsson and J. Vidmar. Location based functionality in public transport applications. Master’s
thesis, Lund University, Faculty of Engineering LTH, June 2015.
[21] Link Consulting. SmartTicketing - What we do. URL http://www.linkconsulting.com/
smartcities/what-we-do/. (Accessed: 2016-12-22).
[22] Carris. Frota. URL http://www.carris.pt/pt/a-frota/. (Accessed: 2017-06-10).
60
Appendix A
Table with comparison between
previous projects
Table A.1: Comparison of features between previous projects.
ALLFA Esprit JKUBibo wake-up Uni-directional process at en-
trance and wake-up schemeduring normal operation
Active during the entire journey Active after first scan
Type of RF com-munication
Bi-directional between on-boardcomputer and user devices;anti-collision protocol; multipletimes between stops
Mainly uni-directional from on-board computer to user devices;anti-collision not needed; multi-ple times between stops
Mainly uni-directionalfrom on-board com-puter to user devices
Transaction datasecurity
Electronic signature (symmetricscheme, 3DES); encoding andpublic key infrastructure (PKI)
Asymmetric scheme (RSA,ECC) and public key infrastruc-ture (PKI)
AES 128 bit encryp-tion
Fare calculation Background system (central) User device (decentral) (Information not ad-dressed)
Time of fare cal-culation
After a period of time, in back-ground system (e.g. end of trip,end of month)
Real-time in vehicle (betweenconsequent of stops)
(Information not ad-dressed)
Type of fare cal-culation
One-step Incremental (Information not ad-dressed)
Fare models High flexibility because of cen-tralized and offline fare calcula-tion
Theoretically less flexible duethe real-time fare calculation
(Information not ad-dressed)
Payment Pre-paid/post-paid (via back-ground system)
Pre-paid (with incremental de-duction from stored value onuser device); post-paid also pos-sible
(Information not ad-dressed)
Data transfer tobackground sys-tem
Independent of place and time,via GSM/GPRS
Via stationary terminal when re-loading user device; also via RFand on-board component plusGSM/GPRS
(Information not ad-dressed)
Data transfer tovehicle
Independent of place and timevia FSP/GPRS
Via GSM/GPRS (Information not ad-dressed)
61
62
Appendix B
Time Measurements
Table B.1: Out to Near times (1).Out—>Near
# Beacon detect State changed State visible Total (s)
1 15:53:17,799 15:53:17,879 15:53:17,940 00,1412 16:48:14,567 16:48:14,719 16:48:14,772 00,2053 16:49:12,880 16:49:12,956 16:49:13,009 00,1294 16:50:26,030 16:50:26,060 16:50:26,105 00,0755 17:41:34,344 17:41:34,443 17:41:34,501 00,1576 17:42:28,176 17:42:28,224 17:42:28,271 00,0957 17:43:58,756 17:43:58,830 17:43:58,885 00,1298 17:44:44,219 17:44:44,309 17:44:44,388 00,1699 17:45:25,391 17:45:25,466 17:45:25,489 00,098
10 18:05:22,756 18:05:22,800 18:05:22,846 00,09011 18:06:17,464 18:06:17,522 18:06:17,560 00,09612 18:07:09,815 18:07:09,886 18:07:09,945 00,13013 18:08:03,419 18:08:03,473 18:08:03,527 00,10814 18:09:09,266 18:09:09,325 18:09:09,373 00,10715 18:11:05,478 18:11:05,537 18:11:05,590 00,11216 18:12:27,009 18:12:27,248 18:12:27,286 00,27717 18:13:24,664 18:13:24,723 18:13:24,823 00,15918 18:14:18,989 18:14:19,070 18:14:19,209 00,22019 18:15:40,365 18:15:40,524 18:15:40,571 00,20620 18:17:31,654 18:17:31,704 18:17:31,789 00,13521 18:18:33,729 18:18:33,798 18:18:33,838 00,10922 18:20:12,464 18:20:12,636 18:20:12,679 00,21523 18:21:56,386 18:21:56,471 18:21:56,598 00,21224 18:22:58,646 18:22:58,703 18:22:58,745 00,09925 18:23:59,306 18:23:59,362 18:23:59,417 00,11126 18:24:53,166 18:24:53,233 18:24:53,286 00,12027 18:26:08,224 18:26:08,454 18:26:08,495 00,27128 18:26:49,450 18:26:49,541 18:26:49,581 00,13129 18:27:47,379 18:27:47,434 18:27:47,475 00,096
63
Table B.2: Out to Near times (2).
# Beacon detect State changed State visible Total (s)
30 18:28:35,894 18:28:35,928 18:28:35,976 00,08231 18:29:29,484 18:29:29,530 18:29:29,576 00,09232 18:31:00,158 18:31:00,195 18:31:00,239 00,08133 18:31:53,792 18:31:53,915 18:31:54,054 00,26234 18:33:12,474 18:33:12,551 18:33:12,608 00,13435 18:34:47,112 18:34:47,202 18:34:47,245 00,13336 18:36:01,750 18:36:01,987 18:36:02,030 00,28037 18:37:45,702 18:37:45,789 18:37:45,843 00,14138 18:39:39,996 18:39:40,069 18:39:40,121 00,12539 18:40:38,875 18:40:38,938 18:40:39,075 00,20040 18:41:52,066 18:41:52,180 18:41:52,219 00,15341 18:42:50,910 18:42:50,965 18:42:51,014 00,10442 18:43:36,168 18:43:36,200 18:43:36,236 00,06843 18:44:41,110 18:44:41,166 18:44:41,216 00,10644 18:45:39,294 18:45:39,473 18:45:39,560 00,26645 18:46:52,705 18:46:52,766 18:46:52,814 00,10946 18:47:41,790 18:47:41,895 18:47:41,945 00,15547 18:50:23,339 18:50:23,572 18:50:23,613 00,27448 18:51:48,640 18:51:48,704 18:51:48,757 00,11749 18:52:38,146 18:52:38,192 18:52:38,338 00,19250 18:53:39,792 18:53:39,927 18:53:39,975 00,18351 18:55:26,844 18:55:26,918 18:55:26,973 00,12952 18:56:09,149 18:56:09,205 18:56:09,249 00,10053 18:58:41,511 18:58:41,572 18:58:41,726 00,21554 19:08:20,006 19:08:20,061 19:08:20,114 00,10855 19:09:09,476 19:09:09,713 19:09:09,757 00,28156 19:10:03,936 19:10:04,006 19:10:04,056 00,12057 19:15:29,960 19:15:30,084 19:15:30,152 00,19258 19:26:27,807 19:26:27,884 19:26:27,938 00,13159 16:40:27,807 16:40:27,884 16:40:27,938 00,13160 16:42:59,612 16:42:59,684 16:42:59,773 00,16161 17:11:35,608 17:11:35,680 17:11:35,696 00,08862 17:42:22,986 17:42:23,214 17:42:23,261 00,27563 17:45:11,406 17:45:11,502 17:45:11,550 00,14464 17:47:02,028 17:47:02,109 17:47:02,150 00,12265 17:52:59,059 17:52:59,123 17:52:59,178 00,11966 17:56:25,102 17:56:25,176 17:56:25,229 00,12767 18:07:22,950 18:07:23,019 18:07:23,073 00,12368 18:11:03,782 18:11:03,846 18:11:03,912 00,13069 18:12:05,711 18:12:05,778 18:12:05,832 00,12170 18:21:32,390 18:21:32,472 18:21:32,526 00,13671 18:24:29,063 18:24:29,129 18:24:29,191 00,12872 18:27:09,994 18:27:10,054 18:27:10,106 00,112
Average: 00,148
64
Table B.3: Near to In times (when not detecting movement in check-in) (1).Near—>In
Near—>Checking-in Checking-in—>In
# Buttonclicked
Statechanged
Statevisi-ble
PartialTotal(s)
Lastlocationsaved
Sentcheck-in
Receivedconfirma-tion
Communi-cationtime (s)
Locationdelay(s)
Statechanged
State visi-ble
PartialTotal (s)
TOTAL(s)
1 15:53:31,436 15:53:31,476 15:53:31,563 00,127 15:53:29,612 15:53:34,634 15:53:36,251 01,617 05,022 15:53:34,833 15:53:34,922 06,639 04,8152 16:48:25,426 16:48:25,468 16:48:25,557 00,131 16:48:19,971 16:48:26,025 16:48:26,652 00,627 06,054 16:48:26,108 16:48:26,219 06,681 01,2263 16:49:15,102 16:49:15,213 16:49:15,281 00,179 16:49:13,081 16:49:19,075 16:49:19,491 00,416 05,994 16:49:19,203 16:49:19,299 06,410 04,3894 16:50:28,807 16:50:28,847 16:50:28,938 00,131 16:50:26,192 16:50:31,212 16:50:32,420 01,208 05,020 16:50:31,488 16:50:31,599 06,228 03,6135 17:41:44,061 17:41:44,107 17:41:44,193 00,132 17:41:39,829 17:41:46,038 17:41:46,389 00,351 06,209 17:41:46,123 17:41:46,235 06,560 02,3286 17:42:30,142 17:42:30,286 17:42:30,351 00,209 17:42:28,374 17:42:35,080 17:42:35,374 00,294 06,706 17:42:35,137 17:42:35,208 07,000 05,2327 17:44:01,159 17:44:01,188 17:44:01,264 00,105 17:43:59,123 17:44:04,149 17:44:05,645 01,496 05,026 17:44:04,213 17:44:04,291 06,522 04,4868 17:44:45,939 17:44:45,986 17:44:46,039 00,100 17:44:44,652 17:44:50,822 17:44:51,125 00,303 06,170 17:44:50,938 17:44:51,021 06,473 05,1869 17:45:28,017 17:45:28,081 17:45:28,164 00,147 17:45:25,537 17:45:31,672 17:45:32,022 00,350 06,135 17:45:31,914 17:45:31,989 06,485 04,005
10 18:05:26,028 18:05:26,107 18:05:26,246 00,218 18:05:22,926 18:05:27,991 18:05:30,276 02,285 05,065 18:05:28,234 18:05:28,377 07,350 04,24811 18:06:21,749 18:06:21,788 18:06:21,839 00,090 18:06:17,642 18:06:24,070 18:06:24,465 00,395 06,428 18:06:24,122 18:06:24,191 06,823 02,71612 18:07:11,247 18:07:11,279 18:07:11,327 00,080 18:07:10,021 18:07:15,049 18:07:15,534 00,485 05,028 18:07:15,180 18:07:15,260 05,513 04,28713 18:08:04,994 18:08:05,032 18:08:05,107 00,113 18:08:03,604 18:08:09,990 18:08:10,375 00,385 06,386 18:08:10,041 18:08:10,139 06,771 05,38114 18:09:10,703 18:09:10,723 18:09:10,777 00,074 18:09:09,533 18:09:14,562 18:09:14,965 00,403 05,029 18:09:14,624 18:09:14,710 05,432 04,26215 18:11:15,757 18:11:15,799 18:11:15,870 00,113 18:11:10,687 18:11:17,976 18:11:18,365 00,389 07,289 18:11:18,029 18:11:18,102 07,678 02,60816 18:12:28,504 18:12:28,532 18:12:28,702 00,198 18:12:27,366 18:12:32,395 18:12:32,794 00,399 05,029 18:12:32,454 18:12:32,552 05,428 04,29017 18:13:26,211 18:13:26,373 18:13:26,424 00,213 18:13:24,895 18:13:26,424 18:13:31,868 05,444 01,529 18:13:31,428 18:13:31,496 06,973 05,65718 18:14:25,869 18:14:26,096 18:14:26,247 00,378 18:14:25,007 18:14:30,831 18:14:32,644 01,813 05,824 18:14:30,904 18:14:30,976 07,637 06,77519 18:15:41,600 18:15:41,642 18:15:41,694 00,094 18:15:40,674 18:15:45,703 18:15:46,084 00,381 05,029 18:15:45,750 18:15:45,843 05,410 04,48420 18:17:33,963 18:17:34,022 18:17:34,075 00,112 18:17:31,880 18:17:36,914 18:17:38,338 01,424 05,034 18:17:36,992 18:17:37,084 06,458 04,37521 18:18:37,257 18:18:37,319 18:18:37,394 00,137 18:18:33,917 18:18:40,028 18:18:40,506 00,478 06,111 18:18:40,080 18:18:40,148 06,589 03,24922 18:20:15,756 18:20:15,876 18:20:15,933 00,177 18:20:12,915 18:20:17,824 18:20:18,590 00,766 04,909 18:20:17,928 18:20:18,068 05,675 02,83423 18:21:57,934 18:21:57,968 18:21:58,027 00,093 18:21:56,670 18:22:01,710 18:22:02,891 01,181 05,040 18:22:01,881 18:22:01,978 06,221 04,95724 18:23:00,655 18:23:00,722 18:23:00,795 00,140 18:22:58,834 18:23:03,869 18:23:04,148 00,279 05,035 18:23:03,983 18:23:04,060 05,314 03,49325 18:24:01,050 18:24:01,184 18:24:01,251 00,201 18:23:59,493 18:24:04,517 18:24:05,830 01,313 05,024 18:24:04,587 18:24:04,675 06,337 04,78026 18:24:54,316 18:24:54,457 18:24:54,546 00,230 18:24:53,371 18:24:59,749 18:25:00,038 00,289 06,378 18:24:59,803 18:24:59,982 06,667 05,72227 18:26:11,115 18:26:11,146 18:26:11,206 00,091 18:26:08,589 18:26:13,606 18:26:14,810 01,204 05,017 18:26:13,661 18:26:13,788 06,221 03,69528 18:26:51,653 18:26:51,689 18:26:51,739 00,086 18:26:49,642 18:26:55,838 18:26:56,127 00,289 06,196 18:26:55,887 18:26:55,968 06,485 04,47429 18:27:48,920 18:27:48,940 18:27:49,056 00,136 18:27:47,552 18:27:52,588 18:27:54,215 01,627 05,036 18:27:52,688 18:27:52,769 06,663 05,295
65
Table B.4: Near to In times (when not detecting movement in check-in) (2).# Button
clickedStatechanged
Statevisi-ble
PartialTotal(s)
Lastlocationsaved
Sentcheck-in
Receivedconfirma-tion
Communi-cationtime (s)
Locationdelay(s)
Statechanged
State visi-ble
PartialTotal (s)
TOTAL(s)
30 18:28:37,129 18:28:37,170 18:28:37,217 00,088 18:28:36,391 18:28:42,468 18:28:42,753 00,285 06,077 18:28:42,528 18:28:42,598 06,362 05,62431 18:29:30,938 18:29:30,969 18:29:31,029 00,091 18:29:29,653 18:29:35,951 18:29:36,229 00,064 06,298 18:29:36,015 18:29:36,101 06,576 05,07732 18:31:02,072 18:31:02,099 18:31:02,173 00,101 18:31:00,316 18:31:05,354 18:31:07,734 02,380 05,038 18:31:05,433 18:31:05,509 07,418 05,66233 18:31:55,829 18:31:55,861 18:31:55,909 00,080 18:31:54,282 18:32:00,358 18:32:00,649 00,291 06,076 18:32:00,413 18:32:00,516 06,367 04,82034 18:33:24,391 18:33:24,505 18:33:24,568 00,177 18:33:24,014 18:33:29,309 18:33:29,625 00,316 05,295 18:33:29,363 18:33:29,436 05,611 05,23435 18:34:51,155 18:34:51,270 18:34:51,324 00,169 18:34:47,329 18:34:52,349 18:34:53,508 01,159 05,020 18:34:52,414 18:34:52,507 06,179 02,35336 18:36:03,763 18:36:03,798 18:36:03,852 00,089 18:36:02,122 18:36:07,118 18:36:09,025 01,907 04,996 18:36:07,179 18:36:07,255 06,903 05,26237 18:38:24,430 18:38:24,474 18:38:24,541 00,111 18:38:23,604 18:38:28,510 18:38:28,794 00,284 04,906 18:38:28,580 18:38:28,670 05,190 04,36438 18:39:41,624 18:39:41,741 18:39:41,804 00,180 18:39:40,391 18:39:45,410 18:39:46,443 01,033 05,019 18:39:45,465 18:39:45,542 06,052 04,81939 18:40:44,710 18:40:44,774 18:40:44,830 00,120 18:40:39,141 18:40:45,263 18:40:45,575 00,312 06,122 18:40:45,417 18:40:45,498 06,434 00,86540 18:41:54,888 18:41:54,943 18:41:55,018 00,130 18:41:52,293 18:41:57,969 18:41:58,722 00,753 05,676 18:41:58,083 18:41:58,148 06,429 03,83441 18:42:53,540 18:42:53,702 18:42:53,766 00,226 18:42:51,368 18:42:55,205 18:42:55,500 00,295 03,837 18:42:55,267 18:42:55,340 04,132 01,96042 18:43:56,599 18:43:56,663 18:43:56,720 00,121 18:43:36,310 18:43:57,530 18:43:57,819 00,289 21,220 18:43:57,583 18:43:57,658 21,509 01,22043 18:44:47,895 18:44:47,929 18:44:47,986 00,091 18:44:47,726 18:44:52,747 18:44:53,195 00,448 05,021 18:44:52,820 18:44:52,959 05,469 05,30044 18:45:43,354 18:45:43,382 18:45:43,459 00,105 18:45:39,695 18:45:44,696 18:45:45,095 00,399 05,001 18:45:44,756 18:45:44,840 05,400 01,74145 18:46:54,113 18:46:54,154 18:46:54,205 00,092 18:46:52,887 18:46:59,057 18:46:59,424 00,367 06,170 18:46:59,126 18:46:59,206 06,537 05,31146 18:47:44,231 18:47:44,258 18:47:44,334 00,103 18:47:42,022 18:47:48,322 18:47:48,704 00,382 06,300 18:47:48,389 18:47:48,462 06,682 04,47347 18:50:34,514 18:50:34,556 18:50:34,630 00,116 18:50:28,699 18:50:35,096 18:50:37,746 02,650 06,397 18:50:35,153 18:50:35,234 09,047 03,23248 18:51:50,556 18:51:50,589 18:51:50,667 00,111 18:51:48,838 18:51:53,908 18:51:54,334 00,426 05,070 18:51:53,978 18:51:54,250 05,496 03,77849 18:52:39,584 18:52:39,605 18:52:39,674 00,090 18:52:38,401 18:52:45,168 18:52:45,495 00,327 06,767 18:52:45,220 18:52:45,300 07,094 05,91150 18:53:41,554 18:53:41,735 18:53:41,782 00,228 18:53:40,058 18:53:46,523 18:53:46,803 00,280 06,465 18:53:46,579 18:53:46,690 06,745 05,24951 18:55:28,203 18:55:28,242 18:55:28,294 00,091 18:55:27,103 18:55:32,155 18:55:33,262 01,107 05,052 18:55:32,399 18:55:32,513 06,159 05,05952 18:56:12,474 18:56:12,516 18:56:12,564 00,090 18:56:09,322 18:56:15,490 18:56:15,803 00,313 06,168 18:56:15,549 18:56:15,660 06,481 03,32953 18:58:44,666 18:58:44,722 18:58:44,800 00,134 18:58:41,944 18:58:47,994 18:58:48,276 00,282 06,050 18:58:48,066 18:58:48,155 06,332 03,61054 19:08:21,353 19:08:21,393 19:08:21,445 00,092 19:08:20,192 19:08:25,271 19:08:26,310 01,039 05,079 19:08:25,327 19:08:25,445 06,118 04,95755 19:09:10,598 19:09:10,626 19:09:10,765 00,167 19:09:10,029 19:09:16,107 19:09:16,580 00,473 06,078 19:09:16,173 19:09:16,262 06,551 05,98256 19:10:06,195 19:10:06,257 19:10:06,336 00,141 19:10:04,133 19:10:10,325 19:10:10,753 00,428 06,192 19:10:10,389 19:10:10,504 06,620 04,558
Average: 00,135 00,825 05,824 06,652 04,222
66
Table B.5: Near to Checking-in times (when detecting movement in check-in).Near—>Checking-in
# Started simulation Movement detect Movement delay (s) State changed State visible TOTAL (s)
1 19:15:30,213 19:15:41,926 11,713 19:15:41,948 19:15:42,013 11,8002 19:26:37,280 19:26:43,595 06,315 19:26:43,654 19:26:43,740 06,4603 16:41:13,161 16:41:17,356 04,195 16:41:17,431 16:41:17,505 04,3444 16:43:26,469 16:43:31,188 04,719 16:43:31,367 16:43:31,715 05,2465 17:11:45,180 17:11:49,632 04,452 17:11:49,703 17:11:49,877 04,6976 17:42:33,413 17:42:37,563 04,150 17:42:37,650 17:42:37,763 04,3507 17:45:17,308 17:45:21,858 04,550 17:45:21,900 17:45:21,963 04,6558 17:47:12,078 17:47:15,800 03,722 17:47:15,824 17:47:15,886 03,8089 17:53:05,741 17:53:09,531 03,790 17:53:09,578 17:53:09,652 03,911
10 17:56:30,511 17:56:34,639 04,128 17:56:34,695 17:56:34,759 04,24811 18:07:32,375 18:07:36,787 04,412 18:07:36,822 18:07:36,947 04,57212 18:11:12,698 18:11:16,739 04,041 18:11:16,777 18:11:16,841 04,14313 18:12:11,589 18:12:16,164 04,575 18:12:16,194 18:12:16,260 04,67114 18:21:32,690 18:21:45,174 12,484 18:21:45,212 18:21:45,274 12,58415 18:24:36,372 18:24:40,182 03,810 18:24:40,211 18:24:40,301 03,92916 18:27:16,675 18:27:20,627 03,952 18:27:20,695 18:27:20,849 04,174
Average: 05,313 05,474
67
Table B.6: Checking-in to In times (when detecting movement in check-in).Checking-in—>In
# Button clicked Sent check-in
Receivedconfirma-tion
Communicationtime (s)
Last loca-tion saved
Locationdelay(s)
Statechanged
State visi-ble
Total(visible)(s)
Total (s)
1 19:15:44,621 19:15:46,114 19:15:46,771 00,657 19:15:41,861 04,253 19:15:46,210 19:15:46,442 01,821 02,1502 19:27:16,331 19:27:17,877 19:27:18,344 00,467 19:27:13,552 04,325 19:27:17,989 19:27:18,111 01,780 02,0133 16:41:22,332 16:41:25,606 16:41:26,117 00,511 16:41:22,055 03,551 16:41:25,695 16:41:25,813 03,481 03,7854 16:43:36,356 16:43:39,035 16:43:40,422 01,387 16:43:35,016 04,019 16:43:39,101 16:43:39,217 02,861 04,0665 17:11:51,891 17:11:53,812 17:11:54,179 00,367 17:11:49,514 04,298 17:11:53,936 17:11:54,079 02,188 02,2886 17:42:39,914 17:42:41,853 17:42:42,764 00,911 17:42:37,516 04,337 17:42:41,953 17:42:42,125 02,211 02,8507 17:45:22,336 17:45:26,627 17:45:27,148 00,521 17:45:21,807 04,820 17:45:26,693 17:45:26,838 04,502 04,8128 17:47:17,009 17:47:20,077 17:47:20,774 00,697 17:47:15,743 04,334 17:47:20,160 17:47:20,482 03,473 03,7659 17:53:10,144 17:53:13,759 17:53:15,476 01,717 17:53:09,469 04,290 17:53:13,849 17:53:14,006 03,862 05,332
10 17:56:35,384 17:56:38,894 17:56:39,903 01,009 17:56:34,572 04,322 17:56:39,154 17:56:39,284 03,900 04,51911 18:07:37,471 18:07:40,268 18:07:40,709 00,441 18:07:36,718 03,550 18:07:40,512 18:07:40,674 03,203 03,23812 18:11:17,077 18:11:20,314 18:11:20,795 00,481 18:11:16,683 03,631 18:11:20,382 18:11:20,511 03,434 03,71813 18:12:16,378 18:12:20,413 18:12:20,834 00,421 18:12:16,101 04,312 18:12:20,471 18:12:20,626 04,248 04,45614 18:21:46,037 18:21:49,530 18:21:53,456 03,926 18:21:45,115 04,415 18:21:49,593 18:21:49,740 03,703 07,41915 18:24:42,712 18:24:44,508 18:24:45,031 00,523 18:24:40,127 04,381 18:24:44,581 18:24:44,711 01,999 02,31916 18:27:22,791 18:27:24,741 18:27:25,099 00,358 18:27:20,552 04,189 18:27:24,815 18:27:24,987 02,196 02,308
Average: 00,900 04,189 03,690
68
Table B.7: In to Checking-out times (1).In—>Checking-out
# Mov? Out of range Stop de-tection
Out ofrange delay(s)
Saved loca-tion
LocationDelay (s)
Statechanged
State visible Sent check-out
Receivedcheck-out
Communicationtime (s)
TOTAL(s)
1 No 15:53:44,561 15:54:07,044 22,483 15:54:07,388 22,827 15:54:07,119 15:54:07,168 15:54:12,441 15:54:13,813 01,372 29,2522 No 16:48:34,608 16:48:55,732 21,124 16:48:56,194 21,586 16:48:55,838 16:48:55,895 16:49:01,232 16:49:02,277 01,045 27,6693 No 16:49:31,997 16:49:53,694 21,697 16:49:53,970 21,973 16:49:53,761 16:49:53,808 16:49:58,976 16:49:59,300 00,324 27,3034 No 16:50:43,805 16:51:04,076 20,271 16:51:05,555 21,750 16:51:04,126 16:51:04,221 16:51:10,771 16:51:11,284 00,513 27,4795 No 17:41:52,687 17:42:12,660 19,973 17:42:12,900 20,213 17:42:12,724 17:42:12,776 17:42:17,886 17:42:19,463 01,577 26,7766 No 17:42:38,547 17:42:57,308 18,761 17:42:57,506 18,959 17:42:57,380 17:42:57,417 17:43:02,507 17:43:03,604 01,097 25,0577 No 17:44:07,680 17:44:27,663 19,983 17:44:27,894 20,214 17:44:27,755 17:44:27,803 17:44:32,900 17:44:33,915 01,015 26,2358 No 17:44:54,881 17:45:13,135 18,254 17:45:13,370 18,489 17:45:13,203 17:45:13,263 17:45:18,378 17:45:19,386 01,008 24,5059 No 17:45:36,336 17:45:54,729 18,393 17:45:55,140 18,804 17:45:54,792 17:45:54,883 17:46:00,147 17:46:01,467 01,320 25,131
10 No 18:05:38,521 18:05:59,816 21,295 18:06:00,074 21,553 18:05:59,889 18:05:59,936 18:06:05,001 18:06:06,226 01,225 27,70511 No 18:06:29,888 18:06:50,334 20,446 18:06:50,550 20,662 18:06:50,389 18:06:50,483 18:06:55,563 18:06:56,019 00,456 26,13112 No 18:07:18,796 18:07:39,317 20,521 18:07:39,644 20,848 18:07:39,544 18:07:39,580 18:07:44,659 18:07:46,309 01,650 27,51313 No 18:08:16,816 18:08:37,246 20,430 18:08:37,497 20,681 18:08:37,387 18:08:37,427 18:08:42,508 18:08:43,986 01,478 27,17014 No 18:09:19,454 18:09:38,226 18,772 18:09:38,408 18,954 18:09:38,289 18:09:38,327 18:09:43,421 18:09:45,974 02,553 26,52015 No 18:11:32,098 18:11:50,762 18,664 18:11:50,939 18,841 18:11:50,821 18:11:50,860 18:11:55,958 18:11:57,296 01,338 25,19816 No 18:12:35,630 18:12:56,630 21,000 18:12:56,822 21,192 18:12:56,720 18:12:56,757 18:13:01,844 18:13:03,346 01,502 27,71617 No 18:13:40,759 18:14:02,238 21,479 18:14:02,773 22,014 18:14:02,313 18:14:02,393 18:14:02,766 18:14:03,161 00,395 22,40218 No 18:14:37,045 18:14:55,982 18,937 18:14:56,159 19,114 18:14:56,039 18:14:56,084 18:15:01,193 18:15:02,527 01,334 25,48219 No 18:15:58,175 18:16:17,692 19,517 18:16:17,925 19,750 18:16:17,769 18:16:17,860 18:16:22,933 18:16:24,606 01,673 26,43120 No 18:17:51,663 18:18:12,970 21,307 18:18:13,240 21,577 18:18:13,036 18:18:13,169 18:18:18,257 18:18:24,971 06,714 33,30821 No 18:18:45,767 18:19:06,567 20,800 18:19:06,775 21,008 18:19:06,647 18:19:06,690 18:19:11,769 18:19:12,072 00,303 26,30522 No 18:20:23,833 18:20:41,107 17,274 18:20:41,331 17,498 18:20:41,187 18:20:41,233 18:20:46,342 18:20:47,274 00,932 23,44123 No 18:22:16,025 18:22:36,819 20,794 18:22:37,229 21,204 18:22:36,935 18:22:36,983 18:22:42,059 18:22:43,260 01,201 27,23524 No 18:23:15,357 18:23:34,695 19,338 18:23:34,907 19,550 18:23:34,764 18:23:34,813 18:23:39,919 18:23:41,253 01,334 25,89625 No 18:24:14,985 18:24:36,215 21,230 18:24:36,432 21,447 18:24:36,313 18:24:36,355 18:24:41,435 18:24:42,697 01,262 27,71226 No 18:25:10,740 18:25:31,176 20,436 18:25:31,429 20,689 18:25:31,327 18:25:31,363 18:25:36,445 18:25:37,461 01,016 26,72127 No 18:26:18,575 18:26:36,996 18,421 18:26:37,210 18,635 18:26:37,069 18:26:37,142 18:26:42,246 18:26:43,243 00,997 24,66828 No 18:27:03,854 18:27:21,484 17,630 18:27:26,800 22,946 18:27:21,650 18:27:21,687 18:27:26,782 18:27:33,212 06,430 29,35829 No 18:27:57,422 18:28:15,247 17,825 18:28:15,406 17,984 18:28:15,297 18:28:15,338 18:28:20,495 18:28:21,549 01,054 24,12730 No 18:28:53,442 18:29:12,821 19,379 18:29:13,034 19,592 18:29:12,913 18:29:12,957 18:29:18,043 18:29:19,691 01,648 26,24931 No 18:29:45,202 18:30:06,527 21,325 18:30:06,795 21,593 18:30:06,604 18:30:06,640 18:30:11,800 18:30:14,059 02,259 28,85732 No 18:31:12,472 18:31:33,122 20,650 18:31:33,291 20,819 18:31:33,173 18:31:33,219 18:31:38,309 18:31:39,973 01,664 27,50133 No 18:32:20,598 18:32:40,229 19,631 18:32:40,495 19,897 18:32:40,293 18:32:40,332 18:32:45,506 18:32:47,005 01,499 26,40734 No 18:33:40,059 18:33:58,742 18,683 18:33:58,932 18,873 18:33:58,810 18:33:58,863 18:34:03,942 18:34:04,315 00,373 24,25635 No 18:35:24,639 18:35:45,138 20,499 18:35:45,571 20,932 18:35:45,236 18:35:45,326 18:35:50,428 18:35:52,387 01,959 27,74836 No 18:36:25,490 18:36:43,297 17,807 18:36:43,760 18,270 18:36:43,353 18:36:43,415 18:36:48,996 18:36:50,164 01,168 24,67437 No 18:38:53,446 18:39:16,104 22,658 18:39:16,485 23,039 18:39:16,168 18:39:16,216 18:39:21,351 18:39:21,632 00,281 28,18638 No 18:39:58,838 18:40:17,525 18,687 18:40:17,865 19,027 18:40:17,585 18:40:17,628 18:40:22,700 18:40:24,267 01,567 25,42939 No 18:41:14,503 18:41:36,681 22,178 18:41:36,897 22,394 18:41:36,772 18:41:36,817 18:41:41,918 18:41:43,277 01,359 28,774
69
Table B.8: In to Checking-out times (2).# Mov? Out of range Stop de-
tectionOut ofrange delay(s)
Saved loca-tion
LocationDelay (s)
Statechanged
State visible Sent check-out
Receivedcheck-out
Communicationtime (s)
TOTAL(s)
40 No 18:42:17,699 18:42:38,149 20,450 18:42:38,354 20,655 18:42:38,216 18:42:38,277 18:42:43,363 18:42:45,720 02,357 28,02141 No 18:43:01,716 18:43:19,753 18,037 18:43:20,054 18,338 18:43:19,823 18:43:19,956 18:43:25,075 18:43:26,206 01,131 24,49042 No 18:44:04,151 18:44:20,321 16,170 18:44:20,524 16,373 18:44:20,392 18:44:20,444 18:44:25,531 18:44:28,070 02,539 23,91943 No 18:45:04,351 18:45:22,998 18,647 18:45:23,376 19,025 18:45:23,059 18:45:23,105 18:45:28,388 18:45:29,866 01,478 25,51544 No 18:46:08,960 18:46:28,838 19,878 18:46:29,014 20,054 18:46:28,901 18:46:28,946 18:46:34,030 18:46:35,346 01,316 26,38645 No 18:47:13,712 18:47:30,589 16,877 18:47:30,836 17,124 18:47:30,631 18:47:30,665 18:47:35,843 18:47:37,131 01,288 23,41946 No 18:48:00,718 18:48:19,199 18,481 18:48:19,381 18,663 18:48:19,262 18:48:19,306 18:48:24,388 18:48:25,433 01,045 24,71547 No 18:50:40,977 18:51:00,436 19,459 18:51:00,693 19,716 18:51:00,466 18:51:00,588 18:51:05,713 18:51:07,176 01,463 26,19948 No 18:51:59,911 18:52:18,549 18,638 18:52:18,719 18,808 18:52:18,599 18:52:18,646 18:52:23,736 18:52:25,960 02,224 26,04949 No 18:52:49,113 18:53:10,979 21,866 18:53:11,230 22,117 18:53:11,061 18:53:11,112 18:53:16,238 18:53:16,521 00,283 27,40850 No 18:53:58,492 18:54:16,965 18,473 18:54:17,243 18,751 18:54:17,041 18:54:17,087 18:54:22,256 18:54:23,368 01,112 24,87651 No 18:55:35,174 18:55:55,803 20,629 18:55:55,982 20,808 18:55:55,863 18:55:55,905 18:56:00,986 18:56:01,283 00,297 26,10952 No 18:56:19,871 18:56:37,317 17,446 18:56:37,532 17,661 18:56:37,416 18:56:37,450 18:56:42,530 18:56:43,618 01,088 23,74753 No 18:58:55,168 18:59:15,515 20,347 18:59:15,887 20,719 18:59:15,579 18:59:15,624 18:59:20,882 18:59:22,024 01,142 26,85654 No 19:08:35,177 19:08:52,868 17,691 19:08:53,069 17,892 19:08:52,943 19:08:52,991 19:08:58,110 19:08:59,636 01,526 24,45955 No 19:09:29,697 19:09:50,671 20,974 19:09:50,968 21,271 19:09:50,734 19:09:50,776 19:09:55,975 19:09:57,096 01,121 27,39956 No 19:10:26,590 19:10:44,189 17,599 19:10:49,489 22,899 19:10:44,253 19:10:44,391 19:10:49,489 19:10:55,816 06,327 29,22657 Yes 19:15:58,472 19:16:18,924 20,452 19:16:11,667 13,195 19:16:18,967 19:16:19,101 19:16:27,513 19:16:27,801 00,288 29,32958 Yes 19:27:23,203 19:27:41,781 18,578 19:27:39,313 16,110 19:27:42,012 19:27:42,053 19:27:43,619 19:27:44,018 00,399 20,81559 Yes 16:41:43,685 16:42:02,771 19,086 16:42:00,309 16,624 16:42:02,832 16:42:02,870 16:42:04,573 16:42:04,850 00,277 21,16560 Yes 16:44:13,180 16:44:34,517 21,337 16:44:31,666 18,486 16:44:34,589 16:44:34,652 16:44:35,972 16:44:36,275 00,303 23,09561 Yes 17:12:02,410 17:12:21,799 19,389 17:12:22,403 19,993 17:12:21,861 17:12:21,915 17:12:26,862 17:12:27,229 00,367 24,81962 Yes 17:42:44,347 17:43:04,332 19,985 17:43:02,947 18,600 17:43:04,395 17:43:04,473 17:43:07,430 17:43:07,910 00,480 23,56363 Yes 17:45:28,705 17:45:49,287 20,582 17:45:48,761 20,056 17:45:49,327 17:45:49,368 17:45:53,116 17:45:53,956 00,840 25,25164 Yes 17:47:23,612 17:47:43,960 20,348 17:47:45,789 22,177 17:47:44,029 17:47:44,076 17:47:50,084 17:47:50,443 00,359 26,83165 Yes 17:53:16,377 17:53:36,897 20,520 17:53:39,627 23,250 17:53:36,954 17:53:37,020 17:53:43,971 17:53:44,358 00,387 27,98166 Yes 17:56:41,284 17:57:01,787 20,503 17:57:00,500 19,216 17:57:01,941 17:57:01,981 17:57:04,750 17:57:05,236 00,486 23,95267 Yes 18:07:42,464 18:08:03,334 20,870 18:08:02,561 20,097 18:08:03,402 18:08:03,442 18:08:06,792 18:08:07,218 00,426 24,75468 Yes 18:11:25,959 18:11:45,880 19,921 18:11:46,619 20,660 18:11:45,958 18:11:46,004 18:11:50,981 18:11:51,310 00,329 25,35169 Yes 18:12:22,363 18:12:43,212 20,849 18:12:42,922 20,559 18:12:43,254 18:12:43,302 18:12:47,246 18:12:49,064 01,818 26,70170 Yes 18:21:52,255 18:22:13,590 21,335 18:22:10,893 18,638 18:22:13,675 18:22:13,737 18:22:15,411 18:22:15,788 00,377 23,53371 Yes 18:24:46,606 18:25:06,415 19,809 18:25:06,222 19,616 18:25:06,453 18:25:06,493 18:25:10,524 18:25:10,982 00,458 24,37672 Yes 18:27:27,138 18:27:47,706 20,568 18:27:46,512 19,374 18:27:47,744 18:27:47,788 18:27:51,110 18:27:51,438 00,328 24,300
Average (no movement): 19,647 20,112 01,529 26,016Average (with movement): 20,258 19,166 00,495 24,738
Average: 19,787 19,895 01,292 25,999
70
Table B.9: Checking-out to Out/Near times (1).Checking-out—>Out/Near
# Summary show Button clicked / Timeout State changed State visible TOTAL (s)
1 15:54:13,948 15:54:17,186 15:54:17,340 15:54:17,456 00,2702 16:49:02,459 16:49:05,180 16:49:05,343 16:49:05,416 00,2363 16:49:59,375 16:50:01,043 16:50:01,268 16:50:01,314 00,2714 16:51:11,410 16:51:12,780 16:51:12,922 16:51:12,988 00,2085 17:42:19,610 17:42:24,407 17:42:24,513 17:42:24,671 00,2646 17:43:03,697 17:43:05,549 17:43:05,670 17:43:05,739 00,1907 17:44:34,165 17:44:40,509 17:44:40,794 17:44:40,852 00,3438 17:45:19,756 17:45:20,946 17:45:21,180 17:45:21,241 00,2959 17:46:01,546 17:46:02,888 17:46:03,045 17:46:03,116 00,228
10 18:06:06,457 18:06:11,520 18:06:11,771 18:06:11,849 00,32911 18:06:56,132 18:07:02,903 18:07:03,003 18:07:03,072 00,16912 18:07:46,431 18:07:56,463 18:07:56,539 18:07:56,610 00,14713 18:08:44,085 18:08:47,515 18:08:47,841 18:08:47,904 00,38914 18:09:46,047 18:09:56,083 18:09:56,230 18:09:56,298 00,21515 18:11:57,448 18:12:01,205 18:12:01,299 18:12:01,457 00,25216 18:13:03,457 18:13:13,501 18:13:13,584 18:13:13,665 00,16417 18:14:03,268 18:14:13,316 18:14:13,603 18:14:13,667 00,35118 18:15:02,625 18:15:04,325 18:15:04,630 18:15:04,689 00,36419 18:16:24,688 18:16:34,712 18:16:34,869 18:16:34,972 00,26020 18:18:25,163 18:18:28,937 18:18:29,075 18:18:29,136 00,19921 18:19:12,184 18:19:19,473 18:19:19,567 18:19:19,634 00,16122 18:20:47,477 18:20:57,515 18:20:57,654 18:20:57,751 00,23623 18:22:43,359 18:22:46,120 18:22:46,254 18:22:46,345 00,22524 18:23:41,356 18:23:51,412 18:23:51,479 18:23:51,541 00,12925 18:24:42,819 18:24:48,092 18:24:48,165 18:24:48,230 00,13826 18:25:37,556 18:25:39,005 18:25:39,183 18:25:39,251 00,24627 18:26:43,371 18:26:45,136 18:26:45,243 18:26:45,310 00,17428 18:27:33,328 18:27:35,330 18:27:35,404 18:27:35,466 00,13629 18:28:21,677 18:28:29,885 18:28:30,026 18:28:30,172 00,28730 18:29:19,794 18:29:23,765 18:29:23,986 18:29:24,043 00,27831 18:30:14,134 18:30:16,149 18:30:16,314 18:30:16,374 00,22532 18:31:40,083 18:31:50,280 18:31:50,380 18:31:50,435 00,15533 18:32:47,101 18:32:49,514 18:32:49,635 18:32:49,699 00,18534 18:34:04,544 18:34:06,287 18:34:06,383 18:34:06,461 00,174
71
Table B.10: Checking-out to Out/Near times (2).# Summary show Button clicked / Timeout State changed State visible TOTAL (s)
35 18:35:52,465 18:35:54,214 18:35:54,328 18:35:54,477 00,26336 18:36:50,301 18:36:59,341 18:36:59,454 18:36:59,524 00,18337 18:39:21,736 18:39:26,346 18:39:26,524 18:39:26,578 00,23238 18:40:24,394 18:40:34,574 18:40:34,639 18:40:34,702 00,12839 18:41:43,389 18:41:48,471 18:41:48,554 18:41:48,656 00,18540 18:42:45,829 18:42:48,605 18:42:48,816 18:42:48,894 00,28941 18:43:26,462 18:43:28,485 18:43:28,642 18:43:28,708 00,22342 18:44:28,169 18:44:37,994 18:44:38,072 18:44:38,146 00,15243 18:45:29,944 18:45:32,396 18:45:32,579 18:45:32,636 00,24044 18:46:35,442 18:46:45,465 18:46:45,641 18:46:45,718 00,25345 18:47:37,232 18:47:39,598 18:47:39,736 18:47:39,818 00,22046 18:48:25,516 18:48:26,973 18:48:27,100 18:48:27,171 00,19847 18:51:07,399 18:51:17,423 18:51:17,483 18:51:17,666 00,24348 18:52:26,039 18:52:36,086 18:52:36,213 18:52:36,274 00,18849 18:53:16,620 18:53:26,647 18:53:26,730 18:53:26,797 00,15050 18:54:23,471 18:54:26,989 18:54:27,306 18:54:27,377 00,38851 18:56:01,410 18:56:05,655 18:56:05,739 18:56:05,808 00,15352 18:56:43,907 18:56:53,934 18:56:54,004 18:56:54,179 00,24553 18:59:22,145 18:59:24,449 18:59:24,743 18:59:24,810 00,36154 19:08:59,723 19:09:02,941 19:09:03,241 19:09:03,406 00,46555 19:09:57,195 19:09:58,678 19:09:58,768 19:09:58,839 00,16156 19:10:55,899 19:11:02,961 19:11:03,070 19:11:03,180 00,21957 19:16:27,893 19:16:29,588 19:16:29,683 19:16:29,960 00,37258 19:27:44,214 19:27:46,557 19:27:46,676 19:27:46,885 00,32859 16:42:04,933 16:42:06,041 16:42:06,138 16:42:06,197 00,15660 16:44:36,370 16:44:40,905 16:44:41,005 16:44:41,079 00,17461 17:12:27,352 17:12:28,986 17:12:29,295 17:12:29,357 00,37162 17:43:08,008 17:43:18,065 17:43:18,202 17:43:18,268 00,20363 17:45:54,095 17:46:04,135 17:46:04,200 17:46:04,268 00,13364 17:47:50,519 17:47:53,092 17:47:53,212 17:47:53,307 00,21565 17:53:44,489 17:53:54,646 17:53:54,740 17:53:54,805 00,15966 17:57:05,317 17:57:15,366 17:57:15,544 17:57:15,625 00,25967 18:08:07,390 18:08:17,491 18:08:17,638 18:08:17,701 00,21068 18:11:51,400 18:12:01,449 18:12:01,570 18:12:01,646 00,19769 18:12:49,206 18:12:59,254 18:12:59,335 18:12:59,405 00,15170 18:22:15,981 18:22:26,022 18:22:26,083 18:22:26,152 00,13071 18:25:11,162 18:25:21,208 18:25:21,279 18:25:21,350 00,14272 18:27:51,671 18:28:01,718 18:28:01,790 18:28:01,887 00,169
Average: 00,228
72