3 The shape of the 5G core

3.1 Why the core was taken apart

An operator wants to run the core network as software: on ordinary servers, in containers, scaled one piece at a time, with some pieces sitting in a central data centre and others in a cabinet near the radio mast.

A design made of fixed boxes with a fixed cable between every pair of them cannot be deployed that way.

The first sentence of §4.1 says so: the architecture is defined to support deployments that use techniques such as network function virtualization and software-defined networking. The rest of the clause is a list of the choices that follow from it. The ones that shape everything else in this course:

• User plane and control plane are separate. The parts that carry your packets and the parts that decide what to do with them scale on their own and can sit in different places.

• Procedures are defined as services wherever that works, so the same piece of behaviour can be re-used by a different procedure instead of being re-specified.

• Functions may talk directly, or indirectly through a Service Communication Proxy (the SCP, a message router for core network traffic). The document does not rule out other message routers either.

• The access network and the core depend on each other as little as possible. One core, one common boundary, several kinds of access behind it.

• Functions are meant to be "stateless" — the words are the specification's — with the compute separated from the storage.

• Local and central services at the same time: user plane functions can be put close to the access network for low delay.

3.2 What a network function actually is

A network function is a named piece of behaviour with an interface. It is not a server, not a process and not a vendor's product. One function can run as many instances at once; how many, and on what, is a deployment choice.

The document lists them all in one place §4.2.2. Three of them carry most of the work: the AMF (keeps track of where a device is and whether it can be reached), the SMF (sets up and tears down connections to a data network) and the UPF (the one that actually forwards packets).

Behind those come the UDM, the UDR, the PCF, the NRF, the NSSF (picks which slices a device may use), the AUSF (checks that a device is who it claims to be), the NEF and about twenty more. What each one does is What each network function does; this chapter is about the shape they sit in.

Two things in that list are worth stopping on.

The (R)AN, the UE and the Data Network appear alongside the core functions. The radio network and the phone are part of the architecture picture even though the radio network is specified elsewhere, in TS 38.300 and TS 38.401 §4.2.1.

