Schedule a free product or technology session with Grandmetric Engineer
schedule a video call

Blog

IP and Mobile Trends and Education

 

5G Core Network Functions



02.03.2018

Introduction

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)

 

Summary

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.

 

References/resources

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

[2] https://academy.5g-courses.com/courses/towards-5g-online-course

Author

Marcin Dryjanski, Ph.D.

Marcin Dryjanski received his M.Sc. degree in telecommunications from the Poznan University of Technology in Poland in June 2008 and Ph.D. in September 2019. 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: marcin.dryjanski@grandmetric.com

28 Comments
Rahul
10 March 2018 at 14:25

Hello,

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.
Nitesh

 
Marcin Dryjanski
12 March 2018 at 07:45

Hi,

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,
Marcin

 
Rahul
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.

 
Rahul
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.

 
Rahul
15 March 2018 at 14:32

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

Kind regards,
Nitesh

 
Rahul
15 March 2018 at 14:32

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

Kind regards,
Nitesh

 
Aayush Bhatnagar
1 October 2018 at 03:30

One of the good use case of “Not Allowed Area” is in India.

Many times, regulatory bodies ask carriers for barring of voice and data services selectively in a given geographic area – due to law and order concerns.

Services are allowed after a certain time window, which is intimated by the regulators on-demand.

In LTE, for such cases – we achieve service barring at many levels – TAC level, Cell-ID level as well as at the APN level, all orchestrated by the PCRF. Only emergency services are allowed in such cases.

In 5G, these use cases will become simpler to handle due to the “Not Allowed Area”,

 
Gulshan Khurana
8 February 2019 at 10:27

Completely agree, till 3G or 4G complete system access barring is the only solution on IMSI level, then one needs to worry about Inroamer barring etc and service type barring as well.
With “Not allowed area” this can be resolved

 
LTE and 5G differences - Function Decomposition Between RAN and CN
21 May 2018 at 21:08

[…] many more of CP functions in the full 5GC architecture – see our posts discussing them here: 5G Core Network Functions and 5G Core Network […]

 
LTE and 5G differences - Function Decomposition Between RAN and CN
21 May 2018 at 21:56

[…] many more of CP functions in the full 5GC architecture – see our posts discussing this here: 5G Core Network Functions and 5G Core Network […]

 
Luis Di Nisio
1 August 2018 at 19:10

What is the diference between HSS and UDM?

There is any diference bwtween HSS and UDM with respect to interface and protocol, Could we use the same HSS for 5G?

Regards,
Luis Di Nisio
Core Engineer

 
Marcin Dryjanski
8 August 2018 at 13:34

Hi Luis,

UDM has only part of the original HSS functionality and the interface is also different: to backup this you can check this presentation by ITU showing mapping of the 4G CN nodes to 5G CN: https://www.itu.int/en/ITU-T/Workshops-and-Seminars/201707/Documents/Joe-Wilke-%205G%20Network%20Architecture%20and%20FMC.pdf

In the case of using HSS for 5G, it depends on what you actually mean by 5G – if its the full blown 5GS (5GC + NGRAN), the related nodes are UDM and AUSF and they use SBA principles with service type interfaces. While if you mean 5G by using NSA with 5G NR being suplement to LTE, the core network comes from EPC thus the corresponding node is HSS.

Hope this helps,
Marcin

 
Adnan Farooq
17 April 2019 at 06:52

Do you know the interface name between AMF & NRF?

I am aware of Nnrf but looking for exact number, like N2 etc.

 
Marcin Dryjanski
8 May 2019 at 13:05

Dear Adnan,

thanks for the question. NRF is present “only” in the service based architecture version of 5GC. I.e. there is no defined reference point (“like N2”) for NRF to any of the other NFs within the home domain (see 3GPP TS23.501 for reference). The only point where NRF is connected via reference point (“like N2”), is where we have a roaming scenario and NRF in home network connects to NRF in visited network and both NRFs are connected with N27.

Hope this clarifies the issue.

