Virtualizing network services - the telecom cloud

1. The communications technology journal since 1924 2014 • 3
Virtualizing network services
– the telecom cloud
March 28, 2014

2. Virtualizing network services
– the telecom cloud
Inspired by a transformation in neighboring industry sectors toward providing information,
products and functions as services – XaaS – the telecommunication industry is evolving the
architecture of its systems and networks. This new generation of architecture is characterized
by a very high degree of abstraction and virtualization.
carry the transformational power that
isneededtoreapthebenefitsofferedby
higherlevelsofabstraction.
Modern virtualization technologies,
such as software-defined networking
(SDN), in combination with existing
toolsforstorageandcomputing,ensure
virtualization and abstraction for the
entire set of critical resources. The gen-
eral aim of SDN and NFV is to deliver
functions, networks and infrastruc-
ture as services rather than as features
of vertically integrated systems. This
enables operators to offer communica-
tion services at the right price points
for subscribers, by serving the next
generations of terminals like high-end
smartphones,tablets,and3Dglasses.In
addition,thisenablesoperatorstooffer
low-price connectivity to service pro-
viders of M2M communication, by sup-
porting devices like utility meters and
healthcareequipment.
Thenatureoftelecomstoday
Thenetworksetupfortelcoapplications
tends to be quite sophisticated, and
there are a number of factors that con-
tribute to this complexity, including:
the need for security zoning; overcom-
ingaddressingconstraints;therequire-
ment for a high degree of statefulness,
whichinturncreatesneedsforloadbal-
ancingandmechanismstoensurehigh
availability;aswellasthewaystandards
have been defined and legacy imple-
mentationchoices.
Telcoapplicationsoftenrequiremul-
tiple VPNs and virtual local area net-
works(VLANs),subnetswithadditional
routing,aswellassophisticatedloadbal-
ancers, firewalls, address translators,
transparent proxies, and QoS/policy-
based routing. The process to integrate
alloftheseelementsisoftenbothstatic
protocols and service quality – a model
that has served the industry well, until
recently.Butthesituationhaschanged.
Increased competition, the perceived
high cost of proprietary hardware and
the need for reduced complexity in net-
work design has led to the formation of
the Network Functions Virtualization
(NFV)consortium.Simplifiedoperation
of virtualized network platforms and
hardware-independent network func-
tionality are just some of this group’s
aims2
.
The benefits offered by next genera-
tion systems include rapid deployment
of new services, ease of scalability and
reduced duplication. These systems are
primarilybeingbuiltwithmass-market
technologies that capitalize on virtual-
ization and cloud techniques to man-
age resources in terms of their storage,
computational and networking needs.
Virtualization and the technologies
relatedtoit,suchascloudorchestration,
HENRIK BASILIER, MARIAN DARULA AND JOE WILKE
BOX A Terms and abbreviations
ADC application delivery controller
API application programming interface
ARPU average revenue per user
BFD Bidirectional Forwarding Detection
DMTF Distributed Management Task Force
EPC Evolved Packet Core
M2M machine-to-machine
NF network function
NFV Network Functions Virtualization
NIC network interface card
NOC network operations center
OAM operations, administration and
maintenance
ONF Open Networking Foundation
OSPF Open Shortest Path First
OSS operations support systems
OVF Open Virtualization Format
SAF Service Availability Forum
SBG Session Border Gateway
SDN software-defined networking
SLA Service Level Agreement
TCO total cost of ownership
VDC virtual data center
VLAN virtual local area network
VM virtual machine
VNF virtual network function
VR virtualized router
VRRP Virtual Router Redundancy Protocol
WAN wide area network
XaaS anything as a service
The demand for bandwidth
created by subscribers and
devices has been rising steadily
for a number of years. The
amount of data carried by mobile
networks is doubling roughly
every year1
, and the number of
connected machine-to-machine
(M2M) devices – sensors and
actuators – is expected to reach
50 billion by 2020. However,
average revenue per user (ARPU)
is declining in most markets, and
the price point for connectivity
for many M2M devices is low.
The subsequent catch-22 situation –
whereinfrastructuregrowthisneeded
tomeetincreaseddemandinthefaceof
hard-pressedrevenuemargins–isasig-
nificant innovation challenge for the
ICTindustry.
Traditional telecom product devel-
opment is deeply rooted in standards,
2
ERICSSON REVIEW • MARCH 28, 2014
The telco cloud

