4.1.1 New Services Emerging

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:

1. Enabling support for new business cases.
2. Enabling operational agility for rapid deployment of new services.
3. Enabling extreme automation to reduce Total Cost of Ownership (TCO).

In short, the new network is expected to be more “flexible, faster and cheaper.”

4.1.2 Targets for the New Architecture

Translating service expectations to objectives for the new architecture has led to the following solution categories:

1. Service flexibility
2. Modular and extendable
3. Unified policy control
4. Access agnostic
5. Automated network deployments

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.

4.1.3 Shortcomings of the Current Architecture

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:

1. 1) All interfaces are point‐to‐point interfaces, allowing only two predefined functions to interconnect, with each function being part of a solution for a predefined problem statement. Extending the functionality of the system requires new functions and/or new reference points.
2. 2) Network functions are not orthogonal in their scope. As an example, session management (SM) functionality is distributed between mobility management entity (MME), serving gateway (S‐GW), packet data network gateway (P‐GW) and Policy and Charging Rules Function (PCRF). This means adding further capabilities to session or quality of service (QoS) management requires updating multiple network functions and interfaces between them, which hinders service flexibility.
3. 3) Each network function hides all the session context it maintains per UE. There is no easy method for network functions to expose and share their session data. In addition, session context is partly overlapping in different network functions like MME, S‐GW and P‐GW.

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.

4.2.1 Overview

Based on the drivers and motivations for the new architecture, the following requirements can be identified for this new architecture:

1. The architecture shall consist of independent domains that enable the independent evolution of each domain and the aggregation of capacity and coverage of multiple access technologies with a single architecture.
2. Network functions are orthogonal and self‐contained, i.e. each main function of the network needs to be assigned to a single Network Function entity, e.g. access control and mobility management (MM) functionality is supported by a single Network Function and not distributed across multiple Network Functions such as MME, ePDG, TWAG in EPC.
3. The architecture shall enable a UE to connect to multiple services simultaneously in a way that provides optimum user plane data paths for each service.
4. The architecture shall use a flexible connectivity framework between network functions without relying on pre‐determined interconnections. This allows new usage scenarios for the services provided by each network function and enables a “plug and play” model for newly introduced network functions. Thus, operators shouldn't have to ask 3GPP to define a new reference point every time they wish to deploy a new function and interface with 3GPP defined functions. In other words, a service based architecture (SBA) is required. Service based interface allows multi‐point connectivity for authorized network functions.
5. The architecture shall support the versatility of network usage by different services requiring different QoS but also different Control Plane (CP) resiliency, scalability and security. For example, the (internet protocol, IP) connectivity management may have different resiliency, scalability and security requirements depending on whether it applies for public safety devices, for a baseline smartphone or for a non‐critical cheap IoT devices.
6. The architecture shall apply a policy driven model where policies can be flexibly defined and applied for any function including the UE.
7. The architecture shall define programmable network functions enabling (external) applications to influence the services of the network functions and enabling automation of all aspects of network operation.
8. The architecture shall support cloud natively designed network functions that are instantiated on a cloud infrastructure and are able to accommodate cloud optimized resiliency models.
9. The architecture shall be able to unify 3GPP and non‐3GPP accesses in a single control and user plane in the core network.
10. The architecture shall enable services to be deployed either locally (geographically close to the UE) and/or centrally in a way that is transparent to the UE.
11. The architecture shall enable connectivity services to support new vertical markets including for example industrial control applications requiring very low latency (possibly coupled with high reliability) or demanding non‐IP connectivity services (e.g. Ethernet like services).
12. The architecture shall provide a simple mechanism to expose network events, e.g. UE registration to the network and establishment of connectivity on behalf of a UE.

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.

1. Phase 1 (3GPP Release 15). An early availability of a basic system that fulfills the goals and expectations set for commercial deployments for the Next Generation System including the Core Network.
2. Phase 2 (3GPP Release 16). Building a complete and feature rich system using the basic system defined as a foundation thereby ensuring backwards compatibility.

To ensure phase 1 is completed in a timely manner, 3GPP agreed to prioritize essential requirements for foundational network.

4.2.2 Architecture Domains

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.

4.2.3 Flexible Connectivity Models

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.

4.2.4 Service Based Architecture

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:

• Interconnections between functional entities of the network are flexible and dynamic, without any predetermined point‐to‐point structure.
• This interconnection must be based on a common protocol framework for all services.
• Each network function provides its capabilities as services any other network function can use if operator policy allows.
• Multiple versions of the same service must be able to co‐exist simultaneously.
• Each network function should only be concerned about the services it offers and the services it uses, no other services should have any impact to this network function.
• Each service must be self‐contained in a sense that there should not be any assumption, implicit or explicit, about a network function using the services in certain order.
• All operations that may modify the same contextual data are grouped in the same service.

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

4.2.5 Unified Policy Framework

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:

• Policies must be able to cover all aspects of the network behavior; the architecture must not limit the policies to specific use cases only.
• Policies may be of different scope in terms of service, user, time of day, network conditions, etc.
• It must be easy to add new policies.
• Any network function can request a certain policy.
• All available policies are capable of being exposed to all the network functions as needed.

4.2.6 Programmable Network

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.

4.2.7 Cloud‐Native Network Functions

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:

• Designed for failure, i.e. tolerating any type of failures that may occur frequently without impacting the end user service.
• Stateless to the degree possible, taking advantage of common solutions for resiliency and enabling use of common solutions for session data storage, as well as to simplify and improve scalability.
• Programmable, or software defined, to enable orchestration and automated configuration, performance monitoring, fault monitoring and troubleshooting. This includes providing all related data to analytics functions to process and to feed into the automation life cycle.
• Modular to enable frequent and independent additions, updates and removal of parts of the network function; in practice this means a micro‐services architecture supporting a continuous delivery model in accordance with DevOps paradigm.

In general, cloud native means building the network function as a flexible software product that can be easily tailored, managed and deployed.

4.2.8 Architectures for Different Spectrum Options

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:

• High frequency (e.g. 28 GHz) radio propagation conditions can lead to rapid signal loss for due to an obstacle between sender and receiver, making it more difficult to provide a robust connection and handovers triggered and executed fast enough to maintain that connection while user is moving.
• Deployments using high frequency bands also lead to smaller coverage areas (inter‐site distances of 100–200 m), making initial 5G coverage very spotty, leading to high load for inter‐system handover.
• Low frequency band deployments provide excellent coverage but lack of bandwidth to provide the throughput expected from 5G.
• High costs associated to rapid build‐out of wide area (WA) 5G coverage.

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:

• Robust connection via the LTE or 5G NR layer of the master cell, depending on whether LTE or 5G NR is the master. This requires wide 5G coverage.
• Aggregated throughput via LTE and 5G NR access.
• Ability to keep selected services such as Voice over Long Term Evolution (VoLTE) calls on the LTE layer.

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.

4.2.9 RAN Architecture Principles

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:

• Centralization of baseband processing, leading to a RAN architecture split into centralized and distributed units for cost efficient pooling of RAN control plane and higher‐layer baseband processing while keeping RF related functions close to the cell site. Such deployments require proper planning of site configurations and the transport network connecting distributed and central units.
• Multi‐access aggregation covering 5G and LTE using the centralized RAN unit as an anchor and aggregation point for increased capacity, coverage and connection reliability (interference control).
• Enabling integrated deployments with core functions, especially user plane functions (UPFs), as well as applications on top of the centralized RAN unit for efficient delivery of high throughput and low latency content (MEC).

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.

4.2.10 Interworking Principles

Interworking can be divided into two levels:

• Access interworking, i.e. how to enable the use of multiple access networks for a single service and device together with the same core network, while preserving radio connectivity to the UE. In this case, access technologies can either be 3GPP or non‐3GPP access (e.g. Wi‐Fi) based.
• Core level interworking, i.e. how to enable mobility of an UE from one access network to another access network served by different core networks. This allows seamless mobility with IP address preservation when the user moves between access networks (e.g. due to loss of coverage).

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:

1. Operators with both Voice over New Radio (VoNR) and LTE enabled, but no VoLTE: Some operators deploy VoNR and LTE, but do not launch VoLTE in their LTE network, which means VoNR will be dropped, if the UE moves from 5G coverage to 4G coverage.
2. Operators with no or poor LTE coverage (nor VoLTE): In some countries, operators only have 2G/3G deployments. Deploying a 5G System and VoNR directly would not be feasible for them since voice continuity cannot be guaranteed.

4.3.1 5G System Architecture Reference Model

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:

1. 1) Converged core to support multiple access technologies. The 5G Core network supports NR, E‐UTRA and non‐3GPP access (Wi‐Fi, Fixed). Untrusted wireless local area network (WLAN) access was the only non‐3GPP access connected to 5GC as part of 3GPP Rel‐15 while trusted and Wireline access were deferred to future releases (Rel‐16).
2. 2) Separate User and Control Plane functions following software defined networking (SDN) principles, allowing independent scalability and evolution of CP and UP. This allows for a flexible deployment of CP functions (geographically) separated from UP functions. Each of them being possibly deployed in centralized or distributed locations (data centers).
3. 3) As opposed to EPC which defined three types of UPFs (SGW‐u, PGW‐u, traffic detection function [TDF]) with statically defined capabilities, the 5G System contains a generic UPF with capabilities that can be programmed by the CP allowing much more flexibility for the deployment of 5G user plane features.
4. 4) Compute and storage separation: capability of a NF to store UE and protocol data unit (PDU) session context in a database (unstructured data storage function, UDSF), allowing the context to be shared across multiple instances of this network function. This supports multiple features such as scaling of network functions and 1 : N‐resiliency models. In both cases, when a new instance of the NF is selected to serve an UE/PDU session, the new NF instance can recover the UE/PDU session context from the database.
5. 5) A SBA (Service Based Architecture)  supporting the principles stated in Section 4.3.2.
6. 6) Modularization of the functional and interface design: ensure a proper design where specification and deployment updates due to the addition of new features are minimized.

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:

• Authentication Server Function (AUSF)
• Access and Mobility Management Function (AMF)
• Data Network (DN), e.g. operator services, Internet access or 3rd party services
• Unstructured Data Storage Function (UDSF)
• Network Exposure Function (NEF)
• NF Repository Function (NRF)
• Network Slice Selection Function (NSSF)
• Policy Control Function (PCF)
• Session Management Function (SMF)
• Unified Data Management (UDM)
• Unified Data Repository (UDR)
• User plane Function (UPF)
• Application Function (AF)
• User Equipment (UE)
• (Radio) Access Network ((R)AN)
• 5G‐Equipment Identity Register (5G‐EIR)
• Security Edge Protection Proxy (SEPP)

For the reader's reference, the outcome of 3GPP normative 5G System architecture work is documented in:

• 3GPP TS 23.501 [1]: “5G System Architecture,”
• 3GPP TS 23.502 [2]: “5G System Procedure and Flows,”
• 3GPP TS 23.503 [3]: “5G System Policy Control and Charging Framework.”

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.

4.3.2 Functional Description

4.3.2.7 Unstructured Data Storage Function (UDSF)

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.

4.4.1 Principles and Objectives

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:

1. – New services and business models. Efficient support of new and enhanced services, including mobile broadband with very high data rates, massive machine‐type communication and ultra‐reliable and ultra‐low latency communication. Here, network slicing is widely recognized as a key technology enabler to tailor network operations to new services and business in an efficient way.
2. – Cloud RAN will drive a paradigm shift in operation and deployment of mobile networks. Based on on‐demand provisioning of resources, centralization of network functions and NFV will impact functional components and interfaces of the logical network architecture.
3. – Integration of multiple Radio Access Technologies (RATs) to achieve an improved user experience and cost efficiency, 5G should provide a framework for tight integration of new 5G and existing radio interfaces in the RAN, including Wi‐Fi and LTE.

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.

• For enhanced mobile broadband (eMBB), a peak cell rate of 20 Gbps and an experienced user data rate of 1 Gbps with at least 100 Mbps at cell edges is expected. The end‐to‐end latency should not be above 10 ms. Vehicular speeds up to 500 km h⁻¹ shall be supported for high‐speed train use cases.
• For mIoT, while experiencing usually low data rates not above 100 kbps, a density of up to 10⁶ devices/km² can be expected.
• For ultra‐reliable low‐latency communication (URLLC), less than 0.5 ms over‐the‐air latency is expected for certain use cases.

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.

4.4.2 Overall NG‐RAN Architecture

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:

• Tight integration of RAN nodes with both LTE (E‐UTRA) and NR air interface;
• common RAN‐CN interface for all nodes; and
• flat and simple architecture with clear functional split between RAN and core.

These requirements are reflected in the overall NG‐RAN architecture as illustrated in Figure 4.13. It comprises the following elements:

• gNB radio nodes, hosting NR air interface;
• ng‐eNB radio nodes, hosting LTE (E‐UTRA) air interface;
• NG interface consisting of a control (NG‐C, corresponding to the N2 reference point) and user plane (NG‐U, corresponding to the N3 reference point) part connecting NG RAN radio nodes to the 5G core; and
• Xn interface, consisting of a control plane (Xn‐C) and user‐plane part (Xn‐U) interconnecting both gNB and ng‐eNB radio nodes [31].

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

4.4.3 Logical NG‐RAN Split

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:

• On the left‐hand side, a “classical” monolithic base station.
• In the center, a gNB with a higher‐layer Fronthaul split interface, which enables deployment of RRC, service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) in edge cloud facilities. The gNB is logically separated in a central unit (gNB‐CU), and one or more distributed units (gNB‐DU), which are interconnected with the F1 (F1‐C, F1‐U) interface [26].
• On the right‐hand side, a gNB with control/user plane separation for the higher‐layer split, where the gNB‐CU is further separated in gNB‐CU‐CP, hosting RRC and PDCP protocols. And gNB‐CU‐UP, hosting SDAP and PDCP protocols. The E1 interface connects gNB‐CU‐CP and gNB‐CU‐UP with a strict 1 : N relation [27].

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.

4.4.4 Lower‐Layer Split

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:

• Support for different beamforming techniques and algorithms for digital, analog and hybrid beamforming;
• interoperability with preferably small number of user and implementation specific parameters;
• support for advanced receiver and coordination features (such as Cooperative Multi Point); and
• future proof for upgrades of both central and remote units.

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.

4.4.5 Service‐Aware Function Placement

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.

• A common c‐plane function hosted in the gNB‐CU‐CP in an edge cloud controls several dislocated user‐plane components.
• MEC platform functions enable hosting of URLLC services in local radio clouds, as well as low latency or mIoT services in edge clouds.
• 5G core control plane is co‐located with fully centralized services.

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.

4.4.6 Connectivity to Multiple RAT

• One of the key features of 5G is the tight integration of multiple RATs in the radio access, specifically by using Multi‐Connectivity (MC) techniques. This refers, in general, to the case if a UE is served by more than one transmission/reception points (TRPs) at the same time, potentially using different RATs. This definition includes a fairly wide set of techniques ranging from lower layer and higher layer radio, and even core network or OTT methods such as Multi‐Path TCP (MP‐TCP). Here, we concentrate on higher‐layer radio access methods enabled by NR and NG‐RAN to achieve Multi‐Connectivity to enhance user throughput, packet reliability and connection robustness. In the first release, 5G focuses on a specific subset of Multi‐Connectivity called Dual Connectivity which involves exactly two RAN nodes where one is the Master Node (MN) which takes most of the radio resource decisions, and the other a Secondary Node (SN) in a supplementary role. In future releases, other RATs such as WiFi will be integrated as well. The following terms are introduced [26]:
• Multi‐Radio Access Technology Dual Connectivity (MR‐DC) as a generic term for Dual Connectivity which involves NR and LTE nodes;
• NR‐DC for Dual Connectivity between gNBs;
• NE‐DC for NR‐E‐UTRA Dual Connectivity where the gNB is the master node and the ng‐eNB is the secondary node
• NGEN‐DC for NG‐RAN E‐UTRA Dual Connectivity where an ng‐eNB is the master node and gNB is the secondary node;
• EN‐DC for E‐UTRA‐NR Dual Connectivity in option 3 deployments (see Section 4.5) where an eNB has the master role and a gNB the secondary role. Note that this variant is strictly interpreted as being not part of the NG‐RAN architecture, but of evolved universal mobile telecommunications system terrestrial radio access network (E‐UTRAN) Rel‐15.

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.

4.5.1 Architecture Options

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:

1. 1) Spectrum availability:
   1. a. NR capacity bands: 3.5 GHz, mmWave
   2. b. NR coverage bands: <2 GHz, best under 1 GHz
   3. c. LTE/NR spectrum sharing
   4. d. 3G refarming strategy
   5. e. Unlicensed band
2. 2) Device availability:
   1. a. Most of the early devices will support option 3 NSA (3GPP Rel‐15 early drop)
   2. b. Standalone and 5G System based deployment options (2/4/7) will come in a later step
   3. c. Support of FDD bands is expected after TDD band support (in higher frequencies enough bandwidth available to go for TDD)
3. 3) Cell density:
   1. a. NR 3.5 GHz massive multiple‐input‐multiple‐output (mMIMO) matches LTE 1800 MHz grid in high density areas
   2. b. Network wide coverage will need sub 1 GHz spectrum or rely on LTE coverage
4. 4) Services and business Strategy:
   1. a. eMBB only or wide set of 5G use cases exploiting low latency and high reliability
   2. b. Vertical opportunities
   3. c. Cost reduction versus new revenue
   4. d. Long term LTE and EPC investment plans

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

4.5.2 Non‐Standalone Architecture with EPS

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:

• Subscription based access control. Mechanism for the HPLMN and VPLMN to control UE's access to 5G NR based on subscription data (when 5G NR is used as a secondary RAT).
• Gateway selection based on NR capability. UE “5G Radio Access Capability” handling in MME and enabling selection of S‐GW and P‐GW optimized for NR capable devices (e.g. allowing for higher throughput).
• Extended throughput/bit rate. Extend the maximum range of maximum bit rate values to cater with 5G demands.
• Secondary RAT type for charging. Mechanism to provide “secondary RAT type” information from RAN to CN (e.g. for S‐GW and P‐GW charging records, for PCC and possibly IMS).
• Optional support for new security algorithms.

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.

4.6.1 Overview

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.

4.6.2 Subscription Permanent Identifier

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.

4.6.3 Subscription Concealed Identifier

The Subscription Concealed Identifier (SUCI) is a privacy preserving identifier containing the concealed SUPI. It is expected to be used in the NAS messages.

4.6.4 Temporary Identifier

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

• <GUAMI> = <MCC> <MNC> <AMF Region ID> <AMF Set ID> <AMF Pointer>
• <5G‐S‐TMSI> = <AMF Set ID> <AMF Pointer> <5G‐TMSI>
• GUAMI = identifies one or more AMFs within an AMF Set.
• MCC = Mobile Country Code of the PLMN.
• MNC = Mobile Network Code of the PLMN.
• AMF Set ID = identifies an AMF Set. An AMF Set comprises of AMFs that support the same set of Network Slices.
• AMF Pointer = identifies one or more AMFs within an AMF Set.
• AMF Region ID = identifies AMF Region. An AMF Region comprises of multiple AMF Sets.
• 5G‐TMSI = identifies the UE within the AMF.

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.

