SGP.22 v3の新機能とは？MEP・Device Change・Push通知をv2との差分で解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。 本記事では、Consumer eSIM の技術仕様 SGP.22 が v2 から v3 に進化して何が変わったのかを整理します。特に実務への影響が大きい MEP(複数プロファイル同時有効化)、Device Change、Push 通知の 3 つを中心に解説します。

はじめに

Consumer 向け eSIM の中核仕様である SGP.22(GSMA RSP Technical Specification)は、長らく v2 系(v2.2〜v2.5)が実装の主流でした。2023 年以降に登場した v3 系(v3.0/v3.1)では、単なる修正にとどまらない大きな機能追加が行われています。スマートフォンのデュアル SIM 運用や機種変更時の eSIM 移行など、エンドユーザーが日常的に触れる場面に直結する変更が多いのが v3 の特徴です。

本稿では、SGP.22 v3.1 に基づいて以下を整理します。

• SGP.22 v2 系と v3 系の差分の全体像

• MEP(Multiple Enabled Profiles): 1 つの eUICC で複数プロファイルを同時に有効化する仕組み

• Device Change: 機種変更時のプロファイル移行を標準化した手続き

• Push Service: SM-DS のイベントをポーリングなしで受け取る仕組み

なお、Consumer RSP の全体アーキテクチャ(SM-DP+/SM-DS/LPA の役割分担)は前提知識として扱います。復習が必要な方はConsumer RSPアーキテクチャの解説記事を先にご覧ください。

1. まず全体像から — SGP.22 v3をざっくり理解する

SGP.22 v2 の世界観をひとことで言うと「eUICC の中で有効なプロファイルは常に 1 つ。プロファイルの入れ替えはユーザーが端末を操作して行う」というものでした。v3 は、この前提を 3 つの方向から緩めています。

1 つめが MEP です。v2 では、デュアル SIM 端末で 2 回線を同時に使いたければ「物理 SIM + eSIM」あるいは「eUICC を 2 個搭載」という構成しかありませんでした。MEP は 1 つの eUICC の中で複数のプロファイルを同時に有効化できるようにする仕組みです。たとえるなら、これまで 1 つの窓口しかなかった役所に複数の窓口を設け、別々の来客(ベースバンド)を並行して応対できるようにしたイメージです。窓口に相当する概念が後述する「eSIM Port」です。

2 つめが Device Change です。eSIM のプロファイルは eUICC の外に取り出せないため、機種変更のたびに「古い端末のプロファイルを削除して、新しい端末で再発行を受ける」という手続きが必要でした。v2 まではこの手続きが標準化されておらず、各キャリアや端末メーカーが独自の再発行フローを用意していました。v3 はこの「引っ越し手続き」を仕様として定義し、旧端末の LPA の操作から新端末でのダウンロードまでを一気通貫でつなげられるようにしました。

3 つめが Push Service です。v2 では、待機中のプロファイルがあるかどうかを LPA が SM-DS に定期的に問い合わせる(ポーリングする)必要がありました。v3 では、スマートフォンのプッシュ通知基盤を利用して「イベントが登録されたらサーバー側から知らせる」方式が追加されています。

いずれも「eSIM をもっと普通の SIM カードのように、あるいはそれ以上に便利に使えるようにする」ための機能です。次章から仕様レベルで見ていきます。

2. v2系とv3系の差分の全体像

SGP.22 v3.0 で追加された主な機能を v2 系と対比すると次の通りです。

SEP(Single Enabled Profile、有効プロファイルが常に 1 つの従来動作)という用語自体、MEP の登場によって v3 で導入されたレトロニムです。また RPM(Remote Profile Management、Operator が SM-DP+ 経由でプロファイルの有効化・無効化などを遠隔指示する仕組み)も v3 の大きな追加ですが、本稿では誌面の都合上、MEP・Device Change・Push Service の 3 つに絞ります。

3. MEP(Multiple Enabled Profiles)

3-1. eSIM Portという考え方

