51学通信

深度解析 3GPP TS 31.102：4.2.47 EFEST (启用服务表)

16分钟阅读

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

深度解析 3GPP TS 31.102：4.2.47 EFEST (启用服务表)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.47 EFEST (Enabled Services Table)”的核心章节，旨在为读者深入剖析在USIM卡的能力清单（EF_UST）之下，这张更为精细的“功能开关”表是如何赋予用户对特定高级服务（如FDN、BDN）进行自主启停的控制权，从而实现更灵活、更个性化的通信体验。

在我们之前的探索中，EF_UST（USIM服务表）给我们留下了深刻的印象。它像一张由运营商颁发的“能力证书”，定义了一张USIM卡到底具备哪些服务的“资格”。例如，EF_UST中的服务n°2比特位为1，表示这张卡具备固定拨号（FDN）的能力。

然而，“具备能力”不等于“立即使用”。这就像我们的主角“李想”的手机具备飞行模式，但他只有在乘坐飞机时才会主动去开启它。对于USIM中的一些强力管控功能，如FDN（固定拨号）和BDN（禁止拨号），同样需要一个由用户掌控的“开关”来决定何时启用、何时关闭。

这个用户级的“总开关”，就是EFEST文件。

EFEST，全称 Enabled Services Table，即“启用服务表”。它的使命非常清晰：在EF_UST声明“有能力”的基础上，进一步记录这些能力中有哪些被用户实际“启用 (enabled)”或“激活 (activated)”。

1. “用户手中的开关”：EFEST的核心价值

EFEST的核心价值在于将服务的**“可用性 (Availability)”与“启用状态 (Enabled Status)”**进行分离，从而在运营商的策略配置和用户的日常使用之间建立了一道灵活的缓冲层。

If service n° 2, 6, 34 or 35 is “available” (as indicated in the USIM Service Table), this file shall be present.

This EF indicates which services are enabled. If a service is not indicated as enabled in this table, the ME shall not select the service.

这段原文揭示了EFEST与EF_UST之间紧密的“父子”关系：

  1. 存在前提: EFEST文件并非总是存在。只有当EF_UST中至少有一个需要用户级开关的服务（如服务n°2 FDN, n°6 BDN, n°35 APN控制列表ACL）被激活时，EFEST文件才必须存在。

  2. 功能: 它明确指出哪些服务被用户启用了 (enabled)。

  3. 最终决定权: 即使EF_UST表示某个服务“可用”，但如果EFEST表示它“未启用”，那么手机依然不能使用 (shall not select) 该服务。

两级开关机制：

EF_UST和EFEST共同构成了一个两级开关系统：

  • 第一级开关 (运营商级): EF_UST

    • 由运营商（ADM权限）控制。

    • 决定了一项服务是否“有资格”被使用。这是能力的“天花板”。如果EF_UST中FDN服务为0，那么无论用户做什么，这张卡永远无法使用FDN功能。

  • 第二级开关 (用户级): EFEST

    • 由用户（PIN2权限）控制。

    • 决定了一项“有资格”的服务，当前是否处于**“开启”状态。这是功能的“日常开关”**。

A service which is listed in this table is enabled if it is indicated as available in the USIM Service Table (UST) and indicated as activated in the Enabled Services Tables (EST) otherwise this service is, either not available or disabled.

这段话完美总结了这个逻辑：一项服务最终被“启用 (enabled)”，必须同时满足两个条件：在EF_UST中“可用 (available)” AND 在EFEST中“激活 (activated)”。

场景化举例：

李想希望为家里的老人启用固定拨号（FDN）功能。

  1. 前提检查: 运营商在发卡时，已经在EF_UST中将服务n°2（FDN）设置为“available”(比特位为1)。

  2. 用户操作: 李想在手机设置中找到“固定拨号”，点击“启用”开关。

  3. PIN2验证: 手机提示输入PIN2码，因为EFEST的更新是受PIN2保护的敏感操作。

  4. USIM操作: 李想输入正确的PIN2码后，手机向USIM发送UPDATE BINARY命令，将EFEST文件中对应FDN服务的那个比特位从0修改为1。

  5. 功能生效: 从此刻起，手机在每次拨号前，都会检查EF_UST和EFEST。它发现FDN服务既“可用”又“激活”，于是开始执行FDN的号码匹配逻辑，只允许拨打EFFDN列表中的号码。

当李想临时需要关闭FDN功能时，他只需在设置中关闭开关，手机就会再次用PIN2授权，将EFEST中对应的比特位从1修改回0。

2. 简洁的位图开关：EFEST文件结构与编码剖析

EFEST在设计上与EF_UST如出一辙，同样采用了极致简洁的位图编码。

2.1 文件结构

表 4.2.47-1: EFEST 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F56’ |

| SFI | ‘05’ |

| Structure | Transparent |

| File size | X bytes, (X ≥ 1) |

| Update activity| low |

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

字节内容

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

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

| 1 | Services n°1 to n°8 | M | 1 byte |

| … | … | O | … |

关键特性解读：

  • Access Conditions: 这是EFEST与EF_UST最核心的区别。EFEST的UPDATE权限是PIN2。这正是它作为“用户级开关”的体现。PIN2码的设计，就是为了让服务的管理者（如家长、企业IT管理员）能够控制这些强力功能，而日常使用者（知道PIN码）无法随意开关。

2.2 编码艺术：一对一的映射

EFEST中的比特位，与其控制的服务是一一对应的。

Coding:

  • 1 bit is used to code each service:
  • bit = 1: service activated;
  • bit = 0: service deactivated.

EFEST中定义的服务列表：

| 服务号 | 服务名称 | 关联文件 |

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

| n°1 | Fixed Dialling Numbers (FDN) | EFFDN |

