SLA Management and Service Composition of

Virtualized Applications in Mobile Networking

Environments
Giada Landi

Thijs Metsch

Nextworks
Via Livornese 1027,
56122 Pisa, Italy
g.landi@nextworks.it

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
thijs.metsch@intel.com

Pedro Miguel Neves

Julius Mueller

Portugal Telecom Inovao

Rua Eng. Jos Ferreira Pinto Basto,
3810-106 Aveiro, Portugal
pedro-m-neves@ptinovacao.pt

Senior Researcher
Chair Next Generation Networks
Technical University Berlin
julius.mueller@tu-berlin.de

Andy Edmonds

Paolo Secondo Crosta

InIT Cloud Computing Lab,

Zurich University of Applied Sciences,
Winterthur, Switzerland 8401
edmo@zhaw.ch

Italtel Spa,
Via Reiss Romoli,
20019 Settimo Milanese (MI) - Italy
paolosecondo.crosta@italtel.com

Abstract Cloud computing is a promising solution for the

flexible, on-demand delivery of communication services and
infrastructures. The European Union funded project Mobile
Cloud Networking is developing a cloud-based mobile
communication service platform where service providers deliver
virtualized wireless infrastructures integrated with high-level
applications running on top of them. Mobile networks are
redesigned, placed upon and operated on cloud computing
platforms. These then are available with the on-demand, elastic
and pay-as-you-go characteristics derived from the cloud
principles. In this platform, a variety of services including
heterogeneous radio networking, federated computing resources,
virtualized network functions, support services and high-level
applications are automatically and seamlessly orchestrated in
composite end-to-end services delivered to enterprise end-users.
The management of Service Level Agreements (SLAs) for these
cloud-based composite services requires a dedicated framework
to combine and jointly manage the multiple SLAs associated to
the different service components. This paper presents an
architecture for the enforcement and validation of SLAs for
mobile cloud services, discussing its positioning in the overall
mobile cloud networking platform and its role across the
different phases of the service lifecycle.
Keywords SLA, cloud services, mobile networking, service
orchestration, distributed services
978-1-4799-0913-1/14/$31.00 2014 IEEE

I.

INTRODUCTION

The rapid evolution of mobile networks towards a fully

cloud-based mobile communication system and the extension
of cloud computing paradigms [1] to an on-demand and elastic
provisioning of services are two of the most important trends
in progress nowadays. Mobile cloud computing is emerging
rapidly as an exciting new trend paradigm to extend the
capabilities of mobile devices and platforms, with many
innovative mobile services (mobile video streaming, rich
media, e-gaming, e-health, etc.).
The EU project MobileCloud Networking (MCN [2]) is
developing a cloud-based mobile communication framework
and platform, where heterogeneous virtualised resources
including radio networking, distributed computing and storage
resources are jointly delivered as end-to-end services. In this
scenario, virtualized LTE (Long Term Evolution)
infrastructures, including Radio Access Network components
and Evolved Packet Core (EPC) deployed on distributed data
centres, can be dynamically combined with further cloudbased high-level applications, like Content Delivery Networks
(CDN) or Digital Signage Service (DSS) and delivered as
fully integrated services to enterprise end-users.
The chain of infrastructure, platform and application
services can be offered either by a single provider or through
the composition of multiple providers. For example the role of

the RAN infrastructure provider can be decoupled from the

