Business Applicability of NFV and SDN in Telecom Network
By
Vadan Mehta
Tata Consultancy Services
vadan.mehta@tcs.com
USA
Abstract
Growing presence of OTT and cloud services,
piggybacking on service providers’ telecom
network, has disturbed the telecom carriers’ voice
centric business models. Service providers
require agile service deployment and elastic
infrastructure, to provide cloud-like network
services to compete and collaborate with OTT
players.
Technological accelerators as NFV and SDN
provide framework to infuse programmability in
existing closed, propriety API based Telco
network. This paper describes business
applicability of NFV & SDN by analyzing two
solution implementations, centralized policy
function and VoLTE service deployment.
Introduction
Free social-messaging applications like
WhatsApp cost phone providers around the world
appx. $32.5 billion in texting fees in 2013,
according to research from Ovum Ltd. That
figure is projected to reach $54 billion by 2016.
Over-the-top (OTT) companies like Skype,
Gmail Chat, Whatsup, which provide
communication services through the IP with free
of charge, poses serious threat to telecom service
providers in terms of revenue. These OTT
companies are making their way into handsets
through mobile app stores and offering new
communications services for users, often for free.
OTT services use dedicated mobile and data
networks or WIFI, without having any revenue
share with mobile or fixed line operators. This
means takes significant chunk of revenues away
from the mobile operators as WhatUp did.
Apart from OTT companies, cloud providers as
Amazon, Microsoft are also encroaching cloud
Manish Singh
Systems Test Solutions LLC
manishsingh@stsi.co.uk
USA
computing space from telecom operators.
Telecom operators need to find ways to counter
these revenue leakages by not just being transport
network but also content provider. Principally,
as owner of transport network, datacenters,
billing and CRM systems, service providers are
better positioned to provide OTT and cloud
services. The key is agility in service deployment,
using already existing billing, CRM and network
infrastructure capabilities.
Programmability
Challenge is current network deployments within
service provider domains are static and
nonprogrammable in nature. This prevents
network engineers from meeting basic business
requests to deliver dynamic network services,
like bandwidth-on-demand, rate limiting, burst
quality of service, and other services. Service
providers require more programmable network to
dynamically instantiate services in the telco cloud
to create concepts such as a network functions
app-store. Programmability implies to provide
telco services as cloud services. Programmability
is defined as network ability to move from pre-
defined configurable network based on
proprietary APIs to real time programmable
network, based on open source APIs. A
programmable network will allow network
behavior to be modified in real-time and new
applications and network services to be deployed
rapidly, independent of vendor development
cycles. Technological enablers to increase
programmability are NFV often called Network
Function Virtualization, concept to make telecom
infrastructure, capable of being directed with
software and Software Defined Networking
(SDN), will introduce programmable interfaces
to network functions, which is closed, proprietary
based currently. Technologies as NFV (network
function virtualization) and SDN (software
defined network) have potential to bring cloud
agility and elasticity in Telco environment.
NFV
Service providers’ networks are populated with a
large and increasing variety of proprietary
hardware appliances. To launch a new network
service, service provider has numerous
operational challenges. It requires the space and
power to accommodate new network elements,
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. 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. Network Functions Virtualization aims to
address these problems by leveraging standard IT
virtualization technology to consolidate many
network equipment types onto industry standard
high volume servers, switches and storage, which
could be located in Datacenters, Network Nodes
and in the end user premises. NFV architecture as
shown in figure 1, (ETSI GS NFV 002), separates
hardware from software, by introducing
virtualization layer.
Figure 1: NFV high level architecture
Figure 1 illustrates the high level NFV
framework. As such, three main working
domains are identified in NFV
1) Virtualised network function (VNF) as the
software implementation of a network
function which is capable of running over
NFV.
2) NFV infrastructure (NFVI), including
diversity of physical resources, hardware and
how these can be virtualised. NFVI supports the
execution of VNF.
3) NFV management and orchestration, which
covers the orchestration and lifecycle
management of hardware(physical resources)
and/or software resources that support
infrastructure virtualisation and the lifecycle
management of VNFs. NFV Management and
orchestration focuses on all virtualization specific
management tasks necessary in the NFV
framework.
SDN
SDN is an architectural framework for creating
intelligent networks that are programmable,
application aware, and more open. SDN allows
the network to transform into a more effective
business enabler. SDN architecture allows for a
fully programmable physical and virtual network
where service providers can deliver high-value
network services with speed and flexibility.
These programmability aspects allow dynamic
instantiation of services. In a very basic SDN
architecture, the "control plane" (that makes
decisions on where traffic is sent) is decoupled
from the "data plane” (that forwards traffic to the
selected destination). This decoupled architecture
not only allows for having programmable and
centralized control of network traffic but also
creates possibilities of creating new services for
enterprise customers via software applications.
SDN uses openflow protocol and open-source
stake development e.g. openstack, to expose
network capabilities in south bound and north
bound interfaces, as shown in figure 2.
Figure 2: SDN High Level Architecture
SDN architecture
Northbound
Manager
Mapping
Algorithm
Southbound
Manager
Figure 3: SDN Controller Generic Architecture
SDN architecture separates northbound and
southbound interfaces to provide agile
development of new services, as shown in figure
3.
SDN architecture has following building blocks:
1) Northbound Manager: NB manager manages
northbound interfaces with OSS/BSS
systems, CLI based service portals, or EMS,
PM systems. New services should be created
into service modelling plan, stored in
centralized database, and pushed into service
manager.
2) Southbound Manager: SB manager manages
southbound interfaces with network
resources i.e firewalls, IMS servers, EPC
routers etc. SB manager represents device
configurations and renders from data plan,
stored in database.
3) Data/Service Plan: Data and Service plans
are modelled in centralised database, in IETF
specified Yang modelling language. Any
new service, policy creation or modification
requires to manipulate service plan. Similarly
any resource configuration change, requires
to modify data plan. These changes are
further pushed into Northbound and
Southbound managers. Old configuration
states are stored into database, in case of
rollback scenarios.
4) Mapping Algorithm: Mapping between
service component and device configuration
is very crucial part of SDN controller.
Currently mapping between service
activating and device configuration,
consumes long time in programming
mapping logic. Mapping algorithm should be
able to map any services to any device for
centralized control and faster service/policy
deployment.
5) Yang modelling language: The data plane
and service plan are represented in modelling
language YANG. The Network
Configuration Protocol, NETCONF is an
IETF network management protocol, is being
adopted by major network equipment
providers and has gained strong industry
support. YANG, specified in RFC 6020 is a
data modelling language for the NETCONF
network configuration protocol. YANG
standardized the way to describe
configuration models which help industry to
have vendor neutral interoperable data
modelling language. YANG definitions
directly map to XML content. YANG was
specifically designed to model configuration
and state data in network devices, it meets
key requirements for a configuration data
modelling language. These requirements
include mechanisms to model operations and
content layers as well as being easily read and
understood by human implementers.
Business Applicability
Both SDN and NFV bring a number of business
benefits when implemented in the networks and
integrated with the business systems. We now
look at a couple of solution implementations and
the benefits that they bring in. Two uses cases are
identified 1) centralized policy function and 2)
VoLTE service deployment to showcase business
applicability.
Centralized Policy function
A service chain simply consists of a set of
network services, such as firewalls or core routers
that are interconnected through the network to
support end to end functionality.
In the past, building a service chain to support a
new services took a great deal of time and effort.
It meant acquiring network devices and cabling
them together in the required sequence. Each
service required a specialized hardware device,
and each device had to be individually configured
for service policy with its own command syntax.
The chance for error was high, and a problem in
one component could disrupt the entire network.
As shown in figure 4, to build the policy functions
for video services in IMS network, each element
in the service chain, has to be configured
individually. As video application load increase
over time, either service chain have to be
reconfigured or over-provisioned for future
growth. Hardware capacity needed to be sized to
support the maximum level of demand --
something which might only occur at particular
times of the year. Yet extra capacity has meant
extra capital investment.
Figure 4: Existing Service Chaining
SDN and NFV enable network managers to
quickly and inexpensively create, modify and
remove service chains.
SDN moves management functions out of the
hardware and places it in controller software that
executes in a server. As shown in figure 5, to
build the policy functions for video services in
IMS network, in NFV/SDN environment, is
much easier than traditional approach. SDN
controller will configure the policy functions in
entire chain, centrally by using open source APIs.
A standardized configuration protocol between
the controller and network devices replaces
proprietary device configuration languages. As
shown in figure 4, SDN controller has policy
manager and device manager(refer figure 3). At
Northbound interface, Policy manager will
interface with OSS/BSS system or service portal
using REST or CLI API. Similarly at southbound
interface device manager will interface network
resources to implement policy attributes, using
open source protocols wrapper e.g Openflow.
Because of NB and SB open interfaces, entire
policy enforcement function can be centralized
rather than fragmented. As a result, entire service
chains policy functions can be provisioned and
constantly reconfigured from the controller. In
that scenario, the chance for error is much smaller
since the controller software has an overall view
of the network, reducing the chance for
inconsistent device configurations.
Figure 5: NFV/SDN Service Chaining
NFV moves network functions out of dedicated
hardware devices and into software. Functions
that in the past required specialized hardware
devices can now be performed on standard x86
servers. Specialized packet handling hardware
has been added to standard servers to make this
possible. Moving network functions into software
means that building a service chain no longer
requires acquiring hardware. Network functions
typically execute as virtual machines under
control of a hypervisor. When more bandwidth is
required, an additional virtual machine can be
provisioned to take part of the load, or the initial
VM can be moved to a higher capacity server or
to one that is less heavily loaded by other
applications. There's no need to overprovision
since additional server-based capacity can be
added when needed.
VoLTE Service Deployment
Current NB and SB interfaces are vendor specific
and mostly proprietary by nature. This restricts
service provider’s ability to manage, manipulate
and consume services on demand and in near real
time, in short ability to govern services as cloud
computing services. The SDN architecture allows
for NB and SB APIs to facilitate faster
application development and programmability by
allowing API space for industry standard
languages as JAVA, REST, and Python. This
allows for having a vibrant network applications
ecosystem that can be used by customers to meet
business requirements. NFV, along with SDN
potentially offer capability to integrate multiple
virtual functions from different vendors and
ability to create virtual networks and manage by
third parties tools and capabilities currently
reserved only for equipment vendors.
Currently service provider has rely on equipment
vendors to add new network service e.g. VoLTE.
Figure 6: VoLTE Service Deployment in current scenario
VoLTE is VoIP service, offered using LTE as
access network and IMS as core network. To
deploy VoLTE in current scenarios, LTE network
has to be enhanced to support voice bearer path
and IMS network elements requires to support
VoLTE applications.
In LTE network, voice packets needs to be
prioritized compared to other data packets.
Telecm standard body, 3GPP has introduced QoS
framework to the purpose. QoS parameters are
used to identify and then prioritize voice packets
at layer 2 scheduler. These QoS parameters have
to be mapped to Diffserv model at transmission
network to maintain the voice priority.
In vendor controlled proprietary environment,
service provider has to depend on vendor
software releases to deploy VoLTE service.
Apart from that, application functionality has to
be aligned with Vendor specifications or service
provider has to bear customization charges. This
proprietary API based service deployment model
is shown in Figure 6.
NFV and SDN technologies address this vendor
lock-in situation, by opening up elements API for
third party development.. NFV separates
hardware from software to provide cloud-like
elasticity and SDN framework will expose
network capabilities though APIs. As shown in
Figure 7, with SDN controller based architecture,
virtualized LTE and IMS functions can be
centrally configured using Yang data models and
open APIs. SDN controller will move fragmented
configuration model into centralized model,
while NFV will provide hardware software
separation for independent scalability.
Figure 7: VoLTE service deployment in NFV/SDN