3. and manual, which is time consuming
and leads to inaccuracies. Being able
to integrate elements automatically,
through say automatic orchestration
with SDN technologies, is a vital step
in the creation of new generation sys-
tems that will reduce time to market
for the deployment of new services and
increaseoperationalflexibility.
Benefitsandcost
Foroperators,thereturnoninvestment
associatedwithmigratingnetworkser-
vices to the cloud comes in the form of
reducedTCO,improvedTTMandavery
high degree of automation in network
operation – all of which improve the
bottomline.
To guarantee continued service, a
migrated environment needs to pro-
videallnetworkingcapabilities,aswell
as ensure the interworking and por-
tability of telco applications. To keep
costsdown,theimpactofmigrationon
applications should be kept to a mini-
mum–however,withsomeapplication
adaptation,itispossibletofurthertake
advantage of the automation and elas-
ticity offered by cloud and virtualiza-
tiontechnologies.
This article describes the require-
ments placed on telco applications as a
result of increased abstraction, as well
as the challenges a telecom cloud must
overcome (including migration), and
how these challenges differ from the
general IT cloud. The article also gives
some insight into the implementation
aspectsofthetelecomcloud,whatkind
of services, APIs and capabilities are
expected, and what technologies will
beused.
Thetelecomcloud
An operator network can be described
as a set of solutions, such as EPC or IMS/
VoLTE, split over multiple organiza-
tional domains. In turn, these domains
consist of sets of telco applications that
interconnect using site infrastructure,
such as switches, routers, firewalls and
transportnetworks.
When a network is deployed virtu-
ally,organizationaldomainswithinthe
operatorbecomesatenantoftheshared
cloud infrastructure, which provides
virtualdatacenters(VDCs)thatserveas
resource containers and zones of isola-
tion.Operatorsolutionsaredeployedin
VDCs and telco applications and nodes
becometelcovirtualnetworkfunctions
(VNFs) – implemented as portable con-
tainers for multiple virtual machines
(VMs). As illustrated in Figure 1, the
cloud infrastructure fulfills the inter-
connect capability along with other
infrastructure requirements that are
provided by site infrastructure and
transport networks in non-virtualized
environments.
Interconnectivity needs to be main-
tained between virtualized and non-
virtualized networks, and domain
managersfortelcosolutions(OSSs)need
to be able to manage dedicated infra-
structureaswellasvirtualresources.
Telco systems and applications place
toughdemandsonthenetworkingcapa-
bilities of cloud infrastructure. This is
because the requirements of telco sys-
tems are much more stringent and var-
iedthangenericITapplications.Typical
telcosystemsneedsupportfor:
multipleroutingcontextsandrouting
protocols;
multipleVPNconnectionstoexternal
networks;
packet-load-balancingcapabilitiesfor
heavypayloadapplications–including
additionalcapabilitiesthanaretypically
includedinapplicationdelivery
controllers(ADCs);
supportforvirtualnetworkinterface
cards(NICs)–totrunklargenumbersof
VLANsandinterconnecttoexternal
networks;
pathdiversity;
servicechaining–forbump-in-the-wire
applications;
securityzoning;
heavy-dutyroutingbetweentenant
networks;
geo-redundancymechanisms;and
latency/QoScontrol.
In traditional networks, these features
are provided by the site infrastructure.
In the telecom cloud, these features
needtobereplicatedbythecloudinfra-
structureinsuchawaythattheycanbe
orchestrated, as orchestrated features
can be exposed through appropriate
abstractions, as well as being coupled
withadvancedsupportfordiscoverabil-
ityandtraceability.
In a cloud infrastructure, the con-
cepts of multi-tenancy and separation
of concerns are crucial, as they enable
organizations (tenants) to securely
sharethesamespaceandmanagetheir
ownvirtualresources–implementedas
isolated slices of the physical resources
(VDCsinotherwords).Isolationandsep-
arationarerequiredbyallfunctionsand
APIcomponents.
For tenants, cloud computing is ulti-
mately about increasing flexibility,
reducing complexity and time to mar-
ket,aswellasimprovingcost-efficiency.
Providers of cloud infrastructure ser-
vices can help tenants to achieve
FIGURE 1 The real-time telecom cloud
Cloud tenants,
virtual data centers (VDCs),
telco VNFs
Cloud tenants,
virtual data centers (VDCs),
telco VNFs
Telco
solutions and
applications
Telco
solutions and
applications
TransportTransport
Cloud
infrastructure(s)
Cloud
infrastructure(s)
3
ERICSSON REVIEW • MARCH 28, 2014

