NEF APIs, SCP routing, new NF onboarding, AF traffic influence, monitoring hooks, enterprise API monetisation
1. What Is the NEF — The Simple Version
The NEF (Network Exposure Function) is the 5GC’s controlled gateway to the outside world. Third-party application servers, enterprise platforms, and hyperscale clouds connect to the NEF to request network services: steer traffic to an edge server, subscribe to UE location events, request QoS boosts for specific sessions, or trigger network analytics. Without the NEF, these requests would require direct SBI access to core NFs — a security nightmare.
The NEF translates external Application Function (AF) requests into 5GC-native procedures. An AF sends a standard HTTP REST request to the NEF. The NEF authorises it, translates it into PCF policy, SMF traffic steering, or NWDAF analytics requests, and sends the result back to the AF. The AF never touches the core NFs directly.
| 3GPP Reference |
| 3GPP TS 23.502 Section 4.15 — NEF procedures |
| 3GPP TS 29.522 — Nnef_TrafficInfluence (edge traffic steering via NEF) |
| 3GPP TS 29.517 — Nnef_AMInfluence (RAN and mobility influence via NEF) |
| 3GPP TS 29.591 — Nnef_NonIPDataDelivery (IoT data delivery via NEF) |
2. Architecture — NEF API Portfolio
| NEF API | 3GPP Reference | What It Does | Example Use Case |
| Traffic Influence | TS 29.522 | AF requests UE traffic steered to specific DNAI/UPF | Edge gaming server: steer player traffic to closest edge DC |
| QoS Sponsorship | TS 29.122 | AF requests QoS boost (specific 5QI/GBR) for specific UE session | Video streaming: request GBR for premium subscriber video session |
| UE Reachability / Location | TS 29.122 | AF subscribes to UE location events (enter/leave geographic area) | Logistics: trigger workflow when delivery vehicle enters depot area |
| Monitoring Events | TS 29.122 | AF subscribes to network events: UE loss of connectivity, data usage threshold | IoT management: alert when device goes offline unexpectedly |
| Non-IP Data Delivery (NIDD) | TS 29.591 | NEF forwards small IoT data messages to/from UE without PDU session | Low-power IoT sensors sending periodic readings without full PDU session overhead |
| Background Data Transfer | TS 29.122 | AF requests network time window for background bulk transfers | OS update push to millions of devices at 03:00 during low-load period |
| AM Policy Influence | TS 29.517 | AF influences RAN mobility decisions — preferred frequency, RAT | Enterprise: keep devices on URLLC slice frequency; avoid handover to congested cell |
Table 1 — NEF API portfolio. Traffic Influence and QoS Sponsorship are the most commercially deployed. NIDD enables battery-optimised IoT without PDU session overhead.
3. How It Works — NEF Traffic Influence Flow
Here is what happens when an edge gaming application server requests traffic steering for a player entering edge coverage:
Step 1 — AF sends POST to NEF: POST /nnef-trafficinfluence/v1/subscriptions. Body: DNN=gaming, S-NSSAI=[SST:1,SD:0xGAME1], target DNAI=muscat-edge-01, traffic filter=[UE IP prefix 10.x.x.x], notificationUri=https://gaming-app.example.com/steering-events.
Step 2 — NEF validates: is this AF authorised for this DNN and DNAI? NEF authorisation policy (configured by operator) defines what each registered AF can request. Unauthorised request → 403 Forbidden.
Step 3 — NEF translates to PCF: Npcf_PolicyAuthorisation_Create. PCF creates a policy session with traffic routing to DNAI=muscat-edge-01 for matching UE sessions.
Step 4 — PCF → SMF: policy update for all active sessions matching DNN+S-NSSAI+UE filter. SMF inserts UL CL UPF at muscat-edge-01 for matching sessions. Traffic now flows locally.
Step 5 — NEF → AF: notification when steering is active. Notification includes: affected UE list, DNAI assigned, steering status. If UE moves outside DNAI coverage: NEF sends DNAI_CHANGE notification to AF so it can update game session routing.
4. SCP — Service Communication Proxy
The SCP (Service Communication Proxy) is an HTTP/2 proxy in the SBI path. It is optional but increasingly deployed in large GCC 5GC installations for three reasons: centralised observability (all inter-NF traffic visible at one point), circuit breaking (SCP detects failed NF and stops routing to it before timeout cascades), and load balancing (SCP distributes NF-to-NF calls across NF pools without each consumer NF doing load balancing individually).
| SCP Function | Benefit | Trade-off |
| Centralised NRF discovery | SCP caches NRF results centrally. All NFs route through SCP. | Consumer NFs do not need individual NRF caching logic. But SCP is a potential single point of failure. |
| Circuit breaking | SCP detects NF health degradation and stops routing to unhealthy NF instance before timeout. | Protects against cascade failure. Adds ~0.3ms per hop. |
| Load balancing | SCP distributes calls across NF instances using least-connections or weighted round-robin. | Simplifies NF client code. Adds hop. |
| Observability | All inter-NF traffic visible at SCP: latency, error rates, per-NF call volumes. | Single point for SBI metrics. But SCP becomes a monitoring dependency. |
| Rate limiting | SCP enforces per-NF-pair rate limits — protects NF from overload. | Prevents SMF from flooding UDM with N10 requests during storm scenarios. |
Table 2 — SCP functions and trade-offs. Deploy SCP if centralised observability and circuit breaking are priorities. SCP HA requires 3+ instances with active-active load balancing.
5. Key Parameters and Technical Terms
| Term | Definition | Operational Significance |
| AF (Application Function) | Third-party application server authorised to call NEF APIs. | Must be pre-registered in NEF with authorised DNN, S-NSSAI, DNAI, and API scope. Unauthorised AF = 403. |
| DNAI | Data Network Access Identifier — labels a UPF location (edge DC, on-premises). | NEF Traffic Influence uses DNAI to identify target edge UPF. SMF maps DNAI to UPF pool. |
| NEF Authorisation Policy | Per-AF policy defining which APIs, DNNs, S-NSSAIs, DNAIs, and UE ranges the AF can access. | Most restrictive part of NEF deployment. Must be designed with security team before AF onboarding. |
| NIDD | Non-IP Data Delivery. NEF forwards small IoT data directly to/from UE via NAS without PDU session. | Eliminates PDU session overhead for IoT sensors sending < 200 bytes periodically. Battery life ×3–10 improvement. |
| Background Data Transfer (BDT) | AF requests operator to perform bulk transfer during a network time window (e.g. off-peak). | Operator receives BDT request, plans optimal window, notifies AF. Enables coordinated CDN prefetch, OS updates. |
| SCP | Service Communication Proxy. HTTP/2 proxy for inter-NF SBI traffic. Optional but increasingly standard. | Centralises discovery, LB, circuit breaking. Adds one hop but enables better observability. |
| Indirect Communication Mode A | NF calls SCP; SCP forwards with NF-routing header to peer NF. | SCP does routing. Consumer NF just needs SCP endpoint. Simplest for NF developers. |
| Indirect Communication Mode B | NF calls SCP; SCP discovers and calls peer NF itself. | SCP fully responsible for routing. Consumer NF completely decoupled from peer NF topology. |
Table 3 — NEF and SCP parameters. NEF authorisation policy is the most operationally sensitive configuration — too permissive = API abuse; too restrictive = AF cannot deliver its service.
6. Common Issues in the Field
| Field Note: NEF AF Authorisation Too Broad — API Abuse |
| Operator onboarded an edge gaming AF with NEF authorisation for all DNNs and all S-NSSAIs. |
| Gaming AF sent traffic influence requests for enterprise URLLC slice UEs (not the gaming DNN). |
| SMF received PCF policy for URLLC UEs steered to gaming edge DC — incorrect. |
| Factory IoT devices briefly lost URLLC QoS profile as sessions modified. |
| Fix: restrict NEF authorisation to specific DNN=gaming and S-NSSAI=[SST:1,SD:0xGAME1]. |
| Principle of least privilege applies to NEF AF authorisation. |
| Field Note: SCP Single Instance — SBI Traffic Blackout During SCP Pod Restart |
| Operator deployed SCP in indirect communication mode with single SCP pod. |
| SCP pod restarted due to OOMKill (memory limit too low). |
| All inter-NF SBI traffic dropped for 28 seconds during pod restart. |
| AMF could not reach SMF, AUSF, UDM. 28-second total SBI blackout. |
| Fix: deploy SCP as minimum 3 replicas with HorizontalPodAutoscaler. |
| SCP is now a critical path component — must be HA from day one. |
7. Summary — Key Takeaways
| Topic | Key Takeaway |
| NEF purpose | Controlled gateway for external AF access to 5GC services. AF never touches core NFs directly. NEF enforces authorisation. |
| Traffic Influence | Most commercially deployed NEF API. AF → NEF → PCF → SMF → UL CL insertion at edge UPF. Works for transparent edge offload. |
| NEF authorisation | Principle of least privilege. Restrict each AF to specific DNN, S-NSSAI, DNAI, UE range. Never grant blanket access. |
| NIDD | Battery-life game-changer for IoT. Small messages via NAS without PDU session. Eliminates PDU session overhead for low-frequency sensors. |
| SCP HA | SCP in indirect communication mode becomes critical path. Deploy 3+ replicas with PDB. Single SCP pod = single point of failure for entire SBI. |
| SCP observability | Main operational benefit: all inter-NF traffic visible at SCP. Build Grafana dashboard for SCP metrics (per NF-pair error rate, latency P95, circuit breaker state). |
Table 4 — Post 18 summary. NEF is the monetisation API layer. SCP is the observability and resilience layer. Both require HA from day one.
Next: Post 19 — 5GC Operations & Lifecycle Management