5G/NR - Core Network Architecture

 

 

 

NR Core Network Architecture / Network Interface

The 5G core network architecture is based on a service-based model, utilizing cloud-native and virtualized network functions. The purpose of this note is to share you with overview of 5G corenetwork. The defails of specific components and functionalities will be described in separate notes.

Overall Architecture

What follows is a map of the 5G core, and the first thing to say about it is what it is not. It is not a flow chart and it is not a hierarchy. There is no box at the top that commands the others, and no left hand side where things begin. It is a picture of a set of specialists and of which ones need to be able to talk to which - nothing more than that. Read as a diagram of relationships rather than a diagram of sequence, it becomes considerably less intimidating.

The reason there are so many boxes is that 5G took the handful of large nodes that made up the 4G core and broke them into much smaller pieces, each responsible for one question. One function knows where a UE currently is. Another knows what sessions it has open. Another holds the subscription data, another decides what policy applies, another does nothing but forward packets. In 4G several of those jobs lived inside a single node ; in 5G they are separate, and the diagram is busy precisely because that separation is drawn out in full. The useful skill when reading it is not memorising the picture but knowing which box owns which question - and once you know that, finding the right reference point between any two of them is straightforward.

It is also worth remembering that this is a logical picture and not a deployment one. Each box is a network function, not a machine. In a real network several of these may be containers running on the same physical host, and any one of them may exist as dozens of instances sitting behind a load balancer, appearing and disappearing as demand changes. The diagram tells you what has to be able to reach what ; it deliberately says nothing about where any of it physically runs, which is exactly the freedom the cloud-native design described at the end of this page was intended to create.

Following is the overal NR Network illustrated based on 23.501. The diagram is based mainly on Figure 4.2.3-1 and Figure 4.2.3-2 of 23.501.

The numbers in the oval shape indicates the reference point between components. This shows NR network only in non-roaming condition. In the condition of roaming with other NR network or Legacy network, some additional function block and interface(reference point) is required.

 

How to read that diagram

There is a lot in it, so it helps to know what to look at first.

The bottom row is the only place user data travels. Follow UE - (R)AN - UPF - DN along the bottom edge and you have the entire user plane : your video, your web page, your call. Everything drawn above that row is control plane - signalling about the connection rather than the connection itself. Once you see the picture that way it stops being a cloud of boxes and becomes a data path with a large amount of machinery sitting on top of it deciding how that path should behave.

The (R)AN box splits in two directions, and that split is the point. One line leaves it as N2 going up to the AMF, and another leaves as N3 going sideways to the UPF. Same base station, two completely separate destinations : control to the AMF, user data to the UPF. That is the control and user plane separation drawn literally, and it is why the UPF can be placed close to the edge of the network for latency while the AMF stays centralised.

N1 is not a wire. The line from the UE up to the AMF looks like the others but is a different kind of thing. There is no direct link between a handset and a core network function - the NAS messages that N1 carries are passed through the base station, which forwards them without reading them. N1 is a logical reference point describing who is talking to whom, not a physical interface. It is worth noticing because it is the reason a UE can complete registration and authentication with the core while the RAN acts purely as a relay.

Count the lines touching the AMF. N1, N2, N8, N11, N12, N14, N15, N20 and N22 all terminate there - more than at any other function in the picture. That fan-out is the visual answer to why the AMF is the natural successor to the MME : it is the node everything has to talk to in order to reach a UE.

Two lines loop back on themselves. N14 connects an AMF to another AMF, and N9 connects a UPF to another UPF. They look odd in a diagram of one network because they are not about one network - N14 is how a UE moves between AMFs, and N9 is how two UPFs are chained when traffic has to pass through more than one, for example when an anchor UPF stays put while a local one follows the user.

And now the detail that explains the whole next section. Look at NEF and NRF in the top row. They have no lines attached to them at all. That is not an omission in the drawing. Those two functions never communicate over a numbered reference point - they only ever talk over service-based interfaces, so a reference-point diagram has literally nothing to draw for them. Which brings us to the two ways this architecture can be drawn.

Reference points and service-based interfaces

Your opening paragraph describes 5G core as service-based, and then the diagram and the whole interface list below are reference points with N numbers. Both are correct, and 23.501 genuinely contains both - which is why you noted the diagram is drawn from Figure 4.2.3-1 and 4.2.3-2. They are two representations of one architecture :

  Reference point representation Service based representation

