The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF.

M

C

The PCRF receives session and media related information from the AF and informs AF of traffic plane events.

M

C

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.

Op

C

The service information shall be used to derive the QoS for the service.

M

C

The PCRF may reject the request received from the AF.

Op

C

If the PCRF rejects a request received from the AF the PCRF shall indicate, in the response to the AF, the service information that can be accepted by the PCRF.

M

PC

The SAPC may reject a request owing to service not authorized, but in the response, the SAPC does not indicate the service information that can be accepted

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.

NOTE 1: Additionally, existing bandwidth limitation parameters (e.g. Max-Requested-Bandwidth-DL AVP, Max-Requested-Bandwidth-UL AVP within the Acceptable-Service-Info AVP) provided by the PCRF to the AF in AA-Answer command during the Rx session establishment are available in order to mitigate RAN user plane congestion.

Op

NC

The PCRF may use the subscription information as basis for the policy and charging control decisions.

Op

C

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.

Op

C

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.

M

PC

See Rx Interface Description for supported events (Specific-Action AVP)

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;

Op

C

- the bearer and subscriber related information obtained from the PCEF over the Gx reference point

Op

C

- the bearer and subscriber related information obtained from the BBERF over the Gxx reference point

Op

NC

The Gxx reference point is not supported.

- subscriber and service related data the PCRF may be aware of by configuration or through the Sp reference point

Op

C

- pre-configured information in the PCRF

Op

C

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

M

PC

The Gxx reference point is not supported.

AF-Application-Identifier 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.

M

C

If the PCRF receives the Service-URN AVP indicating an emergency session, the PCRF may apply special policies, for instance prioritizing service flows relating to the new AF session or allowing these service flows free of charge.

Op

C

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.

M

NC

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 3GPP TS 29.212.

Op

C

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.

Op

NC

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.

Op

NC

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 3GPP TS 29.212.

Op

NC

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.

M

PC

The Gxx reference point is not supported.

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 3GPP TS 29.212.

M

PC

The SAPC may provision PCC rules for GPRS regardless of the Service-Info-Status.

The Gxx reference point is not supported.

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.

M

PC

The SAPC does not support to configure BBEF to provide the access network information.

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.

M

NC

- 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.

M

NC

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 3GPP TS 29.212, then the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED

M

NC

- If the PCEF/TDF supports sponsored data connectivity feature or the required reporting level is different from sponsored connectivity level as described in 3GPP 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.

M

NC

When the PCRF receives an initial AA-Request from the AF, the PCRF shall perform session binding as described in 3GPP TS 29.213

M

C

To allow the PCRF to identify the IP-CAN session for which the session 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.

M

C

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.

M

C

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.

M

C

The PCRF may take the priority information within the Reservation-Priority AVP into account when making this decision.

Op

C

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 3GPP 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.

NOTE 8: The PCRF is not required to be aware of the remote UE.

M

NC

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.

M

C

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 (4XX1). 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.

Op

NC

The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in AA-Answer command.

Op

NC

If the Reservation-Priority AVP is not specified the requested priority is DEFAULT (0).

M

C

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.

M

PC

See Rx Interface Description document for supported values of Specific-Action AVP. If a given specific action is not supported by the SAPC, the SAPC accepts the request anyway, but no associated notifications are sent to AF in that case.

The PCRF shall retrieve the corresponding transfer policy from the SPR based on the Reference Id.

M

NC

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.

M

NC

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.

NOTE 13: In the case that the PCRF can not retrieve the transfer policy or the transfer policy expired, the PCRF makes the decision without considering the transfer policy.

M

NC

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 3GPP TS 29.213 [9].

M

C

Provisioning of PCC/QoS Rules and Authorized QoS to the PCEF/BBERF shall be carried out as specified at 3GPP TS 29.212 [8].

M

PC

The Gxx reference point is not supported.

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 3GPP TS 29.212 [8].

Op

NC

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.

M

PC

The SAPC always sends the AA-Answer before the PCC rule provisioning.

Access Network-Charging-Identifier(s) and Access-Network-Charging-Address AVP, are not returned in AAA.

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.

M

NC

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.

M

NC

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.

M

PC

Interaction with BBERF is not supported.

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.

M

NC

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.

M

C

If the PCRF fails in installing PCC/QoS rules based on the provided service information due to resource allocation failure as specified in 3GPP 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.

M

PC

The Gxx reference point is not supported.

The Content-Version AVP is not supported.

