5G System Architecture (NG-RAN + 5GC) in 5G NR

Introduction

The 5G System (5GS), defined at the top level in TS 23.501, is two halves bolted together: the NG-RAN (Next-Generation Radio Access Network) that owns the air interface, and the 5GC (5G Core) that owns authentication, sessions, policy and the path out to the internet. This page is the map of that system — the nodes, the network functions, and the interfaces between them.

You meet this architecture the moment a UE does anything beyond the radio: after random access and RRC setup, the device registers with the core, is authenticated, gets a PDU session with an IP address, and its traffic is steered to a data network. Every one of those steps rides an interface named on this page. Knowing the boxes and lines is what lets you read a call flow, place a fault, or reason about where latency and policy actually live.

It matters because the 5GC is not a re-skinned EPC. It is a Service-Based Architecture — control-plane functions are software microservices that publish REST-style APIs on a shared bus and discover each other at runtime — and that shift is what unlocks native network slicing, edge user planes, and independent scaling. Get the two naming schemes (service-based interfaces vs reference points) and the control/user-plane split straight, and the rest of 5G signalling falls into place.

Why the 5GC is built this way

Concretely, the 5GC is built as a Service-Based Architecture (SBA) so that the core can be operated like modern cloud software: functions are independently deployable, horizontally scalable, and swappable between vendors, and they find each other dynamically through a registry (the NRF) rather than through static configuration. This is also the precondition for network slicing — because functions are software services, the same physical core can present several logical networks (an eMBB slice, a URLLC slice, an IoT slice), each a curated set of network-function instances selected by the NSSF.

NG-RAN: the radio side of the 5G System

The 5G System (5GS) is, at the highest level, exactly two things bolted together: the NG-RAN (Next-Generation Radio Access Network) that owns the air interface, and the 5GC (5G Core) that owns everything behind it — authentication, sessions, policy and the path out to the internet. Get that top-level split straight and every other acronym on this page slots into one side or the other.

The NG-RAN is the set of base stations that hold the radio. It has two kinds of node, and the distinction matters because it is what lets an operator run 5G without ripping out 4G on day one.

Those two interface names are the first thing to fix in your head, because they run in different directions and are easy to swap. Xn is horizontal: RAN node to RAN node, the path a UE's context travels during an Xn-based handover. NG is vertical: RAN node up to the core. And NG itself is not one link but two logical ones — NG-C (the control plane, carrying NGAP signalling to the AMF) and NG-U (the user plane, carrying GTP-U tunnelled data to the UPF). That control/user split at the very edge of the core is a preview of the theme that runs through this whole architecture.

The protocols on these interfaces are exact. NG-C carries the NGAP application protocol (TS 38.413) over SCTP, the same reliable, message-oriented transport LTE's S1AP used — it handles UE-associated signalling (registration, PDU-session resource setup, handover) and non-UE-associated signalling (NG Setup). NG-U carries user data in GTP-U tunnels over UDP/IP, where each tunnel is identified by a TEID (Tunnel Endpoint Identifier) so the UPF and gNB can map packets to the right UE and QoS flow. Xn mirrors this: Xn-C runs XnAP over SCTP, Xn-U runs GTP-U.

5GC is a Service-Based Architecture

The biggest change in the 5G core is philosophical, not just a rename. In LTE the EPC was a set of dedicated boxes wired together with fixed point-to-point interfaces — the MME talked to the S-GW over S11, to the HSS over S6a, and if you wanted a new conversation you defined a new interface and a new protocol. The 5GC replaces that with a Service-Based Architecture (SBA): each control-plane function is a network function (NF) that exposes services on a common bus, and any authorized NF can consume them. Functions register themselves in a directory and discover each other dynamically, exactly the way microservices do in a modern data centre.

Concretely, control-plane NFs talk to one another over service-based interfaces (SBIs). These are named with an N prefixed to the producer's name: Namf is the set of services the AMF offers, Nsmf the SMF's services, Nudm the UDM's, Npcf the PCF's, Nnrf the NRF's, and so on. Crucially these SBIs ride on HTTP/2 with JSON payloads — ordinary REST-style APIs — rather than the bespoke telecom protocols of the EPC era. A producer advertises operations; a consumer calls them; both sides speak the same web transport.

These are real, versioned web APIs. Each service exposes resources under a URI of the form /<service>/<version>/… — for example the AMF's communication service is Namf_Communication and the SMF's session service is Nsmf_PDUSession — using ordinary HTTP methods (POST/GET/PUT/PATCH/DELETE) and, for the many event-driven flows, an explicit subscribe/notify pattern where a consumer registers a callback URI and the producer POSTs notifications back. HTTP/2 is chosen for multiplexed streams over one TCP connection; TLS secures the hop, and OAuth 2.0 access tokens (issued via the NRF) authorize one NF to call another.

