51学通信

深度解析 3GPP TS 32.290：5.1 Offline charging scenario (离线计费场景)

26分钟阅读

深度解析 3GPP TS 32.290：5.1 Offline charging scenario (离线计费场景)

本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“5.1 Offline charging scenario”的核心章节，旨在为读者提供一个关于5G离线计费全景视图。

欢迎来到5G技术深度解析系列。在数字化浪潮席卷全球的今天，5G不仅是速度的飞跃，更是商业模式创新的催化剂。而这一切的基石，离不开一个精密、高效、灵活的计费系统。本系列文章将带您深入3GPP的“大脑”，逐一剖析5G计费的核心规范——TS 32.290。

作为系列的第一篇，我们将从最基础也最经典的计费模式——**离线计费（Offline Charging）开始。为了让抽象的技术概念变得生动，我们引入今天的主角：一架名为“迅翼-007”**的先进物流无人机。它服务于一家大型物流公司，负责在城市间执行高价值货物的快速配送和关键基础设施的巡检任务。今天，我们将跟随“迅翼-007”一整天的任务，来揭示5G离线计费的每一个细节。

1. 离线计费：信任之上的“秋后算账”

在深入5G的离线计费场景之前，我们必须理解其核心思想。离线计费，顾名思义，计费过程与业务的实际执行过程是分离的。它不像我们手机预付费套餐那样，每用一点流量就实时扣费，而更像我们大部分家庭使用的水电煤账单——先使用，后结算。

这种模式建立在“信任”的基础上，运营商相信用户在使用完服务后会支付费用。在技术实现上，网络侧的设备（如基站、核心网网元）会忠实地记录用户每一次服务使用情况，生成详单，然后在某个时间点（如一天结束后）将这些详单汇总，发送给计费中心进行批处理和出账。

1.1 基本原则 (Basic Principles)

规范的第一句话就为我们指明了方向，它并没有在当前文档中重新发明轮子，而是指向了整个3GPP计费体系的纲领性文件。

5.1.1 Basic principles Basic principles for offline charging are defined in TS 32.240.

这句话虽然简短，但信息量巨大。它告诉我们，要理解5G的离线计费，必须先回到源头——TS 32.240《Charging architecture and principles》。这个规范定义了所有3G/4G/5G网络计费的通用架构和原则。

简单来说，TS 32.240为离线计费描绘了这样的蓝图：

  • 核心实体：引入了两个关键功能实体。计费触发功能 (CTF, Charging Trigger Function) 负责在网络中监控业务事件并生成计费信息；计费功能 (CHF, Charging Function) 负责收集这些信息，并生成最终的话单数据记录 (CDR, Charging Data Record)。
  • 核心产物：离线计费的最终产出物是CDR。你可以把它想象成一张详细的消费小票，记录了“谁（用户）、在什么时间、使用了什么业务、用了多少量（时长/流量等）、结果如何”等信息。
  • 核心流程：CTF在业务发生时（开始、中间、结束）生成计费事件，并将这些事件上报给CHF。CHF将收到的事件组合、关联，最终生成一个或多个完整的CDR。这些CDR文件随后被送往运营商的营帐系统（Billing Domain, BD），用于计算费用、出具账单。

现在，让我们把这些概念应用到“迅翼-007”上。

场景设定：“迅翼-007”所属的物流公司与运营商签订了企业后付费合同。运营商为无人机网络提供了专用的APN（接入点名称）或切片，所有的数据和服务费用都按月结算。网络中的会话管理功能 (SMF) 内嵌了CTF的角色，它会时刻关注“迅翼-007”的网络连接。而在运营商的数据中心，运行着强大的CHF，准备接收所有无人机的计费数据。

2. 离线计费的两大核心场景

了解了基本原则后，我们来看规范如何将这些原则落地为具体的交互场景。

5.1.2.1 Introduction Two basic scenarios are used:

  • Event based charging;
  • Session based charging.

Both scenarios may generate CDR files, which may then be transferred to the network operator’s BD for the purpose of subscriber billing and/or inter-operator accounting.

规范明确指出了离线计费的两种基本模式：基于事件的计费 (Event based charging) 和 基于会话的计费 (Session based charging)。

  • 基于事件的计费：适用于一次性、短时、原子性的业务。可以将其理解为“按次计费”。比如发送一条短信、完成一次API调用、或者像“迅翼-007”完成一次“投递确认”信令的上传。这个动作一旦完成，计费事件就随之完成，整个过程非常短暂。

  • 基于会话的计费：适用于持续一段时间、有明确开始和结束标志的业务。可以将其理解为“按时长/流量计费”。比如一次VoNR通话、一次视频流的观看、或者像“迅翼-007”执行的一次长达30分钟的高清视频巡检任务。这类业务在使用过程中会持续消耗网络资源。

