51学通信

深度解析 3GPP TS 31.102：4.2.48 EFACL (APN控制列表)

16分钟阅读

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

深度解析 3GPP TS 31.102：4.2.48 EFACL (APN控制列表)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.48 EFACL (Access Point Name Control List)”的核心章节，旨在为读者深入剖析在移动数据通信的世界里，USIM卡是如何通过EFACL这张至关重要的“网络通行证”列表，对手机的数据连接行为进行精细化的“白名单”管控。

在我们之前的探索中，我们已经深入了解了EFFDN（固定拨号号码），它像一道坚实的护栏，限制了手机的语音通话范围。然而，在智能手机时代，数据连接的重要性丝毫不亚于语音通话。我们的主角“李想”，他的手机大部分时间都在通过分组交换（PS）域连接到互联网，享受着上网、社交、视频等丰富多彩的应用。

每一次数据连接的发起，都始于一个关键的步骤：建立PDP上下文（Context）或PDU会话（Session）。在这个过程中，手机必须向网络指明它希望连接的目标网络，这个目标的“名字”，就是APN (Access Point Name)，在5G时代也被称为DNN (Data Network Name)。

例如，连接到公共互联网的APN可能是cmnet（中国移动），连接到企业内网的APN可能是corp.internal。但是，如果允许手机随意连接到任何APN，可能会带来安全风险或产生不必要的费用。特别是在企业和行业应用场景下，IT管理员通常希望严格限制员工手机只能连接到指定的、安全的企业内部网络。

为了实现这种对数据连接的“白名单”管理，3GPP规范设计了EFACL文件。

EFACL，全称 APN Control List，即“APN控制列表”。它的使命非常清晰：定义一个允许手机发起数据连接的APN“白名单”。一旦这项功能被启用，任何不在这个列表中的APN连接请求，都将被手机在本地直接阻止。

1. 数据连接的“门禁”：EFACL的核心价值与工作机制

EFACL的核心价值在于将数据连接的权限控制，从网络侧下沉到了USIM卡侧，为企业和个人用户提供了一个强大、可靠、安全的数据访问控制工具。

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

This EF contains the list of allowed APNs (Access Point Names) or DNNs. If this file is present in the USIM, the Enabled Services Table (EFEST) shall also be present.

从原文中，我们可以提炼出EFACL的关键特性：

  1. 服务关联: 它的存在与EF_UST中的服务n°35相关联，并且它的启用/禁用状态由我们上一章介绍的EFEST文件来控制。

  2. 功能核心: 存储一个允许接入的APN/DNN列表 (list of allowed APNs or DNNs)。

  3. 白名单机制: 它的工作模式是典型的“白名单”。只有名单上的APN才被允许通行。

ACL的工作机制

ACL（APN Control List）的工作流程，构成了EF_UST → EFEST → EFACL 这条完整的控制链：

  1. 能力具备 (UST): 运营商在USIM卡的EF_UST中将服务n°35设为1，表示这张卡具备ACL能力。

  2. 功能启用 (EST): 企业IT管理员（知道PIN2码的人）通过管理工具，将EFEST中对应ACL的比特位置为1，启用ACL功能。

  3. 名单配置 (ACL): 管理员在EFACL文件中，写入允许访问的APN列表，例如只写入一个企业内网APN：'vpn.mycorp.com'。

  4. 门禁生效:

    • 员工“李想”在他的工作手机上，尝试手动配置一个新的APN cmnet 来连接公共互联网。

    • 当他保存设置并发起连接时，手机的协议栈会执行ACL检查。

    • 手机读取EFACL列表，发现cmnet不在这个白名单中。

    • 手机在本地直接阻止这次PDP上下文激活请求，根本不会将请求发往网络。手机可能会提示“APN受限，无法连接”。

    • 只有当李想尝试连接vpn.mycorp.com时，手机检查发现该APN在白名单中，才会允许连接请求发往网络。

