简介：本资源为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 计费最巧妙的设计之一，是引入了一组标识符来串联一次会话中的所有计费事件。其中最关键的是ICID（IMS Charging Identifier），你可以把它理解成快递单号：一个会话从建立到释放，无论经过多少个网络节点、产生多少条 CDR，都带着同一个 ICID。这样后台对账时，就能把散落在各处的记录拼成完整的一单。
标准第 5.1.2 节详细规定了 ICID 的生成规则、传递方式和关联机制。还有接入网计费标识、运营商间标识符等辅助标签，分别解决“从哪个网接进来的”“跨运营商怎么分账”的问题。这些标识符是计费准确性的基石，少了任何一个，都可能出现“有记录但拼不出完整会话”的翻车现场。
3. 拆开看架构：IMS 计费系统里都有谁在干活
3.1 核心角色与分工
IMS 计费架构不是单一设备，而是一组功能实体的协作。标准第 4 章给出了高层架构，主要角色包括：
- CDF（Charging Data Function）：负责收集网络节点发来的计费事件，生成 CDR。可以理解为“记账员”。
- CGF（Charging Gateway Function）：负责 CDR 的格式转换、合并和分发，把账本交给后台系统。可以理解为“账本管理员”。
- OCS（Online Charging System）：在线计费的核心，实时处理扣费请求、控制配额。可以理解为“收银员”。
- CTF（Charging 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 章就被各种消息流绕晕了。后来才明白，这份标准的正确用法是“带着问题查”——先搞清楚自己面对的是离线还是在线、涉及哪些节点、卡在哪个流程，然后直接翻到对应章节。从那以后，我每次排查计费问题，都强制自己先画一张会话流程图，标出每个节点的触发点，再对照标准确认。希望这个思路能帮到你。
本文还有配套的精品资源，点击获取
