Deploy and Apply

5G Core
Acronyms & Abbreviations

Numeric
5GC 5G Core Network
A-C I-M
ABMF Account Balance Management I-CSCF Interrogating-Call Session
Function Control Function
AF Application Function ISTP International Signaling Transfer
AIOps Artificial Intelligence for IT Point
Operations K8s Kubernetes
AMF Access and Mobility LBO Local Breakout
Management Function LCM Life Cycle Management
APN Access Point Name L-NRF Low-level NRF
AS Application Server LSMS Local Service Management
ATS Advanced Telephony Server System
AUSF Authentication Server Function MAE MBB Automation Engine
BSF Binding Support Function MEC Multi-access Edge Computing
CBC Content-based Charging MME Mobility Management Entity
CC Charging Characteristic MO Mobile Originated
CCS Converged Charging System MSISDN Mobile Station International
CDF Charging Data Function ISDN Number
CDR Charging Detail Record
CGF Charging Gateway Function
CHF Charging Function
CHR Charging History Record
D-H N-O
DEA Diameter Edge Agent Next-Generation Charging
NCG
DNN Data Network Name Gateway
DRA Diameter Routing Agent NEF Network Exposure Function
EPS FB EPS Fallback NFV Network Functions Virtualization
FBC Flow-based Charging Network Functions Virtualization
NFVO
Orchestrator
FCAPS Fault, Configuration, Accounting,
Performance, Security Number Portability
NPAC
Administration Center
FQDN Fully Qualified Domain Name
NRF Network Repository Function
F-TEID Fully Qualified Tunnel Endpoint
Identifier NS Network Service
GMLC Gateway Mobile Location Center NSD Network Service Descriptor
GPSI Generic Public Subscription Network Slice Management
NSMF
Identifier Function
GUAMI Globally Unique AMF Identifier Network Slice Selection
NSSAI
Assistance Information
GUMMEI Globally Unique MME Identifier
NSSF Network Slice Selection Function
HA High Availability
Network Slice Subnet
HLR Home Location Register NSSMF
Management Function
H-NRF High-level NRF NSST Network Slice Subnet Template
HSS Home Subscriber Server OCF Online Charging Function
OCS Online Charging System
 Acronyms & Abbreviations

P-R U-Z
Policy and Charging Enforcement UDM Unified Data Management
PCEF
Function
UDR User Data Repository
PCF Policy Control Function
Unified Policy and Charging
Policy and Charging Rules UPCC
PCRF Controller
Function
Unified Policy Control
Proxy-Call Session Control UPCF
P-CSCF Function
Function
UPF User Plane Function
PDN Packet Data Network
Ultra-reliable Low-latency
PDU Packet Data Unit URLLC
Communication
PE Provider Edge Universal Subscriber Identity
USIM
P-GW PDN Gateway Module
PNF Physical Network Function UTA UDM Translation Agent
RF Rating Function Virtualized Infrastructure
VIM
RG Rating Group Manager
ROI Return on Investment VNFD VNF Descriptor
S-T
SBA Service Based Architecture
SBI Service-based Interface
SCP Service Communication Proxy
Serving-Call Session Control
S-CSCF
Function
SDN Software-Defined Networking
SEPP Security Edge Protection Proxy
SGSN Serving GPRS Support Node
S-GW Serving Gateway
SMF Session Management Function
SMSF SMS Function
SPR Subscription Profile Repository
Signaling Service Processing
SPS
System
STP Signaling Transfer Point
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
SVC Single Voice Core
TAI Tracking Area Identity
TAU Tracking Area Update
Telecommunications
TMN
Management Network
Topology and Orchestration
TOSCA Specification for Cloud
Applications
Contents

01 Deployment 1

02 Redundancy 9

5G Core 03 4G-5G Interworking 20

04 Subscriber Migration &

Service Provisioning 27

05 Charging 32

06 O&M Solution 66

O&M 07 Cross-Layer O&M Features 70

08 Key O&M Activities 74

5G Core
Deployment

Three-Layer Architecture

A three-layer network architecture is used for 5GC deployment — the central DC deployed with
control plane NFs, the regional DC with the user plane, and the edge DC with the MEC and CDN.
A fully convergent 5GC cannot be built overnight. In the early phase of deployment, we usually
build a new 5GC and enable it to communicate with the existing EPC, with new MMEs/AMFs
pooled with the existing MMEs, or just upgrading the existing MMEs.
In addition, active-active, active/standby, and pool-based redundancy is applied for 5GC NFs to
maintain the highest possible security and reliability.

Central Active Standby

New 5GC
Existing EPC
DC 1 DC 2
Active-active
NRF NRF
Active-active
NSSF NSSF
HSS
IWF/Hybrid networking Active/standby
IWF/UDM/HSS IWF/UDM/HSS
PCRF Hybrid networking Active/standby
PCF/PCRF PCF/PCRF
Active-active
S/P-GW S/P-GW SCP/BSF SCP/BSF
Pool
N26-based interworking AMF AMF
Pool
MME+ MME+ SMF/PGW-C SMF/PGW-C

Regional
Full Mesh
Full mesh Full mesh Full mesh
User
plane
UPF/PGW-U UPF/PGW-U UPF/PGW-U
UPF/PGW-U UPF/PGW-U UPF/PGW-U
The UPF and PGW-U are
co-located for smooth
4G-5G interworking.

Edge
Full mesh Full mesh Full mesh

MEC/CDN
CDN

UPF UPF mCDN MEC App

The user plane is moved to the
B2B B2C B2B2X
network edge, providing ultra-
Campus LBO Service acceleration Targeted advertising,
low latency services to users.
capability exposure

01
 Deployment

Typical NRF Deployment

The NRF is a new NF introduced in 5G which acts like the DNS in 4G. It helps in service discovery
among other 5G NFs. Operators can determine how to deploy NRFs according to network scale or
redundancy concerns:
 Network scale: Single-hierarchy deployment is used for small-sized operator networks, and
multi-hierarchy deployment for large- and medium-sized ones.
 Service reliability: NRFs are deployed as active-active or active/standby pairs across DCs. The
same service data is configured on the paired NRFs. Active-active deployment is recommended
over active/standby deployment if both are available.

Small- and medium-sized operator

Small-sized operator networks
networks (single-hierarchy deployment)
1. Each NRF is configured with information about all NRFs.
One NRF pair manages all NFs.
2. Automating deployment and maintenance is difficult. The
configurations on all NRFs may need to be adjusted due to
any change to a single NF.
NRF 2
NRF 2 NRF 4

NRF 1
NRF 1 NRF 3

AMF SMF UDM PCF NSSF AMF SMF UDM PCF NSSF AMF SMF UDM PCF NSSF

Medium- and large-sized operator networks Large-scale SA network for

(multi-hierarchy deployment) international roaming (available later)
1. Each L-NRF manages the NFs in its home area. This
approach is simple.
Other networks
2. The PLMN-NRF manages L-NRFs and H-NRFs on a three- NRF
hierarchy network, or manages only L-NRFs on a two-
hierarchy network.
SEPP
If the NRFs are arranged as two hierarchies, the PLMN-
NRF addresses the target NF during cross-area service
procedures and international roaming.
Local network SEPP
PLMN-NRF 2
PLMN-NRF 2
PLMN-NRF 1
PLMN-NRF 1

L-NRF 2 L-NRF 4 L-NRF 2 L-NRF 4

L-NRF 1 L-NRF 3 L-NRF 1 L-NRF 3

AMF SMF UDM PCF NSSF AMF SMF UDM PCF NSSF AMF SMF UDM PCF NSSF AMF SMF UDM PCF NSSF

 L-NRF: An NRF at the lowest level of hierarchy. It manages the NFs in its home area.
 PLMN-NRF: An NRF at the highest level of hierarchy. It can be deployed separately or co-
deployed with a group NRF to accommodate international roaming in the future. The group
NRF can be an H-NRF, L-NRF, or PLMN-NRF.
 SEPP: It is part of the roaming security architecture and used to safeguard control plane
signaling interaction between 5G PLMNs.

02
 Deployment

Typical NSSF Deployment

Network slicing is a cutting-edge technology put forward in 5G. It can abstract a physical network
into different logically isolated networks oriented to various industries. 5GC plays a vital role in
driving network slicing across access, transport, and core networks. The NSSF is an NF introduced
to the 5GC to manage and select network slices. Operators can deploy NSSFs differently
depending on two factors:
 Network scale: One NSSF pair is deployed for a small-sized operator network, and one NSSF pair
for each central area on a large- or medium-sized operator network.
 Service reliability: NSSFs are deployed as active-active (recommended) or active/standby pairs
across DCs. The same service data is configured on the paired NSSFs.

Small-sized operator networks

Central area

NSSF 1
NSSF 2

Area 1 Area 2

AMF set 1 AMF set 2 AMF set 3 AMF set 4

AMF AMF AMF AMF

AMF AMF AMF AMF AMF AMF AMF AMF

TAI list 1 TAI list 2

Large-sized operator networks

Central area 1 Central area 2

NSSF 1 NSSF 3
NSSF 2 NSSF 4

Area 1 Area 2 Area 3 Area 4

AMF set 1 AMF set 2 AMF set 3 AMF set 4 AMF set 5 AMF set 6 AMF set 7 AMF set 8
AMF AMF AMF AMF AMF AMF AMF AMF

AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF AMF

TAI list 1 TAI list 2 TAI list 3 TAI list 4

03
 Deployment

Typical Control Plane Deployment

A fully convergent 5G core network cannot be built overnight. In the initial construction phase, 5G
core networks will coexist with existing EPC networks.

5G interface 4G interface Legacy network New component

Solution 1: Build a 5GC and interwork it with the EPC, without deploying new MMEs.

N26 (recommended) Network Deployment

MME MME
 Deploy a cloud-based 5GC with pool-based
AMF AMF redundancy.
 Upgrade the existing MMEs to support the N26
interface and select convergent gateways,
maintaining service continuity.
SMF/GW-C
Highlight
SMF/GW-C

S-GW/P-GW The 5GC only connects to gNodeBs and will be

UPF/
gradually expanded as the 5G construction proceeds.
GW-U
UPF/
UPF/
GW-U
GW-U Weakness
 Increased network deployment costs from
upgrading existing MMEs
 Reduced user experience and interworking
EPC eNodeB gNodeB efficiency because of 4G and 5G interworking
New deployment across pools
5G UE

Solution 2: Build a 5GC and interwork it with the EPC, with new MMEs/AMFs pooled with the
existing MMEs.
.
Network Deployment
 Deploy a cloud-based 5GC with pool-based
MME MME MME/AMF MME/AMF
redundancy.
 Configure the new AMFs/MMEs and the existing
