The AF is an element offering applications that require the Policy and Charging Control of traffic plane resources (e.g. UMTS PS domain/GPRS domain resources). One example of an application function is the P-CSCF. The AF shall use the Rx reference point to provide session information to the PCRF.

The PCRF (Policy Control and Charging Rules Function) is a functional element that encompasses policy control decision and flow based charging control functionalities. These 2 functionalities are the heritage of the release 6 logical entities PDF and CRF respectively. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF receives session and media related information from the AF and informs AF of traffic plane events. The PCRF may check that the service information provided by the AF is consistent with the operator defined policy rules before storing the service information. The service information shall be used to derive the QoS for the service. The PCRF may reject the request received from the AF and as a result the PCRF shall indicate, in the response to the AF, the service information that can be accepted by the PCRF. The PCRF may temporarily not be able to provide the service delivery that AF requested (e.g. due to RAN user plane congestion). In this case, the PCRF may send a re-try interval information to the AF. The re-try interval indicates when service delivery may be retried by the AF over Rx. The PCRF may use the subscription information as basis for the policy and charging control decisions. The subscription information may apply for both session based and non-session based services. The subscription specific information for each service may contain e.g. max QoS class and max bit rate. If the AF requests it, the PCRF shall report IP-CAN session events (including bearer events and events on AF signalling transport) to the AF via the Rx reference point. The PCRF PCC/QoS Rule decisions may be based on one or more of the following:

• the session and media related information obtained from the AF via the Rx reference point;
• the bearer and subscriber related information obtained from the PCEF over the Gx reference point;
• the bearer and subscriber related information obtained from the BBERF over the Gxx reference point;
• subscriber and service related data the PCRF may be aware of by configuration or through the Sp reference point;
• pre-configured information in the PCRF.

The PCRF shall provision PCC/QoS Rules to the PCEF/BBERF via the Gx/Gxx reference point.

