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

Size: px

Start display at page:

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

Amie Austin
6 years ago
Views:

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

2 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 MCN. All rights reserved. / Page 2

3 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 MCN. All rights reserved. / Page 3

4 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 MCN. All rights reserved. / Page 4

5 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 MCN. All rights reserved. / Page 5

6 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 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

9 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) MCN. All rights reserved. / Page 9

MCN Key Arch Elements Overview All are used throughout MCN

18 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 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

19 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 MCN. All rights reserved. / Page 19

20 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 MCN. All rights reserved. / Page 20

21 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 MCN. All rights reserved. / Page 21

22 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 MCN. All rights reserved. / Page 22

29 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 MCN. All rights reserved. / Page 29

30 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 MCN. All rights reserved. / Page 30

32 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 MCN. All rights reserved. / Page 32

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

35 Thank You!

36 Backup

Cloud & Services Cloud service categories IaaS, PaaS & SaaS Deployed Public,

42 From... System is contained to local resources Scaling is limited by local resources Difficult beyond - requires rearchitecting Many existing systems are built like this 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

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 MCN. All rights reserved. / Page 44

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 MCN. All rights reserved. / Page 45

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 MCN. All rights reserved. / Page 46

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 MCN. All rights reserved. / Page 47

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 MCN. All rights reserved. / Page 48

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 MCN. All rights reserved. / Page 49

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 MCN. All rights reserved. / Page 50

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

52 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 MCN. All rights reserved. / Page 53

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 MCN. All rights reserved. / Page 54

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 MCN. All rights reserved. / Page 55

Service Manager Deletes the complete service

Service Orchestrator What services are required to support the SO implementation.

CloudController Interface with other Services, requested by

74 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 MCN. All rights reserved. / Page 75

MCN and NFV Mapping Update image Orch covered only by half This is

78 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 by MCN Consortium MCN. All rights reserved. / Page 79

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 MCN. All rights reserved. / Page 80

Follow Me Cloud and Virtualization of (Multimedia) Services and Applications: Challenges and Possible Solutions

Follow Me Cloud and Virtualization of (Multimedia) Services and Applications: Challenges and Possible Solutions André Gomes (1), Torsten Braun (1), Georgios Karagiannis (2), Morteza Karimzadeh (2), Marco