MMEs as a hybrid pool.

Highlight
SMF/
SMF/ GW-C Service requests from 5G UEs are anchored to the
GW-C convergent 4G/5G network, reducing interactions
across nodes and improving the service experience.
UPF/
S-GW/P-GW
GW-U
Weakness
UPF/  Service requests from the 4G-only UEs are also
GW-U
processed by the convergent 4G/5G network.
Consequently, existing MMEs are not used
efficiently.
eNodeB gNodeB  The existing MMEs must be upgraded to select
EPC
New deployment convergent gateways, increasing network
deployment costs.
Option 2
5G UE

04
 Deployment

Typical UDM Deployment

The UDM provides operators with convergent data management for 2G/3G/4G/5G networks. The
UDM processes subscriber data efficiently, and simplifies networks. It is compatible with existing
services and can also expand into new 5G services, maximizing operators' ROI and ensuring service
continuity during handovers.
The UDM allows existing networks to smoothly evolve to 5G. Cloud-based UDMs can be added to
form a hybrid network with existing ATCA-based HSSs. On this hybrid network, subscriber data is
smoothly migrated from the HSSs to the UDMs, while ensuring data completeness. There are three
evolution solutions which can currently be used:
 Full migration
UDMs are deployed, and subscriber data in existing Huawei or non-Huawei HSSs are batch
migrated to the UDMs. The UDMs provide 2G/3G/4G/5G services for subscribers. This solution
allows all subscriber data from previous generations to be simultaneously migrated to the 5G
network. However, it affects the existing network services, and requires massive upfront investment.
 Hybrid network
UDMs are added to form a hybrid network with existing HSSs in a ratio of 1:1 or 1:X, maximizing
operators' ROI. Operators can plan 2G/3G/4G to 5G upgrades, since the system can automatically
migrate new 5G subscribers or batch migrate existing ones by subscriber number segment.
 UTA
A UDM translation agent is ideal for early-stage 5GC. It improves user experience and quickly
promotes 5G services while maintaining stable 2G/3G/4G services. Newly deployed UTAs are
compatible with the third-party HLR/HSS to provide 5G services without migrating subscriber data
or changing subscribers' SIM/USIM cards or MSISDNs. In addition, they do not affect 4G services on
existing devices and maintain a highly reliable network.

Hybrid Network

Existing network Transitional network Target network

Provisioning system Provisioning system Provisioning system
Hybrid network

Final evolution

Hybrid
HSS-BE HSS-BE network UDR UDR

HSS-FE HSS-FE UDM UDM

DRA/STP DRA/STP AMF/SMF DRA/STP

HSS  UDM/HSS hybrid network  UDM

Full Migration UTA

Other operator Huawei target network Existing Existing network

network network The UTA obtains
2G/3G/4G + VoLTE

Provisioning Provisioning Provisioning Provisioning

batch subscriber

4G data from the

system system system system HSS and converts
migration

UTA it to 5G data to
HSS-BE HSS-BE HSS-BE HSS-BE
provide 5G services.
HSS-FE UTA
HSS-FE HSS-FE HSS-FE HSS-FE

DRA/STP DRA/STP AMF/SMF DRA/STP DRA/STP AMF/SMF

HSS  UDM (Subscriber migration for HSS  UTA (Transitional solution for
5G service provisioning) 5G service provisioning)

05
 Deployment

Typical PCF Deployment

The PCF is a new NF introduced in 5G and works similarly to the PCRF on a 4G network. Now with
enhanced capabilities, it can uniformly control policies across 2G, 3G, 4G, and 5G networks. The
cloud-based PCF can be used together with the existing ATCA-based PCRF, facilitating smooth
transformation of networks.
 Policy data can be smoothly migrated to, and service configurations are centrally managed by
the PCF.
 Subscribers can be migrated from 4G to 5G networks first. Then, we can gradually upgrade 4G
sites to 5G to achieve full 5G coverage.
 The provisioning system can be connected to the PCF, so that the PCF can uniformly deliver
service provisioning instructions.
 The EMS can be selected based on terminal capabilities. 4G and 5G signaling messages can be
processed based on terminal capabilities and network coverage.

Live 4G network
Provisioning system

Pool 1

SPR SPR

PCRF PCRF PCRF

DRA

P-CSCF PCEF

Target hybrid network

Provisioning system
5G 4G

UDR UDR SPR SPR

PCF PCF PCRF PCRF PCRF

HTTP Diameter Diameter

DRA
Diameter

SMF IMS Core PCEF

Redundancy service Redundancy data

Service provisioning Data access
provisioning access
Synchronization of Signaling access Synchronization of
global data global redundancy data

06
 Deployment

Typical SPS Deployment

In a 5G network without an SPS, inter-network communication is not secure, and is open to
attacks. In addition, the NRFs and other NFs must be fully meshed, which significantly increases
links, making their monitoring labor-intensive and error-prone.
The SPS offered by Huawei integrates the BSF, SCP, and SEPP functions to satisfy 5G signaling
network requirements.
 The BSF provides the session binding function to facilitate message routing from the IMS
network to the destination PCF on a 5G network.
 The SEPP secures inter-network interactions.
 The SCP serves as a delegated service discovery point and converges and routes 5G signaling.
A new SPS must be deployed to use these functions on your 5G network.

5G network without an SPS

Region A Region B

CHF
PCF UDM
UDM PCF
AUSF PCF
AUSF UDM
UDM CHF
PCF

NRF LNRF
NRF

SMF
AMF AMF
SMF AMF
SMF SMF
AMF

5G network with an SPS

HPLMN VPLMN
Region A Region B

PCF UDM AUSF AUSF UDM PCF

NRF SCP/BSF
LSCP LSCP
SCP/BSF LNRF
NRF SEPP SEPP

AMF SMF SMF AMF ...

07
 Deployment

Flexible User Plane Deployment

The 5GC user plane (UPFs) can be deployed in central, regional, or edge DCs, depending on service
latency and coverage requirements for different scenarios.
While being fully meshed with their serving SMFs through an IP transport network, the UPFs are
also pooled across DCs for redundancy, so that a faulty UPF does not affect the others. UPFs are
deployed depending on the following service types:
 B2C services
UPFs are deployed in regional DCs to shorten the RTT and improve service experience.
 B2B services
UPFs are deployed in edge or regional DCs to optimize traffic paths and reduce transmission
resource waste:
 Edge DC deployment: It is recommended for security- or latency-sensitive applications, such as
industrial control and AR/VR-based live broadcast.
 Regional DC deployment: It accommodates enterprise campus applications, where the UPFs
can be shared for Internet services or across campuses to improve resource utilization.

UPFs in a Central DC

 B2C services
AMF/SMF/NRF/SMSF/UDM/PCF/CHF/...
The UPFs provide access to the
Internet.

Central DC
UPFs in a Regional DC
Internet Internet
 B2C services
The UPFs transmit massive 5G data
UPF/GW-U
UPF/GW-U UPF/GW-U
UPF/GW-U with shorter latency to improve the
experience for Internet subscribers.
 B2B services
The UPFs allow enterprise
subscribers to access a local DN.
The UPFs can also be shared across
Regional DC campus networks to offload local
services for multiple enterprises.

Local Local UPFs in an Edge DC

Local
Internet campus 1 campus 2 campus
App  On-premises MEC deployment in
All-in-one B2B scenarios
UPF/GW-U Shared UPF
E9000H-based UPF The UPFs provide B2B (enterprises
or factories) or B2C (service
acceleration) services in specific
enterprise campuses.
 Third-party app integration
All-in-one E9000H-based UPFs are
Edge DC
integrated with content servers of
third-party apps and offload service
traffic to the apps.
 LBO
UL CL UPFs are not integrated with
App third-party apps. They only provide
All-in-one the LBO function to steer services to
UL CL UPF
E9000H-based UPF local servers.

08
Redundancy

Challenges
As 5G drives new services, such as IoT, V2X, and VR, it puts more pressure on networks. These
services demand networks that can process massive data and online services anytime, anywhere.
Furthermore, service continuity and resilience are becoming more important than ever with the
increasing use of mobile services by both enterprises and individuals. However, the cloud-based NFs
are not as robust as traditional NEs due to changes in the network architecture – COTS hardware
and a virtualization layer are introduced. As such, ensuring service availability on 5GC NFs is urgent
and more difficult than on traditional NEs.
The 5GC redundancy solution addresses these challenges by deploying NFs as active/standby pairs,
active-active pairs, or pools across DCs at different locations.

Redundancy Networking
5GC cross-DC redundancy networking encompasses both cloud-based NFs and traditional NEs,
including the NSSF, NRF, convergent PCF/PCRF, convergent AUSF/HLR/HSS/UDM, IWF, NCG, SMSF,
convergent SMF/PGW-C, AMF, and convergent UPF/PGW-U.
Control-plane NFs are deployed in the central area, and user-plane NFs are placed at different
distances to users, meeting bandwidth and latency requirements at different levels. For example,
the convergent UPF/PGW-U can be deployed in a regional DC for Internet access, and it can also
be positioned closer to users, such as at the network edge to facilitate access to campus networks.

Central Active Active or standby Standby

DC 1 Redundancy DC 2
Network Active-active or
management NSSF NRF active/standby
NSSF NRF
AUSF/HLR/ PCF/PCRF AUSF/HLR/
PCF/PCRF HSS/UDM HSS/UDM
Active-active or
FE FE active/standby FE FE
Data/policy Active/standby
BE BE BE BE

CDR/SMS
NCG SMSF Active-active NCG SMSF
forwarding

Service SMF/ SMF/

AMF Pool AMF
signaling PGW-C PGW-C

Regional

UPF/ UPF/ UPF/ UPF/

Pool
PGW-U PGW-U PGW-U PGW-U

Edge

Pool
gNodeB gNodeB UPF/ UPF/
PGW-U PGW-U
gNodeB

09
 Redundancy

Redundancy Approaches
The 5GC can apply active/standby, active-active, or pool-based redundancy.

Networking
Active/Standby
Two NFs are deployed in separate DCs as
DC 1 DC 2 an active/standby pair. As always, only the
active NF processes services, with the
standby NF available as a backup.
The two NFs exchange heartbeat
NF 1 NF 2 messages to check each other's status, and
(Active) (Standby) synchronize data to maintain consistency.
If the active NF is faulty, the standby NF
takes over services.
Typical NFs
NRF, NSSF, UDM, and UPCF

Networking
Active-Active
Two NFs are deployed in separate DCs as
DC 1 DC 2 an active-active pair. As always, both NFs
process services.
Some NFs back up data with their paired
NFs, while some do not. If one NF is faulty,
NF 1 NF 2 the other NF takes over services.
(Active) (Active)
Typical NFs
NRF, NCG, NSSF, SMSF, UDM, and UPCF
(the SMSF and NCG do not back up data
with their paired NF)