MEP は SGP.22 v3.1 の §2.12 で定義されるオプション機能です。仕様は目的を「複数のベースバンドを持つ端末が、複数のプロファイルを同時に使って異なるネットワークへ接続できるようにすること」と明記しています。

物理的な話をすると、eUICC と端末の間の配線(物理インターフェース)は 1 本のままです。その 1 本の上で複数プロファイル宛ての APDU(スマートカードとやり取りするコマンド)を多重化する仕組みは ETSI TS 102 221 で LSI(Logical SE Interface、論理 SE インターフェース)として規定されており、SGP.22 はこの LSI を eSIM Port と呼びます。

eSIM Port には 0 から始まる連番が振られ、次のルールで管理されます。

• 1 つの eSIM Port に割り当てられる有効プロファイルは常に最大 1 つ

• 1 つのプロファイルが割り当てられる eSIM Port も常に最大 1 つ

• プロファイルの有効化は「eSIM Port への割り当て」、無効化は「割り当ての解除」を意味する

3-2. 3つの動作モード: MEP-A1/MEP-A2/MEP-B

MEP では、eUICC 管理の窓口である ISD-R(Issuer Security Domain Root)をどの eSIM Port で選択するか、およびプロファイルへの eSIM Port の割り当てを誰が決めるかによって、3 つのモードが定義されています(SGP.22 v3.1 §2.12)。

MEP-A1/A2 は「管理専用の窓口(Port 0)」を常に確保する設計で、コマンドを送る Port と対象プロファイルの Port が必ず分かれます。MEP-B は管理専用 Port を持たず、その分 eSIM Port の本数を節約できます。

どのモードを使うかは、非着脱型の eUICC を前提に OEM と EUM(eUICC Manufacturer、eUICC 製造者)が事前に合意しておくのが基本です。MEP が非着脱型 eUICC のみを対象とするのはこのためです。加えて v3.1 §3.4.1 では、端末と eUICC が MANAGE LSI(Configure LSIs)コマンドの追加 TLV(タグ '90' でサポートモード、タグ '91' で有効プロファイルの最大数)を交換し、両者が共にサポートするモードを起動時に決定するセットアップ手順も定義されています。

3-3. 実務上の注意

MEP は「eUICC が対応していれば使える」機能ではありません。端末側に複数ベースバンド(または 1 つのベースバンドでのデュアル待受処理)と MEP 対応のモデム・OS 実装が必要で、さらに端末と eUICC のモードが一致しなければなりません。市場ではハイエンドスマートフォンから対応が始まっている段階で、SEP 前提のシステム(たとえば「有効プロファイルは 1 つ」を前提にした業務システム)は、MEP 端末で想定外の状態を見る可能性があります。

4. Device Change

4-1. なぜ標準化が必要だったのか

eSIM プロファイルは eUICC の秘密鍵と紐付いてインストールされるため、ファイルのように端末間でコピーできません。機種変更では「新しい eUICC 向けにプロファイルを再発行する」しかなく、v2 時代はこの再発行フローが仕様外でした。結果として、キャリアショップでの再発行手続きや、Apple/Google の独自クイック転送機能が乱立し、ユーザー体験がキャリアと端末の組み合わせに依存していました。この経緯と各社実装の関係はeSIM転送の仕組みの記事で詳しく扱います。

SGP.22 v3.0 はこの手続きを Device Change として標準化しました。ポイントは、旧端末の LPA・SM-DP+・新端末の LPA の間の一連のやり取りが仕様で定義されたことです。

4-2. 手続きの流れ

Device Change を使えるのは、プロファイルのメタデータで Operator が Device Change を許可し、その構成情報(どの SM-DP+ で手続きするか等)が設定されている場合です。手続きは SGP.22 v3.1 §3.11.1 で定義されており、旧端末側では ES10b.PrepareDeviceChange(§5.7.26)などの v3 で新設されたファンクションを使います。おおまかな流れは次の通りです。

エンドユーザーから見ると「旧端末で移行操作をする → 新端末に案内(Activation Code など)を引き継ぐ → 新端末でダウンロードする」という 2 台完結の手続きになります。旧端末側のプロファイルは手続きの中で削除され、削除の Notification が SM-DP+ 経由で Operator に届くため、Operator は回線と旧プロファイルの棚卸しを正しく行えます。

