NFV - Introduction

NFV Introduction
© Nex-G Exuberant Solutions Pvt. Ltd.

TRAINING SESSION AGENDA
• NFV Introduction
• NFV Architecture
© Nex-G Exuberant Solutions Pvt. Ltd. 2

NFV INTRODUCTION
Service provision within the telecommunications industry has traditionally been based
on network operators deploying physical proprietary devices and equipment for each
function that is part of a given service.

NFV INTRODUCTION
In addition, service components have strict chaining and/or ordering that must be
reflected in the network topology and in the localization of service elements.
These, coupled with requirements for high quality, stability and stringent protocol
adherence, have led to long product cycles, very low service agility and heavy
dependence on specialized hardware.

NFV INTRODUCTION
However, the requirements by users for more diverse and new (short-lived) services
with high data rates continue to increase.
Continuous Investment
Therefore, Telecommunication Service Providers (TSPs) must correspondingly and

continuously purchase, store and operate new physical equipment.
This does not only require high and rapidly changing skills for technicians operating and
managing this equipment, but also requires dense deployments of network equipment
such as base stations.
All these lead to high CAPEX and OPEX for TSPs

NFV INTRODUCTION
Even with these high customer demands, the resulting increase in capital and
operational costs cannot be translated in higher subscription fees, since TSPs have
learned that due to the high competition, both among themselves and from services
being provided over-the-top on their data channels, increasing prices only leads to
customer churn.
Therefore, TSPs have been forced to find ways of building more dynamic and service-
aware networks with the objective of reducing product cycles, operating & capital
expenses and improving service agility.
Network Function Virtualization (NFV) has been proposed as a way to address these
challenges by leveraging virtualization technology to offer a new way to design, deploy
and manage networking services.

NFV INTRODUCTION
The main idea of NFV is the decoupling of physical network equipment from the
functions that run on them.
This means that a network function - such as a firewall - can be dispatched to a TSP as
an instance of plain software.
This allows for the consolidation of many network equipment types onto high volume
servers, switches and storage, which could be located in data centers, distributed
network nodes and at end user premises.

NFV INTRODUCTION
This way, a given service can be decomposed into a set of Virtual

Network Functions (VNFs), which could then be implemented in software
running on one or more industry standard physical servers.
vEPG – vEvolved Packet Gateway - Evolved Packet Gateway (EPG),

together with Serving GPRS Support Node—Mobility Management Entity
(SGSN-MME), is a critical component of the Evolved Packet Core. vEPG
providers end-to-end solution for rapid deployment of highly scalable and
reliable Long Term Evolution (LTE) networks. Service providers use the
vEPG as a gateway between their mobile packet-core network and other
packet-data networks, such as the Internet, corporate intranets, and
private data networks.
vMPS – vMultiServer Proxy - Multiservice Proxy (MSP) is a multi-

purpose, multi-technology network node that provides service control and
enables policy control while representing an integration point for value-
added services. It allows operators to differentiate user experiences,
control costs, and monetize data traffic, and it can be run as a VNF on the
NFVi.

NFV INTRODUCTION
vWCG - vWeb Communication Gateway – It translates between telecom and Internet

protocols. It exposes communication APIs in an Internet-friendly way, making it easy to add
communication services to Internet-based applications. The WCG uses well known web
technologies like HTTP and WebRTC to significantly reduce time-to-market for new
combinational services that can be used on practically any device.
It provides the tools to create an ecosystem of partners who create new services that may
include contextual based communication, such as in the medical or transportation industry
where real time communications are combined with access to various data and services.
vWMG - vWi-Fi Mobility Gateway is a high-performance, versatile software product that

enables Evolved Packet Core services in untrusted Wi-Fi access, i.e., residential Wi-Fi. Wi-
Fi Mobility Gateway can be used for session continuity when moving from LTE to untrusted
Wi-Fi and vice versa. It ensures the best quality of experience for the mobile subscriber.
The Wi-Fi Mobility Gateway also supports trusted Wi-Fi access network integration
(TWAG)

