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 NEF Network Exposure Function
DNN Data Network Name NFV Network Functions Virtualization
DRA Diameter Routing Agent Network Functions Virtualization
NFVO
EPS FB EPS Fallback Orchestrator
FBC Flow-based Charging Number Portability
NPAC
Administration Center
FCAPS Fault, Configuration, Accounting,
Performance, Security NRF Network Repository Function
FQDN Fully Qualified Domain Name NS Network Service
F-TEID Fully Qualified Tunnel Endpoint NSD Network Service Descriptor
Identifier Network Slice Management
NSMF
GMLC Gateway Mobile Location Center Function
GPSI Generic Public Subscription Network Slice Selection
NSSAI
Identifier Assistance Information
GUAMI Globally Unique AMF Identifier NSSF Network Slice Selection Function
GUMMEI Globally Unique MME Identifier Network Slice Subnet
NSSMF
Management Function
HA High Availability
NSST Network Slice Subnet Template
HLR Home Location Register
OCF Online Charging Function
H-NRF High-level NRF
OCS Online Charging System
HSS Home Subscriber Server
 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

03 4G-5G Interworking 19

5G Core 04 Vo5G 26

05 Subscriber Migration &

Service Provisioning 31

06 Charging 36

07 Signaling 41

Telco Cloud 08 Telco Cloud 47

09 Overview 54

10 VNF LCM 57
iMaster
MAE-CN
11 NFVO 59

12 Unified Cross-Layer View 62

13 Network Slice Management 63

14 O&M Solution 64

O&M 15 Cross-Layer O&M Features 68

16 Key O&M Activities 72

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

SMS
SMSF Active-active 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, NSSF, SMSF, UDM, and UPCF (the
SMSF does not back up data with the
paired SMSF)

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 NRF

Ping
Nnssf Nausf Nudm Nnrf

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

16
 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

2 An FE is faulty.
through SCTP/TCP, the DRA sends
DRA, NRF, messages to the other FE.
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.

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

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

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

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

21
 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

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

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

24
 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

25
Vo5G

Evolving Voice Solutions

Though the rise of 5G networks gives impetus to elevated data traffic, voice services are still the
pillar of telecom networks. Operators tend to agree that voice services should be provided through
the IMS in the 5G era. The Vo5G solution is conceived based on the preceding consensus. This
solution consists of the following subsets:
• VoNR: Applied when subscribers access the 5GC through 5G NR that supports voice services.
• EPS FB: Applied when subscribers access the 5GC through 5G NR that does not support voice
services. Subscribers have to fall back from the 5GC to EPC before using VoLTE services.

Huawei recommends the EPS FB solution for the early stages of 5G and the VoNR solution for an
SA 5GC.

EPS FB: NR does not support voice services. VoNR: NR supports voice services.

(1) The UE sends an INVITE (2) The 5GC triggers EPS FB. The UE sends an INVITE
message through the NR. message through the NR.

Internet
Internet
5GC 5GC

IMS
NR IMS
NR
EPC
EPC Data Data
traffic LTE traffic
(3) The UE accesses the
LTE IMS through EPC. Voice Voice
traffic traffic

There are two mainstream solutions for evolving VoLTE to VoNR.

Solution Description Prerequisites Advantages

Operators can reuse
Use EPS FB as an VoLTE services VoLTE network
Solution 1: VoLTE → EPS interim solution if have been resources to the
FB → VoNR/EPS FB VoNR is not supported provisioned on maximum extent, and
at the early 5G stage. live networks. the deployment is
relatively simple.
Technologies Operators can build 5G
Build 5G NR networks
Solution 2: VoLTE/IMS for 5G NRs and voice networks in one
and 5GC to provide
→ VoNR 5GCs are step, speeding up
voice services.
mature. evolution.

In summary, solution 1 uses EPS FB as an interim step and is recommended because deployment is
fast and it maximizes the ROI.

26
 Vo5G

EPS FB Network
An EPS FB network consists of the operations support system, NR and LTE networks, IMS, user
database, signaling network, policy control system, EPC, and 5GC.

Operations support system

Operations support system
manages network elements, stores
subscription data, provisions
services on a unified web portal,
EMS SCP SMSC CCF SPG and manages charging and devices.

Database IMS
IMS consists of the P-CSCF, I-CSCF,
S-CSCF, and ATS. The IMS allows
SCC AS/Anchor AS/ registration of 5G subscribers,
AP-AS MMTel AS/IM-SSF obtains 5G location information,
AP/BSF /IP-SM-GW and provides other functions
Sh/Cx/Zh similar to those offered for 4G
subscribers.
DNS/ Zh Sh ISC
ENUM
Rx User database stores 5G
Sh/J subscriber and service data in the
DRA
Cx UDM. The data is used for
selecting a terminating domain
and 4G-5G interworking.
Mp

Cx MRFP
Mw I/S-CSCF
/MRFC Signaling network consists of the
DRA, SCP, and BSF, and NRF. The
DRA/SCP steers received Diameter
N6 signaling to Diameter peers.
UDM
The BSF registers its NF profile with
Rx the NRF and binds UE IP addresses
with PCF IDs.
S6a PCF BSF The NRF functions as a warehouse
A-SBC
/P-CSCF administrator to automatically
/ATCF manage all NFSs, including
/ATGW N7/N15 registration, discovery, and status
N8/N10 detection.

EPC Rx 5GC Policy control system manages

Gx/Rx policies used for 5G voice
services. The PCF requests the
BSF to bind UE IP addresses and
N7/N11/N10 PCF IDs.
Gx
EPC consists of the MME, S-GW,
DRA and P-GW. The MME interworks
NRF SCP UPF with the AMF over the N26
interface for 4G-5G interworking.
N8 The EPC is the entrance to the IMS
S6a N11/N15
for 4G subscribers and 5G
subscribers who fall back to the
LTE network.

5GC consists of the AMF, SMF, and

MME
N4 UPF. The 5GC processes registration
S/P-GW AMF SMF and EPS FB for 5G subscribers. The
AMF interworks with the MME over
S1-C the N26 interface for 4G-5G
S1-U interworking. The 5GC is an
N2 N3 entrance to the IMS for 5G
subscribers.

LTE network 5G UE NR network 5G UEs are capable of accessing

E-UTRAN NG RAN both 4G and 5G networks

27
 Vo5G

Registration
5G subscribers must register with the 5GC and then the IMS before they can use the EPS FB service
and services provided by the IMS, such as IMS calls, SMS, and CRBT.

