51学通信

深度解析 3GPP TS 31.102：4.2.38 EFCCP2 (能力配置参数2)

17分钟阅读

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

深度解析 3GPP TS 31.102：4.2.38 EFCCP2 (能力配置参数2)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.38 EFCCP2 (Capability Configuration Parameters 2)”的核心章节，旨在为读者深入剖析这张特殊的“呼叫参数配置表”，是如何为特定的拨号号码（如服务号码、固定号码）附加详细的网络承载要求，从而实现差异化的业务承载控制。

在我们日常拨打电话时，看似简单的“拨号-接通”过程，背后其实涉及到手机（ME）与网络之间一系列复杂的“协商”。手机需要告知网络，这次呼叫希望使用什么样的承载能力 (Bearer Capability)。例如，这是一次普通的语音通话、一次传真呼叫，还是一次需要特定速率的数据连接？

通常情况下，这些呼叫参数由手机根据呼叫类型（语音/数据）自动生成。然而，在某些特定场景下，运营商或用户需要为某个特定的电话号码预设一套专属的呼叫参数。比如，拨打某个企业的数据接入号码时，需要强制使用特定的数据速率和连接类型。

为了满足这种“号码与呼叫参数绑定”的需求，3GPP规范设计了EFCCP系列文件。EFCCP，全称 Capability Configuration Parameters，即“能力配置参数”。

EFCCP2正是这个家族的一员。它的核心使命，就是充当一个“呼叫参数配置库”，而它的服务对象，是我们在前几章中介绍过的那些具有特殊拨号规则的文件：

  • EFFDN (固定拨号号码)

  • EFBDN (禁止拨号号码)

  • EFMSISDN (我的号码)

  • EFSDN (业务拨号号码)

  • EFICI / EFOCI (呼入/呼出通话记录)

EFCCP2通过一个巧妙的链接机制，允许这些文件中的某条号码记录，在发起呼叫时，不再使用手机的默认参数，而是强制使用EFCCP2中为其量身定制的一套网络能力参数。

1. “呼叫的专属指令集”：EFCCP2的核心价值

EFCCP2的核心价值在于将呼叫号码与呼叫的网络承载要求进行解耦和灵活绑定，为运营商实现精细化的业务控制提供了强大工具。

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

This EF contains parameters of required network and bearer capabilities and terminal configurations associated with a call established using a fixed dialling number, a barred dialling number, an MSISDN, a service dialling number, an incoming call, an outgoing call or an MBDN.

这段原文清晰地定义了EFCCP2的功能和应用范围：

  1. 服务关联: 它的存在与EF_UST中的服务n°14相关联。

  2. 内容核心: 存储了“所需的网络和承载能力参数 (required network and bearer capabilities)”。

  3. 广泛的关联性: 它的服务对象几乎涵盖了USIM中所有与“号码”相关的文件，从FDN到通话记录。

工作机制：

  1. 配置: 运营商或用户（如果权限允许）在EFCCP2中创建一条或多条记录，每一条记录都包含一套完整的承载能力参数。例如，第3号记录被配置为“同步、速率9.6kbps、非透明数据业务”。

  2. 链接: 在EFSDN（业务拨号号码）中，为“企业数据专线”这个条目进行配置。除了写入号码12345之外，还在其Capability/Configuration2 Record Identifier字段中，写入了'03'。这个'03'就像一个指针，指向了EFCCP2中的第3号记录。

  3. 触发与执行:

    • 我们的主角“李想”在他的工作手机上，点击了那个预存的“企业数据专线”号码。

    • 手机在准备发起呼叫前，读取EFSDN中该条目的所有信息。

    • 手机发现了Capability/Configuration2 Record Identifier字段的值为'03'，而不是无效值'FF'。

    • 手机立即明白，这次呼叫需要使用一套特殊的参数。它随即去读取EFCCP2文件的第3号记录。

    • 手机将从第3号记录中读取到的承载能力信息（“同步、9.6kbps、非透明…”），用来构建本次呼叫的SETUP信令。

    • 最终，手机向网络发起的是一个携带了这套专属参数的呼叫请求，而不是它自己的默认语音或数据参数。