NFV INTRODUCTION
vPCRF - vPolicy and Charging Rules Function (PCRF) - It provides the ability to
authorize and offer personalized services increasing service usage and making stronger
customer relationship as a result of a better usability. cPCRF is key to secure the network
behavior when users access data services, such as, authorizing the services, assigning the
QoS of the data-session and the charging that shall be applied; and performs a business
critical role for monetization and differentiation of operator’s mobile and converged
broadband commercial packages.
vDSC – vDiameter Signaling Controller - Diameter signaling is used for Policy Control,
Subscriber Registration, Charging & Roaming Procedures in EPC and IMS. Diameter
Signaling Controller (DSC) is the key network component to secure and centralize Diameter
communication. DSC is a product that supports standard IETF/3GPP Diameter
functionalities.
vIMS - vIP Multimedia Subsystem (IMS) is a core network solution that delivers rich real-
time communication services for both consumer and business users over any access
network and for any device types, including smartphones, tablets, wearables, laptops and
fixed phones. Examples of communication services are HD voice (VoLTE), Wi-Fi calling,
enriched messaging, enriched calling with pre-call info, video calling, HD video
conferencing and web communication.
NFV INTRODUCTION
vMME – vMobility Management Entity helps operator to scale its network capability,
flexibility and manageability. With the virtual MME, the operator's network can be adjusted
according to capacity needs. A flexible and manageable network means that software
upgrade and expansions can be rolled out quickly. This enables operaotrs to launch new
services faster and more efficiently, with shorter lead times and lower capex and opex.
vUDC - vUser Data Consolidation - UDC solution eliminates the complexity of managing
subscription by consolidating subscriber information from the different network silos into one
common repository, creating a Unified Profile. This allows for a simpler and more scalable
network topology, more efficiency on managing the network database resources and it also
gives more flexibility to introduce new services.

NFV INTRODUCTION

NFV INTRODUCTION
vSBG - vSession Border Gateway. SBG integrated with Session Border Controller is a
product for virtualized communication networks, guarantees security and interoperability on
the border between IMS and other networks, both for signaling and media. The Session
Border Controller provides one commercial offering for Voice over LTE (VoLTE), Voice over
WiFI (VoWiFi), Video over LTE (ViLTE), Richs Communication Service (RCS), Interconnect,
Fixed VoIP and Web communication solutions.
vEMA – vEricsson Multi Activation is integrated with Service Activation platform for
service provisioning on IMS.
vENM - vEricsson Network Manager, the next-generation unified network management

system

NFV INTRODUCTION
vEMM – vEricsson Multi Mediation - Ericsson Multi Mediation is a converged mediation

which resides at the boundary between the network and the business support systems to
improve billing accuracy and granularity, support new competitive services, deliver revenue
assurance for BSS systems and prepare data for analytics, IoT or other OSS systems
thereby acting as a key data monetization enabler.
vDNS – vDomain Name Service – It translates domain names to IP addresses so

browsers can load Internet resources.
vAAA - vAuthentication, Authorization and Accounting (AAA) of subscriber sessions is

managed through the AAA server
vEPC - Virtual Evolved Packet Core (vEPC) is a framework for virtualizing the functions
required to converge voice and data on 4G Long-Term Evolution (LTE) networks. vEPC
moves the core network's individual components that traditionally run on dedicated
hardware to software that operates on low-cost commercial off-the-shelf (COTS) servers.

NFV INTRODUCTION
The VNFs may then be relocated and instantiated at different network locations (e.g.,
aimed at introduction of a service targeting customers in a given geographical location)
without necessarily requiring the purchase and installation of new hardware.
NFV promises TSPs with more flexibility to further open up their network capabilities and
services to users and other services, and the ability to deploy or support new network
services faster and cheaper so as to realize better service agility.
To achieve these benefits, NFV paves the way to a number of differences in the way
network service provisioning is realized in comparison to current practice.

NFV INTRODUCTION
In summary, these differences are as follows:-
• Decoupling Software From Hardware - As the network element is no longer a

composition of integrated hardware and software entities, the evolution of both are
independent of each other.
This allows separate development timelines and maintenance for software and
hardware.

NFV INTRODUCTION

NFV INTRODUCTION
• Flexible Network Function Deployment - The detachment of software from

hardware helps reassign and share the infrastructure resources, thus together,
hardware and software, can perform different functions at various times.
This helps network operators deploy new network services faster over the same
physical platform.
Therefore, components can be instantiated at any NFV-enabled device in the

network and their connections can be set up in a flexible way.
• Dynamic Scaling - The decoupling of the functionality of the network function into
instantiable software components provides greater flexibility to scale the actual VNF
performance in a more dynamic way and with finer granularity, for instance,
according to the actual traffic for which the network operator needs to provision
capacity.

NFV INTRODUCTION
The general concept of decoupling NFs from dedicated hardware does not necessarily
require virtualization of resources.
This means that TSPs could still purchase or develop software (NFs) and run it on
physical machines.
The difference is that these NFs would have to be able to run on commodity servers.
However, the gains (such as flexibility, dynamic resource scaling, energy efficiency)
anticipated from running these functions on virtualized resources are very strong selling
points of NFV.
Needless to mention, it is also possible to have hybrid scenarios where functions

running on virtualized resources co-exist with those running on physical resources.
Such hybrid scenarios may be important in the transition towards NFV.

NFV INTRODUCTION
History of Network Function Virtualization
The concept and collaborative work on NFV was born in October 2012 when a number
of the world’s leading TSPs jointly authored a white paper calling for industrial and
research action.
In November 2012 seven of these operators (AT&T, BT, Deutsche Telekom, Orange,
Telecom Italia, Telefonica and Verizon) selected the European Telecommunications
Standards Institute (ETSI) to be the home of the Industry Specification Group for NFV
(ETSI ISG NFV).
ETSI is currently working on Release 3 Specifications.
Specifications:-
http://www.etsi.org/technologies-clusters/technologies/nfv

