Virtualizing network services
- 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