4. their telco VNFs, as well as of the solu-
tion/VDC level. To automate the alloca-
tion of all the requested resources, the
cloud infrastructure uses what is com-
monlyreferredtoasorchestrationtech-
nologies.IfWANconnectivityisneeded
for orchestration, it is provided by an
underlyingtransportdomain.
The basic networking capabilities
provided to a tenant through the VDC
constructcanrangeincomplexityfrom
verybasicL2linkstomultiplenetworks
with intra-routing. Advanced capabili-
ties,suchasfirewalling,loadbalancing
and service chaining can be ordered as
resources within a VDC. From the ten-
ant perspective, all network resources
are virtual and fully isolated. Although
SDN control can be exposed to the ten-
ant (for service chaining purposes, for
example), such control is restricted to
isolated slices of the network under
the management of the tenant SDN
controller.
To connect to other VDCs or another
network outside the cloud infrastruc-
ture, the data center needs to be con-
nected to the internet or to a private
VPN. The need for external connectiv-
ityshouldbedescribedbythetenantin
theformofconnectionpointsatthenet-
workedgesoftheVDC.Authorizationof
therequestedconnectivityisgrantedby
thecloudorchestrator,which(aspartof
the orchestration process) also config-
urestheactualrouting/switchingfunc-
tionsthatconnectnetworkswithinthe
data center to the outside. One of the
aimsofthetelecomcloudistoautomate
thispartoftheprocess.
Serviceestablishment
Setting up a telco service or solution
inside the cloud involves a number of
steps,whichcanbesummarizedas:
onboardinstantiabledescriptions/
templatesofthetelcoVNFs;
onboardinstantiabledescriptions/
templatesoftheVDCs;
instantiatethevirtualdatacenter–in
whichthecloudorchestratorallocates
resourcesforsharedusewithinaVDC;
instantiatethedesiredtelcoVNFswithin
theVDC–thecloudorchestrator
allocatestheresourcesneededforthe
VNFandbindsthemtotheVDC;and
configuretheapplication-specific
elementsofthetelcoVNFs.
Once a service is established, it enters
these goals by providing generic
abstractions of services with a high
degree of automated life cycle manage-
mentforresources.
To manage the complete life cycle of
application-layer functions contained
in VDCs and VNFs, each tenant needs
to provide the domain-manager func-
tionality that is specific to their solu-
tion domain. This manager interacts
with the cloud infrastructure domain
that manages the life cycle for virtual
resources, it maintains descriptions
of VDCs and VNFs, interacts with the
cloud orchestrator for resource cre-
ation/assignment/deletion, as well as
integrating with application-specific
management.
To take advantage of the elasticity
that cloud computing provides, to, for
example, scale out operations or direct
network control, the application layer
needs to adapt to real-time changes
in resources. Descriptors of VDCs and
VNFs exchanged with the cloud infra-
structure serve as a contract between
the two responsibility domains, and
mayalsoincludeSLAs.
Avirtualdatacenterisamanagedcol-
lection of computational, storage and
networking slices provided to a tenant
bythecloudinfrastructurefromitspool
ofresources–whichmaybedistributed
across a set of data centers. Resources
assigned to a given tenant are isolated
fromothertenants,butcanbeintercon-
nected through external networks and
otherVDCs.Thetenantdetermineshow
this interconnection takes place on the
basisoftheirsecuritypolicies.
As illustrated in Figure 2, tenants
can deploy network solutions within
a VDC as a set of interconnected telco
VNFs. For internal and external net-
working purposes, each tenant is
required to supply descriptions of all
Data
center
Data
center
External
networks
External
networks
VDC managementVDC management
WANWAN
Cloud infrastructure domainCloud infrastructure domain
Cloud infrastructureCloud infrastructure
Cloud orchestratorCloud orchestrator
Tenant 1Tenant 1
Tenant
domain
manager
Tenant
domain
manager
Tenant
domain
manager
Tenant
domain
manager
Tenant 2Tenant 2
Telco
VNF
Telco
VNF
Telco
VNF
Telco
VNF
VDCVDC
Domain-
specific
life cycle
management
Domain-
specific
life cycle
management
Domain-
specific
life cycle
management
Domain-
specific
life cycle
management
Telco
VNF
Telco
VNF
Telco
VNF
Telco
VNF
VDCVDC
FIGURE 2 Multi-tenant cloud architecture
4
ERICSSON REVIEW • MARCH 28, 2014
The telco cloud

