Content for  TS 23.203  Word version:  19.0.0

Traffic steering control is triggered by the PCRF initiated request and consists in applying a specific (S)Gi-LAN traffic steering policy for traffic detected based on application level information or service data flow level information for the purpose of steering the subscriber's selected traffic to appropriate (S)Gi-LAN service functions deployed by the operator or 3rd party service provider. The PCRF uses one or more pieces of information such as network operator's policies, user subscription, user's current RAT, network load status, application identifier, time of day, UE location, APN, related to the subscriber session and the application traffic as input for selecting a traffic steering policy. The PCRF controls traffic steering in the PCEF, TDF or TSSF by provisioning and modifying traffic steering control information. Traffic steering control information consists of a traffic description and a reference to a traffic steering policy that is configured in the PCEF, TDF or TSSF. The PCEF, TDF or TSSF performs necessary actions to enforce the traffic steering policy referenced by the PCRF. For enforcing the traffic steering policy, the PCEF, TDF or TSSF may support traffic steering related functions as defined by other standard organizations. The mechanism used for routing the traffic between the service functions within the (S)Gi-LAN, is out of 3GPP scope. The traffic steering control may be deployed using PCEF only, using TDF only, or using TSSF only, or using a combination of PCEF/TDF and TSSF. When a combination of PCEF/TDF with traffic steering control feature and TSSF is deployed, the PCEF/TDF is utilized for application detection and packet marking while traffic steering is done using TSSF. In this case the PCC/ADC Rules provided to the PCEF/TDF for application detection shall be at application level while the traffic steering control information provided to the TSSF for traffic detection and steering control shall be at service data flow level only, i.e. the Application identifier and Traffic steering policy identifier shall be included over Gx/Sd reference point for detection of the traffic and packet marking, and the Service data flow filter(s) and Traffic steering policy identifier shall be included over St reference point for traffic steering control. The value used for packet marking at the PCEF/TDF (according to the Traffic steering policy identifier received from the PCRF) shall be the same as the one within the Service data flow filter (using filter information described in clause 6.2.2.2) that is sent to the TSSF and used for traffic steering. Alternatively, the Application Identifier may be used for traffic detection at the TSSF. In this case the value used for packet marking at the PCEF/TDF (according to the Traffic steering policy identifier received from the PCRF) shall be the same as the one configured in the TSSF for that Application Identifier.

To enable the usage of the same bearer, an AF may indicate to the PCRF that a media flow of an AF session is allowed to use the same priority as media flows belonging to other AF sessions (instead of the service priority provided for this media flow). In this case, the AF will provide a priority sharing indicator in addition to the application identifier and the service priority. For MCPTT, the service priority and the priority sharing indicator are defined in TS 23.179. The priority sharing indicator is used to indicate what media flows are allowed to share priority. The PCRF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC/QoS rule for every media flow as specified in clause 6.1.1.3. The application identifier and the service priority are used to calculate the ARP priority. The AF may also provide suggested pre-emption capability and vulnerability values per media flow to the PCRF. The ARP pre-emption capability and the ARP pre-emption vulnerability are set according to operator policies and regulatory requirements, also taking into consideration the application identifier and suggested values, when provided by the AF. The priority sharing indicator is stored for later use. For PCC/QoS rules with the same QCI assigned and having an associated priority sharing indicator, the PCRF shall try to make authorization and policy decisions taking the priority sharing indicator into account and modify the ARP of these PCC/QoS rules as follows, (the original ARP values are stored for later use):

• The modified ARP priority is set to the highest of the original priority among all the PCC/QoS rules that include the priority sharing indicator;
• The modified ARP pre-emption capability is set if any of the original PCC/QoS rules have the ARP pre-emption capability set;
• The modified ARP pre-emption vulnerability is set if all the original PCC/QoS rules have the ARP pre-emption vulnerability set.

