Mobile Ticketing System For Public Transport Based On

Bluetooth Low Energy

Joao Guilherme Martinsjoao.g.c.s.martins@tecnico.ulisboa.pt

Instituto Superior Tecnico, Lisboa, Portugal

October 2017

Abstract

Ticketing systems for public transport have evolved, according to the latest technologies, toprovide a better travel experience for passengers. Most of the ticketing systems use technologies thatrequire a lot of manual interactions from passengers. Meanwhile, smartphones have gained increasingacceptance, and their potentialities can be exploited in the transport area. This brings us to MobileTicketing, allowing to use our mobile phones to travel in public transport. We propose an implicitticketing system based on Bluetooth Low Energy when travelling on public transport. Our systemdetects the presence of passengers inside a public transport vehicle, using BLE technology availableon mobile phones. The accuracy in passenger detection is crucial to the acceptance by the publictransport companies and passengers. This work addresses mobile computing issues like performance,battery consumption, security and connectivity. It also concerns about mobile ticketing topics as thefare calculation method and the validation process. A prototype with the discussed implementationwas developed and tested, with results that prove the potential of the solution.Keywords: Mobile Ticketing, Ticketing System, Smartphone, Bluetooth Low Energy, Public Transport

1. Introduction

Public transport systems have gone through manychanges, providing better conditions to passengersin order to meet their needs. Nowadays it is possi-ble to verify seat availability, as well as reserve andpurchase a ticket online. The time-consuming taskof acquiring a ticket is becoming easier and moreintuitive, therefore less and less a barrier to publictransport.

The adoption of mobile phones has become sowidespread, and mobile Internet access affordableto the masses. This enables public transportproviders to explore new ways to purchase and carryelectronic tickets using smartphones, introducing amobile ticketing approach. Mobile ticketing is theprocess whereby customers can reserve, purchaseand/or validate tickets using smartphones or othermobile handsets. It is becoming the future of ticket-ing in public transport, allowing passengers to buytickets in advance and from anywhere. From theproviders side, it allows them to gain insight intothe behaviour of the system, providing improve-ments according to usage. All check-in/check-outactions taken in just one trip are time-consumingtasks. However, these actions are very relevant tothe companies, once they provide information aboutthe service occupation. This way, it is essential not

only to reduce the check-in/check-out actions butalso to provide the information required for the op-erators to study possible improvements in the sys-tem.

Therefore, we propose an alternative to the tra-ditional methods, to implicitly interact with a tech-nical system to make a check-in/check-out, simplifythe validation process. Passengers may travel with-out the need to present the ticket. It only needsto carry a daily device - the smartphone - which,communicating with the vehicle devices, automat-ically takes care of billing for the journey. Blue-tooth Low Energy (BLE) is available in every mod-ern smartphone, and its capabilities can be exploredto develop a passenger detection system that can beused in a new mobile ticketing system. This projectstands out for its deploying simplicity because it isnot necessary to have an On-Board System (OBS)to process the check-in/out information. It onlyneeds to deploy a set of BLE beacons inside the ve-hicle and a client-side smartphone application. Thisapplication performs all the necessary processing,including the communication to a central server.

1.1. Objectives

One of the main goals is to achieve a good accu-racy when detecting a passenger on board. It

1

is imperative to avoid charging people that are noton board, or not billing passengers that completeda journey. The reliability of the detection is crucialto the acceptance of the service by the stakeholderssince the system must not lead to a monetary lossfor customers neither for public transport compa-nies.

The system should facilitate the public trans-portation experience, providing the passenger withan easier way of travel in a public transport vehi-cle. It should be as simple as buying a ticket usingthe smartphone, wait for the vehicle, enter it, travel,and exit at another station. The system automati-cally calculates the fare of the journey and chargesit from the user account.

It is crucial that the system achieves a low en-ergy consumption. Communication is the mainsource of battery drain and should be controlled.Connection intervals can be tuned specifically to de-velop a system with low energy consumption with-out losing accuracy.

Since wireless communication happens at openair, everyone can eavesdrop the communication orimpersonate a legit device. Issues like these meansthat security and privacy measures have to betaken to prevent abuse of the system.

In order to provide a great solution to publictransport companies, the system should consist injust a few changes in the infrastructure.

And finally, the system should be availablewhatever smartphone capabilities, except BLEand Global Positioning System (GPS). Althoughour prototype being developed in Android, similarsolutions for other platforms can be implemented.

2. Related Work

Each public transport operator has a tariff methodaccording to its business model. The ticket farecan be a fixed amount per journey, independentlyof the source or destination. Regarding the loca-tion awareness, it can be calculated based the dis-tance travelled; or on the number of stations withinentrance and exit stations; or aggregating severalstations in zones and calculate using the number ofzones crossed by the passenger [7].

