Here management is more accurate to be expressed as "monitoring" and "control" because it includes the monitoring

of system status and the control of system command issuing.

● Monitoring: Monitor system alarms, traffic measurement counters, system logs, tracing results, and other service
flow information.
● Control: Configure the commands issued by devices, add and disable features, and enable services.

02 Implementation of Cloud
Architecture Management
oss
Service
Fault Inventory Provision Performance Diagnose

Service Management Layer

解决方案

XML/CORBA/SNMP/FTP/TL1/112 Test

Network Management Layer

Cloud Insights: NFV Theory and Practice U2000/U2020 Unified

Network Management System
+
NE Management Layer

01 Management Under a Layered

Architecture – MANO and Others
Management is an important and the most
NE Layer
long-lasting part in the lifecycle of equip- Access Network Transport Network IP Network
ment and services. One motivation of the FTTx/D-CCAP/ MSTP/WDM/ PTN/ATN/Router/
DSLAM/MSAN RTN/Marine Switch/BRAS
cloud architecture is that carriers require
software and hardware decoupling and
avoid vendor lock-in of network equipment
Management of traditional communication networks includes three layers, NE (equipment) layer, NE management
supply. Another motivation is that carriers
layer, and service management layer.
require low-cost O&M and fast service
deployment to reduce the time-to-market The NE management layer is called equipment management system (EMS). In IMS network, the U2000/U2020 is the
(TTM) of new services. The low-cost O&M EMS. The EMS realizes the monitoring function by providing network monitoring information such as alarms, perfor-
and fast service deployment are realized mance statistics, inventory, and topologies. The EMS also performs the control function by supporting service provi-
through the cloud architecture and cloud sioning, test, and diagnosis. It can be flexibly integrated into different operations support systems (OSSs) through the
management system. northbound interface to meet the integration requirements of different OSSs. The EMS is closely related to equipment
and is provided by equipment vendors.

P1 P2
 The upper layer is the OSS and business support system (BSS). The OSS manages wider-range networks and intercon-
nects with the EMS through clearly defined northbound interfaces (Common Object Request Broker Architecture
(CORBA), database, and File Transfer Protocol (FTP)), implementing a wider-range monitoring of network status,
alarms, and performance statistics. The OSS is not coupled with the equipment and is procured by carriers separately.
03 Implementation of Cloud
Architecture Management
In the NFV architecture, hardware is decoupled from software. The hardware and Cloud OS for virtualization compose
the network functions virtualization infrastructure (NFVI),providing VNFs with infrastructure resources. The NFVI
provides computing, network, and storage capabilities, allowing for Cloud-OS-based VM provisioning.
Virtualized network functions are established on the NFVI. In the NFV area, we do not have a separate platform layer,
but directly name this part as VNFs. VNFs run on the VMs, providing the network functions of IMS and SBC.
The NFV management and orchestration (MANO) is on the right side of the NFV architecture and provides unified man-
agement and orchestration functions for VNFs and the NFVI.
Excerpted from ETSI GS NFV 002 V1.2.1 Network Functions Virtualisation (NFV)
Although network functions are virtualized, the EMS is still deployed above NEs in actual project deployment. The
EMS manages NEs. In the PS network, it is the virtualized U2000/U2020.
P3
In the new standards of European Telecommunications Standards Institute (ETSI), the EMS is changed to EM, as
shown in the following figure.
Carriers' OSS/BSS is on top of the EMS. The relationship between the OSS/BSS and NEs is the same as that
between the traditional OSS/BSS and NEs.
Excerpted from ETSI GS NFV 002 V1.2.1 Network Functions Virtualisation (NFV)
The MANO is constituted by the virtualized infrastructure manager(s) (VIMs), VNF manager(s) (VNFMs), and the NFV
orchestrator (NFVO).
● The VIM is the management system of the NFVI, and manages commercial off-the-shelf hardware (COTS) and
resources.
● The VNFM manages the lifecycle of service NEs, providing automation capabilities such as deployment, query,
scaling, and logout.
● The NFVO is responsible for the management and orchestration of service applications, virtualization layer, and
NFVI.
Why the MANO is divided into the three parts? It is because of the reality and pursuit of the NFV architecture.
Reality:
Insensitive cross-layer fault location: Hardware is separated from software. Network function software runs on VMs.
When the hardware is faulty, the VNF and VM cannot locate the CPU or memory where the fault occurs. The VNF and
VM can only detect which resources are unavailable after virtualization.
P4
 Diversified NFVI under a layered architecture: Under the layered architecture, the NFVI and VNFs may be provided by Take the VoLTE service provisioning as an example. The following operations are required:
different vendors. The mapping between the NFVI resources and VNF service functions is varies with design and plan- ● On eNodeBs, functions are added and voice scheduling policies are configured.
ning. The VIM that monitors and manages the NFVI needs to be closely adapted to hardware and Cloud OS. ● In the PS network, the access point name (APN) configuration of the information management system (IMS) is added.
For example, a network interface card (NIC) fault on physical hardware causes link interruption of the SBC. The VNF can Addresses are added. Links and routes to the IMS are configured. Quality of service (QoS) policies are added. Related
only detect the link failure of the interface while the NFVI can only detect an NIC fault alarm. Only service alarms can be functions are activated.
observed on the VNF and the root cause cannot be determined. Only hardware faults can be observed on the NFVI and ● In the IMS domain, NEs are added and configured.
the impact cannot be determined. ● On the home subscriber server (HSS), subscription data is added for users.
The VIM is closely connected with hardware and Cloud OS, obtaining hardware information and reporting the ● The policy and charging rules function (PCRF) is connected to the IMS over the Rx interface, and Policy and Charging
information to the VNFM. The mapping relationships among hardware, VMs, and VNFs are saved on the VNFM. Control (PCC) policies are configured.
The VM and VNF information is added to the hardware failure before the failure is reported to the EM. At this A series of operations including creation, capacity expansion and configuration need to be performed on different NEs in
time, the EM has obtained the service alarm information and the corresponding VNF information from the VNF. different fields. The service rollout takes at least one year.
Combining the information from the VNF and MANO, the EM can associate the alarms between hardware to The automatic service orchestration expected by carriers means that the preceding operations are saved as a
the service and display the association on the alarm console. predefined template on the MANO. When enabling VoLTE services, carriers only need to issue commands. The MANO
coordinates the VNFM/VIM to perform end-to-end service configuration, creating new NEs and adding related configura-
tions, to realize the automatic service rollout.
U2000/U2020 EM VNF Manager The enabling of VoLTE is a complicated scenario. A simpler scenario is to define a rule. For example, when the MME
load exceeds 85% for 10 consecutive hours, an MME is added automatically to share the load. It is also a scenario of
service orchestration.
It is implemented by the VNF orchestrator at the top of the MANO.
VNF 1 VNF 2 VNF 3 Therefore, the three parts of the MANO are correspondent with the NFVI, VNF, and OSS/BSS layers, managing
resources, NEs, and services respectively.
CloudSBC CloudIMS CloudSPS vUSN
VNF Orchestrator
VM 1
VNF
VM 1 VM 2 VM 3 OSS/BSS OSS/BSS
Service
Implementation

VNF Manager
U2000/U2020 EM
VIM
Cloud OS Virtualized
Hypervisor Hypervisor Hypervisor
Infrastructure VNF 1 VNF 2 VNF 3
Manager
CloudSBC CloudIMS CloudSPS

VNF
VM 1 VM 2 VM 3
Function NE

VIM
Pursuit: Cloud OS Cloud OS

