51学通信

深度解析 3GPP TS 31.102：4.2.46 EFCMI (比较方法信息)

16分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。由于规范中 4.2.45 EFEXT4 是对EFBDN的扩展文件，其原理与我们之前剖析过的EFEXT系列完全一致，在此合并说明，不再展开。我们将直接进入下一个具有独立功能的文件。

深度解析 3GPP TS 31.102：4.2.46 EFCMI (比较方法信息)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.46 EFCMI (Comparison Method Information)”的核心章节，旨在为读者深入剖析在USIM卡实现的禁止拨号（BDN）功能背后，这个小巧的EFCMI文件是如何像一个“高级规则引擎”，为号码匹配逻辑提供超越简单前缀匹配的、更强大和灵活的自定义能力。

在我们之前探讨EFBDN（禁止拨号号码）时，我们了解到它像一个“黑名单”，可以阻止手机拨打列表中的特定号码。其默认的工作方式是前缀匹配：如果EFBDN中有一条记录是“400”，那么所有以“400”开头的号码都将被禁止。

然而，在某些复杂的管理场景下，简单的前缀匹配可能不够用。例如，一个企业可能需要实现更精细的规则：

  • 精确匹配：只禁止拨打“400-800-1234”这个完整号码，而不影响拨打其他400开头的号码。

  • 后缀匹配：禁止拨打所有以“99”结尾的短号码。

  • 包含匹配：禁止拨打任何包含“555”连续数字的号码。

为了满足这些高级的、非标准的匹配需求，3GPP的设计师们在EFBDN的功能之上，增加了一个“插件化”的规则定义机制。这个机制的核心，就是EFCMI文件。

EFCMI，全称 Comparison Method Information，即“比较方法信息”。它的使命非常独特：它本身不存储任何要禁止的号码，而是存储了一系列**“如何比较号码”的规则**。EFBDN中的每一条记录，都可以通过一个指针，来指定自己应该使用EFCMI中定义的哪一套“高级比较法”，而不是默认的前缀匹配法。

1. “规则引擎”：EFCMI的核心价值

EFCMI的核心价值在于将**拨号控制的“数据”（黑名单号码）与“逻辑”（如何匹配号码）**进行分离，为BDN功能提供了无与伦比的灵活性和可扩展性。

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

This EF contains the list of Comparison Method Identifiers and alpha-tagging associated with BDN entries (see EFBDN).

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

  1. 服务关联: 它的存在与EF_UST中的服务n°6（BDN）紧密绑定。可以说，有EFBDN的地方，就必须有EFCMI作为配套。

  2. 内容核心: 存储了比较方法标识符 (Comparison Method Identifiers) 的列表。每一条记录就是一个自定义的比较规则。

  3. 与BDN的联动: EFBDN中的记录通过一个指针 (Comparison Method Pointer) 来引用EFCMI中的某条规则。

工作流程：

  1. 规则定义: 我们的主角“李想”，现在是一家公司的IT管理员。他需要在公司的USIM卡中定义一条新规则：禁止拨打任何以“888”结尾的号码。

    • 他在EFCMI文件中创建一条新记录（例如，第5条记录）。

    • 在这条记录中，他写入了一个公司内部定义的、代表“后缀匹配‘888’”的比较方法标识符，并为其命名（Alpha-tagging）为“禁888结尾”。

    • 注意：这个标识符的具体含义和如何执行“后缀匹配”，是由手机制造商和卡商共同协商定义的，3GPP规范本身不强制规定。

  2. 规则应用:

    • 李想在EFBDN文件中创建一条新的禁止拨号记录。

    • 在这条记录的号码字段，他可能写入“888”（也可能留空，因为逻辑在EFCMI中定义）。

    • 最关键的一步，他将这条EFBDN记录的最后一个字节——Comparison Method Pointer——的值设置为'05'。这个指针明确地告诉手机：“对于这条BDN记录，不要用默认的前缀匹配，请去EFCMI的第5条记录里找高级玩法！”

  3. 呼叫时的逻辑判断:

    • 公司员工尝试拨打一个号码12345888。

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

    • 手机检查到李想设置的那条BDN记录，并发现其Comparison Method Pointer指向了EFCMI的第5条记录。

    • 手机随即读取EFCMI的第5条记录，获取了那个自定义的“后缀匹配‘888’”的比较方法标识符。

    • 手机的内部逻辑库中，包含了对这个私有标识符的解释程序。它执行“后缀匹配”算法，发现12345888确实以“888”结尾。

    • 匹配成功，手机阻止了这次呼叫。

通过这个流程，EFCMI就像一个可插拔的“规则插件库”，极大地扩展了BDN功能的能力边界。

2. 简洁的“规则索引”：EFCMI文件结构与编码剖析

EFCMI文件本身的设计非常简洁，它只负责存储规则的“索引”，而不包含规则的“实现”。

2.1 文件结构

表 4.2.46-1: EFCMI 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F58’ |

| Structure | Linear Fixed |

| Record length| X+1 bytes |

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

记录内容 (X+1 bytes)

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

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

| 1 to X | Alpha Identifier (规则别名) | M | X bytes |

| X+1 | Comparison Method Identifier (比较方法标识符) | M | 1 byte |

