IMS计费规范TS 32.260实战：ICID关联、Rf/Ro接口与CDR对账避坑指南

简介本资源为3GPP TS 32.260 IMS计费技术规范的中文版文档面向从事移动通信核心网计费系统研发、测试与运维的工程师以及需要理解IMS计费机制的通信专业学生与研究人员。该规范聚焦IP多媒体子系统IMS的计费管理覆盖GSM、UMTS、LTE等多代移动通信技术下的计费场景是理解现代移动网络计费体系的核心参考资料。资源包内共1个PDF文件大小约2.65MB内容完整涵盖前言、范围、参考文献、定义符号与缩写、架构注意事项等章节并深入展开高级IMS架构、离线计费架构、在线计费架构及融合计费架构等关键模块。读者可从中系统掌握计费数据记录CDR、计费触发点、在线与离线计费系统、计费策略与规则功能CPRF以及Diameter、Gx等接口协议的核心知识对保障运营商计费准确性与互操作性具有重要参考价值。目前已有195人学习下载建议结合英文原版对照研读以全面把握技术细节。1. 从一条话单说起IMS 计费为什么绕不开 TS 32.260你大概率是在排查一张 IMS 话单对不上账的时候才第一次听说 3GPP TS 32.260 这个名字。VoLTE 通话结束PGW-C 和 S-CSCF 各自吐出一条 CDR运营商侧账单却差了那么几秒、几 KB或者干脆少了一条记录。翻规范才发现问题不在设备厂商实现而在 IMS 计费架构本身——谁生成、谁传递、谁合并、谁最终出单这套规则全写在 TS 32.260 里。这份规范全称是 IMS charging属于 3GPP TS 32 系列计费规范族的一员和 TS 32.250电路域计费、TS 32.251分组域计费、TS 32.240计费架构总纲是兄弟关系。它定义的是 IMS 域内各个网元S-CSCF、P-CSCF、I-CSCF、MRFC、MGCF、AS 等如何生成计费信息、如何通过 Rf 接口送往 CDF、离线计费与在线计费Ro 接口分别怎么走、多网元场景下如何做 CDR 关联。中文版行标的意义在于英文原版里那些 charging correlation、ICID、Access-Network-Charging-Identifier 的措辞在工程落地时经常被理解偏。中文版把术语锚定下来做需求评审、写测试用例、和核心网厂商对齐接口时少一层翻译损耗。适合谁读IMS 核心网运维、计费系统开发、话单稽核、以及做 VoLTE/VoNR 测试的工程师。如果你只关心通话能不能通这份规范可以先放一放一旦涉及通话怎么算钱它就是绕不过去的底座。2. TS 32.260 的计费架构ICID 是怎么把多个网元串成一条链的IMS 计费最核心的难点不是单个网元怎么出话单而是一次会话经过五六个网元怎么保证这些话单能被拼回同一次通话。TS 32.260 给出的答案是 ICIDIMS Charging IdentifierIMS 计费标识加 Access-Network-Charging-Identifier 的组合。理解这套机制后面看任何字段都不会迷路。2.1 离线计费与在线计费的边界在哪离线计费走 Rf 接口网元把计费事件通过 ACRAccounting Request发给 CDFCharging Data FunctionCDF 落成 CDR再由 CGFCharging Gateway Function做格式转换和合并最终送到 BDBilling Domain。整个过程是先服务、后出单用户通话时并不感知。在线计费走 Ro 接口网元在会话建立前就要向 OCSOnline Charging System申请配额OCS 返回 Granted-Service-Unit网元用完再申请余额不足直接拒绝会话。VoLTE 预付费用户走的就是这条路。两者的分界点在网元配置S-CSCF 上如果同时配了 Rf 和 Ro 地址通常按用户签约类型决定走哪条。工程上最容易翻车的是同一用户两条链路都触发导致重复计费。规范里明确要求网元根据用户 Profile 二选一但厂商实现里这个判断逻辑经常有 bug。2.2 ICID 的生成规则与传递路径ICID 是一个全局唯一的字符串由会话发起侧的第一个 IMS 网元生成。以 VoLTE 主叫为例P-CSCF 收到 SIP INVITE 后生成 ICID写入 P-Charging-Vector 头域后续所有网元从 SIP 消息里读取这个头域把 ICID 抄进自己的 CDR。P-Charging-Vector: icid-valueabc123def456; icid-generated-atp-cscf.example.com这条头域是整条计费链的身份证。S-CSCF、MRFC、MGCF 出的 CDR 里都会带同一个 icid-value后处理系统靠它做关联。如果某个网元没透传这个头域它的话单就成了孤儿单对账时永远拼不上。注意ICID 的格式在 TS 32.260 里没有强制规定具体编码只要求全局唯一。实际部署中常见的是主机名时间戳随机数的拼接长度控制在 64 字符以内避免某些老设备截断。2.3 多网元 CDR 关联的字段对照不同网元出的 CDR 字段名不一样但有几个关键字段是关联的锚点。下面这张表是我在实际对账时整理的对照关系字段名以规范定义为准厂商实现可能有细微差异。关联锚点P-CSCF CDRS-CSCF CDRMRFC CDRMGCF CDR会话标识ICIDICIDICIDICID主叫标识Calling-Party-AddressCalling-Party-Address—Calling-Party-Address被叫标识Called-Party-AddressCalled-Party-Address—Called-Party-Address接入网计费标识Access-Network-Charging-Identifier透传——时间戳Event-TimestampEvent-TimestampEvent-TimestampEvent-Timestamp节点地址P-CSCF-AddressS-CSCF-AddressMRFC-AddressMGCF-Address关联逻辑是先按 ICID 分组组内再按时间戳排序用 Calling/Called-Party-Address 做二次校验。如果 ICID 缺失退而求其次用主被叫时间窗口做模糊匹配但误关联率会明显上升。2.4 一次 VoLTE 通话的计费消息流把上面的概念串起来一次标准 VoLTE 通话的离线计费流程大致是这样主叫 UE 发 INVITEP-CSCF 生成 ICID写入 P-Charging-Vector同时向 CDF 发 ACR START。INVITE 转发到 S-CSCFS-CSCF 读取 ICID向 CDF 发自己的 ACR START。如果涉及 MRF 放音或会议MRFC 也生成带同一 ICID 的 ACR。通话结束各网元依次发 ACR STOPCDF 收齐后合并成一条完整 CDR。CGF 做 CDR 去重和格式转换送 BD 出单。这里的关键是ACR START 和 ACR STOP 必须成对。如果网元异常重启只发了 START 没发 STOPCDF 会挂一条未关闭的记录通常靠超时机制兜底但超时时间设多长是个权衡——太短会误关正常长通话太长会让异常单堆积。3. 中文版行标怎么用从术语对照到接口字段落地拿到中文版 TS 32.260 之后很多人第一反应是逐字读一遍结果读到第三章就放弃了。这份规范的正确用法是当字典查而不是当教材读。下面说几个我实际工作中高频使用的场景。3.1 术语对照英文原版和中文版的锚点中文版最大的价值是把关键术语固定下来。做需求文档、接口规范、测试用例时团队内部必须用同一套词否则计费标识和计费 ID混用评审时就要吵架。下面是我整理的常用术语对照以中文版行标为准。英文术语中文行标译法工程口语IMS Charging IdentifierIMS 计费标识ICIDCharging Data Function计费数据功能CDFCharging Gateway Function计费网关功能CGFAccounting Request计费请求ACRAccess-Network-Charging-Identifier接入网计费标识ANC-IDInter-Operator Tariff运营商间费率IOTGranted-Service-Unit授权服务单元GSU提示中文版行标里有些译法比较生硬比如计费数据功能读起来像在说一个功能模块实际指的是一个网元实体。团队内部沟通时建议中文术语用于正式文档口语继续用英文缩写避免歧义。3.2 Rf 接口 ACR 消息的字段拆解Rf 接口基于 Diameter 协议ACR 消息里承载的计费信息以 AVPsAttribute-Value Pairs形式组织。TS 32.260 定义了 IMS 特有的 AVPs下面挑几个最容易出问题的说。# 用 tshark 抓 Rf 接口 Diameter 消息的典型命令 tshark -i eth0 -f tcp port 3868 -Y diameter.cmd.code 271 \ -T fields -e diameter.Session-Id -e diameter.Origin-Host \ -e diameter.IMS-Charging-Identifier -e diameter.Access-Network-Charging-Identifier这条命令抓的是 ACRCommand Code 271输出 Session-Id、源主机、ICID 和 ANC-ID。排查计费问题时第一步就是确认这几个字段有没有值、值对不对。Session-IdDiameter 会话标识和 ICID 不是一回事。Session-Id 标识的是 Rf 接口上的一次 Diameter 会话ICID 标识的是 IMS 层的一次业务会话。一个 ICID 可能对应多个 Session-Id比如中间 CDF 切换。IMS-Charging-Identifier就是 ICID必须和 SIP 头域里的 icid-value 一致。不一致说明网元透传逻辑有问题。Access-Network-Charging-Identifier接入网侧比如 eNodeB/gNodeB生成的计费标识用于和无线侧话单关联。这个字段在 P-CSCF 的 ACR 里有S-CSCF 通常只透传。3.3 在线计费 Ro 接口的 CCR 交互在线计费走 Ro 接口消息是 CCRCredit-Control-Request和 CCACredit-Control-Answer。和 Rf 的事后上报不同Ro 是事前申请、事中续订、事后终结。# 抓 Ro 接口 CCR 消息看请求的配额和使用的配额 tshark -i eth0 -f tcp port 3868 -Y diameter.cmd.code 272 \ -T fields -e diameter.Session-Id -e diameter.CC-Request-Type \ -e diameter.Requested-Service-Unit -e diameter.Used-Service-UnitCC-Request-Type 有四个值INITIAL_REQUEST1、UPDATE_REQUEST2、TERMINATION_REQUEST3、EVENT_REQUEST4。VoLTE 语音通话典型流程是 INITIAL 申请配额通话中按周期发 UPDATE 续订挂机发 TERMINATION 终结。参数上最容易踩的坑是配额单位和配额大小。Requested-Service-Unit 里可以按时间CC-Time或流量CC-Total-Octets申请VoLTE 语音一般按时间。如果 OCS 返回的 GSU 是 60 秒网元必须在 60 秒用完前发 UPDATE否则 OCS 侧会认为配额超用触发异常告警。3.4 用中文版行标写测试用例的三个切入点测试用例不是把规范抄一遍而是把规范里的必须和应该转成可验证的步骤。我一般从三个切入点下手第一字段完整性。规范里标了 Mandatory 的 AVP测试时逐条检查有没有值。比如 IMS-Charging-Identifier 在 ACR 里是必选缺了就是不合格。第二关联一致性。同一个 ICID 在 P-CSCF、S-CSCF、MRFC 的 CDR 里必须一致测试时构造一次跨网元通话抓三份话单做比对。第三异常场景。规范里对异常处理有描述比如 CDF 不可达时网元应该缓存还是丢弃。测试时模拟 CDF 断连看网元行为是否符合规范要求。4. 避坑与排查IMS 计费对账时最常见的 5 个翻车现场这一章是我这些年踩过的坑里挑出来的每条都按现象→原因→解决写。有些坑看起来是设备问题根子其实在规范理解偏差。4.1 话单缺失ICID 在某个网元断了现象一次 VoLTE 通话P-CSCF 和 S-CSCF 都有话单MRFC 的话单找不到对账时这次通话的时长少了一段。原因MRFC 从 SIP 消息里读 P-Charging-Vector 头域失败。常见情况是 S-CSCF 转发 INVITE 到 MRFC 时头域被某个中间设备改写或剥离。也有厂商实现里 MRFC 只在特定呼叫流程比如会议才读 ICID普通放音场景直接生成新 ICID。解决先在 S-CSCF 出向抓包确认 P-Charging-Vector 有没有透传。如果透传了但 MRFC 没读查 MRFC 配置里 ICID 提取开关。如果 MRFC 生成了新 ICID那是实现 bug需要厂商补丁。临时方案是在后处理系统里用主被叫时间窗口做模糊关联但要把误关联率监控起来。4.2 重复计费Rf 和 Ro 同时触发现象预付费用户通话后余额扣了两次一次来自 OCS 的在线计费一次来自 CDF 的离线话单。原因S-CSCF 上同时配置了 Rf 和 Ro 地址但用户 Profile 判断逻辑有缺陷导致两条链路都走了。规范要求网元根据用户签约的计费类型二选一但有些实现里判断条件写成了只要配了就发。解决检查 S-CSCF 的计费配置确认 Rf 和 Ro 的触发条件互斥。如果配置没问题抓 Diameter 信令看两条链路的 ACR 和 CCR 是不是都发了。确认是设备 bug 后短期可以在 CDF 侧加去重规则按 ICID时间戳长期要厂商修判断逻辑。4.3 时间戳对不上网元间时钟不同步现象同一次通话P-CSCF 话单的开始时间比 S-CSCF 早 3 秒合并后通话时长算出来偏大。原因各网元没有统一 NTP 源或者 NTP 同步精度不够。IMS 计费对时间戳的依赖很强CDR 合并、时长计算、跨网元关联都靠它。解决所有 IMS 网元必须配置同一组 NTP 服务器同步精度控制在毫秒级。如果已经出现时间偏差先查 NTP 服务状态再看网元有没有配置时区偏移。有些设备默认用本地时间而不是 UTC跨时区部署时会出大问题。4.4 ACR STOP 丢失异常重启后的孤儿单现象CDF 里堆积了一批未关闭的 ACR 记录对应的通话早就结束了。原因网元在通话过程中异常重启只发了 ACR START 没发 ACR STOP。CDF 靠超时机制兜底但超时时间如果设得太长比如 24 小时这些孤儿单会一直挂着。解决CDF 侧的超时时间建议设在 1 到 4 小时之间根据业务最长通话时长调整。同时网元侧要开启计费缓存重启后能把未发送的 ACR 补发。如果孤儿单已经产生后处理时按 ICID 找对应的 START 记录人工补一个 STOP 或者标记为异常单。4.5 字段截断ICID 超长被老设备砍掉现象某些老型号网元出的 CDR 里ICID 只有前半段和别的网元对不上。原因ICID 生成时没有控制长度超过了某些设备字段的最大长度限制。TS 32.260 没有强制规定 ICID 长度但工程实践里一般控制在 64 字符以内。解决检查 ICID 生成规则确保长度不超过 64 字符。如果已经部署的设备有截断问题要么改生成规则要么在后处理系统里做前缀匹配。后者是权宜之计会引入误关联风险。5. 进阶用脚本做 CDR 关联校验和计费一致性验证规范读到最后落脚点一定是怎么验证实现是对的。手工对账只能抽查真正靠谱的做法是写脚本做批量校验。这一章给一个可复现的思路和代码骨架。5.1 从 CDR 文件到关联结果的最小脚本假设你手上有三份 CDR 文件分别来自 P-CSCF、S-CSCF、MRFC格式是 CSV每行一条记录关键列是 icid、calling、called、start_time、end_time、node。下面这个脚本做三件事按 ICID 分组、检查组内记录数、输出缺失网元的 ICID。import csv from collections import defaultdict # 三份 CDR 文件路径实际使用时替换 cdr_files { p-cscf: p-cscf_cdr.csv, s-cscf: s-cscf_cdr.csv, mrf: mrf_cdr.csv } # 按 ICID 聚合记录每个网元是否出现 icid_map defaultdict(set) icid_detail defaultdict(list) for node, path in cdr_files.items(): with open(path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: icid row.get(icid, ).strip() if not icid: continue # 跳过无 ICID 的孤儿单 icid_map[icid].add(node) icid_detail[icid].append({ node: node, calling: row.get(calling, ), called: row.get(called, ), start: row.get(start_time, ), end: row.get(end_time, ) }) # 输出关联结果 expected_nodes {p-cscf, s-cscf} for icid, nodes in icid_map.items(): missing expected_nodes - nodes if missing: print(fICID {icid} 缺失网元: {missing}) for rec in icid_detail[icid]: print(f {rec[node]}: {rec[calling]} - {rec[called]} f[{rec[start]} ~ {rec[end]}])这段代码的逻辑很直白把三份 CDR 读进内存按 ICID 建索引然后检查每个 ICID 是否覆盖了预期网元。expected_nodes根据实际组网调整比如有些场景 MRF 不参与就不放进预期集合。参数上要注意两点一是icid列名要和实际 CDR 表头一致不同厂商导出的字段名可能不同二是时间格式脚本里只做字符串比对如果要算时长差需要先解析成 datetime。5.2 关联校验的三个验证维度脚本跑通只是第一步真正要验证的是三个维度完整性每个 ICID 是否覆盖了所有应该出话单的网元。缺失的 ICID 要分类是网元没出单还是出了但 ICID 不一致。一致性同一个 ICID 在不同网元的话单里主被叫号码、通话起止时间是否一致。时间差超过阈值比如 2 秒的要标出来查时钟同步。合理性通话时长是否为正、是否超过业务上限、同一用户短时间内是否有大量重复 ICID。这些异常往往指向设备故障或信令风暴。5.3 把校验脚本接进日常巡检脚本写完不要只跑一次要接进日常巡检。我的做法是每天凌晨跑一次前一天的 CDR输出三个指标ICID 覆盖率、时间戳偏差分布、孤儿单数量。这三个指标连续几天异常基本就能定位到具体网元。指标正常范围异常指向ICID 覆盖率 99.5%网元透传逻辑或生成规则问题时间戳偏差 500msNTP 同步或时区配置问题孤儿单比例 0.1%网元异常重启或 ACR STOP 丢失这套方法不复杂但坚持做下来计费对账从月底救火变成日常可控。我自己最大的教训是早期觉得脚本麻烦靠人工抽查结果一次版本升级引入的 ICID 截断问题拖了两个月才发现补数据补到怀疑人生。后来把校验脚本当成必选项每次网元升级后先跑一遍心里才有底。希望帮到你。本文还有配套的精品资源点击获取