From Point-to-Point to Service-Based
The 4G Evolved Packet Core (EPC) used dedicated point-to-point interfaces between network elements -- S1-MME between eNB and MME, S11 between MME and SGW, S5/S8 between SGW and PGW. Each interface had its own protocol (GTPv2-C, Diameter, etc.), making the system rigid. Adding a new feature often required updating multiple interfaces simultaneously.
The 5G Core (5GC) introduced the Service-Based Architecture (SBA) defined in 3GPP TS 23.501 and TS 29.500. In SBA, every control-plane Network Function (NF) exposes its capabilities as services through RESTful APIs over HTTP/2. Any NF can discover and consume services from any other NF through a common framework. This approach was directly inspired by cloud-native microservices architecture used by hyperscalers like Google and Netflix.
SBA vs Point-to-Point Architecture
| Dimension | EPC Point-to-Point (4G) | 5GC Service-Based Architecture |
|---|---|---|
| Interface model | Dedicated reference points (S1, S5, S6a, etc.) | Common SBI with per-NF service APIs |
| Protocol | GTPv2-C, Diameter, S1AP (mixed) | HTTP/2 + JSON (unified) |
| Discovery | Static configuration or DNS | Dynamic NRF-based discovery |
| Adding new NF | Requires new interface specs | New NF registers services with NRF |
| Communication pattern | Request-response only | Request-response + Subscribe-Notify |
| Load balancing | Proprietary or diameter agent | SCP-based or NRF-assisted |
| API versioning | Protocol version in spec (e.g., GTPv2) | URI-based versioning (v1, v2) |
| Encryption | IPSec (transport layer) | TLS 1.2/1.3 per hop |
| Vendor interop | Interface-specific IOT testing | OpenAPI 3.0 spec compliance |
| Specification body | Multiple TS per interface | TS 29.5xx series (unified) |
This shift reduced the number of distinct protocol implementations and enabled operators to deploy NFs from different vendors on the same SBI bus -- a key enabler of multi-vendor 5GC.
HTTP/2 Service Operations
Every NF service is defined by an OpenAPI 3.0.0 specification published in the 3GPP TS 29.5xx series. The table below lists the key NF services, their specification, and primary operations.
| NF | Service Name | 3GPP Spec | Key Operations | HTTP Method |
|---|---|---|---|---|
| NRF | Nnrf_NFManagement | TS 29.510 | NFRegister, NFUpdate, NFDeregister | PUT, PATCH, DELETE |
| NRF | Nnrf_NFDiscovery | TS 29.510 | NFDiscover (query NFs by type, slice, etc.) | GET |
| AMF | Namf_Communication | TS 29.518 | N1N2MessageTransfer, UEContextTransfer | POST |
| AMF | Namf_EventExposure | TS 29.518 | Subscribe/Notify for UE events | POST, DELETE |
| SMF | Nsmf_PDUSession | TS 29.502 | CreateSMContext, UpdateSMContext, ReleaseSMContext | POST, PATCH |
| UDM | Nudm_SDM | TS 29.503 | SDM_Get (subscription data), SDM_Subscribe | GET, POST |
| UDM | Nudm_UECM | TS 29.503 | Registration, Deregistration | PUT, PATCH |
| PCF | Npcf_SMPolicyControl | TS 29.512 | SMPolicyCreate, SMPolicyUpdate, SMPolicyDelete | POST, PATCH, DELETE |
| AUSF | Nausf_UEAuthentication | TS 29.509 | Authenticate (5G-AKA, EAP-AKA) | POST |
| NEF | Nnef_EventExposure | TS 29.522 | Subscribe to network events for AF | POST |
| NSSF | Nnssf_NSSelection | TS 29.531 | NSSelectionGet (slice selection) | GET |
| CHF | Nchf_SpendingLimitControl | TS 29.594 | SpendingLimitSubscribe, SpendingLimitNotify | POST |
| NWDAF | Nnwdaf_AnalyticsInfo | TS 29.520 | AnalyticsInfoRequest, AnalyticsSubscription | GET, POST |
| SCP | N/A (routing layer) | TS 29.500 | Indirect communication delegation | N/A |
NRF Discovery Flow -- Step by Step
The NRF (NF Repository Function) is the backbone of dynamic NF discovery. Here is the complete flow when an AMF needs to discover an SMF.
Step 1 -- NF Registration (bootstrap):When an SMF instance starts, it sends an HTTP PUT request to the NRF at /nnrf-nfm/v1/nf-instances/{nfInstanceId}. The request body contains the NFProfile including NF type (SMF), S-NSSAIs served, DNNs supported, FQDN, IP addresses, capacity, load, and supported features.
The NRF validates the profile and stores it. It returns 201 Created with the complete profile. The SMF receives a heartbeat timer value (default 60 seconds per TS 29.510).
Step 3 -- Consumer NF queries NRF:The AMF needs an SMF for a PDU session. It sends: GET /nnrf-disc/v1/nf-instances?target-nf-type=SMF&requester-nf-type=AMF&snssai={"sst":1,"sd":"000001"}&dnn=internet
The NRF filters registered SMF instances by the query parameters and returns a SearchResult containing an array of NFProfiles ranked by priority and capacity. The response includes a validity period for caching.
Step 5 -- Consumer selects and invokes:The AMF selects the highest-priority SMF from the list and invokes its Nsmf_PDUSession service directly.
Worked Example -- NRF Discovery Query and Response
An AMF in T-Mobile's Dallas region needs an SMF for S-NSSAI {SST=1, SD=0x000001} and DNN "internet":
Request:`
GET /nnrf-disc/v1/nf-instances?target-nf-type=SMF&snssai={"sst":1,"sd":"000001"}&dnn=internet&preferred-locality=dallas
`
Response (simplified):
- SMF-1: FQDN smf-01.dallas.5gc.t-mobile.com, priority=10, capacity=80, load=45%
- SMF-2: FQDN smf-02.dallas.5gc.t-mobile.com, priority=10, capacity=80, load=62%
- SMF-3: FQDN smf-03.houston.5gc.t-mobile.com, priority=20, capacity=80, load=30%
The AMF selects SMF-1 (same locality, lowest load among equal-priority instances). If SMF-1 fails, SMF-2 is the fallback. SMF-3 in Houston is a cross-region backup with lower priority.
Operator data -- Deutsche Telekom: At their 2024 5GC operations summit, Deutsche Telekom reported their NRF handles approximately 15,000 discovery requests per second across their German network, with a P99 response latency of 4 ms. They cache discovery results for 300 seconds at consuming NFs, reducing NRF load by approximately 85%.Direct vs Indirect Communication
SBA supports two communication models defined in TS 29.500:
Direct Communication (Model A): The consumer NF discovers the producer NF via NRF and communicates directly. Simple but requires every NF to handle discovery, selection, and retry logic. Indirect Communication via SCP (Model C/D): The consumer sends requests to the Service Communication Proxy (SCP), which performs discovery, routing, and load balancing. This offloads complexity from individual NFs.| Aspect | Direct (Model A) | Indirect via SCP (Model C/D) |
|---|---|---|
| Discovery | Consumer queries NRF | SCP queries NRF on behalf of consumer |
| Load balancing | Consumer selects from NRF results | SCP performs weighted routing |
| Retry on failure | Consumer implements retry | SCP handles failover transparently |
| Observability | Per-NF logging | Centralized at SCP |
| Latency | One fewer hop | +0.5--1 ms per SCP hop |
| Operational overhead | Lower (no SCP deployment) | Higher (SCP must be HA) |
| Adoption | Early 5GC deployments | Recommended for production scale |
SBA vs Service Mesh Comparison
Operators and vendors frequently compare 5G SBA to the service mesh pattern used in cloud-native applications (e.g., Istio, Linkerd). The comparison is instructive but reveals important differences.
| Feature | 5G SBA (3GPP) | Service Mesh (Istio/Envoy) |
|---|---|---|
| Service discovery | NRF (dedicated NF) | Control plane (istiod) + sidecar |
| Load balancing | SCP or consumer-side | Envoy sidecar per pod |
| Mutual TLS | OAuth2 tokens + TLS per TS 33.501 | mTLS via sidecar certificates |
| Observability | SCP/NRF logging | Distributed tracing (Jaeger, Zipkin) |
| Traffic routing | SCP delegated routing | VirtualService / DestinationRule CRDs |
| Specification | 3GPP TS 29.500 | CNCF open-source projects |
| Sidecar required | No (SCP is separate) | Yes (Envoy per pod) |
| Protocol | HTTP/2 mandatory | HTTP/1.1, HTTP/2, gRPC |
Some vendors, including Nokia (with their Cloud Mobility Manager) and Samsung, have implemented SCP using Envoy proxies under the hood. This hybrid approach uses 3GPP-compliant SBI externally while leveraging service mesh tooling internally for observability and traffic management.
Worked Example -- API Versioning in Practice
3GPP uses URI-based API versioning. When the SMF API evolves from v1 to v2 in a new release:
- v1 base URI:
/nsmf-pdusession/v1/sm-contexts - v2 base URI:
/nsmf-pdusession/v2/sm-contexts
- SMF registers both v1 and v2 in its NFProfile with the NRF
- AMF queries NRF for SMF and specifies
supported-featuresfor v1 - NRF returns SMFs that support v1 (backward compatible)
- AMF continues using
/nsmf-pdusession/v1/sm-contextswithout disruption - When AMF is upgraded, it begins using v2 endpoints with new features
This graceful version coexistence is defined in TS 29.500 Section 6.6 and is critical for operators running multi-release, multi-vendor cores. Ericsson documented this versioning approach in their 5GC migration guide, noting that backward compatibility must be maintained for at least two major API versions (N-2 policy).
Security on the SBI
SBA security is defined in 3GPP TS 33.501 Section 13:
- Transport security: TLS 1.2 or 1.3 is mandatory between NFs
- NF authorization: OAuth 2.0 tokens issued by NRF. A consumer NF requests an access token from NRF before invoking a producer NF service
- Token scope: Each token is scoped to a specific NF service (e.g., Nsmf_PDUSession)
- SEPP for roaming: The Security Edge Protection Proxy filters and validates all inter-PLMN SBI traffic on the N32 interface using PRINS (PRotocol for N32 INterconnect Security) or TLS
Summary
Service-Based Architecture is the defining structural change from 4G EPC to 5G Core. It replaces rigid point-to-point interfaces with a unified HTTP/2 API framework, enables dynamic NF discovery through the NRF, and supports both direct and SCP-mediated communication. For operators, SBA enables multi-vendor deployments, independent NF scaling, and graceful API evolution across 3GPP releases.
Key Takeaway: SBA transforms the 5G Core from a tightly coupled system into a microservices platform. The NRF provides dynamic discovery, the SCP handles routing and resilience, and HTTP/2 with OpenAPI specs enable multi-vendor interoperability that was never achievable with Diameter and GTP-C in 4G.