Study Paper on Network Function Virtualisation final - TEC Paper on Network Function... · Study Paper on Network Function Virtualisation: ... To reap these benefits, ... firewall,

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,


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.


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.


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:


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.


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.


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.


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


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


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.


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.


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.


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


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.


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.


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


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.


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


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.


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


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.


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


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


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.


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


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


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


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


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


30 | P a g e

WOC WAN Optimization Controller

Study Paper on Network Function Virtualisation final - TEC Paper on Network Function... · Study Paper on Network Function Virtualisation: ... To reap these benefits, ... firewall,

Documents