IJSART - volume 1 Issue
4 –APRIL 2015
ISSN [ONLINE]: 2395-1052
Proximity Based Protocol Development for
Local Ticket Booking
Amol Khedkar 1, Ameet Khedkar 2, Kshitij Gorde 3, Krishna Sisodia 4, Prof. S. A. Joshi 5
Department of Computer Engineering
1, 2,3,4,5
Sinhgad College of Engineering, Pune, India
Abstract- Considering the huge amount of people travelling
via local trains, it is necessary to have a scalable, reliable,
useable and sustainable framework for ticketing. Currently,
manual ticketing systems suffer from various problems; this
system is an attempt at alleviating them by using NFC on
Android for generating e-tickets. A ticket may be verified
electronically by any ticket checking staff, which is another
significant improvement for ticket validation process. Other
features provided to customers include ticket history, virtual
wallet payment and flexible travel in any train of choice within
expiry period. We present a detailed discussion of the
implementation and performance of the system in question.
Keywords- NFC, e-ticketing, encryption
I. INTRODUCTION
22 million people travel daily for distances ranging
from 10-60 kilometers using local trains. To provide a fast and
efficient framework for ticketing such a huge number of
passengers is a considerable challenge. The currently
implemented manual system issues paper based tickets on the
payment of cash, which are verified by ticket checking staff
onboard. The main disadvantages of this current system is that
passengers are required to stand in long queues which results
in wastage of time and energy. Payments are inherently
unsecure because of the use of hard cash and storage and
transferring of cash is a cumbersome process. In addition to
this, ticket validation is another manually carried out process.
In order to overcome all such disadvantages, it is necessary to
implement a secure electronic ticketing framework. Electronic
ticketing signifies using of the customer’s mobile gadget to
book, store and furnish tickets for verification.
II. LITERATURE REVIEW
A number of Android smartphones come with a set of
standards called NFC (Near Field Communication) which
allow them to communicate with other NFC hardware by
touching them or bringing them into close proximity. In NFC,
the communication occurs when two NFC compatible devices
are brought together less than four centimeters, or simply by
touching them. It operates at 13.56 MHz and can transfer data
up to 424 Kbits per second[1]. The devices involved in
Page | 16
communication are known as initiator and target. Initiator is
an active NFC device, responsible for starting the
communication. In addition, it has an embedded energy
component; the target can be either a tag, RFID card or an
NFC device which responses the initiator’s requests.[2]
Advantages of NFC:
One of the advantages of NFC technology is that
mobile devices can be used both as an information storage or
an NFC reader. They can read information from NFC tags and
display that information on the screen with an ability to make
additional processing. They can also be used as a digital
storage e.g. storing credit card information. The technology is
compatible with existing RFID structures, existing RFID tags
and contactless smart cards[3]. It is easy to use because users
don’t need to specialized know-how. All a user has to do is to
start communication by bringing two devices together. The
transmission range is short which brings inherent security and
privacy[4]. If there isn’t any other device close, there is no
other communication.
NFC Operating Modes:
1. Reader/Writer Operating Mode:
The reader/writer mode is about the communication
of an NFC-enabled mobile phone with an NFC tag for the
purpose of either reading data from or writing it to those tags.
In reader mode, the initiator reads data from a 13.56 MHz tag
or NFC tag, which consists of the requested data. In writer
mode, the mobile phone acts as the initiator and writes data to
the tag. If the tag already contains any data prior to the writing
process, it is overwritten[5].
2. Peer-to-Peer Mode
In peer-to-peer mode, two NFC-enabled mobile
phones establish a bidirectional connection to exchange
information. They can exchange virtual business cards, digital
photos, or other kinds of data[5].
3. Card Emulation Mode
In card emulation mode, the NFC-enabled mobile
phone acts as a smart card. As the user touches a mobile phone
to an NFC reader, the NFC reader initiates the communication
immediately. Thus, the mobile device operates in passive
mode whereas the tag reader operates in active mode.
www.ijsart.com
IJSART - volume 1 Issue
4 –APRIL 2015
ISSN [ONLINE]: 2395-1052
In this project, card emulation mode will be used
because the tag reader will be used as the initiator and will
read the data from the mobile device which will be acting as
the passive device[5].
Figure 3: Packet Description [7]
Figure 1: Card Emulation mode illustration [6]
The NFC tag reader acts as active device initiating
the communication and reading the data from the Secure
Element in the NFC mobile.NFC devices that are operating in
card emulation mode use similar digital protocol and analog
techniques as smart cards, and they are completely compatible
with the smart card standards. Analog is related to RF
characteristics of NFC devices and determines the operating
range of devices. Digital protocols refer to the digital aspects
of ISO/IEC 18092 and ISO/IEC 14443 standards and define
building blocks of the communication. It further specifies
methods to perform collision detection[6].
CF (Chunk Flag) is a 1-bit field which indicates that
this is either the first-record chunk or a middle-record chunk
of a chunked payload. SR (Short Record) flag is a 1-bit field
which indicates that the PAYLOAD_LENGTH field is a
single octet. The IL flag is a 1-bit field which indicates that the
ID_LENGTH field is present in the header as a single octet.
III. METHODOLOGY
In order to understand this system we have the
following block diagram:
Figure2: NDEF Packet Format
In an NDEF message, the first record is marked with
the MB (Message Begin) flag set, and the last record is
marked with the ME (Message End) flag set. The minimum
message length is one record, which you can achieve by
setting both the MB and ME flags in the same record.
Page | 17
Numbers in brackets indicate the order of events,
while the direct link from cellphone to ticket management
server (orange) is optional activity. Algorithmically, the same
process can be presented on a higher level in the format:
www.ijsart.com
IJSART - volume 1 Issue
4 –APRIL 2015
ISSN [ONLINE]: 2395-1052
IV. IMPLEMENTATION
The following technologies were used in the following roles:
Technology
MySQL
PHP
C/C++
Java
Android/NFC

