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 220.127.116.11) 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.
Clause 6.1.18 refers to Network Based IP Flow Mobility as described in TS 23.161.
When PCC control for NBIFOM applies for an IP-CAN session:
Multiple IP-CAN types (3GPP EPS and Non 3GPP EPS) may be simultaneously associated with the same IP-CAN session.
The PCRF sends PCC rules including NBIFOM related information as defined in clause 6.3.1.
In UE-initiated NBIFOM mode this is based on Routing Rules received from the UE.
For network-initiated NBIFOM mode, the PCRF determines the NBIFOM related information for a PCC rule as defined in clause 18.104.22.168 (including information about UE requested mapping of IP flows to an access, Change of usability of an Access).
A change of access may trigger the modification of the charging key or the monitoring key in a PCC rule if access dependent charging or usage monitoring is required by the operator.
The PCRF decides whether NBIFOM applies for the IP-CAN session, based on information about the support for NBIFOM received from the PCEF and operator policies that may take into account subscription information.
The PCEF notifies the PCRF when an access is added or removed using the event trigger defined in clause 6.1.4.
The PCEF notifies the PCRF when an access becomes Unusable or Usable again or when the move-to-WLAN or move-from-WLAN event occurs, both events are notified to the PCRF using the event trigger "Change of the usability of an access" as defined in clause 6.1.4.
The PCRF may reject the NBIFOM Routing Rules received from the UE based on user subscription.
In following conditions the PCRF mentioned above is the H-PCRF:
The UE is served by its HPLMN, or
The PDN connection is served by a PGW in the Home PLMN (Home Routed roaming configuration), or
The PDN connection is served by a PGW in the V-PLMN (LBO configuration), and S9 is deployed and the V-PCRF supports NBIFOM. In that case, the V-PCRF acts as a relay of information.
The PCRF mentioned above is the V-PCRF in the case when, through roaming agreement, the HPLMN operator allows the VPLMN operator to operate the V-PCRF without S9; this includes authorization of roamers to use NBIFOM. In that case, network control related with subscription such as checking the total usage allowance does not apply.
In a multi access IP-CAN session, every PCC Rule is associated to one allowed access within the IP-CAN session. The information about the allowed access may be explicitly included in the PCC Rule, within the Allowed Access Type. Otherwise, the default NBIFOM access for the traffic on the IP-CAN session shall be applied as allowed access for a PCC rule. The bearer binding mechanism in the PCEF shall, in addition to the requirements defined in 22.214.171.124, ensure that a PCC Rule is associated to an IP-CAN bearer belonging to the allowed access.
The PCEF may provide the following information for each access in a multi access IP-CAN session:
Location of the subscriber as defined in clauses A.4, H.3 and H.4.
A serving PLMN identifier as defined in clauses A.4, H.3 and H.4.
RAT type as defined in clauses A.4, H.3 and H.4.
For the purpose of usage monitoring in the PCEF when NBIFOM applies for an IP-CAN session, the PCRF may receive an individual Monitoring key per access from SPR.
PCC support of NBIFOM requires following modifications to IP-CAN session procedures:
IP-CAN session establishment.
During the IP-CAN session establishment, the PCEF informs the PCRF about the UE and network support of NBIFOM and the requested NBIFOM mode (defined in TS 23.161). The PCRF takes a policy decision on whether NBIFOM may apply to the IP-CAN session (the hPCRF decides the NBIFOM mode according to TS 23.161) and informs the PCEF about its decision.
Addition of an access.
When the PCEF receives both a handover request and a NBIFOM indication from the UE, the PCEF initiates an IP-CAN Session Modification procedure, to:
Notify the PCRF about the addition of an access to the IP-CAN session together with the IP-CAN type and the RAT type of this access. If UE-initiated NBIFOM mode was selected at IP-CAN session establishment the notification contains also the default NBIFOM access selected by the UE.
Notify the PCRF with the NBIFOM Routing Rules, if the UE included Routing Rules with the access addition request in UE-initiated NBIFOM mode.
The PCRF takes policy decisions and communicates them to the PCEF:
The PCRF may reject the addition of the access if the multi-access IP-CAN session would correspond to an invalid combination of IP-CAN and RAT Types or is not allowed by the subscription. In this release of the specification the only allowed combination corresponds to the UE using a 3GPP access and a WLAN access.
If network-initiated NBIFOM mode was selected at IP-CAN session establishment, the PCRF indicates the default NBIFOM access to the PCEF.
In UE-initiated NBIFOM mode the PCRF verifies the default NBIFOM access provided by the UE. If it complies with the subscription the PCRF provides this default NBIFOM access to the PCEF. If not, the PCRF selects a different default NBIFOM access and provides it to the PCEF.
In UE-initiated NBIFOM mode, the PCRF may receive NBIFOM Routing Rules created by the UE. The PCRF may reject a NBIFOM Routing Rule due to subscription limitations. Otherwise, the PCRF determines for each NBIFOM Routing Rule the impacted PCC rule and provides or modifies this PCC rule.
The PCRF shall ensure that there is at least one PCC Rule that can be bound to the default bearer of each access.
Removal of an access.
When the PCEF is informed about the removal of an access of a multi-access IP-CAN session, the PCEF initiates an IP-CAN Session Modification procedure, to notify the PCRF about the removal of an access together with the IP-CAN type and the RAT type of this access. The PCRF determines the affected PCC rules and replies with updated PCC Rules or informs about the PCC Rules that are to be removed.
The PCC rules corresponding to the removed access are then modified or deleted by the PCEF accordingly. This shall not trigger the sending of Routing Rules deletion to the UE in Network-initiated NBIFOM mode.
Network-initiated IP flow mobility within a PDN connection (Network-initiated NBIFOM mode).
When a multi-access IP-CAN session has been set-up in Network-initiated NBIFOM mode, the PCRF may at any time determine that flows should be moved from a source access to a target access. In that case, the PCRF provides updated PCC Rules with a modified Allowed Access Type and the Routing Rule Identifier using an IP-CAN Session Modification procedure (i.e. the Allowed Access Type can be added, changed or removed).
The PCRF request triggers the sending of Routing Rules creation (when the Allowed Access Type is added) or Routing Rules modification (when the Allowed Access Type is changed) to the UE which may be rejected by the UE due to local radio conditions. In that case the PCRF gets notified which PCC rules cannot be modified. This notification from the PCEF contains an indication of the cause of the rejection received from the UE.
The PCRF request triggers the sending of Routing Rules deletion to the UE when the Allowed Access Type is removed.
UE-initiated IP flow mobility within a PDN connection (UE-initiated NBIFOM mode).
When the PCEF has received a request from the UE to create / modify / delete a Routing Rule, the PCEF initiates an IP-CAN Session Modification procedure and provides the Routing Rule received from the UE to the PCRF as an NBIFOM Routing Rule. The PCRF may reject an NBIFOM Routing Rule received from the UE due to subscription limitations. Otherwise the PCRF determines and updates the impacted PCC rule (as described in 6.12.2) and provides the updated PCC rule to the PCEF.
UE requested mapping of IP flows to an access (Network-initiated NBIFOM mode).
This procedure is only used in Network-initiated NBIFOM mode when the UE wants to request the network to apply specific mappings of IP flows to an access.
When the PCEF has received a request from the UE to have the network create / modify / delete a Routing Rule, the PCEF initiates an IP-CAN Session Modification procedure and provides the information received from the UE to the PCRF as an NBIFOM Routing Rule. The PCRF may reject an NBIFOM Routing Rule received from the UE due to subscription limitations. Otherwise the PCRF determines and updates the impacted PCC rule (as described in clause 6.12.2) and provides the updated PCC rule to the PCEF. The updated PCC rule triggers the sending of a Routing Rules creation / modification / deletion to the UE (as described above for Network-initiated IP flow mobility).
Indication that an access becomes unusable / usable again or indication of move-to-WLAN / move-from-WLAN (Network-initiated NBIFOM mode).
The PCEF initiates an IP-CAN Session Modification procedure to notify the PCRF about the change of usability of an access to the PCRF. For every PCC rule that is currently bound to this access, the PCRF shall either change the Allowed Access Type and provide the updated PCC rule to the PCEF or remove this PCC rule. This triggers the sending of Routing Rules modification to the UE. If the PCRF receives an indication that an access become usable again, The PCRF may update the PCC rules, e.g. by changing the Allowed Access Type and provide the updated PCC rules to the PCEF. This triggers the sending of Routing Rules modification to the UE.
Reporting Access Network Information to the AF.
The PCRF reports to the AF only Access Network Information associated with one access even though different media of the AF session are carried by different accesses.
If the PCRF has received a request for Access Network Information from the AF and PCC rules related with the AF request are bound to multiple accesses, the PCRF selects one PCC rule to be associated with Access Network Information reporting from the PCEF. The selected PCC rule should correspond to the 3GPP access: Using the 3GPP access reduces the risk of getting non-trustable location information from the S2b access of the IP-CAN session.
UE resource request for a multi-access IP-CAN session.
When the UE wants to request the network to allocate resources for one or more IP flows in the non-default NBIFOM access, the UE shall provide a corresponding Routing Rule in the same request in the UE-initiated mode. Without such Routing Rule, the network shall reject the UE resource request.
PCRF initiated IP-CAN session modification.
When network-initiated NBIFOM mode applies and the PCRF modifies the service data flow filter or precedence in a PCC rule for which a corresponding Routing Rule exists, the PCEF shall also modify this Routing Rule at the UE accordingly.
When network-initiated NBIFOM mode applies and the PCRF removes a PCC rule for which a corresponding Routing Rule exists, the PCEF shall also remove the corresponding Routing Rule at the UE.
When UE-initiated NBIFOM mode applies and if a new PCC rule is created due to the request from the network (e.g. request from the AF or application detection information from the PCEF/TDF), the PCRF shall determine that the new PCC rule is bound to the default access. UE may initiate IP flow mobility request to bind the IP flow to another access later.
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 126.96.36.199. 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:
Push of whole PFDF state according to operator configuration in PFDF (e.g., provision per day according to operator configuration);
Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);
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 188.8.131.52, 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 184.108.40.206. 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 220.127.116.11 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".