1 of 80

End-to-End Cloudification of Mobile Telecoms

The MCN Consortium

Presenter: Andy Edmonds (@dizz), ZHAW

  • 2012-2015 MCN. All rights reserved. / Page

2 of 80

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

3 of 80

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

4 of 80

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

5 of 80

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

6 of 80

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

7 of 80

MCN Service Categories

  • 2012-2015 MCN. All rights reserved. / Page

8 of 80

Lifecycle of a MCN Service

  • 2012-2015 MCN. All rights reserved. / Page

9 of 80

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

10 of 80

Service Manager Internals

  • Main entry point so service management for EEU
  • Overall management of SM’s SO’s
  • Maintains list of services offered by SM
  • 2012-2015 MCN. All rights reserved. / Page

11 of 80

Service Orchestrator Internals

  • enforces decisions towards the CC
  • interacts with CC entities
  • Graph of required services and resources for service instance
  • 2012-2015 MCN. All rights reserved. / Page

12 of 80

CloudController Internals

  • 2012-2015 MCN. All rights reserved. / Page

13 of 80

MCN Key Arch Elements Overview

support or MCN

All are used throughout MCN

  • 2012-2015 MCN. All rights reserved. / Page

14 of 80

MCN Services and Arch Elements

  • 2012-2015 MCN. All rights reserved. / Page

15 of 80

Beyond MCN

​

​

​

How does this fit to State of the Art?

  • 2012-2015 MCN. All rights reserved. / Page

16 of 80

MCN and NFV Mapping�

  • 2012-2015 MCN. All rights reserved. / Page

17 of 80

MCN and NFV Mapping�Approximate Mapping

CloudController

Service

Orchestrator

i.e.

Openstack

Service Instances

STG, ITG

Service Manager

  • 2012-2015 MCN. All rights reserved. / Page

18 of 80

MCN and NFV Mapping

MCN Arch Entity

NFV Entity

Service Instance

Virtual Network Function (NVF)

Service Instance Component

NVF component

Service Orchestrator

VNF Manager, ETSI-NFV orchestrator

Service Manager

No entity

The service manager provides a north bound interface enabling EEU self-service

CloudController

No entity

The CloudController abstracts from underlying atomic services. ETSI-NFV Virtualized Infrastructure Manager would sit below

No direct architectural mapping.

Maps technically to OpenStack or CloudSigma

Virtualized Infrastructure Manager

SO Bundle

Service, VNF and infrastructure description

  • 2012-2015 MCN. All rights reserved. / Page

19 of 80

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

20 of 80

MCN and TMForum Mapping

MCN Lifecycle inspired and aligned to TMForum Application framework (TAM) / eTOM

Business Service Manager

Deploy, Provision

Runtime Management

MCN also deals with:

  • Design
  • Implementation
  • Disposal
  • 2012-2015 MCN. All rights reserved. / Page

21 of 80

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

22 of 80

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

23 of 80

How is an E2E MCN Service Instance �Created?

EEU requests a service instance

​

Providers, Services and CloudControllers

  • 2012-2015 MCN. All rights reserved. / Page

24 of 80

How is an E2E MCN Service Instance �Created?

Deployment phase

Service managers inside each service provider

  • 2012-2015 MCN. All rights reserved. / Page

25 of 80

How is an E2E MCN Service Instance �Created?

Deployment phase

Service Orchestrator created to oversee instance creation

  • 2012-2015 MCN. All rights reserved. / Page

26 of 80

How is an E2E MCN Service Instance �Created?

Deployment phase

Service Orchestrator requests necessary services creation

  • 2012-2015 MCN. All rights reserved. / Page

27 of 80

How is an E2E MCN Service Instance �Created?

Deployment phase

Each required service provider’s service manager creates a service orchestrator

  • 2012-2015 MCN. All rights reserved. / Page

28 of 80

How is an E2E MCN Service Instance �Created?

Deployment phase

Service orchestrators that require services from the CloudController requests them

  • 2012-2015 MCN. All rights reserved. / Page

29 of 80

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

30 of 80

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

31 of 80

How is an E2E MCN Service Instance �Created?

Provision phase

Service orchestrators may pass on configuration to CloudController

  • 2012-2015 MCN. All rights reserved. / Page

32 of 80

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

33 of 80

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

34 of 80

Upcoming

    • Architectural Refinement
      • Based on software development
    • Software to be released as open source
      • Apache 2.0
    • Submission as NFV prototype to ETSI
  • 2012-2015 MCN. All rights reserved. / Page

35 of 80

Thank You!

  • 2012-2015 MCN. All rights reserved. / Page

36 of 80

Complete Integrated Vision

  • 2012-2015 MCN. All rights reserved. / Page

37 of 80

Backup

  • 2012-2015 MCN. All rights reserved. / Page

38 of 80

Federation

  • 2012-2015 MCN. All rights reserved. / Page

39 of 80

EGI FedCloud

Fed & Interop Challenge!

  • 2012-2015 MCN. All rights reserved. / Page

40 of 80

A Solution? EGI FedCloud

�

​

Fed & Interop Implemented!

  • 2012-2015 MCN. All rights reserved. / Page

41 of 80