How it is drawn

Point to point lines, numbered Nx

Every NF hanging off a common bus

Names things after

The pair of functions - N11 is AMF to SMF

The provider - Namf is whatever the AMF offers

Underneath it is

A specific protocol for that pair

HTTP/2 REST, the same for everybody

Good for

Seeing the topology, which is why the diagram uses it

Seeing that any NF can call any other without a new interface being defined

The important consequence is that not every N number has a service-based equivalent, and that is deliberate. The ones that survive as genuine point to point interfaces are the ones that do not carry signalling between core network functions :

Reference point Between Why it stays point to point

N1

UE and AMF

The UE is not a network function and has no place on the service bus. NAS is its own protocol

N2

(R)AN and AMF

The RAN is not part of the core. NGAP over SCTP, much as S1AP was in 4G

N3, N6, N9

the user plane path

These carry your actual data. Wrapping bulk traffic in HTTP requests would be absurd, so they stay as tunnels - GTP-U on N3 and N9

N4

SMF and UPF

Control of the forwarding plane, using PFCP. It is a specialised job with a specialised protocol

N26

MME and AMF

The far end is a 4G node that has never heard of the service bus

Everything else in the list - N7, N8, N10, N11, N12, N13, N15, N20, N21, N22 and the rest - describes signalling between two core network functions, and in the service based representation those all become Npcf, Nudm, Nsmf, Namf and so on. The N number and the Nnf name are two labels for the same conversation.

NOTE : this is also the answer to why NEF and NRF have no lines in the diagram. The NRF is the service registry - the function others query to find out where a given service lives - and the NEF exposes core capabilities to outside applications. Neither has a fixed partner to draw a line to, because their whole purpose is to be reachable by anyone. A function that talks to everything cannot be drawn in a diagram whose vocabulary is pairs.

Components of the Network

There are so many components and functionality.  Some of Key components include the Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), and Network Repository Function (NRF). The architecture enables network slicing, end-to-end QoS, and efficient resource management.

Followings are the name of each network component. This is the list of the component that are likely to be commonly used in most of the networks, but depending on real deployment you may see more components or in some cases (like small scale private network) you may see much less components where multiple functionalities are aggregated into one component)

    AMF     Access and Mobility Management Function ==> Equivalent to MME in 4G

    AUSF    Authentication Server Function

    DN       Data Network

    NEF      Network Exposure Function

    NRF      Network Repository Function

    NSSF    Network Slice Selection Function

    PCF      Policy Control Function ==> Equivalent to PCRF in 4G

    (R)AN   (Radio) Access Network

    SMF     Session Management Function

    UDM     Unified Data Management ==> Equivalent to HSS in 4G

    UPF      User Plane Function ==> Equivalent to PGW in 4G

    SMSF   SMS Function

The "equivalent to X in 4G" notes above are the fastest way in if you know EPC, but the mapping is not one to one in either direction - and the places where it is not are exactly where 5G differs :

4G / EPC 5G / 5GC What actually happened

MME

AMF + SMF

One node became two. The MME handled both mobility and sessions ; 5G splits them, so AMF deals with where the UE is and SMF deals with its PDU sessions. They can then be scaled independently

SGW + PGW

UPF (user plane)
SMF (control)

Split horizontally rather than vertically. The forwarding half became the UPF and the deciding half went into the SMF - this is CUPS, and it is what lets a UPF sit at the network edge on its own

HSS

UDM + UDR
+ AUSF

Split three ways : UDM for subscriber logic, UDR for the data itself, AUSF for authentication. Separating the logic from the storage is what makes the data reusable by other functions

PCRF

PCF

The closest thing to a straight rename, though the PCF reaches considerably further

-

NRF, NSSF,
NEF, NWDAF

No 4G ancestor at all. Service discovery, network slicing, capability exposure and analytics are new jobs that only exist because the architecture became service based and sliceable

Reading that table downwards, the pattern is that almost nothing was simply renamed. Functions were split apart along the lines where they needed to scale differently, and a handful of genuinely new ones were added. That is the concrete meaning of the design philosophy you set out at the end of this page - the decomposition is not tidiness for its own sake, it is what makes the independent scaling and the slicing possible.

Interfaces between Components

