Virtualizing network services

The communications technology journal since 1924 2014 • 3

Virtualizing network services – the telecom cloudMarch 28, 2014

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 is needed to reap the benefits offered by higher levels of abstraction.

Modern virtualization technologies, such as software-defined networking (SDN), in combination with existing tools for storage and computing, 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, and 3D glasses. In addition, this enables operators to offer low-price connectivity to service pro-viders of M2M communication, by sup-porting devices like utility meters and health care equipment.

The nature of telecoms todayThe network setup for telco applications 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-ing addressing constraints; the require-ment for a high degree of statefulness, which in turn creates needs for load bal-ancing and mechanisms to ensure high availability; as well as the way standards have been defined and legacy imple-mentation choices.

Telco applications often require mul-tiple VPNs and virtual local area net-works (VLANs), subnets with additional routing, as well as sophisticated load bal-ancers, firewalls, address translators, transparent proxies, and QoS/policy-based routing. The process to integrate all of these elements is often both static

protocols and service quality – a model that has served the industry well, until recently. But the situation has changed. 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. Simplified operation 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 primarily being built with mass-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 related to it, such as cloud orchestration,

H E N R I K BA SI L I E R, M A R I A N DA RU L A A N D JOE W I L K E

BOX A Terms and abbreviations

ADC application delivery controllerAPI application programming interfaceARPU average revenue per userBFD Bidirectional Forwarding DetectionDMTF Distributed Management Task ForceEPC Evolved Packet CoreM2M machine-to-machineNF network functionNFV Network Functions VirtualizationNIC network interface cardNOC network operations centerOAM operations, administration and maintenanceONF Open Networking FoundationOSPF Open Shortest Path First

OSS operations support systemsOVF Open Virtualization FormatSAF Service Availability ForumSBG Session Border GatewaySDN software-definednetworkingSLA Service Level AgreementTCO total cost of ownershipVDC virtual data centerVLAN virtual local area networkVM virtual machineVNF virtual network functionVR virtualized routerVRRP Virtual Router Redundancy ProtocolWAN wide area networkXaaS 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 – where infrastructure growth is needed to meet increased demand in the face of hard-pressed revenue margins – is a sig-nificant innovation challenge for the ICT industry.

Traditional telecom product devel-opment is deeply rooted in standards,

2

E R I C S S O N R E V I E W • MARCH 28, 2014

The telco cloud

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 increase operational flexibility.

Benefits and cost For operators, the return on investment associated with migrating network ser-vices to the cloud comes in the form of reduced TCO, improved TTM and a very high degree of automation in network operation – all of which improve the bottom line.

To guarantee continued service, a migrated environment needs to pro-vide all networking capabilities, as well as ensure the interworking and por-tability of telco applications. To keep costs down, the impact of migration on applications should be kept to a mini-mum – however, with some application adaptation, it is possible to further take advantage of the automation and elas-ticity offered by cloud and virtualiza-tion technologies.

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 aspects of the telecom cloud, what kind of services, APIs and capabilities are expected, and what technologies will be used.

The telecom cloud 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 transport networks.

When a network is deployed virtu-ally, organizational domains within the operator becomes a tenant of the shared cloud infrastructure, which provides virtual data centers (VDCs) that serve as resource containers and zones of isola-tion. Operator solutions are deployed in