通过这个流程，运营商确保了当用户拨打特定业务号码时，其所建立的承「承载」与该业务的要求是完全匹配的，避免了因参数错误导致的业务失败。

2. 承载能力的“蓝图”：EFCCP2文件结构与编码剖析

EFCCP2文件本身是一个简单的“参数库”，其核心在于记录内容的复杂性和标准化。

2.1 文件结构

表 4.2.38-1: EFCCP2 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F4F’ |

| SFI | ‘16’ |

| Structure | Linear Fixed |

| Record length| X bytes, X≥15 |

| Update activity| Low |

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

记录内容 (X bytes)

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

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

| 1 to X | Bearer capability information element (承载能力信息元) | M | X bytes |

逐项解读：

  • Identifier & SFI: EFCCP2拥有固定的ID 6F4F和SFI 16。

  • Structure: 线性固定文件。每一条记录就是一套完整的参数配置。

  • Record length: X字节，规范要求至少15字节，以容纳一个足够复杂的承载能力定义。

  • Access Conditions: 读写都受PIN保护。这允许高级用户或管理员通过PIN码来配置这些高级参数。

2.2 编码的核心：承载能力信息元 (Bearer capability IE)

EFCCP2记录的内容，并非3GPP凭空创造，而是直接复用了在空口信令标准 TS 24.008 中定义的“承载能力信息元 (Bearer Capability Information Element)”的格式。

Contents and Coding: - see TS 24.008. The Information Element Identity (IEI) shall be excluded…

这意味着，EFCCP2中的每一条记录，就是一条“预制”的、准备在呼叫建立时发送给网络的信令参数。手机在需要时，只需将这条记录的内容“复制粘贴”到SETUP信令的相应位置即可。

这个“承载能力信息元”是一个高度结构化的数据块，其中包含了数十个可以配置的参数，例如：

  • 信息传输能力 (Information Transfer Capability): 语音、非限制数字信息、传真等。

  • 传输模式 (Transfer Mode): 电路模式 (Circuit Mode)、分组模式 (Packet Mode)。

  • 速率 (Rate): 9.6 kbit/s, 14.4 kbit/s, 64 kbit/s等。

  • 同步/异步模式 (Synchronous / asynchronous)。

  • 用户速率 (User Information Layer 1 protocol): 如V.110/V.120速率适配协议。

  • 调制解调器类型 (Modem type)。

  • …等等。

通过对这些参数的不同组合，运营商可以在EFCCP2中定义出适用于各种复杂数据业务（如传统的POS机拨号、传真、视频会议终端拨号）的承载配置。

3. EFCCP2与EFCCP1的区别

细心的读者会发现，在EFADN（电话本）的定义中，关联的是EFCCP1，而EFSDN等文件关联的是EFCCP2。这两者有什么区别？

在功能和结构上，EFCCP1和EFCCP2几乎完全相同，它们都是存储承载能力参数的库。之所以要分成两个文件，主要是为了逻辑上的隔离和权限管理：

  • EFCCP1: 主要服务于用户的个人电话本 (EFADN)。其读写权限通常与EFADN一致，允许用户自行（通过PIN码）为某个联系人关联特殊的呼叫参数。例如，李想可以将他办公室的传真机号码关联到一个预设的“传真模式”CCP1记录上。

  • EFCCP2: 主要服务于运营商控制的号码列表（如EFSDN, EFFDN等）。其读写权限通常更严格，由运营商（ADM）或管理员（PIN2）控制。

这种分离确保了用户对个人电话本的自定义配置，不会影响到运营商设定的、具有更高优先级的业务号码配置。

总结：为特殊呼叫铺设的“专属轨道”

