51学通信

深度解析 3GPP TS 31.102：4 Contents of the Files (文件内容概览与MFADF层核心文件)

25分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。

深度解析 3GPP TS 31.102：4 Contents of the Files (文件内容概览与MF/ADF层核心文件)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“第4章 Contents of the Files”的核心章节，旨在为读者揭开USIM内部数据存储的神秘面纱，系统性地介绍文件系统的宏观架构，并对处于文件系统顶层的MF层文件以及ADF层最关键的身份与语言文件 (EF_LI, EF_IMSI) 进行像素级解读。

在上一篇文章中，我们一起学习了第3章，掌握了解读规范所需的“语言”——定义、符号和编码约定。这为我们深入探索USIM的内部世界铺平了道路。我们的主角，通信专业学生“李想”，现在已经手握这本“字典”，准备开启一场对USIM内部“数字城市”的探索之旅。他充满好奇：这张小小的卡片里，究竟藏着怎样一个井然有序的数据宇宙？

第4章“Contents of the Files”正是这个数字城市的完整地图和建筑图纸。它是整部规范中篇幅最浩瀚、信息量最密集的部分，详细定义了USIM中每一个文件的结构、内容和属性。为了避免在这座信息迷宫中迷失方向，我们将首先鸟瞰其整体设计哲学，然后从根目录（MF层）出发，最终进入USIM应用的核心区域（ADF层），并对其中最重要的几个“地标建筑”——基础文件（EFs）进行精细解剖。

1. 数字城市的宏伟蓝图：USIM文件系统概览

在深入具体文件之前，理解USIM的文件系统层级结构（File System Hierarchy）至关重要。这套结构遵循了ISO/IEC 7816-4标准，为数据的组织、访问和安全管理提供了坚实的基础。

This clause specifies the Efs for the 3GPP session defining access conditions, data items and coding. A data item is a part of an EF which represents a complete logical entity…

规范开篇就点明，本章是关于“EFs（基本文件）”的规格说明。我们可以将整个UICC（SIM卡）想象成一个高度结构化的微型硬盘，其组织方式如下：

  • MF (Master File - ‘3F00’): 唯一的根目录，是所有文件和目录的顶级父节点。如同操作系统的C:\或/根目录，它是文件寻址的起点。

  • DF (Dedicated File): 专用文件，相当于操作系统中的“文件夹”。DF用于对功能相关的文件进行逻辑上的分组。例如，DF_TELECOM存放与传统电信业务相关的文件，而ADF_USIM（它本身也是一个DF）则专门存放USIM应用相关的所有文件。

  • EF (Elementary File): 基本文件，是真正存储数据的单元，相当于文件夹里的具体“文件”。每个EF都有其特定的功能和数据结构。

这种 MF → DF → EF 的三层树状结构，构成了USIM文件系统的骨架。它使得数以百计的文件能够被有序地组织起来，便于手机（ME）通过标准化的路径进行寻址和访问。

此外，每个文件都拥有一套“属性”，如同文件的“身份证”，定义了它的特性：

  • 文件标识符 (File ID): 一个2字节的唯一ID，是文件的“门牌号”。

  • 短文件标识符 (SFI): 一个可选的1字节“快捷方式”，允许手机通过更短的指令快速访问常用文件。

  • 文件结构: 包括透明文件（Transparent，作为一个整体的二进制数据块）、线性固定文件（Linear Fixed，由N条等长的记录组成）、循环文件（Cyclic，记录循环覆盖写入）。

  • 访问条件: 定义了对文件进行读、写、增、删等操作所需满足的安全条件，如需要验证PIN码、PIN2码，或需要运营商级别的ADM权限。

理解了这套宏观架构，我们就可以开始我们的探索之旅了，第一站，便是这座“数字城市”的中心广场——MF层。

2. 城市中心广场：4.1 Contents of the EFs at the MF level (MF层文件内容)

MF（主文件）是UICC文件系统的根，其本身和其下属的一些通用文件（如EF_DIR - 应用目录文件，EF_ICCID - 卡片物理序列号文件）是由更上层的规范 TS 31.101 定义的。TS 31.102作为USIM应用的专门规范，在这里只对一个与USIM应用行为相关的MF层文件功能进行了补充说明。

The information in EFPL may be used by the ME for MMI purposes.

This information may also be used for the screening of Cell Broadcast messages in a preferred language…