5. service assurance mode, where the
ability to both observe and trace the
requestedVDCandVNFsiskey.
Automatingorchestration
To be able to automate processes
through orchestration, a number of
service establishment descriptions are
needed,including:
descriptionsofthetelcoVNF,specifying
itsneeds,suchascomputational,
storageandnetworkingresourcesalong
withVMstartorderinstructions;
descriptionsofotherservicesand
resourcesrequiredbythecloudsystem,
suchasfirewallingandloadbalancing;
descriptionsofthenetworking
requirementfortheVDCasawhole,
includinginternalconnectivityamong
VNFsaswellasexternalconnectivity,
whichincludesdefinitionsofservice
chains.
For automated orchestration to work,
essentially everything that in the past
was configured manually must now be
made into machine-readable descrip-
tion formats. To guide the orchestra-
tionofresources,thesedescriptionsalso
includeSLA-relatedparameters,suchas
affinity/anti-affinity rules and latency
requirements.
As illustrated in Figure 3, the rela-
tionships between the different types
of descriptions need to be managed.
A telco VNF (and its constituent parts)
needs to connect with networks inside
and outside the virtual data center. As
such, they define the logical connec-
tion points that the VDC networking
description needs to resolve into net-
works defined within the VDC descrip-
tion.Likewise,theVDCdescriptorneeds
to refer to logical connection points to
(VDC or) external networks, which the
cloud domain manager resolves into
realnetworkconnections.
To support elastic operations such as
scale out, with flexible and automated
deployment of VNFs and VDCs, their
descriptors(theVDCsandVNFs)should
be viewed as templates for all resource
assignments. As such, the containing
VDC defines the network context for a
VNFinstanceandscaleoutVMsusethe
VNFdescriptorasatemplate.
The cloud infrastructure uses the
descriptions provided by the tenant to
orchestrate virtual networks as well
as all other resources. Virtualized
Infrastructure Managers (such as
OpenStack) orchestrate resource
requestsacrossmultiplesitesandlayers
of functionality, using SDN controllers
to create virtual network connections
derivedfromtheprovideddescriptions.
Automatingdeployment
To automate deployment of telco VNFs
in virtual data centers and to reduce
the effort required to support deploy-
ment in different virtualized target
environments, applications should
be made available and packaged in a
hypervisor-neutral virtual-machine
file format – preferably the Open
Cloud
edge
Cloud
edge
Cloud
edge
aaS
Cloud
edge
aaS
External
VPN 2
External
VPN 2
External
transport
WAN
External
transport
WAN
External
VPN 1
External
VPN 1
VMVM VMVM
LBaaSLBaaS
VMVM
VDC execution (tenant view)VDC execution (tenant view)
Telco VNF 1Telco VNF 1
Telco VNF 2Telco VNF 2
VDC
network
VDC
network
VDC
network
VDC
network
Internal
network
Internal
network
FIGURE 3 Logical connection points in VDC networking
VM1VM1 VM2VM2 VM3VM3 VM4VM4
OAMOAM
S-CSCF/BGCFS-CSCF/BGCF
I-CSCFI-CSCF
VM5VM5 VM6VM6
CSCFCSCF I-CSCFI-CSCF S-CSCFS-CSCF BGCFBGCF
Scalable distributed systemScalable distributed system
VNF
internal
VLAN
VNF
internal
VLAN
OAM
VLAN
OAM
VLAN
Application layer
signaling VLANs
Application layer
signaling VLANs
FIGURE 4 An example of telco VNF realized as a cluster of VMs
accommodating multiple logical fucntions
5
ERICSSON REVIEW • MARCH 28, 2014