Summary
To counter the threat coming from cloud and
OTT providers, telecom service providers
requires to re-architect telco network, to design
and deploy new service rapidly. Technology
enablers as NFV and SDN have potential to drive
such telecom network re-architecture. NFV
framework consist of cloud technologies as
virtualization and orchestration for hardware
commoditization, while SDN promotes greater
programmability by exposing network
capabilities though open-stack APIs and Open-
flow standard. Ability to define network by open
APIs and virtualized functions, enable rapid
service deployment in Telco environment.
Abbreviation
OTT: Over the Top
API: Application Programmable interface
NFV: Network Function Virtualization
SDN: Software Defined Network
VNF: Virtual Network Function
ETSI: European Telecommunications Standards
Institute
OSS: Operation Support System
BSS: Business Support System
EMS: Element Management System
IMS: IP Multimedia System
LTE: Long Term Evolution
EPC: Evolved Packet Core
IETF: Internet Engineering Task Force
VoLTE: Voice over LTE
Diffserv: Differentiated Services
[8]Automating Network and Service
Configuration Using NETCONF and YANG by
Stefan Wallin and Claes Wikstrom (Tail-F
system)
About Authors
Vadan Mehta has obtained B.E in
telecommunications from Oslo University and
currently working as NGN consultant for client
AT&T mobility.
He is CCDA (cisco certified design association),
IPTD( IP telephony design expert), PMP and
ITILv3. He has 14 years of experience in wireless
telecommunications and authored white paper on
Necessity of Flat network Architecture at IEEE
India chapter wireless conclave. He is active
member of TMforum and The Open group.
Manish Singh has obtained his BE(Hons.) from
BITS Pilani India in Electrical & Electronics and
is currently working as Project Director &
Customer Delivery Manager for TechMahindra
AT&T LTE Test Program.
He has 21 years of experience in wireless
telecommunications across Europe, Asia and
USA. He has developed several innovative
solutions for UMTES RAN protocol testing and
validation. He is a UMTS and LTE RAN expert
and is active member of Small Cell forum,

Reference
[1] ETSI GS NFV-PER 002 V1.1.1 (2013-10)
[2] ETSI GS NFV-PER 002 V1.1.1 (2013-10)
[3]ETSI NFV Management and Orchestration -
An Overview by Mehmet Ersue
[4] Network Functions Virtualization: An
Introduction, Benefits, Enablers, Challenges
& Call for Action
[5] www.cloudnfv.com
[6] OpenDaylight - An Open Source Community
and Meritocracy for Software-Defined
Networking
[7] www.openstack.org