51学通信

深度解析 3GPP TS 32.255：5.2.2 PDU session charging from SMF (非漫游场景下的计费流程)

18分钟阅读

好的，我们正式进入3GPP TS 32.255规范中最为具体和直观的部分——消息流程。在前面的章节中，我们已经系统地学习了5G计费的“为什么”（原则）和“是什么”（架构），现在，我们将通过详细的信令交互图，亲眼见证计费系统“如何工作”。

本篇文章将作为5.2.2节的开篇，重点解读在最常规的非漫游场景下，一个PDU会话从“呱呱坠地”（建立）到“生命周期中的成长”（修改），再到“最终消亡”（释放）的全过程。我们将扮演一名网络信令分析工程师，通过“翻译”这些流程图，将抽象的计费逻辑还原为网元之间一次次精准的“对话”。

深度解析 3GPP TS 32.255：5.2.2 PDU session charging from SMF (非漫游场景下的计费流程)

本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“5.2.2 PDU session charging from SMF”的核心章节（5.2.2.1 - 5.2.2.2.4），旨在为读者通过详细的消息流程图，直观地展示在非漫游场景下一个标准PDU会话建立、修改和释放过程中的计费交互细节。

1. 流程解读的“金钥匙” (5.2.2.1 & 5.2.2.2.1 General)

在开始分析具体的流程图之前，规范首先给予了我们一把解读的“金钥匙”。

The flows in the present document specify the interaction between the SMF and the CHF for 5G data connectivity converged charging functionality… based on TS 23.501 and TS 23.502 procedures and flows. This interaction is based on Charging Data Request /Response specified in TS 32.290, exchanged between the SMF embedding the CTF and the CHF. As a general principle, the steps in the figures for the message flows below correspond to the steps of figures in TS 23.502, which is the reference. This document specifies the charging specific extension part.

深度解析：

这段话为我们设定了正确的阅读视角：

  1. 参考系：本规范中的所有计费流程图，都不是凭空产生的，而是“附加”在核心网主流程规范TS 23.502之上的。图中的步骤编号（如步骤1, 2, 3…）与TS 23.502中的主流程步骤是严格对应的。
  2. 焦点：本规范只关注与计费相关的“扩展部分”（extension part）。这些部分通常以“ch”作为后缀（如9ch-a, 16ch-b），明确表示这是计费（Charging）相关的交互。
  3. 语言：SMF与CHF之间的“对话语言”，遵循的是服务化接口规范TS 32.290中定义的Charging Data Request/Response消息格式。

有了这把“金钥匙”，我们就可以开始“破译”第一个核心流程了。

2. “开户立账”：PDU会话建立计费流程 (5.2.2.2.2 PDU session establishment)

小杰早晨开机，手机发起了PDU会话建立请求。规范中的**“Figure 5.2.2.2.2-1: PDU session establishment”**为我们完整地展示了这一过程。我们将重点分析其中的计费交互。

主流程回顾（步骤1-8）

  1. UE → AMF → SMF: UE发起PDU会话建立请求。
  2. SMF → UDM: SMF从UDM获取用户的签约数据，其中可能包含重要的“Charging Characteristics”。
  3. SMF → PCF: SMF向PCF请求策略，PCF会根据签约数据和运营商策略，返回初始的PCC规则。
  4. SMF: SMF根据PCF的策略，为会话选择一个SSC模式，并选择一个或多个UPF。

计费交互的“第一次握手”（步骤9ch-a, b, c）

这是计费会话生命周期的起点，至关重要。

9ch-a. The SMF creates a Charging Identifier for the PDU session, and sends Charging Data Request[initial] to CHF for authorization for the subscriber to start the PDU session which is triggered by start of PDU session charging event…

  • 信令分析：在完成了前期的准备工作（获取签约、获取策略、选择UPF）之后，SMF正式启动计费流程。
    1. 生成计费ID：SMF首先为这个会话生成一个唯一的Charging Identifier。
    2. 触发原因：“Start of PDU session”事件被触发。
    3. 发送[Initial]请求：SMF封装Charging Data Request[Initial]消息发往CHF。这个消息里包含了用户信息（SUPI）、计费ID、会话信息（DNN、SSC Mode等），以及可能从PCF获取的初始业务信息。

9ch-b. The CHF opens CDR for this PDU session.

  • 信令分析：CHF收到[Initial]请求后，立即在自己的数据库中为这个PDU会话创建一个新的话单记录（CDR），并将其状态置为“Open”。这个CDR就像一个刚刚开立的文件夹，准备随时接收后续的使用量信息。