For the normal case where 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 rules to the PCEF.

M

C

Upon reception of an AA-Request command with the Service-Info-Status AVP set to 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 3GPP TS 29.212.

M

PC

The Gxx reference point is not supported.

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.

M

PC

The SAPC does not support to configure BBEF to provide the access network information.

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.

M

NC

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.

NOTE 1: In the case that the PCRF can not retrieve the transfer policy or the transfer policy expired, the PCRF makes the decision without considering the transfer policy.

M

NC

The AF may include the MPS-Identifier AVP in order to indicate that the modified AF session relates to an MPS session. If the PCRF receives the MPS-Identifier AVP, it may take specific actions on the corresponding IP-CAN to ensure that the MPS session is prioritized as defined in 3GPP TS 29.212.

Op

C

The AF may include the MCPTT-Identifier AVP in order to indicate that the modified AF session relates to the priority adjustment of an MCPTT session. 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.

Op

NC

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 modify the priority of an AF session that 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 3GPP TS 29.212.

Op

NC

When sponsored data connectivity is requested to be enabled 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.

M

NC

- 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.

M

NC

When sponsored data connectivity is requested to be enabled, 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 [8], then the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED.

M

NC

- 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.

M

NC

The PCRF shall process the received Service Information according the operator policy.

M

C

The PCRF may decide whether the request is accepted or not.

Op

C

If the updated Service Information is not acceptable (e.g. 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.

M

C

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).

Op

NC

The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF.

Op

NC

The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in the AA-Answer command.

Op

NC

If accepted, the PCRF shall update the Service Information with the new information received.

M

C

Due to the updated Service Information, the PCRF may need to create, modify or delete the related PCC rules as specified in 3GPP TS 29.213 [9] and provide the updated information towards the PCEF following the corresponding procedures specified at 3GPP TS 29.212 [8].

Op

C

The procedures to update the Authorized QoS for the affected IP-CAN bearer are also specified at 3GPP TS 29.212 [8].

Op

C

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 3GPP TS 29.212 [8].

Op

NC

The PCRF shall reply with an AA-Answer to the AF.

M

C

The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF.

Op

C

The SAPC always sends the AA-Answer before the PCC rule provisioning

The AA-Answer sent towards the AF shall include the Access Network-Charging-Identifier(s), if they are available at this moment and have not been yet supplied earlier to the AF.

M

NC

The AA-Answer sent towards the AF may include the Access-Network-Charging-Address AVP, if it is available at this moment and have not been yet supplied earlier to the AF.

Op

NC

The AA-Answer message shall include the AN-GW-Address AVP if the PCRF has previously requested to be updated with this information in the PCEF.

M

NC

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.

M

NC

The AA-Answer message shall also include the IP-CAN-Type AVP if such information is available and has not yet been supplied earlier to the AF. 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.

M

C

The PCRF shall also include IP-CAN-type and RAT-type information (if applicable) to IP flow mobility related flows, if the PCRF has previously requested to be updated with this information in the PCEF. The IP flow mobility affected service data flows are included within the Flows AVP at command level.

M

NC

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.

M

C

If the PCRF does not have an existing session for the Rx session being modified (such as after a PCRF failure), the PCRF may reject the request with an AA-Answer with the result code set to DIAMETER_UNKNOWN_SESSION_ID.

Op

C

If the PCRF installs PCC/QoS rules or modifies existing PCC/QoS rules based on the updated service information and the installation or modification fails due to resource allocation failure as specified in 3GPP TS 29.212 [8] 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 modification failure, the Flows AVP containing the service data flows corresponding to the resources that could not be allocated, and the content version(s) within the Content-Version AVP(s) if it was included when the corresponding media component was provisioned. If the modification of the existing PCC/QoS rules fails, the PCRF may also provide the status of the service information within the Media-Component-Status AVP.

M

PC

The Content-Version AVP is not supported.

The PCRF shall set the appropriate gate status for the corresponding active PCC rule(s) in response to an AA-Request message containing the Media-Component-Description AVP(s) that contains the flow status information (in the Flow-Status AVP) for the flows to be enabled or disabled.

M

C

If a Media-Sub-Component AVP under a Media-Component-Description AVP contains a Flow-Usage AVP with the value RTCP, then the corresponding RTCP IP Flows in both directions shall be enabled even if the Flow-Status AVP under the Media-Sub-Component AVP is set to ENABLED-UPLINK, ENABLED-DOWNLINK, ENABLED, or DISABLED.

M

