Transit Gate Evolution: why tap speed matters

As COVID restrictions are eased and the world slowly goes back to work, school and hopefully slightly more normal life, avoiding crowds will be key in keeping COVID from becoming resurgent in the months ahead.

For commuters in Japanese metro areas avoiding crowds is no easy matter. Fortunately the Japanese transit gate infrastructure is a great help. FeliCa based IC transit cards (Suica, PASMO, ICOCA, etc.) with fast transaction speeds combined with open gate flap design maximizes people flow: people walk through gates at normal pace. This is very important for Japanese stations that have to make do with large crowds in limited spaces and smaller gate areas.

It’s wrong however, to think that this only applies to Japan. The benefits of fast tap speed combined with intelligent transit gate design are relevant everywhere and very necessary in this day and age: fast gate tap speed is essential in keeping gate crowding at a minimum. It makes things safer not only for train operation, but also addresses crowd control health concerns in the COVID era.

A reader sent a link to a good discussion of NFC protocols and gate tap speeds that was apparently deleted when YouTube comments were turned off. I retyped the comment below from a screenshot with some light editing for clarity. If I find the author I’ll link to the original. The videos have already appeared in other posts but it’s good have them in one place. A previous installment already covered QR transit code gate issues, this post will focus on NFC.


While transit gates and NFC processors are found worldwide, what makes the Japanese gates different from the rest of the world is they don’t use global standard ISO 14443 (never mind Type A which uses Miller bit coding, the least efficient bit coding method) protocol which is common in many transit and bank cards issued worldwide.

The tap time with ISO 14443 Type A (née Philips) and B (née Motorola) varies greatly: from 200 to 500 milliseconds (ms) with 200 ms only achievable with Type B/Calypso. But it never reaches the short as 100 ms which is only achieved with Felica developed by Sony, also designated NFC-F and NFC Tag Type 3 by the NFC Forum and compatible with ISO 18092 which is commonly found in smartphones and NFC wearables since 2013. In this following video passengers maintain their walking pace but never overshoot and trigger a gate closure nor slow down not even a bit:

It may seem like a minor difference but due to the high volume of passengers per gate and to reduce gate maintenance requirements, tap times really matter.

Companies such as JR East have specified tap time of 200 ms but Suica is actually faster and this allows real life speed tolerances: some passengers tap faster than others due to walking pace, the higher speed tolerances are only possible with the 100 ms tap time of FeliCa. A comparison example of large crowds at gates in Malaysia and Japan below:

Open Loop NFC ticketing in its current form is based on EMVCo Contactless specifications adopted in contactless bank cards issued worldwide including China UnionPay QuickPass which is PBOC derived from the EMVCo Contactless spec. All of these use ISO 14443 Type A at 106 kbps only for 500 ms tap time, which is adopted in cities worldwide such as London, New York, Moscow and Rio de Janeiro where normal walking speed is never supported.

But as seen here, transit cards in Japan such as Suica, PASMO and ICOCA are supported for ultra hight speed and precise account verification and fare processing. Transit cards use offline Stored Fare (SF) which includes the amount of funds stored in the card’s IC smart chip data storage, NOT backend on a server like a bank card, and stored commuter passes. Here are walk flow comparisons for Tokyo and London, and MTA OMNY Open Loop performance:

Japanese IT journalist Junya Suzuki tests OMNY transit gate speed…
and reliability

One hopes the NFC Forum works to increase NFC speeds and global specifications to “improve the overall user experience for NFC users.” We shall see.

With the exception of any Apple Pay news from WWDC20, this will be my last big post for a while. Stay healthy, stay safe and have a great summer.

Advertisements

iOS 13.4: Apple Pay Suica making way for Mobile PASMO?

The iOS 13.4 update adds a few interesting UI tweaks to Wallet and Suica. On the performance front iOS 13.4 Apple Pay Suica is the same level of stability we’ve seen on every release since iOS 12.3. The UI for Suica commuter pass has changed slightly with more detail in a separate window-let just below Suica balance/recharge. The commute pass renew button is gone too, but I’m pretty sure it re-appears during the 2 week renew period. I’ll update when confirmed.

I missed a change in the beta: the JP Wallet blurb has been updated slightly too. The Suica mention has been replaced with a generic ‘Transit IC card’. This change is very interesting in light of the recent Mobile PASMO Android release. It could be a sign that Mobile PASMO will be coming to Apple Pay before iOS 14….whenever that is.

