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

DimensionEPC Point-to-Point (4G)5GC Service-Based Architecture
Interface modelDedicated reference points (S1, S5, S6a, etc.)Common SBI with per-NF service APIs
ProtocolGTPv2-C, Diameter, S1AP (mixed)HTTP/2 + JSON (unified)
DiscoveryStatic configuration or DNSDynamic NRF-based discovery
Adding new NFRequires new interface specsNew NF registers services with NRF
Communication patternRequest-response onlyRequest-response + Subscribe-Notify
Load balancingProprietary or diameter agentSCP-based or NRF-assisted
API versioningProtocol version in spec (e.g., GTPv2)URI-based versioning (v1, v2)
EncryptionIPSec (transport layer)TLS 1.2/1.3 per hop
Vendor interopInterface-specific IOT testingOpenAPI 3.0 spec compliance
Specification bodyMultiple TS per interfaceTS 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.

NFService Name3GPP SpecKey OperationsHTTP Method
NRFNnrf_NFManagementTS 29.510NFRegister, NFUpdate, NFDeregisterPUT, PATCH, DELETE
NRFNnrf_NFDiscoveryTS 29.510NFDiscover (query NFs by type, slice, etc.)GET
AMFNamf_CommunicationTS 29.518N1N2MessageTransfer, UEContextTransferPOST
AMFNamf_EventExposureTS 29.518Subscribe/Notify for UE eventsPOST, DELETE
SMFNsmf_PDUSessionTS 29.502CreateSMContext, UpdateSMContext, ReleaseSMContextPOST, PATCH
UDMNudm_SDMTS 29.503SDM_Get (subscription data), SDM_SubscribeGET, POST
UDMNudm_UECMTS 29.503Registration, DeregistrationPUT, PATCH
PCFNpcf_SMPolicyControlTS 29.512SMPolicyCreate, SMPolicyUpdate, SMPolicyDeletePOST, PATCH, DELETE
AUSFNausf_UEAuthenticationTS 29.509Authenticate (5G-AKA, EAP-AKA)POST
NEFNnef_EventExposureTS 29.522Subscribe to network events for AFPOST
NSSFNnssf_NSSelectionTS 29.531NSSelectionGet (slice selection)GET
CHFNchf_SpendingLimitControlTS 29.594SpendingLimitSubscribe, SpendingLimitNotifyPOST
NWDAFNnwdaf_AnalyticsInfoTS 29.520AnalyticsInfoRequest, AnalyticsSubscriptionGET, POST
SCPN/A (routing layer)TS 29.500Indirect communication delegationN/A
3GPP Reference: TS 29.500 defines the SBA framework, HTTP/2 usage, and common API patterns. TS 29.501 defines the principles and guidelines.

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.

Step 2 -- NRF stores NFProfile:

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

Step 4 -- NRF returns candidate list:

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.
AspectDirect (Model A)Indirect via SCP (Model C/D)
DiscoveryConsumer queries NRFSCP queries NRF on behalf of consumer
Load balancingConsumer selects from NRF resultsSCP performs weighted routing
Retry on failureConsumer implements retrySCP handles failover transparently
ObservabilityPer-NF loggingCentralized at SCP
LatencyOne fewer hop+0.5--1 ms per SCP hop
Operational overheadLower (no SCP deployment)Higher (SCP must be HA)
AdoptionEarly 5GC deploymentsRecommended for production scale
Operator data -- Dish Network: Dish deployed their greenfield 5G SA network with SCP-based indirect communication from day one, using their cloud-native AWS-based architecture. They reported that SCP-mediated routing reduced NF-to-NF failure rates by 60% compared to direct communication in their pre-launch trials.

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.

Feature5G SBA (3GPP)Service Mesh (Istio/Envoy)
Service discoveryNRF (dedicated NF)Control plane (istiod) + sidecar
Load balancingSCP or consumer-sideEnvoy sidecar per pod
Mutual TLSOAuth2 tokens + TLS per TS 33.501mTLS via sidecar certificates
ObservabilitySCP/NRF loggingDistributed tracing (Jaeger, Zipkin)
Traffic routingSCP delegated routingVirtualService / DestinationRule CRDs
Specification3GPP TS 29.500CNCF open-source projects
Sidecar requiredNo (SCP is separate)Yes (Envoy per pod)
ProtocolHTTP/2 mandatoryHTTP/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
Scenario: An operator upgrades SMF to Release 17 (supporting v2) while AMF remains at Release 16 (supporting v1 only).
  1. SMF registers both v1 and v2 in its NFProfile with the NRF
  2. AMF queries NRF for SMF and specifies supported-features for v1
  3. NRF returns SMFs that support v1 (backward compatible)
  4. AMF continues using /nsmf-pdusession/v1/sm-contexts without disruption
  5. 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.