Content for  TS 29.214  Word version:  18.2.0

The AF may modify the session information at any time (e.g. due to an AF session modification or internal AF trigger) by sending an AA-Request command to the PCRF containing the Media-Component-Description AVP(s) with the updated Service Information. The AF shall send an AA-Request command to the PCRF, only after the previous AA-Request has been acknowledged. 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 rules to the PCEF. 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. The AF may include the Rx-Request-Type AVP set to UPDATE_­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 AF 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 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 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 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. The AF may include the MCVideo-Identifier AVP in order to indicate that the modified AF session relates to the priority adjustment of an MCVideo session. 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 AVP and/or Sharing-Key-DL AVP within the Media-Component-Description AVP in order to indicate that the related media of the modified AF session may share resources with other media components in the related direction that include the same Sharing-Key-UL and or Sharing-Key-DL AVP. The AF may modify the conditions for resource sharing by including a new value of the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP for that media component. 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 TS 29.212. 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 Application-Service-Provider-Identity AVP and the Sponsor-Identity AVP in the Sponsored-Connectivity-Data AVP in the AA-Request. If SponsorChange is supported and the AF requests to enable sponsored data connectivity the AF shall provide the application service provider identity, the sponsor identity and an indication to enable sponsored data connectivity to the PCRF by including Application-Service-Provider-Identity AVP, the Sponsor-Identity AVP and the Sponsoring-Action AVP set to the value ENABLE_­SPONSORING (1) in the Sponsored-Connectivity-Data AVP in the AA-Request. If the AF requests to disable sponsored data connectivity the AF shall provide an indication to disable sponsored data connectivity to the PCRF by including the Sponsoring-Action AVP set to the value DISABLE_­SPONSORING (0) in the Sponsored-Connectivity-Data AVP in the AA-Request. 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 in the AA-Request. 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.
• 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 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, 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. The AF may include an AF application identifier within the AF-Application-Identifier AVP at the 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 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 Callee-Information AVP into the AA-Request in order to indicate the callee information that the AF session refers to. The PCRF shall process the received Service Information according the operator policy and may decide whether the request is accepted or not. 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. 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 the AA-Answer command. If accepted, the PCRF shall update the Service Information with the new information received. Due to the updated Service Information, the PCRF may need to create, modify or delete the related PCC rules as specified in TS 29.213 and provide the updated information towards the PCEF following the corresponding procedures specified at TS 29.212. The procedures to update the Authorized QoS for the affected IP-CAN bearer are also 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 at this moment and have not been yet supplied earlier to the AF. 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. 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 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. 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. 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. 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 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 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. The AF shall send an RAA command to acknowledge the RAR command.

Depending on the application, in the Service Information provision, the AF may instruct the PCRF when the IP flow(s) are to be enabled or disabled to pass through the IP-CAN. The AF does this by sending the 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. In response to this action the PCRF shall set the appropriate gate status for the corresponding active PCC rule(s). 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. The PCRF shall reply with an AA-Answer and shall include the Access-Network-Charging-Identifier(s) available at this moment. The PCRF forwards the AF decision to enable or disable the authorized IP flows. The behaviour when the AF does not receive the AAA, 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.

When an AF session is terminated, if the AF had received a successful AA-Answer for the initial AA-Request, the AF shall send a Session-Termination-Request command to the PCRF. Otherwise, the AF shall wait for the initial AA-Answer to be received prior to sending the Session-Termination-Request command to the PCRF. 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. Afterwards, it shall free the resources allocated for the corresponding Service Data Flow(s). In order to do that, 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 TS 29.212. 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. 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 TS 29.212. For Multimedia Priority Service handling for IMS, see Annex A.9. 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 TS 29.212. 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 clause 4.4.8. For sponsored data connectivity, and if a usage 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 usage consumed to the AF. For such purpose, the PCRF shall initiate the IP-CAN session modification procedure according TS 29.212 in order to obtain the consumed usage. 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. 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 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). 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 TS 29.212. If the RAN-NAS-Cause feature is supported , in all the AF session termination cases , t he 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.