4.7.1 Introduction and Definition

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.

4.7.2 Isolation Properties

Slicing provides isolation in many ways and for various properties of the network. The most relevant ones are:

• Isolation of functions. Slices don't require the same network functions, some of the functions can be omitted completely and some functions may have a very different set of services that are relevant in a slice.
• Isolation of configurations. Even for the same functions and services, different configurations can be used, such as parameters impacting the behavior of a function (e.g. level of high availability) or which neighboring functions to use.
• Isolation of resource usage policies. Different slices may have different policies on how much resources are provided by, e.g. the virtualization infrastructure or by the physical network functions such as throughput in switches and routers. This means the load domains are isolated, enabling the prevention of an overload in a manner consistent with the criticality of the traffic in the slice.
• Isolation of lifecycles. Timelines for when a slice is introduced, updated, and finally removed from the network can vary greatly from slice to slice. Functions can also be tested in one slice before extending the use to other slices.
• Isolation of failure domains. Slicing enables
• the impact of a failure to be kept within the slice. In this case the failed function is not present in other slices. The failure is completely isolated to a single slice.
• Isolation of security domains. Since slices should operate on isolated virtual networks, attackers should not be able to access other slices even when one slice is compromised.

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.

4.7.3 Slicing Architecture

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:

• Network functions capable of being either: slice specific, common to a group of slices or common to all slices.
• Orthogonal architecture where each functional domain is fully confined in a single network function.
• Service oriented architecture where each service a network function provides can be individually enabled, tailored or disabled.

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):

• In case of CU‐DU split RAN architecture, CU control and user plane (CU‐CP, CU‐UP) resources can be dedicated to certain slices, or common to several slices. This allows the implementation of a high‐throughput CU user plane instance just for an eMBB slice.
• Flexible deployment of CU‐CP and CU‐UP resources based on the needs of a given slice. This allows CU user plane location geographically close to the DU for URLLC slices (although one CU‐UP can still serve many DU), while CU control plane is centralized.
• Slice aware and slice optimized scheduler in the DU. This allows the allocation of resources to specific slices based on the given SLA and dynamically shift resources from one slice to another, if there is the need and possibility (i.e. one slice does not consume the allocated resources that were promised to it) to do so.
• Support of virtual local area network (VLAN), other virtual private network techniques or DiffServ Code Point (DSCP) marking to separate slices on the backhaul interface between gNB and core network.

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.

4.7.4 Slice Selection

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:

• Slice Service Type (SST) indicating the slice characteristics.
• Slice Differentiator (SD) indicating further differentiation in case multiple slice instances comply with the expectations set by the SST. SD can be used to differentiate between slices of different tenants.

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.

1. UE indicates requested NSSAI as part of Registration Request. The requested NSSAI is a configured NSSAI for the PLMN (i.e. provisioned to the UE) when accessing the PLMN for the first time.
2. RAN selects an AMF based on requested NSSAI and sends the request to the selected AMF.
3. AMF fetches subscription data from UDM, providing also the requested NSSAI
4. UDM returns the subscription data, including subscribed S‐NSSAI(s) for those requested S‐NSSAI(s) for which a subscribed S‐NSSAI exists.
5. AMF requests NSSF to select a Network Slice Instance(s) (NSI) matching the subscribed S‐NSSAI(s) and to provide information on AMF(s) capable of serving the allowed NSI(s).
6. NSSF discovers the suitable AMF(s) by providing allowed S‐NSSAI(s) to NRF.
7. NRF provides AMF candidate(s) to NSSF.
8. NSSF provides NSI identifier(s), allowed S‐NSSAI(s) and AMF candidate(s) to AMF.
9. AMF sends Registration Accept to RAN, including allowed S‐NSSAI(s). In case a different AMF needs to be selected, the AMF processing the Registration Request redirects the request to an AMF that belongs to the AMF candidate set.
10. RAN sends the Registration Accept to UE. UE uses the provided allowed S‐NSSAI(s) as requested NSSAI is subsequent procedures.

4.7.5 Interworking with EPS (e)DECOR

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:

• EPC consisting of a dedicated core network containing MME, S‐GW and P‐GW, and 5G slice consisting of AMF, SMF and UPF.
• EPC consisting of P‐GW and 5G slice consisting of SMF and UPF (Figure 4.29)

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.

4.9.1 Introduction

In a 5G System, the network is expected to manage different kinds of information:

1. 1) Subscription data based on user's subscription contract which are expected to be semi‐static.
2. 2) Policy data based on operator's policies, subscription and dynamic events occurring in the network (e.g. current session, location, session status, etc.).
3. 3) Information targeted for exposure toward external AFs for different purposes: application behavior adaption, application's ability to influence the network, dimensioning and statistics purposes.
4. 4) Transient UE context that is created in each NF based on UE's registration and session in the respective NF.

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.

4.9.2 Compute‐Storage Split

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 high reliability with less hardware footprint. Allows support for newer redundancy models: N + m Geo‐Redundancy, rather than 1 : 1 mated‐pair Geo‐Redundancy.
• Introduces the ability to support dynamic run time load (re‐)balancing with no impact to user's services.
• Opportunity to leverage contexts/state information for data analytics and internal and external capability exposure, e.g. toward edge applications.

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.

4.9.3 What is “Stateless”? How “Stateless” is “Stateless”?

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:

1. 1) No state (Figure 4.34). Such NFs do not store UE state information (UDM frontend connected to one database). This allows NF consumers to select any NF instance for processing a UE transaction.
2. 2) Stateless NF (Figure 4.35). Such NFs hold UE state only for the duration of a transaction, and any NF instance can be selected to process the UE transaction. This allows any NF instance to process UE transactions, thus enabling high scalability and resiliency. However, the risk of race conditions due to two consumers (frequently) selecting a different NF instance for processing the same UE transaction increases (possibly have an impact on system performance).
3. 3) State efficient NF (Figure 4.36). The NF holds UE state during periods of frequent activity (e.g. for some seconds or minutes while the UE is in connected state) in the middle of a certain procedures, and it stores UE state in the Storage resource when the UE is inactive (e.g. no control plane procedure ongoing). This implies all transactions within a certain procedure for a given UE are expected to be processed by the same NF instance. It stores stable state in the UDSF at the end of a certain procedure. When the Producer NF does not hold state, it has the freedom to release the long‐lived association with a Consumer NF instance for a given UE. Thus, after the release of an association, the Consumer NF can select any NF instance for processing UE transaction, however since the frequency of NF instance selection is limited compared to purely stateless NF configuration, the probability of race conditions (i.e. two different NF consumers selecting a different NF instance for processing a certain UE transaction) is minimized. This configuration allows change of NF instances for resource scaling up and down, NF planned maintenance, NF failure handling, etc. Thus, it enables scalability up to “n” NF instances processing UE transactions.
4. 4) Stateful NF (Figure 4.37). The NF holds UE state information permanently.

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.

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.

