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 introduced,
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].

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 correspondent
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.

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
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 checkout
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 ”CALYPSO”
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 Checkin/
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].

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.

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 advertisements.
_ 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 connections
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.

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 individually
or in combination: Eddystone-UID, which is the corresponding functionality of iBeacon, advertising
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.