Concerning about ticket validation mechanisms,one of the most basic ways is the check-in only, inwhich the user has to present the ticket at the en-trance. Check-in/Check-out (CICO) method, needsthe user to explicitly presents the ticket at a reader,when entering and exiting [9]. There are more tech-nological approaches like Check-in/Be-out (CIBO),where the check-in is explicitly made but the sys-tem automatically detects that the user exited thevehicle, and finally Be-in/Be-out (BIBO), a hands-free scheme that detects the presence of a deviceinside/outside a vehicle automatically [6, 10, 8].

When using electronic fare management, thecommunication between tickets and readers is cru-cial. BLE is a wireless technology that exchangesdata over a short distance using radio transmissions,using low bandwidth and low latency, providing avery energy efficient communication [4]. It followsactive RFID approach, although coupled with bat-tery on the tag side. Active RFID systems are suf-fering a gradual replacement by BLE [2]. Nowa-days every recent released mobile phone has BLEsupport.

BLE beacons consist of small devices that peri-odically broadcasting Bluetooth signals containingprogrammable information [5].

ALLFA was the first big innovative fare manage-ment system tested in a real environment. It detectspassengers inside vehicles using special electroniccards or mobile phones. These devices contain a ra-dio frequency communication interface, which com-municates with the antennas installed inside the ve-hicles. There are two types of antennas: ”wake-up”antennas, that sends an initial wake-up signal tothe ALLFA ticket, and an access antenna to com-municate with the OBS [6, 3]. All data transmittedfrom the ticket to the OBS is also transmitted to aremote system. The fare is calculated centrally andoffline in this back-office system [3].

”Esprit” is a BIBO solution based on an elec-tronic user device, with a radio-based communica-tion interface. The vehicle is equipped with an OBSthat controls the data that is sent to the user de-vices through an antenna. This computer also sendsall the information to a remote back-office server[6]. When the passenger enters in a public trans-port vehicle, the computer broadcasts a signal toall users inside the vehicle to activate the user de-vices from the sleep mode. When inside the vehicle,the user device is periodically receiving informationwith enough information to calculate the fare [6].

Johannes Kepler University’s investigation teamin Austria aims to develop a BIBO system, whichincludes a user side BLE beacon or a BLE-enabledsmartphone, an OBS controlling the communica-tion with the user device and with a remote server.The user device broadcasts its unique ID when en-tering the vehicle, which is received by the OBS.In order to accurately detect the presence of thepassengers, OBS performs scheduled BLE scans toremove ambiguousness. Capturing a BLE deviceat all scans indicates the presence of a passengerinside. When the scan does not detect the useranymore, then his trip is over.

Link Consulting started a project with aim on theautomatic detection of user position relative to thebus, using BLE and location services. This projectuses BLE beacons, deployed inside the public trans-port vehicles, to interact with the mobile user de-

2

vice. When the user is outside the vehicle, the ap-plication is scanning for beacons. When it detectsa set of beacons from the same bus, it turns on thelocation and starts recognising if the passenger ismoving, using the smartphone GPS. When app doesnot detect enough beacons from the same bus, theuser should have exited the bus, and it is checked-out. Since this master thesis is supported by LinkConsulting, some of the ideas used in this projectwere adopted in the development of our system.

3. Implementation

We developed a mobile ticketing platform for publictransport, proving the viability of using BLE bea-cons in this domain. In our solution, the user ownsa BLE-enabled smartphone with the developed ap-plication installed. A set of BLE beacons are de-ployed inside public transport vehicles. Beaconshave unique identifiers that indicate which vehiclethey belong. The app detects user presence inter-acting with the beacons, through BLE. GPS andsmartphone sensors are also used to detect move-ment and location, helping on the fare calculation.

This system combines BIBO and CIBO. It uses a”check-in” perspective because the user has to man-ually confirm their presence inside the vehicle press-ing a button in the app. However, this check-in canbe made at the passenger seat. The need of a check-in action is detected when the passenger is near thevehicle, so the system can detect that the user isinside the vehicle, introducing the ”be-in” concept.The check-in action is necessary to eliminate doubtsabout the user presence inside the vehicle. The sys-tem is also able to detect that a user is outside thevehicle, experiencing the ”be-out” idea. To performthese detections, we use BLE technology, due to itsadvantages, as referred in section 2.

With our architecture is the mobile applicationthat detects the beacons and communicates the in-formation, through mobile operator internet or us-ing the vehicle Wi-Fi, to a back-end server thattakes care of all processing. Therefore it is not nec-essary an OBS to control the passenger detection orto communicate with the server. This is an advan-tage to public transport operators since it avoidsa huge modification in the public transport infras-tructure.