C

The PCRF shall reply with an AA-Answer and shall include the Access-Network-Charging-Identifier(s) available at this moment.

M

NC

The PCRF forwards the AF decision to enable or disable the authorized IP flows.

M

C

When the PCRF receives a ST-Request from the AF, indicating an AF session termination, it shall acknowledge that request by sending a ST-Answer to the AF.

M

C

Afterwards, it shall free the resources allocated for the corresponding Service Data Flow(s).

M

C

The PCRF shall initiate the request for the removal of any related PCC/QoS rules from the PCEF/BBERF and for the update of the Authorized QoS for the affected IP-CAN bearer following the corresponding procedures specified at 3GPP TS 29.212.

M

PC

The Gxx reference point is not supported.

However, if the AF requests the reporting of access network information within the ST-Request or if the AF provided a threshold for the sponsored data connectivity, the PCRF shall defer sending the ST-Answer.

M

PC

Sponsored data connectivity is not supported.

If the AF session being terminated corresponds to an MPS session, the PCRF may revoke the actions related to the prioritization of the MPS session in the corresponding IP-CAN as defined in 3GPP TS 29.212.

M

C

If the AF session being terminated corresponds to the last Group Communication session for the IP-CAN session, the PCRF may revoke the actions related to the prioritization of the Group Communication session as specified in 3GPP TS 29.212.

M

NC

If the AF session being terminated corresponds to a session that included the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED within the Media-Component-Description AVP, the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in subclause 4.4.8.

M

NC

For sponsored data connectivity, and if a volume threshold was provided for the sponsored data connection at initial provisioning of session information (clause 4.4.1) or modification of session information (clause 4.4.2) procedures, the PCRF shall provide the volume consumed to the AF.

M

NC

For such purpose, the PCRF shall initiate the IP-CAN session modification procedure according 3GPP TS 29.212 in order to obtain the consumed volume. The PCRF shall send then the ST-Answer to the AF including the Used-Service-Unit AVP for reporting accumulated usage within the Sponsored-Connectivity-Data AVP.

M

NC

If the AF requires access network information at this step, the AF shall include the Required-Access-Info AVP within the ST-Request command, indicating the required information. In this case, the PCRF shall initiate the IP-CAN session modification procedure according to 3GPP TS 29.212. The PCRF shall send then the ST-Answer to the AF including the required data within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier AVP (if available), User-Location-Info-Time AVP (if available), UE-Local-IP-Address AVP (if available), UDP-Source-Port AVP (if available), TCP-Source-Port AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available).

M

C

If the RAN-NAS-Cause feature is supported, and the AF initiated the termination of the AF session upon reception of the ST-Request command, the PCRF shall initiate the IP-CAN session modification procedure according to 3GPP TS 29.212.

C

NC

If the RAN-NAS-Cause feature is supported, in all the AF session termination cases, the PCRF shall send the ST-Answer to the AF including the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the ST-Answer command.

C

NC

NOTE: The PCRF will apply the procedures described in 3GPP TS 29.212 [8] to get updated about the outcome of the resource release over Gx reference point in order to get the location and failure cause(s) when applicable.

C

NC

An AF may subscribe to notifications of the status of the AF Signalling transmission path.

When the PCRF receives an AA-Request from the AF where the Media-Sub-Component AVP contains the Flow-Number AVP set to “0” , the PCRF shall perform session binding as described in 3GPP TS 29.213 and acknowledge the AAR command by sending an AA Answer command to the AF.

M

C

PCC/QoS rules related to AF Signalling IP Flows should be provisioned to PCEF/BBERF using the corresponding procedures specified at 3GPP TS 29.212 at an earlier stage (e.g. typically at the establishment of the IP-CAN bearer dedicated for AF Signalling IP Flows). The PCRF may install the corresponding dynamic PCC/QoS rule for the AF signalling IP flows if none has been installed before.

NOTE 1: Well-known ports (e.g. 3GPP TS 24.229 for SIP) or wildcard ports can be used by PCRF to derive the dynamic PCC/QoS rule for the AF signalling IP flows.

Op

PC

The SAPC supports this feature for PCC rule interaction with PCEF only.

If the Rx Diameter Session is only used for subscription to Notification of Signalling Path Status, the AF may cancel the subscription to notifications of the status of the AF Signalling transmission path. In that case, the AF shall use a Session-Termination-Request (STR) command to the PCRF, which shall be acknowledged with a Session-Termination-Answer (STA) command.

