Contactless Latencies

We are going to discuss here two types of latencies: UniTiAg TANB API latency and Contactless Card-Present Payments Transaction latency.  After that, we discuss latency-specific pros and cons of UniTiAg model.

For the beginning, let’s consider some latency components.

Latency Components

NFC Channel Latency (250 – 450 msec)

This latency comprises the time the contactless card reader needs to engage the contactless card into transaction, read the data that the card presents to the reader, provide the data that the cards requests from the card reader, and execute ODA.

Detailed analysis of cEMV tap latency is provided in this PCN article. You can laso measure this latency and get a gist of data flows between the card reader and the card by using our android application NFC EMV Explorer.

Wired Latency (20 msec per 1000 km)

This latency includes the time it takes for an HTTP request from the client to reach the API host and for the response to return to the client. Host processing latency is not included in this measurement and is discussed separately. Additionally, we assume a stable Internet connection between the client and host, such as wired or fiber optic infrastructure, while wireless components are addressed separately.

This latency is influenced by geographical distance, with signal propagation in fiber optics being ~5 msec per 1000 km. Real-world latency, considering DNS resolution and handshaking, is typically 15-20 msec per 1000 km or more, depending on the network infrastructure.

Wireless Latency ( 30 msec to eternity)

This latency is important for wireless validators, installed on vehicles. If the validator needs to connect to the host to send a message and receive a response via a wireless network, there will be time elapsed between sending a message to the host and receiving a response. We asume here that the host is very fast and is close to the client.

The current state of the wireless data communication technology demonstrates that the wireless latency can be as low as 30 msec. This latency is demonstrated if a wireless network has nothing else to do at that moment. We will treat this value as a low limit.

Unfortunately, the upper limit can not be determined. It could be up to several seconds or even minutes. Nobody knows how the wireless system will behave if there are several thousand bus validators hammering the network with two requests per second at the rush time. Nobody knows how  the cellular system will behave if there are many phone calls, SMS, or emails at the same time in a specific region. Current open-loop pilot projects run relatively small number of open-loop transactions via wireless channels and there is no reliable empiric data.  The situation is even worse: there cannot be reliable statistical data or estimates of that kind obtained because of many unpredictable influential factors impacting the wireless data system throughput.

Host Latency (20-70 msec)

The computer host will require some time to process the requests. We should reasonably allow at least 20 msec to process a request and prepare the response.  We do not count here the time the host needs to “talk” to some other systems such as Visa or MasterCard.

Authorization Latency (150 msec – 5 sec)

This latency is applicable for payments transaction. It includes time the Point-of-Sales would need to obtain the card issuer authorization through a payment scheme network.  As UniTiAg does not process and does not require TAs to process card-present payment transactions, this latency is not applicable to the UniTiAg model.

Cumulative Latency of TANB API cal “Get OTRB”

Let’s consider the following scenario. The Validator, engages the card in cEMV transaction, retrieves the data further required to process the fare (not a payment transaction) in UniTiAg SaaS and makes a request for the OTRB data associated wit this card, via TANB API call “Get OTRB”.

The minimum and maximum cumulative latency values, separately for Wired Validators and Wireless Validators are presented in this illustrative table.

Latency (msec)NFC Channel Wired component (0 – 5000 km)HostWireless componentTotal for Wired ValidatorTotal for Wireless Validator
Min25002030270300
Max45010070Not possible to say620Not possible to say

As we can see from this table, the wired validator, when it is close enough to the Regional UniTiAg host, and when it is connected to this host via fast Internet infrastructure, can achieve reasonably low “Get OTRB” latency. As to wireless validators, they would require the OTRB data pre-downloaded into their local memory which can be achieved by the TANB API call “Sync OTRBs”.

If  the wired validator is too far from the Regional UniTiAg Host, an efficient approach would be for TA to have its own ABT system host and periodically sync OTRB data with the Regional UniTiAg Host using TANB API call “Sync OTRBs”. The validators will request OTRB data from the TA host using an ABT proprietary APIs.

Cumulative Latency Of Card-Present Contactless Payment Transaction

The following tables represent the estimates for the time required if the card issuer authorization approval message needs to be obtained

Wired Validator – Full Authorization

Latency (msec)NFC ChannelTA HostIssuer ApprovalTotal
min25070150470
max450100050006450

Additional Latency for Wireless Validator

min30
maxnone can be guaranteed

Maximal Allowed Transit Tap Latency

The reasonable tap latency in transit environment must not exceed  in average 350-500 msec at subway turnstile and 500 – 1000 msec at bus validator.

This explains why the validator cannot wait for the card issuer authorization before granting access to the transit service. Waiting for the issuer response would impact the transit systems’ throughput and patron experience.

UniTiAg’s ticketing model, based on the OTRB concept and TANB API, offers a low-latency solution for transit authorities, ensuring a risk-free fare validation process.