4.9.4 AMF Resiliency and State‐Efficient AMF

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

4.10.1 Introduction

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:

• Operator can get information on the UE behavior (e.g. traffic patterns) to tune the network accordingly.
• An application can monitor UEs by getting, e.g. information on the location of the UE, on the change of association between UE and serving location (e.g. an edge data center) or on the reachability of the UE.
• To support application instances deployed in the edge influence the flow of user plane traffic and user plane connectivity, the network exposes requested information (e.g. regarding mobility events) toward the application. This allows proper selection and configuration of UPFs in the network.
• An application can request an application trigger to be sent to an application instance running on a UE or in the network; this can trigger the UE to establish communication with the proper application instance in the network.
• An application can “sponsor” some data (like advertisement) ensuring that the corresponding data transmission is not charged to the end‐user.
• An application can provide descriptors, e.g. Packet Flow Descriptors (PFDs), and forwarding rules corresponding to an application identifier.
• A third party can negotiate cheaper usage of the network but only in some conditions, e.g. based on time of day or based on the location where the service is delivered.

4.10.2 Bulk Subscription

The NEF is burdened with significant overhead resulting from per UE events:

1. 1) Subscription events need to be supported for every UE.
2. 2) Serving NF needs to be determined for every UE.
3. 3) Mobility events need to be managed as the serving NFs (e.g. AMF) are modified for every UE.
4. 4) Identifiers must be maintained on a per UE basis.

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:

1. 1) Exposure subscription for one UE, group of UE(s), any UE with the respective NFs, e.g. for all UE(s) served by an AMF.
2. 2) Exposure Subscription from the time of NF instantiation, e.g. immediately after AMF instantiation. This is to ensure that no event is missed by the NEF.

Figure 4.40 illustrates the exposure procedure with bulk subscription:

4.10.3 NEF Capabilities

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:

• Authenticating the application.
• Authorizing the application; this may include checking the SLA for the application. This corresponds to a global authorization for the application to invoke network APIs; per‐UE authorization is performed by the UDM upon request of the NEF.
• Issuing usage data collection to keep track of the application requests and to potentially charge the provider of the external application.
• Support for bulk subscription with all NFs or individual subscription with the targeted NF for exposure events related to a single UE, group of UE(s) or any UE.
• Translation of parameters, e.g.:
  1. ∘ Translating between internal location information (Tracking Area and/or cell ID) and geographical information e.g. latitude and longitude.
  2. ∘ Using knowledge on the application to determine network parameters such as the slice or the DNN that is the target of the application request.
  3. ∘ Translating the external identification of the UE into the PLMN identification of the UE (SUPI); for this purpose, the NEF may need to invoke the UDM.

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.

4.11.1 Background

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:

1. 1) There are many variants expected for 5G network deployments.
2. 2) The 5G Radio is expected to be deployed in high and low bands. In high bands, the UE will lose 5G coverage quite often. Thus, support for an efficient interworking solution is essential.

To ensure that various forms of mobility and coverage scenarios are considered, two levels of interworking are supported:

1. System level interworking with EPS. Interworking supported between NG‐RAN/5GC and LTE/EPC with or without a signaling reference point. This is explained in Section 4.9.2.
2. Access Network interworking. Interworking supported between ePDG/EPC and Non‐3GPP Interworking Function (N3IWF)/5GC for UE(s) connected via untrusted non‐3GPP access. This is explained in Section 4.11.3.

4.11.2 Migration from EPS Toward 5GS

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:

1. 1) EPC and 5GC have access to a common subscriber database, that is HSS in case of EPC and UDM in case of 5GC, acting as the master data base for a given user.
2. 2) A UE that is capable of supporting 5GC NAS procedures may also be capable of supporting EPC NAS to operate in legacy networks, i.e. in case of roaming.
3. 3) The UE can use EPC NAS or 5GC NAS procedures depending on the serving core network it obtains services from. The procedure for the UE to select EPC versus 5GC NAS is specified in 3GPP TS 24.501 [12].
4. 4) A UE that supports only EPC based Dual Connectivity with secondary RAT NR
   1. – always performs initial access through E‐UTRA (LTE‐Uu) but never through 5G NR;
   2. – performs EPC NAS procedures over E‐UTRA (i.e. Mobility Management, Session Management, etc.) as defined in 3GPP TS 24.301 [13].
5. 5) A UE that supports camping on the 5G System with 5GC NAS
   1. – can perform initial access either through E‐UTRA or 5G NR connected to 5GC; or
   2. – can perform initial access through E‐UTRAN toward EPC, if supported and needed.

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:

1. 1) The eNB connected to 5GC will broadcast this information via the air interface. Based on that, the UE AS layer indicates “E‐UTRA connected to 5GC” capability to the UE NAS layer.
2. 2) The UE NAS layer selects 5GC NAS or EPC NAS based on network support and operator policies as specified in 3GPP TS 24.501 [12].
3. 3) Upon selection of EPC versus 5GC NAS, the UE AS layer is informed by the NAS layer whether a NAS signaling connection must be initiated toward 5GC.
4. 4) Based on that information, UE AS layer indicates to the RAN whether it is requesting 5GC access (sends “5GC requested” indication).
5. 5) The RAN uses this indication to determine whether a UE is requesting 5GC or EPC access. The RAN routes NAS signaling to a MME or AMF accordingly.

4.11.3 System Level Interworking with EPS

To support seamless service continuity between 5GS and EPS, an interworking architecture requires

• a common UPF that serves as an IP anchor so that the UE IP address can be preserved;
• a combo SMF/P‐GW‐C function. UPF and SMF are regarded as PGW‐U and PGW‐C, respectively, from the viewpoint of a S‐GW;
• a common subscription database HSS/UDM; and
• a signaling interface N26 between MME and AMF for context transfer. N26 is expected to be based on S10 interface to allow interworking with a MME that will not be upgraded to support interworking with the 5GC.

Figure 4.43 shows the interworking architecture:

The interworking solution was specified to cater for different deployment needs:

1. 1) Interworking between EPC and 5GC using N26 interface between MME and AMF.
2. 2) Interworking between EPC and 5GC without any direct interface between EPC and 5GC network functions.

