51学通信

深度解析 3GPP TS 31.102：4.2.37 EFEXT5 (第五扩展文件)

18分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。由于规范中 4.2.35 EFICT (Incoming Call Timer) 和 4.2.36 EFOCT (Outgoing Call Timer) 是对通话时长的累计，其功能与 EFACM 高度相似，且在现代通信中较少独立使用，我们将它们与紧随其后的扩展文件一并进行关联说明。

深度解析 3GPP TS 31.102：4.2.37 EFEXT5 (第五扩展文件)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.37 EFEXT5 (Extension5)”的核心章节，并关联解读EFICT与EFOCT。本文旨在为读者阐明USIM电话本体系中精巧的“扩展”机制，以及EFEXT5是如何作为EFMSISDN和EFOCI的专属“附楼”，来解决超长号码和数据存储问题的。

在USIM这座由文件构成的“数字城市”中，我们已经参观了许多主要的“建筑”，如EFADN（电话本）、EFSMS（短信仓库）等。然而，随着通信业务的日益复杂，这些主建筑的“标准户型”（如记录长度固定）有时会显得捉襟见肘。例如，一个联系人的号码可能超过20位，或者一条通话记录需要附加额外的信息。

为了解决这个问题，3GPP的设计师们引入了一套非常灵活的“扩建”方案——扩展文件 (Extension Files)，即EFEXT系列。这些文件就像是为主建筑修建的“附属空间”或“储藏室”，专门用于存放主记录中放不下的超长数据。

EFEXT5正是这个扩展家族的一员，它的全称是 Extension 5。根据规范，它被指定为两个特定文件的专属扩展：

  1. EFMSISDN (我的号码)

  2. EFOCI (呼出通话信息)

在深入EFEXT5之前，我们先快速回顾一下与通话记录时长相关的EFICT和EFOCT。

1. 关联章节简述：EFICT & EFOCT - 通话时长累加器

  • EFICT (Incoming Call Timer) 和 EFOCT (Outgoing Call Timer) 分别是服务n°9和n°8的一部分。它们的作用非常纯粹：累计呼入和呼出的总通话时长。

  • 它们的结构、编码（3字节二进制整数，单位秒）和工作方式（使用INCREASE命令）与我们之前详细剖析的EFACM（累计通话计量器）几乎完全一样。

  • 可以理解为，EFACM是基于“计费单位”的计数器，而EFICT/EFOCT是基于“秒”的计数器。

在现代智能手机中，通话时长的统计和显示功能通常由操作系统在本地实现，其实时性和灵活性更高。因此，USIM中的EFICT/EFOCT更多地是作为一种标准化的、备用的时长记录机制而存在，其实际使用频率并不高。

现在，让我们回到今天的主角——EFEXT5。

2. “专属储藏室”：EFEXT5的核心价值

EFEXT5的核心价值在于为EFMSISDN和EFOCI提供一个标准化的、可链接的扩展数据存储空间，确保了这两个文件即使在面对超长、复杂数据时，其主记录的结构依然保持简洁和固定。

If service n° 44 is “available”, this file shall be present.

This EF contains extension data of EFICI, EFOCI and EFMSISDN of the USIM application.

请注意：原文描述中提到了EFICI，但从EFICI的文件结构定义（使用EFEXT5）来看，这似乎是一个笔误或版本演进的残留，因为EFICI本身结构中定义的扩展文件通常是EFEXT1或EFEXT2。在本解读中，我们主要关注规范中明确定义的、与EFMSISDN和EFOCI的强关联。

EFEXT5解决了两大类问题：

  1. 超长号码/数据存储: 当EFMSISDN中的本机号码或EFOCI中的去电号码超过20位数字时，主记录的10字节号码字段无法容纳。此时，超出的部分就需要存入EFEXT5。

  2. 附加数据存储 (如子地址): 在一些传统的ISDN网络或企业电话系统中，一个呼叫除了主号码，还可能携带一个“子地址 (Subaddress)”，用于指定分机号或特定的终端设备。这部分附加数据也可以存储在EFEXT5中。

链接机制：

EFEXT5与主文件之间的关系，是通过主文件记录中的Extension5 Record Identifier字段建立的。这个字段就像一个“指针”，它存储了EFEXT5中的一个记录号。