3.1. Architecture

In Fig. 1 are represented the modules that composethe system and the relationships between them. Inthe mobile app the user can check the current state,i.e. if is far or near a vehicle, or if a trip is currentlyin course or it is already finished. The app can alsoshow the past trips and generate validation codes.It does not store sensible information, such as de-tailed user information or vehicles routes. All thisdata is controlled by the back-end that also per-

forms the sensible tasks like fare calculation, charg-ing money and management of every trip informa-tion.

Figure 1: Components and their relationships of theproposed solution

Inside the vehicle, we have a set of BLE beacons.As we are using as example the case of Carris (Lis-bon) public transport, we made a study of theirbus dimensions, in order to conclude which wouldbe the best configuration for beacons interval timeand broadcasting power, as well as the configura-tion of the beacon set inside the vehicle [1].

We used Estimote R©Proximity Beacons (hard-ware version G1.8 and firmware version 4.9.1).These beacons can either operate in iBeacon orEddystone protocols, but we used iBeacon due toits simplicity and documentation abundance. Toachieve a good balance between detection reliabil-ity and battery consumption, we decided to use aBroadcasting Power of -20dBm (approximate rang-ing of 4 meters) and an Advertising Interval of500ms, which allows a battery lifetime of approx-imately 18 months.

With this values well defined, we found the bestway to deploy a set of beacons inside a typical vehi-cle of Carris: 12m length and 2,5m width for stan-dard models. The configuration example for a stan-dard model can be observed in the scale Figure 2.The blue dots represent the beacon, and the bluecircles represent the range of the beacons. The cir-cles become darker when they intersect each other.We ensure that the disposition of beacons must besuch that within the vehicle area it is always pos-sible to detect at least two beacons with the sameidentifier.

Using iBeacon protocol we have three differ-ent values to define: Universally Unique Identifier(UUID), major and minor. This way we can setdifferent values for each service. We use UUID todefine all the beacons that are used in the applica-tion. Then, we have major associating each beaconto a different public transport operator. Finally, mi-nor values differentiate the vehicles from the same

3

Figure 2: Beacon deployment diagram in a Carrisstandard bus

operator.

Smartphone’s GPS is responsible for detectingthe source and destination stations of the trip. The”check-in” button pressed inside a vehicle triggersGPS to register the current location as the originstation, to use in fare calculation. Then GPS isturned off to save battery. When the beacons arenot detected anymore, the GPS is turned on againto store the destination station, and the trip is over,and GPS is turned off.

The traveller is responsible if the ticket is notchecked-in because the smartphone is out of bat-tery, no GPS signal or without internet connection,or also if the check-in button was not pressed whenentering the vehicle. When an inspector enters thevehicle to check the validity of the passenger tick-ets, the passenger has to generate a Quick Response(QR) code. To do this, the user clicks on ”inspec-tion” button, that automatically shows a code con-taining the user information and current trip data.Then, the inspector can read the code and confirmthe validity of the traveller’s journey.

The back-end is responsible for storing all thesystem information, as well as perform the morecompute-intensive tasks. It contains information ofall users; a journey history with all the trip events(check-in, updates and check-out); route and sta-tions information; and is responsible for calculatingthe fare of each trip performed. Its features will bedescribed in Section 5.

3.2. Assumptions

As this project has a main focus on the accuratedetection of passengers, therefore some of the capa-bilities of the system are not going to be explored,allowing greater flexibility in future when contin-uing the development of the project. To simplifythe system and to give priority to the most cru-cial points, the following assumptions are made: weassume internet availability in all smartphonesand inside every public transport vehicles, whethervia on-board vehicle Wi-Fi or through mobile op-erator data; although there are different possibili-ties to calculate the fare due to system flexibility,we assume a station-based fare, where the priceis determined according to the number of stations

crossed by the passenger; in this implementationdue to time constraints the payment system in-tegration will not be addressed.

4. Mobile ApplicationWe developed an Android application to test andprove that the project is feasible.

4.1. FeaturesTo start using the application, the user needs toperform a registration. To identify the user, weuse the phone number, since it is unique, so thereis no possibility of ambiguity. Besides, is requireda password to protect the account.

If when the user submits the information, it isaccepted by the back-end, then returns a random4-digit code. This code ideally is sent by a ShortMessage Service (SMS). However, due to the diffi-culty of access to free SMS system, this message issimulated as a pop-up message in the app with thegenerated code. If the user enters the received codeand it matches the generated user, then can chargethe account with money and start travelling.