IMS SBC/ IMS

Registration with the 5GC
SBC/ I/S-CSCF P-CSCF I/S-CSCF 1. The UE sends a registration
P-CSCF 7. Obtains request to the AMF.
location 8. 2. The AMF initiates
information. Authenticates authentication.
UDM the UE. UDM
3. The AUSF authenticates the UE.
4. The UE authenticates the
network.
3. QoS Flow Establishment and P-
5GC 5GC
Authenticates CSCF Discovery
the UE.
5. The UE sends a PDU session
AUSF AUSF
establishment request to the
AMF.
6. Creates 5. Requests 2. Initiates 6. The SMF creates a PDU session.
a PDU a PDU authentication.
SMF AMF SMF AMF Registration with the IMS
session. session.
7. The P-CSCF obtains location
1. Requests information.
registration. 8. The I/S-CSCF authenticates the
NG RAN UE.
NG RAN
9. Authenticates the 9. The UE authenticates the IMS.
4. Authenticates
UE UE network.
the network.

Registration with EPC VS. Registration with 5GC

 A UE attaches to an EPC before registering with it. During the attachment, a PDN connection is
established using the default APN (usually a data APN) for the UE. Then, another PDN
connection is established using an IMS APN.
 A UE does not need to attach to a 5GC, and instead registers with it directly. During the
registration, no PDU session is established for the UE. Initial registration with the 5GC and PDU
session establishment are two separate processes.

Attach to Registration Data Registration

Service IMS APN/DNN
EPC with 5GC APN/DNN with IMS
4G data Yes Yes

4G voice Yes Yes Yes

5G data Yes Yes

5G voice Yes Yes Yes

Registration with IMS by 5G Subscribers VS. Registration with IMS by 4G Subscribers

The main difference between those two types of registration lies in the location information sent
to the SBC/P-CSCF. The SBC/P-CSCF uses the RAT Type AVP obtained over the Rx interface to
identify how the UE accesses the network.
 If this AVP is set to E-UTRAN, the UE accesses the network through an eNodeB.
 If this AVP is set to NG RAN, the UE accesses the network through an NR.
If the Rx policy data is not configured, the SBC/P-CSCF uses the PANI header field instead.

28
 Vo5G

Basic Calls

The message flow for EPS FB is as follows:

Originating IMS Terminating IMS

ATS ATS
UDM UDM

I/S-CSCF I/S-CSCF
SBC/P-CSCF PCF SBC/P-CSCF PCF

5GC EPC 5GC EPC

SMF AMF MME S-GW/ SMF AMF MME S-GW/

P-GW P-GW

NG RAN E-UTRAN NG RAN E-UTRAN

UPF UPF

Signaling before the EPS FB

UE Signaling after the EPS FB UE

The following figure illustrates the message sequence for an MO call during which EPS FB is
performed.

P-GW/
UE NG RAN E-UTRAN AMF MME S-GW PCF IMS
SMF/UPF

1. The UE sends a call request to the 5GC.

2. The AMF sends a request to the NG RAN, instructing it to establish the QoS flow dedicated for the
call. The NG RAN decides to trigger EPS FB and denies the request.[1]

[2]
3. The UE falls back from the 5GC to the EPC.

4. The UE initiates a location update with the UDM.

5. The EPC instructs the eNodeB to establish a dedicated bearer.

6. The IMS continues establishing the call.

[1] Checking EPS FB capabilities

The NG RAN checks the capabilities for both the UE and the RAN to determine whether EPS FB
is supported. If any capabilities are not met, the NG RAN rejects the request for establishing the
QoS flow with the cause value "IMS Voice EPS Fallback Triggered".
[2] Selecting an EPS FB mode
A UE triggers EPS FB using either the handover or redirection flow. The NG RAN selects an EPS
FB mode based on its capabilities. During a handover-based EPS FB flow, the NG RAN instructs
the UE to measure the LTE signal strength, and the UE does not fall back to the EPC until
default bearers on the EPC are established. This limits the service interruption duration caused
by EPS FB, and is why the handover-based EPS FB flow is recommended.

29
 Vo5G

Enabling EPS FB on an Existing VoLTE

We can reconstruct an existing VoLTE network so that it supports the EPS FB solution. This
construction method can reuse IMS resources and reduce TTM.
The topology of a reconstructed network is as follows:

5GC IMS
Signaling
UDM+ ATS/
Media BSF IP-SM-GW
HSS

Configure interworking
between the SBC and PCF.

SMF+ SBC/
AMF PCF S-CSCF
PGW-C P-CSCF

UPF+ Terminating
UE NG RAN MRFP
PGW-U network

Prerequisites:
 You have deployed VoLTE and 5GC networks.
 The UDM and PCF have been deployed.
The structure and interfaces of the IMS network remain unchanged. Configure the following service
data on the IMS.

NE/NF Configuration
 Add data about cells that provide access to 5G subscribers.
 Configure policies for searching data tables, setting cell information, PANI
header field in CDRs, and access types in CCR messages.
ATS
 Configure special services supported by the ATS during offline charging.
 (Optional) Enable T-ADS to provide CS Retry for Vo5G subscribers. This is
recommended.
 Configure the UDM to support query for 5G subscriber location and status.
UDM and HSS
 Configure the HSS to support 4G-5G interworking.
 Add location analysis data on the S-CSCF.
 Configure the S-CSCF to determine whether to authenticate subscribers
CSCF based on access types.
 Configure registration validity periods for subscribers based on their access
types.
 Configure the SBC to allow access from 2G, 3G, 4G, and 5G subscribers.
 Configure the SBC to transparently transmit the access network type sent by
SBC
the UE if it fails to obtain the access network type over the Rx interface.
 Add mappings between location information and area codes.

Configure the BSF to support the 5G HTTP Signaling Session Binding Standard
BSF
Package feature.

AMF and SMF Activate the EPS Fallback service.

Note: The EPS FB service applies only to Cloud IMS networks.

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

31
 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

32
 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
definition command to the home UDR based on
the subscriber number segment.
2. The UDR forwards the provisioning command
to the BE.
3. The BE defines 4G subscribers.
1. The provisioning system delivers the 4G service
parameters to the home UDR based on the
subscriber number segment.
2. The UDR forwards the provisioning command to
the BE.
3. The BE provisions 4G services.

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

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

35
Charging

Introduction