An AF may subscribe to notifications of the status of the AF Signalling transmission path. To do so, the AF shall open an Rx Diameter session with the PCRF for the AF signalling using an AA-Request command. The AF shall provide the UE's IP address (using either the Framed-IP-Address AVP or the Framed-Ipv6-Prefix AVP) and the Specific-Action AVP requesting the subscription to "INDICATION_OF_LOSS_OF BEARER" and/or "INDICATION_OF_RELEASE_OF_BEARER". The AF shall additionally provide a Media-Component-Description AVP including a single Media-Sub-Component AVP with the Flow-Usage AVP set to the value "AF_SIGNALLING". The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0". If the procedures in clause 4.4.5A are not applied, the Media-Sub-Component AVP shall contain the Flow-Number AVP set to "0", and the rest of AVPs within the Media-Component-Description and Media-Sub-Component AVPs shall not be used in this case. When the PCRF receives an AA-Request as described in the preceding paragraph from the AF, the PCRF shall perform session binding as described in TS 29.213 and acknowledges the AAR command by sending an AA-Answer command to the AF. PCC/QoS Rules related to AF Signalling IP Flows should be provisioned to PCEF/BBERF using the corresponding procedures specified at 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. 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.

This clause is applicable when IMS restoration is supported according to supported feature ProvAFsignalFlow as described in clause 5.4.1. An AF may provision information about the AF signalling IP flows between the UE and the AF. To do so, the AF shall make use of an Rx Diameter session already opened with the PCRF if an Rx Diameter session related to the AF signalling is already established. The AF may modify an already open Rx Diameter session related to the AF signalling (e.g. an Rx Diameter session established for the purpose of subscription to notification of signalling path status as described in 4.4.5) or it may open a new Rx Diameter session related to the AF signalling if none exists. To provision the AF signalling flow information the AF shall provide the UE's IP address using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP. The AF shall additionally provide a Media-Component-Description AVP including one or more Media-Sub-Component AVP(s) representing the AF signalling IP flows. The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0". Each Media-Sub-Component AVP representing an AF signalling IP flow shall contain the Flow-Number AVP set according to the rules described in Annex B and one or two Flow-Description AVP(s) set to the IP flows of the AF signalling. Additionally, the Media-Sub-Component AVP shall include the Flow-Usage AVP set to the value "AF_SIGNALLING", the Flow-Status AVP set to "ENABLED" and the AF-Signalling-Protocol AVP set to the value corresponding to the signalling protocol used between the UE and the AF. When the PCRF receives from the AF an AA-Request as described in the preceding paragraph, the PCRF shall perform session binding as described in TS 29.213 and shall acknowledge the AAR command by sending an AA-Answer command to the AF. PCC/QoS Rules related to the AF signalling IP flows could have been provisioned to PCEF/BBERF using the corresponding procedures specified in 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. 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.

This clause is applicable when the PCRF-based P-CSCF Restoration Enhancement, as defined in TS 23.380, is supported by both P-CSCF and PCRF. The P-CSCF acting as AF shall send an AAR command including the Rx-Request-Type AVP set to the value PCSCF_RESTORATION (2) to the PCRF in the case P-CSCF Restoration needs to be performed. This AAR shall include the following information required by the DRA or PCRF to find the corresponding IP-CAN session:

• The UE's IP address as applicable in the Framed-IP-Address AVP or in the Framed-Ipv6-Prefix AVP. If the IP address is not unique (e.g. private IPv4 case), the P-CSCF shall also include the IP-Domain-ID AVP if available.
• If the IP address is not available or if the IP address is not unique and the IP-Domain-ID is not available, the P-CSCF shall include the IMSI in the Subscription-Id AVP and the APN in the Called-Station-Id AVP.

The AF shall also include the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1) in the AAR command, as described in IETF RFC 6733 [52]. As a consequence, the PCRF shall not maintain any state information about this session. The PCRF shall acknowledge the AAR command by sending an AAA command to the P-CSCF acting as AF and shall include the Auth-Session-State AVP set to NO_STATE_MAINTAINED (1). The PCRF shall send a request for P-CSCF Restoration to the PCEF for the corresponding IP-CAN session.