If the current balance is not higher than the min-imum fare, the application does not allow to starta new trip. Therefore, at any time the user cancharging money, in a quick task where only hasto choose the amount to charge, fill the tax infor-mation (if required), and submit.

The main feature of this mobile application is thestate visibility of the user at any time. The stateshave different behaviour and representation, withdistinct colours and figures that made the state easyto distinguish. Here we present the five states inwhich the application can operate:

• Out: No beacons are found. Neither check-innor check-out can be made, so the user can-not interact with the state. GPS is turned off,in order to reduce energy consumption. Thisstate is represented in red, with a figure of auser far from a vehicle.

• Near: Minimum number of beacons from thesame vehicle is found. GPS and activity recog-nition is turned on, so it is possible to detectmovement and register the current location.In this state, we can see which vehicles arebeing identified, as we can observe in Figure 3.The user can choose in which vehicle are goingto enter. Otherwise, the application selects thenearest (using RSSI). Pressing the ”Check-inbutton” triggers the entrance transition. The”Near” state is represented in dark blue, witha figure of a user at a bus stop, as shown inFigure 3.

• Checking in: Not also the minimum numberof beacons of the same vehicle are detected but

4

Figure 3: Near state window.

also movement, through the GPS or ActivityRecognition module. Therefore the user mustpress the ”Check-in button” to confirm that isinside the vehicle. This state is represented inorange, with a user entering a bus.

• In: When the user press the ”Check-in but-ton”, the application enters in this state. Thelocation is stored and also a list of every possi-ble bus to check-in, in case the bus automati-cally was chosen was not the right one. Whilethe application is detecting the minimum num-ber of beacons, GPS is turned off to reduce bat-tery consumption because it is not necessaryduring the journey. The ”In” state is repre-sented in green, with a user inside a bus.

• Checking out: When the application stopsdetecting the minimum number of beacons ofthe current vehicle, it enters in this state. Herethe application checks if any alternative buseshave been detected since the entrance in whichit was also possible to check in. If yes, the ap-plication updates the current bus and entersagain into the ”In” state. Otherwise, the jour-ney is finished, and a summary is shown, withthe entrance and exit information, as well asthe cost. After showing the summary (whetherthe user presses the button or the timeout of10 seconds expires), the application transits to”Out” state, trying to detect new beacons. Ifthe application is running in background, thesummary is not shown, and the applicationtransits fast.

At any time it is possible to check the trip his-tory with all the travels that were made by thecurrently logged user, as we can see in Figure 4. Inthis window, we can observe dates of check-in andcheck-out, the travelled bus, and the entrance andexit stations. When the user clicks on a trip of thislist, a map is shown with marks in all the stationswithin that journey. We can observe an examplein Figure 5. A green marker indicates the entrancestation; the red marker shows the exit station and

all the yellow markers are the stops performed bythe vehicle during the journey. It is also possibleto generate inspection codes for each trip, at thespecific inspection button.

Figure 4: Triphistory window.

Figure 5: Map win-dow.

App has an inspection mode that generates avalidation code for a travel. This is need when aninspector enters the vehicle to check if all passen-gers have a valid ticket. When within a journey,there is an ”Inspection button”, that shows a QuickResponse code. This code contains the user identi-fication token, the beacon identification that is de-tected by application, and the identification tokenof the relevant trip. To implement this feature, weused ZXing, an open-source barcode image process-ing library implemented in Java.

4.2. Solution architectureA region can be described as the entire area reach-able 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 definedusing only UUID, UUID + major or UUID + major+ minor. We defined a UUID to relate beacons toour application and a major value associated withall Carris vehicles.

There are two distinct methods for apps to in-teract with regions and beacons within a region:monitoring, which triggers actions when a deviceis entering/exiting the range of beacons defined bythe region; and ranging, where actions are triggeredaccording to the proximity to a region, indicating ifthe device is immediate, near or far from that re-gion. It is important to know that once the beaconis out of range, it still takes to the mobile opera-tive system up to 30 seconds to truly recognise thatfact. This built-in, non-adjustable delay is there toprevent false ”exit” events, like when a crowd tem-porarily obstructs the beacon, and it stops beingdetectable for a few seconds.

The monitoring task is not always detecting en-tering and exiting occurrences. It is defined basedon two values: the scan period and the interval be-tween scans. We set the values to perform 2 secondsscanning with 10 seconds of interval, which gives us

5

a good balance between battery consumption andexpected results, based on tests conducted. Aftermonitoring task detect the presence inside the re-gion, ranging task count the number of occurrencesfor each minor. Ranging is also defined based on thescan period value and the interval between scans.We set the values to perform ranging scans with2 seconds duration and with intervals of 2 secondstoo.

