简介3GPP TS 32.260 IMS计费行标中文版是一份面向IMS计费环节的3GPP标准中文翻译文档适合通信核心网工程师、计费系统研发人员以及需要理解在线/离线计费机制的技术研究者。压缩包内共有1个PDF文件整体大小2.65MB对应规范为V17.3.0版本正文包含前言、范围、参考文献、定义、符号与缩写、高级IMS架构、IMS离线/在线计费架构等章节。文档对CDR计费数据记录、计费触发点、OCS在线计费与离线计费流程、CPRF计费策略规则以及Diameter、Gx等接口协议均有展开说明并覆盖安全隐私、互操作性等落地要点。目前已有195人学习/下载适合作为系统掌握3GPP IMS计费标准的参考材料结合英文原版对照可进一步把握细节。1. TS 32.260 到底管什么IMS 计费行标不是一张表而是一整套「话单长什么样、往哪传、怎么对账」的约定乍一看 3GPP TS 32.260 像是给 IMS 计费定的一个文档编号真正去翻协议的人才发现它管的是整套 IMS 网络里「计费事件怎么产生、怎么打包成 CDR、走 Rf 还是 Ro 接口、传给 OCS 还是 OFCS」的完整链路。做 VoLTE、VoNR、RCS 的计费结算、做 IMS 核心网集成、或者被运营商按着做计费联调的人都需要把这份行标当成主心骨。它解决的是计费厂家和网络设备厂家之间长期扯皮的问题——话单字段各家命名不一样、时间戳粒度不一样、失败呼叫要不要计费——TS 32.260 把这一切定成统一口径照着做不求出彩但能干净过测试。诚实地讲读完这份文档不会直接写出代码但它决定了你的 CDR 生成程序、Rf 接口栈、OCS 在线计费的触发点应该怎么写。这也是这份行标和普通网络协议标准最大的区别它不是「怎么传比特」而是「传什么东西、什么时候传、格式是否合法」。适合谁看做 IMS 核心网与计费系统对接的研发、测试和运维都该通读一遍哪怕你暂时只负责其中一端也必须知道对端拿了你给的数据之后要干什么。2. TS 32.260 的计费模型从 CTF 到 CDR 的整条链路先把离线与在线两条腿分清2.1 两个绕不开的角色CTF 与 DF 的职责切分TS 32.260 沿用了 32.240 里定义的那套计费框架核心角色是 CTFCharging Trigger Function计费触发功能和 DFCharging Data Function计费数据功能。CTF 在 IMS 网元上比如 S-CSCF、P-CSCF、MRFC、AS随手抓一个 SIP 信令节点就是一个计费事件来源它负责监听 SIP 信令的关键节点决定这个事件值不值得触发计费然后在合适的时机把信息合成一个计费请求。DF 则可以是 OFCS离线计费系统或 OCS在线计费系统它拿到请求之后做自己的事OFCS 把数据整理成 CDR 文件落库OCS 则先判断余额、扣费、再决定允许还是切断呼叫。对一线工程而言CTF 和 DF 的分界意味着你要清楚「网元侧该做什么、计费侧该做什么」常见翻车点是让 S-CSCF 做太多事把业务逻辑塞进计费触发里结果一次寻常的注册流程就能产生几十个重复话单把 OFCS 入库链路打爆。2.2 离线计费 Rf 接口与 ACR/ACA 事务什么时候发 START、什么时候发 INTERIM离线计费走 Rf 接口CTF 作为 Diameter 客户端向 OFCS 发 ACRAccounting RequestOFCS 回 ACA。一个完整会话在 TS 32.260 里被切成若干计费事务每个事务有自己独立的 ACR 命令。用抓包或日志观察一次呼叫在 Rf 接口上的典型交互长这样# 典型的 Rf 接口 ACR 命令结构从抓包里还原出来的关键字段 ACR command: Accounting-Record-Type: START_RECORD # 会话开始比如 INVITE 200 OK 之后 Accounting-Record-Number: 1 Event-Timestamp: 20250414103021 # 统一用 UTC本地时区是大坑 Service-Information: IMS-Information: Role-Of-Node: S-CSCF Node-Functionality: S-CSCF User-Name: sip:userexample.com Event-Type: SIP-Method: INVITE这不是一段可执行命令而是从 Rf 接口交互里还原出来的 Diameter AVP 结构。注意 Accounting-Record-Type 有三个主要值START_RECORD 在会话建立后发STOP_RECORD 在会话释放后发INTERIM_RECORD 按运营商设定的间隔周期发通常是 60 秒或 600 秒。INTERIM 的意义在于长呼叫不丢失中间状态——如果用户打了 2 小时电话没有 INTERIM一旦网络中断整张话单直接丢失只有首尾没有过程。参数说明Role-Of-Node 区分布控节点和会话节点S-CSCF 通常填 S-CSCFP-CSCF 填 P-CSCF别混Event-Type 指明是 INVITE、BYE 还是其他方法。排障时先看 Event-Timestamp 是不是 UTC再核对 Accounting-Record-Number 是否连续这两个字段错了后面 OFCS 入库再快也是白搭。2.3 在线计费 Ro 接口与 CCR/CCACredits 怎么扣先预留还是先扣死在线计费走 Ro 接口CTF 发 CCRCredit Control Request给 OCSOCS 回 CCA。TS 32.260 的核心玩法是「配额预留」不是一次扣完。CCR 里带 Requested-Service-UnitOCS 根据费率算出可用时长回 Granted-Service-UnitCTF 在这个额度内放行呼叫快到额度了再发 CCR 续请求。# Ro 接口 CCR 中的关键 AVP 示意OCS 侧接收后的日志结构 CCR command: CC-Request-Type: UPDATE_REQUEST # 初始是 INITIAL_REQUEST续配额是 UPDATE_REQUEST CC-Request-Number: 3 Requested-Service-Unit: CC-Time: 300 # 请求 300 秒的配额 Service-Information: IMS-Information: Access-Network-Charging-Identifier-Group: Access-Network-Charging-Identifier: 0AF00321业界现在讨论「AI 的计费单位 Credits 是什么」时思路其实和这里同源都是先定义一个可计费资源维度——时间、流量、事件次数——再在这个维度上做配额管理。TS 32.260 把 credits 拆成 CC-Time、CC-Total-Octets、CC-Service-Specific-Units 三类你只需要决定按哪个维度卖。语音按 CC-Time 卖视频按 CC-Time文件传输按 CC-Total-Octets按次业务就用 CC-Service-Specific-Units。注意 CC-Request-Type 与 Rf 的 Accounting-Record-Type 不同在线计费没有 STOP 概念终止会话是用 TERMINATION_REQUEST且必须在收到 CCA 确认后才关断媒体面。否则用户已经挂断余额却还没结算下一次呼叫会被连带扣错——这属于最典型的「计费与信令节奏没对齐」事故。2.4 为什么要同时维护 Rf 和 Ro同一个 P-CSCF 可以一鱼两吃实际网络里经常同时开 Rf 和 Ro比如 VoLTE 用户的后付费与预付费混跑。P-CSCF 需要对后付费用户走 Rf 出话单对预付费用户走 Ro 找 OCS 要配额——按用户维度动态选择计费通道。这种「一鱼两吃」的架构在 TS 32.260 里是靠 IMS-Information 里的 User-Name 和 Subscription-Id 区分CTF 拿到用户身份后先查本地签约数据决策用哪个接口。但别指望一份配置走天下VoLTE 漫游用户的归属地 OCS 与拜访地 OCS 的地址不同触发点也受 TS 32.260 的漫游章节约束。一般做法是 CTF 维护一张用户路由表按 IMSI 段区分本地、国内漫游、国际漫游指向不同的 OCS 地址。这张表的更新频率很讲究——每 5 分钟全量重读一次用户量上去之后对数据库压力不小建议做增量热加载不重启网元只在表版本号变化时拉取增量段。3. 把协议落成 CDR字段映射、文件生成与计费参数的工程化选择3.1 从 ACR 到 CDR 字段哪些字段由网元填哪些由 OFCS 补TS 32.260 不只是规定接口命令它直接定义了 CDR 字段的名字、类型和取值语义。OFCS 收到 ACR 后把 AVP 映射到 CDR 记录落地为二进制话单或文本话单。业界最常见的做法是转为 ASN.1 PER 编码后写文件也有不少运营商为了便于解析改成 JSON 话单——后者虽然不完全符合 TS 32.260 附录里的默认编码但只要保持字段名一致联调时多数设备商认。工程上最怕的不是编码格式而是字段名和类型各写各的对账脚本根本没法写。以下是常用字段映射关系表这个表是我做联调时从协议和实际日志里对出来的可以直接当对照清单用TS 32.260 字段ACR/AVP 来源说明常见错填recordTypeAccounting-Record-TypeSTART/INTERIM/STOP把 INTERIM 漏掉sIPMethodIMS-Information.Event-Type.SIP-MethodINVITE/BYE/SUBSCRIBE只填 INVITE 不填 BYEcallingPartyNumberSubscription-Id主叫号码带 CC 前缀忘记去前缀导致前缀比对失败origIOIIMS-Information.Originating-IOI源运营商域漫游时填错为归属域localRecordSequenceNumber网元自增计数器用于对账、去重重启后不通知 OFCS 导致重复参数要点sIPMethod 不是只记 INVITE 和 BYE。TS 32.260 对 SUBSCRIBE、NOTIFY、MESSAGE、REGISTER 也定义了计费事件很多网元默认只开会话类计费短消息计费对应热词里那个「练 28.3 短信计费」的场景需要单独把 MESSAGE 事件头打开否则短信全部白打用户投诉起来查无实据。3.2 CDR 文件生成与汇聚单个 CDR 成型后还要按话单文件聚合上报CDR 记录本身只是话单的「一行数据」工程上还需要把若干 CDR 打包成话单文件定时推送到计费中心的文件服务器。常见的聚合维度有按网元维度、按时间窗口5 分钟、15 分钟、1 小时、按用户归属地。TS 32.260 不强求文件格式只在附录里建议了命名规则所以工程上只要保证一个文件里的记录属于同一时间窗口、同一网元就能减少对账脚本的复杂度。# 伪代码按会话把多段 ACR 合并成一个 CDR 对象再批量写文件 def build_cdr(acr_list): cdr {} for acr in acr_list: if acr[type] START: cdr[start_time] acr[event_timestamp] cdr[session_id] acr[ims_charging_identifier] elif acr[type] INTERIM: cdr.setdefault(interim_list, []).append(acr[event_timestamp]) elif acr[type] STOP: cdr[stop_time] acr[event_timestamp] cdr[sip_method] acr[sip_method] cdr[duration] cdr[stop_time] - cdr[start_time] return cdr逻辑说明这段代码解决的是「同一个会话拆成了多条 ACR怎么合到一张 CDR」的问题。关键点是 start_time 和 stop_time 必须来自同一会话标识——这里用的是 IMS Charging IdentifierICID。ICID 在 INVITE 的 P-Charging-Vector 里传递跨网元时保持一致如果丢掉多网元话单就合并不起来只能靠号码和时间近似匹配那种匹配在账单系统里永远不可靠。参数说明duration的计算最好在 CDR 生成阶段做而不是只靠 OFCS 统计因为 OFCS 侧可能拿不到可靠的 UTC 时间戳另外如果 start_time 缺失是否允许只凭 stop_time 生成时长为零的记录要在配置里用开关控制避免对账时被那边当作脏数据打回整个文件。3.3 计费参数怎么设事件触发点、配额窗口与重传超时TS 32.260 留了很多「厂商可配置」的口子工程调优的重点在下面三个场景。第一个是事件触发点。S-CSCF 上收到初始 INVITE、中间 180 Ringing、最终 200 OK是否都上报计费事件一般做法是只在收到最终响应后上报 START避免把未接通呼叫也计进时长。但有一种例外业务侧要求「呼叫接通前就扣预订费」这时要在 183 Session Progress 触发一个初始配额请求。触发点配多了话务量翻倍配少了预付费用户欠费风险升高。这个开关一般由计费产品经理拍板工程师要做的只是把影响面量化给业务方——比如统计每路呼叫平均产生几个 Diameter 消息再乘预期话务量让决策建立在数字上。第二个是配额窗口。Ro 接口的 Granted-Service-Unit 是 5 秒还是 600 秒直接决定 OCS 的并发压力与粒度。短窗口扣费精准但信令风暴高常见做法是语音按 60 秒、数据按 1MB 或 10MB 一个窗口具体数值与 OCS 的 TPS 能力相关。实测经验是 5 秒窗口在 10 万并发用户下能把 OCS 的 Diameter 线程池打到 90% 占用至少要扩一倍线程数才能稳住所以不建议一上来就追求极致粒度。第三个是重传超时。Diameter 层有 Tx 重传计时器TS 32.260 引用 RFC 6733 的 T 值但计费业务有自己的痛点——ACA/CCA 丢了可以重传重传后 OFCS/OCS 端必须能按 Accounting-Record-Number 或 CC-Request-Number 去重否则一张呼叫可能生成两笔扣费。去重键建议同时记录网元 ID 和序号单靠序号在 S-CSCF 主备切换后会错乱——主备切换后从 1 重新计数OFCS 端如果只按序号去重会把新话单误判成重复话单。3.4 与 IMS 注册链路的关系REGISTER 事件进不进话单是个业务决定热词里有一批搜「Pixel IMS 注册不了」「VoS IMS 注册」的这些是终端侧问题但站在 TS 32.260 角度REGISTER 事件本身也是计费候选。如果一个用户反复注册失败——比如 SIP 401 循环——网元每收到一次 REGISTER 就触发计费事件CDR 里会积攒出大量零话务话单。此时应配置成「仅注册成功且携带有效计费标识才生成 CDR」。个别运营商把「注册尝试」也计入按事件计费的套餐中防刷这是业务选择但默认建议是关掉省得对账时被那堆 401 话单淹没。另外REGISTER 事件话单里通常没有 duration只有 timestamp 和 user-identifier所以走离线计费时会被聚合得很碎文件数量暴涨给文件传输链路带来额外压力。工程上如果确实要开建议独立文件存放别和呼叫话单混在一个文件里。4. 避坑指南IMS 计费联调里最常遇到的 5 个坑每个都有迹可循4.1 时间戳时区不一致一个本地时间、一个 UTC话单错位到对不上现象CDR 上的开始时间比实际呼叫时间差了 8 小时日对账时白班话单对到夜班两边互不认账。原因CTF 网元发 ACR 时 Event-Timestamp 用本地时区OFCS 侧按 UTC 解析时区没有全局统一。TS 32.260 明确要求用 UTC但很多网元的默认日志用本地时间联调环境里又没人注意上线后一锅粥。解决在 CTF 和 OFCS 两侧都把时区钉死为 UTC网元侧通过配置项强制时区为 UTC同时在 CDR 文件头写上 timezone-offset 字段。验收测试里加一条「跨 UTC 边界 00:00 发起呼叫」的用例验证日切是否错位。别以为容器化部署就自动是 UTC很多基础镜像默认 UTC 但网元应用又读宿主机时区双保险做法是应用启动脚本里显式 export TZUTC。4.2 缺少 INTERIM 话单导致长呼叫时长对不上现象一个 2 小时呼叫CDR 只记了 3 分钟用户投诉费用不对。原因会话进行中网元与 OFCS 之间的链路抖动中间所有的 INTERIM_RECORD 都没送到只有 START 和 STOP 到达。离线计费的特点是不实时扣费链路闪断后不重传OFCS 只能看到首尾时间2 小时被算成 3 分钟——因为只按 STOP 减 START 算时长中间过程全丢。解决CTF 侧配置 INTERIM 上报间隔为 60 秒并且开启链路恢复后的补包重传——Rf 接口支持将缓存队列中的 ACR 按原序号续传。同时 OFCS 侧对「只有 START/STOP 且时长异常大」的记录做异常标记人工复核而不是直接计费。注意补包重传会占用 Rf 链路带宽要把队列深度配上上限防止一次闪断后积压几万条 ACR恢复瞬间把链路冲垮。4.3 ICID 跨网元不一致话单合并不起来现象S-CSCF 和 P-CSCF 各自出了一张 CDR但账务系统怎么 join 都对不上同一次通话。原因P-Charging-Vector 里的 ICID 在跨网元传递时被某个 AS 改写了或者网元在接口适配时把头部里的 ICID 截断了。TS 32.260 里 ICID 是会话绑定键一旦改掉全链路话单变成孤岛对账时只能靠主被叫号码和时间模糊匹配。解决在 S-CSCF 出口侧抓 SIP 信令按 Call-ID 过滤比对 INVITE 和后续消息里 P-Charging-Vector 中的 ICID 值是否一直未改动。如果被 AS 改写联系 AS 厂家把透明传递打开。有的 AS 为了做计费中继会主动重生成 ICID此时只能用会话内另一个标识如 Call-ID做关联但要先在协议对接文档里明确避免后期扯皮。4.4 配额耗尽后释放迟延预付费用户多打了 30 秒现象用户余额耗尽OCS 回 Quota-Exhausted但媒体面没有立刻断开多打了半分钟。原因CTF 没有把「配额耗尽」映射成媒体面中断指令或者 P-CSCF 的 BYE 下发依赖 SIP 会话定时器中间存在空闲定时器周期大于配额剩余时间的情况。TS 32.260 文档里 Final-Unit-Indication 就是干这个的但很多实现只在 OCS 侧发了指示CTF 侧没有对应的释放回调。解决在 P-CSCF 上把会话释放条件直接绑定 Ro 接口 CCA 里的 Final-Unit-Indication收到 final 后立即走媒体面资源释放不等待会话定时器超时。同时把 Ro 的配额窗口调到 30 秒以内让终端体验到的最长透支时间可控。如果 P-CSCF 版本不支持这个回调只能升级或打补丁没有绕过去的配置能解决。4.5 Diameter 重传导致重复扣费同一张 CDR 出现在两批话单里现象OCS 侧查到同一通话扣了两次费话单文件里也出现两条完全相同的 CDR。原因ACR/CCR 在网络抖动时重传OFCS/OCS 端没有做幂等去重。特别是 OFCS 多节点负载均衡时重传的请求被路由到另一个 OFCS 实例实例间没有共享去重缓存每个实例都当新话单入账。解决将去重键设计为「来源网元 ID Accounting-Record-Number / CC-Request-Number」的组合写入 OFCS 共享缓存或数据库唯一索引。处理重复 ACR 时第一次正常入库后续命中唯一索引直接返回成功且不落库。这个逻辑必须在文档层面与计费中心约死——不是 OFCS 自己可见即可要保证 OCS 在线扣费侧也走同一套键。另注意 S-CSCF 主备切换后序号可能重置单独用序号去重会把新话单误删所以必须带上网元 ID 和切换事件标识。5. 验证方法用最小 IMS 计费环境试跑 TS 32.260 的联调用例5.1 用轻量方式搭出可验证的 Rf/Ro 计费闭环没有整套运营商级 IMS 核心网也可以用协议栈模拟器验证大部分 TS 32.260 关键行为。做法是搭一个最小 Diameter 服务端模拟 OFCS/OCS再让网元真实上报 ACR/CCR看字段、序列号、重传逻辑是否与标准对齐。这样能在真实网元进场前先把计费侧的口径定下来。# 以搭建最小 Diameter 服务端监听 3868 端口为例 docker run -d --name diameter-ofcs -p 3868:3868 \ -v $(pwd)/ofcs-config.xml:/etc/diameter/ofcs-config.xml \ diameter-ofcs-simulator:latest逻辑说明这段命令把 Diameter 服务仿真器跑在容器里监听 3868 端口等待网元投递 ACR。对于验证 TS 32.260 的联调它不验证 OFCS 的存储但能验证网元侧的触发点、重传行为、字段内容是否合法。配合 wireshark 的 diameter 解析插件可以直接抓包核对 AVP。参数说明ofcs-config.xml里要配置 Origin-Host、Origin-Realm、支持的 Accounting-Record-Type 列表。实际联调里最常见的无效配置是 Origin-Realm 与网元侧配置不一致导致 Diameter Capabilities Exchange 被拒绝连不上就谈不上计费了。不管你拉多少组件先保证 Origin-Host 和 Origin-Realm 两边的值精确匹配这是 Diameter 建链的第一道门槛。5.2 必跑的 6 条联调用例从正常呼叫到配额耗尽联调用例不需要一百条TS 32.260 对应的核心场景跑通六条就够支撑大部分验收用例预期行为验证点正常接通后挂断START STOP 两条 ACR 成对Accounting-Record-Number 连续60 秒长呼叫START INTERIM STOPINTERIM 间隔在配置值内预付费配额耗尽CCA 带 Final-Unit-Indication呼叫被释放释放延迟小于 2 秒主叫无应答只有 START 无 STOP 或单独的特殊话单事件触发点配置符合约定短消息发送MESSAGE 事件单独出 CDR短消息话单格式正确跨时区日切UTC 00:00 前后的呼叫落到正确日期日切归属准确这六条用例覆盖了第 4 章里的 5 个坑位。联调时建议把配额耗尽用例放在第四位跑——它最容易让 P-CSCF 暴露出媒体面释放不及时的问题修起来要动网元侧流程留足修改时间。其他几条基本都是配置问题现场改配置就能过。5.3 一劳永逸的小技巧把话单对账脚本做成接口对拍最后给一个实战里很救命的习惯把对账脚本做成接口对拍而不是事后查数据库。网元侧上传 CDR 文件后立即由一个校验脚本拉取 OFCS 侧同一文件的记录数、总时长、总金额比对两边哈希。哈希不一致就自动告警并标记文件要求人工核查。这个自动化能挡住 5 个坑里至少 3 个因为它把「对账发现问题」的时间从 T1 日缩短到 T0 小时。我自己经历过最痛的一次是上线后第二周才被账单系统发现 ICID 被 AS 改写结果要回溯五天的话单去修关联关系那种感觉就是「计费联调的黑匣子终于打开了但里面已经烂了」。从那以后我再也不信任何「这个 AS 不会改 P-Charging-Vector」的口头承诺一律用对拍脚本当场验证。这个方向值得投入——IMS 计费行标设计得再完善最终仍要用工程手段守住每一张 CDR 的准确性希望这份实战路径能帮你在联调路上少踩几个坑。本文还有配套的精品资源点击获取