Networking
Pool
NFs are pooled. When operational, all NFs
DC 1 DC 2 process services.
If an NF is faulty, other NFs take over
services.
Typical NFs
NF 1 … NF 2 NF 3 … NF 4
(Active) (Active) (Active) (Active) AMF, SMF, and UPF

10
 Redundancy

Link Status Check

NFs periodically check the status of links to their peers. If a link is faulty, services will be switched
to other operational NFs. The 5GC uses two types of interfaces — SBIs and traditional point-to-
point interfaces — over which different communication protocols and link status check
mechanisms are used.
 HTTP is used over SBIs. The NFs check the status of links over SBIs via ping or subscription
notifications from the NRFs.
The NRFs exchange PATCH heartbeat messages with their served NFs to check their status. If
an NF is faulty, its NRF will set it to the SUSPENDED state and notify other NFs, which have
subscribed to the status of this NF. The other NFs determine whether to switch services to
operational NFs according to preset policies.
 The SCTP, PFCP, GTP-U, ICMP are applied over traditional interfaces. The NFs check their link
status through heartbeat messages over SCTP associations or PFCP links, with an echo
request, or via server polling on the IP farm.

SBIs

NSSF AUSF UDM NCG NRF

Ping
Nnssf Nausf Nudm Nchf Nnrf

PATCH
Ping Ping heartbeat
Subscription
Ping Ping Ping Ping Ping notification

AMF AMF SMSF SMF PCF AF

Ping Ping Ping Ping
Namf Namf Nsmsf Nsmf Npcf Naf

Ping
Ping

Traditional
Interfaces
PFCP
SCTP
heartbeat
Echo UPF

UE (R)AN Echo UPF IP farm DN

SBI-based connection Traditional interface-based Traditional interface-

on the control plane connection on the control based connection on
plane the user plane

11
 Redundancy

Pool-based AMF Redundancy

The AMFs are pooled to provide redundancy. The pooled AMFs are fully meshed with gNodeBs
and control-plane NFs, efficiently preventing single points of failure. If an AMF is faulty, its
connected NFs will switch services to other operational AMFs.

Control NRF UDM SMF …

plane

DC 1 DC 2

1
AMF 1 AMF n AMF Pool AMF 1a AMF na
… …

gNodeB 1 gNodeB 2 gNodeB 3

… …

Fault Point Scenario Peer NF/NE Redundancy Solution

After detecting the fault, the gNodeB routes signaling
messages to another operational AMF in the pool.
gNodeB
This newly selected AMF will provide services based
on the registration request from the UE.
The NRF exchanges PATCH heartbeat messages with
An AMF is the AMF to check the status of each other. After
NRF detecting the fault, the NRF notifies the control plane
faulty, or a
1 NFs, which have subscribed to the status of this AMF.
link to this
AMF is faulty. The SMF selects another operational AMF, but the
SMF newly selected AMF does not have user information.
The SMF then deletes the PDU session.
The UDM selects another operational AMF, but the
UDM newly selected AMF does not have user information.
The SMF then deletes the context.

12
 Redundancy

Pool-based SMF and UPF Redundancy

An SMF pool consists of multiple SMFs that serve one radio area and are fully meshed with all
subordinate UPFs. SMF and UPF full mesh networking is also called CU full mesh networking,
which ensures that other NFs remain operational if one SMF or UPF becomes faulty.

Central DC

Control UDM NRF AMF

plane …

1
SMF 1 SMF 2 SMF 3 SMF 3

2
UPF 1 UPF 2 UPF 3 UPF 4

Fault Point Scenario Peer NF/NE Redundancy Solution

When a UPF detects that the SMF is faulty
UPF using PFCP heartbeat detection, the UPF
deactivates the subscribers served by this SMF.
When the NRF detects that the SMF is faulty
An SMF is faulty,
1 using patch heartbeat detection, the NRF
or a link to this NRF
notifies the NFs, which have subscribed to
SMF is faulty.
this SMF.
The AMF deletes existing session resources,
AMF and addresses other functional SMFs to
create a session.
A UPF is faulty, When an SMF detects that the UPF is faulty
or the link using PFCP heartbeat detection, the SMF
2
between an SMF SMF deactivates the subscribers served by this UPF,
and this UPF is and selects another UPF to re-activate
faulty. subscribers.

13
 Redundancy

Active-Active NRF Redundancy

Two active NRFs are deployed across DCs for geographic redundancy. The two NRFs are presented
as two independent NFs with separate identifying information, such as different interface IP
addresses. This allows them to provide services for all other NFs or NFSs in their respective DCs
and to back up data for those in the peer DC. Service links are established between the other NFs,
namely the AMFs and SMFs, and the NRFs in two DCs. If one of the NRFs is faulty, these NFs
select the other NRF to process services, maintaining service continuity.

DC 1 DC 2

PCF 1 … … PCF 2

1 Data synchronization

NRF 1 2 NRF 2

3
4

AMF 1 SMF 1 … … SMF 2 AMF 2

Fault Peer
Scenario Redundancy Solution
Point NE/NF
The NFs in the same DC as the faulty NRF switch services to the
other NRF.
Control After the faulty NRF recovers, the other NRF backs up all data
1 An NRF is faulty.
plane NFs updates to the recovered NRF in one batch, to ensure that both
of them have the same up-to-date data. Data is synchronized
between the NRFs in real time in subsequent service procedures.
The NRFs process service requests from the NFs in their
The data respective DCs.
synchronization Control After the data synchronization path recovers, all data is
2 path between plane NFs synchronized between the NRFs in one batch to ensure that both
NRFs is faulty. of them have the same up-to-date data. Data is synchronized
between the NRFs in real time in subsequent service procedures.

The service The other NRF continues to process service requests from the
processing path NFs in the same DC as the faulty NRF.
3 between an NF NRF After the service processing path recovers, the NFs determine
and its NRF is whether to switch services back to the original NRF according to
faulty. preset policies.
The NRF sets this NF to the SUSPENDED state.
After the NF recovers, the NRF sets the NF to the REGISTERED
4 An NF is faulty. NRF state, and the NF then continues to provide services as normal.
The NRF notifies the other NFs, that have subscribed to the
status of this NF, of the status change.

14
 Redundancy

Active-Active NSSF Redundancy

Two active NSSFs are deployed across DCs for geographic redundancy. The two NSSFs are
presented as two independent NFs with separate identifying information, such as different
interface IP addresses. This allows them to provide services for all AMFs in their respective DCs
and to back up data for those in the peer DC. Service links are established between AMFs and the
NSSFs in two DCs. If one of the NSSFs, for example, the high-priority NSSF, is faulty, the AMFs
detect the fault, and select the other NSSF, for example, the low-priority NSSF, to process services,
maintaining service continuity.

DC 1 DC 2

Data
synchronization
1
NSSF 1 2 NSSF 2

AMF 1 … AMF n AMF 1a … AMF na

AMF pool

Fault Point Scenario Peer NE/NF Redundancy Solution

The other operational NSSF processes
An NSSF is service requests from the AMFs. When the
1 AMF
faulty. faulty NSSF recovers, the AMFs switch
services back to the recovered NSSF.
The NSSFs process service requests from
The data
the AMFs in their respective DCs. After the
synchronization
2 NSSF data synchronization path recovers, the
path between
two NSSFs synchronize data from the
NSSFs is faulty.
primary copies with each other.
The service
The other NSSF processes service requests
processing path
3 from AMFs. After the service processing
between an AMF path recovers, the AMFs switch services
AMF and its
back to the original NSSF periodically.
NSSF is faulty.

15
 Redundancy

Active-Active NCG Redundancy

Two active NCGs are deployed across DCs for geographic redundancy. Each NCG uses the NRF to
discover an OCS server, with the active OCS server as the preferable choice over the standby one.
The SMF preferentially selects a high-priority NCG based on locally configured NCG priorities.

DC 1 DC 2
1 2

NRF 1 OCS 1 NRF 2 OCS 2

3
NCG 1 NCG 2

SMF 1 SMF 2

Fault Peer
Scenario Redundancy Solution
Point NE/NF
The NCG uses the cached OCS data to select an OCS
server.
1 An NRF is
NCG If there is no cached OCS data on the NCG, the NCG
faulty.
cannot find the OCS server and considers the OCS server
as faulty.
An NCG determines that an OCS server is faulty when
receiving a notification message indicating a fault from
the NRF, the OCS server response expires, or it receives
the error code 408, 429, 500, or 503 from the OCS
An OCS server.
2 server is NCG  When one of the OCS servers is faulty, the NCG
faulty.
sends charging requests to the standby OCS server.
 When both OCS servers are faulty, the NCG responds
to the SMF on behalf of the OCS server, and
generates an exception CDR.
The SMF detects an NCG fault through HTTP pings.
 When one of the NCGs is faulty, the SMF sends
3 An NCG is charging messages to the standby NCG.
SMF
faulty.  When both NCGs are faulty, the SMF caches
charging messages and resends the cached messages
to the NCGs once they recover.

16
 Redundancy

Active-Active SMSF Redundancy

Two active SMSFs are deployed across DCs for geographic redundancy. The two SMSFs back each
other up to provide redundancy. When the AMF or STP detects that one SMSF is faulty, it routes
service requests to the other SMSF.

IP-SM
SMSC
-GW

DC 1 DC 2

STP 1 STP 2

UDM 1 UDM 2

Data
1 synchronization
SMSF 1 NRF 1 NRF 2 SMSF 2

AMF 1 AMF 2

Fault Point Scenario Peer NF/NE Redundancy Solution

The STP checks whether the link to an
SMSF is available through heartbeat
detection at the SCTP layer. If the link is
STP
faulty, the STP switches to another link.
If all links to the SMSF are faulty, the
STP switches to the other SMSF.
1
An SMSF is
faulty. The AMF pings the SMSF for its status
or subscribes to the SMSF status
through the NRF. When detecting that
AMF one SMSF is faulty, the AMF steers
service requests to the other SMSF. The
other SMSF cannot take over services
until it re-registers with the UDM.

17
 Redundancy

Active/Standby PCF/PCRF Redundancy

A UPCF can serve as a convergent PCF/PCRF. Logically, a UPCF consists of an FE and a BE. The FE
processes services, and the BE stores and manages data. It is recommended that FEs and BEs both
work as active/standby pairs.
If the active FE is faulty, the standby FE is selected to process new services. If the active BE is faulty,
the FE accesses the standby BE. Data is synchronized between the active and standby BEs.

Provisioning
system

Data
1 synchronization
BE 1 BE 2

DC 1 DC 2

