N33 — NEF ⇔ AF (Nnef Northbound API reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N33 is an SBI (Service Based Interface) whose actual form is the Nnef Northbound API (TS 29.522) provided by the NEF.
• Explain that N33 is the gateway through which an untrusted external AF safely uses 5GC capabilities, and that its role differs from N5 (direct PCF connection) used by trusted AFs.
• Explain that the NEF performs authentication/authorization, data transformation, and internal-NF concealment, bridging AF requests to the internal NFs (PCF/UDM/SMF, etc.).
• List example capabilities handled over N33 (monitoring event subscription, device triggering, AF influence, provisioning).
• Explain the correspondence with 4G (EPC) SCEF + T8 API (TS 29.122).

Prerequisites¶

Understanding the following first will make this smoother:

• The positioning of SBA / SBI and HTTP/2・TLS → Protocol dictionary
• The NFs/functions at both ends of N33 → NEF / AF
• How capability exposure (Exposure), AF influence, and QoS requests are used → QoS
• The concept of interfaces and reference points → Interface dictionary

Why — Why it is needed¶

Outside the 5GC there are many external applications that the operator network does not trust (third-party IoT platforms, content providers, business-application vendors, etc. = external AFs). These have requests such as "I want to know when a certain device comes online," "I want to wake up a specific terminal (trigger)," or "I want to give priority QoS to this video flow." However, connecting such external, unvetted applications directly to the internal NFs (PCF/UDM/SMF, etc.) is out of the question for security reasons.

Therefore, a reception desk / firewall must be placed between the external AF and the internal NFs, exposing capabilities only through it. This is N33. The external AF accesses only the NEF over N33, and the NEF performs identity verification (authentication/authorization), data transformation, and concealment of internal NFs before relaying the request to the internal NFs. Without N33, there would be no way to safely open 5GC capabilities to external AFs, and capability exposure (Exposure) itself would not be feasible.

Analogy: N33 is the reference point through which external application vendors (external AFs) safely use 5GC functions across a reception desk (the NEF). The desk verifies identity, translates, and conceals the internal map before relaying to the back office (internal NFs), never letting the vendor walk directly into the premises.

Overview¶

N33 is the reference point connecting AF (external, untrusted) ⇔ NEF. N33 is an SBI (Service Based Interface) and uses HTTP/2 + JSON (RESTful) over TLS as its common transport.

The actual form of N33 is the Nnef Northbound API (TS 29.522) that the NEF provides toward the outside. "Northbound" here means the API facing toward the external AF side (the upper layer) from the NEF's viewpoint. The external AF calls this API, and the NEF authorizes and transforms the received request before bridging it to the corresponding service of an internal NF (PCF/UDM/SMF, etc.).

As an important distinction, a trusted AF needs no intermediary and connects directly to the PCF over N5 (Npcf_PolicyAuthorization). By contrast, an untrusted external AF can access only via N33/NEF. N33 plays the role of "safe gateway," and N5 that of "trusted direct line."

Basic Concept — Beginner-friendly explanation¶

Let us liken N33 to the interaction between an external vendor and a reception desk.

Suppose an external application vendor (external AF) thinks: "In our service, I want a notification when this terminal connects to the network," "I want to wake up this terminal remotely," or "I want to give priority bandwidth to this video." The vendor cannot just walk into the 5GC back office (internal NFs), so it first submits its request to the reception desk (the NEF) (N33).

The desk first performs identity verification (is this vendor really under contract, and does it have the authority to request this operation? = authentication/authorization), then translation (converting the vendor's language into the internal format = data transformation), and further concealment of the internal map (not showing the vendor which department = internal NF handles the processing = internal-NF concealment), before relaying to the responsible internal party (PCF/UDM/SMF, etc.). The desk also returns the responsible party's answer back to the vendor.

The interaction with this desk is not over a dedicated telephone line (a dedicated protocol like N2 or N4); rather, it is like submitting requests and receiving answers over an internal web system (HTTP). This is the mechanism of SBI (Service Based Interface) = conversing via web APIs (HTTP/2), where both requests and responses are exchanged in human-readable JSON.

Protocol / Transport¶

Architecture¶

This shows the context in which N33 connects the external (untrusted) AF and the NEF, the NEF bridges to internal NFs (PCF/UDM/SMF, etc.), while a trusted AF connects directly to the PCF over N5.

flowchart LR
  extAF["AF (external, untrusted)"]
  NEF["NEF (exposure GW)"]
  Core["Internal NFs (PCF/UDM/SMF)"]
  trustAF["AF (trusted)"]
  PCF["PCF"]

  extAF == "N33 (Nnef Northbound API)" ==> NEF
  NEF -. "Npcf/Nudm etc." .-> Core
  trustAF -. "N5" .-> PCF

  classDef gw fill:#efe,stroke:#3a3,stroke-width:2px;
  class NEF gw;

How to read the diagram: The thick line (==>), N33, is the gateway connecting the untrusted external AF and the NEF (the exposure gateway). The NEF authorizes and transforms the received request and, as shown by the dotted lines, relays it to the internal NFs (PCF/UDM/SMF, etc.). By contrast, a trusted AF needs no NEF intermediary and connects directly to the PCF over N5. Note the difference in path: "untrusted AF = via N33/NEF" versus "trusted AF = direct via N5/PCF."

Usage Procedure¶

N33 is used when an external AF wants to use published 5GC capabilities and issues a request to the NEF.

• Monitoring event subscription: The external AF requests over N33 that the NEF "notify me of events such as reachability, location, or loss detection of a specific terminal." The NEF converts and mediates to internal NFs (UDM/AMF, etc.) and, when an event occurs, notifies the AF (notify).
• Device triggering / parameter provisioning: The external AF requests over N33 the waking (triggering) of a terminal or the configuration of subscriber-related parameters (provisioning). The NEF bridges to the corresponding internal NF.
• AF influence (QoS/routing requests): The external AF requests over N33 priority QoS for a specific flow or influence over traffic routing. After authorization, the NEF mediates to the PCF side (AF influence / QoS request).

Common to all is that the AF talks only to the NEF, and the existence and structure of the internal NFs are concealed by the NEF. The NEF handles authentication, authorization, data transformation, and concealment, converting and mediating the AF's request to the internal NFs.

Because the details of the procedures (message sequences, conditions, IEs, exact operation names, etc.) differ by Release, they are individually to be confirmed. For the applied context of AF influence and QoS requests, see QoS.

Main Messages¶

Because N33 is SBI, messages take the form of HTTP method + resource operation (RESTful operations rather than a procedureCode like NGAP). Representative service operations (conceptual examples) are as follows.

The HTTP-operation mapping is a conceptual arrangement: The service operation names and "HTTP operations" in the table above are representative examples and mappings for understanding; the exact methods, resource URIs, invocation directions, and operation names follow the OpenAPI definitions of TS 29.522. Strict assignments are to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

Because N33 is SBI, it is observed in captures as HTTP/2 (L4-dedicated protocols like NGAP/SCTP do not appear).

Points to watch when decoding:

• N33 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body), a decryption key (TLS session key, etc.) is required. Without the key, it appears only as an encrypted tls payload.
• Once decrypted, you can identify operations by the HTTP/2 headers (:method = POST, etc.; :path containing a resource path such as .../nnef-.../...) (exact paths are implementation/Release dependent, to be confirmed).
• The body is JSON (subscription conditions, notification content, QoS requests, etc.), laid out in a human-readable structure.
• Unlike NGAP on N2 (binary, over SCTP), the key to observing N33 is that it is web-like (HTTP/JSON). SCTP-specific filters are not used.

Comparison with EPC¶

• In 4G: External capability exposure was handled by the SCEF (Service Capability Exposure Function), which interworked with external SCS/AS (≈ external AFs) over the T8 API (TS 29.122). However, on the internal-NF side of the SCEF (HSS/MME/PGW, etc.), the interfaces were a mix of Diameter, OMA-DM, etc.; only the externally facing T8 was a REST-like API.
• In 5G: The NEF inherits the SCEF's role, and the external-facing API (T8 equivalent) was turned into an SBI and organized as N33 (Nnef Northbound API, TS 29.522). While the philosophy of capability exposure (monitoring, triggering, provisioning, AF influence, etc.) continues, the gateway for external AFs is unified into HTTP/2 + JSON (SBI).

The philosophy of capability exposure (Exposure) itself continues from 4G (SCEF/T8). The main change in 5G is that the gateway for external AFs is turned into an SBI (HTTP/2+JSON) and organized under the NEF.

3GPP Specification¶

• 3GPP TS 29.522 — Nnef Northbound API (capability exposure, N33). Specific clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical specification / design principles and OpenAPI). Specific clause numbers are to be confirmed
• 3GPP TS 23.501 §4 — System architecture and reference points (definition of N33/NEF)
• 3GPP TS 23.502 — Procedures (Exposure-related procedures). Specific clause numbers are to be confirmed
• 3GPP TS 33.501 — SBI security (TLS, external-AF authorization, etc.). Specific clause numbers are to be confirmed