Furthermore, the solution supports two different kinds of UEs:

1. 1) Single Registration Mode UE (Figure 4.44). This UE has only one active NAS state (either RM state in 5GC or evolved packet system mobility management [EMM] state in EPC) and it is either working in 5GC NAS mode or in EPC NAS mode depending on whether it is connected to 5GC or EPC. The UE maintains a single coordinated registration state for 5GC and EPC. To enable re‐use of a previously established 5G security context when returning to 5GC, the UE also keeps the native 5G‐GUTI and the native 5G security context when moving from 5GC to EPC.
2. 2) Dual Registration Mode UE (Figure 4.45). The UE can handle independent registrations in 5GC and EPC. In this mode, the UE maintains two NAS states independently. It may be registered to 5GC only, EPC only, or to both 5GC and EPC at the same time.

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:

1. 1) Interworking with MME is based on the S10 interface used within EPC at inter MME mobility. An MME (that is not upgraded) assumes that UE is moving from another MME when the UE moves from the 5G System to EPS. With this approach, the MME treats the AMF as if it was an MME. The AMF acts as an MME toward the MME. This avoids mandatory and/or non‐backward compatible enhancements for an MME at the protocol level.
2. 2) AMF needs to ensure that MME does not assume the UE was previously served by a serving general packet radio service support node (SGSN). After it moves from 5GC to EPC and if the MME would assume the UE was served by a SGSN, security is assumed to be based on 3G – 4G interworking which is less inferior. Also, this would lead to an incorrect context retrieval request toward SGSN.
3. 3) Retain MM/security contexts in the AMF for a configured period to allow support for interworking using the native security context and at the same time support security separation.
4. 4) Minimize signaling to and from HSS/UDM in case of frequent ping‐pong of the UE between 4G and 5G coverage.
5. 5) Minimize impacts to the MME but allow essential (optional) backward compatible enhancements and (e.g. for simplification in the context transfer and improved security) to be specified for an optimal interworking with an MME that can support these optional enhancements. One such justified reason for enhancements – improved security, security separation between EPS and 5GS (i.e. to avoid attack in one system causing an attack also in the other system). Necessary and well justified evolution (e.g. for security reasons) should be possible and not prohibited.

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.

4.11.4 Interworking Between EPC and 5GC Using N26

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:

• In case of idle‐mode mobility from 5GC to EPC, the UE performs TAU (Tracking Area Updating) procedure with 4G‐GUTI mapped from 5G‐GUTI. The MME retrieves the UE's MM and SM context from 5GC, if the UE has a PDU session established or if the UE or the EPC support “Attach without PDN connectivity.” The UE performs an Attach procedure, if it is registered without PDU session in 5GC and the UE or the EPC do not support Attach without PDN connectivity. For connected‐mode mobility from 5GC to EPC, inter‐system handover is performed.
• In case of idle‐mode mobility from EPC to 5GC, the UE performs Registration procedure with native 5G‐GUTI and mapped 5G‐GUTI (mapped from 4G‐GUTI). If the AMF can retrieve the stored security context (e.g. from its own cache, from UDSF or from another AMF) using the native 5G‐GUTI, the AMF uses this security context as opposed to the security context retrieved from EPC. In addition, AMF and SMF retrieve the UE's MM and SM context from EPC. For connected‐mode mobility from EPC to 5GC, inter‐system handover is performed.

4.11.5 Interworking Between EPC and 5GC without N26

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:

• In case of mobility from 5GC to EPC, the UE may perform TAU procedure with 4G‐GUTI mapped from 5G‐GUTI. The MME determines that the old (source) node is an AMF, rejects the TAU with a “Handover PDN Connection Setup Support” indication to the UE. Based on this indication, the UE may perform Attach in EPC with “handover” indication in PDN Connection Request message and it subsequently moves all its other PDU sessions from 5GC to EPC using the UE initiated PDN connection establishment procedure with “handover” flag.
• In case of mobility from EPC to 5GC, the UE performs Registration of type “mobility registration update” in 5GC with 5G‐GUTI mapped from 4G‐GUTI. The AMF determines that old (source) node is an MME, but proceeds as if the Registration is of type “initial registration.” The Registration Accept message includes “Handover PDU Session Setup support” indication to the UE. Based on this indication, the UE may subsequently move all its PDN connections from EPC to 5GC using the UE initiated PDU session establishment procedure with “Existing PDU Sessions.”

It should be noted that the network does not automatically cancel the UE registration when the UE moves from one system to another.

4.12.1 Introduction

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

• 3GPP accesses (the procedures and protocols on the “last mile access” are defined by 3GPP); and
• Non‐3GPP accesses (the procedures and protocols on the “last mile access” are not defined by 3GPP but possibly by another standards forum).

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:

• Some control information exchanged between 5GC and the access network depend on the access type, e.g. the User Location Information (ULI) or the information about Discontinuous Reception (DRX) (discontinuous UE reception, which is only defined for 3GPP access). The 3GPP cell ID can be used as ULI when the UE is camping over WLAN or over Wireline.
• Some procedures do not apply on some access system, e.g. paging and periodic registration procedures do not apply to untrusted non‐3GPP access.
• The mechanisms used for mobility between 3GPP and Non‐3GPP access are different from the handover procedures within 3GPP access. This is because handover within 3GPP access is controlled by the network (RAN) while mobility between 3GPP and Non‐3GPP access is under control of the UE.

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:

1. 1) The UE connects to an untrusted Non‐3GPP access network (e.g. WLAN as defined in IEEE 802.11 [10]) with procedures outside the scope of 3GPP. Any non‐3GPP authentication method can be used, e.g. no authentication (in case of a free WLAN), pre‐shared key, username and password, etc. The UE receives an IP address from the access network that will be used to contact the N3IWF.
2. 2) When the UE decides to attach to 5GC, it selects an N3IWF as described in 3GPP TS 23.501 [1] Section 6.3.6.
3. 3) The UE proceeds with the establishment of an IKE (see [22]) association with the selected N3IWF possibly reachable over other un‐trusted access networks. The IKE association protects both UE and N3IWF against security attacks coming from any of these un‐trusted networks. The establishment of the IKE association follows internet engineering task force (IETF) RFC 7296 [22] complemented by following 3GPP specific procedures:
   1. a. The UE provides information (temporary UE identifier, target set of slices…) allowing the N3IWF to select an AMF.
   2. b. The N3IWF establishes an NGAP association with the AMF for a give UE.
   3. c. The UE exchanges NAS signaling with the 5G Core (Registration, Service Request and possibly authentication related signaling). As the IKE association is still in authentication phase, NAS signaling is carried over EAP‐5G (a specific flavor of the Extensible Authentication Protocol IETF RFC 3748 [17]) on the interface between the UE and the N3IWF and over the N2 association related to the UE between N3IWF and AMF. At the end of this exchange the AMF sends a NAS Security Mode Command to the UE.
   4. d. Access is now granted to the UE. The AMF provides the N3IWF with security material to complete the establishment of the IKE association.
