Transcription
Mobile Ticketing System For Public Transport Based OnBluetooth Low EnergyJoão Guilherme Cardoso Serra MartinsThesis to obtain the Master of Science Degree inInformation Systems and Computer EngineeringSupervisor(s):Prof. José Manuel da Costa Alves MarquesEng. Hugo Miguel de Jesus BichoExamination CommitteeChairperson: Prof. João Emílio Segurado Pavão MartinsSupervisor: Prof. José Manuel da Costa Alves MarquesMember of the Committee: Prof. Luís Manuel Antunes VeigaNovember 2017
ii
AcknowledgmentsFirst of all I would like to thank my supervisors Prof. José Alves Marques and Eng. Hugo Bicho, fortheir knowledge and experience, who have offered me the necessary accompaniment to perform a greatwork. 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 ofmy life. They gave me motivation to never give up, and happiness in the most difficult moments. Evenfailing with my presence in so many events, they have always demonstrated affection and I would like toshare all my success with them.Finally, to all my family, father, mother and sister, for all the love and sacrifice so that I could alwaysgive my best. All I am is thanks to them, and every contribution I may make in this world will always betheir contribution. Thanks for everything.iii
iv
ResumoOs sistemas de bilhética para transportes públicos têm evoluı́do, de acordo com as mais recentestecnologias, de forma a fornecer uma melhor experiência de viagem aos passageiros. A maioria dossistemas de bilhética utilizam tecnologias que requerem muitas interações manuais por parte dos passageiros. Entretanto, os smartphones têm ganho cada vez mais aceitação, e as suas potencialidadespodem ser exploradas na área dos transportes. Isto leva-nos ao Mobile Ticketing, permitindo utilizar ossmartphones para viajar nos transportes públicos.Propomos um sistema de bilhética implı́cito baseado em Bluetooth Low Energy para viajar em transportes públicos. Este sistema deteta a presença de passageiros dentro do veı́culo, utilizando a tecnologia BLE disponı́vel nos smartphones. A precisão na deteção de passageiros é crucial para a aceitaçãopor parte das companhias de transportes públicos e por parte dos passageiros.Este trabalho aborda questões relacionadas com a computação móvel como o desempenho, o consumo de bateria, a segurança e a conectividade. Também tem preocupações relacionadas com Mobile Ticketing, como o método de cálculo de tarifas e o processo de validação. Um protótipo coma implementação discutida foi desenvolvido e testado, com resultados comprovativos do potencial dasolução.Palavras-chave: Bilhética, Mobile Ticketing, Smartphone, Bluetooth Low Energy, TransportePúblicov
vi
AbstractTicketing systems for public transport have evolved, according to the latest technologies, to provide abetter travel experience for passengers. Most of the ticketing systems use technologies that require a lotof 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, allowingto use our mobile phones to travel in public transport.We propose an implicit ticketing system based on Bluetooth Low Energy when travelling on publictransport. Our system detects the presence of passengers inside a public transport vehicle, using BLEtechnology available on mobile phones. The accuracy in passenger detection is crucial to the acceptance by the public transport companies and passengers.This work addresses mobile computing issues like performance, battery consumption, security andconnectivity. It also concerns about mobile ticketing topics as the fare calculation method and the validation process. A prototype with the discussed implementation was developed and tested, with resultsthat prove the potential of the solution.Keywords:Mobile Ticketing, Ticketing System, Smartphone, Bluetooth Low Energy, PublicTransportvii
viii
ContentsAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .iiiResumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiiiList of Figuresxv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii1 Introduction11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.2 Topic Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Related Work52.1 Ticket acquisition and storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.2 Ticket payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.3 Ticket fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.3.1 Fixed amount per journey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.3.2 Distance travelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.3.3 Source/Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.3.4 Zones crossed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.4 Ticket validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.4.1 Conventional method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72.4.2 Check-in only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.4.3 Check-in/Check-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.4.4 Walk-in/Walk-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.4.5 Check-In/Be-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.4.6 Be-in/Be-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92.5 Ticket inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92.6 Communication technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92.6.1 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10ix
2.6.2 Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102.6.3 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102.7 Previous projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122.7.1 ALLFA (2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122.7.2 Esprit (2005/2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142.7.3 Johannes Kepler University (2014-Actuality) . . . . . . . . . . . . . . . . . . . . . .162.7.4 Link Consulting Summer Internship (2016) . . . . . . . . . . . . . . . . . . . . . .183 Implementation213.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233.2.1 Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233.2.2 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263.2.3 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273.2.4 Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283.3.1 Fraud and failure cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294 Mobile Application314.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314.1.1 Login/Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314.1.2 Charging money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324.1.3 State visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334.1.4 Trip history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354.1.5 Inspection mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364.2 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374.2.1 Counting beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374.2.2 Location and movement recognition . . . . . . . . . . . . . . . . . . . . . . . . . .394.2.3 Communication with back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404.3 State machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Back-end Server435.1 User registration and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .445.2 Fare calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .445.3 Trip log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465.4 Transport route and stops database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Evaluation496.1 Travelling simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .496.2 Obtained results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51x
6.3 Battery consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Conclusions54557.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Bibliography59A Table with comparison between previous projects61B Time Measurements63xi
xii
List of Tables3.1 Carris (Lisbon) bus dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256.1 Metrics collected in each state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51A.1 Comparison of features between previous projects . . . . . . . . . . . . . . . . . . . . . .61B.1 Out to Near times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63B.2 Out to Near times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64B.3 Near to In times (when not detecting movement in check-in) (1). . . . . . . . . . . . . .65B.4 Near to In times (when not detecting movement in check-in) (2). . . . . . . . . . . . . .66B.5 Near to Checking-in times (when detecting movement in check-in). . . . . . . . . . . . . .67B.6 Checking-in to In times (when detecting movement in check-in). . . . . . . . . . . . . . . .68B.7 In to Checking-out times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69B.8 In to Checking-out times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70B.9 Checking-out to Out/Near times (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71B.10 Checking-out to Out/Near times (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72xiii
xiv
List of Figures2.1 Overview of the ALLFA system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . .142.2 Overview of the Esprit system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . .152.3 Overview of the Johannes Kepler University system architecture. . . . . . . . . . . . . . .172.4 State Machine Diagram of Link Consulting Project. . . . . . . . . . . . . . . . . . . . . . .183.1 Overview of the proposed system architecture. . . . . . . . . . . . . . . . . . . . . . . . .223.2 Components and their relationships of the proposed solution. . . . . . . . . . . . . . . . .243.3 Beacon deployment diagram in a Carris standard bus. . . . . . . . . . . . . . . . . . . . .253.4 Beacon deployment diagram in a Carris articulated bus. . . . . . . . . . . . . . . . . . . .264.1 Registration window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324.2 Near state window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334.3 In state window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344.4 Summary dialog window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354.5 Trip history window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364.6 Map window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364.7 Inspection mode window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374.8 Beacon regions example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384.9 Implementation State Machine diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . .415.1 Communication exchanged in registering process. . . . . . . . . . . . . . . . . . . . . . .455.2 Communication exchanged in travelling process. . . . . . . . . . . . . . . . . . . . . . . .475.3 Entity model of transport route and stops database. . . . . . . . . . . . . . . . . . . . . .486.1 Test scenario diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .506.2 State transitions graph with average durations. . . . . . . . . . . . . . . . . . . . . . . . .526.3 Checking-in to In times graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .536.4 In to Checking-out average duration graph. . . . . . . . . . . . . . . . . . . . . . . . . . .54xv
xvi
AcronymsAPI 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 1Introduction1.1MotivationPublic transport systems have centuries of history and have gone through many changes, providingbetter 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 ofticketing only started recently. Early systems were based on paper tickets, usually bought on site. Withthe technological advances, ticketing systems began to provide better services to passengers in orderto meet their needs. Nowadays it is possible to verify seat availability, as well as reserve and purchasea 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 affordableto the masses, what enables public transport providers to explore new ways of help users to purchaseand carry electronic tickets using their smartphones, introducing a mobile ticketing approach. Mobileticketing is the process whereby customers can reserve, purchase and/or validate tickets using mobilephones 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 toeveryone carrying a smartphone throughout the day, becoming a fundamental need for humanity. In thisdigital era it very common for the public transport providers to have a digital form of the ticket, allowingto carry it on the smartphone or tablet. This digital capability also allows the transportation providers toinspect travelling patterns, and therefore to adjust the provided services, for example, the organisationduring rush hours or less frequented areas, which led to an improvement in the efficiency, makingpossible to lower the cost for the customers. Mobile ticketing is designed to enable a more convenientpublic transport experience. Users can avoid long lines to buy a ticket, as well as the inconvenience ofholding a ticket or a card between stations. Instead, the passengers can purchase tickets through theirmobile phones and use the information stored to access public transports. From the providers’ side, itallows 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 commissions1
paid to distributors.All check-in/check-out actions taken in just one trip are a time-consuming task, especially if there isa flaw in the reading, which could lead to pay too much or less for the journey. However, these actionsare very relevant to public transport companies, once they provide information about the service occupation. This way, it is essential not only to reduce the check-in/check-out actions but also to provide theinformation 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 following the principle that enables people to implicitly interact with a technical system to make a transparentcheck-in/check-out. Passengers may enter and leave public means of transport without the need topresent the ticket. It only needs to carry a mobile phone that, communicating with the public transportvehicle devices, automatically takes care of billing for the journey.1.2Topic OverviewMobile ticketing systems are commonly implemented based on active Radio Frequency Identification (RFID) [1, 2, 3]. However, to explore all the capabilities of the smartphones, as an alternative andpotentially more powerful technology, Bluetooth Low Energy (BLE) is proposed. With the first BLE standard defined in 2010, this technology evolved in the low-power short-range data transfer. The BLE hasbeen 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 latesttechnologies. Users can acquire and validate their tickets in an automated way using a daily device, thesmartphone. This solution eliminates many time-consuming tasks as obtaining tickets at vending storesand 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 newmobile ticketing system. This project stands out for its deploying simplicity because it is not necessary tohave an on-board computer to process the check-in/out information. It only needs to deploy a set of BLEbeacons inside the public transport vehicle and a client-side smartphone application. This applicationperforms all the necessary processing, including the communication to a central server. The development of this mobile ticketing system is within this master’s thesis. However, it has not only academiccontent but can also be deployed in a real public transport operator infrastructure.1.3ObjectivesAccuracy in passenger detectionOne of the main goals is to achieve a good accuracy when detecting a passenger on board. It isimperative to avoid false positives, charging people that are not really on board, or false negatives, notbilling passengers that completed a journey. The reliability of the detection is crucial to the acceptance2
of the service by the stakeholders since the system must not lead to a monetary loss for customersneither 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 itis covered, for example), or other constraints. If a user owns a right ticket, it should be charged, and if auser is in the vehicle illegally should be detected by an inspector. The accuracy of the detection dependson the quality of the communication established between the mobile device and the beacons inside thevehicle.Ease of useThe system should facilitate the public transportation experience. One of the main goals is to providethe passenger with an easier way of travel in a public transport vehicle, without using more devices thanusual. The system must simplify the entire process of acquiring a ticket. It should be as simple as buyinga ticket using the smartphone, wait for the vehicle inside a station, enter the vehicle, travel, and exit thevehicle at another station. The system automatically calculates the fare of the journey and charges itfrom the user account.Battery consumptionSmartphone 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 protocol. Communication is the main source of battery drain and should be controlled. Connection intervalscan be tuned specifically to develop a system with low energy consumption without losing accuracy. Theuse of our system should not drain the battery significantly throughout the day, being possible to use italong with the typical applications.Security and privacySince wireless communication happens at open air, everyone can eavesdrop the communication orimpersonate a legit device. Issues like these means that security and privacy measures have to be takento prevent abuse of the system. The traveller’s privacy must be ensured and never be tracked by anotherperson. Also, there should not be possible to erase or change data from the mobile device, to deceivethe system to pay less for a journey. These occurrences should be detected and prevented with securemechanisms, to ensure security and privacy of the data.Minimizing costsIn order to provide a great solution to public transport companies, the system should consist in just afew 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 bedetected by the smartphone. One of the major innovations of this project is that there is not necessaryan on-board computer.3
Multi deviceThe system should be available in every smartphone whatever its capabilities, except BLE and GlobalPositioning System (GPS). The application has to be available to all users that carry a smartphoneindependent of the manufacturer or technology. As a BLE-based system, it needs BLE, that can befound 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 in2012, and Windows Phone 8.1 in 2014. Many of platform updates for earlier phones has been releasedand are now ready to use. Although our prototype being developed in Android, this does not mean thatis platform specific, and similar solutions for other platforms can be developed.1.4Thesis OutlineThe remainder of the document is organised as follows. Chapter 2 provides a background on themobile ticketing systems, referring the evolution of each related aspect. Chapter 3 presents the architecture of the solution, describing the inner workings of a prototype that implements this solution. Chapter4 explains in a more detailed way how the mobile application was developed and the technical aspectsof each functionality. Chapter 5 focuses on server implementation details, describing its structure andalgorithms used. Chapter 6 describes how the prototype was evaluated and summarises the resultsobtained. Finally, Chapter 7 concludes the document and proposes future work to improve this system.4
Chapter 2Related WorkTicketing 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 tostart a journey in public transport have evolved, not only the different ways of storing a ticket (e.g. in apaper, smartcards), but also the fare calculation methods (e.g. by travel, distance). The public transportoperators also began to develop automated ways of checking the validity of tickets carried by the usersinside a vehicle. In order to make the ticket validation more natural from the user side, new technologiesand approaches have been used, to abstract the user of this time-consuming task, but ensuring thatthe system always detects an invalid ticket. Communication is crucial for the automatized systems, andthe ways of exchanging information between ticketing system components have also improved with newtechnologies. The different approaches of the described features in ticketing systems are addressedbelow, such as the pros and cons of each one. Lastly, previous projects relevant for this case arepresented, such as their architectures and protocols, to provide an overview of a typical global system.2.1Ticket acquisition and storageIn the conventional payment system for public transport, when the user intends to travel in a specificpublic transport, he needs to buy a paper ticket in a store manually. In early systems, the user entersin a ticket store, where an assistant is selling a paper (ticket) with the source, destination and hour ofthe travel printed. It is also possible to buy a ticket inside the vehicle (on-board) [11], which is still beingused 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 sourceand destination, requiring a tariff knowledge of the service. Companies need information about routesoccupation, bus traffic, and users validations, to track the utilisation of the services and improve specificsectors, such as bus commodities, scheduling or prices. This need led us to the information era, whereevery task is registered on a log held on a computer, also helping to prove that a user has bought theticket, 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 taskof buying several tickets with the same characteristics and avoiding the disposable tickets (and physicalresources), the companies started to develop smartcards with the capacity of storing tickets. The usercan buy one of this cards in a vending store or machine, load it with several tickets and use this card tomake 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 forthe 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 shorttext message, or even using an application Near Field Communication (NFC) or BLE-based to establishcommunication between devices and readers.2.2Ticket paymentThe 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 monthand have free access to the public transport, avoiding the time-consuming task of buying a ticket everytime the user wants to make a journey. Usually, this periodic pass is cheaper than purchasing a ticket foreach trip, to make the pass more attractive for users. It also allows public transport companies to havea fidelity from the user side. Another possibility is to have a smartcard with a modality that functions asa purse, where the user can load it with an amount of money, and each time a journey is made, the fareis 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 havea credit card associated with a smartphone application [12]. Using an NFC-enabled smartphone ispossible to have a specific application to pay for a journey using the smartphone within the near fieldof a ticket reader or a payment station. Then smartphone application uses payment interface to chargethe journey correspondent money from the bank account. Another possibility is to have a smartphoneapplication with the feature that works like a wallet, and using NFC or other communication protocol tointeract with the reader and deduct the money.2.3Ticket faresApart from the payment method, there are several tariff calculation modes for journeys:2.3.1Fixed amount per journeyThe simplest approach is to charge a fixed amount for each travel [11], independently of the sourceor destination. This calculation is straightforward because each user that enters and e
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.
