What can you do in 300 ms?

300 milliseconds—about as long as the blink of an eye. It’s also the amount of time WMATA provides, in the specifications for their New Electronic Payments Program, for bus fareboxes and rail faregates to process a transaction and respond. But how feasible is that? What needs to be done in those 300 milliseconds, and can it be done?

One of the central aspects of an open payment system for mass transit is that it is an account-based system, rather than card-based. The card—whether it’s a contactless credit or debit card, or a specialized card issued by the transit agency—serves only as a token used to store an account number. Everything else is stored in a centralized backend. In the case of a stored-value card, this means that the card doesn’t even store its current balance. Accordingly, every device must operate in an online mode. This is the standard for rail systems, but most bus fareboxes today are designed around offline operation with periodic reconciliation when fareboxes are downloaded at the depot. For open payment to work, though, every bus farebox must have some type of wireless link. In areas with municipal Wi-Fi or WiMax networks, those networks are perfect for this application. However, few areas have municipal wireless, so instead buses will have to use commercial wireless services.

So, with commercially available wireless services, what can you do in 300 milliseconds? In my (admittedly unscientific) tests, ping times on a 3G connection tend to be around 250 milliseconds. That doesn’t leave a lot of margin. Consider that a ping packet is only 56 bytes long, while an encrypted transaction from a bus farebox is likely to be at least a few kilobytes long. Worse, that leaves almost no time for server-side processing. For a stored-value card, the processing to be done is minimal, and doesn’t require any additional queries. But for a credit or debit card, the transaction must then be handed off to a bankcard acquirer for processing. The alternative is for the backend to return an affirmative response to the farebox, while it caches the card information for later processing. This, however, creates a substantial risk for fraud, as envisioned in a question posed by a potential proposer for the NEPP: “By ‘authorizing’ a transaction in 300 milliseconds or less such authorization cannot in today’s world make the trip to the issuing bank and back again before the customer has received the ride. Who does WMATA envision will carry the risk of losses associated with these transactions and processing in this manner?”

There is also still an issue of connectivity. 250 millisecond ping times may be possible in ideal circumstances, but urban environments are bad for wireless connectivity. What about when a bus ends up in a dead zone (in which case the farebox will just fail over into an offline mode), or worse, an area with limited connectivity? This, too has been envisioned by potential proposers, one of whom asks “WMATA states a 300ms maximum transaction time performance requirement. Will WMATA please share if they have access to any wireless provider willing to provide these types of wireless capabilities with penalty for non-performance equal to what WMATA would want from a vendor?” Offline operation of an open payment system is a sub-par option; a bus farebox operating offline in an open payment system would be really hobbled. Because everything (including fare tables) is stored server-side, an offline bus farebox won’t be able to tell riders how much they’ve paid, or if they get a transfer discount, or if there’s a valid pass loaded on their card. It’ll also be powerless to signal potentially fraudulent transactions and deny boarding to those passengers.

There are two open payment systems currently operating in the US which include buses—the Utah Transit Authority, and NJ TRANSIT’s extension of the tri-agency open payment trial in New York (the trials on PATH and the subway have concluded, but NJ TRANSIT has continued their part of the trial). I would be curious to know how they have handled these issues, and what their experience has been.

One thought on “What can you do in 300 ms?”

  1. It seems to me that what is inherent in this discussion is that open payments systems are not yet able to meet transit requirements. In fact the current WMATA system performs quite a bit faster than the 300 millisecond spec requirement. Also I find the concept proposed for so called open payments to be misleading. What does open payments really mean?

Comments are closed.