The core network — what is on the other side of the base station

5G Systems Notes · Reference · The core Concept map · Sessions · The stack · Hub

The three deep notes in this folder stop at the antenna, and the stack note stops at RRC. This note is what is on the other side of the base station. Each section defines one part of the 5G core: what it is, the clause that defines it, and — the part worth the reading — why the architecture is shaped this way rather than the way LTE's was.

In one line. Every generation before 5G described its core as nodes joined by named interfaces. 5G describes it as functions offering services over one common interface, and almost everything else in this note is a consequence: discovery replaces configuration, slicing becomes affordable, and exposing the network outward costs one function instead of one protocol per capability. The user plane did not follow — it is still a tunnel, and deliberately so.

Concepts defined here. 5G Core · Network function · Service-based architecture · SBI · NF service · NRF · Reference point · CP/UP split · AMF · SMF · UPF · UDM · AUSF · PCF · NEF · NSSF


The concepts this note covers

Each concept has a page of its own. This note is the narrative — the group read as one argument, with the connective tissue that a page-per-concept cannot carry. The pages are the definitions, and each one shows what to learn before it.

ConceptWhat it isNeedsPrimary clause
5G CoreThe core network behind the RAN, and the one decision that reshaped it0TS 23.501 §4.2
AMFAccess and Mobility Management Function — the device's one contact in the core2TS 23.501 §6.2.1
AUSFAuthentication Server Function — the function that decides the device is who it claims1TS 23.501 §6.2.8
CP/UP splitWhy the function that forwards packets holds no session state1TS 23.501 §8.2, §6.2.3
NEFNetwork Exposure Function — the core's front door for anything outside it1TS 23.501 §6.2.5
Network functionA named part of the core, defined by the services it offers1TS 23.501 §6.2
NF serviceA named capability one function offers another, and how it is found1TS 23.501 §7.1.2
NRFNF Repository Function — the register every function looks the others up in1TS 23.501 §6.2.6
NSSFNetwork Slice Selection Function — which slice, and therefore which AMF1TS 23.501 §6.2.14, §5.15.5
PCFPolicy Control Function — the rules a session must obey1TS 23.501 §6.2.4, TS 23.503 §6.1
Reference pointThe N-numbers, and what each one joins1TS 23.501 §4.2.3
SBIService-based interface — HTTP/2 and JSON between network functions1TS 29.500 §5.1
Service-based architectureThe core as a set of services, not a set of nodes1TS 23.501 §7.1
SMFSession Management Function — the function that owns a PDU session2TS 23.501 §6.2.2
UDMUnified Data Management — where the subscription lives1TS 23.501 §6.2.7
UPFUser Plane Function — the only function a data packet actually touches1TS 23.501 §6.2.3

Which to read. Come here to see how these ideas hang together; go to a term page when you want one definition, its prerequisites, and everything that depends on it. The concept map indexes all 118, and its hierarchy puts them in learning order.


The two drawings of one architecture

TS 23.501 gives the 5G core twice, and the notes below use both, so it is worth being explicit about which is which and when each is the right one.

ViewClauseUnitAnswersCannot answer
Service-basedTS 23.501 §7.1a service, offered and consumedwho may call whom, and how they find each otherwhat protocol crosses a particular link — because the answer is nearly always "the same one"
Reference pointTS 23.501 §4.2.3a named interface between two functionswhat crosses this line — N3 is GTP-U, N4 is PFCPthe open set of consumers a service may have
Table 1: The service-based and reference-point views of the same core. Neither is a simplification of the other: the first answers who may call whom, the second answers what physically crosses a given line. The right-hand column is the question each one cannot answer.

For the RAN half of these notes, only two lines matter: N2, control signalling between the base station and the AMF, and N3, user packets between the base station and the UPF. Everything in nr- and fe- happens below those two.


The core, and the decision behind it

What it is. Everything behind the radio: authentication, authorisation, mobility, sessions and the path to the internet. TS 23.501 is the architecture, TS 23.502 the procedures. Full definition: 5G Core.

The decision. LTE's core was a set of nodes — an MME, a serving gateway, a PDN gateway — joined by interfaces named per pair. 5G's primary description is a set of network functions offering services over one service-based interface. The node drawing survives as reference points, but it is no longer where the architecture lives.

Why the redrawing is worth anything. Under the node model, "the MME asks the HSS for subscription data" is a protocol: a specific message on a specific interface. A second consumer of subscription data needs a second interface specified. Under the service model it is an HTTP request to a named service, and a second consumer needs nothing specified at all — it discovers the producer and makes the same call.