特别场景：网络提供的APN

In the case that the APN Control List is enabled and no APN is indicated in the PDP context request… the ME shall only request the PDP context activation if “network provided APN” is contained within EFACL.

如果用户没有指定APN，希望由网络来分配一个默认APN，那么手机也必须检查EFACL中是否包含一个特殊的条目——“network provided APN”（网络提供的APN）。如果白名单中没有这一项，那么即使是请求网络分配APN，也会被阻止。这确保了在ACL启用时，所有的数据连接路径都必须是明确授权的。

2. 简洁的列表：EFACL文件结构与编码剖析

EFACL的设计非常直观，它就是一个存储APN字符串列表的文件。

2.1 文件结构

表 4.2.48-1: EFACL 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F57’ |

| Structure | Transparent |

| File size | X bytes (X>1) |

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

字节内容

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

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

| 1 | Number of APNs/DNNs (APN/DNN的数量) | M | 1 byte |

| 2 to X | APN/DNN TLVs (APN/DNN的TLV对象) | M | X-1 byte |

逐项解读：

  • Structure: 透明文件。

  • Access Conditions: UPDATE权限是PIN2。这与EFFDN/EFBDN一致，再次强调了ACL是一项由管理者控制的强策略功能，普通用户（只知道PIN）无法修改这张“网络通行证”列表。

  • 文件内容:

    • 第一个字节: 记录了文件中包含了多少个APN/DNN条目。

    • 后续字节: 连续存储着一个或多个APN/DNN的TLV对象。

2.2 编码的核心：APN/DNN TLV 对象

For contents and coding of APN/DNN-TLV values see TS 23.003. The tag value of the APN/DNN-TLV shall be ‘DD’. “Network provided APN/DNN” is coded with a TLV object of length zero.

EFACL中的每一个APN，都以一个TLV (Tag-Length-Value) 的格式进行编码：

  • Tag (标签): 1字节，固定为'DD'，表示这是一个APN/DNN对象。

  • Length (长度): 1字节或更多，表示后面Value字段的字节长度。

  • Value (值): APN/DNN的字符串本身。

APN的字符串编码格式，则遵循 TS 23.003 的规定，这是一种特殊的域名编码格式。例如，vpn.mycorp.com 会被编码为：03 76 70 6E 06 6D 79 63 6F 72 70 03 63 6F 6D。其中，每个域名部分（如vpn, mycorp）前，都有一个字节来指示该部分的长度。

特殊条目：“网络提供的APN”

如果想允许手机使用网络分配的APN，需要在EFACL中加入一个特殊的TLV对象，其 Length字段为0。即：DD 00。手机在解析时看到这个长度为0的TLV，就知道“请求网络分配APN”这个行为是被允许的。

场景化举例（编码）：

企业IT管理员李想需要配置EFACL，只允许连接vpn.mycorp.com和网络分配的APN。

  1. APN数量: 2个。所以EFACL的第一个字节是'02'。

  2. 第一个APN (vpn.mycorp.com):

    • Tag: 'DD'

    • Length: 15 (十六进制'0F')

    • Value: 03 76 ... 63 6F 6D (共15字节)

    • 完整的TLV是: DD 0F 03 76 ... 63 6F 6D

  3. 第二个APN (网络提供):

    • Tag: 'DD'

    • Length: '00'

    • 完整的TLV是: DD 00

最终，EFACL文件的完整内容（十六进制）将是：

02 DD 0F 03 76 ... 63 6F 6D DD 00

3. ACL 与 FDN/BDN 的对比

EFACL在功能上可以被看作是数据业务领域的EFFDN。它们的设计思想高度一致：

| 特性 | EFFDN (固定拨号) | EFACL (APN控制) |

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

| 管控对象 | 语音/短信呼出 (MO Call/SMS) | 数据连接建立 (PDP/PDU Session) |

| 工作模式 | 白名单 (Whitelist) | 白名单 (Whitelist) |

