Cloud Core Concepts

All
Technology Series

Issue Date 2025-04-16

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2025. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and
recommendations in this document are provided "AS IS" without warranties, guarantees or representations of
any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: [Link]

Email: support@[Link]
Technology Series

Contents
Contents...........................................................................................................................................................................................................1
1 5G Core Technology Series....................................................................................................................................................................2
1.1 Why Choose Cloud Native for 5G...............................................................................................................................................2
1.2 5G Core Network Architecture ....................................................................................................................................................8
1.3 Network Slicing Issue ...................................................................................................................................................................15
1.4 NFS Management..........................................................................................................................................................................26
1.5 Mobility Management Issue ......................................................................................................................................................30
1.6 QoS Issue ..........................................................................................................................................................................................35
1.7 Session Management ...................................................................................................................................................................48
1.8 CUPS & MEC Issue.........................................................................................................................................................................53
1.9 Security Architecture.....................................................................................................................................................................62
1.10 Security Procedure ......................................................................................................................................................................69
1.11 Container and Container Management...............................................................................................................................74
1.12 5G Core Services ..........................................................................................................................................................................86
1.13 5G Core Charging........................................................................................................................................................................93
1.14 UPF Selection Issue ..................................................................................................................................................................100
1.15 SMS Issue.....................................................................................................................................................................................107
1.16 IPv6 Issue .....................................................................................................................................................................................119
2 SVC Technology Series .......................................................................................................................................................................125
2.1 Why Single Voice Core (SVC)?................................................................................................................................................125
2.2 Single Voice Core Solution .......................................................................................................................................................139
2.3 Key Technologies of Single Voice Core................................................................................................................................148
2.4 Core NEs of Single Voice Core: AS.........................................................................................................................................156
2.5 Core NEs of Single Voice Core: SBC ......................................................................................................................................167

2025-04-25 1
Technology Series

1 5G Core Technology Series

1.1 Why Choose Cloud Native for 5G
• Forewords

• A Vision on the Future of 5G

• IT System Architecture Evolution

• Key Cloud Native Technologies in 5G

Forewords

Cloud Native has become one of the most heard concepts when people talk about 5G, but what is Cloud
Native? How does Cloud Native benefit IT applications? Why is Cloud Native a must for 5G? This section
will answer these questions and walk you through the key technologies involved in Cloud Native.

A Vision on the Future of 5G

Mobile communications have profoundly changed how we live, yet our pursuit of a mobile system with
higher performance has never stopped. The 5th generation (5G) mobile communications system has
arrived to accommodate the explosive growth of mobile data traffic, massive connections to devices, and
constant emergence of new services and applications.
5G will penetrate into every aspect of future society and bring us flexible and differentiated user
experience, realizing the vision of 5G, "information a finger away, everything in touch." A fully connected
society is expected in the near future.

The next generation network needs to be capable of agile service launch to quickly respond to and satisfy
new demands from a wide range of customers and vertical industries. 5G features flexible & diversified
service scenarios and short time-to-market (TTM), which is highly identical to the IT usage scenarios. After

2025-04-25 2
Technology Series

years of polishing and evolution, IT network architecture has been made agile and flexible enough to cope
with the requirements.
It is quite reasonable to take the successful practices in IT and use them on 5G networks to address the
service challenges. The foundation of these successful practices is to have a cloud native design. Now, let's
start with the IT architecture evolution to unveil the answer to the question "why do we need cloud
native?"

IT System Architecture Evolution

The IT industry has undergone significant development and overcome a lot of challenges, such as how to
ensure stability while keeping up with or even leading service trends. The story of how company X
addresses this challenge is used to reflect on how the IT system architecture has evolved.
Company X has a successful service. Let's name it service A. They are about to launch another service,
service B. Service B inherits some basic functions from service A, such as membership management,
inventory management, and transaction management. At this point of time, copying service A's code and
making some changes is a reasonable choice. Later however, with the growth of their business, they find
that maintenance and integration have become a challenge. Take modifications on the code for
transaction management for example. The team for service A needs to make the modifications and the
team for service B has to do the same thing. Besides the redundant work and wasted time, there is a risk
of inconsistency between their code and the results. To address this issue, the company starts refactoring
the code. Common and basic functions are abstracted and decoupled from the original code to form a
service-based architecture.
Under the refactored architecture, a modification on transaction management needs to be done only once
and can be synchronized to all of its upper-layer applications. This greatly improves the response efficiency
and shortens the TTM.
The following figure shows how an IT application architecture is refactored to decouple the front-end
applications and back-end databases.

Practices in the IT industry have proven that large-scale distributed software architecture is the key to
address the challenge of quicker response and shorter TTM. This architecture is exactly what a cloud native
design aims for.

• Stateless Design: The service processing units (applications) and storage (back-end database) are
separated. Service status and session-related data are no longer handled by the service processing

2025-04-25 3
Technology Series

units. Instead, they are saved in an independent database at the back end. Such a stateless design
enables service processing units to maximize their elasticity against traffic burst. If a service processing
unit fails, the system can quickly obtain the data and statuses of involved sessions (including ongoing
ones) and start recovery measures immediately, ensuring service continuity.

• Distributed storage: Files are replicated and saved in multiple devices. Data loss due to single point
failure is avoided.

Distributed storage servers share loads, improving system reliability, availability, and read/write efficiency.
Distribution also makes storage expansion much easier.

• (Micro) service decoupling: A service or module decoupled from its original system can either be
deployed independently or together with other services or modules, increasing flexibility and
shortening the TTM.

• Lightweight virtualization (container): In the new architecture, an application is broken down into
smaller service modules, which require lightweight hosts. Containers are a good choice to host the
service modules. Introducing containers accelerates service deployment and capacity expansion.

Compared with traditional virtualization technologies, containers have no overhead for virtualizing
hardware and running an operating system. Systems using containers have higher resource utilization and
faster startup speed.
A traditional virtual machine usually takes several minutes to start an application. A container can start the
same application in seconds or even milliseconds, because containers run on a host kernel and do not need
to launch the whole operating system. This greatly reduces the time for development, tests, and
deployment.

Cloud Native is a profound concept, using a series of IT technologies and management measures in
processes and organization. The following figure is an abstracted illustration. The next section will focus on
the key technologies mentioned in the figure.

2025-04-25 4
Technology Series

Key Cloud Native Technologies in 5G