4. 4) An IPsec security association dedicated to NAS signaling is created.
5. 5) From now on NAS signaling is carried over the IPsec security association dedicated to NAS signaling between UE and N3IWF and over the N2 association related to the UE between N3IWF and AMF.

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:

• NAS signaling relayed to or from the N2 interface with the AMF.
• Add‐on information like 5G UE identity (5G‐S‐TMSI or GUAMI), slice information (NSSAI) allowing the AN to select the correct AMF.
• Access related signaling used to negotiate PDU Session (and QoS flow) related resources on the link between UE and 5G AN (radio link for the RRC protocol, IPSec link in case of N3IWF/Untrusted Access to 5GS).

4.12.2 Interworking with EPC in Case of Non‐3GPP Access

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):

• Common UPF/PGW‐u that serves as an IP anchor so that the UE IP address can be preserved.
• Combo SMF/P‐GW‐c function. UPF and SMF are regarded as PGW‐U and PGW‐C, respectively, from the viewpoint of the S‐GW.
• Common subscription database HSS/UDM.
• Seamless service continuity between 5GS and EPS in case of Non‐3GPP access does not rely on N26 interface between MME and AMF or between ePDG and AMF. This is because no network‐based handover can take place in case of Non‐3GPP access (the mobility is UE driven) and because the PDG does not support any equivalent interface to the MME to MME S10 interface in EPC.

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:

• When the 3GPP access serving the UE provides connectivity to the 5GC, the UE issues 5G NAS signaling to the SMF (via AMF) to move the corresponding PDU Sessions. The AMF that is reachable over 3GPP access is the same AMF reachable over N3IWF/Non‐3GPP access, at least in non‐roaming cases. This AMF is aware of the SMF address where to forward UE requests.
• When the 3GPP access serving the UE does not provide connectivity to the 5GC, the UE needs to ensure it is attached to a MME and to issue a 4G PDN Connection establishment request with a handover request to trigger handover of the PDU Session. This process is equivalent to the mobility in Dual‐Registration mode as described in Section 4.11.3.

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.

4.12.3 Multi‐Access PDU Sessions

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.

4.14.1 Principles of a Service Framework

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:

1. 1) NF services offer a common interface framework to authorized consumers.
2. 2) NF services offer capabilities to authorized consumers. Authorized consumers are identified based on operator policies.
3. 3) NF services shall be self‐contained (operate on own context), reusable and with an independent life cycle management.
4. 4) NF services across Network Functions interact with each other either using “Request‐Response” or “Subscribe‐Notify” service operation types. Request‐Response transactions are generally for 1‐1 communication and guarded by a timer.
5. 5) System procedures should be described by a sequence of service invocations.
6. 6) NF services shall be accessible by means of an interface. An interface may consist of one or several operations.

Furthermore, to ensure that the NF services defined in 3GPP are bound by certain criteria, following principles applied in Rel‐15:

1. 1) Standardized NF services can be defined only when it is needed for 5G System Procedures.
2. 2) Interaction between NF services within the NF is not subject to standards.

4.14.2 What is an NF Service?

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:

1. – Each NF service operates on its own set of context data. A context refers to a state or a software resource or an internal data storage. The NF service operations can create, read, update or delete the context data.
2. – Any direct access of a context owned by a NF service is to be made by the service operations of that NF service. Services provided by the same NF can communicate internally within the NF.

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.

4.14.3 Consumer/Producer Interactions

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:

1. 1) “Request‐Response” (Figure 4.56). A control plane NF_B (NF Service producer) is requested by another control plane NF_A (NF Service consumer) to provide a certain NF service, which either performs an action or provides information or both. NF_B provides NF service based on the request by NF_A. To fulfill the request, NF_B may in turn consume NF services from other NFs. For the Request‐Response mechanism, communication is one‐to‐one between consumer and producer. A one‐time response from the producer to a request from the consumer is expected within a certain timeframe.
2. 2) “Subscribe‐Notify” (Figure 4.57). A control plane NF_A (NF Service consumer) subscribes to a NF service offered by another control plane NF_B (NF Service producer). One or more control plane NFs may subscribe to the same control plane NF Service. NF_B notifies all subscribed NFs about the results of this NF service. The subscription request normally includes:
   1. 1) The notification endpoint (e.g. the notification URL) of the NF Service consumer.
   2. 2) The need receiving periodic updates.
   3. 3) Events that are of interest for notification, e.g. the content of information requested has changed, reaches certain thresholds, etc.

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.

4.14.4 Network Function Service Authorization

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:

1. – Check whether the NF Service consumer is permitted to discover the requested NF Service producer instance during the NF service discovery procedure. This is performed on a per NF granularity by the NRF.
2. – Check whether the NF Service consumer is permitted to access the requested NF Service producer for consuming the NF service on a per request type, per UE, per subscription and roaming agreement granularity. This type of NF Service authorization is embedded in the related NF service logic of the NF.

4.14.5 Network Function Registration and De‐registration

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:

1. – NF instance ID;
2. – NF type;
3. – PLMN ID;
4. – Network Slice related identifier(s), e.g. S‐NSSAI, NSI ID;
5. – Fully qualified domain name (FQDN) or IP address of the NF;
6. – NF capacity information;
7. – NF specific service authorization information;
8. – Names of supported services;
9. – Endpoint information of instance(s) of each supported service; and
10. – Identification of stored data/information.

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.

4.14.6 Network Function Discovery

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:

1. 1) The type of the NF or the specific service it is attempting to discover, e.g. SMF, PCF, UE Location Reporting.
2. 2) The NF service related parameters, e.g. slicing related information to discover the target NF.
3. 3) The detailed service parameters used for specific NF discovery (refer to the related NF discovery and selection clause).

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.

4.14.7 Network Function Services

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

4.15.1 Overview

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.

4.15.2 Support for System/EPS Fallback for Voice

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.

4.15.3 Support for RAT/E‐UTRA Fallback for Voice

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.

4.16.1 Overview

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.