2
FE 1 FE 2

DRA NRF SMF AMF

Fault Point Scenario Peer NE/NF Redundancy Solution

After detecting that a BE is faulty through
1 A BE is faulty. FE SCTP/TCP, the FE sends data service
messages to the other BE.

• After detecting that an FE is faulty

through SCTP/TCP, the DRA sends
DRA, NRF, messages to the other FE.
2 An FE is faulty. SMF, and • After detecting that an FE is faulty, the
AMF NRF sends the fault information to the
AMF and SMF, which then send
messages to the other FE.

A DRA, NRF, After detecting that the DRA, NRF, SMF, or

3 SMF, or AMF FE AMF is faulty, the FE sends messages to an
is faulty. available DRA, NRF, SMF, or AMF.

18
 Redundancy

Active/Standby AUSF/HLR/HSS/UDM Redundancy

A UDM can serve as the AUSF, UDM, HSS, and HLR. Logically, a UDM consists of an FE and a BE.
The FE processes services, and the BE stores and manages data. It is recommended that FEs and
BEs both work as active/standby pairs.
The active and standby FEs send registration requests to the NRF. The requests carry the SUPI
segment, GPSI segment, and group ID (optional).
Normally, the SMF and AMF discover and access the active FE through the NRF. However, if the
active FE is faulty, the SMF and AMF access the standby FE.
The FE accesses the BE over an internal interface. In most cases, the FE accesses the active BE. If
the active BE is faulty, however, the standby BE takes over data services.
 If the standby BE is configured to work as an active BE, it processes all provisioning commands.
 If the standby BE is not configured to do so, it processes only modification and query related
provisioning commands.

Provisioning
system

Data
1 synchronization
BE 1 BE 2

DC 1 DC 2

2
FE 1 FE 2

STP DRA NRF SMF AMF

Fault Point Scenario Peer NE/NF Redundancy Solution

Provisioning The other BE is manually switched to the active
1 A BE is faulty.
system state. The provisioning system then accesses this BE.

 After detecting that an FE is faulty, the STP and

STP, DRA, DRA send messages to the other FE.
2 An FE is faulty. NRF, SMF,  The NRF sends the FE fault information to the
and AMF AMF and SMF, which then send messages to
the other FE.

An STP, DRA, After detecting that the STP, DRA, NRF, SMF, or
3 NRF, SMF, or FE AMF is faulty, the FE sends messages to an
AMF is faulty. available STP, DRA, NRF, SMF, or AMF.

19
4G-5G Interworking

Overview

5G networks are gradually built from hotspots to an increasing number of areas. At the initial
stage of 5G network construction, 4G-5G interworking must be supported by both networks and
UEs. This way, when 5G subscribers move to a new area not covered by 5G, they can have
continued access to mobile services.

Limited 5G Coverage at the Initial Stage of 5G Buildout

P-GW
MME pool SMF AMF pool

MME MME AMF

S10 N26

LTE coverage LTE coverage

eNodeB gNodeB
eNodeB eNodeB

UE
UE
UE

4G and 5G networks may need to co-exist for a long time and work together, through inter-RAT
interoperability, to provide a seamless network experience for both existing and new subscribers.
For example, 4G networks feature wide coverage and are still used to carry voice services to
ensure that these services are stable and reliable; 5G networks feature abundant radio resources,
such as high frequency bands, and are used to carry data services to provide high data rates and
large capacity in hotspots. Therefore, 4G-5G interworking is necessary, and even mandatory for
some countries or operators.

4G-5G interworking allows a UE to move between a 5G SA system and 4G EPS. It involves cell
reselection, handover, and redirection on the (R)AN, as well as TAU, handover, and mobility
registration updates on the core network.

20
 4G-5G Interworking

Networking

Typical Networking

At the early stage of 5G network deployment, some legacy EPC devices are repurposed through
upgrades or reconstruction to handle the procedures and signaling messages of 4G-5G
interworking.

EMS BOSS DNS DRA

IMS
EPC 5GC

UDM+HSS
S6a
N8
NRF
PCF+PCRF
Gx N7

S5-C
SMF+PGW-C

SGW N4
N11
S5-U UPF+GW-U
S11

N3
S1-U MME AMF
N26

S1-C N2

eNodeB gNodeB
Xn
LTE area SA area

NE Interworking Requirement
The eNodeB must be upgraded to support 5G neighboring cells/frequencies, handovers to 5G NR, and
eNodeB
EPS fallback.

The MME must be upgraded to support the N26 interface and the selection of a convergent SMF/PGW-C
MME
over the N26 interface.

DRA The DRA server must be upgraded to support the HTTP links destined to an SMF.

IMS The IMS must be upgraded to interwork with the 5GC, and to support 5G-initiated calls and EPS fallback.

The SMF and PGW-C must be integrated to keep the mobility anchor unchanged and to ensure service
SMF+PGW-C
continuity.

The PCF and PCRF must be integrated to centrally manage 4G and 5G subscriber policies, ensuring that
PCF+PCRF
policies are consistent and services run steadily.

The UDM and HSS must be integrated so that the UDM allows 5G subscribers to register with 4G
UDM+HSS
networks, ensuring that subscriber data is consistent.

NRF The convergent SMF/PGW-C must send the PGW-C FQDN when registering with the NRF.

The DNS server must be configured with records relevant to 4G-5G interworking.
 For 4G-to-5G handover, the MME uses a 5G TAI to query the DNS server for the target AMF.
 For 5G-to-4G TAU, the MME uses a GUAMI to query the DNS server for the original AMF.
page
DNS 02  For 5G-to-4G handover, the AMF uses a 4G TAI to query the DNS server for the target MME.
 For 4G-to-5G registration, the AMF uses a 4G GUMMEI to query the DNS server for the source MME.
 The MME uses an APN to query the DNS server for the SMF FQDN over the S5 interface, with
Service Parameter set to x-3gpp-pgw:x-s5-gtp+nc-smf.

21
 4G-5G Interworking

Networking Diagram

5GS-to-EPS Reselection

DNS NRF

9 Updates the TEID.

SMF+
Uses the GUMMEI SGW-C
6 PGW-C
to query for the peer AMF
Queries the NRF
3 Requests the SMF 2
for a convergent SMF/PGW-C.
8 Establishes a PDN to establish a
connection. PDU session.

7 Obtains UE MM and SM contexts.

MME MME AMF

5 TAU request (5G-GUTI)

Requests PDU session
5 1
establishment.

eNodeB gNodeB

eNodeB eNodeB Moves from NG-RAN

eNodeB
4
coverage to LTE coverage.
UE UE

Key steps:
1. A UE registers with a 5G network, and sends a message to the AMF to request a PDU session.
2. If the UE supports 4G network access and its subscription data (DNN and NSSAI) indicates
that the UE supports 4G-5G interworking, the AMF queries the NRF for a convergent
SMF/PGW-C.
3. The AMF sends a PDU session establishment request to the SMF, indicating that the DNN
supports 4G-5G interworking. The SMF requires the AMF to allocate a 4G EPS bearer ID to the
PDU session. The SMF then constructs an N1 SM message containing 4G and 5G QoS mapping,
and sends the message to the UE through the AMF.
4. When the UE in idle mode moves from NG-RAN coverage to LTE coverage, it initiates a TAU.
5. The TAU request message carries the 4G-GUTI mapped from the 5G-GUTI and access-layer
signaling also contains the GUMMEI mapped from the 5G-GUTI.
6. The MME uses the GUMMEI to query the DNS server for the original AMF following the
procedure on a 4G network.
7. The MME obtains UE contexts from the AMF, including MM contexts for mobility
management and SM contexts for session management. When the AMF obtains SM contexts
from the SMF, the SMF allocates PGW-C and PGW-U tunnel information to an EPS bearer.
8. The MME then preferentially selects a convergent SGW-C/PGW-C according to the PGW-C
information in SM contexts, and sends a 4G session establishment request message to the
selected SGW-C.
9. The SGW-C selects an SGW-U, and sends their F-TEIDs over the S5/S8-C and S5/S8-U
interfaces to the convergent SMF/PGW-C. The convergent SMF/PGW-C then switches the data
tunnel to the SGW-U.

22
 4G-5G Interworking

Gateway Selection During Network Access

Convergent Gateway for 5G UEs Accessing a Network from Anywhere

To ensure service continuity, the PGW-C and SMF on the control plane are integrated to allow a
convergent SMF/PGW-C to always be selected for processing 4G and 5G sessions. This can be done
because the PGW-C FQDN is carried when the convergent SMF/PGW-C registers with the NRF, and
convergent SMF/PGW-C information is also configured on the DNS server.
If convergent SMF/PGW-C information is unavailable on the DNS server, a UE will fail to be
handed over from a 4G network to a 5G network. This handover fails because the UE sends the
UGW9811/CloudUGW host name of the live network during a 4G-to-5G handover, and the AMF
cannot use this host name to locate and select an SMF from the NRF.

UDM+HSS
S6a
N8
PCRF
PCF+PCRF

N7

P-GW NSA P-GW SMF+PGW-C NRF

S5-C

S-GW NSA S-GW N4

N11 Nnrf
S11
UPF+PGW-U
S11

S1-U
N3
MME AMF
N26

S1-C N2

eNodeB gNodeB
Xn

NSA area SA area

5G UE registered 5G UE registered
on 5G on 5G

UE Type Access Area Gateway Is Interworking Supported

Depending on:
• UE capabilities (S1 MODE support)
5G UE registered on • Subscription data (whether the
SA area SMF+PGW-C
a 5G network selected DNN supports 4G-5G
interworking, as indicated by
Interworking with EPS)
Depending on:
• UE capabilities (N1 MODE support)
5G UE registered on • Subscription data (whether the
NSA area SMF+PGW-C
a 5G network selected DNN supports 4G-5G
interworking, as indicated by
Interworking with EPS)
4G UE registered on Convergent SMF/PGW-C
NSA area No
a 5G network or 4G gateway

23
 4G-5G Interworking

Gateway Selection During Network Access

Convergent Gateway Selection and Information Transfer

A convergent SMF/PGW-C ensures that the MME or AMF always discovers and selects the
specified gateway during 4G-5G handovers. To achieve this, the convergent SMF/PGW-C carries
the PGW-C FQDN when registering with the NRF and its information is also configured on the
DNS server. On this server, the value of Service Parameter contains the "nc-smf" flag, such as "x-
3gpp-pgw:x-s5-gtp+nc-smf".

Convergent SMF/PGW-C Discovery by the NRF/DNS Server

DNS server NRF

DNS procedure A UE accesses the

4G network, and The AMF queries
Registration procedure the MME queries for the SMF
the DNS server for 2 based on the
Service procedure a convergent PGW-C FQDN.
1 SMF/PGW-C.