If the PCRF receives an indication that a PCC/QoS rule provisioning or modification failed (due to resource reservation failure) then, the PCRF may apply pre-emption and remove active PCC/QoS rules from the PCEF and then retry the PCC/QoS rule provisioning or modification procedure. If the PCRF does not apply pre-emption, the AF is notified using existing procedures (as defined in clause 6.1.5) that the resource reservation for the new media flow failed. The AF may optionally provide pre-emption control information, including pre-emption capability and vulnerability values, in addition to the priority sharing indicator to the PCRF. If so, the PCRF shall apply pre-emption and remove active PCC/QoS rules according to this information when receiving an indication that a PCC/QoS rule provisioning or modification failed. The pre-emption control information indicates:

• whether media flows sharing priority are candidates to being pre-empted taking into account pre-emption capability and vulnerability values;
• how to perform pre-emption among multiple potential media flow candidates of same priority: most recently added media flow, least recently added media flow, media flow with highest requested bandwidth in the AF request.

The Management of Packet Flow Descriptions (PFDs) enables the PCEF and TDF to perform accurate application detection when PFDs are provided by an ASP (via the SCEF and the PFDF) and then to apply enforcement actions as instructed in the PCC/ADC Rule. The operator is able to configure pre-defined PCC/ADC Rules in the PCEF/TDF or dynamic PCC/ADC Rules in the PCRF that include at least an application identifier for service data flow or application detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both. Depending on the service level agreements between the operator and the Application Server Provider, it may be possible for the ASP to provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the PCEF/TDF via the SCEF and the PFDF. The PFDs become part of the application detection filters in the PCEF/TDF and therefore are used as part of the logic to detect traffic generated by an application. The ASP may remove or modify some or all of the PFDs which have been provisioned previously for one or more application identifiers. When a removed/modified PFD was used to detect application traffic related to an application identifier in a PCC/ADC Rule of an IP-CAN/TDF session and the PCEF/TDF has reported the application start as described in clause 4.5 to the PCRF for the application instance corresponding to this PFD, the PCEF/TDF shall report the application stop to the PCRF for the corresponding application instance identifier if the removed/modified PFD in PCEF/TDF results in that the stop of the application instance is not being able to be detected. Each PFD may be identified by a PFD id. A PFD id is unique in the scope of a particular application identifier. There may be different PFD types associated to an application identifier, see TS 23.682 for the definition of PFD. The PFDs may be retrieved by PCEF/TDF from PFDF in "pull" mode or may be provisioned from PFDF to the PCEF/TDF in "push" mode. When the "push" mode is used, the PFDF distributes PFDs for each application identifier to those PCEFs/TDFs that enable access to those applications. The PFDF may be configured with the list of PCEFs/TDFs where PFDs should be distributed. There are three methods to provision PFDs from the PFDF to the PCEF/TDF, as described in clause 7.12.2:

1. Push of whole PFDF state according to operator configuration in PFDF (e.g., provision per day according to operator configuration);
2. Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);
3. Selective push of an ASP change in the PFD set according to ASP request (i.e. ASP indicates to push changes in a PFD set within the time interval indicated by the Allowed Delay as described in TS 23.682).

