01 Legacy NE Structure

The processing boards (processes) of traditional NEs

process user messages according to the user status.
For example, Link and
address
1. When a bearer is being set up for a UE, the system
queries the existing context information about the user
and then decides whether to allow the procedure and
which QoS should be assigned.
2. When forwarding user-plane data, the system
determines how to encapsulate the data, the header
addresses for the next encapsulation, and the tunnel
Status Status Status Status
endpoint identifier (TEID) according to the context board
解决方案
information.

The user contexts indicate the user status. They are

saved on the board where the processing unit is
located and are maintained by the processing unit.

Cloud Insights: NFV Theory and Practice

Status Status Status Status
board
On a traditional ATCA platform, the user status has a
binding relationship with the processing unit.

02
A network function that is virtualized
using the NFV is referred to as a
virtualized network function (VNF). Cloud Architecture Requirements
In the NFV architecture, NEs must support elasticity, scaling, and CloudIMS/CloudEPC
no single point of failure. If the status data (contexts) of users is
A VNF is equivalent to a traditional
stored also on compute nodes, the following will happen:
NE, such as the IMS, SBC. In the
1.Before deleting a compute node, the user contexts on the node
cloud architecture, a traditional NE
must be transferred to other nodes to prevent service loss.
is no longer a software/hardware
2.When a new compute node is added, existing user contexts
coupled product. Instead, they are
must be transferred to this new node for it to handle online users.
software installed on the universal
hardware at the NFVI layer. In this
way, the traditional NEs are To meet the NFV requirements, the following principles must
represented as applications, whose be adopted in system design:
network functions are completed ● Stateless front end
through software logic. ● Horizontal extension
● No single point of failure

P1 P2
 The following takes the CloudUSN as an example to discuss about the RUs required by each VNFC.
● VNRS_VNFC and CSLB_VNFC: Forwarding RUs are required because these VNFCs are responsible for route
management and distribution. The forwarding RUs are deployed on the IPU VMs.
● USN_VNFC, UDR_VNFC, and FAC_VNFC: Service processing (similar to computing) RUs are required because
05 VNF Scaling
these VNFCs are responsible for service processing. The service processing RUs are deployed on the SPU VMs.
VNF scaling refers to the increase or decrease of VNFC capabilities, which are indicated by the number of RUs. VNF
● CSDB_VNFC: Storage RUs are required because this VNFC is responsible for database-related services.
scaling is achieved through the addition and deletion of VMs where the RUs are located.
The storage RUs are deployed on the SDU VMs.

For example, to increase the service processing capabilities of the CloudUSN, more SPU VMs must be added to
increase the number of RUs for service processing.
CloudUSN

CloudUSN

In a high-capacity CloudUSN, the RU resources for the USN_VNFC are provided by multiple SPU VMs. The number of
VMs directly affects the CloudUSN capacity.

Increasing the VNF capacity by adding VMs is called scale-out, whereas decreasing the VNF capacity by deleting VMs
is called scale-in. The capability of a VM can be increased by adding more hardware resources, which is known as
scale-up. Decreasing the VM capacity by removing hardware resources is known as scale-down.

P7 P8
 The VMs are deployed on different hardware blades, thereby implementing device distribution. This is how the VNF
CloudUSN
gains the cloudified characteristics.
VNRS _VNFC VNRS

CloudUSN
CSLB_VNFC CSLB

SPU_VM
VNRS_VNFC VNRS

SPU_VM
USN_VNFC CSLB_VNFC CSLB

UDR_VNFC
SPU_VM
NLS
SPU_VM SPU_VM
FAC_VNFC

CSDB _VNFC CSDB

Up
Down
Scale SPU_VM SPU_VM
USN_VNFC
CloudUSN CloudUSN
VNRS _VNFC VNRS VNRS _VNFC VNRS UDR_VNFC
CSLB_VNFC CSLB CSLB_VNFC CSLB

SPU_VM SPU_VM SPU_VM

SPU_VM SPU_VM
Out FAC_VNFC

SPU_VM SPU_VM SPU_VM

USN_VNFC USN_VNFC
UDR_VNFC UDR_VNFC

SPU_VM
In SPU_VM SPU_VM CSDB_VNFC CSDB
FAC_VNFC FAC_VNFC