M

C

When the PCRF receives from the AF an AA-Request with provisioning information about the AF signalling IP flows between the UE and the AF, the PCRF shall perform session binding as described in 3GPP TS 29.213 and shall acknowledge the AAR command by sending an AA Answer command to the AF.

M

C

PCC/QoS Rules related to the AF signalling IP flows could have been provisioned to PCEF/BBERF using the corresponding procedures specified in 3GPP TS 29.212 at an earlier stage (e.g. typically at the establishment of the IP-CAN bearer dedicated for AF Signalling IP Flows). The PCRF shall install the corresponding dynamic PCC/QoS rule for the AF signalling IP flows.

M

PC

The Gxx reference point is not supported.

The AF may de-provision the information about the AF signalling IP flows at any time. To do that, if the Rx Diameter session is only used to provide information about the AF Signalling IP flows, the AF shall close the Rx Diameter session by sending a Session-Termination-Request (STR) command to the PCRF, which shall be acknowledged with a Session-Termination-Answer (STA) command. Otherwise, the AF shall remove the IP flows within the Media-Sub-Component AVP by supplying the Flow-Status AVP with value "REMOVED". In both cases, the PCRF shall remove the corresponding dynamic PCC/QoS rule for the AF signalling IP flows.

M

C

When an IP-CAN session is terminated, the PCRF shall inform the AF about the IP-CAN session termination by sending an ASR (abort session request) command to the AF on each active Rx Diameter session.

M

C

When the PCRF gets the knowledge that one or more SDFs have been deactivated, (e.g. due to a bearer release or loss of bearer or out of credit condition), the PCRF shall inform the AF accordingly if the AF has previously subscribed using the Specific-Action AVP in the AAR command.

M

C

When not all the service data flows within the AF session are affected, the PCRF shall inform the AF by sending an RAR (re-authorization request) command. The RAR command shall include the deactivated IP Flows encoded in the Flows AVP, the cause encoded in the Specific-Action AVP and the content version of a media component within the Content-Version AVP if it was included when the media component was provisioned.

M

PC

The Content-Version AVP is not supported.

If the RAN-NAS-Cause feature is supported and the PCRF received the access network information from the PCEF/BBERF due to bearer termination, the PCRF shall include in the RAR command the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause due to bearer termination, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the RAR command.

C

NC

If the PCRF receives the AAR command, it shall acknowledge the command by sending an AAA (AA-answer) command to the AF.

M

C

When all the service data flows within the AF session are affected, the PCRF shall inform the AF by sending an ASR command on the Rx Diameter session related to the AF session.

M

C

In the event that the PCRF is notified of the loss or release of resources associated to the PCC/QoS Rules corresponding with AF Signalling IP Flows, the PCRF shall inform the AF about the Loss of the Signalling Transmission path by sending a Re Authorization Request (RAR) command to the AF.

M

PC

The SAPC supports this feature for PCC rule interaction with PCEF only.

The RAR shall include the Specific-Action AVP set to the value "INDICATION_OF_LOSS_OF_BEARER" or “INDICATION_OF_RELEASE_OF_BEARER” and the deactivated IP Flow encoded in the Flows AVP.

NOTE: According to the standardized QCI characteristics as defined in 3GPP TS 23.203 [2], the IMS signalling specific PCC rules include a QCI corresponding to a non-GBR bearer. When these guidelines are followed, the INDICATION_OF_LOSS_OF_BEARER will not be reported.

M

PC

The SAPC does not support the INDICATION_OF_LOSS_OF_BEARER value in the Specific-Action AVP.

If the RAN-NAS-Cause feature is supported and the PCRF received the access network information from the PCEF/BBERF due to bearer termination, the PCRF shall include in the RAR command the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause due to bearer termination, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the RAR command.

C

NC

If the AF has successfully subscribed to change notifications in UE’s IP-CAN type and RAT type, the PCRF shall send an RAR command when the corresponding event occurs, i.e. when the UE’s IP-CAN type or RAT type changes or becomes available.

M

C

In this case the RAR from the PCRF shall include the Specific-Action AVP for the subscribed event and include the IP-CAN-Type AVP , RAT-Type AVP (if applicable) and AN-Trusted AVP (if applicable) and AN-GW-Address AVP (if applicable) for the UE’s new IP-CAN/RAT.

M

C