| 启用控制 | EFEST (服务n°1) | EFEST (服务n°3) |

| 修改权限 | PIN2 | PIN2 |

| 列表内容 | 电话号码 (BCD编码) | APN/DNN (域名编码) |

可以看出，3GPP为CS域和PS域的访问控制，提供了一套逻辑上完全对等的标准化工具，只是管控的数据对象和编码格式不同。

总结：构筑企业移动数据安全的第一道防线

EFACL文件通过在USIM这个可信根上建立一个不可篡改的APN“白名单”，为企业移动数据安全构筑了第一道坚实的防线。

  • 端侧访问控制: 在连接请求离开手机之前，就在终端侧进行拦截，避免了向网络发送无效或违规的请求，既安全又高效。

  • 防止数据绕路: 有效地阻止了员工使用个人APN连接公共互联网，从而绕过企业安全审计和防火墙的行为，确保了所有业务数据都流经受控的企业网络通道。

  • 降低安全风险: 限制了手机被恶意软件（如果获取了系统权限）利用来连接到恶意APN，从而发起攻击或窃取数据的可能性。

  • 灵活的策略配置: TLV格式和对“网络提供APN”的特殊支持，为管理员配置复杂的访问策略提供了足够的灵活性。

对于李想这样的IT管理员来说，EFACL是一个强大而可靠的“守门人”。通过简单地配置这张存储在每个员工USIM卡中的“通行证”列表，他就能为整个企业的移动数据安全策略，打下坚实的基础。这张小小的列表，是确保企业信息资产在移动化时代安全无虞的关键一环。

FAQ环节

Q1：如果EFACL功能被启用，但文件是空的（即APN数量为0），会发生什么？

A1：在这种情况下，所有数据连接请求都将被阻止。因为“白名单”是空的，所以任何APN（包括请求网络分配的APN）都无法匹配成功。这是一种“一刀切”的、最严格的禁止数据业务的配置方式。

Q2：EFACL可以限制Wi-Fi连接吗？

A2：不可以。EFACL的全称是APN控制列表，APN/DNN是蜂窝移动网络（2G/3G/4G/5G）中用于标识数据网络的概念。Wi-Fi连接使用SSID（服务集标识）来识别网络，其连接和认证机制与蜂窝网络完全不同。EFACL的管控范围仅限于通过蜂窝网络发起的数据会话。

Q3：在5G时代，EFACL还叫EFACL吗？它对DNN（Data Network Name）同样有效吗？

A3：是的，文件名依然是EFACL，但它的功能已经扩展到对5G的DNN同样有效。规范中明确指出，这个文件包含“APNs or DNNs”。DNN可以看作是APN在5G核心网架构下的新名字，其功能和格式与APN高度兼容。因此，EFACL的“白名单”机制在5G时代无缝地延续了下来，继续扮演着数据连接“门禁”的角色。

Q4：为什么EFACL的更新权限是PIN2，而不是普通的PIN？

A4：这与EFFDN/EFBDN的原因相同，都是为了权限分离和强化管控。数据连接的权限是企业安全策略的核心部分，必须由授权的管理员（知道PIN2的人）来控制。如果使用普通PIN码，任何能够解锁手机的普通员工都可以自行添加cmnet等公共APN，从而绕开公司的安全策略，这将使ACL功能形同虚设。PIN2确保了这张“网络通行证”列表的修改权，掌握在少数管理员手中。

Q5：手机厂商或操作系统可以绕过EFACL的限制吗？

A5：一个严格遵循3GPP规范的手机，不应该绕过ACL的限制。ACL检查是协议栈底层必须执行的步骤。然而，在一些非标准的、被修改过的（例如“root”过的）操作系统上，或者在一些特殊的测试模式下，理论上可能存在绕过这种检查的途径。但对于正规的商用手机，EFACL提供的限制被认为是相当可靠的终端侧安全措施。

关系图谱