Chapter 8. 5G Service Based Architecture
Updated: 3 days ago
Chapter 8. 5G Service Based Architecture
8.1 Why the Core Speaks HTTP
Figure 8.1: The six building blocks of this chapter.
What you will be able to explain by the end
What service based actually means, as four principles rather than a slogan.
How a service based interface differs from an interface in the older sense.
Why HTTP/2 and REST were practical engineering choices rather than fashion.
How service discovery works, and why the NRF has no equivalent in the EPC.
What the SCP is for, and why it is optional.
Remember Three shifts carry this chapter. Services instead of interfaces, HTTP/2 instead of Diameter, and discovery instead of static configuration. |
8.2 What Service Based Actually Means
Figure 8.2: Four principles, each one changing behaviour.
Service based architecture is a design philosophy before it is a protocol choice, and it rests on four principles.
Functions offer services. A network function publishes what it can do, and other functions call those services. The AMF offers a communication service the SMF can invoke.
Any authorised function can call any other. There is no fixed pairing decided in advance, which is what removes the point to point wiring of the Evolved Packet Core.
Discovery replaces configuration. A function asks a registry who provides a service, so new instances join without anyone editing another function’s configuration.
Functions are stateless where possible. Session state is held outside the function, so any instance can serve any request.
Why the fourth principle matters most
Statelessness is what allows the core to scale the way cloud software scales. If any instance can serve any request, then instances become interchangeable, and interchangeable instances can be added, removed or replaced without disturbing anything.
Chapter 14 covers the cloud native mechanics in full. For now it is enough to see that the first three principles only deliver their value because of the fourth.
Did You Know? None of these principles is new to computing. What is new is a telecom core network adopting them, after two decades of the industry building its own protocols for every problem. |
8.3 The Service Based Interface
Figure 8.3: One bus, and every control plane function attached.
Every control plane function exposes a service based interface, and the naming convention is completely regular. Each one is the letter N followed by the function name in lower case.
Function | Service based interface | A service it offers |
AMF | Namf | Communication, so other functions can reach a device |
SMF | Nsmf | PDU session management |
PCF | Npcf | Policy control for sessions and charging |
UDM | Nudm | Subscriber data management |
AUSF | Nausf | Authentication |
NRF | Nnrf | Discovery and access token issuance |
Three things the diagram does not say
The bus is logical rather than physical. There is no shared cable anywhere, only an IP network on which any function can reach any other. 3GPP draws a bus because it expresses the relationship, not the cabling.
A service based interface is not a wire either. It is the set of services a function exposes, together with the address where those services can be called.
And the service based architecture applies to the control plane only. The user plane still uses N3, N6 and N9 carrying GTP-U, because forwarding packets at line rate is a fundamentally different problem from exchanging signalling messages.
Common Misconception Learners sometimes assume the service based interface replaced all the N reference points. It did not. N3, N4, N6 and N9 are still very much present, and Chapter 7 covered them. |
8.4 Why HTTP/2, and Why REST
Figure 8.4: Four reasons, and the REST mapping.
The protocol choice was an engineering decision, and it holds up to scrutiny on four counts.
Reason | What it gives the core |
Multiplexing | Many requests share one connection without head of line blocking, which matters when a busy AMF talks constantly to an SMF |
Binary and compact | Header compression and binary framing keep signalling efficient, answering the objection that text protocols are wasteful |
Tooling already exists | Load balancers, proxies, distributed tracing and TLS all come off the shelf rather than being built for telecoms |
Familiar to developers | Anyone who has built a web API can read a 5G Core specification, which widens the pool of people who can work on core networks |
How REST maps onto core network concepts
REST idea | In a 5G Core service | Example |
Resources | Sessions, subscriptions and contexts have addresses | A PDU session context is a resource |
Methods | POST, GET, PATCH and DELETE | POST creates a session management context |
JSON payloads | Readable structured data | Replaces the binary attribute value pairs Diameter used |
Key Takeaway You can read a 5G Core message with your eyes. That sounds cosmetic until you are debugging a live network at three in the morning, at which point it is worth a great deal. |
8.5 Service Discovery and the NRF
Figure 8.5: Register, discover, then call directly.
Service discovery is the part of this chapter with no equivalent at all in the Evolved Packet Core. It runs in three steps.
The producer registers with the Network Repository Function, publishing a profile containing its type, address, capacity and the slices it serves.
The consumer queries the NRF, asking for a function matching criteria such as a slice identifier and a data network name.
The consumer calls the chosen producer directly. The NRF answered a question and stepped out of the way.
Three details that matter
The profile is rich, which is what makes real selection decisions possible rather than a simple name lookup.
Discovery is a query rather than a static table, so the answer can differ from one minute to the next as instances come and go.
Selection stays with the consumer. The NRF returns options and the consumer chooses, so it can balance load or prefer a nearby instance.
Important Nothing in the AMF configuration names a specific SMF. That single fact is what makes the core elastic, and it is the clearest practical difference from a Diameter based core. |
8.6 A Real Service Call, Step by Step
Figure 8.6: What actually crosses the wire when a session is created.
Abstractions become clearer with a concrete exchange, so here is what happens when a device asks for a PDU session.
Step | What happens | In HTTP terms |
1 | A device requests a session, so the AMF needs an SMF | No message yet |
2 | The AMF asks the NRF for SMF instances matching the slice and DNN | GET to the NRF |
3 | The NRF returns candidates and the AMF selects one | A JSON response listing instances |
4 | The AMF creates a session management context on the chosen SMF | POST to Nsmf |
5 | The SMF replies with the location of the new resource | A URI the AMF stores for later |
Every step is an ordinary HTTP request. An engineer who has worked with web APIs can read that exchange without learning a telecom protocol first, which was very much the point.
8.7 The NRF and the SCP
Figure 8.7: The registry, and the optional proxy.
Two supporting functions make the service model work in practice.
| NRF | SCP |
Full name | Network Repository Function | Service Communication Proxy |
Role | Registry and authorisation server | Optional routing proxy for service calls |
In the traffic path? | No, it answers queries and steps aside | Yes, every call it handles passes through it |
Main benefit | Discovery and access control in one place | Load balancing, retries and overload control |
Main cost | It becomes critical infrastructure | One additional hop on every call |
Two points worth stressing
The NRF does authorisation as well as discovery. It issues access tokens saying which consumer may call which service, so the two arrive together rather than being separate systems.
The NRF is also critical infrastructure. If it fails, existing sessions continue because they already know their endpoints, but nothing new can be discovered. You will never see a single NRF in a production network.
Figure 8.8: Direct communication, or indirect through the SCP.
Direct and indirect communication
In direct communication the consumer discovers a producer and calls it straight, giving fewer hops and lower latency, at the cost of every function implementing its own retry and failover logic.
In indirect communication the call goes through the SCP, which routes it and can load balance. Large deployments asked for this because they did not want that logic duplicated inside every function from every vendor.
Did You Know? If the SCP pattern feels familiar from outside telecoms, it should. This is a service mesh, arrived at independently by 3GPP. Chapter 15 covers the cloud native version of the same idea. |
8.8 What the Service Model Buys You
Figure 8.9: Four operational consequences.
Capability | What it means in operations |
Scale a function independently | Add SMF instances before a busy hour without touching the AMF. They register and become available |
Upgrade without a maintenance window | Register a new version, drain the old one, deregister it. Consumers follow the registry |
Add a function without rewiring | A new function registers and becomes discoverable, with no interface provisioned toward it from every peer |
Reuse ordinary infrastructure | Standard load balancers, API gateways, tracing and TLS all apply directly, because this is just HTTP |
And what it costs
You gain flexibility and take on distributed system problems in exchange. Retries, timeouts, partial failure and the genuine difficulty of tracing one request as it crosses six functions are all now your concern.
That trade is worth making, but it is a trade. A statically configured core fails in simpler, more predictable ways, and anyone who has debugged a distributed system will recognise what has been given up.
Important Observability stops being optional in a service based core. If you cannot trace a request across functions, you cannot diagnose the failures this architecture makes possible. |
8.9 Diameter Based EPC Compared With API Based SBA
Figure 8.10: The same conversations, held a different way.
Aspect | Diameter based EPC | API based SBA |
Transport | Diameter over SCTP | HTTP/2 over TCP with TLS |
Message format | Binary attribute value pairs | JSON, readable as text |
Who talks to whom | Fixed peer relationships | Any authorised consumer to any producer |
Finding a peer | Static configuration and realm routing | Query the NRF at runtime |
Adding capacity | Configure the new peer everywhere | Register the instance, it becomes discoverable |
Tooling | Telecom specific protocol analysers | Ordinary web and cloud tooling |
Skills needed | Diameter expertise | API and cloud expertise |
In fairness to Diameter
Diameter was not bad engineering. It was designed for a world of fixed, long lived nodes with stable relationships, and it served that world well for many years.
The 5G Core needed something different, a model where instances appear and disappear continuously and where the set of functions is not known in advance. That is a different problem, and it called for a different answer.
Key Takeaway The skills row has the longest shadow. Moving from Diameter expertise to API and cloud expertise reshaped operator teams as much as it reshaped the core. |
8.10 What Goes Wrong in a Service Based Core
Figure 8.11: Four failures that only exist once functions call each other.
Symptom | Likely cause | What to check |
A new instance gets no traffic | It started but never registered with the NRF, so no consumer can discover it | Query the NRF for that function type and confirm the profile exists |
Calls fail with an authorisation error | The consumer has no valid token for that service, or it expired | Token issuance and the scope the NRF granted, since discovery is not access |
One slow function stalls many others | Consumers waited rather than timing out, so the delay propagated backwards | Timeout and retry configuration, not only the function that looks slow |
The same request works then fails | Two producer instances differ in version or configuration | Every instance the NRF is returning, not just the one you tested |
Common Misconception A successful discovery does not mean access was granted. Discovery and authorisation are separate steps, and confusing them sends engineers looking in the wrong place. |
8.11 Key Takeaways
Figure 8.12: The five points to carry forward.
Functions offer services, and any authorised consumer can call any producer. No fixed wiring.
HTTP/2 was a practical choice, driven by multiplexing, efficiency and existing tooling.
Discovery replaces configuration, with the NRF answering who provides a service at runtime.
The SCP is optional, giving routing and resilience in one place at the cost of a hop.
All of this is control plane only. The user plane still uses GTP-U over N3, N6 and N9.
Chapter 9 walks every 5G Core network function one by one, which finally puts names to all the boxes these diagrams keep drawing.
Frequently Asked Questions
Is the service based architecture just a diagram style?
No. Chapter 7 showed it as an alternative way of drawing the core, which is true but incomplete. It is a real change in how functions communicate, using HTTP/2 with REST style APIs and finding each other through a registry rather than through configuration.
Does the whole 5G Core use HTTP?
The control plane does. The user plane still uses GTP-U over N3, N6 and N9, because forwarding packets at line rate is a different problem. If you remember one boundary from this chapter, make it that one.
What does the N in Namf and Nsmf stand for?
It is simply the prefix 3GPP chose for a service based interface, followed by the function name in lower case. There is nothing to memorise beyond the pattern, and once you notice it the specifications become much easier to read.
Is the service based interface bus a real piece of hardware?
No. It is a logical representation. In reality it is an IP network on which any function can reach any other. 3GPP draws a bus because it expresses the many to many relationship clearly, not because a bus exists.
Why HTTP/2 rather than plain HTTP/1.1?
Mainly multiplexing. HTTP/1.1 suffers head of line blocking, where one slow response holds up others on the same connection. HTTP/2 multiplexes many requests over one connection, which matters when a busy AMF is exchanging thousands of messages with an SMF.
What exactly does a function register with the NRF?
An NF profile, containing the instance identifier, the function type, addresses, the services it supports, capacity information and which slices and data network names it serves. That richness is what allows a consumer to select sensibly rather than picking any instance.
How does authorisation work if any function can call any other?
Through OAuth 2.0 access tokens issued by the NRF. A consumer requests a token for a specific service, the NRF checks whether it is permitted and issues one with a scope. The producer validates the token before serving the request, so discovery and access are separate steps.
Is the SCP mandatory?
No, it is entirely optional. 3GPP defines both direct and indirect communication models. Some operators deploy the SCP for centralised routing and resilience, others prefer direct calls for lower latency and fewer moving parts.
What happens if the NRF becomes unavailable?
Existing sessions continue, because consumers already hold the endpoint details of the producers they are using. What stops is anything requiring new discovery, including new instances joining and consumers looking for a producer they have not used. This is why the NRF is always deployed redundantly.
How do consumers cope with a producer that disappears?
Through a combination of registration heartbeats to the NRF, subscription notifications when a profile changes, and ordinary HTTP error handling with retry to an alternative instance. The consumer usually holds several candidates from its original discovery for exactly this reason.
Does statelessness mean functions hold no state at all?
No. It means session state is not held exclusively inside one instance. The state is stored externally, commonly in the UDSF or an equivalent data layer, so any instance can pick up a request. The function still processes state, it simply does not own it privately.
How is a service versioned when it changes?
The API version appears in the resource path, so a producer can offer more than one version at once. That is what allows a rolling upgrade, where new instances register with a newer version while consumers that need the older one continue to be served.
Scenario Based Question
An operator wants to add SMF capacity before a major event. What is involved?
Deploy the additional instances and let them register with the NRF. No change is needed on the AMF, because it discovers producers at runtime. Afterwards the extra instances can deregister and be removed. That elasticity is the practical payoff of this architecture.
A vendor proposes deploying without an SCP. Is that a problem?
Not inherently. Direct communication is a valid model with lower latency. The question to ask is where retry, load balancing and overload control will live instead, because that logic still has to exist somewhere, most likely inside each function.
Your team has deep Diameter skills and no API experience. What changes?
A great deal, and this is often underestimated. Troubleshooting moves from protocol analysers to HTTP traces and logs, and the useful skills become API debugging, JSON, TLS and distributed tracing. Budget for that transition rather than assuming the old skills transfer directly.
Troubleshooting Based Question
A newly deployed AUSF receives no requests at all. Where do you start?
Query the NRF for AUSF instances and check whether the new one appears. An instance that started successfully but failed to register is invisible to every consumer. If the profile is present, check whether its slice and network name attributes match what consumers are asking for.
Calls to a producer fail with 403 Forbidden. What does that indicate?
Discovery worked, since the consumer found the producer, but authorisation did not. Check whether the consumer obtained an access token for that specific service, whether the token has expired, and whether the scope the NRF granted covers the operation being attempted.
Architecture Based Question
How does the service based architecture relate to network slicing?
Closely. Slice information is part of the NF profile and of discovery queries, so a consumer can ask for a producer serving a particular S-NSSAI. That is how one core can present different function sets to different slices, and Chapter 13 covers the full picture.
Why was the user plane left out of the service model?
Because the problems are different. Signalling involves relatively few messages carrying complex decisions, which suits request and response over HTTP. The user plane forwards millions of packets per second, where per packet overhead dominates and a tunnelling protocol is the right tool.
Is the NRF similar to DNS?
It is a useful analogy but an imperfect one. Both resolve a request into a set of endpoints. The NRF goes considerably further, holding capacity and slice attributes, issuing authorisation tokens, and supporting subscriptions so consumers are notified when a profile changes.
Standards Referenced in This Chapter
Document | Subject |
3GPP TS 23.501 | System architecture for the 5G System, including the service based architecture |
3GPP TS 23.502 | Procedures for the 5G System, including service operations |
3GPP TS 29.500 | Technical realisation of service based architecture, the HTTP/2 framework |
3GPP TS 29.501 | Principles and guidelines for services definition, the REST design rules |
3GPP TS 29.510 | Network Repository Function services, registration and discovery |
IETF RFC 7540 | HTTP/2, the transport protocol the control plane is built on |
IETF RFC 6749 | The OAuth 2.0 framework, used for service access authorisation |
The full 3GPP specification archive is available at 3gpp.org specifications. The 29 series carries the service based architecture detail.
End of Chapter 8. 5G Service Based Architecture
5G Network Architecture Masterclass.
------------------------
Learn Telecom. Crack Interviews. Build Careers.
support@telecomhunt.com | (c) 2026 Telecom Hunt, All rights reserved.
Comments