N5 — AF ⇔ PCF (Npcf_PolicyAuthorization Reference Point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N5 is an SBI (Service Based Interface) and that its substance is the service Npcf_PolicyAuthorization (TS 29.514) provided by the PCF.
• Distinguish that N5 is the window through which a trusted AF requests directly from the PCF, whereas an untrusted AF requests indirectly via N33 (through the NEF).
• Explain what the AF requests from the PCF over N5 (QoS requirements, traffic routing (edge steering), and influence over charging policy).
• Explain the flow whereby the PCF, on receiving the AF request, reflects it into PCC rules and reflects them to the SMF/UPF via N7.
• Explain how it corresponds to 4G (EPC) Rx (AF ⇔ PCRF, Diameter).

Prerequisites¶

It will go more smoothly if you understand the following first.

• The positioning of SBA / SBI and HTTP/2・TLS → Protocol dictionary
• The NFs at both ends of N5 → AF / PCF
• The path by which the PCF hands PCC rules to the SMF → N7
• The path by which an untrusted AF goes through the NEF → N33 / NEF
• How QoS (5QI/QFI) is used → QoS
• The concept of an interface and a reference point → Interface dictionary

Why — why it is needed¶

The application side (e.g., service platforms for video distribution, cloud gaming, video calls = AF) has wishes such as "I want this app's traffic to flow at high quality (low latency, wide bandwidth)," "I want this user's traffic steered to a nearby edge server," and "I want this communication charged specially." However, an AF cannot arbitrarily set the network's QoS or charging.

Therefore, a path for the AF to convey requests — "please treat things this way for this app" — to the PCF, the arbiter of operator policy, is needed. This is N5. The PCF receives the AF's request, reconciles it against operator rules, authorizes it, then reflects it into PCC rules (instruction sheets) and drives them down to the SMF via N7 and further to the UPF. Without N5, the path to reflect the app's needs into network policy would be lost, and fine-grained, app-driven QoS control and edge steering would be impossible.

However, this "direct road" is opened only to trusted AFs that the operator trusts. Untrusted AFs such as third parties request indirectly, going through the reception window of the NEF (N33) rather than directly.

An analogy: N5 is a dedicated line by which the app's sales rep (AF) conveys requests directly to the policy-rules department (PCF). Precisely because it is a trusted party within the company, it can convey requests directly, without going through reception (the NEF): "please treat this service this way." Requests from untrusted outsiders must always go through reception (NEF/N33).

Overview¶

N5 is the reference point connecting AF ⇔ PCF. N5 is an SBI (Service Based Interface) and uses HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N5 is the service Npcf_PolicyAuthorization (TS 29.514) provided by the PCF. A trusted AF invokes this service to request directly from the PCF the QoS requirements, traffic routing (edge steering), and influence over charging policy for a specific app. The PCF authorizes this and reflects it into PCC rules, then drives them down to the SMF via N7 (Npcf_SMPolicyControl), and the SMF to the UPF.

Meanwhile, an untrusted AF cannot use N5 directly; it issues its request through the API exposed by the NEF (N33), and the NEF bridges it to the PCF. The division of roles is: N5 is "the direct line for trusted AFs," and N33 is "the reception-mediated path for untrusted AFs."

Basic Concept — a beginner-friendly explanation¶

Let us liken N5 to a direct request from the app's sales rep to the rules department.

Suppose a certain app service (AF) thinks, "I want our video calls to flow at low latency," "I want this user connected to a nearby edge server." The AF conveys these wishes directly to the PCF, the operator's rules department (a request via Npcf_PolicyAuthorization). The PCF compares them against the company's rules and subscriber data, judges whether it can authorize the wishes, and drives the authorized content down into PCC rules (instruction sheets). These instruction sheets go to the SMF via N7, and the SMF sets the UPF (the pipe): "flow this app's traffic at this quality, over this path."

However, only trusted parties (trusted AFs) can make these direct requests. An untrusted external app (an untrusted AF) issues its wishes through the reception window (NEF / N33) rather than directly. Reception checks the content, and if there is no problem, relays it to the PCF.

This AF request, too, is not a dedicated phone line but rather the image of throwing a request via a Web API (HTTP) and getting an answer back. This is SBI (Service Based Interface) = the mechanism by which NFs converse via Web APIs (HTTP/2), with both requests and responses exchanged in JSON.

Protocol / Transport¶

Architecture¶

This shows N5 connecting the AF and the PCF, the two-path arrangement whereby an untrusted AF goes via N33 (the NEF), and the context in which the AF request the PCF obtains is reflected to the SMF over N7 and further to the UPF.

flowchart LR
  AF["AF (trusted, app request)"]
  NEF["NEF (reception)"]
  UAF["AF (untrusted)"]
  PCF["PCF"]
  SMF["SMF"]
  UPF["UPF (forwarding)"]

  AF == "N5 (Npcf_PolicyAuthorization)" ==> PCF
  UAF -. "N33" .-> NEF
  NEF -. "relay" .-> PCF
  PCF == "N7 (Npcf_SMPolicyControl)" ==> SMF
  SMF == "N4 (PFCP)" ==> UPF

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class AF,PCF ctrl;

How to read the diagram: N5 on the thick line (==>) is the trusted AF⇔PCF direct request (SBI/HTTP2). An untrusted AF goes via the dotted-line N33 through the NEF (reception), and the NEF relays it to the PCF. The PCF authorizes the AF request and reflects it into PCC rules, then to the SMF over N7, and the SMF to the UPF over N4 (PFCP) (the thick line on the right). Note the division of roles: N5 is "the entrance for wishes from the app," and N7 is "the road that reflects the result into the session."

Procedures that use it¶

N5 is used when an app (AF) requests QoS, traffic routing, and charging influence from the PCF for a specific application flow.

• Policy Authorization Create: the AF requests from the PCF by specifying the app's communication requirements (QoS requirements, routing to the edge, charging influence). The PCF authorizes and reflects them into PCC rules.
• Policy Authorization Update: when the app's requirements change, the AF updates its request content.
• Policy Authorization Delete: when the app's request is no longer needed, the authorization is released.
• Notify (notification, PCF→AF): the PCF notifies the AF of session state (QoS notifications, resource allocation results, etc.).

Having received the AF's request, the PCF updates it as a PCC rule within the flow of PDU Session Modification / Release and reflects it to the SMF via N7. The reflected QoS/routing is set on the UPF as a QoS Flow (QFI/5QI) per QoS.

Because the details of the procedure (message sequence, conditions, IEs, exact operation names) differ by release, they are to be confirmed; for details, see the links above and PDU Session Modification.

Main Messages¶

Because N5 is SBI, its messages take the form of HTTP method + resource operation (RESTful operations rather than a procedureCode like NGAP). The representative service operations are as follows.

The HTTP-operation mapping is a conceptual organization: the "HTTP operation" in the table above is a mapping for understanding; the exact method, resource URI, and invocation direction of each operation follow the OpenAPI definitions of TS 29.514. The strict method assignment is to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

Because N5 is SBI, it is observed in a capture as HTTP/2 (L4-dedicated protocols such as NGAP/SCTP or PFCP do not appear).

Decode highlights:

• N5 is encrypted with TLS. To see the contents (the HTTP/2 headers and JSON body), a decryption key (a TLS session key, etc.) is needed. Without the key, it is visible only as the encrypted payload of tls.
• If you can decrypt, you can identify the operation from the HTTP/2 headers (:method = POST, etc.; the resource path with :path containing .../npcf-policyauthorization/...).
• The body is JSON (QoS requirements, media component information, routing requests, charging influence, etc.), packed in a human-readable structure.
• Unlike N2's NGAP (binary, over SCTP), the key to observing N5 is that it is Web-like (HTTP/JSON). Do not use SCTP/PFCP-specific filters.

Comparison with EPC¶

• In 4G: requests by which an application function (AF) influenced policy and charging were made to the PCRF (Policy and Charging Rules Function) over the Rx interface (Diameter-based) (TS 29.214). Over Rx, the AF conveyed QoS/charging requests to the PCRF according to the app's media flows.
• In 5G: the PCF took over the PCRF's role, and the Rx equivalent was turned into an SBI as N5 (Npcf_PolicyAuthorization). The framework in which a trusted AF requests directly from the PCF continues, while it was replaced from Diameter with HTTP/2 + JSON (SBI) (TS 29.514). The distinction that an untrusted AF goes via the NEF (N33) was clarified.

The very idea that the AF influences policy and charging continues from 4G. The main change in 5G is that the Diameter-based dedicated IF (Rx) was turned into an SBI (HTTP/2+JSON), and the distinction of trusted-AF direct (N5) / untrusted-AF via the NEF (N33) was organized.

3GPP Specification¶

• 3GPP TS 29.514 — The Npcf_PolicyAuthorization service (AF⇔PCF, N5). Individual clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical rules / design principles and OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 23.501 §4 — System architecture and reference points (definition of N5)
• 3GPP TS 23.503 — Policy and charging control framework (PCC framework, the policy model of AF influence)
• 3GPP TS 33.501 — SBI security (TLS, etc.). Individual clause numbers are to be confirmed

Note (to be confirmed): That the substance of N5 is Npcf_PolicyAuthorization (TS 29.514), that the SBI common framework is the TS 29.500/29.501 series, that the reference point N5 and the Npcf service are two views of the same coordination, and the distinction of trusted-AF direct / untrusted-AF via the NEF (N33) are general organizations of the 3GPP architecture. Because the exact methods, resource URIs, and detailed clause numbers of each service operation differ by release, they are individually to be confirmed.

Summary¶

• N5 is the reference point connecting AF ⇔ PCF, an SBI (Service Based Interface). Its protocol is HTTP/2 + JSON (RESTful) over TLS.
• Its substance is the PCF's service Npcf_PolicyAuthorization (TS 29.514). The duality of reference point N5 = service Npcf_PolicyAuthorization is the same as with N7.
• N5 is the window through which a trusted AF requests QoS, traffic routing (edge steering), and charging influence directly from the PCF. An untrusted AF requests indirectly via N33 (through the NEF).
• The PCF authorizes the AF request and reflects it into PCC rules, driving them down to the SMF via N7 and further to the UPF.
• It corresponds to 4G's Rx (AF ⇔ PCRF, Diameter, TS 29.214), and in 5G it was turned into an SBI (TS 29.514).

Next Step¶

• PCF — the counterpart of N5. The policy hub that reflects AF requests into PCC rules
• AF — the application function that requests QoS/routing/charging influence from the PCF over N5
• N33 — the path by which an untrusted AF makes policy requests via the NEF (contrast with N5)
• N7 — the road by which the PCF hands PCC rules to the SMF (the exit of the N5 request)
• QoS — the mechanism of the QoS Flow (QFI/5QI) into which AF requests are reflected
• Interface dictionary — to check reference points