If PrioritySharing feature is supported, 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 as media flows which are assigned the same QCI in the PCRF belonging to other AF sessions for the same IP-CAN session that also contain the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED. If the MCPTT-Preemption feature 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 ARP values and include the Pre-emption-Control-Info AVP containing the pre-emption control information at the AAR command level for the PCRF to perform pre-emption control. The AF may also include the INDICATION_OF_FAILED_RESOURCES_ALLOCATION within Specific-Action AVP to request notification for resource allocation failure. Upon reception of this information, the PCRF shall behave as described in clauses 4.5.27 and 4a.5.17 of TS 29.212. For the handling of MCPTT sessions, see Annex A.13. If the AF earlier has indicated a media flow priority sharing to the PCRF by setting the Priority-Sharing-Indicator AVP to PRIORITY_SHARING_ENABLED, the AF may include the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_DISABLED within the Media-Component-Description AVP in order to indicate to the PCRF that the related media flow shall not be part of the mechanism for sharing the Allocation and Retention Priority with other media flows any longer. If this media flow was in priority sharing with other media flows the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in clauses 4.5.27 and 4a.5.17 of TS 29.212, and handle the media flow excluded from priority sharing according to normal PCC/QoS rule provisioning procedures described in clauses 4.5.2 and 4a.5.2 of TS 29.212. If the AF earlier has indicated media flow priority sharing to the PCRF by setting the Priority-Sharing-Indicator AVP to PRIORITY_SHARING_ENABLED for media flows and the AF indicates to remove one or more of the media flows in priority sharing with other media flows, the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in clauses 4.5.27 and 4a.5.17 of TS 29.212, and handle the media flow removed according to normal PCC/QoS rule provisioning procedures described in clauses 4.5.2 and 4a.5.2 of TS 29.212. 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, if the related media flow(s) was in priority sharing with other media flows the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing Allocation and Retention Priority as described in clauses 4.5.27 and 4a.5.17 of TS 29.212, and handle the media flow removed according to normal PCC/QoS rule provisioning procedures described in clauses 4.5.2 and 4a.5.2 of TS 29.212.

The support of the media component versioning is optional. When the MediaComponentVersioning feature is supported, the AF and the PCRF shall comply with the procedures specified in this subclause. If required by operator policies, the AF shall assign a content version to the media component related to certain service and provide the PCRF within the Content-Version AVP as part of the Media-Component-Description AVP. Upon each media component modification, if the content version was assigned to a media component, the AF shall assign a new content version. In this case, all the content related to that media component shall be included. The content version shall be unique for the lifetime of the media component. If the PCRF receives the Content-Version AVP including an content version for certain media component, the PCRF will follow the procedures described in subclause 4.5.28 and subclause 4a.5.18 of TS 29.212. When the PCRF is notified about the outcome of the resource allocation related to one content version of a media component as described in subclause 4.5.28 or subclause 4a.5.18 of TS 29.212 and if the PCRF is required to notify the AF, the PCRF shall provide the content version of the media component within the Content-Version AVP corresponding to the value of content version of the PCC/QoS rule and the status of the media component within the Media-Component-Status AVP corresponding to the status of the PCC/QoS rule to the AF as part of the Flows AVP. The PCRF shall include more than one Content-Version AVPs for the same media component within the Flows AVP in a RAR command if it has received multiple content versions as described in subclause 4.5.28 or subclause 4a.5.18 in TS 29.212.

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^32-1 bps instead of the bandwidth AVPs with a maximum value of 2^32-1 bps that represent bitrates in bps. 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.

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.

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.

For values lower or equal to 2^32-1 bps AVPs representing bitrates in bps shall be used. When the Rx session is being established, if the AF supports the corresponding feature (as listed above) and needs to indicate bandwidth values higher than 2^32-1 bps, AVPs representing bitrate in bps shall be provided with value set to 2^32-1 bps and bandwidth AVPs representing bitrate in kbps shall be provided with the actual required bandwidth.