NFV INTRODUCTION
Six years and over 100 publications later, the ISG NFV community has evolved through
several phases, its publications have moved from pre-standardization studies to detailed
specifications (see Release 2 and Release 3) and the early Proof of Concepts (PoCs)
efforts have evolved and led to interoperability events (Plugtests).
This large community (300+ companies including 38 of the world's major service
providers) is still working intensely to develop the required standards for NFV as well as
sharing their experiences of NFV implementation and testing.
Last set of NFV standards were released in August 2018 (Version 3.1.1).
ISG NFV, like any other ETSI Industry Specification Group is open to ETSI members
and non-members alike, with different conditions depending on ETSI membership
status.

NFV INTRODUCTION
ETSI’s aim is to produce requirements and potential specifications that TSPs and
equipment vendors can adapt for their individual environments, and which may be
developed by an appropriate standards development organization (SDO).
However, since standards bodies such as the 3GPP are in liaison with the ETSI, we can
expect these proposals will be generally accepted and enforced as standards.
3GPP’s Telecom Management working group (SA5) is also studying the management of
virtualized 3GPP network functions.

NFV INTRODUCTION
NFV Examples
The ETSI has proposed a number of use cases for NFV. In this subsection, we will
explain how NFV may be applied to Customer Premises Equipment (CPE), and to an
Evolved Packet Core (EPC) network.
1. Customer Premises Equipment (CPE)
In Figures 1 and 2, we use an example of a CPE to illustrate the economies of scale that
may be achieved by NFV.
Fig. 1 shows a typical (current) implementation of a CPE which is made up of the

functions: Dynamic Host Configuration Protocol (DHCP), Network Address Translation
(NAT), routing, Universal Plug and Play (UPnP), Firewall, Modem, radio and switching.
In this example, a single service (the CPE) is made up of eight functions.
These functions may have precedence requirements.
For example, if the functions are part of a service chain2, it may be required to perform
firewall functions before NAT.

NFV INTRODUCTION
Currently, it is necessary to have these functions in a physical device located at the

premises of each of the customers 1 and 2.
With such an implementation, if there is a need to make changes to the CPE, say, by
adding, removing or updating a function, it may be necessary for a technician from the
ISP to individually talk to or go to each of the customers.
It may even require a complete change of the device in case of additions.
This is not only expensive (operationally) for the ISPs, but also for the customers.

NFV INTRODUCTION
In Figure 2, we show a possible implementation based on NFV in which some of the

functions of the CPE are transferred to a shared infrastructure at the ISP, which could
also be a data center.
This makes the changes described above easier since, for example, updating the DHCP
for all customers would only involve changes at the ISP. In the same way, adding
another function such as parental controls for all or a subset of customers can be done
at once.
In addition to saving on operational costs for the ISP, this potentially leads to cheaper
CPEs if considered on a large scale.

NFV INTRODUCTION

NFV INTRODUCTION

NFV INTRODUCTION
2. Evolved Packet Core:
Virtualizing the EPC is another example of NFV that has attracted a lot of attention from
industry.
The EPC is the core network for Long Term Evolution (LTE) as specified by 3GPP.
On the left side of Fig. 3, we show a basic architecture of LTE without NFV.
The User Equipment (UE) is connected to the EPC over the LTE access network (E-
UTRAN).
The evolved NodeB (eNodeB) is the base station for LTE radio.
The EPC performs essential functions including subscriber tracking, mobility

management and session management.

NFV INTRODUCTION
It is made up of four NFs: Serving Gateway (S-GW), Packet Data Network (PDN)
Gateway (PGW), Mobility Management Entity (MME), and Policy and Charging Rules
Function (PCRF).
It is also connected to external networks, which may include the IP Multimedia Core
Network Subsystem (IMS).
In the current EPC, all its functions are based on proprietary equipment.
Therefore, even minor changes to a given function may require a replacement of the
equipment.
The same applies to cases when the capacity of the equipment has to be changed.
On the right side of Fig. 3, we show the same architecture in which the EPC is
virtualized. In this case, either all functions in the EPC, or only a few of them are
transferred to a shared (cloud) infrastructure.

NFV INTRODUCTION
Virtualizing the EPC could potentially lead to better flexibility and dynamic scaling, and
hence allow TSPs to respond easily and cheaply to changes in market conditions.
For example, as represented by the number of servers allocated to each function in Fig.
3, there might be a need to increase user plane resources without affecting the control
plane.
In this case, VNFs such as a virtual MME may scale independently according to their
specific resource requirements.
In the same way, VNFs dealing with the data plane might require a different number of
resources than those dealing with signaling only.
This flexibility would lead to more efficient utilization of resources.
Finally, it also allows for easier software upgrades on the EPC network functions, which
would hence allow for faster launch of innovative services.

