NEF — Network Exposure Function¶
Learning objectives¶
- Explain that the role of the NEF is a "unified window that securely exposes the capabilities, events, and information inside the 5GC to the outside."
- Understand the mechanism by which the NEF stands at the boundary between the internal SBI and the external side, functioning as a secure gateway that separates inside from outside.
- Grasp that collaboration with external applications (AF) is carried out via the N33 interface / Northbound API.
- Organize the relationship between the 4G SCEF (Service Capability Exposure Function) and the NEF (evolution from the predecessor).
Prerequisites¶
- Basics of AF and SBA (Service Based Architecture) → Curriculum
- The role of the PCF, responsible for policy control → PCF
- The positioning of each interface → Interface dictionary
What you'll learn in this chapter¶
- Why: why a dedicated exposure window for external collaboration is needed.
- What: what the NEF exposes and what it mediates.
- How: how the NEF bridges inside and outside and ensures security.
Why — why it's needed¶
Letting external applications or third parties directly touch the internal NFs of the 5GC is extremely dangerous and also complex. The internal NFs are tightly coupled via the SBI of HTTP/2 + JSON over TLS, and if the internal structure were exposed to the outside as-is, security risks would increase and the implementation would become individually optimized. Therefore, a unified window that exposes internal capabilities securely and in an abstracted manner is needed. This is the NEF.
Analogy: Picture a company's reception / PR window. It receives requests from the outside, relays them to the appropriate department, and protects confidential information from leaving the company. Without the NEF, external collaboration would become an individual implementation per NF, and both security risks and management costs would increase.
Overview¶
The NEF exposes the capabilities and events held by internal NFs to external AFs, and at the same time mediates requests from external AFs (QoS requests, provisioning, etc.) to internal NFs. In that process, it takes on authentication (Authentication), authorization (Authorization), throttling (rate control), and data transformation between the internal and external formats, keeping the internal/external boundary secure. From the outside, it behaves as the "sole entrance to the 5GC."
Basic Concept — explanation for beginners¶
The NEF is easiest to understand as a "reception window with translation." An external visitor (AF) speaks in the outside language (Northbound API). Reception (the NEF) understands that language, translates it into the internal language (SBI), and relays it to the appropriate department (internal NF). It also translates the reply in the reverse direction and returns it to the outside. In this way, the NEF's basic function is to bridge the outside language and the inside language while protecting sensitive internal information from leaking out.
Network Function details¶
| Item | Content |
|---|---|
| Role | A capability-exposure gateway that securely exposes the capabilities, events, and information of internal NFs to external AFs / third parties, and mediates requests from the outside to the inside |
| Held information | Exposure policies, authorization information of AFs, temporary mapping between external IDs and internal IDs, etc. |
| Main APIs used | Calls the APIs of internal NFs: Npcf (PCF), Nudm/Nudr (UDM/UDR), Nsmf (SMF), etc. |
| APIs provided | Nnef (various Exposure functions: EventExposure, PFDManagement, ParameterProvision, ChargeableParty, AFsessionWithQoS, etc. — TS 29.522 / 23.502) |
| Related interfaces | N33 (AF⇔NEF), SBI (Nnef) |
| Impact on failure | External exposure and third-party collaboration stop. Internal core communication can continue, and the impact is limited to external collaboration (details to be confirmed) |
Architecture¶
flowchart LR
AF["AF (external app)"] -->|"N33 / Northbound API"| NEF["NEF (capability exposure)"]
NEF -->|"SBI (Nnef)"| PCF["PCF (policy)"]
NEF -->|"SBI"| UDM["UDM/UDR (subscriber)"]
NEF -->|"SBI"| SMF["SMF (session)"]
subgraph EXT["external domain"]
AF
end
subgraph CORE["5GC internal domain"]
NEF
PCF
UDM
SMF
end
How to read the diagram: The external AF on the left sends requests to the NEF through the N33 / Northbound API. The NEF transforms those requests into the internal SBI (Nnef) and mediates them to internal NFs such as the PCF, UDM/UDR, and SMF. It emphasizes that the NEF stands between the "external domain" and the "5GC internal domain" enclosed by dotted lines, functioning as a secure gateway that separates inside from outside.
Interface¶
| Interface | Connection | Description |
|---|---|---|
| N33 | AF ⇔ NEF | External exposure API (Northbound API) |
| SBI (Nnef) | internal NF ⇔ NEF | Internal collaboration |
For details, see the Interface dictionary.
Appearance in procedures¶
In many cases, the NEF appears in the context of external collaboration that lies "outside" basic procedures such as the Registration procedure and PDU session establishment. For example, a scenario in which an external AF issues a QoS request (such as a time-window guarantee) via the NEF, which is then reflected in the PCF's policy and applied to the SMF/UPF. This is positioned as an applied scenario rather than the basic procedure itself. For related content, see QoS and PCF. The specific details of the procedures are to be confirmed.
Comparison with EPC¶
The 4G SCEF (Service Capability Exposure Function) is the predecessor of the NEF. In 5G, the philosophy of capability exposure of the SCEF was inherited and developed into the NEF. During the transitional period of IoT migration, an SCEF+NEF configuration linking the SCEF and NEF is said to exist as well, but the details are to be confirmed.
| Generation | Function |
|---|---|
| 4G (EPC) | SCEF (Service Capability Exposure Function) |
| 5G (5GC) | NEF (Network Exposure Function) |
The philosophy of capability exposure is continuous from 4G, and the NEF is positioned as an extension of it.
Release differences¶
- Rel-15: The basic functions of the NEF were defined.
- Rel-16/17: The expansion of exposed API types progressed, and exposure of analytics (NWDAF collaboration), etc., is said to have been added (details to be confirmed).
3GPP Specification¶
- TS 23.501 §6.2.5: Functional definition of the NEF
- TS 29.522: Nnef (Northbound APIs) — individual section numbers to be confirmed
- TS 23.502: Capability exposure procedures — details to be confirmed
Summary¶
- The NEF is a unified window that securely exposes the capabilities, events, and information inside the 5GC to external AFs / third parties.
- It stands at the boundary between the internal SBI and the external side, functioning as a secure gateway responsible for authentication, authorization, throttling, and data transformation.
- Collaboration with external AFs is carried out via N33 / Northbound API, and internal collaboration is done over SBI (Nnef).
- The 4G SCEF is the predecessor of the NEF, and the philosophy of capability exposure is continuous from 4G.
- The impact on failure is limited to external collaboration, and internal core communication can continue (details to be confirmed).