5G imposes new requirements on how charging is performed and how it interacts with the
network. To address this, 3GPP Release 15 defines a new charging architecture with a new API —
a Converged Charging System (CCS):
 The 5G CCS combines the 4G Online Charging System (OCS) and its separate offline charging
system.
 The Nchf interface, which is an SBI, replaces the previous Ga and Gy interfaces, to interwork
with 5G NFs.

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

The CCS introduces the Charging Function (CHF) to interact with the billing system, over the
existing Bx interface. With the Rating Function (RF), Account Balance Management Function
(ABMF), and Charging Gateway Function (CGF), the CHF can perform both online and offline
charging.
This evolution conforms to the SBA used by 5GC, meeting the requirement of IT system
cloudification and flexible deployment.
In spite of the changes, the purposes of the CCS and traditional online and offline charging
systems are essentially the same, that is, to charge for traffic usage by volume or duration, collect
information such as the RAT, QoS, and URL, and perform credit control for online charging
services, no matter what charging interfaces and functions are used, and where the systems are
deployed.

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

37
 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

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

39
 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

40
Signaling

Challenges

 Overlapping funding and complex O&M: Constructing a 5G network is costly. Moreover, 4G

and 5G networks co-exist, which overlaps funding and requires highly specialized O&M
personnel.
 HTTP shortcomings: The control plane of 5G networks adopts the open HTTP protocol and is
prone to attacks. Signaling security turns to be a primary concern for operators. In addition,
HTTP links are unidirectional, leading to a dramatic increase in link quantity.
 Complex routing: A 5G core network is built based on the SBA and is fully meshed. The link
quantity on a 5G core network is several times of that on a 4G network. In addition, addressing
a PCC network or DC on a 5G core network is complex because terminals access the network
in different modes. For better management, flexible routing is required.

Huawei Convergent Signaling Network Solution

Roaming hub IPX provider

SPS (ISTP) SPS (ISTP) IPX agent IPX agent

NMS
International International International 5G
2G/3G network 4G network network

SPS (ISTP) SPS (ISTP) SPS (DEA) SPS (DEA) SPS (SEPP) SPS (SEPP) NPAC

National network

SPS (STP/DRA/BSF/SCP) SPS (STP/DRA/BSF/SCP) LSMS

SS7/SIP/Diameter Diameter Diameter SS7/SIP SS7/SIP HTTP

PCC Fixed
IMS 2G/3G 5GC
network

OFCS PCRF MSC NGN PCF

CSCF ATS server .
.
.

HSS OCS

SMSC AMF
GPRS/EPC

SGSN PCRF MME HSS HLR LE/LS SMF

41
 Signaling

Signaling Network Evolution Towards 5G

4G 5G NSA 5G SA

VoLTE PCRF HSS VoLTE PCRF+ HSS+ VoLTE/Vo5G PCRF+/PCF HSS+/UDM

Other network
Diameter Other network Diameter Diameter & HTTP

Other network
DRA DEA DRA+ DEA+ DRA+&SCP DEA+&SEPP

Diameter Diameter Diameter & HTTP

MME P-GW MME+ P-GW+ MME+/AMF P-GW+/SMF

Evolving to support 5G SA
Upgrading software to support deployment based on the SBA
Migrating the DRA and DEA 5G NSA deployment
to the cloud
Accelerating 5G network Safeguarding signaling
Maximizing 4G signaling construction
Uniformly monitors 4G&5G signaling and
Supports 4G&5G session binding data
network investment returns sharing and reduces overlapping
identifies signaling attacks.
Supports the smooth evolution to 5G. configurations.

Huawei SPS converges the DRA, SCP, and HSS UDM/AUSF

BSF functions and routes 4G&5G signaling
within a PLMN.
SPS
SPS with the SCP and DRA co-located: PCRF
DRA PCF
 Supports 4G&5G routing data sharing.
Gy
 Defends against network-level traffic surges OCS SCP
and dispatches traffic in real time for load
balancing. BSF NchfCHF

IMS
SPS with the BSF and DRA co-located:
 Supports 4G&5G session binding data sharing,
reducing database resource consumption. EPC 5GC

 Reduces 4G-5G interactions, simplifying the

session binding data query process.

MSC
The SPS will ultimately converge the ISTP, DEA, server
and SEPP to connect multiple PLMNs and secure IPX/PLMN
HLR SMSC
an inter-network signaling exchange. (SS7)
SPS
SPS with the ISTP, DEA, and SEPP co-located: HSS/UDM
ISTP
 Interworks with other PLMNs or IPXs, hides
IPX/PLMN
network topologies, and encrypts inter- PCRF/PCF
DEA (Diameter)
network transmission.
MME/AMF
 Acts as a firewall to block invalid messages SEPP
and identify attacks by detecting abnormal
GW/SMF SMSF IPX/PLMN
behaviors and analyzing security data. (HTTP)

 Provides a unified O&M platform to

facilitate O&M.

42
 Signaling

SCP Functions
The SPS provides the SCP functions to converge HTTP signaling. This simplifies network topology
and facilitates O&M.

Region A Region B Region A Region B

HSS/UDM HSS/UDM HSS/UDM HSS/UDM

PCRF/PCF OCS/CHF PCRF/PCF OCS/CHF PCRF/PCF OCS/CHF PCRF/PCF OCS/CHF
/AUSF /AUSF /AUSF /AUSF

NRF NRF
NRF SCP SCP NRF

MME/AMF PGW/SMF AF MME/AMF PGW/SMF AF MME/AMF PGW/SMF AF MME/AMF PGW/SMF AF

The SCP provides the following functions:

 Signaling aggregation: It converges signaling to simplify a mesh network to a star network.
 Flexible message routing: It provides flexible routing policies, such as routing messages based
on FQDNs or IP addresses in URIs.
 Delegated NF discovery: It is delegated by the NF service consumers to initiate service
discovery with the NRF.

SCP Deployment

SCPs are deployed in pairs for redundancy. SCPs in a pair (SCP A and SCP B) share traffic load with
each other and communicate over C links. If the HTTP link between SCP A and an NF becomes
faulty, SCP A forwards messages to SCP B over C links. SCP B then forwards the messages to the
target NF. This enhances service reliability.

CHF PCF UDM AUSF

NF service producer 1 NF service producer 2

N40 N15 N7 N8 N10 N12

SBI
C links
Nnrf

SCP A SCP B
SCP A SCP B
NRF

N12 N10 N7

N8 N15 N40

NF service consumer 1 NF service consumer 2

Physical link set Signaling flow