接下来，我们将通过“迅翼-007”的任务来详细拆解这两种场景的信令流程。

2.1 场景一：基于事件的计费 (Event Based Charging)

任务背景：上午9点，“迅翼-007”成功将一个高价值医疗包裹投递到指定医院的楼顶。投递完成后，它需要立即向物流中心发送一条投递成功的确认消息。这条消息非常小，通过5G网络发送，属于一个典型的一次性事件。

规范通过 “Figure 5.1.2.2.1.1: Post Event Charging” 这张图，为我们清晰地展示了这个过程。我们来一步步解读。

2.1.1 图解流程：Post Event Charging (PEC)

这个流程被称为“后事件计费”，意味着计费信息的上报发生在业务完成之后。

步骤1: Request for resource usage (资源使用请求) “迅翼-007”的机载计算机（UE）向网络发起请求，要求发送一条确认消息。这个请求被送达到核心网的相关网络功能（NF），比如SMF。此刻，SMF作为CTF，已经准备好要“记账”了。

步骤2: Content/Service Delivery (内容/服务交付) 5G网络为“迅翼-007”分配了必要的无线和传输资源。确认消息被成功发送到物流中心服务器。从“迅翼-007”的角度看，服务已经完成了。

步骤3: Charging Data Request [Event] (计费数据请求[事件]) 服务交付后，CTF（SMF）立刻生成了一条计费事件。这个事件包含了所有必要的信息：无人机身份（SUPI/GPSI）、服务类型（短信或数据传输）、事件发生时间、事件结果（成功）等。随后，CTF将这些信息封装在一个Charging Data Request消息中，并标记为[Event]类型，发送给CHF。

  1. Charging Data Request [Event]: The NF (CTF) the CTF generates charging data related to the delivered service and sends the request for the CHF to store related charging data for CDR generation purpose.

这里的关键是“generates charging data related to the delivered service”，计费数据是在服务交付后生成的。CTF的责任是将这些原始数据发送给CHF，用于后续生成正式的CDR。

步骤4: Create CDR (创建CDR) CHF接收到来自CTF的请求后，它会验证信息的完整性，然后基于这些信息，按照预定义的格式，创建一个CDR。这个CDR就像是为这次“投递确认”事件盖了一个官方的、可用于记账的“戳”。

  1. Create CDR: the CHF stores received information and creates a CDR related to the service.

CHF此时不仅是创建，还会存储这个CDR。在实际系统中，可能会有成千上万的CDR在短时间内生成，它们会被统一管理，等待批处理。

步骤5: Charging Data Response [Event] (计费数据响应[事件]) CHF在成功创建并存储CDR后，会向CTF回送一个Charging Data Response消息，告知CTF：“消息收到，账已记下，你可以放心了”。这个响应确保了计费信息没有丢失，形成了一个完整的闭环。

  1. Charging Data Response [Event]: The CHF informs the NF (CTF) on the result of the request.

至此，一次简单的事件计费就完成了。整个过程对于业务本身是非侵入的，它在后台默默发生，确保了每一次微小的网络使用都被精确记录。

2.2 场景二：基于会话的计费 (Session Based Charging)

任务背景：下午2点，“迅翼-007”接到一项新任务：对城市的一段关键输电线路进行30分钟的高清视频巡检。这意味着它需要建立一个持续的PDU会话，并在此期间稳定地上传高清视频流。这是一个典型的会话类业务。

规范通过 “Figure 5.1.2.2.2.1: Offline charging” 这张复杂的时序图，为我们描绘了会话计费的全过程。我们可以将这个过程分解为三个主要阶段：会话建立、会话中和会话终止。

2.2.1 图解流程：Offline Session Charging

阶段一：会话建立 (Session Establishment)

步骤1: Request for service delivery and start of service delivery (服务交付请求与开始) “迅翼-007”向网络请求建立一个PDU会话，用于视频回传。这个请求由AMF转发给SMF。SMF（作为CTF）识别出这是一个需要进行会话计费的业务。

步骤2: Charging Data Request [Initial] (计费数据请求[初始]) 在PDU会话成功建立，业务即将开始时，CTF（SMF）会立即向CHF发送一个Charging Data Request消息。与事件计费不同，这次的消息被标记为[Initial]。它在告诉CHF：“注意，一个全新的计费会话开始了，请为此准备一个账本。”

  1. Charging Data Request [Initial]: The NF (CTF) sends the request to inform the CHF about the service to be started.