VDCs and telco applications and nodes become telco virtual network functions (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 managers for telco solutions (OSSs) need to be able to manage dedicated infra-structure as well as virtual resources.

Telco systems and applications place tough demands on the networking capa-bilities of cloud infrastructure. This is because the requirements of telco sys-tems are much more stringent and var-ied than generic IT applications. Typical telco systems need support for:

multiple routing contexts and routing protocols;multiple VPN connections to external networks;packet-load-balancing capabilities for heavy payload applications – including additional capabilities than are typically included in application delivery controllers (ADCs); support for virtual network interface cards (NICs) – to trunk large numbers of VLANs and interconnect to external

networks;path diversity;service chaining – for bump-in-the-wire applications;security zoning;heavy-duty routing between tenant networks; geo-redundancy mechanisms; and latency/QoS control.

In traditional networks, these features are provided by the site infrastructure. In the telecom cloud, these features need to be replicated by the cloud infra-structure in such a way that they can be orchestrated, as orchestrated features can be exposed through appropriate abstractions, as well as being coupled with advanced support for discoverabil-ity and traceability.

In a cloud infrastructure, the con-cepts of multi-tenancy and separation of concerns are crucial, as they enable organizations (tenants) to securely share the same space and manage their own virtual resources – implemented as isolated slices of the physical resources (VDCs in other words). Isolation and sep-aration are required by all functions and API components.

For tenants, cloud computing is ulti-mately about increasing flexibility, reducing complexity and time to mar-ket, as well as improving cost-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

Telcosolutions andapplications

Telcosolutions andapplications

TransportTransport

Cloudinfrastructure(s)

Cloudinfrastructure(s)

3


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-monly referred to as orchestration tech-nologies. If WAN connectivity is needed for orchestration, it is provided by an underlying transport domain.

The basic networking capabilities provided to a tenant through the VDC construct can range in complexity from very basic L2 links to multiple networks with intra-routing. Advanced capabili-ties, such as firewalling, load balancing 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-ity should be described by the tenant in the form of connection points at the net-work edges of the VDC. Authorization of the requested connectivity is granted by the cloud orchestrator, which (as part of the orchestration process) also config-ures the actual routing/switching func-tions that connect networks within the data center to the outside. One of the aims of the telecom cloud is to automate this part of the process.

Service establishment Setting up a telco service or solution inside the cloud involves a number of steps, which can be summarized as:

onboard instantiable descriptions/templates of the telco VNFs; onboard instantiable descriptions/templates of the VDCs;instantiate the virtual data center – in which the cloud orchestrator allocates resources for shared use within a VDC;instantiate the desired telco VNFs within the VDC – the cloud orchestrator allocates the resources needed for the VNF and binds them to the VDC; andconfigure the application-specific elements of the telco VNFs.

Once a service is established, it enters

these goals by providing generic abstractions of services with a high degree of automated life cycle manage-ment for resources.

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 may also include SLAs.

A virtual data center is a managed col-lection of computational, storage and networking slices provided to a tenant by the cloud infrastructure from its pool of resources – which may be distributed across a set of data centers. Resources assigned to a given tenant are isolated from other tenants, but can be intercon-nected through external networks and other VDCs. The tenant determines how this interconnection takes place on the basis of their security policies.

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

Datacenter

Datacenter

ExternalnetworksExternalnetworks

VDC managementVDC management

WANWAN

Cloud infrastructure domainCloud infrastructure domain

Cloud infrastructureCloud infrastructure

Cloud orchestratorCloud orchestrator

Tenant 1Tenant 1

Tenantdomainmanager

Tenantdomainmanager

Tenantdomainmanager

Tenantdomainmanager

Tenant 2Tenant 2

TelcoVNFTelcoVNF

TelcoVNFTelcoVNF

VDCVDC

Domain-specific

life cycle management

Domain-specific


Domain-specific


Domain-specific


TelcoVNFTelcoVNF

TelcoVNFTelcoVNF

VDCVDC

FIGURE 2 Multi-tenant cloud architecture

4


The telco cloud

service assurance mode, where the ability to both observe and trace the requested VDC and VNFs is key.

Automating orchestration To be able to automate processes through orchestration, a number of service establishment descriptions are needed, including:

descriptions of the telco VNF, specifying its needs, such as computational, storage and networking resources along with VM start order instructions; descriptions of other services and resources required by the cloud system, such as firewalling and load balancing;descriptions of the networking requirement for the VDC as a whole, including internal connectivity among VNFs as well as external connectivity, which includes definitions of service 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-tion of resources, these descriptions also include SLA-related parameters, such as 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, the VDC descriptor needs to refer to logical connection points to (VDC or) external networks, which the cloud domain manager resolves into real network connections.

To support elastic operations such as scale out, with flexible and automated deployment of VNFs and VDCs, their descriptors (the VDCs and VNFs) should be viewed as templates for all resource assignments. As such, the containing VDC defines the network context for a VNF instance and scale out VMs use the VNF descriptor as a template.

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 requests across multiple sites and layers of functionality, using SDN controllers to create virtual network connections derived from the provided descriptions.

Automating deployment

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

CloudedgeCloudedge

CloudedgeaaS

CloudedgeaaS

ExternalVPN 2

ExternalVPN 2

Externaltransport

WAN

Externaltransport

WAN

ExternalVPN 1

ExternalVPN 1

VMVM VMVM

LBaaSLBaaS

VMVM

VDC execution (tenant view)VDC execution (tenant view)

Telco VNF 1Telco VNF 1

Telco VNF 2Telco VNF 2

VDCnetwork

VDCnetwork

VDCnetwork

VDCnetwork

InternalnetworkInternalnetwork

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

VNFinternalVLAN

VNFinternalVLAN

OAMVLANOAMVLAN

Application layersignaling VLANsApplication layersignaling VLANs

FIGURE 4 An example of telco VNF realized as a cluster of VMs accommodating multiple logical fucntions

5


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 and IP-VPN technologies in the VDC.

To separate the communication for different trust domains, VMs use dif-ferent VLANs. To start with, there is one VLAN for communication among the VMs within the telco VNF; one VLAN for operations, administration and maintenance (OAM) communication between the telco VNF and the OSS/net-work operations center (NOC); and one VLAN for application layer communica-tion among the network functions (NFs) in the IMS network architecture.

In addition, some telco VNFs, such as Session Border Gateway (SBG), commu-nicate with users and other operators; such VNFs require an additional VLAN per access domain and per interconnect network.

For security and L3 load balancing reasons, IP routers are used for commu-nication among telco VNFs – there is no direct VLAN connectivity between telco VNFs. This concept is illustrated in Figure 5.

The best solution for virtual data cen-ters is to deploy nodes together with vir-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-cate with each other and externally. VRs support Open Shortest Path First (OSPF), Bidirectional Forwarding Detection (BFD) and link load balancing for the telco VNF as well as forwarding filters. The complete solution, including VNFs, can be described by, for example, an evolved OVF description, enabling auto-matic deployment without the need for any manual correction.

Quality remains the same Traditional telecom networks are designed to provide uninterrupted ser-vice and a superior user experience. 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 VPNOAM VPNApplication signaling VPNOAM 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-mat that is suitable for automation. Both descriptor levels need to encompass all applicable networking.

Telco applications in the cloud A cloud-based networking solution needs to support QoS to guarantee tele-com quality and real-time behavior, and at the same time it needs to be flexible to automate deployment and connectivity within the VNF – implemented as a clus-ter for scaling.

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. This applies to traditional (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) virtual machines (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, is exposed as a single entity on a network level, hiding internal struc-ture from the surroundings and thus providing a manageable network solu-tion with low opex.

Such an architecture allows the telco VNF to be scaled dynamically to fit traf-fic conditions, where scaling can be achieved by adding or removing cluster members. As such, the virtualized solu-tion provides obvious advantages when scaling can be achieved by simply turn-ing a VM on or off.

The entire cloud deployment needs to be optimized from a transport and storage perspective, so that, for exam-ple, an increase or decrease in available resources automatically generates a corresponding adaptation of transport layer bandwidth and storage capacity.

Proper operation of a telco VNF

6


The telco cloud

OSS/BSSOSS/BSS

EMS 1EMS 1 EMS 2EMS 2 EMS 3EMS 3

VNF 1VNF 1

Virtualcomputing

Virtualcomputing

Computinghardware

Computinghardware

NetworkhardwareNetworkhardware

Execution reference pointOther reference pointMain NFV reference point

Execution reference pointOther reference pointMain NFV reference point

Hardware resourcesHardware resourcesStorage

hardwareStorage

hardware

VirtualstorageVirtual

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

VirtualnetworkVirtual

network

VNF 2VNF 2 VNF 3VNF 3

Service, VNF and infrastructuredescription

Service, VNF and infrastructuredescription

OrchestratorOrchestrator

NFV management and orchestrationNFV management and orchestration

VNFmanager(s)

VNFmanager(s)

Virtualizedinfrastructuremanager(s)

Virtualizedinfrastructuremanager(s)

FIGURE 6 NFV reference architectureenvironments. However, virtualization poses additional challenges that need to be overcome.

Telco VNFs typically include built-in support for resilience, such as availabil-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’s not a good idea to deploy all VMs on the same hardware, as a hard-ware failure would cause complete node outage. Such deployment rules can be specified in OVF, so that correct deploy-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 hardware in the event of a failure.

Industry movements A wide variety of organizations, such as 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 development of overall frameworks and architectures and attention to telecom-specific requirements.

NFV was established as an industry consortium to ensure alignment within 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-built systems to high-scale generic hardware is an attractive one for opera-tors, as it results in more homogenous systems, reducing the costs associ-ated with complexity and proprietary hardware.

This ability to replace static and man-ual configuration, including operations 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 orchestration domain.

From the management and orchestra-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

IPworks

IPworks

A-SBCA-SBC LBaaSLBaaS L3aaSL3aaS FWaaSFWaaS

L3aaSL3aaS VPNaaSVPNaaS FWaaSFWaaS

GRXGRX

OMOM

AccessAccess

FIGURE 7 IMS core network example

7


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.

In the near future, ETSI NFV require-ments will be translated into appropri-ate standards.

Example case – IMS An IMS core network is based on stan-

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 core network.

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. An example of such deployment is illustrated in Figure 8. Tenants are deployed over a shared cloud infrastruc-ture in which the networking solution guarantees tenant separation – fulfill-ing security requirements and fair use of resources.

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 – and all of these requirements not only need to be implemented, they also need to be automated. The functionality pro-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. Automation and dynamicity are key ele-ments to providing a cloud offering as a service based on an IMS core. A VDC can be instantiated from a description on

demand, resulting in tenant networks being created or modified. Interconnect is established automatically by the infra-structure using orchestration and SDN technologies. The domain manager for the IMS application is responsible for these steps, as well as all other life cycle management, including, for example, runtime scale out operations.

Conclusion Traditional network architecture is often built on proprietary hardware. Telecom systems are by nature verti-cal – inseparable – towers that become overly complex and are as a result costly to operate. Spearheaded by the IT indus-try, a shift toward providing everything as a service is taking place. Adopting a similar approach for network func-tions is one way for operators to expand infrastructure.

Some of the benefits of this type of network transformation are:

reduced complexity – which lowers running costs;simplified in and out scalability – which makes efficient use of network resources and supports dynamic ability to respond to changes in capacity demand; and reduced time to market for new services.

In addition to enabling new benefits and opportunities, the cloud infrastruc-ture must ensure the robustness, per-formance, security and interoperability for telco applications, minimizing the costs induced by the transformation itself. This requires a system that pro-vides telco apps with a smooth transi-tion and real-time fully telecom-adapted network support, while providing new sets of enablers that act as a bridge to a new era of cloud-empowered telco appli-cations and solutions.

Tenant 1networkTenant 1network Tenant 1 IMS networkTenant 1 IMS network

OAMOAM

SignalingSignalingMediaMedia

OAMOAM

SignalingSignalingMediaMedia

Tenant 2 IMS networkTenant 2 IMS network

NOCNOCOAMOAM StorageStorage

Centralstorage

Acc

ess

Acc

ess

Acc

ess

Acc

ess

Co

reC

ore

Ten

ant

1T

enan

t 1

Ten

ant

2T

enan

t 2

Tenant 2networkTenant 2network

VRVR

DCswitch

FW

DCswitch

FW

VRVR VRVR

CSCFclusterCSCFcluster

HSScluster

HSScluster

MTASclusterMTAScluster

MFRPMFRPIDNSIDNSPGMPGM

VRVR VRVR VRVR

CSCFclusterCSCFcluster

HSScluster

HSScluster

MTASclusterMTAScluster

MFRPMFRPIDNSIDNSPGMPGM

SBGSBG

FIGURE 8 Multi-tenant multi-instance IMS network in VDC

8


The telco cloud

http://www.ericsson.com/res/docs/2013/ericsson-mobility-report-november-2013.pdf

http://www.etsi.org/technologies-clusters/technologies/nfv

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 :EricssonSE-164 83 Stockholm, SwedenPhone: +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 InsightsAll 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 ordownload 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. Doyledeirdre.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 R&D 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


https://play.google.com/store/apps/details?id=com.ericsson&feature=search_result#?t=W251bGwsMSwxLDEsImNvbS5lcmljc3NvbiJd

https://itunes.apple.com/se/app/id668627885

Virtualizing network services

Technology

Transcript of Virtualizing network services