FeliCa/Suicaについて調べた

Suica（FeliCa）がiPhone7とApple Watch series 2に搭載されることになったので、この機会にいろいろ調べてみた。まだ、憶測の域をこえないところはある。

Sony Japan | FeliCa | FeliCaとは | FeliCaって何？

• SuicaはFelicaに対応した一つのアプリケーション

• FelicaはNFCフォーラムで規定されているNFC国際規格のType-Fである

  • その他に市場投入されているTypeとしてType-A（タスポ etc.）/Type-B（運転免許証 etc.）がある

  • 国際規格については複雑な事情がある 近距離無線通信 - Wikipedia

  • 2010年のFeliCaチップの出荷台数（最近の情報ではないがアジアのみに集中していたことが分かる）
    → 現時点で国際的にNFCでどのくらいType-Fが占めているのか知りたい（おそらく非常に少ない）

  • FeliCa/NFCの概説とAndroidの対応状況 from Isao Soma

• 電源を持つリーダ／ライタ端末から電磁波を発生させて電磁誘導を起こし、カード側ではその反射波を変化させることで振幅を制御してデータを載せる（Type-Fの変調方式はASK=振幅偏移変調）

  • 今回のiPhone/Apple Watchの対応は、カード（FeliCa IC）とリーダ／ライタ機能、の両方を搭載するはず
  • ただし、iPhone/Apple Watch内部で電波を使う必要は無さそう （FeliCa ICとリーダ／ライダ機能が物理的に分かれている必要すらない） → FeliCa対応のiPhone 7に「総務省指定」刻印があるのに、同じくFeliCa対... - Yahoo!知恵袋
  • でも、NFCは電力は相当小さいはずだけど無線の認可は本当に必要なんだろうか NFCについてのまとめ | インバウンドマーケティング/Facebookアプリ/Web制作 Hivelocity ハイベロシティ
  • "2.設置許可不要設備 無線通信等への影響が少ないと判断される設備については、 個別の許可を不要としており、次のような設備があります。" 認可は不要だけど"MIC/KS"の表示は必要とのこと（もしかすると、送信電力が弱い、のではなく受信のみ、なのかも） 総務省 電波利用ホームページ | 高周波利用設備の概要
  • 海外版のiPhoneでも搭載されているNFCチップの型番は同じなので、ハード的にはFliCaに対応しているらしい 海外版のiPhone 7にもFeliCaは内臓していた。ただし・・・。

• NFCの周波数は13.56MHz／最大スループットは424Kbps

  • Bluetoothの周波数は2.4GHz／最大スループットは24Mbps（BLE（Bluetooth Low Energy）は1Mbps）
  • WiFiは2.4GHz+5GHz／最大スループットは300Mbps（802.11n／HT40／MIMO（2x2））あるいは1.3Gbps（802.11ac（wave1）／HT80／MIMO（3x3））
• Type-F（Felica）は対称通信、つまりリーダ／ライタ側からカードへの通信とその逆の通信において、13.56MHzを使う

• Type-A/Type-Bは非対称通信、つまりリーダ／ライタ側からカードへの通信において13.56MHzを使い、その逆の通信においては13.56/16=848KHzを使う

• 非対称通信の方は、周波数帯が違うので全二重通信が可能になるが、FeliCaが半二重通信となる対称通信を採用した背景として、上位層=アプリケーションのスループットを考えると対称通信の方が良くなるから 非接触ICに最適化された「FeliCa」の正体 − ＠IT

• Apple Watchは電源が心配（通常使用で18時間）だが、電源が切れてもFelicaが使えなくなることはなさそう

  • "アプリケーションを開く必要はなく、デバイスをスリープ状態から復帰させる必要さえありません。" Apple Pay - 始め方 - Apple（日本）
  • 電源が切れた場合には、Apple Watchのリーダ／ライタ機能を起動できずにFeliCa ICチップにはアクセスできなくなるので、Apple Payでのチャージ等はできなくなるだろう

• SuicaのカードをiPhone7/Apple Watch Series 2にかざして取り入れた場合、そのSuicaのカードは二度と使用できなくなるらしい Rebuild: Aftershow 157: Gigaflops Per Yen (hak)

  • これはSuicaの仕様的に、中央サーバに記録されているアカウントと紐付いているのが唯一のFelica ICだから？

How to protect from fraud?

• 中央サーバでトランザクションを一元管理するしかないが、Suicaのような高速な応答性を求められるアプリケーションで、それをどのように実現するか？
• 改札機器端末 → 駅 → 中央サーバ の階層型分散システム
  • 各階層でトランザクションのキャッシュを持つことで、中央サーバが応答不能になっても即座にサービス停止とはならない
    → 改札機器端末は各アカウントの3日分のトランザクションを蓄えられる容量があるらしい
  • 上階層へのトランザクションの更新処理は、キューに溜める非同期型になっているため、入場時の改札機器端末の応答速度は、カードと改札機器端末の間の処理にかかる時間に縮められる
  • 改札端末には各駅までの運賃がキャッシュされており、運賃計算時に即座に反応できるようになっている
  • 出場時の改札機器端末の応答速度を速めるため、入場時にある程度前もって計算してカードに保存しておく（e.g. 入場駅から定期区間の始めまでの運賃）

How to avoid data break?

• Felica（FeliCa OS）はファイルシステム上に更新中のデータを二面持ちしているため、更新処理が完了しなかった場合（更新処理中に物理的にNFCの範囲外に離れてしまった場合）でも、元データに復旧する事ができる

• カード側と改札機器端末側（リーダ／ライタ側）でデータの不整合が発生した場合（カード側で更新処理が完了したが改札機器端末側にそれを伝えられなかった場合）でも、中央サーバ側で不整合の状態を記録しておき、次回アクセス時にカード側の整合状態を中央サーバに伝達して不整合を修復する

http://www.sice.jp/ia-j/papers/jitk6-20050722-1305.pdf