IoT機器をeSIM対応にするLPA Bridgeの開発・実装とPoCへのお誘い

わたくし、ひげのおじさんエンジニアはプロフィールにもある通りコンピュータおよび移動体通信の進歩を横目に見ながら自称技術者として30年強この業界に関わってきました。

本投稿の概要紹介

本投稿は、3年ほど前にIIJモバイルがeSIMサーバを立上げeSIMサービスを開始する事が決まった当時、eSIMの出口と言いますか サービスの利用が想定されるデバイスとして一部のPCやスマホ、iPhone しかないのは面白くないなぁと考え、LTEルータやIoTデバイスにもeSIMサービスを提供できる、言い換えれば「eSIM(eUICC^(※1))内蔵機器を簡単に開発出来ないか」と考えたことに始まり、やっと実装をにこぎつけPoCのお誘いが出来るところまで来ました…と言う内容を、今日に至る経緯から技術的な詳細、PoCでIIJは何を提供しご一緒に何をしたいのかを記載します。

先ずは、SIM, eSIMとは

移動体通信を利用する為にスマホなどにセットするSIMのご説明を。
ご存じの方も多いとは思いますが、SIM(Subscriber identity Module)とはMPU,ストレージ,メモリを持ちJavaプログラムが動作するTiny Computerです。
H/W的な特徴は、暗号化ストレージと対タンパー性を有しており、不正なアクセスが繰り返されると自己破壊を起こすと言う非常にセキュアなシステムで、物理的な形態としてカード型は皆様パスケースに入っているクレジットカードと同じモノとなります。
従来のSIMはこの器に、通信に必要な情報(SIMプロファイル^(※2)と称される、IMSI,MSISDN,Ki,etc.)を、予め入れた状態で発行していますが、対してeSIMは器と情報を分離した状態で管理し、必要に応じて情報を器に入れ、通信が可能なSIM機能を完成させるようOSが拡張され、複数保持可能なSIMプロファイルの操作を受け持つAppletが動作しています。
SIMとeSIMは機能性が異なるだけで、双方物理的な形態はカード型もICチップ型も存在します。

本題であるeSIM PoCを可能にする要素の開発

先ずはドキュメントの収集と読込。
GSMA^(※3)が発行している、Official Document SGP.2x – RSP Architectureや、3GPP^(※4)が発行するETSI TS 131 122などeSIMに関するドキュメントを読み漁りました。
提唱された実装アーキテクチャは図１に示した通り2種類。
M2Mモデル(IoT機器向け)とコンシューマモデルがあり、IoTデバイスはM2Mモデルを使え的な。
リッチなUIを持たないIoTデバイスなどが対象ゆえ、予めeUICC内にBootStrapと呼ばれる事前に取り決めたSM-SRにアクセス可能な通信プロファイルを仕込んで置き、アクセスしたSM-SR内に設定したルールに従いeSIMサーバ(SM-DP)からSIMプロファイルを取得する。
「取得する」と表現しましたが、ユースケースとしては単一モデルのIoTデバイスを複数の仕向け先に出荷、設置された環境に応じて予め決められた最適とされるSIMプロファイルが「送り付けられる」プッシュ型のモデルです。
これは、SIMベンダと通信キャリアの深い関与が無いと実装困難なモデル。

図1 2つのeSIM アーキテクチャ
GSMA_eSIM-Whitepaper-v4.11より引用

一方、コンシューマモデルはSIMベンダからも通信キャリアからも解放された、本当の意味でユーザの意向を尊重したプル型のモデルなのですが、ただ…ここにも課題が２つ。

一つは、通信を可能にするためのSIMプロファイルをインターネット上にあるeSIMサーバからダウンロードする為の通信ベアラが必要。（エッグアンドチキン・・・）

もう一つは… なんか変だぞ?! どのドキュメントを見ても図2にあるように、デバイスのMPUで動作するLPA^(※5)が直接eUICCと通信する様なアーキテクチャに成っている。

図2 コンシューマモデル デバイス内の実装
SGP.22 RSP Technical Specification Version 2.2.2より

ほとんどのIoT機器は、デバイスのアプリケーションを動作させるMPUがeUICCへアクセスする為のI/Oバスは存在せず、通信モジュール(モデム)と言われる別のコンピュータを介してその先にUARTで接続されているeUICCと通信をしなければならない。

図3 IoT機器内の標準的な実装