AMF SMF

43
 Signaling

SCP Routing Capabilities

The SCP can route messages based on IP addresses in URIs, FQDNs, GPSIs, SUCIs, SUPIs, and DNNs.
The FQDN-based message routing is used as an example here.

01 HTTP request
03 HTTP request
FQDN

Client SCP Routes the request to the Server

destination server based on
02 the FQDN carried in the
apiRoot IE in the request.

Routing Policy

Interface Involved NFs Service Invoked API User Identity

DNN FQDN URI IP Encrypted
SUPI GPSI
SUCI

AF – PCF Npcf_ npcf-

N5 Yes Yes Yes Yes Yes
NEF – PCF PolicyAuthorization policyauthorization

npcf-
N7 SMF – PCF Npcf_SMPolicyControl Yes Yes Yes Yes Yes
smpolicycontrol

Nudm_Subscriber
nudm-sdm Yes Yes Yes Yes
DataManagement
N8 AMF – UDM
N10 SMF – UDM
N21 SMSF – UDM
Nudm_UEContext
nudm-uecm Yes Yes Yes Yes
Management

Nausf_
N12 AMF – AUSF nausf-auth Yes Yes Yes Yes
UEAuthentication

Nudm_
N13 AUSF – UDM nudm-ueau Yes Yes Yes Yes
UEAuthentication

npcf-am-policy-
Npcf_AMPolicyControl Yes Yes Yes Yes
control
N15 AMF – PCF
npcf-ue-policy-
Npcf_UEPolicyControl Yes Yes Yes Yes
control

N5g-eir_
N17 AMF – 5G-EIR EquipmentIdentity n5g-eir-eic Yes Yes Yes Yes
Check

Nchf_ nchf-
N40 SMF – CHF Yes Yes Yes
ConvergedCharging convergedcharging

44
 Signaling

BSF Functions
The SPS provides the 3GPP-compliant BSF functions. The BSF facilitates target PCF addressing on
a 5G network.
If multiple PCFs are deployed on a 5G network, the BSF queries session binding data for the PCF
serving a subscriber, such as the IP address or DNN. Afterwards, it sends the PCF information to
the NEF or AF. The NEF or AF then can route messages received from the subscriber over different
interfaces (N7, N5, and Rx) to the target PCF during data and voice services.

Interactions with NFs/NEs

HTTP/Nnrf  Interactions with the NRF: The BSF registers,

NRF updates, or deregisters its NF profile with the
NRF.
 Interactions with the PCF: The PCF registers
HTTP/Nbsf or deregisters session binding information with
PCF
the BSF.
BSF  Interactions with the NEF/AF: The NEF/AF
HTTP/Nbsf invokes the Nbsf_Management service to query
NEF/AF
session binding information for the PCF
address.
Diameter/Rx  Interactions with the P-CSCF: The BSF
P-CSCF receives AAR messages from the P-CSCF over
the Rx interface.

Interface NF/NE Service Process Protocol

NF profile registration
Nnrf_NFManagement_NFRegister

NF profile update
Nnrf BSF -> NRF
Nnrf_NFManagement_NFUpdate

NF profile deregistration
Nnrf_NFManagement_NFDeregister
HTTP/2.0
Session binding information registration
Nbsf_management_Register
BSF <- PCF
Session binding information deregistration
Nbsf
Nbsf_management_Deregister

Session binding information query

BSF <- NEF/AF
Nbsf_management_Discovery

Rx BSF <- P-CSCF Session binding information query Diameter

45
 Signaling

BSF Deployment
Networking
5G voice services are still provided by the IMS network. To support VoNR services for 5G subscribers,
the BSF needs to be able to interwork with the DRA on the IMS network over the Rx interface. The
BSF can act as a proxy agent or a redirect agent to help the DRA address a PCF, as defined in 3GPP
TS 29.513.
 Proxy agent: After receiving an AAR message from the DRA, the BSF obtains the host name of
the target PCF, includes the PCF host name in the AAR message, and sends the message to the
target PCF over the Diameter link.
 Redirect agent: After receiving an AAR message from the DRA, the BSF obtains the host name of
the target PCF and returns a response carrying the PCF host name to the DRA. The DRA then
redirects the AAR message to the target PCF.
When the BSF acts as a proxy agent, Diameter links between the BSF and PCF are required.
When the BSF acts as a redirect agent, Diameter links between the BSF and PCF are not required.

5GC
N7

01 PCF 1
AMF SMF

NR The BSF is configured to

BSF
interwork with the DRA Registers binding
02
over Diameter links. information.
04 Sends the AAR message
to the target PCF.
PCF 2
Sends an AAR 04 Returns a redirection
03
message. indication.

05
IMS Rx
Rx

PCF 3
The DRA on the live
network remains
unchanged.
IMS AF DRA
UE

Proxy

Deployment Scheme Redirect

Here is a recommended scheme when a standalone BSF is deployed.

In this scheme, it is recommended that dedicated IP segments be allocated to 5G subscribers
during attach procedures to help the DRA distinguish 5G subscribers from 4G.

… NF/NE Deployment

NEF/AF NRF Deploy two BSFs as an active-active

PCF PCF
BSF pair and each BSF connects to
multiple PCRFs.

Add Diameter links for the BSF to

interwork with the DRA. If IP
addresses in Rx messages fall in the
DRA
IP segments dedicated for 5G
subscribers, the DRA queries the BSF
over Diameter links.
BSF BSF Deploy the BSF to interwork with the
PCF
PCF over HTTP and Diameter links.
Deploy the BSF to interwork with the
NRF
NRF over HTTP links.
HTTP link
Deploy the BSF to interwork with
Diameter link NEF/AF
DRA DRA the NEF/AF over HTTP links.

46
Telco Cloud
Telco Cloud

Positioning
Telco Cloud is a cloud platform for telecom services. It leverages advanced technologies, such as
NFV, SDN, Cloud Native, container, and AI. With these technologies, it endows solutions, including
5GC, MEC, and SVC, with full-cloud, full-stack, ultimate experience, and multi-network convergence
features.

All-cloud, full-stack Ultimate experience Multi-network convergence

5GC MEC SVC

NEF NRF PCF UDM MEAO CloudIMS

AUSF AMF SMF UPF App MEP CloudSBC

controller

… …
MEC

UE AN UPF MEC IaaS CloudSBC

Telco Cloud platform

NFV Cloud Native SDN

 5GC adopts SBA and NFV architectures to deploy core NFs on an SA network, empowering agile,
