简介本资源为3GPP TS 32.260 IMS计费技术规范的中文版PDF文档面向从事移动通信核心网计费系统研发、测试与运维的工程师以及需要理解IMS计费机制的通信专业学生与研究人员。文档系统梳理了IMS离线计费、在线计费与融合计费三种架构涵盖计费数据记录CDR、计费触发点、在线计费系统OCS、离线计费系统OFS、计费策略与规则功能CPRF以及Diameter、Gx等接口协议并给出定义、符号、缩写与参考文献等基础章节便于读者建立完整的计费知识框架。资源包内共1个PDF文件大小约2.65MB内容为规范正文适合作为案头查阅与对照英文原版学习的参考资料。目前已有195人学习下载对于理解从GSM、UMTS到LTE多制式下IMS计费标准、保障运营商计费准确性与互操作性具有实用价值。1. 从一张话单说起IMS 计费到底在算什么你手机打了一通 VoLTE 电话运营商怎么知道该收你多少钱这背后不是人工记账而是一套标准化的“自动记账规则”。IMS 计费通俗地说就是给 IP 多媒体子系统IMS里发生的每一次通话、每一条消息、每一次多媒体交互打上可追踪、可结算的标签。IMS 是 4G/5G 时代运营商提供语音和多媒体业务的核心网络而计费就是它的“收银台”。3GPP TS 32.260 就是这套收银台的“操作手册”——它规定了 IMS 网络里各个节点该在什么时候、把什么信息、通过什么接口送给计费系统。没有它运营商就不知道一通电话该算 5 毛还是 1 块用户也拿不到清晰的话单。搞懂它你就理解了移动通信里“钱是怎么算出来的”这条暗线。2. 为什么需要一份专门的 IMS 计费标准从“各算各的”到“统一账本”2.1 没有标准之前计费是场灾难在 IMS 出现之前语音走电路域计费相对简单——通话时长乘以费率一张话单就出来了。但 IMS 把语音、视频、消息、会议都搬到了 IP 网络上一个用户可能同时用着多种业务一个会话可能跨越多个运营商、多个接入网。如果每个设备厂商都按自己的方式记录用量运营商之间的结算就会变成一笔糊涂账。打个比方以前是各家小卖部自己记流水现在变成了连锁超市必须有一套统一的收银系统否则总部根本对不上账。3GPP TS 32.260 就是这套“统一收银系统”的规范它定义了计费架构、触发条件、消息流和接口协议让不同厂商的设备能说同一种“计费语言”。2.2 离线计费与在线计费两种“结账方式”这份标准把 IMS 计费分成两大模式理解它们的区别是搞懂全篇的关键。离线计费Offline Charging像信用卡消费先享受服务后出账单。网络节点把用户的活动记录成 CDR计费数据记录事后再由计费系统汇总出账。它适合后付费用户对实时性要求不高但要求记录完整、不丢单。在线计费Online Charging像预付费手机卡余额不够服务直接掐断。计费系统在服务使用过程中实时扣费需要和网络节点保持信令交互。它适合预付费用户能防止欠费但对系统响应速度和可靠性要求极高。标准里用一张架构图把这两条路径画得清清楚楚离线走 Rf 接口在线走 Ro 接口融合计费场景下两者还能协同工作。你不需要记住接口名但要理解一个核心逻辑——计费模式决定了网络节点在会话建立、中期、释放各阶段该做什么动作。2.3 计费标识符给每一笔消费贴上唯一标签IMS 计费最巧妙的设计之一是引入了一组标识符来串联一次会话中的所有计费事件。其中最关键的是ICIDIMS Charging Identifier你可以把它理解成快递单号一个会话从建立到释放无论经过多少个网络节点、产生多少条 CDR都带着同一个 ICID。这样后台对账时就能把散落在各处的记录拼成完整的一单。标准第 5.1.2 节详细规定了 ICID 的生成规则、传递方式和关联机制。还有接入网计费标识、运营商间标识符等辅助标签分别解决“从哪个网接进来的”“跨运营商怎么分账”的问题。这些标识符是计费准确性的基石少了任何一个都可能出现“有记录但拼不出完整会话”的翻车现场。3. 拆开看架构IMS 计费系统里都有谁在干活3.1 核心角色与分工IMS 计费架构不是单一设备而是一组功能实体的协作。标准第 4 章给出了高层架构主要角色包括CDFCharging Data Function负责收集网络节点发来的计费事件生成 CDR。可以理解为“记账员”。CGFCharging Gateway Function负责 CDR 的格式转换、合并和分发把账本交给后台系统。可以理解为“账本管理员”。OCSOnline Charging System在线计费的核心实时处理扣费请求、控制配额。可以理解为“收银员”。CTFCharging Trigger Function嵌入在各个网络节点里的计费触发模块负责在正确的时间点发出计费请求。可以理解为“扫码枪”。这些角色之间通过标准接口通信Rf 用于离线计费Ro 用于在线计费第 5.2.1 节还提到了基于服务接口的 Nchf。你不需要背下所有接口但要明白一个原则——每个接口都有明确的触发条件和消息格式不能随意发、也不能漏发。3.2 会话流程中的计费触发点标准第 5.2.2 节用大量篇幅描述了各种场景下的消息流从会话建立、中期过程到会话释放覆盖了移动发起、移动终止、PSTN 发起、IMS 发起、多方通话、AS 相关程序等。这些流程看起来繁杂但核心逻辑是一致的会话建立时CTF 向计费系统发送初始计费请求携带 ICID、用户标识、业务类型等信息。会话进行中根据触发条件如时间阈值、流量阈值、业务变更发送中期计费请求更新用量。会话释放时发送最终计费请求包含总用量和结束原因计费系统据此生成最终 CDR。以一次普通的 VoLTE 呼叫为例S-CSCF、AS、IBCF 等节点都可能产生计费事件每个事件都带着同一个 ICID。后台系统把这些事件按 ICID 聚合就能还原出完整的通话账单。如果某个节点漏发了事件账单就会缺一块——这就是为什么标准要把触发条件写得如此细致。3.3 在线计费的配额管理机制在线计费比离线多了一层“配额控制”。当用户发起会话时CTF 向 OCS 请求配额OCS 根据用户余额和套餐返回一个可用额度比如 10 分钟或 100MB。用户使用过程中CTF 监控用量快用完时再次请求配额。如果余额不足OCS 拒绝请求CTF 就终止服务。标准第 5.2.1.2 节描述了基于 Nchf 的在线计费特定流程包括配额请求、配额分配、配额使用报告等环节。这套机制的关键在于实时性和可靠性OCS 必须在极短时间内响应否则用户会感知到呼叫延迟同时要保证配额不超发否则运营商会亏钱。这也是为什么在线计费系统的部署和调优一直是运营商的核心关切。4. 容易搞混的几个概念别把计费当收费4.1 计费与收费记录和要钱是两回事易混点很多人把“计费”和“收费”当成同义词。为什么混日常语境里“计费”常常直接指向“收多少钱”。怎么区分在这份标准里计费Charging指的是收集、记录、传输用量信息的过程产出的是 CDR 和计费事件收费Billing是后台系统根据 CDR 计算价格、生成账单、执行扣款。TS 32.260 管的是前者不是后者。计费是“记账”收费是“收钱”中间还隔着定价、优惠、税务等环节。4.2 CDR 与话单原始记录和最终账单易混点把 CDR 直接等同于用户看到的话单。为什么混两者都包含通话时长、用量等信息。怎么区分CDR 是网络节点生成的原始计费记录可能一个会话产生多条格式是标准定义的 ASN.1 结构话单是计费系统对 CDR 进行聚合、定价、格式化之后呈现给用户的账单。CDR 是原料话单是成品。标准规范的是 CDR 的生成和传输不涉及话单的呈现样式。4.3 离线计费与在线计费不是“旧”和“新”的关系易混点认为在线计费更先进离线计费会被淘汰。为什么混在线计费听起来更“实时”、更“智能”。怎么区分两者是面向不同用户群体的并行方案。后付费用户天然适合离线计费预付费用户需要在线计费。标准同时维护两套架构并且在融合计费场景下让它们协同。选择哪种取决于运营商的用户结构和业务策略不是技术先进性的问题。4.4 ICID 与 Session-ID名字像作用不同易混点把 ICID 和 SIP 会话的 Session-ID 混为一谈。为什么混两者都标识一次会话都出现在信令里。怎么区分Session-ID 是 SIP 协议层面的会话标识用于信令路由和对话管理ICID 是计费层面的标识专门用于关联一次会话产生的所有计费事件。一个 SIP 会话可能对应一个 ICID但 ICID 的生命周期和传递范围由计费标准定义不受 SIP 信令流程影响。标准第 5.1.2.2 节专门规定了 ICID 的生成和关联规则。4.5 触发条件与计费事件原因和结果易混点把“触发条件”和“计费事件”当成一回事。为什么混两者总是成对出现。怎么区分触发条件是“什么时候该发计费请求”的规则比如会话建立、会话释放、时间阈值到达、业务变更等计费事件是触发之后实际发出的消息携带具体的用量信息。触发条件是因计费事件是果。标准第 5.1.4 节定义了触发条件的类型第 5.2.2 节描述了各种触发条件下产生的消息流。5. 什么时候该翻这份标准几个真实场景的判断这份中文版标准不是拿来通读的而是拿来查的。它最适用的场景是当你需要确认某个计费行为“标准里到底怎么规定的”时候。场景一排查计费差异。某运营商发现两个厂商设备对同一通电话的计费时长不一致一个记了 62 秒一个记了 58 秒。这时候需要翻到第 5.2.2 节对照会话释放流程确认计费停止的触发点到底应该在哪一步。标准里写得很清楚计费请求的发送时机取决于具体节点和场景差几秒可能是触发条件理解不同导致的。场景二设计新业务计费方案。某实验室要为一个 IMS 新业务设计计费流程需要确定用离线还是在线、在哪些节点埋触发点、ICID 怎么传递。第 4 章的架构和第 5 章的计费原则就是设计依据。标准不会告诉你“该收多少钱”但会告诉你“该怎么记”。场景三对接第三方 AS。当第三方 AS 需要实时提供资费信息RTTI时第 5.2.2.1.17 和 5.2.2.1.18 节描述了消息流和接口要求。如果你不按这个流程走计费系统可能收不到 RTTI 信息导致计费失败。什么时候别用如果你只是想了解“IMS 计费大概是怎么回事”不需要翻标准原文看科普文章就够了。标准是给实现者和测试者用的不是给入门者用的。另外这份标准是 2022 年发布的第 17 版如果你维护的是更早版本的网络需要确认版本差异——不同版本之间消息流和参数可能有变化。注意标准原文明确说明“本文件未经 3GPP 组织合作伙伴的任何批准程序不得实施”它是一份技术规范不是法律文件实施时需要结合具体网络环境和厂商文档。我刚开始接触 IMS 计费时以为把标准通读一遍就能搞懂结果翻到第 5 章就被各种消息流绕晕了。后来才明白这份标准的正确用法是“带着问题查”——先搞清楚自己面对的是离线还是在线、涉及哪些节点、卡在哪个流程然后直接翻到对应章节。从那以后我每次排查计费问题都强制自己先画一张会话流程图标出每个节点的触发点再对照标准确认。希望这个思路能帮到你。本文还有配套的精品资源点击获取
简介本资源为3GPP TS 32.260 IMS计费技术规范的中文版PDF文档面向从事移动通信核心网计费系统研发、测试与运维的工程师以及需要理解IMS计费机制的通信专业学生与研究人员。文档系统梳理了IMS离线计费、在线计费与融合计费三种架构涵盖计费数据记录CDR、计费触发点、在线计费系统OCS、离线计费系统OFS、计费策略与规则功能CPRF以及Diameter、Gx等接口协议并给出定义、符号、缩写与参考文献等基础章节便于读者建立完整的计费知识框架。资源包内共1个PDF文件大小约2.65MB内容为规范正文适合作为案头查阅与对照英文原版学习的参考资料。目前已有195人学习下载对于理解从GSM、UMTS到LTE多制式下IMS计费标准、保障运营商计费准确性与互操作性具有实用价值。1. 从一张话单说起IMS 计费到底在算什么你手机打了一通 VoLTE 电话运营商怎么知道该收你多少钱这背后不是人工记账而是一套标准化的“自动记账规则”。IMS 计费通俗地说就是给 IP 多媒体子系统IMS里发生的每一次通话、每一条消息、每一次多媒体交互打上可追踪、可结算的标签。IMS 是 4G/5G 时代运营商提供语音和多媒体业务的核心网络而计费就是它的“收银台”。3GPP TS 32.260 就是这套收银台的“操作手册”——它规定了 IMS 网络里各个节点该在什么时候、把什么信息、通过什么接口送给计费系统。没有它运营商就不知道一通电话该算 5 毛还是 1 块用户也拿不到清晰的话单。搞懂它你就理解了移动通信里“钱是怎么算出来的”这条暗线。2. 为什么需要一份专门的 IMS 计费标准从“各算各的”到“统一账本”2.1 没有标准之前计费是场灾难在 IMS 出现之前语音走电路域计费相对简单——通话时长乘以费率一张话单就出来了。但 IMS 把语音、视频、消息、会议都搬到了 IP 网络上一个用户可能同时用着多种业务一个会话可能跨越多个运营商、多个接入网。如果每个设备厂商都按自己的方式记录用量运营商之间的结算就会变成一笔糊涂账。打个比方以前是各家小卖部自己记流水现在变成了连锁超市必须有一套统一的收银系统否则总部根本对不上账。3GPP TS 32.260 就是这套“统一收银系统”的规范它定义了计费架构、触发条件、消息流和接口协议让不同厂商的设备能说同一种“计费语言”。2.2 离线计费与在线计费两种“结账方式”这份标准把 IMS 计费分成两大模式理解它们的区别是搞懂全篇的关键。离线计费Offline Charging像信用卡消费先享受服务后出账单。网络节点把用户的活动记录成 CDR计费数据记录事后再由计费系统汇总出账。它适合后付费用户对实时性要求不高但要求记录完整、不丢单。在线计费Online Charging像预付费手机卡余额不够服务直接掐断。计费系统在服务使用过程中实时扣费需要和网络节点保持信令交互。它适合预付费用户能防止欠费但对系统响应速度和可靠性要求极高。标准里用一张架构图把这两条路径画得清清楚楚离线走 Rf 接口在线走 Ro 接口融合计费场景下两者还能协同工作。你不需要记住接口名但要理解一个核心逻辑——计费模式决定了网络节点在会话建立、中期、释放各阶段该做什么动作。2.3 计费标识符给每一笔消费贴上唯一标签IMS 计费最巧妙的设计之一是引入了一组标识符来串联一次会话中的所有计费事件。其中最关键的是ICIDIMS Charging Identifier你可以把它理解成快递单号一个会话从建立到释放无论经过多少个网络节点、产生多少条 CDR都带着同一个 ICID。这样后台对账时就能把散落在各处的记录拼成完整的一单。标准第 5.1.2 节详细规定了 ICID 的生成规则、传递方式和关联机制。还有接入网计费标识、运营商间标识符等辅助标签分别解决“从哪个网接进来的”“跨运营商怎么分账”的问题。这些标识符是计费准确性的基石少了任何一个都可能出现“有记录但拼不出完整会话”的翻车现场。3. 拆开看架构IMS 计费系统里都有谁在干活3.1 核心角色与分工IMS 计费架构不是单一设备而是一组功能实体的协作。标准第 4 章给出了高层架构主要角色包括CDFCharging Data Function负责收集网络节点发来的计费事件生成 CDR。可以理解为“记账员”。CGFCharging Gateway Function负责 CDR 的格式转换、合并和分发把账本交给后台系统。可以理解为“账本管理员”。OCSOnline Charging System在线计费的核心实时处理扣费请求、控制配额。可以理解为“收银员”。CTFCharging Trigger Function嵌入在各个网络节点里的计费触发模块负责在正确的时间点发出计费请求。可以理解为“扫码枪”。这些角色之间通过标准接口通信Rf 用于离线计费Ro 用于在线计费第 5.2.1 节还提到了基于服务接口的 Nchf。你不需要背下所有接口但要明白一个原则——每个接口都有明确的触发条件和消息格式不能随意发、也不能漏发。3.2 会话流程中的计费触发点标准第 5.2.2 节用大量篇幅描述了各种场景下的消息流从会话建立、中期过程到会话释放覆盖了移动发起、移动终止、PSTN 发起、IMS 发起、多方通话、AS 相关程序等。这些流程看起来繁杂但核心逻辑是一致的会话建立时CTF 向计费系统发送初始计费请求携带 ICID、用户标识、业务类型等信息。会话进行中根据触发条件如时间阈值、流量阈值、业务变更发送中期计费请求更新用量。会话释放时发送最终计费请求包含总用量和结束原因计费系统据此生成最终 CDR。以一次普通的 VoLTE 呼叫为例S-CSCF、AS、IBCF 等节点都可能产生计费事件每个事件都带着同一个 ICID。后台系统把这些事件按 ICID 聚合就能还原出完整的通话账单。如果某个节点漏发了事件账单就会缺一块——这就是为什么标准要把触发条件写得如此细致。3.3 在线计费的配额管理机制在线计费比离线多了一层“配额控制”。当用户发起会话时CTF 向 OCS 请求配额OCS 根据用户余额和套餐返回一个可用额度比如 10 分钟或 100MB。用户使用过程中CTF 监控用量快用完时再次请求配额。如果余额不足OCS 拒绝请求CTF 就终止服务。标准第 5.2.1.2 节描述了基于 Nchf 的在线计费特定流程包括配额请求、配额分配、配额使用报告等环节。这套机制的关键在于实时性和可靠性OCS 必须在极短时间内响应否则用户会感知到呼叫延迟同时要保证配额不超发否则运营商会亏钱。这也是为什么在线计费系统的部署和调优一直是运营商的核心关切。4. 容易搞混的几个概念别把计费当收费4.1 计费与收费记录和要钱是两回事易混点很多人把“计费”和“收费”当成同义词。为什么混日常语境里“计费”常常直接指向“收多少钱”。怎么区分在这份标准里计费Charging指的是收集、记录、传输用量信息的过程产出的是 CDR 和计费事件收费Billing是后台系统根据 CDR 计算价格、生成账单、执行扣款。TS 32.260 管的是前者不是后者。计费是“记账”收费是“收钱”中间还隔着定价、优惠、税务等环节。4.2 CDR 与话单原始记录和最终账单易混点把 CDR 直接等同于用户看到的话单。为什么混两者都包含通话时长、用量等信息。怎么区分CDR 是网络节点生成的原始计费记录可能一个会话产生多条格式是标准定义的 ASN.1 结构话单是计费系统对 CDR 进行聚合、定价、格式化之后呈现给用户的账单。CDR 是原料话单是成品。标准规范的是 CDR 的生成和传输不涉及话单的呈现样式。4.3 离线计费与在线计费不是“旧”和“新”的关系易混点认为在线计费更先进离线计费会被淘汰。为什么混在线计费听起来更“实时”、更“智能”。怎么区分两者是面向不同用户群体的并行方案。后付费用户天然适合离线计费预付费用户需要在线计费。标准同时维护两套架构并且在融合计费场景下让它们协同。选择哪种取决于运营商的用户结构和业务策略不是技术先进性的问题。4.4 ICID 与 Session-ID名字像作用不同易混点把 ICID 和 SIP 会话的 Session-ID 混为一谈。为什么混两者都标识一次会话都出现在信令里。怎么区分Session-ID 是 SIP 协议层面的会话标识用于信令路由和对话管理ICID 是计费层面的标识专门用于关联一次会话产生的所有计费事件。一个 SIP 会话可能对应一个 ICID但 ICID 的生命周期和传递范围由计费标准定义不受 SIP 信令流程影响。标准第 5.1.2.2 节专门规定了 ICID 的生成和关联规则。4.5 触发条件与计费事件原因和结果易混点把“触发条件”和“计费事件”当成一回事。为什么混两者总是成对出现。怎么区分触发条件是“什么时候该发计费请求”的规则比如会话建立、会话释放、时间阈值到达、业务变更等计费事件是触发之后实际发出的消息携带具体的用量信息。触发条件是因计费事件是果。标准第 5.1.4 节定义了触发条件的类型第 5.2.2 节描述了各种触发条件下产生的消息流。5. 什么时候该翻这份标准几个真实场景的判断这份中文版标准不是拿来通读的而是拿来查的。它最适用的场景是当你需要确认某个计费行为“标准里到底怎么规定的”时候。场景一排查计费差异。某运营商发现两个厂商设备对同一通电话的计费时长不一致一个记了 62 秒一个记了 58 秒。这时候需要翻到第 5.2.2 节对照会话释放流程确认计费停止的触发点到底应该在哪一步。标准里写得很清楚计费请求的发送时机取决于具体节点和场景差几秒可能是触发条件理解不同导致的。场景二设计新业务计费方案。某实验室要为一个 IMS 新业务设计计费流程需要确定用离线还是在线、在哪些节点埋触发点、ICID 怎么传递。第 4 章的架构和第 5 章的计费原则就是设计依据。标准不会告诉你“该收多少钱”但会告诉你“该怎么记”。场景三对接第三方 AS。当第三方 AS 需要实时提供资费信息RTTI时第 5.2.2.1.17 和 5.2.2.1.18 节描述了消息流和接口要求。如果你不按这个流程走计费系统可能收不到 RTTI 信息导致计费失败。什么时候别用如果你只是想了解“IMS 计费大概是怎么回事”不需要翻标准原文看科普文章就够了。标准是给实现者和测试者用的不是给入门者用的。另外这份标准是 2022 年发布的第 17 版如果你维护的是更早版本的网络需要确认版本差异——不同版本之间消息流和参数可能有变化。注意标准原文明确说明“本文件未经 3GPP 组织合作伙伴的任何批准程序不得实施”它是一份技术规范不是法律文件实施时需要结合具体网络环境和厂商文档。我刚开始接触 IMS 计费时以为把标准通读一遍就能搞懂结果翻到第 5 章就被各种消息流绕晕了。后来才明白这份标准的正确用法是“带着问题查”——先搞清楚自己面对的是离线还是在线、涉及哪些节点、卡在哪个流程然后直接翻到对应章节。从那以后我每次排查计费问题都强制自己先画一张会话流程图标出每个节点的触发点再对照标准确认。希望这个思路能帮到你。本文还有配套的精品资源点击获取
