51学通信

深度解析 3GPP TS 31.102：4.2.70 EFURI (URI拨号) & 统一资源标识符的崛起

16分钟阅读

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

深度解析 3GPP TS 31.102：4.2.70 EFURI (URI拨号) & 统一资源标识符的崛起

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.70 EFURI (URI)”的核心章节，旨在为读者深入剖析随着通信网络向全IP化演进，USIM卡是如何超越传统的数字电话号码，引入EFURI文件来拥抱URI（统一资源标识符）这一更通用、更强大的寻址方式，从而为VoLTE/VoNR、富媒体通信等IP业务提供原生支持。

在我们之前对USIM电话本体系的探索中，所有的“地址”都是基于一个共同的基础——E.164电话号码（即我们熟悉的、由0-9数字组成的手机号或固定电话号）。EFADN、EFFDN、EFSDN等文件，其核心都是存储和管理这些数字串。

然而，随着4G/VoLTE和5G/VoNR的普及，我们的通信世界正在经历一场深刻的变革：从电路交换（CS）全面转向IP多媒体子系统 (IMS)。在IMS这个基于IP的“新世界”里，用户的身份和寻址方式，不再仅仅是一个电话号码，而是一个更通用、更强大的概念——URI (Uniform Resource Identifier，统一资源标识符)。

我们的主角“李想”，他现在使用的已经不仅仅是电话号码了。他的联系方式可能是一个SIP URI (如 sip:[email protected])，或者一个Tel URI (如 tel:+8613800001111)。他发起一次VoLTE高清通话，其本质是在IMS网络中，从他自己的URI向对方的URI发起一次SIP会话。

为了让USIM这个传统的“身份证”能够适应IMS这个“新世界”，3GPP必须为其引入存储和管理URI的能力。EFURI文件的诞生，正是这一演进的直接产物。

EFURI，全称 Uniform Resource Identifier。它的使命，就是在USIM的各类号码簿（如FDN, SDN, MBDN等）中，为那些非数字的、基于URI的联系方式提供一个标准的存储空间。

1. “IP世界的地址簿”：EFURI的核心价值

EFURI的核心价值在于，它将USIM的寻址能力从单一的E.164数字域，扩展到了广阔的URI字符域，为IMS时代的IP通信业务提供了原生的数据模型支持。

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

This EF contains URIs for Fixed Dialling, Barred Dialling, Mailbox Dialling and Service Dialling Numbers.

这段原文揭示了EFURI的关键特性：

  1. 服务关联: 它的存在与EF_UST中的服务n°61（URI支持）相关联。

  2. 内容核心: 存储URI。

  3. 广泛的“插件”角色: 它不是一个独立的新电话本，而是作为**现有电话本（FDN, BDN, MBDN, SDN）的“扩展”**而存在的。它为这些原本只能存储数字号码的文件，增加了存储URI地址的能力。

EFURI的联动工作机制

EFURI与EFFDN等主文件的关系，是一种典型的“主-从”链接模式，类似于我们之前探讨的EFEXT扩展文件。

  1. URI联系人的存储: 李想的公司为所有员工分配了SIP URI作为内部通信方式。IT管理员需要将CEO的SIP URI (sip:[email protected]) 添加到所有员工手机的“固定拨号（FDN）”列表中。

    • 这个URI是一个字符串，无法直接存入EFFDN的BCD号码字段。

    • 管理员首先在EFURI中找到一条空闲记录（例如，第8条记录），并将sip:[email protected]这个字符串写入。

    • 然后，在EFFDN中创建一条新记录。在这条记录中，号码字段可能被留空或填充特殊值，但最重要的，是将其**Extension record identifier**（或其他类似的指针字段）指向EFURI的第8号记录。

  2. URI拨号的执行:

    • 员工尝试拨打一个SIP URI sip:[email protected]。

    • 手机的拨号控制逻辑启动，开始检查FDN规则。

    • 手机遍历EFFDN列表。对于每一条记录，它不仅检查其号码字段，还会检查其指针字段。

    • 当检查到CEO那条记录时，手机发现其号码字段为空，但指针指向了EFURI的第8条记录。

    • 手机随即读取EFURI的第8条记录，得到sip:[email protected]。

    • 手机将用户拨打的sip:[email protected]与从EFURI中读出的sip:[email protected]进行比对。

    • 这个比对过程，不再是简单的数字前缀匹配，而是遵循RFC 3261等SIP标准中定义的URI匹配规则（例如，大小写不敏感、参数处理等）。

