51学通信

深度解析 3GPP TS 31.102：4.2.29 EFSDN (业务拨号号码)

16分钟阅读

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

深度解析 3GPP TS 31.102：4.2.29 EFSDN (业务拨号号码)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.29 EFSDN (Service Dialling Numbers)”的核心章节，旨在为读者深入剖析在普通的电话本（EFADN）之外，USIM卡中这张特殊的“VIP号码簿”是如何为运营商的增值业务提供便捷入口，并与eCall等关键功能紧密关联的。

在我们之前的探索中，已经熟悉了存储“我的号码”的EFMSISDN和存储“朋友号码”的EFADN。然而，在移动通信的世界里，还有一类特殊的号码——它们不是指向某个人，而是指向某项服务。例如，查询话费的10086，预订酒店的服务热线，或是航空公司客服中心。

为了方便用户快速访问这些常用的服务号码，并为运营商提供一个统一的、可管理的业务入口列表，3GPP规范设计了EFSDN文件。

EFSDN，全称 Service Dialling Numbers，即“业务拨号号码”。它就像是USIM卡内置的一本“黄页”或“快速拨号列表”，专门用于存储由运营商预置的各类服务号码。对于我们的主角“李想”来说，当他在手机联系人中看到一个名为“话费查询”或“移动客服”的预存条目时，这个条目很可能就来自EFSDN。

更重要的是，EFSDN不仅仅是一个简单的号码簿。随着技术演进，它还被赋予了更为重要的使命，成为了承载 eCall（紧急救援呼叫） 相关号码的关键文件，构成了智能汽车时代“生命线”的一部分。

1. “运营商的快捷方式”：EFSDN的核心价值

EFSDN的核心价值在于提供一个由运营商控制的、标准化的增值业务号码入口，提升用户便利性，并为特殊业务（如eCall）提供可靠的号码来源。

If service n° 4 and or service n° 89 is “available”, this file shall be present.

This EF contains special service numbers (SDN) and/or the respective supplementary service control strings (SSC). … If the service n° 89 is available this file will contain the eCall test and reconfiguration numbers that are used by an UE in eCall and normal service mode.

这段原文揭示了EFSDN的多重身份：

  1. 服务关联: 它的存在与EF_UST中的服务n°4（SDN）和/或服务n°89（eCall数据）相关联。

  2. 通用业务入口: 存储运营商希望推广的“特殊服务号码 (special service numbers)”。这可以是客服、信息查询、业务办理等各类短号码或完整号码。

  3. eCall生命线: 当支持eCall功能时 (service n° 89)，EFSDN将必须包含用于eCall测试和重新配置的专用号码。

与普通电话本EFADN的区别：

  • 所有权不同: EFADN由用户管理，存储用户的私人联系人。而EFSDN由运营商管理（ADM权限），存储官方的服务号码，用户通常无法自行修改。

  • 用途不同: EFADN用于社交，而EFSDN用于业务交互。

  • 显示方式不同: 手机可能会将EFADN的内容显示在“联系人”应用的主列表中，而将EFSDN的内容显示在一个独立的“SIM卡联系人”或“服务号码”的特殊分组中。

场景化举例：

李想拿到一张新的USIM卡，插入手机后，他打开联系人应用。

  • 他发现联系人列表不是空的，里面已经预存了几个号码：“移动客服 10086”、“话费查询 1008611”、“国际漫游 1008688”。这些号码并非李想自己存储的，它们正是手机在初始化时从EFSDN文件中读取并显示出来的。

  • 这种预置方式极大地便利了用户，尤其是对于不熟悉运营商服务代码的新用户。

2. 熟悉的结构，特殊的使命：EFSDN文件结构与编码剖析

EFSDN在结构上再次体现了3GPP的“复用”思想，其记录结构与EFADN和EFFDN高度相似。

2.1 文件结构

EFSDN是一个线性固定文件，每一条记录代表一个服务号码。

表 4.2.29-1: EFSDN 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F49’ |

| Structure | Linear Fixed |

| Record length| X+14 bytes |

| Update activity| Low |

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

记录内容 (X+14 bytes)

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

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

| 1 to X | Alpha Identifier (服务名称) | O | X bytes |

| … | … | … | … |

| X+13 | Capability/Configuration2 Record Identifier | M | 1 byte |

| X+14 | Extension3 Record Identifier | M | 1 byte |

关键特性解读：

  • Access Conditions: 这是EFSDN与EFADN的关键区别。EFSDN的UPDATE权限被严格设置为ADM。这意味着这个“官方黄页”的内容由运营商全权控制，确保了其权威性和准确性，用户无法随意篡改。

  • 记录结构复用:

    For contents and coding of all data items see the respective data items of the EFADN… with the exception that extension records are stored in the EFEXT3 and capability/configuration parameters are stored in EFCCP2.

    规范明确指出，EFSDN的字段编码与EFADN基本相同，但也存在细微但重要的差别：

    • 扩展文件不同: EFSDN使用EFEXT3来存储超长号码，而EFADN用EFEXT1，EFFDN用EFEXT2。这种分离设计，使得不同功能的号码列表，其扩展记录也存储在不同的“篮子”里，避免了相互干扰。

    • 能力配置文件不同: EFSDN中的号码可以关联到EFCCP2（Capability Configuration Parameters 2）中的参数，而EFADN关联的是EFCCP1。这允许运营商为服务号码定义不同于普通通话的网络和承载能力要求。

2.2 eCall的特殊角色