And the list ends differently. After the network functions the clause says the architecture "also comprises the following network entities" and names the SCP and the SEPP (the guard that sits at the border between two operators' networks) §4.2.2.

They are entities, not functions, and the difference is real: an SCP forwards other functions' service calls but does not offer any service of its own §4.2.3.

3.3 The same network, drawn twice

The interaction between network functions is represented in two ways §4.2.1. This is the single most confusing thing about the document for a newcomer, because both pictures show the same network and neither is wrong.

The service-based representation draws every control plane function hanging off one horizontal bar. The bar is not a bus and not a cable. It means: each of these functions offers services, and any authorized function may call them. The user plane connections still appear as lines, because they are real links.

The reference point representation draws the same network as a graph, with a labelled edge between each pair of functions that talk. It is the easier picture to follow when you are reading one procedure, because you can trace it.

That sentence settles it. The second drawing is a view of the first, not an alternative to it.

Both figures also leave things out on purpose, and the notes under them say so one by one §4.2.3.

Absent are the UDR, the NRF, the NEF, the UDSF (stores whatever a function needs to keep, in whatever shape it likes), the analytics functions, the TSCTSF (keeps clocks in step for time-critical traffic) and the EASDF (helps a device find its nearest edge server).

3.4 Service-based interfaces: one name per producer

A service-based interface is written as N plus the function's name in lower case: Namf is the interface exhibited by the AMF, Nsmf the one exhibited by the SMF, Nudm, Npcf, Nnrf, Nudr and so on §4.2.6.

The word "exhibited" is the important one. The interface belongs to the function that offers the services, and to nothing else. There is exactly one per function, and it names a producer, never a pair. A consumer does not have an interface — it just calls.

That list is longer than the list of core functions you would expect, because functions defined in other documents also exhibit interfaces into this architecture: Nmbsmf and Nmbsf come from TS 23.247, Neasdf from TS 23.548, Naanf from TS 33.535, Naiotf and Nadm from TS 23.369 §4.2.6.

The mechanics of calling one — how a request is made, how a subscription works — are Services instead of interfaces, and how a consumer finds an instance to call is How one function finds another.

3.5 Reference points: two families under one letter

One clause lists reference points from N1 up to N115, and they are not all the same kind of thing §4.2.7. It splits them with one sentence in the middle, and everything depends on which side of it a name falls.

The six named before that sentence are real, separate links:

Reference point	Between
N1	the UE and the AMF
N2	the (R)AN and the AMF
N3	the (R)AN and the UPF
N4	the SMF and the UPF
N6	the UPF and a Data Network
N9	two UPFs

What travels on each of them is What actually travels on the wire.

Everything after that — N5, N7, N8, N10, N11, N12 and the rest of the way up to N115 — is a different animal:

So "N11" is a name for the conversation between the AMF and the SMF. There is no N11 protocol and no N11 socket. The traffic goes over Namf and Nsmf, and N11 is the label the document uses when it wants to talk about that pair without naming the individual services.

The numbering has holes, and they are deliberate. N44 to N49 and N100 to N109 are reserved for the charging specification, TS 32.240; N90 to N95 are reserved for the policy specification, TS 23.503 §4.2.7. A gap is a booking, not an omission.

Other reference points are not in this clause at all: the ones for location services live in TS 23.273, the ones for ProSe in TS 23.304, the ones for multicast-broadcast in TS 23.247.

3.6 Where the data lives

If a function is supposed to be stateless, its state has to be somewhere. The document gives it two homes §4.2.5, split by one question: does 3GPP define the shape of this data?

Unstructured data goes in a UDSF. Unstructured means the structure is not defined in 3GPP specifications — a UE context is the example the clause gives. Any NF may create, read, update and delete its own unstructured data there.

If that NF belongs to an NF Set (a group of instances of the same function that stand in for one another), any instance in the set may read, update and delete what another instance created. That is exactly how a failed instance's work gets picked up.

The UDSF sits in the same network as the function using it, and functions may share one or each keep their own, perhaps placed nearby §4.2.5. The interface is Nudsf, the reference point N18.

Structured data goes in a UDR. Four kinds of consumer write to it — the UDM, the PCF, the NEF and the ADM — and five data sets are standardized §4.2.5:

• Subscription data

• Policy data

• Structured data for exposure

• Application data: packet flow descriptions for detecting an application, and application function requests that apply to many devices at once

• Ambient IoT data, defined in TS 23.369

Access is checked per data set and per consumer, and possibly down to the single subscriber: a consumer may change only the data it is authorized to change, and the UDR is the one that decides §4.2.5.

Operator-specific data sets are allowed on top, but their content and encoding are not standardized — and neither is the way the UDR organizes any of it internally.

One small storage arrangement gets its own clause: a reference point from the AMF to the UCMF, which holds identifiers standing in for a device's radio capabilities so they need not be signalled in full.

The note is worth keeping — this is a serving-network-only feature and needs nothing from the roaming agreement with the home network §4.2.5a.

3.7 The extra views

Eleven clauses each take the architecture above and say what one feature adds to it. Several are one line long, because the real drawing is in another document. That is normal and worth getting used to.

Clause	What it adds	Where the detail is
§4.2.9	Network analytics	TS 23.288
§4.2.10	Using 3GPP and non-3GPP access at once	§5.32
§4.2.11	Multicast and broadcast	TS 23.247
§4.2.12	Device-to-device proximity services	TS 23.304
§4.2.13	Edge computing	§5.13, TS 23.548
§4.2.14	Uncrewed aerial systems	TS 23.256
§4.2.15	WLAN on 5G credentials without registering	TS 33.501
§4.2.16	A service-based interface on the UPF	§5.8.2.17
§4.2.17	Ranging and sidelink positioning	TS 23.586
§4.2.18	Energy information	§4.2.18.1
§4.2.19	Integrated sensing and communication	TS 23.137

Three of them change the picture rather than pointing elsewhere.

ATSSS §4.2.10 — carrying one connection over mobile and Wi-Fi at the same time — puts steering functions into the UE and matching proxy functions into the UPF.

The choices are MPTCP (multipath TCP), three flavours of multipath QUIC (a transport protocol that runs over UDP), and a lower-layer option called ATSSS-LL that has no user plane protocol between the two ends at all.

The UPF also gains a performance measurement function so the device can measure each access. The AMF, SMF and PCF are extended too. The whole feature is Using two accesses at once.

Nupf §4.2.16 is the odd one, because the UPF is a user plane function and this gives it a service-based interface. Only four kinds of consumer may receive its event notifications: the analytics functions, the NEF and AF, the SMF, and the time-sensitive functions.

Reporting the same information over N4 to the SMF still works — the service-based interface is an addition, not a replacement.

Energy §4.2.18 introduces the EIF, which collects energy information and talks directly to the AF, NEF, UDM, PCF and SMF over N110 to N114.

Its own source of energy data is the management system, over an interface the figures do not draw. In this Release there is no roaming architecture for it at all §4.2.18.1.

3.8 Where this meets the rest of the course

The roaming pictures are the same architecture with the functions split across two networks; they are Being served by somebody else's network. What each function does is What each network function does, and how a service call is actually made is Services instead of interfaces.

The choice between direct communication and going through an SCP is set out in §Annex E, and the rules for keeping state outside a function in §Annex C.