cloud infrastructure provider, while different actors can
provide the EPC-as-a-Service and the CDN-as-a-Service
respectively. However, even the single provider scenario must
deal with new challenges, from the composition of a variety of
interdependent virtualized network services and high-level
applications, to the sharing of the heterogeneous and cross
domain cloud/network infrastructure among multiple tenants.
It becomes essential for the MCN Service Providers to use an
end-to-end approach and to integrate all the services in an endto-end perspective, developing all potential added values
inside the convergence between Telco and IT worlds. In this
context of multiple cooperating services, Service Level
Agreements (SLA) play a fundamental role in the system.
Several European projects have investigated the SLA topic
in scenarios with multiple resource domains and services,
considering the problem from different perspectives. In the
network area, the ETICS project has proposed a hierarchical
composition of SLAs for end-to-end QoS-enabled
connectivity services delivered from a chain of Network
Service Providers [3], designing a suitable SLA template to
capture the related business and technical implications. The
GEYSERS project has defined a converged SLA management
system able to handle the combination of network and cloud
services over virtual infrastructures. In this case a variety of
strategies have been proposed to allow cooperating
infrastructure providers, virtual network operators and cloud
service providers to guarantee consistent SLAs across the
physical and virtual service layers [4]. The CONTRAIL
project has defined mechanisms to support SLA management
for cloud federation [5], with focus on automated generation
of SLA offers, negotiation among multiple providers and
selection of optimum SLA.
The MCN approach focuses on the seamless integration of
SLA management capabilities in the multi-service framework
defined by the project. The objective is to design a MCN
platform offering the capability to guarantee and validate the
compliance of the end-to-end services delivered to the
customers with the agreements defined during the business
negotiation, independently on the complexity of the atomic
instances composing the final service. In this kind of scenario,
the main challenge is to collect and combine together in a
consistent manner a variety of parameters of different nature,
referring to different layers (e.g. utilization of network or
cloud resources, service performance), and belonging to
different domains.
From a business point of view, an improved customer
experience resulting from QoS and SLA enforcement may
push content and service providers to share revenues for their
services with network providers, to ensure better customers
experience and in return for customer satisfaction. Exploiting
the cloud computing principles, MCN Service Providers can
take full advantage of new customer charging models, apply a
pay-per-use model, and use cloud flexibility to deliver
resources as needed, without over-provisioning techniques,
and react in an appropriate way to SLA violations. The
automatic SLA enforcement and validation is a fundamental
mechanism to offer service reliability from the provider side,
in a fully transparent, but customer-driven, fashion.

In this paper we present the reference architecture of a

SLA-as-a-Service management framework, as a support
service handled by a MCN Service Provider and integrated
with the overall MCN architectural components. Starting from
the description of MCN services and their composition, we
present how to use cloud principles to offer a SLA-as-aService. Moreover, we discuss the role of SLA management
during a services lifecycle and its integration with the MCN
architecture, showing how this architecture can be flexibly
used and adopted in a variety of settings. Finally, we suggest
ideas for further investigations, with special focus on SLA
support for composed services delivered by multiple service
providers.
II.

A REFERENCE ARCHITECTURE FOR A MOBILE CLOUD

ENVIRONMENT

In a mobile cloud environment, services are dynamically

deployed on the cloud and delivered on demand to the
customers. This model enables a strong flexibility in the
provisioning of different types of services, where one or
multiple providers can combine and configure instances of
different components to cooperate together, ready to be
delivered as a single end-to-end service for enterprise endusers. In MCN, this concept is exploited to deliver integrated
cloud services composed of wireless virtual resources, mobile
network connectivity and high-level applications deployed on
top of them, everything coordinated in an end-to-end service
chain. The entire MCN framework follows a service-oriented
architecture, where all the functional elements are modeled
and delivered as services. The key architectural entities of the
MCN architecture are represented in Fig. 1, where the dotted
lines indicates how they interact together.

Fig. 1. MCN Architectural Functional Elements

The Service Manager (SM) provides an external interface

to the enterprise end-user, both programmatic and/or visual,
offering multi-tenant capable services. The SM constitutes the
entry point for all the requests for a given service in the MCN
architecture. The SM has two dimensions: the business one,
which encodes business agreements, and the technical one that
manages the Service Orchestrator instances related to all the
particular tenants. The Service Orchestrator (SO) is a domain
specific entity with the knowledge of the internal
implementation of the service (e.g. in terms of quantity, type
and interconnection of the VMs composing a service
instance). Generally, one SO per SM domain is instantiated for

each tenant and the SO itself is managed by the SM. The SO

oversees the complete, end-to-end orchestration of a service
instance, usually decomposed in service instance components.
In particular, it manages the creation of the service instances,
their scaling up and down at runtime, the monitoring of the
associated metrics and the disposal at the end of their
lifecycle. The actual provisioning of the resources composing
a given service is handled by the Cloud Controller (CC). This
entity offers the SOs the mechanisms to provide services of
categories atomic (computing, networking or storage
resources) and support (e.g. monitoring, analytics, charging
and billing, ) through a Service Development Kit (SDK).
A. Mobile Cloud Services Lifecycle
Each architectural entity and service within MCN shares a
common lifecycle model. The lifecycle model is divided into
two complementary phases, the business and the technical
phase. During the business life cycle phase (Fig. 2), Service
Provider and Service Customer negotiate the type and the
quality of the service that will be delivered, specifying the
associated SLAs. This initial phase is typically structured in a
design step, where the two parties establish the characteristics
of the service and the Service Provider defines its
decomposition in internal and outsourced resources or subservices, and an agreement step. The SLA negotiation takes
place during this last step and involves both business and
technical agreements, like prices, compensations for service
violations, access models and QoS parameters. It should be
noted that SLAs among different cooperating Service
Providers are required in case of federation and usage of
outsourced resources.