这里提到的EF_PL (Preferred Languages) 是一个位于MF层的文件。它存储了用户偏好的语言列表。TS 31.102在此强调了它的两个作用：

  1. MMI (Man-Machine Interface) 用途: 手机可以在用户界面上使用这个语言偏好。例如，在USIM应用被完全激活之前，手机可能会显示一些初始信息（如“请输入PIN码”），此时就可以参考EF_PL来决定使用哪种语言。

  2. 小区广播消息筛选 (Screening of Cell Broadcast messages): 小区广播（CB）可以用于发送天气预警、公共通知等信息。手机可以利用EF_PL中的语言列表，只接收和显示与用户偏好语言匹配的广播消息，过滤掉其他语言的信息。

场景化举例：

李想拿到的是一张国际卡，EF_PL中可能存储了”en”（英语）和”zh”（中文）。当他首次将卡插入手机，手机在还未完全初始化USIM应用时，可能会弹出一个欢迎界面。此时，ME读取MF下的EF_PL，发现有中文选项，于是友好地显示了“欢迎使用”。之后，当他所在区域发布了一条同时包含英文和日文的小区广播预警时，他的手机会根据EF_PL，只接收并显示那条英文的预警，而自动忽略日文信息。

值得注意的是，EF_PL提供的是一个通用的、跨应用的语言偏好。在USIM应用内部，还有一个功能更强、优先级更高的语言文件，那就是我们接下来要探索的EF_LI。

3. USIM应用的核心区：4.2 Contents of files at the USIM ADF level (USIM ADF层文件内容)

现在，我们正式从“城市中心广场”（MF）进入了这座城市最繁华的核心CBD——ADF USIM (USIM Application Dedicated File)。这里存放着实现3G、4G、5G网络接入和相关业务所需的所有核心数据。我们的探索将从最基础的两个文件开始。

The Efs in the USIM ADF contain service and network related information.

The File Ids ‘6F1X’ (for Efs), ‘5F1X’ and ‘5F2X’ (for DFs) with X ranging from ‘0’ to ‘F’ are reserved under the USIM ADF for administrative use by the card issuer.

这段引文为我们揭示了ADF内部的命名约定，‘6F’开头的ID通常分配给EF，而’5F’开头的则分配给DF，并且’1X’和’2X’系列被保留给发卡方用于内部管理。

3.1 沟通的起点：4.2.1 EF_LI (Language Indication - 语言指示)

这是手机进入ADF后首先要关注的文件之一，它直接关系到李想后续的交互体验。

This EF contains the codes for one or more languages. This information, determined by the user/operator, defines the preferred languages of the user in order of priority. This information may be used by the ME for MMI purposes.

深度解析：

EF_LI与MF层的EF_PL功能相似，但有本质区别：

  • 优先级更高: 在USIM应用会话期间，手机应 优先使用EF_LI 来确定显示语言。EF_PL更多是作为备用或在应用选择前的通用指示。

  • 带有顺序: EF_LI中的语言列表是 按优先级排序的。排在第一位的是用户的首选语言。

  • 用户/运营商可配: 这个列表的内容可以由用户通过手机菜单设置，也可以由运营商在发卡时预置。

文件结构与编码剖析

为了深入理解，我们必须像工程师一样，仔细审视规范中定义的文件“图纸”。

表 4.2.1-1: EF_LI 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F05’ |

| SFI | ‘02’ |

| Structure | Transparent |

| File size | 2n bytes, (n ≥ 1) |

| Update activity | Low |

| Access Conditions | |

| READ | ALW (Always) |

| UPDATE | PIN |

| DEACTIVATE | ADM |

| ACTIVATE | ADM |

字节内容

| 字节 | 描述 | M/O | 长度 |

| :--- | :--- | :--- | :--- |

| 1 to 2 | 第1语言代码 (最高优先级) | M | 2 bytes |

| 3 to 4 | 第2语言代码 | O | 2 bytes |

| … | … | O | … |

| 2n-1 to 2n| 第N语言代码 (最低优先级) | O | 2 bytes |

逐项解读：

  • Identifier & SFI: ‘6F05’是它的固定地址，‘02’是它的快捷访问代码。

  • Structure: 透明文件，意味着手机需要一次性读取整个文件内容，然后自行解析。

  • File size: 2n字节，因为每个语言代码占用2个字节。

  • Access Conditions:

    • READ权限是ALW（总是允许），意味着任何时候手机都可以读取语言偏好，无需用户输入PIN。这是合理的，因为显示语言是基础功能。

    • UPDATE权限是PIN，意味着李想要修改语言偏好时（通常通过手机的设置菜单），需要先通过PIN码验证用户身份。

    • DEACTIVATE/ACTIVATE权限是ADM，意味着只有运营商能停用或启用这个文件本身。

编码细节：