Under the traditional architecture, enabling an NE needs planning and design, installation and commissioning,
Hypervisor Hypervisor Hypervisor
test and acceptance, and cutover. The entire cycle can be years. To achieve short TTM under the cloud architec-
NFVI
ture, carriers expect to deploy NEs as fast as installing software. In addition, carriers and equipment vendors
have a higher pursuit: automatic service orchestration.
Hardware
Resource

P5 P6
 04
The following figure is excerpted from 06_Huawei_CloudOpera_CSM_V200R016C10 training slides v1.1, which
Implementation and Product clearly illustrates the functions of the old and new network management modules.
Name of Huawei MANO Ecosystem

At present, the components of Huawei MANO are named by CloudOpera. The VNFM is named as CloudOpera
REST

NFVO:

CSM/U2020. The orchestrator is named as CloudOpera Orchestration. The two parts were respectively named as vCMM MANO(Resource/Service Orchestration) The NFVO is responsible for the network
BSS/OSS: service lifecycle management, including
Big Data Analytics network service on-boarding, scale-in,
The existing BSS and OSS on BSS/OSS (Daas)
and vCMO. The two names are no longer used now.
REST scale-out, and termination. Resource
the live network can be used NFV Orchestrator scheduling across data centers is provided.
to manage both traditional (Huawei CloudOpera Orchestrator)
and cloudified NEs.
VNFM:
The VNFM is responsible for the VNF
The following figure shows the functions of the three parts.
REST REST
lifecycle management, including
EMS: on-boarding, scale-in, scale-out, and
SNMP/FTP termination.
The EMS is responsible for
fault monitoring and
demarcation across the REST VNF Manager VNF Manager
EMS
SaaS and NFVI layers. (Huawei CloudOpera CSM) (Other Vendors)
VNF Orchestrator The capabilities of the VIM:
existing EMS are inherited Management system of the NFVI ，
CloudOpera Coordinated enabling/modification/
for the management of both for example, Vmware, FusionManager

OSS/BSS OSS/BSS traditional and cloudified NEs.

VIM VIM
Orchestration removal of services on the
Service Life Cycle entire network Whole-Network Deployment and Scale-in/out
Network
Management MML/SOAP
Big Data

Legacy Scale-in/out Scale in/out

TAS

VNF Manager VNF VNF VNF VNF VNF VNF IP Optical

controller

U2000/U2020 EM I/S-CSCF/MRFC MRFP

EPC IMS XGSN LTE VDSL CDN Controller and others

CloudOpera CSM Distributed DC（Central、Region、Mini）

U2020 Connecting the VNF orchestrator

with VIM MME IP+Optical IMS
RRU Operator 3 rd party
NE Life Cycle I-SBC I-SBC Cloud SGSN Controller PCRF
VNF 1 VNF 2 VNF 3 Management
RRU
CPRI
GSM UMTS LTE
Scale in/out
Service Apps

RRU
Performing operations on function CloudBB DC service cloud

CloudSBC CloudIMS CloudSPS NEs Creating/Changing/Deleting NEs ONT

DSL PON
Eth
Switch
Eth
Switch IP RAN EPC
SBC
DPI Router Router
MxU Controller Controller GGSN FW MAN or
ADSL VDSL ... BRAS WDM backbone WDM
CDN
VNF ONT
CloudDSL/OLT
network

VM 1 VM 2
CloudEdge
VM 3

05
Controlling the relationships among
hardware, VMs, and VNFs

Examples of Life Cycle Management

Cloud OS Cloud OS VIM The MANO is responsible for NFV lifecycle management. The definition in the latest ETSI white paper is as follows:
Virtualized
Infrastructure The capability enables the creation, maintenance and termination of VNFs. This set of functions allow managing the association of the virtualised
Hypervisor Hypervisor Hypervisor
Manager
resources throughout the lifecycle of a VNF instance, and the maintenance of such association according to VNFD and runtime information.
Connecting to the Cloud OS
NFVI Resource Life Observing hardware status
Cycle Management
In the present release, VNF lifecycle management functions specified are the creation/deletion of VNF instance identifier, instantiation, scaling,
scaling to VNF level, change of VNF deployment flavour, healing, modification and querying of VNF information, termination of VNF instances.

