End-to-End Cloudification of Mobile Telecoms. The MCN Consortium Presenter: Andy Edmonds ZHAW

End-to-End Cloudification of Mobile Telecoms The MCN Consortium Presenter: Andy Edmonds (@dizz), ZHAW

Goals of MCN Architecture Modularity, reusability Creation of composed (end-to-end) services Adhere to the NIST cloud computing definition Enable cloudification of services e.g. EPC keep functional arch, adapt software arch Common framework and lifecycle to design services that accommodates all identified scenarios No technology specific dependencies Leverage & influence suitable/relevant standards to ensure interoperability and integration 2012-2015 MCN. All rights reserved. / Page 2

MCN Key Principles Service-Oriented Principles Autonomous: The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not tightly coupled to execute. Share a formal contract: In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange. Loosely coupled: Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. Services abstract underlying logic, which is invisible to the outside world, beyond what is expressed in the service contract metadata. 2012-2015 MCN. All rights reserved. / Page 3

MCN Key Principles Service-Oriented Principles Composable: Services may compose others, allowing logic to be represented at different levels of granularity. This allows for reusability and the creation of service abstraction layers and/or platforms. Reusable: Whether immediate reuse opportunities exist, services are designed to support potential reuse. Stateless: Services should be designed to maximise statelessness even if that means deferring state management elsewhere. Discoverable: Services should allow their descriptions to be discovered and understood by (possibly) humans and service requestors that may be able to make use of their logic. 2012-2015 MCN. All rights reserved. / Page 4

MCN Key Principles Cloud Native Services Leverages cloud-platform services for reliable, scalable infrastructure. Non-blocking asynchronous communication in a loosely coupled architecture. Monitors and manages application logs even as nodes come and go. Scales horizontally, adding resources as demand increases and releasing resources as demand decreases. Scales automatically using proactive and reactive actions. Cost-optimizes to run efficiently, not wasting resources. Handles scaling events without downtime or user experience degradation. Handles transient failures without user experience degradation. Handles node failures without downtime. Upgrades without downtime. Uses geographical distribution to minimize network latency. 2012-2015 MCN. All rights reserved. / Page 5

Terminology Service E.g. CDNaaS Service Instance E.g. EPC service instance Service Instance Components (SIC) E.g. MME or DSS cache Resources (Physical/Virtual) build services 2012-2015 MCN. All rights reserved. / Page 6

MCN Key Arch Elements Service Manager Provides an external interface to the user Business dimension: encodes agreements Technical dimension: Management Service Orchestrators of a particular tenant Service Orchestrator Oversees (E2E) orchestration of a service instance Domain specific component Manages service instance 'Runtime & Management' step of the Service Lifecycle One SO is instantiated per each tenant within the domain SO is associated with a Service Manager Monitors application specific metrics and scales (SOE/SOD) CloudController Supports the deployment, provisioning, and disposal of services Access to atomic services Access to support services Configures atomic services (IaaS) 2012-2015 MCN. All rights reserved. / Page 9

MCN and NFV Mapping MCN Arch Entity Service Instance Service Instance Component Service Orchestrator Service Manager CloudController No direct architectural mapping. Maps technically to OpenStack or CloudSigma SO Bundle 2012-2015 MCN. All rights reserved. / Page 18 NFV Entity Virtual Network Function (NVF) NVF component VNF Manager, ETSI-NFV orchestrator No entity The service manager provides a north bound interface enabling EEU self-service No entity The CloudController abstracts from underlying atomic services. ETSI-NFV Virtualized Infrastructure Manager would sit below Virtualized Infrastructure Manager Service, VNF and infrastructure description

MCN NFV Scope & Applicable NFV Use Cases Use Case #1: Network Functions Virtualisation Infrastructure as a Service Use Case #2: Virtual Network Function as a Service (VNFaaS) Use Case #3: Virtual Network Platform as a Service (VNPaaS) Use Case #4: VNF Forwarding Graphs Use Case #5: Virtualisation of Mobile Core Network and IMS Use Case #6: Virtualisation of Mobile base station Use Case #7: Virtualisation of the Home Environment Use Case #8: Virtualisation of CDNs (vcdn) Use Case #9: Fixed Access Network Functions Virtualisation 2012-2015 MCN. All rights reserved. / Page 19

MCN and TMForum Mapping MCN Lifecycle inspired and aligned to TMForum Application framework (TAM) / etom Deploy, Provision Runtime Management MCN also deals with: Design Business Service Manager Implementation Disposal 2012-2015 MCN. All rights reserved. / Page 20

MCN and TMForum Mapping TMForum Application framework (TAM) / etom Business Service Manager Technical Service Manager Service Orchestrator CloudController Support Services SLAaaS MaaS (CMMS) RCBaaS Atomic Services 2012-2015 MCN. All rights reserved. / Page 21

How is an E2E MCN Service Instance Created? Scenario 4 service providers (C1-C4) 3 services orchestrated - RAN, Core, CDN 1 value added E2E service offered to the enterprise end user Both public and private cloud resources Scenario Assumption Service designed and implemented 2012-2015 MCN. All rights reserved. / Page 22

How is an E2E MCN Service Instance Created? Where are we? Deployment phase is completed Eventually all services are created Not configured however Provisioning phase begins 2012-2015 MCN. All rights reserved. / Page 29