When a new AF session is being established and media information for this AF session is available at the AF and the related media require PCC supervision, the AF shall open an Rx Diameter session with the PCRF for the AF session using an AA-Request command, unless an Rx session has already been established for the AF session (e.g. as per clause 4.4.6.7). If an Rx Diameter session already exists for the AF session, the AF uses the existing Rx Diameter session. The AF shall provide the full IP address of the UE using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP, and the corresponding Service Information within Media-Component-Description AVP(s). The AF shall not include circuit-switched bearer related media in the service information sent to the PCRF. The AF shall indicate to the PCRF as part of the Media-Component-Description whether the media IP flow(s) should be enabled or disabled with the Flow-Status AVP. The AF may include the AF-Application-Identifier AVP into the AA-Request in order to indicate the particular service that the AF session belongs to. This AVP can be provided at both AF session level, and Media-Component-Description level. When provided at both levels, the AF-Application Identifier provided within the Media-Component-Description AVP will have precedence. The AF may also include an AF application identifier within the AF-Application-Identifier AVP at the AF session level to trigger the PCRF to indicate to the PCEF/TDF to perform the application detection based on the operator's policy as defined in TS 29.212. The AF may include the AF-Charging-Identifier AVP into the AA-Request for charging correlation purposes. The AF may also include the Specific-Action AVP to request notification for certain user plane events, e.g. bearer termination. The AF may include the Service-URN AVP in order to indicate that the new AF session relates to emergency or RLOS traffic and additionally it may include the AF-Requested-Data AVP to indicate the information required by the AF. If the PCRF receives the Service-URN AVP indicating an emergency session, the PCRF may apply special policies, for instance prioritising service flows relating to the new AF session or allowing these service flows free of charge. If the Service-URN AVP indicates that the new AF session relates to emergency traffic and the AF-Requested-Data AVP is received, the PCRF shall provide the requested available user information as part of the AA-Answer command. The AF may include the MPS-Identifier AVP in order to indicate that the new AF session relates to an MPS session. If the PCRF receives the MPS-Identifier AVP indicating an MPS session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MPS session is prioritized as specified in TS 29.212. For Multimedia Priority Service handling for IMS, see Annex A.9. The AF may include the MCPTT-Identifier AVP in order to indicate that the new AF session relates to an MCPTT session with priority call. If the PCRF receives the MCPTT-Identifier AVP related to that MCPTT session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCPTT session is prioritized. For the handling of MCPTT session with priority call, see Annex A.13. The AF may include the MCVideo-Identifier AVP in order to indicate that the new AF session relates to an MCVideo session with priority call. If the PCRF receives the MCVideo-Identifier AVP related to that MCVideo session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCVideo session is prioritized. For the handling of MCVideo session with priority call, see Annex A.15. If the QoSHint feature is supported by the AF, the AF may include the Desired-Max-Latency AVP and/or Desired-Max-Loss AVP within the Media-Component-Description AVP to indicate to the PCRF that the related application media has specific latency and/or loss demands. The AF may include the FLUS-Identifier AVP within the Media-Component-Description AVP in order to indicate to the PCRF that the media flow(s) correspond to a FLUS media stream. Additional QoS information for the treatment of FLUS media may be provided within Desired-Max-Latency AVP and/or Desired-Max-Loss AVP. The AF may include the Priority-Sharing-Indicator AVP set to PRIORITY_­SHARING_­ENABLED within the Media-Component-Description AVP in order to indicate to the PCRF that the related media flow is allowed to use the same Allocation and Retention Priority (ARP) as media flows belonging to other AF sessions as described in clause 4.4.8. In this case, if the MCPTT-Preemption is supported, the AF may also include the Pre-emption-Capability AVP containing the suggested pre-emption capability value and the Pre-emption-Vulnerability AVP containing the suggested pre-emption vulnerability value within the Media-Component-Description AVP for the PCRF to determine the ARP values. The AF may also include the Pre-emption-Control-Info AVP containing the pre-emption control information at the AAR command level for the PCRF to perform the pre-emption control as defined in clause 4.5.27 or 4a.5.17 of TS 29.212. The AF may include the Sharing-Key-UL and/or Sharing-Key-DL AVP within the Media-Component-Description AVP in order to indicate that the related media of the new AF session may share resources with other media components in the related direction that include the same value for the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP. When the AF is a GCS AS, it may include the GCS-Identifier AVP at command level and Reservation-Priority AVP at command level or media component level in order to indicate that the new AF session relates to a prioritized Group Communication session. Based on this information, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the Group Communication session is prioritized as specified in TS 29.212. If the AF provides service information that has been fully negotiated (e.g. based on the SDP answer), the AF may include the Service-Info-Status AVP set to FINAL_­SERVICE_­INFORMATION. In this case the PCRF shall authorize the session and provision the corresponding PCC/QoS rules to the PCEF/BBERF. The AF may additionally provide preliminary service information not fully negotiated yet (e.g. based on the SDP offer) at an earlier stage. To do so, the AF shall include the Service-Info-Status AVP with the value set to PRELIMINARY SERVICE INFORMATION. Upon receipt of such preliminary service information, the PCRF shall perform an early authorization check of the service information. For GPRS, the PCRF shall not provision PCC rules towards the PCEF unsolicitedly. However, the PCRF may authorize a PCC/QoS rule request received from the PCEF/BBERF as per TS 29.212. Further, if the AF requests the PCRF to report the access network information together with preliminary service information, the PCRF shall immediately configure the PCEF (or BBERF) to provide the access network information. For sponsored data connectivity and if SponsoredConnectivity is supported, the AF shall provide the application service provider identity and the sponsor identity to the PCRF by including the Application-Service-Provider-Identity AVP and the Sponsor-Identity AVP in the Sponsored-Connectivity-Data AVP in the AA-Request. Additionally if SponsorChange is supported the AF shall provide an indication whether to enable or not enable sponsored data connectivity to the PCRF by including the Sponsoring-Action AVP set to the applicable value. To support the usage monitoring of sponsored data connectivity, the AF may also include the Granted-Service-Unit AVP in the Sponsored-Connectivity-Data AVP and the Specific-Action AVP set to the value USAGE_­REPORT in the AA-Request to request notification when the usage threshold has been reached. When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity, the following procedures apply:

• If the UE is roaming with the visited access case and the AF is located in the HPLMN or roaming with the home routed case and operator policies do not allow accessing the sponsored data connectivity with this roaming case, the H-PCRF shall reject the service request indicating UNAUTHORIZED_­SPONSORED_­DATA_­CONNECTIVITY to the AF.
• If the UE is roaming with the visited access case and the AF is located in the VPLMN, the V-PCRF shall reject the service request indicating UNAUTHORIZED_­SPONSORED_­DATA_­CONNECTIVITY to the AF.

When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity, if the UE is in the non-roaming case or roaming with the home routed case and the operator policies allow accessing the sponsored data connectivity with this roaming case, the following procedures apply:

• If the PCEF/TDF does not support sponsored connectivity and the required reporting level for that service indicates a sponsored connectivity level according to TS 29.212, then the PCRF shall reject the request indicating REQUESTED_­SERVICE_­NOT_­AUTHORIZED.
• If the PCEF/TDF supports sponsored data connectivity feature or the required reporting level is different from sponsored connectivity level as described in TS 29.212, then the PCRF, based on operator policies, shall check whether it is required to validate the sponsored connectivity data. If it is required, it shall perform the authorizations based on sponsored data connectivity profiles. If the authorization fails, the PCRF responds to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value UNAUTHORIZED_­SPONSORED_­DATA_­CONNECTIVITY. The profile may include a list of Application Service Providers and their applications per sponsor.