工作流程：

  1. 写入:

    • 手机需要为一个EFOCI条目存储一个25位的电话号码。

    • 手机首先在EFEXT5中找到一个空闲的记录（例如，第7号记录）。

    • 手机将号码的后5位数字存入EFEXT5的第7条记录中，并将其记录类型标记为“附加数据 (additional data)”。

    • 然后，手机在EFOCI的主记录中，存入号码的前20位，并将其Extension5 Record Identifier字段的值设置为'07'。

  2. 读取:

    • 当手机需要完整显示这条25位的通话记录时，它首先读取EFOCI的主记录。

    • 手机发现Extension5 Record Identifier字段的值是'07'，而不是无效值'FF'。

    • 手机立即明白，这条记录有扩展数据。它随即去读取EFEXT5文件的第7条记录。

    • 最后，手机将主记录中的前20位号码和扩展记录中的后5位号码拼接起来，形成并显示出完整的25位号码。

3. 通用扩展模板：EFEXT5文件结构与编码剖析

EFEXT系列文件（包括EXT1, 2, 3, 4, 5…）都遵循一个高度统一的“通用扩展记录”模板。这种设计极大地简化了手机端的实现逻辑，手机可以用一套通用的代码来处理所有类型的扩展文件。

3.1 文件结构

表 4.2.37-1: EFEXT5 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F4E’ |

| Structure | Linear Fixed |

| Record length| 13 bytes |

| Update activity| Low |

| Access Conditions| READ: PIN, UPDATE: PIN, … |

记录内容 (13 bytes)

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

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

| 1 | Record type (记录类型) | M | 1 byte |

| 2 to 12 | Extension data (扩展数据) | M | 11 bytes |

| 13 | Identifier (下一个扩展记录的标识符) | M | 1 byte |

逐项解读：

  • Record length: 固定的13字节。这是一个经过权衡的长度，既能容纳一定量的扩展数据，又不会占用太多USIM空间。

  • Record type (1 byte): 这个字节定义了Extension data字段中存储的是什么类型的数据。

    Coding:

    b1: Called Party Subaddress

    b2: Additional data

    ‘00’ indicates the type “unknown” or “free”.

    • b1=1: 表示存储的是子地址 (Called Party Subaddress)。

    • b2=1: 表示存储的是附加号码数据 (Additional data)。

    • '00': 表示这是一条空闲的、可被覆写的记录。

  • Extension data (11 bytes): 这是真正的“储藏室”。

    • 如果是附加号码数据: 第一个字节（记录的字节2）表示后面实际号码数据的长度，剩余的字节则用BCD码存储号码数字。

    • 如果是子地址: 这11个字节直接存储子地址的信息，其格式遵循TS 24.008。

  • Identifier (1 byte): 这是实现**“链式扩展”的关键。如果11字节的Extension data仍然不够用，这个Identifier字段就可以指向EFEXT5中的另一条**记录，形成一个记录链表。

    Coding: record number of next record. ‘FF’ identifies the end of the chain.

    • 它的值是EFEXT5中的下一个记录号。

    • 'FF'是一个终结符，表示“链到此结束”。

场景化举例（链式扩展）：

假设需要存储一个长达40位的附加号码。

  1. 手机在EFOCI主记录中存入前20位，并将其Extension5 Record Identifier指向EFEXT5的第3号记录。

  2. 在EFEXT5的第3号记录中：

    • Record type: 标记为“附加数据”。

    • Extension data: 存入号码的第21到38位（假设能存18位）。

    • Identifier: 发现号码还没存完，于是指向下一个空闲记录，例如第8号记录。此字段值为'08'。

  3. 在EFEXT5的第8号记录中：

    • Record type: 标记为“附加数据”。

    • Extension data: 存入号码的最后2位（第39、40位）。

    • Identifier: 号码已存完，链结束。此字段值为'FF'。

当手机读取时，它会从EFOCI开始，沿着EFEXT5中记录3 → 记录8这条“藤”，一路“摸瓜”，最终将所有分片的数据拼接成完整的40位号码。

总结：小文件，大智慧的扩展哲学

