51学通信

深度解析 3GPP TS 33.515：4.2.2.1.4 计费ID唯一性 (捍卫运营商的“钱袋子”)

16分钟阅读

深度解析 3GPP TS 33.515：4.2.2.1.4 计费ID唯一性 (捍卫运营商的“钱袋子”)

本文技术原理深度参考了3GPP TS 33.515 V18.1.0 (2023-12) Release 18规范中，关于“4.2.2.1.4 Charging ID Uniqueness”的核心章节。本文将聚焦于SMF一项至关重要但常在安全讨论中被忽视的职责：如何为每一条数据流生成一个独一无二的“订单号”（Charging ID），以及为何这个看似简单的唯一性要求，是捍卫运营商商业利益、防止计费欺诈的第一道，也是最关键的一道防线。

“总指挥部”的财务纪律：每一颗“子弹”都要有账可查

在前几篇文章中，我们见证了“CommandCore-SMF”在资深架构师王工和新人工程师李娜的手中，如何被打造成为一个能够做出权威安全策略决策的“总指挥部”。它确保了电竞选手“Zero”的顶级游戏体验得到了应有的安全保障。

今天，王工将一个全新的、极其严肃的任务交给了李娜。“李娜，我们的指挥部不仅要能打胜仗，还要懂得精打细算，遵守严格的‘财务纪律’。我们为Zero提供的每一次‘电竞级’服务，都像是发射了一枚昂贵的‘精确制导导弹’。我们的职责，就是要为每一枚发射出去的导弹，都生成一个唯一的、不可伪造的序列号，并上报给‘军需处’（计费系统CHF）。如果这个序列号搞错了，或者两枚不同的导弹用了同一个序列号，会发生什么？”

王工的这个问题，让李娜的思路从技术安全转向了商业安全。她立刻意识到，如果计费ID出错，后果将是灾难性的：

  • 计费混乱：Zero的游戏账单上，可能会出现隔壁观众看视频的流量费用。
  • 收入流失：如果两个付费会话因为ID冲突，只被计费系统记录为一笔，运营商将直接损失一份收入。
  • 欺诈温床：恶意的攻击者可能会故意利用ID碰撞的漏洞，将自己的高额流量费用，“嫁祸”给其他无辜的用户，或者干脆让自己的会话因为ID冲突而成为无法被追踪的“幽灵会话”，实现免费上网。

“没错，”王工总结道，“计费ID的唯一性，看似是一个简单的功能要求，但它直接关系到运营商的‘钱袋子’。保障它的绝对唯一，就是捍卫运营商最核心的商业利益。这就是我们今天要攻克的堡垒——Charging ID Uniqueness。”

1. 威胁：当“订单号”发生碰撞

SMF作为PDU会话的“总管家”，在会话建立时，会与CHF（Charging Function）进行交互，启动计费流程。在这个交互中，SMF会为这个PDU会话生成一个在运营商网络（PLMN）范围内唯一的32位整数——Charging ID。这个ID将伴随该会话的整个生命周期，所有后续的计费数据（如流量、时长）都会与这个ID绑定。

核心威胁：在高并发、高负载的情况下（例如，一个城市的用户在跨年夜零点同时上网），SMF的ID生成器如果设计不当（例如，基于一个简单的、可能回绕的计数器，或者随机数生成器不够健壮），就有可能为两个或多个不同的PDU会话，生成了同一个Charging ID。这就是“ID碰撞”。

1.1 规范原文

4.2.2.1.4 Charging ID Uniqueness Requirement Name: Charing ID uniqueness. Requirement Reference: TS 32.255, clause 5.1.2 Requirement Description: According to TS 32.255, clause 5.1.2:

  • The SMF supports PDU session charging using service based interface.
  • The SMF collects charging information per PDU session for UEs served under 3GPP access and non-3GPP access.
  • Every PDU session is assigned a unique identity number for billing purposes per PLMN. (i.e. the Charging Id). Threat Reference: TR 33.926, clause J.2.2.3, “Failure to assign unique Charging ID for a session”

TEST CASE: Test Name: TC_CHARGING_ID_UNIQUENESS_SMF Purpose: Verify that the charging ID generated by the SMF for each PDU session is unique.

1.2 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：SMF为每一个PDU会话生成的Charging ID，在运营商网络（PLMN）范围内，必须是唯一的。
  • “唯一”的尺度：这里的“唯一”不仅仅指在同一时刻是唯一的，更重要的是，在一个相当长的时间周期内（通常远超计费账期），不能出现重复。一个被释放的ID，不能立刻被重新分配给新的会话。
  • 为何重要？
    • 计费准确性：这是所有后续计费、审计、账单查询的基础。ID不唯一，一切都无从谈起。
    • 防范欺诈：杜绝了通过ID碰撞进行欺诈的可能性。
    • 系统稳定性：一个设计良好的ID生成器，也是系统健壮性的体现。

测试用例解读 (The “How to Verify”)