6. cluster requires reliable, secure and
high performance intra-cluster com-
munication as well as communica-
tion with neighboring networks. This
is implemented by adopting L2, VLAN
andIP-VPNtechnologiesintheVDC.
To separate the communication for
different trust domains, VMs use dif-
ferentVLANs.Tostartwith,thereisone
VLAN for communication among the
VMs within the telco VNF; one VLAN
for operations, administration and
maintenance (OAM) communication
betweenthetelcoVNFandtheOSS/net-
work operations center (NOC); and one
VLANforapplicationlayercommunica-
tionamongthenetworkfunctions(NFs)
intheIMSnetworkarchitecture.
In addition, some telco VNFs, such as
Session Border Gateway (SBG), commu-
nicate with users and other operators;
such VNFs require an additional VLAN
peraccessdomainandperinterconnect
network.
For security and L3 load balancing
reasons,IProutersareusedforcommu-
nication among telco VNFs – there is
no direct VLAN connectivity between
telco VNFs. This concept is illustrated
inFigure 5.
Thebestsolutionforvirtualdatacen-
tersistodeploynodestogetherwithvir-
tualized routers (VRs). VRs host router
functions and serve different traffic
types, such as application signaling or
OAM. VRs – one per security domain
– are used by telco VNFs to communi-
catewitheachotherandexternally.VRs
supportOpenShortestPathFirst(OSPF),
Bidirectional Forwarding Detection
(BFD) and link load balancing for the
telco VNF as well as forwarding filters.
Thecompletesolution,includingVNFs,
can be described by, for example, an
evolvedOVFdescription,enablingauto-
maticdeploymentwithouttheneedfor
anymanualcorrection.
Qualityremainsthesame
Traditional telecom networks are
designed to provide uninterrupted ser-
viceandasuperioruserexperience.The
high availability and real-time charac-
teristics of telco applications supported
by related infrastructure capabilities
are key capabilities that help opera-
tors achieve their targeted levels of ser-
vice and QoE, and these targets are the
same for both traditional and virtual
VMVM VMVM VMVM VMVM
VRVR VRVR
VRRPVRRP
VNFVNF
VMVM VMVM VMVM VMVM
VNFVNF
Application signaling VPN
OAM VPN
Application signaling VPN
OAM VPN
FIGURE 5 Connectivity and transport solution among telco VNFs
Virtualization Format (OVF) spec-
ified by the Distributed Management
Task Force (DMTF). When deploying
telco solutions, the set of OVF files con-
taining deployment instructions is
ingested by the cloud manager orches-
tration function, and the network solu-
tion is deployed accordingly. Similarly,
the VDC needs to be described in a for-
matthatissuitableforautomation.Both
descriptor levels need to encompass all
applicablenetworking.
Telcoapplicationsinthecloud
A cloud-based networking solution
needs to support QoS to guarantee tele-
comqualityandreal-timebehavior,and
atthesametimeitneedstobeflexibleto
automatedeploymentandconnectivity
withintheVNF–implementedasaclus-
terforscaling.
An application implements a logical
function, and its interfaces are defined
by standards like 3GPP and IETF. Telco
VNFs accommodate one or more logi-
cal functions and are usually designed
to be used by large numbers of sub-
scribers and to support heavy traffic
loads. Scalable capacity is a fundamen-
tal part of telco application design, and
implementation typically uses cluster
architecture.Thisappliestotraditional
(non-cloud) deployment as well as
deployment in a virtual data center. In
the virtual environment, the software
of a telco VNF cluster runs on a set of
(OS-inclusive)virtualmachines(VMs).
A telco VNF built on a clustered
architecture can be dimensioned to
fit expected capacity by deploying the
right number of VMs. The application,
however,isexposedasasingleentityon
a network level, hiding internal struc-
ture from the surroundings and thus
providing a manageable network solu-
tionwithlowopex.
Suchanarchitectureallowsthetelco
VNFtobescaleddynamicallytofittraf-
fic conditions, where scaling can be
achievedbyaddingorremovingcluster
members.Assuch,thevirtualizedsolu-
tionprovidesobviousadvantageswhen
scalingcanbeachievedbysimplyturn-
ingaVMonoroff.
The entire cloud deployment needs
to be optimized from a transport and
storage perspective, so that, for exam-
ple,anincreaseordecreaseinavailable
resources automatically generates a
corresponding adaptation of transport
layerbandwidthandstoragecapacity.
Proper operation of a telco VNF
6
ERICSSON REVIEW • MARCH 28, 2014
The telco cloud