| n°2 | Barred Dialling Numbers (BDN) | EFBDN |

| n°3 | APN Control List (ACL) | EFACL |

| … | (其他未来可能增加的服务) | … |

请注意：EFEST的“服务清单”比EF_UST要短得多。它只包含那些需要用户级启停开关的特定服务。EF_UST中定义的大多数服务，要么是基础功能（一旦可用就应始终可用），要么其启用/禁用由其他机制控制，因此无需在EFEST中列出。

场景化举例（编码）：

假设EFEST的第一个字节，其b1对应FDN，b2对应BDN，b3对应ACL。

  • 初始状态，所有功能都未启用：EFEST的第一个字节为'00'（二进制00000000）。

  • 李想启用了FDN功能：第一个字节变为'01'（二进制00000001），因为b1被置为1。

  • 随后，他又启用了ACL功能：第一个字节变为'05'（二进制00000101），因为b3也被置为1。

手机通过读取这个字节，就能瞬间了解当前所有受EFEST控制的高级服务中，哪些处于开启状态。

3. EFEST的逻辑重要性

EFEST的存在，不仅仅是为了提供一个UI开关。在手机的底层协议栈中，它是一个至关重要的逻辑判断节点。

手机在执行任何与FDN, BDN, ACL相关的操作前，都必须执行一个完整的检查链：

IF (Service_is_Available_in_UST) THEN { IF (Service_is_Activated_in_EST) THEN { // 执行具体的功能逻辑，如读取EFFDN进行号码匹配 } }

这个检查链确保了：

  1. 尊重运营商配置: 手机不会去尝试使用一张根本不具备某项能力的USIM卡的功能。

  2. 尊重用户设置: 手机不会在用户明确禁用了某项功能后，仍然去执行它。

EFEST是用户意图在USIM卡上的最终体现，是手机执行策略的“最后一道指令”。

总结：在授权与使用之间建立桥梁

EFEST文件虽然看似只是EF_UST的一个“影子”，但它在USIM的功能体系中扮演着一个独特的、不可或缺的角色。它在运营商授予的“能力”和用户实际的“意图”之间，建立了一座至关重要的桥梁。

  • 实现了权限分层: 通过EF_UST（ADM权限）和EFEST（PIN2权限）的组合，构建了一个清晰的“运营商授权 → 用户/管理员启用”的两级权限模型。

  • 提升了用户体验的灵活性: 赋予了用户对FDN、BDN等强力管控功能自主启停的权利，使得用户可以根据实际场景（如在家给孩子用，还是自己出差用）灵活地切换手机的“模式”。

  • 保障了功能控制的安全性: 使用比PIN码更高级别的PIN2码来保护，防止了普通使用者对管控策略的随意篡改，确保了功能开关的严肃性。

对于李想而言，EFEST就是他手机设置菜单里那几个高级功能开关在USIM卡中的“物理化身”。每一次他拨动开关，改变的不仅仅是UI上的一个状态，更是EFEST这个文件里一个决定手机后续行为的关键比特位。EFEST让李想从一个只能被动接受USIM能力的用户，升级为了一个可以主动管理和控制这些能力的“高级玩家”。

FAQ环节

Q1：EFEST和服务n°35 EFACL（APN控制列表）有什么关系？

A1：关系与FDN/BDN完全一样。EF_UST中的服务n°35决定了USIM卡是否具备APN控制能力。如果具备，EFEST中的服务n°3（在EFEST中，ACL被分配为第3号服务）则作为用户级的开关，决定这个功能当前是否启用。当ACL功能被启用后，手机在发起数据连接时，就必须检查目标APN是否在EFACL这张“白名单”中。

Q2：如果我把SIM卡换到一部老旧的功能手机上，EFEST还有用吗？

A2：只要那部功能手机遵循3GPP规范，EFEST就依然有效。例如，如果你在智能手机上启用了FDN（即EFEST中FDN位为1），然后把卡换到一部支持FDN的功能手机上，那么这部功能手机在开机读取EFEST后，会发现FDN已处于激活状态，并会立即开始执行固定拨号限制。EFEST的状态是跟卡走的，与手机无关。

Q3：为什么EFEST的更新需要PIN2码，这么麻烦？

A3：这是为了安全。FDN、BDN、ACL都是具有强限制性的功能。一旦启用，会直接改变手机的核心通信行为。使用PIN2码可以确保只有授权的管理者（比如家长、企业IT管理员）才能启停这些功能。如果使用普通的PIN码，那么任何知道开机密码的人（比如孩子、普通员工）都可以轻易地关闭这些限制，从而使管控失效。PIN2为这些功能增加了一道额外的安全门槛。

Q4：EFEST中定义的服务，和EF_UST中的服务号是一样的吗？

A4：不一定。这是一个容易混淆的点。EF_UST中的服务号是全球唯一的、由3GPP分配的。例如，FDN在EF_UST中的编号永远是n°2。而EFEST中也需要一个编号来定位服务，但这个编号是EFEST内部的，与EF_UST的编号没有直接关系。在EFEST的定义中，服务n°1被分配给了FDN。手机在实现时，内部会有一个映射关系：当处理EFEST的第1个服务时，它知道这对应的是EF_UST中的第2项服务。

Q5：如果运营商不支持FDN（EF_UST中FDN位为0），EFEST文件里还会有FDN的开关位吗？

A5：EFEST文件本身可能就不存在。根据规范，EFEST的存在前提是EF_UST中至少有一项需要EFEST控制的服务（如FDN, BDN, ACL）被激活。如果运营商提供的USIM卡，这几项服务在EF_UST中全都是0（不可用），那么这张卡上就不需要也不应该存在EFEST文件。

关系图谱