/Marcin

 
Ruben
11 July 2019 at 16:31

What does it mean access independent in the following sentence?
“unlike EPC functions, AMF, SMF and UPF should be access independent”

They will work independently of the RAN type (2G, 3G, 4G, 5G)? Backwards & forwards compatibility?

 
Marcin Dryjanski
15 July 2019 at 23:15

Hi Ruben,

thanks for your question. Access independent means two things in this context:
* first – it enables independent evolution of the access network from the core network (i.e., separates RAN from CN);
* second – it is access independent, because it allows the evolved LTE connect to the 5GC and NG-RAN connect to the same 5GC. As per TR23.799, the 5G System shall support the NR, the Evolved LTE, and non-3GPP access types. GERAN and UTRAN are not supported.

Hope this helps,
Marcin

 
aravind Sirsikar
18 July 2019 at 10:29

HI Marcin Dryjanski,

Just wondering how SMF can allocate the UE IP address for MEC cases(Ex: LIPA).

In LTE, PGW allocates the IP address, in normal cases.
In MEC cases, there is a provision to have the PGW locally at RAN(LGW). Which allocates the local IP address.

Is there similar concept adopted in 5G as well?

Thanks,
Aravind Sirsikar

 
Marcin Dryjanski
23 July 2019 at 10:23

Hi Aravind,

The SMF either allocates UE IP address or acts as “sort-of” proxy for the IP address allocation when the address is allocated by external data network (according to the below quotes, the SMF is always in the process).

According to 3GPP TS23.501: “The SMF shall process the UE IP address management related messages, maintain the corresponding state information and provide the response messages to the UE. In the case that the UE IP address is obtained from the external data network, additionally, the SMF shall also send the allocation, renewal and release related request messages to the external data network and maintain the corresponding state information.”

According to 3GPP TS 29.561: “The 3GPP network may obtain IP address via external DHCP server during the PDU establishment procedure, the SMF acts a DHCP server towards the UE and it acts as a DHCP client towards the external DHCP server. ”

And according to ETSI White Paper No. 28: “The SMF is in a key position with its large number of responsibilities. Some functionality provided by the SMF includes session management, IP address allocation and management, DHCP services, selection/re-selection and control of the UPF, configuring the traffic rules for the UPF, lawful interception for session management events, charging and support for roaming. As MEC services may be offered in both centralized and edge clouds, the SMF plays a critical role due to its role in selecting and controlling the UPF and configuring its rules for traffic steering. The SMF exposes service operations to allow MEC as a 5G AF to manage the PDU sessions, control the policy settings and traffic rules as well as to subscribe to notifications on session management events.”

Hope this helps,
Marcin

 
Sandeep Agarwal
11 October 2019 at 06:10

Dear Marchin,

Do you have any article for MEC? How does it work and help for low latency?

Thanks
Sandeep Agarwal

 
Marcin Dryjanski, Ph.D.
14 October 2019 at 20:40

Thanks for the question Sandeep,

regarding MEC, you can check out this article: http://www.eurecom.fr/fr/publication/5218/download/comsys-publi-5218.pdf (a scientific one about MEC in LTE for low latency), and a short one from ETSI: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf

I would recommend those two.

Hope this helps,
Marcin

 
Sandeep Agarwal
11 October 2019 at 06:25

Hi Marchin,

LBO ( Local Breakout) is old concept from LTE or 3G times but it was not implemented by most of the MNOs because of billing complications. In 5G is LBO different than 4G LBO? Do you think MNOs would implement it in 5G to reduce latency or it should not be implemented again same as earlier?

Thanks
Sandeep Agarwal

 
Marcin Dryjanski, Ph.D.
14 October 2019 at 20:37

Hi Sandeep,

an interesting question. I believe this time it could be a little different, as 5G can use the MEC concept and a native tight interworking with Wi-Fi, while in LTE LBO was added on top of the existing infrastructure.

 

Leave a Reply

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

*

code


 

Newsletter