这个测试用例的设计思想非常直接，就是**“暴力施压，秋后算账”**。

  • 前提条件 (Pre-Conditions)：
    1. 搭建一个包含待测SMF和模拟CHF的测试环境。
    2. 测试人员必须能够捕获SMF和CHF之间的所有网络流量。
  • 执行步骤 (Execution Steps)：
    1. 拦截流量：在SMF和CHF之间部署抓包工具，准备捕获所有Nchf_ConvergedCharging_Create请求。
    2. 极限施压：这是测试的关键。测试脚本需要模拟海量的UE，在短时间内向SMF发起其所能支持的最大并发数的PDU会话建立请求。这个过程就是要模拟最极端、最容易出错的场景。
    3. 捕获“订单”：当SMF处理这些请求时，它会为每个会话生成Charging ID，并向CHF发送Charging Data Request [initial]消息。测试工具需要捕获所有这些初始计费请求消息。
    4. 查重验证：捕获结束后，测试脚本会解析所有捕获到的计费请求，提取出其中PDU Session Charging Information IE里的chargingId字段，并将所有提取出的ID存入一个集合（Set）。
  • 预期结果 (Expected Results)：
    • 集合的大小必须等于捕获到的请求消息的数量。如果集合的大小小于消息数量，就说明存在重复的ID，测试失败。
    • 最终的交付证据，就是包含所有计费交互的.pcap抓包文件，以及一个分析脚本或报告，证明在所有创建的会话中，Charging ID集合内没有重复元素。

2. SMF在计费安全中的扩展职责

虽然TS 33.515的这个章节只明确要求了ID的唯一性，但在一个完整的安全体系中，王工向李娜阐述了SMF在计费安全领域的更广泛职责：

  • 信息的完整性与真实性：SMF上报给CHF的所有计费信息（如流量、时长、QoS、用户位置等），都必须是准确、未经篡改的。SMF与CHF之间的SBI接口，必须强制使用TLS进行加密和完整性保护。
  • 防范拒绝服务攻击：SMF必须能够抵御针对其计费功能的DoS攻击。例如，攻击者可能通过快速建立并拆除大量会话，来消耗SMF的计费处理资源，或向CHF发起大量的计费请求，从而淹没CHF。SMF需要有相应的速率限制和异常检测机制。
  • 可靠的计费事件上报：SMF必须保证在PDU会话的各个关键节点（建立、修改、释放），都能可靠地向CHF上报计费事件。即使在SMF自身发生故障切换等异常情况下，也要有机制保证计费信息的最终一致性。

总结：SMF，运营商商业模式的忠诚卫士

通过今天对4.2.2.1.4节的攻坚，李娜深刻理解到，SMF的安全职责，远不止于技术层面。它还是运营商商业模式的直接守护者。

Charging ID的唯一性，就像是商业世界中最基础的“一物一码”、“一单一号”原则。它简单、纯粹，却是一切信任和交易的基石。TS 33.515通过一个看似简单的测试用例，为SMF的这项核心商业安全职责，设定了不可逾越的红线。

这个要求，确保了“CommandCore-SMF”不仅是一个技术上卓越的“总指挥部”，更是一个财务上严谨、纪律上严明的“廉洁机构”。它确保了为Zero选手提供的每一次昂贵服务，都有据可查、有账可依，从而捍卫了整个5G商业生态的健康运转。

FAQ 环节

Q1：Charging ID是由SMF独立生成的吗？它需要和其他SMF实例协调吗？ A1：Charging ID的生成策略由运营商决定。一种常见的、健壮的实现方式是，每个SMF实例都会被分配一个唯一的ID前缀，然后它在自己的前缀空间内生成后续的ID。例如，SMF-1生成的ID可能是0x01xxxxxx，SMF-2生成的可能是0x02xxxxxx。这样，即使不进行实时协调，也能保证在整个PLMN范围内，不同SMF实例生成的ID不会发生碰撞。

Q2：如果SMF和CHF之间的连接中断了，会发生什么？会计费失败吗？ A2：不会。5G的计费架构设计了很强的容错机制。如果SMF无法连接到主CHF，它会尝试连接到备用CHF。如果所有CHF都不可用，SMF会在本地缓存计费数据。一旦与CHF的连接恢复，SMF会立即将缓存的计费数据上报，从而保证计费信息的最终一致性。这种机制被称为“Store and Forward”。

Q3：除了Charging ID，PDU会话还有没有其他的ID？ A3：有的。一个PDU会话有多个ID，用于不同的层面。

  • PDU Session ID：这是一个在UE和AMF/SMF之间，用于标识一个PDU会话的ID，范围通常是1-15。它只在UE的单个接入连接中具有唯一性。
  • SUPI + PDU Session ID：这个组合可以在一个SMF的范围内唯一地标识一个会话。
  • Charging ID：这是一个在整个PLMN范围内，对计费系统而言唯一的会话标识。
  • N4 Session ID：这是SMF和UPF之间，用于在N4接口上标识一个会话的ID。 这些不同的ID，体现了在不同接口和功能域中，对会话进行标识的关注点是不同的。

Q4：为什么测试用例要求进行“最大并发数”的压力测试？ A4：因为ID碰撞的bug，通常只会在高并发、资源紧张的“极限”情况下才会暴露。在低负载下，一个简单的递增计数器可能永远不会出错。但在高并发时，如果多线程或多进程之间对ID生成器的访问没有进行严格的“加锁”或原子操作保护，就可能出现两个线程同时读取了同一个计数值，然后各自加一，最终生成了两个相同的ID。极限压力测试，就是为了揭露这种在并发编程中最常见的、也是最难发现的“竞态条件”（Race Condition）bug。

Q5：计费安全和我们之前讨论的用户面安全策略有什么关系？ A5：它们是紧密关联的。用户面安全策略，决定了用户享受了何种等级的服务（例如，是否启用了昂贵的端到端加密）。而计费安全，则确保了用户所享受的这种服务被准确地记录和收费。例如，SMF在向CHF上报计费信息时，会附带上该会话的QoS信息和安全服务等级。CHF可以据此进行差异化计费：享受了“强制加密”服务的Zero选手，其每GB流量的单价，可能就远高于普通上网用户。两者结合，构成了5G“按质付费”、“按安全等级付费”的商业模式基础。

关系图谱