MME PGW-C SMF AMF

2
Context transfer The UE is handed over to a 5G
network, and the MME transfers the
PGW-C FQDN of the convergent
SMF/PGW-C to the AMF.

How is a convergent SMF/PGW-C discovered when a 5G UE that previously accessed from a 4G

network moves to a 5G network:
 During an initial attach to the LTE network, the MME obtains the PGW-C FQDN from the DNS
server, identifies the convergent SMF/PGW-C based on the "nc-smf" flag, and establishes a
PDN connection to the convergent SMF/PGW-C for the 5G UE.
 When the 5G UE is handed over or reselected to a 5G network, the MME sends the PGW-C
FQDN to the AMF.
 The AMF uses the PGW-C FQDN to query the NRF for the convergent SMF/PGW-C and then
hands over the UE bearer to the 5G network.

How is a convergent SMF/PGW-C discovered when a 5G UE that previously registered with a 5G

network moves to a 4G network:
 The AMF queries the NRF for an available SMF.
 When the UE is handed over or reselected to a 4G network, the AMF sends the S5 interface
address of the PGW-C to the MME.
 The MME queries the DNS server for the PGW-C FQDN to obtain PGW-C topology information,
and selects the SGW-C closest to the PGW-C.

24
 4G-5G Interworking

Equivalent 4G/5G NE/NF Selection

MME and AMF Discovery and Selection

4G-5G Interworking Solution Overview
4G-5G interworking requires the MME and AMF to address each other. The source end needs to
send UE static contexts, containing MM contexts (including security contexts) and SM contexts, to
the peer end. MM contexts provide UE network capabilities, and authentication, security, and
location information. SM contexts provide tunnel information about existing sessions and tunnels.

MME Discovery by the AMF Through the DNS Server

The AMF obtains the address of the

MME from the DNS server.
DNS server
Service scenarios:
(1) 5G-to-4G handover: The AMF uses
Service procedure
the 4G TAI (TAI FQDN) to query the
TAI/GUMMEI- DNS server for the MME that serves
DNS procedure based query the radio coverage area (4G TAI).
(2) 4G-to-5G registration: The AMF
AMF MME uses the 4G GUMMEI (MMEC
Context transfer FQDN) to query the DNS server for
the original MME.
The AMF interacts
with the DNS server
to select an MME.

AMF Discovery Through MME and DNS Server Interaction

The MME interacts with the DNS server

DNS records
to select the target AMF. When an
relevant to the AMF
must be configured AMF is added to the 5GC, a 5G
on the DNS server. GUAMI/TAI record must be added to
the DNS server.
DNS server NRF
Service scenarios:
DNS procedure
(1) 5G-to-4G TAU: The MME
Registration SBI-based constructs a mapped GUMMEI
procedure TAI/GUMMEI
-based query AMF (MMEC FQDN), and queries the
Service registration
procedure DNS server for the original AMF
following the procedure on a 4G
network.
MME AMF
(2) 4G-to-5G handover: The MME
Context transfer
queries the DNS server for an
available AMF based on the 6-
byte 5G TAI (TAC-LB.XX.TAC-
MB.XX.TAC-HB.XX).

25
 4G-5G Interworking

4G and 5G QoS Mapping

4G and 5G networks use different formats and parameters to represent QoS levels. To provide a
seamless experience for subscribers moving between 4G and 5G networks, it is important to
provide them with consistent QoS levels. For this to happen, the convergent SMF/PGW-C must be
able to correctly map between 4G and 5G QoS levels. QoS levels are mapped either during 5G
PDU session establishment or 4G EPS bearer establishment.

5G QoS 4G QoS 4G and 5G QoS Mapping on the Convergent

Parameter Parameter SMF/PGW-C
 One standard 5QI is mapped to one EPS QCI.
5QI QCI  Non-standard 5QIs are mapped to EPS QCIs based on
SMF configurations.
ARP ARP One-to-one mapping
Priority Level N/A This parameter can be ignored on 4G networks.
 If one QoS flow is mapped to one EPS bearer, one GFBR
is also mapped to one GBR.

GFBR GBR
 If multiple QoS flows are mapped to one EPS bearer,
the GFBR is mapped to the GBR based on SMF
configurations. For example, the GBR is equal to the
highest GFBR in QoS flows.
 If one QoS flow is mapped to one EPS bearer, one GFBR
is also mapped to one GBR.

MFBR MBR
 If multiple QoS flows are mapped to one EPS bearer,
the GFBR is mapped to the GBR based on SMF
configurations. For example, the GBR is equal to the
highest MFBR in QoS flows.
Session AMBR APN AMBR One-to-one mapping
UE AMBR UE AMBR One-to-one mapping
This parameter defines the time window for calculating the
Average Window N/A GFBR/MFBR. It is used only for GBR QoS flows and can be
ignored on 4G networks.

This parameter defines the maximum length of data

packets that can be transmitted over the air interface
within the latency budget, and is, therefore, used to control
Maximum Data network admission. It is suitable for URLLC services (GBR
N/A
Burst Volume QoS flows of the delay-critical type). 5G slicing is typically
used to ensure the experience for services requiring ultra-
low latency. This parameter can be ignored on 4G networks
as this type of service is rarely performed on 4G networks.

Reflective QoS This parameter is not required on 4G networks and can be

N/A
Attribute ignored during QoS mapping.
This parameter is not required on 4G networks and can be
Notification control N/A
ignored during QoS mapping.
Maximum
Maximum Packet This parameter is suitable only for voice services and can
Packet Loss
Loss Rate be ignored during QoS mapping for 4G data services.
Rate

26
Subscriber Migration &
Service Provisioning

Background and Challenges

When existing networks evolve to 5G, the UDM needs to integrate and manage 2G/3G/4G/5G
subscriber data, while ensuring services. A smooth evolution of existing networks optimizes
operator investment. That's why the UDM provides several 5G evolution solutions. From these,
operators can select the one that is most suitable for their existing services.

Evolution Solutions

Solution Scenario Provisioning Constraints Advantages Disadvantages

Full migration:
All existing Severe impact on
Use the migration The provisioning
A quick increase subscribers can be existing network
tool to batch system only
in the 5G None simultaneously services, and
migrate subscriber connects to the
subscriber base migrated to the 5G massive upfront
data from existing UDR.
network. investment
HSSs to UDMs.

The provisioning
system only needs
Existing HSSs Only slightly affects 2G/3G/4G
to connect and
Hybrid network: must be existing network subscriber data on
deliver the service
Add UDMs to form deployed by services and user existing HSSs
provisioning
a hybrid network Huawei and experience, while needs to be
command to the
with existing HSSs. upgraded to optimizing operator gradually migrated
home UDR based on
HSS 19.1. investment. to UDMs.
the subscriber
number segment.

UTAs can also

interwork with HSSs
UTA: Add UTAs to
Provide 5G deployed by other
interwork with 2G/3G/4G
services in certain vendors and require
existing HSSs, The provisioning Existing HSSs subscriber data on
areas without little upfront
convert subscriber system only must support existing HSSs
affecting 4G investment. They do
data to 5G data, connects to an 4G-5G needs to be
network services. not affect 4G services
and provide 5G existing HSS. interworking. gradually migrated
on existing devices,
services for to UDMs.
so the network
subscribers.
remains highly
reliable.

This solution is
HSS proxy: Add 2G/3G/4G
Requirements similar to the hybrid
UDMs to exchange The provisioning subscriber data on
on the network solution.
signaling with system connects to existing HSSs
provisioning However, it is also
existing HSSs and both the HSS and needs to be
system are suitable for HSSs
provide 5G services UDM. gradually migrated
higher. deployed by other
for subscribers. to UDMs.
vendors.

27
 Subscriber Migration & Service Provisioning

Full Migration
Full migration is suitable in areas where 5G UEs have a high penetration rate and the 5G
subscriber base needs to grow quickly. UDMs provide 5G services for subscribers, as well as
integrate and manage 2G/3G/4G/5G subscriber data. All subscriber data on existing HSSs is
exported and converted, and then imported to UDMs.

Provisioning Provisioning Existing

System System devices
Convergent
devices
HSS-BE UDR Peripheral
2G/3G/4G
devices
+VoLTE
subscriber batch
HSS-FE migration UDM

DRA/STP DRA/STP AMF/SMF

This solution migrates subscriber data in batches to quickly provision 5G services for subscribers,
allowing existing networks to directly evolve to 5G SA. However, operators need to invest heavily
to build 5G networks for all their subscribers. Also, provisioning services must halt during migration,
and the switch from an HSS to a UDM severely impacts existing network services.

That said, full migration helps to quickly expand the number of 5G subscribers by integrally
managing subscriber data, which allows the UDM to provision both 5G and 2G/3G/4G/IMS services
to subscribers. In addition, subscribers do not need to change their SIM/USIM cards or MSISDNs to
access 5G services.

Hybrid Network
A hybrid network allows for a seamless transition from ATCA-based sites to UDM sites. ATCA-
based sites form a hybrid network with UDM sites, which is then gradually reconstructed into a 5G
network. This solution reduces impacts on the existing network and optimizes operator investment.

Transitional Existing
Target network
Existing network devices
network
Convergent
devices
Provisioning Provisioning Provisioning
System System Peripheral System
devices

Provisioning
command
forwarding
HSS-BE HSS-BE UDR UDR

Hybrid network

HSS-FE HSS-FE UDM UDM

Signaling data
forwarding

DRA/STP DRA/STP AMF/SMF DRA/STP

28
 Subscriber Migration & Service Provisioning

In this case, cloud-based UDM devices form a hybrid network with existing ATCA-based devices,
facilitating a smooth evolution to 5G. Operators enjoy the following advantages:
 The provisioning system only connects to a UDM. Remote provisioning sites are deployed to
obtain routing data according to subscriber numbers and forward it to the relevant BE for
processing.
 Signaling on a hybrid network can be forwarded between FEs. If subscriber data is available in
the local partition, the FE processes signaling requests locally. Otherwise, the FE forwards
requests to another partition's FE, ensuring service continuity.
 Operators can plan 2G/3G/4G to 5G upgrades, since the system can automatically migrate new
5G subscribers or batch migrate existing ones by subscriber number segment.

Subscriber data can be migrated using:

 MML commands delivered to the HSS BE to migrate subscriber data to the UDR by subscriber
number segment.
 MML commands delivered to the UDR to provision 5G services for subscribers, which triggers
an automated subscriber migration from the HSS BE to the UDR — a key advantage of Huawei
UDM.

Typical Service Provisioning on a Hybrid Network

New 5G subscribers
Provisioning
System 1

5G for existing 4G subscribers HSS-BE UDR 2 5G for existing 5G subscribers