9ch-c. The CHF acknowledges by sending Charging Data Response[Initial] to the SMF.

  • 信令分析：CHF通过Charging Data Response[Initial]消息向SMF确认“开户成功”。这个响应消息非常关键，它会包含CHF下发给SMF的第一批“指令”：
    • 初始配额：如果会话中包含需要在线计费的业务，CHF会在此处授予第一笔配额。
    • 触发器列表：CHF会下发一套初始的计费触发器，告诉SMF接下来需要监控哪些事件。
    • 会话“休眠”计时器：CHF可能会下发一个Unit Count Inactivity Timer值，覆盖SMF的本地默认配置。

完成这“三步曲”后，计费会话正式建立。SMF随即可以继续主流程，通过N4接口在UPF上建立数据转发规则（步骤10）。

业务启动的“按需索取”（步骤16ch-a, b, c）

PDU会话建立后，小杰的手机开始同步邮件、刷新天气，这些后台流量开始在UPF上流动。随后，他点开了一个需要在线计费的视频App。

16ch-a. This step may occur in case “start of service data flow” needs quota from CHF, for the SMF to request quota.

  • 信令分析：
    1. 触发：UPF检测到一条新的数据流（视频流），它根据SMF下发的PCC规则，发现这条流匹配到了一个需要“在线计费”的Rating Group，但UPF手上并没有这个Rating Group的配额。UPF立刻向SMF报告。
    2. SMF行动：SMF收到报告，触发了“start of service data flow”事件。它立即封装一个Charging Data Request[Update]消息，向CHF为这个视频业务申请配额。
    3. CHF响应：CHF在Charging Data Response[Update]中授予一笔视频流量配额，并可能针对这个Rating Group下发更精细的触发器。

NOTE 1: The steps from 16ch-a to 16ch-c for quota request from CHF are not applicable for offline only charging.

这个附注提醒我们，如果视频App被配置为离线计费，那么SMF在检测到视频流开始时，只会在本地开始记录用量，而不会触发这次与CHF的[Update]交互。

3. “动态调整”：PDU会话修改计费流程 (5.2.2.2.3 PDU Session Modification)

小杰正在看视频，突然接到了一个VoNR高清语音通话。网络为了保障通话质量，需要为他建立一个新的专用QoS流。这个过程会触发PDU会话修改流程，规范中的**“Figure 5.2.2.2.3-1: PDU Session Modification”**对此进行了描述。

2ch-a. The SMF sends Charging Data Request [Update] to the CHF for reporting the charging information when the corresponding trigger is armed (e.g., start of the service data flow, QoS change).

  • 信令分析：
    1. 触发：会话修改可能由多种原因触发（网络侧、用户侧、PCF策略变更等）。在这个例子中，是为了增加一个新的VoNR QoS流，这对应着一个“QoS change”事件，或者一个新的“start of service data flow”（如果VoNR被映射到一个新的Rating Group）。
    2. SMF行动：假设“QoS change”被配置为一个“立即报告”的触发器，SMF会立刻封装Charging Data Request[Update]消息发给CHF。
    3. 消息内容：消息中会详细描述这次变更的内容，例如新增了一个QFI，其QoS参数是什么，它被绑定到了哪个Rating Group等。同时，也会上报从上次报告到此刻为止的所有业务的使用量。

2ch-b. The CHF update the CDR for the PDU session. 2ch-c. The CHF acknowledges by sending Charging Data Response [Update] to the SMF.

  • 信令分析：CHF收到后，将这次QoS变更事件记录到CDR中。这个记录对于事后分析网络质量、或者实现按QoS等级收费非常重要。随后，CHF返回响应，可能会根据这次变更，调整下发给SMF的触发器或配额策略。

4. “结账关单”：PDU会话释放计费流程 (5.2.2.2.4 PDU Session Release)

小杰结束了通话，并关闭了手机的移动数据，准备休息。PDU会话释放流程被触发。规范中的**“Figure 5.2.2.2.4-1: PDU Session Release”**展示了最后的计费动作。

2ch-a. The SMF sends Charging Data Request [Termination] to the CHF for terminating the charging associated with PDU sessions, with the trigger “End of PDU session”.

  • 信令分析：
    1. 触发：“End of PDU session”事件被触发，这是一个强制的“立即报告”事件。
    2. SMF行动：SMF执行最后一次计费上报，封装Charging Data Request[Termination]消息。
    3. 消息内容：这个消息是“最终陈词”。它包含了自上次报告以来、到会话结束这一时间段内所有业务的最终使用量。

