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

ICS33.060.99
中华人民共和国通信行业标准
YD/T2993-2016
演进的移动分组核心网络（EPC）策略和计费控制系统Rx接口技术要求Technical requirementsforPCCsystem Rx interfaces inevolvedpacketcorenetwork
2016-01-15发布
2016-04-01实施
中华人民共和国工业和信息化部发布前言·
1范围·
2规范性引用文件：
3缩略语·
4Rx接口概述·
4.2Rx接口参考模型.
功能实体·
4.4Rx接口的PCC过程
5Rx接口协议
协议支持：
会话与连接的初始化、保持和终止5.2
5.3Rx特定AVP描述
5.4Rx重用AVP描述·
5.5Rx专有Experimental-Result-CodeAVP的取值5.6Rx接口消息
YD/T2993-2016
YD/T2993-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给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、中国电信集团公司、中国移动通信集团公司、中国联合网络通信集团有限公司、华为技术有限公司、中兴通讯股份有限公司、上海贝尔股份有限公司、诺基亚西门子通信（上海）有限公司、南京爱立信熊猫通信有限公司、大唐电信科技产业集团、新邮通信设备有限公司、中国普天信息产业股份有限公司。本标准主要起草人：杨红梅、吴锦花、习建德、覃东、王、剑、高功应、谢晓棠、严学强、魏彬。HTiKAoNiKAca
YD/T2993-2016
演进的移动分组核心网络（EPC）策略和计费控制系统Rx接口技术要求
1范围
本标准规定了策略和计费控制系统Rx接口（AF和PCRF之间的接口）的技术要求，包括协议概述、接口定义、Rx接口的PCC过程、Rx接口协议等。本标准适用于支持采用演进的移动分组核心网络（EPC）架构的GERAN、UTRAN、e-UTRAN接入和cdma2000eHRPD接入的策略和计费规则功能（PCRF）、应用功能（AF）设备。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。YD/T2995
3GPPTS29.212
3GPPTS29.213
3GPPTS29.214(v9.5.0)
3GPPTS29.229
IETFRFC3162
IETFRFC3264
IETFRFC3556
IETFRFC3588
IETFRFC4005
IETFRFC4566
3缩略语
下列缩略语适用于本文件。
IP-CAN
演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口技术要求
策略和计费控制Gx接口（PolicyandchargingcontroloverGxreferencepoint)
策略和计费控制信令流程和QoS参数映射（Policyandchargingcontrolsignalling flows and Quality of Service (QoS)parameter mapping)策略和计费控制Rx接（PolicyandchargingcontroloverRxreferencepoint)
基于Diameter协议的Cx和Dx接口协议细节（CxandDxinterfacesbased on the Diameter protocol;Protocol details)RADIUS和IPv6（RADIUSandIPv6）SDP提供/应答模型（AnOffer/AnswerModelwithSessionDescriptionProtocol）
RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽调整（SessionDescription Protocol (SDP) Bandwidth ModifiersControlProtocol(RTCP)Bandwidth)Diameter基本协议（DiameterBaseProtocol）forRTP
Diameter网络接入服务器应用（DiameterNetworkAccessServerApplication）
会话描述协议（SDP：SessionDescriptionProtocol）Application Function
IP Connectivity Access Network应用功能
IP连接性接入网络
HiKAoNiKAca
YD/T2993-2016
P-CSCF
4Rx接口概述
4.1概述
Policy and Charging Control
PolicyandChargingEnforcementFunctionPolicyandChargingRuleFunctionPolicy Decision Function
Proxy-Call SessionControlFunctionQualityof Service
Service Data Flow
Subscriber Profile RepositoryUser Equipment
策略和计费控制
策略和计费执行功能
策略和计费规则功能
策略决策功能
代理呼叫会话控制功能
服务质量
业务数据流
用户属性存储
用户设备
Rx接口用于在PCRF和AF之间交换应用层会话信息。这些信息作为PCRF策略决策的部分输入信息用于策略决策。
Rx接口相关的信令流处理按3GPPTS29.213的描述执行。4.2Rx接口参考模型
Rx接口位于PCRF和AF之间，该接口与相关功能实体的关系如图1所述。用户属性存储器
策略和计费规则功能
(PCRF)
策略和计费
承载绑定和事
件报告功能
(BBERF)
4.3功能实体
执行功能
(PCEF)
！在线计费系统(OCS)
基于业务数据流
的信用控制
图1PCC架构中的Rx接口
高线计费系统
(OFCS)
AF是一个网络功能实体，可以为应用向网络侧申请资源，这些应用一般都需要使用PCC进行动态策略和计费控制。对于IMS业务而言，AF为P-CSCF：对于第三方业务，AF可由运营商提供或由第三方应2
HiikAoNiKAca
YD/T2993-2016
用提供。AF应使用Rx接口把会话信息交互到PCRF。AF还与PCRF交互以便接收具体IP-CAN的信息和IP-CAN承载级事件的通知。
4.3.2PCRF
PCRF包含策略控制决策和基于流计费控制的功能，向PCEF提供关于业务数据流检测、门控、QoS和基于流计费（除信用管理外）的网络控制功能。PCRF从AF接收应用信息并在特定事件发生时通知AF。
PCRF通过AF传递过来的业务信息和运营商定义的策略规则，映射出该业务的QoS。PCRF可以拒绝AF传递的业务信息，但在PCRF给AF的应答中，需提供PCRF可以接收的业务信息。PCRF可以基于用户的签约数据进行策略和计费控制的决策，签约数据可适用于有会话或者无会话的业务，每个业务的签约数据包含QoS级别和MBR等参数。PCRF对于PCC/QoS的决策可以基于下面一个或多个输入：·从Rx接口获得的会话以及媒体相关信息：●从Gx/Gxa接口获得的承载以及用户相关信息：·通过配置或者Sp接口获得的用户签约以及业务相关数据：·PCRF上预配置的信息。
PCRF应把PCC/QoS规则通过Gx/Gxa接口配置到PCEF/BBERF。4.4Rx接口的PCC过程
4.4.1会话信息初始提供
AF发起AA-Request消息，在AF和PCRF之间建立一个RxDiameter会话，消息中包括会话相关的媒体信息，PCRF根据这些媒体信息对其提供相应的PCC策略控制。AF在Framed-IP-AddressAVP或者Framed-IPv6-PrefixAVP中携带用户IP地址，在Media-Component-DescriptionAVP中携带业务信息。AF通过Media-Component-DescriptionAVP中的Flow-StatusAVP指示媒体流是否可以通过。注1：如果SDP有效载荷指示使用CS承载（即如3GPPTS24.292中描述，“c=”行和m”行置为“PSTN”），则AF不会和PCRF之间建立RxDiameter会话。注2：AF会话的RxDiameter会话和AF信令传输路径状态通知的RxDiameter会话是两条不同的会话。如果要进行信令传输路径状态通知，则需要为每一个新建的AF会话建立一个新的RxDiameter会话。AF通过AA-Request消息中的AF-Application-IdentifierAVP指明AF会话从属的特定业务。此AVP既可以是AA-Request消息的命令级参数，也可以包含在Media-Component-DescriptionAVP中，如果两处都有则Media-Component-DescriptionAVP中的值具有较高优先级。为计费目的，AF可以在AA-Request消息中包含AF-Charging-IdentifierAVP。此外，AF还可以在AA-Request消息中包含Specific-ActionAVP，用来请求承载面事件的上报，例如承载终止事件。对于紧急业务，AA-Request消息中会包含Service-URNAVP。如果PCRF收到Service-URNAVP，则执行紧急业务特定的控制策略，例如，提高AF会话中业务流的优先级或者对这些业务流免费。如果AF提供的业务信息是完全协商好的信息（例如是基于SDPanswer的信息），则AF置Service-Info-StatusAVP为FINAL_SERVICEINFORMATION。在这种情况下，PCRF对会话进行授权并向PCEF/BBERF下发相应的PCC/QoS规则。HiiKAoNiKAca
YD/T2993-2016
如果AF提供的业务信息是未协商好的信息，则AF置Service-Info-StatusAVP为PRELIMINARYSERVICEINFORMATION。PCRF收到未协商好的业务信息时，会对会话进行一个早期的授权检测。对于GPRS，在没有来自PCEF的PCC规则请求时，PCRF不会主动向PCEF下发PCC规则。PCRF仅在收到PCEF请求时，才会向PCEF下发相应的PCC规则。当PCRF收到一条AF发送的初始AA-Request消息后，要进行会话绑定，详见3GPPTS29.213。为了使PCRF将该AA-Request消息与相应的IP-CAN会话关联起来，AA-Request消息中需要携带Framed-IP-AddressAVP或者Framed-IPv6-PrefixAVP。如果请求消息中携带的是私有IP，且AF能获取到PDN信息的话，将PDN信息包含在Called-Station-IDAVP中。如果PCRF会话绑定失败，则置AA-Answer消息中Experimental-Result-CodeAVP为IP-CANSESSIONNOT_AVAILABLE，详见3GPPTS29.213。PCRF收到请求消息后，保存消息中Media-Component-DescriptionAVP包含的业务信息。然后，根据运营商策略处理业务信息，并决定是否接受该请求。PCRF在做决策时，需要同时考虑请求消息中Reservation-PriorityAVP所携带的优先级信息。如果AA-Request消息中携带的业务信息被拒绝（例如，用户使用带宽超出签约的保证带宽），PCRF在AA-Answer消息中的Experimental-Result-CodeAVP中携带拒绝原因REQUESTEDSERVICENOTAUTHORIZED，同时，PCRF在Acceptable-Service-InfoAVP中携带充许的带宽。
为了使得PCRF和PCEF对AA-Request消息中的IP流执行PCC规则授权以及承载绑定，AF要将获取到的源地址/源端口和目的地址/目的端口信息通过Flow-DescriptionAVP发送给PCRF。Reservation-PriorityAVP即可以包含在AA-Request消息的命令级，也可以包含在media-component-descriptionAVP级。如果在命令级，则表示AF会话的优先级；如果在AVP级，则表示相应媒体流对应IP流的优先级。如果两个级别均包含Reservation-PriorityAVP，并不矛盾，此时命令级的Reservation-PriorityAVP表示AF会话的优先级，而media-component-descriptionAVP级的Reservation-PriorityAVP表示在AF会话中此媒体流对应IP流的优先级。如果请求消息中未带Reservation-PriorityAVP，则优先级为缺省值DEFAULT(O)。AF可以通过AA-Request消息中的Specific-ActionAVP规定希望PCRF通知的事件。PCRF要确保当这些事件发生时，通知给AF。
PCRF收到AA-Request消息后，需要确定其中业务信息对应的PCC/QoS规则是否已经授权/下发。如果没有，需要按照YD/T2995《演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口技术要求》中描述的过程进行授权/下发。PCRF收到AA-Request消息后，向AF回应AA-Answer消息进行响应。该响应消息的发送可以先于或并行于PCC规则的授权/下发过程。如果此时能获取到接入网计费信息，PCRF在响应消息中包含Access-Network-Charging-Identifier和Access-Network-Charging-AddressAVP。如果此时能获取到IP-CAN类型，响应消息还应包含IP-CAN-TyPeAVP。在特定IP-CAN类型的情况下（例如IP-CAN类型为3GPP），响应消息还需要携带RAT-TypeAVP。如果PCRF在发送AA-Answer消息之前想要终止Rx会话，需先发送AA-Answer消息进行响应，然后再发起AS-Request消息请求终止Rx会话。当AF没有收到AA-Answer响应或者收到时等待的内部定时器已经超时，或者AA-Answer响应指示了非DLAMETER_SUCCESS时，AF的处理依赖于运营商的策略，不在本标准的范围内。HiiKAoNiKAca
4.4.2会话信息修改
YD/T2993-2016
AF可以随时（例如由于AF会话修改或者AF内部触发器触发）发送AA-Request消息修改会话信息。在Media-Component-DescriptionAVP中包含更新的业务信息。AF只能在收到前一个AA-Request消息的响应后才可以再发起一个AA-Request消息。如果AF提供的业务信息是完全协商好的信息（例如是基于SDPanswer的信息），则AF置Service-Info-StatusAVP为FINALSERVICE_INFORMATION。在这种情况下，PCRF对会话进行授权并向PCEF/BBERF下发相应的PCC/QoS规则。如果AF提供的业务信息是未协商好的信息（例如是基于SDPoffer的信息），则AF置Service-Info-StatusAVP为PRELIMINARY_SERVICE_INFORMATION。PCRF收到未协商好的业务信息时，会对会话进行一个早期的授权检测。对于GPRS，在没有来自PCEF的PCC规则请求时，PCRF不会主动向PCEF下发PCC规则。PCRF仅在收到PCEF请求时，才会向PCEF下发相应的PCC规则。PCRF根据运营商策略处理接收到的业务信息，并决定是否接受该请求。如果拒绝AA-Request消息中的业务信息（例如，用户使用带宽超出签约的保证带宽），则PCRF在AA-AnsWer响应消息中的Experimental-Result-CodeAVP中携带拒绝原因REQUESTED_SERVICENOT_AUTHORIZED，同时，PCRF在Acceptable-Service-InfoAVP中携带允许的带宽。如果接受AA-Request消息中的业务信息，PCRF更新保存的业务信息，并根据业务信息需要新建、修改或者删除PCC规则，或者更新受影响的IP-CAN承载的授权Qos，过程见YD/TXXXX《演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口技术要求》。
PCRF收到AA-Request消息后，向AF回应AA-Answer消息进行响应。该响应消息的发送可以先于或并行于PCC规则的授权/下发过程。如果此时能获取到接入网计费信息并且相关信息还未发送给AF，则PCRF要在响应消息中包含Access-Network-Charging-ldentifier和Access-Network-Charging-AddressAVP。如果此时能获取到IP-CAN类型并且此信息还未发送给AF，响应消息中还应包含IP-CAN-TypeAVP。此外，在特定IP-CAN类型的情况下（例如IP-CAN类型为3GPP），响应消息还需要携带RAT-TypeAVP。如果PCRF在发送AA-Answer消息之前想要终止Rx会话，需先发送AA-Answer消息进行响应，然后再发起AS-Request消息请求终止Rx会话。4.4.3门控过程
AF可以指示PCRF允许或禁止应用对应的IP流在IP-CAN上的传输。为完成该门控功能，AF向PCRF发送AA-Request消息，消息中携带Media-Component-DescriptionAVP，该AVP中包含的Flow-StatusAVP用来指示是否允许媒体流对应的IP流在IP-CAN上传输。PCRF收到请求后，需要对相应激活的PCC规则设置相应的门控状态。在Media-Component-DescriptionAVP中的Media-Sub-ComponentAVP中包含Flow-UsageAVP，如果该AVP取值为RTCP，则无论Media-Sub-ComponentAVP中的Flow-StatusAVP取什么值，该媒体子成分对应的IP流在上下行都不受限制。PCRF向AF回AA-Answer消息进行响应，并在响应消息中携带Access-Network-Charging-IdentifienAVP。PCRF按照AF指示进行相应的门控处理。当AF没有收到AA-Answer响应或者收到时等待的内部定时器已经超时，或者AA-Answer响应指示了非DIAMETERSUCCESS时，AF的处理依赖于运营商的策略，不在本标准的范围内。S
HiiKAoiKAca
YD/T2993-2016
PCRF根据请求消息中更新的业务信息对已有的PCC/QoS规则进行修改。在修改过程中，如果由于资源分配失败导致规则修改失败时，并且此时AF订阅了INDICATION_OFFAILED_RESOURCESALLOCATION承载面事件，则PCRF向AF发送RA-Request消息，消息中的Specific-ActionAVP置为INDICATION_OF_FAILEDRESOURCES_ALLOCATION。AF向PCRF回RA-AnSWer消息进行响应。4.4.4AF会话终止
当要终止AF会话时，AF向PCRF发送ST-Request消息。AF在发送ST-Request消息之前，需要判断是否已经收到初始AA-Answer消息，如果没有收到，AF要等收到初始AA-Answer消息后才可以发起ST-Request消息终止AF会话。
PCRF收到AF发送的终止会话的ST-Request消息后，向AF回应ST-Answer进行响应。然后，PCRF释放相应业务信息流对应的资源。按照YD/T2995《演进的移动分组核心网络（EPC）策略和计费控制系统Gx/Gxa接口技术要求》所述，PCRF进行相关PCC/QoS规则的删除、对受影响的IP-CAN承载的授权QoS进行更新。
4.4.5信令路径状态订阅
AF可以订阅AF信令路径状态通知事件。为此，AF向PCRF发送一个AA-Request消息，为AF信令建立一个RxDiameter会话。在请求消息中需要包括用户IP地址（Framed-IP-AddressAVP或者Framed-IPv6-PrefixAVP）和Specific-ActionAVP（需订阅\INDICATION_OF_LOSS_OF_BEARER和/或“INDICATION_OF_RELEASE_OF_BEARER\事件）。AF还要在请求消息中包含Media-Component-DescriptionAVP，在此AVP中包含一个Media-Sub-ComponentAVP，其中的Flow-UsageAVP置为\AF_SIGNALLING\，Media-Component-DescriptionAVP中的Media-Component-NumberAVP置为0。如果未使用4.4.6描述的过程，AF需要置AA-Request消息中Media-Sub-ComponentAVP中的Flow-NumberAVP为o，Media-Component-DescriptionAVP和Media-Sub-ComponentAVP中其他的AVP不使用。
PCRF接收到AF发送的AA-Request消息后，按照TS29.213中所述过程进行会话绑定，并向AF回AA-Answer消息进行确认。
AF可以随时取消AF信令路径状态的通知事件。此时，AF向PCRF发送ST-Request消息，PCRF向AF回sT-Answer进行确认。
4.4.6AF信令流信息的提供
AF可以向PCRF提供AF信令的流信息。如果AF与PCRF之间已经存在与该AF信令相关的RxDiameter会话，则AF使用已有的RxDiameter会话（例如，如果AF向PCRF订阅信令路径状态通知事件，则会建立一条与AF信令相关的RxDiameter会话）：如果不存在与该AF信令相关的RxDiameter会话，则需要重新建立一条Rx会话。如果使用已有的Rx会话，则需要对已有的会话信息进行修改。为了提供AF信令的流信息，AF在AA-Request消息中包含用户的IP地址（使用Framed-IP-AddressAVP或者Framed-IPv6-PrefixAVP）。此外，还包括Media-Component-DescriptionAVP，此AVP中包含一个或多个Media-Sub-ComponentAVP来描述AF信令的IP流信息。Media-Component-DescriptionAVP中的Media-Component-NumberAVP置为0。与AF信令相关的每一条IP流的信息通过一个Media-Sub-ComponentAVP来描述，该AVP中包含Flow-NumberAVP和一或两个Flow-DescriptionAVP。Media-Sub-6
HiKAoNiKAca
YD/T2993-2016
ComponentAVP中的Flow-UsageAVP置为\AF_SIGNALLING\，Flow-Status AVP置为\ENABLED\，AF-Signalling-ProtocolAVP置为UE和AF之间信令协议的类型。PCRF收到AF发送的AA-Request消息后，按照3GPPTS29.213中所述过程进行会话绑定，并向AF回AA-Answer消息进行响应。
PCRF在早期，例如在AF信令的IP-CAN承载建立的过程中，已经把与AF信令相关的PCC/QoS规则下发给了PCEF/BBERF。PCRF在收到AF提供的与信令相关的流信息时，要进行动态PCC/QoS规则的安装。AF可以随时取消AF信令流信息的提供。要取消时，AF发起ST-Request消息关闭RxDiameter会话，PCRF回ST-Answer响应消息。
4.4.7承载面事件
IP-CAN会话终止
当IP-CAN会话终止时，对于每一条与此IP-CAN会话关联的Rx会话，PCRF要向AF发起AS-Request消息，请求终止Rx会话。
AF收到AS-Request消息后，向PCRF回AS-Answer消息进行响应。之后，AF发起ST-Request消息，终止Rx会话，PCRF回应ST-Answer消息进行会话终止确认。IP-CAN会话终止的信令流程详见3GPPTS29.213所述。4.4.7.1业务数据流（SDF）去激活在PCEF/BBERF上，PCC/QoS规则（即业务数据流）可能暂时或者永久地被去激活。PCRF如果收到业务数据流去激活的指示（例如，由于承载释放、承载丢失或者信用额度不足引起的业务数据流去激活），并且AF前期订阅了相关事件通知（通过AAR消息中的Specific-ActionAVP订阅），则PCRF向AF通知相关事件。
在一条AF会话中，当并非所有的业务数据流都去激活时，PCRF向AF发送RA-Request消息。消息中，在FlowsAVP包含去激活的IP流信息，在Specific-ActionAVP中包含去激活原因。AF收到RA-Request消息后，向PCRF回RA-Answer消息进行响应。AF可以通过AA-Request消息更新会话信息。
如果AF收到AA-Request消息，向PCRF回应AA-Answer消息进行响应。当一条AF会话中所有的业务数据流都去激活时，PCRF向AF发送AS-Request消息。当AF接收到AS-Request消息时，使用AA-Answer消息进行响应。之后，AF发起RxDiameter会话终止过程，如4.4.4所述。
业务数据流激活的信令流程如3GPPTS29.213所述。4.4.7.2信令路径状态通知
当PCEF/BBERF向PCRF上报资源丢失或释放事件时，如果携带的PCC/QoS规则对应的是AF信令流，则PCRF向AF发送RAR消息通知信令传输路径丢失。RAR消息中包含Specific-ActionAVP，该AVP置为\INDICATION_OFLOSS_OFBEARER\或“INDICATION_OF_RELEASE_OFBEARER\，消息中还包括FloWsAVP，该AVP指示去激活的IP流信息。说明：如果IMS信令对应的PCC规则包含的QCI对应nOn-GBR承载，则不会上报INDICATIONOFLOSSOFBEARER事件。当AF接收到RAR消息后，向PCRF回RAA消息进行响应。YD/T2993-2016
AF在收到信令传输路径丢失的通知后，可以选择终止与AF信令相关的RxDiameter会话。AF还可以选择终止和该AF信令相关的其他RxDiameter会话。AF发起的RxDiameter会话终止过程如4.4.4所述4.4.7.3IP-CAN类型改变通知
如果AF成功订阅了用户IP-CAN类型以及RAT类型变化的事件通知，若发生了IP-CAN类型变化或者RAT类型变化（RAT类型变化仅用在IP-CAN类型为GPRS时）事件，PCRF向AF发送RAR消息通知此事件。RAR消息中的Specific-ActionAVP置为\IP-CANCHANGE\，另外在IP-CAN-TYPEAVP和RAT-TYPEAVP中带上变化后的IP-CAN类型和RAT类型（如果IP-CAN类型为GPRS时）。4.4.7.4接入网计费信息通知
AF向PCRF发送请求，订阅接入网计费信息通知事件，如果PCRF在收到请求时，已经获取到接入网计费信息，则在响应中包含相关信息：如果PCRF在收到请求时，还未获取到接入网计费信息，则在响应中不包含相关信息，后续从PCEF获取到相关信息时，通过RAR消息上报给AF。如果一个IP-CAN会话包含有不同接入网计费信息，PCRF要将每一条流的接入网计费信息通知给AF。RAR消息中的Specific-ActionAVP置为\CHARGING_CORRELATION_EXCHANGE\，消息中应包含Access-Network-Charging-IdentifierAVP，另外，还可以包含Access-Network-Charging-AddressAVP。5Rx接口协议
5.1协议支持
Rx应用为IETF中定义的厂商指定Diameter应用，厂商为3GPP，Rx应用ID为16777236。LANA分配给3GPP的厂商ID为10415（http://iana.org/assignments/enterprise-numbers）。说明：对于Diameter消息，基于消息中的应用ID，相同的路由入口会有不同的目的地。因此，DiameterAgents（即Diameter中继、Diameter代理，Diameter重定向器、Diameter协议转换器）应在Auth-Application-IdAVP中配置恰当的Rx应用ID，以便生成正确的路由表。根据Rx协议的使用原则，Vendor-Specific-Application-IdAVP是不能代替Auth-Application-IdAVP的。因此，要在Auth-Application-IdAVP中也包含Rx应用ID。在Rx接口协议中，PCRF作为Diameter服务器端，处理一个领域内AF会话的授权请求，AF作为Diameter客户端，发起AF会话资源的授权请求。5.2会话与连接的初始化、保持和终止AF和PCRF之间连接的初始化和保持在本标准中定义，Diameter节点间连接的建立和保持在IETFRFC3588中定义。
在AF与PCRF之间的传输连接建立后，PCRF和AF之间通过Diameter基础协议中的能力交换消息（Capabilities-Exchange-Request和Capabilities-Exchange-Answer）对Rx应用能力进行协商，具体通过Auth-Application-IdAVP和Vendor-Specific-Application-IdAVP中的Vendor-IdAVP实现。可参考IETFRFC3588。
Diameter用户会话的终止过程参考IETFRFC3588。Rx会话使用Diameter用户会话的终止过程来终止Rx会话。
5.3Rx特定AVP描述
5.3.1Rx特定AVP
YD/T2993-2016
表1描述了Rx接口规范中定义的DiameterAVP以及它们的AVP代码值、类型、可能的标识值、是否可加密，适用特性。本标准描述的所有AVP的Vendor-Id头域都应置为3GPP（10415）Rx特定AVP
AVP标识规则
属性名称
Abort-Cause
Access-Network-Charging-Add
Access-Network-Charging-Identifier
Access-Network-Charging-Identifier-Value
Acceptable-Service-Info
AF-Application-Identifier
AF-Charging-Identifier
Codec-Data
Flow-Description
Flow-Number
Flow-Status
Flow-Usage
Service-URN
Specific-Action
Max-Requested-Bandwidth-DLwwW.bzxz.Net
Max-Requested-Bandwidth-UL
Media-Component-Description
Media-Component-Number
Media-Sub-Component AVP
Media-Type
RR-Bandwidth
RS-Bandwidth
Service-Info-Status
SIP-Forking-Indication
AF-Signalling-Protocol
定义所在
类型b
Enumerated
Address
Grouped
OctetString
Grouped
OctetString
OctetString
OctetString
IPFilterRule
Unsigned32
Grouped
Enumerated
Enumerated
OctetString
Enumerated
Unsigned32
Unsigned32
Grouped
Unsigned32
Grouped
Enumerated
Unsigned32
Unsigned32
Enumerated
Enumerated
Enumerated
可能不
适用特性。
ProvAFsignalFlow
AVP头中的\M\的标识，指明对该AVP的支持是否是必须的。AVP头中的V\标识，指明AVP中是否出现可选的Vendor-ID域。详情见IETFRFC3588。类型定义参考IETFRFC3588。
“ProvAFsignalFlow\AVP的应用见本标准5.4.2描述2终止原因Abort-CauseAVP
Abort-CauseAVP（AVP代码为500)的类型为Enumerated，它表示会话终止请求或者在RAR中指示释放IP-CAN承载的原因。其枚举值定义如下：9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。