NFV INTRODUCTION

NFV INTRODUCTION
Virtual EPS

NFV ARCHITECTURE
According to ETSI, the NFV Architecture is composed of three key elements: Network
Function Virtualization Infrastructure (NFVI), VNFs and NFV MANO.
We represent them graphically in Fig. 4. In this section these elements are defined

NFV ARCHITECTURE
A. NFV Infrastructure (NFVI)
The NFVI is the combination of both hardware and software resources which make up
the environment in which VNFs are deployed.
The physical resources include commercial-off-the-shelf (COTS) computing hardware,

storage and network (made up of nodes and links) that provide processing, storage and
connectivity to VNFs.
Virtual resources are abstractions of the computing, storage and network resources.
The abstraction is achieved using a virtualization layer (based on a hypervisor), which

decouples the virtual resources from the underlying physical resources.

NFV ARCHITECTURE
In a data center environment, the computing and storage resources may be represented
in terms of one or more Virtual Machines (VMs), while virtual networks are made up of
virtual links and nodes.
A virtual node is a software component with either hosting or routing functionality, for
example an operating system encapsulated in a VM.
A virtual link is a logical interconnection of two virtual nodes, appearing to them as a

direct physical link with dynamically changing properties

NFV ARCHITECTURE
B. Virtual Network Functions and Services
A NF is a functional block within a network infrastructure that has well defined external
interfaces and well-defined functional behaviour.
Examples of NFs are elements in a home network, e.g. Residential Gateway (RGW);
and conventional network functions, e.g. DHCP servers, firewalls, etc.
Therefore, a VNF is an implementation of an NF that is deployed on virtual resources

such as a VM.
A single VNF may be composed of multiple internal components, and hence it could be
deployed over multiple VMs, in which case each VM hosts a single component of the
VNF.
A service is an offering provided by a TSP that is composed of one or more NFs.

NFV ARCHITECTURE
In the case of NFV, the NFs that make up the service are virtualized and deployed on
virtual resources such as a VM. However, in the perspective of the users, the services-
whether based on functions running dedicated equipment or on VMs - should have the
same performance.
The number, type and ordering of VNFs that make it up are determined by the service’s
functional and behavioral specification.
Therefore, the behaviour of the service is dependent on that of the constituent VNFs.

NFV ARCHITECTURE
C. NFV Management and Orchestration (NFV MANO)
According to the ETSI’s MANO framework, NFV MANO provides the functionality
required for the provisioning of VNFs, and the related operations, such as the
configuration of the VNFs and the infrastructure these functions run on.
It includes the orchestration and lifecycle management of physical and/or software

resources that support the infrastructure virtualization, and the lifecycle management of
VNFs.
It also includes databases that are used to store the information and data models which
define both deployment as well as lifecycle properties of functions, services, and
resources.
NFV MANO focuses on all virtualization-specific management tasks necessary in the

NFV framework.

NFV ARCHITECTURE
In addition the framework defines interfaces that can be used for communications
between the different components of the NFV MANO, as well as coordination with
traditional network management systems such as Operations Support System (OSS)
and Business Support Systems (BSS) so as to allow for management of both VNFs as
well as functions running on legacy equipment.

NFV ARCHITECTURE

NFV Technology
Architectural Functional Blocks
The NFV architectural framework identifies functional blocks and the main reference
points between such blocks.
Some of these are already present in current deployments, whilst others might be
necessary additions in order to support the virtualisation process and consequent
operation.
The functional blocks are:

• Virtualised Network Function (VNF).
• Element Management (EM).
• NFV Infrastructure, including:
• Hardware and virtualised resources, and
• Virtualisation Layer.
• Virtualised Infrastructure Manager(s).
• NFV Orchestrator.
• VNFManager(s).
• Service, VNF and Infrastructure Description.
• Operations and Business Support Systems (OSS/BSS).

NFV Technology
Next Figure shows the NFV architectural framework depicting the functional blocks and
reference points in the NFV framework.
The main (named) reference points and execution reference points are shown by solid
lines and are in the scope of NFV.
These are potential targets for standardization.
The dotted reference points are available in present deployments but might need
extensions for handling network function virtualisation.
However, the dotted reference points are not the main focus of NFV at present.
The architectural framework shown focuses on the functionalities necessary for the
virtualisation and the consequent operation of an operator's network.
It does not specify which network functions should be virtualised, as that is solely a
decision of the owner of the network.

NFV Technology
NFV reference architectural framework

NFV Technology
Virtualised Network Function (VNF)
A VNF is a virtualisation of a network function in a legacy non-virtualised network.