simplified, efficient networking.
 MEC moves core network applications, content, and some MBB service processing and resource
scheduling functions to the network edge, closer to users. Applications, content, and networks
collaborate with each other, providing the ultimate service experience.
 SVC converges voice services of different RATs into the same network. It simplifies networks and
O&M, and improves the overall voice service experience.

47
 Telco Cloud

Solution Architecture

Operation support layer BSS/OSS Application management

VNF layer

EMS EMS EMS NFVO

VNF VNF VNF VNFM

Virtualization layer Infrastructure management

Virtual Virtual Virtual NFV_FusionStage

compute storage network

NFV_FusionSphere
Hardware layer
eSight

Compute Storage Network iMaster NCE-Fabric

Category Main Component

COTS hardware devices, including servers, storage, and network devices.

 Huawei servers include RH2288, E9000, RH1288, TaiShan 200 (model:
2280), and E9000H.
Hardware layer
 Huawei storage includes OceanStor series disk arrays and the
FusionStorage solution.
 Huawei network devices include CE and NE series switches.
The components at this layer abstract underlying physical resources into
Virtualization layer
virtual resources. Virtual switching technologies include EVS, OVS, and SR-IOV.
The EMSs are used to manage VNFs. One or more EMSs can be deployed as
required. Huawei U2020 or MAE serves as an EMS.
VNF layer
A VNF is a network function entity. It runs on VMs to provide services. Huawei
VNFs include the UNC, UDG, UDM, and more.
Operation support layer BSS and OSS
A VNFM manages VNF life cycles. For example, it instantiates, scales, and
rebuilds VNFs. Huawei U2020 VNF LCM or MAE-VNF LCM serves as a VNFM.
Application
management An NFVO orchestrates and manages all the software and network services
across an NFV network. Huawei CloudOpera Orchestrator NFV serves as an
NFVO.
Management
and NFV_FusionStage deploys containers and manages their resources.
orchestration NFV_FusionSphere, including FusionSphere OpenStack and FusionSphere
domain OpenStack OM, provides cloud OS functions and manages virtual resources.
Infrastructure
management iMaster NCE-Fabric, an SDN controller that automatically deploys and
configures networks.
eSight, an NFVI O&M center that manages NFVI hardware and topologies,
and provides O&M functions.

48
 Telco Cloud

Networking
SDN is recommended for Telco Cloud because it centrally controls and manages routing and
switching, provides a unified network view, and automatically and intelligently manages networks
and orchestrates services. Services can be quickly deployed, and network efficiency can be improved.
Networking Categories

Network overlay NFVI management & storage traffic is routed over VLANs, and service traffic over network
(recommended) overlay-based VXLANs.
NFVI management & storage traffic is routed over VLANs, and service traffic over host
Host overlay
overlay-based VXLANs.
NFVI management & storage traffic is routed over VLANs, some service traffic over network
Hybrid overlay
overlay-based VXLANs, and other service traffic over host overlay-based VXLANs.
Non-SDN VLANs for both NFVI management & storage and service networks.

Network Overlay (Recommended)

PE PE
NFVO/VNFM
VIM

DC GW DC GW
SDN controller
Border leaf Border leaf
VXLAN VXLAN
MS: NFVI management & storage

MS-EOR MS-EOR Spine Spine

SDN mgmt.
& config.
VXLAN VXLAN channel

MS-TOR MS-TOR L2/L3 GW L2/L3 GW

Server leaf Server leaf

vSwitch vSwitch vSwitch vSwitch

VM VM VM VM

Provides a way to extend Layer 2 networks across Layer 3 infrastructure using MAC-in-
VXLAN
UDP encapsulation.
An entity for SDN. It converts the VNF network interconnection model into the NFVI
NFVO
network model, and manages service and network life cycles.
A network automation control center for SDN. It controls switches to automatically
SDN controller
generate network interconnection data.
Start point of a VXLAN tunnel. It encapsulates and parses VXLAN packets, and allows
Server leaf
VNFs to access the VXLAN.
Distributed gateway at Layer 2 or 3 of a VXLAN. It allows VXLAN packets to be
L2/L3 GW
transmitted over the nearest Layer 2 or 3 network.
The switching center of network traffic. It provides high-speed IP forwarding, and
Spine
connects to each server leaf through high-speed interfaces.
A VXLAN Layer 3 gateway and the end point of a VXLAN tunnel. It allows external traffic
Border leaf
to access the VXLAN of a DC.

49
 Telco Cloud

Data center gateway. It is connected to external routers or transmission devices. It is usually

DC GW
co-located with the border leaf.

PE An operator's border router. It enables a DC to communicate with external networks.

Access switch on the management & storage network. It enables Layer-2 communication
MS-TOR
for management & storage VLANs.
Aggregation switch on the management & storage network. It enables Layer-3
MS-EOR
communication for management & storage VLANs.

Network Overlay Features

 Hardware switches encapsulate VXLAN packets.
 NFVI management & storage traffic is routed over VLANs, and service traffic over network
overlay-based VXLANs.

Host Overlay

PE PE
NFVO/VNFM
VIM

DC GW DC GW
SDN controller
Border leaf Border leaf
VXLAN VXLAN
MS: NFVI management & storage

MS-EOR MS-EOR Spine Spine

MS-TOR MS-TOR L2/L3 GW L2/L3 GW

Server leaf Server leaf

SDN mgmt.
& config.
VXLAN VXLAN channel
vSwitch vSwitch
CE1800V CE1800V
VM VM VM VM

CE1800V is a new component for host overlay. In essence, it is a software switch and functions as
a server leaf at the start point of a VXLAN tunnel.

Host Overlay Features

 Software switches (CE1800V) encapsulate VXLAN packets.

 NFVI management & storage traffic is routed over VLANs, and service traffic over host overlay-
based VXLANs.

50
 Telco Cloud

Automatic Deployment

One of the advantages of SDN is that it automatically deploys networks, improving deployment
efficiency.
With the SDN controller, network devices automatically deliver network interconnection data.

Fusion Fusion DCN Network device/

NFVO VNFM VNF
Stage Sphere controller CE1800V

Complete installation, interconnection configurations, VNF pre-configurations, and underlay network configurations.

Uploads the VNFD,

service TOSCA
template, image
packages, and
software packages. Synchronizes the
Synchronizes the
uploaded files.
service TOSCA
template and
container images.

Synchronizes VM images.

