Telefónica s view on virtualized mobile networks

Transcription

1 Telefónica s view on virtualized mobile networks ijoin Winter School Telefonica I+D - GCTO February, 2015

2 What are we going to present? Firstly, a general introduction to virtualization that we are required to include in any presentation by contract Then, a brief overview of Telefonica s activities related to virtualization, mainly focused on the mobile networks area Finally, the viewpoint on the role of virtualization in mobile networks and 5G Unfortunately, we cannot share these slides with you for reasons that would be very difficult to understand for someone who is not used to Telefónica s way of doing things 1

3 1. Virtualization: Telefónica s Vision and Strategy

4 Telco environment has some peculiarities that have made it traditionally different from the Internet model Telco cycle is conditioned by HW: economies of scale NETWORK FOCUS & HW-BASED FUNCTIONALITIES Geographical dispersion High number of nodes Interoperability Internet Service Providers cycle is based on SW running over COTS HW OTT & SW-BASED FUNCTIONALITIES Edge deployments Global service from scratch No Interoperability Upgrades are complex and expensive Upgrades are easier and cheaper SW requires low scale requirements Telco Operators Equipment Vendors SDOs Idea!! Demand Critical mass of supporters 2-6 years Drive Standardise AVAILABLE Deploy Sell Implement Time Idea!! Service Providers 2-6 months AVAILABLE Develop Deploy Publish Time Relaxed Time-To-Market No differentiation Fast TTM & Innovation Differentiation strategies

5 which has resulted in high entry barriers for new ideas and differential features 1.2 There is an enormous installed base of equipment & protocols where: Standardised external interfaces are narrow: lack of Interoperability Internals are hidden and differ from vendor to vendor This telco cycle has favoured a closed vendors ecosystem HW economies of scale and interoperability requirements become effective entry barriers for competition SW has been artificially tied to HW As a result, most of new ideas are never tried nor tested!

6 We need to attack the root of the problem! 1.3 Hardware and Software is now v vertically integrated Capacity is tied to a function Vendor lock in (it is difficult to switch from one vendor to another when deployments are made) Difficult v IoT Interoperability tests required per protocol and node Complex Network v Management Small changes in a network element requires an adaptation of the corresponding EMS Complex stitching of network functions across different network segments and technologies which has resulted in excessive time to market and high costs

7 Network Virtualization = SDN + NFV? 1.4 Provide a general interface to network resources Abstracting actual infrastructure details Decouple the planes conforming the network Relying on software mechanisms to support functionality SDN Decouple the control and data planes Gain programmability Simplify data plane elements Software in the network NFV Separate functionality from capacity Increase network elasticity Reduce heterogeneity The network in software

8 Network Virtualisation implies the separation of the FUNCTION from the CAPACITY 1.5 DPI BRAS Firewall CG-NAT PE Router GGSN/ SGSN VIRTUAL NETWORK FUNCTIONS FUNCTION (semantics) Decoupled COMMON HW (Servers & Switches) CAPACITY (resource mgmt)

9 Which translates to a proper balance of NFV & SDN 1.6 BNG IPv4 / IPv6 CONTROL Session mgmt TR-069 UPnP DHCP CG-NAT NAT Pool admin NAT ctrl. POOL MGMT NFV SW-defined network functions Separation of HW and SW No vertical integration - HW vendor SW vendor Mgmt vendor Once network elements are SW-based, HW can be managed as a pool of resources SDN Interconnecting Virtual Network Functions (a.k.a. backplane) Separation of control and data plane Easy orchestration with SW domain

10 Once network functions are SW-based, they can be moved to the most convenient location, providing flexibility to the network architecture 1.7 To accelerate service deployment and Time-To-Market To obtain relevant CAPEX and OPEX reduction To build a New Open Telco Model: with a broader ecosystem of HW and SW partners to meet Telefónica s interests, avoiding potential vendor s lock-in Virtualisation is a key lever to selectively introduce more competition to traditional infrastructure suppliers & reduce costs

11 ETSI NFV ISG has generated a reference architecture for deploying and managing this vision 1.8 Management environment Legacy OSS/BSS Execution environment Orchestrator Network Scenarios Virtual Network Functions VNF Manager Network Functions OS + Hypervisor Commodity HW Commodity Switching infrastructure Virtualised Infrastructure Manager Virtual Machines

12 A future-proof network architecture requires distributing data plane intensive functions and centralising control plane ones 1.9 There will be two kinds of Virtualized Network Infrastructure: local PoPs and regional Data Centres Service Domain Data Plane must be Distributed LOCAL PoPs CDN P-CSCF v Video Security Control Plane can be Centralised REGIONAL DATA CENTRES SDP IMS v CSFB SRVCC NGIN M/SMSC EPC BRAS PE DHCP PCRF Network Domain DPI CG-NAT GGSN DNS UDB Infrastructure HW and SW decoupling OS + Hypervisor COTS HW HW and SW decoupling OS + Hypervisor COTS HW MPLS/SDN/Optical MPLS/SDN/Optical

