Content for  TS 23.203  Word version:  19.0.0

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 category;
• 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 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.

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.