Uploads the NSD.

Instantiates NSs
and VNFs.
Sets network and
deployment
parameters. Creates northbound external networks and subnets and automatically completes related
configurations on network devices or the CE1800V.

Creates VNF logical networks and subnets and automatically

completes related configurations on network devices and the CE1800V.

Requests for virtual

resources to create
VMs.

Forwards the request to the VIM.

Creates VMs and internal networks and ports of VNFs.

Completes network configurations after the

VMs are created.

Configures deployment parameters after the VMs are created.

Notifies
FusionStage to
create a network
stack.
Creates a network stack.
Notifies
FusionStage to
manage the VMs.

Orchestrates and schedules containers according to the TOSCA template.

Deploys service programs.

The VNF is
deployed.

Completes the subsequent VNF service configurations.

Note: The CE1800V is used only for host overlay networks.

A VNFD template describes the resource models, internal connections, and deployment models
required for VNF instantiation.
An NSD template describes the network service functions, network topologies, and external
connections of VNFs.
A TOSCA template describes the topology structure of a service application, services contained in
the application, service resources, and relationships and dependencies among the services.

51
 Telco Cloud

Container Deployment Solution

Container Overview

Both VMs and containers are virtualization technologies. Containers start up faster than VMs,
utilize resources more efficiently, and leverage lighter, higher-performance resource isolation
mechanisms.

App App App App

Bins/Libs Bins/Libs Bins/Libs Bins/Libs

App App
Guest OS Guest OS Guest OS+Docker Engine Bins/Libs
Bins/Libs

Host OS+Hypervisor Host OS+Hypervisor Host OS+Docker Engine

Server Server Server

VM VM-based container Bare-metal container

VM: The NFVI creates VMs, and the OSs of VMs are isolated from one another.
VM-based container: The container platform creates containers over VMs. Containers share the
guest OS and can be started quickly.
Bare-metal container: The container platform directly creates containers over the infrastructure,
resulting in higher performance, quicker startup, and greater resource utilization.

Container Resource Object Model

(VM-based containers FusionStage
as an example)

Project/Namespace Project/Namespace

Host Host
VM/Node VM/Node

Pod Pod Pod

Container Container Container

Huawei container management platform. It manages container life cycles and provides routine
FusionStage
O&M for containers.
FusionStage can create multiple projects, each with their own resource quota. In this way,
Project resources of different projects are isolated. A project is similar to a VPC at the NFVI layer. To unify
the resource models of FusionStage and NFVI, a project corresponds to a VPC in most cases.
Each project has its namespace. When FusionStage creates a project, K8s creates a namespace
Namespace
with the same name as the project. Resources are isolated logically by namespaces.
Each namespace is mapped to one or more hosts. The resources logically isolated by a namespace
Host
are the sum of resources provided by these hosts.
Each VM is managed by FusionStage as a node in the target namespace. A node carries and runs
VM containers.
Each host houses one or more VMs and these VMs/nodes share the host resources.
A pod is the smallest deployable unit in K8s. Resources are logically isolated among pods. Each
Pod
node contains one or more pods.
One or more containers thrive in a pod and share the pod resources. Microservices run on
Container
containers.

52
 Telco Cloud

Container Network Interconnection Model

(VM-based containers as an example)

Server/Host Server/Host

VM/Node VM/Node VM/Node

Pod Pod Pod Pod

Container Container Container Container Container

interface
mapped to
1 VM interface
mapped to
Logical
network Physical port

connected to
2

TOR Layer-2 switch

TOR
connected to
3

EOR EOR Layer-3 switch

1 Container interfaces are mapped to VM interfaces, and communicate with each other through
the VM network.
2 Container interfaces within the same VLAN use the internal Layer-2 switch network for intra-
server communication, and an external Layer-2 switch for inter-server communication.
3 Container interfaces in different VLANs communicate via a Layer-3 switch, no matter if
interfaces reside on the same or different servers.

Container Deployment Overview

(VM-based containers as an example)
1
VNF
VNFM
VM VM

Pod Pod
3
Container Container Container Container
FusionStage

Guest OS Guest OS

2
Host OS+Hypervisor FusionSphere
OpenStack
Compute, storage, and network

1 VNFM manages VNF life cycles. It deploys VNFs with uploaded VNFD files, software packages,
image packages, service templates, and service image packages.
2 FusionSphere OpenStack manages VM life cycles. It applies for VM resources described in
the VNFD and creates VMs.
3 FusionStage manages container life cycles. It creates containers on VMs based on TOSCA
service templates.

53
iMaster MAE-CN
Overview

Evolution of Cloud Core O&M Systems

The architecture of cloud core O&M systems has evolved from silo-like to convergent, and the
mechanism behind the O&M itself moved from auxiliary O&M to SDN/NFV cloud-based O&M.
Ultimately, O&M systems are expected to become an engine for autonomous driving networks,
achieving simplified O&M and enhancing O&M efficiency.
Autonomous driving
network engine
R20.1 or later

Cloud-based
SDN&NFV O&M
(R19.1)

Auxiliary O&M
R18.1 or earlier
iMaster MAE-CN
Network Network
optimization maintenance

mAOS CN NFVO
Network Service
Unified planning provisioning
Comprehensive,
orchestration &
flexible KPI
resource
report analysis
management
PRS KPI Network
NFVO
deployment
Unified
Comprehensive, orchestration &
flexible KPI resource
report analysis U2020-CN
management

Analysis Policy Execution

(big data) (management) (automation)
NBI/OpenAPI

CCE
Convergent Convergent
Unified data
Scenario- Enhanced management management
base
specific NFV O&M plane /control
configuration
NFV O&M
CSM VNF life cycle
management
Basic FCAPS
VNF life cycle management
U2000/M2000 management
/N2000

Basic FCAPS
management
for PNFs/VNFs

54
 Overview

Simplified Network Architecture

iMaster MAE converges subsystems such as U2020, VNFM LCM, NFVO, SmartTestKit, and
CCNFMA into an autonomous network driving engine. It can manage 2G/3G/4G/5G NEs/NFs in
the wireless and core network domains, including those developed on traditional and cloud-based
platforms.
MAE provides unified portals for engineering deployment and O&M to manage NBI, SBI, platform,
and service data, reducing the interconnections between management planes and saving system
resources.
MAE adopts a unified architecture and base of data. This enables the system to flexibly
orchestrate resources and streamline service management processes for various scenarios, such as
telecom cloud, slicing, and MEC O&M.
MAE converges autonomous management and control units with service NEs/NFs, and the
management and control units can be deployed closer to the edge of the network, achieving
cloud-edge collaboration, hierarchical autonomy, and real-time service control.