If the PCRF is informed of an IP-CAN type change due to IP flow mobility as specified in 3GPP TS 29.212, where a subset the flows within the AF session are affected, the PCRF shall include IP-CAN-type and RAT-type information (if applicable) to IP flow mobility affected service data flows. The IP flow mobility affected service data flows are included within the Flows AVP at command level.

M

NC

If the AF has subscribed to a notification about Access Network Charging Information, the PCRF shall provide the Access Network Charging Information in the response, if already known by the PCRF.

M

NC

If not available, the PCRF shall provide the Access Network Charging Information by sending a Re-Authorization-Request (RAR) command when the Access Network Charging Information is received from the PCEF.

M

NC

If different Access Network Charging Information is applicable to the IP-CAN session, the PCRF shall notify the AF about the Access Network Charging Information that applies to each authorized flow

M

NC

The RAR shall include the Specific-Action AVP set to the value "CHARGING_CORRELATION_EXCHANGE" and shall include the assigned Access Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address AVP.

M

NC

When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity and the AF provided usage monitoring thresholds for such sponsor to the PCRF when the Rx Diameter session was established or modified, the PCRF shall report accumulated usage to the AF, when

- the PCRF detects that the usage threshold provided by the AF has been reached; or

M

NC

- the AF session is terminated by the AF; or

M

NC

- the AF session is terminated by the PCRF due to the IP-CAN session termination, the termination of all the service data flows of the AF session or the home operator policy disallowing the UE accessing the sponsored data connectivity in the roaming case.

M

NC

When the PCRF detects that the usage threshold has been reached, the PCRF shall report the accumulated usage as provided by the PCEF/TDF to the AF in a RA-Request (RAR) command with the Specific-Action AVP set to the value USAGE_REPORT.

M

NC

Otherwise, when the AF session is terminated by the AF or the PCRF, the PCRF shall report the accumulated usage as provided by the PCEF/TDF to the AF in ST-Answer (STA) command.

M

NC

The accumulated usage shall be reported in the Used-Service-Unit AVP within the Sponsored-Connectivity-Data AVP.

M

NC

NOTE: After the PCRF reports the accumulated usage to the AF, the AF can provide a new usage threshold to the PCRF. The monitoring will not start until the PCRF receives the new threshold from the AF and provide it to the PCEF.

M

NC

When the PCRF receives a request to report the access network information from the AF in an AAR command or in an STR command triggered by the AF, if the PCRF determines that the access network does not support the access network information reporting based on the currently used IP-CAN type or the values of the RAT-Type AVP or the PCEF/BBERF does not support the NetLoc feature as described in subclause 5.4.1, the PCRF shall respond to AF with an AAA or STA command including the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED); otherwise, it shall immediately configure the PCEF or BBERF to provide such access network information.

M

PC

The SAPC does not support the interaction with BBERF.

The SAPC does not check either the IP-CAN type or the RAT-Type values to determine if the access network supports or not the access network information reporting.

When the PCRF then receives the access network information from the PCEF/BBERF, the PCRF shall provide the corresponding access network information to the AF within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier AVP (if available), User-Location-Info-Time AVP (if available), UE-Local-IP-Address AVP (if available), UDP-Source-Port AVP (if available), TCP-Source-Port AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP in the RAR command if the Rx session is not being terminated or in the STA command if the Rx session is being terminated. If the information is provided in the RAR command, PCRF shall also provide the ACCESS_NETWORK_INFO_REPORT within Specific-Action AVP.

M

PC

The SAPC does not support the interaction with BBERF.

When the PCRF receives the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) from the PCEF/BBERF, the PCRF shall send a RAR command including the Specific-Action AVP set to INDICATION_OF_ACCESS_NETWORK_INFO_REPORTING_FAILURE and the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) if the AF requested the access network information in an AAR command or send an STA command including the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) if the AF requested the access network information in an STR command.

M

PC

The SAPC does not support the interaction with BBERF.

The PCRF shall not send an RAR command with the ACCESS_NETWORK_INFO_REPORT value within a Specific-Action AVP to report any subsequently received access network information to the AF, unless the AF sends a new request for access network information.

M

C

When the Extended-Max-Requested-BW-NR feature, the Extended-Min-Requested-BW-NR feature, and/or the Extended-BW-E2EQOSMTSI-NR features are supported, extended bandwidth AVPs representing bitrates in kbps shall be used to represent bandwidth values higher than 2³²-1 bps instead of the bandwidth AVPs with a maximum value of 2³²-1 bps that represent bitrates in bps.

Op

PC