2ch-b. The CHF closes the CDR for the PDU session.

  • 信令分析：CHF收到[Termination]请求后，将这最后一笔使用量数据追加到对应的CDR中，然后，它会将这个CDR的状态从“Open”修改为“Closed”。一个关闭的CDR意味着它已经完整，可以被后续的CGF和计费域（BD）进行处理和归档。

2ch-c. The CHF acknowledges by sending Charging Data Response [Termination] to the SMF.

  • 信令分析：CHF向SMF返回最终确认，表示“账已结清，此会话的计费已正式结束”。SMF收到后，就可以安心地清理与该计费会话相关的所有上下文信息。至此，一个计费会话的完整生命周期画上了句号。

文章结尾

通过对5.2.2节非漫游场景下PDU会话计费全流程的解读，我们将之前学习的抽象原则与具体的信令交互一一对应了起来。我们像信令分析师一样，追踪了一个计费会话从[Initial]的诞生，到[Update]的成长，再到[Termination]的消亡的全过程。我们清楚地看到，每一次与CHF的“对话”，都是由预设的触发器精确驱动的，消息内容承载着丰富的网络和业务上下文。

这套标准化的流程，是5G实现大规模、自动化、精细化计费运营的基石。在接下来的文章中，我们将基于这个基础流程，去探索更复杂的场景，例如SSC模式下的会话迁移计费流程，看看这套基础的“三部曲”是如何被巧妙地组合和运用，以应对5G网络千变万化的移动性挑战。

FAQ环节

Q1：在PDU会话建立时，SMF是先联系PCF拿策略，还是先联系CHF开户？ A1：SMF是先联系PCF拿策略。这个顺序至关重要。因为PCF的策略会直接影响计费的方式，例如，PCF可能会根据用户签约或当前的网络情况，决定某个业务需要在线计费还是离线计费，甚至直接指定一个特定的CHF地址。SMF必须在拿到这些“指导方针”后，才能构造出内容正确的初始计费请求（Charging Data Request[Initial]）发给CHF。

Q2：什么是CDR（计费数据记录）？它在计费流程中何时被创建和关闭？ A2：CDR（Charging Data Record）可以理解为一个详尽的电子话单，记录了一次计费服务（如一个PDU会话）的所有相关信息，包括用户信息、会话属性、各个业务的流量/时长使用量、QoS变化、位置变化等。CDR在CHF收到[Initial]请求时被创建并打开（Open），在会话期间，每次收到[Update]请求，CHF都会向这个打开的CDR中追加新的信息。最后，在CHF收到[Termination]请求时，它会做最后一次信息追加，然后关闭（Close）这个CDR。

Q3：为什么在PDU会话修改流程中，SMF也要上报一次使用量？ A3：这主要是为了保证计费的精细度和准确性。会话修改通常意味着网络状态或业务属性发生了重要变化（如QoS变更）。在变更的精确时间点上报一次使用量，可以将变更前和变更后的使用情况清晰地分离开。例如，如果运营商对不同QoS等级的流量有不同的价值评估或定价，那么在QoS变更时进行一次分割和报告，就使得这种差异化计费成为可能。

Q4：如果SMF和CHF之间的计费消息丢失了会怎么样？ A4：3GPP为计费这种高可靠性要求的交互设计了重传和故障恢复机制。Charging Data Request/Response消息交互基于可靠的传输协议（如TCP/HTTP2），并包含调用序列号（Invocation Sequence Number）。如果SMF发送了一个请求但没有在规定时间内收到响应，它会进行重传。CHF侧也能根据序列号来识别和处理重复的消息。此外，规范还定义了CHF和SMF之间的故障倒换和数据恢复流程，以确保在网元故障等极端情况下，计费信息的丢失被最小化。

Q5：这些流程图看起来很复杂，实际网络中真的是这样一步步交互的吗？ A5：是的，实际商用网络中的交互流程与这些标准流程图高度一致。这些流程图是不同厂商设备（如A厂商的SMF和B厂商的CHF）能够互联互通的“法律依据”。通过信令抓包工具，我们可以清晰地捕获到这些Charging Data Request/Response消息，其内容和触发时机都严格遵循着本规范的定义。当然，为了性能优化，在某些情况下，多个事件可能会被合并到一次Update请求中上报，但其基本逻辑和触发原则是不变的。

关系图谱