iMaster MAE-CN

Unified portal Unified NBI management

 Intent engine  Orchestration & MEAO  VNF LCM  Data analysis, decision-
making, and verification
 Network definition  NSSMF  FCAPS & centralized maintenance & optimization

Unified data
management
Unified resource management Unified alarm management Unified KPI management

Unified SBI management

U2020 mAOS NFVO NSSMF MEAO MEPM SmartTestKit CCNFMA

Autonomous management
and control unit
IMS
Service enabling/control Autonomous management
and control unit
LCM
Service enabling/control
CSP Edge
LCM
UPF MEC
COTS Infrastructure
resource agent

CSP
PCF UDM NRF
FusionSphere
/FusionStage

AMF SMF NSSF COTS

 Convergent: The EMS, VNF LCM, NFVO, and SmartTestKit & CCNFMA tools are converged into
one system, and functions such as slicing and MEC management are added, forming an
autonomous network driving engine.
 Unified: Unified engineering deployment and O&M portals are provided to manage northbound
and southbound interface, platform, and service data, reducing interconnections, resource
consumption, and expenditure.
 Flexible: One architecture is used as base. Services can be flexibly combined to adapt to various
service scenarios, such as slicing, telecom cloud, and MEC.
 Efficient: CD/CT automation and AIOps are enabled to ensure efficient delivery of functions and
services.
55
 Overview

Management Across Different Domains, Generations, Platforms, and Layers

Everything
Cross- IP-based Web & mobile
2G 3G 4G connected 5G
generation
management

IMS CS EPC Cloud IMS Cloud SDM Cloud EPC

Cross-domain
management
UNC UDG UPCF SPS UDM ...

Cross-platform
management

Traditional platform (PNF) Cloud platform (VNF)

 Cross-layer management: MAE supports cross-layer topology and alarm management. The unified
cross-layer topology centrally displays the relationships between components at the hardware layer,
virtualization layer, and VNF layer, which helps quickly identify NE/NF faults, if any. Cross-layer
alarm management enables MAE to display VNF and NFVI alarms in the same view. MAE can mask
correlative alarms and display only root alarms. VM and host locations can also be displayed.
 Cross-generation management: MAE can manage 2G, 3G, 4G, and 5G wireless and CN NEs/NFs.
 Cross-domain management: MAE can manage various cloud core NEs/NFs, including CS, IMS, PS,
and 5GC.
 Cross-platform management: MAE can manage both traditional platform NEs (PNFs) and cloud
platform NEs/NFs (VNFs).

Alarm/KPI Reporting (Convergent Deployment)

MAE
SNMP alarm

RESTful
SFTP

UNC UDG UPCF SPS UDM

NFVI FusionSphere
Virtual Virtual Virtual OpenStack OM
compute storage network
PNF
FusionSphere
SNMP
eSight
OpenStack
Server Server Third-
party SNMP/
RESTful
Network device hardware MongoDB

VNF Alarms/KPIs
VNF -> MAE: VNF alarms and KPIs are directly reported to MAE.
eSight Alarms/KPIs
eSight -> MAE: eSight alarms and KPIs are directly reported to MAE.
Hardware Alarms/KPIs
COTS hardware -> eSight -> MAE: Hardware alarms and KPIs are reported to eSight and then to MAE.
FusionSphere Alarms/KPIs
FusionSphere OpenStack -> FusionSphere OpenStack OM -> eSight -> MAE: FusionSphere alarms are
reported to eSight and then to MAE.
56
VNF LCM

5GC provides higher bandwidth and lower latency for subscribers to satisfy their service
requirements. Besides VMs, it also uses a container-based architecture to provide better network
experience.
VNF LCM allows users to upload VNFD files and software packages required for VNF deployment.
The VNF LCM automatically parses the VNFD files and deployment parameters, then interacts with
the VIM and FusionStage to create VMs and pods accordingly. In this way, VNF software can be
installed easily. The deployment progress is displayed during installation, and fault demarcation
and handling advice is provided if a step needs redoing, or a task fails.

VM-based VNF Deployment

OSS/BSS VNF LCM 1 User

VNF catalog
management
2
VNF life cycle FusionStage
EMS interconnection management interconnection
EMS VNFD
6
SFTP server VNF interconnection VIM interconnection
Image/
7 5 Software

4
NFVI VM

1 VNFD upload Users upload VNFD files and related software packages on VNF LCM.

2 VNF LCM creates a VNF deployment task.

3 VNF VNF LCM applies for resources from the VIM to create VMs required by VNFs.
instantiation

4 The VIM creates VMs.

VNF software After the VMs start up, VNFs download the software packages from the SFTP
5 installation server, install the VNF software, and notify VNF LCM of the completed installation.

6 EMS notification VNF LCM notifies the EMS of the completed VNF software installation.

EMS processing
7 The EMS configures the newly connected VNFs.
VNF configuration

57
 VNF LCM

Container-based VNF Deployment

OSS/BSS VNF LCM 1 User

VNF catalog
management
2
VNF life cycle FusionStage
EMS interconnection
management interconnection
EMS VNFD
7
SFTP server VNF interconnection VIM interconnection
Image/
8 6 Software
5
3

4
NFVI VM FusionStage

1 VNFD upload Users upload VNFD files and related software packages on VNF LCM.

2 VNF LCM starts a VNF deployment task.

3 VNF LCM applies for resources from the VIM to create VMs required
by VNFs.
VNF instantiation

4 The VIM creates VMs.

FusionStage manages the VMs created by the VIM and creates

5
corresponding pods.

After the pods start up, VNFs download the software packages from the
6
VNF software
SFTP server, install the VNF software, and notify VNF LCM of the
installation
completed installation.

7 EMS notification VNF LCM notifies the EMS of the completed VNF software installation.

8
EMS processing
The EMS configures the newly connected VNFs.
VNF configuration

VNF LCM also monitors VNF counters, adds or deletes VMs or pods, and uses a stack-based
method to scale VNFs, improving resource utilization.
VNF LCM provides the VNF self-healing management function, which enables VNFs to self-heal in
the case of faults. The system allows users to power on, power off, and live migrate VMs. If a VM
is faulty, users can reboot or rebuild the VM for quick restoration. If a pod is faulty, users can
rebuild the pod. VNF LCM also allows users to delete invalid VNF VMs to improve resource
utilization.