The support of the MPSforDTS feature is optional. When the MPSforDTS feature is supported as described in clause 5.4.1, the AF and the PCRF shall comply with the procedures specified in this clause. MPS for DTS is the means for an AF to invoke/revoke the Priority EPS Bearer Service for the default bearer only, i.e. without designating a particular service data flow for priority service. MPS for DTS applies only to non-IMS APNs. To invoke/revoke MPS for DTS, the AF shall include the MPS-Action AVP in the AAR command. The MPS-Action AVP signals a change to the default bearer and IP flows mapped to the default bearer. When the MPS-Action AVP is set to ENABLE_MPS_FOR_DTS (1) and included in the AAR command, and if allowed by local policy, the PCRF does not check the user's MPS subscription details and shall upgrade the QoS of the default bearer to MPS, as specified in TS 29.212. When the MPS-Action AVP is set to AUTHORIZE_AND_ENABLE_MPS_FOR_DTS (2) and included in the AAR command, and if allowed by local policy, the PCRF shall check the user's MPS subscription details and if valid, shall upgrade the QoS of the default bearer to MPS, as specified in TS 29.212. If the request is not allowed, the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED. When the MPS-Action AVP is set to DISABLE_MPS_FOR_DTS (0) and included in the AAR command, and if allowed by local policy, the PCRF does not check the user's MPS subscription details and shall downgrade the QoS of the default bearer to non-MPS priority, as specified in TS 29.212. The AF may also include in the AAR command the Specific-Action AVP with the value SUCCESSFUL_QOS_UPDATE to request notification when the PCRF has successfully acted upon the invocation/revocation request indicated in the MPS-Action AVP. The PCRF shall inform the AF of successful MPS for DTS invocation/revocation with a RAR command with the Specific-Action AVP with the value SUCCESSFUL_QOS_UPDATE. The AF may also include in the AAR command the Specific-Action AVP with the value FAILED_QOS_UPDATE to request notification when the invocation/revocation request indicated in the MPS-Action AVP has failed. The PCRF shall inform the AF of the failure of the MPS for DTS invocation/revocation with a RAR command with the Specific-Action AVP with the value FAILED_QOS_UPDATE. When the PCRF receives from the AF an AA-Request as described in the preceding paragraphs, the PCRF shall perform session binding as described in TS 29.213 and shall acknowledge the AAR command by sending an AA-Answer command to the AF. The PCRF shall install the event trigger for the MPS for DTS request using the corresponding procedures specified in TS 29.212 if the AF requests the notification. The AF may use the procedure specified in clause 4.4.12 to establish a priority signalling IP flow between the UE and AF.

This clause is applicable when MPS for DTS is supported according to the supported feature MPSforDTS as described in clause 5.4.1. An AF may provision information about the AF signalling IP flows between the UE and the AF. To do so, the AF may modify an already open Rx Diameter session related to the AF signalling (e.g. an Rx Diameter session established for the purpose of DTS control as described in clause 4.4.11) or it may open a new Rx Diameter session related to the AF signalling if none exists. To provision the AF signalling flow information, the AF shall provide the UE's IP address using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP. The AF shall additionally provide the MPS-Identifier AVP and a Media-Component-Description AVP containing a Media-Component-Number AVP set to "0", and including a Media-Sub-Component AVP that contains the Flow-Description AVP set to the AF signalling IP flow. If the AuthorizationForMpsSignalling feature is supported, the AF shall provide the MPS-Action AVP set to value AUTHORIZE_AND_ENABLE_MPS_FOR_AF_SIGNALLING (3). The Media-Sub-Component AVP shall include the Flow-Number AVP set according to the rules described in Annex B and the Flow-Usage AVP set to the value "AF_SIGNALLING" and the Flow-Status AVP set to "ENABLED". When the PCRF receives from the AF an AA-Request as described in the preceding paragraph, the PCRF shall determine whether the request is accepted or not. If accepted, the PCRF shall perform session binding as described in TS 29.213 and shall acknowledge the AAR command by sending an AA-Answer command to the AF. If rejected, the PCRF shall indicate the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. The PCRF shall set appropriate QoS values for the AF signalling IP flow and install the corresponding dynamic PCC rule at the PCEF and the QoS rule at BBERF if applicable. 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 and QoS rule if applicable for the AF signalling IP flows.