Extended-Min-Requested-BW-NR and Extended-BW-E2EQOSMTSI-NR not supported.

For the Extended-Max-Requested-BW-NR feature:

• Extended-Max-Requested-BW-DL/UL AVPs shall be used instead of Max-Requested-Bandwidth-DL/UL AVPs

Op

C

For the Extended-BW-E2EQOSMTSI-NR feature:

• Extended-Max-Supported-BW-DL/UL AVPs shall be used instead of Max-Supported-Bandwidth-DL/UL AVPs.

• Extended-Min-Desired-BW DL/UL AVPs shall be used instead of Min-Desired-Bandwidth-DL/UL AVPs.

Op

NC

For the Extended-Min-Requested-BW-NR feature:

• Extended-Min-Requested-BW-DL/UL AVPs shall be used instead of Min-Requested-Bandwidth-DL/UL AVPs.

Op

NC

For values lower or equal to 2³²-1 bps AVPs representing bitrates in bps shall be used.

Op

C

The Rx application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP and the Application-Id for the Rx application in the present release is 16777236.

M

C

The vendor identifier assigned by IANA to 3GPP is 10415.

M

C

The Rx application identification shall be included in the Auth-Application-Id AVP.

M

C

The PCRF acts as Diameter Server, in the sense that it is the network element that handles AF session authorization requests for a particular realm.

M

C

The initialization and maintenance of the connection between each AF and PCRF pair is defined by the underlying protocol. Establishment and maintenance of connections between Diameter nodes is described in IETF RFCIETF 6733 [52].

M

PC

See Statement of Compliance to RFC 6733 - Diameter Base Protocol for further information.

After establishing the transport connection, the PCRF and the AF shall advertise the support of the Rx specific Application by including the value of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Vendor-Specific-Application-Id AVP contained in the Capabilities Exchange-Request and Capabilities-Exchange-Answer commands.

M

C

Vendor-Id header of all AVPs shall be set to 3GPP (10415).

M

C

Abort-Cause

M

PC

For supported values, refer to Rx Interface Description.

Access-Network-Charging-Address

M

NC

Access-Network-Charging-Identifier

M

NC

Access-Network-Charging-Identifier-Value

M

NC

Acceptable-Service-Info

M

NC

AF-Application-Identifier

M

C

AF-Charging-Identifier

M

C

AF-Requested-Data

M

NC

AF-Signalling-Protocol

Op

C

Application-Service-Provider-Identity

Op

NC

Codec-Data

M

NC

Content-Version

M

NC

Extended-Max-Requested-BW-DL

Op

C

Extended-Max-Requested-BW-UL

Op

C

Extended-Max-Supported-BW-DL

Op

NC

Extended-Max-Supported-BW-UL

Op

NC

Extended-Min-Desired-BW-DL

Op

NC

Extended-Min-Desired-BW-UL

Op

NC

Extended-Min-Requested-BW-DL

Op

NC

Extended-Min-Requested-BW-UL

Op

NC

Flow-Description

M

PC

The SAPC does not send an error response (Experimental-Result-Code with value FILTER_RESTRICTIONS) if the AF does not meet IPFilterRule restrictions.

Flow-Number

M

C

Flows

M

C

Flow-Status

M

C

Flow-Usage

M

C

GCS-Identifier

Op

NC

IP-Domain-Id

Op

C

Max-Requested-Bandwidth-DL

M

C

Max-Requested-Bandwidth-UL

M

C

Max-Supported-Bandwidth-DL

Op

NC

Max-Supported-Bandwidth-UL

Op

NC

MCPTT-Identifier

Op

NC

Media-Component-Description

M

PC

The Codec-Data AVP is ignored.

The Min-Requested-Bandwidth-UL and Min-Requested-Bandwidth-DL AVPs are ignored.

Media-Component-Number

M

C

Media-Component-Status

M

NC

Media-Sub-Component

M

C

Media-Type

M

C

MPS-Identifier

Op

C

Min-Desired-Bandwidth-DL

Op

NC

Min-Desired-Bandwidth-UL

Op

NC

Min-Requested-Bandwidth-DL

Op

NC

Min-Requested-Bandwidth-UL

Op

NC

Pritority-Sharing-Indicator

M

NC

Pre-emption-Control-Info

M

NC

Required-Access-Info

Op

C

Retry-Interval

Op

NC

Rx-Request-Type

Op

PC

PCSCF_RESTORATION (2) is not supported.

RR-Bandwidth

M

C

RS-Bandwidth

M

C