EFCCP2文件虽然在普通的语音通话中“英雄无用武之地”，但它在差异化、专业化的数据通信领域，扮演着不可或缺的“参数工程师”角色。

  • 实现了号码与承载的绑定: 通过一个简单的记录ID链接，EFCCP2将抽象的呼叫号码与具体的网络资源要求紧密地绑定在一起，是实现业务策略的基础。

  • 复用标准，简化实现: 直接采用TS 24.008中定义的信令信息元格式，避免了重复造轮子，使得手机端的实现逻辑大大简化——只需“读取”和“复制”。

  • 保障特殊业务成功率: 对于那些对承载网络有严格要求的传统数据业务（如传真、拨号上网、POS交易），EFCCP2提供的预配置参数，是保证这些业务能够成功建立连接的关键。

  • 提供了分级管理的能力: 通过与EFCCP1的分离，实现了用户自定义参数和运营商策略参数的隔离，保证了配置的清晰和安全。

对于李想而言，当他按下那个“企业数据专线”的快捷拨号时，他可能只觉得这次连接比平时更稳定、更符合预期。他不知道的是，EFCCP2已经在幕后启动，为这次重要的呼叫，铺设了一条精确配置、畅通无阻的“专属数字轨道”。这正是EFCCP2在USIM这座“数字城市”中，作为专业“线路工程师”的价值所在。

FAQ环节

Q1：在5G时代，主要使用分组交换（PS）网络，EFCCP2中定义的这些电路交换（CS）参数还有用吗？

A1：作用大大减弱，但并未完全消失。首先，为了向后兼容，5G手机和USIM仍然需要支持CS Fallback（CSFB）或RAT Fallback，在没有VoNR覆盖时回落到2G/3G网络进行通话，此时CS域的承载能力参数依然可能被使用。其次，EFCCP2中定义的“承载能力信息元”也包含了一些与分组交换相关的早期参数。更重要的是，它的设计思想——为特定号码/业务绑定一组底层网络参数——在5G时代被继承和发扬了，只不过载体变成了更复杂的URSP规则、NSSAI（网络切片选择辅助信息）等，其配置也可能存储在EFURSP等新的5G专属文件中。

Q2：EFCCP2和APN（Access Point Name）有什么关系？

A2：两者都用于定义数据连接的参数，但层面不同。APN主要用于在PS域，定义了UE要连接的外部数据网络网关 (GGSN/PGW/UPF)，即“要去哪里”。而EFCCP2主要（但不仅限于）用于在CS域，定义了建立这条连接所需要的无线承载本身的特性（如速率、同步/异步等），即“要怎么去”。在一些早期的GPRS业务中，两者可能会协同工作。

Q3：用户可以自己编辑EFCCP2的内容吗？

A3：通常比较困难。虽然EFCCP2的UPDATE权限可以是PIN，但其内容是高度专业化的、二进制编码的“承载能力信息元”。普通的手机设置菜单几乎不会提供一个用户友好的界面来让用户逐一编辑比特位的含义。这个文件的修改通常由运营商通过OTA下发，或者由企业IT管理员通过专门的管理工具进行配置。

Q4：一个EFCCP2记录可以被多个EFSDN或EFFDN条目共享吗？

A4：可以。这正是EFCCP2作为“参数库”的价值所在。运营商可以在EFCCP2中定义一个“标准9.6kbps数据呼叫”的模板，并将其设为第5号记录。然后，所有需要此承载能力的服务号码（无论它们在EFSDN的哪条记录中），都可以在其Capability/Configuration2 Record Identifier字段中填入'05'，共同指向这个模板。这极大地提高了配置的效率和一致性。

Q5：EFCCP2中的“2”代表什么？为什么不是EFCCP？

A5：这里的“2”主要是为了与EFCCP1进行区分。在最初的规范设计中，可能先定义了服务于EFADN的EFCCP（后来演变为EFCCP1）。当需要为EFSDN等其他文件也提供类似功能，但又需要进行逻辑和权限隔离时，便引入了第二个能力配置文件，并命名为EFCCP2。这种通过数字后缀来区分功能相似但应用域不同的文件，是3GPP规范中的一种常见命名习惯。

关系图谱