each language code is a pair of alpha-numeric characters, defined in ISO 639. Each alpha-numeric character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in TS 23.038 with bit 8 set to 0.

  • 每个语言代码是两个字母，遵循ISO 639标准（例如，“en”代表英语，“zh”代表中文，“fr”代表法语）。

  • 每个字母使用“SMS默认7位编码”方案，但存储为1个字节，且第8位（MSB）设为0。

场景化举例：

李想在手机设置里，将首选语言设为中文，第二语言设为英文。此时，手机会向USIM发起一个UPDATE BINARY命令，更新EF_LI文件。更新后的文件内容（十六进制）可能如下：

'7A 68 65 6E'

  • '7A 68': “zh”（中文）的编码。

  • '65 6E': “en”（英语）的编码。

下次开机，手机读取到这个文件，就会将系统语言设置为中文。如果中文资源不可用，则会使用备选的英文。

3.2 身份的核心：4.2.2 EF_IMSI (International Mobile Subscriber Identity)

这是USIM的“心脏”，存储着用户的根本身份。

This EF contains the International Mobile Subscriber Identity (IMSI).

深度解析：

IMSI是在全球移动通信网络中唯一标识一个用户的号码，通常为15位数字。它由三部分组成：

  • MCC (Mobile Country Code): 移动国家码，3位，如中国的460。

  • MNC (Mobile Network Code): 移动网络码，2或3位，用于区分国内的不同运营商，如中国移动的00。

  • MSIN (Mobile Subscriber Identification Number): 移动用户识别号码，在运营商内部唯一标识用户。

IMSI是极为敏感的信息。一旦泄露，攻击者可能利用它来追踪用户位置或发起其他攻击。因此，在实际通信中，网络在第一次认证成功后，会立刻给手机分配一个临时的GUTI，后续所有通信都使用GUTI，从而隐藏真实的IMSI。

文件结构与编码剖析

表 4.2.2-1: EF_IMSI 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F07’ |

| SFI | ‘07’ |

| Structure | Transparent |

| File size | 9 bytes |

| Update activity | Low |

| Access Conditions | |

| READ | PIN |

| UPDATE | ADM |

| DEACTIVATE | ADM |

| ACTIVATE | ADM |

字节内容

| 字节 | 描述 | M/O | 长度 |

| :--- | :--- | :--- | :--- |

| 1 | IMSI长度 | M | 1 byte |

| 2 to 9 | IMSI | M | 8 bytes |

逐项解读：

  • File size: 固定的9字节。

  • Access Conditions:

    • READ权限是PIN。手机需要读取IMSI来发起网络注册，而这一敏感操作必须在用户通过PIN码验证后才能进行。

    • UPDATE权限是ADM。这一点至关重要，它意味着用户的根本身份标识绝对不允许用户或手机自行修改，只有运营商有权在个人化阶段写入。这从根本上保证了身份的不可篡改性。

编码细节 (重中之重)：

Coding: - according to TS 24.008. … If a network operator chooses an IMSI of less than 15 digits, unused nibbles shall be set to ‘F’.

IMSI的编码方式是一种紧凑的BCD（Binary-Coded Decimal）变体，将两个十进制数字压缩到一个字节中。

  • 字节1: IMSI长度

    这个字节表示后面IMSI数据占用的字节数，通常是8。

  • 字节2-9: IMSI本体 (8字节)

    这8个字节用来存储15位IMSI数字。编码规则遵循TS 24.008，非常精巧：

    • 每个字节的高4位（b8-b5）存储一个数字，低4位（b4-b1）存储另一个数字。

    • 但是顺序是颠倒的：低4位存储奇数位的数字，高4位存储偶数位的数字。

    • 字节2的低4位存储IMSI的第1位数字，高4位存储IMSI的第2位数字。

    • 字节3的低4位存储IMSI的第3位数字，高4位存储IMSI的第4位数字，以此类推。

    • 由于IMSI是15位（奇数），最后一个数字（第15位）将占用字节9的低4位，而高4位将用'F'来填充。

场景化举例：

假设李想的IMSI是 460001234567890。我们来看它如何被编码成这8个字节：

  • 字节2: 第1位是4，第2位是6。编码为 64 (十六进制)。

  • 字节3: 第3位是0，第4位是0。编码为 00。

  • 字节4: 第5位是0，第6位是1。编码为 10。

  • 字节5: 第7位是2，第8位是3。编码为 32。

  • 字节6: 第9位是4，第10位是5。编码为 54。

  • 字节7: 第11位是6，第12位是7。编码为 76。

  • 字节8: 第13位是8，第14位是9。编码为 98。

  • 字节9: 第15位是0，后面没有数字了。编码为 F0。