这个初始请求非常关键，它标志着计费周期的开始。

步骤3: Open CDR (打开CDR) CHF收到[Initial]请求后，会在其数据库中打开一个新的CDR。这个CDR目前还是“开放”状态，它记录了会话的开始时间、无人机身份等初始信息，并准备好随时接收后续的更新。

  1. Open CDR: the CHF opens a CDR related to the service.

步骤4: Charging Data Response [Initial] (计费数据响应[初始]) CHF向CTF返回一个Charging Data Response，确认CDR已经打开。这个响应中还可能包含一些重要的策略信息，比如“Usage Reporting Triggers”（使用量上报触发器），它会告诉CTF在何种情况下需要进行中间汇报。

  1. Charging Data Response [Initial]: The CHF informs the NF (CTF) on the result of the request and optionnaly provides the usage reporting triggers applicable to the service.

阶段二：会话进行中 (Session Ongoing & Usage Reporting)

步骤5: Service delivery ongoing (服务持续交付) “迅翼-007”沿着输电线路飞行，机载摄像头拍摄的高清视频流通过5G网络源源不断地传回监控中心。PDU会话持续进行中。

步骤6: Usage reporting trigger (使用量上报触发) 在会话进行过程中，CTF会根据CHF下发的策略或本地配置，监控特定的触发条件。这些触发器可能包括：

  • 时长触发：例如，每隔10分钟汇报一次。
  • 流量触发：例如，每使用1GB流量汇报一次。
  • QoS变化：例如，视频流的QCI（QoS Class Identifier）发生了改变。
  • 位置变化：例如，“迅翼-007”飞入了新的TA（Tracking Area）。

假设CHF下发的策略是“每10分钟汇报一次”。当会话开始10分钟后，这个触发器被满足。

  1. Usage Reporting Trigger: the NF (CTF) generates charging data related to service delivered, based on a trigger for usage reporting is met.

步骤7: Charging Data Request [Update] (计费数据请求[更新]) 触发条件满足后，CTF会立刻打包过去10分钟内的使用量信息（例如，上行流量500MB，下行流量10MB），封装在一个标记为[Update]的Charging Data Request消息中，发送给CHF。

  1. Charging Data Request [Update]: the NF (CTF) sends the request for reporting the related charging data to the CHF.

步骤8: Update CDR (更新CDR) CHF收到[Update]请求后，并不会创建新的CDR，而是找到之前为这个会话打开的那个“开放”状态的CDR，并将新的使用量信息追加进去。这就像在购物小票上不断添加新的商品项目。

  1. Update CDR: the CHF updates the CDR with charging data related to the service.

步骤9: Charging Data Response [Update] (计费数据响应[更新]) CHF向CTF返回响应，确认更新已收到。这个过程会不断重复。在“迅翼-007”的30分钟任务中，这个更新流程至少会发生2次（在第10分钟和第20分钟）。

步骤10: Service delivery ongoing (服务持续交付) 无人机继续执行任务，计费也在后台有条不紊地进行记录。

阶段三：会话终止 (Session Termination)

步骤11: Service release (服务释放) 30分钟后，“迅翼-007”完成巡检任务，准备返航。它主动向网络请求释放PDU会话。

步骤12: Charging Data Request [Termination] (计费数据请求[终止]) 在PDU会话被释放时，CTF会进行最后一次“盘点”，统计从上次汇报到会话结束这段时间内的使用量。然后，它将这最后一部分使用量信息，连同一个“会话结束”的标志，封装在一个标记为[Termination]的Charging Data Request消息中，发送给CHF。这是它为这个会话发的最后一条消息。

  1. Charging Data Request [Termination]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination.

步骤13: Close CDR (关闭CDR) CHF收到[Termination]请求后，会将最后的使用量信息追加到CDR中，并进行最终的计算（例如，总时长、总流量）。然后，它会将这个CDR的状态从“开放”变为“关闭”。一个关闭的CDR意味着它已经完整，可以被发送到计费域进行处理了。

  1. Close CDR: the CHF closes the CDR with charging data related to the service termination.

步骤14: Charging Data Response [Termination] (计费数据响应[终止]) CHF向CTF返回最终的响应，确认计费会话已成功关闭。至此，整个会话计费流程完美结束。

3. 总结与对比

通过“迅翼-007”一天的任务，我们详细体验了5G离线计费的两种核心场景。现在，让我们用一个表格来清晰地对比它们：

