《NGBOSS2BOSS(V3.0)在线计费接口规范 .doc》由会员分享，可在线阅读，更多相关《NGBOSS2BOSS(V3.0)在线计费接口规范 .doc（75页珍藏版）》请在三一办公上搜索。
1、中国移动通信企业标准QB-Y-xxx-2010NGBOSS2-BOSS3.0在线计费接口规范The Online Charging Interface Specification of NGBOSS2-BOSS3.0版本号：1.0.02010-xx-xx实施2010-xx-xx发布中国移动通信集团公司 发布目录1.范围12.规范性引用文件23.术语、定义合缩略语24.DCCA协议定义44.1.协议结构54.2.协议格式54.2.1.消息头格式54.2.2.消息列表74.2.3.AVP头格式84.2.4.AVP数据格式94.2.5.AVP编码原则115.Diameter 协议命令集115.1.C
2、redit-Control-Request (CCR)125.2.Credit-Control-Answer (CCA)185.3.Re-Auth-Request(RAR)215.4.Re-Auth-Answer(RAA)225.5.Device-Watchdog-Request(DWR)225.6.Device-Watchdog-Answer(DWA)235.7.Capabilities-Exchange-Request (CER)235.8.Capabilities-Exchange-Answer (CEA)245.9.Abort-Session-Request(ASR)255.10.Ab
3、ort-Session-Answer(ASA)255.11.Disconnect-Peer-Request(DPR)265.12.Disconnect-Peer-Answer(DPA)266.语音业务276.1.接口定义276.1.1.在CCR中的IN-Information276.1.2.在CCA中的IN-Information286.2.业务流程296.2.1.主叫流程296.2.2.被叫流程316.2.3.无条件呼叫前转336.2.4.有条件呼叫前转346.2.5.异常流程366.3.交换机话单标志427.短信业务437.1.接口定义437.1.1.在CCR中的P2PSMS-Inform
4、ation437.1.2.在CCA中的P2PSMS-Information437.2.业务流程457.2.1.短信流程458.GPRS业务468.1.接口定义468.1.1.在CCR中的PS-Information468.1.2.在CCA中的PS-Information478.2.业务流程478.2.1.流量计费类业务在线计费流程478.2.2.时长计费类业务在线计费流程548.2.3.费率改变控制流程568.2.4.余额不足控制流程578.2.5.用户充值成功业务放通流程（可选）608.2.6.异常流程618.2.7.其他流程628.3.Result-Code场景举例629.梦网业务639.
5、1.接口定义639.1.1.在CCR中的DSMP-Information639.1.2.在CCA中的DSMP-Information649.2.业务流程659.2.1.梦网SMS/MMS业务659.2.2.梦网SMS/MMS业务包月费用收取6610.已定义的AVP表6610.1.CCR AVP表6710.2.CCA AVP表6811.Result-Code定义68图4.1 DCCA协议的协议结构5图4.2 消息头格式5图4.3 AVP头格式8图6.1 语音主叫流程29图6.2 语音被叫流程32图6.3 语音无条件前转流程33图6.4 语音有条件前转流程34图6.5 语音异常流程，初始余额不足，
6、不足一个时间片36图6.6 语音异常流程，初始余额不足，不足最小计费单元37图6.7 语音异常流程，通话过程中余额不足，不足一个时间片38图6.8 语音异常流程，通话过程中余额不足，不足一个计费单元39图6.9 语音异常流程，未受到更新或中止消息41图8.1 GPRS非内容计费类业务在线计费流程48图8.2 GPRS内容计费类业务在线计费流程51图8.3 GPRS时长计费类业务在线计费流程54图8.4 GPRS费率改变控制流程56图8.5 用户上线过程中发现余额不足控制流程58图8.6 用户使用数据业务过程中发现余额不足控制流程158图8.7 用户使用数据业务过程中发现余额不足控制流程259图
7、8.8 用户充值成功业务放通流程60图8.9 异常流程的离线话单处理流程62图8.10 Result-Code场景举例63图9.1 梦网SMS/MMS流程65表2-1 规范性引用文件2表3-1 术语和定义2表3-2 缩略语3表4-1 消息列表7表5-1 Credit-Control-Request (CCR)12表5-2 Credit-Control-Answer (CCA)18表6-1 CCR中的IN-Information27表6-2 CCA中的IN-Information28表7-1 CCR中的P2PSMS-Information43表7-2 CCA中的P2PSMS-Informatio
8、n43表8-1 CCR中的PS-Information46表8-2 CCA中的PS-Information47表9-1 CCR中的DSMP-Information63表11-1 Result-Code68前言本标准以新一代业务运营支撑系统（NGBOSS）整体规划为指导，明确定义了中国移动省级BOSS系统的在线计费接口规范，用以指导现有BOSS系统建设。本标准主要包括NG2-BOSS(V3.0) 在线计费接口定义及流程。本标准由中移技2010xxx号印发。本标准由中国移动通信集团公司业务支撑系统部提出,集团公司技术部归口。本标准起草单位：中国移动通信集团公司业务支撑系统部。本标准主要起草人：*等
9、。1. 范围NG2-BOSS(V3.0)在线计费接口规范分册基于3GPP及相应国际技术标准规范, 制定了BOSS支持在线计费的接口协议规范，供中国移动内部和厂商共同使用，适用于中国移动各省（直辖市、自治区）BOSS系统工程的建设。本规范涉及语音业务、短信业务、数据流量业务、梦网业务的在线计费接口规范。本规范下列章节中述及的CRM、BOSS、业务平台和DSMP等，如未特别注明，均指中国移动省级系统。2. 规范性引用文件 下列文件中的条款通过本规范的引用而成为本规范的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本规范，然而，鼓励根据本规范达成协议的各方研究是
10、否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本规范。表2-1 规范性引用文件1QB-J-011-2007省级业务运营支撑系统（BOSS）业务技术规范欠费风险控制分册（3.0版）中国移动通信有限公司2QB-Y-010-2009NGBOSS1.0-BOSS(v2.0)业务规范中国移动通信有限公司3QB-Y-011-2009NGBOSS1.0-BOSS(v2.0)技术规范中国移动通信有限公司4QB-Y-009-2009NGBOSS1.0-BOSS(V2.0)系统流程框架规范中国移动通信有限公司5RFC 3588: “Diameter Base Protocol”IETF6RF
11、C 4006: “Diameter Credit-Control Application”IETF7TS 32.299: Telecommunication management; Charging management; Diameter charging application3GPP3. 术语、定义合缩略语如无特殊说明，本规范中BOSS均特指NG2-BOSS(V3.0) ，CRM均特指NG2-CRM(V3.0)。下列术语和定义适用于本规范：表3-1 术语和定义字母名词解释F服务使用记录在使用中国移动提供的服务时，由相关的设备和系统产生的标识用户使用网络资源的记录。R融合计费融合计费是依据
12、计费资源、产品资费、用户资料信息实现个人客户跨业务和集团客户跨地域、跨业务的计费过程。S实时出帐实时出帐是指根据融合计费功能域形成的计费详单进行汇总，进行固定费用的加载、包月信息费、帐单级优惠，形成用于实时信用控制的综合帐单数据的过程。Y业务平台提供独立的有某项业务能力的系统，如彩铃中心。Y用户用户是中国移动客户订购产品的实例。包括资源占用、用户价值、订购信息。Y用户号码用户号码是指由中国移动通信用户的移动电话号码MSISDN。Y预付费业务移动客户预先购买一定价值的通信资源，用户使用时，移动网络对其实时计费，从预先购买的通信资源里减去本次通信费用，直至预付金额全部用完。Z帐本是登记帐户服务收费
13、及往来收支关系的帐簿。Z帐户客户使用移动服务的付费实体。Z综合采集综合采集从采集源读取各种移动业务的服务使用记录、结算稽核、客户资料、产品资料等数据，将读取到的数据传输到融合计费和综合结算功能域进行处理。Z综合帐务综合帐务是指对综合帐单的生成、管理及核算的过程，包括：帐务处理、帐务管理、信用管理、积分管理。Z资费规则资费规则是对资费的适用条件、计算方法等的描述。Z增值服务增值服务是指依赖于主体服务的附加功能。例如：来电显示、三方通话等。下列缩略语适用于本规范：表3-2 缩略语缩略语全称英文全称中文INIntelligent Network智能网络CAMELCustomized Applicat
14、ions for Mobile Network Enhanced Logic移动网络增强逻辑客户化应用SSPService Switch Point业务交换点SCPService Control Point业务控制点MAPMobile Application Part移动应用部分CAPCAMEL Application PartCAMEL应用部分HLRHome Location Register归属位置寄存器VLRVisit Location Register拜访位置寄存器MSCMobile Switch Center移动交换中心O-CSIOriginating CAMEL Subscript
15、ion Information发端CAMEL签约信息T-CSITerminating CAMEL Subscription Information终端CAMEL签约信息BOSSBusiness Operation Supporting System中国移动业务运营支撑系统DiameterDiameter一种AAA协议Diameter CCDiameter Credit ControlDiameter协议的信用控制扩展协议AVPAttribute Value Pairs属性-值对CDRCall Data Record呼叫数据记录SMSCShort Message Center短信中心ISMGIn
16、ternet Short Message Gateway短信网关MMSCMultimedia Message Switch Center彩信中心DSMPData Service Management Platform数据业务管理平台NGBOSSNew Generation Business Operation & Support System新一代业务运营支撑系统4. DCCA协议定义目前,移动网络正逐步向全IP网络演进，不仅在核心网络使用支持IP的网络实体，在接入网络也使用基于IP的技术，而且移动终端也成为可激活的IP客户端。这就需要采用新一代的AAA协议Diameter。Diameter基
17、础协议为各种认证、授权和计费业务提供了安全、可靠、易于扩展的框架。以此为基础定义Diameter应用，只需要定义应用协议的应用标识、参与通信的网络功能实体、相互通信的功能实体间的消息内容以及协议过程，就可以完全依赖Diameter基础协议完成特定的接入和应用业务。Diameter协议具有如下特性： （1）具有良好的网络适应性和可扩展性；（2）统一且良好的失败控制和检测机制；（3）完整的传送层安全保证（包括域内和域间）；（4）数据传输可靠性保证机制；（5）支持各种类型的代理，包括Proxy 代理、重定向代理以及中继代理等；（6）支持服务器发起的消息，即允许服务器主动发送消息给其客户端；（7）与现
18、有网络协议的良好可互操作性；（8）支持节点间的能力协商机制；（9）支持动态对等端发现和配置机制；（10）支持安全和可扩展的漫游。Diameter包含基础协议、传送协议、不同的应用扩展，如：所有应用和服务共用的基本功能都在基础协议中实现，而应用特定的功能则会在不同的应用中实施。Diameter基础协议注重能力协商，消息发送以及对等端如何最终被拒绝。Diameter基础协议还规定了特定规则以用于Diameter节点之间所有的消息交换。Diameter基础协议旨在提供一个AAA框架，以用于各种应用。基础协议还定义了所有Diameter应用使用的，并且所有Diameter设备都必须支持的消息格式、传输
19、、差错报告和安全服务等机制。在Diameter基础协议上扩展的应用协议Diameter Credit Control Application，定义了针对预付费用户的计费机制，采用信用额度控制实现了基于会话及事件的计费，解决了对于预付费的计费需求。4.1. 协议结构遵循Diameter基础协议，DCCA协议是在Diameter 基础协议之上，根据数据业务在线计费的具体需求，设计的用于进行信用控制的应用层协议：Diameter Credit Control ApplicationDiameter BaseTLSTCPSCTPIP/IPsec图4.1 DCCA协议的协议结构4.2. 协议格式4.2.
20、1. 消息头格式DCCA协议的消息结构如下图所示，这些字段是以网络字节顺序传送的。0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | command flags | Command-
21、Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-
22、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs . +-+-+-+-+-+-+-+-+-+-+-+-+-图4.2 消息头格式 Version：该版本字段必须被置为1，表明Diameter版本1。 Message Length：该消息长度字段为3个八位组，指明该Diameter消息的字节长度，包括头字段。 Command flags：该命令标记字段为8个比特。已经分配的比特位如下：0 1 2 3 4 5 6 7+-+-+-+-+-+-+-+-+|R P E T r r r r|+-+-+-+-+-+-+-+-+n R(equest) -如果设置，
23、表明该消息是一个请求。如果清零，该消息是一个应答。n P(roxiable) 如果设置，表明该消息可以被Proxy、中继或者重定向。如果清零，该消息必须在本地处理。n E(rror) -如果设置，表明该消息包含一个协议差错，且该消息与ABNF中描述的该命令不一致。“E”比特设置的消息一般当作差错消息。在请求消息中不能设置该比特。n T(Potentially re-transmitted message)-该标记在链路失败过程后被设置，以帮助去除重复的请求。当重发请求还没有被确认时，需要设置该比特，以作为链路失败而造成的可能的重复包的指示。当第一次发送一个请求时，该比特必须被清零，否则发送者必
24、须设置该比特。Diameter代理仅需要关心它们发送的同一请求消息的遍数；其他实体进行的重传不须考虑。Diameter代理接收到一个T比特设置为1的请求，必须在前转该请求时保持T标记的设置。如果接收到一个以前消息的差错消息（例如协议差错），则不可以设置该标记。该标记只有在没有接收到任何来自服务器的该请求的应答、且该请求再次被发送的情况下，才能被设置。该标记不能在应答消息中设置。n r(eserved) -这些标记比特为将来使用预留，必须设置为0，接收者应当忽略。 Command-Code：该命令码字段为3个八位组，用于表明与该消息相关联的命令。该24位地址空间由IETF的IANA负责分配管理。
25、命令码值16，777，214和16，777，215（16进制的FFFFFEFFFFFF）被预留为实验使用。 Application-ID： 应用ID为4个八位组，用于标识该消息可适用于哪个应用。该应用可以是一个认证应用。头中的应用ID必须与该消息中包含的其他相关AVP相同。 Hop-by-Hop Identifier：Hop-by-Hop标识符为一个无符号32比特整数字段（按网络字节顺序），用来帮助匹配请求和响应。发送者必须保证请求中的Hop-by-Hop标识符在特定的连接上在任何特定的时间是唯一的，并且保证该数字在经过重启动后仍然唯一。应答消息的发送者必须确保Hop-by-Hop标识符字段维
26、持与相应的请求相同的值。Hop-by-Hop标识符通常是单调升序的数字，其开始值是随机生成的。一个带有未知Hop-by-Hop标识符的应答消息必须被丢弃。 End-to-End Identifier：端到端标识符是一个无符号32比特整数字段（按网络字节顺序），用来检测重复消息。重启动实施可以设置高位12比特为包含当前时间的低位12比特，低位20比特为随机值。请求消息的发送者必须为每一个消息插入一个唯一的标识符。该标识符必须维持本地唯一至少4分钟，即使经过重启动。应答消息的生成者必须确保该端到端标识符字段包含与相应的请求相同的值。端到端标识符不可以被Diameter代理以任何原因修改。源主机AV
27、P和该字段的结合可以用于检测重复。重复请求会造成相同应答的传输，并且不可以影响任何状态的设置，当处理原始请求时。应当在本地被消除的重复的应答消息将会被忽略。 AVPs： AVP是封装与Diameter消息相关信息的一种方法,参见4.2.3节。4.2.2. 消息列表 表4-1 消息列表命令名缩写命令码参考Credit-Control-RequestCCR2725.1Credit-Control-AnswerCCA2725.2Re-Auth-RequestRAR2585.3Re-Auth-AnswerRAA2585.4Abort-Session-RequestASR2745.5Abort-Sess
28、ion-AnswerASA2745.6Device-Watchdog-RequestDWR2805.7Device-Watchdog-AnswerDWA2805.8Disconnect-Peer-RequestDPR2825.9Disconnect-Peer-AnswerDPA2825.10Capabilities-Exchange-RequestCER2575.11Capabilities-Exchange-AnswerCEA2575.124.2.3. AVP头格式AVP中的字段必须按网络字节顺序发送。头的格式如图所示：0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4
29、 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-
30、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data . +-+-+-+-+-+-+-+-+图4.4 AVP头格式 AVP CodeAVP码与制造商ID 结合，可以唯一标识属性。AVP 1到255为前向兼容RADIUS预留，无需设置制造商ID字段。256以及大于256的AVP用于Diameter，由IANA负责分配。 AVP 标记AVP标记字段告知接收者如何处理每个属性。“r”（预留）比特不使用，应设置为0。表示以后的Diameter应用可以在AVP头中定义附加的比特，一个未被承认的比特应被看作差错。“P”比特
31、指明为保证端到端安全需要加密。“M”比特，称为强制比特，指明对该AVP的支持是否是必需的。如果Diameter客户、服务器、Proxy、或者翻译代理接收到一个AVP，其“M”比特设置为1，且该AVP或其值为未知，该消息必须被拒绝。Diameter 中继和重定向代理不可以拒绝带有未知AVP的消息。“M”比特清零的AVP仅是信息提示性的，接收者接收到其不支持的（包括不支持其值）“M”比特为零的AVP，可以简单忽略该AVP。“V”比特，称作制造商定义（Vendor-Specific）比特，指明在AVP头中是否出现可选的制造商ID字段。当设置时，该AVP码属于某特定制造商编码地址空间。除非另外注明，A
32、VP将拥有以下缺省AVP标记字段设置：“M”比特必须设置。“V”比特不可以设置。 制造商ID（Vendor-ID）如果在AVP标记字段中设置了“V”比特，则会出现制造商ID字段。可选的四个八位组的制造商ID字段包含IANA分配的“SMI网络管理私有企业码”值，按网络顺序编码。任何希望实现制造商定义（vendor-specific）Diameter的制造商必须使用它们自己的制造商ID，顺着它们的私有管理AVP地址空间，以保证它们与其他制造商的vendor-specific AVP 以及将来的IETF应用的AVP都不会冲突。制造商ID值为0符合IETF采用的AVP值，由IANA管理。由于制造商ID
33、字段缺失暗示该AVP不是制造商定义的，实施不可以使用值为0的制造商ID。该字段为可选字段，如果该AVP值为IETF所定义，则该字段不出现；如果该AVP值为3GPP所定义，则该值为10415；如果该AVP值为中国移动所定义，则该值为28357。 AVP LengthAVP长度字段为3个八位组，指明在这个AVP中的八位组的数量，能包括AVP码、AVP长度、AVP标记、Vendor-ID字段（如果出现）以及AVP数据。如果接收到一个消息，其带有无效属性长度，该消息应被拒绝。4.2.4. AVP数据格式数据字段为0到多个八位组，包含属性定义的信息。数据字段的格式和长度由AVP码和AVP长度字段决定。数
34、据字段的格式必须是以下基本数据类型中的一种。 OctetString该数据包含任意可变长的数据。除非另外注明，AVP长度字段必须至少设置为8（如果“V”比特有效，则为12）。这种类型的AVP值的长度如果不是4个八位组的倍数，应按照需要填充，这样下一个AVP（如果有）才能够在一个32比特边界开始。 Integer3232比特有符号值，按照网络字节顺序。AVP长度字段必须设置为12（如果“V”比特有效，则为16）。 Integer6464比特有符号值，按照网络字节顺序。AVP长度字段必须设置为16（如果“V”比特有效，则为20）。 Unsigned3232比特无符号值，按照网络字节顺序。AVP长度
35、字段必须设置为12（如果“V”比特有效，则为16）。 Unsigned6464比特无符号值，按照网络字节顺序。AVP长度字段必须设置为16（如果“V”比特有效，则为20）。 Float32该类型表示单精度浮点值，遵循IEEE标准754-1985中关于浮点的描述。该32比特值按网络字节顺序传送。AVP长度字段必须设置为12（如果“V”比特有效，则为16）。 Float64该类型表示双精度浮点值，遵循IEEE标准754-1985中关于浮点的描述。该64比特值按网络字节顺序传送。AVP长度字段必须设置为16（如果“V”比特有效，则为20）。 Grouped该数据字段定义为一个AVP序列。这些AVP按
36、其定义的顺序排列，每一个都包括它们的头和填充位。AVP长度字段值设置为8（如果“V”比特有效，则为12），加上所有序列内的AVP的长度总和。因此Grouped类型的AVP的AVP长度字段总是4的倍数。 Address地址格式是从OctetString AVP基本格式导出的。它与其他数据格式不同，例如需要区分32比特（IPV4）或128比特（IPV6）地址。地址AVP的头两个八位组为AddressType，其包含一个在IANA的“地址簇号码”中定义的地址簇。AddressType用来区别剩下八位组的内容和格式。 Time时间格式是从OctetString AVP基本格式导出的。该字符串必须包含4
37、个八位组，与NTP时间戳格式的前4个字节格式相同。NTP时间戳在NTP协议规范RFC2030第3章中定义。本格式描述的时间，从通用协调时间（UTC）1900年1月1日0点开始。在UTC时间2036年二月7日6点28分16秒，时间值将溢出。SNTP规范中描述了将时间扩展到2104年的程序，所有DIAMETER节点都必须支持该程序。 UTF8StringUTF8String格式是从OctetString AVP基本格式导出的。该格式是使用ISO/IEC IS 106461字符集表示的可读的字符串，使用RFC 2279中描述的UTF-8转换格式，编码为一个OctetString。 DiameterI
38、dentityDiameterIdentity格式是从OctetString AVP基本格式导出的。DiameterIdentity = FQDNDiameterIdentity值唯一标识一个Diameter节点，以用于重复连接和路由环路检测。字符串的内容必须是Diameter节点的FQDN。如果多个Diameter节点在同一台主机上运行，每个Diameter节点必须分配一个唯一的DiameterIdentity。如果一个Diameter节点可以由若干个FQDN标识，其中一个FQDN应在启动时被挑选出来，并作为该节点唯一的DiameterIdentity。 EnumeratedEnumerat
39、ed是从Integer32 AVP基本格式导出的。该定义包含一个有效值的列表及相关解释，并在引入该AVP的Diameter应用中有所描述。4.2.5. AVP编码原则为了保持与国际规范的一致性，只允许在Service-Information里面扩展参数，不允许在Service-Information之外扩展任何参数。对于中国移动定义的Service-Information，AVP代码为2xx00，如IN-information为20300，P2PSMS-Information 20400，DSMP-Information 20500。对于特定业务的参数，AVP代码为2xxyy，如IN-info
40、rmation里面的Calling-Vlr-Number为20302。原则上不能与RFC 3588、RFC 4006、3GPP 32.299有冲突，但对于历史遗留的一些参数则继续保留，如IN-information里面的Calling-Party-Address为603，在3GPP 32.299里面603为Server-Capabilities，因此必须用Vendor-ID加以区分。5. Diameter 协议命令集在以下的表述中，“”符号表示必选而且位置必须是在消息的开头，“”符号表示必选，“”符号表示可选，“*”符号表示可重复的可选项。M必选C条件可选OM运行商定义的必选项OC运营商定义的
41、条件可选项5.1. Credit-Control-Request (CCR)信用控制请求Credit-Control-Request (CCR)，用命令码设置为272，消息标志R设置来表示。该命令用于信用控制的请求。消息格式如下： := Origin-Host Origin-Realm Destination-Realm Auth-Application-Id Service-Context-Id CC-Request-Type CC-Request-Number Destination-Host User-Name Origin-State-Id Event-Timestamp * Subscription-Id Termination-Cause Requested-Service-Unit Requested-Action * Used-Service-Unit Multiple-Services-Indicator * Multiple-Services-Credit-Control CC-Correlation-Id User-Equipment-Info * Proxy-Info * Route-Record Service-Information * AVP 表5-1 Credit-Control-Request (CCR)AVP名称AVP代码Vendor-