How is an E2E MCN Service Instance Created? Provision phase The SO has access to all other service instance management endpoints Configuration information is supplied to these 2012-2015 MCN. All rights reserved. / Page 30

How is an E2E MCN Service Instance Created? Where are we? Ready for service Deployment & provisioning phase completed Service instance management interfaces are available to the EEU EUU can use & further customise the service instance degree of configurability is dependent on service provider SO of all service instances manage runtime SOD & SOE 2012-2015 MCN. All rights reserved. / Page 32

Key Enabling Framework Technologies Service Manager Python, Pyssf, OCCI Service Orchestrator Python, Pyssf, OCCI Cloud Controller OpenShift, OpenStack, Pyssf, OCCI 2012-2015 MCN. All rights reserved. / Page 33

Thank You!

Backup

From... System is contained to local resources Scaling is limited by local resources Difficult beyond - requires rearchitecting Many existing systems are built like this 2012-2015 MCN. All rights reserved. / Page 43

To... System is not contained to local resources Scaling is adding as many resources/nodes that are available Elasticity enabled grow and shrink as needed Existing systems are not built for this Requires additional orchestration and management 2012-2015 MCN. All rights reserved. / Page 44

Services are made up of Resources Resource: Any physical or virtual component of limited availability within a computer or information management system. Physical Resource: Any one element of hardware, software or data that is part of a larger system. Virtual Resource: A virtual computer resource is a temporal partitioned fraction of any physical resource of limited availability within a computer or information management system. 2012-2015 MCN. All rights reserved. / Page 45

How to Architect Services? Service-Oriented Principles Autonomous: The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not tightly coupled to execute. Share a formal contract: In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange. Loosely coupled: Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. Services abstract underlying logic, which is invisible to the outside world, beyond what is expressed in the service contract metadata. 2012-2015 MCN. All rights reserved. / Page 46

How to Architect Services? Service-Oriented Principles Composable: Services may compose others, allowing logic to be represented at different levels of granularity. This allows for reusability and the creation of service abstraction layers and/or platforms. Reusable: Whether immediate reuse opportunities exist, services are designed to support potential reuse. Stateless: Services should be designed to maximise statelessness even if that means deferring state management elsewhere. Discoverable: Services should allow their descriptions to be discovered and understood by (possibly) humans and service requestors that may be able to make use of their logic. 2012-2015 MCN. All rights reserved. / Page 47

Cloud Native Services Leverages cloud-platform services for reliable, scalable infrastructure. Non-blocking asynchronous communication in a loosely coupled architecture. Monitors and manages application logs even as nodes come and go. Scales horizontally, adding resources as demand increases and releasing resources as demand decreases. Scales automatically using proactive and reactive actions. Cost-optimizes to run efficiently, not wasting resources. Handles scaling events without downtime or user experience degradation. Handles transient failures without user experience degradation. Handles node failures without downtime. Upgrades without downtime. Uses geographical distribution to minimize network latency. 2012-2015 MCN. All rights reserved. / Page 48

Business Phase Design: This is the phase where the service is conceptualised, the services that cannot be supplied by the organisation are sourced from other organisations, and requirements upon the external services to be combined are collected and studied. Agreement: Here items such as Pricing, Service Level Agreement (SLA), Access, etc., are agreed between two or more organisations. The agreements are generally bilateral business ones. 2012-2015 MCN. All rights reserved. / Page 49

MCN Service Lifecycle: Technical Design of the service architecture Implementation of the designed solution Deployment of the implemented solution & elements Destroy service instances or SIC(s) Activities such as scaling, reconfiguration of Service Instance Components (SICs) Activation of the service such that the user can actually use it. 2012-2015 MCN. All rights reserved. / Page 50

Technical Phase Design: Design of the architecture, implementation, deployment, provisioning and operation solutions. Supports Service Owner to "design" their service 2012-2015 MCN. All rights reserved. / Page 51

Technical Phase Deployment: Deployment of the implemented elements, e.g. DCs, cloud, controllers, etc. Provide anything such that the service can be used, but don't provide access to the service. 2012-2015 MCN. All rights reserved. / Page 53

Technical Phase Provisioning: Provisioning of the service environment (e.g. NFs, interfaces, network, etc.). Activation of the service such that the user can actually use it. 2012-2015 MCN. All rights reserved. / Page 54

Technical Phase Operation and Run-Time Management: in this stage the service instance is ready and running. Activities such as scaling, reconfiguration of Service Instance Components (SICs) are carried out here. 2012-2015 MCN. All rights reserved. / Page 55

How to Bring All These Together? Service Manager (B+T) SO Service Manager (B+T) SO Service Manager (B+T) Drop this slide SO MCN Service Instance N MCN Service Instance M MCN Service Instance K SICs SICs SICs Use Support Services Cloud Controller Cloud Controller Cloud Controller Multiple e2e tenant services: Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN 2012-2015 MCN. All rights reserved. / Page 75

2012-2015 MCN. All Rights Reserved The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2012-2015 by MCN Consortium. 2012-2015 MCN. All rights reserved. / Page 79

How to Bring All These Together? Service Manager (B+T) Service Manager (B+T) Service Manager (B+T) SO SO SO MCN Service Instance N MCN Service Instance M MCN Service Instance K SICs SICs SICs Use Support Services Cloud Controller Cloud Controller Cloud Controller Multiple e2e tenant services: Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN 2012-2015 MCN. All rights reserved. / Page 80