ドキュメントには、eUICCを直接操作する為の各種APDUは詳細に記載されてはいるものの、通信モジュールを介してeUICCへアクセスするにはどうしたらよいのかは書かれていない。（まあ、多くのベンダが作る通信モジュールの実装には構っていられないと言うのも解りますが）
もしかすると、スマホのSoCは赤で示した回路が在るとか…電気的には出来ない事もないが。

この時点で、IoTデバイス向けのコンシューマeSIMの実装は一旦断念。

これも出会い⁇ 忘れていた思いが発想の転換で復活

ところが昨年(2021年)の春、有るベンダよりPCにUSBケーブルでスマートカード(SIMカード)リーダを接続し、カード型のeUICCへのSIMプロファイルの書込み/有効化/無効化/削除 が出来るアプリの紹介を受けた事がきっかけとなり、今回のLPA Bridgeの開発に至りました。

なお、LPA Bridgeについては本日プレスリリースも出しています。
IIJ、ウェアラブル機器やIoTデバイスなどでコンシューマ向けeSIMの利用を可能にする新技術「LPA Bridge」を開発

最初の印象は、「使い道のないアプリだなぁ、メジャーではないカード型のeUICCにわざわざeSIMサーバからSIMプロファイルをダウンロードして書込、それをデバイスのSIMソケットに挿して使う??…何を思ってこんなまどろっこしいアプリを作ったんだろう」…名刺だけもらって放置。

数日後、飲んでた時にフッと何かが降りてきた…もしかするとこれは凄いしろものなのでは無いか。
と考え始め、紹介してきたベンダに開発したエンジニアと製品責任者に話がしたいと連絡。
そして、開発したエンジニアへ自身のアイデアを説明し議論を開始する事に。

足りなかったパーツが見つかる!?

図4

先に挙げた一つ目の課題である、通信する為のSIMプロファイルをダウンロードする為のインターネットへアクセスするベアラ（図4の①）は、PCが持っているモノを借りれば解決。
いよいよ2つ目の課題であるLPAアプリケーションとeUICCとをどうやってコミュニケーションさせるか。

USBケーブル ⇒ Wi-FiやBLE（Bluetooth Low Energy）の通信

USBでコミュニケーションできるなら、LPAアプリ側はデバイスファイルを変更してソケット通信でも出来るよね・・・「簡単ですよ」
これで、既存のIoTデバイスが持つWi-FiやBLEを使ってPC側のLPAアプリと接続。

後は、IoTデバイスをLPAアプリからはeUICCに見えるように出来れば、そのまま利用可能ではないか。

Smart Card R/W ⇒ アプリで仮想化して実装

いろいろ調べてみると、ほとんどの通信モジュールにはマニュアルが未公開のSIM操作に関するATコマンドがある事を発見
だったら、ソケット通信の受け手であるデバイス側アプリケーションが、PCで動作するLPAアプリに対してeUICCとして振舞い、受けたAPDUを通信モジュールの秘孔を突いてeSIMへ送信、戻値を再度APDUに変換してLPAアプリに戻すという通訳の様なモノを造って通信モジュールを論理的にバイパスすれば…。

図5 Smard Card R/WをLPA Bridgeで実現

これが、今回開発したLPA Bridgeの全体像です。

LPA Bridgeの意味は、通信モジュールの向こうにあるeUICCとLPAアプリを繋ぐ架け橋の意味を込めて命名しました。
# 蛇足とはなりますが、仕組みが分かってしまうと、「あ～ぁ、そういう事なんだぁ」となってしまう為、どうなるかは分かりませんが、考え方と実装方法をに関して特許の出願もしました。

図6 全体概要

こんなプログラムがデバイス内にあると、eSIMの中身が不正に書換えられて危険なのでは…と言う指摘もありましたが、このLPA Bridgeが起動して居ない限り、eUICCモジュールに対してeSIMとしてアクセスする事は出来ず、通信モジュールからも活性化されているSIMプロファイが入っているこれまでのSIM(UICC)カードとしか認識できない。
故に、このアプリの起動制御をしっかり管理すればデバイスのセキュリティは担保可能です。

具体的には

リファレンス実装は多くのルータ等に採用されているLinuxとし、先に使い道のないマイナーな…と思っていたカード型eUICCをSIMカードソケットにセット、これで既存IoT機器のH/Wを改変することなくeSIM環境を実装出来ます。
簡単に言うと、既存のデバイスにIIJが提供するLPA BridgeのSourceとカード型eUICCを実装するだけで、コンシューマeSIMサービス対応デバイスになり、使い勝手やユースケース、Biz Modelの検討が具体的に出来るようになります。

