好的,我们继续之前的深度解析之旅。在分别探讨了5G的离线和在线计费之后,现在我们将迎来一个真正体现5G架构先进性的主题——融合计费。

深度解析 3GPP TS 32.290:5.3 Converged Charging scenario (融合计费场景)

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

在前两篇文章中,我们分别认识了为企业无人机“迅翼-007”提供“先用后付”服务的离线计费系统,以及为消费者“美美”管理预付费套餐的在线计费系统。它们各自为政,逻辑清晰。然而,在5G这个万物互联的时代,业务模式空前复杂,一个用户或一台设备可能同时需要两种计费模式。为了应对这一挑战,5G架构进行了一次意义深远的进化——融合计費(Converged Charging)

融合计费并非简单地将在线和离线功能堆砌在一起,而是通过统一的架构、统一的接口和统一的消息流程,实现对所有业务的计费处理。这大大简化了网络,降低了运营商的运营成本,并为灵活的业务创新铺平了道路。

今天,我们的主角是**“李工”**,一位在偏远山区维护风力发电机的现场工程师。他使用一台工业级5G AR眼镜,这台设备既需要连接公司内网进行常规数据上报(类似离线计费),又需要进行高精度的AR远程专家指导(需要严格的在线实时信控)。李工和他的AR眼镜,将为我们完美演绎融合计费的强大之处。

1. 融合计费的核心原则:合二为一的艺术

融合计费的精髓在于“统一”。规范开宗明义地指出了其与传统计费模式的根本不同。

5.3.1 Basic principles When offline charging and online charging are applicable to a service delivery, the charging information of both offline charging (without quota management) and online charging (with quota management) can be provided in a single command. The triggering for reporting the charging information can be any triggers of the offline charging or online charging (deferred or immediate triggers).

这句话揭示了融合计费的第一个“魔力”:单一指令(single command)。SMF(作为CTF)不再需要维护两套独立的接口和逻辑去分别对接离线和在线计费系统。现在,它只需要通过一个统一的Nchf_ConvergedCharging服务接口,就可以在一个计费请求消息中,同时携带需要在线信用控制的业务(例如,AR视频流)和只需要事后记账的业务(例如,后台日志上传)的计费信息。

1.1 阻塞模式 vs. 非阻塞模式 (Blocking vs. Non-blocking)

为了应对不同业务的实时性要求,融合计费引入了两种关键的调用模式。

The invocation of the Charging Data Request for start of service, in case there is no valid quota for the rating group, can be done in either blocking mode or non-blocking mode:

  • blocking mode: the service delivery shall not start before its authorization from CHF;
  • non-blocking mode: the service delivery may start before its authorization from CHF.
  • 阻塞模式(Blocking Mode):这是“安全第一”的模式。对于像李工的AR远程指导这样至关重要的业务,SMF在收到业务请求后,会先“暂停”业务的建立,并向CHF发起授权请求。只有在收到CHF明确的授权响应(即批复了配额)之后,SMF才会放行业务,让AR视频流开始传输。这确保了运营商不会有任何资金风险。

  • 非阻塞模式(Non-blocking Mode):这是“体验优先”的模式。对于某些对时延极其敏感,但价值不高的业务,SMF可以在向CHF发送授权请求的同时,就允许业务开始。它“乐观”地假设CHF会授权成功。这种模式减少了业务建立的等待时延,但运营商需要承担微小的信用风险(即在CHF返回拒绝响应之前,用户可能已经消耗了少量资源)。

1.2 单元确定的灵活性

融合计费继承并发展了在线计费中单元确定的灵活性。

For invoking the ConvergedCharging service with quota management, the ConvergedCharging service will operate in decentralized unit determination with the provided amounts of the Quota Requested information element otherwise if no amount is included in the Quota Requested information element, the ConvergedCharging service will operate in centralized unit determination and rating.

这里的逻辑非常清晰:

  • 如果CTF(SMF)在计费请求中包含了**Quota Requested信息单元(IE),就意味着它在告诉CHF:“我(CTF)已经决定了需要多少资源(例如100MB),请你(CHF)按这个量来授权和计费。” 这就是分散式单元确定**。
  • 如果CTF的请求中没有包含Quota Requested IE,则意味着它在说:“我不知道该申请多少,请你(CHF)根据用户策略,直接告诉我该用多少。” 这就是集中式单元确定和计费