また v3 では、旧プロファイルを削除したあとに新端末でのインストールが恒久的なエラーで失敗した場合に備えた Profile Recovery(プロファイル復旧。SGP.22 v3.1 §3.11.2)の手続きも定義されており、「移行に失敗して回線が宙に浮く」事態への手当てがなされています。復旧を使えるのは、SM-DP+ が Device Change 応答で復旧サポートを示しており、旧端末の LPA が復旧に必要な情報を保持したまま復旧有効期間内である場合です。

注意点として、Device Change は SM-DP+ と旧端末・新端末の LPA がいずれも v3 対応であって初めて機能します。また、実際に再発行を許可するかどうかの判断は Operator 側にあり、仕様は「安全に再発行するための伝送路と手続き」を提供するものです。

5. Push Service(Push通知)

v2 までの SM-DS ディスカバリは、LPA が端末の電源投入時などに SM-DS へ「自分宛のイベントはあるか」と問い合わせるプル型でした。確実ですが、問い合わせのタイミングまでダウンロード案内に気づけないという遅延と、無駄なポーリングトラフィックが課題でした。

SGP.22 v3 は §2.13 で Push Service の仕組みを定義しました。これは、スマートフォン OS が持つプッシュ通知基盤(OS ベンダーのプッシュサービス)を利用して、SM-DS にイベントが登録された時点でサーバー側から端末へ通知を届けるものです。LPA はあらかじめプッシュ通知の宛先(プッシュトークン)を SM-DS に登録しておき(§3.6.5 の Push Service Registration 手続き。ES11 の相互認証の中でプッシュトークンを EID と紐付けて渡します)、通知を受け取ったら従来どおりのイベント取得・ダウンロード手続きを開始します。

「Push Service が運ぶのは『問い合わせるきっかけ』だけであり、プロファイル本体やイベント内容はこれまで通り相互認証を経て取得する」

という点が設計上のポイントです。プッシュ通知経路は認証された経路ではないため、そこに機微な情報は載せず、セキュリティモデルは v2 から変えていません。Activation Code や SM-DS ディスカバリの基本形についてはActivation CodeとSM-DSディスカバリの記事を参照してください。

まとめ

• SGP.22 v3 系(v3.0/v3.1)は、MEP・Device Change・Push Service・RPM など、v2 系に対して機能面の大型追加を含む世代である

• MEP は 1 つの eUICC で複数プロファイルを同時に有効化するオプション機能で、ETSI TS 102 221 の LSI を「eSIM Port」として利用する(SGP.22 v3.1 §2.12)

• MEP には ISD-R の選択方法と Port 割り当て主体が異なる MEP-A1/MEP-A2/MEP-B の 3 モードがあり、非着脱型 eUICC を前提に端末側と合意して使う

• Device Change は機種変更時のプロファイル再発行手続きの標準化であり、旧プロファイルの削除と新端末へのダウンロードを一連の流れとして定義した

• Push Service は SM-DS イベントの検知をプル型からプッシュ型に拡張するもので、セキュリティモデル自体は従来のままである

v3 の新機能はいずれもオプションであり、エコシステム全体(eUICC・端末・LPA・SM-DP+/SM-DS)の対応が揃って初めて効果を発揮します。自社サービスがどの機能を前提にできるかは、接続相手の対応バージョンを含めて確認することをおすすめします。

参考規格

• GSMA SGP.22 v3.1 — RSP Technical Specification

• GSMA SGP.21 v2.7 — RSP Architecture

• ETSI TS 102 221 — Smart Cards; UICC-Terminal interface; Physical and logical characteristics(LSI/APDU 多重化の定義)

おわりに

弊社では「LibeSIM」として、SM-DP+やMVNO回線、eIM(eSIM IoT Remote Manager)、eUICC、IPA/LPAのご提供を行っております。 ご興味がございましたら、デモやPoC等行っておりますので、ぜひお問い合わせください。

https://common-creation.com/service/libesim