Devaki Chandramouli1, Subramanya Chandrashekar2, Andreas Maeder3, Tuomas Niemela4, Thomas Theimer3 and Laurent Thiebaut5
1Nokia, Irving, TX, USA
2Nokia, Bangalore, India
3Nokia, Munich, Germany
4Nokia, Espoo, Finland
5Nokia, Paris‐Saclay, France
Consumer demand continues to be insatiable with ever growing appetite for bandwidth that is needed for 4K or even 8K video streaming, augmented and virtual reality and multiple devices, among other use cases. On the same token, operators want the network to be “better, faster and cheaper” without compromising any of these three elements. Furthermore, operator demands are not homogeneous in terms of requirements or in terms of timing for deployment of new services.
In recent years, the emergence of Internet of Things (IoTs) has provided us with abundance of different use cases, each of them with their own demands for the network. This creates a business landscape for network operators where many new business partners, verticals, come and go, each with a need for a service level agreement (SLA) of their own.
As opposed to previous generations that targeted one type of device (a mobile phone for 2G, a smartphone for 3G/4G) and one type of user, the 5G network needs to serve a diverse set of devices and applications, e.g. from super secured and expensive phones for security forces to cheap and “dumb” IoT devices. Furthermore, the same device may host or relay very different applications ranging from resilient voice services to simple IoT services.
Consumer needs for more bandwidth continue to increase, with virtual and augmented reality leading the way toward connections with ultra‐high bandwidths and very low latency. The challenge for the network operator is to deploy a network with these characteristics at reasonable costs. The most challenging part is to provide it cheaper than previous generation of networks.
Beyond providing better service for the several billion humans already connected, there is a need to also connect the currently non‐connected ones (humans and things) and in some cases, offer 5G as a replacement for fixed access (e.g. Industries, enterprise, etc.). This requires cost efficient solutions. As 5G will be a mature technology some day, it is beneficial to have a system that enables providing essential functions at minimal complexity and costs.
As a summary, following are key drivers for the new architecture:
In short, the new network is expected to be more “flexible, faster and cheaper.”
Translating service expectations to objectives for the new architecture has led to the following solution categories:
Service flexibility means that the architecture needs to support different lifecycles for different network services. It should be easy to add a new service to the network, control which users are allowed using it, parametrize the service per group of users and control network resource usage per group of users. Equally important is the capability to easily remove services from the network.
Modular and extendable architecture allows to add new network functions (NFs) and modify existing network functions with limited or no impact to existing functions. Extending functionality while maintaining key paradigms of the architecture is essential for enabling the architecture to evolve without increasing overall complexity.
An architecture based on unified policy control allows to build consistent policies covering the entire network behavior and to some extent also the user equipment (UE) behavior. This way diverse use cases can co‐exist, and operators keep full control over use cases and offered services. Assignment of functions like policy control to single functional elements of the architecture allows for consistent and less complex introduction and offering of new network services.
An access agnostic architecture allows to build a system utilizing multiple different access technologies. One device may simultaneously be served by multiple accesses, e.g. 3rd Generation Partnership Project (3GPP) access and non‐3GPP access. This applies not only to 3GPP and non‐3GPP accesses but also to different variants of 3GPP access. Thus, the 5G system allows access via “NR” (New Radio) as well as long term evolution (LTE) radio. This also implies that mobility of a UE (device) from one access technology to another should be seamless for the end user (i.e. without service interruption).
Automated network deployments are crucial for being able to take advantage of the architecture flexibility. This implies that the new 5G Core should be designed to enable operational agility. Without full automation, operational costs will prevent customized support for verticals and IoT service providers.
One of the most frequently asked question was: “Can the existing Evolved Packet Core (EPC) efficiently support the new services of the 5G era?” Considering the expectations on the network, device and application evolution, the answer was clearly “No.” The EPC architecture was designed mainly for the mobile broadband use case. Furthermore, the functional split defined for EPC was “box‐driven,” i.e. assuming dedicated hardware (bar‐metal) deployments. For the 5G architecture, virtualization was considered as a basic design principle. Furthermore, the new 5G system is required to support ultra‐low latency and high reliability use cases simultaneously at reasonable costs.
EPC was developed for Internet and operator voice services in mind. Therefore, it is lacking support for the diverse service landscape of the 5G era and is not being inherently cloud native.
Service flexibility is supported in evolved packet system (EPS) only in terms of providing network differentiation on a per UE basis. There is no method available to introduce multiple services per UE with different network parametrization and a different set and topology of network functions.
Modularity and extendibility is lacking in EPS because of three main reasons:
Policy control is limited to QoS and charging aspects. There is no unified method for providing other kinds of policies, e.g. mobility policies and network selection policies.
The Core Network architecture is not access agnostic; it requires dedicated interworking functions (enhanced packet data gateway [ePDG]/trusted wireless LAN access gateway [TWAG]) for non‐3GPP access each replicating a lot of the functionalities supported by MME, and S‐GW. Thus, as an example, when introducing features like emergency sessions almost the same functionality needs to be defined, tested (inter‐operability tests) and deployed in multiple network functions (MME, S‐GW, ePDG, TWAG).
There is no unified core network architecture with common control and user plane (UP) functions supporting 3GPP and non‐3GPP accesses.
Automation is not supported natively in the EPS network architecture beyond European Telecommunications Standards Institute (ETSI) defined Network Function Virtualization (NFV) related implementation and instantiation of virtual network functions. Automation is built only as vendor specific functionality in the management plane, there is no structural support for automation in the network architecture.
Based on the drivers and motivations for the new architecture, the following requirements can be identified for this new architecture:
Besides all the expectations and requirements for the new architecture, another non‐technical challenge with the new architecture development is the “timing aspect.” Market needs are not homogeneous around the globe.
Some operators wish to deploy 5G radio early as a capacity boost leveraging existing LTE and EPC deployments, mainly to offer enhanced broadband services.
Some operators wish to deploy both 5G NR and new core network early to offer enhanced broadband services including network slicing.
Some operators wish to deploy a revolutionary new core network with many new features but had no urgency regarding the deployment timeline.
To ensure that we have a global ecosystem with the right balance on schedule and features supported, 3GPP agreed to a phased approach.
To ensure phase 1 is completed in a timely manner, 3GPP agreed to prioritize essential requirements for foundational network.
Architecture domains can be defined in many ways, depending on the viewpoint and targeted characteristics. There are practical constrains on the number of domains. Too few domains lead to monolithic structure that prevents “divide and conquer” approach for managing complexity, whereas too many domains lead too overly complex interactions between domains and unclear responsibilities for each domain.
The first principle for splitting the network is difference between distributed radio access nodes and central processing functions. Antenna and radio frequency (RF) units need to be distributed due to laws of physics while processing should be centralized due to laws of economics. Adding computing power to highly distributed sites will never be as cost efficient as adding it to central sites, but it might be necessary for some use cases and services.
Second principle is the split of management, control and user plane processing functions. Management and control plane are a natural split based on the very different tasks these planes have, management dealing with infrequent needs of operating personnel while control plane dealing with the very frequent needs of end user devices and their users. This layering allows to keep the control plane more centralized while enabling the user plane to be more distributed for improving end user experience and to some degree reducing transport costs, in alignment with the locations where the services are provided. This also acknowledges the different implementation approaches needed for control plane (focusing on how to achieve an easily maintainable and extendable solution) and user plane (focusing on how to achieve high throughput and low latency cost effectively).
Third principle is the separation of access and core related processing. This also creates a natural split between managing the radio resources and managing the user connections (the latter predominantly a core function).
Fourth principle is the breakdown of core control plane into several Network Functions. This is necessary to manage the high complexity of this domain.
Fifth principle is the separation of the core functions from the applications. Figure 4.1 shows the architecture domains resulting from the described principles.
Connectivity services are required from various locations. Internet connectivity (i.e. inter‐connection between mobile network and Internet service provider) can be highly centralized especially from the perspective of a mobile network user. But it is also possible that some services, such as video streaming, are provided from a local cache to optimize transmission resources of the operator and to reduce the delay experienced by the end‐user. Connections to enterprise networks, be that to an office premises or to a factory can be highly local in nature. Cities may offer its residents and visitors services that are hosted within the city boundaries.
For these and many more scenarios it is beneficial to optimize the data path from the mobile network user to the service's point of presence. This optimization is relevant for latency as well as for bandwidth purposes. Latency depends both on the physical distance as well on how many processing hops the connection needs to traverse, thereby localizing the service provides a direct benefit by reducing latency. Bandwidth optimization is a slightly more complex topic but having a high bandwidth connection across a wide network area puts more strain to the transport network than being able to provide the service locally. This is especially true for very popular videos where local caching of data content may provide fair savings in the operator backbone.
Since not all services and content can be localized, the architecture must support flexible connectivity models that allows a single UE to connect to multiple data networks (DNs) and to multiple access points simultaneously, enabling optimizing the topology per service. This requires that the UE can connect to multiple interfaces to a DN simultaneously, each interface to a DN being in various places in the topology.
Figure 4.2 shows this kind of a flexible connectivity model with radio access network (RAN) connecting to multiple user plane (UP) entities which connect to different data networks. The architecture defined to support these principles is further described in Section 4.3.
Traditional telco architectures are based on point‐to‐point interfaces between two network elements. Often those interfaces are designed to be different, not only in the structure of the application layer but on the transport stack as well. This tradition has led to architectures that are unnecessarily complex, require a lot of effort in extending or modifying the functionality and don't facilitate reuse functions across the system.
To design a system that is flexible and future proof, the following requirements need to be supported:
To fulfill these requirements, the basic paradigm is for each network function to provide its' services via application programming interfaces (APIs), for each network function instance to register itself as a provider of these services to a central repository function and for all network functions intending to use those services to query the central repository on the instances providing the services (Figure 4.3).
This paradigm enables each service to have its' own lifecycle, to easily add new services without impact to any other service and to decouple the service provider and service user in a sense that a new version of a service, or a completely new service, doesn't impact the user until the service user is ready to use this new version or the new service (with the old version of the service being simultaneously available for as long needed).
An operator can define multiple policies on how the network should behave, or how it should not behave, and what behavior is allowed or not allowed for a device. In a diverse service landscape, different policies are needed to control how the network interprets the required characteristics of a service for a user. Policy control ensures a systematic and unified behavior on those aspects where this is needed. Policy control is the way how new functions can be introduced into the network and gain awareness of the required behavior. Therefore, the requirements for a policy control architecture are as follows:
A programmable network is a network where the network functions, or rather their services, and the data they store, can be easily tailored for various applications to fit their needs.
On one hand this requires the capability to orchestrate network functions as use case specific resources with their own parameter sets, isolated from those functions serving a different use case. This is called network slicing, and is described in Section 4.7.
On the other hand, the architecture needs to enable external or internal applications to influence the behavior of network functions and enable network functions to expose network events to applications.
To control what is exposed and to whom, network functions should not expose information directly to the external network but via a well‐defined (central) exposure function. This function should authenticate and authorize access to services and data and hide the network internal architecture from the external domain. Within the core control plane domain, the network functions can use each other's services directly. The architecture for controlling the exposure of information is shown in Figure 4.4.
Cloud native refers to network functions being inherently designed to operate in a cloud environment. This means not only the ability for the network function to be efficiently executed on top of a virtualized infrastructure but also to fulfill the expectations on automation and business agility.
Cloud native network functions should be:
In general, cloud native means building the network function as a flexible software product that can be easily tailored, managed and deployed.
Traditionally new 3GPP access technology generations have been defined as standalone (SA) overlay networks where the new RAN is independent from the old RAN with core network interworking capabilities enabling inter‐system mobility. This kind of deployment model is still valid and needed for 5G as well. However, considering the diverse spectrum options available for 5G, the need for a more tightly LTE integrated deployment model, called Non‐Standalone (NSA) is needed. This is primarily resulting from the following issues:
These issues can be solved by the NSA model, where 5G NR is a secondary cell to the LTE master cell (or vice versa), using aggregation via dual connectivity to achieve:
When 5G coverage becomes good in selected areas it may be beneficial to reverse the roles between LTE and 5G by making 5G the master and LTE the secondary access. This enables faster setup times compared to a NSA solution with signaling via LTE.
RAN architecture is mainly driven by cost efficiency, providing high throughput per user and cell, low latency for services and multi‐access aggregation of different RAT(s) (Radio Access Technology). Thus, the 5G RAN architecture follows to below mentioned key principles:
The centralized RAN unit can be realized as a virtual network function running in an edge or radio cloud. Figure 4.5 shows the high‐level RAN architecture.
Interworking can be divided into two levels:
The capability to aggregate multiple RATs into a single access connection is a very desirable property as it provides increased capacity, coverage and reliability for a connection. This kind of aggregation is relevant for LTE and 5G and requires a common anchor point in the RAN as well as common procedures over the radio interface to flexibly and dynamically use any of these access technologies based on whichever is best suited considering the service requirements, radio resource availability and coverage situation.
Even though the 5G System allows integrating LTE radio access, this requires upgrades to the LTE eNB as the eNB need to support the (new or updated) procedures and interfaces defined for the 5G Core. To enable an independent deployment and evolution of the different access technologies, a core network based interworking solution between legacy core (EPC) and new core (5GC) is needed (Figure 4.6).
For applications such as internet protocol multimedia subsystem (IMS) it should be transparent whether a user is currently served by the legacy core (EPC) or by the new 5G Core (5GC). Thus, core entities facing the applications (API exposure, subscriber database) shall hide from applications which core network (EPC/5GC) is currently serving the user.
The requirement to support interworking for all existing legacy mobile access systems has created considerable complexity to EPC with the definition of complex mechanisms for circuit switched (CS) voice interworking such as Circuit Switched Fall Back (CSFB) and Single Radio Voice Call Continuity (SRVCC). Since in the advent of 5G the role and coverage of legacy systems like 2G and 3G will be further reduced and since LTE provides already good coverage in many countries, defining direct interworking between 2G/3G and 5G is no longer justified. The same logic applies to the voice service interworking, making IP based (IMS and over‐the‐top (OTT)) voice services the only supported voice services in 5G. In cases when there is need for interworking with 2G/3G, including CS voice interworking, it can be done with the help of LTE/EPC. However, some operators expressed strong demand to enable voice call continuity between 5G and 3G (which is being defined in 3GPP Rel‐16). They used the following two scenarios to justify their requirement:
The 5GS architecture is built around NF (Network Functions) that are the smallest set of functionalities deployable in a multi‐vendor environment. Internal interfaces, structures and contexts within a NF are not subject to standardization.
Figure 4.7 shows the non‐roaming architecture model, while Figure 4.8 shows the roaming architecture model.
Some key principles that were adopted for the new architecture are the following:
Compared to previous generations, the 3GPP 5G System architecture is service‐based. That means wherever suitable the architecture elements are defined as network functions that offer their services via interfaces of a common framework to other network functions that are authorized to make use of the provided services (either using request/response or subscribe/notify transactions). The Network Repository Function (NRF) allows every network function to discover the services offered by other network functions. This architecture model, which further adopts principles like modularity, reusability and self‐containment of network functions, was chosen to enable deployments considering the latest virtualization and software technologies. The related SBA figures depict those service‐based principles by showing the network functions, primarily Core Network functions, with a single interconnect to the rest of the system. Reference point‐based architecture figures are also provided by 3GPP in TS 23.501 [1], which represent the interactions between network functions for providing system level functionality and to show inter‐public land mobile network (PLMN) interconnections across various network functions.
The 5G System architecture comprises of the following Network Functions:
For the reader's reference, the outcome of 3GPP normative 5G System architecture work is documented in:
Stage 3 Technical realization of Service Based architecture is documented in 3GPP TS 29.500 [14]. In case of roaming with local breakout, the roaming UE connects to the Data Network (DN) in the visited public land mobile network (VPLMN). NSSF, AMF, SMF, UPF and AF are in the VPLMN. The SEPP protects and simplifies the interactions between PLMNs. The home public land mobile network (HPLMN) provides UDM, AUSF and PCF. Other scenarios and corresponding architecture figures are all covered in 3GPP TS 23.501 [1].
Figure 4.9 shows the network functions (NF) that make up the 5G core control plane. The following further describe the role and functions of each of them.
In accordance with SBA principles, each network function offers services to other network functions. Interfaces to other domains are still point‐to‐point in nature and are thus not directly connected to the SBA framework.
The SBA protocol framework enables flexible definition and re‐use of services, easy modifications and easy integration to external domains via the NEF.
The Access and Mobility Management (network) function (AMF) terminates the Access Network to Core Network control plane interface (N2) as well as the UE to Core Network signaling (non‐access stratum, “NAS”) interface (N1). AMF features can be divided into following categories:
UE access control refers to the control of UE registration in the 5G System, including:
UE access security management consists of two functions:
UE mobility management includes:
NAS message routing provides a generic capability for other network functions to communicate with the UE using the NAS protocol. The initial use cases for this capability are SM signaling from/to SMF and short message service (SMS) delivery from/to short message service function (SMSF). This feature includes managing the UE signaling connection via the access network and paging the UE for transitioning from idle to connected mode when needed.
LI support includes delivery of AMF events to LI system.
AMF provides these functions for both 5G access (3GPP access) and non‐3GPP access such as untrusted non‐3GPP Access (e.g. access to 5G core via WLAN). Separate UE context is maintained for 3GPP and non‐3GPP accesses. Some functions (e.g. paging, handover procedures) may not be applicable to non‐3GPP access.
The AMF serving an UE is in the PLMN serving the UE: in the Visited PLMN when the UE is roaming, in the Home PLMN or an equivalent PLMN when the UE is not roaming.
Features supported by the SMF can be divided into following categories:
The “PDU session” is the (new) abstraction for 5G user plane services replacing the concept of a packet data network (PDN) connection in EPC. A PDU session provides connectivity between applications on an UE and a Data Network (DN) such as the “Internet” or private corporate networks in case of IP.
PDU session control supports establishing, modifying and releasing PDU sessions, including related tunnels between access network and UPF as well as between UPFs, when relevant. All characteristics of the PDU session, such as session and service continuity (SSC) mode are determined by the SMF based on UE request (NAS signaling) and on information received from the subscription data base UDM/UDR. Optional authentication and authorization of the PDU session by the external Data Network is also supported. Session control includes User Plane path establishment between UE and 5G Core when triggered by downlink data reception.
UE IP address allocation includes assigning an IP address, either from SMF's own internally managed IP address pool or via external entity like a dynamic host configuration protocol (DHCP) server or an authentication, authorization and accounting (AAA) server.
UPF selection and control includes:
Control of policy enforcement includes interacting with the PCF for obtaining policy rules and decisions related to the QoS and charging properties of the PDU session. These are propagated by the SMF to the UPF for enforcing policies on the data flow. The SMF supports interfaces to the charging system for usage reporting and credit control‐based charging related to PDU sessions. LI support includes delivery of SMF events to the LI system. Depending on the configuration, when the UE is roaming, a PDU session may be controlled by a SMF in the Visited PLMN and by a SMF in the Home PLMN. SMF features and PDU session related functionalities are further detailed in Chapter 6.
The PCF provides a single framework for defining any type of policies in the network and for delivering related policy rules to the other control plane network functions (NF), as relevant per each function.
In case the target NF is an SMF the policies sent by the PCF to the SMF may correspond to:
In the case where the target NF is an AMF the policies sent by the PCF are of two distinct categories:
Such kind of policy information was handled by the Access Network Discovery and Selection Function (ANDSF) in EPC. 5GC allows the PCF to co‐ordinate between connectivity related policies sent to the UE and policies sent to the network (SMF).
The PCF features can be divided into following categories:
Policy rule determination contains methods how policies governing different aspects of the network behavior can be defined and managed, considering:
How policy rules are determined and how they are influenced by local operator policies are not subject to 3GPP standardization.
Policy rule delivery contains methods for the PCF to:
The PCF can get subscription information and global application requirements from the UDR. The information being retrieved from the UDR can target an individual subscription, a group of users, all users of a roaming partner or any user.
The PCF may get application requirements targeting an individual PDU session via its service authorization exposure. Via this service authorization exposure an AF can provide requests targeting an individual PDU session identified by the UE address (IP or Ethernet address).
The UDM is a control function in the Home PLMN that supports access to the data storage. It allows for:
Subscription data management includes accessing the subscription data in the UDR, delivering relevant data to the NFs serving the UE (AMF, SMF) and updating the UE location and serving nodes (e.g. AMF) in the UDR. The UDM is always located in the Home PLMN of the UE.
The AUSF is responsible of the primary authentication and key agreement procedures carried out to enable mutual authentication between UE and network. It provides keying material that can be used between the UE and network in subsequent security procedures. The AUSF is closely linked to the UDM. The AUSF is always located in the Home PLMN of the subscriber.
The UDR provides storage and retrieval, of subscription data (by the UDM), policy data (by the PCF) and structured data for exposure (by the NEF).
In the roaming case, UDR in Home PLMN and UDR in Visited PLMN may be used to serve an UE. The UDR is in the same PLMN as the Network Functions storing data in and retrieving data from it using Nudr. Nudr is an intra‐PLMN interface. Subscription data, are stored in an UDR located in the HPLMN, while policy data or data for exposure can be stored in an UDR located in the VPLMN.
The UDSF provides storage and retrieval of unstructured data, such as session related data, for any NF (Figure 4.10). Deployment of the UDSF is optional, depending on the implementations of the NFs and operator desires. UDSF may be co‐located with the UDR to allow for a single data layer solution.
In the case of roaming, UDSF in Home PLMN and UDSF in Visited PLMN can be used to context for a given UE.
The NSSF and NRF are auxiliary functions deployed between the Operation, Administration and Maintenance (OAM) of the network and the Network Functions providing services for UEs. The NRF provides a service discovery function for the other Network Functions to use. NRF features include NF profile and NF instance management and NF service discovery.
NF profile and NF instance management includes NRF maintaining the list of NF instances and a profile for each instance. This profile includes, e.g. the address of the instance, the services supported and key attributes defining the domain in which these services are authorized to be used, such as network slice related identifiers and the PLMN ID.
NF service discovery contains the methods for NFs to query the NRF for discovery of NF instances providing a requested service or set of services and for the NRF to notify when the set of such instances has been modified.
Each PLMN runs its own NRF. Each part of the network that is separated from the rest of the network due to slicing may have its own NRF.
The NSSF selects the network slice(s) to be used for an UE. Basically, this consists of mapping Single Network Slice Selection Assistance Information (S‐NSSAI) to the actual Network Slice Instance Identifier (NSI). Additionally, the NSSF determines the set of AMF instances that can be used to serve the UE.
Each PLMN runs its own NSSF. The NSSF has an overview of all slices of the network.
The NEF provides a means for external domains to access data and capabilities of the 5G core control plane and to expose structured data within the core control plane domain.
The clients of the NEF may be external AFs possibly deployed by 3rd party operators or internal 5GC Control Plane NF(s); the NEF provides the capability to (re‐)expose APIs and data provided by other NFs. The Multi‐Access Edge Computing (MEC) platform is an example of a NEF client.
NEF features can be categorized in the following way:
Secure exposure provides means to authenticate and authorize (possibly throttle) the external domain entity to which data or capabilities are exposed. It may also create usage data that can be used to charge the external domain for the services rendered by the PLMN. The capabilities exposed by the NEF are described in Section 4.2.6.
Structured data exposure management consists of a service provided by the NEF to other NFs such that the NEF stores NF data as structured data in the UDR. These data can afterwards be provided to other NFs.
Mapping of identifiers and concepts consists of translating between identities used in the AF domain and identities used in the 5G core domain.
The SEPP is a non‐transparent proxy. It provides message filtering and policing on inter‐PLMN control plane interfaces, and topology hiding.
Detailed functionality of the SEPP is specified in 3GPP TS 33.501 [6].
Since the SEPP is a proxy, i.e. it transparently forwards messages from a NF in one PLMN to a NF in another PLMN without parsing the message, no service‐based interface is needed for the SEPP.
The 5G System relies on a generic UPF to handle the user plane traffic.
UPF(s) offer capabilities that can be programmed over the N4 interface by the SMF allowing flexibility for the deployment of 5G user plane features. UPFs can be geographically distributed or centralized. The 3GPP specifications place no restriction on the number of UPFs (cascaded UPFs) being used to serve a PDU session.
The following functions are offered by a UPF instance:
UPF features are further detailed in Section 6.7.
AF is not part of the 5G core but it can interact with the 5G core for various purposes, such as accessing 5G core data and capabilities via NEF, influencing how the traffic related to applications should be routed (e.g. via local UPFs) or informing the 5G core about the QoS needs of applications.
While external to the 5G core, some AFs may be considered by the operator to be in a trusted domain and thus allowed to access 5G core functions directly without using the NEF.
The motivation for a new system architecture for 5G as described in Section 4.1 applies in general to the RAN as well. However, there are some unique challenges which need to be considered. The design of the NG (5G) RAN architecture needs to have a healthy balance between evolution and revolution, to fulfill the novel requirements and operation paradigms on the one hand, and cost‐efficiency and best utilization of already existing deployments (e.g. LTE) on the other hand. NG‐RAN is defined as in Section 4.22.
In summary, the main drivers of the 5G RAN architecture design are the following:
The impact of the new 5G service requirements on RAN are vastly different in terms of network performance indicators, but also in the categories of cost efficiency and functional requirements. As an example, for massive IoT the cost factor for chipsets and modules is the most important due to the expected number of devices, low average revenue per device (ARPD), low peak rates and restricted periods of service and mobility.
The main challenge for the 5G RAN architecture is to support all requirements within one flexible framework, without compromising interoperability and manageability.
Figure 4.11 illustrates how the 5G main use cases integrate into a common RAN perspective. Important aspects are the tight integration of LTE with support for Dual Connectivity between LTE and NR, Fronthaul split architecture for different infrastructure and transport capabilities, multi‐hop self‐backhauling, and support for MEC (see Section 4.8), enabling for support local services operating on the same virtualized or physical infrastructure as RAN functions.
The 5G RAN functional architecture aims to achieve a unified framework which minimizes the need for specialized functions for different RATs (like 5G, LTE, Wi‐Fi) or radio interfaces (like wide area [WA], cmWave, and mmWave air interfaces).
Figure 4.12 illustrates these general principles. The 5G core network is access‐agnostic as far as possible, aiming to utilize common functionality for different RATs as far as possible. This facilitates independent evolution of core and radio, e.g. if a new RAT is to be deployed, and the use of a single RAN‐CN interface for both 3GPP and non‐3GPP access [30].
In RAN, common functions for different RATs are more challenging to achieve. However, there are strong functional similarities for NR and LTE, which is reflected in the NG‐RAN architecture. This re‐use of parts of the higher‐layer user‐plane protocol as anchor for multiple RAT and multi‐connectivity (MC) features, including routing, traffic handling and bearer mapping, and QoS/QoE enforcement. The control plane includes radio resource and mobility management, as well as radio resource control (RRC) protocol for different RATs which can have common and access‐specific aspects.
Furthermore, integrated radio resource management and control of multiple RATs for efficient coordination of radio resources Cloud RAN enables gains for system and cell edge capacity, as well as improved user experience with seamless and transparent inter‐RAT access.
RAN may be deployed in a radio cloud with a functional split between virtualized and physical network functions which reflects the infrastructure and service requirements of the operator. This is illustrated by the real‐time (RT) and non‐real time (NRT) parts of the radio protocols, which can be in a radio cloud or at the cell site.
The overall NG‐RAN architecture is reflected in Figure 4.13.
As described in the previous section, the overall 5G RAN architecture addresses the following main requirements:
These requirements are reflected in the overall NG‐RAN architecture as illustrated in Figure 4.13. It comprises the following elements:
The functional split between RAN and Core follows the principle that access specific functions which are concerned with radio resources are hosted in RAN nodes. This includes radio resource management in general, connection setup, scheduling, as well as functions for AMF selection and user‐plane routing. For more details, refer to [4].
The logical NG‐RAN architecture [25] supports interfaces such that a flexible placement and independent scaling of logical entities is enabled. Both centralized and distributed network deployments are supported by the architecture design. It depends on the operator's infrastructure and offered services which functions will be centralized and where to be placed. This is illustrated in Figure 4.14.
Figure 4.14 shows three possible configurations of a logical gNB, possibly deployed in the same network:
Depending on the fronthaul capabilities, both C‐plane and U‐plane RAN functionalities can be placed in centralized nodes. In this configuration, the smaller signaling effort between functions in the cloud enables an efficient coordination between them.
The very high bandwidth requirements on 5G make classical centralized radio access network (C‐RAN) deployments impractical, since those rely on the transmission of quantized radio symbols (raw data) between central and remote unit. This approach results in very high bandwidth requirements on the Fronthaul interface coming with high costs. The solution in 5G is to develop a new lower‐layer split (LLS) which requires less bandwidth, but still enables the benefits of C‐RAN such as gains from coordination and joint processing.
In case of lower layer split, the Fronthaul interface interconnects a central unit and many remote units where the latter hosts functions of the lower physical layer (PHY) of the logical radio node (see Figure 4.15 left‐hand side). Note that lower layer split and higher layer split options can be in principle deployed in parallel, i.e. either in a central unit which implements both higher and lower layer split interfaces, or in a multi‐tier deployment where both higher and lower layer split implementations are present for the same logical node.
Due to the complexity of the PHY, many different implementation options are possible, and it is less clear (compared to higher layers) how to group and split functions. This makes it more difficult to converge to a single split point, which is illustrated in the right‐hand side of Figure 4.15. In this example, four different split points are defined, each with its implementation‐specific advantages and disadvantages. Nevertheless, there are some common principles in all split options which need to be supported:
LLS is addressed in various industry fora and standardization bodies, including the Common Public Radio Interface (CPRI) industry cooperation, IEEE 1914.1 and in 3GPP.
The flexible functional split is a key feature for enabling (ultra‐)low latency services. Due to the strong requirements of below 1 ms end‐to‐end latency for certain services (see Chapter 1), service‐related functions need to be placed close to the access. How close depends on the specific service requirements. This necessity is adversarial to the objective of centralization and cloudification, which benefits from aggregation of processing‐intensive functions due to scaling effects. The solution to resolve this contradiction is the NG‐RAN logical split architecture with service‐aware placement of RAN functions as illustrated in Figure 4.16.
This example illustrates how the flexible functional split architecture can be used for service‐aware placement of functions. It also enables many other deployment scenarios which are not necessarily driven by service requirements, but by infrastructure capabilities, cost, or legacy deployments.
Figure 4.17 illustrates the generic control‐plane architecture of MR‐DC and EN‐DC, where the involved RAN nodes can host NR or LTE radio. The Master Node (MN) or Master eNB (MeNB) for EN‐DC takes RRC decisions and initiates procedures for SN (SeNB) management. In general, the UE follows the RRC state of the master to avoid state confusion. The MN is generally also the node which provides c‐plane connectivity to the 5GC (or EPC in case of EN‐DC). This is illustrated in Figure 4.17, which shows the involved RAN and CN interface depending on the DC type. Apart from some differences in terminology, both 5GC and EPC‐connected DC types employ connectivity from master and from secondary node to the core network, depending whether higher layers (i.e. at least PDCP) of the radio user plane is anchored in the master or secondary node, respectively (Figure 4.18).
Irrespective of the DC type, the functions for secondary node management (addition/modification/release/change), bearer setup, QoS mapping and others are very similar. For enhanced connection robustness, split transmission of RRC messages over the two involved radios is supported (via a so‐called split signaling radio bearer [SRB]). This reduces the probability of radio link failures, where the UE/RAN node ignores duplicate reception of messages, if both transmissions were successful. Furthermore, an additional SRB3 can be established to the SN to enable more autonomy of SN decisions and reduced signaling between SN and MN.
Different configurations for data radio bearers (DRB) are supported as illustrated in Figure 4.19. The PDCP layer is responsible for splitting and aggregating, or duplicating packets depending on the service requirements. A flow control mechanism (the same as employed by the F1‐U interface) between MN and SN avoids data starvation between RAN nodes. For EN‐DC, the X2 interface with flow control is used.
Since NR could be deployed over a wide range of spectrum (e.g. 600 MHz to 100 GHz) bands and the fact that operators have different needs, and the timeline to deploy NR, 3GPP specifications allow various NSA and standalone deployment options. Traditionally, 2G, 3G, and 4G were always introduced as standalone system in the first release of the specifications. NSA options were considered later, e.g. in LTE with the introduction of small cells in 3GPP Rel‐12. However, with NR, both NSA and standalone deployments options will be possible based already with the first 5G 3GPP release 15.
Figures 4.20–4.23 show the possible NR deployment options with a 5G Core.
Spectrum availability and radio coverage will be one of the key considerations for operators to determine the right deployment option. Following are the key considerations for operators to determine the right option:
Based on spectrum availability and radio coverage, most of the operators publicly expressed that they will start with a NR NSA architecture re‐using existing EPS (also referred to as Option 3 in 3GPP) before moving toward one or several of the options 2, 7, and 4 deployment options stated above. Due to the importance of option 3, we summarize the rationale, objective, and technical impacts of this deployment option 3 below (Figure 4.24).
For operators who want to quickly deploy NR to boost their radio capacity and user plane bandwidth in places where LTE starts to get saturated, 3GPP has defined an early drop of Rel‐15 specifications (completed in March 2018) where a gNB (RAN node that supports NR) is used as a secondary RAN node of a LTE eNB connected to EPC (Figure 4.25).
However, deployments using this option can't benefit of all the functionalities and features offered by the 5G System Architecture but can just provide a higher user plane throughput (where an EPS service can be simultaneously supported by both LTE and NR radio). Enhancements to EPS were introduced for connectivity of devices that support NR NSA with EPS NAS. It mainly encompasses the following enhancements:
It should be noted that the enhancements to EPS are purely optional. This implies that NR can be deployed in NSA mode with EPS. the UE can be offered basic connectivity with NR anchored to E‐UTRAN, without upgrading the existing EPC network elements (i.e. MME, S‐GW, P‐GW, home subscriber server [HSS]) in deployed networks.
Each subscriber and/or subscription to the 5G System is allocated one 5G Subscription Permanent Identifier (SUPI) for use within the 3GPP system. The 5G System supports identification of subscriptions independent of the UE. Each UE accessing the 5G System is assigned a Permanent Equipment Identifier (PEI). It is also required by the 5G System to support allocation of a temporary identifier 5G Globally Unique Temporary Identifier (5G‐GUTI) to support user confidentiality protection.
A globally unique 5G SUPI must be allocated to each subscriber in the 5G System and provisioned in the UDM/UDR. The SUPI is used only inside the network. The SUPI may either be based on international mobile subscriber identity (IMSI) as defined in 3GPP TS 23.003 [5], or it can be a network‐specific identifier, used for a private network.
To enable roaming scenarios, the SUPI must contain the PLMN ID (mobile country code (MCC) plus mobile network code [MNC]), especially for a IMSI based SUPI. SUPI is not expected to be used over the air (i.e. in clear) in the paging, access stratum (AS) or NAS messages exchanged with the UE.
The Subscription Concealed Identifier (SUCI) is a privacy preserving identifier containing the concealed SUPI. It is expected to be used in the NAS messages.
The AMF assigns a Temporary Identifier 5G‐GUTI to the UE for supporting subscriber confidentiality. The AMF leverages the same identifier to include routing information that the 5G‐AN node can use to determine how to route the NAS message. The UE is required to derive the 5G‐S‐TMSI (5G S‐Temporary Mobile Subscription Identifier), which includes the routing information, from the identifier (5G‐GUTI) assigned by the AMF and to provide that in the RRC message toward the 5G‐AN. The 5G‐AN uses the routing information present in the 5G‐S‐TMSI and routes the NAS message accordingly. Structure of the 5G‐GUTI and 5G‐S‐TMSI are as follows:
where
When an AMF assigns a 5G‐GUTI to the UE with a GUAMI (comprising an AMF Pointer) value that identifies only one AMF, the 5G‐TMSI identifies the UE uniquely within the corresponding AMF. However, when AMF assigns a 5G‐GUTI to the UE with a GUAMI (comprising an AMF Pointer) value used by more than one AMF, the AMF shall ensure that the 5G‐TMSI value used within the assigned 5G‐GUTI is not already in use by the other AMF(s) sharing that GUAMI value. The reason for allowing the GUAMI (comprising an AMF Pointer value) identify one or more AMFs is to allow one or AMF process a given UE transaction, enable stateless or state‐efficient AMF behavior, explained further in Section 4.9.4.
The emerging wide variety of services with distinct characteristics and requirements have led to the question how these requirements can be cost effectively met by the network. Different services together with personalization of tenants' networks create a long tail of requirements that become impractical to meet with a single network since the complexity of each network function within that network grows along with the requirements. Network slicing uses a divide‐and‐conquer approach where each network function instance handles only requirements relevant for some users, services, or tenants.
In its most basic form network slicing refers to an implementation model where particular sets of end users, services, or more generally tenants are assigned to dedicated sets of network function instances (Figure 4.26). Contrasted with the non‐sliced implementation where all of them would be sharing common instances, slicing provides a universal method for user, service, or tenant specific customization without directly requiring this customization capability from the network functions themselves. Slicing requires full automated orchestration capability as otherwise deploying various custom behaviors would be prohibitively costly.
While this arrangement is possible with physical network functions as well, for cost efficiency reasons virtual network functions are the default approach for slicing. This enables each tenant to have a virtual network, or a part of a network, on their own.
This basic form of slicing is however inadequate when considering the whole network. Virtualized network functions need to be provided with computing, networking, and storage resources, and functions at different sites must connect to the transport network. Some network functions, such as antennas or power amplifiers, can't be virtualized. For these physical entities a different approach is required. Physical resources can be connected to slices by having policies controlling the use of these resources, reflecting the characteristics of a slice. Thus, network slicing can be defined as the ability to create isolated behavior across the entire network in an automated way.
Slice specific physical instances are possible, thereby enabling the entire network including the antenna to be sliced, but such approaches are usually impractical from a cost and network deployment perspective, except perhaps for most specialized use cases.
Network slicing assumes each network function instance can be easily tailored for meeting specific requirements, creating a need for programmable network functions to allow for automated slice creation and maintenance.
With the growing number of network slices, automation of operations becomes of paramount importance. Operating multiple network function instances and configurations can easily increase operational costs, if an adequate level of automation is not available. Further, different functions and resources used by the slices must be configured and monitored coherently, as any misalignment breaks the behavior of the slice. This requires network level mechanisms, which can be referred to as a “network operating system.”
Network slicing and automation together create a programmable network, capable of adapting to the needs of any service or user by providing isolated network behaviors for each of them.
Slicing provides isolation in many ways and for various properties of the network. The most relevant ones are:
These isolation properties are the real benefits of slicing. These properties enable to have use case tailored networks, to move away from “one size fits all” approaches. For these properties to materialize, the 5G System must accommodate the slicing paradigm in the network architecture and definition of the network functions.
Network slicing requires certain specific capabilities from the network, particularly the slice selection function, but equally important is how the network architecture supports meaningful ways of isolating the functions and the configuration of services within those functions. The key targeted properties are:
In the 5G network architecture these properties are supported in multiple ways. User plane and control plane are separated, with user plane being confined into a single versatile function, the UPF. Since a UE can connect to multiple UPFs simultaneously, dedicated UPFs can be assigned to a service and thus to a slice. This way entire user plane traffic of, e.g. a certain data network can be fully confined within that slice only.
Access and mobility management (AMF) is separated from session management (SMF). This enables the SMF to be fully confined into a slice while all UE specific functions can be common to multiple slices. Naturally different UEs can be assigned to different AMFs and in this way two level slicing can be achieved: common functions creating the first level and service specific functions the second level.
Subscriber data in the UDM are separated into access, mobility related and session related parts, thereby enabling to slice the subscription data as well. This matches the functional split between AMF and SMF and enables to assign corresponding parts of the UDM functions into same slices as their AMF and SMF counterparts, if so desired.
PCF can be assigned as a common entity, slice specific entity or both, i.e. some policies being common to all slices while others being slice specific. This likely needs to follow the assignment of the network functions that are the consumers of those policies. For example, a PCF should be assigned to the same slice to which the SMF using the QoS and charging policies provided by the PCF is assigned to, while a PCF instance providing access and mobility related policies can reside in the common functions together with the AMF.
While all the above network functions can be assigned to a slice, none of them is aware of that. This is the key architectural property of slicing, it allows for multi‐tenancy without making the network functions multi‐tenant aware.
The only functions aware of slicing are the NEF, NRF and the NSSF. What these functions have in common are that their focus is controlling which network function and instance of it should serve a request rather than providing the needed service by themselves. Thus, they can be said to be the “control plane of the control plane.” NEF can be assigned as a common entity, slice specific entity, or both. Again, this structure should be defined according to the network functions whose capabilities are being exposed. Additionally, since the external domain is likely not aware of the slicing architecture of the network, a common NEF is needed to provide a single point of access toward the external domain and determining the correct slice where the slice specific NEF resides. This is where NEF needs to be aware of slices. The NRF is slice aware, and thus able to select the right network function instances for each slice. This is where the SBA can be effectively used by providing different services or different versions of services in different slices. The NRF acts as the single control point of this exposure. The NSSF can support the AMF in selecting the allowed network slice selection assistance information (NSSAI) and enables the network to control which slices are used for UE's PDU session(s).
Figure 4.27 shows an example of how network functions can be assigned to slices or applied as common functions.
In the example, there are three slices proving services. Slices #1 and #2 share a common AMF while slice #3 has a dedicated AMF. This means that on UE level the network is sliced into two, each UE assigned to only one of the AMFs. Those UEs assigned to the top AMF can access services from slices #1 and #2, while those assigned to the bottom AMF can access services from slice #3 only. Each slice contains SMF, UPF and PCF instances. SMF related policies are thus controlled by the PCF within the slice while AMF and UE related policies are controlled by the PCF that is common to all slices. Slice #1 has its own NRF; this can be relevant, for example, in cases where the slice belongs to a tenant that manages slice specific instances. In this example, UDM, UDR, NSSF and NEF are common to all slices, with NRF being common to slices #2 and #3.
In 3GPP Rel‐15, 5G RAN needs to support AMF selection based on slice identifiers provided by the UE. In addition, AMF and gNB exchange information which slices are supported per Registration Area via the N2 interface. Although Rel‐15 enables RAN to be slice aware, slice specific behavior of 5G RAN was not specified in Rel‐15 and is still open at the time of writing this book (planned for 3GPP Rel‐16). However, the following RAN specific slicing features can be envisioned (some of them are implementation and deployment specific):
5G is targeted to be a natively virtualized system, enabling use of cloud paradigm for maximizing flexibility and automation. This way slicing becomes a cost‐effective solution and proper tailoring of functions per each slice can be achieved.
Slices to be used for an UE and it's PDU sessions need to be decided and controlled by the operator and need to correspond to the user's subscription. The 5GC provides UE(s) with rules associating applications on the UE with corresponding Data Network Names (DNN) and slicing information.
The selection of the AMF serving an UE should consider the various slices the UE may need to use. Since the initial AMF selection is done by the 5G‐AN (e.g. gNB in NG‐RAN) which is not aware of the subscription data, 3GPP has decided to use a UE‐assisted slice selection paradigm where the network provides the UE with NSSAI. The UE relays this information to the 5G‐AN, enabling the 5G‐AN to select the correct AMF. The NSSAI is provided to the UE during initial registration.
A NSSAI is made up of one or more S‐NSSAI each of which comprises the following:
S‐NSSAI can contain standard values or PLMN specific values; in the latter case the UE will not use the S‐NSSAI in other PLMNs except the one to which the S‐NSSAI is associated. Standard SST values can contain service indicators such as eMBB, URLLC or MIoT. SD values are not standardized.
While S‐NSSAI indicates the characteristics expected, it does not necessarily uniquely identify a single slice as the network may also choose to use other additional information when selecting the slice. Furthermore, multiple S‐NSSAI values can lead to select a single slice. This is consistent with the assisting nature of the NSSAI.
When requiring PDU session related resources in the 5G‐AN, the 5GC provides the S‐NSSAI corresponding to the PDU session to the 5G‐AN. Thus, the 5G‐AN can select resources and policies consistent with the S‐NSSAI.
A slice selection message flow example when the UE is registering in the network is shown in Figure 4.28. Please note that the flow is simplified in terms of message names and contents details.
While actual network slicing is not supported in EPS, there is a similar concept for enabling a dedicated core network (DECOR) for a set of subscribers, as well as an enhancement of it (enhanced dedicated core network [eDECOR]). Service specific slicing, with UE simultaneously being able to access multiple slices, is not possible in LTE. RAN slicing is also not supported by LTE but some basic support for this may emerge, if suitable UE type or Core Network Identity (CNID) information is provided by the core to the RAN.
Given the different capabilities, 3GPP specified mechanisms to interwork with EPS networks that support or do not support (e)DECOR. A detailed overview of EPS interworking principles is provided in Section 4.11. These mechanisms can be used to provide inter‐system handover with IP address preservation between EPC and 5GC in the following configurations:
In Figure 4.29, the UE IP address is preserved when UE moves from EPC dedicated core/slice #1 to 5G slice #1 or vice versa.
In Figure 4.30, the UE IP address is preserved when UE moves from EPC dedicated core/slice #1 (specific P‐GW based on access point name [APN]) to 5G slice #1 or vice versa.
Multi‐Access Edge Computing (MEC) is an ETSI ISG (industry specification group), focusing on an architecture framework and environment for hosting performance‐critical applications at the network edge (refer to [8]). Use cases such as video analytics, location services, augmented reality, optimized local content hosting and caching can benefit from very low latency. A set of MEC APIs are defined to expose network capabilities and services such as radio network information.
Figure 4.31 shows a high‐level structure of the MEC framework, consisting of an umbrella MEC system‐level management, a local host (edge cloud) level and the network infrastructure domain including 3GPP and other networks. The MEC host level includes virtualization infrastructure, which is hosting MEC applications and a common MEC platform. The platform offers application‐enabling functions such as service registration and discovery, MEC APIs for information exposure and it interacts with the network layer including the 5G core.
The MEC local hosts (MEC platform and MEC enabled applications) are deployed in data centers at the network edge, i.e. close to the network access, possibly in the same data centers than the RAN functions.
MEC was created independently of 5G and many use cases can also be deployed in a 4G network environment. However, 5G is the first network generation specifically designed for MEC applications requiring mobility, lowest latency and service continuity at the same time. EPC networks can satisfy each of those needs individually but hardly their combination.
MEC enabled applications (like any other application) are accessed by a UE via “PDU Sessions” providing user plane connectivity. “PDU Sessions” are further defined in Chapter 6.
As MEC is hosting applications at the network edge, it requires the capability to deliver user plane traffic of PDU Sessions to “local” application instances. In the network example shown in Figure 4.32, 5GC CP (Control Plane) functions are deployed in a centralized core cloud, whereas 5GC UPF are available in both the edge clouds (also hosting RAN higher layer functions) and in the core cloud. One or more UPF instances, e.g. a local and a central UPF, can be selected for a PDU Session depending on network policies and interactions with the MEC system‐level management platform.
The MEC system‐level management deploys application instances. It provides information to the 5GC PDU Session management (SMF) where application instances are deployed. This is to be used when selecting suitable UPFs so that these UPF can forward traffic related with an application to the closest deployed instance of that application.
The information on where instances of an application are deployed is provided by MEC as:
In the example of Figure 4.32, based on requirements received from the MEC system‐level management and on UE location (5G‐AN location) the SMF
At this point the UE has an established connectivity to local services in the Edge Cloud (via UPF‐1) as well as to the public Internet through the central Telco Cloud (via UPF‐0).
Mobility may lead to a change in the (R)AN attachment, anchoring the UE in a different Edge Cloud (e.g. Edge Cloud #2 shown in Figure 4.33). The 5GC CP determines that another Edge Cloud 2 has become the new primary serving location for the UE, and hence selects UPF‐2 as the new local UPF.
Further steps depend on the specific needs and characteristics of the application:
In a 5G System, the network is expected to manage different kinds of information:
Traditionally (e.g. in EPS), the above four different types of data were stored and processed independently. Also, compute and storage layer was already split in the case of subscription data, optional UDC architecture for the HSS with the Ud interface toward UDR. In the 5G System, one objective of Data Storage architecture was to specify a unified framework, especially for the storage layer. Also, the objective was to enable deployment of stateless functions for all NFs/NF services within 5GC to improve resiliency, reliability and availability of the system.
In the 5G System Architecture, decoupling of Compute from Storage enables support for improved resiliency of a NF, almost “near zero downtime” in terms of service interruption for the UE. It also saves NF processing resources (e.g. for mIoT devices). It allows unified data storage for a network function (i.e. multiple instances of a NF can share the same storage resource), thus enables independent dimensioning of the NF and storage resource. Therefore, the storage resource also serves as a repository (like an “one stop shop”) to support network capability exposure and data analytics. Some benefits of having a common data storage layer are:
Ability to support higher reliability is achieved by introduction of the UDSF in the 5G System Architecture with the caveat that the data stored in the UDSF are “opaque.” This implies that the data stored in the UDSF can only be understood and interpreted by the NF (and the NF instances from the same vendor) storing it. The structure of the data stored in UDSF is not specified by 3GPP.
Opportunities to use the context data for data analytics, internal and external capability exposure is enabled by introduction of the UDR in the 5G System Architecture. Data stored in the UDR are standardized allowing NFs (NF instance from multiple vendors) to store and retrieve {subscription, policy, application, exposure related} data from UDR.
It is an implementation decision whether UDSF and UDR are independent functions or collocated.
In simple words, the term “stateless” is used to refer to a state of a compute function (in the context of the 5G System) that does not store UE context within its cache (i.e. for a certain duration when it remains stateless). How long this duration is, depends on the type of Network Function, ranging from a NF that requires no state to a NF that is completely stateless and a NF that is always stateful. Broadly, there are four possible implementation choices for a Network Function in the 5G System:
Depending on the type of NF and deployment needs, a wide range of implementation configurations are possible. Table 4.1 summarizes the four different implementation options described above.
Table 4.1 NF types in terms of states.
No‐state NF | Stateless NF | State‐efficient NF | Stateful NF | |
Select NFs at transaction start | Yes | Yes | Yes | No |
Interactions with UDSF | None | Highest, context stored at the end of every transaction | Medium, stable state stored at the end of a procedure, e.g. Registration, Service Request, PDU Session | None |
Supports failure | Yes | Yes | Yes, but the transient UE session may be lost | No, but needs specialized recovery procedures |
Scale‐in (NF removal from service) | Yes | Yes | Yes | No – sessions must be moved |
Scale‐out with load balancing (LB) | Yes | Yes – LB for all sessions | Yes – LB for new UE activity | No |
Candidate NFs | UDM FE | PCF | AMF, SMF |
Compute‐Storage split alone is not sufficient to enable a scalable NF (i.e. N + 1 scalability), especially for NFs like AMF, SMF. As illustrated above, it is also the behavior of the NF that it exhibits toward its peer NFs that matters, e.g. whether the peer NF can invoke any NF instance or invoke the same NF instance for processing a certain transaction, to determine whether the NF instance is stateless with N + 1 scalability.
Generally, for NFs like AMF, SMF, state‐efficient (#3 described above) NF implementation options might be reasonable. This implies that the NF instances are transaction‐stateful (i.e. efficiently access context/states stored within the cache in the middle of a certain procedure) but stateless outside the procedure (i.e. stateless after the completion of a certain procedure with the need to retrieve externally stored context/states only once in the beginning of the procedure). For support of stateless NF or state efficient NF, some standard enablers are required as this also impacts interoperable interfaces between producer and consumer NF, but it also allows scalability up to “n” NF instances. In 3GPP Release 15, this was specified mainly for the AMF. For NFs like UDM and AUSF, stateless NF or no‐state NF kind of implementation options might be reasonable.
In the first 3GPP release of the 5G System, significant effort was undertaken to specify standard enablers for state‐efficient AMF and AMF resiliency. The reason for starting with the AMF was that the AMF maintains associations to the UE, RAN and other NFs. Thus, some of the enablers, e.g. temporary identifier encoding for the UE and its semantics, presence of certain fields in AS/NAS messages to allow for a state‐efficient AMF, had to be introduced in the very first release of the new system to ensure that this is working with all 5GS UE(s) in the field from the very beginning of 5G introduction. Such identifiers, (fields within AS, NAS messages) that are critical to basic connectivity and functioning of the system cannot be changed in subsequent releases easily without adverse impact. Thus, it was important and critical to introduce the necessary standard enablers for support of state‐efficient AMF in the very first 3GPP release as part of clean slate 5G System architecture to ensure forward compatibility.
The 5G System standards specify enablers for implementations to support configuration #4 (see above) for state‐efficient AMF. The concept of an AMF Set was introduced to allow load sharing and scalability up to n AMF instances (where n = number of AMF instances within an AMF Set) for processing UE transactions. An AMF is referred to by the AMF Pointer. This allows load balancing of AMF instances sharing the same AMF pointer value. Also, an AMF pointer can point to one or more AMFs. An AMF set comprises of AMFs that can store and retrieve data from the same data base (UDSF). The AMFs within the same AMF Set are assumed to support the same network slice(s). An AMF Set is identified by the AMF Set ID. Figure 4.38 illustrates the AMF structure.
The AMF assigns a Temporary Identifier (5G‐GUTI) to the UE for supporting subscriber confidentiality. The AMF leverages the same identifier to include routing information that the 5G‐AN node can use to determine the target NF instance(s) for NAS messages. The UE derives the 5G‐S‐TMSI including the routing information (AMF Set ID and AMF Pointer value) from the 5G‐GUTI assigned by the AMF, and provides it in the RRC message toward the 5G‐AN. The 5G‐AN uses the routing information present in the 5G‐S‐TMSI and routes the NAS message accordingly.
An AMF can advertise a distinct and/or common address toward the 5G‐AN: The standard specified the ability for an AMF to provide a distinct AMF Pointer value (that identifies a specific AMF) and a common AMF Pointer value (that is shared by multiple AMFs within an AMF Set) toward the 5G‐AN over the N2 interface using next generation application protocol (NGAP).
AMF Set ID and AMF Pointer value can be included within the 5G‐S‐TMSI provided by the UE. The AMF assigns the 5G‐GUTI including the GUAMI which itself includes AMF Set ID and AMF Pointer value. If the AMF wishes to remain stateless, it can allocate a 5G‐GUTI with a common AMF Pointer value.
When the UE sends an RRC establishment request, it includes the 5G‐S‐TMSI including AMF Set ID and AMF Pointer value. The 5G‐AN can use the AMF Set ID and AMF Pointer value in the 5G‐S‐TMSI to determine how to route the encapsulated NAS message toward the AMF. If the AMF Pointer value provides a distinct address for a specific AMF, then the 5G‐AN will forward it to this specific AMF. If the AMF Pointer value maps to multiple AMFs, then the 5G‐AN can forward it to any of these AMFs. It can use the AMF Set ID to select any AMF within the AMF Set, if the specific AMF has failed or reported out‐of‐service. This allows for scalability up to an AMF Set.
Figure 4.39 illustrates the principles above.
Ability to release signaling (per UE TNL – Transport Network Layer) association was introduced to avoid long lived associations between 5G‐AN and a specific AMF instance for a given UE in connected (RRC_CONNECTED/CM‐CONNECTED) state. An AMF can release “per UE” TNL association between AMF and 5G‐AN without releasing UP connectivity and/or RRC connectivity for the given UE. This allows the AMF to become stateless or state efficient enabling the AN to select any AMF from the AMF Set (even for UE(s) that are in RRC_CONNECTED state) for subsequent N2 messages targeted for a given UE.
Ability for other CP NFs (e.g. SMF, PCF, UDM) to select a new AMF instance when the AMF releases the signaling association (or it has failed or reported out‐of‐service) was also introduced. Control plane NFs can also select another AMF instance for processing the UE transaction.
If there is a race condition between mobile originating (MO) and mobile terminating (MT) transactions, e.g. an AMF instance is already processing a UE's MT transaction while another AMF has been selected for a MO transaction, then the wrong (newly selected) AMF is expected to forward the transaction to the right (currently serving) AMF for processing the UE transaction and respond accordingly to the requester.
In the past generations (i.e. EPS, general packet radio service [GPRS]), these enablers were not present thus it was not possible to support “zero downtime” for MME without impacting the UE's service and/or incurring excessive signaling. To avoid service disruption, fully redundant NFs (1 : 1 mated‐pair) had to be deployed. With the 5GS enablers for stateless/state‐efficient AMF, operators can avoid deploying fully redundant NFs at the same time avoid service disruption and support scalability up to n AMF instance, where n is the number of AMFs within an AMF Set. More importantly, this introduces the ability to support “dynamic run time load balancing” between AMFs with no service disruption and it also avoids heavy signaling traffic toward the UE. This avoids also concurrent signaling toward millions of UE(s) for AMF load re‐balancing.
Detailed descriptions of the technical solutions and procedures for support of state‐efficient AMF, AMF resiliency, N2 management, AMF planned removal and AMF load re‐balancing can be found in 3GPP TS 23.501 [1] and TS 23.502 [2].
With network capability exposure via APIs provided by the NEF, operators can give applications (either operator's own or third‐party applications) access to network capabilities affecting the services provided to the users. This is intended to provide additional value to the application by optimizing the application and/or network behavior and to help operators to better monetize their network. Such interactions may be limited by a SLA between operator and third‐party service provider.
Network capability exposure allows support for following features:
The NEF is burdened with significant overhead resulting from per UE events:
To reduce this overhead, the 5G System supports capability exposure using bulk subscriptions to reduce signaling and to reduce the overhead incurred due to “per UE” subscription events (i.e. there is no need to keep track of serving NF for a given UE using bulk subscription). This allows the NEF to subscribe with registered NF instances for a set of events targeting a group of UEs or any UE. The two main principles are:
Figure 4.40 illustrates the exposure procedure with bulk subscription:
Network capability and event exposure are key enablers to support network programmability as defined in Section 4.2.6.
In case an external application is seeking to use Network capability exposure and Event exposure services, the NEF acts as the network interface to the external application and is responsible for:
In summary, the NEF has the role of an API gateway toward the 5G network, controlling access to network capabilities, and hiding internal network details such as serving network functions and internal identifiers from external applications.
As stated in the architecture section, the 5G System natively integrates various access technologies, thus the focus of interworking and migration was mainly to ensure seamless mobility and service continuity between existing deployed EPS networks and the new 5G System. Note seamless interworking with IP address preservation between 5G System and 2G/3G is not supported.
As with any new technology, initial deployments are expected in small regions within a country (urban scenarios) and coverage will be sparse. Besides that, following are the additional challenges faced with the development of an interworking and migration solution for the 5G System:
To ensure that various forms of mobility and coverage scenarios are considered, two levels of interworking are supported:
Deployments based on different 3GPP architecture options, EPC based or 5GC based, and UEs with different capabilities (supporting EPC NAS and 5GC NAS) may coexist at the same time within one PLMN.
The ability to deploy two radio technologies in the same spectrum simplifies migration from EPS toward 5GS. How this is done is explained in Chapter 2.
Figure 4.41 illustrates the migration support from EPS to 5GS.
To support smooth migration, following are some assumptions that have been made regarding UE and network support:
Supporting different UEs with different capabilities in the same network, UEs that are capable of only EPC NAS (possibly with EPC based Dual Connectivity with secondary NR) and UEs that support both EPC NAS and 5GC NAS procedures in the same network, is illustrated in Figure 4.42. The figure shows the principles that apply for ng‐eNB and UE to enable appropriate system selection and routing.
The following steps are performed:
To support seamless service continuity between 5GS and EPS, an interworking architecture requires
Figure 4.43 shows the interworking architecture:
The interworking solution was specified to cater for different deployment needs:
Furthermore, the solution supports two different kinds of UEs:
While Dual Registration mode is optional for the UE, Single Registration mode is mandatory for the UE in 3GPP Rel‐15. Networks that support interworking with EPC, may support interworking procedures with or without N26 interface. Interworking procedures using N26 are providing IP address continuity on inter‐system mobility for UEs that support 5GC NAS and EPC NAS. Networks that support interworking procedures without using the N26 interface, also support procedures to provide IP address continuity on inter‐system mobility for UEs operating in single‐registration and dual‐registration mode.
Figure 4.46 summarizes the (mandatory, optional) capabilities supported by a UE and the default mode of operation that can be expected from the network for EPS interworking.
The following list provides an overview of some high‐level principles adopted for interworking with EPS:
PDU Session types “Ethernet” and “Unstructured” are transferred to EPC as “non‐IP” PDN type (when supported by UE and network). The UE sets the PDN type to non‐IP when it moves from 5GS to EPS and after the transfer to EPS, the UE and the SMF shall maintain information about the PDU Session type used in 5GS, i.e. information indicating that the PDN Connection with “non‐IP” PDN type corresponds to PDU Session type Ethernet or Unstructured respectively. This ensures that the appropriate PDU Session type will be used when the UE moves and transfers PDU Sessions to 5GS.
Since there are many related concepts discussed such as dual connectivity, dual registration, dual radio etc., Table 4.2 provides a comparison and summary of these concepts to put things in the right perspective.
Table 4.2 Used terminology.
Concept | Dual connectivity | Dual registration | Dual radio |
Core registration | Single IMSI, single registration |
Single IMSI, dual registration; UE can register in both networks independently and the network is required to maintain the two registrations without canceling them as part of HO |
Dual registration (single or dual credential) |
RAN‐Core interface | Single | One at a time | One per credential |
RRC interface | RRC mainly anchored using the Master RAT (including containers over Master RRC); Light RRC for Secondary RAT | Single RRC | Dual RRC |
Services | Allows services to be supported in different RATs | Allows services to be supported in different systems | Allows services to be supported in different RATs |
Paging | Listens to paging in the Master RAT only | Depends on UE's radio capability; 3GPP solution does not require the UE to listen to paging in both RATs | Listens to paging in both RATs |
NAS states | One NAS state only | One NAS state per registration! UE maintains the NAS states independently | One NAS state per registration! UE maintains the NAS states independently |
Interworking procedures using the N26 interface enable the exchange of MM and SM states and the security context between source and target network. The UE operates in single‐registration mode.
The support for N26 interface between AMF in 5GC and MME in EPC is required to enable seamless session continuity (e.g. for voice services) for inter‐system change. It allows for fast handover and minimized service interruption. When the UE moves from 5GS to EPS, the SMF determines which PDU sessions can be relocated to EPS, e.g. based on capability of the deployed EPS, operator policies for which PDU sessions, seamless session continuity should be supported etc. The SMF can release the PDU sessions that cannot be transferred as part of the handover process to EPS. However, whether the PDU Session is successfully moved to the target network is determined by the target EPS.
When the UE supports single‐registration mode and the network supports interworking with the N26 interface, the following principles apply:
For interworking without the N26 interface, IP address continuity is provided for the UE on inter‐system mobility by storing and fetching the combined PGW‐C + SMF address and corresponding APN/DDN information via the combined HSS + UDM. Such networks also provide an indication that “interworking without N26” is supported to UEs during initial Registration in 5GC. This indication is valid for the entire PLMN. UEs that support dual‐registration mode may use this indication to decide whether to register “early” in the target system, i.e. before the mobility occurs.
When the UE supports single‐registration mode and the network supports interworking procedure without N26 interface, the following principles apply:
It should be noted that the network does not automatically cancel the UE registration when the UE moves from one system to another.
The 5G System is built to support multiple kinds of accesses in a generic way. This means the 5GC provides a single control plane and user plane interface toward the UE and/or the access network to allow for UE reachability over
Regardless of the access the UE is using, the same 5GC NF instances are used to serve the UE in most of the cases. This allows the UE security context that was established on one access (e.g. 3GPP access) to be re‐used on different access systems (e.g. non‐3GPP access). The same master key can be used to derive access related ciphering and integrity keys, without the need to re‐authenticate the UE.
The same protocol (“NAS”) and procedures are used between the UE and the 5GC. This corresponds to the N1 interface of the reference architecture (Section 4.3.1). This is an improvement compared to EPC where three different protocols, NAS, Internet Key Exchange (IKE) extensions, Wireless Local Area Network Control Plane Protocol WLCP, and three different Network Functions (MME/SGW, ePDG, TWAN) for three different types of accesses (3GPP, untrusted Non‐3GPP and trusted Non‐3GPP access) were necessary.
The same protocol and procedures are used between the different kinds of access networks and the 5GC. This corresponds to the N2 (Control Plane) and N3 (User Plane) interface of the reference architecture (Section 4.3.1). The same UPFs can serve a PDU session regardless of the (3GPP or Non‐3GPP) access used to carry the UP flows of this PDU session. This allows for an efficient PDU session mobility between 3GPP and Non‐3GPP access as only two NFs (a SMF and a UPF) may need to be involved due to mobility. Which access type (3GPP or Non‐3GPP) a PDU session may use is controlled by policies on the UE.
The 3GPP Rel‐15 specifications do not support multi‐access PDU sessions, i.e. PDU sessions concurrently served by both 3GPP and Non‐3GPP access.
However, there are still some access specific aspects in 5GC, such as the following:
Apart from the differences listed above (that correspond to optional information and procedures for some accesses), the same 5GC protocol and state machines apply for the different accesses. The specific protocol and procedural adaptations related to each access technology are confined in the access network itself, i.e. the RAN for 3GPP access and an interworking function called N3IWF for non 3GPP accesses (see Figure 4.47).
3GPP has defined “untrusted non‐3GPP access” as the only type of non‐3GPP access connected to 5GC in Release 15. The support of other kinds of accesses like wireline access is deferred to 3GPP Release 16.
Establishment of the signaling connectivity between a UE and the 5GC over un‐trusted Non‐3GPP access is depicted in Figure 4.48 and follows these steps:
The IKE protocol between UE and N3IWF plays an equivalent role to the RRC protocol between UE and NG‐RAN: both IKE and RRC provide a secured link for the UE to exchange following information with the network:
To support seamless service continuity between 5GS and EPS in case of Non‐3GPP access, the interworking architecture requires support for the following requirements (which are common requirements like for 3GPP access as exposed in Section 4.11.1):
Once a UE loses Non‐3GPP access connectivity to the N3IWF, the UE may try to move PDU Sessions to 3GPP access, if this is allowed by local policies:
For a UE desiring to access the 3GPP Core network over non 3GPP access, operator policies guide the UE choice of whether to use a ePDG in EPC or a N3IWF in 5GC.
3GPP Rel‐15 specifications do not support multi‐access PDU sessions, i.e. PDU sessions concurrently served by both 3GPP and Non‐3GPP access. This feature is nevertheless being studied for further 3GPP releases as discussed in Section 4.21.
Multi‐access PDU sessions imply the support of traffic splitting between accesses enforced in the UE for UL traffic and in an UPF of the 5GC for DL traffic.
Depending on specific use cases and application requirements, traffic flows can be placed on one or both access networks under policy control. Changes in access network performance can lead to dynamic re‐allocation of traffic flows, especially when mobile or WLAN access networks are involved. Another challenge is making the steering function in the 5GC aware that downstream network conditions have changed at the UE side.
MPTCP (IETF RFC 6824 [21]) is one of the solutions which addresses the traffic steering problem in an elegant way, as it adapts itself in real‐time to changes in network performance. It also has the capability to support TCP “elephant flows” that exceed the capacity of a single access network connection, by splitting those into multiple sub‐flows. While this helps to improve the end user perception of high peak data rates, it comes at the price of increased latency due to buffering and synchronization of flows in the receiver.
Fixed‐Mobile Convergence (FMC) has been on the agenda of network operators for several decades. In the context of FMC, we use the terms fixed as well as wireline networks interchangeably. In the past, the biggest obstacle to convergence has been the internal structure of large incumbent operators where different organizations are typically responsible for fixed and mobile networks. Hence, the opportunities for convergence were limited to infrastructure sharing, e.g. transport, aggregation and IP core networks, also more recently virtualized cloud infrastructure, and service convergence (mainly converged voice and broadband data services).
As capabilities and data rates, reliability of the connectivity, and services offered by fixed and mobile networks are becoming similar (especially with 5G), most of applications can work over any access network. Commercial service offers, and end user devices are also increasingly bundling fixed and mobile connectivity, which has led to a growing interest in converged network architectures. A converged 5G Core creates a unique control point to leverage intelligent traffic steering and multi‐access integration and to ensure a seamless end user experience through selecting the best available access technology.
The virtualization of (wireline) access networks is another potential enabler to consider FMC now as both FMC and virtualization imply the need to re‐think network architectures and deployments.
Hybrid access is one of the main convergence use cases, where a residential gateway has both a wireline and a cellular (5G) radio connection to the same core network (see Figure 4.49). To optimize both user experience and access network usage, the residential gateway and the 5G Core require intelligent traffic combining, splitting and steering functions. Hybrid access enables both higher peak data rates as well as better resiliency by simultaneous use of both access networks.
Figure 4.49 shows the full range of convergence use cases that are of interest to operators driving FMC in the Broadband Forum (BBF). The BBF is responsible for DSL (Digital Subscriber Line) as well as PON (Passive Optical Network) access networks which are typically owned by incumbent network operators; many of those also operate cellular access networks. Competition on peak data rates is driving converged operators to bundle both access technologies. A variation of this is fixed wireless access where a wireless access network is used to provide fixed broadband services including Internet access and IPTV (Internet Protocol Television).
A second class of use cases are related to the use of multi‐access devices like smartphones which can connect simultaneously to two different access networks, e.g. 5G cellular and WLAN operating over wireline access network. Traffic combining, splitting and steering functions required for this scenario are like that for hybrid access, but operator policies and user preferences may be slightly different as the use case aims at improving coverage and reducing the impact of handovers between access networks.
Wireline access integration will be based on interworking functions that adapt between the wireline access network and the converged 5G Core, which has the advantage of minimizing impacts to wireline access nodes as well as 5G Core functions. As illustrated in Figure 4.50, a 5G Residential Gateway (5G RG) can support N1 (NAS) signaling toward the AMF for registration and SM. A new encapsulation for NAS signaling needs to be defined for wireline access, transporting NAS frames between the 5G RG and a new interworking function that connects to the core network via N2 and N3 interfaces.
Existing interfaces such as N1, N2 and N3 will be reused with minimal changes, ideally there would be no impacts to the protocols defined for 5GS in 3GPP Rel‐15. Broadband subscriber management is taken over by the 5G SMF/UPF combination, which will need to support various flavors of residential gateways and offer the same data connectivity services than a Wireline BNG (Broadband Network Gateway). The full details of wireline access integration will be defined in 3GPP Rel‐16, hence the corresponding interfaces have been denoted as N1′, N2′ and N3′ to indicate the possibility of small deviations from Rel‐15 specifications.
At the time of writing this book, BBF and 3GPP are collaborating to standardize wireline access integration into the 5G Core. Studies conducted by BBF are focusing on requirements and gap analysis (see BBF SD‐407 [9]), allowing 3GPP to study solutions, which will most likely be based on a trusted Non‐3GPP interworking model. Normative specifications for FMC are targeted for completion in 3GPP release 16 (mid 2019).
The Network Function Service Framework is mainly about using design principles that enable “simple, modular and flexible” design. Following are some of the key principles:
Furthermore, to ensure that the NF services defined in 3GPP are bound by certain criteria, following principles applied in Rel‐15:
An NF service is a capability of a certain Network Function (e.g. AMF or SMF) exposed by the NF (NF service producer) to authorized NFs (NF service consumers) through a service‐based interface. An NF can expose one or more NF services. Similarly, an NF can consume one or more NF services.
Network Functions may offer different capabilities and thus, different NF services to distinct consumers. An NF can be composed of NF services as shown in Figure 4.51.
Each NF service shall be accessible by means of an interface. An interface may consist of one or several operations (Figure 4.52).
5G System procedures can be built by invocation of multiple NF services as shown in Figure 4.53. Figure 4.53 shows an illustrative example on how a procedure can be built; it is not expected that system procedures depict the details of the NF services within each Network Function.
The following are the design criteria for specifying NF services of a certain NF within the 5G System:
Figures 4.54 and 4.55 illustrate the above criteria.
The use of NF services in operator deployed network is not restricted to the identified consumers. But it has also been agreed in 3GPP that no specific effort will be made to develop the description of NF services beyond what is necessary to support their use as part of the5G System procedures.
The Network Function that is offering a service is called NF Service Producer. The Network Function that is consuming a service is called NF Service Consumer.
The interaction between consumer and producer within the NF service framework follows two mechanisms:
A control plane NF_A may also subscribe to an NF Service offered by control plane NF_B on behalf of another control plane NF_C, i.e. it requests the NF Service producer to send the event notification to other consumers (Figure 4.58). In this case, NF_A includes the notification endpoint of the NF_C in the subscription request.
The NF service authorization framework ensures that the NF Service consumer is authorized to access the NF service provided by the NF Service provider, according to the policies of the NF, the policies of the serving operator and inter‐operator agreements. Service authorization information is configured as part of the NF profile of the NF Service producer. It includes the NF type and NF realms/origins allowed to consume NF Service(s) of the producer. The service authorization entails two steps:
The NRF maintains the information of available NF instances and their supported services. Each NF instance registers at the NRF the list of NF services it supports.
The NF instance may register this information with the NRF when the NF instance becomes operative for the first time (registration operation) or upon individual NF service instance activation/de‐activation within the NF instance (update operation), e.g. triggered after a scaling operation. During the registration operation, the NF instance provides an NF profile that is maintained in the NRF. The NF profile includes:
The NF instance can register with the NRF directly using an NRF service or via operations, administration & maintenance (OA&M).
The NF instance should also de‐register from the NRF when it is about to (gracefully) shut down or disconnect from the network in a controlled way. If an NF instance become unavailable or unreachable due to unplanned errors (e.g. NF crashes), an authorized entity should deregister the NF instance from the NRF.
The NF discovery and NF service discovery framework (Figure 4.59) enables one NF to discover a set of NF instances with a specific NF service or target NF type.
Unless the expected NF and NF service information is locally configured on the requester NF, e.g. the expected NF service or NF is in the same PLMN as the requester NF, the NF and NF service discovery is implemented in the NRF. The NRF is the logical function that is used to support the functionality of NF and NF service discovery.
To enable access to a requested NF type or NF service, the requester NF initiates the NF or NF service discovery by providing information such as the following:
In the discovery response, the NRF provides information such as IP address, FQDN, or the identifier of relevant services and/or NF instances to the requester.
Based on that information, the requester NF can select one specific NF instance or a NF instance that is able to provide a NF Service, e.g. an instance of the PCF providing Policy Authorization.
For NF discovery across PLMNs, the requester NF provides to the NRF the PLMN ID of the target NF. The NRF in the local/visited PLMN interacts with the appropriate NRF in the target/home PLMN. The NRF in the local PLMN reaches the NRF in the target PLMN by forming a target PLMN specific query using the PLMN ID provided by the requester NF. The NRF in the local PLMN interacts with the NRF in the target PLMN to retrieve the IP address, FQDN or the identifier of relevant services of the target NF instances.
To enable network topology hiding, it is also possible that the IP address or the FQDN of proxy function(s) (SEPP) instead of the target NF instances are provided to the requester NF. The proxy functions are transparent to the requester NF.
This section summarizes the NF services defined in 3GPP for the control plane Network Functions within the 5G Core. As discussed in the previous sections, the NF services can be consumed by any authorized consumers, thus the consumers are not fixed rather the consumers are meant only as examples. The examples are listed mainly to allow deployments getting an idea on the reason for specifying each NF service and service operation. Having an idea of the NF consumer also helps with trouble shooting with a given NF service in the field, furthermore it helps to determine the capabilities that should be offered by the given NF service.
NF services for 5GC NFs should be defined at a reasonable granularity (avoiding explosion of services) along with detailed NF service operations for each NF service. Here we summarize the NF services agreed for different 5GC NFs, taking AMF, SMF, NRF and UDM as examples. For details about 5GC NF services and NF service operations, please refer to 3GPP TS 23.502 [2].
The following NF services are specified for the AMF (Table 4.3).
Table 4.3 NF services provided by AMF.
Service name | Description | Example consumers |
Namf_Communication |
This service enables an NF to communicate with the UE and/or the AN through the AMF. This service enables SMF to request EBI allocation to support interworking with EPS. |
Peer AMF, SMF, PCF, NEF, SMSF, UDM, NEF, LMF |
Namf_EventExposure | This service enables other NFs to subscribe or get notified of the mobility related events and statistics. | NEF, SMF, PCF, UDM |
Namf_MT | This service enables an NF to make sure UE is reachable. | GMLC |
The following NF services are specified for the SMF (Table 4.4).
Table 4.4 NF services provided by SMF.
Service name | Description | Example consumers |
Nsmf_PDU Session | This service manages the PDU sessions and uses the policy and charging rules received from the PCF. The service operations exposed by this NF service allows the consumer NFs to handle the PDU sessions. | Peer V/H‐SMF, AMF |
Nsmf_Event Exposure | This service exposes the events happening on the PDU sessions to the consumer NFs. | PCF, NEF, AMF |
The following NF services are specified for the UDM (Table 4.5).
Table 4.5 NF services provided by UDM.
Service name | Description | Example consumers |
Nudm_UE Context Management |
|
AMF, SMF, SMSF, NEF, SMSF, GMLC |
Nudm_Subscriber Data Management |
|
AMF, SMF, SMSF |
Nudm_UE Authentication |
|
AUSF |
Nudm_Event Exposure |
|
NEF |
The following NF services are specified for the NRF (Table 4.6).
Table 4.6 NF services provided by NRF.
Service name | Description | Example consumer(s) |
Nnrf_NF Management | Provides support for register, deregister and update service to NF and NF services. Provide consumers with notifications of newly registered NF along with its NF services. | AMF, SMF, UDM, AUSF, NEF, PCF, SMSF, NSSF |
Nnrf_NF Discovery | Enables one NF service consumer to discover a set of NF instances with specific NF service or a target NF type. Also enables one NF service to discover a specific NF service. | AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF |
The 5G System is a pure packet‐based system without an in‐built CS voice component like global system for mobile communications (GSM) and universal mobile telecommunications system (UMTS). Thus, the preferred way to provide voice and other multimedia services is via the IMS. It can be assumed that the same or a similar voice profile defined by global system for mobile communications association (GSMA) for VoLTE becomes also applicable for VoNR. For example, GSMA IR.92 has specified a well‐known APN, the so called “IMS APN,” to enable IMS roaming.
The 5G Core Network indicates to the UE that Voice over Internet Protocol (VoIP) in 5GS is supported; more precisely that the tracking area(s) the UE is currently camping on provide sufficient QoS and coverage for VoIP support. Therefore, a UE that has been provisioned as IMS VoIP capable can start an IMS voice session at its current location based on the received network indication.
When IMS services are supported for UEs registered in the 5G Core, the services can be provided to the UEs either via 3GPP access or Non‐3GPP access.
However, during the initial stages of 5G System roll out, actual NR coverage is expected to be spotty. If a UE starts an IMS voice session in 5GS, it may need to continue the voice call when it moves out of NR coverage. To allow continuation of voice calls in LTE support for interworking with E‐UTRA/EPS was introduced. It extends the voice service coverage area and provides a good voice experience in the early days of NR.
Some 5G System based deployed networks may not support IMS based voice service natively either because NR roll‐out is in the high frequency band (i.e. rapid signaling loss can occur) or because early NR deployments are not supporting the required QoS. For such scenarios, support for voice fallback toward E‐UTRA in combination with 5GC (RAT Fallback) and E‐UTRAN in combination with EPC (EPS Fallback or System Fallback) was introduced. Even when fallback for voice is supported, the UE can remain registered in the 5G System for IMS signaling over NR and 5GC as fallback toward E‐UTRA/5GC happens only when a MT or MO voice call is initiated.
When a MO or MT voice call is initiated and the IMS requests the 5GS to establish the desired QoS flow for voice, NG‐RAN detects the need for voice call setup, e.g. based on the respective 5QI = 1 (5G QoS indicator 1). Based on this trigger, NG‐RAN can initiate the fallback toward EPS (Figure 4.60) and reject the QoS flow setup with “fallback toward EPS.” This can either result in a network assisted handover from 5GS toward EPS using the interworking principles mentioned in Section 4.9.2 or using RRC release with redirection causing the UE to re‐select E‐UTRA/EPC (network assisted redirection), and the voice call to be successfully setup upon mobility toward EPS. Support for EPS Fallback does not assume the existence of signaling reference point N26 between MME and AMF.
However, if there is no N26 reference point, there is a risk that IMS signaling messages are lost due to the delay incurred during the fallback, which will require support for retransmissions at the protocol layer (e.g. TCP in case of session initiation protocol [SIP] signaling) to avoid several seconds of voice call interruption. With the N26 reference point in place the delay is reduced as no re‐authentication is needed at the target side.
When a MO or MT voice call is initiated and the IMS requests the 5GS to establish the desired QoS flow for voice, NG‐RAN detects the need for voice call setup, e.g. based on 5QI 1. Based on this trigger, NG‐RAN can initiate the fallback toward E‐UTRA/5GC (Figure 4.61) and reject the QoS flow setup with “fallback toward EPS.” This can either result in network assisted handover from NR/5GC toward E‐UTRA/5GC using N2 handover as explained in Chapter 5 or using RRC release with redirection causing the UE to re‐select E‐UTRA/5GC (network assisted redirection) and the voice call to be successfully setup upon mobility toward E‐UTRA/5GC.
Emergency services are available in the 5G System in 3GPP Rel‐15 based on IMS (IMS Emergency Calls).
Emergency calls will be routed to a call center called PSAP (Public Safety Answering Point). An emergency call is routed to a PSAP that is best suited for this call, e.g. regarding caller location load situation. Since IMS is mostly access agnostic (with very few access specific adaptations) and supports emergency services since Release 9, it doesn't require any enhancements to support emergency calls over 5G‐NR. However, the newly introduced 5G System needs to support some specific functionalities to provide support for emergency services.
The UE shall not initiate Emergency Services over untrusted Non‐3GPP access to 5GC, if the emergency session can be established via 3GPP access. To use 5GC for emergency services in case of untrusted Non‐3GPP access, the UE may select any N3IWF. For further details on native support for Emergency Services, please refer to 3GPP TS 23.501 [1] Section 5.16.4.
In addition to native support for emergency services, support for Emergency Services using fallback to another technology has also been introduced to cater to varying deployment needs. As mentioned above for voice services, some 5G deployments may not support IMS‐based Emergency Services natively either because NR roll‐out is in the high frequency band (i.e. radio propagation conditions are such that rapid loss of signal may occur) or because initial stages of NR deployments are unable to support required QoS and/or Location services. For such scenarios, support for Emergency Services fallback via RAT Fallback or EPS Fallback was defined.
The network can initiate fallback toward EPS and/or E‐UTRA just as it does fallback for regular voice calls as outlined in Section 4.12. In addition, Emergency Services fallback triggered based on the UE initiated Service Request procedure was introduced.
The UE and 5GC may support the mechanism to direct or redirect the UE either toward E‐UTRA connected to 5GC (RAT fallback) when only NR does not support Emergency Services but 5GC supports it or toward EPS (E‐UTRAN connected to EPC System fallback) when the 5GC does not support Emergency Services.
If the AMF indicates support for Emergency Services using fallback (for a given RAT) in the Registration Accept message, a normally registered UE supporting Emergency Services fallback shall initiate a Service Request with Service Type set to “Emergency.” The AMF uses the Service Type Indication within the Service Request to initiate redirection of the UE toward the appropriate RAT/System. The 5GS can trigger redirection to EPS or redirection to E‐UTRA connected to 5GC. After receiving the Service Request for Emergency Fallback, the AMF triggers an appropriate N2 procedure (e.g. paging) resulting in CONNECTED state mobility (handover procedure) or IDLE state mobility (redirection) to either E‐UTRA/5GC or to E‐UTRAN/EPC depending on factors such as N26 availability, network configuration and radio conditions. The AMF indicates to the RAN whether it should trigger RAT fallback or System fallback by including the Core Network type. RAN determines whether to trigger N2 (intra‐NG‐RAN) handover/redirection toward E‐UTRA/5GC or N26 inter‐system handover/redirection toward E‐UTRAN/EPC. If the RAN decides to perform redirection, it indicates the Core Network type to the UE as part of the RRC Redirection message for the UE to determine whether it should initiate an EPC NAS or 5GC NAS procedure upon redirection to E‐UTRA.
Support for Location Services is optional for 5G System deployments. Also, the support for Location Services is restricted to provide regulatory services in 3GPP Release 15, e.g. determine location of the user in case of emergency calls. Figure 4.62 shows support for location services for non‐roaming scenarios using the service‐based interface representation. Only entities directly relevant to location services are shown.
The functional split between AMF and LMF is almost the same as the functional split between MME and serving mobile location center (SMLC). The main addition for the 5G System Location Services architecture is that the LMF is integrated into the SBA. Support for Location Services was included within 3GPP Release 15, but only RAT independent mechanisms are used in NR. This implies that Location Services support from E‐UTRA and other mechanisms that do not require support for it directly in the gNB are used. At the time of writing this book, it is expected that the following principles will be employed for Location Services in NG‐RAN Rel‐15:
The LMF supports the following functionality:
With the advent of many popular over the top messaging services using smart phone apps, SMS traffic is decreasing but continues to still exist for many reasons. One classical use for SMS is support for “human to human” text messaging service and this is what is being replaced by over the top applications. In addition, SMS was used for device triggering purposes, especially in case of IoT devices. Recently, SMS has also been used for “two‐factor” authentication by many companies, e.g. when using corporate Office applications outside the Intranet. In fact, SMS traffic has increased recently mainly due to use of “two‐factor” authentication and IoT device management. Thus, classic SMS service must be supported in the 5G System.
SMS can be provided in LTE natively over IP (called “SMS over IP”) via IMS (see 3GPP TS 23.204 [23]). There is no special requirement being placed on the 5G System for this feature; 5G is just used to provide IP connectivity. The precondition is that the UE must have successfully performed an IMS registration, is supporting the “SMS over IP” feature and has been configured to use the feature. If this is the case, a SMS is encoded by the network or UE into a special SIP message and sent to the peer. This requires support for IMS (SIP) client in the UE.
For the scenario where there is no deployment of IMS in the network or no IMS (SIP) client support in the UE, a solution was specified to allow native support for SMS in the 5G System. Since the architecture leverages NAS messages to transmit and receive SMS, this architecture is called “SMS over NAS architecture.”
Figure 4.63 shows the non‐roaming architecture to support SMS over NAS using Service‐based interfaces within the 5G Core control plane.
The System Architecture for SMS over NAS follows mostly the SMS over SGs solution approach specified for LTE/EPC with some subtle differences:
Thus, the SMSF existence is completely transparent to the UE. Similarly, the transmission of SMS (and SMS payload) within a NAS message is completely transparent to the AMF. SMS relocation is not supported in Rel‐15. Each UE is associated with only one SMSF at any time. Support for SMS incurs the following functionality:
The SMSF connects the legacy SMS architecture to the 5G Core, mainly to the AMF. The SMSF is responsible for SMS authorization, SMS relay and protocols, SMS charging and LI.
In the SMSF, SMS authorization checks the UE requests regarding SMS related subscription data retrieved from the UDM. SMS relay and protocols consist in relaying SMS, via AMF, from UE to SMS‐GMSC/IW‐MSC/SMS‐Router or vice versa, and supporting SM‐RP and SM‐CP protocols toward the UE. The UE availability notifications are also included. SMS charging creates SMS related Charging Data Records (CDR). LI support includes delivery of SMS events to the LI system.
During the registration procedure, a UE that wants to use SMS provides an “SMS supported” indication over NAS signaling indicating the UE's capability. “SMS supported” indicates whether UE can support SMS delivery over NAS via 3GPP access or via both 3GPP and Non‐3GPP access. If the core network supports SMS, the AMF includes “SMS supported” indication to the UE, and whether SMS delivery over NAS via 3GPP access or via both the 3GPP and Non‐3GPP access is accepted by the network. SMS is transported over NAS without the need to establish DRBs, using NAS transport message carrying the SMS as payload.
PWS is a service offered to local, regional, or national authorities to reach out to a public mass warning them of an impending emergency. Such warning messages may be necessary for reasons such as:
Some cities use emergency warnings to advise people of prison escapes, abducted children, emergency telephone number outages and other events.
The 5G System supports warning message delivery as specified in 3GPP TS 23.041 [24] but permits a number of unacknowledged warning messages to be broadcasted to UEs within a service area. The term “unacknowledged” implies that there exists no retry mechanism for warning messages.
There are different regional variants requiring support for PWS:
The Cell Broadcast Center (CBC) belongs to the serving operator's domain. It is under the responsibility of public authorities and network operators in each country to agree on a national standard for the interface between Cell Broadcast Entity (CBE) and CBC (Figure 4.64).
A simplified description of a warning message delivery is as follows:
The Control Plane interface (N2/NG‐C) between the 5G‐AN and the 5G Core is defined according to following principles:
Following procedures and information exchange are defined over N2:
NGAP protocol stack is depicted in Figures 4.65 and 4.66. NG Application Protocol (NG‐AP): 3GPP defined Application Layer Protocol between the 5G‐AN node and the AMF (Figure 4.65). NG‐AP is defined in TS 38.413 [16].
Stream Control Transmission Protocol (SCTP): This protocol guarantees delivery of signaling messages between AMF and 5G‐AN node (N2). SCTP is defined in RFC 4960 [18].
N2 SM information: This is the subset of NG‐AP information that the AMF transparently relays between the 5G‐AN and the SMF (Figure 4.66).
A single NAS protocol applies on any (3GPP and Non‐3GPP) access for signaling between the UE and the 5G Core (Figure 4.67). The 5G NAS protocol is defined in 3GPP TS 24.501 [12].
A N1 NAS connection is used for each access to which the UE is connected. The N1 termination point is the AMF. The single N1 NAS connection is used for multiples purposes and 5GC Network Functions such as Registration Management and Connection Management (RM/CM controlled by the AMF itself and defined in Chapter 5), SM‐related messages and procedures for a UE (supported by the SMF and defined in Chapter 6), SMS delivery (supported by the SMSF and defined in Section 4.14).
The NAS protocol on N1 comprises a NAS‐MM and a NAS‐SM component. The NAS‐MM supports:
Security of NAS messages is provided based on the security context established between the UE and the AMF after UE authentication. For this purpose, the AMF receives a Master Key from the AUSF from which it derives the security material to be used to secure NAS messages.
The NAS protocol for SM (NAS‐SM) functionality supports user plane PDU session establishment, modification and release [12].
SM signaling messages are handled, i.e. created and processed, in the NAS‐SM layer of the UE and in the SMF. The content of the SM signaling messages is not interpreted by the AMF. The NAS‐MM layer transfers the SM signaling (NAS‐SM) as follows:
The common protocol framework for SBA consists of:
For transmitting large parts of opaque binary data along with the JSON format, multipart messaging is supported using:
This protocol suite enables a flexible definition of services and supports re‐use, easy modifications and easy integration to external domains via the NEF.
The control plane protocol between SMF and UPF (N4 reference point) is described in Chapter 6 and specified in 3GPP TS 29.244 [15].
While the IKE security association between the UE and the N3IWF is not established (see Section 4.12), the UE exchanges signaling with the network using EAP‐5G carried over IKE (Figure 4.68): EAP‐5G allows the exchange of NAS signaling and auxiliary information such as the UE temporary identifier (5G GUTI) and the slices requested by the UE (requested NSSAI). The N3IWF uses the auxiliary information to select the proper AMF for this UE. EAP‐5G is defined in 3GPP TS 24.502 [13].
When the IKE association between the UE and the N3IWF is established (see Section 4.12), the UE exchanges NAS signaling with the network using a dedicated IPsec security association (Figure 4.69).
When the N3IWF receives requests from the SMF related to user plane resources for a PDU session, it exchanges related signaling, creating, modifying, releasing such user plane resources on SWu for the PDU session, with the UE using dedicated signaling (as defined in 3GPP TS 24.502 [13]) carried over IKE (Figure 4.70).
In the three figures, the UDP protocol may be used between the UE and N3IWF to enable network address translation (NAT) traversal for IKEv2 and IPsec traffic.
This clause illustrates the protocol stack for the user plane transport related with a PDU session (Figure 4.71).
PDU layer: This layer corresponds to the PDUs carried between the UE and the DN over the PDU session. When the PDU session type is IPv6, it corresponds to IPv6 packets. When the PDU Session Type is Ethernet, it corresponds to Ethernet frames, etc.
General Packet Radio Service Tunneling Protocol for the user plane (GTP‐U): This protocol (defined in [11]) supports multiplexing traffic of different PDU sessions by providing encapsulation on a per PDU session level. It also carries the marking associated with a QoS flow as described in Section 6.4.
5G‐AN protocol stack: This set of protocols is Access Network specific. When the 5G‐AN is a 5G‐NR access, these protocols are defined in Section 4.4.3 and in TS 38.300 [4]. When the 5G‐AN is an Untrusted Non‐3GPP access these protocols are defined in Figure 4.72.
IPsec is used in tunnel mode for the following reasons:
UDP can be used below the IPsec layer to enable NAT traversal.
The NG‐RAN user plane protocol stack for the gNB is illustrated in Figure 4.73. The figure shows the case for a gNB with F1 Fronthaul interface [25] between gNB‐CU and gNB‐DU. In case of monolithic deployment, F1 interface collapses. The F1‐U interface like Xn‐U and NG‐U utilizes GTP‐U on top of UDP and IP as transport protocol. The NR User Plane protocol [28] (denoted as “NR UP” in Figure 4.73) is introduced on top of F1‐U and Xn‐U for flow control and frame retransmission. On the NG‐U interface (corresponding to N3 reference point in the 5G System), the PDU Session User Plane Protocol [29] is introduced which encapsulates user data and encodes additional information such as the Quality of Service Flow Identifier (QFI).
The user‐plane protocol stack is similar like for the gNB with fronthaul interface, if master and secondary nodes are in Dual Connectivity mode involving the Xn interface as illustrated in Figure 4.74.
This figure applies to the cases of NR‐E‐UTRA‐DC (NE‐DC) and NG‐RAN‐E‐UTRA‐NR‐DC (NGEN‐DC) [26], i.e. for Dual Connectivity between 4G and 5G nodes irrespective of the master node role, but with all involved nodes connected to the 5G Core. If the F1 interface is present, Xn‐U terminates at the gNB‐CU. The gNB‐DU relays the PDCP and higher layers between gNB‐CU and UE as illustrated in Figure 4.73.
Usage of the 5G System is subject to usage data collection. Usage data collection is a prerequisite for charging but may also be used to gather statistics and to monitor network usage and UE behavior. Usage data collection allows end‐user off‐line charging where the amount to be charged to the end‐user is determined on a regular basis, e.g. every month; it allows end‐user on‐line charging where the amount to be charged to the end‐user is determined as the telecommunication service is being delivered. This allows the network to cancel the service delivery when the end‐user has not previously filled the account; it also allows inter‐operator charging, where the visited PLMN collects usage data related with the telecommunication service it delivers to subscribers of roaming partners.
The SMF is responsible to collect usage monitoring data from the UPF and to transfer these data to the Charging Function (CHF). The CHF is responsible for creating CDR and transferring them to the billing system; it is responsible for checking whether the user account allows the delivery of the telecommunication service and controlling the network behavior, if this is not the case; for example, the CHF may instruct the SMF to have the user traffic redirected to an operator Web Page where the user is invited to refill the account; it is responsible for indicating to the PCF when the user has crossed some spending limits; this allows the PCF considering this information in the policies related with a user session and e.g. restrict the QoS for a given PDU session.
The SMF controls the UPFs to report traffic usage on a PDU session possibly considering the usage of traffic diversion at an UL classifier or a branching point as defined in Chapter 6. Charging information collected by the SMF includes the user ID (SUPI), the target DNN, the slice being used (S‐NSSAI); the amount of data exchanged per access type (e.g. 3GPP or Non‐3GPP access), rating group (a traffic identification that the PCF can associate with a traffic filter), it this allows to monitor separately traffic of different applications or traffic targeting different IP domains, time of the day.
Features specified for the 5G System as part of 3GPP Rel‐15 include, but are not limited to (see [32]):
Future 3GPP releases will be built on top of 3GPP 5G System Rel‐15 features and capabilities. It is expected that the following features are covered in 3GPP Release 16 for the 5G System:
The new features (not exhaustive list) targeted for the overall 5G System Architecture in Release 16 could be grouped under the following themes:
A RAN that supports one or more of the following options with the common characteristics that it connects to 5GC:
An access network comprising of a NG‐RAN and/or Non‐3GPP AN connecting to a 5G Core Network.
The core network specified in 3GPP TS 23.501 [1]. It connects to a 5G Access Network.
The 3GPP system consisting of 5G Access Network (AN), 5G Core Network (5GC) and UE.
The Latin word “Stratum” means layer and was chosen to avoid confusion with other layers such as the Open Systems Interconnection (OSI) layers.
The Access Stratum (AS) layer consists of all functions that are directly related to the RAN and the control of connections between end user device and radio network. Protocols on AS layer run between the device and the radio base station to establish and maintain radio channels.
The NAS layer on the other hand is on top of the AS layer and consists of functions that are related to connection control, access control, mobility and SM. Protocols on the NAS layer are exchanged between the device and the core network. The NAS and AS layer in the device and core network can communicate with each other. Figure 4.75 provides a simplified overview of the two layers.
All 3GPP specifications can be found under http://www.3gpp.org/ftp/Specs/latest.
The acronym “TS” stands for Technical Specification and “TR” stands for Technical Report (document a priori not maintained by 3GPP).