拓冰网站定制 
简介本资源为3GPP TS 32.260《电信管理—计费管理—IP多媒体子系统IMS计费》第17版的中文版技术规范面向从事IMS计费系统研发、测试与运维的通信工程师及标准研究者帮助读者跨越英文原文门槛准确理解IMS在线计费、离线计费与融合计费的核心机制。压缩包内仅含1个PDF文件约2.65MB内容涵盖前言、范围、参考文献、定义符号与缩写、架构注意事项、计费原理等章节并系统梳理了计费数据记录CDR、计费触发点、在线计费系统OCS、离线计费系统OFS、计费策略与规则功能CPRF以及Diameter、Gx等接口协议等关键知识点。目前已有195人学习下载适合作为IMS计费方案设计、接口对接与问题排查的案头参考建议结合英文原版对照研读以全面掌握技术细节。1. 3GPP TS 32.260 IMS计费行标中文版从协议到落地的关键拼图做IMS计费对接的工程师大概率都经历过这种场景话单对不上、CDR字段缺失、离线计费与在线计费切换时信令流程卡死抓包一看问题出在某个Diameter AVP的取值和规范理解有偏差。这时候翻出3GPP TS 32.260的英文原版几百页的协议文档光术语定义就能劝退一半人。而市面上流传的所谓“中文版”要么是机器翻译的残卷要么是某个版本的部分章节摘录真正能拿来对照代码和抓包做逐字段核对的完整行标中文版极其稀缺。TS 32.260全称是“Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging”它定义了IMS域内离线计费、在线计费和计费数据采集的完整框架包括Rf、Ro接口的Diameter消息结构、CDR的字段语义、计费触发条件、部分CDR的生成规则等。没有这份规范的中文对照你在对接BOSS系统、调试CDF/CGF、排查话单异常时基本等于盲人摸象。这篇文章面向的是正在做IMS计费开发、测试或运维的一线人员目标是把TS 32.260的核心结构拆开给出可复现的查阅方法、字段映射思路和实际对接中的避坑经验。2. TS 32.260的文档结构与核心计费模型拆解2.1 为什么IMS计费不能只看Diameter协议本身很多刚接触IMS计费的工程师会有一个误区以为把Diameter基础协议RFC 6733搞懂了Rf和Ro接口就能直接上手。实际翻车点在于Diameter只是承载层TS 32.260定义的是一套完整的计费信息模型——什么事件触发计费请求、哪些信息单元必须携带、CDR如何组织、部分CDR在什么条件下生成、计费会话的起止如何界定。这些内容不在Diameter协议里而在32.260的各个章节中。具体来说TS 32.260的文档结构大致分为几个核心板块计费架构与原则第4章、离线计费第5章、在线计费第6章、计费数据采集与CDR定义第7章及附录。其中第5章和第6章是日常对接中最常翻阅的部分分别对应Rf接口的ACR/ACA消息和Ro接口的CCR/CCA消息。第7章则定义了IMS CDR的ASN.1结构和字段语义做话单解析的同事基本要逐字段对照。中文版的价值在这里就体现出来了英文原版中大量使用“shall”“should”“may”来区分强制、推荐和可选行为机器翻译经常把这些情态动词翻得模棱两可导致开发时误判某个字段是否必须填充。比如“the SDP media component shall be included”和“may be included”在代码实现上就是必填和选填的区别翻错了直接导致对接联调时被对方打回。2.2 离线计费与在线计费的关键差异对照在动手查阅中文版之前先把离线计费和在线计费的核心差异理清楚这样翻文档时能快速定位到对应章节。下面这张表是我在实际对接中整理的对照关系方便你带着问题去查规范。对比维度离线计费Rf接口在线计费Ro接口触发方式计费事件触发事后上报资源使用前请求授权Diameter消息ACR / ACACCR / CCA计费会话管理基于Acct-Session-Id基于Session-Id和CC-Request-Number信用控制不涉及涉及Granted-Service-Unit和Used-Service-UnitCDR生成CDF生成CGF转发通常不生成传统CDR依赖计费会话记录典型失败场景ACR超时未收到ACACDR丢失CCA未及时返回用户业务中断规范章节TS 32.260 第5章TS 32.260 第6章这张表的作用是当你在联调中遇到问题时先判断是Rf还是Ro的问题然后直接跳到对应章节去核对消息结构和AVP定义。比如用户投诉“打电话被莫名中断”大概率是在线计费Ro接口的CCA超时或信用额度耗尽需要查第6章中关于Final-Unit-Indication和Tariff-Time-Change的处理逻辑。2.3 中文版查阅的实操方法从目录到字段定位拿到一份TS 32.260中文版之后不要从头读到尾效率太低。我一般按下面的步骤来定位问题第一步确认版本号。3GPP规范每个Release都有差异比如Rel-15和Rel-17在IMS计费上对5G NSA/SA的支持就有变化。中文版如果没标注对应的Release号先对照英文原版的版本历史确认。第二步用目录锁定章节。TS 32.260的目录结构比较清晰离线计费看5.x在线计费看6.xCDR定义看7.x。如果中文版目录被改过直接搜关键词“ACR”“CCR”“CDR”定位。第三步对照英文原版核对关键字段。中文版最大的风险是翻译偏差尤其是AVP名称和枚举值。我的习惯是中文版看语义理解英文版核对字段名和取值。比如“Service-Information”这个AVP组中文版可能翻译成“服务信息”但代码里必须写Service-Information不能写中文。第四步用抓包工具验证。规范是死的现网是活的。拿Wireshark抓一段Rf或Ro的Diameter消息逐字段和规范对照比单纯读文档快得多。下面是一个用tshark过滤Diameter IMS计费消息的示例# 过滤Rf接口的ACR消息只显示计费相关字段 tshark -r ims_charging.pcap -Y diameter.cmd.code 271 -T fields \ -e frame.number \ -e diameter.Session-Id \ -e diameter.Origin-Host \ -e diameter.Destination-Realm \ -e diameter.Acct-Application-Id \ -e diameter.CC-Request-Type \ -e diameter.Service-Context-Id # 过滤Ro接口的CCR消息查看信用控制相关字段 tshark -r ims_charging.pcap -Y diameter.cmd.code 272 -T fields \ -e frame.number \ -e diameter.Session-Id \ -e diameter.CC-Request-Type \ -e diameter.CC-Request-Number \ -e diameter.Requested-Service-Unit \ -e diameter.Used-Service-Unit \ -e diameter.Multiple-Services-Credit-Control这段命令的逻辑说明-Y后面跟的是Wireshark的显示过滤器diameter.cmd.code 271对应ACRAccounting-Request272对应CCRCredit-Control-Request。-T fields -e用来提取指定字段方便和规范中的AVP定义做对照。参数方面diameter.CC-Request-Type的取值需要对照TS 32.260第6章中的枚举定义INITIAL_REQUEST(1)、UPDATE_REQUEST(2)、TERMINATION_REQUEST(3)、EVENT_REQUEST(4)。如果你在抓包中看到CC-Request-Type的值不在这个范围内说明要么是解析错误要么是对方实现有问题。提示中文版规范中如果出现“计费请求类型”这类翻译建议同时在旁边标注英文原词和枚举值避免开发时混淆。3. 从规范到代码IMS计费对接的核心字段映射与实现3.1 CDR字段解析ASN.1定义到实际话单的映射TS 32.260第7章用ASN.1定义了IMS CDR的结构这是做话单解析的核心依据。很多工程师拿到话单文件后不知道怎么下手其实关键是把ASN.1的字段和实际二进制/文本话单中的位置对应起来。下面以IMS CDR中常见的IMSChargingData为例给出一个Python解析框架# IMS CDR解析框架示例 # 基于TS 32.260第7章ASN.1定义实际解析需结合具体编码格式BER/DER或文本 class IMSChargingData: 对应TS 32.260中IMSChargingData的ASN.1结构 def __init__(self): self.record_type None # 对应recordType标识CDR类型 self.retrieval_timestamp None # 对应retrievalTimeStamp self.subscriber_id None # 对应subscriberIdentifier如IMSI/IMPI self.ims_charging_info None # 对应iMSChargingInformation核心计费信息 def parse_ims_charging_info(self, raw_data): 解析iMSChargingInformation字段组 关键子字段包括 - sDPMediaComponent: SDP媒体描述用于区分音频/视频/消息 - timeStamps: 计费事件的时间戳用于计算时长 - iMSNodeRole: IMS节点角色Originating/Terminating - userLocationInfo: 用户位置信息 - callingPartyNumber / calledPartyNumber: 主被叫号码 # 实际解析逻辑取决于CDR编码格式 # 文本格式通常用分隔符拆分二进制格式需要按ASN.1标签解析 pass def validate_required_fields(self): 校验TS 32.260中定义的必选字段 required [record_type, retrieval_timestamp, subscriber_id] missing [f for f in required if getattr(self, f) is None] if missing: raise ValueError(fCDR缺少必选字段: {missing}) return True这段代码的逻辑说明IMSChargingData类对应规范中的ASN.1结构parse_ims_charging_info方法负责解析核心计费信息字段组。参数方面record_type的取值需要对照规范中的CDR类型定义比如iMSRecord对应IMS计费记录。retrieval_timestamp是CDR生成的时间戳格式通常为UTC时间。subscriber_id可能是IMSI、IMPI或SIP URI具体取决于运营商配置。实际解析时最容易出问题的是iMSChargingInformation中的timeStamps字段。TS 32.260定义了多个时间戳invocationTimeStamp、answerTimeStamp、releaseTimeStamp等用于计算通话时长和计费时长。如果解析时把answerTimeStamp和releaseTimeStamp搞反了算出来的时长就是负数话单直接异常。3.2 Rf接口ACR消息构造必选AVP与条件必选AVP的处理离线计费Rf接口的核心是构造ACR消息。TS 32.260第5章详细定义了ACR中必须携带的AVP和条件必选AVP。下面是一个用Python构造ACR消息的示例基于pyDiameter库的思路# Rf接口ACR消息构造示例 # 参考TS 32.260第5章ACR消息定义 def build_acr_message(session_id, origin_host, origin_realm, destination_realm, acct_application_id, record_type, service_context_id, service_informationNone): 构造Diameter ACR消息 必选AVP参考TS 32.260 5.2节 - Session-Id: 计费会话标识 - Origin-Host / Origin-Realm: 发起方标识 - Destination-Realm: 目的域 - Acct-Application-Id: 计费应用IDIMS Rf通常为16777216 - Accounting-Record-Type: 记录类型 - Accounting-Record-Number: 记录序号 - Service-Context-Id: 服务上下文标识 - Service-Information: 服务信息条件必选IMS场景通常必填 acr { Session-Id: session_id, Origin-Host: origin_host, Origin-Realm: origin_realm, Destination-Realm: destination_realm, Acct-Application-Id: acct_application_id, Accounting-Record-Type: record_type, Accounting-Record-Number: 0, Service-Context-Id: service_context_id, } # Service-Information是IMS计费的核心包含IMS-Information子AVP组 if service_information: acr[Service-Information] service_information return acr # Accounting-Record-Type枚举值TS 32.260 5.2节 # EVENT_RECORD 1 事件记录用于一次性事件 # START_RECORD 2 开始记录会话开始时发送 # INTERIM_RECORD 3 中间记录会话进行中周期性发送 # STOP_RECORD 4 停止记录会话结束时发送这段代码的逻辑说明build_acr_message函数按照TS 32.260第5章的要求组装ACR消息。参数方面acct_application_id在IMS Rf接口中通常为16777216这个值在规范中有明确定义。Accounting-Record-Type的四个枚举值对应不同的计费场景START_RECORD在会话建立时发送INTERIM_RECORD在会话进行中按周期发送周期由Acct-Interim-Interval控制STOP_RECORD在会话结束时发送。实际对接中最容易踩的坑是Service-Information的构造。这个AVP是一个分组AVP内部包含IMS-Information、SDP-Media-Component、Time-Stamps等多个子AVP。TS 32.260对哪些场景下必须携带哪些子AVP有详细规定比如语音通话必须携带SDP-Media-Component来描述媒体类型而短信类业务可能不需要。如果漏填了必选子AVPCDF侧会直接拒绝或生成异常话单。3.3 Ro接口CCR消息与信用控制Granted-Service-Unit的坑在线计费Ro接口比Rf复杂得多因为涉及信用授权和额度管理。TS 32.260第6章定义了CCR/CCA的消息结构和信用控制逻辑。下面是一个CCR消息构造的示例# Ro接口CCR消息构造示例 # 参考TS 32.260第6章CCR消息定义 def build_ccr_initial(session_id, origin_host, origin_realm, destination_realm, service_context_id, requested_service_unit, multiple_services_credit_controlNone): 构造初始CCR消息CC-Request-Type INITIAL_REQUEST 关键AVP - CC-Request-Type: 请求类型 - CC-Request-Number: 请求序号初始为0 - Requested-Service-Unit: 请求的信用额度 - Multiple-Services-Credit-Control: 多服务信用控制IMS场景常用 - Service-Information: 服务信息 ccr { Session-Id: session_id, Origin-Host: origin_host, Origin-Realm: origin_realm, Destination-Realm: destination_realm, Auth-Application-Id: 4, # Diameter Credit-Control Application Service-Context-Id: service_context_id, CC-Request-Type: 1, # INITIAL_REQUEST CC-Request-Number: 0, Requested-Service-Unit: requested_service_unit, } if multiple_services_credit_control: ccr[Multiple-Services-Credit-Control] multiple_services_credit_control return ccr # CC-Request-Type枚举值TS 32.260 6.2节 # INITIAL_REQUEST 1 初始请求会话开始时 # UPDATE_REQUEST 2 更新请求额度耗尽或周期上报 # TERMINATION_REQUEST 3 终止请求会话结束时 # EVENT_REQUEST 4 事件请求一次性事件这段代码的逻辑说明build_ccr_initial构造初始CCR消息Auth-Application-Id固定为4这是Diameter Credit-Control Application的标识。CC-Request-Type的枚举值定义了请求的生命周期阶段。Requested-Service-Unit中通常包含CC-Time请求的时长额度或CC-Total-Octets请求的流量额度具体取决于业务类型。实际对接中Granted-Service-Unit的处理是最容易出问题的环节。OCS返回的CCA中会携带Granted-Service-Unit告诉网元可以使用多少额度。如果网元侧没有正确解析这个字段或者额度耗尽后没有及时发送UPDATE_REQUEST就会出现用户业务中断但OCS侧还在计费的“双杀”场景。TS 32.260第6章对Final-Unit-Indication和Tariff-Time-Change有专门的处理流程定义建议在实现时逐条对照。注意Ro接口的信用控制涉及实时性要求CCA的超时时间通常配置为3-5秒。如果超时未收到CCA网元侧需要根据本地策略决定是放行还是阻断这个策略在TS 32.260中没有强制规定需要和运营商确认。4. IMS计费对接避坑5个血泪踩坑记录4.1 坑一中文版翻译导致AVP名称写错现象联调时CDF侧一直返回“Missing mandatory AVP”错误但代码里明明填了对应的字段。原因中文版规范把Service-Information翻译成“服务信息”开发人员直接在代码里用了中文字段名或者拼音缩写导致Diameter消息编码时AVP名称不匹配。解决所有AVP名称必须以英文原版为准中文版只用于理解语义。建议在代码中维护一个AVP名称常量表直接从英文规范复制避免手写出错。4.2 坑二Accounting-Record-Number不连续导致话单丢失现象CDF侧收到ACR后部分话单没有入库但Diameter层没有报错。原因Accounting-Record-Number在同一个会话中必须连续递增。如果START_RECORD的序号是0INTERIM_RECORD的序号应该是1、2、3……但有些实现中每次新建消息都重置为0导致CDF侧判定为重复消息而丢弃。解决在会话上下文中维护Accounting-Record-Number计数器每次发送ACR时递增。会话结束后计数器销毁。这个逻辑在TS 32.260第5章中有明确说明但容易被忽略。4.3 坑三CC-Request-Number与信用额度不匹配现象OCS侧返回CCA后网元侧继续使用旧额度导致超额使用。原因CC-Request-Number在UPDATE_REQUEST中必须递增OCS根据这个序号判断是否是新的额度请求。如果序号重复OCS可能返回缓存的旧CCA网元侧以为额度已更新实际没有。解决每次发送CCR时CC-Request-Number必须比上一次大1。初始请求为0第一次更新为1以此类推。终止请求的序号是最后一个更新序号加1。这个规则在TS 32.260第6章中有详细描述。4.4 坑四Time-Stamps字段时区处理错误现象话单中的通话时长与实际不符有时差8小时。原因TS 32.260中定义的时间戳通常为UTC时间但有些实现直接用了本地时间导致CDF侧计算时长时出现偏差。解决所有时间戳字段统一使用UTC时间格式为YYYY-MM-DDTHH:MM:SS.sssZ。在代码中明确标注时区转换逻辑避免混用。4.5 坑五Service-Information中SDP-Media-Component缺失现象语音通话的话单中缺少媒体类型信息无法区分音频和视频。原因SDP-Media-Component是条件必选AVP在IMS语音和视频场景中必须携带。有些实现只在视频通话时填了这个字段语音通话时漏填。解决对照TS 32.260第7章中SDP-Media-Component的定义确认在哪些场景下必须携带。一般来说只要涉及SDP协商的业务都需要携带这个字段来描述媒体流信息。5. 进阶技巧用脚本自动化核对中文版与英文版字段差异5.1 为什么需要自动化核对中文版规范在翻译过程中难免出现字段名不一致、枚举值遗漏、章节对应错位等问题。人工逐页核对效率太低而且容易漏。我一般会写一个简单的脚本把中文版和英文版的关键字段提取出来做对比快速定位差异点。5.2 提取规范中的AVP定义并生成对照表下面是一个Python脚本示例用于从文本格式的规范文档中提取AVP名称和描述生成中英文对照表# 规范字段对照提取脚本 # 用途从中文版和英文版TS 32.260文本中提取AVP定义生成对照表 import re def extract_avp_definitions(file_path, langen): 从规范文本中提取AVP定义 英文版通常格式AVP-Name :: AVP header: code 中文版通常格式AVP名称 :: AVP头: 编码 avp_pattern re.compile(r([A-Za-z-])\s*::\s*AVP header:\s*(\d)) definitions {} with open(file_path, r, encodingutf-8) as f: content f.read() matches avp_pattern.findall(content) for name, code in matches: definitions[name] { code: code, lang: lang } return definitions def compare_avp_definitions(en_file, cn_file): 对比中英文版的AVP定义输出差异 en_avps extract_avp_definitions(en_file, en) cn_avps extract_avp_definitions(cn_file, cn) # 找出英文版有但中文版缺失的AVP missing_in_cn set(en_avps.keys()) - set(cn_avps.keys()) # 找出编码不一致的AVP code_mismatch [] for name in set(en_avps.keys()) set(cn_avps.keys()): if en_avps[name][code] ! cn_avps[name][code]: code_mismatch.append((name, en_avps[name][code], cn_avps[name][code])) print(f中文版缺失的AVP数量: {len(missing_in_cn)}) for name in sorted(missing_in_cn): print(f - {name} (code: {en_avps[name][code]})) print(f\n编码不一致的AVP数量: {len(code_mismatch)}) for name, en_code, cn_code in code_mismatch: print(f - {name}: 英文版{en_code}, 中文版{cn_code}) return missing_in_cn, code_mismatch # 使用示例 # compare_avp_definitions(ts_32_260_en.txt, ts_32_260_cn.txt)这段代码的逻辑说明extract_avp_definitions函数用正则表达式从规范文本中提取AVP名称和编码。英文版的格式通常是AVP-Name :: AVP header: code中文版可能略有差异需要根据实际文档调整正则。compare_avp_definitions函数对比两个版本的AVP集合输出中文版缺失的AVP和编码不一致的AVP。参数方面file_path是规范文本文件的路径建议先把PDF转成纯文本再处理。lang参数用于标记来源语言方便后续扩展。实际使用时如果中文版是扫描件或PDF格式需要先用OCR工具提取文本这一步的准确率会影响后续对比结果。5.3 用抓包数据反向验证规范理解自动化核对只能解决字段名和编码的问题真正的理解验证还是要靠抓包。我的习惯是每读完一个章节就抓一段对应的现网消息逐字段对照。比如读完第6章在线计费就抓一段Ro接口的CCR/CCA检查Multiple-Services-Credit-Control中的Rating-Group、Service-Identifier、Granted-Service-Unit等字段是否和规范描述一致。下面是一个用tshark提取Ro接口关键字段并导出CSV的示例# 提取Ro接口CCR/CCA消息的关键字段导出为CSV便于分析 tshark -r ro_charging.pcap -Y diameter.cmd.code 272 || diameter.cmd.code 272 \ -T fields \ -e frame.number \ -e frame.time_relative \ -e diameter.Session-Id \ -e diameter.CC-Request-Type \ -e diameter.CC-Request-Number \ -e diameter.Granted-Service-Unit.CC-Time \ -e diameter.Granted-Service-Unit.CC-Total-Octets \ -e diameter.Used-Service-Unit.CC-Time \ -e diameter.Used-Service-Unit.CC-Total-Octets \ -e diameter.Multiple-Services-Credit-Control.Rating-Group \ -E headery -E separator, ro_charging_analysis.csv这段命令的逻辑说明-Y过滤器同时匹配CCR272和CCA272实际使用时需要根据消息方向区分。-T fields -e提取指定字段-E headery生成CSV表头-E separator,指定逗号分隔。导出的CSV可以直接用Excel或Python做进一步分析比如统计每个会话的额度使用情况、检查CC-Request-Number是否连续等。参数方面diameter.Granted-Service-Unit.CC-Time和diameter.Used-Service-Unit.CC-Time分别对应授权时长和已用时长单位通常是秒。如果发现Used-Service-Unit的值大于Granted-Service-Unit说明网元侧超额使用了额度需要检查信用控制逻辑。提示抓包分析时注意区分CCR和CCA的方向。CCR是网元发往OCS的请求CCA是OCS返回的应答。用-e diameter.CC-Request-Type可以区分请求类型但CCA中也会携带这个字段需要结合IP地址或端口判断方向。5.4 建立自己的规范速查手册最后分享一个习惯我会把TS 32.260中最常用的字段和枚举值整理成一个速查表放在手边。比如CC-Request-Type的四个值、Accounting-Record-Type的四个值、Acct-Application-Id的固定值、Auth-Application-Id的固定值等。这些值在联调和排错时反复用到每次翻规范太浪费时间。速查表的内容不需要多一页纸就够。关键是把中文版和英文版对照着写避免翻译偏差。比如字段名中文版翻译常用取值所在章节CC-Request-Type信用控制请求类型1/2/3/46.2Accounting-Record-Type计费记录类型1/2/3/45.2Acct-Application-Id计费应用标识167772165.2Auth-Application-Id认证应用标识46.2Service-Context-Id服务上下文标识由运营商定义5.2/6.2这张表是我在多次联调中逐步积累的每次遇到新问题就补充一行。时间长了它比任何文档都管用。希望帮到你。本文还有配套的精品资源点击获取 3GPP TS 32.260 IMS计费行标中文版：从协议到落地的关键拼图
简介本资源为3GPP TS 32.260《电信管理—计费管理—IP多媒体子系统IMS计费》第17版的中文版技术规范面向从事IMS计费系统研发、测试与运维的通信工程师及标准研究者帮助读者跨越英文原文门槛准确理解IMS在线计费、离线计费与融合计费的核心机制。压缩包内仅含1个PDF文件约2.65MB内容涵盖前言、范围、参考文献、定义符号与缩写、架构注意事项、计费原理等章节并系统梳理了计费数据记录CDR、计费触发点、在线计费系统OCS、离线计费系统OFS、计费策略与规则功能CPRF以及Diameter、Gx等接口协议等关键知识点。目前已有195人学习下载适合作为IMS计费方案设计、接口对接与问题排查的案头参考建议结合英文原版对照研读以全面掌握技术细节。1. 3GPP TS 32.260 IMS计费行标中文版从协议到落地的关键拼图做IMS计费对接的工程师大概率都经历过这种场景话单对不上、CDR字段缺失、离线计费与在线计费切换时信令流程卡死抓包一看问题出在某个Diameter AVP的取值和规范理解有偏差。这时候翻出3GPP TS 32.260的英文原版几百页的协议文档光术语定义就能劝退一半人。而市面上流传的所谓“中文版”要么是机器翻译的残卷要么是某个版本的部分章节摘录真正能拿来对照代码和抓包做逐字段核对的完整行标中文版极其稀缺。TS 32.260全称是“Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging”它定义了IMS域内离线计费、在线计费和计费数据采集的完整框架包括Rf、Ro接口的Diameter消息结构、CDR的字段语义、计费触发条件、部分CDR的生成规则等。没有这份规范的中文对照你在对接BOSS系统、调试CDF/CGF、排查话单异常时基本等于盲人摸象。这篇文章面向的是正在做IMS计费开发、测试或运维的一线人员目标是把TS 32.260的核心结构拆开给出可复现的查阅方法、字段映射思路和实际对接中的避坑经验。2. TS 32.260的文档结构与核心计费模型拆解2.1 为什么IMS计费不能只看Diameter协议本身很多刚接触IMS计费的工程师会有一个误区以为把Diameter基础协议RFC 6733搞懂了Rf和Ro接口就能直接上手。实际翻车点在于Diameter只是承载层TS 32.260定义的是一套完整的计费信息模型——什么事件触发计费请求、哪些信息单元必须携带、CDR如何组织、部分CDR在什么条件下生成、计费会话的起止如何界定。这些内容不在Diameter协议里而在32.260的各个章节中。具体来说TS 32.260的文档结构大致分为几个核心板块计费架构与原则第4章、离线计费第5章、在线计费第6章、计费数据采集与CDR定义第7章及附录。其中第5章和第6章是日常对接中最常翻阅的部分分别对应Rf接口的ACR/ACA消息和Ro接口的CCR/CCA消息。第7章则定义了IMS CDR的ASN.1结构和字段语义做话单解析的同事基本要逐字段对照。中文版的价值在这里就体现出来了英文原版中大量使用“shall”“should”“may”来区分强制、推荐和可选行为机器翻译经常把这些情态动词翻得模棱两可导致开发时误判某个字段是否必须填充。比如“the SDP media component shall be included”和“may be included”在代码实现上就是必填和选填的区别翻错了直接导致对接联调时被对方打回。2.2 离线计费与在线计费的关键差异对照在动手查阅中文版之前先把离线计费和在线计费的核心差异理清楚这样翻文档时能快速定位到对应章节。下面这张表是我在实际对接中整理的对照关系方便你带着问题去查规范。对比维度离线计费Rf接口在线计费Ro接口触发方式计费事件触发事后上报资源使用前请求授权Diameter消息ACR / ACACCR / CCA计费会话管理基于Acct-Session-Id基于Session-Id和CC-Request-Number信用控制不涉及涉及Granted-Service-Unit和Used-Service-UnitCDR生成CDF生成CGF转发通常不生成传统CDR依赖计费会话记录典型失败场景ACR超时未收到ACACDR丢失CCA未及时返回用户业务中断规范章节TS 32.260 第5章TS 32.260 第6章这张表的作用是当你在联调中遇到问题时先判断是Rf还是Ro的问题然后直接跳到对应章节去核对消息结构和AVP定义。比如用户投诉“打电话被莫名中断”大概率是在线计费Ro接口的CCA超时或信用额度耗尽需要查第6章中关于Final-Unit-Indication和Tariff-Time-Change的处理逻辑。2.3 中文版查阅的实操方法从目录到字段定位拿到一份TS 32.260中文版之后不要从头读到尾效率太低。我一般按下面的步骤来定位问题第一步确认版本号。3GPP规范每个Release都有差异比如Rel-15和Rel-17在IMS计费上对5G NSA/SA的支持就有变化。中文版如果没标注对应的Release号先对照英文原版的版本历史确认。第二步用目录锁定章节。TS 32.260的目录结构比较清晰离线计费看5.x在线计费看6.xCDR定义看7.x。如果中文版目录被改过直接搜关键词“ACR”“CCR”“CDR”定位。第三步对照英文原版核对关键字段。中文版最大的风险是翻译偏差尤其是AVP名称和枚举值。我的习惯是中文版看语义理解英文版核对字段名和取值。比如“Service-Information”这个AVP组中文版可能翻译成“服务信息”但代码里必须写Service-Information不能写中文。第四步用抓包工具验证。规范是死的现网是活的。拿Wireshark抓一段Rf或Ro的Diameter消息逐字段和规范对照比单纯读文档快得多。下面是一个用tshark过滤Diameter IMS计费消息的示例# 过滤Rf接口的ACR消息只显示计费相关字段 tshark -r ims_charging.pcap -Y diameter.cmd.code 271 -T fields \ -e frame.number \ -e diameter.Session-Id \ -e diameter.Origin-Host \ -e diameter.Destination-Realm \ -e diameter.Acct-Application-Id \ -e diameter.CC-Request-Type \ -e diameter.Service-Context-Id # 过滤Ro接口的CCR消息查看信用控制相关字段 tshark -r ims_charging.pcap -Y diameter.cmd.code 272 -T fields \ -e frame.number \ -e diameter.Session-Id \ -e diameter.CC-Request-Type \ -e diameter.CC-Request-Number \ -e diameter.Requested-Service-Unit \ -e diameter.Used-Service-Unit \ -e diameter.Multiple-Services-Credit-Control这段命令的逻辑说明-Y后面跟的是Wireshark的显示过滤器diameter.cmd.code 271对应ACRAccounting-Request272对应CCRCredit-Control-Request。-T fields -e用来提取指定字段方便和规范中的AVP定义做对照。参数方面diameter.CC-Request-Type的取值需要对照TS 32.260第6章中的枚举定义INITIAL_REQUEST(1)、UPDATE_REQUEST(2)、TERMINATION_REQUEST(3)、EVENT_REQUEST(4)。如果你在抓包中看到CC-Request-Type的值不在这个范围内说明要么是解析错误要么是对方实现有问题。提示中文版规范中如果出现“计费请求类型”这类翻译建议同时在旁边标注英文原词和枚举值避免开发时混淆。3. 从规范到代码IMS计费对接的核心字段映射与实现3.1 CDR字段解析ASN.1定义到实际话单的映射TS 32.260第7章用ASN.1定义了IMS CDR的结构这是做话单解析的核心依据。很多工程师拿到话单文件后不知道怎么下手其实关键是把ASN.1的字段和实际二进制/文本话单中的位置对应起来。下面以IMS CDR中常见的IMSChargingData为例给出一个Python解析框架# IMS CDR解析框架示例 # 基于TS 32.260第7章ASN.1定义实际解析需结合具体编码格式BER/DER或文本 class IMSChargingData: 对应TS 32.260中IMSChargingData的ASN.1结构 def __init__(self): self.record_type None # 对应recordType标识CDR类型 self.retrieval_timestamp None # 对应retrievalTimeStamp self.subscriber_id None # 对应subscriberIdentifier如IMSI/IMPI self.ims_charging_info None # 对应iMSChargingInformation核心计费信息 def parse_ims_charging_info(self, raw_data): 解析iMSChargingInformation字段组 关键子字段包括 - sDPMediaComponent: SDP媒体描述用于区分音频/视频/消息 - timeStamps: 计费事件的时间戳用于计算时长 - iMSNodeRole: IMS节点角色Originating/Terminating - userLocationInfo: 用户位置信息 - callingPartyNumber / calledPartyNumber: 主被叫号码 # 实际解析逻辑取决于CDR编码格式 # 文本格式通常用分隔符拆分二进制格式需要按ASN.1标签解析 pass def validate_required_fields(self): 校验TS 32.260中定义的必选字段 required [record_type, retrieval_timestamp, subscriber_id] missing [f for f in required if getattr(self, f) is None] if missing: raise ValueError(fCDR缺少必选字段: {missing}) return True这段代码的逻辑说明IMSChargingData类对应规范中的ASN.1结构parse_ims_charging_info方法负责解析核心计费信息字段组。参数方面record_type的取值需要对照规范中的CDR类型定义比如iMSRecord对应IMS计费记录。retrieval_timestamp是CDR生成的时间戳格式通常为UTC时间。subscriber_id可能是IMSI、IMPI或SIP URI具体取决于运营商配置。实际解析时最容易出问题的是iMSChargingInformation中的timeStamps字段。TS 32.260定义了多个时间戳invocationTimeStamp、answerTimeStamp、releaseTimeStamp等用于计算通话时长和计费时长。如果解析时把answerTimeStamp和releaseTimeStamp搞反了算出来的时长就是负数话单直接异常。3.2 Rf接口ACR消息构造必选AVP与条件必选AVP的处理离线计费Rf接口的核心是构造ACR消息。TS 32.260第5章详细定义了ACR中必须携带的AVP和条件必选AVP。下面是一个用Python构造ACR消息的示例基于pyDiameter库的思路# Rf接口ACR消息构造示例 # 参考TS 32.260第5章ACR消息定义 def build_acr_message(session_id, origin_host, origin_realm, destination_realm, acct_application_id, record_type, service_context_id, service_informationNone): 构造Diameter ACR消息 必选AVP参考TS 32.260 5.2节 - Session-Id: 计费会话标识 - Origin-Host / Origin-Realm: 发起方标识 - Destination-Realm: 目的域 - Acct-Application-Id: 计费应用IDIMS Rf通常为16777216 - Accounting-Record-Type: 记录类型 - Accounting-Record-Number: 记录序号 - Service-Context-Id: 服务上下文标识 - Service-Information: 服务信息条件必选IMS场景通常必填 acr { Session-Id: session_id, Origin-Host: origin_host, Origin-Realm: origin_realm, Destination-Realm: destination_realm, Acct-Application-Id: acct_application_id, Accounting-Record-Type: record_type, Accounting-Record-Number: 0, Service-Context-Id: service_context_id, } # Service-Information是IMS计费的核心包含IMS-Information子AVP组 if service_information: acr[Service-Information] service_information return acr # Accounting-Record-Type枚举值TS 32.260 5.2节 # EVENT_RECORD 1 事件记录用于一次性事件 # START_RECORD 2 开始记录会话开始时发送 # INTERIM_RECORD 3 中间记录会话进行中周期性发送 # STOP_RECORD 4 停止记录会话结束时发送这段代码的逻辑说明build_acr_message函数按照TS 32.260第5章的要求组装ACR消息。参数方面acct_application_id在IMS Rf接口中通常为16777216这个值在规范中有明确定义。Accounting-Record-Type的四个枚举值对应不同的计费场景START_RECORD在会话建立时发送INTERIM_RECORD在会话进行中按周期发送周期由Acct-Interim-Interval控制STOP_RECORD在会话结束时发送。实际对接中最容易踩的坑是Service-Information的构造。这个AVP是一个分组AVP内部包含IMS-Information、SDP-Media-Component、Time-Stamps等多个子AVP。TS 32.260对哪些场景下必须携带哪些子AVP有详细规定比如语音通话必须携带SDP-Media-Component来描述媒体类型而短信类业务可能不需要。如果漏填了必选子AVPCDF侧会直接拒绝或生成异常话单。3.3 Ro接口CCR消息与信用控制Granted-Service-Unit的坑在线计费Ro接口比Rf复杂得多因为涉及信用授权和额度管理。TS 32.260第6章定义了CCR/CCA的消息结构和信用控制逻辑。下面是一个CCR消息构造的示例# Ro接口CCR消息构造示例 # 参考TS 32.260第6章CCR消息定义 def build_ccr_initial(session_id, origin_host, origin_realm, destination_realm, service_context_id, requested_service_unit, multiple_services_credit_controlNone): 构造初始CCR消息CC-Request-Type INITIAL_REQUEST 关键AVP - CC-Request-Type: 请求类型 - CC-Request-Number: 请求序号初始为0 - Requested-Service-Unit: 请求的信用额度 - Multiple-Services-Credit-Control: 多服务信用控制IMS场景常用 - Service-Information: 服务信息 ccr { Session-Id: session_id, Origin-Host: origin_host, Origin-Realm: origin_realm, Destination-Realm: destination_realm, Auth-Application-Id: 4, # Diameter Credit-Control Application Service-Context-Id: service_context_id, CC-Request-Type: 1, # INITIAL_REQUEST CC-Request-Number: 0, Requested-Service-Unit: requested_service_unit, } if multiple_services_credit_control: ccr[Multiple-Services-Credit-Control] multiple_services_credit_control return ccr # CC-Request-Type枚举值TS 32.260 6.2节 # INITIAL_REQUEST 1 初始请求会话开始时 # UPDATE_REQUEST 2 更新请求额度耗尽或周期上报 # TERMINATION_REQUEST 3 终止请求会话结束时 # EVENT_REQUEST 4 事件请求一次性事件这段代码的逻辑说明build_ccr_initial构造初始CCR消息Auth-Application-Id固定为4这是Diameter Credit-Control Application的标识。CC-Request-Type的枚举值定义了请求的生命周期阶段。Requested-Service-Unit中通常包含CC-Time请求的时长额度或CC-Total-Octets请求的流量额度具体取决于业务类型。实际对接中Granted-Service-Unit的处理是最容易出问题的环节。OCS返回的CCA中会携带Granted-Service-Unit告诉网元可以使用多少额度。如果网元侧没有正确解析这个字段或者额度耗尽后没有及时发送UPDATE_REQUEST就会出现用户业务中断但OCS侧还在计费的“双杀”场景。TS 32.260第6章对Final-Unit-Indication和Tariff-Time-Change有专门的处理流程定义建议在实现时逐条对照。注意Ro接口的信用控制涉及实时性要求CCA的超时时间通常配置为3-5秒。如果超时未收到CCA网元侧需要根据本地策略决定是放行还是阻断这个策略在TS 32.260中没有强制规定需要和运营商确认。4. IMS计费对接避坑5个血泪踩坑记录4.1 坑一中文版翻译导致AVP名称写错现象联调时CDF侧一直返回“Missing mandatory AVP”错误但代码里明明填了对应的字段。原因中文版规范把Service-Information翻译成“服务信息”开发人员直接在代码里用了中文字段名或者拼音缩写导致Diameter消息编码时AVP名称不匹配。解决所有AVP名称必须以英文原版为准中文版只用于理解语义。建议在代码中维护一个AVP名称常量表直接从英文规范复制避免手写出错。4.2 坑二Accounting-Record-Number不连续导致话单丢失现象CDF侧收到ACR后部分话单没有入库但Diameter层没有报错。原因Accounting-Record-Number在同一个会话中必须连续递增。如果START_RECORD的序号是0INTERIM_RECORD的序号应该是1、2、3……但有些实现中每次新建消息都重置为0导致CDF侧判定为重复消息而丢弃。解决在会话上下文中维护Accounting-Record-Number计数器每次发送ACR时递增。会话结束后计数器销毁。这个逻辑在TS 32.260第5章中有明确说明但容易被忽略。4.3 坑三CC-Request-Number与信用额度不匹配现象OCS侧返回CCA后网元侧继续使用旧额度导致超额使用。原因CC-Request-Number在UPDATE_REQUEST中必须递增OCS根据这个序号判断是否是新的额度请求。如果序号重复OCS可能返回缓存的旧CCA网元侧以为额度已更新实际没有。解决每次发送CCR时CC-Request-Number必须比上一次大1。初始请求为0第一次更新为1以此类推。终止请求的序号是最后一个更新序号加1。这个规则在TS 32.260第6章中有详细描述。4.4 坑四Time-Stamps字段时区处理错误现象话单中的通话时长与实际不符有时差8小时。原因TS 32.260中定义的时间戳通常为UTC时间但有些实现直接用了本地时间导致CDF侧计算时长时出现偏差。解决所有时间戳字段统一使用UTC时间格式为YYYY-MM-DDTHH:MM:SS.sssZ。在代码中明确标注时区转换逻辑避免混用。4.5 坑五Service-Information中SDP-Media-Component缺失现象语音通话的话单中缺少媒体类型信息无法区分音频和视频。原因SDP-Media-Component是条件必选AVP在IMS语音和视频场景中必须携带。有些实现只在视频通话时填了这个字段语音通话时漏填。解决对照TS 32.260第7章中SDP-Media-Component的定义确认在哪些场景下必须携带。一般来说只要涉及SDP协商的业务都需要携带这个字段来描述媒体流信息。5. 进阶技巧用脚本自动化核对中文版与英文版字段差异5.1 为什么需要自动化核对中文版规范在翻译过程中难免出现字段名不一致、枚举值遗漏、章节对应错位等问题。人工逐页核对效率太低而且容易漏。我一般会写一个简单的脚本把中文版和英文版的关键字段提取出来做对比快速定位差异点。5.2 提取规范中的AVP定义并生成对照表下面是一个Python脚本示例用于从文本格式的规范文档中提取AVP名称和描述生成中英文对照表# 规范字段对照提取脚本 # 用途从中文版和英文版TS 32.260文本中提取AVP定义生成对照表 import re def extract_avp_definitions(file_path, langen): 从规范文本中提取AVP定义 英文版通常格式AVP-Name :: AVP header: code 中文版通常格式AVP名称 :: AVP头: 编码 avp_pattern re.compile(r([A-Za-z-])\s*::\s*AVP header:\s*(\d)) definitions {} with open(file_path, r, encodingutf-8) as f: content f.read() matches avp_pattern.findall(content) for name, code in matches: definitions[name] { code: code, lang: lang } return definitions def compare_avp_definitions(en_file, cn_file): 对比中英文版的AVP定义输出差异 en_avps extract_avp_definitions(en_file, en) cn_avps extract_avp_definitions(cn_file, cn) # 找出英文版有但中文版缺失的AVP missing_in_cn set(en_avps.keys()) - set(cn_avps.keys()) # 找出编码不一致的AVP code_mismatch [] for name in set(en_avps.keys()) set(cn_avps.keys()): if en_avps[name][code] ! cn_avps[name][code]: code_mismatch.append((name, en_avps[name][code], cn_avps[name][code])) print(f中文版缺失的AVP数量: {len(missing_in_cn)}) for name in sorted(missing_in_cn): print(f - {name} (code: {en_avps[name][code]})) print(f\n编码不一致的AVP数量: {len(code_mismatch)}) for name, en_code, cn_code in code_mismatch: print(f - {name}: 英文版{en_code}, 中文版{cn_code}) return missing_in_cn, code_mismatch # 使用示例 # compare_avp_definitions(ts_32_260_en.txt, ts_32_260_cn.txt)这段代码的逻辑说明extract_avp_definitions函数用正则表达式从规范文本中提取AVP名称和编码。英文版的格式通常是AVP-Name :: AVP header: code中文版可能略有差异需要根据实际文档调整正则。compare_avp_definitions函数对比两个版本的AVP集合输出中文版缺失的AVP和编码不一致的AVP。参数方面file_path是规范文本文件的路径建议先把PDF转成纯文本再处理。lang参数用于标记来源语言方便后续扩展。实际使用时如果中文版是扫描件或PDF格式需要先用OCR工具提取文本这一步的准确率会影响后续对比结果。5.3 用抓包数据反向验证规范理解自动化核对只能解决字段名和编码的问题真正的理解验证还是要靠抓包。我的习惯是每读完一个章节就抓一段对应的现网消息逐字段对照。比如读完第6章在线计费就抓一段Ro接口的CCR/CCA检查Multiple-Services-Credit-Control中的Rating-Group、Service-Identifier、Granted-Service-Unit等字段是否和规范描述一致。下面是一个用tshark提取Ro接口关键字段并导出CSV的示例# 提取Ro接口CCR/CCA消息的关键字段导出为CSV便于分析 tshark -r ro_charging.pcap -Y diameter.cmd.code 272 || diameter.cmd.code 272 \ -T fields \ -e frame.number \ -e frame.time_relative \ -e diameter.Session-Id \ -e diameter.CC-Request-Type \ -e diameter.CC-Request-Number \ -e diameter.Granted-Service-Unit.CC-Time \ -e diameter.Granted-Service-Unit.CC-Total-Octets \ -e diameter.Used-Service-Unit.CC-Time \ -e diameter.Used-Service-Unit.CC-Total-Octets \ -e diameter.Multiple-Services-Credit-Control.Rating-Group \ -E headery -E separator, ro_charging_analysis.csv这段命令的逻辑说明-Y过滤器同时匹配CCR272和CCA272实际使用时需要根据消息方向区分。-T fields -e提取指定字段-E headery生成CSV表头-E separator,指定逗号分隔。导出的CSV可以直接用Excel或Python做进一步分析比如统计每个会话的额度使用情况、检查CC-Request-Number是否连续等。参数方面diameter.Granted-Service-Unit.CC-Time和diameter.Used-Service-Unit.CC-Time分别对应授权时长和已用时长单位通常是秒。如果发现Used-Service-Unit的值大于Granted-Service-Unit说明网元侧超额使用了额度需要检查信用控制逻辑。提示抓包分析时注意区分CCR和CCA的方向。CCR是网元发往OCS的请求CCA是OCS返回的应答。用-e diameter.CC-Request-Type可以区分请求类型但CCA中也会携带这个字段需要结合IP地址或端口判断方向。5.4 建立自己的规范速查手册最后分享一个习惯我会把TS 32.260中最常用的字段和枚举值整理成一个速查表放在手边。比如CC-Request-Type的四个值、Accounting-Record-Type的四个值、Acct-Application-Id的固定值、Auth-Application-Id的固定值等。这些值在联调和排错时反复用到每次翻规范太浪费时间。速查表的内容不需要多一页纸就够。关键是把中文版和英文版对照着写避免翻译偏差。比如字段名中文版翻译常用取值所在章节CC-Request-Type信用控制请求类型1/2/3/46.2Accounting-Record-Type计费记录类型1/2/3/45.2Acct-Application-Id计费应用标识167772165.2Auth-Application-Id认证应用标识46.2Service-Context-Id服务上下文标识由运营商定义5.2/6.2这张表是我在多次联调中逐步积累的每次遇到新问题就补充一行。时间长了它比任何文档都管用。希望帮到你。本文还有配套的精品资源点击获取