Hold that thought through the rest of this note. It is why slicing is affordable, why NEF is a small function rather than a new protocol suite, and why the NRF is the only configured address in the system.


Functions, services, and finding them

What a network function is. A named part of the core, defined by the services it offers and listed with its functionality in TS 23.501 §6.2. Full definition: Network function.

It is a function, not a server. §6.2.1 says "Some or all of the AMF functionalities may be supported in a single instance of an AMF" — the specification describes behaviour, and says nothing about how many processes provide it or where they run.

The service-based architecture

Service-based architecture — TS 23.501 §7.1. A producer offers services; a consumer calls them; the same function is routinely both. Three moves make it work: one interface for everybody, producers register and consumers discover, and the service, not the function, is the unit — which is why the naming is Namf_Communication and Nsmf_PDUSession rather than a link name.

The interface, which is the web's

SBI — TS 29.500 §5.1 gives the stack, and it is worth quoting in full because of how ordinary it is: Application · HTTP/2 · TLS · TCP · IP. HTTP/2 per RFC 9113, JSON as the serialisation, TLS "used within a PLMN if network security is not provided by other means".

The signalling protocol of the mobile core used to be Diameter, and before that SS7. It is now the same stack a web API uses — methods, paths, status codes, and bodies a person can read.

Services, and discovering them

NF service — TS 23.501 §7.1.2. Two interaction models: request–response, and subscribe–notify, the second being how the core is event-driven (a notification is an HTTP request from the producer, so both ends are servers).

Discovery is the point. A consumer holds no producer's address. It asks the NRF — who offers Nsmf_PDUSession for this S-NSSAI and this DNN? — and gets back matching NF profiles.

Slice-aware selection is not extra machinery. It falls out of the discovery filter, because the parameters that distinguish one instance from another are exactly the slice it serves, the data network it reaches and the region it is in. That is why the NSSF only has to decide which slice and never which instance.

The register

NRF — TS 23.501 §6.2.6. Maintains NF profiles, answers discovery requests, notifies subscribers of changes, and maintains the health status of NFs. That last one matters: a register without liveness would hand out addresses of functions that died an hour ago, so discovery doubles as availability filtering.

It is the one configured address in the core — and its bootstrapping service exists so that even the NRF's own service endpoints can be fetched rather than assumed.


The other drawing: reference points

Reference point — TS 23.501 §4.2.3. The interfaces this folder needs:

PointBetweenCarriesProtocol
N1device ↔ AMFNAS — logical; the RAN only relays itNAS
N2(R)AN ↔ AMFRAN control signalling — the boundary, control sideNGAP
N3(R)AN ↔ UPFuser packets — the boundary, user sideGTP-U
N4SMF ↔ UPFthe CP/UP split itselfPFCP
N6UPF ↔ a data networkthe exit, to whatever the DNN namedIP
N9UPF ↔ UPFone anchor to anotherGTP-U
Table 2: The reference points a reader of the RAN notes actually meets. N2 and N3 are the RAN/core boundary, control side and user side. N1 is the odd one: it is drawn between the device and the AMF although no such link exists physically, and drawing it that way is what makes the RAN's obligation to carry NAS without reading it obvious.

Two of those are not HTTP, and that is the standing correction to "the 5G core is all REST": N3 is GTP-U and N4 is PFCP. No user packet ever travels over HTTP.

Control and user planes

CP/UP split — the function that decides is not the function that forwards. The SMF holds the session state; the UPF holds the packets; N4 joins them.

This is the precondition for the edge. A UPF holds no state of its own — everything it does was programmed over N4 — so it can be placed in a central data centre, a regional site, or a cabinet at the foot of the mast, and the SMF controlling it does not move.

And it is why the two planes scale separately. Control traffic grows with events; user traffic grows with bytes. An operator can buy forwarding capacity without buying signalling capacity, which is the practical reason the split exists.


The functions themselves

AMF — the device's one contact

AMF — TS 23.501 §6.2.1. Terminates N2 and NAS (N1), including NAS ciphering and integrity. Registration, connection, reachability and mobility management. Acts as SEAF, the security anchor.

Two lines of its list deserve reading twice: "Provide transport for SM messages between UE and SMF" and "Transparent proxy for routing SM messages". The AMF carries session-management signalling without reading it — a deliberate architectural refusal, and the reason TS 24.501 defines two state machines instead of one.

SMF — the owner of a session

SMF — TS 23.501 §6.2.2. Session establishment, modification and release; UE IP address allocation; selection and control of the UP function; traffic steering; determining SSC mode; and "Termination of SM parts of NAS messages".