2. 融合事件计费:一次性业务的统一处理

李工在开始复杂的AR维修任务前,需要从公司服务器下载一个一次性的加密安全证书,以获得对风机控制单元的访问权限。这是一个典型的事件类业务。

5.3.2.2 Event based charging For Converged Event based Charging, the following cases are supported:

  • Immediate Event Charging (IEC);
  • Post Event Charging (PEC).

融合计费优雅地支持了两种事件计费模式:

  • PEC (Post Event Charging):即“事后事件计费”,其流程与我们在离线计费章节中分析的完全一致。适用于公司内部的、可信任的事件,如一次普通的日志记录。
  • IEC (Immediate Event Charging):即“立即事件计费”,它要求在服务交付前完成计费。李工下载安全证书就需要付费,必须采用IEC模式。

规范中的“Figure 5.3.2.2.1: IEC- Event based charging with Decentralized and Centralized Unit Determination, Centralized Rating”详细描绘了IEC流程。

  1. Request for resource usage: 李工的AR眼镜请求下载安全证书。
  2. Units Determination: AR眼镜应用(或CTF)确定这次服务是“1个安全证书”,这属于分散式单元确定。
  3. Charging Data Request [Event, Units]: CTF在交付证书,向CHF发起请求,请求对“1个安全证书”进行计费。
  4. Account, Rating Control: CHF收到请求,检查公司账户余额,计算出证书费用(如2元)并执行扣款。
  5. Create CDR: CHF创建一条CDR记录本次交易。
  6. Charging Data Response [Event, Units]: CHF返回成功响应,可能还会携带一些授权信息。
  7. Granted Units Supervision & Content/Service Delivery: CTF收到成功响应后,才允许安全证书被下载到AR眼镜。

3. 融合会话计费:复杂业务的核心引擎

这部分是融合计费的核心,也是最复杂的部分。李工现在要开始进行长达一小时的AR远程专家指导了。这个业务既需要在线计费的实时信控,也可能伴随着一些需要离线记账的后台数据同步。

融合会话计费主要分为两大类:SCURECUR

3.1 SCUR:带单元预留的会话计费

SCUR (Session Charging with Unit Reservation) 是最常见、功能最强大的融合会话计费模式,它支持会话中的多次配额申请(再授权)。李工的AR指导就是典型的SCUR场景。

我们将以阻塞模式为例,详细解读规范中的“Figure 5.3.2.3.1: SCUR - Session based charging with Decentralized and Centralized Unit Determination, Centralized Rating”。这个流程图非常复杂,我们将其分解为几个关键阶段。

阶段一:会话建立与首次授权 (步骤1-8)

这个阶段与我们在线计费章节中美美的经历非常相似。

  1. 李工启动AR远程指导,SMF收到请求。
  2. SMF确定需要100MB的初始流量配额(分散式单元确定)。
  3. SMF发送Charging Data Request [Initial, Quota Requested]给CHF(阻塞模式,业务等待)。
  4. CHF执行账户检查、费率计算和资金预留。
  5. CHF打开一个CDR。
  6. CHF返回Charging Data Response [Initial, Quota Granted],授予100MB配额,并可能设置门限。
  7. SMF开始监控这100MB配额的使用。
  8. SMF允许业务流量通过,AR指导开始。

阶段二:会话中的使用量上报 (步骤9-13)

这是一个有趣的混合点。假设在AR指导的同时,AR眼镜还会上报一些非关键的设备状态遥测数据,这部分数据被配置为不需要配额管理(即离线计费模式)。

  1. Usage Reporting Trigger: 比如每5分钟,离线计费的触发器被触发。
  2. Charging Data Request [Update, Units Used]: SMF向CHF发送更新请求,但这个请求中上报的Units Used是属于遥测数据的,并且明确标记为“非配额管理”。
  3. Account, Rating Control: CHF收到后,仅对这部分用量进行记账(累加到CDR中),不涉及配额或预留金的操作。
  4. Update CDR: CHF更新CDR。
  5. Charging Data Response [Update]: CHF返回确认响应。

阶段三:会话中的配额管理与再授权 (步骤14-18)