Update: some readers have questioned whether this is just a change to bring different region Wallet blurbs in line with each other. Apple Pay Wallet for Hong Kong, for example, added ‘Travel Cards” in iOS 13.0 even though Apple Pay Octopus has yet to appear. But region differences are still there: transit IC cards, travel cards, transit cards. Suica has massive brand recognition in Japan. Apple has leveraged the Suica brand at every opportunity and would not swap it for generic wording lightly, not without a very good reason: more transit IC cards. There is also timing. Mobile PASMO started service March 18, just as iOS 13.4 GM was going out to developers. If it was just a text change, Apple would have done this earlier with the iOS 13.0 debut.

Mobile PASMO Q&A

What is Mobile PASMO?
Mobile PASMO is an app service, identical to Mobile Suica, for Android v6 Osaifu Keitai devices or later. Users can recharge a virtual PASMO card on the device with a registered credit card, purchase or renew commute plans, view use history, restore the PASMO card from the cloud in case of a lost device, PASMO bus transit users can also earn ‘Bus Toku’ points. Mobile PASMO launched March 18. Details are listed on the Mobile PASMO site (Japanese only).

Is it compatible with Google Pay? (Updated)
Not at this time. Users need to be careful: active Google Pay blocks Mobile PASMO transactions. Bank cards are limited to Mobile PASMO app registered credit cards: American Express, JCB, Mastercard, Visa. Credit card registration is processed by PASMO and seems to be the weakest part of the system where users are experiencing the most trouble (the rest of the system appears to be licensed Mobile Suica IT assets). Only Japanese issue cards are accepted.

Is the Mobile PASMO app multi-lingual? (Updated)
Everything is Japanese language only. Android users can download the Mobile PASMO app on Google Play.

Can I use Mobile Suica and Mobile PASMO on the same device? (Updated)
Only 6 recent Osaifu Keitai Type 1 devices support multiple transit card installs. On older Type 2 devices you can only install one and have to choose. As FeliCa Dude explains in his excellent Reddit post, “Mobile PASMO: the “me-too” that’s all about them, and not you” the Mobile FeliCa Android stack on older FeliCa chip devices isn’t like Apple Pay and does not support multiple transit cards or the ability to select one for Express Transit. Type 1 devices updated to Osaifu Ketai 8.2.1 can set one (and only one) ‘main card’ for Express Transit use, with Mobile Suica and Mobile PASMO on the same device. Here is a full device list of Type 1 (Mobile Suica and Mobile PASMO), Type 2 (Mobile Suica or Mobile PASMO), Type 3 (Mobile Suica).

I have a Mobile PASMO capable Type 2 device, which mobile transit service should I use?
It all comes down to commuter pass use, if you live in the Suica/PASMO region and use a JR East line on any part of your commute, Mobile Suica is the best choice that gives you the most options on Apple Pay and Google Pay. If you do not use a JR East line as part of your commute, Mobile PASMO is the natural choice.

Will Mobile PASMO be coming to Apple Pay? (Updated)
iOS 13.4 has some indications that Mobile PASMO might be coming at some point. Mobile PASMO uses licensed Mobile Suica assets and technology, the backend is very similar with a different operator. Apple Pay Wallet does have the ability to host multiple transit cards and select one for Express Transit. In theory a user could have a Suica and a PASMO together in Wallet. We’ll have to wait and see if the PASMO group has enough cloud resources to plug into Apple Pay/Google Pay and how willing they are to deal with non-JP issue credit cards.

Isn’t next generation ‘2 cards in 1’ Suica supposed to fix this? (Updated)
Mobile PASMO throws cold water on the one big happy mobile transit family concept of next generation Suica: sharing resources instead of “me too” fiefdoms. Even if the new card architecture fixes all the current shortcomings, which it is supposed to do, nothing can fix the selfish mindset of transit companies who refuse to cooperate. As FeliCa Dude points out, Mobile PASMO is a boondoggle, the result of JR East and PASMO Association failing to cooperate and mutually host commute plans. I suspect that auto-charge transit company premium branded credit cards are getting in the way. Japanese transit companies need to put aside old grudges and cooperate intelligently to get all transit players on mobile as fast as possible. Everybody loses out if they do not.

UPDATE: Japanese programmers digging into Mobile PASMO details find that PASMO licensed Mobile Suica IT assets for Mobile PASMO service. This makes a lot of sense and is an encouraging sign that Mobile Suica cloud resources can be licensed to host other transit IC cards for mobile (ICOCA, TOICA, manaca, etc.).