13 Our strategy: to advance through TCO-driven uses cases 1.10 No need of a Virtual Network flag-day Different network nodes and segments can be virtualised... Access Point BY RELEVANT USE CASES TCO Benefits vcpe vbras vims vepc Switch Modem Virtual CPE Tech difficulty 2G/3G/4G xdsl FTTx EVOLUTIONARY APPROACH Adapt to: - New specific needs for different nodes - Reuse of equipment still in amortization - Leverage on new planned elements in architecture Legacy Infrastructure 30% of new network elements to be virtualized by 2016 UNICA Infrastructure

14 No disruptive changes are required in the network at the beginning 1.11 No need to change the current network infrastructure overnight (just needs to be reconfigured) while the new functions are deployed in the new virtualised infrastructure VIRTUAL NETWORK INFRASTRUCTURE LEGACY INFRASTRUCTURE

15 but paves the way towards a deeper and evolutionary transformation 1.12 Natural capacity extension and amortization of legacy equipment will quickly change the balance among both infrastructures VIRTUAL NETWORK INFRASTRUCTURE LEGACY INFRASTRUCTURE

16 but paves the way towards a deeper and evolutionary transformation 1.13 Going to a fully virtualised approach as quickly as possible, for maximum improvement in OPEX and time to market VIRTUAL NETWORK INFRASTRUCTURE

17 transforming the whole network 1.14 v v v v v v Users Access Aggregation Local Data Centres Core Regional Data Centres Devices Connectivity, Capacity, Mobility support 2G/3G/4G xdsl Multiplexing Manage users and sessions Managed local services Switching, Transport Interconnection Managed regional services Places FTTx Management plane Net OS: THE orchestrator (towards zero OSS) Network Big Data

18 This new network model will help us to deeply transform our factory 1.15 Network Paradigm Change Computing principles used in IT world are beginning to be applied in telecoms by the means of Network Virtualization IP as common language for all services, included traditional Telco ones Network virtualisation enabling network reprogrammability & agile service creation Operation Model Change Global E2E vision instead traditional silo model, not linked to monolithic OSS Organization Model Change Breaking the traditional model mapping isolated network domains

19 We have created an internal Telefónica NFV council to start this global transformation 1.16 Accelerate the transformation to meet the target for 2016 of virtualizing 30% of the network Identify network elements subject to be virtualised Benefits in terms of TCO, TTM or any others. Global processes Virtualised network functions Orchestration modules Define a common reference architecture (NFV compliant), operable with common and simple procedures, and steer the industry to provide it Openness and future-proof flexibility are key elements Provide a Group-Level Reference Lab (NFV-RL), to minimize integration efforts per operation in the desired multi-vendor environment Acquisition of the appropriate skillset to operate a virtualised network

20 2. Telefónica s Main Activities on Virtualization

21 Telefónica focus in virtualization 2.1 Telefónica is active in three main areas: R&D, Standardization and Procurement R&D: EU projects, In the mobile area, both already active like ijoin, and H2020 proposals, like 5G NORMA Corporate Innovation Budget (CIB) projects Standardization: ETSI: quite active in the NFV ISG, considering the participation in MEC ISG IETF/IRTF, e.g., NFVRG, SDNRG, Open Networking Foundation (some contributions originated in ijoin) Telefónica has also supported the opening of a Study Item in 3GPP regarding network virtualization Procurement & evaluation of solutions UNICA project, which defines UNICA Infrastructure Architecture reference model, which defines a Reference Architecture for a service rooms with all the functionality that need the Telco and Service Platforms and shall be cloud oriented Key features: Openness for multi-vendor, Multi-tenancy operation, SDN network, NFV compliance, Template service automatic deployment, Elastic scaling, Disaster Redundancy and Multi-Business operation for public and private cloud The intended objective NFV Reference Lab, engaged in the performance evaluation of the solutions of different vendors in a reference environment 20

22 Telefónica UNICA objectives

23 Our NFV Reference Lab: fostering the ecosystem, avoiding vendor lock-in & minimising integration efforts 2.3 ECOSYSTEM VENDOR CERTIFICATION HERE: Simplest integration ECOSYSTEM VNFs New VNFs to be added here NFVO Others to come VENDOR VALIDATION HERE: Network Orchestration on top of Carrier-grade OpenStack Proper HW & Hypervisor config NFVI VIM = OpenStack++ OFC++ Carrier-grade OpenStack going to upstream development BASELINE TECHNOLOGIES (commodity, non-proprietary) 22

24 NFV Reference Lab: VNFs validation 2.4 Validating generic aspects of VNFs as NFV elements Lab testing in reference environment Open RFI questionnaire since March 2014 What is covered: Capacity consumption Performance Deployment options VM interconnection options Assumptions on VIM Integration with NFV-O & VNFM elements >20 VNFs under validation vrouter vcpe vbras vfirewall vdns vepc vstb vims vsbc vpcrf vlb vids >15 Vendors 23

