AF — Application Function¶

Difficulty: Beginner–Intermediate ／ Estimated study time: 15 min ／ Related NFs: PCF (policy-request target), NEF (window for untrusted AFs) ／ Related interfaces: SBI (Naf/N5)

Learning objectives¶

Understand that the AF plays the role of an application-side "request window" that conveys requests for communication quality and routing to the network.
Be able to explain the difference between trusted AFs and untrusted AFs, and their respective access paths.
Understand how the AF coordinates with the PCF (and, when untrusted, the NEF).
Grasp how the AF influences QoS requests and edge (local routing) steering.

Prerequisites¶

The role of the PCF, the center of policy control.
The role of the NEF, the window for untrusted AFs.
QoS, the concept of communication quality.
For the basics of SBA/SBI, see the Curriculum.

What you will learn in this chapter¶

Why: Why the differing communication-quality and routing requests of each application need to be conveyed to the network.
What: What requests (QoS/routing/charging influence) the AF passes, via which path, and to whom.
How: The flow in which a trusted AF requests the PCF directly and an untrusted AF requests via the NEF, and the PCF turns it into policy and applies it.

Why — Why it is needed¶

The communication quality and routing required differs per application. Requests vary — video streaming emphasizes bandwidth, online gaming emphasizes low latency, and so on. A "window" is needed to reflect such application-side requests into the network.

Analogy: The AF is like the "request window / sales representative" from the application industry to the network. Without the AF, there would be no means to ask the network for application-driven QoS adjustment or edge optimization.

Overview¶

The AF issues application requests (QoS, traffic routing, influence on charging policy, etc.). A trusted AF passes these directly to the PCF, and an untrusted AF passes them via the NEF. The PCF turns the received request into policy and applies it to the SMF/UPF. The AF is also involved in steering to the edge (local routing).

Basic Concept — Explanation for beginners¶

The AF is like a "sales representative" who receives application requests and bridges them to the network department. Requests from within the company (a trusted AF) are delivered as-is to the person in charge (the PCF), whereas requests from outside the company (an untrusted AF) are delivered after passing through reception (the NEF). In this way, application concerns and network concerns are connected safely.

Network Function details¶

Item	Content
Role	The application-side request window. Conveys QoS requests, traffic routing (edge steering), and influence on charging policy to the network.
Retained information	The application's session/flow requests, service identifiers, etc.
Main APIs used	The PCF's Npcf_PolicyAuthorization (QoS/routing requests). When untrusted, Nnef via the NEF.
Provided APIs	Application-specific. Handles responses/notification reception as Naf (the standardized scope is limited; to be confirmed).
Related interfaces	SBI (Naf). N5 with the PCF, N33 with the NEF.
Impact on failure	The network coordination of the relevant application (special QoS/edge steering) becomes impossible. Since basic communication continues, the impact is limited to the optimization of that application.

Architecture¶

flowchart LR
    AF_T["AF (trusted AF: application request)"]
    AF_U["AF (untrusted AF: application request)"]
    NEF["NEF (window for untrusted AFs)"]
    PCF["PCF (policy control)"]
    SMF["SMF"]
    UPF["UPF"]

    AF_T -->|N5| PCF
    AF_U -->|N33| NEF
    NEF --> PCF
    PCF --> SMF
    PCF --> UPF

How to read the diagram: A trusted AF delivers requests directly to the PCF over N5, and an untrusted AF delivers them to the PCF after passing through the NEF via N33. The PCF turns the received request into policy and applies it to the SMF/UPF, so that the application's request is applied to actual communication.

Interface¶

Interface	Connection	Use
N5 (SBI, Naf/Npcf_PolicyAuthorization)	AF ⇔ PCF	Requests from trusted AFs.
N33	AF ⇔ NEF	Requests from untrusted AFs.

For details, see the Interface dictionary.

Appearance in procedures¶

The AF appears in application-driven QoS changes. In the flow AF → PCF → SMF, it modifies the QoS Flow of a PDU session. For related content, see QoS, PDU Session Modification / Release, and NEF, the window for untrusted AFs. The detailed procedure is to be confirmed.

Comparison with EPC¶

In 4G/EPC too, the AF existed and requested the PCRF over the Rx interface (the P-CSCF of IMS and the like are representative AFs). In 5G, it became SBI-based and takes the form of requesting the PCF (a trusted AF directly, an untrusted AF via the NEF) (to be confirmed).

Generation	AF's request path
4G AF	Rx → PCRF
5G AF	Naf/N5 → PCF (an untrusted AF via the NEF)

Release differences¶

The basics were defined in Rel-15. In Rel-16/17, extensions such as edge computing coordination are said to have been made (to be confirmed).

3GPP Specification¶

TS 23.501 §6.2.10 defines the AF.
TS 23.503 = policy-related (AF influence / PolicyAuthorization) (to be confirmed).
TS 29.514 = Npcf_PolicyAuthorization (individual section numbers to be confirmed).

Summary¶

The AF is the application-side "request window," conveying QoS requests, routing, charging influence, and the like to the network.
A trusted AF requests the PCF directly from within the operator network, and an untrusted AF requests via the NEF.
The PCF turns the AF's request into policy and applies it to the SMF/UPF, so that the application's request is applied to actual communication.
The AF is also involved in edge (local routing) steering.
The 4G flow via Rx (addressed to the PCRF) became SBI-based in 5G and addressed to the PCF (trusted directly / untrusted via the NEF).