Provisioning Provisioning
System 1 System 1
HSS-FE UDM
2
HSS-BE UDR 3 1. The provisioning system delivers the HSS-BE UDR 2
subscriber definition command to the
4 home UDR based on the subscriber
number segment.
HSS-FE UDM HSS-FE UDM
2. The UDR defines 5G subscribers locally.
1. The provisioning system delivers the 5G
1. The provisioning system delivers the 5G service parameters to the home UDR
service parameters to the home UDR based on the subscriber number
based on the subscriber number segment. segment.
2. Subscriber attributes and data are Typical Service 2. The UDR provisions 5G services locally.
migrated from the home BE to the UDR.
Provisioning
3. The UDR provisions 5G services locally.
Procedures
4. The BE deletes subscriber data.

New 4G subscribers 4G for existing 4G subscribers

Provisioning Provisioning
System 1 System 1
3 2 3 2
HSS-BE UDR HSS-BE UDR

HSS-FE UDM HSS-FE UDM

1. The provisioning system delivers the subscriber 1. The provisioning system delivers the 4G service
definition command to the home UDR based on parameters to the home UDR based on the
the subscriber number segment. subscriber number segment.
2. The UDR forwards the provisioning command 2. The UDR forwards the provisioning command to
to the BE. the BE.
3. The BE defines 4G subscribers. 3. The BE provisions 4G services.

29
 Subscriber Migration & Service Provisioning

UTA
The UTA is ideal for early-stage 5GC. This solution improves user experience and quickly promotes
5G services while maintaining stable 2G/3G/4G services.

Provisioning Obtains 4G data and

AMF
System converts it to 5G data to
provision 5G services.

VLR/ 2G/3G
SGSN
HSS UTA SMF
4G
MME

Existing
IMS devices
CSCF/AS Convergent NRF
devices
Peripheral
2G/3G/4G/IMS network 5GC network
devices

UTAs help operators seamlessly evolve to 5G. Compared with the hybrid network solution, UTAs:
 Are compatible with the third-party HLR/HSS to provision 5G services without migrating
subscriber data or changing their SIM/USIM cards or MSISDNs.
 Require few resources during initial small-scale deployment. UDMs can be added as the 5G
subscriber base increases.
 Do not affect 4G services on existing devices and maintain a highly reliable network.

To connect 4G and 5G networks, a UTA:

 Functions as a UDM/AUSF on a 5GC network to interwork with the AMF/SMF/NRF, and
provides UDM/AUSF interfaces and services.
 Simulates the SGSN and MME on a 2G/3G/4G network to interwork with the HLR/HSS, GMLC,
and SCP AS over the signaling network, and obtains 3G authentication vectors and 4G
subscription data.
 Simulates the I-CSCF on an IMS network to interwork with the HLR/HSS over the signaling
network, and checks VoLTE subscriptions.

UTA Evolution Policies

UTAs interwork with the existing HLR/HSS to convert authentication and subscription data. They
then provide the 5G authentication and subscription data (still stored on the HSS/HLR) for
subscriber access to the 5G network.
UTAs are a temporary solution, which operators eventually need to replace with UDMs.

HSS/HLR HSS/HLR
(reconstructed) (removed)
All subscribers Migration-

+ +
based
5GC evolution UDM/UDR

UTA UTA All subscribers

1. Deploy a UTA. 1. Deploy the UDM/UDR to replace the existing

2. Reconstruct existing devices to interwork with HSS/HLR.
the UTA. 2. Migrate 2G/3G/4G subscribers to the UDM. Identify 5G
UEs and batch provision 5G services for them.

30
 Subscriber Migration & Service Provisioning

Subscriber Data Conversion on UTA

UTAs obtain 4G subscription data from the convergent HLR/HSS over the S6a interface, and
convert it to 5G subscription data according to the locally saved template. There are two types of
subscription data:
 Shared 4G/5G data
 Basic 5G data

HSS Proxy
This solution is similar to the hybrid network solution. The two main differences are:
 The provisioning system needs to interwork with both the HSS and UDM.
 The HSS needs to forward signaling data.

Existing
HSS proxy devices
Convergent
devices

Provisioning System Peripheral

devices

Subscribers 5G subscribers

HSS-BE UDR

HSS-FE UDM

DRA SCP AMF

This solution needs the provisioning system to:

 Connect to both the HSS and UDM.
 Interwork with the UDM according to the new provisioning interface protocol.
 Distribute 5G subscriber data and 2G/3G/4G subscriber data to different NEs/NFs.
 Convert 4G to 5G subscription data: Define subscribers, reissue cards, and provision 4G and
5G services on the UDR, as well as delete subscribers from the HSS BE.
 Modify/query for 5G subscriber services: Send relevant requests to the UDR.
 Modify/query for 4G subscriber services: Send relevant requests to the HSS BE.
 Withdraw 5G services: Send relevant requests to the UDR, which withdraws 5G services
from subscribers.
 Define subscribers on the HSS BE or UDR depending on the subscriber number segment
configured on the provisioning system.

31
Charging

Charging Architecture and Challenges

4G charging system CCS

Billing domain Billing domain

Bx Bx
Bx
OCS CCS
ABMF RF CGF
ABMF RF

OCF CHF
Offline charging system

CGF
Ga
CDF SBI

Gy Diameter interface Rf Nchf

4G NEs 5G NFs

3GPP Release 15 Charging, Challenges Facing CCS

3GPP Release 15 Charging

 The 5G CCS replaces the 4G OCS, and its separate offline charging system.
 The Nchf interface replaces the previous Ga and Gy interfaces.
Challenges Facing CCS
 There is no evolution path from the 4G charging system to the CCS defined in protocols.
Moving 4G charging over to the CCS is complex.
 Traditionally, the CG was deployed on the local core network whereas only the CHF is
deployed and connected to the 5G billing domain, reducing charging reliability.

32
 Charging

Charging Network

Network Architecture

NSSF NEF NRF PCF UDM AF

Nnssf Nnef Nnrf Npcf Nudm Naf

Nausf Namf Nsmf Nchf

AUSF AMF SMF CHF

N1 N2 N4

N3 N6
UE (R)AN UPF DN

Related NFs Function

SMF  Processes charging parameters delivered by the CHF, and

collects and reports quota usage when a charging event occurs.
 Monitors the quotas of online charging services.
 Delivers quotas and charging parameters as well as reports the
quota usage to the UPF over the N4 interface.
CHF  Performs rating, deducts account balance, and delivers quota
and charging parameters for online charging.
 Delivers charging parameters for offline charging.
 Processes the quota usage reported by the SMF and generates
CHF-CDRs.
PCF Delivers charging policies for the SMF.

UPF Measures subscriber quota usage based on the charging

parameters and quotas delivered by the SMF and reports the
quota usage to the SMF when trigger conditions are met.
UDM Carries the CC in the subscription data sent to the SMF.

NRF Supports the registration, update, and deregistration of each NF,

and enables the SMF to discover a CHF.

33
 Charging

Huawei 5GC Charging Solution

The CG in the 4G charging system is no longer part of the 3GPP-compliant 5GC charging system
(solution 1). The CHF implements charging instead, and is connected to the billing domain. This
results in insufficient charging data and affects reliability on the core network.
To solve these issues, Huawei introduces the NCG (solutions 2 and 3) on the core network. The
NCG uses the standard Nchf interface and processes CDRs.

Solution 1: 5G CCS is connected to the billing domain.

NRF
Nnrf Nnrf CCS
Convergent SMF/
PGW-C
ABMF
Bx
CTF Nchf CHF CHF-CDR Billing
(CDF+OCF) CGF domain
(Online and offline charging)

RF

Solution 2: The NCG is deployed, and 5G CCS is connected to the billing domain.

NRF CCS
Nnrf Nnrf
Convergent SMF/ ABMF
PGW-C NCG Bx
Nchf Nchf CHF CHF-CDR Billing
CTF AGF CGF
(Online and offline (CDF+OCF) domain
charging)
RF Bx
CDF CGF
CHF-CDR

Solution 3: The NCG is deployed, and 5G OCS is connected to the billing domain.
NRF OCS
Nnrf
Convergent SMF/ ABMF
PGW-C NCG
Nchf (Online charging) Nchf Bx Billing
CTF AGF OCF domain
(Offline charging)
RF Bx
CDF CGF
CHF-CDR

Charging
Description Difference
Solution
• The CDF and CGF need to be moved into the CCS. It
• This is a standard 5G SA charging solution. The CCS
will take a long time to reconstruct.
Solution 1 performs charging and is connected to the billing domain.
• No charging NF is deployed on the core network,
• No CDRs are generated on the core network.
reducing network reliability.
• The CDF and CGF need to be moved into the CCS. It
• The NCG and CCS work together for charging. The CCS
will take a long time to reconstruct, but can be done in
performs converged charging.
batches. The NCG is deployed for offline charging first
Solution 2 • The NCG stores all CDRs.
to roll out 5G services quickly.
• If the CHF is faulty, the NCG responses to the requests from • The NCG is deployed on the core network, improving
the SMF and generates abnormal online CDRs.
charging reliability.
• The NCG and OCS work together for charging. The NCG
• The OCS only needs to support the Nchf interface,
performs offline charging and OCS online charging.
reducing the reconstruction workload by 40%.
Solution 3 • The NCG stores all CDRs.
• The NCG is deployed on the core network, improving
• If the OCS is faulty, the NCG responses to the requests from
charging reliability.
the SMF and generates abnormal online CDRs.

34
 Charging

Converged Charging — Charging Scope and Types

Converged charging is used for a PDU session or a service. Both online charging with quota
management and offline charging without quota management can be provided.

Charging Scope Description

PDU session All services of a PDU session use the same RG.

Service flow-level charging, or CBC, is a type of service-based charging.

Service flow
Different services use different RGs.

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

Charging Type Description

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

Different charging types and scopes can coexist.

All services (online or offline

charging, RG 1) UE 1: PDU session-level
PDU session 1 charging for all services
using the same RG

Video (online charging, RG 1)

UE 2: service-level online
Web (online charging, RG 2) PDU session 2
charging for all services

Video (offline charging, RG 1)

UE 3: service-level offline
Web (offline charging, RG 2) PDU session 3
charging for all services

Video (online charging, RG 1)

UE 4: service-level online
Web (offline charging, RG 2) PDU SESSION 4
and offline charging

35
 Charging

Converged Charging — CHF Selection

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

CHF Selection Priority (High to Low)

1 > 2 > 3 > 4

PCF CHF 1
1

SMF-configured CC

UDM-provided
UDM 2 4 SMF
subscribed CC

3
NRF CHF 2

Trigger Condition