现在,AR视频流消耗的流量即将到达100MB配额的门限。

  1. Quota management Trigger: 配额门限被触发。
  2. Charging Data Request [Update, Units Used, Quota Requested]: SMF立即发起再授权请求,上报已使用的配额流量,并请求新的100MB配额。
  3. Account, Rating, Reservation Control: CHF执行复杂的操作:结算已上报的用量(扣费、解冻剩余预留金),并为新的100MB配额执行新的预留。
  4. Update CDR: 更新CDR,记录本次用量结算和新的配额信息。
  5. Charging Data Response [Update, Quota Granted]: CHF授予新的100MB配额。这个循环会一直持续。

阶段四:会话终止 (步骤19-24) AR指导结束,流程与在线计费的终止流程一致,SMF上报最后一次的用量,CHF进行最终结算并关闭CDR。

3.2 ECUR:带单元预留的事件计费(会话模式)

ECUR (Event Charging with Unit Reservation) 是一种简化的会话计费模式。它适用于那些总时长/总量固定,且需要在业务开始前就一次性预留所有费用的会话。例如,李工需要运行一个15分钟的“风机叶片全方位扫描”程序,这个程序费用固定,必须在开始前就完成授权。

ECUR的流程(见Figure 5.3.2.3.3)与SCUR的主要区别在于:

  • 一次性授权:在会话开始时,SMF就会请求全部所需的资源(例如15分钟时长),CHF也一次性预留全部费用。
  • 无中间更新:在整个15分钟的扫描过程中,没有[Update]消息交互。
  • 直接终止:15分钟结束后,SMF直接发送[Termination]消息上报最终用量,CHF进行结算。

ECUR可以看作是“会话级”的IEC,适用于有固定时长的服务包。

4. 计费通知:当计费系统主动“召唤”

在之前的场景中,总是CTF(SMF)主动向CHF发起请求。融合计费引入了一个强大的反向机制——计费通知。

5.3.2.4 Charging notification The CHF can provide notifications to the NF (CTF), the NF (CTF) implicitly subscribes to these when it sends a Charging Data Request [Initial]…

这意味着,一旦一个计费会话建立,CHF就有能力在任何需要的时候,主动向CTF发送通知。

场景:在李工进行AR指导时,公司后台管理员发现该项目的预算即将耗尽,于是在计费策略系统中紧急调低了该业务的可用额度。CHF检测到这个策略变化,需要立即通知SMF。

此时,CHF会主动向SMF发送一个Charging Notify Request,这个通知可以有两种目的(见Figure 5.3.2.4-1 和 5.3.2.4.2):

  • 请求再授权 (Re-authorization):CHF通知SMF:“你的配额策略变了,请立即上报当前用量并发起一次新的配额请求,我需要根据新策略重新给你授权。”
  • 请求终止 (Termination):如果预算已经用完,CHF会直接通知SMF:“立即终止这个用户的服务!” SMF收到后会立刻释放PDU会话,中断李工的AR指导。

这个机制赋予了计费系统前所未有的实时策略控制能力。

5. 动态切换:在线与离线模式的“无缝变身”

这是融合计费最令人惊叹的特性之一。一个正在进行的会话,可以在“在线计费模式”(需要配额管理)和“离线计费模式”(无需配额管理)之间动态切换。

5.3.2.5 Switch between quota managed and not quota managed When converged charging is used for a service delivery it is possible to in online charging to switch from quota management to quota management suspended, and in some cases back again.

场景:李工的AR指导任务完成了。现在,他需要将AR眼镜在过去一小时内录制的大量高清诊断视频(约5GB)上传到公司服务器。根据公司策略,这种大文件上传业务被定义为非实时、低优先级业务,不需要进行实时信控,只要记录总流量用于月底结算即可。

李工无需断开重连,可以直接在同一个PDU会话中开始上传。此时的流程(见Figure 5.3.2.5.1)将非常奇妙:

  1. SMF检测到业务类型变化,向CHF发起一个[Update]请求。
  2. CHF识别出这是大文件上传业务,根据策略,决定暂停配额管理
  3. CHF在Charging Data Response中返回一个特殊的结果码,明确告知SMF:“quota management is suspended”(配额管理已暂停)。
  4. 收到这个指令后,SMF就“变身”了。它停止了对配额和门限的监控,行为模式切换到了离线计费。它只会根据时间或流量的触发器,定期上报使用量,而不会在请求中包含Quota Requested
  5. 文件上传结束后,SMF发送[Termination]消息,CHF根据之前所有上报的用量(包括AR指导和文件上传),最终关闭CDR。