Note (to be confirmed): That the actual form of N33 is the Nnef Northbound API (TS 29.522), that the common SBI framework is the TS 29.500/29.501 family, and that the reference point N33 and the service Nnef are two views of the same interworking are general characterizations of the 3GPP architecture. Because the exact names, methods, resource URIs, and detailed clause numbers of each service operation differ by Release, they are individually to be confirmed.

Summary¶

• N33 is the reference point connecting AF (external, untrusted) ⇔ NEF, and it is an SBI (Service Based Interface) (HTTP/2 + JSON over TLS).
• Its actual form is the Nnef Northbound API (TS 29.522) provided by the NEF. Reference point N33 = service Nnef Northbound API are two views of the same AF⇔NEF interworking.
• N33 is the gateway through which an untrusted external AF safely uses 5GC capabilities. The NEF performs authentication/authorization, data transformation, and internal-NF concealment and bridges to internal NFs (PCF/UDM/SMF, etc.).
• Example published capabilities = monitoring event subscription, device triggering, AF influence (QoS/routing), provisioning. A trusted AF needs no intermediary and connects directly to the PCF over N5.
• It corresponds to 4G SCEF + T8 API (TS 29.122), and in 5G it was turned into an SBI (TS 29.522) under the NEF.

Next Step¶

• NEF — The internal side of N33. The exposure gateway (authentication/authorization, transformation, concealment)
• AF — The external side of N33. The distinction between trusted AFs (direct via N5) and untrusted AFs (via N33)
• N5 — The direct reference point for trusted AF ⇔ PCF. Contrast its role with N33
• QoS — The applied context of AF influence / QoS requests
• Interface dictionary — Confirming reference points / Message dictionary / Protocol dictionary