USIM与ISIM在3GPP标准中的主要功能差异是什么？

Question

在3GPP标准中，USIM（Universal Subscriber Identity Module）与ISIM（IP Multimedia Services Identity Module）的核心功能差异是什么？为何ISIM是实现IMS（IP Multimedia Subsystem）注册的关键组件？两者在身份认证、应用标识（AID）及支持的EF文件结构上有何不同？特别是在VoLTE或VoWiFi场景中，ISIM如何提供IMPI和IMPU等特有参数，而传统USIM无法支持这些功能？

Answer 1

1. USIM与ISIM的基本定义与演进背景

在3GPP标准体系中，USIM（Universal Subscriber Identity Module）是UMTS（Universal Mobile Telecommunications System）网络中的核心用户身份模块，继承并扩展了GSM时代的SIM卡功能。它主要用于执行网络接入认证、存储用户密钥（如Ki）、提供安全会话密钥，并支持GSM/UMTS/LTE等多种接入方式的身份验证。

随着IP多媒体子系统（IMS, IP Multimedia Subsystem）的引入，传统USIM无法满足IMS域中对用户身份标识和认证机制的更高要求。因此，3GPP在TS 31.103规范中定义了ISIM（IP Multimedia Services Identity Module），作为USIM的应用扩展，专门用于支持IMS相关服务。

ISIM本质上是一个运行在UICC（Universal Integrated Circuit Card）上的独立应用，可与USIM共存于同一物理卡片中，但具备独立的应用标识（AID）和专属文件结构，以实现对IMS注册、鉴权及多媒体会话建立的支持。

2. 核心功能差异对比分析

功能维度	USIM	ISIM
主要用途	蜂窝网络接入认证（EPC/LTE）	IMS域注册与多媒体服务认证
支持协议栈	MAP, SS7, AKA for E-UTRAN	IMS AKA, SIP over IP
关键参数	IMSI, Ki, OPc	IMPI, IMPU, Domain Name, CK/IK
认证机制	EPS-AKA 或 UMTS-AKA	IMS-AKA（基于IPSec/IKEv2或HTTP Digest）
应用场景	Voice (CSFB), Data Bearer	VoLTE, VoWiFi, RCS, Video Call
是否必需用于IMS注册	否	是（若使用本地ISIM应用）

3. 应用标识（AID）与文件系统结构差异

• USIM AID: 为 A0000000871002，标识其为通用用户身份模块应用。
• ISIM AID: 定义为 A0000000871004，由ISO/IEC 7816-5和3GPP TS 31.103规定，确保终端能正确选择并激活ISIM应用。

在EF（Elementary File）文件结构方面，两者存在显著区别：

1. EF.IMPI：存储IMPI（IP Multimedia Private Identity），格式通常为“private-identity@realm”，仅存在于ISIM中。
2. EF.IMPU：包含一个或多个IMPU（IP Multimedia Public Identity），如sip:[e-mail]，支持SIP URI或TEL URI形式。
3. EF.DOMAIN：保存归属IMS域名称，例如“ims.mnc001.mcc001.3gppnetwork.org”。
4. EF.ADN 和 EF.SPN：由USIM管理，用于电话簿和运营商名称显示。
5. EF.UICCIARI：记录UICC上所有可用应用及其AID信息，便于终端发现ISIM是否存在。
6. EF.Kc, EF.CK, EF.IK：分别存储GSM、UMTS及IMS专用加密密钥材料。

4. IMS注册过程中的ISIM关键作用

在VoLTE或VoWiFi场景中，UE需通过IMS完成注册以启用语音和视频通话服务。该流程依赖于ISIM提供的以下特有参数：

// 示例：IMS注册请求中携带的关键字段
REGISTER sip:ims.mnc001.mcc001.3gppnetwork.org SIP/2.0
From: <sip:[e-mail]>;tag=abc123
To: <sip:[e-mail]>
Contact: <sip:[e-mail];ob>
P-Preferred-Identity: <sip:[e-mail]>
Authorization: Digest username="[e-mail]",
                   realm="ims.operator.com",
                   nonce="dcd98b7102dd2f0e",
                   uri="sip:ims.operator.com",
                   response="generated_response"

其中，username取自ISIM的EF.IMPI，而P-Preferred-Identity则来自EF.IMPU。这些字段无法从传统USIM获取，因为其缺乏对应EF文件支持。

5. 认证机制深度解析：USIM vs ISIM

尽管USIM和ISIM均可参与AKA（Authentication and Key Agreement）流程，但其实现目标不同：

graph TD A[UE发起IMS注册] --> B{终端是否存在ISIM?} B -- 是 --> C[选择ISIM应用] B -- 否 --> D[使用Non-3GPP AAA或NAI伪IMPI] C --> E[读取EF.IMPI & EF.DOMAIN] E --> F[执行IMS-AKA挑战响应] F --> G[生成CK/IK密钥对] G --> H[建立IPSec SA保护SIP信令] H --> I[成功注册至P-CSCF/I-CSCF/S-CSCF]

IMS-AKA基于与EPS-AKA相似的数学原理（f1-f5算法），但输入参数包括IMPI和归属域名，输出密钥CK（Cipher Key）和IK（Integrity Key）用于保护IMS层通信安全，而非空口链路。

6. 实际部署中的兼容性与替代方案

尽管ISIM是原生支持IMS的最佳选择，但在部分老旧设备或IoT终端中可能不存在ISIM应用。此时可通过以下方式实现IMS接入：

• NAI封装：将IMSI伪装成IMPI格式（如[e-mail]）提交给AAA服务器。
• eUICC远程配置：动态下载包含ISIM应用的Profile，提升灵活性。
• UE本地生成IMPU：由设备厂商或运营商策略决定映射规则。

然而，这些方法牺牲了安全性与标准化程度，无法完全替代ISIM在真实商用网络中的地位。