Fig. 2. MCN Services: Business Lifecycle

The technical life cycle phase is structured in six

subsequent stages as shown in Fig. 3.

Fig. 3. MCN Services: Technical Lifecycle

The initial services technical design provides the

guidelines for the service implementation, which entails also
the implementation of a SM and a SO. During the deployment
phase, the service components are deployed using the CC. At
this stage the SO itself is deployed, so that the SM can start to
receive requests to create new service instances. Once the SO
is fully instantiated, in the provisioning phase it can start to
create and configure all the service instance components that
constitute the end-to-end service. During the runtime and

operation the SO is responsible for the monitoring and

management of the entire service, including, if needed, the
scaling in and out of the components. Finally, at the
termination stage, the service instance sub-components are
destroyed and deleted.
III.

THE MCN SLA MANAGEMENT SYSTEM

The management of the SLAs associated to the MCN

services is a fundamental function that enables the MCN
Service Providers to delivery end-to-end services compliant
with the features and performances expected by the customers.
The fundamental and most challenging characteristic of the
SLA management approach is the automatic combination of a
mixed set of information, derived from the multiple service
components, according to the required interactions and
interoperations among the services. This combination allows
to deliver the whole service as an integrated single instance
fully compliant with the global customers expectations.
Monitoring data are elaborated according to SLA rules able to
describe not only the Service Level Objectives of the single
service instances composing an end-to-end service, but also
their inter-dependencies and expected cooperation.
SLA guarantees are evaluated from a combined dual-level
perspective, at the virtual infrastructure and application layers.
This approach requires the real-time collection of monitoring
data from the virtual infrastructure at the resource-level (e.g.
status of VMs or wireless links) and from the different
services at the application level (e.g. number of on-going calls,
caching size for CDN contents). Their joint evaluation allows
to validate the performance of the global MCN service,
independently on the complexity of the service instances
composing the end-to-end chain. It should be noted that in this
context the traditional measurement of QoS parameters at the
physical infrastructure level may be not enough. Suitable
abstraction and decomposition models must be applied in
order to evaluate the real impact of the performance achieved
in single layers or domains with respect to the high-level endto-end SLAs.
SLA management in the MCN architecture is provided
through a dedicated support service, handled by a Service
Provider. As any other service in the MCN environment, it can
be deployed and provisioned on-demand on a cloud platform.
This is a key feature, since it allows to automatically adapt the
SLA system to the dynamicity of the other services. For
example, it can easily evolve to support new MCN services
through the real-time creation of agents specialized for a new
type of monitoring data.
The SLA management service is a prerequisite for the
provisioning of all the other high-level SLA-enabled MCN
services, since it is the component that enables a generic MCN
Service Provider to guarantee and validate the compliance of
the delivered services with the agreements negotiated with its
customers. The SLA management system provides three main
functionalities: it acts as a centralized SLA repository for all
the services, supports the SO in the SLA enforcement and
implements the procedures for SLA verification.
As SLA repository, the SLA management system provides
a secure access to the catalogue of SLAs negotiated between