当车辆发生严重碰撞时，车载的eCall系统会自动被激活，并尝试与公共安全应答点（PSAP）建立紧急语音通话，同时通过数据通道上报事故位置、车辆信息等关键数据。这个“自动救命”电话，其拨打的号码正是来源于EFSDN。

If eCall and normal calls are supported, then the last two entries of EFSDN shall contain the eCall test number and the eCall reconfiguration number respectively.

规范对eCall在EFSDN中的存储位置做了强制性规定：

  • EFSDN的倒数第二条记录: 必须存储 eCall测试号码。车辆在出厂或年检时，需要使用这个号码来测试eCall系统是否能正常工作。

  • EFSDN的最后一条记录: 必须存储 eCall重新配置号码。如果eCall的相关参数需要更新，车载终端可以通过拨打这个号码，与后台服务器建立连接，进行远程配置。

场景化举V2X：

李想购买了一辆支持eCall功能的新车，车内集成了一个车载通信单元（TCU），其中插入了一张专用的USIM卡。这张卡的EFSDN文件中：

  • 前面的记录可能存储了“道路救援”、“4S店服务”等普通车联网服务号码。

  • 最后两条记录，则雷打不动地存储着由国家应急部门和运营商共同规定的eCall测试和重配号码。

当车辆发生事故时，TCU会自动从EFSDN读取紧急号码（注意：实际拨打的紧急号码本身可能来自EFECC，而EFSDN更多是提供测试和配置入口，具体实现见5.3.40），并以最高优先级发起呼叫。而维修人员在检修车辆时，则会利用EFSDN中的测试号码，来验证整个eCall链路的健康状况。

EFSDN在这里，从一个提供便利的“黄页”，升格为了保障行车安全的“生命线”的一部分。

总结：从便利到生命的“服务热线”

EFSDN文件通过在USIM中建立一个由运营商管理的“服务号码簿”，巧妙地解决了多个层面的需求。

  • 提升用户便利性: 预置常用服务号码，为用户提供“开箱即用”的便捷体验，降低了用户获取运营商服务的门槛。

  • 强化运营商渠道: EFSDN成为了运营商向用户推广其增值业务的一个标准化的、内置于SIM卡的“快捷方式入口”。

  • 保障关键业务可靠性: 通过为eCall等关键任务业务预留标准化的存储位置，EFSDN确保了这些“生命线”号码的权威性和可靠性，为公共安全提供了坚实的通信基础。

  • 体现了设计的层次性: 通过使用独立的扩展文件（EFEXT3）和能力配置文件（EFCCP2），EFSDN在复用基础结构的同时，又与普通电话本（EFADN）保持了清晰的界限，体现了规范设计的严谨和层次感。

对于李想而言，EFSDN是他手机里那个“永不丢失”的官方服务通讯录。他可能很少意识到，当他按下那个预存的“道路救援”号码时，他正在使用EFSDN提供的服务。而当未来的某一天，他驾驶的智能汽车在危急时刻为他自动呼救时，EFSDN（及其关联的eCall机制）可能将扮演更为关键的“守护者”角色。

FAQ环节

Q1：EFSDN中的号码可以被用户删除或修改吗？

A1：通常不可以。EFSDN的UPDATE权限被设置为ADM，这意味着只有运营商才有权通过后台或OTA方式修改这个列表。这种设计保证了服务号码的权威性和准确性，防止用户误删重要号码（如eCall测试号）或被恶意软件篡改。

Q2：EFSDN、EFFDN和EFADN在记录结构上非常相似，手机如何区分它们？

A2：手机通过它们各自唯一的**文件标识符（File ID）**来区分。EFSDN的ID是6F49，EFFDN是6F3B，而EFADN通常是4FXX（可由卡商自定义）。尽管它们的内部记录格式相似，但由于文件ID不同，手机可以准确地知道自己正在操作的是“服务号码”、“固定拨号号码”还是“普通电话本”，并应用与之对应的不同访问权限和业务逻辑。

Q3：为什么eCall的测试和重配号码要放在EFSDN，而不是更直接的EFECC（紧急呼叫码）？

A3：这是一个功能定位上的区别。EFECC存储的是真正用于发起紧急求救的号码（如112, 911），这些号码在任何情况下都应被立即拨出，连接到公共安全应答点（PSAP）。而eCall的测试号和重配号，其目的并非发起真实的求救，而是用于系统维护和配置。将它们放在EFSDN（服务号码）中，逻辑上更清晰，也避免了与真实紧急号码混淆，防止用户或系统在非测试场景下误拨。

Q4：我的手机通讯录里并没有看到单独的“服务号码”分组，这些号码去哪了？

A4：这取决于手机操作系统（OS）的实现。一些手机OS可能会将EFSDN中的号码与EFADN的号码合并显示在主联系人列表中，并可能用一个特殊图标（如SIM卡图标）加以区分。另一些OS则可能将它们放在一个不那么显眼的位置，如“SIM卡联系人管理”或类似的子菜单中。但无论如何，这些预置的号码数据源头都是EFSDN。

Q5：如果一个服务号码（如10086）同时存在于EFSDN和我的个人电话本EFADN中，手机会如何显示？

A5：手机通常会都显示出来，可能会造成重复条目。在联系人列表中，你可能会看到一个来自EFSDN的、不可编辑的“中国移动客服”，以及一个你自己创建的、可以编辑的“移动客服”。现代智能手机的联系人应用通常有“合并重复联系人”的功能，可以智能地将这两个条目聚合显示，但其底层数据源依然是两个独立的文件记录。

关系图谱