A charging event, initiated by the CHF, is a trigger condition which 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 the traffic used by a service reaches a specified threshold, the SMF requests the
CHF to update the charging session and obtain a new quota. Trigger conditions are classified into
the following types:

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 types:
 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.

36
 Charging

Procedure

UE UPF SMF PCF CHF

1. The UE initiates a PDU session request to obtain the charging policy.

2. The SMF
selects the CHF.

3. A charging session is established, and the quota and

trigger condition are delivered.

4. The charging rule and service quota are delivered to the

UPF after the PDU session is established.

Service data flow

.
5. A new quota is required when a trigger
condition is met.

6. The charging session is updated, the charging information is

reported, and a new quota is delivered.

7. The SMF delivers the

updated quota.

8. The UE is deactivated, the charging session is terminated,

and the CHF generates a final CDR.

5G converged charging is similar to 4G online charging, and charging information is transmitted

using four pairs of messages.

5G Charging 4G Charging
Service Operation Function
Message Message

Charging Data
Nchf_ Charging session
Request/Response CCR-I/CCA-I
ConvergedCharging_Create establishment
[Initial]

Charging session update, Charging Data

Nchf_
such as quota application Request/Response CCR-U/CCA-U
ConvergedCharging_Update
and reporting [Update]

Charging Data
Nchf_ Charging session
Request/Response CCR-T/CCA-T
ConvergedCharging_Release termination
[Termination]

CHF-initiated re-
Nchf_ Charging Notify
authorization or RAR/RAA
ConvergedCharging_Notify Request/Response
deactivation notification

37
O&M Solution

Overview
Huawei offers a comprehensive set of O&M activities, features, and tools to ensure that the 5GC
network runs smoothly.
Change Preventive Emergency
Routine O&M Troubleshooting
Management Inspection Management

• Ticket dispatching • Upgrades

• Alarm monitoring • Routine inspection
• Patch updates • Emergency response
• Fault diagnosis and • Potential risk analysis
• KPI analysis • Emergency handling
analysis • Migration and
• Metric monitoring • Potential risk detection
• Fault rectification capacity expansion • Redundancy
• Complaint resolution • Solution switchover
• Fault tracking • Network
optimization
reconstruction

VNF & NFVI capabilities

• MML configuration • Common and • Feature deployment • Checklist review prior • Pool-based
management and export random user trace to major VNF redundancy
• Comparison of alarms, operations
• MML batch processing • Interface trace statuses, and KPIs before • Active/standby
and after an upgrade • Key VNF feature redundancy
• Mistake proofing for • Logs
inspection
high-risk commands • Silent patch upgrade • Active-active
• CHRs
• VNF pre-warning and redundancy
• Alarm management • Hitless scaling rectification
• Self-healing of links • Full mesh
• Performance in suboptimal state • Adaptive scaling of COTS
management (eSight providing open APIs; • VM N-way
• Multi-level self- NFVI providing the Deploy
• License management healing of tool) • Flow control
microservices
• User and password • FusionSphere OpenStack
management • Suboptimal batch upgrade
network inspection
• Equipment archive • eSight/E9000 firmware
management • Anti-brain-split for batch upgrade
a distributed cluster
• SSO

• Scenario-based data
collection (via OM portal)

EMS capabilities

 Alarm monitoring  Signaling trace  Scenario-based data collection  Intelligent KPI anomaly detection
(using the NIC tool)

 Performance monitoring  KPI monitoring  VNF cross-layer topology

Tool capabilities

 Metrics and KPIs display  CHRs display  Offline MML tool  Scenario-based health check

 License display,  Operation logs display  Operation attendance tool

comparison, and check

 Alarms display  Traffic counter comparison  NFVI unified log analysis (CLLI)

38
 O&M Solution

Basic VNF O&M Architecture

Our service-centric O&M model maintains VNFs on a 5G network. It offers basic FCAPS capabilities,
including alarm and performance monitoring, performance statistics, data collection, as well as
configuration, log, and license management.

EMS

MML/SNMP/SFTP/FTPS/SOAP/NETCONF/RESTful
OM portal

O&M service set

Running and
deployment OMLB

Web

Portal
EMS
interconnection
Software upgrade Configuration maintenance

Backup and Northbound

Patch upgrade Licenses Help center
restoration interworking

Node
management O&M security Service monitoring

Security Alarm Service

Security audit
certificates management monitoring

OS Basic services Troubleshooting

management
O&M Data
O&M model Trace service Log service
database collection

File transfer File server Unified agent

Basic Framework Services

The EMS is a remote O&M center for centralized and intelligent O&M of diverse VNFs.
The O&M portal supplements the EMS, providing basic local emergency O&M capabilities for users
to maintain each VNF.
O&M capabilities of the EMS and OM portal:

Software
MML Log Trace Data
package
configuration management management collection
management

Alarm Performance Real-time License

monitoring statistics monitoring management

39
 O&M Solution

Centralized O&M Using EMS

The EMS is a device maintenance center that centralizes cross-layer O&M for VNFs and the NFVI.

OSS

EMS
(MAE-Access/U2020)

VNF VNF VNF VNFM

FusionStage

FusionSphere OpenStack/ eSight

FusionSphere OpenStack OM

COTS hardware

FusionSphere OpenStack OM eSight

Provides local O&M for FusionSphere Provides enhanced O&M services in the VIM
OpenStack; but does not support O&M for and is the unified O&M center for the NFVI
COTS hardware. in a DC.
eSight centrally monitors FusionSphere
OpenStack and hardware, including
compute servers, disk arrays, and switches.

VNFM (MAE-VNF LCM/VNF LCM) EMS (MAE-Access/U2020)

Manages VNF life cycles and obtains their Provides O&M for its managed VNFs,
infrastructure monitoring data from eSight. obtains NFVI monitoring data from eSight
and the VNFM, and provides correlation
analysis between the VNFs and NFVI
resources.

40
 O&M Solution

Centralized O&M Using IES-A

IES-A (IES-Assurance) is a centralized ICT O&M center and NFVO (MAE-Orchestrator) manages
service life cycles. Collectively, IES-A and NFVO are referred to as NFVO+.

OSS

NFVO+
(NFVO/IES-A)

EMS
Third-party EMS
(MAE-Access/U2020)

VNF 1 VNF 2 VNF 3

VNF 1 VNF 2 VNF 3
VNFM

FusionStage
FusionSphere OpenStack/ Cloud OS
FusionSphere OpenStack OM
eSight
COTS hardware Third-party hardware

FusionSphere OpenStack OM eSight

Provides local O&M for FusionSphere Provides enhanced O&M services in the VIM
OpenStack; but does not support O&M for and is the unified O&M center for the NFVI
COTS hardware. in a DC.
eSight centrally monitors FusionSphere
OpenStack and hardware, including
compute servers, disk arrays, and switches.

VNFM (MAE-VNF LCM/VNF LCM) EMS (MAE-Access/U2020)

Manages VNF life cycles and obtains their Provides O&M for managed VNFs, and
infrastructure monitoring data from eSight. obtains virtual resource and monitoring
data for the VNFs and NFVI from the
VNFM.

IES-A

Obtains VNF O&M data from the EMS and NFVI monitoring data from eSight, provides cross-
vendor, cross-layer, and cross-domain O&M, and reports the O&M monitoring data of the entire
5G network to the operator's OSS.

41
Cross-Layer O&M Features

Centralized Alarm and KPI Monitoring

The alarm and KPI monitoring data of the VNFs and NFVI is reported to the EMS and eSight,
respectively.
The data is then obtained by the IES-A for centralized cross-layer O&M.

IES-A Web NFVO+

portal (NFVO/IES-A)

MAE/U2020
EMS
Web portal
(MAE-Access/U2020)
sso
VNF OM portal

eSight portal

VNF VNF VNF

VNFM

FusionStage

FusionSphere OpenStack/
FusionSphere OpenStack OM
Compute Disk eSight
Switches
servers arrays

Alarm and performance data VNF alarm and performance data

Alarm data only NFVI alarm and performance data

Monitored Object Alarm and KPI Reporting Path

VNFs VNFs -> EMS -> NFVO+ (IES-A)

FusionStage FusionStage -> EMS -> NFVO+ (IES-A)

FusionSphere FusionSphere OpenStack -> FusionSphere OpenStack OM -> eSight -

OpenStack > NFVO+ (IES-A)

Hardware Compute servers/Disk arrays/Switches -> eSight -> NFVO+ (IES-A)

VNFM VNFM -> EMS -> NFVO+ (IES-A)

eSight eSight -> NFVO+ (IES-A)

42
 Cross-Layer O&M Features

SSO
SSO is an access management feature, which allows a user to access any of the several related,
yet independent, application systems with just one set of credentials.
With this feature enabled, users can:
1. Switch to the VNF OM portal, FusionStage OM portal, or VNF LCM Web portal from the
topology page of the EMS.
2. Switch to the web portals of NFVI components, such as FusionSphere OpenStack, E9000, and
disk arrays, from the eSight topology page.

MAE/U2020 Web
eSight Web portal
portal

FusionSphere
FusionStage OM VNF LCM Web OpenStack OM
VNF OM portal
portal portal Web portal

DeviceManager
Web portal

HMM Web portal

Logged-in Portal SSO-supported Destination Component

VNF OM portal VNF
FusionStage OM portal FusionStage
EMS (MAE/U2020) VNF LCM Web portal VNFM

eSight Web portal eSight

FusionSphere
FusionSphere OpenStack OM Web portal
OpenStack
eSight DeviceManager Web portal Disk arrays

HMM Web portal Compute servers

43
 Cross-Layer O&M Features

Unified Cross-Layer View

To locate a VNF fault, you may need to view the correlation between the VNFs, virtual resources,
and hardware resources.
The EMS can display this as a layered topology, or in a device panel view.

Cross-Layer Topology View Device Panel View

Board status:
VNF UNC_NSSF Normal Offline Unknown Faulty

VM status:
NF Service Framework NSSF Normal Offline Unknown Faulty

Service NSSF SBIM

Appctrl-pod Netm-Pod-d5...
Pod

VM

Host

Host
aggregate
HA
/Cluster

Cloud
Cloud

service DC

Description Description

Helps users easily find the VMs housing the Displays the status of servers and
VNFs to locate a fault. boards on a device panel.

Displays the VM status, so users can learn

the running status of all VMs where a VNF
resides.

Shows the VNFs affected by the faulty host

for users to determine the fault impact
scope.

44
 Cross-Layer O&M Features

Intelligent KPI Anomaly Detection

KPI anomaly detection plays a critical role in O&M, as it helps O&M personnel promptly identify faults
and provides a basis for further analysis.
The EMS intelligently detects KPI anomalies for 5G NFs. It uses AI algorithms to detect abnormal KPIs
and multi-metric correlation to analyze faults.
This function significantly reduces the time required to locate faults.