Examples of NFs are 3GPP™ Evolved Packet Core (EPC) network elements, e.g.
Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network
Gateway (PGW); elements in a home network, e.g. Residential Gateway (RGW); and
conventional network functions, e.g. Dynamic Host Configuration Protocol (DHCP)
servers, firewalls, etc.

NFV Technology
Functional behaviour and state of a NF are largely independent of whether the NF is

virtualised or not.
The functional behaviour and the external operational interfaces of a Physical Network
Function (PNF) and a VNF are expected to be the same.
A VNF can be composed of multiple internal components.
For example, one VNF can be deployed over multiple VMs, where each VM hosts a
single component of the VNF.
The whole VNF can be deployed in a single VM as well.

NFV Technology
Element Management (EM)
The Element Management performs the typical management functionality for one or
several VNFs.

NFV Technology
NFV Infrastructure
The NFV Infrastructure is the totality of all hardware and software components which
build up the environment in which VNFs are deployed, managed and executed.
The NFV Infrastructure can span across several locations, i.e. places where NFVI-PoPs
are operated.
The network providing connectivity between these locations is regarded to be part of the
NFV Infrastructure.
From the VNF's perspective, the virtualisation layer and the hardware resources look
like a single entity providing the VNF with desired virtualised resources.

NFV Technology
Hardware Resources
In NFV, the physical hardware resources include computing, storage and network that
provide processing, storage and connectivity to VNFs through the virtualisation layer
(e.g. hypervisor).
Computing hardware is assumed to be COTS as opposed to purpose-built hardware.

Storage resources can be differentiated between shared network attached storage
(NAS) and storage that resides on the server itself.
Computing and storage resources are commonly pooled. Network resources are
comprised of switching functions, e.g. routers, and wired or wireless links.
Also, network resources can span different domains.

NFV Technology
However, NFV differentiates only the following two types of networks:
• NFVI-PoP network: the network that interconnects the computing and storage
resources contained in an NFVI-PoP.
It also includes specific switching and routing devices to allow external

connectivity.
• Transport network: the network that interconnects NFVI-PoPs, NFVI-PoPs to other

networks owned by the same or different network operator, and NFVI-PoPs to other
network appliances or terminals not contained within the NFVI-PoPs.

NFV ARCHITECTURE

NFV Technology
Virtualisation Layer and Virtualised Resources
The virtualisation layer abstracts the hardware resources and decouples the VNF
software from the underlying hardware, thus ensuring a hardware independent lifecycle
for the VNFs.
In short, the virtualisation layer is responsible for:

• Abstracting and logically partitioning physical resources, commonly as a hardware
abstraction layer.
• Enabling the software that implements the VNF to use the underlying virtualised
infrastructure.
• Providing virtualised resources to the VNF, so that the latter can be executed.

NFV Technology

NFV Technology
Role Of Hypervisor
• It provides sufficient abstract of the hardware to provide portability of software

appliances;
• allocates the compute domain resources to the software appliance virtual machines;
• provides a management interface to the orchestration and management system
which allows for the loading and monitoring of virtual machines.

NFV Technology
The architectural view of NFV infrastructure and network function virtualisation is

presented in the NFV Architecture diagram.
The virtualisation layer in the middle ensures VNFs are decoupled from hardware
resources and therefore, the software can be deployed on different physical hardware
resources.
Typically, this type of functionality is provided for computing and storage resources in
the form of hypervisors and VMs.
A VNF can be deployed in one or several VMs.

NFV Technology
The NFV architectural framework does not restrict itself to using any specific
virtualisation layer solution.
NFV expects to use virtualisation layers with standard features and open execution
reference points towards VNFs and hardware (computation, network and storage).
VMs may have direct access to hardware resources (e.g. network interface cards) for
better performance.
In NFV, VMs shall always provide standard ways of abstracting hardware resources
without restricting its instantiation or dependence on specific hardware components.

NFV Technology
The use of hypervisors is one of the present typical solutions for the deployment of
VNFs.
Other solutions to realize VNFs may include software running on top of a non-virtualised
server by means of an operating system (OS), e.g. when hypervisor support is not
available, or VNFs implemented as an application that can run on virtualised
infrastructure or on bare metal.
The operation of the VNF should be independent of its deployment scenario.

NFV Technology
When virtualisation is used in the network resource domain, network hardware is

abstracted by the virtualisation layer to realize virtualised network paths that provide
connectivity between VMs of a VNF and/or between different VNF instances.
Several techniques allow this, including network abstraction layers that isolate resources
via virtual networks and network overlays, including Virtual Local Area Network (VLAN),
Virtual Private LAN Service (VPLS), Virtual Extensible Local Area Network (VxLAN),
Network Virtualisation using Generic Routing Encapsulation (NVGRE), etc.
Other possible forms of virtualisation of the transport network include centralizing the
control plane of the transport network and separating it from the forwarding plane, and
isolating the transport medium, e.g. in optical wavelengths, etc.

NFV Technology
Virtualised Infrastructure Manager(s)
From NFV's point of view, virtualised infrastructure management comprises the

