Study Paper on Network Function Virtualisation final - TEC Paper on Network Function... · Study...
Transcript of Study Paper on Network Function Virtualisation final - TEC Paper on Network Function... · Study...
Telecom Engineering Center, Department of Telecommunications, Government of India
1 | P a g e
Study Paper on Network Function Virtualisation: Architecture and core network
applications U C Meena ADG, R. Saji Kumar Director, Chandra Shekhar DDG, IT Division, Telecom Engineering Center, Department of Telecommunications, New Delhi.
Abstract: The study paper describes the high level functional architectural framework and design
philosophy of virtualized network functions and of supporting infrastructure. It also describes use cases
of Virtualisation of Enterprise CPE, Virtualisation of Mobile Core Network, Virtualisation of Mobile base
station, Virtualisation of Home CPE and Virtualisation of Fixed Access Network for Network Functions
Virtualisation(NFV). NFV reduces equipment cost(CAPEX), increases speed of time to market, allows
a single platform for different applications, users and tenants, enable a variety of eco-systems and
encourage openness. To reap these benefits, the technical challenges need to be addressed by the
industry. To arrive at possible solutions to these technical challenges, the IT and Telecom Network
industries may have to combine their complementary expertise and resources in a joint collaborative
effort to reach broad agreement on standardised approaches and common architectures which may
address these technical challenges, and provide tested and interoperable solutions for delivery of end
to end virtualised services with economies of scale
Keywords: Network Function Virtualisation, NFV Infrastructure, Virtualised Network Functions,
Network Functions Virtualisation Infrastructure as a Service, Virtual Network Function as a Service,
Virtual Network Platform as a Service
1.0 Introduction
1.1. Telecom Service providers networks are populated with a large and increasing variety of
proprietary hardware appliances. To launch a new network service often requires yet another
variety and finding the space and power to accommodate these boxes is becoming increasingly
difficult; compounded by the increasing costs of energy, capital investment challenges and the
rarity of skills necessary to design, integrate and operate increasingly complex hardware-based
appliances (Router, firewall, CDN, PGW, NAT etc). Moreover, hardware-based appliances rapidly
reach end of life, requiring much of the procure design-integrate-deploy cycle to be repeated with
little or no revenue benefit.
1.2. In figure 1 Network Functions Virtualisation addresses these problems by leveraging standard
software virtualisation techniques to consolidate many network equipment types onto industry
standard high volume servers, switches and storage, which could be located in Datacenters,
Telecom Engineering Center, Department of Telecommunications, Government of India
2 | P a g e
Network Nodes and in the end user premises. It involves the implementation of network functions
in software that can run on a range of industry standard server hardware, and that can be moved
to, or instantiated in, various locations in the network as required, without the need for installation
of new equipment.
Figure-1: NFV Approach
2.0 NFV architectural framework
2.1. The NFV architectural framework focuses on the changes likely to occur in an operator's network
due to the network function virtualisation process. The Network Function Virtualisation (NFV)
architecture has been defined by the ETSI NFV ISG and comprises three principal elements as
shown in figure 2: the NFV Infrastructure (NFVI), Virtualised Network Functions (VNFs) and the
NFV Management and Orchestration (MANO) functions.
Telecom Engineering Center, Department of Telecommunications, Government of India
3 | P a g e
Figure 2: High-level NFV framework
2.1.1. The NFV Infrastructure (NFVI) consists of physical networking, computing and storage
resources that can be geographically distributed and exposed as a common networking/NFV
infrastructure. It is the combination of both hardware and software resources which build up the
environment in which VNFs are deployed, managed and executed. The NFVI can span across
several locations i.e. places where NFVIPoPs are operated. The network providing connectivity
between these locations is regarded to be part of the NFVI.
2.1.2. Virtualised Network Functions (VNFs) are software implementations or virtualisation of network
functions (NFs) that are deployed on virtual resources such as VM. Virtualized network functions,
or VNFs, are responsible for handling specific network functions that run in one or more virtual
machines on top of the hardware networking infrastructure, which can include routers, switches,
servers, cloud computing systems and more. Individual virtualized network functions can be
chained or combined together in a building block-style fashion to deliver full-scale networking
communication services.
2.1.3. NFV Management and Orchestration (NFV MANO) functions provide the necessary tools for
operating the virtualized infrastructure, managing the life cycle of the VNFs and orchestrating
virtual infrastructure and network functions to compose value-added end-to-end network services.
NFV MANO focuses on all virtualisation specific management task necessary in the NFV
framework.
Telecom Engineering Center, Department of Telecommunications, Government of India
4 | P a g e
2.2. Architectural functional blocks: 2.2.1. Figure 2 shows 3 main functional blocks but the NFV architectural framework also identifies other
functional blocks and main reference points between such blocks. The various functional blocks
are as following:
Virtualised Network Function (VNF).
Element Management (EM).
NFV Infrastructure, including:
Hardware and virtualised resources, and
Virtualisation Layer.
Virtualised Infrastructure Manager(s).
NFV Orchestrator.
VNF Manager(s).
Service, VNF and Infrastructure Description.
Operations and Business Support Systems (OSS/BSS).
Figure 3 shows the detailed NFV architectural framework depicting the functional blocks and
reference points in the NFV framework.
Figure 3: NFV reference architecture framework
2.2.2. The overview of the functional blocks in the architecture framework are as follows:
Telecom Engineering Center, Department of Telecommunications, Government of India
5 | P a g e
2.2.2.1. 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. 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. However, in other cases, the whole VNF can be deployed
in a single VM as well.
2.2.2.2. 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. 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
2.2.2.3. 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.
Telecom Engineering Center, Department of Telecommunications, Government of India
6 | P a g e
The architectural view of NFV infrastructure and network function virtualisation is presented in figure
3. 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 is envisioned to be deployed in one or several VMs.
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.
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. 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.
2.2.2.4. Element Management (EM):
The Element Management performs the typical management functionality for one or several VNFs.
2.2.2.5. 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.
Operations, for:
Visibility into and management of the NFV infrastructure.
Telecom Engineering Center, Department of Telecommunications, Government of India
7 | P a g e
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.
2.2.2.6. 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.
2.2.2.7. 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.
2.2.2.8. 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.
2.2.2.9. Operations Support Systems and Business Support Systems(OSS/BSS)
The OSS/BSS in figure 4 refers to the OSS/BSS of an Operator.
2.2.3. Reference Points 2.2.3.1. 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.
2.2.3.2. 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.
2.2.3.3. 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.
Telecom Engineering Center, Department of Telecommunications, Government of India
8 | P a g e
2.2.3.4. Virtualised Infrastructure Manager - VNF Manager (Vi-Vnfm): This reference point is used for: Resource allocation requests by the VNF Manager. Virtualised hardware resource configuration and state information (e.g. events) exchange.
2.2.3.5. NFV Orchestrator - Virtualised Infrastructure Manager (Or-Vi): This reference point is used for: Resource reservation and/or allocation requests by the NFV Orchestrator. Virtualised hardware resource configuration and state information (e.g. events) exchange.
2.2.3.6. NFVI - Virtualised Infrastructure Manager (Nf-Vi): This reference point is used for:
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.
2.2.3.7. OSS/BSS - NFV Management and Orchestration (Os-Ma): This reference point is used for: 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.
2.2.3.8. VNF/EM - VNF Manager (Ve-Vnfm): This reference point is used for: Requests for VNF lifecycle management. Exchanging configuration information. Exchanging state information necessary for network service lifecycle management.
3.0 Use Case
The NFV ISG member companies identify and describe a first set of service models and high level use cases which represent, important service models and initial fields of application for NFV. The different used cases presented here are Virtualisation of Enterprise CPE, Virtualisation of Mobile Core Network, Virtualisation of Mobile base station, Virtualisation of Home CPE and Virtualisation of Fixed Access Network.
3.1. Virtualisation of Enterprise CPE Today the enterprises are continuing to evolve, more services and applications migrate to the
enterprise DC or public clouds, forcing a change in the way enterprise networks are built. Rather
than the Enterprise investing its own capital in deployment of networking infrastructure, now days the
service provider may be able to provide advanced networking features on an expense basis. The
Telecom Engineering Center, Department of Telecommunications, Government of India
9 | P a g e
service provider could operate a VNF instance using its NFVI which provides the functionality
required to implement the enterprise CPE and potentially another VNF instance for the control plane
of the PE router improving its scalability.
3.1.1. In this Virtualised enterprise services example, the VNF is the service provider's application. The
Enterprise is the consumer of the service. The Enterprise is not managing or controlling the NFVI or
the VNF. The Enterprise as a consumer of the VNFaaS does not have to invest additional capital in
advanced networking features provided via the control plane; rather it can obtain them on an expense
basis from the Service Provider as needed. The Service Provider can scale the NFVI resources
allocated to the VNF instance in response to increasing usage of the VNF.
3.1.2. Pre-NFV service provider networks include a Provider Edge (PE) router at the edge of the core,
facing the Customer Premises Equipment (CPE) device as illustrated in Figure 4. Virtualisation of
the enterprise may include Virtualisation of the CPE functions (vE-CPE) in the service provider cloud
and Virtualisation of the PE functions (vPE) where the virtual network services functions and core-
facing PE functions can be executed in the service provider cloud.
Figure 4: Service Provider without virtualisation of the enterprise
3.1.3. The vE-CPE solution enhances the enterprise network by replacing appliances with NFV compliant
Virtualised solutions located at either the enterprise cloud or the operator of the NFV framework.
Services provided by the vE-CPE may include a router providing QoS and other high-end services
such as L7 stateful firewall, intrusion detection and prevention and more. Application accelerators
are also deployed either as standalone appliances or as router integrated services.
3.1.4. Virtualisation Target: There are a number of Network Functions typically deployed today within
Enterprise networks as dedicated hardware infrastructure where it may, in the future, be appropriate
Telecom Engineering Center, Department of Telecommunications, Government of India
10 | P a g e
for a Service Provider to deliver on a VNFaaS basis to the Enterprise. These Enterprise network
functions include:
AR - Enterprise Access Router / Enterprise CPE PE - Provider Edge Router FW - Enterprise Firewall NG-FW - Enterprise NG-FW WOC - Enterprise WAN optimization Controller DPI - Deep Packet Inspection (Appliance or a function) IPS - Intrusion Prevention System and other Security appliances Network Performance Monitoring
3.1.5. The Figure 5 presents the functionality re-distribution as a result of the virtualisation of the CPE. The
enterprise local traffic is handled by a local L2 or L3 switch providing physical connectivity (and
possibly further functionality), and the enterprise LAN is extended to the Operator NFV Network
located vE-CPE. Example functionality provided by the vE- CPE in Figure 8 includes routing, VPN
termination, QoS support, DPI, NG-FW and a WOC (WAN Optimization Controller). We contrast the
case of a non-virtualised customer site served by a non-virtualised CPE, and that of a site served by
a vE-CPE. The dotted purple lines indicate where this vE-CPE functionality may be located.
Telecom Engineering Center, Department of Telecommunications, Government of India
11 | P a g e
Figure 5: Non-Virtualised CPE and vE-CPE
3.1.6. Coexistence of Virtualised and Non-Virtualised Network: Figure 6 demonstrates co-existence and
interoperability of Virtualised and non-Virtualised Enterprise CPE functions. In the upper depicted
branch, the vE-CPE is implemented in the operator NFV Network. The Branch local traffic extends
into the operator network and terminates at the vE-CPE. The lower branch represents a legacy
solution provided by non-Virtualised appliances. In this case, the Enterprise local traffic stays within
the branch.
Telecom Engineering Center, Department of Telecommunications, Government of India
12 | P a g e
Figure 6: Co-existence of legacy Enterprise CPE & Operator located vE-CPE
3.2. Virtualisation of Mobile Core Network 3.2.1. Network Function Virtualisation enables the creation of a competitive environment where innovative
implementations of 3rd party network applications can be supplied by unlocking the proprietary
boundaries of current Mobile Core and IMS implementations. The 3GPP™ is the standards developing
organization that defines the Network Architecture and specifications for the Network Functions (NFs)
for mobile and converged networks.
3.2.2. The Evolved Packet Core (EPC), which is the latest core network architecture for a LTE cellular
system shown in figure 7. Network Functions of the core network are MME, SGW, PGW, PCRF etc.
which are implemented through proprietary hardware vendor.
Telecom Engineering Center, Department of Telecommunications, Government of India
13 | P a g e
Figure 7: LTE Core Network Architecture
3.2.3. Virtualisation Target :The following network functions of Mobile Core Network are virtualised:
EPC Core & Adjunct Network Functions e.g. MME, S/P-GW, PCRF, etc. 3G/EPC Interworking Network Functions e.g. SGSN, GGSN, etc.
3.2.4. The Figure 8 presents a possible view of the EPC virtualisation based on NFV.
Figure 8: Virtualisation of EPC
Telecom Engineering Center, Department of Telecommunications, Government of India
14 | P a g e
3.2.5. The entire EPC is virtualised in a single NFVI-PoP or only some NFs are virtualised. Virtualised
Network Functions (VNFs), e.g. S/P-GW, MME, may scale independently according to their specific
resource requirements. Figure 9 shows Virtualised EPC and IMS, where Virtualised S/P-GW and IMS
Functions are dealing with PDN connections and IMS session, respectively. When dynamic relocation
of those VNF instances is performed due to VM's overload or failure in an automatic or on-demand
fashion, the relocation of the managed sessions and/or connections needs to be handled appropriately
to achieve operator desired service continuity and service availability.
3.2.6. Coexistence of Virtualised and Non-Virtualised Network Functions
NFV-based Virtualised mobile core network will coexist with non-Virtualised mobile core network.The
various scenario of virtualisation are possible e.g a case where only some NFs are Virtualised (Figure
9). They can be EPC control functions (e.g. MME/SGSN), HSS or service nodes (e.g. IMS).
Figure 9: Partial virtualisation of mobile core network
In other case where operator deploys a complete Virtualised core network while still having the non-Virtualised one (Figure 10). The Virtualised core can be used for specific services and/or devices (e.g. machine-to-machine) or for traffic exceeding the capacity of the non-Virtualised network.
Telecom Engineering Center, Department of Telecommunications, Government of India
15 | P a g e
Figure 10: Service specific mobile core network virtualisation
3.3. Virtualisation of Mobile base station 3.3.1. The present day base station architecture is shown in figure 11. The mobile operators Total Cost of
Operation(TCO) and energy consumption in today’s mobile networks, RAN nodes account for most
of them. The large number of RAN nodes such as eNodeB are usually based on proprietary platforms
and are suffering from long life-cycle in development, deployment and operation. 3GPP LTE™ is the
emerging cellular network system choice now a day, with the demand for higher data rates and good
quality of service, low complexity, continued cost reduction of radio access and packet core.
Figure 11: Present day Base station Architecture
3.3.2. Virtualisation of mobile base station leverages IT virtualisation technology to realize at least a part of
RAN nodes onto standard IT servers, storages and switches. It is expected to provide advantages,
such as lower footprint and energy consumption coming from dynamic resource allocation and traffic
load balancing, easier management and operation, and faster time-to-market.
Telecom Engineering Center, Department of Telecommunications, Government of India
16 | P a g e
3.3.3. In major mobile operators' networks, multiple RAN nodes from multiple vendors are usually operated
with different mobile network systems, e.g. 3G, LTE and WiMAX®, in the same area. Base Station
(BS) virtualisation can achieve sharing of resources among multiple logical RAN nodes from different
systems, dynamically allocating the resource as well as reducing power consumption.
3.3.4. Virtualisation Target: The following are the targeted network function for virtualisation
For Traditional RAN node such as eNodeB, Home eNodeB, and Femto/Picocell, possible virtualisation targets are baseband radio processing unit, MAC, RLC, PDCP, RRC (Radio Resource Control), Control and CoMP.
For C-RAN we consider the above functions in BBU, Switching function and Load balancer.
3.3.5. BS (used here as a generic term to designate 2G BS, 3G Node B and 4G eNode B) are part of the
3GPP™ reference model, and include radio access functions. In LTE, Base Stations (BS) are in
charge of the PHY, MAC, RLC (Radio Link Control), RRC and PDCP (Packet Data Convergence
Protocol) functions as shown in figure 12.
Figure 12: functional block of BBU
3.3.6. The PHY layer includes the most computational intensive tasks, such as channel coding/decoding,
FFT/iFFT. BS virtualisation requires baseband radio processing using IT visualization technologies,
such as high-performance general purpose processors and real-time processing virtualisation to
provide the required signal processing capacity. Moreover, BS virtualisation for C-RAN requires
Telecom Engineering Center, Department of Telecommunications, Government of India
17 | P a g e
building the processing resource, i.e. Base Band Unit (BBU) pool for aggregating the resources onto
centralized virtualised environment, such as a DC or cloud infrastructure as shown in figure 13.
Centralized-RAN (C-RAN) technology with virtualisation can leverage more efficient resource
utilization among different physical BSs.
Figure 13: LTE RAN architecture evolution by centralized BBU pool
3.4. Virtualisation of the Home CPE 3.4.1. Current network operator provided home services through dedicated CPE devices located as part of
the home network. These CPE devices mark the operator and/or service provider presence at the
customer premises and usually include a Residential Gateway (RGW) for Internet and VOIP services,
and a Setup Box (STB) for Media services normally supporting local storage for PVR services. The
availability of high bandwidth access (such as offered by Fibre) and the emergence of NFV
technology facilitate virtualisation of the home environment, requiring only simple, physical
connectivity and focused, low cost, and low maintenance devices at the customer premises.
3.4.2. Figure 14 depicts a legacy network without home Virtualisation. In this example, each home is
equipped with an RGW and IP STB. All services are received by the RGW, converted to private IP
address and delivered inside the home. The RGW is connected (via a PPPoE Tunnel or IPoE) to the
BNG which provides connectivity to the Internet or DC. VoIP and IPTV services bypass the BNG in
this scenario.
Telecom Engineering Center, Department of Telecommunications, Government of India
18 | P a g e
Figure 14: No Home Virtualisation
3.4.3. Virtualisation Target: The following traditional functions could be Virtualised in the target scenario:
1. RGW - Residential Gateway: Connectivity:
DHCP server - Provide private IP addresses to home devices. NAT router - Provide routing capabilities to the home. Convert the home addresses
to one public IP per home (IPv4/6). PPPoE client - Client for connectivity to the BRAS. ALG - Application level gateway to allow Application Specific routing behaviour.
Security:
Firewall, Antivirus, IPS - Provide protection to the home environment. Parental control - Allows control of consumed web content to device level. Port mapping. VPN Server - Provide remote accesses to the user LAN.
Management Web GUI - to allow subscriber management. TR-69 - To allow operator's control. uPnP comparable technology with augmented security - Discovery of vRGW by
Telecom Engineering Center, Department of Telecommunications, Government of India
19 | P a g e
home applications. Statistics & Diagnostics.
2. STB - Home Set Top Box:
User Interface & Connectivity: Remote UI server - Allows same look and feel to a big variety of home devices
including UI automatic negotiation for best possible user experience.
Middleware Client - Provide interface for existing middleware servers to query information such as Electronic Program Guide (EPG), subscriber rights, etc.
Media Streaming: DLNA media server - Expose all media inventory such as: EPG, VOD catalog,
NPVR list, TSTV inventory to DLNA devices. VOD, NPVR, TSTV, OTT clients - Provide interfaces to existing content platforms. Streaming methods such as HTTP and Zero Client. Multi-screen - support various, simultaneous, screens of varying resolution and
formats. Media Cache - Support caching of different content types and formats.
Management & Security:
Web GUI - to allow subscriber management. Encryption - support different encryption schemes for cached content Share Content - Possibility a user be able to see its contents over any virtualised
Home
3.4.4. NFV technology facilitates virtualisation of services and functionality migration from home devices to
the NFV cloud as shown in the Figure 15. In this use case description we follow the Virtualised
Network Function proposal by NFV and maintain a virtualised replica of the original device, such that
the RGW migrates into a vRGW and STB into vSTB. In so doing, we maintain as much as possible
the original Interfaces to the virtualised devices.
Telecom Engineering Center, Department of Telecommunications, Government of India
20 | P a g e
Figure 15: Home Virtualisation functionality
3.4.5. Coexistence of Virtualised and Non-Virtualised Network Functions: Figure 16 depicts an RGW
virtualisation for Home #1. In this scenario, vRGW would be implemented in the NFV Network,
providing the Private IP address to the home and is directly connected to some services like IPTV
and VoIP. For Internet Services, the vRGW uses a tunnel or a session to the BNG. For all services,
vRGW performs a NAT function (conversion to private IP address).
Figure 16: Home Virtualisation - RGW is Virtualised
Telecom Engineering Center, Department of Telecommunications, Government of India
21 | P a g e
3.4.6. Figure 17 depicts a Use Case where both RGW and STB for Home #2 are Virtualised. The vSTB
now uses a Public IP address to communicate with the vRGW and its service platforms (IPTV or
Internet platforms via the BNG).
Figure 17: Home Virtualisation - Both RGW and STB are Virtualised - Public IP
3.4.7. In this scenario depicted in Figure 18, the STB services for Home #3 are provided from the NFV
network. Interoperability with an existing home located RGW is maintained. The vSTB now uses
a Public IP address to communicate with its service platforms (IPTV or Internet platforms via the
BNG). It also uses a public IP address to communicate with the home located RGW.
Telecom Engineering Center, Department of Telecommunications, Government of India
22 | P a g e
Figure 18: Home Virtualisation - Both RGW and STB are Virtualised - Public IP
3.5. Fixed Access Network Functions Virtualisation 3.5.1. The main costs and bottlenecks in a network often occur in the access. For the wireline fixed access
network in today’s time is shown in figure 19 and the most prevalent broadband access technologies
today are based on DSL. The trend however is to replace exchange-based equipment with
equipment based on VDSL2 in new street cabinets with fibre backhaul (FTTcab). VDSL2 can provide
bit rates of up to ~100 Mb/s. However a new DSL standard is under development - ITU-T/G.fast -
which will provide very high data rates of up to ~1Gb/s on the existing short copper drop wires
connecting end-user premises (FTTdp).
Telecom Engineering Center, Department of Telecommunications, Government of India
23 | P a g e
Figure 19: Present fixed access Network diagram
3.5.2. Both FTTcab/VDSL2 and FTTdp/G.fast systems require electronic systems to be deployed in remote
nodes located in the street or in multiple-occupancy buildings. These systems need to be energy
efficient to minimize thermal problems. To deploy on large scale we envisage the features like Low
cost, Minimal power consumption, Complex processing moved to the head-end, and Automated
provisioning.
3.5.3. Virtualisation Target:
Target Network functions for virtualisation may include control functions for the fixed access network
are:
OLT DSLAM ONU ONT MDU DPU
3.5.4. Access Network Functions Virtualisation will be initially applied to hybrid fibre-DSL nodes such as
FTTcab and FTTdp. These nodes will be located deep in the access network, within existing or new
street cabinets (FTTcab), or in the case of FTTdp, located underground or on poles or in multiple-
occupancy buildings. By applying NFV principles, hardware complexity at the remote node can be
Telecom Engineering Center, Department of Telecommunications, Government of India
24 | P a g e
reduced both saving energy and providing an enhanced degree of future proofing through centralized
software updates as services evolve.
3.5.5. Various scenarios of Access networks and virtualisation possibilities for L2 functionality and control
planes are shown in Figure 20. Marked in Yellow are network elements whose L2 & control plane
functionality may be separated and run in a NFV enabled CO.
Figure 20: Access Network Virtualisation and Open Interfaces
3.5.6. Coexistence of Virtualised and Non-virtualised Network Functions
Legacy and virtual Access nodes can co-exist and share the Fibre Access Network and the common Aggregation and Service platforms as shown in Figure 21. In legacy Access networks (bottom of Figure 21), each network function contains its own
control plane. In the Hybrid Case (middle of Figure 21), the Access Node supports both legacy (xDSL &
FTTH) and Virtualised (FTTdp) Access nodes whose control functions are implemented in the CO.
The upper part of Figure 21 depicts an NFV based solution. All access nodes have their Control plane virtualised in the CO.
Telecom Engineering Center, Department of Telecommunications, Government of India
25 | P a g e
Figure 21: Virtualised and Legacy Access Networks 4.0 Key benefits of NFV
1.1. Reduced equipment costs and reduced power consumption through consolidating
equipment and exploiting the economies of scale of the IT industry.
1.2. Increased speed of Time to Market by minimising the typical network operator cycle of
innovation. Economies of scale required to cover investments in hardware-based
functionalities are no longer applicable for software-based development, making feasible
other modes of feature evolution. Network Functions Virtualisation should enable network
operators to significantly reduce the maturation cycle.
1.3. Availability of network appliance multi-version and multi-tenancy, which allows use of a
single platform for different applications, users and tenants. This allows network operators
to share resources across services and across different customer bases.
1.4. Targeted service introduction based on geography or customer sets is possible. Services can
be rapidly scaled up/down as required.
1.5. Enables a wide variety of eco-systems and encourages openness. It opens the virtual
Telecom Engineering Center, Department of Telecommunications, Government of India
26 | P a g e
appliance market to pure software entrants, small players and academia, encouraging more
innovation to bring new services and new revenue streams quickly at much lower risk.
5.0 Conclusion:
Network Functions Virtualisation is likely to deliver many benefits for network operators and their
partners and customers while offering the opportunity to create new types of eco-systems which
may encourage and support rapid innovation with reduced cost and reduced risk. To reap these
benefits, the technical challenges need to be addressed by the industry. To arrive at possible
solutions to these technical challenges, the IT and Telecom Network industries may have to
combine their complementary expertise and resources in a joint collaborative effort to reach broad
agreement on standardised approaches and common architectures which may address these
technical challenges, and provide tested and interoperable solutions for delivery of end to end
virtualised services with economies of scale. NFV need to be part of the broader transformation
effort and may require service providers to make significant changes and progressive efforts.
6.0 Reference
1. NFV White paper: "Network Functions Virtualisation, An Introduction, Benefits, Enablers,
Challenges & Call for Action. Issue 1".
2. ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main
Concepts in NFV".
3. ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
4. ETSI GS NFV 001: "Network Functions Virtualisation (NFV); Use Cases".
Abbreviations
Telecom Engineering Center, Department of Telecommunications, Government of India
27 | P a g e
3GPP™ 3rd Generation Partnership Project ALG Application Level Gateway API Application Programming Interface APN Access Point Name AR Access Router AS Application Server BBU Base Band Unit BGP Border Gateway Protocol BNG Broadband Network Gateway BPF Band Pass Filter BS Base Station BSS Business Support System CAPEX Capital Expenses CDN Content Delivery Network CO Central Office COTS Custom Off The Shelf CPE Customer Premises Equipment C-RAN Cloud Radio Access Network CSC Cloud Service Customer CSCF Call Session Control Function CSP Cloud Service Provider DC Data Centre DHCP Dynamic Host Configuration Protocol
DNS Domain Name System DPI Deep Packet Inspection DPU Distribution Point Unit DSL Digital Subscriber Line DSLAM Digital subscriber line access multiplexer E2E End to End EMS Element Management System eNodeB Evolved Node B EPC Evolved Packet Core EPS Evolved Packet System EVPN Ethernet Virtual Private Network FG Forwarding Graph FTTcab Fibre To The Cabinet FTTdp Fibre To The Distribution Point
Telecom Engineering Center, Department of Telecommunications, Government of India
28 | P a g e
FTTH Fibre To The Home FTTP Fibre To The Premises FW Firewall GGSN Gateway GPRS Support Node GUI Graphical User Interface GW Gateway HD High Definition
HSS Home Subscriber Server IaaS Infrastructure as a Service I-CSCF Interrogating-Call Session Control Function IMS IP Multimedia Subsystem IP Internet Protocol IPS Intrusion Prevention System IPTV Internet Protocol Television ISP Internet Service Provider IT Information Technology ITU International Telecommunication Union ITU-T International Telecommunication Union - Telecommunication LAN Local Area Network LTE Lone-Term Evolution MAC Media Access Control MDU Multi Dwelling Unit MME Mobility Management Entity NAS Network Attached Storage NaaS Network as a Service NAT Network Address Translation NF Network Function NFV Network Functions Virtualisation NFVI Network Functions Virtualisation Infrastructure NFVI-PoP Network Functions Virtualisation Infrastructure Point of Presence NG-FW Next Generation Firewall OAM Operation, Administration and Maintenance OLT Optical Line Termination ONT Optical Network Terminal ONU Optical Network Unit OPEX Operational Expenses OSS Operations Support System
Telecom Engineering Center, Department of Telecommunications, Government of India
29 | P a g e
OTT Over-The-Top PaaS Platform as a Service PCRF Policy and Charging Control Function P-CSCF Proxy-Call Session Control Function PDCP Packet Data Convergence Protocol PDN Packet Data Network PE Provider Edge (Router)
PGW Packet Gateway PHY Physical PoP Network Point of Presence PPPoE Point-to-Point Protocol Over Ethernet PPVPNS Provider Provisioned Virtual Private Network Service QoE Quality of Experience QoS Quality of Service RAN Radio Access Network RGW Residential Gateway RLC Radio Link Control RRC Radio Resource Control S-CSCF Serving-Call Session Control Function SGSN Serving GPRS Support Node SGW Serving Gateway STB Setup Box TCO Total Cost of Ownership UI User Interface uPnP Universal Plug-and-Play vE-CPE Virtual Enterprise-Customer Premises Equipment VLAN Virtual Local Access Network VM Virtual Machine VNF Virtual Network Function VNF FG VNF Forwarding Graph VNFaaS Virtual Network Function as a Service VOIP Voice Over Internet Protocol (IP) vPE Virtual Provider Edge (Router) VPLS Virtual Private LAN Service VPN Virtual Private Network WAN Wide Area Network WiMAX® Worldwide Interoperability for Microwave Access