58
NFVO

Position of MAE-Orchestrator on the Network

As a subsystem of MAE, MAE-Orchestrator manages NFV network services. It orchestrates and

schedules NFV network services and resources, allows for E2E service provisioning, and implements
automatic network deployment and unified O&M.

OSS/BSS Os-Ma
NFV Orchestrator
(MAE-Orchestrator)

Or-Vnfm

EMS 1 EMS 2 EMS 3

Ve-Vnfm
VNF
Manager(s)
VNF 1 VNF 2 VNF 3

Or-Vi
Vn-Nf

NFVI Vi-Vnfm

Virtual Virtual Virtual

Compute Storage Network

Nf-Vi
Virtualised
Virtualization Layer
Infrastructure
Manager(s)

Vi-Ha

Computing Storage Network

Hardware Hardware NFV Management
Hardware
and Orchestration

Execution reference points Other reference points Main NFV reference points

59
 NFVO

Automated NS Life Cycle Management

In an NFV system, an NS is made up of VNFs and networks between the VNFs.

MAE-Orchestrator automatically manages the entire life cycle of NSs, including automatic NS
deployment and service rollout. It also provides the means for users to scale NSs in or out based on
their service requirements, which significantly reduces OPEX.

Automated NS life cycle management:

Deploy an NS in one click.

Edit NSDs for NS service 2

orchestration.

Automated NS
life cycle
management 3

Scale the NS.

Terminate the NS.

1 Users can edit NSDs to quickly orchestrate NSs, including VNF deployment, network setting,
and scaling.
2 NSs can be deployed with ease. The detailed process is as follows:
1. Users upload NSDs and import VNFDs, software packages, and image packages
required for VNF deployment on the MAE-Orchestrator client.
2. Users select the NSDs to be deployed and set deployment parameters.
3. MAE-Orchestrator parses NSDs, interacts with the VIM to create NSs, and interacts with
the VNFM to create VNFs. In this way, NSs are deployed easily.
4. Users configure VNFs on the EMS or VNF maintenance platform.
5. Services are brought online.

3 MAE-Orchestrator can scale NSs in or out as required.

Scale-out: Users select VNFs to add to an NS on the MAE-Orchestrator client.

Scale-in: Users select VNFs to delete from an NS on the MAE-Orchestrator client.

4 NSs can be deleted on the MAE-Orchestrator client when they are no longer required.

60
 NFVO

Unified Resource Management

Centralized planning and management of multi-DC resources: MAE-Orchestrator supports

unified planning and management of physical and virtual resources in multiple DCs.
Domain-based resource management: MAE-Orchestrator allows users to create organizations
based on operators' organization structure. Users can create tenants under an organization by
department or team. An organization owns its own resources. After an organization is created, the
organization administrator can create and manage DC resources. MAE-Orchestrator can allocate
and manage organization resources by tenant to isolate resources among tenants and achieve
domain-based resource management. Domain-based resource management enables O&M
personnel to focus on the resource utilization of the current NS and filter out unnecessary
information, achieving efficient O&M.

MAE-Orchestrator

DC 1 DC 2 … DC n
Physical resources

Virtual resources

Equipment room Region 1

AZ
Physical server
HA VDC
Storage device Host

VM VPC
Network device

Region 2

AZ

HA VDC

Host
VPC
VM
…

61
NFV Unified Cross-layer View

Introduction
The NFV unified cross-layer view feature provides a cross-layer topology and unified device panel,
helping O&M personnel quickly locate the root cause of NE faults.
Cross-layer topology: Displays the relationships between VNFs and VMs, hosts, host groups, and
cloud services in a vertical manner. This helps O&M personnel understand relationships between
components and locate faults.
Device panel: Displays the status of servers and VMs on the servers, helping O&M personnel
identify the impact scope of a fault.
After interconnection with eSight, MAE obtains cross-layer topology data from eSight to obtain
and display relationships between NEs/NFs and VMs, hosts, host groups, and cloud services, as well
as between VMs, hosts, and hosts. The following figure shows the path used to report data.

RESTful
MAE-CN

NE

CloudIMS CloudDB CloudSBC

UNC UDG UPCF

SPS UDM ...

NFVI

Virtual Virtual Virtual

compute storage network

Network eSight
Server Server
device

Third-party hardware

NFVI-> eSight

eSight obtains details about virtual and hardware resources from the NFVI.

eSight -> MAE-CN

1. MAE obtains the relationships between VMs, hosts, and servers from eSight.
2. MAE obtains details about virtual and hardware resources from eSight.

62
Network Slice Management

Introduction
The 5G network slice management function is built on the SBA. This function is provided by the
NSMF and NSSMF to implement E2E network slice collaboration and full life cycle management
across the access network, the transport network, and the core network. The NSSMF is responsible
for managing and orchestrating slice subnet instances.
With this function, operators can:
 Design the NSST, based on which the system creates slice subnet instances.
 Set the SLA parameters of a slice subnet, such as the uplink and downlink rates, latency, and
maximum number of subscribers.
 Define the NSD file.
This function enables users to deploy services on demand and to scale slice instances in or out
when services change, improving resource efficiency. When a slice instance is no longer required,
the slice instance is terminated to promptly release and reclaim resources. The NSSMF supports
slice subnet alarm reporting and SLA metric monitoring, helping users learn the slice running
status, prevent network accidents, and forecast the network running status.

Purchases
slices.
BSS/CSMF
Tenant

OSS/NSMF

iMaster MAE-CN (CN NSSMF) AN NSSMF TN NSSMF

RAN TN
Slice Slice Service SLA
design deployment activation assurance

5GC
VR/AR
SMF PCF …

Network slice 1 UPF

IoV
Network slice 2

Smart campus
Network slice 3

NFVI

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

64
 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

65
 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
OpenStack; but does not support O&M for
COTS hardware.
Provides enhanced O&M services in the VIM
and is the unified O&M center for the NFVI
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
infrastructure monitoring data from eSight.
Provides O&M for its managed VNFs,
obtains NFVI monitoring data from eSight
and the VNFM, and provides correlation
analysis between the VNFs and NFVI
resources.

66
 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
OpenStack; but does not support O&M for
COTS hardware.
Provides enhanced O&M services in the VIM
and is the unified O&M center for the NFVI
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.

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

68
 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

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

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

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

72
 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

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

74
 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 SMSF

NRF NSSF 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

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