25 Performance and predictability have already been proven for some demanding NFVs & use cases 2.5 RESIDENTIAL vcpe DPI SW BNG SW ROUTER + PE Open Source SW ROUTER SW CG-NAT 24 2

26 NFV Ref Lab results virtual EPC 2.6 (*) Throughput results are limited by traffic generator capabilities. 25

27 3. Mobile Networks Virtualization

28 Virtualized Mobile Networks 3.1 The situation is different depending the network segment: Virtualisation of the Core Network is already in a pre-commercial status Virtualisation of the RAN is intended to apply these principles to the Radio access Network, following the NFV/SDN architectural framework, but taking into account the specific technical requirements of the RAN RAN virtualization is based on three differentiating principles: Supporting functional split of network functions This is considered a distinctive feature of mobile networks with respect to fixed networks Supporting mobility of network functions Depending on the implementation scenarios, functions may be have different levels of centralization/distribution Running some functionalities on software on top of generic hardware, while others are implemented on specific hardware Carrying out all the baseband processing on GPP is feasible but makes no sense (yet) from an economic viewpoint But it would be interesting to extend the virtualization procedures to non GPP based processing 27

29 Is the virtualized Core Network ready? 3.2 First pre-commercial VNFs for LTE EPC functions (vims, vmme, vhss, vs/p-gw) are being evaluated for potential deployment in commercial networks in the following months Solutions available from NEC, Alcatel Lucent, ZTE, Huawei, Cisco, Two aspects should be addressed in this evaluation: Functional compliance with 3GPP/IETF standards I,e., the virtualized EPC behaves like the non virtualized one Performance as required for the support of commercial services Performance of virtualized network should be on par with existing networks Reliability should also comply with existing solutions Lessons learned so far: Functional compliance is not the main issue so far Many network functions that are being virtualized have been originally developed over GPP Performance is a much more problematic issue hitherto Connectivity and switching performance are the main obstacles to a fully virtualization of core elements like the S- GW/P-GW Data plane packet rates of the S/P-GW VNFs tested in the NFV Ref Lab are significantly lower than other data plane VNFs tested such as vcgnat or vrouter Orchestration is also a pending problem 28

30 Mobile network virtualisation in ETSI NFV 3.3 NFV ISG has developed an NFV PoC Framework to coordinate and promote multi-vendor Proofs of Concept illustrating key aspects of NFV ISG work. The goal for the NFV ISG PoC Framework is to build awareness and confidence and to encourage the development of an open ecosystem by integrating components from different players. In ETSI ISG NFV, seven PoCs have been proposed that are related to the virtualization of mobile networks: PoC#6: Virtualised Mobile Network with Integrated DPI Telefonica, Intel, Tieto, Qosmos, Wind River Systems, Hewlett Packard PoC#7: C-RAN virtualisation with dedicated hardware accelerator China Mobile, Alcatel-Lucent, Wind River Systems, Intel PoC#23: Demonstration E2E orchestration of virtualized LTE core-network functions and SDN-based dynamic service chaining of VNFs using VNF FG SK Telecom, Hewlett Packard, Samsung, Telcoware PoC#25: Demonstration of Virtual EPC (vepc) Applications and Enhanced Resource Management Vodafone, AMD, ARM, Aricent PoC#26: Virtual EPC with SDN Function in Mobile Backhaul Networks Telecom Italia, Nokia, EXFO, Coriant, Aalto University PoC#27: VoLTE Service based on vepc and vims Architecture China Unicom, ZTE Corporation, Hewlett-Packard PoC#30: LTE Virtualized Radio Access Network (vran) SK Telecom, Nokia, Intel 29

31 Virtual RAN & 5G 3.4 Cloudification and virtualization are the most significant new trends in terms of future 5G network architecture They may allow for a simple and elegant solution to one of the major problems in the core network architecture, its (ever) increasing complexity: too many network elements and interfaces The reasons for this complexity are diverse: The standards and the requirement of coexistence between different generations and RATs is one of them But also the fact that aiming for a one-fits-all architectural solution results in the introduction of new elements in order to fulfill service specific requirements E.g., video services may need to be transcoded to a lower bit rate in order to reduce the radio interface load (which requires a new network element), but for this to happen they need to be identified (which requires an additional one) Specific core network solutions for specific services and applications may become feasible without increasing the hardware network infrastructure, so complexity moves to the software layer, but for many of them it is already there (e.g., in OTT applications) We think that service specific solutions should be available for some services like voice, video and MTC On top of this, the virtualization of the core may allow to incorporate different network paradigms, like Content Centric Networks, that may be useful for some use cases, like emergency communications We also expect the boundary between Core and Access networks to blur in 5G systems In some deployment scenarios, radio interface functionalities will be centralized in data centers In others, local breakout will happen very close to the radio elements, so most of the core network functions will be located close to the antenna 5G architectural framework should allow for the support of both extreme cases, as well as other intermediate alternatives Different levels of radio interface centralization (e.g., in aggregation point) Moving network intelligence close to the edge (e.g., content caching) 30

32 Thank You! 31

33 32