Service-Authorization-Info

M

NC

Service-URN

M

C

Service-Info-Status

M

C

Sharing-Key-DL

Op

NC

Sharing-Key-UL

Op

NC

Specific-Action

M

PC

See Rx Interface Description document for supported values.

SIP-Forking-Indication

M

C

Sponsor-Identity

Op

NC

Sponsored-Connectivity-Data

Op

NC

Sponsoring-Action

Op

NC

3GPP-MS-TimeZone

Op

C

3GPP-SGSN-MCC-MNC

Op

C

3GPP-User-Location-Info

Op

C

AN-GW-Address

M

C

AN-Trusted

Op

C

Called-Station-Id

M

C

DRMP

Op

NC

Final-Unit-Action

M

NC

Framed-IP-Address

M

C

Framed-IPv6-Prefix

M

C

Granted-Service-Unit

Op

NC

IP-CAN-Type

M

C

Load

M

NC

OC-OLR

Op

NC

OC-Supported-Features

Op

NC

Pre-emption-Capability

Op

NC

Pre-emption-Vulnerability

Op

NC

RAN-NAS-Release-Cause

Op

NC

NetLoc-Access-Support

Op

C

RAT-Type

Op

C

Reference-Id

Op

NC

Reservation-Priority

Op

C

Subscription-Id

Op

C

Supported-Features

M

C

TCP-Source-Port

M

C

TWAN-Identifier

Op

C

ToS-Traffic-Class

Op

NC

UDP-Source-Port

M

C

UE-Local-IP-Address

Op

C

Used-Service-Unit

Op

NC

User-Equipment-Info

Op

NC

User-Location-Info-Time

Op

C

0: Rel8

M

NC

Rx Rel-8 is not supported.

1: Rel9

M

C

This feature indicates the support of the base 3GPP Rel-9 functionality, including the AVPs and corresponding procedures supported by the Rel8 feature bit, but excluding those features represented by separate feature bits.

2: ProvAFsignalFlow

Op

C

3: SponsoredConnectivity

Op

NC

Not supported

4: Rel10

M

C

This feature indicates the support of the base 3GPP Rel-10 functionality, including the AVPs and corresponding procedures supported by the Rel9 feature bit, but excluding those features represented by separate feature bits.

5: NetLoc

Op

C

6: ExtendedFilter

Op

NC

Not supported

7: SCTimeBasedUM

Op

NC

Not supported

8: Netloc-Trusted-WLAN

Op

NC

Not supported

9: RAN-NAS-Cause

Op

NC

Not supported

10: GroupComService

Op

NC

Not supported

11: ResShare

Op

NC

Not supported

12: DeferredService

Op

NC

Not supported

13: DSCP

Op

NC

Not supported

14: SponsorChange

Op

NC

Not supported

15: E2EQOSMTSI

Op

NC

Not supported

16: NetLoc-Untrusted-WLAN

Op

C

17: MCPTT

Op

NC

Not supported

18: PrioritySharing

Op

NC

Not supported

19: PLMNInfo

Op

NC

Not supported

20: MediaComponentVersioning

Op

NC

Not supported

21: MCPTT-Preemption

Op

NC

Not supported

Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number “0”.

Feature: A short name that can be used to refer to the bit and to the feature, for example "EPS".

M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O").

Description: A clear textual description of the feature.

0: PCSCF-Restoration-Enhancement

Op

NC

Not supported

1: Extended-Max-Requested-BW-NR

Op

NC

Not supported

2: Extended-Min-Requested-BW-NR

Op

C

2: Extended-BW-E2EQOSMTSI-NR

Op

C

Not supported

Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0".

Feature: A short name that can be used to refer to the bit and to the feature, e.g. "EPS".

M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O").

Description: A clear textual description of the feature.

Existing Diameter command codes from the Diameter base protocol IETFRFC 6733 [52] and the NASREQ Diameter application (RFC 4005 [12]) are used with the Rx specific AVPs.

M

C

An Rx specific Auth-Application id is used together with the command code to identify the Rx messages.

M

C

Auth–Application–Id value is 16777236

AA-Request (AAR)

M

C

AA-Answer (AAA)

M

C

Re-Auth-Request (RAR)

M

C

Re-Auth-Answer (RAA)

M

C

Session-Termination-Request (STR)

M

C

Session-Termination-Answer (STA)

M

C

Abort-Session-Request (ASR)

M

C

Abort-Session-Answer (ASA)

M

C