When CHEM feature is supported, the AF includes the Max-PLR-DL AVP and/or Max-PLR-UL AVP within the Media-Component-Description AVP, to indicate the downlink maximum packet loss rate and/or uplink maximum packet loss rate for each payload type. For CHEM feature, see Annex A.18. When the PCRF receives an initial AA-Request from the AF, the PCRF shall perform session binding as described in TS 29.213. To allow the PCRF to identify the IP-CAN session for which this request applies, the AF shall provide either the Framed-IP-Address or the Framed-Ipv6-Prefix containing the full IP address applicable to an IP flow or IP flows towards the UE. In case of private IP address being used, the AF may provide PDN information if available in the Called-Station-Id AVP for session binding. The AF may provide the domain identity in the IP-Domain-Id AVP for session binding. If the PCRF fails in executing session binding, the PCRF responds to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value IP-CAN_­SESSION_­NOT_­AVAILABLE. Further details on how the PCRF identifies suitable IP-CAN sessions can be found in the binding mechanism described in TS 29.213. If the request contains Media-Component-Description Attribute-Value Pair(s) (AVP(s)) the PCRF shall store the received Service Information. The PCRF shall process the received Service Information according to the operator policy and may decide whether the request is accepted or not. The PCRF may take the priority information within the Reservation-Priority AVP into account when making this decision. For an IP-CAN session associated to a dedicated APN for the purpose of offering services to remote UEs via a ProSe UE-to-network relay UE, as defined in TS 23.303, the PCRF shall validate the service information based on the service/roaming agreement and the operator policies related to that PDN information. If the service information provided in the AA-Request command is rejected (e.g. the subscribed guaranteed bandwidth for a particular user is exceeded), the PCRF shall indicate in the AA-Answer command the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_­SERVICE_­NOT_­AUTHORIZED. If the service information provided in the AA-Request command is rejected by the PCRF due to a temporary condition in the network (e.g. the user plane in the cell the user is located is congested), the PCRF may indicate in the AA-Answer the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_­SERVICE_­TEMPORARILY_­NOT_­AUTHORIZED (4261). The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF. When the AF receives the re-try interval within the Retry-Interval AVP, the AF shall not send the same service information to the PCRF again (for the same IP-CAN session) until the re-try interval has elapsed. The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in AA-Answer command. To allow the PCRF and PCEF to perform PCC rule authorization and bearer binding for the described service IP flows, the AF shall supply both source and destination IP addresses and port numbers within the Flow-Description AVP, if such information is available. The AF may specify the ToS-Traffic-Class AVP for the described service data flows together with the Flow-Description AVP. The AF may specify the Reservation-Priority AVP at request level in the AA-Request in order to assign a priority to the AF Session as well as specify the Reservation-Priority AVP at the media-component-description AVP level to assign a priority to the IP flow. The presence of the Reservation-Priority in both levels does not constitute a conflict as they each represent different types of priority. Specifically the Reservation-Priority at the AA-Request level provides the relative priority for a session while the Reservation-Priority at the media-component-description level provides the relative priority for an IP flow within a session. If the Reservation-Priority AVP is not specified the requested priority is DEFAULT (0). The AF may request notifications of specific IP-CAN session events through the usage of the Specific-Action AVP in the AA-Request command. The PCRF shall make sure to inform the AF of the requested notifications in the event that they take place. The AF may include the Rx-Request-Type AVP set to INITIAL_­REQUEST in the AAR. The AF may include a Reference Id within the Reference-Id AVP related to a transfer policy negotiated for background data transfer via the Nt reference point as described in TS 29.154. The PCRF shall retrieve the corresponding transfer policy from the SPR based on the Reference Id. If the PCRF can not retrieve the transfer policy, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 0 set to indicate that the transfer policy is unknown. If the time window of the received transfer policy has expired, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 1set to indicate that the transfer policy has expired. Otherwise, if the time window of the received transfer policy has not yet occurred, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 2 set to indicate that the time window of the transfer policy has not yet occurred. The AF may include the IMS-Content-Type AVP into the AA-Request in order to indicate the type of IMS communication service (e.g. CAT service, 3PTY conference) the AF session refers to. The AF may include the IMS-Content-Identifier AVP into the AA-Request in order to indicate the particular IMS communication service or communication dialogue that the AF session refers to. The AF may include the Calling-Party-Address AVP and the Callee-Information AVP into the AA-Request in order to indicate the caller and the callee information that the AF session refers to. The PCRF shall check whether the received Service Information requires PCC/QoS Rules to be created and provisioned and/or authorized QoS to be provisioned as specified in TS 29.213. Provisioning of PCC/QoS Rules and Authorized QoS to the PCEF/BBERF shall be carried out as specified at TS 29.212. If the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP are provided within the Media-Component-Description AVP, the PCRF may apply the mechanisms for resource sharing as specified at TS 29.212. The PCRF shall reply with an AA-Answer to the AF. The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF and shall include the Access-Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address AVP, if they are available. The AA-Answer message shall also include the AN-GW-Address AVP, if the PCRF has previously requested to be updated with this information in the PCEF. The AA-Answer message shall also include the PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP if the PCRF has previously requested to be updated with this information in the PCEF/BBERF. The AA-Answer message shall also include the IP-CAN-Type AVP. if the PCRF has previously requested to be updated with this information in the PCEF/BBERF. In that case, the AA-Answer message shall also include the RAT type information within the RAT-Type AVP and AN-Trusted AVP when applicable for the specific IP-CAN Type. In addition, if IP flow mobility applies to service data flows as specified in TS 29.212, such that a subset of the flows within the AF session are affected, the PCRF shall also include IP-CAN-type and RAT type information (if applicable) to IP flow mobility related flows, if such information is available. The IP flow mobility affected service data flows are included within the Flows AVP at command level. If the PCRF needs to terminate the Rx session before it has sent the AA Answer, the PCRF shall send the AA Answer immediately and before the AS Request. The behaviour when the AF does not receive the AA Answer, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_­SUCCESS, are outside the scope of this specification and based on operator policy. If the PCRF fails in installing PCC/QoS rules based on the provided service information due to resource allocation failure as specified in TS 29.212 and if requested by the AF, the PCRF shall send an RAR command to the AF with the Specific-Action AVP set to the value INDICATION_­OF_­FAILED_­RESOURCES_­ALLOCATION to report the resource allocation failure, the Flows AVP containing the service data flows corresponding to the resources that could not be allocated, and the content version within the Content-Version AVP if it was included when the corresponding media component was provisioned. The AF shall send an RAA command to acknowledge the RAR command.