特性基于事件的计费 (Event Based Charging)基于会话的计费 (Session Based Charging)
适用业务一次性、原子性、短暂的业务（如短信、信令）持续性、有明确开始/结束的业务（如通话、上网）
核心流程请求 → 交付 → 上报 → 创建CDR初始上报 → 打开CDR → 中间更新 → 终止上报 → 关闭CDR
消息类型[Event][Initial], [Update], [Termination]
CDR管理每个事件一个独立的CDR一个会话对应一个CDR，在会话期间持续更新
复杂性简单、直接复杂，需要管理会话状态和多种触发器
“迅翼-007”示例完成投递后发送“确认消息”执行30分钟的高清视频巡检任务

离线计费作为一种成熟而可靠的计费模式，在5G时代依然扮演着不可或缺的角色，尤其是在物联网、企业专网等后付费场景中。它通过标准化的流程和接口，确保了网络中发生的每一个有价值的活动都能被精确、无遗漏地记录下来，为运营商的商业变现提供了坚实的数据基础。

在下一篇文章中，我们将探讨与离线计费相对的、更具实时性的——在线计费（Online Charging Scenario）。届时，我们将看到5G网络是如何实现实时信控、预付扣费等更为复杂的计费能力的。敬请期待！

FAQ - 常见问题解答

Q1：离线计费（Offline Charging）和在线计费（Online Charging）最核心的区别是什么？ A1：最核心的区别在于授权与交互的实时性。在线计费要求在服务使用前或使用中，实时地向计费系统请求授权（检查余额/配额），并在配额即将用尽时再次交互，否则服务会被中断。而离线计费则是在服务完成后才将使用信息上报给计费系统，整个过程对实时业务的执行没有阻塞或干预。简单来说，在线计费是“先付款/授权，后消费”，离线计费是“先消费，后记账”。

Q2：什么是CDR（Charging Data Record），它为什么如此重要？ A2：CDR（计费数据记录）是离线计费的最终产物，可以理解为一张标准格式的电子“发票”或“消费详单”。它详细记录了单次服务使用的所有相关信息，如用户标识、服务类型、开始/结束时间、使用量（时长/流量）、服务质量、位置信息等。CDR是运营商进行用户计费、网络优化、数据分析、欺诈检测以及网间结算的根本依据，是电信运营商将网络服务转化为商业收入的核心数据。

Q3：在真实的5G网络中，通常是哪个网络功能（NF）扮演CTF（计费触发功能）的角色？ A3：CTF不是一个独立的物理设备，而是一个逻辑功能，它内嵌在处理具体业务的NF中。对于数据业务（PDU会话），**SMF（Session Management Function）**是主要的CTF。对于移动性相关的事件（如注册、服务请求），**AMF（Access and Mobility Management Function）可以作为CTF。对于短信业务，则是SMSF（SMS Function）**扮演CTF的角色。

Q4：在基于会话的离线计费中，为什么需要中间的[Update]消息？只在会话结束时上报一次不行吗？ A4：不行，中间更新（[Update]）至关重要，主要有以下几个原因：

  1. 防止数据丢失：对于长时间运行的会话（如长达数小时的视频会议或IoT连接），如果只在最后上报，一旦中间出现网络设备故障、重启或连接异常中断，整个会话的计费数据就会全部丢失。定期更新可以将损失降到最低。
  2. 准实时监控：运营商需要监控网络中的资源消耗情况，中间更新可以提供准实时的数据，用于网络性能分析和容量规划。
  3. 支持复杂的计费策略：某些计费策略可能与时间（如不同时段费率不同）或位置相关，中间更新可以及时反映这些变化，确保计费的准确性。

Q5：离线计费听起来有些“过时”，在强调实时交互的5G时代，它还有广泛的应用场景吗？ A5：是的，离线计费在5G时代依然非常重要且应用广泛。

  1. 后付费用户：全球有大量的后付费个人用户和所有企业用户，他们的计费模式天然就是离线计费。
  2. 物联网（IoT/M2M）：海量的物联网设备通常数据量小、不要求实时信控，采用离线计费可以极大地降低网络信令开销和计费系统的处理压力。
  3. 运营商内部和网间结算：用于统计和结算不同部门、不同运营商之间的漫游费用等，这些都是批处理模式，天然适合离线计费。
  4. 降低信令开销：对于无需实时信控的业务，采用离线计费可以避免频繁的在线计费交互，节省了宝贵的网络资源，提升了系统效率。

关系图谱