In previous sections, we learned how IT systems evolved to cloud native, but the question of why cloud
native is essential to 5G is yet to be answered.
We have talked about the challenges that the IT industry has faced and how these challenges drove an
evolution in software architecture. The challenges we are facing in building 5G are quite similar to those of
IT. We can start by standing on others' shoulders.
Cloud native suits 5G service scenarios. 5G is going to support a wide variety of services that have different
quality assurance requirements. To suit these requirements, a 5G system must be flexible in determining
the granularity of resources to be provided. Cloud native gives a 5G system the flexibility to provide
resources with virtual machines (VMs), containers, or even microservices. Breaking down resources within a
container into microservices makes small-scale replacement easier, upgrade smoother, and dynamic
upgrade possible.
Cloud native makes service implementation more flexible. Common resources, such as databases, load
balancers, and microservices, can be assembled flexibly based on the type of service to be implemented.
Cloud native meets the requirements for flexible function assembly on the 5G application layer. 5G
standards have defined how functions, such as authentication, access control, and QoS assurance, shall be
assembled for different service scenarios. (We'll talk more in following sections.) Only with flexible
application assembly and implementation can the system deliver flexible and differentiated services to
various scenarios.
We have answered the question of why cloud native is essential to 5G. Now, let's take a look at how cloud
native technologies in the IT industry are applied in 5G.

• Stateless design
Service processing, storage, and data forwarding are completely decoupled. Compute nodes no longer
save user status and focus only on processing signaling. Service processing units are put at the front

2025-04-25 5
Technology Series

end, forwarding packets and distributing data layer loads. After the decoupling, the VNF architecture
is reformed to three layers: service processing units, distributed data storage, and distributed load
balancers.

The reformed architecture ensures service continuity. When a service processing unit fails, signaling is
forwarded to other functioning service processing units by load balancers. The backup service
processing units obtain user status information from the backend database and continue to handle
the signaling. The architecture also enables a newly added service processing unit to obtain user
status from databases and to handle service messages of users in the initial or intermediate state.

• Distributed storage
The data service deploys several instances to save data backups in a distributed manner. Such a design
can handle concurrent read/write transactions and provide tolerance against multi-point failures. The
following figure illustrates distributed storage.

• (Micro-) service decoupling

For 5G core, monolithic application architecture is broken down into independent service modules,
which are loosely coupled and communicate with each other via open APIs. The service governance
framework automatically manages service registration, discovery, and orchestration. Service modules
can be flexibly assembled and upgraded independently, speeding up TTM.
The following figure illustrates the software-based architecture (SBA) that the 3GPP standards defined
for 5G.
SBA defined by the 3GPP

2025-04-25 6
Technology Series

SBA and LEGO-style assembly answer the needs for flexible and differentiated 5G services.

• Agile infrastructure (lightweight virtualized container)

Learning from IT practices, telecommunications network designers have broken down monolithic
applications into service modules. Containers have become their virtualized hosts. Compared with
VMs, containers are more lightweight, consume less resources, and have better flexibility, making
service rollout and capacity expansion much faster.
The following figure shows the options that a carrier can select based on their service scenarios. They
can choose to deploy infrastructure with VMs, containers, or both.

• Automated life cycle management

With the introduction of stateless design, decoupled (micro-) services, and new infrastructure resource
isolation technologies (such as containers), it is inevitable that network management becomes much
more complex. More objects (service modules) are to be managed. Mappings between applications
and their supporting infrastructure resources are much more complex. Service modules have shorter
life cycle and more frequent releases, launches, updates, and status reports; and thus require more
intensive management.
Human maintenance is obviously not efficient enough for what's coming. Automated maintenance
capabilities, tools, and platforms have become essential to keep a network running and well
maintained during its life cycle. In addition, the O&M system shall have the capabilities to aggregate
complex information and to present only the meaningful service-oriented information to users, not
microservice information. Users care about services, not how services are implemented within the
system. Users shall not bear the increase of complexity (on configurations, alarm handling, and more)

2025-04-25 7
Technology Series

caused by service decoupling. Last but not least, the O&M system must be able to manage the
network in a closed-loop manner. To be specific, the O&M system should be able to identify issues
based on service running status and big data analysis results, trigger automated countermeasures, and
confirm their results. An automated, continuous, and highly efficient O&M mechanism is to be
expected.

1.2 5G Core Network Architecture

• Forewords

• SBA Network Architecture

• SBA Highlights

Forewords

As mentioned before, 5G will penetrate into various fields of future society, and these fields have different
requirements on the network. For example, smart home, grid, agriculture, and stopwatch require a large
number of extra connections and frequent transmission of small data packets; autonomous driving and
industrial control require the latency to be reduced to milliseconds and the reliability to approach to 100%;
entertainment information services require fixed or mobile broadband connections. To meet these
requirements, the 5G network must have a more flexible architecture.
However, NEs defined by 3GPP are complex, their functions may overlap, and a control function
combination cannot be tailored for a specific service type. Therefore, all services share a set of logical
control functions, and tight coupling between control functions and the complexity of inter-NE interfaces
bring great difficulties to service rollout and network O&M. This lack of flexibility cannot provide full
support for the evolution to 5G networks in multi-service scenarios.

Figure 1 Tight coupling between 4G NE functions

2025-04-25 8
Technology Series

SBA Network Architecture

To enable the 5G network architecture to serve a diverse range of services in the future, experts in the
industry have transformed the architecture in the following two aspects based on the Cloud Native concept
in the IT field:
NFS: Control plane functions are abstracted into multiple network function services (NFSs), aiming to build
networks through softwarization, modularization, and service based architecture (SBA). CUPS: The user
plane functions are decentralized, making them to be flexibly deployed on the core network or deployed
close to the access network (AN) where subscribers access.

NFSs are decoupled from each other and provide service based interfaces (SBIs). The same interface can be
used to provide services for other invokers, and multiple coupling interfaces are converted into a single SBI,
reducing the number of interfaces. This architecture is referred to as SBA.
SBA architecture towards Cloud Native brings the following advantages:

• Modular design for customizability: Each 5G software function is defined by microservices so that the
5GC network can be customized and orchestrated using NFSs in different scenarios.

• Lightweight design for scalability: SBIs are compliant with the Internet protocol and interact through
the application programming interfaces (APIs) that can be flexibly invoked. Network configurations
and signaling overhead are reduced, and a unified external interface is provided for capability
exposure.

• Independent NFSs for upgradability: Independent deployment and A/B tests of microservices are
supported so that network functions (NFs) can be quickly upgraded and new functions can be
introduced. NFSs can be quickly deployed and elastically scaled using the virtualization platform.

SBA Highlights

The design concept of 5GC is Cloud Native. It uses network functions virtualization (NFV) and software-
defined networking (SDN) technologies to enable control plane functions to interact with each other using
NFSs.
These NFSs are deployed on a shared and orchestrated cloud infrastructure, and are then designed to cater
for the diverse services required on the network. The figure below shows the highlights of the 5GC network

2025-04-25 9
Technology Series

architecture. Stateless NFSs have been introduced in previous sections. CUPS and network slicing, as key
solutions, will be introduced later. This section focuses on NF decoupling, SBIs, and network self-discovery
and autonomy.

• NFs are decoupled and abstracted into independent NFSs.

On the EPC network, the PCRF, MME, and S-GW/P-GW have control over QoS. When a mobile
subscriber is activated, QoS parameters are determined through negotiation. On the 5GC network, the
QoS control function is modularized into the policy control function (PCF). For example, the session
management function (SMF) modularizes the session management functions of the MME, S-GW, and
P-GW. On the 5GC network, NFs are decoupled and abstracted into independent NFSs that support a
variety of network applications.
As shown in the following figure, different colors are used to show the function mapping between EPC
NEs and 5GC NFs.

Figure 2 Mapping between EPC NEs and 5GC NFs

NF Function Description Mapped EPC NE

Access and Supports registration, connection, Mobility management function in the

mobility reachability, and mobility MME
management management. Provides a channel for
function (AMF) exchanging session management

2025-04-25 10
Technology Series

NF Function Description Mapped EPC NE

messages between a UE and the SMF,

and serves as the access point on the
control plane of the core network for
UEs and (R)AN.

Session Provides the session management, Control plane functions, such as session
management tunnel maintenance, IP address management in the MME+S-GW+P-GW
function (SMF) allocation and management, UP
function selection, policy
enforcement, QoS control, charging
data collection, roaming, and other
functions.

Authentication Serves as an authentication server to Authentication function in the MME and

server function authenticate 3GPP and non-3GPP authentication data management in the
(AUSF) access. HSS

User plane Provides user plane functions such as SGW-U/PGW-U

function (UPF) packet routing and forwarding, policy
enforcement, traffic reporting, and
QoS processing.

Policy control Provides a unified policy framework PCRF

function (PCF) and policy rules for control plane
functions.

Unified data Provides unified data management, HSS+

management 3GPP AKA authentication, user
(UDM) identification, access authorization,
registration, mobility, subscription,
and SMS management.

Network Provides a new function for None

repository registration and discovery. It enables
function (NRF) NFs to discover and communicate
with each other through APIs.

Network slice Selects a network slice instance for a None

selection function UE to access, according to the UE's
(NSSF) network slice selection assistance
information (NSSAI), subscription
data, and other information.

NEF (Network Securely exposes NF capabilities and None

Exposure converts internal and external
Function) information.

2025-04-25 11
Technology Series

On the 5GC network, the control plane functions are decoupled, and the same functions are
aggregated as NFSs. After decoupled network functions are abstracted as NFSs, they can be
independently scaled, evolve, and be deployed on demand.

• SBIs
In SBA architecture, traditional point-to-point communication is no longer used. Each NF on the
control plane uses the service based interface (SBI) serial bus interface protocol and the TCP protocol
at the transport layer. They carry different service messages at the application layer, as shown in
Figure 3.

Figure 3 SBI serial bus interfaces

The interface on each NF is an SBI, that is, the Nxxx interface (such as Namf and Nsmf) mentioned
above. This is referred to as bus communication.
In practice, the bus is one or more routers. Different from the DRA in the EPC network, the DRA in the
5GC network is aware of 3GPP protocols, for example, the DRA can forward 3GPP-defined messages
based on the number segment and subscription data. However, the control plane bus in 5G SBA
architecture only forwards messages based on the router L3/L4 protocol, without being aware of
upper-layer protocols.

Figure 4 Communication between SBIs

3GPP provides two types of reference points for 5GC:

• Reference point based on SBI, for example, an interaction relationship between control plane NFs.

• Reference point based on traditional point-to-point communication, for example, an interaction

relationship between an NF and a wireless network or an external data network (DN).

To help understand these interactions, 3GPP also provides an architecture in which a traditional
topology is used, as shown in Figure 5. On the control plane, the SBI-based reference points, such as

2025-04-25 12
Technology Series

N11, N12, and other below illustrated red lines, are used. When control plane functions are connected
to the UPF, 5GC, (R)AN, and DN, the reference points based on traditional point-to-point
communication are still used, such as the illustrated N1, N2, and the other blue lines.

Figure 5 Reference point architecture of 5GC

5GC inherits and decouples the core functions of mobility management, session management, and
data transmission to make 5GC more flexible, exposable, and scalable for application in different 5G
scenarios.

• The NRF automatically discovers NFSs, facilitating automatic deployment and agile network.
NF Splitting
For refined management, 3GPP defines NFSs that each NF provides for the control plane. End-to-end
mobile network signaling processes, such as registration, session management, mobility management,
authentication, and key negotiation are implemented using different NFSs.
Each NFS is autonomous. For example, the AMF contains four NFSs (as shown in Figure 6) to
implement access control and other functions.

Figure 6 NF splitting

Automatic NFS management

Each NF has possibly dozens of NFSs, and this may increase in the future. It is difficult for
maintenance personnel to maintain large amounts of NFSs. Therefore, 3GPP defines the network
repository function (NRF), which is responsible for automatic NFS management, including registration,
discovery, and status detection. After being powered on, an NF reports its NFS information to the NRF
and discovers the peer NFS through the NRF.
Figure 7 uses the establishment of a PDU session as an example to describe how the NRF uses
different NFSs to provide services.
After the AMF and SMF are powered on, they actively register with the NRF. The NRF saves the AMF
and SMF information and marks them as available. When the NFSs provided by the AMF or SMF

2025-04-25 13
Technology Series

change or the NFSs are no longer provided, the AMF or SMF requests the NRF update or deregister
the NFSs.

Figure 7 NF/Service registration and update procedure

After receiving a session establishment request from the UE, AMF-1 requests the NRF to discover the
SMF. The NRF queries for the locally maintained NF information, selects SMF-1, and sends SMF-1
information to AMF-1. After obtaining SMF-1 information, AMF-1 invokes the corresponding service
through the SBI to establish a PDU session.

Figure 8 NF/Service discovery

Network Communication Path Optimization

There are fixed communication links between traditional NEs. In SBA architecture, each NFS can
communicate with each other as required. The following uses the subscriber location information
policy as an example. The PCF subscribes to subscriber location change events in advance. The PCF
can promptly receive the event through an NFS in the AMF, which detects the location change and
notifies the PCF. This reduces the intermediate forwarding on the traditional network and optimizes
communication paths.

Figure 9 Comparison of 4G and 5G network communication paths

2025-04-25 14
Technology Series

1.3 Network Slicing Issue

• Forewords

• Why Does 5G Introduce Network Slicing?

• What Is Network Slicing?

• Network Slice Management System

• 5GC Slice Service Capability

• Network Slice Deployment Process

• Network Slice Selection

Forewords

Networking slicing is the most widely discussed technology in 5G networks. Many carriers and equipment
vendors believe that network slicing is the ideal network architecture for the 5G era. What is network
slicing? How are network slices deployed? How do we select a slice network? This section will bring you a
step-by-step understanding of network slicing.

Why Does 5G Introduce Network Slicing?

5G ushers in a new era of Internet of Everything (IoE) by supporting enhanced Mobile Broadband (eMBB),
Massive Machine Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication
(URLLC), three scenarios incorporating diversified and differentiated applications.

2025-04-25 15
Technology Series

• eMBB: Based on the breakthroughs in spectrum utilization and spectrum bandwidth on the R(AN), 5G
will be 10x faster than 4G. For example, the 4G transmission rate cannot meet the service
requirements for popular AR/VR and HD video broadcast services. Only 5G's significantly faster speeds
can be used. Currently, when using VR to watch HD videos or interactive games, you must use wired
communication. In the future, you will immerse yourself in VR/AR services by using 5G wireless
connections.

• By using multi-user remote access, ultra-dense heterogeneous networks, and other technologies, 5G
enhanced Machine Type Communication (eMTC) can support a maximum of 1 million devices per
square kilometer, which may be 10 times that of 4G. With the rapid development of smart cities,
public facilities such as street lamps, manhole covers, and water meters have network connections and
can be remotely managed. However, 5G will be more innovative. With 5G massive connectivity, public
facilities in cities can be connected to the intelligent management platform and collaborate with 5G
networks. Only a small number of maintenance personnel are required to uniformly manage them,
greatly improving the efficiency of city operation.

2025-04-25 16
Technology Series

• URLLC: The most typical application for 5G is autonomous driving. In common scenarios of
autonomous driving, such as emergency braking, vehicle to vehicle, vehicle to human, and vehicle to
infrastructure, a large amount of data needs to be processed and decisions are made instantaneously.
Therefore, the 5G network must have ultra-high bandwidth, ultra-low latency, and ultra-high
reliability.

In the 4G era, a network fits all application scenarios and customer groups by adding related features, and
meeting increasing customer requirements. For example, enable NB-IoT features on NEs to provide NB-IoT
capabilities for networks. Add NE device-level redundancy to build network reliability.
However, services in the vertical industry are far and unpredictable in terms of latency, number of
connections, reliability, and security. For example, AR services require an ultra-high bandwidth of 1600
Mbit/s, and energy meter reading services require massive connections, autonomous driving requires
millisecond-level E2E low latency and high reliability of 99.999% or higher. It is impossible to meet all
current and future requirements through current LTE networks.
Network slicing enables carriers to almost literally slice a network into multiple virtual E2E networks on
the same hardware infrastructure to allocate resources as required and flexibly combine capabilities. This
meets various requirements in different industries and service scenarios. When new requirements are
raised but the network cannot meet the requirements, carriers only need to virtualize a new slice network
without affecting the existing network slice to launch services as soon as possible.

What Is Network Slicing?

Network slicing is a technology that allows multiple logical networks with functionality specific to the
service or customer over a common network infrastructure. Figure 1 shows the 5G network slicing
architecture. After purchasing physical resources, carriers use physical resources to virtualize an eMBB slice
network for network services and an mMTC slice network for smart meter reading. The two slice networks
provide services for two different service scenarios.

Figure 1 Definition of network slicing

2025-04-25 17
Technology Series

Although various applications in vertical industries have various requirements for network functions, such
as network bandwidth, number of connections, delay, and reliability. These can all be solved by 5G. The 5G
standard classifies network function requirements of different services into three use cases. The
corresponding network slice types are eMBB slices, mMTC slices, and URLLC slices.

Figure 2 Three typical use cases

Services of different 5G industries can be carried by different slice networks. Even different vendors that
provide the same services can serve as tenants of the slice network to purchase, manage, and operate their
slice networks to provide communication services for their customers. As shown in Figure 3, car makers A
and B can subscribe to URLLC network slices provided by carriers and use different network slice instances
(NSIs) to provide communication services for their customers, achieving real-time and reliable connections
between cars and remote platforms. A tenant of a network slice may also be another carrier. The carrier
does not establish its own networks, and directly uses subscribed slice networks, and provides
communication services for the customers in a certain scope.

Figure 3 NSIs

2025-04-25 18
Technology Series

Network slicing enables carriers to almost literally slice a network into multiple virtual E2E networks on
the same hardware infrastructure. Each network slice is logically isolated from end to end, including radio
access network (RAN), transport networks (TNs), and core networks (CNs).

Figure 4 E2E network slicing

In a word, network slicing has three characteristics: On-demand customization, E2E, and isolation. It can
deploy network services on demand (with a customized location and specifications) from end to end, and
ensure that slices run independent of each other. Life cycles of slices are independently managed.

Figure 5 Three characteristics of network slicing

Network Slice Management System

A slice is an E2E network. A new unified orchestration and management system must be introduced to
support fast deployment, collaborative work, and full-life cycle management of slices. The new

2025-04-25 19
Technology Series

management system must support on-demand network slice customization, automatic slice deployment,
E2E slice monitoring and collaboration, and intelligent O&M of slices.

Figure 6 Network slice management architecture

As shown in Figure 6, network slice management functions, such as Communication Service Management
Function (CSMF), Network Slice Management Function (NSMF), and Network Slice Subnet Management
Functions (NSSMF) defined in protocols, form a management system to implement end-to-end network
slice collaboration and life cycle management across the (R)AN, TN, and CN. Table 1 shows the
responsibilities of CSMF, NSMF, and NSSMF.

Table 1 Network slice management

Network Slice Description

Management

CSMF Converts service requirements related to communication services into network slicing
requirements.

NSMF Manages and orchestrates network slice instances (NSIs) and derives network slice
subnet instance (NSSI) requirements from network slicing requirements.

NSSMF Manages and orchestrates NSSIs.

Figure 7 shows the service flow of network slice life cycle management. The slice management system
provides tenants with a website portal for subscription to the communications service. Service attributes
include bandwidth, latency, number of connections, mobility, reliability, and coverage. The CSMF, NSMF,
NSSMF, and MANO collaborate with each other to deploy network slices that meet tenant service
requirements and perform management and O&M.

Figure 7 Network slice life cycle

2025-04-25 20
Technology Series

5GC Slice Service Capability

To fit eMBB and fixed wireless access (FWA) in early commercial scenarios defined by 3GPP specification,
Huawei 5GC provides two types of slices: UeMBB and FWA. These eMBB slices defined by protocols.
UeMBB slices are used to provide AR, VR, and HD video services. FWA slices are used as a supplement to
fixed broadband in densely-populated urban areas or are used to provide last-mile coverage. It provides
services for HD IPTV and VoIP services. Figure 8 shows the characteristics of the two slice types. Generally,
carriers must deploy UeMBB slices, and FWA slices are optional as required.

Figure 8 Network slices supported by 5GC

Network Slice Deployment Process

After purchasing physical resources, carriers need to deploy slice networks based on tenant requirements.
Tenants provide communication services for customers on the slice networks, and then manage and
operate the slice networks. Figure 9 shows the process of deploying NSIs.

Figure 9 NSI deployment process

2025-04-25 21
Technology Series

When designing a slice template, a carrier can directly use the basic slice template provided by the vendor
or create a customized slice template with different specifications by customizing the basic slice template.
When subscribing to a slice, a tenant needs to submit service requirements, such as the service area,
charging mode, isolation, and SLA parameters. Carriers can deploy NSIs in one-click mode based on
parameters in the slice template or customize NSI deployment based on new network planning
parameters.

Network Slice Selection

Relevant Concepts

• S-NSSAI
Single Network Slice Selection Assistance Information (S-NSSAI) identifies a network slice. According
to carriers' operations or deployment requirements, one S-NSSAI can be associated with one or more
NSIs, and one NSI can be associated with one or more S-NSSAIs. As shown in the figure below, the S-
NSSAI values for UeMBB slices 1 and 2 are both 0x01000000. eMBB+mMTC slice 4 can provide both
eMBB and mMTC services, so it is a combination of eMBB and mMTC slices, with the S-NSSAI values
0x01000000 and 0x03000000, respectively.

Figure 10 Network slice and NSI

As shown in Figure 11, S-NSSAI consists of Slice/Service Type (SST) and slice differentiator (SD).

2025-04-25 22
Technology Series

• SST refers to the expected network slice behavior in terms of features and services. The standard
SST values are 1, 2, and 3. 1 indicates eMBB, 2 indicates URLLC, and 3 indicates Massive Internet
of Things (MIoT).

• SD is optional information that complements SST to distinguish multiple network slices of the
same SST.

The SST and the SD together indicate a slice type and multiple slices of a same slice type. For
example, S-NSSAI values 0x01000000, 0x02000000, and 0x03000000 indicate eMBB, URLLC, and MIoT,
respectively. S-NSSAI values 0x01000001 and 0x01000002 indicate eMBB slices that serve subscriber
groups 1 and 2.

Figure 11 S-NSSAI structure

• NSSAI
Network Slice Selection Assistance Information (NSSAI) is a collection of S-NSSAIs. The NSSAI used on
the 5GC network can be requested NSSAI, allowed NSSAI, and configured NSSAI. The S-NSSAI used on
the 5GC network can be subscribed S-NSSAI, default S-NSSAI, and rejected S-NSSAI. For the detailed
definitions, see Table 2 and Table 3.

Table 2 NSSAI definition

NSSAI Definition

Requested The requested NSSAI is sent by the UE to the network upon registration. There can be at most
NSSAI eight S-NSSAIs in a requested NSSAI.

Allowed NSSAI The allowed NSSAI is sent by the serving PLMN to a UE during the registration procedure. The
allowed NSSAI indicates available NSSAI values in the current registration area for the serving
PLMN of an access type. There can be at most eight S-NSSAIs in an allowed NSSAI and they
are stored locally on the UE.

Configured The configured NSSAI is applicable to one or more PLMNs. The AMF delivers the configured
NSSAI NSSAIs to the UE in the registration accept or configuration update command. A maximum of
16 S-NSSAIs are stored locally.

default The default configured NSSAI is configured by the UDM in the UE's home PLMN through the
Configured UE Parameters Update procedure. It is considered as the default network slice set that can be
NSSAI used across PLMNs.

2025-04-25 23
Technology Series

Table 3 S-NSSAI definition

S-NSSAI Definition

Subscribed S- The subscribed S-NSSAIs are subscribed to by a UE in their home PLMN. One or more of them
NSSAI can be set to the default S-NSSAIs. A UE can subscribe to a maximum of eight default S-
NSSAIs.

default S- The default S-NSSAI is used when a UE does not deliver the requested NSSAI to the network.
NSSAI It can be one or more S-NSSAIs in subscribed slices.

Rejected S- The rejected S-NSSAI is sent by the AMF to a UE if the UE-requested NSSAI is not accepted by
NSSAI a network.

• NSSP
The PCF delivers the Network Slice Selection Policy (NSSP) as a part of the UE Route Selection Policy
(URSP) rule to the UE through the AMF. The UE uses the NSSP rules to associate the app ID with the
S-NSSAI, as shown in Figure 12.

Figure 12 NSSP

Slice Selection - Registration

In the registration procedure, the (R)AN selects an initial AMF for a UE, according to the local storage
information and the UE registration request message, to provide services for the UE. However, the initial
AMF may not support the network slice requested by the UE. For example, the initial AMF supports only
the FWA network slices, but the UE requests a UeMBB network slice. If the initial AMF cannot provide
services for the UE, the initial AMF queries for and selects the target AMF that supports the UE-requested
network slice from the NSSF, and then directly or indirectly sends the registration request message from
the UE to the target AMF. The target AMF processes the registration request and then provides a network
service for the UE.

Figure 13 Slice selection in the registration procedure

2025-04-25 24
Technology Series

1. When a UE registers with a PLMN through an access type, the UE sends a Registration Request
message to the (R)AN. If the UE stores the configured NSSAI of the PLMN or the allowed NSSAI of
the access type of the PLMN, the UE carries the requested NSSAI in the NAS Registration Request
message and the AN message. The requested NSSAI includes the S-NSSAI of the UE-requested slice.

2. The (R)AN selects the initial AMF based on globally unique AMF ID (GUAMI) or requested NSSAI. If
the UE does not provide the requested NSSAI and GUAMI in the AN message, the (R)AN sends the
Registration Request message from the UE to the initial AMF.

3. The initial AMF queries the UDM for UE subscription data including the subscribed S-NSSAIs. The
initial AMF determines whether it can provide services for the UE, according to the received
requested NSSAI, subscribed S-NSSAI, and local configuration. If the initial AMF can serve the UE, it
is the serving AMF. It constructs the allowed NSSAI based on the subscribed S-NSSAI and the
requested NSSAI and returns the allowed NSSAI to the UE through a registration accept message. If
the initial AMF cannot provide services for the UE or cannot make a judgment, the AMF needs to
query the NSSF for the target AMF.

4. Query parameters include the PLMNs and TAIs of the requested NSSAI, subscribed S-NSSAI, and
SUPI.

5. The NSSF selects an AMF set or a candidate AMF list that may serve the UE, and an allowed NSSAI
of the access type. It may further select an NSI serving the UE, and an NRF used to select an NF in
the instance. These are selected according to the received information, and local configuration. This
information is sent to the initial AMF after selection.

6. If the initial AMF is not in the AMF set or the AMF address is unavailable in local information, the
initial AMF obtains the candidate AMF list by querying the NRF. The NRF returns a group of
available AMF lists, including AMF pointer and address information. The initial AMF selects an AMF
as the target AMF. If the initial AMF cannot obtain the candidate AMF list by querying the NRF, the
initial AMF needs to send the Registration Request message for the UE to the target AMF through
the (R)AN. The message includes the AMF set and the allowed NSSAI.

7. If the initial AMF directly sends the NAS message to the target AMF based on the local policy and
the subscription data, the initial AMF sends the Registration Request message and other information
except for the AMF set obtained from the NSSF to the target AMF.
If the initial AMF determines to forward the NAS message to the target AMF through the (R)AN
based on the local policy and subscription information, the initial AMF sends a Reroute NAS message

2025-04-25 25
Technology Series

to the (R)AN. The Reroute NAS message includes the target AMF set information and the
Registration Request message, and the related information obtained from the NSSF.

8. After receiving the registration request message sent in step 7, the target AMF continues the
registration procedure, and finally sends UE a registration accept message containing the allowed
NSSAI.

1.4 NFS Management

• Forewords

• NFS registration, update, and deregistration

• NFS Discovery

Forewords

The 5GC uses the service based architecture (SBA) to simplify and abstract control plane functions into
network functions (NFs). For example, the AMF is responsible for access and mobility management, and
the SMF is responsible for session management.
Just as a person can have multiple skills, such as requirement analysis, coding, testing, documentation
development, and project management, each NF can be deployed with multiple capabilities. These
capabilities are provided by network function services (NFSs). NFSs are carried by NFs.
AMFs are used as an example. Some AMFs provide only the Namf_Communication NFS, which supports
only UE access and mobility management; some AMFs provide the Namf_Communication and
Namf_Location NFSs, which support UE access and mobility management and provide UE location
information for other NFs. The following table lists the NFSs supported by the AMF and SMF. For details
about NFSs in other NFs, see section 5.2 in 3GPP TS 23.502.

Table 1 NFSs supported by the AMF and SMF

NF NFS Description

AMF Namf_Communication Used by an NF to communicate with a UE or (R)AN.

Namf_EventExposure Allows other NFs to subscribe to or obtain mobility-related events and statistics.

Namf_MT Used to send MT signaling or data to a UE to ensure that the UE is reachable.

Namf_Location Used by an NF to obtain UE location information from the AMF.

SMF Nsmf_PDUSession Used by an NF to manage PDU sessions and to use policies and charging rules
received from the PCF.

Nsmf_EventExposure Used by an NF to expose the events occurring on PDU sessions to other NFs.

With the network evolution and continuous enhancement of product capabilities, the 5GC will provide
more NFSs. How can hundreds or thousands of these NFSs be managed? If engineers still rely on
traditional manual maintenance, it would be a disaster. Therefore, the NFSs of the 5GC must support

2025-04-25 26
Technology Series

automated management. An NRF is the key to NFS automated management. It maintains real-time
information about all NFSs in the entire network, similar to an NFS real-time warehouse.
The NRF supports the following functions:

• Automated registration, update, or deregistration of NFSs

• Automated discovery and selection of NFSs

The NRF supports NFS registration, update, and deregistration. These operations are initiated and
completed by an NF. During the registration, an NF sends all the information as the NF profile to the NRF.
Each NF profile has an NFS list. In this way, the NFS registration can be successful. When another NF
needs to use a service, it queries and discovers the NFS registered on the NRF. The NRF returns the
information about the NFS and its NF.

NFS registration, update, and deregistration

We know that upon enrollment of a new employee in a company, the company will generate personal
information, including the basic attributes (such as the name and employee ID), and the information about
the work department, competency and qualification, and appointed position, for the new employee. When
an employee changes his or her name or department, or gets promoted, the company updates the
employee's personal information. When an employee leaves the company, the company also deletes the
employee's personal information.
Similarly, after an NF is powered on, the NF proactively registers NF profile information with the NRF. NF
profile information includes the NF attributes and the supported NFSs. When any of the basic attributes of
the NF or the supported NFSs are changed, the NF automatically sends an update request to the NRF.
During graceful power-off (planned removal), the NF deregisters from the NRF, and the NRF deletes the
NF profile. Figure 1 shows NFS registration, update, and deregistration.

Figure 1 NFS registration, update, and deregistration

2025-04-25 27
Technology Series

The NF profile that an NF registers with the NRF contains NF attribute information, such as the NF
identifier, type, PLMN, and IP address, and information about NFSs supported by the NF. Figure 2 shows
the example information about the NF profile that the SMF registers with the NRF.

Figure 2 NF profile information

NFS Discovery

On a 5GC network, each NF can use an NRF to search for a proper service producer rather than a fixed
peer obtained from local configurations. The NRF returns available service information to the NF for
automated NFS discovery and selection based on the registered NF information. This mode is similar to the
DNS mechanism.
For example, to establish a PDU session, the AMF needs to invoke the Nsmf_PDUSession service operation
of the SMF to establish the context. However, before PDU session establishment, the AMF needs to request
the NRF to discover an SMF that can provide a service. Figure 3 shows the procedure for SMF selection by
the AMF.

Figure 3 SMF selection by the AMF

2025-04-25 28
Technology Series

1. A UE sends a PDU session establishment request message to the AMF. This message contains the
DNN and S-NSSAI.

2. The AMF queries the NRF for an available SMF. The query request contains the DNN, type of the
requester NF, requested PLMN, target NFS name, S-NSSAI, target NF type, and more.

3. If all the SMFs registered on the NRF support the nsmf-pduSession service, the NRF selects an
available SMF based on the DNN and S-NSSAI in the request and returns the SMF IP address and
endpoint information about the nsmf-pduSession service to the AMF, as shown in Figure 4.

Figure 4 SMF information returned by the NRF

2025-04-25 29
Technology Series

4. The AMF invokes the Nsmf_PDUSession service of the SMF to establish a PDU session.

5. The SMF initiates an N4 session establishment procedure towards the selected UPF.

6. The SMF notifies the AMF of the N2 session management information and the N1 session
management information.

7. The AMF sends an N2 PDU session request message to the (R)AN to request the (R)AN to allocate
the N3 tunnel access network address and radio resources.

8. The (R)AN forwards the PDU session establishment response to the UE. The PDU session is
established successfully.

1.5 Mobility Management Issue

• Forewords

• Involved NFs

• Mobility Management Objects

2025-04-25 30
Technology Series

• Mobility Management Procedures

• Mobility Restrictions

• Mobility Management Example

• Summary

Forewords

Mobile communication is evolving from 4G to 5G. The network architecture and service types have
changed greatly. 5G mobility management must adapt to changes in the network architecture and meet
diversified service requirements. This section describes 5G mobility management by comparing and
analyzing mobility management principles on 4G and 5G networks.

Involved NFs

We have learned that both the Access and Mobility Management function (AMF) in the 5G service based
architecture (SBA) and mobility management entity (MME) on a 4G network can provide the access and
mobility management functions. The following figure shows a comparison of 4G and 5G network
architecture.

The 5G system (5GS) architecture provides fixed mobile convergence (FMC) to allow the AMF to provide
services for both 3GPP and non-3GPP access networks, ensuring subscriber service experience. On a 4G
network, when a UE accesses a core network through an untrusted non-3GPP network, the UE is directly
connected to the gateway through the ePDG, and the UE is not connected to the MME for access and
mobility management. However, when the 3GPP and non-3GPP access networks used by a 5G UE belong
to the same PLMN, the same AMF can perform mobility management for the UE, providing seamless
mobility of the UE. The following figure shows the differences of 4G and 5G architectures over non-3GPP
access.

To provide FMC and improve subscriber experience, the 5G network allocates and uses the same
temporary identity for a UE on 3GPP and non-3GPP access networks, introduces UE connection
management status, and flexibly defines service request procedures. The following describes differences
between 5G and 4G networks.

2025-04-25 31
Technology Series

Mobility Management Objects

UE Identifiers
UE identifiers are involved when a network performs mobility management on a UE. The UE identifiers
used on a 5G network are as follows:

• Subscription permanent identifier (SUPI): An SUPI is globally unique and identifies a subscriber on the
entire network. An IMSI is used for 3GPP access, and a network access identifier (NAI) is used for non-
3GPP access.

• Permanent equipment identifier (PEI): A PEI is globally unique and identifies a device on a 5G
network.

• 5G-GUTI: A temporary identifier is allocated by the core network. It is used to prevent the
transmission of a permanent identifier on a network and prevent attackers from tracking the location
and activity status of the UE.

The following table compares UE identifiers between 4G and 5G networks.

Table 1 5G and 4G UE identifiers

Category 5G Identifier 4G Identifier

3GPP Non-3GPP 3GPP Access Non-3GPP

Access Access Access

UE permanent identifier SUPI NAI IMSI NAI

UE permanent equipment PEI N/A IMEI N/A

identifier

UE temporary identifier 5G-GUTI EPS GUTI N/A

<5G-GUTI> := <GUTI>:= <GUMMEI><M-
<GUAMI> <5G-TMSI> TMSI>

5G protocols optimize UE identity security. A network does not directly transmit an SUPI, but uses an
encrypted SUPI, that is, subscription concealed identifier (SUCI). The AMF can obtain an SUPI after a
security procedure is complete.
After 5G introduces network slicing, the format of the temporary identifier of a UE changes. When the UE
moves between the 5GS and E-UTRAN, the 5G-GUTI needs to be mapped to the EPS-GUTI or the EPS-GUTI
needs to be mapped to the 5G-GUTI according to the mapping shown in the following figure, and the
mapped EPS-GUTI or 5G-GUTI is sent to the AMF or MME in the corresponding message.
The following figure shows the comparison between 5G-GUTI and EPS GUTI.

5G GUTI introduces the AMF set ID. An AMF set comprises of AMFs that serve a particular region or the
same set of network slices. Each AMF region consists of one or more AMF sets. After 5G introduces the

2025-04-25 32
Technology Series

concept of network slicing, the AMFs in a region are divided into different sets according to the capability
to support network slicing. The AMFs in a set have the same capability (equivalent to a 4G MME pool).
UE Status
The mobility management is performed by a network for UEs in different manners according to UE states.
On a 4G network, UE status is classified into EPS mobility management (EMM) and EPS connection
management (ECM). On a 5G network, UE status is classified into registration management (RM) and
connection management (CM). The following figure shows the differences between the management
status of 4G and 5G.

The RRC Inactive state is added to 5G CM states so that a network can quickly recover a link when data
needs to be transmitted, and to meet power saving requirements for terminals. In this case, the (R)AN and
CN are still in the CM-CONNECTED state, and the signaling between the UE and (R)AN is released, as
shown in the following figure.

Mobility Management Procedures

In a mobile communications system, a UE or a mobile device is in a constantly moving state. The core
network needs to change the state of the UE according to the service condition of the UE, and ensure that

2025-04-25 33
Technology Series

the UE location information is obtained and data transmission continuity is ensured when the UE moves.
These functions need to be supported using a mobility management procedure.

Table 2 Differences between 4G and 5G mobility management procedures

5G Mobility Management 4G Mobility Management Function

Procedure Procedure

Registration Initial registration Attach The UE accesses a network.

Mobility registration TAU The network updates the TA and related

update parameters of the UE.

Periodic registration Periodic TAU The UE periodically updates the location.

update

AN Release S1-Release The UE enters the idle state.

Service request Service request The UE enters the connected state.

Handover Handover The UE in the connected state is successfully

handed over to a new cell.

Deregistration Detach The UE location information is deleted from

the network.

The mobility management procedure of 5G is similar to that of 4G. Some 5G procedures, such as the AN
release procedure and deregistration procedure, are similar to those of 4G. The only difference with these
procedures is the names. The other differences between mobility management procedures are as follows:

• The attach, TAU, and periodic TAU procedures on a 4G network are all provided using a registration
procedure on a 5G network. Only the registration types are different, namely, initial registration,
mobility registration update, and periodic registration update.

• Only some PDU sessions can be activated during a 5G service request procedure. When the UE is in
the connected state, the 5G service request procedure can also be used to activate certain PDU
sessions and establish user plane connections for data transmission.

Mobility Restrictions

Network mobility management must ensure that UEs are reachable and data transmission is continuous. In
addition, the UEs must be prevented from accessing certain restricted areas and requesting unauthorized
services. Mobility restrictions include the access restrictions and mobility restrictions of UEs. Mobility
restrictions are only used for 3GPP access.
4G mobility restrictions are enforced using some optional features. 5G protocols define multiple mobility
restrictions: forbidden area, RAT restriction, service area restriction, and core network type restriction.

• Forbidden area: In a forbidden area, a UE is prohibited from sending messages over the network.

• RAT restriction: It defines the RAT that a UE is not allowed to access.

2025-04-25 34
Technology Series

• Service area restriction: It defines the allowed areas or non-allowed areas. The UE can access a
network in the allowed area. The UE can initiate periodic updates and registration requests but cannot
initiate SR or any session-related signaling procedures in the non-allowed area.

• A service area restriction contains one or more complete TAs.

Mobility Management Example

The following figure shows the main procedures involved in the mobility management of UEs during the
daily use of UEs.

Summary

Compared with 4G mobility management, 5G mobility management has changed in terms of UE

identifiers, UE status, and management procedures to adapt to changes in the network architecture and
meet diversified service requirements.
A 5G network supports both 3GPP access and non-3GPP access, and the AMF provides access and mobility
management services. The UE uses a same temporary identifier in both 3GPP access and non-3GPP access,
and it contains AMF set information for network slicing. 5G mobility management inherits the 4G CM
status: idle and connected states, and also introduces the RRC Inactive state to the UEs to meet high power
saving requirements. Mobility management of 5G networks simplifies the management procedures. The
attach, TAU, and periodic TAU procedures are completed by a registration procedure on a 5G network, and
only the registration types are different.

1.6 QoS Issue

• Forewords

• Overview

• Data Paths

2025-04-25 35
Technology Series

• Service Packet Steering to Tunnels

• QoS Parameters

• QoS Control

• Summary

Forewords

With the advent of 5G, the architecture and services of mobile networks have changed greatly. New use
cases such as Internet of Vehicles (IoV), cloud AR/VR, high definition (HD) live streaming, and industrial
control have emerged, and pose higher quality of service (QoS) requirements for 5G.

• Enhanced mobile broadband (eMBB)

High speed, and dynamic bandwidth allocation are required. You can upload and download videos (of
several GBs in size) at a high speed, and dynamically allocate bandwidth to ultra-high-definition
(UHD) videos and VR/AR services.

• Ultra-reliable and low-latency communications (URLLC)

High reliability, high availability, and low latency are required. Mission-critical services, such as
automatic manufacturing and remote surgery, can run reliably. Delay-critical services such as
autonomous driving and unmanned aerial vehicle (UAV) remote control can meet their low-latency
requirements.

• Massive machine-type communications (mMTC)

Large-capacity is required to provide massive connections to more than 1 billion devices for IoT
services such as smart cities. The connection density can reach millions of devices per square
kilometer.

5G requires QoS to ensure ultra-high bandwidth, ultra-low latency, and ultra-high reliability. This chapter
describes the 5G QoS model based on the 4G QoS, including the QoS concept, QoS flow and mappings,
QoS parameters, and QoS control mechanism.

Overview

The purpose of QoS is to provide services with differentiated QoS when resources are insufficient. QoS has
two meanings. One is a group of QoS indicators or parameters. The other is the QoS mechanism, that is,
how to guarantee these indicators or parameters within a normal range.
If 5G data communication is regarded as a transportation system, the user plane is a road, and the service
data is a passenger or cargo transported on the road. Different service traffic can be transported through
different roads. For example, common roads are used for common vehicles, bus-only lanes are used only
for buses, and bus rapid transit (BRT) lanes are used only for BRT vehicles. The process of laying and
distributing roads as required by transportation services is similar to the signaling process in data
communications. Accordingly, QoS indicates whether materials are delivered to the destination within the
scheduled time, to meet customer requirements.

2025-04-25 36
Technology Series

Data Paths

In logistics, roads must be available before cargo can be delivered to the destination. Similarly, on a mobile
network, data paths, which are EPS bearers on a 4G network and QoS flows on a 5G network, are required
for service data transfer. For details about QoS flows, see [Link] "QoS Flow" in 3GPP TS 23.501.
A data path is the minimum granularity of end-to-end QoS control. That is, all data flows on the same
path are guaranteed with the same QoS (such as scheduling policy and buffer queue management).
Different QoS guarantees require different paths.

2025-04-25 37
Technology Series

As shown in the preceding figure, the end-to-end implementation of EPS bearer and QoS flow has the
following differences:
Item 4G 5G

Data path EPS Bearer QoS Flow

Identifier EBI(EPS Bearer ID) QFI(QoS Flow ID)

Category Default bearer Default QoS flow

Dedicated bearer Dedicated QoS flow

Implementation An EPS bearer needs to be mapped to different QoS flows involve only the bearers on
on each interface underlying bearers through different NEs and the (R)AN side and do not actually have
interfaces. The underlying bearers include radio an end-to-end bearer. In addition, a
bearers, S1 bearers, and S5/S8 bearers, as PDU session uses a common NG-U
shown in the preceding figure. They are in a tunnel, and a radio bearer maps to
one-to-one relationship. multiple QoS flows.

2025-04-25 38
Technology Series

Item 4G 5G

NE functions Each network node is responsible for The UE and (R)AN are responsible for
maintaining identifiers of underlying bearers maintaining data radio bearer (DRB) IDs
and the binding relationships between them. as well as the binding relationships
between DRB IDs and QFIs.

• The QoS flow decouples the CN from the (R)AN in terms of functions. That is, the 5G CN can adapt to various
access technologies such as fixed network access, and the (R)AN decides how to carry QoS flows over the air
interface.
• 3GPP does not clearly define the default QoS flow and dedicated QoS flow for 5G networks, but a similar
classification applies in practice. This chapter uses the default QoS flow and dedicated QoS flow for ease of
description.
• A QoS flow is the finest granularity of QoS differentiation in a PDU session, and is identified by a QoS flow ID
(QFI). QFIs shall be used for all PDU session types. QFIs are unique within a PDU session. QFIs may be
dynamically assigned or be equal to the 5QIs. For details, see clause [Link] in 3GPP TS 23.501.

Service Packet Steering to Tunnels

This section describes how to steer packets with different QoS requirements to established data tunnels.
During packet steering, the packet sender preferentially identifies a specific service that generates packets,
such as WeChat, Taobao, and Youku. The sender then steers packets to different data tunnels by service
type.

• Service Identification
On a TCP or IP network, a service flow (session) is identified based on whether packets match the
specified 5-tuple. On a 4G or 5G network, services are identified based on whether packets match the
packet filter (PF) (4G) or packet filter set (PFS) (5G).
A PF is the finest unit for identifying services and contains information, such as 5-tuple. A PFS is a set
of PFs.

PF parameters on 4G and 5G networks are different. For example, the PF on a 5G network does not
contain the priority, and certain parameters are also different in terms of details. For details about the
differences, see section 15.3.2 in 3GPP TS 23.060 for 4G PF parameters, and see section 5.7.6 in 3GPP
TS 23.501 for 5G PF parameters.

• Service Packet Steering

2025-04-25 39
Technology Series

Service identification aims to steer packets of different services to required data tunnels. To achieve
this, the packet sender must establish a mapping between PFs/PFSs and a tunnel ID. For details about
5G QoS flow mapping, see section [Link] in 3GPP TS 23.501.
4G and 5G networks use different service steering procedures due to their different mappings between
data tunnels and bottom-layer bearers, as shown in the following figure.

On a 4G network, the packet sender only needs to establish a mapping between packets and EPS
bearers, as there is a one-to-one mapping between bottom-layer bearers. However, on a 5G network,
there can be a one-to-many mapping between a radio bearer and QoS flows. Therefore, the packet
sender needs to establish not only a mapping between packets and QoS flows, but also a mapping
between QoS flows and radio bearers over the air interface. This way, packets can be associated with
QoS flows in an E2E mode on a 5G network.

To simplify route management, all QoS flows of one PDU session on a 5G network share an NG-U tunnel. To
distinguish between QoS flows to which packets transmitted over an NG-U tunnel belong, a UE and the UPF add a QFI
to the encapsulation header of a packet after completing QoS flow mapping. This is similar to using the line identifier
on a bus to distinguish between bus lines. For details, see sections [Link] and [Link] in 3GPP TS 23.501.

A mapping cannot be directly established, and instead requires a traffic flow template (TFT). Use mapping
establishment on a 4G network as an example. The UE or P-GW functions as a packet sender and identifies
the service generating packets, such as AliExpress or Facebook Messenger, in the figure below. The UE or
P-GW then maps the packet to an EPS bearer (bearer marked in yellow or orange in the figure) based on

2025-04-25 40
Technology Series

the uplink or downlink TFT associated with filters. A TFT is a set of filters associated with an EPS bearer
and has a one-to-one mapping with an EPS bearer.

On a 5G network, QoS rules on a UE and packet description rules (PDRs) on the UPF are similar to the
TFT. For details, see sections [Link] and [Link] in 3GPP TS 23.501. However, there can be a multiple-to-
one mapping between QoS rules/PDRs and a QoS flow on a 5G network, which is different from TFT
mapping on a 4G network.

The following table lists the differences between QoS mapping on 4G and 5G networks.
Category 4G 5G

Mapping principles One-level mapping Two-level mapping

Packets → EPS bearer mapping Packets → QoS flows → radio bearers

Characteristics Symmetry: The uplink and downlink Asymmetry: The uplink and downlink
process data in the same manner. process data in different manners.

2025-04-25 41
Technology Series

Category 4G 5G

NF for mapping UL UE UE
enforcement
DL P-GW UPF and (R)AN

Tool for association UL UL TFT QoS rule: multiple QoS rules <-> one
QoS flow
Mapping rules over the air interface

DL DL TFT PDR: multiple PDRs <-> one QoS flow

Mapping rules over the air interface

QoS Parameters

A transportation analogy is used for 4G QoS parameters. ARP indicates whether there are roads. QCI
indicates whether vehicles work properly. xBR indicates whether roads are wide enough. 5G QoS
parameters inherit the basic architecture of 4G QoS parameters. The difference is that the names and
descriptions of some parameters are modified and three optional parameters, such as Reflective QoS
Attribute (RQA), are added, as shown in yellow boxes.

• ARP: Are There Roads?

On 4G and 5G networks, allocation and retention priority (ARP) is used to identify the capability for a
service to obtain a path resource (mainly referring to air interface resources). This means that ARP is
used to control the priority of EPS bearer/QoS flow establishment and modification.
ARP has three parameters: priority level, preemption capability, and preemption vulnerability. The
priority level indicates the priority for creating a path. The preemption capability indicates whether
preempting resources of other paths is allowed during creation or modification of a channel. The
preemption vulnerability indicates whether the resources can be preempted by other paths. For
details, see [Link] "ARP" in 3GPP TS 23.501.

2025-04-25 42
Technology Series

• xBR: How Wide Is a Road?

In terms of service quality, bandwidth is always the biggest concern for end users and is the most
easily observed quality parameter. Bandwidth is classified into uplink bandwidth and downlink
bandwidth.
In terms of resource type, 4G/5G paths can be classified into guaranteed bit rate (GBR) paths and
non-GBR paths. The bandwidth guarantee for the two types of paths is different.

• For GBR paths, each path has its own bandwidth parameter, which defines the guaranteed
bandwidth or the possibly maximum bandwidth. For details, see [Link] "Flow Bit Rates" in 3GPP
TS 23.501.

• For non-GBR paths, the bandwidth is not guaranteed. Therefore, each path has its own
bandwidth parameter aggregate maximum bit rate (AMBR), which indicates the maximum
bandwidth used by a group of non-GBR paths. AMBR limits the total rate of all paths that share
the AMBR. Different aggregation granularities use different AMBRs. For details, see [Link]
"Aggregate Bit Rates" in 3GPP TS 23.501.
The following figure shows the bandwidth parameters of 4G and 5G networks.

Compared with 4G, 5G has the following changes:

2025-04-25 43
Technology Series

• GBR paths: The GBR and MBR parameters are renamed to the GFBR and MFBR parameters. Their
meanings are the same.

• Non-GBR paths:

• The name and meaning of UE-AMBR remain unchanged.

• APN-AMBR is changed to Session-AMBR, that is, the aggregation granularity is changed

from a 4G PDN to a 5G PDU session.

A 4G PDN is equivalent to a 5G data network (DN). A DN can have multiple PDU sessions. For details, see
"Session Management."

• 5QI: Do Vehicles Work Properly?

5G QoS identifier (5QI) corresponds to the 4G QoS class identifier (QCI) as the index of service
quality. 5QI is a set of parameters such as resource type, priority, reliability, and packet loss rate, and
is applied to all paths. After 5QI is defined, the core network only transfers the 5QI rather than all
parameters. The 5QI value can be used to notify the (R)AN side of all QoS information, reducing
parameter transfer between NFs.
To support new services such as Internet of Vehicles (IoV) and remote control, 5QI is improved and
enhanced based on QCI. For example, standard values 69 and 79 to 85 are added, and the
classification of resource types is refined. The following table lists the differences between 5QI and
QCI in addition to standard 5QIs.
Item 4G 5G

Resource Type Value Value range:

range:
GBR
GBR
Non-GBR
Non-
Delay-critical GBR: It is used for URLLC services.
GBR

Averaging NA Item added to 5G. It applies to GBR QoS flows and defines the duration over which
Window the GFBR and MFBR are calculated, making GFBR and MFBR calculation more
accurate.

Maximum NA Item added to 5G. It applies to GBR QoS flows of the delay-critical type in URLLC
Data Burst services. It defines the maximum length of data packets over the air interface
Volume within the delay budget. It is used for admission control over the air interface and
prevents IP fragmentation on N3 tunnels.

For details about the definition of 5QI, see [Link] "5QI", 5.7.3 "5G QoS characteristics", 5.7.4
"Standardized 5QI to QoS characteristics mapping" in 3GPP TS 23.501.

• Optional 5G parameters
In addition to the preceding parameters, 5G introduces the following optional parameters to flexibly
control QoS and guarantee service quality.

2025-04-25 44
Technology Series

New Target Function Scenario Relevant

Parameter Object Protocol

RQA Non- Indicates QoS flow support for the Reflective Services that do not 23501
GBR QoS mechanism. For details, see the following require bandwidth [Link]
QoS section. guarantee, such as
Flow web browsing.

Notification GBR When the (R)AN cannot fulfill GFBR, it sends Services that can 23501
Control QoS a notification to the SMF and the 5GC initiates change the rate with [Link]
Flow an N2 signaling procedure to modify or the QoS change, such
remove the QoS flow. The (R)AN fulfills the as live video.
GFBR if allowed.

Maximum GBR Indicates the maximum packet loss rate that Voice services 23501
Packet Loss QoS can be accepted by QoS flows over the air [Link]
Rate Flow interface.

QoS Control

In the 5G QoS mechanism, the PCF/SMF is a key NF for QoS control. The following uses a company
analogy for them. The PCF works as a boss and has the final decision-making power for QoS. The SMF
works as a manager and controls QoS flows according to the instruction of the PCF. The UPF/(R)AN/UE
are employees with different responsibilities and perform user-plane operations according to the
instruction of the SMF.

• QoS parameter decision

The QoS decision process is the same for the 4G and 5G networks. The QoS parameters are
determined by the network side, and slight differences are introduced due to network architecture
evolution.
The QoS parameters in the 5G network are determined by the PCF, SMF, and UDM, as shown in the
following figure. The PCF is the top decision maker for QoS parameters. If the PCF does not deliver the
QoS parameters, the SMF determines whether to allow UEs to use the requested QoS according to the
local configuration. The SMF stores the final QoS parameters.

QoS Flow Type QoS Parameter Decision-Making Method

Default QoS flow 5QI/ARP/Session-AMBR After obtaining the QoS from the UDM, the SMF
obtains the negotiated QoS from the local
configuration and reports the QoS to the PCF.
If the local configuration does not contain QoS, the
SMF uses the subscribed QoS from the UDM as the
locally determined QoS.

2025-04-25 45
Technology Series

QoS Flow Type QoS Parameter Decision-Making Method

If the PCF delivers a new QoS, the SMF uses the QoS
delivered by the PCF.

UE-AMBR The AMF obtains the UE-AMBR from the UDM and
sends it to the (R)AN.

Network-initiated 5QI/ARP, GFBR/MFBR, Notification The PCF directly delivers the QoS parameters.
dedicated QoS control, and Maximum Packet
flow Loss Rate

UE-initiated The UE can include the QoS parameters of the

dedicated QoS requested dedicated QoS flow in the request message.
flow The QoS parameters delivered by the PCF prevail.

• QoS flow control

After determining the finally used QoS parameter, the SMF determines the QoS flow information
including QFI, PFS, and QoS parameters, according to the QoS parameters and the service
information. To further control establishment, modification, and deletion of the QoS flow, the SMF
separately notifies the UPF/(R)AN/UE of the QoS flow information to indicate how to process data
packets.
On the 4G network, EPS bearers are controlled using signaling, and the MME notifies UEs of how to
process data packets by using signaling. On the 5G network, QoS flow control is enhanced to reduce
signaling messages for PDU session modification when new applications are to be deployed. In
addition to the 4G signaling QoS flow control mechanism, a Reflective QoS mechanism is introduced
for the UE to derive the uplink QoS rule. For details about the Reflective QoS mechanism, see 5.7.5
"Reflective QoS" in 3GPP TS 23.501.
QoS Applicable Principle
Mechanism QoS Flow

Signaling All QoS The SMF sends a message to the UPF/(R)AN/UE when a PDU session is
control flows established, modified, or activated on the user plane. The message carries
the QoS flow information.

The (R)AN and UE processes QoS flows according to the received QoS flow
information.

Reflective Non-GBR When a PFS (for example, a new application) needs to be added to an
QoS QoS Flow existing QoS flow, the SMF does not notify the UE of a new PFS by using
signaling messages. Instead, the UE derives the PFS according to the
information carried in the received data packet header.

2025-04-25 46
Technology Series

QoS Applicable Principle

Mechanism QoS Flow

The UE reports the Reflective QoS capability to the UDM and SMF during
registration or session establishment. The Reflective QoS mechanism is
initiated by the SMF. When the SMF determines to activate the Reflective
QoS mechanism, the SMF sends the SDF QoS control information (RQI)
including the Reflective QoS indication to the UPF, and sends the QoS
profile including the Reflective QoS Attribute (RQA) to the (R)AN. The RQA
is used to notify the (R)AN of whether to enable the Reflective QoS
mechanism.

After the UPF/(R)AN adds an RQI to the header of a packet and sends the
packet to the UE. After receiving the downlink data packet with the RQI, the
UE derives the uplink PFS according to the packet header, and sends the
uplink data packet.

The UE generates an uplink QoS rule based on the received data, starts the
RQ timer, and uses the derived QoS rule in the uplink direction. The UE
receives the data packets containing the RQI. If there is no uplink QoS rule
for the data packets, the UE starts the timer when generating the QoS rule.
If the uplink QoS rule of the corresponding data exists locally, the UE
restarts the timer. When the timer expires, the UE deletes the QoS rule
derived by the UE.

Summary

5G QoS has been optimized and enhanced on the basis of 4G QoS to cater for requirements of new 5G
services. The following table lists the differences between 4G QoS and 5G QoS.
Item 4G 5G

QoS control EPS bearer, identified by EBI. QoS flow, identified by QFI.
granularity

Control Signaling control Signaling control

mechanism
Reflective QoS control

Implementation There is an end-to-end bearer There is only an air interface bearer between the UE
of data paths between a UE and a P-GW, and and the UPF, and there is no end-to-end bearer
bearer segments have one-to-one between them. In addition, there is no one-to-one
mapping relationships. The key relationship for bearers. The key points are as follows:
points are as follows:
N3 interface: One NG-U tunnel maps to one PDU
S1 interface: One EPS bearer session.
maps to one S1 bearer.
Air interface: N QoS flows map to one radio bearer.

2025-04-25 47
Technology Series

Item 4G 5G

Air interface: One EPS bearer

maps to one radio bearer.

QoS mapping One-layer mapping: Uses the Dual-layer mapping: Using the packet filter to map an
packet filter set to map an IP IP data packet to a QoS flow, and then using the QFI
packet to an EPS bearer. to map the IP data packet to a radio bearer.
Uplink: The UE maps the data Uplink: The UE uses the filter set to determine the QoS
packet to the EPS bearer, and the flow to which the data packet should be mapped, adds
eNodeB and the S-GW forward the QFI flag to the data packet header, maps the QoS
the data packet according to the flow to the radio bearer, and sends the data packet to
one-to-one mapping relationship the (R)AN. After receiving the packet, the (R)AN
between the bearers. carries the QFI in the packet header and sends the
packet to the UPF.
Downlink: The P-GW maps the
data packet to the EPS bearer, Downlink: The UPF maps the data packet to the QoS
and the S-GW and the eNodeB flow, marks the packet header using QFI, and sends
forward the data packet the packet to the (R)AN. After receiving the data
according to the one-to-one packet, the (R)AN maps the QoS flow to the radio
mapping relationship between the bearer according to the QFI, carries the QFI in the
bearers. packet header, and sends the packet to the UE.

QoS parameters Bearer-level parameters: QCI, QoS flow-level parameters: 5QI, ARP, GFBR/MFBR,
ARP, and GBR/MBR RQA, and Notification Control
PDN-level parameter: APN-AMBR Session-level parameter: Session-AMBR
UE-level parameter: UE-AMBR UE-level parameter: UE-AMBR

QoS Resource Type/Priority Resource Type/Priority Level/Packet Delay Budget/

characteristics Level/Packet Delay Budget/Packet Packet Error Rate/Averaging Window/Maximum Data
Error Loss Rate Burst Volume
Delay-critical GBR is added for Resource Type.
Some standard 5QIs are added.

For details, see 3GPP TS 23.501.

1.7 Session Management

• Forewords

• Control NFs for Session Management

• Session Management Differences Between 4G and 5G Networks

• Session Management Procedure

• SSC Mode

• Conclusion

Forewords
2025-04-25 48
Technology Series

QoS is implemented by QoS flows, and QoS flow establishment, modification, or deletion is completed
using a session management procedure. Session management is optimized and extended in 5G based on
the network architecture and the types of services carried by QoS flows.
This chapter describes the session management of 5G networks in terms of control NFs, management
procedure, and service continuity. It focuses on the differences between 5G session management and 4G
session management, helping you better understand how 5G session management responds to network
architecture changes and meets requirements of diverse 5G services.

Control NFs for Session Management

Figure 1 4G/5G network architecture

As shown in Figure 1, on a 4G network, the session management function is provided by the MME and S-
GW/P-GW. On a 5G network, the session management function is provided by the SMF as it aggregates
the session management function of the MME and the control plane function of the S-GW/P-GW.

Session Management Differences Between 4G and 5G Networks

Table 1 lists the session management concepts for 4G and 5G networks.

Table 1 Session management concepts for 4G and 5G networks

Category 4G Network 5G Network

Data channel PDN connection PDU session

Session management object EPS bearer QoS Flow

Default bearer Default QoS flow
Dedicated bearer Dedicated QoS flow

QoS control granularity EPS bearer QoS Flow

On a 4G network, a UE can simultaneously create multiple packet data network (PDN) connections to
access different PDNs. On a 5G network, the UE can also simultaneously create multiple PDU sessions to
access different data networks (DNs). You can further understand the differences between session
management concepts for 4G and 5G networks using the information in Table 1, and descriptions in Figure
2. These also explain the relationships between data network names (DNNs), PDU sessions, QoS flows, and
DNs on a 5G network, and relationships between APNs, PDN connections, bearers, and PDNs on a 4G
network.

Figure 2 Support for multiple PDN connections/PDU sessions

2025-04-25 49
Technology Series

Session management differences between a 4G network and a 5G network are as follows:

1. Bearer establishment
When a UE attaches to a 4G network, a default bearer is established to provide a permanent IP
connection. When the default bearer cannot meet service requirements, a dedicated bearer is then
established. When a UE registers with a 5G network, it is not mandatory to establish a default
bearer, and the UE can choose to establish a PDU session based on service requirements.
This way, mobility management and session management can be decoupled. In addition, resource
consumption decreases because a UE does not need to always keep a default QoS flow while only
interacting with the network occasionally, similar to that in NB-IoT scenarios.

2. QoS control
On a 4G network, QoS control is performed by bearer. On a 5G network, QoS control is performed
by QoS flow. There is a default QoS flow on a 5G network, which is similar to the default bearer on
a 4G network. One PDU session can be controlled by multiple QoS flows, which is similar to the
relationship between a PDN connection and bearers on a 4G network. When the default QoS flow
cannot meet service requirements, a dedicated QoS flow is established to ensure service quality. For
details, see section "QoS".

Session Management Procedure

This part uses the procedure for a UE to access the network, access a web page or video, and surf the
Internet as an example. In this procedure, a data channel must be established between the UE and Internet
to transmit packets. This channel ensures the quality of E2E service transmission. All of these requirements
can be satisfied by using the session management procedure. For details, see clause 5.6 in 3GPP TS 23.501
and clause 4.3 in 3GPP TS 23.502.
Differences in Session Management Procedures Between 4G and 5G Networks

2025-04-25 50
Technology Series

The following table describes the differences in session management procedures between 4G and 5G
networks.
4G Network 5G Network Difference

PDN connection PDU session establishment They are functionally the same but conceptually different.
establishment

Dedicated bearer PDU session update On a 4G network, there are dedicated bearer activation,
activation bearer update, and bearer deactivation procedures. On a 5G
Bearer update network, there are QoS flow addition, modification, and
Bearer deletion procedures, which are all implemented in the PDU
deactivation session update procedure.
According to the 5G QoS model (see the section "QoS"), the
granularity in the 5G tunnel model is changed from bearer
granularity to session granularity, and session management
procedures are defined as session-level PDU procedures.

PDN PDU session release They are functionally the same but conceptually different.
disconnection PDN disconnection = Release of all bearers
PDU session release = Release of all QoS flows

- Selective activation and New procedures:

deactivation of user-plane
Activation: Activating an existing PDU session through the
connections for existing
service request procedure requires that a user-plane
PDU sessions
connection be established.
Deactivation: Deleting a user-plane connection of an existing
PDU session does not change control-plane connections.
These new procedures help decrease radio resource
consumption and facilitate quick recovery of PDU sessions.

Procedure Implementation
The following figure uses a PDU session establishment procedure as an example to describe the differences
in session management procedures between 4G and 5G networks.

As shown in the preceding figure, a 5G PDU session establishment procedure is still an establishment of a
connection between the UE and external data network. Therefore, the overall framework of a 5G PDU
session establishment procedure is basically the same as that of a 4G PDN connection establishment

2025-04-25 51
Technology Series

procedure, except that NF functions on a 5G network are decoupled and interactions between the NFs
(AMF, SMF, and UPF) are added.

SSC Mode

The 5G system supports session and service continuity (SSC).

A 4G network provides IP continuity, while a 5G network supports a variety of service scenarios to meet
diverse requirements of different services for continuity. The 5G system supports different SSC modes. The
SSC mode of a PDU session remains unchanged in the life cycle of the session. When the SSC mode of an
existing PDU session does not meet application requirements, a UE establishes another PDU session for the
application.
SSC Mode Principle Scenario
Type

SSC Mode1 For a PDU session in SSC mode 1, the IP address provided by This mode is used
(for IP the network for a UE and the UPF selected for the UE remain for applications
continuity) unchanged. that have high
requirements on
service continuity,
such as IMS voice
services.

SSC Mode2 When the SMF determines that the serving UPF needs to be This mode is used
(not for IP reallocated (one possible cause is that the current user-plane for applications
continuity) path is not the optimal one), the SMF instructs the UE to that have low
release the existing PDU session and then establish another requirements on
PDU session to the same DN. After the new PDU session is service continuity
established, the SMF selects another UPF for the PDU session. and allow short-
(disconnected and then connected) term service
interruption, such
as video services
with data caching.

The SMF dynamically selects the optimal data path based on

the real-time conditions of subscribers, networks, and
applications to improve network efficiency.

SSC Mode3 When the SMF determines that the data path of a PDU session This mode is used
(for short- needs to be switched (for example, the user-plane path of the for applications
term IP existing PDU session is not the optimal one when a UE moves), that support multi-
continuity) the SMF instructs the UE to establish another PDU session to path transmission,
the same DN, selects another UPF for the new PDU session, and such as the
requests the UE to release the old PDU session when the applications using
specified timer expires or when the service traffic related to the the Multipath
old DN has been switched to the new PDU session (connected Transmission
and then disconnected).

2025-04-25 52
Technology Series

SSC Mode Principle Scenario

Type

Control Protocol
(MPTCP).

SSC modes 2 and 3 are introduced to 5G to provide the following benefits:

• Ensure service continuity based on different sessions' service requirements, such as requirements for
the delay caused during session interruption.

• Improve user-plane path efficiency and ensures subscriber experience of services requiring a low delay.
Allow UEs that are moving to change their in-use service anchors and data paths based on topology
changes.

• Provide a more flexible session reestablishment or handover solution.

Along with the service anchor relocation, the process of maintaining service continuity in SSC mode 2
or 3 is more complex than that of SSC mode 1.

Carriers can provide an SSC mode selection policy for UEs. The policy contains one or more SSC mode
selection rules, and UEs can use these rules to determine the intended SSC mode type associated with a
specific application. The SMF interacts with the UDM to obtain SMF-level subscription data, such as the
allowed SSC mode and the default SSC mode. The SSC mode selection policy may contain a default SSC
mode selection rule, which matches all UE applications.

Conclusion

• Session management similarities between 4G and 5G networks

The core content of session management on a 5G network remains unchanged. Session management
remains the basis for UEs to establish connections with external DNs and then access data services.

• Session management differences between 4G and 5G networks

Session management and mobility management on a 5G network are decoupled from each other. The
independent activation and deactivation procedures for the user plane of existing PDU sessions are
added based on application scenarios, and new SSC modes are introduced to better support diverse
5G services.

1.8 CUPS & MEC Issue

• Forewords

• What is CUPS?

• What is MEC?

2025-04-25 53
Technology Series

• MEC Application Scenarios

• MEC Network Architecture

• Key Technologies

• MEC Deployment

• MEC Evolution

Forewords

Why are people fascinated by science fiction movies?

If we call movies the mirrors reflecting the real world, science fiction movies are the mirrors reflecting the
future. In the legendary television series Star Trek, which was initially aired in 1966, caption Kirk and his
crew communicated with each other using a handheld communicator that flips open. The communicator
later inspired Martin Cooper to invent the world's first cellphone. At that time, no one could have imagined
that more than half the population on the earth would have cellular phones, and that feature phones
would evolve to smart phones. Reality surpassed science fiction in only 40 years.
It is very possible that the science fiction movies we see today are giving us a peek into life of the future. In
one of the hit scenes in Black Panther (2018), while Black Panther is hunting down his assailants, his sister
Shuri joins the car chase from thousands of miles away, thanks to the remote driving system. It is certain
to say that we will enjoy some very cool technologies in the very near future, such as autonomous driving,
VR fitting rooms, and virtual tours to museums.

The secret power to make all these science fiction scenes a reality is 5G. In this section, we will talk about
control and user plane separation (CUPS) and multi-access edge computing (MEC), two of the key
technologies that enable ultimate user experience.

What is CUPS?

CUPS is short for control and user plane separation. Before 5G, core network functions can also be
classified into control plane functions and user plane functions, but they are not clearly separated from
each other. The control plane functions establish and manage tunnels for data transmission. The user
plane functions transmit user data.

2025-04-25 54
Technology Series

3GPP release 14 defined the 4G-based CUPS architecture, introducing the SGW and the PGW to separate
the control plane and user plane. On a 5G network, software-based architecture (SBA) is introduced to
make the separation more clean. The control plane is handled by several network functions (NFs). The user
plane is handled by the UPF. The UPF can be deployed either at the core or at the access network, which is
in closer proximity to users.

What is MEC?

5G encourages service innovations toward enhanced mobile broad band (eMBB), massive machine type
communications (mMTC), and ultra-reliable and low latency communications (URLLC). Typical services
include IoV, cloud-powered AR/VR, cloud-based gaming, UAV applications, HD live broadcast, and
industrial control. These new services have raised standards on network capabilities, such as lower latency,
roaming at the edge, and exposure of user location information for real-time service optimization.
To satisfy new service requirements, MEC emerges and offers a future-oriented architecture.
Multi-access edge computing is proposed by the ETSI. It offers application developers and content
providers cloud-computing capabilities and an IT service environment at the edge of the network. With the
MEC system, carriers are able to deploy applications, contents, and a part of core network functions (such
as service logic and resource orchestration) to the edge of access networks. Comparing with conventional
central DC, MEC nodes are located in close proximity to users and are able to provide better reliability and
service experience.
Let's further break the concept down word by word.
Multi-access: MEC was previously named mobile edge computing. Later the ETSI MEC group replaced
"mobile" with "multi-access." When a telecom network evolves to 5G, it supports multiple access
technologies and is able to manage them in a unified manner. The "multi-access" feature enables an MEC
system to provide consistent experience to users connecting through any access technologies.

Edge: Network functions and applications are moved from the center to the edge, delivering ultra-low
latency. For example, if both servers of an enterprise and core network gateways of a carrier are placed in

2025-04-25 55
Technology Series

front of your home, traffic can be locally processed no matter how much traffic volume is and when traffic
needs to be processed.

Computing: The computing capabilities of the network are distributed to the edge. Such capabilities include
video encoding and decoding, VR/AR rendering, and video analysis. A typical application is local video
surveillance for security and traffic control. Backhauling surveillance video consumes a great amount of
bandwidth, but most of the video is static or of no value. MEC makes it possible to analyze and process
video streams locally and backhaul only the meaningful data. Meaningless data will temporarily be stored
locally and then deleted. Use of MEC in this scenario greatly reduces bandwidth consumption.

MEC Application Scenarios

MEC has unlimited potential. Let's take a peek at some of its use cases.
The ETSI has released the MEC service scenarios, including intelligent mobile video acceleration, AR/VR,
enterprise deployment, connected vehicles, IoT gateway service, video stream analysis, and assistance for
intensive computation.

Based on industry maturity and how long it takes to commercialize, Huawei has selected the following key
use cases:

• Local breakout (LBO) for enterprise-dedicated networks

• CDN sinking

2025-04-25 56
Technology Series

• Video Surveillance

• Cloud VR/AR

• V2X

• Industrial control

LBO for enterprise-dedicated networks

For an enterprise or university campus, traffic is generated and terminated locally, and data is not
transferred outside the campus. MEC brings about low-latency and high-bandwidth experience to users
within the virtual LAN.
CDN
OTT players have already deployed their CDN nodes downwards in edge DCs. If mobile gateways are still
located in the backbone network, there will be unnecessary bandwidth consumption in between the edge
DCs and the backbone network, and user experience deteriorates. To address this, MEC can be introduced
to eliminate such bandwidth consumption, shortening latency, and improving user experience.

Video surveillance
Backhauling surveillance video consumes a great deal of bandwidth, but most of the video is static or of no
value. Deploying MEC on the RAN makes it possible to analyze and process video streams locally and
backhaul only the meaningful data. It avoids transporting numerous high data video streams.

Cloud VR/AR
Take VR as an example. Cloudification gives VR a strong push by addressing the lack of capabilities on user
devices. However, such services require high bandwidth and low latency, and therefore need the support of
a 5G network. It is expected that VR applications will require a bandwidth of over 200 Mbit/s and a lower
latency of about 5 ms.
An example VR application is a live broadcast of a football game, where panoramic cameras capture high-
definition real-time video streams. The audience can replay a scene from multiple close-up angles through
their VR terminals. With high bandwidth and low latency, MEC is an effective solution for eliminating
dizziness.

2025-04-25 57
Technology Series

V2X
Vehicle-to-everything (V2X) is a form of technology that allows vehicles to exchange data with their
surroundings. Exchanged data includes speed, location, driving directions, and more. Such information is
exchanged between vehicles in real time, facilitating the autonomous driving system to make sound
decisions, and significantly improving safety. To achieve this, the network infrastructure must be capable of
providing massive bandwidth, low latency, and high reliability. According to the 3GPP, latency in V2X
applications must be less than 3 ms.
Industrial control
Combination of MEC and cellular networks provide solid support for industry 4.0. An MEC-based industrial
control system can be deployed locally to process manufacturing data in real time and steer traffic locally
for better automation and efficiency.
There are various service scenarios besides the ones mentioned here. Each service scenario can be further
broken down into many sub-scenarios based on the technology it relies on. The time sub-scenarios go
commercial varies depending on their E2E industry maturity level. Take cloud VR applications as an
example. They can be further classified into 4K VR and 8K VR. Since the ecosystem for 4K applications is
more mature, we are expecting to see the 4K VR applications earlier than 8K VR applications. In short, the
pace of MEC commercial use can be divided into three phases.

Phase Typical Application Requirements

2018-2021 (short term) 4K VR, 4K video, and HD live broadcast - Delay: 30–50 ms
- Bandwidth < 50 Mbit/s

2025-04-25 58
Technology Series

Phase Typical Application Requirements

2022–2023 (medium term) 8K VR, VR game, V2X, and industrial control - Delay: 10–30 ms
- Bandwidth: 50–100 Mbit/s
- Mobility control on the edge

2024+ (long term) Telemedicine, 24K VR, and V2X - Delay: about 5 ms
- Bandwidth > 150 Mbit/s
- Mobility control on the edge

MEC Network Architecture

We have seen the blueprint of the MEC applications. Let's talk about what the Huawei MEC solution looks
like.
In Huawei MEC network architecture, the user plane is separated from the control plane and moves to the
edge. The user plane functions are deployed on the MEC platform, together with value-added applications
(such as NAT, firewall, and DNS), mobile edge applications (such as video surveillance, VR, and V2X), and
network capability exposure functions.

MEC hardware and MEC IaaS provide hardware resources and infrastructure services.
5GC user plane includes the SGW-U, PGW-U, and UPF functions and is deployed at the edge.
MEP is short for MEC platform. It provides service registration, discovery, and deregistration functions and
exposes network capabilities to third-party applications.
VAS is short for value-added services. They are deployed on the MEP and are provided to third-party
applications. Typical VAS services include NAT, firewall, and TCP optimization (TO).
ME apps are OTT applications integrated on the MEP. Typical applications include V2X server, CDN, and
AR/VR.
APIs are used to expose network and platform capabilities.

Key Technologies

2025-04-25 59
Technology Series

Implementation of the MEC blueprint relies on the following technologies:

• Local breakout (LBO)

An MEC server can provide the LBO function to steer traffic to local application servers, avoiding
traffic hauling back and forth between the edge and the core. An example use case is video
surveillance. MEC servers and cameras deployed locally can upload video streams to the local server
instead of to the Internet, ensuring video playback in real time.

• Edge charging and control

The MEC platform at the edge interworks with the control plane of the core network to perform
charging and policy control over local traffic.

• Network information and capability exposure

The exposed capabilities and information can be divided into three categories:

• Radio network information

The RAN collaborates with the MEC API GW to expose radio network information to applications,
including user location information, cell information, user information, bandwidth information.

• Core network capabilities

• The MEC API GW obtains charging, QoS, and service control policies from the central
network exposure function (NEF).

• When there is a policy change, the central NEF synchronizes the change to MEC API GW, or
to the SMF, which will forward it to the UPF.

2025-04-25 60
Technology Series

• MEC platform capabilities

The MEP exposes its capabilities such as transcoding and IPsec to local applications through the
RESTful API.

• Capability exposure
The MEC platform is capable of hosting various third-party applications for different business
scenarios. It provides common network functions such as firewall and NAT, saving third parties the
trouble and investment from deploying these functions on their own. The platform also hosts the
O&M and lifecycle management of the applications deployed on it.

MEC Deployment

Is it necessary to have computing capabilities move to the edge for all service scenarios?
The answer is no. There is still a small portion of traffic that is sent to the core for processing. Then it
comes to the question: which services require MEC and which do not?
To answer this question, we will need to consider the latency and LBO requirements of each service; and
then determine where to deploy the MEC servers and user plane gateways.

2025-04-25 61
Technology Series

MEC Evolution

We have seen what MEC is capable of. Now, how do we move from 4G to 5G?
Huawei has already introduced remote gateways (RGW) at the network edge so that 4G users can benefit
from MEC. After CUPS, the distributed gateways (DGW) are deployed at the edge or in regional DCs to
handle user plane data and deliver ultimate user experience. When 5G comes, the user plane and control
plane are separated by default. The UPF, which handles the user plane data, is deployed together with the
MEC platform at the edge or in regional DCs. Backed up by the powerful 5G network capabilities, more
MEC potential is to be explored.

MEC is going to deliver ultimate user experience and bring scenes from science fiction into reality. Stay
tuned.

1.9 Security Architecture

• Security Challenges

• Standards Security

• Conclusion

Security Challenges

2025-04-25 62
Technology Series

5G implements interconnection of everything, supports diversified service scenarios, and introduces new IT
technologies and architectures. What challenges do these changes pose to cyber security? How can we
deal with these challenges?
New Architecture and Technologies
The 5GC architecture introduces new architecture and technologies, such as the service based architecture
(SBA), network functions virtualization (NFV), control and user plane separation (CUPS), slicing, and
capability exposure. The following figure shows the security challenges and requirements.

Scenarios of New Services

The three major scenarios of 5G services are as follows:

• eMBB
5G networks must be able to provide differentiated security protection mechanisms because different
service types have different security requirements.

• mMTC
There are a variety of IoT applications and hundreds of billions of connections, and 5G networks may
have risks of attacks from terminals, such as signaling storms.

• URLLC
Low latency and high reliability are the basic requirements of URLLC services, and 5G networks need
to provide high-level security protection measures but not increase the communication delay.

Multiple Access Modes and Device Types

5G networks support multiple access technologies, such as WLAN, LTE, and 5G radio access technologies.
There are diversified terminal types, such as VR devices, smart cars, drones, and smart water meters.

2025-04-25 63
Technology Series

Different access technologies have different security requirements and access authentication mechanisms.
When a terminal is handed over between different access modes or a subscriber uses different terminals to
access the same service, fast authentication is required to ensure service continuity.
Therefore, a unified authentication framework needs to be constructed for 5G networks to integrate
different access authentication modes and optimize existing security authentication protocols. This
improves security authentication efficiency when a terminal is handed over between heterogeneous
networks. In addition, the unified authentication framework ensures the service security of the same
service when a terminal is replaced or an access mode is changed.
Higher Privacy Protection Requirements
The diversity of services and scenarios on 5G networks and the exposure of networks enable subscriber
privacy information to be transferred from closed platforms to open platforms, raising privacy concerns.
For example, privacy information, such as patient medical records, prescriptions, and treatment solutions,
in the intelligent medical system may be leaked or tampered with during data collection, storage, and
transmission. In addition, subscriber data on a 5G network may traverse multiple access networks and
network function entities provided by different vendors. As a result, subscriber privacy data is scattered
throughout the network. With the continuous improvement of privacy protection in each field, relevant
laws and regulations are released. For example, the General Data Protection Regulation (GDPR) was
officially released by the EU in 2016. Therefore, 5G networks have higher subscriber privacy protection
requirements.
To sum up, 5G networks need to provide unified security authentication capabilities, stronger data security
protection capabilities, subscriber privacy protection capabilities, SBA security capabilities, multi-layer slice
security capabilities, and security protection mechanisms required for capability exposure. These
capabilities prevent or reduce potential security risks, ensure network service continuity, protect business
secrets, and subscriber privacy.

Standards Security

Security Authentication Capability (3GPP TS 33.501)

5G builds a unified security framework, authentication method, and key architecture that are independent
of access modes.

• Security Framework
On 4G networks, two different authentication frameworks are used for 3GPP and non-3GPP access.
On 5G networks, the security framework consists of the UE, AMF, AUSF, and UDM, regardless of
access modes, as shown in the following figure.

The functions of each NF in the 5G security framework are as follows:

2025-04-25 64
Technology Series

• UDM
The UDM stores subscriber root keys and authentication-related subscription data, and generates
5G authentication parameters and authentication vectors, similar to the HSS on a 4G network.

• AUSF
The AUSF derives an anchor key KSEAF. The AUSF provides the network authentication function if
the EAP-AKA' authentication method is used; the AUSF provides the home network
authentication function if the 5G AKA authentication method is used.

• AMF
The AMF derives lower-layer NAS and AS keys based on the anchor key KSEAF. The AMF
acknowledges the service network authentication result if the 5G AKA authentication method is
used.

• Authentication Method
5G and 4G support bidirectional authentication between the UE and network. The difference is that
5G has the unified 3GPP and non-3GPP authentication methods and supports EAP-AKA' and 5G AKA.
For details, see the following table. In practice, carriers can select authentication methods based on
their policies.
Authentication Description Authentication Authentication Vector
Method NF

EAP-AKA' EAP authentication based on the USIM. AUSF 5-tuple, consisting of

RAND, AUTN, XRES, CK',
and IK'

5G AKA 5G AKA enhances EPS AKA. AMF and AUSF 4-tuple, consisting of
RAND, AUTN, XRES*, and
A procedure for home network authentication
confirmation is added for 5G AKA to defend KAUSF
against roaming spoofing attacks.
5G AKA does not support requests for
multiple authentication vectors or
authentication vector pre-acquisition.

• Key Architecture
Compared with 4G, 5G has unified the derivation of keys for 3GPP and non-3GPP access. As shown in
the following figure, in the 5G key architecture, the root key K is stored in the UDM and USIM card,
and the KAUSF, KSEAF, and KAMF are derived from the root key K. Different authentication methods
require different KAUSF calculation formulas. Both 3GPP and non-3GPP access use the same KAMF key
to derive NAS and AS keys, and unify derivation.

2025-04-25 65
Technology Series

Control Plane and User Plane Data Protection (3GPP TS 33.501)

Confidentiality and integrity protection of the 5G control plane inherits the 4G mechanism, with 4G
integrity protection enhanced on the 5G user plane.

Subscriber Privacy Protection (3GPP TS 33.501)

To solve the problem of IMSI disclosure on 4G networks, IMSIs on 5G networks are encrypted and
transmitted over air interfaces for subscriber privacy protection, as shown in the following figure.

During initial registration, a UE uses the public key of the home network to encrypt non-routing
information in the subscription permanent identifier (SUPI) and converts the SUPI into a subscription
concealed identifier (SUCI). The routing information is still transmitted in plaintext, and is used to address
the home network. After obtaining the SUCI, the core network uses the private key to decrypt the SUCI
into an SUPI.

2025-04-25 66
Technology Series

SBA Security (3GPP TS 33.501)

5G core networks decouple and aggregate control plane functions and provide these functions as services
to support agile deployment of network functions (NFs). NFs communicate with each other over SBIs, as
shown in the following figure.

To prevent and reduce security risks such as NF spoofing, tampering, information leakage, and privilege
escalation, the 5G core network provides functions such as SBI encryption, NF authentication, and NF
access authorization.

• SBI encryption: Transport Layer Security (TLS) is used at the SBI security transport layer to encrypt
data and protect data integrity.

• NFs on the 5G core network authorize each other based on the OAuth2.0 framework. After
registration, an NF applies to the NRF for an access token. When requiring a service, the NF carries
the access token to access the NF service producer. The NF service producer determines whether to
provide the service based on the access token verification result. In other words, an access token is like
a license that is necessary for an NF service consumer to use a service provided by an NF service
producer. And, the license will expire.

Figure 1 NF authentication and authorization

Slice Security (3GPP TS 28.801)

5G provides slice isolation based on the SBA. Compared with 4G dedicated network isolation, 5G uses slices
to isolate services of different levels, reducing costs and improving security.

2025-04-25 67
Technology Series

The following aspects are considered for slice security: slice authentication, security service feature
adaptation of slices, management plane interface security of slices, slice security capability exposure, and
more.

Conclusion

The following table lists the security differences between 5G and EPS networks according to 3GPP
specifications.
Category EPS 5GC (Phase 1 eMBB)

Architecture Authentication 3GPP access: The authentication The authentication framework consists of
framework framework consists of the UE, the UE, AMF, AUSF, and UDM.
MME, and HSS.
Non-3GPP access: The
authentication framework consists
of the UE, ePDG (untrusted), TGW,
HSGW (trusted), AAA server, and
HSS.

Authentication 3GPP access: EPS-AKA EAP-AKA' and 5G AKA

algorithm Non-3GPP access: EAP-AKA and
EAP-AKA'

Security anchor 3GPP access: MME AMF

Non-3GPP access: 3GPP AAA Re-authentication is not required
server because the anchor key is shared during

2025-04-25 68
Technology Series

Category EPS 5GC (Phase 1 eMBB)

Re-authentication and security handovers between 3GPP and non-3GPP

context establishment are required networks.
during handovers between 3GPP
and non-3GPP networks.

Capability User plane Confidentiality protection Confidentiality/integrity protection

security

Subscriber IMSIs are transmitted in plaintext The public key of the home network is
privacy over the air interface before used to encrypt IMSIs. IMSIs are not
security contexts are established. transmitted in plaintext over the air
interface.

Encryption SNOW 3G, AES, and ZUC algorithms. The key size is 128 bits.
algorithms

With the continuous discussion and evolution of standards in the future, we will continue to enhance 5G
network slice security and network capability exposure security, and also defend against DDoS attacks on
the air interface. This is to provide a secure, trusted, and resilient network.

1.10 Security Procedure

• Security Procedure Differences Between 5G and 4G Networks

• IMSI Encryption (SUPI -> SUCI)

• Authentication (5G AKA and EAP-AKA')

Security Procedure Differences Between 5G and 4G Networks

The following figure shows the security procedure between the core network and UE.

• UE identity confidentiality: It prevents transmission of the real identity of a UE over a network so that
attackers cannot easily obtain the real identity of the UE. In addition to the inheritance of the
mechanism for allocating a temporary identity (4G: GUTI -> 5G: 5G GUTI) to the UE on a 4G network,
the IMSI encryption (SUPI -> SUCI) mechanism is added to a 5G network to prevent the IMSI of the
UE from being transmitted over the air interface before the security context is established.

2025-04-25 69
Technology Series

• Identification: When the network side cannot identify a UE, it initiates an identification procedure
towards the UE. The identification procedure in 5G is the same as that in 4G. The difference lies in the
ID changes. The UE identity is changed from IMSI in 4G to SUCI in 5G. The device identity is changed
from IMEI in 4G to PEI in 5G. For details about the identifier definition of 5G networks, see section
"Identifiers" in 3GPP TS 23.501. For details about the identification procedure, see section
"Subscription identification procedure" in 3GPP TS 33.501.

• Authentication: The UE and network perform bidirectional authentication to check whether they are
secure and legal. The authentication procedure in 5G differs greatly from that in 4G due to the
impacts of SBA introduced to 5GC, unified 5G security architecture, and authentication efficiency and
performance optimization.

• NAS security algorithm negotiation: After the UE and network acknowledge each other, they
negotiate a security algorithm and key used for signaling ciphering and integrity protection in
subsequent communication. After the NAS security algorithm negotiation is complete, the NAS
messages between the AMF and UE are ciphered and integrity-protected. 5G and 4G use the same
NAS security algorithm negotiation procedures as well as the same encryption algorithms (SNOW 3G,
AES, and ZUC). For details, see section "NAS security mode command procedure" in 3GPP TS 33.501.

In conclusion, 5G uses similar security procedures to those in 4G, but introduces IMSI encryption. However,
there are some differences in each sub-procedure. The following table describes the differences.
Security Procedure 5G Network 4G Network Difference Between 5G
and 4G Networks

Identity confidentiality: IMSI SUPI -> SUCI N/A Added procedure in 5G

encryption

Identification Involved NFs UE-AMF UE-MME Change in the functional

unit of the core network:
4G MME -> 5G AMF

Identity UE identity: SUCI UE identity: IMSI 5G and 4G identity change

Device identity: PEI Device identity:
IMEI

Authentication Involved NFs UE authentication: UE authentication: Changes in functional

UE-AMF-AUSF- UE-MME-HSS units of the core network:
UDM Device 4G MME -> 5G
Device authentication: AMF+AUSF, 4G HSS -> 5G
authentication: UE- UE-MME-EIR UDM
AMF-EIR

Authentication 3GPP and non-3GPP 3GPP access: EPS- Change in the 3GPP
method access: 5G AKA and AKA authentication method: 4G
EAP-AKA' Non-3GPP access: EPS AKA -> 5G AKA or
EAP-AKA and EAP- EAP-AKA'
AKA'

NAS security Involved NFs UE-AMF UE-MME Change in the functional

algorithm unit of the core network:
negotiation 4G MME -> 5G AMF

2025-04-25 70
Technology Series

Security Procedure 5G Network 4G Network Difference Between 5G

and 4G Networks

Encryption SNOW 3G, AES, and ZUC No change

algorithms

Algorithm key 128 bits No change

Identity Involved NFs AMF-UE MME-UE Change in the functional

confidentiality: unit of the core network:
allocation of a 4G MME -> 5G AMF
temporary identity
Identity 5G GUTI GUTI 5G and 4G identity change

The following sections describe the differences in the IMSI encryption and authentication procedures
between 5G and 4G networks.

IMSI Encryption (SUPI -> SUCI)

On a 4G network, a UE identifies itself using an IMSI before the core network allocates a GUTI to the UE.
Before the security context is established, the IMSI is transmitted in plaintext over the air interface. In this
situation, there are security risks. Will the IMSI be attacked? The IMSI protection mechanism was not
included in the discussion of 4G security standards because there was no actual application scenario for
IMSI attacks. In the 5G era, IMSI protection is required, as experts point out actual application scenarios for
IMSI attacks are a real threat, and people attach more and more importance to privacy protection.
How can IMSIs be protected? Simply speaking, IMSI encryption is used to protect IMSIs. A UE uses the
public key of the home network to encrypt the non-routing information in the SUPI, and generates a
subscription concealed identifier (SUCI). If the UE is not allocated with a 5G-GUTI during an initial
registration procedure or the UE receives an identity identification request from the network side indicating
that the network side cannot identify the UE through the 5G-GUTI, the UE sends the SUCI in a NAS
message. After obtaining the SUCI, the UDM uses the private key to decrypt the SUCI into an SUPI, and
obtains the UE's real identity and subscription information.
The following figure shows the format of an SUCI. For details, see "Subscription Concealed Identifier
(SUCI)" in 3GPP TS 23.003.

• SUPI Type: SUPI type. The value is 0 for IMSI-based 3GPP access, and 1 for NAI-based non-3GPP
access.

• Home Network Identifier: identifies the home network of the subscriber. When the SUPI type is an
IMSI, the home network identifier is composed of the MCC and MNC.

• Routing Indicator: assigned by the home network operator and stored in the USIM. It is used together
with the home network identifier to address the AUSF and UDM.

2025-04-25 71
Technology Series

• Protection Scheme ID: ID of the encryption algorithm used to encrypt the SUPI into an SUCI.

• Home Network Public Key ID: ID of the home network public key used to decrypt the SUCI into an
SUPI.

• Scheme Output: output of the encrypted SUPI.

Authentication (5G AKA and EAP-AKA')

Authentication involves device authentication and UE authentication.

• Device authentication: Device authentication on 4G and 5G networks is performed through the EIR.
The only change in a 5G network is that the ID changes from an IMEI to a PEI.

• UE authentication: 5G and 4G support bidirectional authentication between the UE and network. The
difference is that 5G has the unified 3GPP and non-3GPP authentication methods and supports EAP-
AKA' and 5G AKA. For details, see the following table. In practice, carriers can select authentication
methods based on their policies.
Authentication Description Authentication Authentication Vector
method NF

5G AKA 5G AKA enhances EPS AKA. A procedure for home AMF and AUSF 4-tuple, consisting of
network authentication confirmation is added. 5G RAND, AUTN, XRES*,
AKA does not support the function of requesting
and KAUSF.
multiple authentication vectors or pre-obtaining
authentication vectors.

EAP-AKA' EAP authentication based on the USIM. AUSF 5-tuple, consisting of

RAND, AUTN, XRES,
CK', and IK'.

5G AKA ("Authentication Procedure for 5G AKA" in 3GPP TS 33.501)

5G AKA is an enhancement to EPS AKA. A procedure for home network authentication confirmation is
added on the basis of EPS AKA to defend against spoofing attacks. In EPS AKA, the MME performs
authentication. In 5G AKA, both the AMF and AUSF perform authentication. The AMF completes UE
authentication on the serving network, and the AUSF completes UE authentication on the home network.
The following figure shows 5G AKA and EPS AKA authentication procedures.

2025-04-25 72
Technology Series

An authentication procedure is divided into three sub-procedures: authentication data acquisition,

bidirectional authentication between the UE and serving network, and home network authentication
confirmation.

1. Authentication data acquisition:

On a 4G network, the MME directly obtains authentication data from the HSS, and can obtain
multiple authentication vectors from the HSS at a time.
On a 5G network, the AMF sends an initial authentication request to the AUSF, and the AUSF
requests authentication data from the UDM. The UDM decrypts an SUCI into an SUPI, selects an
authentication method based on the subscription information, and generates an authentication
vector. In the 5G AKA authentication, only one authentication vector can be obtained at a time, and
the AUSF performs derivation and conversion.

2. Bidirectional authentication between the UE and serving network

a. The UE authenticates the network based on the AUTN. After the authentication is successful,
the UE calculates the authentication response and sends it to the core network. This part is
the same on both 4G and 5G networks.

b. The serving network authenticates the UE. The AMF verifies the authentication response sent
by the UE and determines whether serving network authentication is successful.

3. Home network authentication confirmation:

A new procedure on a 5G network. The AMF sends the UE authentication response to the AUSF. The
AUSF verifies the UE authentication response and provides the result of home network
authentication confirmation.

EAP-AKA' ("Authentication procedure for EAP-AKA'" in 3GPP TS 33.501)

EAP-AKA' is a USIM-based EAP authentication method. During an EAP-AKA' authentication procedure, the
AUSF is responsible for authentication, and the AMF is only responsible for deriving keys and transparently
transmitting EAP messages.

2025-04-25 73
Technology Series

EAP-AKA' authentication can be divided into two sub-procedures: authentication data acquisition, and
bidirectional authentication between the UE and network, as shown in the following figure.

1. Authentication data acquisition:

The AMF sends an initial authentication request to the AUSF. The AUSF determines that the serving
network is authorized and requests authentication data from the UDM. The UDM decrypts the SUCI
of the UE into an SUPI, selects an authentication method based on the subscription information, and
generates and sends an authentication vector to the AUSF. After internal processing, the AUSF sends
an EAP message to the AMF.

2. Bidirectional authentication between the UE and network

a. The AMF sends an authentication request to the UE and transparently transmits the EAP
message to the UE.

b. The UE authenticates the network based on the AUTN. After the authentication is successful,
the UE calculates and sends the authentication response to the AMF.

c. The AMF transparently transmits the EAP message to the AUSF.

d. The AUSF verifies the authentication response sent by the UE and determines whether the
network authentication is successful. If the authentication is successful, the AUSF sends the
AMF an EAP Success message containing the root key.

e. The AMF uses the root key to derive the NAS and air interface keys and the keys used for non-
3GPP access, and sends the authentication result to the UE through an N1 message.

1.11 Container and Container Management

• Forewords

• Why Are Containers Introduced in the 5G Era?

• A Glance at the Industry

• How Are Containers Used for 5G Core

2025-04-25 74
Technology Series

Forewords

The preceding chapters unveil how key cloud native technologies are leveraged in the 5G field. Container-
based virtualization is one of these key technologies, which lays the foundation for agile infrastructures.
This chapter dives into container-based virtualization technology. You will find answers to the following
questions:

• Why Are Containers Introduced in the 5G Era?

• A Glance at the Industry

• How Are Containers Used for 5G Core

Why Are Containers Introduced in the 5G Era?

Virtualization technologies are popularized alongside rapid development of information technologies. VMs
came into light, powered by technologies such as Xen and KVM. Container technologies are now gaining
ground, with Docker as the main player. More and more innovations and breakthroughs are made through
virtualization development.
Traditional virtualization approaches can be applied through hardware abstraction or OS software
functions. Container technology utilizes a ground-breaking approach. It relies on the nature and features of
OS kernel to virtualize resources for individual processes. This approach ushers in fine-grained and efficient
resource sharing. Containers are considered advanced, lightweight alternatives to VMs. That is why
containers are called the new generation of virtualization technology.
Why are containers introduced in the 5G era? In the age of 5G, microservice architecture is introduced
from the IT world.
It is an approach that restructures a software system as a suite of loosely coupled modular services. Each
service module is tied to a specific service goal and uses simple, well-defined APIs to communicate with
other modules. In a traditional monolithic software system, any slight change or update requires building
and developing an entirely new system, which is time-consuming and labor-intensive. Microservices, on the
other hand, can be independently developed, deployed, and scaled. These decomposed services are fine-
grained and loosely-decoupled. They are registered, identified, and even orchestrated on demand over the
service governance architecture. Products that are decoupled based on the microservice architecture can be
flexibly restructured and combined, quickly launched, and delivered in a more agile manner.
As a mature technology, VMs are suitable for stable, coarse-grained services. In addition, low resource
utilization cannot keep up with agile delivery.
To support the microservice architecture, containers are chosen as the most suitable resource carriers.
Containers have less overhead than VMs. Services can be swiftly deployed and scaled independently on
containers even during peak hours.

A Glance at the Industry

Containers run services using shared OS kernels and enable process-level virtualization.
Linux OS Kernel
Linux OS consists of two parts:

2025-04-25 75
Technology Series

• Kernel
The kernel is at the core of an OS. It loads when the OS is starting up, and remains in primary
memory. As a result, it is important for the kernel to be as small as possible while still providing all
essential services required by other parts of the OS. Usually the kernel takes up only a few hundred
MBs.
The kernel provides system-wide control. It has the permissions to access all hardware devices and
abstracts, allocates, and shares CPU and memory resources, for example, it schedules CPU resources
among processes and manages the communication between processes.

• Third-party applications
Third-party applications are mounted to the OS kernel. These applications include graphical user
interfaces (GUIs) and file management tools. They may occupy a few GBs of memory.

Organizations or vendors, such as CentOS, build their own Linux OS versions by assembling the kernel and
peripheral applications and providing OS installation interfaces as well as configuration and management
tools.
Organizations and vendors make contributions to the Linux community, but because of its open license,
these contributions do not fall under copyright. Since each release uses the same Linux kernel, there are no
compatibility problems at the kernel layer.
Container
Containers are more lightweight than VMs. A container does not need to virtualize the entire OS like a VM,
and instead virtualizes a small-scale, isolated virtual environment on a host OS.
A container instance can be considered a miniature OS that shares the Linux kernel of the host OS, and the
container runs its own processes on this thin OS. The container packages up the code and all its
dependencies so the processes can move quickly and reliably from one environment to another.

2025-04-25 76
Technology Series

The figure above shows a container instance of a web service, for example, a service that controls file
uploading on web pages. The container environment consists of three parts:

• Web service (W):

Process code that manages file uploading on web pages, that is, the upper-layer service that
customers are concerned about.

• Web service operating environment (R):

Running files, configuration files, and environment variables required for running upper-layer service
code.

• Linux base (L):

Files that help the web service and its thin OS to use kernel resources efficiently and reliably. These
files define the approach to isolating access, controlling resources, and isolating file systems. The Linux
base is like a socket inserted into the OS kernel.

The container instance of the web service can be developed on an Euler OS (for developers). Since the
container has incorporated the operating environment and Linux base, it does not rely on the peripheral
applications of any other OSs. The container can run on any OS which has the same Linux kernel as the
Euler OS, for example, CentOS.
Container deployment depends on the same Linux kernel but not the operating system of the host
machine. Therefore, the host machine operating system of the container can be the Linux OS (Host OS) on
the physical server or the Linux OS (Guest OS, for example, Euler OS) running on some VMs. Containers
hosted on physical machines are also called bare-metal containers, and those hosted directly on VMs are
called VM-based containers.
The figure below shows the relationship between a container instance and its hosted OS.

2025-04-25 77
Technology Series

Containers share the same OS kernel as the host, but the benefits of resource sharing come at the cost of
security risks. When a container encounters security issues, other containers on the same host may be
affected through the shared kernel.
Containers share host resources more efficiently than VMs. For example, containers use CPU resources
based on CPU quotas, that is, allocated time slices. This fine-grained CPU allocation translates into higher
resource utilization. Unlike containers, each VM needs to be allocated at least one CPU core.
VMs abstract hardware resources. This requires a virtualization layer and guest OS, whereas containers
virtualize the OS. The figures below compare the two virtualization approaches.

VMs and containers provide similar benefits of resource isolation and allocation but work differently in
virtualization, and they also can work together to make service deployment more flexibly. Choose VMs,
containers or use them together to suit your network conditions.
Item VM Container

Virtualization Hardware-based virtualization. Software is Process- or application-oriented virtualization.

decoupled from hardware, and hardware The process or application code and
resources are abstracted, isolated, and dependencies are packaged together.
shared. Fine-grained OS virtualization
Coarse-grained OS virtualization

Isolation Strong Weak

The whole OS is isolated, and tenants can The OS kernel is shared, incurring security risks.
share nodes securely.

Resource Good Excellent

utilization VMs use hardware resources effectively. Containers do not directly occupy hardware
resources, but share the OS kernel.

Boot speed Medium High

Each VM needs to load the whole OS. A container only needs to start processes
because the host OS is already running.

2025-04-25 78
Technology Series

Item VM Container

Portability Medium Excellent

VMs can be rebuilt on other hosts by using Containers package up code and environment
their images. The migration is restricted by dependencies in a unified format so that they
the NFVI configuration can be moved swiftly across different
environments.

Maturity High, and available for large-scale Low, but is developing fast.
commercial use.

Docker
Docker is a tool or engine that makes it easier to create, deploy, and run services with containers. A
container can be quickly replicated from an OS to any other OS with the same Linux kernel.
Docker is a US company that promotes such technology. Docker started as an internal project on the
container engine of the dotCloud company. Later dotCloud was renamed Docker. After being open
sourced, Docker has become the new craze in virtualization and container technology. Some people even
regard Docker and containers as equivalent concepts. In this chapter, we interpret Docker as the container
engine.
Docker packages up all the dependencies required for running upper-layer services, just as workers pack
goods into containers at docks. It simplifies service deployment from "install-configure-run" to "replicate-
run", freeing developers from laborious and complex deployment.
A common case can be used as an example: When you install some software on your PC, the message
similar to the following is displayed, indicating that you need to install dependencies or configuration files.
With Docker, you will not be bothered by this type of message. Docker includes applications and all the
environment dependencies required by the applications in a static image. These dependencies include
runtime environment, configuration files, and other binary files. The image can be shipped to any host so
that applications can be built at any time, without the need of installation and configuration.

A container image is a static file comprised of system libraries, system tools, and other platform settings required by
applications to run on containers. After a container is created from an image, Docker adds a read-write lay on top of
the image to run applications and facilitate container development.

Docker stores image files centrally in a registry that is either private or public on a repository. The image
creator pushes images to a registry. After the registry authenticates the data, users can pull an image
when they want to run it as a container.

Kubernetes (K8s)

• Overview

2025-04-25 79
Technology Series

Docker enables "build-ship-run" for containers and standardizes container migration among hosts, but
users need to run Docker commands manually for the migration.
Generally, an application requires a lot of containers on many hosts. Docker becomes inadequate to
automate deployment, scaling, and management of containers, for example, it is difficult for Docker
to manage all the host locations to deploy containers. Therefore, a production-grade container
platform was urgently called for to make container management, scheduling, and orchestration more
flexible and efficient.
Many container management platforms have arisen in the industry, among which, Kubernetes (Greek
for "navigator") has gained the most popularity.
Kubernetes was originally created by Google in 2014. It is often called K8s for short because there are
eight characters between k and s. It can manage containers across clusters of nodes and automate the
container deployment, maintenance, and scaling.

• Pod: Basic K8s Scheduling Unit

K8s manages life cycles of containers in the unit of pod, including creation, scheduling, and
termination. A pod consists of either a single container or a small number of containers that are
tightly coupled and share resources. This is similar to company management. A company manages its
staff by department or project team rather than on an individual basis.
Containers in a pod run the same application and communicate with each other frequently. Multiple
pods in a management unit use the same network address and port and can communicate with each
other through the local network. This simplifies communication between closely associated service
containers.

• Master-Worker Architecture
K8s groups pods into clusters, and each cluster is a distributed system consisting of nodes. These
nodes are assigned master and worker roles. The master node serves as the control plane, managing
communication and workloads in the cluster, and the worker nodes process services.
These nodes run their respective host machine operating systems (Linux OSs). The host machine
operating system can be the Linux OS on the blade server or the Linux OS running on some VMs.
The figure below shows a K8s system, which is called a K8s cluster, which comprises one master node
and several worker nodes.

Master node components:

• API server: provides KPIs to external networks. This component is invoked by clients or other
components.

2025-04-25 80
Technology Series

• Scheduler: schedules resources, for example, it allocates requests from pods to nodes.

• Controller manager: maintains cluster status, detects faults, and performs automatic scaling.

Worker node components:

• Docker: creates and removes containers.

• Kubelet: manages container life cycles and reports pod status to the master node.

• Kube-proxy: Assigns access requests to pods and serves as a load balancer. It allocates an access
request to a pod.

If a container in a pod fails, the master node will restart the pod. If a worker node fails, the master
node will schedule the pods on this faulty node to another normal worker node.

How Are Containers Used for 5G Core

Container Deployment
In Container section, we compare the features of containers and VMs. They are suited to different
scenarios.
Containers were first put forward and used in the IT field, and container capabilities have been improved
to cater for IT needs. However, IT and communication technology (CT) applications are essentially
different. Most IT applications are compute-intensive while CT ones are forwarding-intensive. IT
applications are data-oriented while CT ones are connection-oriented. IT players are self-operated. In the
CT field, carriers and suppliers collaborate. IT and CT fields have different requirements for multi-tenant
security.
Though containers have been widely used in the IT field, there are many challenges to applying containers
in the CT field. For example, container isolation is inadequate, and can hardly ensure multi-tenant security.
Containers do not support multiple network planes, such as the separately deployed control, user, and
management planes which are usually required by CT applications to guarantee reliability and security.
Containers need to be further strengthened to provide carrier-class reliability and performance. The
coordination among multi-vendor CT components relies on standard procedures and interfaces, but right
now industry standards are insufficient to guide the application of containers in the CT field and this
standardization is slow-paced.
To address these challenges, enhancements are required for various aspects of containers.
After weighing the pros and cons, we choose to use VM-based containers for 5G Core. Using VM-hosted
containers, the advantages of VMs and containers can be complementary. The VM solution focuses on
resource virtualization, whereas the container solution focuses on agile release. The combination of the
two solutions makes the solution more mature and stable.
Central DCs are usually large-scale, which lays a solid foundation for sharing resources. Carriers usually
need to deploy different applications from multiple vendors, and the multi-tenancy requires high security.
Control-plane applications take a large part of these applications, which calls for higher security and
reliability. Therefore, VM-based containers are the best choice for core DCs.

2025-04-25 81
Technology Series

Edge DCs are relatively small-scale. Resources are limited and fewer application types are deployed. Bare
metal-based containers can be considered in such scenarios after their maturity is verified for commercial
use.
There are three available deployment approaches:

• VM-based containers

• Containers based on manually installed bare metal servers

• Containers based on bare metal servers delivered by FusionSphere OpenStack on the NFVI

When high performance is required, FusionSphere OpenStack can be used to provision and manage bare metal servers
just like VMs.

The table below compares the three deployment approaches.

Item VM-based Containers Containers on Bare Metal Servers Containers on Manually
Delivered by NFVI Installed Bare Metal
Servers

Sharing NFVI Yes Yes No

with existing Such containers do not have Same as the VM-based Such containers cannot
VNFs special requirements for the containers. run in the original
existing NFVI and can run in the system, causing a waste
original system without of previous investments.
adaptation, preserving previous
investments.

Container Hardware differences are shielded The container management The container platform
platform from the upper-layer containers. platform is coupled with needs to manage
decoupled hardware. hardware.
from
hardware
infrastructur
e

Multi-vendor The NFVI is friendly to the The container platforms have not been standardized,
integration container management platforms hindering multi-vendor integration.
from different vendors.

Multi-vendor Tenants are isolated from one Tenants are isolated from one another by physical
isolation another by VM, which is flexible. machine, which is not so flexible.

Performance Similar to VMs. Similar to physical machines.

Reliability Container faults need to be Container faults need to be located by checking bare metal
located by checking VMs. servers.

2025-04-25 82
Technology Series

Item VM-based Containers Containers on Bare Metal Servers Containers on Manually

Delivered by NFVI Installed Bare Metal
Servers

Flexible Containers can be live migrated Containers cannot be live migrated.

resource through VMs.
managemen
t

FusionStage: Huawei's K8s-based Pod Management System

After taking a glance at the container technologies in the industry, you might wonder how Huawei
leverages containers. Can we deploy containers directly on the open-source K8s? It is not that simple. The
container management platform needs to suit the needs of efficient monitoring, fault locating, and
development in telecom scenarios.
The standardization of telecom cloud container management platforms is still in the early stage. Different
vendors build their own platforms by enhancing K8s. Huawei's enhanced container management platform
is FusionStage.
FusionStage is developed by the IT product line based on K8s and Docker. Huawei adheres to the win-win
concept and aims to build a mature platform for commercial use through persistent contributions to the
open-source communities.
The IT product line promotes FusionStage as a self-operation PaaS platform to power DevOps in the IT
field. It streamlines the process from development, operation, to maintenance. FusionStage encompasses
the application development pipeline, resource management and application life cycle management,
microservice runtime and governance framework, and cloud middleware services. The 5G Core solution
only requires resource management and application life cycle management.
Specifically, FusionStage is used to manage the onboarding, instantiation, scaling, O&M, and termination
of 5G Core containers.
The figure below illustrates the FusionStage architecture, in which the blue part is used by the 5G Core.

Changes Brought by FusionStage to the 5G Core

VM-based containers are used for the 5G Core. The figure below shows the overall system architecture of
the 5G Core.

2025-04-25 83
Technology Series

The 5G Core inherits the basic NFV architecture, where FusionSphere OpenStack, U2020/MAE, and eSight
are deployed on the management plane, and VNFs are deployed on the service plane. FusionStage is
introduced in 5G Core, and is the major difference from the NFV architecture.
FusionStage needs to be deployed independently. Its deployment process is similar to that of the VNFM.
FusionStage is usually deployed above VMs on the management nodes where FusionSphere, U2020/MAE,
and eSight reside.
The K8s master node is deployed on a management node during FusionStage installation. The worker
nodes are deployed as VMs during VNF installation. FusionStage manages these VMs and uses them to
deploy and manage containers.
Interfaces are added between the VNFM and FusionStage so that they can co-work to manage VNFs and
containers.

• The VNFM manages the VNF life cycles and provides an entry for container management. The VNFM
provisions VMs as k8s nodes for FusionStage. It manages TOSCA templates and transparently
transfers the templates to FusionStage for container deployment. It centrally manages container life
cycles and receives the alarms and KPIs of containers and FusionStage from FusionStage.

• FusionStage accesses VMs through the interface to the VNFM, and manages pod life cycles on these
VMs.

FusionStage can only use VMs. The VM life cycles are managed by the VNFM.

Container-based VNF Life Cycle Management

After containers are introduced, the 5G Core installation files are changed accordingly. The bare-metal-
based containers have not been widely used. This section only describes how to manage life cycles of VNFs
on VM-based containers.
The table below lists the files required to install VNFs on an NFV network.
Template VNFD template Describes the VNFs to be installed, including types, quantity,
and networks of VMs.

Image Guest OS image package Euler OS image package for VMs.

Software VUSN_Version Service software. Each VNF has one such package.
Package number_Install.zip

2025-04-25 84
Technology Series

The table below lists the installation files required to install VNFs on a 5G Core network.
Template VNFD Describes the VNFs to be installed, including types, quantity, and networks of VMs.
template

TOSCA Defines the containers to be installed, including the namespace, networks, and
template image repositories.

Image Guest OS Euler OS image package for VMs.

image
package

Pod image Image package of a group of container processes. The service software package
package for a VNF is split into several pod image packages, and these pod image packages
can be upgraded and maintained independently.
The pod image packages for a VNF may be combined as a software package for
commercial release.

The figure below illustrates how a VNF is deployed after NFVI and FusionStage are installed.

Deployment process:

1. The operator logs in to the VNFM, imports the VNFD and TOSCA templates as well as the guest OS
and pod image packages.

2. After receiving the VNF deployment request, the VNFM applies for the NFVI resources from
FusionSphere OpenStack.

3. The VNFM and FusionSphere OpenStack co-work to deploy VMs based on the VNFD template and
guest OS image package.

4. The VNFM instructs FusionStage to manage VMs. FusionStage loads the Docker, Kubelet, and Kube-
proxy components to K8s nodes. One VM is used for each K8s node.

5. FusionStage creates containers and pods required by the VNFs based on the TOSCA template and
pod image package.

The VNFM and FusionStage collaborate to manage container life cycles, including onboarding,
instantiation, upgrades, scaling, and termination. The procedures for these life cycle operations are similar.
The following figures only show the termination and manual scale-out procedures.
Termination procedure:

2025-04-25 85
Technology Series

Manual scale-out procedure: Before scale out pods, ensure that VM resources are sufficient. If VM
resources are insufficient, scale out VMs first.

1.12 5G Core Services

• Forewords

• NFSs

• Microservices

• NFS-Microservice Mapping

Forewords

On a 5G network, services are classified into two types:

• NF-provided services, which are called NF services (NFSs), as defined in 3GPP specifications.

• Microservices, which constitute software of the 5G core network products.

This chapter describes the functions, differences, and association of these services.

NFSs

A good analogy for NFSs provided by an NF is the skills an engineer masters. An engineer can have
multiple skills such as requirement analysis, code writing, documentation development, and function
testing. Similarly, each NF in service-based architecture (SBA) can have multiple capabilities, such as
session creation and data subscription. These NF capabilities are implemented by different NFSs.

2025-04-25 86
Technology Series

Table 1 describes the NFSs provided by the AMF and SMF.

Table 1 NFSs provided by the AMF and SMF

NF NFS NFS Description

AMF Namf_Communication Enables an NF to communicate with a UE or the (R)AN through the AMF.

Namf_Location Enables an NF to request location information or location change notifications.

SMF Nsmf_PDUSession Manages PDU sessions.

Nsmf_EventExposure Manages subscription data.

3GPP-defined NFS implementation is described as follows.

In SBA architecture, NFs interact with each other by invoking NFSs during service procedures.

As shown in Figure 1, the AMF invokes the Nsmf_PDUSession service of the SMF to create an SM context
in the PDU session establishment procedure.

Figure 1 NFS implementation

Generally, the operation of invoking an NFS is called service operation. Different NFSs can be used for
multiple operations after being invoked. For example, if an NF invokes the Nsmf_PDUSession service of an
SMF, the NF can create, update, and release an SM context. The corresponding service operations are
Create SM Context, Update SM Context, and Release SM Context.
In conclusion, NFS is a capability of an NF. The following describes when and how an NFS is invoked by an
NF.
Initial NF startup
When an NF becomes operative for the first time, it registers its NFSs with the NRF. When other NFs need
to communicate with the NF in service procedures, NFs use certain search criteria to query for and identify
this NF before interacting with it.
NF capability update
An NF can update its capabilities through software upgrades to extend its NFSs. After the capability is
updated, the NF sends the update request to update its capabilities to the NRF.
For details about the NFS autonomy mechanism, see "NFS Management and Discovery" in A Beginner's
Guide to 5G.
NFSs make NFs on a 5G network more scalable and flexible. They are also key factors for future expansion
of NF capabilities.

Microservices

2025-04-25 87
Technology Series

To adapt to the scalability and flexibility of the 5G core network, Huawei 5G Core solution uses the
microservice architecture. The microservice architecture consists of microservices and a service governance
framework.
Overview
Microservices are software entities that can independently complete a specific function. They are loosely
coupled and support independent release, deployment, upgrade, and O&M. Microservice combinations can
implement certain service functions.
Take the Huawei 5GC product UNC as an example. The UNC consists of the following microservices and
frameworks, as shown in Figure 2. Table 2 describes these microservices.

• Service microservices: microservices related to upper-layer service logic. For example, USN is
responsible for mobility management and access management functions.

• Link and interface microservices: microservices that distribute request messages between an external
system and microservices. For example, messages from the (R)AN need to be processed by the LINK
before being forwarded to the USN.

• Public microservices: microservices that provide public services for the system. For example, all
messages that are transmitted to the UNC can reach the target microservice only after being
processed and forwarded by the CSLB. The distributed data storage of microservices must be
processed by the CSDB.

• Microservice framework: runs multiple service governance microservices. It manages microservice

registration, communication, discovery, subscription, deregistration, and more, to ensure that the
system runs normally and reliably.

• O&M framework: runs multiple O&M microservices. It delivers configurations from the EMS or OM
Portal to microservices and reports microservice status information (such as alarms and processed
data) to the EMS or OM Portal.

Figure 2 UNC microservice framework

2025-04-25 88
Technology Series

Table 2 Microservices provided by the UNC

Category Microservice Microservice (Full Home NF Function

(Abbreviation) Name)

Service USN Unified Service Node SGSN, MME, Provides mobility and access
microservices and AMF management for 2G/3G/4G/5G
networks.

SM Session SMF Manages sessions and provides

Management charging functions.

NRF Network Repository NRF Provides all NRF functions.

Function

NSSF Network Slice NSSF Provides all NSSF functions.

Selection Function

SMS Short Message SMSF Provides short message service

Service (SMS) functions.

Link and interface SBIM Service-based AMF, SMF, Manages SBIs.

microservices Interface NRF, and
Management NSSF

NSIM Non Service-based SMF/GW-C Manages traditional interfaces.

Interface
Management

GTP GPRS Tunneling AMF and Manages GTP-C paths.

Protocol for SMF
Controlling

Public CSLB Cloud Session Load — Distributes mobile packets and

microservices Balancer provides load sharing.

VNRS Virtualized Network — Provides IP routing/forwarding.

Routing Service

CSDB Cloud Session — Stores, backs up, and

Database synchronizes data.

Huawei 5G Core products may have many microservices. As the 5G service ecosystem grows, microservices
may continue to increase. A complete mechanism is required to manage these microservices so that the
interaction and communication between microservices can be completed quickly, securely, and reliably.
Service Governance Framework
Huawei 5G Core solution provides a complete microservice governance mechanism built on its own
characteristics. This mechanism adopts a service governance framework for launch, registration,
communication, discovery, subscription, and deregistration of microservices to ensure that the system is
running properly and reliably. Figure 3 describes the microservice governance mechanism.

Figure 3 Microservice governance

2025-04-25 89
Technology Series

Table 3 Microservice governance

Microservice Description
Governance
Mechanism

Registration After the instantiation is complete, microservices USN1 and LINK1 need to register with
the service governance framework to establish their own legal identities in the system.
After that, they work as microservice instances in the system and can be discovered by
other microservices.

Discovery When microservice USN1 needs to communicate with other microservices, it needs to
send a request to the service governance framework to communicate with other
microservices.
For example, if USN1 needs to communicate with other microservices, it initiates a
request to the service governance framework, and describes the characteristics of the
target microservice. The microservice framework then finds the target microservice
according the described information and sends the information about the target
microservice (for example, LINK1) to USN1.

Inter-microservice After microservice discovery is complete, two microservices USN1 and LINK1 can
communication communicate with each other through the service governance framework.

Subscription USN1 can request the service governance framework to subscribe to other microservices
so that USN1 can learn about the status of specified microservices in a timely manner.
In this way, proper adjustment measures can be taken when the status of the subscribed
microservice changes, for example, the microservice becomes offline or faulty.
After receiving a subscription request, the service governance framework searches for
the target microservice according to the characteristics of the target microservice
described in the request information sent by USN1. If the subscribed microservice

2025-04-25 90
Technology Series

Table 3 Microservice governance

Microservice Description
Governance
Mechanism

already exists, the service governance framework returns the status information of the
subscribed microservice (for example, LINK2). Otherwise, the service governance
framework informs USN1 that the microservice to be subscribed does not exist. The
microservice instance status is pushed to the USN1 only after LINK2 goes online.

Deregistration When LINK2 goes offline due to pod deletion, LINK2 needs to deregister from the
service governance framework. After successful deregistration, the service governance
framework needs to notify other microservices (for example, USN1) that have
subscribed to the microservice.

The interaction between microservices is triggered by service procedures or prepared for services. The next
part describes mappings between upper-layer service functions and microservices.

NFS-Microservice Mapping

NFS-Microservice Mapping
As mentioned above, NFS is the capability of an NF and NFSs are implemented by microservices which are
carriers of software. For example, an AMF has four NFSs, Namf_Communication, Namf_EventExposure,
Namf_MT, and Namf_Location, which are implemented by the USN microservice. The SMF NFS
Nsmf_PDUSession is implemented by the SM microservice. The NRF NFSs are implemented by the NRF
microservice. The NSSF NFSs are implemented by the NSSF microservice, as shown in Figure 4.

Figure 4 Mapping between NFSs and microservices

In addition to NFSs, each NF has other capabilities. For example, an AMF needs to interact with the (R)AN
and obtain access control policies from the PCF. These functions are implemented by the LINK and SBIM
microservices.
In conclusion, 5G service functions need to be implemented through NF interactions. NFs interact with
each other by invoking their NFSs, and are ultimately implemented by interaction between microservices.
Interaction Between Microservices in Service Procedures

2025-04-25 91
Technology Series

The following uses a UE-initiated PDU session establishment procedure as an example to describe the
interaction between microservices that implement NFSs provided by an SMF.
The interaction between microservices in the following procedure is implemented through a service
governance framework. Interactions between microservices and a service governance framework are not
described here to simplify the description.

Figure 5 UE-initiated PDU session establishment procedure

The key steps are as follows:

1. The UE initiates a request to establish a PDU session. After receiving the request, the AMF requests
the NRF to select an SMF. After the SMF receives the message, the CSLB microservice performs load
balancing and forwards the message to the SBI management microservice SBIM, and finally reaches
the SM microservice for processing (1 -> 2 -> 3 -> 4 -> 5).

2. After receiving the message, the SM microservice performs PDU session registration and subscription
on the UDM and obtains the subscription data related to the DNN (6 -> 7 -> 8).

3. After obtaining the subscription data, the SM microservice sends an

Nsmf_PDUSession_CreateSMContext Response message to the AMF (9 -> 10 -> 11).

4. The SM microservice sends an Npcf_SMPolicyControl_Create Request message to the PCF to obtain

the corresponding policy (12 -> 13 -> 14).

5. After receiving the request, the PCF sends an Npcf_SMPolicyControl Create Response message to the
SMF and the message finally reaches the SM microservice through the CSLB and SBIM microservices
(15 ->16 -> 17).

6. After receiving the response, the SM microservice sends a PFCP Session Establishment Request
message to the UPF, requesting to establish a PDU session (18 -> 19 -> 20).

7. After receiving the request, the UPF sends a PFCP Session Establishment Response message to the
SMF and the message finally reaches the SM microservice through the CSLB and NSIM microservices
(21 -> 22 -> 23).

2025-04-25 92
Technology Series

1.13 5G Core Charging

• Forewords

• Charging on 5G NSA Networks

• Charging Scope and Charging Type

• CHF Selection

• Charging Event

• Summary

Forewords

The previous chapters looked at 5G network architecture and 5G NFs and how this leads to more 5G
networks being launched and new business models being unlocked. This chapter looks at how operators
can charge customers for their services.
To begin with, we will look at how the core network charging solution is continuously adapted to network
evolution.

On a 4G or 5G NSA network, the charging gateway (CG) performs offline charging — which collects
charging information and generates charging data records (CDRs), while the online charging system (OCS)
performs online charging — which collects charging information and controls account credit.

2025-04-25 93
Technology Series

On a 5G network, the charging function (CHF) is introduced to combine the conventional CG and OCS and
provide both online and offline charging, which is known as converged charging. This chapter will explain
how converged charging is implemented in compliance with 3GPP Release 15.

Charging on 5G NSA Networks

On an NSA network, 5G services can be flexibly charged with or without 2G, 3G, and 4G services.

In an NSA architecture, UEs use different RATs to access the core network through gNodeBs or eNodeBs.
The core network cannot obtain the RATs, and therefore cannot distinguish 5G traffic from other traffic. If
5G services need to be separately charged, the gNodeBs need to be configured to collect statistics on 5G
traffic and report them to the CG through the control plane. However, this solution does not support
online charging or flow-based charging (FBC), with the latter now becoming a popular choice for
operators. Therefore, charging 5G services together with 2G, 3G, and 4G services is advised.
Charging on 5G SA Networks
As the core network shifts towards 5G SA architecture, a converged charging system comes in to combine
offline and online charging and uses unified service-based interfaces (SBIs).
The new charging framework introduces several NFs, such as the CHF, which is a combination of the CG
and OCS. Furthermore, the Nchf interface is added to replace the previous Gy and Ga interfaces. Despite
these changes, the converged charging system and conventional online and offline charging systems are
used essentially for the same purpose, that is, to charge for traffic usage by volume or duration, collect
information such as the RAT, QoS, and URL information, and perform credit control for online charging
services.
The following looks at how the separated charging systems are converged.

2025-04-25 94
Technology Series

The figure shows that the CHF integrates the account balance management function (ABMF) and rating
function (RF) of the OCS for online charging and the charging gateway function (CGF) of the CG for
offline charging.
This transition conforms to the service-based architecture (SBA) used by the 5G Core, facilitating the
cloudification of IT systems and flexible commercial deployment of charging systems. Additionally, the
converged charging solution resolves inconsistent charging results of separated online and offline charging.
The CHF both manages quotas and generates CDRs, to ensure that consistent data is used throughout the
entire charging process.
Moving on to the bigger picture, we will see how charging-related NFs interact with other 5G Core NFs.

NF Function

SMF Processes charging parameters delivered by the CHF, collects quota usage and service usage for each
charging event, and reports them to the CHF.
Monitors service quotas for online charging.
Delivers quotas and charging parameters, in addition to reporting the quota usage, to the UPF over the
N4 interface.

PCF Delivers charging policies to the SMF.

CHF Performs rating, deducts the account balance, and delivers quotas and charging parameters for online
charging.
Delivers charging parameters for offline charging.
Processes the quota usage reported by the SMF and generates CHF-CDRs.

UPF Measures subscriber quota usage based on the charging parameters and quotas delivered by the SMF. It
then reports the quota usage to the SMF when trigger conditions are met.

These NFs interact with each other through 3GPP-defined service operations over SBIs.

2025-04-25 95
Technology Series

Operation Function Sender 5G Message 4G

Message

Nchf_ Establishes a charging session. SMF Charging Data CCR-

ConvergedCharging_Create Request/Response I/CCA-I
[Initial]

Nchf_ Updates a charging session, SMF Charging Data CCR-

ConvergedCharging_Update such as applying for a new Request/Response U/CCA-U
quota or reporting a quota [Update]

Nchf_ Terminates a charging session. SMF Charging Data CCR-

ConvergedCharging_Release Request/Response T/CCA-T
[Termination]

Nchf_ Sends a notification for CHF- CHF Charging Notify RAR/RAA

ConvergedCharging_Notify initiated session Request/Response
reauthorization or deactivation.

The following figure shows message exchanges between the preceding NFs.

1. After receiving a PDU session establishment request from a UE, the SMF applies for a charging rule
from the PCF. The returned charging rule includes the charging type and scope.

2. The SMF selects a CHF based on predefined priorities.

3. The SMF applies for a quota from the CHF, which returns the quota and trigger condition.

4. The SMF delivers the charging rule, trigger condition, and related parameters to the UPF.

5. The UE initiates a service request. The UPF matches service packets against the charging rule, and
reports the quota usage for the matched traffic to the SMF.

2025-04-25 96
Technology Series

6. The SMF reports the quota usage to the CHF and then applies for a new quota. Before the UE is
deactivated or the account balance is finished, the charging information is reported and the quota is
updated for each service use.

Now, we will look into the key concepts (highlighted in red in the preceding figure) involved in a charging
process.

Charging Scope and Charging Type

Converged charging can be PDU session based or service based.

Charging Description
Scope

PDU session All services of a PDU session use the same rating group (RG).

Service flow Service flow-level charging, or FBC, is a type of service-based charging. Different services use
different RGs.

QoS flow Different QoS flows use different RGs for roaming subscribers.

There are two charging types:

1. Online charging: The SMF requests a quota and charging parameters from the CHF during PDU
session establishment.

2. Offline charging: The SMF only requests charging parameters from the CHF during PDU session
establishment.

Different charging scopes and charging types can coexist. The following figure shows that only online
charging is used for PDU session 2 and only offline charging is used for PDU session 3, while both are used
for PDU session 4.
Operators currently use only one charging type for each subscriber, but in the future, they may adopt
different charging types for different services of each subscriber. For example, online charging for standard
services and offline charging for free services. In this case, offline charging is implemented only to collect
charging and service usage information.

CHF Selection

2025-04-25 97
Technology Series

When multiple CHFs are deployed, the SMF selects a CHF using approach 1, 2, 3, or 4, as shown in the
figure below.

1. The SMF selects a CHF based on the fully qualified domain name (FQDN) delivered by the PCF.

2. The SMF selects a locally configured CHF based on the subscribed charging characteristic (CC)
obtained from the UDM.

3. The SMF requests the NRF to discover a CHF.

4. The SMF selects a locally configured CHF based on the locally configured CC.

For more details, see 3GPP TS 32.255.

Charging Event

A charging event is a trigger condition that the CHF delivers to the SMF. The SMF applies for new quotas
or reports used quotas to the CHF when this condition is met. For example, when a service's traffic reaches
a specified threshold, the SMF requests the CHF to update the charging session and obtains a new quota.
Trigger conditions are classified as follows:
By charging scope:

• PDU session: A PDU session trigger condition takes effect for all RGs in a PDU session.

• RG: An RG trigger condition takes effect only for the current RG.

By report type:

• Immediate: When an immediate trigger condition occurs, the SMF needs to immediately report the
quota usage to the CHF.

• Deferred: When a deferred trigger condition occurs, the SMF temporarily stores the quota usage
corresponding to the current trigger condition, and reports the quota usage when the next immediate
trigger condition occurs.

On the SMF, the trigger conditions used and their report types can be defaulted. The SMF can also use the
trigger conditions delivered by the CHF, which have priority over those locally configured trigger
conditions. Not all locally configured trigger conditions and report types on the SMF can be modified.

2025-04-25 98
Technology Series

Most charging events on 2G, 3G, and 4G networks are immediately reported, whereas 5G converged
charging allows operators to define different report types for different services to reduce the burden on
signal and improve network performance. The table below lists two trigger condition examples.
Trigger Condition Charging Default Report Changed by the Enabled/Disabled by the
Scope Type CHF CHF

UE location changed Session/RG Deferred Yes Yes

Volume threshold RG Immediate No Yes

reached

The following figure illustrates how the aforementioned functions are used together to charge a subscriber
for 5G services.

An account has been created for subscriber A using online charging. The subscriber topped up US$100 and
subscribed to a service plan that includes:

• A basic traffic package for standard services, which charges US$0.1 per MB under RG 1.

• A sponsored traffic package for a news app, which charges US$10 per GB under RG 2.

1-2: UE A is powered on and initiates a PDU session establishment request. After receiving the request, the
SMF requests RGs and charging types for the UE from the PCF. The PCF notifies the SMF of the required
charging information (online charging for both RGs 1 and 2) based on the subscription details.
3: The SMF applies for quotas from the CHF. The CHF then checks the account balance, creates a CDR, and
delivers the quotas and trigger conditions for the two traffic packages to the SMF.
The CHF assigns a quota of 50 MB for the basic traffic package and 30 MB for the sponsored traffic
package. It delivers the same trigger condition for both packages, that is, when the remaining quota
decreases to 10 MB, a charging event will be immediately reported.
4: The SMF sends the quotas and trigger conditions to the UPF.
5: The subscriber uses the news app. The UPF parses the resulting service packets, and starts the counter to
record the app's traffic.
6: The app generates 20 MB traffic, meeting the trigger condition. The UPF reports the charging
information to the SMF, which then passes it onto the CHF and requests a new quota.
7: The CHF updates the CDR based on the charging information and delivers another quota of 30 MB to
the UPF. Along with the quota update, the UPF provides services to the UE and continues charging. During
this process, 5 MB is consumed, which will be deducted from the new quota.

2025-04-25 99
Technology Series

As the subscriber continues to use services, this process repeats. The UPF and SMF keep reporting charging
information and requesting quotas until the UE is powered off or the account balance becomes
insufficient.
Charging Reliability
Reliable charging is vital to the revenue of operators. To ensure reliable converged charging, the CHFs are
deployed as active/standby pairs.

If the active CHF is faulty, the SMF sends the charging information to the standby CHF, and switches back
to the active CHF once it recovers.

If both the active and standby CHFs are faulty, either of the following solutions can be used:

1. Services are still provided to users, but will not be charged. This solution provides a smooth service
experience to subscribers, and therefore is recommended in the early construction phase of 5G.
However, CDRs cannot be generated, which may influence an operator's revenue.

2. PDU sessions are deactivated, and services are not provided for subscribers. This solution will
deteriorate service experience.

4G-5G Interworking
Setting up a 5G network is a long process and therefore 4G-5G interoperation will be needed in the early
construction phase.
If the N26 interface is used for 4G-5G interworking, the PGW-C and SMF must be co-located, and together
they use the N40 interface to interwork with the CHF. This means that the PGW-C will implement
converged charging with the same mechanism and interface as the SMF.
The SMF interacts with the CHF through an SBI to charge subscribers for 5G SA services when their UEs
are in 5G NR coverage, fall back to 4G coverage, and attach to 4G networks.

Summary

Converged charging must be flexible enough to cope with the rise of 5G applications and innovative
business models and be able to charge services based on latency, rate, connection quantity, slice, and QoS,
for example. The converged charging system must fit into the ever-advancing industry ecosystem, helping
operators capitalize on not only traffic, but also differentiated service experience.

1.14 UPF Selection Issue

• Forewords

• When Is the UPF Needed?

2025-04-25 100
Technology Series

• UPF Roles

• Principles

• UPF Selection in Different Service Scenarios

• Summary

Forewords

To begin this chapter, let's look at the following figure. 5G enterprise subscribers (for example, subscriber
A), take a high-speed train from city A to city B while continuously watching live videos on their mobile
phone. After arriving at city B, they take a taxi to their company's campus and access the enterprise private
network to process administrative services.

How is subscriber A able to watch live videos without interruption and switch between services on the
campus network and the Internet? The User Plane Function (UPF) plays an important role.
The UPF identifies and controls services based on the policies delivered by the SMF, generates downlink
routes, and forwards data packets. It works with the control plane to provide services for subscribers.

As such, it is key to select a UPF that fits the given service scenario.
This chapter will look at how the UPF is selected.

2025-04-25 101
Technology Series

When Is the UPF Needed?

When the subscriber in the previous example moved from city A to city B, the base station initiated a
handover based on the signal strength. If the subscriber leaves the coverage of the anchor UPF in city A, a
new I-UPF needs to be inserted to ensure uninterrupted video services.
When the subscriber arrives at the campus in city B and accesses the enterprise private network in the
campus for administrative service processing, the UL CL UPF identifies and steers service flows to the local
PSA UPF for processing, keeping service traffic at the edge.
UPFs with different roles are selected throughout subscriber A's movement.

• When the subscriber accesses a DN, the SMF selects the primary PSA UPF during PDU session
activation, and assigns an IP address to the UE to establish a PDU session.

• When they leave the coverage of the original UPF, the SMF selects an I-UPF to continue providing
services.

• When they access a local DN, the SMF selects UL CL UPF+secondary PSA UPF, which locally processes
data accessing the local DN.

UPF Roles

You might be confused about the differences between UPFs in the 5G Core. After all, on a 4G network with
CUPS architecture, only the SGW-U and PGW-U are available to provide the user plane function. Why are
there more types of UPFs on the 5G Core?
Let's first look at the roles of these UPFs.
UPF Role Description Scenario

PDU session A UPF connected to a DN over the N6 interface. The PGW-U and SGW-U are
anchor (PSA) A primary PSA UPF connects to the central DN. A secondary co-deployed on networks
UPF PSA UPF connects to the local DN.

2025-04-25 102
Technology Series

UPF Role Description Scenario

supporting 4G-5G
interworking with a PSA UPF.

Uplink classifier A UPF that supports traffic steering and can forward local A UL CL UPF is used in
(UL CL) UPF services to the local PSA UPF. IPv4/IPv6 PDU session
The UL CL UPF connects to a PSA UPF over the N9 interface. scenarios.
The UL CL UPF identifies and forwards the uplink packets to
be sent to the primary and secondary PSA UPFs based on
traffic steering rules. It aggregates packets from PSA UPFs
and forwards them to the base station over the N3 interface.

Branching point A UPF that supports BPs and can forward IPv6 multi-homed The BP UPF applies to IPv6
(BP) UPF PDU session data to different PSA UPFs. multi-homed PDU sessions.

Intermediate Any UPF that connects the (R)AN and PSA UPF. An I-UPF refers to any
UPF (I-UPF) intermediate UPF between
the (R)AN and PSA UPF,
including UL CL UPF and BP
UPF.

Let's look at the positions of different types of UPFs on the network.

The following figures show the positions of UPFs with different roles on a network.

A 5G Core network has its control plane and user plane separated using the CUPS architecture. UPFs can
also be distributed under this architecture and can be located in the central data center (DC), local DC, or
edge DC closer to subscribers. These options meet a diverse range of service requirements. Where to
deploy a UPF depends on how much latency, bandwidth, or reliability is needed. For example, in latency-
sensitive scenarios (such as autonomous driving), the UPF needs to be deployed at the edge to be closer to
subscribers.
Subscribers need to access local edge or regional services and central data services (such as the Internet)
at the same time. To achieve this, 5G introduces UL CL UPF and BP UPF to steer service data.

2025-04-25 103
Technology Series

If a subscriber moves from a network center location (a PSA UPF coverage area) to an edge location (a
non-PSA UPF coverage area), the UPF cannot be changed to ensure service continuity during a PDU
session. This is where an I-UPF comes in. During session activation, if the location area served by the
selected primary PSA UPF does not cover the current location area of the UE, the I-UPF needs to be
inserted.
The UL CL UPF and BP UPF have been introduced in addition to the PSA UPF (4G PGW-U) and the I-UPF
(4G SGW-U) as networks have evolved and service requirements change.

Principles

Now that we have learned UPFs roles in different service scenarios, let's see how the target UPF is selected.

1. The SMF first selects UPFs that meet mandatory conditions.

2. The SMF then selects UPFs from these based on preferred conditions.

Conditions for selection of UPFs vary with UPF roles, as shown in the following figure. This is also related
to UPF functions. For example, to ensure service continuity in SSC mode 1, the primary PSA UPF selected
for a UE is fixed during UE movement. As such, the location area of the UE is not used as a condition
determining when the primary PSA UPF is to be selected.

2025-04-25 104
Technology Series

• The UNC determines whether to continue the selection only after the selection based on mandatory
conditions is complete.

• The mandatory conditions have no order of priority. The priority of preferred conditions can be set
using commands.

• If multiple UPFs in the returned result meet the mandatory and preferred conditions, the UPF is
ultimately selected based on the UPF weight.

• If only one UPF is selected in any round, no further selection is required.

The following table describes the mandatory conditions and their sources.

Mandatory Description
Condition

UE DNN The DNN supported by the peer UPF is configured based on the network plan. When a UE
information sends an activation request message, the SMF obtains the UE DNN information from the
activation request, and selects a UPF that matches the DNN in a list of DNNs supported by
UPFs.

UE slice The service slice supported by the peer UPF is configured on the SMF based on the network
information plan. When a UE sends an activation request message, the SMF obtains the UE slice
information from the activation request, and selects a UPF that meets the service slice in a
list of service slices supported by UPFs.

PDU session The PDU session type supported by the peer UPF is configured on the SMF based on the
type network plan. When a UE sends an activation request message, the SMF obtains the UE's
PDU session type from the activation request, and selects a UPF that matches a PDU session
type in a list of PDU session types supported by UPFs.

UE location Location area names and the UPFs in the location areas are configured on the SMF. When a
area UE sends an activation request message, the SMF obtains the UE's location area information
information from the activation request, and selects a UPF in the same location area.

DNAI The DNAI supported by the peer UPF is configured on the SMF based on the network plan.
information When a UE sends an activation request message, the SMF obtains the DNN from the
activation request, obtains the DNAI mapped from the DNN, and selects a UPF that meets
the DNAI in a list of DNAIs supported by UPFs.

2025-04-25 105
Technology Series

Mandatory Description
Condition

UPF Function The function of the peer UPF (whether the UPF supports the UL CL/BP function) is
configured on the SMF based on the network plan. A UPF that meets the condition is
selected based on the network plan and service requirements.

UPF interface The SMF selects a UPF that meets the interface capability contained in association messages
capability reported by the UPF. For example:
The primary PSA UPF must support the Pa interface.
The I-UPF must support the N3 and N9 interfaces.
The primary PSA UPF+I-UPF and UL CL UPF+secondary PSA UPF must support the Pa, N3,
and N9 interfaces.
Note: The Pa interface in this document refers to the N9a+S5/S8-P interface, and the N9
interface refers to the N9c interface.

Preferred Description
Condition

Combined UPF The SMF can preferentially select a combined UPF based on the network plan to reduce
traffic and signaling transmission delay. The UPF can be SGW-U/PGW-U, primary PSA UPF+I-
UPF, secondary PSA UPF+UL CL/BP UPF, or primary PSA UPF+secondary PSA UPF+UL CL/BP
UPF.

UPF location UPF locations are bound to their serving areas on the SMF. When a UE sends an activation
information request message, the SMF obtains the UE location information from the activation request
and then obtains the name of the location area to which the UE belongs. The SMF then
preferentially selects a UPF that serves the location area for the UE.

Payload The SMF determines the load status of UPFs based on the information contained in
association messages reported by UPFs and preferentially selects a UPF with a low load.

Weight The weight of the peer UPF is configured on the SMF based on the network plan. The weight
indicates the UPF capacity. When multiple UPFs meet the selection conditions, the SMF may
preferentially select a UPF based on the UPF weight. The greater the weight, the more likely
a UPF is selected.

UPF Selection in Different Service Scenarios

The following uses Internet access as an example to describe how the SMF selects a UPF. When a UE
accesses an Internet data network, the SMF needs to select a UPF during PDU session establishment. The
UPF selection procedure is as follows.

2025-04-25 106
Technology Series

Summary

This chapter looked at how a user plane is selected to work with the control plane to provide services for
subscribers when they access 5G networks. The PGW-U/SGW-U must be co-deployed with the PSA UPF in
4G-5G interworking.
The UPF selection principles and methods in different service scenarios during 4G-5G interworking are the
same as those when 5G subscribers access 5G networks. The only difference is that the selected UPF must
support 4G-5G interworking. That said, the UPF that is co-deployed with the PGW-U/SGW-U is selected as
the primary PSA UPF.

As networks evolve, more UPFs roles are added to deliver better services. Each role has its own function.
UPF types and their selection conditions vary between scenarios.

1.15 SMS Issue

• What Was the Early SMS Like?

• What Is Today's SMS Like?

• SMS with 5G

• SMS over IP

• SMS over NAS

• Summary

What Was the Early SMS Like?

Definition
The short message service (SMS) is one of the fundamental telecommunication services provided by
operators and value-added service providers.
The legacy SMS is characterized by:

• Limited length: A point-to-point SMS and a broadcast SMS can deliver a maximum of 140 and 82
bytes, respectively. If the message exceeds its size limit, the system automatically splits the message
content and sends multiple short messages.

2025-04-25 107
Technology Series

• Latency- and bandwidth-insensitive: The SMS is not a connection-oriented service. It poses low
requirements on both bandwidth and latency.

• SMS buffer-capable: If paging the called party fails, the system buffers the short message. The system
does not forward the short message again until paging the called party succeeds.

• Independent of voice services: A subscriber can receive short messages regardless of whether the
subscriber is in the idle or connected state.

Development Milestones

• 1G marks the birth of mobile communications. At the time, a mobile communications network would
rely on analog technologies and was independent from the Internet. The SMS was not officially
defined on 1G networks. Subscribers used pagers to exchange text information.

Figure 1 SMS in 1G

• 2G leveraged digital communications technologies on mobile networks and provided SMS for
subscribers. In 2G, mobile voice services were expensive because both calling and called parties were
charged. The SMS therefore experienced fast proliferation in 2G. The advent of 3G led to a sharp
decrease in data service fees. Moreover, the popularity of smartphones and emergence of over-the-
top (OTT) applications further made exchanging texts, images, audio, and other multimedia
information simple. SMS was gradually made obsolete by all kinds of instant messaging software and
saw business trough.

Figure 2 SMS in 2G/3G

2025-04-25 108
Technology Series

In 2G, a GSM network consists of only CS domains. On a CS domain, the predominant NE is the MSC
server. The protocol defines how the MSC server works with the SMSC to provide point-to-point SMS
on a GSM network. With the continuous development of the GSM network, the 2.5G and later mobile
communications networks allowed subscribers to use GPRS services to access the Internet. To this end,
the PS domain was introduced. In a PS domain, the predominant NEs are SGSN and GGSN. In addition
to providing access to the Internet, the PS domain can interwork with the SMSC via the SGSN. In this
way, subscribers could still send short messages over the CS domain or send multimedia short
messages over the PS domain. Figure 3 illustrates the networking for providing the SMS for 2G/3G
subscribers.

Figure 3 SMS solution in 2G/3G

2025-04-25 109
Technology Series

• 4G offers abundant bandwidth resources to bear audio, video, and online gaming services. The SMS,
to adapt, changed its business model to serve subscribers. Subscribers themselves do not send short
messages as much as they did in 2G/3G. However, now they receive them. If you check your SMS
inbox on your mobile phone, you will see many short messages from applications, enterprises,
operators, and other organizations. These short messages deliver notices, such as package delivery
information, to subscribers.

Figure 4 SMS in 4G

The core network structure underwent significant changes in 4G. The 4G core network, also called the
EPC, consists of the MME, PCRF, and SAE-GW (System Architecture Evolution gateway + Serving

2025-04-25 110
Technology Series

gateway + PDN gateway). The EPC does not have a CS domain. Therefore, voice calls must fall back to
2G/3G networks or bear on IMS networks. Subscribers still preferred voice services provided by OTT
applications. The SMS can be provided by the IP-SM-GW and SMSC on the IMS network. Alternatively,
the MME in the EPC can work together with the SMSC to provide the SMS.

Figure 5 SMS scheme in 4G

What Is Today's SMS Like?

You may be wondering why SMS has not been abolished in 4G/5G.
There are many reasons for this, but the main concern is because of cyber security. Although 4G
communications technologies bring great convenience for subscribers to access information, subscribers
are at the same time subject to information leakage and telecommunications fraud. Compared with OTT
services, the legacy SMS is more secure. This is because an IMSI that can uniquely identify a subscriber is
used to provide the legacy SMS. In contrast, IP addresses are used as user identities during OTT services. It
is difficult to identify subscribers using IP addresses. Therefore, legacy SMS is still used by enterprises and
governments to deliver user identity, package delivery, transaction, and password information.

SMS with 5G

5G is ushering in a fully interconnected world that will radically change the way we live and work. At the
heart of this technology is Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communications

2025-04-25 111
Technology Series

(mMTC), and Ultra-Reliable Low-Latency Communication (URLLC). The following solutions are brought
about to fit SMS requirements in 5G:

• SMS over NAS

In this solution, short messages are routed over the PS network, and signaling is transmitted over the
non-access stratum (NAS) layer. This solution applies to terminals using data cards, Internet of Things
(IoT) terminals, and customer-premises equipment (CPE) in the mMTC scenarios. The short message
service function (SMSF) is introduced in the SMS over NAS solution. The SMSF interacts with other
control-plane NFs over SBIs using HTTP/2. The SMSF converts HTTP/2 and MAP signaling and
forwards short messages to bridge the 5G core and SMSC.

• SMS over IP
This solution is inherited from 4G. It applies to subscribers who use mobile terminals and have
subscribed to IMS services. The SMS over IP solutions used on 4G and 5G networks are similar. On a
5G network, short messages are transmitted through the UPF.

• Rich Communication Suite (RCS)/5G SMS

The RCS is an E2E all-IP solution and is also known as the converged communication service. In this
solution, a 5G message center (5GMC) is deployed to provide multimedia, bulk messaging, and group
messaging services. The Messaging as a Platform (MaaP) service provides the SMS interface between
enterprise and individual users. It also supports the chatbot service. This solution extends the service
portfolio of the legacy SMS and fits in with various requirements of different industries.

The following table lists the similarities and differences between these three 5G SMS solutions.

Table 1 5G SMS solution comparison

Solution All-IP Involved Applies Positioning Advantages

or Not NF/NE Only in 5G

RCS/5G Yes RCS AS No Target solution App-free

SMS
Requires no collaboration with the
SMSC

SMS over No IP-SM-GW No Transitional solution for Requires collaboration with the SMSC
IP providing SMS for
subscribers Access-agnostic, requires no
collaboration with EPC/5GC NEs/NFs

SMS over No SMSF Yes SMS solution for IoT Requires collaboration with the SMSC
NAS applications and mMTC
scenarios Transmits short messages over the
NAS layer; similar to the SMS over
SGs solution used in 4G

The RCS project was proposed by the Global System for Mobile Communications Association (GSMA) in
2007 and was officially founded in 2008. According to the 5G Message White Paper jointly released by
three major operators in China, RCS is the long-term goal and operates on an IMS network.
We will focus on the SMS over IP and SMS over NAS solutions in the following section.

2025-04-25 112
Technology Series

SMS over IP

The SMS over IP solution was born on a 4G network and has vastly matured since its conception. SIP is
used for communication between IMS NEs. When an LTE subscriber sends an IP short message, the IP-SM-
GW converts this SIP-compliant short message to the MAP-compliant short message that can be processed
by the SMSC deployed on a CS domain. The SMSC then buffers and forwards the short message to the UE.
When using the SMS over IP solution on a 5G network, the IP-SM-GW is still responsible for converting
short messages. Principles of implementing the SMS over IP solution on 4G and 5G networks are similar.
The only difference lies in the device forwarding the IP short messages. Figure 6 and Table 2 illustrate the
service flows of implementing the SMS over IP solution on 4G and 5G networks.

Figure 6 SMS over IP on 4G and 5G networks

Table 2 Comparison of SMS over IP on 4G and 5G networks

Solution Registration SMMO SMMT

4G SMS The UE attached to the The UE sends a The SMSC obtains the data for routing the
over IP EPC through the eNodeB MESSAGE request to short message from the HLR/HSS, and the
and S-GW/P-GW. the IP-SM-GW through terminating IP-SM-GW selects a domain to
the P-CSCF/S-CSCF. which the short message is routed.
The UE sends a REGISTER
message to register with The IP-SM-GW delivers If the terminating domain is CS, the MSC
the IMS network. the short message to server forwards the short message to the
the SMSC. UE. If the terminating domain is IMS, the P-
CSCF/S-CSCF forwards the short message to
the UE.

5G SMS The UE performs initial The UE sends a The SMSC obtains the data for routing the
over IP registration to register with MESSAGE request to short message from the HLR/HSS, and the

2025-04-25 113
Technology Series

Table 2 Comparison of SMS over IP on 4G and 5G networks

Solution Registration SMMO SMMT

the 5GC through the the IP-SM-GW through terminating IP-SM-GW selects a domain to
gNodeB and UPF. the P-CSCF/S-CSCF. which the short message is routed.
The UE sends a REGISTER The IP-SM-GW delivers If the terminating domain is CS, the MSC
message to register with the short message to server forwards the short message to the
the IMS network. the SMSC. UE. If the terminating domain is IMS, the P-
CSCF/S-CSCF forwards the short message to
the UE.

SMS over NAS

Next, let's focus on the SMS over NAS solution in 5G.

• Application scenario
Take the water quality sensor connected to an IoT network as an example. The sensor does not need
to frequently send and receive short messages. Instead, it periodically sends NAS short messages
delivering collected information.

Figure 7 Delivering short messages by sensors

1. To register with the 5GC, the sensor sends a registration request with the SMS over NAS IE to
the AMF.

2. The AMF registers with the UDM and obtains the SMS subscription data of the UE.

3. The AMF sends a message to the SMSF to activate the SMS over NAS function.

4. The SMSF registers with the UDM and obtains SMS subscription data.

5. The SMSF notifies the sensor of the registration success through the AMF.

6. After that, the sensor can periodically send NAS short messages to the SMSF via the AMF, and
then the SMSF transmits the short messages to the SMSC. The SMSC processes the short
messages and sends them to corresponding receivers.

• Concepts
NAS: channels service and signaling messages between the core network and UEs.

2025-04-25 114
Technology Series

SMSF: provides the following functions in the SMS over NAS solution:

• Manages subscriber data, transfers short messages, and converts between HTTP/2 and MAP.

• Forwards short messages from UEs to the SMSC.

• Forwards short messages from the SMSC to UEs.

• Networking and interfaces

The following figure shows the SMS over NAS networking and related protocols.

Figure 8 SMS over NAS networking

Table 3 Interfaces between the SMSF and peer devices

Peer Interface Interface Protocol and Interface Function

Device Type Protocol
Stack

SMSF <- SBI N20 HTTP/2 The SMSF obtains UE capability information and transparently
> AMF transmits short messages over this interface. Registration and
deregistration information, as well as NAS short messages, are
transmitted over this interface.

SMSF <- SBI N21 HTTP/2 The SMSF obtains UE's NAS subscription data from the UDM
> UDM over this interface.

SMSF <- SBI - HTTP/2 The SMSF registers its information with the NRF over this
> NRF interface.

SMSF <- Non-SBI E MAP The SMSF transparently transmits MO and MT SMS messages
> SMSC to the SMSC over this interface.

• Service flows

• Registration: The UE registers with the SMSF. The SMSF registers with the UDM, obtains the UE's
subscribed SMS capability, and subscribes to the SMS capability changes.

Figure 9 Registration during the SMS over NAS service

2025-04-25 115
Technology Series

• Deregistration: The SMSF deletes the UE's SMS context information, unsubscribes to the UE's SMS
capability changes, and deregisters from the UDM.

Figure 10 Deregistration during the SMS over NAS service

• SMMO: A UE sends a short message to the SMSC.

Figure 11 SMMO procedure

• SMMT: The SMSC forwards a short message to the receiver.

Figure 12 SMMT procedure

2025-04-25 116
Technology Series

• Comparison between SMS over NAS and SMS over IP solutions

Figure 13 illustrates the networking of the SMS over NAS and SMS over IP solutions.

Figure 13 SMS over NAS and SMS over IP networking

Table 4 Comparison between SMS over NAS and SMS over IP solutions

Solution Registration SMMO SMMT Application Deployment

Scenario Requirement

SMS The UE performs The UE sends The SMSC obtains the Subscribers who The IMS network
over IP initial registration to a MESSAGE data for routing the attempt to send must be
register with the 5GC request to short message from short messages deployed, and
through the gNodeB the IP-SM- the HLR/HSS, and the using mobile data for
and UPF. GW through terminating IP-SM- terminals interworking with
GW selects a domain the P-CSCF/S-

2025-04-25 117
Technology Series

Table 4 Comparison between SMS over NAS and SMS over IP solutions

Solution Registration SMMO SMMT Application Deployment

Scenario Requirement

The UE sends a the P- to which the short CSCF must be

REGISTER message to CSCF/S-CSCF. message is routed. configured.
register with the IMS
The IP-SM- If the terminating
network.
GW delivers domain is CS, the
the short MSC server forwards
message to the short message to
the SMSC. the UE. If the
terminating domain is
IMS, the P-CSCF/S-
CSCF forwards the
short message to the
UE.

SMS The UE performs The UE sends The SMSC forwards Terminals using The SMSF must
over initial registration an NAS short the short message to data cards, be deployed.
NAS with the 5GC. The message to the SMSF. Internet of
AMF obtains the UE's the SMSF via Things (IoT)
The SMSF terminals, and
SMS subscription data the AMF.
transparently customer-
and SMSF information
The SMSF transmits the NAS premises
from the UDM, and
delivers the short message to the equipment (CPE)
the SMSF obtains the
short UE through the AMF. in the mMTC
UE's SMS subscription
message to scenarios
data from the UDM.
the SMSC.

Summary

We can see from its history that the SMS solution evolves along side the progress of mobile networks.

Though the SMS is no longer the first choice for communication between people, it still plays an
indispensable role on an Internet of Everything (IoE) network. In addition, operators expect that the RCS
(5G SMS) solution can bring new business value to the SMS.

2025-04-25 118
Technology Series

1.16 IPv6 Issue

• Background

• What Is IPv6?

• Deploying IPv6

• IPv6 Implementation on UEs

• IPv6 Implementation on Servers

• IPv6 Implementation on 5G Core NFs

Background

In 1981, Internet Protocol version 4 (IPv4) was defined in the publication RFC 791 to provide numerical
addresses to every device to enable them to communicate over the Internet. As it is simple, easy to
implement, and facilitates interoperability, IPv4 has been extensively used worldwide. Theoretically, IPv4
supports 4.3 billion addresses. However, due to the explosive growth of device connections and uneven
address allocation, IPv4 addresses are quickly running out. To resolve this issue, a new IP version — IPv6 —
is introduced as a supplement to IPv4 to provide more addresses.
An IPv6 address has 128 bits. With this many bits, IPv6 can theoretically provide 2128 addresses (4.3 billion
x 4.3 billion x 4.3 billion x 4.3 billion addresses) — that is as many as the total number of grains of sand in
the world and, as such, likely sufficient to assign a public network IP address to each device. A basic
technology of the next-generation network, IPv6 started to be used commercially in June 2012. As the
adoption of new technologies such as the Internet of Things (IoT), industrial IoT (IIoT), and 5G increases,
more IP addresses are required than ever, and IPv6 has become a natural fit for these emerging fields.

What Is IPv6?

Developed by the Internet Engineering Task Force (IETF), IPv6 is IPv4's successor. It supplements and will
eventually replace IPv4. In addition to providing more IP addresses, IPv6 differs from IPv4 in the following
two ways:

• The IPv6 packet header has a fixed length (40 bytes) and simpler structure, which increases the packet
processing efficiency.

• Without fragmenting packets, IPv6 provides a higher routing efficiency with unicast, multicast, and
anycast addresses.

Deploying IPv6

As 5G networks scale up, IPv6 is a favorable option. However, IPv6 cannot be immediately implemented
network-wide, but needs to be planned in steps:

• To protect carriers' prior investments, first enable the user plane to support IPv6 and then rebuild the
core network as dual-stacked to enable both IPv4 and IPv6 connectivity. Next, ensure that new UEs

2025-04-25 119
Technology Series

support dual-stack and use IPv6 to access networks. Promote IPv6 UEs, which will stimulate
innovation of new IPv6 services.

• Then, reconstruct the signaling network as dual-stacked or IPv6-only and gradually shift the 5G Core
and mobile networks to IPv6.

Figure 1 IPv6 deployment strategy

Table 1 IPv6 deployment

Phase Objective Requirements

Start-up The user plane supports IPv6, while the UEs support IPv6-only or IPv4v6 dual-stack.
signaling plane is still IPv4-only.
The (R)AN can transparently transmit IPv4 and IPv6
packets with IPv4 networking.
The 5G Core supports IPv6-based access. The
gateway can assign IPv6 addresses to UEs, and the
DNS can cache and query for IPv6-related AAAA
records.
The 5G Core still uses IPv4 for internal
communications, but uses external IPv6 interfaces to
communicate with the IP Core.
The IP Core network supports IPv4v6 dual-stack or
6over4 tunnels.
Service servers are gradually enabled to support IPv6
data services.

Growing Both the user and signaling planes support Many IPv6-only UEs are used.
IPv6 and use it in most cases, and only a
small number of network services are still The (R)AN supports IPv6.
IPv4-only. The 5G Core uses IPv6 for internal communications.
The IP Core can use either IPv4v6 dual-stack or IPv6-
only.
Most service servers use IPv6, while a small number
are IPv4-only.

Mature IPv6 dominates. Both the user and signaling planes support IPv6.
IPv6-only is used across the entire network.
5G Core NFs communicate with the (R)AN by using
IPv4v6 dual-stack.

2025-04-25 120
Technology Series

Table 1 IPv6 deployment

Phase Objective Requirements

All service servers use IPv6.

Essentially, IPv6 will gradually be used more by UEs, service servers, and 5G Core NFs.

IPv6 Implementation on UEs

Carriers can deploy IPv6 address pools to provide more addresses to UEs, so that more UEs can access the
network, and more users can access the diversifying 5G services. After a UE accesses the 5G Core and
requests a PDU session, it is assigned an IPv6 address or both an IPv4 and IPv6 address when the PDU
session is being established. If assigned both address types, the UE sends IPv6 packets to IPv6 servers and
IPv4 packets to IPv4 servers, as shown in the figure below. Data is encapsulated in GTP-U packets when
transmitted through the GTP tunnels between the (R)AN and UPF. After receiving the packets, the UPF
decapsulates the packets and sends the uplink data from the (R)AN to IPv6 servers.

Figure 2 Packet transmission over an IPv6-capable user plane

The external interfaces connecting the 5G Core to the IP Core, specifically, the UPF's N6, Gi, and SGi
interfaces, must also support IPv6 to facilitate the transmission of IPv6 data packets from UEs to IPv6
servers. In addition, the type or types of addresses assigned to the N6, Gi, and SGi interfaces must be the
same as those in the local address pool from which IP addresses are assigned to UEs. For example, if the
pool contains only IPv6 addresses, the N6, Gi, and SGi interfaces need to be configured with IPv6
addresses; if the pool has dual-stack addresses, the N6, Gi, and SGi interfaces need to be configured with
both IPv4 and IPv6 addresses.

Figure 3 N6/Gi/SGi interface addresses

2025-04-25 121
Technology Series

The IPv6 address used by a UE to access the 5G Core is a global unicast address, equivalent to a public IPv4
address. The IPv6 address consists of a 64-bit prefix and a 64-bit interface ID. It is assigned to the UE by
the UPF in a stateless approach. As shown in the following figure, the UE obtains the IPv6 address in two
steps.

Figure 4 IPv6 address acquisition

1. The UE initiates PDU session establishment and receives an interface ID (the least significant 64 bits
of an IPv6 address) randomly allocated by the SMF and sent by the AMF.

2. After the PDU session is established, the UE sends a Router Solicitation (RS) message to the UPF to
obtain the prefix (the most significant 64 bits of an IPv6 address) of the IPv6 address.

The UE combines the interface ID (either received from the AMF or locally generated) and prefix into a
complete 128-bit IPv6 address and uses this address to access services.

IPv6 Implementation on Servers

As more IPv6 UEs are adopted, network services need to gradually shift to IPv6, which will be a long
process. The network must stay dual-stacked before IPv6-only is fully implemented. During this process,
UEs and service servers will inevitably adopt different IP versions. Therefore, accurate IP address
translation, either from IPv4 to IPv6 or from IPv6 to IPv4, is essential.

Figure 5 IPv6 UE accessing an IPv4 server

2025-04-25 122
Technology Series

IPv6 packets cannot be directly sent from a UE to an IPv4 server; they must first be converted into IPv4
packets. The preceding figure shows this process. The UE first queries the DNS64 for the IPv6 address
corresponding to the domain name of the destination server. The obtained IPv6 address has a fixed prefix
configured on the DNS, and uses the least significant 32 bits to represent the destination server's IPv4
address. The UE then sends IPv6 packets to the NAT64 server through the UPF. The NAT64 server
translates the source and destination addresses in the IPv6 packet headers, converts the IPv6 packets into
IPv4 packets, and forwards them to the destination IPv4 server.

Figure 6 IPv4 UE accessing an IPv6 server

Although IPv4 packets are rarely sent to IPv6 servers, IPv4-to-IPv6 transition is still required. For example,
some customer-premises equipment (CPE) cannot be upgraded to use IPv6, and there are no more public
IPv4 addresses that can be assigned to new content or service providers.
The preceding figure shows how IPv4 packets are sent to an IPv6 server. The IPv4 UE first attempts to
query the DNS for the A record corresponding to the destination server's URL. The DNS only has the AAAA
record, so it translates the URL requested by the UE into an IPv6 address, statically converts the IPv6
address into an IPv4 address and a port number and uses them to create an A record, and then sends the
A record to the UE. The UE then uses the IPv4 address and port number in the A record as the destination
IP address and port number to send IPv4 packets. After receiving the IPv4 packets, the NAT64 server
translates the destination IPv4 address and port into an IPv6 address and port according to the static
mapping table, replaces the source private IPv4 address with a public IPv6 address, and forwards the
packets to the IPv6 server.

IPv6 Implementation on 5G Core NFs

2025-04-25 123
Technology Series

IPv6 not only provides more IP addresses than IPv4; it also introduces new features and advantages. For
instance, implementing IPv6 is simpler, more transparent, and more efficient. Additionally, IPv6 further
strengthens the QoS to ensure E2E security. These advantages have accelerated the commercialization of
IPv6. In this process, the 5G Core signaling network needs to either be dual-stacked or use IPv6-only to
accelerate the integration of the entire 5G Core with IPv6. The logical interfaces between 5G Core NFs,
including the N11, N15, N8, N7, N10, and N4 interfaces, must support IPv6, through IPv4v6 dual-stack or
IPv6-only. Internally, the NFs must use IPv6 addresses to communicate with each other. Externally, the NFs
use dual-stack O&M interfaces to interwork with the U2020, VNF LCM, and NFVO. Table 2 describes the
interface and IP address plan for 5GC NFs.

The value SBI for Peer indicates all the NFs that communicate with the current NF through the specified 5G Interface.
The values of Dual/Single Stack include:

• IPv4- or IPv6-only: The NF supports either IPv4 or IPv6; it cannot support IPv4 and IPv6 simultaneously.
• IPv4- and IPv6-only: The NF can use IPv4 and IPv6 to interwork with different peer devices, but can only establish
one IPv4 or IPv6 link to each peer.
• IPv4v6 dual-stack: The NF can use both IPv4 and IPv6 communicate with each peer.

Table 2 Example plan for IP addresses of 5G Core NFs

NF Peer 5G Shared 4G Dual/Single Stack

Interface Interface

AMF gNodeB N2 S1-MME IPv4- and IPv6-only

MME N26 - IPv4- or IPv6-only

SBI Namf - IPv4v6 dual-stack (IPv6 preferentially

used)

SMF/PGW-C/BSF UPF/GW-U N4 Sx IPv4- and IPv6-only

SBI Nsmf - IPv4v6 dual-stack (IPv6 preferentially

used)

LDRA Nbsf - IPv4v6 dual-stack

MME - S11 IPv4- and IPv6-only

SGW - S5 IPv4v6 dual-stack

NRF NF Nnef - IPv4v6 dual-stack (IPv6 preferentially

used)

NSSF SBI Nnssf - IPv4v6 dual-stack (IPv6 preferentially

used)

PCF/PCRF SBI Npcf - IPv4- or IPv6-only

LDRA - Gx/Rx IPv4- or IPv6-only

2025-04-25 124
Technology Series

Table 2 Example plan for IP addresses of 5G Core NFs

NF Peer 5G Shared 4G Dual/Single Stack

Interface Interface

BOSS Bi Bi IPv4- or IPv6-only

UDM/HSS/AUSF SBI Uudm - IPv4- or IPv6-only

LDRA - S6a IPv4- or IPv6-only

LDRA Cx IPv4- or IPv6-only

LDRA Sh IPv4- or IPv6-only

STP C/D IPv4- or IPv6-only

HSS BE DCI IPv4- or IPv6-only

BOSS Bi Bi IPv4- or IPv6-only

UPF/PGW-U gNB N3 S1-U IPv4- and IPv6-only

SMF/GW-C N4 Sx IPv4- and IPv6-only

DN N6 SGi IPv4- and IPv6-only

UPF N9c - IPv4- and IPv6-only

UPF/SGW- Paif (N9a) Paif (S5/S8_p) IPv4- and IPv6-only

U

SBC-U N6 (VoLTE) SGi (VoLTE) IPv4- and IPv6-only

All EMS O&M - IPv4v6 dual-stack

2 SVC Technology Series

2.1 Why Single Voice Core (SVC)?
• Forewords

• Voice Platform Architecture Evolution

• Voice Network Architecture Evolution

• Voice Solution Evolution

Forewords

After years of development, the voice platform architectures, voice network architectures, and voice
solutions have undergone dramatic changes, culminating in the realization of the "One Network, One
Cloud, and One Solution", as shown in the figure below.

2025-04-25 125
Technology Series

Voice Platform Architecture Evolution

The voice platform has experienced several rounds of upgrades, from non-cloud Advanced Telecom
Computing Architecture (ATCA) to cloud-based Network Functions Virtualization (NFV), and then to 5G-
oriented cloud-native Service-Based Architecture (SBA).

• ATCA-based voice platform

ATCA, a platform developed from CompactPCI standards, is a next generation mainstream industrial
computing technology widely used in telecom, astronautics, industrial control, medical appliances,
intelligent traffic, and military facilities. ATCA provides a modularized, scalable, and cost-effective
hardware architecture for the next generation integrated telecom and data network applications. It is
the last-generation non-cloud architecture and features the coupling of software with hardware. With
this architecture, software that is tied to a specific function can only run on a dedicated board. And
the software performance highly depends on the service processing and Disaster Recovery (DR)
capabilities of the board. Besides, software communications also rely on the physical interfaces and
connections among boards. In this case, software is unable to move to better performing hardware,
let alone flexibly migrate services. The tight coupling of software and hardware causes a series of
issues, including low hardware resource utilization, high investment and maintenance costs, and slow

2025-04-25 126
Technology Series

service deployment. To address these issues, virtualization is introduced, pushing the voice platform to
enter the cloud era.

• NFV-based voice platform

NFV leverages virtualization technologies to decouple software from hardware. No longer bound to
proprietary hardware, NEs can obtain required virtual resources, including memory, hard disk, and NIC
resources, from the virtual resource pool. To adapt to this trend, the voice platform is divided into two
layers: Infrastructure as a Service (IaaS) and Software as a Service (SaaS), and NEs are deployed on
Virtual Machines (VMs) instead of directly running on conventional boards. The NFV architecture
brings considerable benefits to the voice platform, including high hardware resource utilization, low
investment and maintenance costs, increased reliability, improved security, and flexible service
deployment.
Although the NFV-based platform outperforms the ATCA-based platform, there are still certain strings
attached to it, despite its numerous advantages. The introduction of virtualization makes the network
architecture extremely complex. For instance, creating or configuring virtual networks is rather labor-
intensive and time-consuming. To cope with these challenges, Software-defined Networking (SDN)
technology is introduced to the NFV architecture to simplify network configuration. SDN separates the
control plane from the forwarding plane by adding a Distributed Computing Node (DCN) controller to
the Virtualized Infrastructure Manager (VIM) and introducing the Network Service Descriptor (NSD)
file, which can be imported to the Network Functions Virtualisation Orchestrator (NFVO) for
automatic configuration. This separation enables the automatic configuration of virtual networks,
reducing Operation and Maintenance (O&M) costs. Nevertheless, the SDN+NFV combination does not
equate to being truly cloud-based. Following NFV, the industry proposes the concept of Network
Functions Cloudification (NFC), which is also known as cloud native. NFC decouples apps from data by
separating the Platform as a Service (PaaS) layer from NFV, forming a three-layer cloud architecture:
IaaS, PaaS, and SaaS. NFC promotes in-depth convergence of IT and CT technologies, helping build a
cloud-native service-based voice platform.

• Cloud native voice platform

Cloud native decouples apps from data by introducing the PaaS layer to NFV in addition to the IaaS
and SaaS layers. The PaaS layer is dedicated for functions such as Cloud Session Load Balancer (CSLB)
and Cloud Session Database (CSDB). Cloud native transitions the NFV-based network architecture
from resource-centric to application-centric, achieving a truly cloud-based environment. In addition to
the architecture change, cloud native adopts the latest IT technologies to the CT industry, including:

• Three-layer decoupling

• Microservice

• Container-based deployment

• Development & Operations (DevOps)

• New deployment and operations models

With the continued evolution of communications technology, the future 5G-oriented voice platform
will also use Commercial Off-the-Shelf (COTS) hardware and SBA. The SVC solution is built with the
advanced Telco Cloud platform architecture and therefore born with the above advantages.

2025-04-25 127
Technology Series

Voice Network Architecture Evolution

The voice network architecture has undergone profound transformational changes from 1G to 5G, evolving
from fixed networks to mobile networks, from analog signals to digital signals, and from voice
communications to multimedia communications.

• Fixed voice network architecture

The fixed network architecture has developed from Public Switched Telephone Network (PSTN) to
Next-Generation Network (NGN), and then to IP Multimedia System (IMS).
The figure below shows the PSTN architecture. On a PSTN network, Plain Old Telephone Service
(POTS) terminals access the core network through Time Division Multiplexing (TDM) trunks and
communicate with the core network using SS7 signaling to route calls and control announcement
playback. However, it is worth noting that due to the inherent shortcomings of the TDM standard:
high-power consumption, single-services, and high O&M costs, PSTN has gradually fallen out of favor
in the communications market. As a result, PSTN gradually evolved to NGN, a preferred choice for
carriers.

2025-04-25 128
Technology Series

The NGN architecture allows the service, bearer, and control layers to be separated on the fixed
network for the first time. This architecture offloads a large volume of traffic onto the IP network,
improving network flexibility and ensuring service continuity.

Although the NGN architecture has many advantages over PSTN, fixed networks still face many
challenges. Due to the rapid rise of the mobile subscriber base in the telecom market, fixed networks
are unable to cope with the growing demands of these subscribers who are demanding better
multimedia services such as videos, images, and texts. In addition, fixed networks do not support the
convergence of fixed and mobile networks, and carriers need to deploy or maintain fixed and mobile
networks separately.
This is where the IMS comes in. The IMS provides a way for fixed networks to transition to Fixed
Mobile Convergence (FMC) and is the most promising voice network since NGN. The IMS is
distinguished with all-IP and its support for FMC and multimedia services.

2025-04-25 129
Technology Series

• Mobile voice network architecture

Unlike the stuttered growth of the fixed voice network, the mobile voice network has grown steadily
since its inception. From 1G to 5G, the mobile voice network has gone through several upgrades,
including voice and data channel. This has culminated in today's mobile voice network that is able to
provide diverse, intelligent voice services.
1G to 2G evolution: With the advent of the second generation of wireless mobile communications, the
mobile voice network replaced analog signals with digital signals. The figure below shows a typical 2G
network architecture. On the 2G network, mobile voice services are provided by the Circuit Switched
(CS) network. And the Mobile Switching Center (MSC) processes not only the signaling messages of
voice services on the control plane, but also controls media resources on the user plane.

2G to 3G evolution: The figure below shows a typical 3G network. In the 3G network architecture, with
the UTRAN as the access network and the CS and PS as the core network, an MSC is split into an MSC
server and a Media Gateway (MGW). The MSC server handles call control, and the MGW handles
bearer control, i.e. the signaling and media planes are separated. This separation enables networks to

2025-04-25 130
Technology Series

be deployed more flexibly. For example, the MSC server can be deployed in a densely populated
central city, facilitating easier management and maintenance. The MGW can be deployed at an edge
site to shorten the media paths and avoid repeated transcoding, minimizing call delay and improving
media quality.

3G to 4G evolution: The figure below shows a typical 4G network. The 3G to 4G evolution is another
important milestone for the upgrade of the voice network. First, the voice network is further split to
form a three-layer architecture that consists of the control layer, bearer layer, and service layer. In
terms of functions, the Advanced Telephony System (ATS) and Call Session Control Function (CSCF)
play the role of the MSC server on the CS network. The ATS controls service logic, while the CSCF
controls call sessions. This separation enables new services to be quickly deployed through service
provisioning gateways, improving service rollout efficiency. The Session Border Controller (SBC)
processes media plane messages, something that was originally accomplished by the MGW in the CS
domain. Second, the CS network is replaced by the all-IP IMS network and evolves to the convergent
multimedia network. As an all-IP network based on SIP, the IMS greatly simplifies the protocol layer.
As an independent logical entity to process service logic, each ATS can process videos, texts, and
images to provide subscribers with convergent media services, just like Internet apps. This provides a
way for carriers to monetize a greater range of services.

4G to 5G evolution: Voice services are still provided by the IMS, which remains unchanged except
certain interfaces and network identifiers.

2025-04-25 131
Technology Series

• 5G-oriented future voice network architecture

The 5G-oriented future voice network architecture supports FMC and the separation of the service,
control, and bearer layers, helping innovate new 5G services and providing more open network
capabilities. The SVC solution is based on the IMS and also supports the aforementioned functions.
Carriers can leverage the SVC solution to build a convergent and simplified voice network, as well as
connect all subscribers to the IMS to use voice services.

Voice Solution Evolution

With the growth of voice services, voice solutions have transitioned from fixed voice solutions to mobile
voice solutions, and then to FMC.

• Voice solutions on fixed networks

Voice solutions on fixed networks predominantly include the NGN, PSTN reconstruction, and Voice
over Broadband (VoBB) solutions.
NGN solution: In the traditional PSTN network architecture, the rise of numerous issues such as the
slow deployment of new services and high network construction costs are turning the market away
from this technology. Therefore, the NGN solution can be used to overcome these shortcomings.
Through the innovative separation of service, control, and bearer layers, the NGN solution enables
fixed voice networks to be deployed more flexibly and provides a network foundation for service
innovation and fast service rollout. The figure below shows the NGN network architecture. In addition,

2025-04-25 132
Technology Series

the NGN is designed as an open, flexible solution used to provide convergent services. The AS at the
service layer integrates the third-party Application Programming Interface (API), enabling the NGN
solution to offer a greater range of services. With the three-layer architecture, the NGN solution can
be deployed more flexibly. Theoretically, the NGN solution is able to provide voice, video, and data
services as the bearer plane adopts the IP-based packet network.
Although the NGN solution is a service-driven solution, fixed network carriers need to consider FMC
due to the rise of mobile networks. Therefore, the IMS network gradually replaces NGN and becomes
the new core network. In addition, the IMS-based PSTN reconstruction solution and VoBB solution are
introduced.

PSTN reconstruction solution: To aid the smooth upgrade of the NGN to the IMS network, the PSTN
reconstruction solution (shown in the figure below) is introduced. Thanks to the IMS, which leverages
various types of network architectures, the PSTN reconstruction solution not only provides the same
services as NGN, but also allows diverse fixed-line terminals, such as Plain Old Telephone Service
(POTS) terminals, Integrated Services Data Network (ISDN) terminals, and TDM Private Branch
Exchange (PBX) terminals, to access the IMS network through the Access Gateway Control Function
(AGCF) or Access Gateway (AG). This allows different types of subscribers to enjoy a wide range of
voice services. Furthermore, since the IMS supports FMC, the PSTN reconstruction solution can
smoothly transition toward an FMC-based voice solution. Although the PSTN reconstruction solution
has upgraded voice services by moving them from the NGN into the IMS, it is restricted to serving
narrowband fixed terminals, which has been gradually dwarfed by fixed broadband terminals thanks
to the rise of the Internet. Against this backdrop, the VoBB solution emerges.

2025-04-25 133
Technology Series

VoBB solution: As the name implies, VoBB is a voice solution developed for broadband terminals. The
VoBB solution allows various broadband terminals, such as IP-PBX terminals, SIP terminals, and x
Digital Subscriber Line (xDSL) terminals, to access the network through the A-SBC (P-CSCF). The VoBB
solution can also be used in cloud scenarios, facilitating the evolution towards a cloud+FMC IMS
network.

• Voice solutions on mobile networks

2025-04-25 134
Technology Series

On the early 2G/3G mobile network, the CS domain is still responsible for providing voice and video
services.
CS solution: With this solution, 2G/3G subscribers access the CS network through voice channels
provided by the BSC/RNC to enjoy voice services. The CS solution enables the voice network to provide
basic calling services, and also Short Message Service (SMS) and Intelligent Network (IN) services.
With the development of mobile communications and Internet technologies, subscribers are less
willing to make phone calls or send SMSs. As a result, carriers have an urgent need to develop new
voice services to meet subscribers' emerging communications requirements. With the flexible, open
network architecture, the IMS has become the preferred core network for the next-generation mobile
voice solution.

With the advent of 4G and 5G, the IMS network featuring FMC has become the mainstream core
network, on which various mobile voice solutions are implemented. The figure below shows the IMS-
based voice solution family.

In the 4G era, typical IMS voice solutions include the following:

CS Fallback (CSFB) solution: Before the IMS network becomes widespread, the CSFB solution is
introduced to reuse existing CS network devices. With this solution, the voice requests of LTE
subscribers are routed to the CS network over the SGs interface between the MME on the Evolved

2025-04-25 135
Technology Series

Packet Core (EPC) network and the CSFB function entity on the CS network. The CS network provides
voice services for LTE subscribers. To provide both voice and data services, carriers only need to deploy
an Evolved Packet System (EPS) as a supplement to the CS network.

Voice over LTE (VoLTE) solution: As the IMS gains market traction, the VoLTE solution starts to take
center stage. The VoLTE solution can also enable 4G terminals to access the IMS network via the voice
service channels provided by the EPC, so that 4G subscribers can enjoy High Definition (HD) voice and
video services. In addition to basic voice, IN, and SMS services, the VoLTE solution also helps provide a
wealth of voice and video services, like multi-device, Voice over Wi-Fi (VoWiFi), and Video Ring Back
Tone (VRBT).

Enhanced Single Radio Voice Call Continuity (eSRVCC) solution: Before the LTE network becomes
widespread, this solution is introduced to ensure the call continuity of LTE subscribers who move to an
area not covered by the eNodeB or an area with weak LTE signals. The eSRVCC solution enables LTE
subscribers to be anchored to 2G/3G networks over the Sv interface between the MME on the EPC
network and the SRVCC Interworking Function (IWF) on the CS network. Then, a CS-to-IMS network
bearer is re-established over the I2 interface between the Access Transfer Control Function (ATCF) or
Access Transfer Gateway (ATGW) on the IMS network and the SRVCC IWF. And finally, the call is
routed to the IMS network through this bearer, preventing call interruption.

2025-04-25 136
Technology Series

IMS Centralized Services (ICS) solution: Before the LTE network becomes widespread, the CSFB and
eSRVCC solutions can be used to ensure voice continuity. However, they cannot ensure a consistent
service experience. To address this issue, the ICS solution is introduced. If the 2G to 4G range of
subscribers enabled with the ICS on the IMS network camp on the 2G/3G network, they can access the
IMS network through the mAGCF, ensuring their service consistency.

In the 5G era, typical IMS-based voice solutions include:

EPS fallback solution: With a similar mission to that of CSFB, EPS fallback is introduced at the initial
stage of New Radio (NR) deployment so that existing VoLTE devices can be reused. With EPS fallback,
5G subscribers can be routed to the VoLTE network over the N26 interface between the AMF on the
NR network and the MME on the EPC network. The VoLTE network provides voice services for
subscribers.

2025-04-25 137
Technology Series

Voice over NR (VoNR) solution: After the NR network becomes widespread, the full potential of the
VoNR solution can be unleashed. This solution enables 5G terminals to access the IMS network via the
voice service channels provided by the NR network. The service types supported by the VoNR solution
are the same as those supported by the VoLTE solution. This is why the next-generation voice solution
is introduced.

• 5G-oriented future voice solution

Reflecting on the evolutionary journey of voice solutions, we observe that the momentum behind the
various upgrades has been propelled by the continuously changing requirements of subscribers.
Carriers have duly responded by updating their marketing strategies and service schemes to provide
differentiated voice services. However, these solutions only provide network capabilities for basic voice
and video services. 5G unleashes the vast potential of call services.
On top of the SVC solution, carriers need to leverage 5G's three features — Enhanced Mobile
Broadband (eMBB), Ultra-Reliable Low-latency Communication (URLLC), and Massive Machine-Type
Communications (mMTC) — to seek breakthroughs in the voice field. Combined with emerging
technologies, such as Augmented Reality (AR), Virtual Reality (VR), and cloud services, 5G will
redefine calling, delivering more enjoyable and immersive services, beyond voice and video calls.

2025-04-25 138
Technology Series

SVC, an integrated solution, also has the following advantages:

1. Consistent service experience: SVC provides the same voice and video services for fixed and
mobile subscribers.

2. Fast service deployment: New services can be quickly developed and rolled out by opening
network capabilities and using the service-oriented architecture.

3. New business ecosystem and operations models: A 5G-oriented voice and video service
ecosystem can be created by leveraging 5G technologies such as AR and VR to support new
operations models such as Business to Business to Consumer (B2B2C) and Application to Point
Service (A2P).

SVC, the optimal evolution towards the "One Network, One Cloud, and One Solution", can effectively
expedite network convergence, simplify networks, and create a new 5G-oriented business ecosystem for
new operations models. Along with the development from 1G to 5G, voice solutions have been gradually
evolving. After the SVC solution emerges, where will other voice solutions go next? Is there any
relationship between these solutions? To find the answers, let's look forward to the next series "Single
Voice Core Solution".

2.2 Single Voice Core Solution

• Forewords

• Network Architecture of the SVC Solution

• IMS over 2G/3G

• VoLTE

• Vo5G

• VoBB

• Convergent Gateway Office

Forewords

In the previous series, we covered how the voice solution has undergone several development phases –
fixed, mobile, and Fixed Mobile Convergence (FMC) – before the eventual adoption of the Single Voice
Core (SVC) solution. On fixed networks, the Voice over Broadband (VoBB) solution stood out for
empowering various broadband terminals. As for the mobile networks, the Circuit Switched (CS), Voice
over LTE (VoLTE), and Voice over 5G (Vo5G) solutions all played pivotal roles in the voice service arena. In
this series, we will talk about how the SVC solution works to provide voice services on both fixed and
mobile networks, and how it affects the VoBB, CS, VoLTE, and Vo5G solutions.

2025-04-25 139
Technology Series

Network Architecture of the SVC Solution

Why is the SVC solution called the convergent voice solution?

From the perspective of voice solution evolution, the SVC solution integrates five sub-solutions: VoBB, IMS
over 2G/3G, VoLTE, Vo5G, and Convergent Gateway Office. The IMS over 2G/3G solution is the substitute
of the traditional CS solution during the evolution from 2G/3G networks to SVC networks.

From the perspective of the voice network architecture, the SVC network integrates the control plane,
media plane, and gateway offices to form a simplified voice network. This simplified voice network solves
the problem of the coexistence of multiple networks and becomes the optimal voice and video solution in
the industry. On an SVC network, 2G, 3G, 4G, 5G, and fixed-line subscribers can access the IMS network to
enjoy voice services. The SVC network architecture is shown in the following figure.

2025-04-25 140
Technology Series

To better understand the SVC solution, it is necessary to introduce five sub-solutions of the SVC solution
family, starting from the IMS over 2G/3G solution.

IMS over 2G/3G

In the 2G and 3G eras, CS networks provided simple voice and video services. However, after decades of
uptime, CS networks are facing numerous problems, such as obsolescent devices, outdated underlying
architecture, and high O&M costs. In addition, 2G/3G subscribers are only willing to use basic voice call and
short message services provided by CS networks. CS networks cannot meet today's subscriber requirements
of enjoying diverse communications services on large-screen smart mobile phones in the LTE and 5G eras.

Taking all the preceding factors into consideration, Huawei proposes the IMS over 2G/3G solution. With
this solution, 2G/3G subscribers can access the IMS networks.
In this way, a CS network can be gradually evolved to a fully converged SVC network. The IMS over 2G/3G
solution replaces the traditional CS solution, meets operators' requirements for retrofitting CS networks

2025-04-25 141
Technology Series

and fast tracking IMS deployment, and ensures that 2G/3G subscribers can enjoy voice and video services
in the same manner as IMS subscribers.

• IMS over 2G/3G Network Architecture

The following section describes how 2G/3G subscribers access the IMS network and what changes are
brought to the network architecture in order to evolve 2G/3G networks to SVC networks. During this
process, the Mobile Access Gateway Control Function (mAGCF) and IMS Centralized Services (ICS)
Interworking Function (IWF) will play a vital role.

• mAGCF: The CloudSE2980 provides the mAGCF functions to process access and location update
requests from 2G/3G subscribers.

• ICS IWF: The ATS9900 provides the ICS IWF functions to derive service and subscriber data of
2G/3G subscribers registered with an SVC network.

The IMS over 2G/3G solution uses VoLTE as the basic network. For details about network architectures
of the CS and IMS over 2G/3G networks, see the following figure.

• Before the IMS over 2G/3G solution is deployed, 2G/3G subscribers access the CS network
through the Media Gateway (MGW) to use voice services. The Mobile Switching Center (MSC)
server controls service processing, exchanges messages with peers, and derives subscriber data
from the Home Location Register (HLR).

• After the IMS over 2G/3G solution is deployed, 2G/3G subscribers access the IMS network
through the mAGCF to use voice services. The Call Session Control Function (CSCF) controls
service processing, exchanges messages with peers, and derives subscriber data from the ICS IWF.

2025-04-25 142
Technology Series

The solutions for deploying an IMS over 2G/3G network vary depending on the existing VoLTE
network conditions. If VoLTE has been deployed on the live network, deploy an IMS over 2G/3G
network overlaying the VoLTE network. If only the CS network exists, deploy a new IMS over 2G/3G
network. If both CS and Evolved Packet Core (EPC) networks exist, deploy new IMS and IMS over 2/3G
networks.

• Highlights of the IMS over 2G/3G Solution

With the IMS over 2G/3G solution, the IMS network can also provide services for 2G/3G subscribers. In
this way, carriers can gradually sunset CS networks, maintain one voice network, and improve voice
service quality.

VoLTE

Now, let's talk about how VoLTE is evolved to SVC.

VoLTE relies on LTE to provide voice services and is considered the optimal choice in the mobile broadband
era, especially for the transition from 3G to 4G. VoLTE supports an increased transmission rate which goes
hand in hand with subscribers' increasing demands on data services.
The LTE solution comprises four commercial solutions: IMS/SRVCC, OTT, CSFB, and SVLTE. The following
figure shows advantages and disadvantages of each solution. Considering multiple factors, IMS/SRVCC
becomes the final solution of VoLTE. In this solution, voice services are provided by the IMS and LTE,
enabling voice calls to be handed over between 2G/3G and LTE networks. For example, when a UE that is
on a call moves out of the LTE coverage, the system can smoothly hand over the call to the 2G/3G
network without interrupting the call.

• VoLTE Network Architecture

Huawei VoLTE solution builds IMS and LTE over the CS network to provide end-to-end Quality of
Service (QoS) guarantee, high-quality voice and video calls, and enriched data services. With this
solution, carriers can transform their 2G and 3G networks to LTE networks and expand their portfolio
of services. Subscribers can also use LTE terminals to connect to LTE or 2G/3G networks. And after the
convergence, where, incidentally, the VoLTE network remains unchanged, the VoLTE subscriber base
increases, which poses higher requirements on core network NE performance.

2025-04-25 143
Technology Series

• Highlights of the VoLTE Solution

Huawei VoLTE solution is highly integrated, reliable, advanced, and cost-effective. Carriers using
Huawei VoLTE solution can provide a diverse rang of services for subscribers.

• High integration: A single physical device can provide functions of multiple logical entities,
reducing network interfaces, simplifying O&M, and reducing costs.

• High reliability: The solution is designed to support multiple redundancy and flow control
mechanisms, improving network reliability and service availability.

• Advanced platform architecture: Huawei VoLTE solution employs the NFV-oriented cloud
platform, which leverages the virtualization and cloudification technologies.

• Cost-effective deployment: Carriers can reuse CS network resources to build IMS and LTE
networks, minimizing impacts on existing HLRs and maximizing the return on CS networks.

• Centralized O&M: The solution supports unified network management, service provisioning,
terminal management, and End to End (E2E) signaling tracing functions.

Vo5G

2G, 3G, and 4G subscribers can access the IMS network in a unified way. To integrate the mobile voice
network into the SVC network, Vo5G, as the voice solution in 5G, must be taken into consideration.
With the Vo5G solution, 5G subscribers can access the IMS network. The Vo5G solution consists of the
following sub-solutions:

• Voice over NR (VoNR): The target voice solution in 5G, requiring the collaboration of new radios
(NRs).

• EPS Fallback (EPS FB): At the early stage of 5G, NRs cover only limited areas and eNodeBs are not
upgraded. With the EPS FB solution, 5G UEs can fall back to LTE networks to use VoLTE services,
ensuring voice service continuity. EPS FB is a transitional voice solution during the VoLTE-to-VoNR
period.

2025-04-25 144
Technology Series

• Voice over eLTE (VoeLTE): This solution applies when NRs cover only limited areas and eNodeBs have
been upgraded to interwork with the 5GC.

• RAT Fallback (RAT FB): This solution applies when NRs do not support voice services. UEs fall back to
eLTE networks to use voice services.

Among the preceding 5G voice solutions, VoNR and EPS FB are voice solutions supported by Huawei. VoNR
is the target voice solution, and EPS FB is a transitional solution during the VoLTE-to-VoNR evolution.

• Vo5G Network Architecture

5G continues to use 4G's voice architecture, providing IMS-based voice services for subscribers. Therefore,
the network architecture of the Vo5G solution remains unchanged after the convergence.

Compared with a VoLTE network, new NEs including NG Radio Access Networks (NG-RANs), Access and
Mobility Management Functions (AMFs), Session Management Functions (SMFs), and User Plane
Functions (UPFs) must be deployed on a Vo5G network. NG-RANs are located at the terminal layer and
are responsible for connecting 5G UEs to the 5GC network. AMFs, SMFs, and UPFs are located at the
access layer and process registration of UEs with 5G networks, EPS fallback, and 4G-5G interworking.
A VoLTE network evolves to a VoNR network in two phases.

• Phase 1: Deploy the EPS FB solution. Use the VoLTE network, existing one or newly deployed one, as
the basic network and add NRs and a 5GC to the VoLTE network. In this way, the 5GC can interwork
with the IMS, ensuring that Vo5G subscribers can access the IMS network to use relevant services. In
this phase, voice services must fall back to the LTE network and be provided by the VoLTE network.

• Phase 2: Deploy the VoNR solution on the existing EPS FB network.

2025-04-25 145
Technology Series

VoBB

The preceding sections have described the convergence and evolvement of voice solutions used on mobile
networks for 2G, 3G, 4G, and 5G subscribers. Now, let's focus on how VoBB, the dominant voice solution
on fixed networks, evolves to the SVC network.
With the VoBB solution, voice services are carried over broadband. Fixed line terminals convert voice
streams into IP packets and access the IMS through broadband, such as x Digital Subscriber Lines (xDSLs).
VoBB subscribers can directly access the IMS. This architecture makes the evolution from VoBB to SVC
relatively easy.

• VoBB Network Architecture

Before the convergence, VoBB subscribers access the IMS through broadband. Therefore, the VoBB
network architecture remains unchanged after the convergence.

In the VoBB solution, core NE functions, including Proxy-Call Session Control Function (P-CSCF) and
Session Border Controller (SBC), are provided by the CloudSE2980. The P-CSCF serves as an entrance
to the IMS. It exchanges SIP signaling between users and their home networks. The SBC is located at
the network border and provides capabilities such as security protection and IPv4/IPv6 address
translation.

• Highlights of the VoBB Solution

Huawei VoBB solution supports the following functions:

• Provides centralized user access control, network management, service provisioning, data centers,
and application platforms under the all-IP, cloud-based IMS architecture. The VoBB-based
network topology remains stable even when there are frequent service changes.

• Delivers IP-based carrier-grade voice, video, and other rich communications services for fixed
broadband subscribers, and guarantees the experience of different services through E2E QoS
management, helping carriers better capitalize on broadband network resources.

Convergent Gateway Office

2025-04-25 146
Technology Series

We have learned how mobile and fixed networks are converged and evolved to SVC networks so that
fixed-line, 2G, 3G, 4G, and 5G subscribers can access the IMS in a unified way. On an SVC network, how do
different networks communicate with each other? What are the differences before and after the
convergence? To answer these questions, it is important to learn the last sub-solution of the SVC solution,
that is, the convergent gateway office solution.
First, let's begin with a gateway office. A gateway office is an egress office for interconnection between
different networks, for example, interconnection between different operators, regions, or countries. The
following figure shows the location of a gateway office on the network.

Before SVC convergent gateway offices are introduced, there are three types of gateway offices, namely CS
gateway offices for CS-CS interworking, IP gateway offices for IMS-IMS interworking, and IMS gateway
offices for IMS-CS interworking.

As 5G is adopted more widely, CS networks are quickly becoming obsolete. In particular, conventional
gateway offices face the following challenges:

• Conventional MGWs have reached the end of their product life cycle. Expanding MGW capacity may
be difficult because relevant hardware may approach the End of x (EOX) phase and be no longer
available.

• Inter-VoLTE network traffic no longer passes through the IP multimedia media gateways (IM-MGWs).
Instead, the traffic is steered to the interconnection SBC (I-SBC). Investment in IM-MGWs is wasted.

• There are many interfaces on conventional gateway offices, resulting in complex networking and
O&M. The gateway offices using legacy hardware require increased investment for cloudification.

To address the preceding challenges, Huawei innovatively proposes the convergent gateway office solution.
The solution integrates gateway offices in all scenarios and realizes interworking of different types of
networks in a unified way.

• Network Architecture of Convergent Gateway Offices

2025-04-25 147
Technology Series

In the SVC convergent gateway office solution, the CloudSE2980 provides functions of the gateway
MSC (GMSC) servers, gateway MGWs (GMGWs), MGCFs, IM-MGWs, I-BCFs and BGFs. In this way, the
CloudSE2980 supports CS-CS, CS-IMS, and IMS-IMS interworking, simplifying network interworking
and realizing centralized route control. The following figure shows the differences before and after a
convergent gateway office is deployed.

• Before the convergence, GMSC servers/GMGWs, I-BCFs/I-BGFs, MGCFs/IM-MGWs are deployed

for CS-CS, IMS-IMS, and IMS-CS interworking, respectively.

• After the convergence, CloudSE2980s are deployed for CS-CS, IMS-IMS, and IMS-CS interworking.

You can deploy CloudSE2980s or reconstruct existing CloudSE2980s to provide convergent gateway
office functions.

• Highlights of Convergent Gateway Offices

By deploying an SVC convergent gateway office, latency caused by inter-network traffic detour and
transcoding times are reduced, improving inter-network service processing efficiency and voice quality.
An SVC convergent gateway office has the following features:

• Convergent interconnection: The CloudSE2980 is a 6-in-1 gateway office that can route signaling
and media streams between 2G, 3G, 4G, 5G, and fixed-line subscribers.

• One-time investment: A convergent gateway office covers the functions of multiple gateway
offices. This simplifies network architecture, reduces construction costs, and improves hardware
resource utilization.

• All-cloud architecture: The solution is based on future-oriented 5G architecture and is the

industry's first all-cloud platform with high media processing performance.

In this series, we have explored how voice solutions on mobile and fixed networks evolve into the ultimate
convergence solution. In addition, we have analyzed the differences between the five SVC sub-solutions
before and after the convergence. What are the key technologies in the SVC convergence evolution? We
will continue to unveil them in the next series.

2.3 Key Technologies of Single Voice Core

• Forewords

• SVC Network Architecture

• Convergence Architecture Provided by SVC

2025-04-25 148
Technology Series

Forewords

The voice service is one of the basic services provided by carriers. With the development of the voice
network, the core network has undergone a process from convergence to decoupling and then to
convergence. With Single Voice Core (SVC), the existing five types of networks are converged, bringing a
myriad of advantages to the unique architecture and leveraging various solutions. SVC has become the
optimal voice and video solution in the industry. But, what exactly is its network architecture, and what are
the advantages? Now, let's learn about the key technologies of SVC.

SVC Network Architecture

With the introduction of 5G, the voice network needs to support Vo5G on the basis of the Circuit Switched
(CS), Voice over LTE (VoLTE), and fixed networks, which brings numerous challenges to carriers. To cope
with the challenges, Huawei launched the SVC solution. SVC uses the IP Multimedia Subsystem (IMS) to
provide access and full-range services for 2G, 3G, 4G, 5G, and fixed-line subscribers. With this solution,
network reconstruction will accelerate the sunsetting of CS networks and transformation to all-cloud
networks, helping carriers reduce Operating Expenses (OPEX) and eliminating the high Total Cost of
Operations (TCO) caused by simultaneous operations of multiple networks.
The figure below shows the SVC network architecture. This architecture achieves convergence at the
control plane, media plane, and gateway office, and therefore can help build a simplified voice and video
network.

1. Control plane convergence: Huawei CloudTAS supports Fixed Mobile Convergence Telephony
Application Server (FMC TAS) and Emulated Mobile Switching Center (MSC)/Visitor Location
Register (VLR) functions, and processes services for 2G, 3G, 4G, 5G, and fixed-line subscribers. In
particular, the Emulated MSC/VLR functions can process all services of 2G and 3G CS subscribers,
enabling the sunsetting of all CS networks. Huawei CloudCSCF integrates the functions of the
Serving-Call Session Control Function (S-CSCF), Interrogating-Call Session Control Function (I-CSCF),

2025-04-25 149
Technology Series

Breakout Gateway Control Function (BGCF), and Media Resource Function Controller (MRFC) to
implement unified call control.

2. Media plane convergence: Currently, the media gateways (MGWs) are separately deployed on both
the CS and IMS networks. The CloudSE2980 provides the media gateway function for the entire 2G
to 5G range of converged access, functioning not only as the Mobile Access Gateway Control
Function (mAGCF) and Proxy-Call Session Control Function (P-CSCF) to allow all subscribers to
access the SVC network, but also as the Virtual Media Gateway (VMGW) and Access Session Border
Controller (A-SBC) to implement unified processing on the media plane.

3. Gateway office convergence: The Media Gateway Control Function (MGCF) needs to be introduced
for VoLTE deployment. In the future, the Interconnection Session Border Controller (I-SBC) also
needs to be deployed to support the IP-based service processing. The voice network gateway office
needs to evolve twice and supports the communication within the gateway office. The CloudSE2980
alone can provide all control-plane and media-plane functions at the CS, IMS, and IP gateway
offices, including the Gateway Mobile Switching Center (GMSC), MGCF, Interconnection Border
Control Function (I-BCF), Gateway Media Gateway (GMGW), IP Multimedia Media Gateway (IM-
MGW), and Interconnection Border Gateway Function (I-BGF).

With the all-cloud product portfolio and network function integration, SVC can greatly simplify the voice
network and reduce OPEX. This is attributed to the convergence architecture provided by SVC.

Convergence Architecture Provided by SVC

• Convergence at the control plane

SVC integrates the CS and IMS networks to provide a single voice network to provide services for
different types of subscribers. The figure below shows the convergence at the control plane.

The CloudSE2980 enables CS and IMS subscribers to access the CloudIMS. The CloudIMS supports
both service processing and call control, including voice services, supplementary services, value-added
services, Short Message Service (SMS), Unstructured Supplementary Service Data (USSD), and
roaming. Therefore, all CS interfaces are incorporated into the SVC, which reduces the peripheral
interfaces by 50%, simplifying Operations and Maintenance (O&M) as well as reducing device
investment and maintenance costs. Additionally, calls between CS and IMS subscribers do not need to
be connected through gateway offices, saving trunk resources and improving voice quality.
How can services be processed after a CS subscriber accesses the IMS network?
This processing is the most important and innovative part of Huawei's SVC solution. All CS services
can be divided into two parts. One part can be processed by the IMS network through the standard
IMS Centralized Service (ICS) flow, such as Call Forwarding (CFX), Call Hold (CH), and Explicit Call

2025-04-25 150
Technology Series

Transfer (ECT). The other part is the services (such as SMS, USSD, and roaming) that cannot be
implemented by the ICS flow. These services cannot be processed on the IMS network and still need to
be processed on the CS network. As such, the ICS solution cannot enable the sunsetting of all CS
networks, and the interfaces between the CS network and peripheral NEs must be retained.
The following uses an inbound roaming service as an example to describe how the service is
implemented in the SVC solution. The figure below shows the process for a CS subscriber to access the
SVC network.

• For inbound roaming services in the CS service flow, the subscriber sends a location update
request to the Network Element (NE) related to access and mobility management on the CS
network, and then the NE sends the request to the Home Location Register (HLR).

• For inbound roaming services in the SVC service flow, the subscriber sends a location update
request to the mAGCF. Based on 3GPP specifications, the mAGCF converts the location update
request to Session Initiation Protocol (SIP) signaling and sends the SIP signaling to the CloudTAS.
The CloudTAS simulates the VLR and sends the location update information to the HLR over the
Mobile Application Part (MAP) interface. In this way, the inbound roaming services of the CS
subscriber can be processed on the SVC network.

If a subscriber with account creation on the CS network needs to be migrated to the SVC network, is
account creation required on the SVC network?

In the SVC solution, there are two solutions, which correspond to two different service provisioning
solutions.

• In one solution, account creation is not required, as described above. The subscriber data and
service data are obtained from the HLR on the CS network.

• In the other solution, account creation is required. The subscriber data and service data are
obtained from the local Home Subscriber Server (HSS).

If CS subscribers need to access the SVC network, the solution with account creation not required is
recommended. The solution with account creation required requires HSS capacity expansion and
applies only to local subscribers. The solution with account creation not required applies to local and
roaming subscribers and does not require HSS capacity expansion, saving HSS storage resources. In

2025-04-25 151
Technology Series

addition to the roaming service, other services such as SMS and USSD require similar processing. After
all the services of CS subscribers are processed on the SVC network, the interfaces between the CS
network and peripheral NEs can be incorporated to the interfaces between the IMS system and the
Element Management System (EMS), between the IMS system and the charging/provisioning system,
as well as between the IMS system and peripheral NEs.
What are the impacts on peripheral devices after CS subscribers access the SVC network? What are
the requirements for the network? The following table describes the impacts and requirements.
Scenario Solution for 2G/3G Subscribers to Access the IMS Network Requirements
Network and Impacts on Peripheral NEs

Service Account creation required: For local 2G/3G Account creation required: The Business &
provisioning subscribers, define 2G/3G subscribers on the IMS- Operation Support System (BOSS) defines
HSS based on the VoLTE subscriber data model. 2G/3G subscribers as ICS subscribers on
The IMS-HSS needs to support all 2G/3G the IMS-HSS based on the VoLTE
subscribers accessing the network. subscriber definition interface.
Account creation not required: For local 2G/3G Account creation not required: The service
subscribers and roaming subscribers, the TAS data in the HLR and the service
obtains subscriber service data from the HLR and provisioning interface of the HLR are
converts the data into repository data. The TAS reused.
simulates the IMS-HSS to process the data.

Charging After all the 2G/3G subscribers who have been The billing center needs to adapt to 2G/3G
defined as IMS ICS subscribers access the IMS subscribers' CDRs generated on the TAS.
network, the mAGCF does not generate Charging The CDRs contain the identifiers of
Data Records (CDRs). Instead, the TAS generates inbound roaming and local 2G/3G
CDRs for these subscribers. subscribers.

ENUM Account creation required: All local 2G/3G Account creation required: The ENUM
subscribers on the SVC network are IMS server capacity needs to be expanded to
subscribers. Account creation is required for these support all 2G/3G and VoLTE subscribers
subscribers on the E.164 Number to URI Mapping on the network.
(ENUM) server.
Account creation not required: Account
Account creation not required: Account creation is creation is not required for 2G/3G
not required for 2G/3G subscribers on the ENUM subscribers on the ENUM server. The
server. ENUM server only needs to support all
VoLTE subscribers.

IMS-HSS Account creation required: All 2G/3G subscribers Account creation required: The IMS-HSS
access the IMS network. The IMS-HSS needs to capacity needs to be expanded to support
support all subscribers on the network. In this all 2G/3G, VoLTE, and inbound roaming
case, the IMS-HSS capacity needs to be expanded subscribers on the network.
based on the total number of subscribers on the
Account creation not required: Account
network.
creation is not required for 2G/3G
Account creation not required: Account creation is subscribers on the IMS-HSS. The IMS-HSS
not required for 2G/3G subscribers on the IMS- only needs to support all VoLTE
HSS. subscribers.

DRA Account creation required: All 2G/3G subscribers Account creation required: The DRA
access the IMS network. The Diameter Routing capacity needs to be expanded to support
Agent (DRA) needs to support all subscribers on all 2G/3G and VoLTE subscribers on the
the network. In this case, the IMS-HSS capacity network.

2025-04-25 152
Technology Series

Scenario Solution for 2G/3G Subscribers to Access the IMS Network Requirements
Network and Impacts on Peripheral NEs

needs to be expanded based on the total number Account creation not required: The TAS
of subscribers on the network. simulates the HSS. The CSCF is directly
connected to the TAS/ICS IWF over the Cx
Account creation not required: The TAS simulates
interface without requiring the DRA.
the HSS. The Call Session Control Function (CSCF)
Therefore, the DRA capacity does not need
is directly connected to the TAS/ICS Interworking
to be expanded.
Function (ICS IWF) over the Cx interface without
requiring the DRA. Therefore, the DRA capacity
does not need to be expanded.

As described in the table, Huawei's innovative solution enables all services of CS subscribers to be
processed on the IMS network and incorporates all interworking interfaces of the CS network,
achieving full convergence and sunsetting of all CS networks. Convergent service processing is the
essence of the SVC solution, offering the following advantages:

• Convergent deployment of NEs saves 20% of Network Functions Virtualization Infrastructure

(NFVI) resources and reduces peripheral interfaces by 50%.

• Various fixed-line access types, including SIP, H.248, Media Gateway Control Protocol (MGCP),
Primary Rate Access (PRA)/Basic Rate Access (BRA), and R2, are supported.

• The fully convergent TAS inherits fixed network services on the Public Switched Telephone
Network (PSTN) and Next-Generation Network (NGN), reducing subscriber migration risks.

• Automation tools support smooth subscriber migration from Huawei Advanced Telecom
Computing Architecture (ATCA)-based IMS to Network Functions Virtualization (NFV)-based IMS.

• Convergence at the media plane

On the current network, the MGWs are separately deployed on the CS and IMS networks. In the SVC
solution, CS and IMS subscribers access the network through the A-SBC (mAGCF/P-CSCF) provided by
the CloudSE2980. The CloudSE2980 convergent media engine also provides the logical NE capabilities
of the VMGW and A-SBC. Therefore, the signaling and media planes of fixed and mobile terminals can
be converged. The figure below shows the convergence at the media plane.

In the SVC solution, the CS and IMS media plane functions are integrated into the CloudSE2980. In
this way, media resources are processed in a unified manner and hardware resources on the media
plane are reused. After NEs are cloudified, NFVI hardware resources can be shared only by adjusting
network configurations in a dedicated time window. Cloud-based and convergent NEs can share basic
functions such as Load Balance (LB), Database (DB), and O&M, saving resources. The SVC solution not
only enables NFVI hardware and basic function sharing, but also deeply converges NE functions. The

2025-04-25 153
Technology Series

following uses the in-depth convergence of the VMGW and A-SBC as an example. The VMGW and A-
SBC have similar service logic and functions in media processing. Through in-depth convergence, they
can use the same modules to process media. No manual operations (for example, configuration or
adjustment) are required for resource sharing.

Based on the above, the media plane convergence significantly improves the utilization of media
resources, and has the following advantages:

• The IMS media gateway is compatible with the CS media gateway, preventing duplicate
investment.

• Centralized deployment of the NFV-based CS and IMS media planes reduces 50% of sites,
footprint, and power consumption.

• The convergent deployment of the VMGW and A-SBC reduces 50% of NFVI resource consumption
(such as DB and LB) of common components and 30% of transcoding (TC) resource
consumption.

• The number of media paths decreases, the number of hops on the media plane for a call
between CS and VoLTE networks decreases from 3 to 1, and the Mean Opinion Score (MOS)
increases by 0.2-0.4.

• Convergence at the gateway office

The gateway office convergence is another feature of SVC. On the current CS and IMS voice networks
that are not using the SVC solution, the MGCF needs to be introduced for 4G VoLTE deployment. In
the future, the I-SBC also needs to be deployed to support the IP-based gateway office. The voice
network gateway office needs to evolve twice and supports the communication within the gateway
office. With the CloudSE2980, the SVC converges three gateway offices and six NEs. The CloudSE2980
provides the functions of the GMSC, MGCF, I-BCF, GMGW, IM-MGW, and I-BGF, converges gateway
offices, and supports the interworking between fixed and mobile networks. The figure below shows
the convergence at the gateway office.

2025-04-25 154
Technology Series

How does the CloudSE2980 fully converge gateway offices? Why is this convergence another feature
of the SVC solution?
The figure below compares the call paths of a local CS subscriber and an IMS subscriber on the SVC
solution and other voice solutions.

• On other voice solutions, calls are processed by the CS end office (Visited Mobile Switching
Center (VMSC)+VMGW), CS gateway office (GMSC+GMGW), IMS-MGCF gateway office
(MGCF+IM-MGW), and IMS system. In this case, the call path is longer. When media is being set
up during a call, extra TC resources are consumed because the media is processed by two
gateway offices. As a result, the call connection takes a longer time.

• In the same scenario, if the SVC solution is used, the CS and IMS networks are integrated into one
voice network. Calls only need to pass through the CS end office, convergent gateway office
CloudSE2980, and IMS system. The processing on gateway offices such as the MGCF is not
required, greatly simplifying the call flow. Furthermore, TC resources are saved, and the number
of call paths and transcoding times decreases, reducing the connection delay and improving
subscriber experience.

As we are well aware, interworking with CS subscribers on other PLMNs consumes resources on the
CS and the IMS-MGCF gateway offices, and interworking with IMS subscribers of other Public Land
Mobile Networks (PLMNs) through IP consumes resources on the IP gateway office (I-BCF/I-BGF).
With the full convergence and the change in the traffic between the gateway office and the external
network, the in-depth convergence of the IM-MGW/GMGW and I-BGF enables automatic reuse of
hardware resources. The MGCF/GMSC and I-BCF also support hardware resource sharing, reusing
hardware resources to the maximum extent. The advantages of the gateway office convergence are as
follows:

2025-04-25 155
Technology Series

• NFV-based deployment enables IP gateway offices to smoothly evolve and protect the
investment.

• The convergent deployment of the MGCF, GMSC, and I-BCF reduces 50% of NFVI resource
consumption of common components. The IM-MGW and I-BGF share the TC resource pool.

• The convergent gateway office reduces the number of internal interworking nodes and manages
external routing policies in a unified manner.

• The convergent gateway office reduces the number of media forwarding times by preferentially
selecting the same MGW, reducing TC resource consumption, shortening the delay, and
improving the voice quality.

Based on the three key technologies, the SVC solution provides a 5G-oriented, all-cloud, and fully
convergent voice network and enables the sunsetting of CS networks. The overall network is greatly
simplified. In particular, the simplified voice network architecture improves resource utilization and
maintenance efficiency, and the cloud-native-based agile network integrates multiple networks, reduces
costs, and improves efficiency, lowering O&M and making the SVC become the optimal voice and video
solution in the industry. The success of the SVC solution depends on the contributions of key NEs such as
the TAS, CSCF, and Session Border Controller (SBC). How do they emerge, what capabilities do they have,
and how do they evolve? We will unveil these in the subsequent sections.

2.4 Core NEs of Single Voice Core: AS

• Forewords

• Introduction and Evolution of the ATS9900

• ATS9900 in the SVC Solution

• Summary

Forewords

Before you embark on reading this document, it is assumed that you have prior knowledge of the Single
Voice Core (SVC) solution. Here, we will focus on the Application Server (AS), which is one of the most
crucial Network Elements (NEs) in the SVC solution. The SVC is a modern voice solution that offers a wide
range of multimedia services, making it highly popular among customers and carriers. The primary driving
force behind the SVC is the AS, which is powered by the ATS9900 and is responsible for handling various
types of services.

Introduction and Evolution of the ATS9900

The ATS9900 serves as the AS for processing and controlling services, and its development is fueled by the
service needs of subscribers. In this document, we will introduce its history and evolutionary progress.
Inspired by PSTN and NGN networks
During the fixed network era, fixed-line calls were just starting to emerge on the initial Public Switched
Telephone Network (PSTN) and Next Generation Network (NGN) networks. At that time, only a few

2025-04-25 156
Technology Series

people had access to phones, and both the user relationship network and the fixed network were relatively
simple. As a result of its simplistic nature, users only needed to make voice calls and did not have high
expectations for voice call services. Therefore, there was no NE specifically designed for processing voice
call services. Instead, the SoftX3000/CC&08 was used as the core for service processing, route forwarding,
and bearer controlling.
Available on VoBB networks
When Voice over Broadband (VoBB) networks were created, the introduction of a greater range of call
functions led not only to an increase in the volume of subscribers, but also more complex relationships
between them. As a result, new service requirements emerged, such as call forwarding and caller ID
presentation. However, the SoftX3000/CC&08 was unable to meet these requirements, so an independent
service function was required. After extensive research and development, the ATS9900 was designed to
independently process, control, and trigger voice services. To cater to different subscriber groups, the
ATS9900 provides two logical NEs: the Multimedia Telephony Application Server (MMTel AS) for individual
subscribers and the Centrex AS for group subscribers. The Centrex AS provides services for subscribers in a
group, where the group's rules are strictly followed when calling or sending messages each other. In
addition, the ATS9900 uses processes as the basic units to allocate and schedule resources, with the Call
Control Unit (CCU) process used to process fixed network services.

The ATS9900 has evolved as follows.

2025-04-25 157
Technology Series

How Logical NEs Evolve

With the rise of mobile communications, there has been a surge in mobile subscribers on networks and an
increase in demand for mobile communication, as opposed to traditional fixed-line communication. On
Voice over LTE (VoLTE) networks, the ATS9900 starts to serve both fixed-line and mobile subscribers, and
it functions as Service Centralization and Continuity Application Server (SCC AS), Anchor AS, IP Short
Message Gateway (IP-SM-GW), and IP Multimedia Service Switching Function (IM-SSF), instead of only
MMTel AS and Centrex AS. The Centrex AS is still used to serve group and enterprise subscribers, while the
other five logical NEs are dedicated to processing new types of services for individual subscribers. To
handle a large volume of service requests, the CCU process, which only supports fixed networks, is being
replaced by the Service Control Unit (VCU) process that supports both fixed and mobile convergence
networks. This allows the ATS9900 to process both fixed and mobile service requests.
The ATS9900 is encountering a myriad of new challenges with the implementation of the SVC solution,
which is a voice network that offers unified access for 2G to 5G range of subscribers. Once the Circuit
Switched (CS) subscribers are migrated to the SVC network, the IMS Centralized Services Interworking
Function (ICS IWF) is introduced to the ATS9900, allowing these subscribers to continue using the services
provided by the SVC network.
In the SVC solution, the ICS IWF serves as a crucial logical NE. The first challenge after existing CS
subscribers access the SVC network is how to obtain their data. Ideally, these CS subscribers should be
redefined in the SVC network and their data should be stored in the HSS of the SVC network. However,
migrating all their data to the Home Subscriber Server (HSS) of the SVC network requires a significant
amount of storage space and time. Alternatively, if their data is retained in the Home Location Register
(HLR) of the CS network, it will cause the NEs on the SVC network to become overwhelmed and this will
negatively impact user experience. To address this issue, an account can be defined for some of CS
subscribers on the SVC network and their data can be temporarily stored in the HSS on this network.
However, this method is limited by available storage capacity and network deployment cost. The ATS9900
must be able to serve these subscribers without defining an account for them. The ICS IWF can temporarily
store their data, obtaining it in real time from the HLR when they register with the SVC network and
deleting it when they deregister. This eliminates the need to define an account for these subscribers on the
SVC network, saving storage space and related costs.
How the CCU Process Is Replaced with the VCU Process
It is a well-known fact that the ATS9900 utilized the CCU process during the fixed network era. However,
with Fixed-Mobile Convergence (FMC), the ATS9900 switched to using the VCU process instead. What
prompted this change?
With the emergence of VoLTE networks, the CCU process is unable to handle mobile Intelligent Network
(IN) services and the heavy workload of new VoLTE services, allow logical NEs to be separated from each
other or co-deployed, support interaction between multiple services, or manage non-standard repository
data. Only the VCU process can do all of these.
The differences between the CCU and VCU are as follows:

1. Network deployment: The CCU is limited to fixed networks, while the VCU can be deployed on fixed,
mobile, and FMC networks.

2. Functions: The CCU offers only two logical functions for multimedia services, exclusively for fixed-
line subscribers. On the other hand, the VCU provides six or seven logical functions for multiple

2025-04-25 158
Technology Series

multimedia services, catering to both fixed-line and mobile subscribers. The VCU is more robust than
the CCU and is expected to have wider usage in the future.

3. Software structure: The CCU's software structure is designed to offer multimedia services exclusively
for fixed-line subscribers, while the VCU's software structure caters to both fixed-line and mobile
subscribers.

By replacing the CCU with VCU, the ATS9900 can keep up with the fast-paced growth of mobile services.

ATS9900 in the SVC Solution

On an SVC network, the ATS9900 functions as seven logical NEs: MMTel AS, Centrex AS, SCC AS, Anchor
AS, IP-SM-GW, IM-SSF, and ICS IWF.
Functions of Logical NEs

• The Prime Logical NE — MMTel AS

The MMTel AS is the core network element used for processing voice services and handling the
majority of our basic calls. In this section, we will use call forwarding services as an example to explain
how the MMTel AS processes these basic calls. The call forwarding services include the following
types:

• Call Forwarding Unconditional (CFU): When Party A (A) calls Party B (B), the MMTel AS will
automatically forward the call to a third party (C) without any conditions, regardless of whether
B is available or not. B will not receive the call from A.

• Call Forwarding Busy (CFB): When A calls B and B is already on a call, the MMTel AS will forward
the call to C.

• Call Forwarding on No Reply (CFNR): When A calls B and B's phone rings but B does not answer
the call, the MMTel AS will forward the call to C.

• Call Forwarding on User Not Reachable (CFNRc): When A calls B and B is unreachable because it
is out of the service area, the MMTel AS will forward the call to C.

In brief, if A calls B and the MMTel AS detects that B has activated a call forwarding service and that
the call meets the service conditions, the call will be forwarded to C.

2025-04-25 159
Technology Series

• Route Distributor — SCC AS

The SCC AS performs terminating access domain selection (T-ADS) for FMC subscribers. It can also
collaborate with Single Radio Voice Call Continuity Interworking Function (SRVCC IWF) and Access
Transfer Control Function (ATCF)/Access Transfer Gateway (ATGW) to facilitate Enhanced Single
Radio Voice Call Continuity (eSRVCC).
This section uses VoLTE, a sub-solution in the SVC solution, as an example to explain Terminating
Access Domain Selection (T-ADS). VoLTE-capable UEs can connect to multiple networks, such as 2G,
3G, or 4G, depending on signal strength. When the UEs receive voice calls, an access domain must be
selected to connect the calls, a process known as domain selection. When the UEs are making calls,
UEs select an access domain based on the network they are registered with. When the UEs are
receiving calls, the network queries the registered network's data and selects an access domain. The
4G and 2G/3G subscribers share the same number segments. When a 4G subscriber receives a call, the
network selects the Long Term Evolution (LTE) or CS network based on the latest registered domain
of the LTE subscriber, not just their number segment.
When A calls B, the network does not know which network B is on. The SCC AS is used to locate B and
route the call to B's network. The T-ADS enables the SCC AS to locate B's network. For instance, if B is
on a CS network, the SCC AS will route the call to that network.

2025-04-25 160
Technology Series

• Powerful Anchor – Anchor AS

The Anchor AS is used to anchor service requests to the IP Multimedia Subsystem (IMS) network. In
the event that VoLTE and Voice over 5G (Vo5G) subscribers who have subscribed to voice services
move to a 2G/3G network, their voice service requests will still be triggered in the IMS domain
because they are anchored to the IMS network.
More specifically, if a VoLTE subscriber accesses the network through the CS domain and makes or
receives calls, the Anchor AS will initiate the IN-based redirect process and route the call to the IMS
domain to activate Mobile Originated (MO) or Mobile Terminated (MT) services. Similarly, if a VoLTE
subscriber accesses the network through the IMS domain and receives a call from a CS subscriber, the
Anchor AS will initiate the IN-based redirect process and route the call to the IMS domain for
connection.

2025-04-25 161
Technology Series

• Shortcut to Obtain Data — ICS IWF

The ICS IWF is used to retrieve service and subscriber data for 2G/3G subscribers and 4G CS Fallback
(CSFB) subscribers. Usually, the ICS IWF is logically co-deployed with the MMTel AS to offer
registration, basic calls, and supplementary services for these subscribers.
The data of CS subscribers who have migrated to the SVC network is still stored on the HLR. However,
to ensure that these subscribers can still access their original services on the SVC network, their data
needs to be stored on the SVC network as well. Unfortunately, there is not enough storage space to
accommodate this data. To address this lack of storage space, the ICS IWF as a transfer station for
subscriber data is employed. The ICS IWF is co-deployed with the MMTel AS and downloads data only
for CS subscribers, who access the network, from the HLR, without storing it. This data is then
provisioned to trigger services. When 2G/3G subscribers de-register from the network, the ICS IWF
deletes their data to free up more storage space, whereas, the HLR stores their service data and
subscriber data. The ICS IWF simulates the HSS and downloads the data from the HLR to provision it.
The HSS is not used as a database to store the data of 2G/3G subscribers, but only to verify if an
account has been defined for them.
Simply put, the ICS IWF does not directly activate services for subscribers. Its purpose is to retrieve
service and subscriber data for 2G/3G subscribers and 4G CSFB subscribers. When these subscribers
connect to the network, the ICS IWF retrieves their data from the HLR on their HPLMN.

2025-04-25 162
Technology Series

• SMS Expert — IP-SM-GW

The IP-SM-GW directs Short Message Service (SMS) requests to the Short Message Service Center
(SMSC), enabling the exchange of short messages between subscribers on different networks and
between the IMS and CS domains.
Here's a more precise way to phrase it. The IP-SM-GW processes the short message that A sends to B.
When A sends a short message to B, the IP-SM-GW processes it. There are two IP-SM-GWs involved,
one serving A and the other serving B. Both IP-SM-GWs are connected to the SMSC, which transfers
the short message to B.

2025-04-25 163
Technology Series

• First Logical NE that ATS9900 Provided — Centrex AS

The Centrex AS offers a convergent Centrex service for FMC subscribers, providing enterprise
customers with an all-IP solution that integrates FMC networks, telecommunications, and Information
Technology (IT).
If A and B work for the same railway bureau and use enterprise services to communicate, A can call B
by dialing the internal short number of the railway bureau. The call is routed to the Centrex AS
through the railway bureau's internal network. The Centrex AS then connects the call to B based on
their internal short number.

2025-04-25 164
Technology Series

• All-in-One IN Service Trigger — IM-SSF

The IM-SSF verifies subscription information from the Serving-Call Session Control Function (S-CSCF)
and local configuration data before contacting the Service Control Point (SCP) to activate IN services.
Services such as a blacklist and whitelist, One Number, and call barring that we regularly use are all
examples of IN services. However, the IM-SSF does not directly handle these services. Instead, when
subscribers who have subscribed to these services make or receive calls, the IM-SSF identifies the IN
services by checking their subscription information and transfers them to the SCP for further
processing.

2025-04-25 165
Technology Series

Peripheral NEs and Interfaces

Let's examine how the ATS9900 interacts with its peripheral NEs and related interfaces. To simplify the
explanation of peripheral NEs and interfaces, this section will use a service flow as an example.

2025-04-25 166
Technology Series

The ATS9900 only handles services that subscribers have activated, which are provisioned by the Service
Provisioning Gateway (SPG). To achieve this, the ATS9900 communicates with the SPG through the Simple
Object Access Protocol (SOAP) interface.
When processing SMS requests, the IP-SM-GW sends them to the SMSC over the E interface. When
processing IN service requests, the IM-SSF routes them to the SCP over the CAMEL Application Part (CAP)
interface.
When subscribers who access the network through CloudSE2980 make calls and send SMS requests or
similar requests, the Interrogating-Call Session Control Function (I-CSCF)/S-CSCF directs them to ATS via
the IP Multimedia Service Control (ISC) interface. The Call Session Control Function (CSCF) checks the
initial filter criteria (iFC) obtained from the HSS and then contacts the ATS to trigger services. The ATS
retrieves subscriber service data from databases such as the HSS and HLR over the Sh/Dh interface. Once
services are triggered, the called parties' phones ring. The ATS collaborates with the Multimedia Resource
Function Controller (MRFC), which manages announcement playback, digit collection, conference bridges,
and video streaming media, over the Mr interface. During service usage, the AS triggers offline or online
charging over the Rf or Ro interface, respectively.
To round-up this section, we'll explore the interworking of the ICS IWF. On an SVC network, new interfaces
are added to enable the ICS IWF to collaborate with other NEs. As previously mentioned, the ICS IWF
temporarily stores data of CS subscribers on the SVC network. When these subscribers access the network
through the Mobile Access Gateway Control Function (mAGCF) and register, the mAGCF sends messages
to CSCF. The CSCF then forwards the messages to the ICS IWF over the Cx' interface, and the ICS IWF
retrieves subscriber data from the HLR over the C/D interface. The ICS IWF also collaborates with the
mAGCF over the I3 interface and with the HSS over the Cx' interface.

Summary

The ATS9900 offers seven logical NEs to handle various service types. It can trigger and process voice
communication services for fixed network subscribers and the entire range of 2G to 5G subscribers. In
VoBB networks, the ATS9900 provides two logical NEs, while in VoLTE networks, it offers six logical NEs. In
SVC networks, it provides seven logical NEs. Its core process has shifted from the CCU to VCU, enabling it
to handle more service types. In the current SVC solution, the ATS9900 offers crucial logical functions and
collaborates with the CloudSE2980 and other NEs to ensure the SVC network operates smoothly.
The ATS9900 functions like a sophisticated and intricate machine, tirelessly processing massive service
requests around the clock.
That's all about this issue. Stay tuned for further updates.

2.5 Core NEs of Single Voice Core: SBC

• Forewords

• SBC Evolution on Fixed Networks

• SBC Evolution on Mobile Networks

Forewords

2025-04-25 167
Technology Series

Past series have taught us how the Single Voice Core (SVC) solution is formed and in particular, how it
impacts voice services. The details outlined in this series will increase your proficiency with another core NE
of the SVC solution: Session Border Controller (SBC). The SBC integrates functions of all logical control-
and media-plane NEs at the access and interworking layers, making itself indispensable for realizing
convergent control, access, and interworking of the all-in-one SVC network.
The SBC has gone through several important development phases throughout the history of the mobile
communication network. And the purpose of these technical series is to help strengthen and educate you
on the origins of the SBC and how it has grown with the mobile communication network.

SBC Evolution on Fixed Networks

SBC on the NGN

The SBC was born on the Next Generation Network (NGN), where it provided security and Network
Address Translation (NAT) traversal proxy functions.
On the NGN, UEs access the Circuit Switched (CS) core network using wired connections, with the SBC
being deployed between UEs and the CS core network to guarantee secure connections.

Another key function of the SBC in its infancy is NAT traversal proxy.

• Users on a public network predominantly use IPv4 addresses to exchange information. On this type of
network, each computer or user has an assigned IPv4 address. However, as the Internet grows, IPv4 is
running out. In order to preempt this, the private network is being utilized. On a private network, a
private IP address space is used for information exchange. However, the private IP addresses may be
the same as the public ones, leading to conflicts when these private IP addresses are directly used to
access a public network. To resolve this, a NAT device can be employed to provide NAT traversal. NAT
traversal allows multiple private IP addresses to share a single public IP address, establishing direct

2025-04-25 168
Technology Series

communication between the private and public networks. In this way, NAT traversal helps conserve
the limited IPv4 address space.

• It is worth noting that the NAT device cannot translate application-layer IP addresses, therefore, two
solutions can be employed to overcome this.

• The first solution involves upgrading all NAT devices so that they support Application Level
Gateway (ALG). However, this solution is costly, complex, and not practical at the moment.

• The second solution involves adding a proxy server (that is, the SBC) outside the NAT devices to
transmit all call signaling and media streams. The signaling and media streams are processed at
the application layer due to sessions on NGN and IP Multimedia Subsystem (IMS) networks
leveraging the Session Initiation Protocol (SIP).

In addition to the above, the SBC can also help connect the NGN to other networks and properly allocate
resources.
SBC from NGN to VoBB
In response to the internal driving forces of Communication Technology (CT) network development and
external challenges faced by the Information Technology (IT) network advancement, a new generation of
all-IP IMS network architecture has emerged.
Huawei's IMS solution helps carriers focus on user experience, create refined network O&M, and transform
towards Information and Communications Technology (ICT) convergence. It becomes a key control point
for carriers to promote the convergence of networks, data, services, and operations, helping them take the
lead in the eras of post-voice, mobile Internet, and ICT convergence and further accelerate service
monetization.
The Voice over Broadband (VoBB) solution, which is based on the IMS, allows conventional fixed-line
terminals to access the IMS network through the SBC after converting voice signals into IP packets.
Services are processed on the core network so that subscribers can enjoy diverse voice services. In the VoBB
solution, the SBC provides both security and user access functions.
The VoBB solution is able to:

• Provide centralized user access control, network management, service provisioning, data centers, and
application platforms under the all-IP, cloud-based IMS architecture. The VoBB-based network
topology remains stable even when there are frequent service changes.

2025-04-25 169
Technology Series

• Deliver IP-based carrier-grade voice, video, and other rich communications services for fixed
broadband subscribers, and guarantee the experience of different services through End to End (E2E)
Quality of Service (QoS) management, helping carriers better capitalize on broadband network
resources.

On the one hand, the development of fixed networks, from Public Switched Telephone Network (PSTN),
NGN, to IMS-based VoBB, has reached a bottleneck.
On the other hand, the mobile communication network shows much broader prospects with the evolution
of the 1G to 5G range of mobile networks. Voice over LTE (VoLTE), which is also powered by the IMS, is
the optimal mobile voice solution in the 4G era. The SBC has grown exponentially since the IMS was
created, and has made huge strides in the VoLTE era.

SBC Evolution on Mobile Networks

Over the course of mobile voice services history, CS, VoLTE, and Vo5G solutions have dominated the
mobile voice network in the 2G/3G, 4G, and 5G eras, respectively.

• In the 2G/3G era, CS was the mainstream voice solution for mobile subscribers, and the MSC server
processed sessions for them. 2G subscribers connect to the MSC server through RAN, while 3G
subscribers connect to the MSC server through the RAN and the MGW. The UMG8900 functions as an
MGW on the 3G network. And in this era, the SBC provides only basic security functions.

• In the 4G/5G era, VoLTE/Vo5G has become the typical voice solution for mobile subscribers. 4G
subscribers access the IMS core network through the Evolved Packet Core (EPC) and A-SBC, and 5G
subscribers access the IMS core network through the 5G Core Network (5GC) and A-SBC. An
Interconnection Session Border Controller (I-SBC) is also utilized to allow different IMS networks to
communicate with each other. In this era, the SBC holds an essential position at both the access and
interworking layers of the IMS network.

• The SVC solution proposed by Huawei marks an important milestone of mobile voice services. The SBC
used in the SVC solution integrates the functions of all gateway office and end office logical NEs of
the MSOFTX3000 to realize convergent access and interworking.

• Convergent access: The SBC is the integration of the Access Border Control Function (ABCF),
Border Gateway Function (BGF), Mobile Access Gateway Control Function (mAGCF), Virtual
Media Gateway (VMGW), and Proxy-call Session Control Function (P-CSCF). In this way, a
centralized entrance is available to the IMS network for the entire range of 2G to 5G subscribers
and VoBB subscribers.

• Convergent interworking: The SBC provides the Gateway Mobile Switching Center (GMSC),
Gateway Media Gateway (GMGW), Media Gateway Control Function (MGCF), IP Multimedia
Media Gateway (IM-MGW), Interconnection Border Control Function (IBCF), and BGF functions.
In this way, it functions as a 6-in-1 gateway office that interconnects signaling and media
between CS networks, between IMS networks, as well as between CS and IMS networks.

2025-04-25 170
Technology Series

Now that we are up to speed with the fact that the SBC has the combined functions of numerous other
NEs in the SVC era, these functions can be classified into end office functions and gateway office functions
in terms of their network positions. Next, let's delve into the SBC evolution from these two dimensions.
End Office Evolution of the SBC
When the SBC first came about, the A-SBC was the only end office function. The A-SBC consists of the
ABCF and BGF, both of which are deployed between the access network and the core network.

• The ABCF controls access and defends security.

• The BGF processes packets on the media plane.

On the basis of the ABCF and BGF, the SBC gradually develops and finally unifies the access layer by
undertaking the functions of other end office logical NEs. These NEs include the P-CSCF, Access Transfer
Control Function (ATCF)/Access Transfer Gateway (ATGW), Emergency-Call Session Control Function (E-
CSCF)/Emergency Access Transfer Function (EATF), Single Radio Voice Call Continuity Interworking
Function (SRVCC IWF), VMGW, and mAGCF.

• End Office Evolution: Embedded P-CSCF

In the VoLTE solution, 4G subscribers access the IMS core network through the P-CSCF. As an entrance
to the visited IMS network, the P-CSCF forwards SIP messages from the visited access network to the
home Serving-Call Session Control Function (S-CSCF) or Interrogating-Call Session Control Function (I-
CSCF). We can see that the P-CSCF has similar functions and network positions as the A-SBC.
Therefore, the P-CSCF functions can be embedded into the A-SBC for the following reasons:

• The A-SBC provides security and access functions. After the P-CSCF functions are embedded into
the A-SBC, only one NE is used at the access layer. This further simplifies the network and
reduces network maintenance costs.

• The P-CSCF functions as an entrance to the visited domain, and is located nearer to subscribers.
After its functions are embedded into the A-SBC, the A-SBC responds to messages and forwards
signaling more quickly. This improves the network running efficiency and user experience.

• End Office Evolution: Embedded E-CSCF/EATF, ATCF/ATGW, and SRVCC IWF

2025-04-25 171
Technology Series

In the new voice era, voice-only services are unable to meet people's communication expectations.
More diversified voice services and better session experience drive the continuous development of
mobile communication technologies.
The major strength of the next-generation IMS network architecture is that the control, bearer, and
service planes are decoupled. This drives the SBC to enhance its session access, network interworking,
and media processing capabilities. For example, to provide two typical key features, emergency call
and SRVCC, the SBC needs to integrate the following new logical NEs:

• E-CSCF/EATF: Its functions can be embedded into the SBC to provide the emergency call feature.

• The E-CSCF is a signaling-plane NE that analyzes the subscriber's location information and
routes emergency calls to the nearest emergency call center.

• The EATF is a media-plane NE that anchors media flows of emergency calls experiencing
LTE-to-2G/3G handovers to ensure emergency call continuity.

Emergency call is the basic feature of the SBC. The SBC allows subscribers accessing the IMS
network in various modes to originate emergency calls. This feature enables carriers to use the
existing network architecture to support emergency calls originated by subscribers accessing the
network using a new access method. Subscribers can make emergency calls anytime and
anywhere, even when they have not registered with the network or paid their overdue balances.

• ATCF/ATGW and SRVCC IWF: Their functions can be embedded into the SBC to provide the
SRVCC feature.

• The ATCF/ATGW anchors the media flow of a call during which an SRVCC handover is likely
to occur. When an SRVCC handover occurs during the call, only media information on the
ATGW needs to be updated, but remote media information remains unchanged. This speeds
up SRVCC handovers.

• The SRVCC IWF works with the SCC AS to process SRVCC and eSRVCC handovers.

The SRVCC feature enables carriers to provide uninterrupted voice services on the Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) by utilizing existing Universal Terrestrial
Radio Access Network (UTRAN)/GSM/EDGE Radio Access Network (GERAN) infrastructure. Also,
it provides subscribers with uninterrupted voice services when they move out of the E-UTRAN
coverage during ongoing calls.

• End Office Evolution: MGW Integration

Why should we integrate the MGW with the SBC? And why should we choose the SBC over other NEs?
These questions will be answered in this section.
The MGW and BGF are the most important media processing NEs on the CS and IMS networks. The
MGW functions were previously provided by UMG8900 before the MGW was co-located with the SBC.
The UMG8900 works with the MSOFTX3000 to process voice media for 2G/3G subscribers on the CS
network. The SBC, however, uses its BGF and BCF to process voice media at the access layer and
interworking layer on the IMS network.
Based on what we know about mobile networks and how they are changing, we can see that the SBC
and MGW can be converged because of two main reasons:

2025-04-25 172
Technology Series

• Network evolution requirements

As the CS network gradually withdraws while the IMS network proliferates, the MSOFTX3000
(providing signaling control) and UMG8900 (providing media bearer) on the CS network are
being sunsetting. However, 2G/3G subscribers still make up a significant portion of mobile
communication subscribers. To ensure a smooth network evolution without compromising user
experience, the media capabilities of the original UMG8900 must be taken over by a new NE. In
addition, the NE that integrates the MGW must be located nearer to subscribers to make the
media plane processing faster and deliver better user experience.

• Network positions and NE capabilities

The SBC, instead of another NE, is selected to replace the MGW because of the following reasons:

• The SBC and MGW have similar network positions and NE functions at the access layer. The
MGW enables 2G/3G subscribers to access the CS network, and the SBC enables 4G/5G
subscribers to the IMS network. What's more, the SBC's location is nearer to subscribers.

• The SBC and MGW have similar network positions and NE functions at the interworking
layer. The MGW works with the MSC server to forward signaling and media between CS
networks, as well as between a CS network and an IMS network, and SBC forwards signaling
and media between IMS networks.

• The BGF and MGW have similar functions. The BGF is a media processing NE that is able to
convert multiple media codecs. By integrating the MGW functions, the media processing
capability of the SBC is further strengthened.

As the above paragraphs bear witness, both the development trend of the mobile communication
network and the SBC's own positioning and capabilities have necessitated SBC-MGW convergence.
This convergence upgrades the SBC from a session engine to the convergent media engine.
In addition of the end office (VMGW) functions, the MGW integrated by the SBC also provides
gateway office (GMGW, IM-MGW, and TMGW) functions. These NEs are located at different layers on
the network and interwork with different signaling-plane NEs.

• The VMGW is located at the access layer and provides A and Iu interfaces. It works with the
mAGCF to connect 2G/3G subscribers in the CS domain to the IMS network.

• The GMGW is located at the interworking layer and provides Mc and Nb interfaces. It works with
the GMSC server to exchange media between CS networks.

• The IM-MGW is located at the interworking layer and provides Mn and Mb interfaces. It works
with the MGCF to exchange media between CS and IMS networks.

• The TMGW is located at the interworking layer and provides Mc and Nb interfaces. It works with
a TMSC server to transcode speech and play announcements.

• End Office Evolution: mAGCF Integration

Since you are aware that the SBC has replaced the UMG8900 at the media plane on the CS network,
you may wonder what is the evolution target of the MSOFTX3000 on the signaling plane? The answer
is still SBC.

2025-04-25 173
Technology Series

• By integrating the end office (mAGCF) functions of the MSOFTX3000, the SBC supports CS-CS,
CS-IMS, and IMS-IMS interworking. 2G/3G subscribers can access the IMS network through the
mAGCF. This helps smoothly migrate 2G/3G subscribers from the CS network to the IMS network
when the CS network shuts down.

• To fuel SVC development, the SBC must integrate gateway office and end office functions of all
signaling- and media-plane logical NEs of the MSOFTX3000.

Gateway Office Evolution of the SBC

When the SBC first came about, the I-SBC was the only gateway office function. The I-SBC consists of the
IBCF and BGF, both of which are deployed between different core networks.

• The IBCF realizes interworking on the control plane and defends security.

• The BGF processes packets on the media plane.

On the basis of the I-BCF/BGF, the SBC gradually develops and finally unifies the interworking layer by
undertaking the functions of other gateway office logical NEs, such as the GMGW, IM-MGW, GMSC, and
MGCF.

• Gateway Office Evolution: MGW Integration

From the end office evolution part, we are already aware that the SBC integrates all MGW functions,
including the end office (VMGW) and gateway office (GMGW, IM-MGW, and TMGW) functions.

• Gateway Office Evolution: GMSC and MGCF Integration

From the end office evolution part, we are already aware that the SBC integrates all MSOFTX3000
functions, including the end office (mAGCF) and gateway office (MGCF and GMSC) functions.

From struggling on the fixed network to competing with Over the Top (OTT) devices in the 2G/3G era, the
SBC has faced numerous challenges in the past. However, the 4G era gives the SBC an opportunity to
stand out with the VoLTE solution. As the SVC solution matures, the SBC is finally holding a crucial
network position and is displaying vigorous vitality. We expect that, with the advent of 5G, the SBC will
show even greater promise in the future.

2025-04-25 174