スマートフォンが5Gネットワークに接続する仕組みを見るとき、通常はgNB、AMF、SMF、UPFなどのネットワーク要素に注目が集まります。はるかに小さなUSIMは見落とされがちです。しかし実際には、5G登録やモビリティ状態の保存、加入者識別情報のプライバシー、NASセキュリティコンテキスト、アクセス制御に至るまでの機能をサポートするために、USIMにも専用のデータ構造が必要です。
5Gの導入に伴い、USIMファイルシステムもそれに応じて拡張されました。これは既存のSIM構造にいくつかのパラメータを追加するだけの話ではありませんでした。5GS固有のディレクトリ、サービスインジケータ、EFファイルがUSIMアプリケーション内に新たに導入され、モバイル機器がカードのサポートする5G機能、保存すべきデータ、対応する設定をどこから読み取るべきかを判断できるようになりました。
EF5GS3GPPLOCI、EF5GAUTHKEYS、EFSUCI_Calc_Infoなどの名前を個別に覚えるのはすぐに混乱を招きます。より実用的なアプローチは、これらのファイルを扱う問題ごとにグループ化することです：モビリティ、セキュリティ、加入者識別情報のプライバシー、アクセス制御、オペレータ情報。
5G USIMファイルを見る前にUICCとファイルシステムが重要な理由
SIMは2G時代に生まれ、ハードウェアとアプリケーションが密接に統合された加入者識別モジュールとして理解できます。ハードウェアコンポーネントはICチップであり、ソフトウェア側はCOSオペレーティングシステム、ファイルシステム、上位層のアプリケーションまたはサービスで構成されます。
3Gの導入により、USIM（Universal Subscriber Identity Module）はアプリケーションを実行するカードプラットフォームからより明確に分離されました。UICCは基盤となるUniversal Integrated Circuit Cardプラットフォームであり、USIMはそのプラットフォーム上のアプリケーションとして動作します。言い換えれば、一般に「USIMカード」と呼ばれるものは、論理アーキテクチャの観点からは、より正確にはUICC上で動作するUSIMアプリケーションと表現できます。
この区別が重要なのは、5GがUSIMの外部に完全に独立したデータシステムを導入したわけではないからです。代わりに、5Gの機能は既存のUSIMサービスとファイル管理モデルを引き続き利用しています。
スマートカードの大量のデータはファイル形式で保存されます。論理構造は主に次のとおりです：
MF（マスターファイル）：カードファイルシステムの最上位ファイル。
DF（デディケイテッドファイル）：特定のアプリケーションまたはデータグループを整理するための専用ディレクトリ。
EF（エレメンタリファイル）：実際にサービスデータ、状態情報、構成パラメータを格納する基本ファイル。
5Gでは、5GS関連のEFファイルを整理するために、USIMアプリケーションの下に専用のDF5GSディレクトリが追加されました。関連するUSIMアプリケーション仕様では、この一連の機能に対して9つの5G関連サービスと10の対応するEFファイルが定義されています。
DF5GSの下に追加される5G機能とは？
EFファイルが存在するだけでは、機能を自動的に使用すべきという意味にはなりません。もう一つの重要なファイルがEFUST（USIMサービス表）です。
EFUSTは、USIMがサポートするサービスを示します。サービス表には合計131のサービスが含まれ、ここで説明する5G関連サービスは122から130までの番号です。サービスが利用不可とマークされている場合、MEはそのサービスを選択しません。実際のサービス構成はオペレータによって定義されます。
| サービス番号 | 5Gサービス | 主な関連ファイルまたは機能 |
|---|---|---|
| 122 | 5GSモビリティ管理情報 | 3GPPおよび非3GPPの位置情報とNASセキュリティコンテキスト |
| 123 | 5Gセキュリティパラメータ | EF5GAUTHKEYS |
| 124 | 加入者識別子プライバシーサポート | EFSUCI_Calc_Info および EFRouting_Indicator |
| 125 | USIMによるSUCI計算 | SUCI計算がUSIMによって実行されることを示す |
| 126 | UACアクセスアイデンティティサポート | EFUAC_AIC |
| 127 | 制御プレーンによるVPLMN内UEステアリング | ローミングシナリオ向けPLMNステアリング機能 |
| 128 | USIMによるPDUセッションの呼制御 | PDUセッション向けUSIMベースの呼制御 |
| 129 | 5GSオペレータPLMNリスト | EFOPL5G |
| 130 | ネットワーク固有識別子タイプのSUPIサポート | EFNSI |
この表は、個々のファイル名を暗記するよりも有用です。なぜなら、基本的なUSIM設計モデル、つまりサービス能力表示と対応するEFデータを示しているからです。
例えば、サービス122が利用可能な場合、USIMは5GSモビリティ管理に関連するファイルを提供する必要があります。サービス123が利用可能な場合、5G認証鍵ファイルが必要です。サービス129が利用可能な場合、USIMは5GSオペレータPLMNリストを提供します。
工学的観点から見ると、EFUSTは「このカードは何をサポートしているか？」という問いに答え、個々のEFファイルは「この機能にはどのようなデータが必要か？」という次の問いに答えます。MEは両方の情報を使用して、対応する5G機能をどのように処理するかを決定します。
なぜ5Gの位置情報とセキュリティ状態は3GPPアクセスと非3GPPアクセスで別々に保存されるのか？
DF5GSの下で最も分かりやすいファイルグループの一つがモビリティ管理に関するものです。
EF5GS3GPPLOCIは3GPPアクセスの5GS位置情報を保存します。これには以下が含まれます：
5G-GUTI；
最後に訪問した5G-TAI；
5GS更新ステータス。
対応するEF5GSN3GPPLOCIは非3GPPアクセスについて同様の情報を保存します。2つのファイルは同様の目的を果たしますが、異なるアクセスタイプに適用されます。
これは、USIMが5GSモビリティコンテキストで加入者番号を保存するだけではないことを示しています。後の手順で使用できる一時的な識別情報、最近の位置データ、更新ステータスも保持します。
NASセキュリティコンテキストにも同じ分離が適用されます。EF5GS3GPPNSCは3GPPアクセス用のNASセキュリティコンテキストを保存し、EF5GSN3GPPNSCは非3GPPアクセス用の対応するNASセキュリティコンテキストを保存します。
もう一つの専用セキュリティファイルがEF5GAUTHKEYSです。EFUSTのサービス123が利用可能な場合、このファイルが必要であり、MEによって生成されたKAUSFおよびKSEAFを含む5G認証関連の鍵を保存します。
これらのファイルをまとめて見ると、5G USIMの設計ロジックが明らかになります。データは単にプロトコル名でグループ化されているのではありません。UEの実際の動作状態を中心に整理されています：どこに登録されているか、どのようにネットワークにアクセスしているか、現在有効なセキュリティコンテキストはどれか、後でどの認証情報が必要になる可能性があるか。
SUCI、アクセス制御、オペレータ情報はどのように特定のEFファイルに対応付けられるのか？
モビリティとセキュリティのコンテキストに加えて、5Gは加入者識別情報のプライバシーとアクセス制御のためにUSIM側に追加のデータ要件を導入しています。SUCI関連の機能は最も明確な例の一つです。
EFSUCI_Calc_Infoは、SUCIの計算と保護に必要な情報を保存します。このファイルがMEに利用可能かどうかは、EFUST内のサービス124と125の組み合わせによって決まります。
サービス124が利用可能でサービス125が利用不可の場合、SUCI計算はMEによって実行されます。この場合、EFSUCI_Calc_Infoが存在し、MEに利用可能である必要があります。
サービス124と125の両方が利用可能な場合、SUCI計算はUSIMによって実行されます。この場合、EFSUCI_Calc_InfoはMEに利用可能であってはなりません。サービス124自体が利用不可の場合も、ファイルはMEに公開されるべきではありません。
ファイル内の主要なデータオブジェクトは次のとおりです：
保護スキーム識別子リスト：保護スキームの優先順位と鍵インデックスを含みます。
ホームネットワーク公開鍵リスト：SUPI保護に使用されるホームネットワークの公開鍵と関連識別子を含みます。
SUCIと共に使用される別のファイルがEFRouting_Indicatorです。これはSUCIの一部を構成するルーティングインジケータを保存し、ホームネットワークのAUSFおよびUDMへのルーティングに使用できます。
加入者識別情報のプライバシー以外にも、USIMは統合アクセス制御（Unified Access Control）に参加できます。EFUAC_AICは、定義された高優先度サービスに関連付けられたアクセスアイデンティティを含むアクセス管理設定を保存します。これらの値はアクセスカテゴリと共に使用され、特定のサービスのアクセス制御をサポートします。
オペレータ表示情報については、EFOPL5Gが5G-TAIとPLMNネットワーク名レコード識別子の関連付けを保存します。UEがPLMNに登録すると、MEはこれらの関連付けを使用し、対応するオペレータ名情報を読み取ってサービスプロバイダ名またはアイコンを表示できます。
一方、EFNSIはネットワーク固有識別子タイプのSUPIを保存します。この場合、SUPIはNAI形式を使用し、IMSIであってはなりません。
5GネットワークにおいてUSIMは実際にどのような役割を果たすのか？
USIMを単なる加入者識別カードと見なすと、5Gがこれほど多くの追加サービスとEFファイルを必要とする理由を説明するのは困難です。
これらのファイルを総合すると、USIMは加入者データ、UE状態、セキュリティ情報、オペレータポリシーのためのサービス表制御のストレージ機能のセットを提供していることが分かります。
固定された識別情報以上のものを保存しています。5G-GUTIと最後に訪問したTAIはモビリティ状態を表します。NASセキュリティコンテキストと5G認証鍵はセキュリティ状態を表します。SUCI関連ファイルは加入者識別情報のプライバシー保護に関与し、UAC、PLMN、PDUセッション呼制御はオペレータポリシーがUSIMを通じてUEの動作に影響を与える方法を示しています。
サービス127は制御プレーンによるVPLMN内UEステアリングを提供し、ローミング関連のPLMN選択で使用できます。サービス128はUSIMによるPDUセッションの呼制御を提供します。関連操作の前に、端末はPDUセッションタイプ、SSCモード、5GSM機能、サービングセル情報などの情報をUSIMに提供し、カードから返された指示に従って続行できます。
これはトラブルシューティングにも実用的な意味を持ちます。5G端末の互換性問題、登録障害、加入者識別情報のプライバシー問題、または特定のアクセス制御動作を調査する場合、無線ネットワークと5Gコアだけを確認するのでは不十分な場合があります。エンジニアは、USIMが対応するサービスを正しく宣言しているか、必要なEFが存在するか、ファイル内容がオペレータ設定と一致しているかも確認する必要があるかもしれません。
実用的なトラブルシューティング手順は次のとおりです：まずEFUSTを確認してサポートされている機能を確認し、対応するEFが存在することを確認し、次にEFの内容を検査する。これは、5G関連ファイルを個別にすべて読むよりも効率的な場合が多いです。
5Gデバイスおよびコアネットワークのエンジニアにとって、これこそがUSIMファイルシステムを理解する真の価値です。一見別々に見える多くの5G機能は、最終的に非常に具体的な問いに帰着します：UEがネットワーク手順を実行する前に、USIMはどの機能を宣言し、その機能のためにどのデータを保存しているのか？
よくある質問
DF5GSとADFUSIMの関係は何ですか？
DF5GSはUSIMの外部にある別個のアプリケーションではありません。USIMファイル構造内の5GS関連データを整理するための専用ディレクトリです。ADFUSIMはUSIMアプリケーションのメインファイル空間と見なすことができ、DF5GSは5G関連EFファイルの専用の場所を提供します。
EFUSTが5Gサービスを利用可能とマークしているのに必要なEFファイルが欠落している場合はどうなりますか？
サービスが利用可能な場合に対応するEFが存在することを仕様が要求しているサービスでは、これはサービス宣言とカードファイル構成の間に不整合があることを示しています。トラブルシューティングでは、ネットワーク側だけを見るのではなく、まずUSIMのパーソナライゼーションデータ、EFUST構成、必要なEFが正しく作成されたかどうかに焦点を当てるべきです。
スマートフォンはUSIM内の5G EFファイルを自由に変更できますか？
必ずしもそうではありません。異なるEFファイルには異なるアクセス条件があります。一部のファイルの読み取りや更新にはPIN認証が必要な場合があり、アクティベーション、非アクティベーション、または特定の構成変更にはADM権限が必要な場合があります。したがって、ファイルを読み取り、更新、アクティベーション、または非アクティベーションできるかどうかは、その特定のEFに定義されたアクセス条件によって異なります。
EFUSTにサービス番号があるのに専用のEFファイルがない5Gサービスがあるのはなぜですか？
すべてのUSIMサービスがデータを保存するために個別のEFを必要とするわけではありません。一部のサービスは、SUCI計算がUSIMによって実行されることを示すなどの機能インジケータであり、他のサービスはUSIMアプリケーション自体によって実装される制御動作を表します。したがって、EFUSTのサービスエントリは必ずしも専用EFファイルとの1対1の関係を意味するわけではありません。