The word to pay attention to in that definition is conceptual, because it is doing more work than it looks. A reference point is a named relationship, not a cable. Saying that N11 exists is saying that the AMF and the SMF have things they need to tell each other and that this particular conversation has a name - it says nothing whatsoever about how the two are physically connected. They might be separate machines in separate buildings joined by fibre, or two containers on the same server exchanging messages that never leave the host. The reference point is identical in both cases, and that indifference is deliberate : it is what allows an operator to deploy the same standardised architecture as a rack of dedicated hardware or as software on a cloud platform.

The list below is long, and the natural reaction is to assume it must be learnt. It does not need to be. The numbering is roughly historical rather than logical - the low numbers are the original Release 15 core, the connections without which a network cannot function at all, and the higher ones were added over time as features arrived. That is why N1 to N15 or so describe registration, sessions and the user plane, while further down you find reference points that exist only because someone later added charging, analytics, public warning, roaming security or slice-specific authentication. A high number generally means a later or optional feature, not a more important one.

In practice nobody reads a list like this from top to bottom. You meet an N number somewhere - in a specification, a log, a vendor diagram - and come to a page like this one to find out which two functions it joins. That is worth knowing because it tells you what the list is really for : it is an index from a name to a pair of endpoints. And it works in both directions, so if you know that the SMF needs to fetch a subscriber's session data from the UDM, you can reasonably expect a reference point to exist for it, and go looking for its number.

One caveat is worth carrying into the list, and it follows from the service-based discussion further up this page. Only a handful of these are protocols you could actually capture on a wire - N1 carrying NAS, N2 carrying NGAP, N3 and N9 carrying GTP-U tunnels, N4 carrying PFCP, and N26 reaching back to an MME. The rest describe conversations between core network functions, and those are carried over the service bus. So if you go hunting through a packet capture for an N11 message you will not find one ; what you will find is an HTTP/2 request to a service the SMF has published. The reference point is still the right way to describe the relationship - it is simply not the shape the traffic takes.

Followings are the reference point definition specified in 23.501 - 4.2.7.  A reference point is a conceptual point of interaction between two network functions or components.

    N1: Reference point between the UE and the AMF.

    N2: Reference point between the (R)AN and the AMF.

    N3: Reference point between the (R)AN and the UPF.

    N4: Reference point between the SMF and the UPF.

    N6: Reference point between the UPF and a Data Network.

    N9: Reference point between two UPFs.

    N5: Reference point between the PCF and an AF.

    N7: Reference point between the SMF and the PCF.

    N8: Reference point between the UDM and the AMF.

    N10: Reference point between the UDM and the SMF.

    N11: Reference point between the AMF and the SMF.

    N12: Reference point between AMF and AUSF.

    N13: Reference point between the UDM and Authentication Server function the AUSF.

    N14: Reference point between two AMFs.

    N15: Reference point between the PCF and the AMF in the case of non-roaming scenario, PCF in the visited network and AMF in the case of roaming scenario.

    N16: Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF in the home network).

    N16a: Reference point between SMF and I-SMF.

    N17: Reference point between AMF and 5G-EIR.

    N18: Reference point between any NF and UDSF.

    N19: Reference point between two PSA UPFs for 5G LAN-type service.

    N22: Reference point between AMF and NSSF.

    N23: Reference point between PCF and NWDAF.

    N24: Reference point between the PCF in the visited network and the PCF in the home network.

    N26: Reference point between MME (4G) and AMF

    N27: Reference point between NRF in the visited network and the NRF in the home network.

    N28: Reference point between PCF and CHF.

    N29: Reference point between NEF and SMF.

    N30: Reference point between PCF and NEF.

    N31: Reference point between the NSSF in the visited network and the NSSF in the home network.

    N32: Reference point between SEPP in the visited network and the SEPP in the home network.

    N33: Reference point between NEF and AF.

    N34: Reference point between NSSF and NWDAF.

    N35: Reference point between UDM and UDR.

    N36: Reference point between PCF and UDR.

    N37: Reference point between NEF and UDR.

    N38: Reference point between I-SMFs.

    N40: Reference point between SMF and the CHF.

    N50: Reference point between AMF and the CBCF.

    N51: Reference point between AMF and NEF.

    N52: Reference point between NEF and UDM.

    N55: Reference point between AMF and the UCMF.

    N56: Reference point between NEF and the UCMF.

    N57: Reference point between AF and the UCMF.

    N41: Reference point between AMF and the CHF in HPLMN.

    N42: Reference

    N58: Reference point between AMF and the NSSAAF.

    N59: Reference point between UDM and the NSSAAF.