CSDB _VNFC CSDB CSDB _VNFC CSDB

The VNF-related concepts mentioned in this chapter may have renamed during the architecture development. The
following figure shows the current structure of the CloudUSN VNF, which is subject to changes in the future.

P9 P10
 In the traditional architecture, an SPU queries the user status information by itself before processing a user signaling
With the preceding principles, the user status information is saved on separated storage nodes (as database) instead.
message. In the NFV architecture, the SPU obtains the user status information from the database and then processes
In this way, the service processing units (SPUs) need only to process signaling and no longer save user status
the message. The following figure shows the details.
information. When processing user signaling messages, an SPU obtains the user status information from the
database and then performs appropriate processing on the user according to its status.
Traditional NFV
architecture architecture
As the equivalent of an NE, a VNF consists of multiple VNF components (VNFCs), as shown in the following figure.
Link and
address CSLB

MM
Traditional NFV
architecture architecture
Service processingVNFC
Link and
MM MM
address CSLB
Status Status Status Status
board
MM SM SM

Service processingVNFC
SM
MM MM MM MM

Status Status Status Status

board Status
Status

SM SM SM SM
Status Status Status Status
Status
board CSDB
Status

SM
CSDB

Status Status Status Status

● The Cloud Session Database VNFC (CSDB_VNFC) is responsible for user status information storage.

Status Status Status Status ● VNFCs that functions as SPUs have varying name according to the NE functions they need to perform.
Status Status Status Status
board
● The Cloud Session Load Balancer VNFC (CSLB_VNFC) is located at the front end of the SPUs. The CSLB_VNFC is
responsible for service packet distribution and user-plane message load balancing.
● In the front end of the CSLB_VNFC, there is a Virtualized Network Routing Service VNFC (VNRS_VNFC) responsible
for routing management and packet forwarding.

Such architecture ensures proper service handling when an SPU is faulty. After service messages are distributed to other
SPUs in normal status by the CSLB_VNFC, the new SPUs obtain the user status information from the CSDB_VNFC and
then handle the service messages. The architecture also enables newly added SPUs to handle service messages in the
initial or middle state after obtaining the related user status information from the CSDB_VNFC.

P3 P4
 03 VNFCs for a VNF
This section takes the vUSN as an example. A vUSN typically consists of the VNRS_VNFC, CSLB_VNFC,
04 Relationship Between VNFCs and VMs
As mentioned previously, a VNF, equivalent to a traditional NE, consists of multiple VNFCs. Service data flows between
CSDB_VNFC, USN_VNFC, UDR_VNFC, and FAC_VNFC. The USN_VNFC, UDR_VNFC, and FAC_VNFC are service
the VNFCs to implement the mobile data core network functions.
VNFCs. The USN_VNFC performs the service processing functions of a traditional USN. The UDR_VNFC reports
records and is the combination of the traditional CHR and UDN. The FAC_VNFC collects information and analyzes faults
and is similar to an embedded FMA. In the virtualization architecture, hardware resources are divided into VMs for the service layer to use. This means that
the VNFCs obtain resources for service handling from the underlying VMs.
Each VNFC contains a Virtualized Network Function Platform (VNFP). The VNFP is responsible for virtual device
management within an NE and resource allocation and deployment for VNFCs. The VNFP also interacts with the
Management and Orchestration (MANO) for VM resource control. A VM consists of one or more resource units (RUs), which provide services to the various VNFCs. An RU is equivalent
to a group of processes in the traditional architecture.
The following figure shows the components in the CloudUSN VNF.

There are four types of VMs: OMU, IPU, SPU, and SDU.

VM Type Description

Functions as the VNF OM center and provides OAM basic functions including the
OMU southbound interface, configurations, alarms, counters, logs, and access
authentication.

Provides connections with external IP network, virtual network switching capability,

IPU
and load balance function between the SPU VMs.

SPU Provides service functions defined in 3GPP and non-3GPP specifications.

Provides distributed context data storage and access function. The SPU performs
SDU computing processing, and the SDU stores all status data for high reliability
assurance in cloudified scenarios.

The following figure shows the components in the CloudUGW VNF.

OM-related RUs are mandatory in each VNFC. Other additional RUs are determined by the process functions of the
VNFC.

Provides CloudUGW service functions.

P5 P6