customer and provider for the MCN services. Each SLA entry
includes information about the Service Level Objectives
(SLOs) defined for the given service and reports the occurred
SLA violations or service performance degradations.
The SLA enforcement is initially applied during the
provisioning of each service instance and is continuously
guaranteed during the service execution. In this phase,
proactive procedures verify the service performances for in
advance prediction of potential SLA violations in order to
trigger an automated service scaling. This aspect is strictly
related to the SLA verification, which evaluates the service
performance to verify the consistency with the specific SLOs.
This verification is based on monitoring measurements
retrieved from the MCN monitoring service (see section IIIC), elaborated to detect any SLA breach occurred during the
service runtime. SLA violations are stored in the SLA
repository and immediately reported to the Rating, Charging
and Billing (RCB) service.
SLA enforcement during the on-demand service
provisioning is based on a top-down SLA propagation model,
where the overall metrics are decomposed and translated on
the technical characteristics of each component. On the other
hand, SLA verification (i.e. monitoring and re-enforcement
through continuous validation and close-loop feedbacks) are
managed through a distributed approach, with lightweight
SLA agents interacting with the monitoring service for each
service component.
A. SLA Management System Architecture
Fig. 4 provides the FMC (Fundamental Modeling Concept)
representation of the internal architecture of the SLA
Management System (dark grey boxes). The picture shows
also the interaction with the external components of the MCN
architecture (see section II) and other support services, like
Monitoring and Rating, Charging and Billing.
SM
instance

SO
instance

SLA Repository

Collector

Aggregator

SLA Rules
Engine

Feedback
Manager

Centralized SLA Management System

CC
instance

MCN Service

Per-atomic-service
distributed SLA Agents

Monitoring
Service
Instance

RCB Service
Instace

Fig. 4. SLA Management System.

The architecture is based on a centralized module, called

Centralized SLA Management System, a persistent component
that constitutes the core of the entire SLA framework, and on
distributed SLA agents deployed on-demand for each single
MCN service provided by the MCN provider.
The centralized module is the global repository and
processing engine for the SLAs associated to all the services
offered by an MCN provider. This module is instantiated

within the MCN platform, independently on the specific

services delivered to the customers, and it acts as the SLA
service contact point for all the other components of the MCN
framework. The distributed SLA agents are deployed ondemand and have a per-service-instance scope: at least one
SLA agent is required for each single service instance
provided within a composite MCN service. The agents collect
monitoring information about the virtual resources composing
the infrastructure where the services are running, together with
application-specific monitoring data characterizing each
service. The collected information, optionally filtered and preprocessed locally, is forwarded to the Centralized SLA
Management System. Here, they are combined and jointly
elaborated considering the inter-dependencies between the
different components of the whole MCN service.
The centralized SLA management system is internally
structured in further functional components, as follows:
SLA Repository: centralized storage point for all the SLAs
available for the different services and customers handled by
an MCN provider. SLAs are modelled through generalized
templates, extended with the QoS parameters and metric
charactering each specific service. The generic template
includes cross-service aspects like price models, monitoring,
procedures for service modification and reactions to SLA
violations.
SLA Rules Engine: responsible for the processing and
validation of the SLA rules, including the SLO decomposition
in atomic rules that must be jointly applied to validate the
compliance of the overall service with the active SLAs.
Collector and Aggregator: modules in charge of collecting
the monitoring information from the distributed SLA Agents
and responsible for their aggregation in consolidated reports
generated periodically to enable the prediction or detection of
SLA breaches.
Feedback Manager: decision point about SLA violation apriori predictions and post-detections. In these situations,
automated and asynchronous notifications are issued to trigger
actions from external MCN components or services. For
example, decrease of performance can be notified to the
Service Orchestrator of the high-level MCN service, so that
countermeasures can be applied to avoid or mitigate future
SLA violations.
In the MCN framework, part of the SLA management
system (e.g. the SLA agents) is inherently deployed on the
cloud, installed in VMs running on data centers. This is due to
the specific on-demand nature of these components that can be
considered as an integrated part of each on-demand MCN
service. However the Centralized SLA Management System
can be also deployed itself on the cloud, thus exploiting the
dynamicity and elasticity features offered by the cloud
paradigm. This model enables the Service Providers to
automatically adjust the resources dedicated to the Centralized
SLA Management System to its real-time requirements. The
processing resources can be scaled up and down depending on
their work-load, the amount of monitoring information or the
number of deployed SLA agents. Storage resources used to

host service catalogues and SLAs repository can be resized

according to the number of customers or offered services.
B. SLA Management and service lifecycle
The role of SLA management is fundamental in two steps
of the MCN service lifecycle, as shown in Fig. 5.

provider or through cloud federation) is entirely managed at

the Cloud Controller, while the Service Orchestrator is not
aware of the specific capabilities of the cloud infrastructure(s)
where the end-to-end service will be deployed.

Fig. 6. SLA enforcement during service provisioning.

Fig. 5. SLA Management in the MCN Service Lifecycle.

