end-to-end cloudification of mobile telecomsportugal.chapters.comsoc.org/files/2016/01/... ·...

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

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

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 Service Categories

Lifecycle of a MCN Service

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)

Service Manager Internals

• Main entry point so

service management

for EEU

• Overall management

of SM’s SO’s

• Maintains list of

services offered by

Service Orchestrator Internals

• enforces decisions

towards the CC

• interacts with CC

entities

• Graph of required

services and

resources for service

instance

CloudController Internals

MCN Key Arch Elements Overview

support or MCN

All are used throughout MCN

MCN Services and Arch Elements

Beyond MCN

How does this fit to State of the Art?

MCN and NFV Mapping

Approximate Mapping

CloudController

Service

Orchestrator

Openstack

Service Instances

STG, ITG

Service Manager

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

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 and TMForum Mapping

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

Business Service

Manager

Deploy, Provision Runtime Management

MCN also deals

• Design

• Implementation

• Disposal

MCN and TMForum Mapping

TMForum Application framework (TAM) / eTOM

Business Service Manager

Technical Service Manager

CloudController

Support Services

● SLAaaS

● MaaS (CMMS)

● RCBaaS

Atomic Services

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

Both public and private cloud

resources

Scenario Assumption

Service designed and

implemented

Created?

EEU requests a service

instance

Providers, Services and

CloudControllers

How is an E2E MCN Service Instance Created?

Deployment phase

Service managers

inside each service

provider

Created?

Deployment phase

created to oversee

instance creation

Created?

Deployment phase

requests necessary

services creation

Created?

Deployment phase

Each required service

provider’s service

manager creates a

service orchestrator

Created?

Deployment phase

Service orchestrators

that require services

from the

CloudController

requests them

Created?

Where are we?

Deployment phase is completed

Eventually all services are created

Not configured however

Provisioning phase begins…

Created?

Provision phase

The SO has access to

all other service

instance management

endpoints

Configuration

information is supplied

to these

Created?

Provision phase

Service orchestrators

may pass on

configuration to

CloudController

Created?

Where are we? Ready for service

Deployment & provisioning phase completed

Service instance management interfaces are available to the

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

Key Enabling Framework Technologies

Service Manager

Python, Pyssf, OCCI

Cloud Controller

OpenShift, OpenStack, Pyssf, OCCI

Upcoming

Architectural Refinement

Based on software development

Software to be released as open

source

Apache 2.0

Submission as NFV prototype to ETSI

Thank You!

Backup

Federation

EGI FedCloud

Fed & Interop Challenge!

A Solution? EGI FedCloud

Fed & Interop Implemented!

Cloud & Services

• Cloud service categories – IaaS, PaaS & SaaS

• Deployed – Public, private

– Both considered for the MCN Arch

Cloud & MCN

● Cloud-defined (NIST)

○ On-Demand, Self-Service

○ Resource Pooling

○ Broad Network Access

○ Rapid Elasticity

○ Measured Service / Pay-As-You-Go

From...

● System is contained to local resources

● Scaling is limited by local resources

○ Difficult beyond - requires rearchitecting

● Many existing systems are built like this

● 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

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.

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.

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.

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.

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

Technical Phase

Design: Design of the architecture, implementation, deployment, provisioning

and operation solutions. Supports Service Owner to "design" their service

Technical Phase

Implementation: of the designed architecture, functions, interfaces, controllers,

APIs, etc.

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.

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.

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.

Technical Phase

Disposal: Release of SICs and the service

instance itself is carried out here.

Service Manager

EEU or requesting SO

submits a request for

a service instance

(direct, UI or CLI)

Service Manager

contains a list of the

available services

offered by the

provider

Contains a list of the

available services

offered by the

provider

Service Manager

deploys the SO

bundle to the CC

Service Manager

provisioning of the

service instance incl.

all SICs

Service Manager

Tracks all provisioned

SOs (service

instance)

Also contains info on

all mgt interfaces

Service Manager

Deletes the complete

service instance

All requests by SM to

SO goes through here

Takes decisions on

the run-time

management of the

SICs (e.g. based on

monitoring data)

Responsible for

enforcing the

decisions towards the

What services are

required to support

the SO

implementation.

How they’re

configured.

Model defined by CC

What services are

required to support

the SO

implementation.

How they’re

configured

Diff - live information

from CC

CloudController

Provides a Frontend

and exposes an API

which can be used to

interface with the CC.

CloudController

Allows the listing of

capabilities which the

CC offers

CloudController

Will enable the

deployment of the SO

and its individual SIC

CloudController

Will enable the

configuration of the

CloudController

Takes care of runtime

operations such as

scaling requests

CloudController

will support the

disposal of each SIC

CloudController

Interface with other

Services, requested

by higher layers

How to Bring All These Together?

Use Support

Services

Cloud Controller

MCN Service

Instance N

Service Manager

Cloud Controller

MCN Service

Instance M

Cloud Controller

MCN Service

Instance K

Service Manager

Multiple e2e tenant services:

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

Service, ....

SICs SICs SICs

Drop this

Sequence diagram in D2.2

Drop this

MCN and NFV Mapping

This is an approximate mapping

Update image

Orch covered only by half

Colors and Halftone Values

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

2015 by MCN Consortium.

Use Support

Services

Cloud Controller

MCN Service

Instance N

Service Manager

Cloud Controller

MCN Service

Instance M

Cloud Controller

MCN Service

Instance K

Service Manager

Multiple e2e tenant services:

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

Service, ....

SICs SICs SICs

end-to-end cloudification of mobile telecomsportugal.chapters.comsoc.org/files/2016/01/... ·...

Documents

vehicle reusability - university of...

designing and developing interactive training for...

data modeling on steroids: patterns and reusability

reusability in the oracle adf development

cookbook reusability @ chef community summit 2014

pioneering reusability and convenience in the …

usability, reusability and reproducibility of bioinformatic...

ahead of the nfv curve with truly scale-out network function...

ebook carrier cloudification: what every telecom executive...

rethinking reusability

code reuse & reusability of the software

cloudification of on-premises data warehouses

reusability measure of devs simulation models in devsim++...

variables limit reusability - rebecca wirfs-brock

application of membrane technology towards the reusability

thermal response and reusability testing of advanced

reusability-oriented software engineering

reusability and hydrocarbon rocket engines relevant us

a cloudification methodology for high performance...

cloudification™ - the evolution of the server hugger -...