通过这种“指针”机制，EFURI为所有传统的、基于数字的拨号控制文件，无缝地“嫁接”上了处理URI的能力。

2. 灵活的“文本框”：EFURI文件结构与编码剖析

EFURI的设计专注于存储可变长度的字符串，因此采用了线性固定文件结构，但其内部记录的有效长度是可变的。

2.1 文件结构

表 4.2.70-1: EFURI 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6FCD’ |

| Structure | Linear Fixed |

| Record length| X bytes |

| Access Conditions| READ: PIN, UPDATE: PIN2/PIN/ADM (取决于关联的主文件) |

记录内容 (X bytes)

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

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

| 1 | URI type (URI类型) | M | 1 byte |

| 2 to X | URI | M | X-1 bytes |

关键特性解读：

  • Access Conditions: EFURI的更新权限是动态的，它继承了其“主文件”的权限。

    • 如果一条EFURI记录被EFFDN或EFBDN引用，那么对这条记录的修改就需要PIN2授权。

    • 如果它被EFSDN引用，则需要ADM权限。

    • 如果被EFADN（个人电话本）引用，则只需要PIN权限。

    这种权限继承机制，确保了URI数据的安全性与其所属的业务逻辑保持一致。

  • URI type (1 byte):

    This byte indicates the type of the URI.

    ‘01’: SIP URI

    ‘02’: TEL URI

    这个字节明确了存储的URI的类型。SIP URI（如 sip:user@host）和 TEL URI（如 tel:+1-201-555-0123）是IMS中最常见的两种URI。这个类型字段，可以指导手机使用正确的解析和比较算法。

  • URI (X-1 bytes):

    This contains a URI according to RFC 3986. The URI is coded as an UTF-8 string… Unused bytes shall be set to ‘FF’.

    这部分是真正的URI字符串，采用UTF-8编码，具有良好的国际化支持。记录中未使用的部分用'FF'填充。

3. EFURI与现代电话本的融合

EFURI的出现，是USIM电话本体系走向“富媒体化”和“IP化”的第一步。它标志着USIM联系人的“地址”不再局限于电话号码。

  • EFURI: 解决了在管控类号码簿（FDN/BDN/SDN）中存储URI的问题。

  • 后续演进: 在EFURI的基础上，3GPP进一步为个人电话本（DF_PHONEBOOK）也引入了更强大的URI支持能力。例如，通过在EFPBC（电话本控制）中增加字段，可以直接将一条EFADN记录与一条EFURI记录关联起来。

这使得李想可以在他的USIM卡联系人“王教授”的名下，不仅存储他的手机号，还可以同时存储他的SIP工作号、个人Email URI等多个IP时代的联系方式。USIM电话本由此从一个简单的“号码簿”，演变为了一个多维度的“联系人档案”。

总结：迈向IP时代的“地址升级”

EFURI文件是USIM为了适应通信网络从CS向IMS/IP全面演进而进行的一次至关重要的“底层升级”。它虽然只是一个简单的文本存储文件，但其引入的意义深远。

  • 打破了数字的桎梏: 使得USIM的寻址能力不再局限于E.164数字号码，能够原生支持SIP URI, Tel URI等更通用、更具扩展性的IP时代寻址方式。

  • 保障了IP业务的策略管控: 通过与FDN/BDN等文件的联动，将传统的拨号控制策略，无缝地延伸到了VoLTE/VoNR等IP语音业务上，确保了企业通信策略在IP时代的延续性。

  • 优雅的向后兼容设计: 采用“主文件+指针+扩展文件”的模式，在不改变原有EFFDN等文件核心结构的前提下，为其“赋能”了处理URI的能力，展现了卓越的向后兼容设计。