The SLAs negotiated between customer and provider are

activated and enforced during the deployment and
provisioning of the specific service instance; once running, the
service is continuously monitored to verify the compliance of
the real-time service characteristics and performances with the
given SLA. These actions require the collaboration between
the SLA service and other MCN components or support
services during the entire lifecycle of the high-level MCN
service.

During service runtime, the SLA service becomes

responsible for the validation of the service performance
against the SLAs negotiated with the customer. In order to
guarantee the continuous compliance between service
characteristics and customer expectations, the MCN platform
implements an iterative loop of feedbacks and reactions to
automatically re-adjust the resources and configurations of the
service to the dynamic load of the applications.

Fig. 6 and Fig. 7 detail the workflows and the interaction

between the different entities during service provisioning and
service runtime respectively. The left side of the pictures
represents the main MCN architecture entities (SM, SO and
CC) for a general MCN service exploiting the SLA features
offered by the platform. The dotted lines between the internal
components of the Centralized SLA Management System
indicate a general interaction, while the numbered arrows
show the sequence of messages exchanged between the
different entities.
As mentioned in section II, the requests for the on-demand
provisioning of composed MCN services are mediated through
the Service Manager and coordinated at the Service
Orchestrator level. In the deployment and provisioning phase,
shown in Fig. 6, the Service Orchestrator interacts with the
SLA management system to retrieve the specification of the
SLOs currently in place for the service to be instantiated. The
SLOs technical parameters (e.g. QoS attributes, monitoring
metrics) are translated in the corresponding service
infrastructure description, which specifies the type and amount
of resources and configurations required to meet the active
SLA. The infrastructure description is then enforced by the
Cloud Controller, that instantiates and configures all the
atomic components of the end-to-end service (including the
SLA Agents). The management of the available resources, as
well as the decisions about the location of the new VMs (e.g.
in a single or multiple data centres, from a single cloud

Fig. 7. SLA validation during service runtime.

The distributed SLA Agents interact with the monitoring

service to collect monitoring measurements related to the
infrastructure usage and the atomic instances composing the
end-to-end MCN service (step 1 in Fig. 7). Monitoring data
are locally pre-processed (e.g. filtering redundant information)
at each SLA Agent and forwarded to the Centralized SLA
Management System (step 2). The messages exchanged
between agents and centralized module are typically
asynchronous and characterized by a per-atomic-service
scope. They can be generated periodically or triggered when a
violation is detected within a single service component. The
Collector parses the received data and groups reports related to
the end-to-end services, while the Aggregator elaborates the
resulting data applying the algorithms specified by the active
SLA rules. This processing generates consolidated SLA
reports, describing the overall and end-to-end performance of

an MCN service in different time intervals. When received at

the Feedback Manager (step 3), the summarized reports are
analyzed and compared with the previous ones to identify
performance degradations that may lead to future SLA
violations or reflect already occurred SLA breaches.

tenant. The MaaS lifecycle follows the same principles of any

other MCN service: it is originated from the Service Manager
and coordinated through the Service Orchestrator, in
cooperation with the Cloud Controller.

Important features are the capabilities to identify the

factors (i.e. a service misbehavior, a failure in the virtual
infrastructure) at the origin of the service degradation and to
predict performance downgrading in advance, in order to
effectively avoid or limit the impact of SLA violations. A
possible solution is the implementation of internal SLAs,
transparent from the customers perspective, and enforced
only at the service provider level to detect critical situations,
without waiting for an explicit SLA violation occurrence.
Internal SLAs can be enforced applying a double level of
thresholds. The former indicates an initial service degradation,
still acceptable for the limits of the official SLA, but can be
used to take pro-active countermeasures and upgrade the
service infrastructure accordingly. On the other hand, the
second threshold identifies an SLA breach that has already
occurred and, as such, must be notified to external components
(e.g. RCB service, Service Orchestrator) for further actions.
The notification of SLA alerts, possibly including
indications for counteractions (indicated with step 4 and step 5
in Fig. 7) are considered just as suggestions in the MCN
framework, while the final decision points for money
compensation and service/resource modification resides in
RCB service and Service Orchestrator respectively. This
choice allows to apply more efficient compromises at the
Service Orchestrator level, possibly considering other factors
like the current infrastructure load or the coexistence of other
degraded services. If the Service Orchestrator decides to react
upon the SLA violation feedback and modify accordingly the
resources allocated for the service, the Cloud Controller
receives a new service description (step 6) and enforces the
requested modifications (step 7).
C. Infrastructure and service monitoring
As analyzed in the previous section, the MCN SLA
management system requires precise and real-time monitoring
information of all the MCN services involved in an end-to-end
scenario. Therefore, Monitoring-as a Service (MaaS) has been
realized to provide a collection of data, derived out of multiple
services, where monitoring information are exposed as a
service towards other MCN services, including the SLA
management system.
Two main dimensions for monitoring have been taken into
consideration while designing the MaaS. The first horizontal
dimension covers the end-to-end domain including the access,
core and backbone network. The second vertical domain
follows the NIST cloud paradigms [1] and is structured into
the layers software, platform and infrastructure. All layers
expose service specific metrics, which are monitored for
ensuring the correct SLA management in real-time.
MaaS, as depicted in Fig. 8, is created and initiated
through the Service Requestor. This role in MCN intiates the
automated lifecycle management of the MaaS platform and
the configuration of the parameters to be monitored for each

Fig. 8. Monitoring as a Service.

The MaaS platform is composed of two main types of

module: a centralized Common Monitoring Management
System (CMMS) and several distributed Monitoring Agents.
Monitoring data is extracted from each service instance
component using a dedicated Monitoring Agent, specialized to
interact with a given components and manage the specific type
of produced measurements. Monitoring Agents expose certain
metrics through the southbound API of the CMMS, providing
monitoring information through a unified information model
towards the Aggregation point. A database stores the metrics
persistently and allows other MCN Services to query the
CMMS through the Frontend in order to retrieve specific
monitoring data.
The Monitoring Agents operates on the specific vertical
and horizontal levels described earlier. Various metrics and
parameters can be monitored such as number of used CPUs,
RAM, storage (infrastructure level), number of deployed Call
Session Control Functions (CSCFs) or Mobility Management
Entities (MMEs) or size of a VM (platform level) as well as
number of attached mobile subscriber service or load of the
Video on Demand (VoD) service (application level).
The implementation of the CMMS is based on the Zabbix
tool [6], while different Monitoring Agent can be used
depending on the specific type of monitoring information to be
collected. For example, Ceilometer [7], the metering
component of OpenStack, can be used for all the monitoring
data associated to the cloud infrastructure.
IV.

SERVICE LEVEL DELIVERY IN THE CLOUD

The key for getting guaranteed SLA in the cloud is through

proper service exposure. Cloud computing lives from the fact
that capabilities are offered out on-demand, scalable and as-a-

Service. Hence there is a need to expose service provider

supported service levels in the cloud to end users.
Exposing functionalities in the cloud is done today through
creating APIs. Those APIs are mostly offered out over the
HTTP protocol and follow the REST paradigm. So ideally
when dealing with SLAs there would be an API in place
which allows for handling SLAs.
Next to these pure technical functionalities, it is key that
services which shall fall under a certain SLA can come from
multiple sources. Also the customer of those services might
choose to create a cloud service based on multiple other
composed services and hence should create an SLA which
builds upon other SLAs, in doing so creating a composed
SLA. This composition of services if key in modern
infrastructures such as the one proposed by the MCN project
[2]. Standardized APIs for exchange and negotiation of
multiple SLA offers, as well as for enforcement and validation
of SLA rules, are fundamental in these scenarios that integrate
a variety of SLA-enabled composed services.
Standardization is a main aspect of offering out reusable,
stable and reliable interfaces. The European Commission has
identified that strong requirements for standards related to
cloud and SLA exist and they recommend in [8]: [...] the
adoption of current SLA standards [...] highlights the success
potential and need for standards. It is therefore recommended
to develop domain agnostic standards and to encourage SLArelevant standards (e.g. Open Cloud Computing Interface OCCI, [...]) to incorporate enhancements which further
enable SLA support.. OCCI indeed seems to be a promising
candidate to control SLAs with. Blumel et. al. [9] already
identified the usage of WS-Agreement over OCCI as a
feasible solution. Furthermore the EU projects SLA@SOI [10]
and RESERVOIR [11] have shown that OCCI can be used to
ensure interoperability in [12].

in place to establish SLAs and to guaranteed a way to monitor

the resources and verify that the SLA is no breached. Today
the OCCI interface is widely adopted in cloud environments
and it is highly flexible in supporting the definition of new
extensions. Therefore it can be considered an excellent
candidate for the interface to exchange SLA information
related to cloud service components, so that hierarchical SLAs
can be dynamically created on top of it. Furthermore, the SLA
validation and the monitoring of the resources under SLA
control must be assured to have a certain transparency.
V.

CONCLUSIONS AND FUTURE WORK

This paper has presented an architecture and some

procedures for the management of SLAs of composed Mobile
Cloud Networking services. An initial proof of concept
prototype is in progress and it is expected to validate a sample
composition of services where virtualized Radio Access
Network resources and Evolved Packet Core are offered as an
on-demand end-to-end cloud service with a Content Delivery
Network application running on top of them.
The proposed reference architecture is mainly tailored to
scenarios with a single service provider offering the full chain
of end-to-end service components to the final customer.
However the MCN SLA concepts can also be applied in case
of service federation, where multiple service providers
cooperate to provide a seamlessly integrated service. The
future work will analyze in more details the impact of this
scenario on the SLA management, with particular focus to the
cooperation of multiple SLA management systems and
services, each of them handled by a single Service Provider.
Different levels of SLA and monitoring information
disclosures among the different service providers will be
analyzed, identifying the most suitable interfaces across these
administrative domains and federated procedures for SLA
enforcement and validation, as well as effective strategies for
revenues sharing and compensations.
ACKNOWLEDGMENT
This work has been funded by the FP7 EU Project
#318109 MobileCloud Networking. We thank our project
partners for their valuable contributions.
REFERENCES
[1]

[2]
Fig. 9. Customers Using Service Level Assured *aaS.

Fig. 9 shows two customers, A and B, using one or

multiple services, provided through the as-a-Service
paradigm (*aaS indicates a generic resource or application
offered as a Service), with an SLA in place. Customer B
directly communicates with an IaaS and has an SLA in place.
Customer A however has an SLA in place between himself
and his provider. In this case this provider builds upon the
SLAs exposed by the IaaS provider.
This kind of hierarchical/composed SLAs is key in a
service-oriented cloud. In both cases, in order to make services
and SLAs composition more programmable, an API must be

[3]

[4]

[5]

[6]
[7]

P. Mell, and T. Grance: The NIST Definition of Cloud Computing,

Recommendations of the National Institute of Standards and
Technology. Special Publication 800-145. September 2011.
Mobile Cloud Networking project web-site: http://www.mobile-cloudnetworking.eu
H. Pouyllau, G. Carofiglio, Inter-carrier SLA negotiation using QLearning, Telecommunication Systems Journal Special issue on
Socio-economic Issues of Next Generation Networks, 2011
A.F. Antonescu, P. Robinson, L.M. Contreras-Murillo, J. Aznar, S.
Soudan, F. Anhalt, et al., Towards Cross Stratum SLA Management
with the GEYSERS Architecture, 10th IEEE International Symposium
on Parallel and Distributed Processing with Applications, ISPA 2012
R. Cascella, L. Blasi, Y. Jegou, M. Coppola, C. Morin, Contrail:
Distributed Application Deployment under SLA in Federated
Heterogeneous Clouds, Springer, Lecture Notes in Computer Science,
2013
Zabbix web-site, http://www.zabbix.com/
Ceilometer web-site, https://wiki.openstack.org/wiki/Ceilometer

[8]

[9]

D. Kyriazis - Cloud Computing Service Level Agreements Exploitation of Research Results, European Commission Directorate
General Communications Networks, Content and Technology Unit E2 Software And Services, Cloud, June 2013
F. Blumel, T. Metsch, A. Papaspyrou, A Restful Approach to Service
Level Agreements for Cloud Environments, 9th IEEE International
Conference Dependable, Autonomic and Secure Computing (DASC),
December 2011

[10] SLA@SOI project web-site: http://sla-at-soi.eu/

[11] RESERVOIR project web-site: http://www.reservoir-fp7.eu/
[12] T.Metsch, A. Edmonds, V. Bayon, Using Cloud Standards for
Interoperability of Cloud Frameworks,
[13] R. Nyren, A. Edmonds, A. Papaspyrou, T. Metsch, Open Cloud
Computing Interface - Core, June 2011