7. OSS/BSSOSS/BSS
EMS 1EMS 1 EMS 2EMS 2 EMS 3EMS 3
VNF 1VNF 1
Virtual
computing
Virtual
computing
Computing
hardware
Computing
hardware
Network
hardware
Network
hardware
Execution reference point
Other reference point
Main NFV reference point
Execution reference point
Other reference point
Main NFV reference point
Hardware resourcesHardware resources
Storage
hardware
Storage
hardware
Virtual
storage
Virtual
storage
Virtualization layerVirtualization layer
Vn-NfVn-Nf
Os-MaOs-Ma
Or-VnfmOr-Vnfm
Or-ViOr-Vi
Vi-VnfmVi-Vnfm
Se-MaSe-Ma
Ve-VnfmVe-Vnfm
Nf-ViNf-Vi
Vi-HaVi-Ha
NFVINFVI
Virtual
network
Virtual
network
VNF 2VNF 2 VNF 3VNF 3
Service, VNF and infrastructure
description
Service, VNF and infrastructure
description
OrchestratorOrchestrator
NFV management and orchestrationNFV management and orchestration
VNF
manager(s)
VNF
manager(s)
Virtualized
infrastructure
manager(s)
Virtualized
infrastructure
manager(s)
FIGURE 6 NFV reference architecture
environments.However,virtualization
posesadditionalchallengesthatneedto
beovercome.
Telco VNFs typically include built-in
supportforresilience,suchasavailabil-
ity support in core middleware based
on OpenSAF. Consequently, certain
rules need to be taken into consider-
ation when deploying telco VNF clus-
ters in a virtualized environment. For
example,it’snotagoodideatodeployall
VMs on the same hardware, as a hard-
warefailurewouldcausecompletenode
outage. Such deployment rules can be
specifiedinOVF,sothatcorrectdeploy-
ment is performed when a cloud man-
ager ingests the OVF file during initial
deployment.
Telco applications can in turn make
the most of features provided by the
infrastructure to, for example, main-
tain availability. For example, VMs can
be automatically restarted on different
hardwareintheeventofafailure.
Industrymovements
Awidevarietyoforganizations,suchas
ETSI NFV, OpenStack, OpenDaylight,
DMTF, ONF and IETF, are involved in
the industry shift to cloud-deployed
solutions. For operators, ETSI NFV has
a more prominent role as a result of its
developmentofoverallframeworksand
architecturesand attentiontotelecom-
specificrequirements.
NFV was established as an industry
consortiumtoensurealignmentwithin
the telecom segment, enabling opera-
tors to deploy network functions in an
automated way on state-of-the art com-
putational and storage entities. Such a
move from vertically-integrated pur-
pose-builtsystemstohigh-scalegeneric
hardwareisanattractiveoneforopera-
tors, as it results in more homogenous
systems, reducing the costs associ-
ated with complexity and proprietary
hardware.
Thisabilitytoreplacestaticandman-
ualconfiguration,includingoperations
such as cabling, will be an important
capability of efficient future systems.
This is reflected in the NFV reference
architecture, which is illustrated in
Figure 6 as the NFV management and
orchestrationdomain.
Fromthemanagementandorchestra-
tion domain, reference points connect
the layers in the non-management
MTASMTAS L3aaSL3aaS N-SBCN-SBC LBaaSLBaaS
iCSCFiCSCF sCSCFsCSCF MRFMRF BGFBGF
L3aaSL3aaS FWaaSFWaaS
HSSHSSL3aaSL3aaSCUDBCUDB L3aaSL3aaS
IP
works
IP
works
A-SBCA-SBC LBaaSLBaaS L3aaSL3aaS FWaaSFWaaS
L3aaSL3aaS VPN
aaS
VPN
aaS
FWaaSFWaaS
GRXGRX
OMOM
AccessAccess
FIGURE 7 IMS core network example
7
ERICSSON REVIEW • MARCH 28, 2014