这个动态切换的能力,极大地提升了网络资源的利用效率,减少了不必要的信令交互,同时满足了复杂业务场景下的多样化计费需求。

6. 总结

融合计费是5G计费系统真正的“集大成者”。通过跟随现场工程师李工一天的复杂工作,我们看到了它如何通过统一的接口和流程,优雅地处理了从付费事件到长连接会话,从严格的实时信控到宽松的事后记账,甚至实现了在线和离线模式在会话内的动态切换。

这种前所未有的灵活性和统一性,是5G能够支撑千行百业数字化转型的关键基石之一。它使得运营商能够像“乐高积木”一样,自由组合各种计费策略,为最终用户和企业客户量身定制出最具吸引力的商业模式。


FAQ - 常见问题解答

Q1:相比于同时部署独立的在线(OCS)和离线(OFCS)计费系统,融合计费(Converged Charging)最大的优势是什么? A1:最大的优势在于简化和降本增效

  1. 架构简化:运营商不再需要维护两套独立的计费系统、两套接口协议和两套运维团队。一个融合的CHF即可处理所有业务,大大降低了CAPEX(资本支出)和OPEX(运营支出)。
  2. 网络功能简化:核心网中的NF(如SMF)也只需要对接一个Nchf接口,其内部逻辑大大简化,降低了开发和测试的复杂性。
  3. 业务上市更快:推出一个涉及混合计费模式的新业务时,无需在两个系统间进行复杂的开发和协调,所有策略都在一个融合系统中配置,极大地缩短了业务上线时间(Time-to-Market)。

Q2:在融合计费会话中,CHF如何区分哪些流量需要配额管理,哪些不需要? A2:这是通过**Rating Group(计费组)**来实现的。在PDU会话建立时,PCF(策略控制功能)会下发不同的计费规则给SMF。SMF会根据业务的数据流(如通过SDF模板识别),将流量映射到不同的Rating Group。例如,AR视频流可能被映射到Rating Group 1,后台遥测数据被映射到Rating Group 2。当SMF向CHF发送计费请求时,它会在Multiple Unit Usage这个IE中,为每个Rating Group分别上报用量,并只为需要配额管理的Rating Group(如RG 1)携带Requested Unit信息。CHF据此就能精确地对不同业务应用不同的计费模式。

Q3:什么是阻塞模式(Blocking Mode),它对用户体验有何影响? A3:阻塞模式是指CTF(如SMF)在收到需要在线计费的业务请求后,必须先暂停业务的建立,等待CHF的计费授权响应。只有收到CHF的“许可”(即授予了配额)后,业务才能继续。这会给业务的建立带来一个额外的“计费交互时延”。对于大多数业务,这个时延在毫秒级,用户几乎无感知。但对于时延要求极为苛刻的业务(如某些URLLC场景),运营商可能会选择非阻塞模式来优化初始接入速度。

Q4:CHF主动发起的“计费通知(Charging Notification)”主要用于哪些场景? A4:主要用于计费策略实时变更的场景,赋予运营商动态控制的能力。典型场景包括:

  1. 用户行为触发:用户通过App订购了一个新的流量包,策略立即生效,CHF需要通知SMF更新配额。
  2. 时间策略触发:进入“夜间闲时流量”时段,CHF通知SMF切换到新的计费费率或授予更优惠的配额。
  3. 后台策略变更:如例子中的李工,公司管理员调整了项目预算,CHF需要立即执行新的信用控制策略。
  4. 欺诈检测:检测到异常使用行为,CHF可主动通知SMF终止会话。

Q5:一个会话从“在线模式”切换到“离线模式”后,还能再切换回来吗? A5:可以的。规范指出“…and in some cases back again.”。这种切换是双向和动态的。例如,李工在上传完大文件后,如果又需要开启一段新的AR远程指导,那么SMF可以再次发起一个包含Quota Requested[Update]请求。CHF收到后,就会理解这是要恢复配额管理,于是会像首次授权一样,执行预留并授予配额。之后,会话就又回到了“在线计费模式”。这种灵活性是融合计费强大能力的体现。