The app shows a notification to check-in if is de-tecting the required number of beacons and iden-tifies movement. To identify movement a servicetracks the user movement, considering that the useris moving aboard if three conditions are simulta-neously reunited: the beacons of that vehicle arebeing detected for more than the minimum detec-tion time (15 seconds); if movement is being trackedfor more than the minimum threshold (10 seconds);and if the average speed of the user matches a ve-hicle speed (assuming that a minimum of a vehicleis about 21.6 km/h).

Notice that activity recognition and movementdetection is only used to identify that a check-inis required to notify the user to do it. If the useris inside the vehicle and the application does notdetect activity/movement, it is always possible toperform a check-in, and the user should do it.

Every sensible information is computed andstored in back-end side, to guarantee that thereare no inconsistencies or fraud. This includes in-formation about the user, travels or vehicle trans-port routes; and tasks like the translation betweenbeacon identification to its respective vehicle, farecalculation or balance charging.

The back-end is implemented in order to pro-vide its services through a REST (RepresentationalState Transfer) architecture style. To consume theservices provided by the back-end, we use Retrofit,a REST client for Android (and Java).

4.3. State machineTravel processing is controlled by a state machinedependent on several factors, that can be observedin Figure 6.

1. The application starts in the ”Out” state.When it starts detecting the minimum numberof beacons (2) with the same identification, ittransits to ”Near” state. Otherwise, it stays in”Out” state.

2. While it is detecting the minimum number ofbeacons it stays in ”Near”. If at any point, theapplication detects that the user is moving, us-ing the activity recognition, the current loca-tion is stored. Then, if the user has a positivebalance, the application changes to ”CheckingIn” state. Otherwise, the application does notallow to check-in and warns the user to charge

Figure 6: Implementation State Machine diagram.

it. Clicking on ”check-in button” transits di-rectly to ”In” state. Although it only changesto this state after storing the current location.If the minimum number of beacons are notbeing detected the application goes to ”Out”state.

3. In ”Checking In” state, the current locationis always getting stored with four seconds ofinterval. This state is waiting for the user topress the check-in button, in order to change to”In” state, indicating the beginning of a jour-ney. When the button is clicked, the ”check-In” process begins, in which the applicationcommunicates to the back-end not only thecurrent location but also the beacons being de-tected. The back-end returns the identificationnumber of that journey. Again, if no beaconsare detected transits to ”Out” state.

4. When ”In” it is only possible to change to state”Checking Out” when the minimum beacons ofthe bus in which the check-in was made, andthere are no alternatives to update the check-in. If the application stopped detecting thecurrent bus beacons but continues to detect thebeacons from an alternative bus, it starts the”Update Check-in” task, communicating it tothe back-end. Notice that it does not indicatethat the user changed from one bus to another,but that the initial check-in was made in thewrong bus.

5. When in ”Checking Out” state, the current lo-cation is stored in order to communicate it tothe back-end, along with journey and user iden-tifications, to perform the ”Check-out” andchange to ”Out” state. This is an automatictransition that has not related conditions. Inback-end side, the amount to pay for the com-plete journey is calculated, and it is deductedfrom the user balance.

6

5. Back-end server

We developed a back-end that should be managedby the public transport operator. This server cancontrol all information about the system, such asjourneys and users. It is possible to the opera-tor to make adjustments to its services based onthe information held by the back-end, like vehicleroute modifications or even changing the fare cal-culation. To do this, it is connected to a transportbuses and route database that has the informationabout all the vehicles in transit and what their pos-sible routes.

5.1. Features

Each user has an account, in which is stored thepersonal information, trip history and balance. Allusers are identified by their phone number, whichis unique and personal. A password protects eachaccount, to prove that the person who is trying touse the application is who claims to be. When theuser is making the registration in the application,is necessary to fill a form with the personal informa-tion and send to the back-end. If all data is valid,the back-end generates a random 4-digit code thatreturns to the application. When the user correctlyinserts this code, will obtain a unique token thatidentifies the user in each future communication.

One of the main focus of the back-end server isto calculate how much to pay for a journey. Thefare calculation is based on the following steps:

1. Identify the bus in which the passenger is trav-elling. Then, get that bus route, which includesall the stations it stops from the origin to thedestination.

2. Identify the entrance location stored in thecheck-in information. Then, compare each sta-tion coordinates with the user location whenthe check-in was performed, to select the near-est station. Comparing all bus route stationswith check-in location, the minimum distanceobtained refers the nearest station from wherethe check-in was performed, therefore the en-trance station to use in the calculation.