The line that reaches the RAN is "Initiator of AN specific SM information, sent via AMF over N2 to AN" — that is the QoS profile travelling into the base station's scheduler. It is the single instruction the core gives the RAN about how to treat a device's traffic.

The line that makes a phone ring is "Downlink Data Notification": a packet arrives for an idle device, the UPF buffers it, the SMF is told, the AMF pages.

UPF — the only function a packet touches

UPF — TS 23.501 §6.2.3. Anchor point for mobility; the external PDU session point of interconnect; routing and forwarding; packet inspection; user-plane policy enforcement; QoS rate enforcement; downlink buffering and downlink data notification triggering; and packet duplication in the GTP-U layer.

"Anchor point" is the word carrying the mobility story: the device's IP address belongs to the anchoring UPF, so keeping the address means keeping the anchor — which is exactly what SSC mode is about.

UDM and AUSF — subscription, and proof

UDM — TS 23.501 §6.2.7. Generates AKA credentials; stores the SUPI; de-conceals the SUCI; authorises access from subscription data; and holds the reverse index — "UE's Serving NF Registration Management", i.e. which AMF is currently serving this subscriber.

Logic and storage are separable: the clause allows the UDM to keep its data in a UDR, in which case "a UDM implements the application logic and does not require an internal user data storage" — the same instinct as the CP/UP split, applied to subscriber data.

AUSF

AUSF — TS 23.501 §6.2.8, and it has the shortest functionality list in the specification: two lines, both saying see TS 33.501. That is not an omission — duplicating 5G AKA here would create two texts that could disagree.

Why it is separate from the UDM. The UDM generates credentials; the AUSF runs the procedure with a possibly-foreign serving network. Splitting them puts a boundary between the store of long-term secrets and the thing exposed to a visited network's requests. In roaming, the home operator decides — the visited AMF can neither authenticate the device nor read its SUCI.

PCF, NEF, NSSF

PCF — TS 23.501 §6.2.4, TS 23.503 §6.2.1. "Provides policy rules to control plane function(s) to enforce them" — it decides, and enforces nothing. See policy for the two directions the rules travel.

NEF

NEF — §6.2.5. The boundary at which the network's internal names and trust assumptions stop. It is cheap because of the SBA: every internal capability is already an HTTP service, so exposing a curated subset is one function with authorisation and mapping, not a new external protocol.

NSSF

NSSF — §6.2.14, §5.15.5. Turns which slice into which AMF. It exists because a device has one AMF but may hold several slices, so the AMF must serve the intersection — a constraint the RAN, which saw only a Requested NSSAI in an RRC message, cannot solve.


What the core does not do

Worth stating plainly, because the two halves of this folder are easy to blur.

The core knowsThe core does not know
About the radiothe QoS profile it sent over N2; that a device is reachableresource blocks, numerology, MCS, HARQ — the whole of layer 1
About the packetwhich flow it is, by QFIits contents, in the ordinary case
About locationthe tracking area listwhich cell — not while the device is idle
Table 3: The boundary between this folder's RAN layers and its core layer, in both directions. The middle column is the only channel by which the core influences the radio, and it is one message: a QoS profile per flow. The right-hand column is the only thing the radio needs from the core to page a device.

The two genuine seams, and both have arithmetic behind them: the 5QI the SMF hands the scheduler, and the ten bits of 5G-TMSI that decide a device's paging occasion.


Sources

DocumentClauseWhat it gives
TS 23.501 v19.7.04.2.3, 6.2, 7.1, 8.2The architecture; the functionality list of every network function; the reference points
TS 23.502 v19.7.04.2, 4.3The procedures — registration and session establishment as message sequences
TS 29.500 v19.7.05.1, 5.2The SBI protocol stack; HTTP/2 per RFC 9113; the mandatory custom headers
TS 23.503 v19.7.06.2.1The PCF in detail
TS 33.501 v19.7.06.1, 6.12Why the AUSF's own list is two lines long
Table 4: The clauses this reference note stands on. All are in the archive folder Courses (RAW)/5G Topics, fetched as one Release 19 snapshot at v19.7.0 so that cross-references between them resolve - the same discipline the physical-layer group uses at v19.4.0.
cd ~/Documents/md-engine/"Courses (RAW)/5G Topics"
pdftotext -layout ts_123501v190700p.pdf - | grep -n -A22 "^6.2.1 *AMF"
pdftotext -layout ts_129500v190700p.pdf - | grep -n -A20 "^5.1 *Protocol Stack Overview"
pdftotext -layout ts_123501v190700p.pdf - | grep -nE "^ *N[1-9][0-9]?: "
5G Systems Notes · Reference · The core Top · Concept map · Hub