逐项解读：

  • Access Conditions: UPDATE权限为ADM。这非常重要，因为定义和修改比较规则是运营商或企业IT的核心管理权限，必须严格控制。

  • Alpha Identifier: 为这条规则起一个可读的名称，如“精确匹配”、“禁止4位短号”等，便于管理。

  • Comparison Method Identifier (1 byte): 这是EFCMI的灵魂——一个1字节的标识符。

    Contents: - this byte describes the comparison method which is associated with a BDN record. Its interpretation is not specified but it shall be defined by the card issuers implementing the BDN feature on their USIMs.

    Coding: - binary; values from 0 to 255 are allowed. The default coding 255 is reserved for empty field.

    • 核心思想: 规范不定义这个字节的值代表什么。0到254的任何值，其具体解释权 (interpretation) 完全下放给了卡商和手机制造商。

    • 协同定义: 卡商和手机制造商需要事先坐下来开会，共同商定一个“私有协议”。例如，他们可以约定：

      • ID 0x01 = 精确匹配

      • ID 0x02 = 后缀匹配

      • ID 0x03 = 包含匹配

      • …

    • 手机在出厂时，其拨号控制模块的软件中，就必须内置对这套私有ID协议的解析和执行逻辑。

3. 设计哲学的升华：标准化与定制化的完美结合

EFCMI的设计，是3GPP标准化工作中一个非常经典的“高阶范例”。它完美地展示了如何在保持全球标准统一性的同时，为特定市场和客户的定制化需求留出巨大的创新空间。

  • 标准化的“接口”: 3GPP定义了一个标准的“插件接口”。这个接口就是EFBDN中的Comparison Method Pointer字段，以及EFCMI文件的结构和存在性。全球所有的手机和USIM卡都必须支持这个“插座”。

  • 定制化的“插件”: 至于“插座”里具体插什么“电器”（即Comparison Method Identifier的具体含义和实现），3GPP则完全放手，让产业链的合作伙伴（运营商、卡商、手机商）根据具体的项目需求去**“联合开发”**。

这种模式的优点是：

  • 无限的可扩展性: 只要厂商愿意，他们可以定义出255种五花八门的、极其复杂的比较规则，来满足任何刁钻的客户需求，而无需去推动3GPP修改主标准。

  • 保护商业秘密: 这些私有的比较逻辑是厂商的核心竞争力之一，无需在公开的标准中暴露。

  • 保持主干稳定: 主标准EFBDN的结构得以保持长期的稳定，不会因为各种零散的定制化需求而被频繁修改。

总结：为拨号控制插上“想象的翅膀”

EFCMI文件虽小，却意义非凡。它不是一个简单的数据存储文件，而是USIM卡内一个“逻辑与数据分离”设计哲学的集中体现。它将BDN功能从一个固定的“前缀匹配器”，升级为了一个可编程、可扩展的“智能规则引擎”。

  • 实现了逻辑的可定制化: 允许运营商和设备商根据特定需求，共同定义超越标准的、私有的号码匹配算法。

  • 提供了强大的灵活性: 使得BDN功能可以应对从简单号码屏蔽到复杂号码模式分析的各种场景。

  • 展现了标准制定的智慧: 在全球统一的框架下，为本地化和定制化创新预留了“接口”，是标准化与灵活性相结合的典范。

对于李想而言，当他作为公司IT管理员，能够轻松地配置出“禁止拨打尾号为4444或6666的号码”这样复杂的规则时，他所依赖的，正是EFCMI这个小文件所提供的强大“编程”能力。EFCMI为看似简单的拨号控制功能，插上了一双“想象的翅urry”，让其能够适应千变万化的企业管理需求。

FAQ环节

Q1：EFCMI中定义的比较方法，可以用在EFFDN（固定拨号）上吗？

A1：不可以。根据规范，Comparison Method Pointer这个字段是**EFBDN独有的**。EFFDN的匹配逻辑被固定为标准的前缀匹配。这个设计是合理的，因为“白名单”通常要求规则清晰、简单、无歧义，以避免用户因为复杂的规则而被意外地阻止拨打正常号码。而“黑名单”则往往需要更灵活的规则来应对各种层出不穷的骚扰或风险号码模式。

Q2：如果一部手机不认识EFCMI中定义的某个私有“比较方法标识符”会怎么样？

A2：手机将无法执行这条BDN规则，其行为取决于具体的实现。一种安全的做法是，如果手机不认识某个Comparison Method Identifier，它应该将这条BDN规则视为无效并忽略它，即允许呼叫通过。因为错误地禁止一个本该允许的呼叫，其后果通常比错误地放行一个本该禁止的呼叫更严重。这也是为什么EFCMI的有效性，依赖于卡商和手机制造商之间紧密的协同和测试。

Q3：EFCMI是强制必须存在的吗？

A3：是的。规范中明确指出，“If service n° 6 is “available”, this file shall be present.”（如果服务n°6 BDN可用，这个文件必须存在）。即使运营商不打算使用任何高级比较规则，也必须存在一个空的或只包含默认规则的EFCMI文件，以保证手机侧处理逻辑的完整性。

Q4：EFCMI中的规则可以由用户自己修改吗？

A4：绝对不可以。EFCMI的UPDATE权限是ADM，是最高级别的管理权限。定义和修改号码比较逻辑，是运营商和企业IT的核心策略，必须被严格保护，不允许任何未经授权的修改。

Q5：这个EFCMI机制在5G时代还有意义吗？

A5：在传统的CS语音通话和VoLTE/VoNR的号码拨叫场景中，这个机制的原理依然有效。然而，5G时代的通信模式更加丰富，很多控制策略正在向网络侧的PC/PCF（策略控制功能）网元和终端侧的URSP（UE路由选择策略）规则转移。对于基于号码的拨号控制，EFCMI仍然是USIM层面最灵活的实现方式。但对于更复杂的、基于应用、基于切片、基于网络状态的业务流控制，则会由URSP等新的5G机制来主导。EFCMI可以看作是“端侧策略控制”思想在早期的一个经典实现。

关系图谱