The 5G Core is no longer designed only for person-to-person communications. Connected vehicles, smart factories, smart campuses, remote healthcare, drones, and many other vertical-industry applications increasingly need to influence network resources dynamically according to service conditions or obtain authorized network status information from the operator. If every new requirement required an operator to manually modify configurations across the AMF, SMF, PCF, UDM, and other network functions, large-scale 5G deployment across vertical industries would be extremely difficult.

This is where the NEF, or Network Exposure Function, comes in. It sits between the 5GC and application functions, or AFs, converting internal core network capabilities into standardized interfaces that external applications can use. At the same time, it handles security control, information translation, and parameter delivery. For third-party applications, the NEF acts as a controlled gateway into the operator's 5G Core capability framework rather than simply serving as a basic API gateway.

Why 5GC Needs the NEF

The 4G business model was largely B2C-oriented: the network provided connectivity, and subscribers used mobile Internet access to reach different applications. With 5G, the model has expanded toward B2B2X. The network must now support not only individual users but also deeper, automated interaction with platforms used in manufacturing, transportation, campuses, healthcare, and other vertical industries.

This creates an important question: how can industry applications use operator network capabilities in a way that is both secure and standardized?

Consider an industrial company that wants production terminals in a specific area to receive more predictable QoS, or wants application traffic to be steered toward a local data network closer to the factory. Without a unified capability exposure mechanism, the application platform might have to connect directly to multiple core network functions and implement different configurations for different vendors. That would increase integration complexity and expose more internal core network interfaces.

The NEF creates a common boundary between industry applications and the 5GC. An external AF does not need to understand every internal detail of the AMF, SMF, PCF, UDM, or UPF. It only needs to submit a standards-compliant service request through the NEF. The NEF then interacts with the appropriate 5GC network functions and returns the result to the application side.

This approach converts some requirements that would otherwise depend on manual coordination and static configuration into standardized service calls, allowing operators to expose network capabilities to partners in a more automated manner.

Where the NEF Sits in 5GC

The NEF is deployed between 5GC network functions and AFs. An AF is an application-layer functional entity responsible for business logic. It may be a trusted application owned or managed by the operator, or a third-party application platform located outside the operator's trust domain. A third-party application cannot be given unrestricted access to internal core network functions, so controlled interaction is handled through the NEF.

From an interface perspective, the NEF effectively connects two different environments. Northbound, it serves AFs such as video platforms, connected-vehicle platforms, and industrial control systems. Southbound, it connects to internal 5GC network functions and communicates with entities such as the SMF, PCF, and UDM according to the service being requested.

The NEF evolved from the SCEF used in 4G, but the scope is significantly broader. SCEF was mainly associated with specific IoT use cases, while the NEF in 5GC supports a much wider range of human-centric and machine-centric applications and has become an important part of the service-based capability exposure framework.

By design, the NEF does much more than forward messages. Its core responsibilities include exposing network capabilities and events, securely provisioning information from external applications into the 3GPP network, translating information between external and internal formats, and receiving data from other network functions for storage or later re-exposure when required.

Some information received by the NEF can be stored in the UDR, which means it does not have to remain tied to a single NEF instance. The NEF can also support PFD functionality, providing the basis for more accurate application detection and policy processing.

How Five Key Capabilities Are Exposed

The value of the NEF ultimately comes from the services it can expose. In practical 5GC deployments, its main capabilities can be grouped into five areas: QoS exposure, network event subscriptions, traffic steering, parameter provisioning, and PFD management. These functions correspond to some of the most common interaction requirements between industry applications and operator networks.

QoS Capability Exposure

QoS capability exposure allows a partner application to request specific service quality for a particular service flow. For example, a video application may already be running over an existing PDU session. If the user selects a higher-quality video service, the AF can use the NEF to request enhanced QoS for that traffic flow.

After receiving the request, the NEF coordinates with core network functions such as the PCF. The PCF then applies policy logic and works with the SMF and other network resources to establish the appropriate QoS treatment for the service flow.

The key point is not simply to assign more bandwidth to the device. The objective is to let an application express its service requirements through a standardized interface while keeping policy decisions and network resource enforcement under the control of the 5GC.

Mobility and Network Event Subscriptions

A third-party AF can also use the NEF to subscribe to UE-related network events, such as whether a UE has lost connectivity, whether it has become reachable again, its current or last known location, roaming status, communication failure reasons, and downlink data delivery status.

These events are detected by different core network functions. The AMF can detect UE reachability, loss of connectivity, and certain communication failures. The UDM can provide information such as roaming status or specific identity-association changes, while the SMF can report conditions related to downlink data delivery.