functionalities that are used to control and manage the interaction of a VNF with
computing, storage and network resources under its authority, as well as their
virtualisation.
According to the list of hardware resources specified in the architecture, the Virtualised
Infrastructure Manager performs:
• Resource management, in charge of the:

• Inventory of software (e.g. hypervisors), computing, storage and network
resources dedicated to NFV infrastructure.
• Allocation of virtualisation enablers, e.g. VMs onto hypervisors, compute
resources, storage, and relevant network connectivity.
• Management of infrastructure resource and allocation, e.g. increase resources to
VMs, improve energy efficiency, and resource reclamation.

NFV Technology
• Operations, for:
• Visibility into and management of the NFV infrastructure.
• Root cause analysis of performance issues from the NFV infrastructure
perspective.
• Collection of infrastructure fault information.
• Collection of information for capacity planning, monitoring, and optimization.
Multiple Virtualised Infrastructure Manager instances may be deployed.
NFV Orchestrator
The NFV Orchestrator is in charge of the orchestration and management of NFV

infrastructure and software resources, and realizing network services on NFVI.

NFV Technology
VNF Manager(s)
A VNF Manager is responsible for VNF lifecycle management (e.g. instantiation, update,
query, scaling, termination).
Multiple VNF Managers may be deployed; a VNF Manager may be deployed for each
VNF, or a VNF Manager may serve multiple VNFs.
Service, VNF and Infrastructure Description
This data-set provides information regarding the VNF deployment template, VNF
Forwarding Graph, service-related information, and NFV infrastructure information
models.
These templates/descriptors are used internally within NFV Management and

Orchestration.
The NFV Management and Orchestration functional blocks handle information

contained in the templates/descriptors and may expose (subsets of) such information to
applicable functional blocks, as needed.

NFV Technology
Operations Support Systems and Business Support Systems (OSS/BSS)
The OSS/BSS in last figure refers to the OSS/BSS of an Operator.

NFV Technology
Reference Points
Virtualisation Layer - Hardware Resources - (Vl-Ha)
This reference point interfaces the virtualisation layer to hardware resources to create
an execution environment for VNFs, and collect relevant hardware resource state
information for managing the VNFs without being dependent on any hardware platform.
VNF - NFV Infrastructure (Vn-Nf)
This reference point represents the execution environment provided by the NFVI to the
VNF. It does not assume any specific control protocol. It is in the scope of NFV in order
to guarantee hardware independent lifecycle, performance and portability requirements
of the VNF.

NFV Technology
Reference Points
NFV Orchestrator - VNF Manager (Or-Vnfm)
This reference point is used for:

• Resource related requests, e.g. authorization, validation, reservation, allocation,
by the VNF Manager(s).
• Sending configuration information to the VNF manager, so that the VNF can be
configured appropriately to function within the VNF Forwarding Graph in the
network service.
• Collecting state information of the VNF necessary for network service lifecycle
management.

NFV Technology
Reference Points
Virtualised Infrastructure Manager - VNF Manager (Vi-Vnfm)

• Resource allocation requests by the VNF Manager.
• Virtualised hardware resource configuration and state information (e.g. events)
exchange.
NFV Orchestrator - Virtualised Infrastructure Manager (Or-Vi)

• Resource reservation and/or allocation requests by the NFV Orchestrator.
• Virtualised hardware resource configuration and state information (e.g. events)
exchange.

NFV Technology
Reference Points
NFVI - Virtualised Infrastructure Manager (Nf-Vi)

• Specific assignment of virtualised resources in response to resource allocation
requests.
• Forwarding of virtualised resources state information.
• Hardware resource configuration and state information (e.g. events) exchange.

NFV Technology
Reference Points
OSS/BSS - NFV Management and Orchestration (Os-Ma)

• Requests for network service lifecycle management.
• Requests for VNF lifecycle management.
• Forwarding of NFV related state information.
• Policy management exchanges.
• Data analytics exchanges.
• Forwarding of NFV related accounting and usage records.
• NFVI capacity and inventory information exchanges.
VNF/EM - VNF Manager (Ve-Vnfm)

• Requests for VNF lifecycle management.
• Exchanging configuration information.
• Exchanging state information necessary for network service lifecycle
management.

NFV Technology
Focus Areas in NFV Reference Architectural Framework
Network Functions Virtualisation represents a paradigm shift in networking.
In order to realize a carrier-grade deployment of the NFV architectural framework, the

following areas are to be focussed.
• Virtualisation Layering and NFVI Support

• VNF Software Architecture
• NFV Management and Orchestration
• Performance
• Reliability
• Security

NFV Technology
A key component in the NFV architectural framework is the virtualisation layer.
This layer abstracts and logically partitions physical hardware resources and anchors
between the VNF and the underlying virtualised infrastructure.
The primary tools to realize the virtualisation layer would be the hypervisors.
The NFV architectural framework should accommodate a diverse range of hypervisors.