Cloud & Services

  • Cloud service categories
    • IaaS, PaaS & SaaS
  • Deployed
    • Public, private
    • Both considered for the MCN Arch

​

  • 2012-2015 MCN. All rights reserved. / Page

42 of 80

Cloud & MCN

  • Cloud-defined (NIST)
    • On-Demand, Self-Service
    • Resource Pooling
    • Broad Network Access
    • Rapid Elasticity
    • Measured Service / Pay-As-You-Go
  • 2012-2015 MCN. All rights reserved. / Page

43 of 80

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

44 of 80

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

45 of 80

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

46 of 80

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

47 of 80

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

48 of 80

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

49 of 80

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

50 of 80

MCN Service Lifecycle: Technical

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

51 of 80

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

52 of 80

Technical Phase

Implementation: of the designed architecture, functions, interfaces, controllers, APIs, etc.

  • 2012-2015 MCN. All rights reserved. / Page

53 of 80

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

54 of 80

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

55 of 80

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

56 of 80

Technical Phase

Disposal: Release of SICs and the service instance itself is carried out here.

  • 2012-2015 MCN. All rights reserved. / Page

57 of 80

Service Manager

EEU or requesting SO submits a request for a service instance (direct, UI or CLI)

  • 2012-2015 MCN. All rights reserved. / Page

58 of 80

Service Manager

contains a list of the available services offered by the provider

Contains a list of the available services offered by the provider

  • 2012-2015 MCN. All rights reserved. / Page

59 of 80

Service Manager

deploys the SO bundle to the CC

  • 2012-2015 MCN. All rights reserved. / Page

60 of 80

Service Manager

provisioning of the service instance incl. all SICs

  • 2012-2015 MCN. All rights reserved. / Page

61 of 80

Service Manager

Tracks all provisioned SOs (service instance)

​

Also contains info on all mgt interfaces

  • 2012-2015 MCN. All rights reserved. / Page

62 of 80

Service Manager

Deletes the complete service instance

  • 2012-2015 MCN. All rights reserved. / Page

63 of 80

Service Orchestrator

All requests by SM to SO goes through here

  • 2012-2015 MCN. All rights reserved. / Page

64 of 80

Service Orchestrator

Takes decisions on the run-time management of the SICs (e.g. based on monitoring data)

  • 2012-2015 MCN. All rights reserved. / Page

65 of 80

Service Orchestrator

Responsible for enforcing the decisions towards the CC

  • 2012-2015 MCN. All rights reserved. / Page

66 of 80

Service Orchestrator

What services are required to support the SO implementation.

How they’re configured.

Model defined by CC

  • 2012-2015 MCN. All rights reserved. / Page

67 of 80

Service Orchestrator

What services are required to support the SO implementation.

How they’re configured

​

Diff - live information from CC

  • 2012-2015 MCN. All rights reserved. / Page

68 of 80

CloudController

Provides a Frontend and exposes an API which can be used to interface with the CC.

  • 2012-2015 MCN. All rights reserved. / Page

69 of 80

CloudController

Allows the listing of capabilities which the CC offers

  • 2012-2015 MCN. All rights reserved. / Page

70 of 80

CloudController

Will enable the deployment of the SO and its individual SIC

  • 2012-2015 MCN. All rights reserved. / Page

71 of 80

CloudController

Will enable the configuration of the SIC

  • 2012-2015 MCN. All rights reserved. / Page

72 of 80

CloudController

Takes care of runtime operations such as scaling requests

  • 2012-2015 MCN. All rights reserved. / Page

73 of 80

CloudController

will support the disposal of each SIC

  • 2012-2015 MCN. All rights reserved. / Page

74 of 80

CloudController

Interface with other Services, requested by higher layers

  • 2012-2015 MCN. All rights reserved. / Page

75 of 80

How to Bring All These

Together?

Use Support Services

Cloud Controller

MCN Service Instance N

Service Manager (B+T)

Cloud Controller

MCN Service Instance M

Cloud Controller

MCN Service Instance K

SO

SO

Service Manager (B+T)

Service Manager (B+T)

SO

Multiple e2e tenant services:

Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN Service, ....

SICs

SICs

SICs

Drop this slide

  • 2012-2015 MCN. All rights reserved. / Page

76 of 80

How to Bring All These

Together?

Sequence diagram in D2.2

Drop this slide

  • 2012-2015 MCN. All rights reserved. / Page

77 of 80

MCN and NFV Mapping

This is an approximate mapping

Update image

Orch covered only by half

  • 2012-2015 MCN. All rights reserved. / Page

78 of 80

Colors and Halftone Values

  • 2012-2015 MCN. All rights reserved. / Page

79 of 80

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

  • 2012-2015 MCN. All rights reserved. / Page

80 of 80

How to Bring All These Together?

Use Support Services

Cloud Controller

MCN Service Instance N

Service Manager (B+T)

Cloud Controller

MCN Service Instance M

Cloud Controller

MCN Service Instance K

SO

SO

Service Manager (B+T)

Service Manager (B+T)

SO

Multiple e2e tenant services:

Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN Service, ....

SICs

SICs

SICs

  • 2012-2015 MCN. All rights reserved. / Page