6.2.3 Application Function (AF)

23.2033GPPPolicy and charging control architectureRelease 17TS

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.

NOTE 1: By using the end user IP address, an AF is not required to acquire any UE identity in order to provide information, for a specific user, to the PCRF.

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.

NOTE 2: The QoS authorization based on incomplete service information is required for e.g. IMS session setup scenarios with available resources on originating side and a need for resource reservation on terminating side.

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.

NOTE 3: The H-PCRF informs the AF of event triggers that cannot be reported. For detail see Annex L.

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.

NOTE 4: Additionally, existing bandwidth limitation parameters on Rx interface during the Rx session establishment are available in order to mitigate RAN user plane congestion.

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).