UPDATE 2: Junya Suzuki posted an article with more Mobile PASMO system details. One leading company in the PASMO Association (Tobu, Keio or Odakyu) licensed Mobile Suica assets and technology from JR East. Cut and paste IT. As said above, this is encouraging because other transit companies (JR West, JR Central et al) can license Mobile Suica assets and park it on whatever cloud service they want: AWS, Azure, NTT Data and so on. Mobile plumbing for connecting Apple Pay and Google Pay is already in place.

UPDATE 3: the Mobile PASMO device link keeps dying, here is downloadable PDF copy as backup:

Transit Cards on Mobile

The long delayed Apple Pay Octopus finally launched in June. Apple Pay Guangzhou, Shenzhen and Foshan China T-Union transit cards launched in May. Rumors said that hosting China T-Union transit cards on Apple Pay is easier than Octopus. Is this true? Let’s take a look.

The chart below lists native transit cards hosted on mobile digital wallets by service launch year, limited to reloadable virtual transit cards already in service or formally announced by wallet platform vendors (Apple/Google/Samsung/etc.) and/or transit agencies. Best viewed in landscape mode.

YearCardAreaOperatorOS/Digital WalletNFCProtocol
2006
Mobile SuicaJapanJR EastOsaifu Keitai/SymbianFMobile FeliCa
2011
Mobile SuicaJapanJR EastOsaifu Keitai/AndroidFMobile FeliCa
2015
TmoneyKoreaTmoney Co. LtdSamsung PayAMIFARE
cashbeeKoreaEB Card Co.Samsung PayAMIFARE
2016
Mobile SuicaJapanJR EastApple PayFMobile FeliCa
China T-UnionChinaVariousHuawei Pay/Samsung PayAPBOC 2.0
2017
Beijing/Shanghai TransitChinaBMAC/SPTCCApple PayAPBOC 2.0*
2018
iPassTaiwaniPass Co.FitBit Pay/Garmin PayAMIFARE
EasyCardTaiwanEasyCard Co.Garmin PayAMIFARE
HOPPortlandTriMetGoogle PayAMIFARE
Smart OctopusHong KongOCLSamsung PayFMobile FeliCa
2019
HOPPortlandTriMetApple PayAMIFARE
VentraChicagoCTA/CubicApple Pay (announced/delayed)AMIFARE
Mobile mykiVictoriaPublic Transport VictoriaGoogle PayAMIFARE4Mobile
2020
ShenzhenGreater Bay RegionShenzhen Tong LimitedApple PayAPBOC 3.0
GuangzhouGreater Bay RegionGuangzhou Yang Cheng Tong LimitedApple Pay APBOC 3.0
FoshanGreater Bay RegionApple Pay APBOC 3.0
SmarTripWashington DCWMATA/CubicApple Pay (announced)AMIFARE
EasyCardTaiwanEasyCard Co.Samsung PayAMIFARE
VentraChicagoCTA/CubicGoogle Pay (announced)AMIFARE
Mobile PASMOTokyoPASMOOsaifu KeitaiFMobile FeliCa
Mobile SuicaTokyoJR EastGarmin PayFMobile FeliCa
Smart OctopusHong KongOCLApple PayFMobile FeliCa
*iOS 11 Apple Pay Beijing/Shanghai transit cards were not full spec PBOC 2.0 and listed as ‘beta’

Mobile transit card protocol overview
Transit card payment mobile protocols are FeliCa, MIFARE and PBOC 2.0/3.0, the later is the Chinese variant of EMV which uses Type A NFC, the slowest of the three protocols designed for supermarket checkout not transit gates.

While transit gates and NFC processors are found worldwide, what makes the Japanese gates different from the rest of the world is they don’t use global standard ISO 14443 (never mind Type A which uses Miller bit coding, the least efficient bit coding method) protocol which is common in many transit and bank cards issued worldwide.

The tap time with ISO 14443 Type A (née Philips) and B (née Motorola) varies greatly: from 200 to 500 milliseconds (ms) with 200 ms only achievable with Type B/Calypso. But it never reaches the short as 100 ms which is only achieved with Felica developed by Sony, also designated NFC-F and NFC Tag Type 3 by the NFC Forum and compatible with ISO 18092 which is commonly found in smartphones and NFC wearables since 2013. In this video passengers maintain their walking pace but never overshoot and trigger a gate closure nor slow down not even a bit.

It may be a minor difference but due to the high volume of passengers per gate (comparison example of large crowds at gates in Malaysia and Japan) and to reduce gate maintenance requirements, taps times really matter. Companies such as JR East have specified tap time of 200 ms but Suica is actually faster and this allows real life speed tolerances: some passengers tap faster than others due to walking pace, the higher speed tolerances are only possible with the 100 ms tap time of FeliCa.

