The Complete
5G Architecture.

TS 23.501 §4.2.1 defines exactly two ways to draw the 5G Core control plane — and they describe the same system:

• Service-based representation (Fig 4.2.3-1) — "network functions (e.g. AMF) within the Control Plane enable other authorized network functions to access their services." Everyone hangs off one horizontal bus; it "also includes point-to-point reference points where necessary."
• Reference-point representation (Fig 4.2.3-2) — "shows the interaction… described by point-to-point reference point (e.g. N11) between any two network functions (e.g. AMF and SMF)."

So N11 is not a cable and not a protocol — it is a name for a relationship: "the AMF consuming Nsmf and the SMF consuming Namf." Service-based interfaces are listed in §4.2.6; reference points in §4.2.7 — both are in the filterable tables below.

The move from 4G's monolithic MME / S-GW / P-GW to 5G's NF mesh buys three properties, and the spec pins the key one down word-for-word:

• Modularity — the core is decomposed into small NFs (AMF, SMF, UPF, AUSF, UDM…), each independently deployable and version-able.
• Reuse — a service written once (e.g. Nudm_SDM) is consumed by many NFs; procedures in TS 23.502 are literally built by invoking a sequence of NF services.
• Compute–storage separation — NFs are kept stateless: structured context lives in the UDR (Nudr) and unstructured context in the UDSF (Nudsf), so any instance can pick up any transaction and the layer scales and self-heals like cloud microservices.

The specification is precise about granularity §7.2.1:

• A Network Function offers one or more NF Services.
• "Each NF service shall be accessible by means of an interface. An interface may consist of one or several operations."

That maps straight onto the naming you see everywhere:

• SBI = N + function name → Namf, Nsmf, Nudm, Nnrf… §4.2.6
• NF Service = <SBI>_<ServiceName> → e.g. Namf_Communication.
• Operation = service + operation → e.g. Namf_Communication_N1N2MessageTransfer.

Read a call flow and you are reading a stack of these: a procedure such as PDU-Session Establishment is just a choreography of Nsmf_PDUSession_CreateSMContext, Npcf_SMPolicyControl_Create, Nudm_SDM_Get, N4… TS 23.502

Regardless of transport, every SBI exchange is one of exactly two patterns §7.1.2:

• Request-Response — one-to-one. Consumer NF_A asks producer NF_B to "perform an action or provide information or both"; one response is expected within a timeframe. To fulfil it, NF_B may itself consume other NFs' services.
• Subscribe-Notify — NF_A subscribes; NF_B notifies every interested subscriber when the event fires. The subscription must carry a notification endpoint = a Notification Target Address + Notification Correlation ID (typically a callback URL). NF_A may even subscribe on behalf of NF_C, pointing notifications at a third NF.

Subscription itself comes in three flavours:

• Explicit — a separate subscribe request/response.
• Implicit — the subscription rides inside another operation of the same service.
• Default notification endpoint — registered once with the NRF at NF registration (§4.17.1 of TS 23.502), so producers already know where to push.

A Binding Indication (→ Routing Binding Indication for indirect comms) lets a consumer pin subsequent requests to a suitable producer instance/set — vital when an NF is a stateful set. §6.3.1.0

An NF pair can talk directly, or indirectly through a Service Communication Proxy (SCP) — and the choice is per-message, driven by local configuration ("An NF may not use SCP for all its communication"). §4.2.1 · §7.1.1

• Direct — the consumer discovers the producer by local config or via the NRF, then connects straight to it.
• Indirect — the consumer sends via an SCP. It may still discover the producer itself, or delegate discovery/selection to the SCP, which then uses the parameters the consumer supplied. The SCP routes on the Routing Binding Indication when present.

Combining the two axes gives the four communication models of Annex E:

• Model A — Direct, no NRF discovery (local config only).
• Model B — Direct with NRF discovery.
• Model C — Indirect, consumer does discovery, SCP forwards.
• Model D — Indirect with delegated discovery — the consumer just hands intent to the SCP. §6.3.1 · Annex E

The NRF is the repository that makes the mesh find itself, across three §7.1 procedures:

• Registration §7.1.5 — every NF tells the NRF the services it supports: on first start (register), on activation/de-activation after a scaling event (update), and de-register on graceful shutdown; if an NF crashes, an authorised OA&M entity de-registers it. Registration "includes capacity and configuration information at time of instantiation."
• Discovery §7.1.3 · §6.3.1 — a consumer (or SCP) asks the NRF for instances providing the wanted service, filtered by target-nf-type, snssais, dnn…
• Authorization §7.1.4 — two steps: (1) may I discover it? — per-NF granularity, enforced by the NRF; (2) may I consume it for this UE / subscription / roaming case? — request-type granularity, embedded in the producer's own service logic.

On the wire that authorization is OAuth2: the NRF is the authorization server, issuing signed access tokens (grant_type=client_credentials, scoped to a service) that the producer verifies before serving. TS 33.501 §13

Because the control plane shall only use SBIs, its reference points (N8, N11, N12, N15…) are all the same HTTP/2 bus under different names — a reference point is a named relationship, realised as two NFs consuming each other's services.

The user plane is the exception: it does not run HTTP, so it keeps genuine point-to-point interfaces — which is exactly why the UPF never appears on the SBI bus:

• N1 — NAS (5GMM / 5GSM), UE ↔ AMF (logical, tunnelled in N2).
• N2 — NGAP over SCTP, (R)AN ↔ AMF.
• N3 / N9 — GTP-U over UDP, user data to the gNB / between UPFs.
• N4 — PFCP over UDP:8805, SMF ↔ UPF.
• N6 — plain IP, UPF ↔ Data Network.

The N1–N114 table below now carries the exact transport each reference point runs, so you can tell a "name on the bus" from a real wire at a glance.

Roaming stitches a VPLMN (visited) to an HPLMN (home). Every inter-operator control message crosses two SEPPs over N32 §4.2.4 · TS 33.501 §13, and N32 is really two connections:

On the user plane, home-routed traffic crosses the border on N9, guarded by IPUPS (Inter-PLMN User Plane Security) — the SEPP's user-plane counterpart. Supporting cross-PLMN control rides the bus through the SEPPs too: N27 (vNRF ↔ hNRF discovery), N31 (vNSSF ↔ hNSSF slice mapping), N24 (vPCF ↔ hPCF policy), N16 (V-SMF ↔ H-SMF). Where the user plane exits — visited vs home — is the LBO-vs-Home-Routed decision detailed below.