The Application Function (AF) is an element offering applications that require dynamic policy and/or charging control over the IP-CAN user plane behaviour. The AF shall communicate with the PCRF to transfer dynamic session information, required for PCRF decisions as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IM CN subsystem.
The AF may receive an indication that the service information is not accepted by the PCRF together with service information that the PCRF would accept. In that case, the AF rejects the service establishment towards the UE. If possible the AF forwards the service information to the UE that the PCRF would accept.
An AF may communicate with multiple PCRFs. The AF shall contact the appropriate PCRF based on either:
the end user IP Address; and/or
a UE identity that the AF is aware of.
In case of private IP address being used for the end user, the AF may send additional PDN information (e.g. PDN ID) over the Rx interface. This PDN information is used by the PCRF for session binding, and it is also used to help selecting the correct PCRF.
For certain events related to policy control, the AF shall be able to give instructions to the PCRF to act on its own, i.e. based on the service information currently available as described in clause 6.1.5.
The AF may use the IP-CAN bearer level information in the AF session signalling or to adjust the IP-CAN bearer level event reporting.
The AF may request the PCRF to report on IP-CAN bearer level events (e.g. the signalling path status for the AF session). The AF shall cancel the request when the AF ceases handling the user.
The AF may request the PCRF to report on the change of type of IP-CAN. The PCRF shall report the IP-CAN type and subsequent changes to the AF together with the information of the Radio Access Technology Type (e.g. UTRAN) as defined in access specific annexes. The change of the Radio Access Technology Type (e.g. UTRAN) shall be also reported to the AF, even if the IP-CAN type is unchanged.
The AF may request the PCRF to report any combination of the user location and/or UE Timezone at AF session establishment, modification or termination. For AF session termination the communication between the AF and the PCRF shall be kept alive until the PCRF report is received.
The AF may request the PCRF to report changes of the PLMN identifier where the UE is currently located at AF session establishment. The PLMN identifier reporting remains until the AF session is terminated.
If IP-CAN bearer resources corresponding to the AF session are released, the PCRF reports to the AF, if available, the reason why IP-CAN bearer resources are released i.e. RAN/NAS Release Cause, TWAN Release Cause or UWAN Release Cause.
If IP-CAN bearer resources corresponding to the AF session are released, the PCRF reports to the AF, if available, the User Location Information and/or the UE Timezone.
To support sponsored data connectivity (see Annex N), the AF may provide the PCRF with the sponsored data connectivity information, including optionally a usage threshold, as specified in clause 5.2.1. The AF may request the PCRF to report events related to sponsored data connectivity.
If the user plane traffic traverses the AF, the AF may handle the usage monitoring and therefore it is not required to provide a usage threshold to the PCRF as part of the sponsored data connectivity information.
In order to mitigate RAN user plane congestion, the Rx reference point enables transport of the following information from the PCRF to the AF:
Re-try interval, which indicates when service delivery may be retried on Rx.
When receiving service information from the AF, the PCRF may temporarily reject the AF request (e.g. if the service information is not consistent with the operator defined policy rules for the congestion status of the user). To temporarily reject the AF request the PCRF shall indicate a re-try interval to the AF. When receiving a re-try interval from the PCRF 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 AF may contact the PCRF via the SCEF (and the Nt interface) to request a time window and related conditions for future background data transfer (as described in clause 6.1.16). If the PCRF replies with more than one transfer policy, the AF shall select one of them and inform the PCRF about the selected transfer policy. The reference ID provided by the PCRF shall be used by the AF during every subsequent transfer of AF session information related to this background data transfer (via the Rx interface).
The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The SPR may be combined with or distributed across other databases in the operator's network, but those functional elements and their requirements for the SPR are out of scope of this document.
The SPR may provide the following subscription profile information (per PDN, which is identified by the PDN identifier):
Subscriber's allowed services;
For each allowed service, a pre-emption priority;
Information on subscriber's allowed QoS, including the Subscribed Guaranteed Bandwidth QoS;
Subscriber's charging related information (e.g. location information relevant for charging);
Subscriber's User CSG Information reporting rules;
List of Presence Reporting Area identifiers and optionally the elements for one or more of the Presence Reporting Areas;
Subscriber's usage monitoring related information;
MPS EPS Priority and MPS Priority Level;
IMS Signalling Priority;
Subscriber's profile configuration indicating whether application detection and control can be enabled.
Spending limits profile containing an indication that policy decisions are based on policy counters available at OCS that has a spending limit associated with it and optionally the list of policy counters.
The SPR may provide the following sponsored data connectivity profile information:
A list of Application Service Providers and their applications per sponsor identity.
If the IMS Signalling Priority is set, it indicates that the IMS Signalling Bearer and the Default Bearer are assigned ARP appropriate for MPS at the time of the establishment of the PDN connection for IMS, i.e. EPS Attach or PDN Connectivity Request.
The SPR may provide the following policy information related to an ASP (see clause 6.1.16):
The ASP identifier;
A transfer policy together with a reference ID, the volume of data to be transferred per UE, the expected amount of UEs and the network area information.
The Online Charging System (OCS) performs online credit control functions as specified in TS 32.240.
The OCS may trigger the PCEF to initiate an IP-CAN bearer service termination at any point in time.
There may be several OCSs in a PLMN. The default OCS addresses (i.e. the primary address and secondary address) shall be locally pre-configured within the PCEF and TDF. OCS addresses may also be passed once per IP-CAN session or TDF session from the PCRF to the PCEF or TDF. The OCS addresses provided by the PCRF shall have a higher priority than the pre-configured ones.
The Offline Charging System is specified in TS 32.240.
There may be several OFCSs in a PLMN. The default OFCS addresses (i.e. the primary address and secondary address) shall be locally pre-configured within the PCEF and TDF. OFCS addresses may also be passed once per IP-CAN session or TDF session from the PCRF to the PCEF or TDF. The addresses provided by the PCRF shall have a higher priority than the pre-configured ones.
The service data flow detection at the BBERF is identical to the detection at PCEF with the following modifications:
If the service data flow is tunnelled at the BBERF, the BBERF uses information on the mobility protocol tunnelling header provided by the PCRF and the QoS rules to detect the service data flows.
For the uplink direction, the BBERF applies QoS rules with a bearer binding to the bearer that the packet arrived on. The uplink bearer binding verification is successful if there is a QoS rule with a matching uplink SDF filter. The BBERF shall discard packets for which the uplink bearer binding verification fails.
The ARP, GBR, MBR and QCI are used by the BBERF in the same way as in the PCEF for resource reservation.
When access network is not utilizing QCI based QoS parameters, the BBERF shall be able to convert a QoS class identifier value to QoS attribute values used in the access network and determine the QoS class identifier value from a set of QoS attribute values used in the access network.
The BBERF controls the QoS that is provided to a combined set of service data flows. BBERF ensures that the resources which can be used by an authorized set of service data flows are within the "authorized resources" specified via the Gxx interface by "authorized QoS". The authorized QoS provides an upper bound on the resources that can be reserved (GBR) or allocated (MBR) for the service data flows.
In order to support the different IP-CAN bearer establishment modes (UE-only or UE/NW), the BBERF shall support the same procedures for handling different IP-CAN bearer establishment modes as specified for the PCEF in clauses 22.214.171.124 and 126.96.36.199.
The UDR is a functional entity that acts as a single logical repository storing user data. As such it may contain all subscriber/subscription related information needed by the PCRF. In deployment scenarios where the UDR is used it replaces the SPR. The UDR provides a unique reference point to fetch these subscriber/subscription data. This reference point is named Ud. More information on the UDR can be found in TS 23.335.
The SPR data listed in clause 6.2.4 are stored in the UDR, the information model remains unspecified.
The TDF is a functional entity that performs application detection and reporting of detected application and its service data flow description to the PCRF. The TDF supports solicited application reporting and/or unsolicited application reporting. The application detection filter may be extended with the PFDs provided by the PFDF as described in clause 6.1.20. The new PFDs provided by the PFDF replace the existing ones in the PCEF.
The TDF shall detect Start and Stop of the application traffic for the ADC rules that the PCRF has activated at the TDF (solicited application reporting) or which are pre-provisioned at the TDF (unsolicited application reporting). The TDF shall report, unless the notification is muted for the specific ADC Rule in case of solicited application reporting, to the PCRF:
For the Start of application event trigger: the application identifier and, when service data flow descriptions are deducible, the application instance identifier and the service data flow descriptions to use for detecting that application traffic with a dynamic PCC rule as defined in clause 6.1.4.
For the Stop of application event trigger: the application identifier and if the application instance identifier was reported for the Start, also the application instance identifier as defined in the clause 6.1.4.
For solicited application reporting, the PCRF can request the TDF to also perform enforcement actions, charging and usage monitoring.
For those cases where service data flow description is not possible to be provided by the TDF to the PCRF, the TDF performs:
for the detected applications.
For those cases where service data flow description is provided by the TDF to the PCRF the actions resulting of application detection may be performed by the PCEF as part of the charging and policy enforcement per service data flow as defined in this document or may be performed by the TDF.
The TDF shall support usage monitoring as specified in clause 4.4 and the usage reporting functions as specified in clause 188.8.131.52 for the PCEF.
The TDF shall support data volume, duration, combined volume/duration and event based measurement for charging. The Measurement method indicates what measurement type is applicable for the ADC rule.
The TDF measurement measures all the user plane traffic, except packets discarded by ADC-rule enforcement or due to MBR-enforcement.
The TDF shall maintain a measurement per TDF session and Charging Key combination.
If Service identifier level reporting is mandated in an ADC rule, the TDF shall maintain a measurement for that Charging Key and Service identifier combination, for the TDF session.
If there are required events which cannot be monitored in the TDF (e.g. related to the location changes), the TDF shall request the information about these Event Triggers from the PCRF using either:
The IP-CAN Session Establishment procedure, as defined in clause 7.2, or
The PCEF initiated IP-CAN Session Modification procedure, as defined in clause 7.4.1, or
In the response to a PCRF initiated IP-CAN Session Modification, as defined in clause 7.4.2, or
Within the Update of the subscription information in the PCRF procedure, as defined in clause 7.5.
For unsolicited application reporting, the TDF performs only application detection and reporting functionality but neither enforcement actions nor usage monitoring. The TDF should handle each IPv4 address and IPv6 prefix, assuming the max prefix length used in the access network, within a separate TDF session. The PCRF shall, if needed, correlate TDF sessions that correspond to the same IP-CAN session.
The TDF shall support traffic steering as specified in clause 6.1.17.
When the PCRF provides a Traffic Steering Policy Identifier(s) in an ADC rule, the TDF shall enforce the referenced traffic steering policy for the application. A traffic steering policy is locally configured and can be used for the uplink, the downlink or for both directions.
To enforce the traffic steering policy, the TDF performs deployment specific actions as configured for that traffic steering policy. The TDF may for example perform packet marking where, for the traffic identified by the Application Identifier or by the service data flow filter list (defined by an active ADC rule), the TDF provides information for traffic steering, as part of the packets, to the (S)Gi-LAN. This information for traffic steering identifies, explicitly or implicitly, a specific set of service functions and their order via which the traffic needs to be steered in the (S)Gi-LAN.
A RAN Congestion Awareness Function (RCAF) is an element which reports RAN User Plane Congestion Information (RUCI) via the Np interface to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for policy decisions. The RCAF sends the RUCI to the PCRFs serving the UEs' PDN connections as follows:
For a PDN connection in a non-roaming scenario the RCAF reports the RUCI to the PCRF.
For a PDN connection in a local breakout scenario, based on operator configuration, the RCAF reports the RUCI to the V-PCRF.
For a PDN connection in a home routed scenario, based on the roaming agreement with the HPLMN and operator configuration, the RCAF reports the RUCI to the H-PCRF.
The RCAF determines whether a given PDN connection is served in a local breakout or a home routed roaming scenario based on the APN operator identifier received as part of the APN information from the MME or the S4-SGSN as documented in TS 23.401 and TS 23.060, respectively.
In addition if the RCAF detects that a UE is no longer subject to congestion (i.e. the UE is no longer detected in any of the congested cells that the RCAF is monitoring) then the RCAF shall indicate the no congestion state to the PCRFs serving the UE.
Any RUCI changes shall be reported by RCAF unless reporting restrictions apply.
The RCAF maintains a context on per UE and per APN basis. The context is identified by the IMSI and the APN. It contains the following information:
The previously reported congestion level over the Np reference point.
The reporting restrictions received from the PCRF. The reporting restrictions are stored by the RCAF until the PCRF explicitly signals to remove the reporting restrictions.
The logical PCRF id received from the PCRF to identify the PCRF that is the Np destination for the RCAF when sending aggregate messages.
A Service Capability Exposure Function (SCEF) is an element which provides a means to securely expose the services and capabilities provided by 3GPP network interfaces (for further details see TS 23.682).
The TSSF is a function that receives traffic steering control information from the PCRF and ensures that the related traffic steering policy is enforced in the (S)Gi-LAN.
A traffic steering policy is locally configured in TSSF and can be used for uplink, downlink or for both directions. To ensure that the traffic steering policy is enforced, the TSSF performs deployment specific actions as configured for that traffic steering policy. For example, the TSSF may configure traffic detection and forwarding entities in the (S)Gi-LAN to fulfil the traffic steering policy.
A Packet Flow Description Function (PFDF) is an element which stores PFDs associated with an application identifier and transfers them to the PCEF/TDF via Gw/Gwn interface to enable the PCEF/TDF to perform application detection when the PFDs are managed by a 3rd party SP.
The PFDF receives PFDs for an application identifier from the SCEF as defined in TS 23.682.