Open Loop NFC ticketing (in its current form, EMVCo Contactless specifications are adopted in contactless bank cards issued worldwide including China UnionPay QuickPass which is PBOC derived from the EMVCo Contactless spec and uses the ISO 14443 Type A at 106 kbps only for 500 ms tap time, which is adopted in cities worldwide such as London, New York, Moscow and Rio de Janeiro is never supposed but as seen here, transit cards in Japan such as Suica, PASMO and ICOCA are supported for ultra hight speed and precise account verification and fare processing. Transit cards use offline Stored Fare (SF) which includes the amount of funds stored in the card’s IC smart chip data storage, NOT backend on a server like a bank card, and stored commuter passes.

YouTube comment explaining the speed differences between NFC types (blocked outside of Canada), lightly edited for clarity

The PBOC Protocol

Each card organization has formed its own specifications based on the EMV specification based on its own business refinement and expansion, such as China UnionPay’s PBOC 2.0 specification…PBOC based on the EMV standard, combined with the needs of domestic banks, the People’s Bank of China promulgated the PBOC series of standards:
1 PBOC1.0: e-wallet / electronic passbook / magnetic stripe card function
2 PBOC 2.0: E-wallet extension application, debit/credit application, personalization guide, contactless IC card standard
3 PBOC 3.0: Cancel e-wallet and electronic passbook application, cancel downgrade transaction, multi-algorithm extension, multi-application extension, mobile payment standard

Super Lu

The interesting thing here is that many Greater Bay Area transit cards were FeliCa based cards but are migrating to the PBOC 2.0 powered China T-Union cards that are much slower. Users notice the difference:

Compared to other contactless smartcards in use, the data transmission of <PBOC 2.0 China T-Union> Yang Cheng Tong is criticized by commuters that it takes 1~2 seconds between the card and reader to complete the transaction, though the operator claims that the data communication only takes 0.5 seconds in its official site.

Wikipedia Yang Cheng Tong

Despite the slower gate speeds the PBOC 2.0 China T-union card spec is the Chinese mainland standard for interoperable transit cards on plastic and mobile that work across the country, similar to what Japan has with Suica, ICOCA, PASMO, etc.

This Wikipedia chart needs to be updated but illustrates how many China T-Union cards there are

Mobile transit cards vs Open Loop
Mobile FeliCa developed by Sony and NTT Docomo has been around the longest and works across multiple mobile hardware platforms from Symbian handsets, to Android, to iOS/watchOS. MIFARE has a shorter history on mobile, PBOC 2.0/3.0 is basically new. The key period is 2015~2016 which saw transit card debuts on Apple Pay, Samsung Pay and Huawei Pay. Initial Apple Pay support for Beijing and Shanghai transit cards was listed as beta on iOS 11.3. The early Apple implementation was not the full PBOC 2.0/3.0 spec, apparently fixed in iOS 12.3 when the beta label was removed.

One of the biggest advantages of transit cards in digital wallets is the freedom of anywhere anytime recharge with credit/debit cards; transit users are no longer chained to station kiosks to recharge plastic smartcards or renew a pass. The more payment options supported on the recharge backend, the more convenient. These are great customer features, so why is it taking so long to get transit cards on mobile in America and Europe when there are some 257 China T-Union transit card compatible transit authorities already on mobile?

Many transit card fare systems outside of Asia are managed by Cubic Transportation Systems, including Oyster, Opal, Clipper, OMNY, Ventra and SmarTrip to name a few. Cubic and operators like Transport for London and Transport for NSW have focused primarily on Open Loop EMV card support as a mobile solution instead of native virtual transit cards.

Publicly run transit system resources are limited so using bank cards for open loop transit is seen as a way to reduce costs for both fare collection and plastic card issue. The downside is that open loop eats up precious system resources so that banks can get a cut from transit gate transactions. The end result is that native transit card mobile support is a secondary priority, if at all.

Cubic’s very first virtual transit card effort, the long delayed Apple Pay Ventra, is all the evidence you need when open loop is a priority and transit cards are not. Despite the recently announced Google Pay and Cubic alliance, I think transit cards on mobile will continue to arrive in a slow trickle. Let’s face it, HOP is the only American transit card that has gone mobile so far, and it’s not managed by Cubic. It’s the same story in Australia with Melbourne myki Google Pay.

China T-Union: streamlined for mobile
Putting aside the open loop fad for a moment, the large deployment of China T-Union cards on mobile comes down to a few simple things that has nothing to do with protocols or smartphone hardware. It is all about streamlining:

  1. All China T-Union cards share a common recharge backend cloud provided by UnionPay. It’s the reason why China T-Union sports a similar logo and the reason why transit cards can only be recharged with a UnionPay card. It’s all one package.
  2. China T-Union cards on mobile have to be created on the device, plastic card transfers are not supported. Local transit agency transit card apps are intentionally crippled and do not support any NFC features. Apple Support pages do not mention plastic card transfer:

You can create a new transit card in Wallet to use with Apple Pay. The first transit card that you add to Wallet automatically becomes your Express Transit card.

Add a transit card to Apple Pay in mainland China

Eliminating plastic card transfers reduces management hotlist headaches and the common UnionPay recharge backend shared by all transit cards with the same card architecture makes hosting virtual cards much easier. The various transit operators only need to plug into the network. They don’t have to host everything directly or build a cloud backend from scratch, and there’s nothing to negotiate because UnionPay is the only payment network.

China T-Union in the cards for Hong Kong Octopus?
China T-Union illustrates the power a national transit card standard backed with a shared cloud resource but it’s a streamlined straightjacket: UnionPay is the only payment network allowed, there are far fewer service options than Suica or Octopus systems. The real interesting development here is that QR Codes (AliPay/WeChat Pay) for transit, and everything else, are mainstream in China. There are many reasons for this outcome but on the transit gate QR Codes and PBOC-EMV transit cards are pretty much the same speed. There isn’t enough difference to care, and AliPay/WeChat Pay represent a choice outside the UnionPay straitjacket with all kinds of incentives to use QR.

Another interesting development is the pressure from QR Code players like Alipay for a piece of MTR transit gate action, and the Greater Bay Area transit card negoiations with Yangchengtong on the Hong Kong MTR/Octopus Card Limited mobile strategy roadmap. QR is mobile only of course, but a dual mode FeliCa/PBOC card approach for the Greater Bay Area is much cheaper and easier to implement on mobile than plastic.

Unfortunately in the face of pressure MTR/OCL, a world leading transit platform business model and innovator, has been surprisingly slow rolling out virtual Octopus card service on digital wallets to encourage the migration from plastic cards with new kinds of mobile services. It’s a troubling turn of events because OCL has all the necessary transit on mobile infrastructure in place to move forward quickly but progress is painfully slow.

The Hong Kong protests followed by the COVID-19 crisis have certainly slowed things down. In the end however, growing mobile services is the best way forward for Octopus to remain a viable Hong Kong MTR business in these uncertain times. Because if it does not, Octopus risks becoming just another China T-Union card.

Put another way, Octopus is living on borrowed time. If OCL doesn’t innovate and invest it its future as a world’s leading transit platform, it does not have one.

The Mobile PASMO Super Suica Challenge

The recently announced Mobile PASMO has some serious limitations lucidly explained in FeliCa Dude’s ‘Mobile PASMO – something we shouldn’t need‘ reddit post. It shines a light on the unfortunate petty politics of Japanese business culture, a catch-22 that ends up killing the very opportunities Japanese companies work to create. Mimicchii is a good Japanese word for it: so obsessively stuck on pointless small details that one completely misses the big opportunity. The PASMO association knows they will loose out, eventually, but hang on to their one and only advantage, commute passes, in the hope they gain a better losers bargain in the end. But how much opportunity is lost by then?

As FeliCa Dude points out, Mobile PASMO is a pointless waste of money and system resources to replicate what Mobile Suica already does:

PASMO is inferior to Suica in many respects, the idea of deploying Mobile PASMO and removing the user’s ability to choose Mobile Suica is fairly short-sighted. Such a development likely cost many hours and much money, but is effectively a boondoggle and a monument to the stubborn failure of JR and the PASMO Association to sort out a way to issue commuter passes on each other’s cards.

Taken to an extreme each transit card player would build its own mobile service but this is impossible in an era of shrinking ridership and resources.

Come together into one mobile service please…

The next generation 2 cards in 1 Suica due in 2021 aims to fix the current state of affairs. Architecturally I expect the problems will be solved, but corporate politics are another matter. JR East will have to offer enough cost saving incentives and flexible extras for the other major transit card players to host their service assets on Mobile Suica: commute plans, Shinkansen eTickets and more. It’s certainly in everybody’s best interest to do so. Time to put aside the mimicchii politics and duplication. If Japanese transit companies can’t come together to build the future, everybody loses.