8. 1. Ericsson, November 2013, Mobility
Report, available at: http://www.
ericsson.com/res/docs/2013/
ericsson-mobility-report-
november-2013.pdf
2. ETSI, NFV role and activities,
available at: http://www.etsi.
org/technologies-clusters/
technologies/nfv
References
domain, which contains: a support
systems layer (OSS/BSS), a layer repre-
senting the virtualized network func-
tions, and a third layer (NFVI) that
represents the infrastructure con-
taining both virtualized and physical
resources.
Inthenearfuture,ETSINFVrequire-
ments will be translated into appropri-
atestandards.
Examplecase–IMS
AnIMScorenetworkisbasedonstan-
dardized interconnected logical func-
tions whose operation in a virtual data
center would be supported by addi-
tional infrastructure-related functions
such as firewalling and load balancing.
Figure 7 illustrates an example IMS
corenetwork.
Cloud deployment creates the possi-
bility to implement multiple instances
of IMS core networks to serve different
tenants by utilizing the multi-tenant
capability of the cloud infrastructure.
The set of telco VNFs that implements
a given tenant’s IMS core network is
deployed in the VDC dedicated to the
tenant.Anexampleofsuchdeployment
is illustrated in Figure 8. Tenants are
deployedoverasharedcloudinfrastruc-
ture in which the networking solution
guarantees tenant separation – fulfill-
ing security requirements and fair use
ofresources.
As Figure 8 illustrates, the require-
ments placed on the cloud infrastruc-
ture are complex. Advanced VLAN
handling for telco VNFs is required – as
is path redundancy, the ability to cope
with large numbers of VLANs for SBG
access, interconnect for multiple enter-
prises, and routing and complex inter-
connect with legacy networks/VPNs
–andalloftheserequirementsnotonly
needtobeimplemented,theyalsoneed
tobeautomated.Thefunctionalitypro-
vided by the virtual data center needs
to cover all of these aspects, on top of
providing true tenant separation, real-
time performance, geographical distri-
bution and telecom-grade availability.
Automationanddynamicityarekeyele-
mentstoprovidingacloudofferingasa
servicebasedonanIMScore.AVDCcan
be instantiated from a description on
demand, resulting in tenant networks
beingcreatedormodified.Interconnect
isestablishedautomaticallybytheinfra-
structure using orchestration and SDN
technologies. The domain manager for
the IMS application is responsible for
thesesteps,aswellasallotherlifecycle
management, including, for example,
runtimescaleoutoperations.
Conclusion
Traditional network architecture is
often built on proprietary hardware.
Telecom systems are by nature verti-
cal – inseparable – towers that become
overlycomplexandareasaresultcostly
tooperate.SpearheadedbytheITindus-
try,ashifttowardprovidingeverything
as a service is taking place. Adopting
a similar approach for network func-
tionsisonewayforoperatorstoexpand
infrastructure.
Some of the benefits of this type of
networktransformationare:
reducedcomplexity–whichlowers
runningcosts;
simplifiedinandoutscalability–which
makesefficientuseofnetwork
resourcesandsupportsdynamicability
torespondtochangesincapacity
demand;and
reducedtimetomarketfornewservices.
In addition to enabling new benefits
andopportunities,thecloudinfrastruc-
ture must ensure the robustness, per-
formance,securityandinteroperability
for telco applications, minimizing the
costs induced by the transformation
itself. This requires a system that pro-
vides telco apps with a smooth transi-
tionandreal-timefullytelecom-adapted
network support, while providing new
sets of enablers that act as a bridge to a
neweraofcloud-empoweredtelcoappli-
cationsandsolutions.
Tenant 1
network
Tenant 1
network
Tenant 1 IMS networkTenant 1 IMS network
OAMOAM
SignalingSignaling
MediaMedia
OAMOAM
SignalingSignaling
MediaMedia
Tenant 2 IMS networkTenant 2 IMS network
NOCNOC
OAMOAM StorageStorage
Central
storage
AccessAccessAccessAccess
CoreCore
Tenant1Tenant1Tenant2Tenant2
Tenant 2
network
Tenant 2
network
VRVR
DC
switch
FW
DC
switch
FW
VRVR VRVR
CSCF
cluster
CSCF
cluster
HSS
cluster
HSS
cluster
MTAS
cluster
MTAS
cluster
MFRPMFRPIDNSIDNSPGMPGM
VRVR VRVR VRVR
CSCF
cluster
CSCF
cluster
HSS
cluster
HSS
cluster
MTAS
cluster
MTAS
cluster
MFRPMFRPIDNSIDNSPGMPGM
SBGSBG
FIGURE 8 Multi-tenant multi-instance IMS network in VDC
8
ERICSSON REVIEW • MARCH 28, 2014
The telco cloud

