IP and Mobile Trends and Education


5G Core Network Functions



As a follow up from our previous post on 5G Core Network (5GC) and system architecture, today I’d like to touch upon the 5G network functions (NFs) that are related to core network. As we’ll see, some of them look very similar to the corresponding functions in the previous generations’ core networks (CN). This of course is not surprising, as the network always has to carry out some basic functions such as: communicate with the UE, store its subscription and credentials, allow access to external networks & services, provide security and manage the network access and mobility. However, we will also see some new functions, that were not present before, which are needed to enable the new network paradigms like slicing and service-based networking.


Service-Based Architecture (SBA)

To describe the CN functions themselves, let’s firstly look at the system architecture from 3GPP SA2 on the following figure.

5G Core Network SBA

Figure 1: 5G System: Service-based architecture (SBA) [1]

We can see that part of this architecture, looks like good old LTE/3G with similar nodes and interfaces (lower part of the picture). However, the upper part of the figure (5GC Control Plane), has a “bus” and service-based interface exhibited by individual function. This creates a so-called Service Based Architecture (SBA), in which, one CP network function (e.g. SMF) allows any other authorized NFs to access its services. According to [1], the NFs within 5GC Control Plane, shall only use service-based-interfaces for their interactions.

Note: If you want to revisit the “good-old” reference point architecture representation for 5G, read our other blog on the general 5GC aspects: [5G CN Overview]. Yes, the 5G system architecture with reference points is still there.


Network Functions (NFs)

Ok, let’s discuss a bit of the 5GC network functions themselves and what functionalities do they support (note that not all functionalities of individual functions are present). The main 5G NFs are the following:

  • Access and Mobility Management function (AMF) supports: Termination of NAS signalling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. (AMF has part of the MME functionality from EPC world)
  • Session Management function (SMF) supports: session management (session establishment, modification, release), UE IP address allocation & management, DHCP functions, termination of NAS signalling related to session management, DL data notification, traffic steering configuration for UPF for proper traffic routing. (AMF has part of the MME and PGW functionality from EPC world)
  • User plane function (UPF) supports: packet routing & forwarding, packet inspection, QoS handling, acts as external PDU session point of interconnect to Data Network (DN), and is an anchor point for intra- & inter-RAT mobility. (UPF has part of the SGW & PGW functionality from EPC world)
  • Policy Control Function (PCF) supports: unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR. (PCF has part of the PCRF functionality from EPC world)
  • Authentication Server Function (AUSF) acts as an authentication server. (part of HSS from EPC world)
  • Unified Data Management (UDM) supports: generation of Authentication and Key Agreement (AKA) credentials, user identification handling, access authorization, subscription management. (part of HSS functionality from EPC world)
  • Application Function (AF) supports: application influence on traffic routing, accessing NEF, interaction with policy framework for policy control. (same as AF in EPC world)
  • Network Exposure function (NEF) supports: exposure of capabilities and events, secure provision of information from external application to 3GPP network, translation of internal/external information. (not present in EPC world)
  • NF Repository function (NRF) supports: service discovery function, maintains NF profile and available NF instances. (not present in EPC world)
  • Network Slice Selection Function (NSSF) supports: selecting of the Network Slice instances to serve the UE, determining the allowed NSSAI, determining the AMF set to be used to serve the UE. (not present in EPC world)



As we can see from the description of the individual NFs, some of them are a modified, split or merged version of the good old EPC functions (like MME, SGW, PGW, HSS & PCRF) namely, AMF, SMF, PCF, UDM, AF, UPF or AUSF, but unlike EPC functions, AMF, SMF and UPF should be access independent.

On the other hand, there are some functions that are new, related either to the concept of slicing (i.e., NSSF), to support handling multiple slices, or to the SBA itself (i.e., NEF & NRF) to support the concept of services subscription, exposure and access.

Another thing is that in this architecture, we have a full CP & UP split in the core network, i.e. UPF supports UP data processing, while all other nodes act as CP functions (this is a bit different compared to EPC, where, e.g. PGW was acting a bit as UP and CP node, having some DHCP functionality and IP address allocation and PCEF functionality).  This allows for independent scaling of CP and UP functions for the operators and for handling network slices efficiently to tailor them to support different services.



[1] 3GPP TS 23.501 V15.0.0 (2017-12) System Architecture for the 5G System (Stage 2)



Marcin Dryjanski

Marcin Dryjanski received his M.Sc. degree in telecommunications from the Poznan University of Technology in Poland in June 2008. During the past 8 years, Marcin has served as R&D Engineer, Lead Researcher, R&D Consultant, Technical Trainer and Technical Leader. He has been providing expert level courses in the area of LTE/LTE-Advanced for leading mobile operators and vendors. Marcin provides consulting services to business projects in the area of 5G related topics. In addition to that, Marcin was a workpackage leader in EU-funded research projects aiming at radio interface design for 5G including FP-7 5GNOW and FP-7 SOLDER. He co-authored a number of research papers targeting 5G radio interface design. To contact Marcin please write to:

10 March 2018 at 14:25


Curious to know, what is the main reason why 3GPP choose to introduce the “Not Allowed Area” concept in 5G. Why keep the UE is kept registered while it cannot get any user (PDU) services? what is the use case behind this as we do not have this concept in 4G NAS.

Thank you.

Marcin Dryjanski
12 March 2018 at 07:45


according to TS 23.501, the “Non-Allowed area” is an Area where the UE is allowed to initiate registration procedure, but no session management. If you take a look on the other two possibilities i.e.:
* in the “allowed area” the UE is registered in the network and update its location over NAS, and can initiate session (by service request),
* in the “forbidden area”, the user cannot register to the network, but can use the emergency services,
the “non-allowed area” is in the middle, i.e., the UE can register and send periodic registration update and can respond to paging from 5GC, and the emergency services are allowed, but cannot set the actual services.

This is to realise “mobility-on-demand” i.e., to support mobility only to the UEs that need it. More specifically, in a “non-allowed area” a UE is “service area restricted” based on its subscription. So, if you define a UE as “stationary”, it will only be able to reach its services within a “restricted area” and not outside.

Hope this helps,

15 March 2018 at 12:40

Dear Marcin,

Thank you for your response.

As per the above example, a “stationary UE”, if it is brought out sides its “allowed area” ( i.e. into “not allowed area”) is not going to get any user services (PDU sessions) from the network, but the registration context still remains and also its reachable for CN paging.
So you mean that it is more efficient way of handling in 5GC as compared to LTE EPC , the similar thing to achieve in LTE EPC would need reject causes but then it also removes the UE’s registration context and hence makes it unreachable ?

Thank you.

Marcin Dryjanski
15 March 2018 at 13:28

I think that in general this allows for more generic approach – i.e., you don’t have to have any special actions (as you mentioned reject causes etc.,) for specific cases, but handles different options using a single way and this suits well the slicing concept where you configure the tracking areas and allowed/non-allowed area depending on your situation. So in general I’d say that 4G could handle a lot of things that 5G is suppose to do (also slicing was sort of touched by DECOR), but as an add-ons to the baseline, while 5G should be more “generic” and “flexible” and “future proof” so that the new “cases” could be added / handled easier than modyfing a lot of 3GPP TSs’ contents.

15 March 2018 at 14:32

Thank you Marcin for your valuable feedback and explanation. In sync and agree to your comments.

Kind regards,


Leave a Reply

Your email address will not be published. Required fields are marked *