本来であればチップタイプのeUICCを製品に搭載頂く事に成るのですが、PCBのパターン修正やeUICCチップのマウントなど、eSIMの世界に踏み込むためのハードルが上がってしまいます。

先ずは手元にあるものを最低限の改造で、eSIMの世界に踏み込んでもらう事を目的としています。

既存デバイスへの実装(主に移植作業)を行う上で、ラズパイにLPA Bridgeと比較的多くのLTEルータ/GWに搭載されているEC25-J(Quectel社製)を搭載、SIMソケットにはカード型eUICCをセットしたリファレンスモデルを同時に提供。
# SIMCom社製やSeiko Solution社製の通信モジュールでも動作を確認済み。

Step by Stepで動作を比較しながら自身のデバイスをeSIM化可能です。
これまで、見えない障害となっていたeUICCへ格納するSIMプロファイルの柔軟な発行でテストを支援します。

IIJのビジネスモデルと課金エンジン

コンシューマモデルeSIMの最大の特徴は、デバイスベンダ/ユーザがMNO(キャリア)から完全に開放されると言う事。
言い換えれば、MNOに縛られず必要なタイミングで必要な通信を好きなMNOから入手し利用出来ると言う事 ≒ IIJモバイルが提供しているeSIMサーバ以外からのSIMプロファイルのDLも当然OK。（それが標準仕様完全準拠)

「面白そうだね、何処でどうやって利益を上げるの？」　企業としては給与を支払って我々を活動させているのだから、これは至極 当然の指摘。

• デバイスへ実装するLPA Bridgeのライセンス…う～ん、なんだかねぇ。
  # 本来の目的である、eSIM対応デバイスを誰でも作れるようにしたい、いろんなデバイスがeSIM対応になる…に反する愚行。
• PCやスマホに実装されるLPA Appの受託開発…したい事とずれている様な。
• IIJのeSIMサーバからしかダウンロード出来ない様に…それっ、最低の輩と軽蔑してきたはず。
  # 大きな波紋を立てるのなら、投じる石は出来るだけ大きい方が良いに決まってる。
• LPAに手を入れて、必ず経由する料金所的なGateサーバで通行料を…なんだかなぁ。
  # システムの健全な運用にかかる費用と高可用性に対する責任に対して、取れる通行料って見合うの??
  # とりあえず実装したこの中継サーバですが、デバイスの開発時には様々なeSIMサーバの挙動を確認する事が出来る重宝なデバッガとして利用出来た…(笑)

仮に、スマホを含むほぼほぼ全ての通信デバイスがeSIM対応に成った世界においては、現在世界的に規格化された”乾電池”の様に”通信”が何処でも買えて利用できる様になる。
そういう世界においては、キャリア主体では無くAmazonやAlibabaの様なe-commerceの巨人が全てのeSIMを取り扱う方が効率が良いのではないか。

ゲームのルールが変わると…。

現状のビジネスモデルに一石を投じて市場を破壊…ここまでは責任をもって私が推進。
利益の生み方は、新たに創造されたビジネスモデルから生まれる市場のスタープレイヤに委ねたいと考えます。
# リアルに、課金モデルが見えてたら会社起こしてます。

本来の目的である PoCへのお誘い

既に、SIMカードが入るデバイスを開発されているメーカ様には、中盤で述べた通りサクッと移植してeSIMデバイスのユースケースとビジネスモデルの検討を。
これから、通信対応機器を造って新たなサービスを立ち上げようとしている方々や、海外から面白そうなガジェットを引っ張ってきて、アレンジしたサービスを始めようとする方々、最初にサービサーやデバイスベンダが通信を用意して…というベーシックなモデルから、仮にオンデマンドな通信の調達が可能に成る時サービスの提供形態、デバイスの利用形態は何処まで発展できるのかを創造したい方。
部品の供給者としてのeSIMベンダさんとの市場拡大に向けた挑戦なども大歓迎です。

ラズパイで組み上げた、リファレンスモデルによるデモンストレーションも可能です。
ご興味がある方々、eSIMが当たり前になる事を推進したい方々、その他様々なからのお問合せを歓迎しています。

－語句説明－