NOTE : two reference points that appear in the diagram above are missing from this list, and one entry is incomplete. Worth adding when you next revise the page :

Entry Should read Where it shows up

N20

Reference point between AMF and SMSF

Drawn in the diagram between AMF and SMSF. The list jumps straight from N19 to N22

N21

Reference point between SMSF and UDM

Also drawn - it is the line from SMSF up to UDM

N42

-

The entry currently reads only "N42: Reference", with the definition missing

The N20 and N21 pair is a small but complete illustration of how a feature is bolted onto this architecture. SMS over NAS needs somewhere to live, so a function is added - the SMSF - and it needs exactly two connections : one to the AMF, which is the only function with a path to the UE, and one to the UDM, to find out whether this subscriber is allowed SMS at all. Two reference points, one new box, and the rest of the network is untouched.

Design Philosophy of 5G Core network

That reaction is a fair one, and it is worth taking seriously rather than waving away, because the comparison most people are making when they have it is not quite a fair comparison. Set this diagram beside a 4G core and 5G looks like several times the machinery for the same job. But it is not the same job. The 4G core was designed to do one thing well - deliver mobile broadband to handsets - and it was shaped accordingly. The 5G core has to serve a handset streaming video, a factory robot that cannot tolerate a ten millisecond delay, a water meter that wakes up once a day and must run for ten years on one battery, and a car moving at motorway speed, all at the same time and all on the same infrastructure. A single design tuned for any one of those is the wrong design for the other three.

Once you see it that way, the second thing worth noticing is that the complexity did not really increase - it moved. Take almost any individual function in the diagram and it is simpler than its 4G ancestor, not more complicated. The AMF does less than the MME did, because the session half of that job went to the SMF. The UPF does less than a PGW, because everything except forwarding packets was lifted out into the SMF. What grew was not the boxes but the number of relationships between them, which is exactly why the picture looks busy. You are trading a handful of complicated nodes for a larger number of simple ones plus a great many arrows.

The reason that trade is worth making is that it lets a network be assembled from only the parts it actually needs. If an operator has no interest in network analytics, the NWDAF is simply never deployed and nothing else has to change. If one slice serves metering devices that never make a voice call, it does not have to carry the machinery that voice would require. And when one function becomes a bottleneck it can be scaled on its own, rather than forcing an upgrade of a large node that happened to contain it. None of that is possible when the functions are welded together, which is the real reason the 4G core could not simply be extended.

It would be dishonest to present this as free. More moving parts means more things to configure, more interfaces to get wrong, and a system that is genuinely harder to troubleshoot - when a call fails you now have several functions to eliminate rather than one or two. Automation and orchestration stop being conveniences and become necessities, because no one is going to configure this by hand. That cost is real, and it is the price paid for the flexibility described below.

At first glance, you may think 5G core is too complicated and look over-designed. There is some design philosophy behind the architecture.

  • Flexibility: The 5G core network was designed with flexibility in mind, allowing network operators to deploy new services and features quickly and efficiently. This is achieved through the use of network slicing, which enables the creation of virtual networks that can be tailored to specific applications or user groups, providing customized service levels and performance guarantees.
  • Scalability: The 5G core network is designed to be highly scalable, allowing network operators to easily add new users, devices, and services to the network. This is achieved through the use of virtualization, which enables network functions to be separated from the underlying hardware and deployed as software instances. This allows network operators to scale their networks more easily and reduce costs.
  • Virtualization: The 5G core network is designed with virtualization in mind, which allows network functions to be separated from the underlying hardware and deployed as software instances. This enables network operators to deploy and manage network services more efficiently, reduce costs, and scale their networks more easily.
  • Automation: The 5G core network architecture is highly automated, with many of the network functions being automated and managed through software. This automation allows network operators to provision, configure, and manage their networks more efficiently, reducing operational costs and improving network performance.
  • Security: Security is a fundamental design philosophy of the 5G core network architecture. The network is designed with built-in security features such as mutual authentication, encryption, and secure transport protocols to protect against cyber attacks and ensure the privacy and integrity of user data.
  • Cloud-native: The 5G core network architecture is designed to be cloud-native, with network functions deployed as software containers that can run on public, private, or hybrid cloud environments. This allows network operators to take advantage of the scalability and cost-efficiency of cloud computing while maintaining control over their networks.

Reference

YouTube