NFV Technology
On top of such a virtualisation layer, the primary means of VNF deployment would be
instantiating it in one or more VMs.
Therefore, the virtualisation layer shall provide open and standard interfaces towards
the hardware resources as well as the VNF deployment container, e.g. VMs, in order to
ensure independence among the hardware resources, the virtualisation layer and the
VNF instances.
VNF portability shall be supported over such a heterogeneous virtualisation layer.

NFV Technology
VNF Software Architecture
Network functions are well-defined; hence both their functional behaviour as well as
their external interfaces.
In NFV, a VNF is a software package that implements such network functions.
Virtualisation presents an opportunity of modular and slimmer software design of the

conventional monolithic NFs.
A VNF can be decomposed into smaller functional modules for scalability, reusability,
and/or faster response.
Alternatively, multiple VNFs can be composed together to reduce management and VNF
Forwarding Graph complexity.

NFV Technology
These two approaches of composition and decomposition:-
• VNF decomposition, as the process whereby a higher-level VNF is split into a set of
lower-level VNFs. The NFV ISG shall provide guidelines in determining how VNF
decomposition should be standardized.
• VNF composition, as the process whereby a group of lower-level VNFs is used to

define a higher-level VNF.

NFV Technology
We can take the Evolved Packet Core (EPC), Serving Gateway (SGW) and Packet Data
Network Gateway (PGW) NFs to illustrate the above.
Both GW types can be provided as VNFs in their own right with the applicable properties
of VNFs as described in the present document.
It is also conceivable that vendors could implement the SGW and the PGW
in combination, thereby creating a new combined VNF "SGW-PGW".
A vendor that initially implements this combined VNF could also create independent
VNFs for the SGW and the PGW.
Since NFV makes no assumption on the internals relating to such "composed" or

"decomposed" VNFs, a third party cannot decompose the SGW or the PGW VNFs from
a combined SGW-PGW VNF.

NFV Technology
Different management needs may arise when VNFs are composed or decomposed out
of other VNFs.
This may differ from when VNF Forwarding Graphs are constructed and each VNF is
individually manageable, whereas in a composed VNF individual, VNF management
interfaces may not be visible or in a decomposed VNF more management interfaces
may be created.

NFV Technology
Furthermore, each VNF consists of a number of software components that are

manageable by corresponding management and orchestration systems.
Such VNF components can only exist within the context of their "parent" VNF.
The flexibility brought by virtualisation should be exploited to realize modular, portable,

hardware independent, reusable and scalable software design of the VNFs.

NFV Technology
NFV Management and Orchestration
The decoupling of a VNF from the underlying hardware resources presents new
management challenges.
Such challenges include end-to-end service to end-to-end NFV network mapping,

instantiating VNFs at appropriate locations to realize the intended service, allocating and
scaling hardware resources to the VNFs, keeping track of VNF instances
location, etc.
Such decoupling also presents challenges in determining faults and correlating them for
a successful recovery over the network.
While designing the NFV Management and Orchestration, such challenges need to be
addressed.
In order to perform its task, the NFV Management and Orchestration should work with
existing management systems such as OSS/BSS, hardware resource management
system, CMS used as a Virtualised Infrastructure Manager, etc. and augment their
ability in managing virtualisation-specific issues.

NFV Technology
Performance
Performance and scalability are important since the implementation of a VNF may have
a per-instance capacity that is less than that of a corresponding physical network
function on dedicated hardware.
Therefore, methods are needed to split the workload across many distributed/clustered
VNF instances.
Performance-efficient methods of deploying VNF instances on the NFV infrastructure

can also be considered.

NFV Technology
Reliability
NFV should provide reliability as high as that provided with equivalent non-virtualised
legacy network functions, but with improved cost efficiency.
Reliability could depend on specific services, (e.g. voice, health-related applications,

and financial transactions) which may need higher reliability than best-effort services.
To address this issue, functions can be organized into classes or categories that have
similar reliability requirements.
Single-point-of failure, fault detection and recovery methods need to be addressed.
The full potential of the flexibility provided by virtualisation needs to be utilized to

achieve cost efficient reliability necessary for carrier-grade service availability and
completion.

NFV Technology
Security
Physical network functions assume a tight coupling of the NF software and hardware
which, in most cases, is provided together by a single vendor.
In the NFV scenario, multiple vendors are expected to be involved in the delivery and
setup of different NFV elements (e.g. hardware resources, virtualisation layer, VNF,
virtualised infrastructure manager, etc.).

NFV Technology
As a result, due to the virtualisation process, new security issues need to be addressed.
• The use of hypervisors may introduce additional security vulnerabilities, even though
hypervisor-based virtualisation is the state of the art.
Third-party certification of hypervisors should help shed light on their security