The SCEF may be configured with a minimum allowed delay based on SLA to authorize the allowed delay provided by the ASP, as defined in TS 23.682. When the "pull" mode is used, at the time a PCC/ADC Rule with an application identifier for which PFDs provisioned by the PFDF are not available is activated or provisioned, the PCEF/TDF requests all PFDs for that application identifier from the PFDF. The PFDs retrieved for an application identifier from the PFDF are cached in the PCEF/TDF with an associated caching timer to control how long the PFDs are valid. When the caching timer elapses, if there are still active PCC/ADC rules that refer to the corresponding application identifier, the PCEF/TDF reloads the PFD(s) from the PFDF. When the PCEF/TDF removes the last PCC/ADC rule that refers to the corresponding application identifier, or when the caching timer expires and no PCC/ADC rule refers to the application identifier, the PCEF/TDF may remove the PFD(s) related with the application identifier. Within one PLMN, "push" mode only, "pull" mode only, or a combination of "pull" and "push" mode may be supported if the feature is supported. When the "pull" mode is used, the PFDF may provide to the PCEF/TDF a caching time value per application identifier. The PCEF/TDF receives the caching time value together with the PFD(s) from the PFDF over Gw/Gwn and applies this value for the application identifier instead of the configured default caching time value. In case no caching time value is received from PFDF, the PCEF/TDF uses the configured default caching time value. When only "pull" mode is supported in one PLMN, if the Allowed Delay is shorter than the caching time value stored for this application identifier, or shorter than the default caching time if no application-specific caching time is stored, the PFDF sends a response to SCEF with an indication that the Allowed Delay cannot be met. The PFDF may still store the PFD(s) and if so, indicate this to the SCEF. The PFDF shall also include the caching time value in the response to the SCEF. The SCEF shall forward the indication that the PFDF stored the PFD(s) (if available) and the caching time value to the ASP when informing that the Allowed Delay could not be met. If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from PFDF overrides any PFDs pre-configured in the PCEF/TDF. If all PFDs retrieved from the PFDF are removed for an application identifier, the pre-configured PFDs shall be applied again for the application identifier. The PCEF/TDF may differentiate the need for PFD retrieval based on operator configuration in the PCEF/TDF. The AF requests including an application identifier may trigger the activation or provisioning of a PCC/ADC Rule in the PCEF/TDF by the PCRF based on operator policies.

This feature, when activated by the user, prevents downlink traffic and may prevent uplink traffic via 3GPP access except for 3GPP PS Data Off Exempt Services. The 3GPP PS Data Off Exempt Services are a set of operator services, defined in TS 22.011, that are the only allowed services in downlink direction when the 3GPP PS Data Off feature has been activated by the user. When PCRF is deployed, it shall be configured with the list of 3GPP PS Data Off Exempt Services and the event trigger of 3GPP PS Data Off status change is used to inform the PCRF about every change of the 3GPP PS Data Off status. When the PCRF is informed about the activation of 3GPP PS Data Off, it shall update the PCC rules in such a way that only packets for services belonging to the list of 3GPP PS Data Off Exempt Services are forwarded while all other packets are discarded. When the PCRF receives service information from the AF, in addition to what is specified in clause 6.2.1.0, PCRF shall check if the requested service information belongs to the 3GPP PS Data Off Exempt Services. If the requested service belongs to 3GPP PS Data Off Exempt Services, PCRF shall continue as specified in clause 6.2.1.0. If the requested service doesn't belong to the 3GPP PS Data Off Exempt Services, PCRF shall reject the service request. When the PCRF is informed about the deactivation of 3GPP PS Data Off, it shall perform policy control decision as specified in clause 6.2.1.0 and perform PCC rule operations as specified in clause 6.3.2 2 to make sure that the services are allowed according to user's subscription and operator policy (irrespective of whether they belong to the list of 3GPP PS Data Off Exempt Services). When PCRF is not deployed, predefined PCC rules, as example, can be configured in the PCEF to ensure the following:

• when the PCEF is informed about activation of 3GPP PS Data Off, only packets for services belonging to the list of 3GPP PS Data Off Exempt Services are forwarded while all other packets are discarded. The list of 3GPP PS Data Off Exempt Services for UEs camping in HPLMN and the list of 3GPP PS Data Off Exempt Services for UEs camping in VPLMN can be different, and
• When PCEF is informed about deactivation of 3GPP PS Data Off, downlink packets are forwarded according to the operator policy for the subscriber.

When the UE 3GPP PS Data Off status is "active" and a handover from one access-system to another occurs, the PCRF performs the above operations so that the downlink traffic for services not belonging to the list of 3GPP PS Data Off Exempt Services is only prevented via the 3GPP access. When NBIFOM applies for the IP-CAN session, the PCRF shall not modify PCC rules associated to the IP-CAN type "Non 3GPP EPS".