【YD通讯标准】 演进的移动分组核心网络(EPC)策略和计费控制系统计费接口技术要求

ICS33.060.99
中华人民共和国通信行业标准
YD/T2997-2016
演进的移动分组核心网络（EPC）策略和计费控制系统
计费接口技术要求
Technical requirements for PCC system charginginterfacesinevolvedpacketcorenetwork2016-01-15发布
2016-04-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件
缩略语·
Gy接口·
4.2Gy接口参考模型.
4.3Gy接口的PCC过程…
4.4Gy接口协议：
5Gz接口..·
5.1Gz接口功能
5.2离线计费话单产生机制
Gz接口协议
YD/T2997-2016
YD/T2997-2016
本标准是演进的移动分组核心网络策略和计费系列标准之一，该系列标准的结构和名称预计如下：a）YD/T2621《演进的移动分组核心网络（EPC）策略和计费规则功能设备技术要求》：b）YD/T2921《演进的移动分组核心网络（EPC）策略和计费规则功能设备测试方法》；c）YD/T2919《演进的移动分组核心网络（EPC）策略和计费执行功能设备/承载绑定和事件报告功能技术要求》：
d）YD/T2920《演进的移动分组核心网络（EPC）策略和计费执行功能设备/承载绑定和事件报告功能测试方法》；
e）YD/T2995《演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口技术要求》：f）YD/T2996《演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口测试方法》：g）YD/T2993《演进的移动分组核心网络（EPC）策略和计费控制系统Rx接口技术要求》；h）YD/T2994《演进的移动分组核心网络（EPC）策略和计费控制系统Rx接口测试方法》：i）YD/T2997《演进的移动分组核心网络（EPC）策略和计费控制系统计费接口技术要求》：j）YD/T2998《演进的移动分组核心网络（EPC）策略和计费控制系统计费接口测试方法》。本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、中国电信集团公司、中国移动通信集团公司、中国联合网络通信集团有限公司、华为技术有限公司、中兴通讯股份有限公司、上海贝尔股份有限公司、诺基亚西门子通信（上海）有限公司、南京爱立信熊猫通信有限公司、大唐电信科技产业集团、新邮通信设备有限公司、中国普天信息产业股份有限公司。本标准主要起草人：杨红梅、吴锦花、习建德、覃东、王剑、高功应、谢晓棠、严学强、魏彬TiiKAoNiKAca
YD/T2997-2016
演进的移动分组核心网络（EPC）策略和计费控制系统计费接口技术要求
1范围
本标准规定了策略和计费控制系统Gy接口（PCEF和OCS之间的接口）和Gz（PCEF和OFCS之间的接口）接口的技术要求，包括概述、接口定义、参考模型、接口协议等。本标准适用于支持采用演进的移动分组核心网络（EPC）架构的GERAN、UTRAN、e-UTRAN接入和cdma2000eHRPD接入的策略及计费执行功能（PCEF）、在线计费系统（OCS）、离线计费系统(OFCS)。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IECIS10646—1
3GPPTS23.203v9.5.0
3GPPTS29.060v9.7.0
3GPPTS29.212
3GPPTS32.240
3GPPTS32.299v9.7.0
IETFRFC2030
IETFRFC2279
IETFRFC3588
IETFRFC4006
3缩略语
下列缩略语适用于本文件：
信息技术-通用编码字符集(UCS）（Informationtechnology--UniversalCodedCharacterSet(UCS))
策略和计费控制体系架构（Policyandchargingcontrolarchitecture）通用分组数据业务：Gn和Gp接口的GPRS隧道协(GTP)(GeneralPacketRadioService (GPRS);GPRSTunnellingProtocol (GTP)acrossthe Gn and Gp interface)
策略和计费控制；参考点（PolicyandChargingControl(PCC)：Reference points)
电信管理、计费管理、计费架构和原理（Telecommunicationmanagement）Charging management; Charging architecture and principles)电信管理：计费管理：Diameter计费应用（Telecommunicationmanagement; Charging management Diameter charging applications)IPv4，IPv6和OSI的简单网络时间协议（SNTP）版本4（SimpleNetworkTimeProtocol (SNTP) Version 4forIPv4,IPv6and OSI)UTF-8,ISo10646的传送格式（UTF-8，atransformationformatofISO10646）基于Diameter的协议（DiameterBaseProtocol）Diameter信用控制应用（DiameterCredit-ControlApplication）ApplicationFunction
Charging Data Function
Charging Gateway Function
Closed Subscriber Group
应用功能
计费数据功能
计费网关功能
闭合用户群
iiKAoNiKAca
YD/T2997-2016
4Gy接口
4.1概述
Charging TriggerFunction
Multiple Service Credit ControlFlow Based Charging
Online charging system
Offline charging system
Policyand ChargingEnforcementFunctionPolicy and Charging Rule Function计费触发功能
多业务信用控制
基于流的计费
在线计费系统
离线计费系统
策略和计费执行功能
策略和计费规则功能
Gy接口用于PCEF和OCS交互信用控制请求和信用额度下发等在线计费相关信息，用于基于流的承载计费。该接口功能等同于Ro接口（见3GPPTS23.203和3GPPTS32.240）。4.2Gy接口参考模型
Gy接口位于PCEF和PCRF之间，该接口与相关功能实体的关系如图1所示用户属性存储器
策略和计费规则功能
(PCRF)
承载绑定和事
件报告功能
(BBERF)
4.3Gy接口的PCC过程
4.3.1Ro接口消息流程
策略和计费
执行功能
(PCEF)
在线计费系统（OCS)
基于业务数据流
的信用控制
PCC架构中的Gy接口
高线计费系统
(OFCS)
P-GW使用CCR（Credit-Control-Request）消息传递采集的计费信息给OCS。OCS使用CCA（Credit-Control-Answer）消息为不同的费率组传递配额信息给P-GW，并指示P-GW是否让IP-CAN承载上的业务数据流继续传输或者终止。CCA消息还用于指示PCEF执行终止操作类型，即当用户使用完授权配额后PCEF的操作，详见3GPPTS32.299。P-GW根据计费特征参数决定是否激活或者去激活在线计费。4.3.2IP-CAN计费相关信息的提供4.3.2.1提供计费地址信息
在PCC规则提供过程中，PCRF可以在Charging-InformationAVP中提供OCS的地址给PCEF，该地址将会覆盖PCEF中预定义的地址。OCS的主地址与次地址可同时提供。如果PCRF提供OCS地址时2
TiiKAoNiKAca
YD/T2997-2016
未提供需要在线计费的PCC规则，不应当作为错误处理，因为在线计费的PCC规则可能在后续提供。4.3.2.2提供缺省的计费模型
缺省计费模型用于指示对所有的PCC规则缺省使用的计费方式，即在线计费或者是离线计费。当PCC规则内不含计费模型时，将采用缺省计费模型进行计费。PCEF上可以预先配置缺省计费模型。在与PCRF的初始交互过程中，PCEF如果预配置了缺省计费模型，则PCEF通过在CCR消息中携带OnlineAVP或者OfflineAVP用于指明其预配置的缺省计费模型。在与PCEF的初始交互过程中，PCRF可以通过在CCA消息中的OnlineAVP或者OflineAVP提供缺省计费模型。PCRF提供的缺省计费模型将覆盖PCEF上预配置的缺省计费模型。4.3.2.3提供接入网计费标识
如果PCRF无Access-Network-Charging-Identifier-GxAVP信息时，PCRF可以请求PCEF提供PCC规则对应的Access-Network-Charging-Identifier-GxAVP。这种情况下，PCRF应提供值为CHARGING_CORRELATION_EXCHANGE（取值为28)的Event-TriggerAVP，同时Charging-Correlation-IndicatorAVP中指明CHARGINGIDENTIFIER_REQUIRED。如果PCEF收到CHARGINGCORRELATIONEXCHANGE（取值为28）的事件订阅，PCEF应将为动态PCC规则分配的接入网计费标识包含在Access-Network-Charging-Identifier-GxAVP中，同时设置Charging-Correlation-IndicatorAVP为CHARGING_IDENTIFIER_REQUIRED。4.3.2.4提供信用额度使用情况
PCRF可以向PCEF订阅信用额度事件。如果PCRF在CCA或者RAR消息中通过Event-TriggerAVP订阅了OUT_OF_CREDIT（取值为15)事件，PCEF需要在检测到不再能获得新的信用额度并且OCS已决定终结授信（会话也许还可以继续）时，将生成CCR消息用于通知PCRF该事件，在Charging-Rule-ReportAVP中指明受影响的PCC规则，同时在Final-Unit-IndicationAVP中指明相应终止动作类型，详见3GPPTS32.240和3GPPTS32.299。
如果PCRF在CCA或者RAR消息中通过Event-TriggerAVP订阅了REALLOCATION_OF_CREDIT（取值为16事件，PCEF不再能获得新的信用额度并且OCS已决定终结授信时，将生成CCR消息用于通知PCRF该事件，在Charging-Rule-ReportAVP中指明被重新分配信用额度的PCC规则详见3GPPTS32.240和3GPPTS32.299。
4.4Gy接口协议
4.4.1协议支持
目前，移动网络正逐步向全IP网络演进，不仅在核心网络使用支持IP的网络实体，在接入网络也使用基于IP的技术，而且移动终端也成为可激活的IP客户端。这就需要采用新一代的AAA协议Diameter。Diameter基础协议为各种认证、授权和计费业务提供了安全、可靠、易于扩展的框架。以此为基础定义Diameter应用，只需要定义应用协议的应用标识、参与通信的网络功能实体、相互通信的功能实体间的消息内容以及协议过程，就可以完全依赖Diameter基础协议完成特定的接入和应用业务。Diameter协议具有如下特性：
a）具有良好的网络适应性和可扩展性：b）统一且良好的失败控制和检测机制：c）完整的传送层安全保证（包括域内和域间)：d）数据传输可靠性保证机制：
e）支持各种类型的代理，包括Proxy代理、重定向代理以及中继代理等：3
HiiKAoNiKAca
YD/T2997-2016
f）支持服务器发起的消息，即允许服务器主动发送消息给其客户端：g）与现有网络协议的良好可互操作性：h）支持节点间的能力协商机制；i）支持动态对等端发现和配置机制：ji）支持安全和可扩展的漫游。Diameter包含基础协议、传送协议、不同的应用扩展，如：所有应用和服务共用的基本功能都在基础协议中实现，而应用特定的功能则会在不同的应用中实施。Diameter基础协议注重能力协商，消息发送以及对等端如何最终被拒绝。Diameter基础协议还规定了特定规则以用于Diameter节点之间所有的消息交换。Diameter基础协议旨在提供一个AAA框架，以用于各种应用。基础协议还定义了所有Diameter应用使用的，并且所有Diameter设备都必须支持的消息格式、传输、差错报告和安全服务等机制。在Diameter基础协议上扩展的应用协议，定义了针对预付费用户的计费机制，采用信用额度控制实现了基于会话及事件的计费，解决了对于预付费的计费需求。移动分组域通信网络Gy应用的协议基础是IETFRFC4006和3GPPTS32.299。GyDiameter应用标识设置为4。IANA将3GPP厂商标识设置为10415，详情可参考IANA网站（网址http://iana.org/assignments/enterprise-numbers)。4.4.2协议结构
遵循Diameter基础协议，DCCA协议是在Diameter基础协议之上，根据数据业务在线计费的具体需求，进行信用控制的应用层协议，协议结构见表1。表1DCCA协议的协议结构
DiameterCredit Control ApplicationDiameter Base
4.4.3协议格式
4.4.3.1消息头格式
IP/IPsec
DCCA协议的消息结构如图2所示，这些字段是以网络字节顺序传送的。0
01234567890123456789012345678901Version
I command flags
Message Length
Command-Cod
Application-ID
Hop-by-op Identifier
End-to-End Identifier
图2消息头格式
HiiKANiKAca
关键字段说明如下：
a）Version：该版本字段应被置为1，表明Diameter版本1。YD/T2997-2016
b）MessageLength：该消息长度字段为3个八位组，指明该Diameter消息的字节长度，包括头字段。c）Commandflags：该命令标记字段为8个比特。已经分配的比特位如图3所示。01234567
+-+-+-+-+-+-+-+-+
IRPETrrrr
++++-+-+-+-+-+
图3Commandflags格式
1）R(equest)-如果设置，表明该消息是一个请求。如果清零，该消息是一个应答。2）P(roxiable)-如果设置，表明该消息可以被Proxy、中继或者重定向。如果清零，该消息应在本地处理。
3）E(rror）-如果设置，表明该消息包含一个协议差错，且该消息与ABNF中描述的该命令不一致。“E”比特设置的消息一般当作差错消息。在请求消息中不能设置该比特。4）T(Potentiallyre-transmittedmessage)-该标记在链路失败过程后被设置，以帮助去除重复的请求。当重发请求还没有被确认时，需要设置该比特，以作为链路失败而造成的可能的重复包的指示。当第一次发送一个请求时，该比特应被清零，否则发送者应设置该比特。Diameter代理仅需要关心它们发送的司一一请求消息的遍数：其他实体进行的重传不须考患。Diameter代理接收到一个T比特设置为1的请求应在前转该请求时保持T标记的设置。如果接收到一个以前消息的差错消息（例如协议差错），则不可以设置该标记。该标记只有在没有接收到任何来自服务器的该请求的应答、且该请求再次被发送的情况下，才能被设置。该标记不能在应答消息中设置。5）r(eserved)-这些标记比特为将来使用预留，应设置为0，接收者应当忽略。d）Command-Code：该命令码字段为3个八位组，用于表明与该消息相关联的命令。该24位地址空间由IETF的IANA负责分配管理。命令码值16、777、214和16、777、215（16进制的FFFFFE一FFFFFF）被预留为实验使用。
e）Application-ID：应用ID为4个八位组，用于标识该消息可适用于哪个应用。该应用可以是一个认证应用。头中的应用ID应与该消息中包含的其他相关AVP相同。f）Hop-by-HopIdentifier：Hop-by-Hop标识符为一个无符号32比特整数字段（按网络字节顺序），用来帮助匹配请求和响应。发送者应保证请求中的Hop-by-Hop标识符在特定的连接上在任何特定的时间是唯一的，并且保证该数字在经过重启后仍然唯一。应答消息的发送者应确保Hop-by-Hop标识符字段维持与相应的请求相同的值。Hop-by-Hop标识符通常是单调升序的数字，其开始值是随机生成的。个带有未知Hop-by-Hop标识符的应答消息应被丢弃。g）End-to-EndIdentifier：端到端标识符是一个无符号32比特整数字段（按网络字节顺序），用来检测重复消息。重启动实施可以设置高位12比特为包含当前时间的低位12比特，低位20比特为随机值，请求消息的发送者应为每一个消息插入一个唯一的标识符。该标识符应在一定时间内维持本地唯一，即使经过重启动。应答消息的生成者应确保该端到端标识符字段包含与相应的请求相同的值。端到端标识符不可以被Diameter代理以任何原因修改。源主机AVP和该字段的结合可以用于检测重复。重复请求5
HiiKANiKAca
YD/T2997-2016
会造成相同应答的传输，并且不可以影响任何状态的设置，当处理原始请求时。应当在本地被消除的重复的应答消息将会被忽略。
h）AVPs：AVP是封装与Diameter消息相关信息的一种方法。4.4.3.2消息列表
消息列表见表2。
表2消息列表
命令名
Credit-Control-Request
Credit-Control-Answer
Re-Auth-Request
Re-Auth-Answer
Abort-Session-Request
Abort-Session-Answer
Device-Watchdog-Request
Device-Watchdog-Answer
Disconnect-Peer-Request
Disconnect-Peer-Answer
Capabilities-Exchange-RequestCapabilities-Exchange-Answer4.4.3.3AVP头格式
AVP中的字段应按网络字节顺序发送。头的格式如图4所示。0
01234567890123456789012345678901AVPCode
IvMprrrrrl
关键字段说明如下：
a）AVPCode
AVPLength
Vendor-ID (opt)
图4AVP头格式
命令码
AVP码与制造商ID结合，可以唯一标识属性。AVP1到255为前向兼容RADIUS预留，无需设置制造商ID字段。256以及大于256的AVP用于Diameter，由IANA负责分配。b）AVP标记
AVP标记字段告知接收者如何处理每个属性。“”（预留）比特不使用，应设置为0。表示以后的Diameter应用可以在AVP头中定义附加的比特，一个未被承认的比特应被看作差错。“p”比特指明为保证端到端安全需要加密。
iiiKAoiKAca
YD/T2997-2016
“M”比特，称为必选比特，指明对该AVP的支持是否是必需的。如果Diameter客户、服务器、Proxy、或者翻译代理接收到一个AVP，其“M”比特设置为1，且该AVP或其值为未知，该消息应被拒绝。Diameter中继和重定向代理不可以拒绝带有未知AVP的消息。“M”比特清零的AVP仅是信息提示性的，接收者接收到其不支持的（包括不支持其值）“M”比特为零的AVP，可以简单忽略该AVP。“V”比特，称作制造商定义（Vendor-Specific）比特，指明在AVP头中是否出现可选的制造商ID字段。当设置时，该AVP码属于某特定制造商编码地址空间。除非另外注明，AVP将拥有以下缺省AVP标记字段设置：“M”比特应置位。“V”比特不能置位。c）制造商ID（Vendor-ID）
如果在AVP标记字段中设置了“V”比特，则会出现制造商ID字段。可选的四个八位组的制造商ID字段包含IANA分配的“SMI网络管理私有企业码”值，按网络顺序编码。任何希望实现制造商定义Diameter的制造商应使用它们自已的制造商ID，顺着它们的私有管理AVP地址空间，以保证它们与其他制造商的vendor-specificAVP以及将来的IETF应用的AVP都不会冲突。制造商ID值为O符合ETF采用的AVP值，由IANA管理。由于制造商ID字段缺失暗示该AVP不是制造商定义的，实施不可以使用值为0的制造商ID。该字段为可选字段，如果该AVP值为IETF所定义，则该字段不出现；如果该AVP值为3GPP所定义，则该值为10415。
d)AVPLength
AVP长度字段为3个八位组，指明在这个AVP中的八位组的数量，能包括AVP码、AVP长度、AVP标记、Vendor-ID字段（如果出现）以及AVP数据。如果接收到一个消息，其带有无效属性长度，该消息应被拒绝。
4.4.3.4AVP数据格式
数据字段为0到多个八位组，包含属性定义的信息。数据字段的格式和长度由AVP码和AVP长度字段决定。数据字段的格式应是以下基本数据类型中的一种：a）OctetString
该数据包含任意可变长的数据。除非另外注明，AVP长度字段应至少设置为8（如果“V”比特有效则为12）。这种类型的AVP值的长度如果不是4个八位组的倍数，应按照需要填充，这样下一个AVP（如果有）才能够在一个32比特边界开始。b）Integer32
32比特有符号值，按照网络字节顺序。AVP长度字段应设置为12（如果“V”比特有效，则为16）。c）Integer64
64比特有符号值，按照网络字节顺序。AVP长度字段应设置为16（如果“V”比特有效，则为20）。d）Unsigned32
32比特无符号值，按照网络字节顺序。AVP长度字段应设置为12（如果“V”比特有效，则为16）。e）Unsigned64
64比特无符号值，按照网络字节顺序。AVP长度字段应设置为16（如果“V”比特有效，则为20）。7
YD/T2997-2016
f)Float32
该类型表示单精度浮点值。该32比特值按网络字节顺序传送。AVP长度字段应设置为12（如果“V\比特有效，则为16)。
g）Float64
该类型表示双精度浮点值。该64比特值按网络字节顺序传送。AVP长度字段应设置为16（如果“V比特有效，则为20）。
h）Grouped
该数据字段定义为一个AVP序列。这些AVP按其定义的顺序排列，每一个都包括它们的头和填充位。AVP长度字段值设置为8（如果“V”比特有效，则为12），加上所有序列内的AVP的长度总和。因此Grouped类型的AVP的AVP长度字段总是4的倍数。i)Address
地址格式是从OctetStringAVP基本格式导出的。它与其他数据格式不同，例如需要区分32比特（IPV4）或128比特（IPV6）地址。地址AVP的头两个八位组为AddressType，其包含一个在IANA的“地址簇号码”中定义的地址族。AddressType用来区别剩下八位组的内容和格式。j)Time
时间格式是从OctetStringAVP基本格式导出的。该字符串应包含4个八位组，与NTP时间戳格式的前4个字节格式相同。NTP时间截在NTP协议规范IETFRFC2030第3章中定义。本格式描述的时间，从通用协调时间（UTC）1900年1月1日0点开始。在UTC时间2036年二月7日6点28分16秒，时间值将溢出。SNTP规范中描述了将时间扩展到2104年的程序，所有DIAMETER节点都应支持该程序。k）UTF8String
UTF8String格式是从OctetStringAVP基本格式导出的。该格式是使用ISO/IECIS10646一1字符集表示的可读的字符串，使用IETFRFC2279中描述的UTF-8转换格式，编码为一个OctetString。1) DiameterIdentity
Diameterldentity格式是从OctetStringAVP基本格式导出的。Diameterldentity=FQDN。
DiameterIdentity值唯一标识一个Diameter节点，以用于重复连接和路由环路检测。字符串的内容应是Diameter节点的FQDN。如果多个Diameter节点在同一台主机上运行，每个Diameter节点应分配一个唯一的DiameterIdentity。如果一个Diameter节点可以由若干个FQDN标识，其中一个FQDN应在启动时被挑选出来，并作为该节点唯一的Diameterldentity。m)Enumerated
Enumerated是从Integer32AVP基本格式导出的。该定义包含一个有效值的列表及相关解释，并在引入该AVP的Diameter应用中有所描述。4.4.4Gy应用AVP定义
Gy应用的AVP来自于IETFRFC3588和IETFRFC4006，以及3GPPTS32.299。4.4.4.1IETF定义的AVP
IETFAVP定义的具体内容见表3。8
AVP名称
Acct-Application-Id
Auth-Application-Id
Called-Station-Id
CC-Input-Octets
cC-Money
CC-Output-Octets
CC-Request-Number
CC-Request-Type
CC-Service-Specific-Units
CC-Session-Failover
CC-Time
CC-Total-Octets
CC-Unit-Type
Credit-Control-Failure-HandlingCurrency-Code
Destination-Host
Destination-Realm
Direct-Debiting-Failure-HandlingEvent-Timestamp
Exponent
Failed-AVP
Filter-Id
Final-Unit-Action
Final-Unit-Indication
Granted-Service-Unit
G-S-U-Pool-Identifier
G-S-U-Pool-Reference
Multiple-Services-Credit-ControlMultiple-Services-Indicator
Origin-Host
Origin-RealmwwW.bzxz.Net
Origin-State-Id
Proxy-Info
Proxy-Host
Proxy-State
Rating-Group
Redirect-Address-Type
Redirect-Server
Redirect-Server-Address
Requested-Action
表3IETFAVP定义
取值类型
Unsigned32
Unsigned32
UTF8String
Unsigned64
Grouped
Unsigned64
Unsigned32
Enumerated
Unsigned64
Enumerated
Unsigned32
Unsigned64
Enumerated
Enumerated
Unsigned32
DiamIdent
DiamIdent
Enumerated
Integer32
Grouped
UTF8String
Enumerated
Grouped
Grouped
Unsigned32
Grouped
Grouped
Enumerated
Diamldent
DiamIdent
Unsigned32
Grouped
Diamldent
OctetString
Unsigned32
Enumerated
Grouped
UTF8String
Enumerated
AVP标志规则
YD/T2997-2016
可能加密
可以不应
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。