3. After that, we need to know the exit stationof the travel. Now we just have to comparethe check-out location with the stations in theroute that follows the already selected entrancestation.

4. Finally, as we have already obtained the sta-tions of entry and exit, we can now count thenumber of stations between them and calculatethe price to pay for the trip.

Although it is possible to choose any fare cal-culation method, in this prototype we are using astation-based method. In this calculation, we use a

fixed price for starting a trip plus a fixed price foreach number of intermediate stations.

Back-end server is responsible for storing everytrip that is made using the system. It is importantto record trip logs with every relevant informa-tion. During a journey, there are three importantmoments in which is important to record the appli-cation context: when the application starts detect-ing a minimum number of beacons from the samebus, it is necessary to translate the beacon identifi-cation to the correspondent bus number.

1. When the check-in button is pressed, the appli-cation sends the user token, to identify whichuser is starting the journey, the identificationof the beacons in which is checking-in, a list ofbeacon IDs of all other possibilities to check-in,and finally the current latitude and longitude.The back-end creates a new journey entry withthis received information, generates an identi-fication of this journey entry and returns it tothe application.

2. When the application stops detecting the min-imum number of beacons of the given beaconID in the check-in, it will verify if any of the al-ternatives are being identified. If yes, an ”Up-date check-in” is performed, in which the ap-plication sends the journey identification to saywhich trip is being updated, as well as the co-ordinates (latitude and longitude) of the pointin which this update is performed. The back-end returns the journey identification to con-firm that the update was done.

3. Finally, when no more beacons are being de-tected, the applications performs a ”Check-out”, and sends the journey identification thatis being finished, the user token to identify thepassenger and the current location (latitudeand longitude) where the check-out is done.The back-end calculates the price to pay forthe travel and returns the new user balance,and a journey summary with the check-in andcheck-out dates, the cost of the finished trip,the bus number and the list of stations crossedwithin the travel.

It is essential for the back-end to have full knowl-edge about all the stations, buses and routes ofthe public transport operator. Regarding this is-sue, we implemented a transport route andstops database with information of several sta-tions, buses and routes of Carris, our use case forthis prototype. This database have three main enti-ties: Stop, represented by its coordinates and name,which is identified by a unique code; Line, whichhas a unique name and indicates the correspondentbus, the destination station and direction; and fi-

7

nally LineStop, which connects the other two enti-ties, indicating the stops that constitute a line.

6. EvaluationThe evaluation of this work focuses on measuringthe times of the system critical tasks, such as en-trance and exit detection times; the differences be-tween the internal state transitions; and the visi-bility of the new state to the user. We found thisvalues indicative of the system performance since itallows to verify some failure cases, related to thedetection reliability. Notice that the values in thisevaluation were obtained in a simulation environ-ment and not in a real public transport vehicle.Therefore, the times collected are approximate tothe real-time operation of the system.

We decided to perform tests in a room largeenough to include the standard bus dimensions anda margin for the user to move inside/outside thebeacon range. In this test case, the bus remainsstill and is the user who moves away from the ”ve-hicle” (beacon range). We used the standard busdimensions, and the beacons were placed with thesame configuration as inside a standard bus. Threedifferent users were invited to participate in the testset. The smartphone used to perform the tests wasan LG L90 D405 (Android 5.0.2 Lollipop, API 21)with a 2540mA battery.

Users could perform travels in two modes: click-ing in ”check-in button” when in ”Near” state; orsimulating movement using a third-party applica-tion to simulate the navigation between two pointson the map, and finally clicking on ”check-in but-ton” when our application detected movement. Weused an app called ”Mock Locations (fake GPSpath)” developed by Dvaoru, to simulate the po-sitions.

An auxiliary button (”Simulation button”) inthe application was created for the user to warnwhen left the room (passing through the door),and therefore move out from the beacon range, tocalculate the delay compared to the time detectedby the application. Each user was asked to simulatea journey, depending on the mode and accordingto the following steps:

• Not simulating movement (Experiment 1):