9. To bring you the
best of Ericsson’s
research world, our
employees have been
writing articles for
Ericsson Review –
our communications
technology journal
– since 1924. Today,
Ericsson Review
articles have a two-to-
five year perspective
and our objective is
to provide you with up-to-date insights on how
things are shaping up for the Networked Society.
Address :
Ericsson
SE-164 83 Stockholm, Sweden
Phone: +46 8 719 00 00
Publishing:
Ericsson Review articles and additional material
are pub ished on: www ericsson.com/review.
Use the RSS feed to stay informed of the latest
updates.
Ericsson Technology Insights
All Ericsson Review articles are available on the
Ericsson Technology Insights app available for
Android and iOS devices. The link
for your device is on the Ericsson
Review website: www.ericsson.com/
review. If you are viewing this digitally,
you can:
download from Google Play or
download from the App Store
Publisher: Ulf Ewaldsson
Editorial board:
Håkan Andersson, Hans Antvik,
Ulrika Bergström, Joakim Cerwall,
Deirdre P. Doyle, Dan Fahrman, Anita Frisell,
Jonas Högberg, Patrik Jestin, Magnus Karlsson,
Cenk Kirbas, Sara Kullman, Börje Lundwall,
Hans Mickelsson, Ulf Olsson, Patrik Regårdh,
Patrik Roséen and Gunnar Thrysin
Editor:
Deirdre P. Doyle
deirdre.doyle@jgcommunication se
Contributors:
Paul Eade, Nathan Hegedus and
Ian Nicholson
Art director and layout:
Carola Pilarz
Illustrations:
Claes-Göran Andersson
ISSN: 0014-0171
Volume: 91, 2014
Henrik Basilier
is an expert at Business
Unit Networks. He has
worked for Ericsson since
1991 in a wide area of
subjects and roles. He is currently
engaged in internal RD studies and
customer cooperation in the areas of
cloud, virtualization and SDN. He holds
an M.Sc. in computer science and
technology from the Institute of
Technology at Linköping University,
Sweden.
Marian Darula
is head of Network
Transformation at
Development Unit Core
Networks, Architectures
and Technology. He is currently leading
the technology project for telecom
networks transformation adopting
cloud technologies and NFV. He holds a
Ph.D. in theoretical electronics from the
Institute of Electrical Engineering,
Slovak Academy of Sciences,
Bratislava, Slovakia and a degree in
applied mathematics and software
engineering from Czech Technical
University, Prague, Czech Republic.
Joe Wilke
is head of Development
Unit IP Broadband
Technology Aachen and
currently manages the
technology leadership program for
network virtualization and cloud. He
holds a degree in electrical engineering
from the University of Aachen,
Germany and a degree in engineering
and business from the University of
Hagen, Germany.
9
ERICSSON REVIEW • MARCH 28, 2014

10. Ericsson
SE-164 83 Stockholm, Sweden
Phone: + 46 10 719 0000
ISSN 0014-0171
284 23-3223 | Uen
© Ericsson AB 2014