The AF does not need to connect directly to every network function. Instead, it creates an event subscription through the NEF. The NEF then establishes the necessary internal subscription with the relevant network function. When the target event occurs, the core network notifies the NEF, and the NEF forwards the event notification to the external AF according to the subscription.

This mechanism is particularly useful for industry applications that need to trigger automated business logic based on device status. Instead of continuously polling the network for UE state, the external platform can receive a notification when the relevant event actually occurs.

Traffic Steering

The NEF can also receive Traffic Influence requests from an AF and steer traffic for a specific UE or service toward a Local DN, or Local Data Network. A Local DN is identified by a DNAI and is commonly associated with edge-computing or regionally deployed services.

In an automated factory, for example, an industrial control server may be deployed in a local network close to the production site. The application platform can request through the NEF that the 5GC adjust the user-plane path so that relevant device traffic is routed toward the appropriate Local DN.

The NEF does not directly control the UPF. Instead, it sends the requirement into the policy-control process. The PCF and SMF then handle policy and user-plane configuration. Depending on the situation, the SMF can reselect the UPF or add, replace, or remove UPFs in the existing path to complete the traffic-steering operation.

Secure Parameter Provisioning

An external AF can also use the NEF to provide certain user-related parameters to the 5GC. This does not mean that the application is allowed to modify core network parameters freely. The range of information that can be provisioned is strictly controlled.

Typical examples include Expected UE Behaviour and selected Network Configuration Parameters. Expected UE Behaviour can describe anticipated mobility characteristics of a device, while network configuration parameters may include information such as maximum response time, acceptable downlink data transmission delay, or the recommended number of downlink packets to buffer when the UE is unreachable.

The NEF forwards authorized parameter requests to the UDM, which works with the UDR to read and update the relevant data. The AMF or other network functions that have subscribed to those data changes can then receive the updated parameters for subsequent network processing.

PFD Management

PFD, or Packet Flow Description, can be understood as a set of rules used for application detection. A third-party AF can create application identification information through the NEF. The resulting rules may be stored in the UDR, retrieved by the SMF through the NEF, and then delivered to the UPF for application detection.

Compared with identifying traffic only by basic ports or addresses, PFDs can describe more specific application characteristics. A video service, for example, may be identified by a particular URL pattern or other traffic characteristics, allowing the network to map the traffic more accurately to the appropriate policy-processing rules.

The Real Technical Value of the NEF

From an architectural perspective, the most important role of the NEF is not to add another forwarding node. Its real purpose is to create a manageable capability exposure layer. External AFs see service-oriented interfaces, while the actual work inside the 5GC continues to be performed by functions such as PCF policy control, SMF session management, UDM data management, and UPF user-plane processing.

This is why the NEF should not be viewed as an ordinary API gateway. It must understand the relationship between external business requests and 3GPP core network capabilities, while handling security control, information translation, and process coordination between the two sides.

The NEF also does not replace other network functions. QoS enforcement still depends on policy control and session resource configuration. Network events are still detected by the appropriate NF. User-plane paths are still adjusted by functions such as the SMF, and user-related data continues to be maintained by the UDM and UDR. The NEF's role is to expose these internal capabilities in a controlled and standardized manner.

This capability is especially important for 5G B2B2X services. Industry applications do not need to understand the complete internal topology of the 5GC or build proprietary interfaces to every network function. They can submit network requirements through standardized exposure mechanisms. At the same time, the operator retains control of the core network boundary while turning selected network capabilities into services that trusted partners can use.

In practical terms, the NEF helps the 5G Core evolve from a network that primarily provides connectivity into a platform capable of exposing network capabilities directly to industry applications.

Frequently Asked Questions

Do all AFs have to be deployed outside the operator network?

No. An AF may be a trusted application owned or managed by the operator, or it may be a third-party application outside the operator's trust domain. Access methods and security handling can differ depending on the type of AF.

Is business data always stored locally in the NEF?

No. Some information received by the NEF can be stored in the UDR and later used by other network functions or subsequent procedures. Data storage therefore does not have to remain tied to a single NEF instance.

Is a Local DN the same as a UPF?

No. A Local DN is a local data network that hosts specific applications or data services, while the UPF is a 5GC user-plane network function. Traffic can be routed through an appropriate UPF path to reach a designated Local DN, but the two serve different roles.

Does the UPF create PFD rules by itself?

No. PFD rules can be provided by an AF and managed through the NEF. The SMF retrieves the relevant rules and delivers them to the UPF for more accurate application detection in the user plane.