icin2012

Session 1 "Cloud Opportunities for Telcos"

Towards a CAPEX-free Service Delivery Platform

Company logos may appear on this title page

P. Baglietto, M. Maresca, M. Stecca - CIPI University of Genoa and Padua

C. Moiso - Strategy Telecom Italia

Outline

• Introduction• Moving Service Platforms In The Cloud• Embracing Open Source Software for the SDP• Open Source Service Platforms in The Cloud• Case Study: An Elastic Open Source Service

Orchestrator• Conclusions

8-11 Oct 2012 Session 1 / Towards a CAPEX-free Service Delivery Platform

2

• Is it possible to decrease CapEx and to transform part of these expenditures into OpEx?– To reduce costs– To improve efficiency– To reduce the risks related to the launch of a *real* new

service• How can we do that?

– Open Source Software (OSS)– Cloud Computing (Cloud)– OSS + Cloud

In this paper we explore the pros/cons related to these three solutions


3

Introduction

1. Virtualizing SDP (Service Delivery Platform) components in the Cloud

– Private/Public Cloud– Hybrid Cloud (e.g., to manage unexpected traffic peaks)

2. Virtualizing users’ terminals in the Cloud– To compensate mobile terminals limited on-board

resources (see, e.g., the ‘CloudPhone’ and the ‘Virtual Smartphone over IP’ projects by Intel and NTT) See #1 in next slide

– To “reduce the distance” among mobile terminals and the SDP See #2 in next slide


4

Moving Service Platforms in the Cloud (1/3)


5


#2

#1

• Pros– Cost Reduction (e.g., pay-as-you-go model, auto-scaling,…)– From CapEx to OpEx– Improved Time to Market– ‘Green’ approach


6


• Pros– Cost Reduction (e.g., pay-as-you-go model, auto-scaling,…)– From CapEx to OpEx– Improved Time to Market– ‘Green’ approach

• Cons/Risks– Lock-in (due to lack of standardization)– Licensing problems (e.g., Oracle)– Data privacy (for European users, see the Directive

95/46/EC)– Software/Hardware specific requirements


7


• …and pay attention with the Cloud Providers


8



9

Embracing Open Source Software for the SDP (1/3)

The SDP reference architectural model

• Examples of Open Source SDP components:– Core Network: Open IMS Core (part of the Open IMS Playground

@ FOKUS);– IP PBX systems: Asterisks;– SMS gateway: Kannel;– MMS gateway: Mbuni;– Application Servers: Mobicents (JSLEE + SIP Servlet), JBoss,

Glassfish; – Map-Reduce: Hadoop; – NoSQL databases: HBase, MongoDB;– Enterprise Service Bus: Apache ServiceMix;– Service Orchestration: Orchestra, Apache ODE;– …


10



11


• Pros– cost effective and flexible approach– mitigate the ‘lock-in’ from vendors– increase the level of ‘mastering’ of all the software stack– platform enhancement in a shorter time frame and at

lower costs

• Cons/Risks– lack of support– risks of infringements of licensing terms – Telcos must adopt new specific procedures for ‘software

quality’ control


12

• Telco might take advantage of both the OSS and the Cloud paradigm.

• In order to exploit this opportunity, we defined a table (see next slide) where – The rows represent the Cloud choice (Public vs.

Private);– The columns represent the software choice:

• OSS;• Vendor software;• Custom software (i.e., developed by the Telco Operator).

Open Source Service Platforms in The Cloud (1/2)


13

Open Source Service Platforms in The Cloud (2/2)


14

So far…

Next: a real example for OSS + Cloud


15

An Elastic Open Source Service Orchestrator (1/4)

• We developed a Service Orchestrator using OSS1

• We deployed such a system on a Private Cloud based on the commercial product VMware2

• We finally deployed it on an Open Source Private Cloud

1 Stecca M. et al, “Scalable Orchestration of Telco/IT Mashups”, ICIN 20092 Stecca M. et al, “An Architecture for a Mashup Container in Virtualized

Environments”, IEEE Cloud 2010


16


Products:• IaaS system: Eucalyptus (Hypervisor: KVM); • Load Balancer: HAProxy; • Orchestrator middleware: JBoss AS messaging system (i.e., JMS).


17


• In order to have an elastic system we extended the Eucalyptus IaaS framework with 3 new components: – A Load Balancer: we re-used the Open Source HAProxy

Load Balancer; – The Monitor: it monitors the VMs’ resource usage; – The Control Daemon: it knows the entire status of the

system and decides whether it is necessary to execute a scaling operation (the user can define some triggers like, e.g., “turn on a new virtual machine if the incoming traffic goes beyond 100MB/s”).


18

An Elastic Open Source Service Orchestrator (4/4)• A Scale-up operation can be summarized as follows. The Daemon

Controller:– detects the need for a new Scale-up operation by comparing the

Monitor collected data against the thresholds defined by the user;– chooses the appropriate virtual machine type and image, according to

the user preferences;– checks whether there are enough resources to be allocated to the new

virtual machine in the Eucalyptus system;– sends a request to the Eucalyptus infrastructure to start a new virtual

machine; – waits for the new virtual machine activation and initialization. When

the virtual machine is in the ‘running’ status, the system updates the Load Balancer configuration by adding the details of the new virtual machine;

– finally the Control Daemon issues the ‘hot-reconfiguration’ command to the HAProxy Load Balancer.

• We analyzed the advantages and the potential risks that must be taken into account when moving the SDP’s components to an OSS/cloud-based solution.

• It is possible to transform CapEx into OpEx but the 0-CapEx SDP is not a reality yet.

• We described an OSS/Cloud-based Service Orchestrator.

• We are planning to migrate other SDP’s components to OSS-based/cloud-based systems with particular attention to mobile terminals.


19

Conclusions

20

The EndMichele Stecca

Follow me on Twitter: @steccami

icin2012

Documents

new service

service delivery platform2

service delivery platform3

service delivery platform4

service delivery platform8

service delivery platform11

service delivery platform15

open source private