EFEXT5及其同系列文件，完美地展示了3GPP在USIM标准设计中的一个核心哲学：保持核心数据结构的稳定与简洁，通过标准化的、可链接的扩展机制来应对未来的复杂性。

  • 主次分离: 将高频访问的核心数据（如号码前20位）和低频访问的扩展数据分离开，保证了主文件的访问效率。

  • 结构统一: 所有扩展文件采用统一的记录结构，大大降低了手机端的实现复杂性，一套代码逻辑可以处理所有EFEXT文件。

  • 无限扩展: 链式结构（通过Identifier字段）理论上提供了无限的扩展能力，使得USIM能够从容应对未来可能出现的、任何长度的数据存储需求。

  • 专属指定: 为不同的主文件（EFADN, EFFDN, EFMSISDN等）分配不同的专属扩展文件（EFEXT1, EFEXT3, EFEXT5等），实现了扩展空间的隔离，避免了不同功能之间因争抢扩展记录而产生的冲突。

对于李想而言，他可能永远都用不到超过20位的号码，也用不到子地址功能。但EFEXT5的存在，就像是建筑设计师为他的“数字公寓”预留的承重墙和管道接口。即使今天用不上，但这个标准化的扩展能力，确保了他的USIM在未来的某一天，能够平滑地“加盖楼层”、“扩建房间”，而无需对整个“建筑”进行结构性的大改。这正是优秀标准设计的生命力所在。

FAQ环节

Q1：为什么不同的主文件（EFADN, EFMSISDN等）要使用不同的扩展文件（EFEXT1, EFEXT5）？用一个公共的EFEXT不行吗？

A1：使用专属的扩展文件主要是为了避免数据管理上的冲突和复杂性。如果所有主文件共享一个公共的EFEXT，就会出现“抢占资源”的问题。例如，电话本EFADN可能占用了EFEXT的大量记录来存储长号码，导致EFMSISDN需要存储一个超长本机号码时，找不到空闲的扩展记录。此外，权限管理也会变得复杂。EFADN的扩展记录应该和EFADN一样，由用户通过PIN码控制；而EFMSISDN的扩展记录则可能需要ADM权限。通过分配专属的EFEXT文件，可以实现清晰的资源隔离和权限隔离。

Q2：EFEXT5中记录类型里的“子地址 (Called Party Subaddress)”是什么？现在还常用吗？

A2：子地址是源于传统数字电话网（ISDN）的概念，它在一个主电话号码之后附加额外的信息，用于在该号码下的多个终端之间进行选择。最常见的例子就是公司的总机号+分机号。例如，拨打8888-8888（总机），再拨123（子地址），就能接通123号分机。在IP通信时代，这个功能很大程度上被SIP URI等更灵活的寻址方式所取代，因此在公众移动通信中已非常少见。但USIM作为需要兼容各种网络环境的设备，依然保留了对它的支持。

Q3：扩展记录的链式结构会不会导致读取效率很低？

A3：会的，相比一次性读取，多次跳转读取（Chaining）确实会增加开销和延迟。但这是在空间限制和时间效率之间做出的一个权衡。首先，超长数据本身就是低频事件，为了这种罕见情况而将所有主记录的长度都设计得非常大，是对宝贵的USIM空间的巨大浪费。其次，USIM的读写速度非常快，几次额外的记录读取所增加的延迟（通常在毫秒级）对于用户来说是无感的。因此，采用链式扩展是在保证功能完整性的前提下，一种非常经济和实用的方案。

Q4：如果我删除了EFOCI中一条关联了扩展记录的通话记录，EFEXT5中的记录会怎么样？

A4：理想情况下，手机应该执行“级联删除”。当手机将EFOCI中的主记录标记为无效或删除时，它应该解析该记录的Extension5 Record Identifier字段，找到EFEXT5中所有与之关联的记录链，并将这些记录的Record type都设置为'00'（空闲），从而释放这些扩展空间。如果手机没有实现这个逻辑，这些EFEXT5中的记录就会成为无法被访问的“垃圾数据”，占用宝贵的USIM空间，直到下一次“垃圾回收”（Purge）操作才可能被清理。

Q5：这些扩展文件EFEXT的File ID是如何分配的？

A5：EFEXT系列文件的File ID通常不是固定的，而是像EFADN一样，属于'4FXX'的可变范围，由卡商在个人化时自行分配。手机是通过读取“电话本引用文件”EFPBR来获知这些动态分配的File ID的。EFPBR中定义了整个电话本的结构，包括哪个主文件（如EFADN1）使用了哪个扩展文件（如EFEXT1A），以及它们的具体File ID。手机必须先解析EFPBR这张“地图”，才能准确地找到所有的扩展文件。

关系图谱