Why go service-based at all? Because it turns the core into something you can operate like modern software. An NF can be upgraded, scaled out horizontally, or swapped for a different vendor's implementation without rewiring fixed cables to every peer — it simply re-registers its services and its consumers rediscover it through the NRF. It also underpins network slicing: the same physical core can present multiple logical networks — a low-latency URLLC slice, a massive-IoT slice, a mobile-broadband slice — each a curated set of NF instances, precisely because functions are software services rather than dedicated boxes. Each slice is identified by an S-NSSAI (an 8-bit SST plus optional 24-bit SD), and the NSSF then steers each UE to the right slice.

The network functions and what they do

The 5GC has more functions than you will touch day to day, but each has a crisp, single job. Learn the role, not just the acronym — every one of these answers a "who is responsible for X?" question. Note that most rows are control-plane SBA functions; the UPF is the odd one out, and the N3IWF is a gateway for devices that arrive over Wi-Fi rather than 3GPP radio.

Reference points: the N-numbered links

Alongside the service bus, the 5GS still defines a set of classic reference points — point-to-point links, each with a specific job and often a specific protocol. These are the links you draw when you sketch the end-to-end path of a packet or a piece of signalling, and they are the ones that show up in call-flow diagrams. Here are the ones you must know.

Two subtleties are worth calling out. First, N1 is a logical reference point: there is no direct radio-independent pipe from the UE to the AMF. The UE's NAS messages are carried transparently by RRC over the air and then by N2/NGAP across the RAN — the RAN does not read them, it just relays. Second, the reference points and the service-based interfaces are two views of the same core, not two different cores: N11 is the reference-point name for a conversation that, in an SBA deployment, actually happens as Namf and Nsmf service calls. 3GPP maintains both representations on purpose.

Control plane vs user plane: CUPS and the data path

The single most important design idea in the 5GC is the clean separation of mobility, sessions and data into three different functions, and more broadly the separation of the control plane from the user plane. This is CUPS — Control and User Plane Separation — and it is what lets the packet-forwarding boxes sit close to the user for low latency while the control logic stays centralized.

So the end-to-end user-plane path is short and named at every hop: UE → gNB → UPF → DN. The UE's packets cross the air on Uu, ride N3 as GTP-U from the gNB to the UPF, possibly traverse N9 to an anchor UPF, and leave via N6 to the data network. Not one control-plane NF sits on that path — the AMF, SMF and PCF only ever set it up and steer it; the bytes never flow through them.

The rules the SMF programs into the UPF over N4 use the PFCP protocol and a small, exact vocabulary: Packet Detection Rules (PDR) match incoming packets, Forwarding Action Rules (FAR) say where to send them, QoS Enforcement Rules (QER) police rate and marking per QoS flow (keyed by the QFI), and Usage Reporting Rules (URR) drive charging counters. That is the concrete meaning of "the SMF programs the UPF."

The payoff is concrete. Because the SMF and UPF are decoupled, an operator can drop a UPF next to a factory or a stadium so that traffic for a local application never traverses the whole network — a pattern called local breakout or edge computing, realized with an intermediate UPF and N9. The centralized SMF still owns the decision of which UPF anchors each PDU session, but the packets take the short path. Meanwhile the AMF keeps tracking the UE's location and reachability no matter how many sessions it has open or where their UPFs sit, so mobility and data placement are optimized independently.

5GC (SBA) compared to the EPC

If you already know 4G, the fastest way to internalize the 5GC is by contrast. The EPC and the 5GC solve the same problems — authenticate the device, manage its mobility, set up bearers, forward its data, apply policy — but the 5GC redistributes those jobs across more, smaller, software-native functions and connects them with a service bus instead of fixed interfaces.

Notice the pattern: LTE's MME is deliberately split into an AMF (mobility) and an SMF (sessions), and the combined S-GW/P-GW user plane collapses into a single, relocatable UPF. The HSS becomes a stateless UDM backed by a UDR database. And the whole thing gains an NRF so functions can find each other at runtime instead of being wired together in configuration. The 5GC is, in short, the EPC's responsibilities re-expressed as cloud-native microservices.

Quick Q&A

These are the questions that separate memorizing acronyms from truly understanding the architecture.

Summary

The 5G System is two halves: NG-RAN (the gNB and ng-eNB, meeting the UE over Uu) and the 5GC (a catalogue of software network functions). They join at NG, which splits into NG-C (N2, NGAP/SCTP to the AMF) and NG-U (N3, GTP-U to the UPF); RAN nodes talk sideways over Xn.

The core is a Service-Based Architecture: control-plane NFs publish HTTP/2+JSON services (named Namf, Nsmf, Nnrf, …), register with and are discovered through the NRF, and are also describable as classic reference points (N1–N11) for call flows. Keep those two naming schemes separate — they are two views of one core.

The organising principle is CUPS: the AMF owns the device, the SMF owns the session and programs the UPF over N4/PFCP, and only the UPF touches user packets — which is why it can sit at the edge for local breakout. Compared with the EPC, the MME splits into AMF+SMF, the S-GW/P-GW user plane collapses into the UPF, the HSS becomes UDM+UDR, and everything is discovered at runtime rather than wired in configuration.