When receiving an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the PCRF shall identify the existing authorization information for that AF session.

M

C

The PCRF shall send additional PCC Rules or individual service data flow filters to already provided PCC rules as required by the Flow Description AVPs within the session information to the PCEF.

M

C

The PCRF shall authorize any additional media components and any increased QoS requirements for the previously authorized media components, as requested within the service information.

M

C

The PCRF shall authorize the maximum bandwidth required by any of the dialogues, but not the sum of the bandwidths required by all dialogues.

M

C

Thus, the QoS authorized for a media component is equal to the highest QoS requested for that media component by any of the forked responses.

M

C

The PCRF shall open or close the gates for service flows depending on the flow status that is being provisioned.

M

C

If a flow ID has been enabled in uplink or downlink direction or both way within previous service information, it shall remain enabled even if the PCRF receives service information that disable this flow ID within an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES.

M

C

If the P-CSCF provides one or more Media-Component-Description AVP with the Flow-Status AVP set to "REMOVED" for previously authorized media component(s) the media component shall remain as authorized and the PCRF shall not take any action on that media component(s).

M

NC

NOTE: There can be cases where a forked response could not support some of the media components included in the SDP Offer (e.g. when early session disposition SDP as described in Annex A.7 applies, the forked response related to the early session could include the port set to zero for those media components not related to the early session or when a subsequent SDP Offer-Answer to indicate that some media is disabled). For those cases the P-CSCF will indicate the PCRF about the removal of the corresponding media component. However this media component is already supported by other UEs and the PCRF needs to maintain the corresponding PCC rules until the final SDP answer is received in the P-CSCF in order to avoid the release of resources in the network.

M

NC

When receiving an AA request with no SIP-Forking-Indication AVP or with a SIP-Forking-Indication AVP with value SINGLE_DIALOGUE, the PCRF shall update installed PCC Rules information and Authorized-QoS information to match only the requirements of the service information within this AA request.

M

C

The PCRF should immediately remove PCC Rule(s) or individual service data flow filters not matching IP flow(s) in the updated Service Information, to reduce the risk for initial clipping of the media stream, and to minimize possible misuse of resources.

Op

C

The PCRF shall also open or close the gates for service flows according to the flow status in the received service information

M

C

When the P-CSCF receives an initial REGISTER SIP message from an attached UE, the P-CSCF may subscribe to notifications of the status of the AF Signalling transmission path using the procedures specified in clause 4.4.5. Once the P-CSCF has subscribed, the P-CSCF may receive notifications from the PCRF according to clause 4.4.6.3.

NOTE 1: When the Standardised QCI characteristics as defined in 3GPP TS 23.203 [2] are followed, the QCI for IMS signalling will correspond to a non-GBR bearer. In this case, the P-CSCF will not receive notifications related to the Specific-Action with value "INDICATION_OF_LOSS_OF_BEARER".

NOTE 2: This procedure is not applicable for IMS registrations for Emergency sessions.

Op

PC

Refer to clause 4.4.5 and clause 4.4.6.3.

When the P-CSCF receives an initial REGISTER SIP message or an INVITE SIP message from an attached UE, the P-CSCF may request from the PCRF the information about the type of IP-CAN the UE is attached to using the procedure specified in clause 4.4.1.

NOTE 1: This procedure is not applicable for IMS registrations for Emergency sessions.

NOTE 2: The P-CSCF can request information about the type of IP-CAN as part of the SIP session setup when it is only interested in the related information when the IMS session is ongoing.

Op

PC

Refer to clause 4.4.1.

The P-CSCF may receive notifications for changes of the IP-CAN type from the PCRF according to clause 4.4.6.4.

Op

PC

Refer to clause 4.4.6.4.

NOTE 4: The PCRF will treat service information containing the SIP-Forking-Indication AVP as described in clause A.3.

M

C

Upon reception of a request that requires MPS treatment, the PCRF shall derive the PCC/QoS Rules corresponding to the MPS session, as appropriate.

M

C

The PCRF shall take specific actions on the corresponding IP-CAN to ensure that the MPS session is prioritized, as described in 3GPP TS 29.212, clause 4.5.19.1.3.

Op

C

When the P-CSCF terminates the MPS session, the PCRF shall delete the PCC/QoS Rules corresponding to the MPS session.

M

C

The PCRF shall revoke the actions related to the prioritization of the MPS session in the corresponding IP-CAN, as described in 3GPP TS 29.212, clause 4.5.19.1.3.

M

C