Role
Store and retrieve backend data
Keep data of customers, fare, tickets
and station codes
Communicate with database for
requests, read replies and generate
tickets
Construct xml files for sending SMS
Read xml files from resending module
Spew JSON output of passenger list
Encrypt symmetrically
Access files from/push data to reader(s)
Clean up files after processing
Constructing GUI frontend
Use in Android application design and
logic
Decrypt symmetrically
Send/Receive strings containing ticket
data
Sending SMS to customer mobile

Standard method for transporting data













Figure 4: Algorithm
Some requirements kept in mind during planning were:
1. First Come First Serve method
Ticket requests must be time ordered i.e. if a
passenger’s request was received first then the ticket allotment
must be done to the passenger before processing further
requests.
2. Polling for Files
Inter-process communication is carried out via the
presence or absence of certain XML files. The directories
containing these files are well known to communicating
processes. Each process outputs some data file which is read
by waiting process and deleted to signify end of operation.
3. Data Optimization
3NF schema design is implemented to optimize query
search times. The need of specialized parsers/ readers is
eliminated by using the standardized formats of XML and
JSON.
4. Encryption
Wireless communication between TC and database
must be resistant to active as well as passive attacks.
5. Concurrency Handling
Multiple readers may generate multiple taps at the
same time, which must be serialized at a sufficiently high rate
to time order the requests (see point 1).
6. Resending of tickets
Another requirement of the framework is to
implement a non-exploitable resending module. A customer
must be allowed to request a ticket resending until a threshold
value based on time and cardinality is not reached.
Page | 18
GSM
network
XML/JSON
Encryption is achieved using the base64 encoding
after symmetrical XOR operation. The MIME text is then sent
for decryption and base64 decoding is applied to get back
original data.
JSON/XML is used for transporting over the network
layer as they are standardized formats and it is trivial to parse
data from them.
Minimum Android API level 14 (Ice Cream
Sandwich) is required to install and run the customer’s
application as well as the ticket checker’s application.
The system also requires that the customer remember
a mobile number associated with the system. This number
must be used to send resending requests of the format
“RESEND<space><customerID>”, which signifies to the
system to fetch the last transaction which occurred associated
with <customerID> and send it to the relevant mobile number.
In order to provide security against misuse of this facility, we
implement a threshold value of resending requests maintained
per customerID per month. If the customer tries to send a
request above threshold number of values, further requests are
ignored from the user for 2 days.
www.ijsart.com
IJSART - volume 1 Issue
4 –APRIL 2015
ISSN [ONLINE]: 2395-1052
V. RESULTS
REFERENCES
The following performance metrics can be observed after
implementation using sections IV and V:
[1] R. Chokngamwong, C. Techapanupreeda and S.
Kungpisdan, "“A secure lightweight protocol for NFC
communications with mutual authentication based on
limited-use of session keys”," Institute of Electrical and
Electronics Engineers, Jan. 2015.
No.
1.
Metric
Ticket Reception Time
T0=time of successful
tap
2.
Form Filling Time
3.
Total Time for booking
T0=time of successful
tap
4.
5.
Server Latency
6.
Resolution
(maximum concurrent
taps which can be
distinguished as separate
taps)
Resending Time
7.
Memory Footprint
8.
Decryption Time
(for
one
record
containing name, status,
ticket ID)
Result
Best Case: (t0+ 1.5’)
Average Case: (t0+ 3’)
Worst Case: 10” (lost
SMS)
Minimum: 12’
Maximum: 60’
Average: 36’
Best Case: t0+ 1.5’+12’
Average Case: t0+ 3’
+36’
Worst Case: 10”(lost
SMS)
(ClockFrequency)-1*2’
Where 2’ is the sampling
time for new requests
Best Case: 200
Average Case: 50
Worst Case: 2
Same
as
Ticket
Reception Time
NFC app: 1.3 Megabytes
TC app: 2 Megabytes
0.0003’
[2] C. Medaglia, A. Marino, M. Morena, S. Sposato, A.
Moroni, P. Di Rollo and M. Morgia, "“Mobile ticketing
with NFC management for transport companies. Problems
and solutions”," Institute of Electrical and Electronics
Engineers, Feb. 2013.
[3] W. Liguori and F. Palumbo, "“NFC Smart Tourist Card:
Combining Mobile and Contactless Technologies towards
a Smart Tourist Experience”," Institute of Electrical and
Electronics Engineers, June 2014.
[4] H. Aziza, ""NFC Technology in Mobile Phone NextGeneration Services”," Institute of Electrical and
Electronics Engineers, April 2010.
[5] N. H. L. Keskin, ""A low power receiver architecture for
Near Field Communication readers”," Institute of
Electrical and Electronics Engineers, April 2014.
[6] K. O. B. O. Vedat Coskun, “Professional NFC Application
Development For Android”, April 2013.
[7] E. M. H. A. I. W. Surya Michrandi Nasution, "“Prototype
Of Train Ticketing Application Using Near Field
Communication (Nfc) Technology On Android Device”,"
International Conference on System Engineering and
Technology, September 2012.
VI. CONCLUSION AND FUTURE SCOPE
In order to implement a usable platform for ticketing,
we require various resources like a dedicated SMS sending
service, auto reply e-mail service, web hosting service for preregistration and dedicated reader-server connections. In order
to gain the customer satisfaction goal of the project, a proper
implementation must ensure maximum reader installation on
all platforms. Frequent maintenance of the readers is necessary
to ensure they are functioning correctly and they must also
have an independent dedicated power supply to minimize
downtime.
The implementation in question can of course be
extended to include other non-functional requirements like
modification of customer profiles (mobile, address or email
change and their validation), behavioral profiling of customers
using data mining techniques for identifying new business
strategies and distributed architecture for geographically
distant processing.
Page | 19
www.ijsart.com