1. 1) The network must be capable of supporting IMS services as explained in the previous Section 4.14.
2. 2) The network must consider emergency services with high priority both for control plane signaling related to emergency services establishment and user plane traffic related to emergency services communication. This implies that even under congestion situation, requests for emergency services and the actual emergency session shall be treated with high priority by RAN and each Network Function within the 5GC.
3. 3) The network may need to support emergency services for unauthenticated UEs depending on regulatory requirements. In some countries, emergency services must be supported also for UEs without universal subscriber identity module (USIM) (e.g. North America) in addition to supporting emergency services for UEs with USIM but without active subscription. In some countries (e.g. Germany), emergency services are not provided to UEs without USIM, but the network may still need to support emergency services for unauthenticated UEs.
4. 4) The network must be able to detect UE's location (Location Services) to route the UE to the right PSAP.
5. 5) The network must indicate support for Emergency Services on a per RAT basis to the UE. The Emergency Services support indication is valid within the current Registration Area. Based on this indication, the UE determines whether a PDU session for emergency services can be initiated. If the network indicates support for Emergency Services in the RAT and in the Registration Area the UE is camping on, the UE is required to initiate a PDU session for Emergency Services.
6. 6) The radio network needs to broadcast support for Emergency Services. This is needed for UEs that are in limited service state (UE not registered on the network) to determine which network natively supports emergency services for unauthenticated UEs.
7. 7) When a PLMN supports IMS Emergency Services, all AMFs in that PLMN and at least one SMF shall have the capability to support 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.

4.16.2 Support for Emergency Services Fallback

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.

4.18.1 Overview

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

4.18.2 SMS over NAS

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:

1. 1) The SMSF need not assign any temporary identifier such as TMSI for the UE as it is only the AMF that is assigning temporary identifiers for a UE.
2. 2) The SMSF does not have to assign any location area for the UE as it is only the AMF that is assigning a Registration Area for a UE.

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:

1. – Support for SMS over NAS transport between UE and AMF. This applies to both 3GPP and Non‐3GPP accesses.
2. – The AMF determines the SMSF for a given UE.
3. – Support for subscription checking and actual transfer of MO‐SMS and MT‐SMS by the SMSF.
4. – Support for MO‐SMS and MT‐SMS transmission for both roaming and non‐roaming scenarios.
5. – Support for selecting proper domains for MT‐SMS message delivery (e.g. over 5G, LTE or CS) including initial delivery and re‐attempting in other domains.

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.

4.20.1 Control Plane Protocol Stacks

4.20.1.1 Control Plane Protocol Stacks Between the 5G‐AN and the 5G Core

The Control Plane interface (N2/NG‐C) between the 5G‐AN and the 5G Core is defined according to following principles:

• Different types of 5G‐AN (e.g. 3GPP RAN, N3IWF for Untrusted Non‐3GPP access to 5GC) connect to the 5CG via a unique control plane protocol, the NGAP.
• There is a unique N2 termination point in the AMF per access for a given UE regardless of the number (possibly zero) of PDU sessions of the UE and regardless of the number of 5GC NF needing to send signaling to the 5G‐AN (e.g. SMF(s) and SMSF serving the UE, Cell Broadcast Service).
• From the 5G‐AN perspective, there is a single N2 termination point, the AMF.
• NGAP supports a decoupling between AMF and other functions such as SMF that may need to control the services supported by 5G‐AN(s) (e.g. control of the UP resources in the 5G‐AN for a PDU session).

Following procedures and information exchange are defined over N2:

• Procedures related to N2 interface management and not related to an individual UE, such as configuration or reset of the N2 interface. Via these procedures the 5G‐AN and the AMF can exchange configuration information, e.g. about:
  • Tracking Areas, PLMN ID and slices (S‐NSSAI) the 5G‐AN support.
  • AMF identifier, slices (S‐NSSAI) and transport connections the AMF supports.
  • AMF overload status.
• Procedures related with an individual UE:
  • Procedures related to NAS transport between the UE and the AMF.
  • Procedures related with UE context management, e.g. to provide the 5G‐AN with relevant security material to secure the AN‐related procedures (RRC or interface between the N3IWF and the UE).
  • Procedures related to resources for PDU sessions. They may correspond to messages that carry information, e.g. related to N3 addressing and QoS requirements, that is transparently forwarded by the AMF between the 5G‐AN and the SMF.
  • Procedures related to handover management. These procedures are intended for 3GPP access only.

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

4.20.1.2 Control Plane Protocol Stacks Between the UE and the 5GC

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:

• Registration Management and Connection Management state machines and procedures between the AMF and the UE (see Chapter 5).
• Transmission of other types of NAS information (e.g. NAS SM) on behalf of other NFs.
• Providing a secure NAS connection (integrity protection, ciphering) between the UE and the 5GC, including for the transport of payload targeting other Network Functions (e.g. SMS, SMSF).
• Provide access control if applicable.

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:

• For transmission of SM signaling. The NAS‐MM layer creates a NAS‐MM message, including SM signaling and the corresponding PDU session ID, an indication that SM signaling is carried and finally a NAS security header.
• For reception of SM signaling. The receiving NAS‐MM processes the NAS‐MM part of the message, i.e. performs integrity check based on the NAS security header, and based on the indication that SM signaling is carried and on the PDU session ID, forwards the SM message to the relevant SM entity.

4.20.1.5 Control Plane Protocol Stack for Untrusted Non‐3GPP Access

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.

4.20.2 User Plane Protocol Stacks

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:

• Support MOBIKE [7] preserving the IKE association even though the UE has changed the local IP address, e.g. the UE is camping on a new WLAN access that has allocated a new IP address,
• Support of IP packet fragmentation.

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.

4.23.1 NG‐Radio Access Network (NG‐RAN)

A RAN that supports one or more of the following options with the common characteristics that it connects to 5GC:

1. 1) Standalone NR.
2. 2) NR is the anchor with E‐UTRA extension.
3. 3) Standalone E‐UTRA.
4. 4) E‐UTRA is the anchor with NR extension.

4.23.2 5G‐Access Network (5G‐AN)

An access network comprising of a NG‐RAN and/or Non‐3GPP AN connecting to a 5G Core Network.

4.23.3 5G Core (5GC)

The core network specified in 3GPP TS 23.501 [1]. It connects to a 5G Access Network.

4.23.4 5G System (5GS)

The 3GPP system consisting of 5G Access Network (AN), 5G Core Network (5GC) and UE.

4.23.5 Access Stratum (AS) and Non‐Access Stratum (NAS)

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.