对于李想而言，当他使用公司内网的SIP软电话，发现自己只能呼叫地址簿内的同事，而无法随意呼叫外部SIP地址时，他所体验到的这种IP通信环境下的“固定拨号”，其背后的技术基石，正是由EFFDN和EFURI共同构筑的。EFURI的出现，确保了USIM这张诞生于电路交换时代的“旧船票”，依然能登上IMS这条驶向全IP未来的“新客船”。

FAQ环节

Q1：URI是什么？它和我们上网用的URL有什么区别？

A1：URI（统一资源标识符）是一个更宽泛的概念，URL（统一资源定位符）是URI的一个子集。简单来说，URI负责“识别”一个资源，而URL不仅识别它，还告诉了我们“如何找到”它。

  • sip:[email protected] 是一个URI，它识别了一个SIP用户，但没说服务器在哪。

  • http://www.example.com/index.html 是一个URL（也是一个URI），它不仅识别了index.html这个页面，还告诉我们通过HTTP协议，在www.example.com这个主机上可以找到它。

在IMS通信中，我们主要使用URI（如SIP URI, Tel URI）来作为用户的“通信地址”。

Q2：EFURI可以存储电子邮件地址（mailto: URI）或网页地址（http: URI）吗？

A2：从技术上讲，EFURI的URI字段可以存储任何符合RFC 3986的URI字符串，其URI type字段也有“RFU”（预留）值，可以被扩展来支持mailto:或http:。然而，EFURI的核心设计目标是服务于可发起通信会话的URI，主要是SIP和Tel URI，并与拨号控制（FDN/BDN）联动。存储一个网页地址在EFURI中，并将其与FDN关联，在逻辑上是没有意义的，因为你无法“拨打”一个网页。存储这类信息的更合适位置，是个人电话本中专门的“网站”或“电子邮件”字段。

Q3：EFURI和EFEXT系列文件有什么区别？它们都是“扩展”文件。

A3：它们都属于“扩展”机制，但扩展的内容和目的完全不同。

  • EFEXT系列: 其目的是解决**“长度”问题。它存储的是主记录中放不下的同类型**数据（如超长的BCD数字号码）。它只是主记录字段的一个“加长段”。

  • EFURI: 其目的是解决**“类型”问题。它存储的是与主记录字段不同类型**的数据（即从数字变成了字符串URI）。它为主记录提供了一个“地址格式”的升级。

Q4：为什么EFURI的更新权限是可变的（PIN2/PIN/ADM）？

A4：因为EFURI是一个“公共服务”文件，它可以被多个具有不同安全要求的“主文件”所引用。它的权限模型遵循“谁引用，谁负责”的原则。如果一条EFURI记录存储的是一个FDN（固定拨号）的SIP地址，那么这条记录的安全性就应该和FDN本身一样高，因此需要PIN2来保护。如果它存储的是一个个人电话本联系人的SIP地址，那么只需要PIN级别的保护就足够了。这种继承式权限的设计，非常灵活且安全。

Q5：EFURI的引入，是否意味着USIM卡可以脱离电话号码，只使用SIP URI来进行通信？

A5：理论上是的。一个纯IMS环境下的用户，可以只有一个Public User Identity (IMPU) 是SIP URI格式，而没有分配传统的E.164号码（MSISDN）。他的USIM卡中可以只有EF_IMSI（作为接入网络的底层身份）和EFIMPU（存储其SIP URI），而EFMSISDN可以为空。他所有的通信，无论是发起还是接收，都将基于SIP URI进行。EFURI的存在，正是为这张USIPM卡的电话本、拨号控制等上层功能，能够在这种“纯IP”环境中正常工作，提供了数据基础。

关系图谱