所以，EF_IMSI文件中存储的IMSI数据（字节2-9）将是（十六进制）：

64 00 10 32 54 76 98 F0

当李想的手机读取到这串数据后，就会按照相反的规则，将其准确地解码为15位的IMSI号码460001234567890，然后用它（或由它生成的SUCI）向网络发起第一次“身份宣告”。

总结：从语言和身份开始的旅程

通过对第4章的宏观介绍，以及对EF_LI和EF_IMSI这两个 foundational 文件的深度剖析，我们已经正式踏入了USIM数据世界的内部。

我们看到，EF_LI通过标准化的语言代码和优先级排序，为人机交互提供了清晰的指引，是优化用户体验的第一步。而EF_IMSI则通过其唯一的、不可篡改的编码，并由严格的ADM权限守护，构成了用户在移动通信世界中一切行为的身份根源。其精巧的BCD编码方式，也体现了在存储资源极其有限的智能卡上，标准制定者对空间效率的极致追求。

李想的数字身份之旅，正是从这两个文件的正确读取和解析开始的。接下来，手机将继续读取更多的文件，以获取安全密钥、服务列表、网络偏好等信息，为一次完整的、安全的通信会话做准备。在后续的文章中，我们将继续沿着TS 31.102的地图，探索USIM中更多功能各异、设计精妙的文件。

FAQ环节

Q1：MF层和USIM ADF层有什么关系？为什么不把所有文件都放在一个地方？

A1：MF（主文件）是整个UICC卡的根目录，而USIM ADF（应用专用文件）是位于MF下的一个“文件夹”，专门用于存放USIM这个应用的所有相关文件。将文件分层存放是为了实现“应用隔离”。一张UICC上可能不止USIM一个应用，还可能有银行卡应用、交通卡应用等。每个应用都有自己的ADF。这种结构确保了USIM应用的数据不会与银行卡应用的数据混淆，各自拥有独立的文件空间和安全域，这是UICC作为多应用平台的基础。

Q2：EF_PL（在MF层）和EF_LI（在ADF层）都与语言有关，它们在使用上有什么区别？

A2：主要区别在于作用域和优先级。EF_PL位于MF层，是卡级别的通用语言偏好，作用范围更广，但优先级较低。它可以在任何应用（USIM, ISIM等）被选择之前，为ME提供一个初步的语言参考。而EF_LI位于USIM ADF内，是专属于USIM应用的、带优先级排序的语言列表。一旦USIM应用被激活，ME应该优先使用EF_LI来确定界面语言，只有在EF_LI不可用或不包含ME支持的语言时，才回退到使用EF_PL。

Q3：为什么EF_IMSI的读取权限是PIN，而更新权限是ADM？

A3：这是基于“最小权限”和“责任分离”的安全原则。读取（READ） 权限设为PIN，是因为手机在发起网络注册时必须获取IMSI，这是一个正常操作，但由于IMSI是敏感信息，需要得到用户本人（通过PIN码）的授权。更新（UPDATE） 权限设为ADM（行政管理），是因为IMSI是运营商分配给用户的唯一身份标识，与计费、签约等后台系统强绑定。如果允许用户或手机随意修改，将导致整个身份和计费体系的混乱。因此，修改IMSI的权限被严格限制在运营商手中。

Q4：规范表格中常出现的SFI（Short File Identifier）是什么？它有什么用？

A4：SFI是文件ID（File ID）的一个“别名”或“快捷方式”。文件ID是一个2字节的地址，而SFI是一个1字节（通常是5 bit）的短地址。在一些APDU命令中，可以通过指定SFI来代替完整的文件ID来选取文件。这样做的好处是提高效率，因为指令更短。规范通常会为最常用、最关键的文件（如EF_IMSI, EF_LI）分配一个SFI，方便ME快速访问。

Q5：为什么15位的IMSI号码要用那么复杂的“奇偶位-半字节”方式编码，而不是直接存为字符串？

A5：这是为了极致地节省存储空间。在智能卡早期，存储资源非常宝贵。如果将15位数字存为字符串，每个数字占一个字节，需要15个字节。而采用BCD（二进制编码的十进制）编码，每个数字只用4个比特（半个字节），15个数字只需要7.5个字节。规范采用的这种打包BCD方式，将两个数字打包进一个字节，最终用8个字节就存储了15位数字和一个半字节的填充符’F’，相比字符串存储节省了近一半的空间，在资源受限的环境下是非常高效的设计。

关系图谱