Chapter 7. 5G System Architecture
Updated: 3 days ago
7.1 The Assembly Chapter
Figure 7.1: The six building blocks of this chapter.
What you will be able to explain by the end
The three domains of a 5G network, and which two the formal 5GS definition actually covers.
Why transport is the domain most often forgotten, and what it costs when it fails.
Why 3GPP draws the same architecture two different ways, and how to read both.
What N2, N3 and N4 carry, and why those three matter more than the rest.
The complete path a single user packet takes, and which functions never touch it.
Remember The control plane builds the path. The user plane carries the traffic. Holding those two apart makes the rest of this course considerably easier. |
7.2 The 5G System in One Picture
Figure 7.2: Three domains, and the boundaries between them.
A 5G network divides into three domains, and being precise about where each one ends prevents a great deal of confusion later.
Domain | What it is | What it owns | Covered in |
Access network | NG-RAN | The air interface, the gNodeB and its units | Chapters 4 to 6 |
Transport network | The links | Fronthaul, midhaul and backhaul over IP and optical | This chapter |
Core network | 5GC | Sessions, mobility, policy and subscriber data | Chapters 8 to 12 |
A definition worth getting right
The formal 5G System, written 5GS, means the 5G Core plus the NG-RAN plus the device. Transport is assumed to exist rather than specified by 3GPP.
That single omission explains a great deal about how operators are organised. Transport often sits with a separate team, on a separate budget, following separate standards from the IETF and the ITU-T rather than 3GPP.
Did You Know? The device and the data network sit outside all three domains. Everything in between exists purely to connect one to the other, which is a useful thing to remember when a design discussion drifts. |
7.3 The Access Network, Compressed
Figure 7.3: Three chapters of radio, in one view.
The access chain runs from the device through the Radio Unit, the Distributed Unit and the Central Unit to the core, joined by NR-Uu, Open Fronthaul, F1 and NG.
What matters at system level is not the internal detail but the four things the access network contributes.
Spectrum decides reach. Low band covers, mid band carries the traffic, millimetre wave fills hotspots.
Numerology decides latency. Wider subcarrier spacing means shorter slots, so a transmission opportunity arrives sooner.
Beamforming and massive MIMO decide capacity, by serving many users on the same time and frequency resources.
Where the CU, DU and RU sit decides the economics, trading site cost against transport cost.
Key Takeaway Everything from here on assumes those four decisions are already made. The core network inherits whatever the radio delivers. |
7.4 The Transport Network
Figure 7.4: Three segments, and what breaks when each one fails.
Transport is not specified by 3GPP, which is exactly why it falls between teams and gets diagnosed last.
Segment | Connects | Latency budget | What breaks if it fails |
Fronthaul | RU to DU | Around 100 microseconds | The cell drops entirely |
Midhaul | DU to CU | A few milliseconds | Sessions fail to set up |
Backhaul | CU to the 5G Core | Tens of milliseconds | Users lose connectivity |
What sits underneath
IP and MPLS, providing routing, segment routing and traffic engineering.
Optical transport, providing fibre and wavelengths, often with a dedicated wavelength reserved for fronthaul.
Precision timing from GPS or the Precision Time Protocol, which time division duplex makes compulsory as Chapter 6 explained.
Important Transport is blamed last and responsible first. When a 5G problem has no obvious radio or core cause, this is where to look before anywhere else. |
7.5 Inside the 5G Core, at a Glance
Figure 7.5: Control plane above, user plane below.
This is a first look rather than a study, since Chapter 9 covers every function properly. What matters here is the shape.
Function | Responsibility | Plane |
AMF | Access and mobility management, the device talks to it over N1 | Control |
SMF | Session management, and it controls the UPF over N4 | Control |
AUSF | Authentication of the subscriber | Control |
UDM | Subscriber data management, with the UDR holding the data | Control |
PCF | Policy decisions for sessions and charging | Control |
NRF | Service discovery, how functions find each other | Control |
UPF | Forwards every user packet, applies QoS and counts traffic | User |
The asymmetry is deliberate
There are many control plane functions and one user plane function in the path. Control is complex because decisions are complex, involving authentication, policy, subscriber data and mobility.
The user plane is deliberately simple so that it can be fast, and so that it can be placed anywhere, including at an edge site close to the user. Chapter 10 covers that separation in full.
7.6 Two Drawings of One Architecture
Figure 7.6: Reference point view and service based view.
This confuses almost everyone reading 3GPP specifications for the first time. The same architecture appears in two entirely different diagram styles, sometimes on adjacent pages.
| Reference point view | Service based view |
How it looks | Named point to point links between functions | Functions attached to a common bus |
Example | N11 joins the AMF and the SMF | The SMF consumes a service the AMF offers |
Feels familiar to | Anyone who worked with LTE | Anyone from a web or cloud background |
Best used for | Drawing call flows and procedures | Explaining the service based principle |
Both appear in TS 23.501, and specifications switch between them without warning. They are two drawings of one architecture, not two architectures, and the same relationship simply has two vocabularies.
Common Misconception Learners sometimes assume the reference points were replaced by services. They were not. N11 still exists as a name, and it describes the same interaction the service based view expresses differently. |
7.7 The Reference Points You Will Actually Meet
Figure 7.7: Seven names that cover most documentation.
Name | Connects | Carries | Where it appears |
N1 | UE to AMF | NAS signalling, a logical connection | Registration, Chapter 11 |
N2 | gNodeB to AMF | NGAP control signalling | Every control procedure |
N3 | gNodeB to UPF | GTP-U user traffic | Every user packet |
N4 | SMF to UPF | PFCP session control | CUPS, Chapter 10 |
N6 | UPF to data network | Plain IP traffic | The exit to the internet |
N9 | UPF to UPF | GTP-U between user plane functions | Edge and roaming paths |
N11 | AMF to SMF | Session requests | PDU session setup |
N1 deserves a note. It is a logical connection rather than a physical link, since NAS messages ride over the radio interface and then over N2 inside NGAP. The device and the AMF behave as though they have a direct channel, and in signalling terms they do.
Remember Learn N2, N3 and N4 first. Control to the core, user traffic to the core, and the control of the user plane. Those three carry most conversations you will have. |
7.8 One Packet, End to End
Figure 7.8: From the device to the internet.
This is where the chapter pays off. Follow a single packet and every earlier concept lands in place.
The application on the device sends the packet.
The gNodeB schedules it on the air interface, using the numerology, beamforming and MIMO from Chapter 5.
It crosses N3 inside a GTP-U tunnel to the UPF.
The UPF terminates the tunnel, applies QoS, counts the traffic for charging, and forwards plain IP out of N6.
Three things worth noticing
First, the path existed before the packet did. The device registered over N1 and N2, and the SMF established a PDU session, well before any user data flowed.
Second, the tunnel exists so the network can move the device between cells without changing its IP address. Mobility is the reason for the encapsulation, not overhead for its own sake.
Third, and this surprises people, the control plane never sees a user packet. The AMF and the SMF build the road. They do not drive on it.
Key Takeaway If you can narrate this journey from memory, including which interface each hop uses, you understand the 5G System well enough to follow every remaining chapter. |
7.9 Where Each Piece Physically Lives
Figure 7.9: The same architecture across three kinds of site.
Architecture diagrams hide geography, and geography is what actually determines latency.
Site type | How many | What it holds | Why it matters |
Cell site | Thousands | RU, and often the DU | Space and power are tightly constrained |
Edge site | Tens to hundreds | CU, and often a UPF | Where low latency is actually won |
Central site | A handful | Control plane, subscriber data, policy | National scale and fully redundant |
Latency is bought with geography. Moving the UPF from a central site to an edge site is the single largest lever available, and it is precisely what the URLLC requirements from Chapter 2 demand.
Important None of this distribution would be possible without separating control from user plane. That separation is what allows one control plane to manage user plane functions scattered across a country. |
7.10 EPC Architecture Compared With 5GC
Figure 7.10: Same job, rebuilt on different principles.
Aspect | EPC | 5GC |
Communication style | Point to point interfaces | Service based, functions call each other |
Signalling protocol | Diameter and GTP-C | HTTP/2 with REST style APIs |
Control and user plane | Combined in the S-GW and P-GW | Fully separated, the SMF controls the UPF |
Mobility and session | Both handled by the MME | Split into the AMF and the SMF |
Subscriber data | HSS holds data and logic together | UDM with UDR, data separated from logic |
Deployment | Appliances in central sites | Cloud native, placed where needed |
Slicing | Not supported | Native, identified by the S-NSSAI |
What did not change
Authentication still happens. Sessions are still established. Mobility is still managed and policy is still applied. Every job the EPC performed still needs doing.
What changed is how the work is packaged into functions and how those functions talk to each other. Understanding that keeps the 5G Core from feeling like an unfamiliar system, because in behaviour it is the same network reorganised.
7.11 Where End to End Problems Come From
Figure 7.11: Four failures, and the domain each belongs to.
Symptom | Likely cause | What to check |
Device registers but has no data | Registration over N1 and N2 succeeded, the session path did not come up | The N4 association between SMF and UPF, then N3 |
Everything works, latency is poor | The UPF sits in a central site, so every packet makes a long round trip | Where the UPF is anchored, before touching the radio |
One site fails, others are fine | Almost always transport rather than radio or core | The backhaul path and the timing source for that site |
Intermittent faults nobody owns | Three teams each see a healthy domain, the fault sits between them | Trace one session end to end rather than checking domains |
Did You Know? The first row is diagnostically useful on its own. A successful registration tells you N1, N2, the AMF, the AUSF and the UDM are all working, which eliminates most of the control plane in a single observation. |
7.12 Key Takeaways
Figure 7.12: The five points to carry forward.
Three domains, one system. Access, transport and core, and the formal 5GS covers only two of them plus the device.
Two drawings, one architecture. The reference point view and the service based view describe the same thing.
Learn N2, N3 and N4 first. Control to the core, traffic to the core, and control of the user plane.
The control plane builds the path and never carries a user packet.
Latency is bought with geography. Where the UPF sits matters more than almost anything in the radio.
Chapter 8 answers a question that puzzles many telecom engineers. Why does the 5G Core speak HTTP, and what does the service based architecture actually mean in practice?
Frequently Asked Questions
Is the 5G System the same thing as the 5G Core?
No. The 5G Core, written 5GC, is one part. The 5G System, written 5GS, means the 5G Core plus the NG-RAN plus the device. People often use the terms loosely, but specifications are precise about the difference.
Why is transport not part of the 5G System?
Because 3GPP specifies the functions and the interfaces between them, not the network that carries those interfaces. Transport follows IETF and ITU-T standards instead. The practical consequence is that transport is usually a separate team with a separate budget.
What is the difference between an interface and a reference point?
In everyday use they are treated as the same thing. Strictly, a reference point is the conceptual boundary between two functions, such as N11, and an interface is the concrete protocol implementation across it. Most engineers say interface for both.
Does every packet really pass through the UPF?
Yes, every user plane packet for that session does. The UPF is the anchor point where QoS is enforced, traffic is counted for charging and lawful intercept is applied. There is no path from the radio to the internet that bypasses it.
Why is N1 described as logical rather than physical?
Because there is no direct link between the device and the AMF. NAS messages travel over the radio interface to the gNodeB, and the gNodeB carries them onward inside NGAP over N2. The device and the AMF behave as though they have a private channel, and in signalling terms they do.
What is actually inside the GTP-U tunnel on N3?
The user IP packet, wrapped in a GTP-U header, then UDP, then an outer IP header for transport. The tunnel endpoint identifier in the GTP-U header tells the UPF which session the packet belongs to, which is how one UPF serves many devices.
Why separate the UDM from the UDR?
To split logic from data. The UDM implements the procedures while the UDR stores subscriber records. Separating them means the data layer can be scaled, replicated or shared with other functions independently of the logic that uses it.
If the control plane never sees user packets, how is charging done?
The UPF counts the traffic and reports usage to the SMF over N4. The SMF then reports to the charging function. The control plane receives measurements about the traffic rather than the traffic itself, which is precisely the point of the separation.
When would a session use two UPFs over N9?
Two common cases. In an edge deployment an uplink classifier or branching point UPF can send some traffic to a local server while the rest goes to a central anchor. In home routed roaming the visited network UPF connects over N9 to the home network UPF.
Does the service based architecture apply to the user plane too?
No, and this is a common misunderstanding. The service based interfaces apply to the control plane only. The user plane still uses N3, N6 and N9 with GTP-U, because tunnelling packets at line rate is a very different problem from exchanging signalling messages.
How does the AMF know which SMF to select for a session?
It queries the NRF, using criteria including the requested S-NSSAI and DNN. The NRF returns candidate SMF instances and the AMF chooses one. That discovery step is exactly what the service based architecture enables, and Chapter 8 covers it in detail.
What happens to the N3 tunnel during a handover?
The tunnel endpoint on the radio side changes to the new gNodeB while the UPF anchor normally stays the same. The device keeps its IP address because the anchor did not move, which is the entire reason for anchoring the session at the UPF.
Scenario-Based Questions
An operator wants 10 ms round trip for a factory. Where do you start?
With UPF placement, not the radio. If the UPF sits in a central site the round trip may exceed the budget before any radio delay is counted. Place a UPF at an edge site near the factory, then examine the radio configuration. Chapter 2 covered why distance dominates.
A design review shows the reference point diagram only. What is missing?
Nothing technically, but you are seeing one view. Ask for the service based view as well, because it shows which functions register with the NRF and which services they expose. The two views answer different questions and reviews benefit from both.
A new engineer confuses the AMF and the MME. How would you explain the difference?
The MME did two jobs, mobility management and session management. In the 5G Core those were split, with the AMF taking access and mobility and the SMF taking sessions. The AMF is therefore roughly the mobility half of the MME, not its direct replacement.
Troubleshooting Based Questions
Registration succeeds but the PDU session establishment fails. What does that tell you?
A great deal. Registration used N1, N2, the AMF, the AUSF and the UDM, so all of those work. The failure is in the session path, so check N11 between the AMF and the SMF, the N4 association between the SMF and the UPF, and whether the requested DNN and S-NSSAI are permitted.
Users on one gNodeB have high latency while the rest are normal. Where do you look?
A single site behaving differently points at that site rather than the core. Check its backhaul path length and utilisation, and confirm it is anchored to the expected UPF. A site homed to a distant UPF by misconfiguration produces exactly this pattern.
Why does the 5G Core separate the AMF and the SMF at all?
Because mobility and sessions scale differently. A device moving frequently generates mobility signalling without needing new sessions, while a device with many sessions may barely move. Separating them lets each function scale to its own load, which matters in a cloud native deployment.
Can one AMF serve gNodeBs from different vendors?
Yes. N2 is a standardised interface using NGAP, so any compliant gNodeB can connect to any compliant AMF. In practice operators still test each combination carefully, but the interface itself does not constrain vendor mixing.
Where does network slicing fit into this architecture?
It runs through all of it. A slice is identified by an S-NSSAI, selected during registration, and it influences which SMF and UPF serve the session and how the radio treats the traffic. Chapter 13 covers slicing properly, but it is worth knowing that it touches every domain in this chapter.
Standards Referenced in This Chapter
Document | Subject |
3GPP TS 23.501 | System architecture for the 5G System, both architecture views |
3GPP TS 23.502 | Procedures for the 5G System, including registration and session setup |
3GPP TS 38.410 | NG general aspects and principles, the N2 and N3 interfaces |
3GPP TS 29.244 | Packet Forwarding Control Protocol, the N4 interface between SMF and UPF |
3GPP TS 24.501 | NAS protocol for the 5G System, carried over N1 |
3GPP TS 23.401 | EPS architecture, the Evolved Packet Core this chapter compares against |
The full 3GPP specification archive is available at 3gpp.org specifications. Always check the release version that matches your deployment.
End of Chapter 7. 5G System Architecture
5G Network Architecture Masterclass.
------------------------
Learn Telecom. Crack Interviews. Build Careers.
support@telecomhunt.com | (c) 2026 Telecom Hunt, All rights reserved.
Comments