In addition, in the present release, the provision of runtime notifications related to the state of a VNF instance as a result of changes made during
lifecycle procedures is also supported.
The VIM is closely related to hardware and the Cloud OS, and is integrated in the Cloud OS and provided by NFVI
vendors. Finally, the present release supports the VNF lifecycle operation granting, which allows the VNFM to request NFVO the permission to perform
a lifecycle management action and its associated resource management operations. Such a capability is only supported at the Or-Vnfm reference
point.

In short, the life cycle management (LCM) is the capability that enables the creation, maintenance, and termination of
VNFs provided by the MANO. The LCM includes instantiation, scaling, and VNF termination. The corresponding opera-
tions on traditional telecommunication equipment are powering-on, adding and removing boards, and powering-off.
Different from traditional equipment, under the NFV architecture, the operation object of LCM is not an actual hardware
device, but a combination of various virtual resources, which is the VNF constituted by VMs.

P7 P8
 Take the instantiation as an example, the specific steps are as follows: Flavor: the specification. That is, the number of CPUs of the VM, memory size,
and disk size
Image: the image file used
Volume: the volume of the disk array

VIMA cinder glance neutron nova

createFlavor()

flavorId()

createImage()

imageId()

1 A user uploads the VNFD file, image file of the guest OS, and VNF software package.
createPrivateVolume()
After parsing the VNFD, the VNFM creates the deployment task according to the description in the VNFD and
2
requests virtual resources from the VIM.
volumeId()
The VIM creates VMs according to the resource requirements sent from the VNFM (The VNFM obtains resource
3 specifications from the description in the VNFD. Then, the MANO combines different VMs into a VNF. That is, createNetwork()
the VNFM assigns resources on a per VM basis.

In the process, when receiving commands from the MANO to create VMs, the VIM will check whether the networks()
resource pool of NFVI has sufficient virtual resources according to the virtual resource elements defined by the
OpenStack. Firstly, the main control module of the OpenStack Nova is checked to determine the VM createVM(flovorId+imageId+volumeId+networks)
specification and computing resources, that is the number of CPUs, memory, and disk size. Then the VIM will
4 check whether the image, block storage (volume), and network resources managed respectively by Glance,
Cinder, and Neutron are sufficient. If the resources in all the modules are sufficient and properly allocated, the
VIM will require Nova to create a VM. After receiving and confirming the command, Nova invokes the Hypervisor
driver to create a VM through corresponding Hypervisor (In the FusionSphere solution, the KVM is used). The
Similar to instantiation, other operations defined in the entire VNF lifecycle are constituted by the following standard
VIM can only perceive the VM level and but not VNFs. It is the VNFM that actually perceives the VNFs.
sub-actions:
● The MANO parses the VNFD (or receives commands directly).
The VNF is created. At this time, the VNF is constituted by empty VMs. There is nothing on them except the
guest OS, Linux (like blank boards with no software installed). Therefore, the MANO needs to download ● The corresponding VIM implements operations on the NFVI resources.
5 ● The NFVI schedules resources.
corresponding software packages from the SFTP server and install service software according to VM types after
the VMs are started. ● A VM is created or terminated.
● The VNF status changes.
After the software installation, the service software is started to complete the instantiation (Just like the green
6 ● The MANO notifies the EMS.
indicators of all boards are on). Then the MANO notifies the EMS that the instantiation of the VNF is completed.
From the preceding procedures, it can be concluded that under the NFV architecture, the MANO is closely related to the
7 The EMS configures the newly created NE. traditional EMS/NMS. The MANO is responsible for virtual resources and the LCM of service flow. When the status of
operation objects (VNF/Network Service) changes, the MANO notifies the traditional EMS/NMS. The EMS/NMS takes
over management of upper-layer services.

P9 P10