1. Move away from the beacon range (wait forstate ”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 door5. Wait for the end of the journey (state

”Checking-out”) and confirm the summaryshown or wait for the timeout.

• Simulating movement (Experiment 2):

1. Move away from the beacon range (wait forstate ”Out”)

2. Move inside the beacon range (wait for state”Near”)

3. Open auxiliary app (”Mock Locations”) andinitiate stored simulation. Return to our ap-plication and click ”simulation button” to in-dicate that the movement has initiated (waitfor 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 door6. Wait for the end of the journey (state

”Checking-out”) and confirm the summaryshown or wait for the timeout.

6.1. Obtained resultsAfter setting up the test environment and providingthe experiment instructions to users, 72 travels weresimulated: 56 using the process of Experiment 1, inwhich is not detected movement before the check-in, and 16 following the instructions of Experiment2, in which the movement is mocked using the aux-iliary application. We decided to test this differenceto verify if there is a delay between checking-in whenentering the bus or checking-in when already insidethe bus and moving, waiting for application check-in warning due to motion detection.

First, we calculated the average duration of everytransition for each experiment and elaborated thegraph shown in 7.

Figure 7: State transitions graph with average du-rations.

As we can observe, transitions ”Out to Near”, ”Into Checking-out” and ”Checking-out to Out/Near”have similar values in both experiments. The dif-ference between the two testing processes is at thecheck-in moment, so only the transitions that in-clude the ”Checking-in” state are affected. There-fore, as we can see, in Experiment 1, transition”Near to Checking-in” takes much less time than inExperiment 2. In contrast, transition ”Checking-in to In” takes almost twice (180%) as long as inExperiment 2. This difference is due to the delaycaused by the motion detection in Experiment 2.

The graph in Figure 8 specifically shows the timespent on each task of transition ”Checking-in to In”,

8

we can see that in Experiment 1, the duration isdue to the location delay. This value is the timespent between the last position saved and the mo-ment when the check-in information is sent to theback-end. This delay may be caused by the intervalbetween each collection be set for 4 seconds, whichis a reasonable value that does not compromise thefare calculation.

In experiment 2, there is a movement detectiondelay of 05,313 seconds that affect the total tran-sition duration. This delay causes an increase of04,942 seconds in relation to the first experiment.Notice that the movement detection only verifies ifit is necessary to warn the user that a check-in mustbe performed, so it is possible to check-in as soonas the user is near the vehicle (as in experiment 1).On the other hand, when checking-in, as soon as weobtain the location, the more accurate is the stationselection, therefore the fare calculation. We foundthis value acceptable, as long as it provides a moreprecise calculation in exchange of an average delayof fewer than 5 seconds presenting the state to theuser that is not forced to wait since it is possible tocheck-in when in ”Near” state.

Communication delay is the difference betweensending the check-in information and the responsefrom the back-end. This value depends on the in-ternet bandwidth, so the value is similar in bothcases with an average value of 00,841 seconds.

Figure 8: Checking-in to In times graph.

Observing again Figure 7 we can conclude thatthe transition that takes most of the time is ”In toChecking-out”. We can observe each task durationof this transition in Figure 9.

Figure 9: In to Checking-out average durationgraph.

The time spent in this transition is also influencedby the location delay. However, in this case, the lo-

cation delay is much higher, with average values of19,947 seconds. This increase is due to the out ofrange delay up to 30 seconds, that is associated withthe beacon protocol to avoid false positives whenmonitoring exits from beacon region area, as al-ready mentioned in section 3.1. Therefore, we mea-sured an average delay of 19,820 seconds betweenthe moment the user moves out from the beaconsand the moment detected by the beacon protocol.As the application recognises it later, the locationis also obtained later. This value can compromisethe fare calculation since it can lead to the differ-ence between two stations, and therefore the systemmay harm or benefit the user. Also, users have towait almost 20 seconds to verify in the applicationthat the check-out was performed, which leads toconfusion, as the participants in the test informed.However, this item can be solved adapting the op-erator business model to accept a margin, i.e. sincethe location is obtained too late, discount one sta-tion (margin), for example. Other solution wouldbe to use another beacon protocol that avoids thisdelay related to false positives. We did not triedanother protocol, e.g. Eddystone, due to lack ofdocumentation to solve our issues.

6.2. Battery consumption

During the test battery, we used an application tomonitor the battery consumption. Two hours ofan intensive usage running on a smartphone with2540 mA battery, resulted in a battery usage of138,4 mAh, which represents 5,45%/h. During 4hours detecting beacons but without performingany travel, we observed a battery usage of 12,5mAh, which indicates less than 0,05%/h. Thesevalues indicate that the application has a low bat-tery consumption, allowing an intensive usage ofapproximately 18 hours on a regular smartphone.

7. Conclusions

One of the main problems when using public trans-port is the time-consuming tasks of acquiring tick-ets, checking-in/out tickets or inspector validation.This led us to look for a solution that allows to re-duce these waits, simplifying all the travel process.Also, the usage information of the public transportservices is essential for the operator and nowadaysis not easy to monitor their traffic based on the cur-rent statistics. Our solution suggests a global visu-alisation of the public transport service, providinginformation about the past and current travels.

After a deep analysis of the current market andthe related projects being matured in this area,we identified some flaws that could be improved.Therefore, we found our opportunity to embrace thechange and help provide a mobile ticketing solution,location-aware and based on BLE beacon technol-ogy. One of the main innovations of our approach

9

is that the mobile application is responsible for co-ordinating the beacon detection and sending thetravel information to the back-end, without need-ing any other device. It only needs beacons, whichare cheap, have their own power supply (battery)and are very easy to deploy.

The work presented had to deal with mobile com-puting issues, such as memory requirement, batteryconsumption, interactivity, connectivity, and secu-rity. As we are faced with a mobile application fora smartphone, it is essential to ensure its interop-erability, i.e. that the application is able to runon any smartphone. Although the prototype hasbeen developed for Android, all of the functional-ities used are also available on any other platformdevelopment kit.

To evaluate the performance of our system wemeasured the time consumed by each process per-formed by the app, to verify if the results were ac-ceptable in this context. We found most of the val-ues satisfactory, with acceptable delays that do notcompromise the correct system behaviour. How-ever, the checking-out duration caused by the bea-con protocol monitoring should be reduced to detectwith more accuracy the exit station of the travel.

The developed system allows to reduce user inter-action when travelling inside public transport vehi-cles, providing a new and simpler travel experienceusing a daily device such as the smartphone. Be-sides that, operators can obtain real-time statisticsof the system behaviour, allowing them to adapttheir services to the user needs. Our solution meetsthe initially proposed goals, with some innovationand a progression margin for improvements.

8. Future Work

The present work consists of a prototype that issusceptible to improvement since there is still someissues that can be deeply developed in this context.

It would be profitable to provide an external APIto access some services of the back-end, allowingusers to manage their account, for example. Thisway, it would be possible to develop a portal inwhich users could check their trip history or chargetheir account. Also, it would allow to build ap-plications to monitor operator resources (vehiclesoccupation, users currently travelling, etc.)

To confirm the benefits of the system, it wouldbe better to perform more tests to validate thesolution, especially to the location accuracy, bat-tery consumption. But most importantly, the testsshould be made in a real environment, inside a realvehicle with some users generating interferences, togive a better overview of system operation.

Although some of the leading security concernsbeing addressed in this work, like the crucial infor-mation decoupling from the mobile application, it is

important to issues need more attention. In a realdeployment of a system like the described, shouldbe necessary to have more security concerns like theauthenticity of users, preventing an intruder to im-personate other user and perform travels withoutpaying, using the other user’s identification.

References[1] Carris. Frota. (Accessed: 2017-06-10).

[2] G. Conte, M. D. Marchi, A. A. Nacci, V. Rana,and D. Sciuto. Bluesentinel: a first approachusing ibeacon for an energy efficient occu-pancy detection system. In editor, editor,BuildSys ’14: Proceedings of the 1st Associa-tion for Computing Machinery Conference onEmbedded Systems for Energy-Efficient Build-ings, pages 11–19, Nov. 2014.

[3] Fraunhofer Institute for Transportation andInfrastructure Systems IVI. ALLFA Ticket.(Accessed: 2016-11-10).

[4] J. Leal, R. Couto, P. Costa, and T. Galvo. Ex-ploring ticketing approaches using mobile tech-nologies: Qr codes, nfc and ble. In IEEE 18thInternational Conference on Intelligent Trans-portation Systems, pages 7–12, Sept. 2015.

[5] J. Lindh. Bluetooth low energy beacons. Appli-cation report, Texas Instruments Incorporated,Oct. 2016.

[6] H. Lorenz, D. T. Grndel, P. W. Tomlinson,K. Philipp, and J. Acklam. Be-in-be-out pay-ment systems for public transport. Report, UKDepartment for Transport, July 2009.

[7] M. Mezghani. Study on electronic ticketing inpublic transport. Report, European Metropoli-tan Transport Authorities, May 2008.

[8] W. Narzt, S. Mayerhofer, O. Weichselbaum,S. Haselbck, and N. Hfler. Be-in/be-out withbluetooth low energy: Implicit ticketing forpublic transportation systems. In IEEE 18thInternational Conference on Intelligent Trans-portation Systems, Sept. 2015.

[9] W. Narzt, S. Mayerhofer, O. Weichselbaum,S. Haselbck, and N. Hfler. Bluetooth lowenergy as enabling technology for be-in/be-out systems. In 13th IEEE Annual Con-sumer Communications & Networking Confer-ence, Jan. 2016.

[10] W. Narzt, S. Mayerhofer, O. Weichselbaum,G. Pomberger, A. Tarkus, and M. Schumann.Designing and evaluating barrier-free travel as-sistance services. In HCI in Business, Gov-ernment, and Organizations: Information Sys-tems, pages 434–445, July 2016.

10