1. Training module 2. Detection

Provides a module
Selects an training
Historical Algorithm algorithm model Algorithm/
data library Algorithm model Test result

Classification result

Feature Real-time
classifier data

Training Module
1. The feature classifier in the training module classifies historical KPIs according to their features and
generates a classification result.
2. After the historical KPIs and classification are provided for the algorithm library, the training module
selects an appropriate algorithm to train KPI data, and then generates a training model.

Detection Module
1. After real-time KPI data is input into the detection model, the model predicts dynamic KPI thresholds
and KPI anomalies.
2. KPI anomalies and dynamic thresholds are displayed on the GUI and alarms are reported.

Multi-KPI Correlation Analysis

Traditionally, O&M personnel had to rely on experience to manually filter through many KPIs to find
correlations that would lead to a fault.
The multi-KPI correlation analysis enables automatic filtering of KPIs based on preset analysis templates. The
analysis result sorts the correlated KPIs by their relevance to the abnormal KPI in descending order. Therefore,
O&M personnel can efficiently locate the root cause by analyzing the most relevant KPIs.
Present templates for relationships between abnormal and correlated KPIs:

Relationship Description
Direct relationship The correlated KPIs directly cause the abnormal KPI.
The measurement object of a correlated KPI is part of the
Part-to-whole relationship
measurement object of the abnormal KPI.
Intra-NF service flow Correlated KPIs represent some stages in the procedure of the primary
relationship KPI.
Inter-NF service flow KPIs of multiple NFs are correlated based on services and are assigned
relationship into a correlation group, facilitating cross-NF fault locating.

For example, the following KPIs are in a direct relationship:

 Number of 5G-to-4G handover requests
 Number of successful 5G-to-4G handovers
 Number of failed 5G-to-4G handovers (License or configuration restriction)
 Number of failed 5G-to-4G handovers (Subscription data restriction)
 Number of failed 5G-to-4G handovers (Forward Relocation Response timeout)
 Number of failed 5G-to-4G handovers (Forward Relocation Complete Notification timeout)
 Number of failed 5G-to-4G handovers (Other causes)

45
Key O&M Activities

Routine Maintenance
Routine maintenance is an important part of keeping systems up to date and functional, and helps
O&M personnel mitigate risks.

Daily Weekly Monthly Quarterly

• Alarm check • Health check

• Historical alarm
• Software version
• Performance analysis • IP address check
check
statistics check • Historical • System data
• Patch version
• System running performance check
check
status check statistics analysis
• Switchover test
• User account
• License usage • Configuration
management • File system
check backup
backup

Address critical and some major alarms immediately, as they can affect system services.
Set KPI thresholds based on services, as well as observe and handle KPI fluctuation.

Fault Data Collection

Huawei provides advanced tools to efficiently collect fault data in different scenarios.
The table below lists the tools available for collecting fault data.

Object Tool Description

Mainly, the NIC tool provided by the MAE/U2020
collects VNF-related data. It supports scenario-,
MAE/U2020 NIC
template-, and problem-based data collection, as well
VNFs as customized items.
The OM portals of VNFs collect data for handling
VNF OM portal
VNF-related incidents and problems.

FusionStage OM The OM portal of FusionStage collects data for

FusionStage
portal handling FusionStage-related incidents and problems.
FusionCare collects FusionSphere OpenStack data. It
FusionSphere
FusionCare supports item-, scenario-, and component-based data
OpenStack
collection.
SmartKit collects data about hardware, including
Hardware SmartKit
servers, storage devices, and switches.

46
 Key O&M Activities

Data Collection Using the NIC Tool of MAE/U2020

Scenario-based Template-based
Customized items
collection collection

Incidents Service
issues
Items available Items selected

Before
Reset
and after an
issues Offline
operation
Template
Online

Upgrade Network
evaluation

Health
check

Inspection Process

VNFs are regularly inspected online or offline. The NIC tool provided by the MAE/U2020 collects
data online, and the NetCare platform performs offline inspections.
SmartKit and FusionCare help to inspect the NFVI.

Start an inspection Inspected Objects Checked Items

Collect requirements Device VMs, logical boards, and processes

Data configuration Parameter settings of key features

Handle changes
VNF Implementation of pre-warning
Pre-warning notices
Obtain authorization from notices
customers
Networking Network design data
Collect data Performance statistics Abnormal KPIs

Upload data Alarms Active, historical, and major alarms

Analyze data
Inspected Objects Checked Items
Generate a risk list FusionSphere
Statuses of FusionSphere OpenStack
OpenStack
components
Manage risks components

Memory, network performance, I/O,

Provide an inspection KPIs
NFVI disk usage, and CPU usage
report
Statuses of storage controllers, hard
Communicate with the Storage devices disks, power supply units, and fan
customer modules

Statuses of power supply units, hosts,

Servers
End the inspection ports, and server drivers

47
 Key O&M Activities

Basic Troubleshooting Process

5G networks are vertically decoupled and horizontally reconstructed. A single problem may involve software
and hardware at different network layers and from different vendors. To determine which provider or team
should be responsible for locating and rectifying the fault, follow the principles below:
 Service layer: Determine the responsible party and then locate the faults. Check the network horizontally
and then vertically.
 NFVI layer: Check the network vertically and then horizontally and evaluate the impacts on services.

Responsible-party
Data collection Fault locating Troubleshooting Summary
determination
Horizontal analysis

Dialing tests &

Alarms KPI monitoring
Problem analysis

complaints Irrelevant to virtual

compute, storage,
NFVI alarms VNF alarms Track KPI analysis and network
resources

No more
Preliminary analysis and conclusion
horizontal analysis

UNC UDG
VM VM
Pod Pod Pod
Relevant to virtual compute, storage, or network

Container Container Determination

Container
resources: Check the network vertically.

Container Container Container

point 1
Vertical analysis

FusionStage

Determination
point 2 FusionSphere OpenStack

Servers
Determination point 3

COTS hardware

TOR TOR

Storage EOR

Determination point 4

Customer
networks

Key Determination Points Analysis Methods

1: Between VNFs  Communication and reset problems: Check

2: Between VNFs and the cloud OS NFVI alarms and then VNF alarms.
3: Between the cloud OS and COTS hardware  Interconnection problems: Ping the peer
4: Between COTS hardware and customer end, and then check the MAC address
networks table and routing table on both ends.
 Service loss problems: Check the
networking and routes, and then the reset
and migration records.

48
 Key O&M Activities

Emergency Handling Process

Incident Prevention Typical Faults Handling Methods

• Draw a detailed networking diagram.  VNF redundancy switchover

• Design an emergency plan.  Service exception  Operation rollback
• Perform redundancy checks and emergency  Database exception  VNF bypass/flow control
drills regularly.  BE database restoration
• Formulate an emergency handling process.
• Set up a joint emergency response team.  VM migration/reset/reboot
 Host/VM network
fault
 Host reset/VNF redundancy
Incident Handling switchover
 Host/VM storage fault
 VNF redundancy switchover
Determine the fault scope and promptly rectify  Host/VM OS panic
the fault.
 HA self-healing

 Blade fault
Incident Summary  Disk array fault  VM migration
Analyze the root cause of the incident and  Network port  Host restart/power-
summarize the incident handling experience. fault/packet loss and off/isolation
error

Data Fault Faulty VNF Redundancy Service Root Cause

Collection Report Identification Switchover Restoration Locating

Cross-DC Redundancy Networking

NRF NSSF NCG SMSF

NRF NSSF NCG SMSF

SMF/PGW-C PCF/PCRF FE UDM/HSS FE

AMF SMF/PGW-C PCF/PCRF FE UDM/HSS FE
AMF
UPF/PGW-U PCF/PCRF BE UDM/HSS BE
UPF/PGW-U PCF/PCRF BE UDM/HSS BE

AN

Cross-DC Redundancy Solution

NF Product Redundancy Solution NF Product Redundancy Solution

UPF/PGW-U UDG/UEG Pool-based

NRF UNC
• (Recommended) AUSF/UDM/ • FE: Active-active or
UDM
Active-active HSS/HLR active/standby
NSSF UNC • Active/standby • BE: Active/standby
Networking:
• 2x(FE+BE)
AMF UNC PCF/PCRF UPCF active/standby
• 2xFE active-active +
Pool-based 2xBE active/standby
SMF/PGW-C UNC

SMSF UNC
Active-active
NCG UNC

49
Find Out More

5G is here. Are you ready?

We hope this brochure shows how 5G can benefit and unlock new
opportunities to boost your business.

Huawei strongly believes that 5G will reshape society as a whole, and

is dedicated to developing well-rounded technical solutions to
unleash the full potential of 5G.

5GC plays a vital role in empowering the digital transformation of all

industries. That’s why Huawei is doing everything we can to
strengthen it by focusing on deployment, maintenance, and operation,
and innovatively introducing network slicing and MEC technologies.
O&M
We offer a wide range of documentation for all of our 5GC services
and solutions to help operators and developers. They are available at
the 5G Core Information Center.

Browse Our Documents for 5GC

https://support.huawei.com/

Cloud Core Network

Visit Huawei support website.

Bookshelf
Click 5G Core.
5G Core (5G Core/UNC/UDG/UDM/UPCF/
Telco Cloud)

Click the banner for 5G Core Information Center.

5G Core Information Center

One-Step Information Center on 5GC Official Documents

Let's forge an exciting new future-oriented world

empowered by 5G technology.
Sponsors: Wang Xiang, Yi Duoliang, Ning Qiguo, Tang Yunyu
Taowen, Zhang Junxia, Liu Ying, Chen Yuejing, Liao
Authors: Mingming, Yan Ming, Sun Lan, Wang Ping, Wang Jun, Chen
Jie, Dong Baoli, Chang Lun, Wang Shengnan, Wang Xiaocen
Dong Zhengping, Jia Weigang, Hu Xiao, Zhao Yang,
Editors:
Xuan Zhengchun, Wu Rongtao, Deng Zhiwen, Cui Rongwei
Visual Effects: Guo Xin, Gui Fei, Wang Ying

Trademarks and Permissions

, HUAWEI, and 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 information in this document may contain predictive statements including,
without limitation, statements regarding the future financial and operating
results, future product portfolio, new technology, etc. There are a number of
factors that could cause actual results and developments to differ materially
from those expressed or implied in the predictive statements. Therefore, such
information is provided for reference purposes only, and constitutes neither an
offer nor a commitment. Huawei may change the information at any time
without notice.
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.

Customer Service Email: CoreNetworkDoc@huawei.com

Copyright © Huawei Technologies Co., Ltd. All rights reserved.