properties.
In general, to reduce the vulnerabilities of the hypervisors in use, it is essential

to follow the best practices on hardening and patch management.
To ensure that the right hypervisor is being executed calls for authenticating the
hypervisor at the boot time through secure boot mechanisms.
• The usage of shared storage and shared networking may also add additional
dimensions of vulnerability

NFV Technology
• The interconnectivity among NFV end-to-end architectural components (e.g.

hardware resources, VNFs, and management systems), expose new interfaces that,
unless protected, can create new security threats.
• The execution of diverse VNFs over the NFV infrastructure can also create additional
security issues, in particular if VNFs are not properly isolated from others.

NFV - Introduction

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NFV - Introduction

Uploaded by

Copyright:

Available Formats

NFV Introduction

© Nex-G Exuberant Solutions Pvt. Ltd.

© Nex-G Exuberant Solutions Pvt. Ltd. 2

© Nex-G Exuberant Solutions Pvt. Ltd. 3

© Nex-G Exuberant Solutions Pvt. Ltd. 4

Therefore, Telecommunication Service Providers (TSPs) must correspondingly and

All these lead to high CAPEX and OPEX for TSPs

© Nex-G Exuberant Solutions Pvt. Ltd. 5

© Nex-G Exuberant Solutions Pvt. Ltd. 6

© Nex-G Exuberant Solutions Pvt. Ltd. 7

This way, a given service can be decomposed into a set of Virtual

vEPG – vEvolved Packet Gateway - Evolved Packet Gateway (EPG),

vMPS – vMultiServer Proxy - Multiservice Proxy (MSP) is a multi-

© Nex-G Exuberant Solutions Pvt. Ltd. 8

vWCG - vWeb Communication Gateway – It translates between telecom and Internet

vWMG - vWi-Fi Mobility Gateway is a high-performance, versatile software product that

© Nex-G Exuberant Solutions Pvt. Ltd. 9

© Nex-G Exuberant Solutions Pvt. Ltd. 11

© Nex-G Exuberant Solutions Pvt. Ltd. 12

vENM - vEricsson Network Manager, the next-generation unified network management

© Nex-G Exuberant Solutions Pvt. Ltd. 13

vEMM – vEricsson Multi Mediation - Ericsson Multi Mediation is a converged mediation

vDNS – vDomain Name Service – It translates domain names to IP addresses so

vAAA - vAuthentication, Authorization and Accounting (AAA) of subscriber sessions is

© Nex-G Exuberant Solutions Pvt. Ltd. 14

© Nex-G Exuberant Solutions Pvt. Ltd. 15

In summary, these differences are as follows:-

• Decoupling Software From Hardware - As the network element is no longer a

© Nex-G Exuberant Solutions Pvt. Ltd. 16

© Nex-G Exuberant Solutions Pvt. Ltd. 17

• Flexible Network Function Deployment - The detachment of software from

Therefore, components can be instantiated at any NFV-enabled device in the

© Nex-G Exuberant Solutions Pvt. Ltd. 18

Needless to mention, it is also possible to have hybrid scenarios where functions

Such hybrid scenarios may be important in the transition towards NFV.

© Nex-G Exuberant Solutions Pvt. Ltd. 19

History of Network Function Virtualization

ETSI is currently working on Release 3 Specifications.

© Nex-G Exuberant Solutions Pvt. Ltd. 20

© Nex-G Exuberant Solutions Pvt. Ltd. 21

© Nex-G Exuberant Solutions Pvt. Ltd. 22

1. Customer Premises Equipment (CPE)

Fig. 1 shows a typical (current) implementation of a CPE which is made up of the

These functions may have precedence requirements.

© Nex-G Exuberant Solutions Pvt. Ltd. 23

Currently, it is necessary to have these functions in a physical device located at the

It may even require a complete change of the device in case of additions.

© Nex-G Exuberant Solutions Pvt. Ltd. 24

In Figure 2, we show a possible implementation based on NFV in which some of the

© Nex-G Exuberant Solutions Pvt. Ltd. 25

© Nex-G Exuberant Solutions Pvt. Ltd. 26

© Nex-G Exuberant Solutions Pvt. Ltd. 27

2. Evolved Packet Core:

The EPC performs essential functions including subscriber tracking, mobility

© Nex-G Exuberant Solutions Pvt. Ltd. 28

© Nex-G Exuberant Solutions Pvt. Ltd. 29

This flexibility would lead to more efficient utilization of resources.

© Nex-G Exuberant Solutions Pvt. Ltd. 30

© Nex-G Exuberant Solutions Pvt. Ltd. 31

© Nex-G Exuberant Solutions Pvt. Ltd. 32

© Nex-G Exuberant Solutions Pvt. Ltd. 33

A. NFV Infrastructure (NFVI)

The physical resources include commercial-off-the-shelf (COTS) computing hardware,

The abstraction is achieved using a virtualization layer (based on a hypervisor), which