Towards The Future Internet PDF

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/230634061
Towards the Future Internet - Emerging Trends from European Research
Book · April 2010
CITATIONS READS
46 196
8 authors, including:
Alex Galis Anastasius Gavras

University College London Eurescom
218 PUBLICATIONS 2,564 CITATIONS 66 PUBLICATIONS 680 CITATIONS
SEE PROFILE SEE PROFILE
Srdjan Krco Elena Simperl

DunavNET University of Southampton
90 PUBLICATIONS 1,610 CITATIONS 276 PUBLICATIONS 2,390 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
H2020 SliceNet View project
FI-STAR: Future Internet Social Technological Alignment Research View project
All content following this page was uploaded by Burkhard Stiller on 17 February 2016.
The user has requested enhancement of the downloaded file.

TOWARDS THE FUTURE INTERNET
The image on the cover is a partial map of the Internet based on the OPTE project started by
Barrett Lyon (www.blyon.com) who kindly let us use it for the front cover of this book. In this
graph the lines connect nodes representing IP addresses of some indicative Class C networks
color-coded according to their corresponding allocation. For more information see
http://www.opte.org/maps/.
Towards the Future Internet
Emerging Trends from European Research
Edited by
Georgios Tselentis
Alex Galis
Anastasius Gavras
Srdjan Krco
Volkmar Lotz
Elena Simperl
Burkhard Stiller
and
Theodore Zahariadis
Amsterdam • Berlin • Tokyo • Washington, DC

© 2010 The authors and IOS Press.
All rights reserved. No part of this book may be reproduced, stored in a retrieval system,
or transmitted, in any form or by any means, without prior written permission from the publisher.
ISBN 978-1-60750-538-9 (print)

ISBN 978-1-60750-539-6 (online)
Library of Congress Control Number: 2010924479
Publisher
IOS Press BV
Nieuwe Hemweg 6B
1013 BG Amsterdam
Netherlands
fax: +31 20 687 0019
e-mail: order@iospress.nl
Distributor in the USA and Canada

IOS Press, Inc.
4502 Rachael Manor Drive
Fairfax, VA 22032
USA
fax: +1 703 323 3668
e-mail: iosbooks@iospress.com
LEGAL NOTICE
The publisher is not responsible for the use which might be made of the following information.
PRINTED IN THE NETHERLANDS

Towards the Future Internet v
G. Tselentis et al. (Eds.)
IOS Press, 2010
© 2010 The authors and IOS Press. All rights reserved.
Preface
Nobody could foresee 20 years ago the important role Internet is playing today as one
of the cornerstones of our society, supporting social and economic interactions at
global scale. Internet’s critical role will be more evident in the future as more and more
activities based on it will permeate our daily life, driven by emerging novel Informa-
tion and Communication Technologies.
Therefore, trying to foresee how the internet will evolve in the next 20 years is a
great challenge. Even greater challenge is to guide research and innovation in this area
so that our society benefits from them. It is not surprising that research on the future of
the Internet has become a strategic priority all over the world, with important national
initiatives in USA, Japan, Korea and China as well as in many European Member
States. The European Commission through its Seventh Framework Research pro-
gramme dedicates about 20% of the budget for research related to the Future Internet,
corresponding to more than a billion euros funding.
The adoption pace of internet technologies has been accelerated. At the same time
as society we face three emerging challenges: the need to recover from a period of eco-
nomic crisis, the need to better manage energy resources and the need to mitigate the
effect of climate change; these three interrelated needs call for sustainable solutions.
The anticipated technological developments of the Future Internet and the trends to-
wards smart infrastructures (in energy, mobility, health, work, environment, etc.) pro-
vide Europe with an opportunity to progress towards a sustainable economy and soci-
ety. The foundations for these technological developments lay on the efforts of re-
searchers in Europe and worldwide.
Τhis book, the second of a series, tries to capture the emerging trends in Future
Internet research, as they are presented through European funded research activities.
Enjoy reading!
Directorate General for Information Society and Media
Mário Campolargo Luis Rodríguez-Roselló

Emerging Technologies & Infrastructures Converged Networks & Services
This page intentionally left blank
vii
Reviewers
Nancy Alonistioti, University of Piraeus
Thomas Bohnert, SAP AG
Mike Boniface, University of Southampton – IT Innovation Centre
Jan Camenisch, IBM Research, Zurich Research Laboratory
Constantinos Courcoubetis, Athens University of Economics and Business
Petros Daras, Informatics and Telematics Institute
Panagiotis Demestichas, University of Piraeus
Spyros Denazis, University of Patras
Schahram Dustdar, Vienna University of Technology
Dieter Fensel, University of Innsbruck
Alex Galis, UCL – Department of Electronic and Electrical Engineering
Anastacius Gavras, Eurescom GmbH
Alexander Gluhak, University of Surrey
Stephan Haller, SAP AG
Halid Hrasnica, Eurescom GmbH
Ebroul Izquierdo, Queen Mary University of London
Adam Kapovitz, Eurescom GmbH
David Kennedy, Eurescom GmbH
Srdjan Krco, Ericsson
Volkmar Lotz, SAP AG
Thomas Magedanz, Fraunhofer Fokus
Fabio Massaci, University of Trento
Daniele Miorandi, Create-Net
Barry Norton, University of Innsbruck
Max Ott, National ICT Australia
Aiko Pras, University of Twente
Christian Prehofer, Nokia Research
Mirko Presser, University of Surrey
Elena Simperl, STI Innsbruck
Sergios Soursos, Intracom
Burkhard Stiller, University of Zurich
Ivan Stojmenovic, University of Ottawa
Phuoc Tran-Ghia, University of Wuerzburg
Theodore Zahariadis, Synelixis Ltd
Anna Zhdanova, Telecommunications Research Center Vienna
ix
Introduction
1. CURRENT INTERNET
The current Internet designed 40 years ago is today the most important evolving
information, service and networking infrastructure providing the mechanisms for the
digital society at large to function as an integrated entity enabling sharing, contributing,
creating, using, collaborating and integrating information and knowledge by all.
The current Internet has been founded on a basic architectural premise, that is: a
simple network service can be used as a universal means to interconnect intelligent end
systems. This simple premise has allowed the Internet to reach an impressive scale in
terms of inter-connected devices. However, while the scale has not yet reached its
limits, the growth of functionality and the growth of size have both slowed down. It is
now a common belief that the current Internet would reach soon both its architectural
capability limits and its capacity limits.
Although the current Internet, as a ubiquitous and universal means for

communication and computation, has been extraordinarily successful, there are still
many unsolved problems and challenges several of which have basic aspects. Many of
these aspects could not have been foreseen 40 years ago when the first parts of the
Internet were built, but these need to be addressed now. The very success of the
Internet is now creating obstacles to future innovation of both the networking
technology that lies at the Internet’s core and the services that use it. In addition, the
ossification of the Internet makes the introduction and deployment of new network
technologies and services both difficult and costly.
We are faced with an Internet that is good at delivering packets, but shows a level
of inflexibility at network layer and a lack of built-in facilities to support any non-basic
functionality. The aspects, which we consider to be missing, are:
• Explicit multi-faceted unification, integration and orchestration of polymorphic

systems.
• Inherent network management functionality, specifically self-management
functionality.
• Facilities for the addition of new functionality, including capability for activating
a new service on-demand, network functionality, or protocol (i.e. addressing the
ossification bottleneck).
x
• Facilities for the large scale provisioning, management and deployment of

services; support for a high-level integration between services and networks.
• Facilities for orchestration of security, reliability, robustness, mobility, context,
service support, and management for both the communication resources and the
services’ resources.
• Mobility of networks, services, and devices.
• Facilities to support Quality of Service (QoS) and Service Level Agreements
(SLAs).
• Trust Management and Security; Privacy and data-protection mechanisms of
distributed data.
• An adequate addressing scheme, where identity and location are not embedded in
the same address.
• Facilities to interact with the physical world and seamlessly use the physical
context information to enhance and improve existing services and to create the
new ones.
• Socio-economic aspects including the need for appropriate incentives, viable
business models, legal and regulative issues, and the need for security and
privacy.
• Energy awareness.
Those challenges and capabilities envisaged for the Future Internet are addressed by
several research areas as depicted in Figure 1 and are presented in the following
sections.
Socio-Economics
Service-aware Networking
Management and
Trust and Identity

Future Content
Future Internet
Service Offers
Real World
Networks
Internet
Future Internet Research Experimentation

ͳȂ
xi
This book contains 25 selected papers presenting a variety of European research

results aimed at progressing the current Internet. It offers, above all, a vision of the
future rather than an account of deployed solutions. It presents representative research
results in seven interrelated area of research for Future Internet: 1.1 Socio-economics;
1.2 Trust and Identity; 1.3 Experimental Research; 1.4 Management and Service-aware
networking Architectures; 1.5. Service Offers; 1.6 Content Networks; 1.7 Real Word
Internet.
1.1 Future Internet Socio-economics Research Challenges
The technology of the Future Internet determines the underlying basis for many
services and applications of the near future. However, this approach and network will
be only operationally and commercially successful, if social and economic constraints
and challenges are taken into consideration. Thus, today this arena of networks,
especially Internet-based communications, differs highly compared to the traditional
Internet developments in the last century. Therefore, on one hand, the clear
understanding and modelling is important, especially of economic effects of technical
mechanisms and protocols as well as services offered in a Future Internet. On the other
hand, the users’ perspectives need to gain a considerably more recognized position,
especially in terms of their needs with respect to, e.g., security, identities, services,
content, and Quality-of-Experience (QoE). Note that these users mentioned do not only
encompass traditional end-users, but also other roles, such as network providers,
telecommunication service providers, content providers, or application and overlay
providers in their specific settings and service relationships.
In consequence, the socio-economic aspects of the Future Internet has reached until
now a little more attention and the positive and constructive influence on service
developments, network mechanism design, and operational preferences has started to
grow. To this end, this book includes a number of contributions in the area of Future
Internet Socio-economics.
Paper #1 “ETMS: A System for Economic Management of Overlay Traffic”

considers the concept of Economic Traffic Management (ETM) for optimizing overlay
networks taking into account both underlay and overlay networks’ performance
requirements. It presents an overview of several ETM mechanisms as well as the
architecture of the ETM System, which can be used to implement those mechanisms.
Further, it presents selected results from the test-bed trial of the ETMS concluding with
a corresponding discussion.
Paper #2 “Modelling the Economics of Loc/ID Split for the Future Internet”
addresses a modelling approach of the economics of locator/identifier split for the
Future Internet. In a careful analysis and a detailed modelling followed by evaluations
the problem of the locator and ID split for a possible Future Internet is investigated.
The motivation is to reduce the operation expenditure by reducing the amount of
entries Network Domains have to maintain to provide end-to-end connectivity.
xii
Paper #3 “Business Aspects of Multipath TCP Adoption” presents an overview of

how multipath TCP could be used in practice at the business level and not at the
protocol level, by sketching a couple of scenarios that differ in how the multiple paths
are obtained, e.g., from one or from more ISPs. Possible business models are presented
and for each a brief list of Strengths/Weaknesses/Opportunities/Threats (SWOT) is
given.
Paper #4 “The Economics of Utility Services in the Future Internet” investigates the
economics of utility services in the Future Internet, while focusing on a potential
universal service offering within the future broadband communications. A high level
analysis of the viability of utility services in ICT considers comparisons with different
possible economic models under efficiency, value chains, and networks perspectives.
Paper #18 “The Human Side of the Future Internet” discusses the user’s side of the
Future Internet to better understand him/her by capturing and managing complex
structured user profiles. Based on user profile taxonomy and a simple architecture,
identities, user profiles, and enabling technologies to support 3rd party applications are
integrated, leading to a higher-level conclusion that an improved QoE may be
achieved.
1.2 Future Internet Trust and Identity Research Challenges
There is a broad consensus that the many new opportunities of the Future Internet
will only kick-off if trusted and secure spaces for executing them can be provided. The
accelerated scale of a Future Internet embracing businesses, citizens and objects, the
fading distinction between consumers and providers, and the pervasion of everybody’s
daily life with novel technology and advanced usage scenarios ask for rethinking the
protection needs of the different stakeholders and for a systematic assessment of the
risks that may exist in the Future Internet. New scenarios introduce new risks and
potential attacks that need to be addressed from the beginning of the design of a new
Internet: malicious services, limited transparency and a lifelong digital footprint of
individuals are only a few examples of security and trust challenges that need to be
met.
The security, trust and identity related papers presented in this book address three
important areas where these new challenges occur: the scalability of attack prevention
to new technologies and highly distributed environments, the prediction of new and
attacks and their targets; and the need for new identity management schemes.
Paper #13 “Scalable Cloud Defenses for Detection, Analysis and Mitigation of
DDoS Attacks” investigates into distributed denial of service attacks in cloud
environments and shows that scalable cloud mechanisms can be effectively used to
protect from those attacks.
xiii
Paper #14 “Vulnerabilities and Protection of Satellite Networks Interconnected

with Terrestrial Segments” analyses the use of intrusion detection techniques to
discover and counter specific attacks rooted in heterogeneous network technology,
satellite connections in particular. Since the Future Internet is likely being composed of
a variety of technologies, this is a good example of how to cope with related security
challenges.
If we accept the fact – and there is no indication of the contrary – that Future
Internet security is characterized by emerging threats, the capability to predict attacks
in order to focus attention on critical structures and application becomes essential.
Paper #5 “Towards Security Climate Forecasts” shows an approach for prediction of
critical components based on empirical analysis of past vulnerabilities and machine
learning techniques with surprisingly good results.
Ultimately, a trusted Future Internet is made up by people interacting with each

other, with services or things. Identity is at the heart of building trust. Paper #9
“Identity Engineered Architecture” proposes an identity engineered architecture for the
Future Internet, emphasizing on usability and privacy concerns.
1.3 Future Internet Research and Experimentation Challenges
The Internet itself has been the largest-scale laboratory for emerging applications
and services. However, it is evident that it cannot be considered as a testbed for the
basic protocols, architectures and services. The shape of a Future Internet Research and
Experimentation (FIRE) facility is emerging that will provide an open playground for
the kind of research that cannot be conducted on a critical infrastructure like today’s
Internet. This facility is being gradually built, based on a federation of existing relevant
testbeds, and will grow according to the research needs specified by the related
“customer” research projects.
In paper #6 “Conceptual Design and Use Cases for a FIRE Resource Federation
Framework” the authors propose a federation model that defines high-level conceptual
entities for federating resources across administrative domains. The model can guide
future testbed developments and harmonize the currently scattered efforts across
several FIRE projects in order to establish an agreed resource federation framework.
This framework shall be the basis for Future Internet research and experimentation in
Europe and provide experimental facility services to academia and industry.
In paper #7 “Virtual Infrastructures in Future Internet” describes how virtualisation

and its challenges in computer systems and network elements are addressed by the
work of the national research and education networks in Europe. The work presents the
physical be polymorphic substrate on which various parallel infrastructures can be
provisioned on demand.
xiv
1.4 Future Internet Management and Service-aware Networking Architectures

(MANA) Research Challenges
MANA research covers the management, the networking, the service-aware

networking including service platform technologies and systems, which form the
infrastructure for Future Internets.
The current trend for networks is that they are becoming service-aware. Service
awareness itself has many aspects, including the delivery of content and service logic,
fulfilment of business and other service characteristics such as Quality of Service
(QoS) and Service Level Agreements (SLA) and the optimisation of the network
resources during the service delivery. Conversely, services themselves are becoming
network-aware. Networking-awareness means that services are executed and managed
within network execution environments and that both services and network resources
can be managed uniformly in an integrated way. The design of both Networks and
Services is moving forward to include higher levels of automation, autonomicity,
including self-management.
The Future Internets would be built as service-aware and self-aware federated

networks, which provide built-in and orchestrated aspects such as: context, reliability,
robustness, mobility, security, service support, and self-management of the
communication resources and the services. Such aspects suggest a transition from a
service-agnostic Internet to a new service-aware and self-aware Internet, in which self-
awareness is serving the purpose of communication and computation by means of
enhanced in-network and in-service decisions. In order to achieve the objective of
being service-aware and network-aware and to overcome the ossification of the current
Internet, papers selected for this book envisage various novel solutions for the Future
Internet including:
Paper #8 “Publish/Subscribe for Internet: PSIRP Perspective” describes the

architecture and implementation of the PSIRP project as a novel approach to
publish/subscribe networking. The clean-slate design of this approach allows a more
efficient publishing / subscription solution than current IP networks, which are based
on a different paradigm. While such approach is very radical, the preliminary results
are encouraging as this architecture is scalable, efficient and secure. There exist a
working software prototype for the PSIRP architecture.
Paper #9 “Identity Engineered Architecture” describes the identity-engineered

architecture of the SWIFT project, which includes how virtual and digital identities
relate to the real world. It presented an approach to user privacy and how virtual
identities and the digital identities designating them may be used in the network while
preserving privacy. The session concept addresses how to connect applications with the
underlying transport and infrastructure. Finally, the Intentity concept puts the user’s
intention at the centre of Future Internet.
xv
Paper #10 “An Experimental Path Towards Self-Management for Future Internet
Environments” describes the cognitive network manager (CNM) developed by the Self-
NET Project. CNM attempts to provide the software architecture for a realistic and
implementable self-managed network system. The inherent distribution of cognitive
agents as well as components modularity, and the adoption of an open standard (i.e.
OSGi) assure the applicability of CNM in the Future Internet.
Paper #11 “Manageability of Future Internet Virtual Networks from a Practical

Viewpoint” describes the manageability of virtual networks as developed by the
AUTOI project. It presents the full implementation of self-configuration and self-
performance management scenarios for virtual networks. All software components
described in this paper are released as Open Source components for experimental
purposes.
Paper #12 “Monitoring Service Clouds in the Future Internet” describes a new
monitoring framework called Lattice applicable in service clouds, as developed in the
RESERVOIR project. The Lattice framework facilitate building a monitoring
infrastructure that collects, processes, and disseminates network, service and system
information from/to the entities at real-time, acting as an enabler for service
management functionality for service computing clouds. Service Clouds are a key
emerging feature of the Future Internet, which provide a platform to execute virtualized
services.
Paper #13 “Scalable Cloud Defenses for Detection, Analysis and Mitigation of
DDoS Attacks” describes how a federated cloud architecture could be extended to deal
with the DDoS threat. The result is a scalable cloud defence architecture for dealing
with DDoS. The architecture builds on the ability of federated Infrastructure as a
Service (IaaS) to scale and migrate virtual execution environments within the
federation.
1.5 Future Internet Service Offer Research Challenges
A new-generation network such as the Future Internet can obviously be seen from
multiple perspectives. Among them, the service-centric one is universally
acknowledged to play a paramount role, based on the assumption that every self-
contained piece of functionality located above a certain level of abstraction of this
network can be viewed as a service, and that such services can be feasibly deployed
and flexibly integrated into various environments and applications. This service-centric
perspective leads to the concept of the “Internet of Services”. The Internet of Services
will offer services for everyone and everything, across business sectors and areas of
life. This will be achieved through so-called “service delivery platforms” including
service-oriented architectures, Web 2.0-style interaction, semantically enabled
processing, business models and deployment models, which bring together service
prosumers around the globe. The realization of such service infrastructures is examined
by several papers in this book.
xvi
Paper #15 “Creating a Reference Architecture for Service-Based Systems” presents

the pattern-based methodology adopted in the NEXOF project to design a reference
architecture for service-oriented systems (SBS) and applications. The system of
patterns that has been presented allows addressing the different characteristics and
requirements of the different types of SBSs that should be considered in Future
Internet.
Paper #16 “SOA4All: Towards a Global Service Delivery Platform” introduces the
NEXOF reference architecture for service-based systems as well as guidelines for
implementing it in specific application contexts, and elaborates on the approach
followed by the research project of the same name to create this architecture. The
authors argue in favour of the usage of patterns in order to better accommodate the
requirements of particular scenarios, as opposed to the design of a single while not
restricting the applicability of the reference architecture.
Paper #17 “Real Time Energy Management in Smart Cities by Future Internet”
covers an interesting application: smart grids permitting the co-ordination of a very
large number of devices and users in which the future occurrences of the energy
consumption dynamics are promptly exchanged between competing actors.
Paper #18 “The Human Side of the Future Internet” presents a framework for
managing and accessing users’ profile data and preferences, in an environment of
Future Internet services. The authors identify the requirements that will arise with
respect to the provision of personalized services combined with the concepts of
“always connected”, the “Internet of Things” and other characteristics that the Future
Internet will introduce. Moreover, they categorize the information that should be
included in a user’s profile and provide a high-level architecture of the system that
manages such information and how this should interact with the applications, the
content providers and the end users
Paper #19 “Self-Improving Personal Smart Spaces for Pervasive Service Provision”
presents the PERSIST project approach to personalization and self-organization of
Smart Spaces and pervasive computing in terms of conference scenarios.
1.6 Future Content Networks Research Challenges
It is a common belief that the Internet is evolving towards providing more

immersive experiences. Advances in video capturing and multimedia authoring tools
will lead to massive creation of new multimedia content and innovative internet
applications, including 3D videos, edutainment and tele-presence applications, multi-
player network gaming, virtual worlds. As such the Internet will play an increasing role
in the ability of humans to communicate, but at the same time opens new demanding
problems. Future Content Networks aim to capture and analyse the research challenges
that govern both the new media creation towards richer 3D/stereoscopic video and
xvii
audio-wave field synthesis, and the network issues covering network architecture and
protocols towards real-time content-aware delivery and streaming.
Paper #19 “Self-Improving Personal Smart Spaces for Pervasive Service

Provision,” describes the concept of Personal Smart Spaces (PSS). A PSS aim to
couple the facilities offered by the next generation mobile communications and the
Future Internet with the features provided by static smart spaces to support a more
ubiquitous and personalised smart space, able to Starting from the new media creation
dimension, the need for standardized and efficient content formats is more import than
ever before.
Paper #20 “Scalable Video Coding: Source for Future Media Internet,” describes a
flexible wavelet-based scalable video coding framework (W-SVC) to support Future
Media Internet, specifically content delivery to different display terminals through
heterogeneous networks. Scalable video bit-stream can easily be adapted to the
required spatiotemporal resolution and quality, according to the transmission and the
user context requirements.
Adaptation should be supported by a network independent middleware platform

with standardized independent application programming interfaces (APIs) for well-
known media-related functions (e.g., coding, packaging, storing, delivering).
Paper #21 “Accelerating Media Business Developments with the MPEG Extensible
Middleware” describes the vision behind the ISO/IEC MPEG Extensible Middleware
(MXM), its architecture, and a high level overview of the API.
Two innovative approaches to offer media scalable content delivery, increasing the
robustness and enriching the QoS over heterogeneous physical architecture and P2P
logical overlay network topologies are introduced in Paper #23 “Efficient Streaming in
Future Internet”. The paper presents two new architectures including special Media
Aware Network Element (MANE), which perform content adaptation and in the
network content enrichment.
In most cases, current Internet architecture treats content and services simply as bits
of data transported between end-systems. While this relatively simple model of
operation had clear benefits when users interacted with well-known servers, the recent
evolution of the way the Internet is used makes it necessary to create a new model of
interaction between entities representing content. Paper #22 “Towards a Content-
Centric Internet” studies the limitations of current Internet and proposes a new model,
where the smallest addressable unit is a content object, regardless of its location.
xviii
1.7 Real World Internet Research Challenges
Integration of the physical world into the Future Internet is another important aspect
addressed in the book. Sensors, actuators, Radio-frequency identification (RFID)
enabled items, and generally heterogeneous network enabled machines and everyday
items will be integrated into the fabric of the Future Internet, merging the digital and
the physical worlds and enabling a range of new and enhanced Internet services and
applications. Current sensor and actuator network deployments are still relatively
sparse and built as independent, vertically closed solutions. To achieve real integration
of the physical and the digital world it is necessary to interconnect these individual
installations, to enable their seamless interaction with other Internet users and to
provide unified access to the information and services they provide.
Paper #24 “The SENSEI Real World Internet Architecture” presents a design that
enables efficient integration of heterogeneous and distributed sensor and actuator
networks into a homogeneous framework for real world information and interactions
and horizontal reuse of the deployed sensor and actuator infrastructure across a variety
of application domains is presented.
Paper #25 “SENSEI Traffic Impact on Mobile Wireless Networks” analyses a

number of Internet of Things scenarios with the goal to define an IoT traffic model.
Using the derived traffic model, analysis of the impact of the IoT traffic on the
dimensioning of the mobile radio access networks have been done and the results
presented.
2. FUTURE INTERNET ASSEMBLY (FIA)
Future Internet research and development threads have recently been gaining
momentum all over the world and as such the international race to create a new
generation Internet is in full swing. The Future Internet Assembly (FIA) was kicked off
at the Bled conference (e.g. www.future-internet.eu/events/future-internet-conference-
bled-2008.html) organised by the European Commission as the means to enable
fundamental and systemic innovation in Europe in networking and services for the
realization of the Future Internet within the timescale of 2020. FIA includes most of the
EU FP7 research projects associated with Future Internet. The Assembly is structured
to permit open interaction and cross-fertilization across technical domains and also has
the following strategic goals:
• A joint strategic research agenda for the Future Internet encompassing common
actions, requirements and architectures
• Multi-faceted unification, integration and orchestration of polymorphic systems
and results enabling highest impact and moving research results into practice
xix
• Fostering common research deliverables and results creating value for the EU
research projects concerned
• Developing a consolidated calendar of events aiming at avoiding fragmentation of
research efforts in Europe
ACKNOWLEDGMENT
This book reports on advances in Internet and it is a joint effort of the people who
are active in European Union funded research projects. The book editorial group wish
to thank to the papers’ authors, who worked hard and timely to produced and edit 25
selected papers from a group of 59 papers submitted to the call for papers. We also
thank to the book reviewers who helped with the selection of and with the quality
improvement of the papers by providing valuable recommendations.
Finally, we would like to thank Mario Campolargo and Luis Rodriguez-Rosello for
their drive and wisdom in instituting FIA as a key player in the research marketplace
for Future Internet, to Georgios Tselentis, Paulo de Sousa, Remy Bayou, Isidro Laso,
Yves Paindaveine, Anne-Marie Sassen, Manuel Mateo, Max Lemke, Peter Fatelnig,
Bart Van-Caenegem, Miguel Montarelo-Navajo, Inge Ceuppens, Bernard Barani,
Franco Accordino for their support and encouragement for the work on the book. They
actively supported the progress of the book and therefore favourably and constructively
affected its content. Special thanks also go to Sandra Giovanelli who patiently assured
the interface with authors during the period this book was prepared.
3rd March 2010

Future Internet Assembly caretakers and book editorial group
Alex Galis – University College London, United Kingdom

Anastasius Gavras – Eurescom, Germany
Srdjan Krco – Ericsson, Ireland
Volkmar Lotz – SAP Research, France
Elena Simperl – STI International, Austria
Burkhard Stiller – University of Zurich, Switzerland
Theodore Zahariadis – Synelixis/TEI of Chalkida, Greece
xxi
Contents
Preface v
Reviewers vii
Introduction ix
Alex Galis, Anastasius Gavras, Srdjan Krco, Volkmar Lotz, Elena Simperl,
Burkhard Stiller and Theodore Zahariadis
ETMS: A System for Economic Management of Overlay Traffic 1

Sergios Soursos, María Ángeles Callejo Rodriguez, Konstantin Pussep,
Peter Racz, Spiros Spirou, George D. Stamoulis and Burkhard Stiller
Modeling the Economics of Loc/ID Split for the Future Internet 11
Luigi Iannone and Tapio Levä
Business Aspects of Multipath TCP Adoption 21
Tapio Levä, Henna Warma, Alan Ford, Alexandros Kostopoulos,
Bernd Heinrich, Ralf Widera and Philip Eardley
The Economics of Utility Services in the Future Internet 31
Man-Sze Li
Towards Security Climate Forecasts 41
Stephan Neuhaus and Fabio Massacci
Conceptual Design and Use Cases for a FIRE Resource Federation Framework 51
Sebastian Wahle, Thomas Magedanz and Anastasius Gavras
Virtual Infrastructures in Future Internet 63
Mauro Campanella, Vasilis Maglaris and Martin Potts
Publish/Subscribe for Internet: PSIRP Perspective 75
Dmitrij Lagutin, Kari Visala and Sasu Tarkoma
IDentity Engineered Architecture (IDEA) 85
Joao Girao and Amardeo Sarma
An Experimental Path Towards Self-Management for Future Internet
Environments 95
Apostolos Kousaridas, Gérard Nguengang, Julien Boite, Vania Conan,
Vangelis Gazis, Tilemachos Raptis and Nancy Alonistioti
Manageability of Future Internet Virtual Networks from a Practical Viewpoint 105
J. Rubio-Loyola, A. Astorga, J. Serrat, L. Lefevre, A. Cheniour,
D. Muldowney, S. Davy, A. Galis, L. Mamatas, S. Clayman, D. Macedo,
Z. Movahedi, G. Pujolle, A. Fischer and H. de Meer
xxii
Monitoring Service Clouds in the Future Internet 115

Stuart Clayman, Alex Galis, Clovis Chapman, Giovanni Toffetti,
Luis Rodero-Merino, Luis M. Vaquero, Kenneth Nagin and
Benny Rochwerger
Scalable Cloud Defenses for Detection, Analysis and Mitigation of DdoS
Attacks 127
Joseph Latanicki, Philippe Massonet, Syed Naqvi,
Benny Rochwerger and Massimo Villari
Vulnerabilities and Protection of Satellite Networks Interconnected with
Terrestrial Segments 139
F. Belli, M. Luglio and C. Roseti
Creating a Reference Architecture for Service-Based Systems – A Pattern-Based
Approach 149
Vanessa Stricker, Kim Lauenroth, Piero Corte, Frédéric Gittler,
Stefano de Panfilis and Klaus Pohl
SOA4All: Towards a Global Service Delivery Platform 161
Reto Krummenacher, John Domingue, Carlos Pedrinaci and
Elena Simperl
Real Time Energy Management in Smart Cities by Future Internet 173
Mikhail Simonov, Marco Mussetta, Andrea Pirisi, Francesco Grimaccia,
Davide Caputo and Riccardo E. Zich
The Human Side of the Future Internet 183
Jose Simoes, Peter Weik and Thomas Magedanz
Self-Improving Personal Smart Spaces for Pervasive Service Provision 193
Ioanna G. Roussaki, Nikos K. Kalatzis, Kevin J. Doolin, Nick K. Taylor,
Guido P. Spadotto, Nicolas D. Liampotis and M. Howard Williams
Scalable Video Coding: Source for Future Media Internet 205
Naeem Ramzan, Toni Zgaljic and Ebroul Izquierdo
Accelerating Media Business Developments with the MPEG Extensible
Middleware 217
Christian Timmerer, Filippo Chiariglione, Marius Preda and
Victor Rodriguez Doncel
Towards a Content-Centric Internet 227
Theodore Zahariadis, Petros Daras, Jan Bouwen, Norbert Niebert,
David Griffin, Federico Alvarez and Gonzalo Camarillo
Efficient Streaming in Future Internet 237
Theodore Zahariadis, Christos Katsigiannis, Ahola Jari,
Roberta Fracchia, Janne Vehkapera, Federico Alvarez,
Thierry Filoche and Harilaos Koumaras
xxiii
The SENSEI Real World Internet Architecture 247

Vlasios Tsiatsis, Alexander Gluhak, Tim Bauge, Frederic Montagut,
Jesus Bernat, Martin Bauer, Claudia Villalonga, Payam Barnaghi and
Srdjan Krco
SENSEI Traffic Impact on Mobile Wireless Networks 257
Igor Tomić, Srdjan Krčo, Divna Vučković, Alexander Gluhak and
Pirabakaran Navaratnam
Subject Index 267

Author Index 269
Towards the Future Internet 1
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-1
ETMS: A System for

Economic Management of Overlay Traffic
Sergios Soursosa,b,1, María Ángeles Callejo Rodriguezc,
Konstantin Pussepd, Peter Racze, Spiros Spiroub,
George D. Stamoulisa, Burkhard Stillere
a
Athens University of Economics and Business, {sns, gstamoul}@aueb.gr
b
Intracom Telecom R&D, {souse, spis}@intracom.com
c
Telefónica Investigacion y Desarrollo, macr@tid.es
d
Technische Universität Darmstadt, pussep@kom.tu-darmstadt.de
e
University of Zürich, {racz, stiller}@ifi.uzh.ch
Abstract. The concept of Economic Traffic Management (ETM) encompasses

various techniques for optimizing overlay networks considering both, underlay
and overlay networks’ performance requirements as well as the resulting economic
implications for ISPs. This work presents several mechanisms through an overall
ETM System (ETMS), identifying the possibility for synergies between
mechanisms, both in the sense of complementarity of decision grounds and in the
sense of functionality and components employed thereby. The paper describes the
core ETMS architecture and how various mechanisms are instantiated. It continues
with the discussion of the flexibility and modularity of this architecture, allowing
for the accommodation of synergies. Finally, it presents selected results from the
test-bed trials of the ETMS and a dedicated discussion on incentives behind these
ETM mechanisms.
Keywords. Overlays, Peer-to-Peer (P2P), Economic Traffic Management (ETM),

Incentives, Architecture, Modular Design
1. Introduction
Recent research focusing on the optimization of overlay networks has identified the
tussle between Internet Service Providers (ISPs) and peer-to-peer (P2P) applications.
This is due to different views of the former with respect to the overlay-optimized
routing of traffic generated by P2P applications, which might result in increased
interconnection costs for ISPs. Localization of overlay traffic appears as one of the
most promising solutions to tackle this emerging problem. Despite the criticism on
locality promotion [1], [2], there are significant efforts from the research community,
industry, and standardization bodies to devise mechanisms for traffic localization of
overlay-based applications [3], [4], [5], and [6]. One of the most popular of such
application is BitTorrent. Those mechanisms, however, are partially similar, both in
concept and in implementation, since in their core they provide the overlay with the
information about network topology, even if they use different information sources and
1
Corresponding Author.
2 S. Soursos et al. / ETMS: A System for Economic Management of Overlay Traffic
granularity. Throughout this paper, we identify those approaches and spot the
differences with the presented proposed solutions.
The objective of the SmoothIT project [7] is to define the framework for applying
Economic Traffic Management (ETM) techniques, categorize them, implement the
most promising ones, and evaluate their performance with respect to key benefits for
all stakeholders. That is to achieve the TripleWin situation [8], where ISPs, overlay
providers, and end users all benefit in terms of performance optimization and monetary
gains. Thus, this work provides an overview of main ETM mechanisms (Section 2),
presents the architecture of the ETM System (ETMS), which can be used to implement
any of the aforementioned mechanisms (Section 3), describes how each of these ETM
mechanisms is mapped to the generic architecture (Section 4), presents selected
preliminary results from the deployment of the system in a controlled test-bed (Section
5), and finally, discusses economic implications of those mechanisms with respect to
offered incentives for all stakeholders (Section 6), before concluding in Section 7.
2. Economic Traffic Management Mechanisms
Within the SmoothIT project, a multitude of approaches for enabling overlay traffic
management techniques that lead to a TripleWin situation, have been identified. The
most important of these can be classified into the following three main categories:
Locality Promotion involves peers of a domain having their overlay neighbors
rated according to their underlay proximity. A peer sends a list of peers to the SIS
(SmoothIT Information Service). The latter entity interfaces with the underlay network,
obtains locality information, and rates each peer of the list based on certain location
attributes, e.g., on the number of hops in the Autonomous System (AS) path. The rated
and accordingly sorted list is returned to the requesting peer where, in turn, overlay
operations (e.g., unchoking and neighbor selection in BitTorrent) are modified in order
to favor peers that belong to the same domain with the requesting one. Thus, the
interconnection costs for the ISP are reduced, while the performance for the peer is also
improved in a variety of cases. Dynamic extensions of this mechanism can involve the
promotion of locality only when necessary according to underlay conditions. The level
of interference of SIS with overlay operations is reduced, also avoiding any negative
impact on the quality of services offered.
Insertion of locality-promoting peers/resources: An indirect way of promoting
locality for the ISP is to introduce to its domain special resources so that content is
downloaded faster into the domain and distributed among the local peers. Two such
ETM mechanisms developed are the ISP-owned Peer (IoP) and the Highly Active Peer
(HAP). With the IoP, the ISP deploys and controls a peer with augmented bandwidth
and storage capabilities that allow downloading content and making it available quickly
to the domain’s peers. To do so, the IoP initially participates in the swarm as a normal
peer, but quickly acquires the entire content and starts serving the local peers. By the
HAP this idea is implemented in a decentralized manner, with the functionality being
passed to normal peers. In particular, based on overlay and underlay information,
certain highly active peers in a domain are promoted by the ISP to enhanced peers and
their Internet connection speed is increased dynamically by the ISP, so as to download
and offer overlay content more efficiently.
Inter-domain collaboration addresses cases, where information available to a
domain is not sufficient to reach some of the aforementioned optimization objectives.
S. Soursos et al. / ETMS: A System for Economic Management of Overlay Traffic 3
This can be due to asymmetry of routing information between source and destination
domains or it is due to the lack of connection details of communicating peers. In such
cases, inter-domain collaboration can lead to fine-tuning and improvement of local
decisions in all participating domains.
3. ETMS Architecture
Figure 1 depicts the ETMS architecture developed. Underlay and overlay networks and
their components, which interact with the ETMS, are also included for completeness.
As observed, the SIS encompasses the main functionality offered by the ETMS.
Figure 1. The ETMS Architecture
Components of the SIS, the entire ETMS architecture, and their functionality cover:
• The Controller determines the core of the system. Its main responsibility is to
coordinate the ETM mechanism. Therefore, it receives requests from the
overlay application (simple peer, IoP, or HAP), performs calculations based
on the ETM mechanism deployed and according to several underlay metrics,
such as metering and policy information, and returns to the overlay application
the information required. Usually, the information returned is in the form of
ranked lists, rating either peers as possible “good” neighbors, or swarms as
“popular” ones.
• The Metering component collects network information from the underlying
Network Management System (NMS) in order to support ETM mechanisms
implemented by the SIS. This information can include, e.g., BGP (Border
Gateway Protocol) routing tables in order to support locality enforcement
algorithms, network performance parameters and network usage by users that
is necessary to support accounting and charging.
• The QoS Manager checks the availability of network resources, guarantees

resources requested by the end user, and enforces QoS (Quality-of-Service)
policies in the network. For example, it interfaces to the network by using the
NGN (Next Generation Network) transport control functionalities, if available.
• The InterSIS component facilitates the exchange of information between two
or more SISs to fine-tune local decisions.
• The SIS DB (Data Base) is a repository storing all information that may be
useful for all modules, such as configuration parameters or business logic.
• The Security component provides security services to the SIS, including
authentication, access control, and secure communication.
• The Admin component is used by the administrator of the SIS to access and
configure the server as well as the deployed ETM mechanisms.
• The Monitor component is a supportive component used to gather certain
overlay and underlay statistics for evaluation purposes.
• The IoP and the HAP, as already explained, denote two special cases of peers.
In case of the IoP mechanism, this special peer belongs to the ETMS and is
fully controlled by the ISP (through the SIS). In case of the HAP, the peer is a
regular peer that is granted with special network capabilities by the ISP, for a
given time, hence it belongs both to the overlay and to the ETMS.
The ETMS architecture designed has been implemented as a prototype. It follows a

modular design and allows interfacing with external elements (e.g. NMS) without
affecting the mechanism logic.
The overlay application is based on NextShare, a P2P streaming application
developed by the P2P-Next project [9]. The application is written in Python and it has
been extended to communicate with the SIS. The modified application also includes the
biased neighbor selection and biased unchoking mechanisms to support locality
promotion. Additionally, the application supports live monitoring by periodically
sending XML (eXtended Markup Language) reports to the Monitor component.
Reports include overlay statistics (e.g., total download and upload, download and
upload rate, or download progress) as well as video playback statistics (e.g., like play
time or stall time) and they are stored in the SIS DB.
All components of the SIS have been implemented in Java and are deployed on a
JBoss application server. The Controller provides a Web Service interface over SOAP
(Simple Object Access Protocol) to communicate with peers in the overlay application.
The current version of the Controller supports the BGP-based locality promotion
(BGP-Loc) and the IoP mechanisms, while the HAP mechanism will be implemented
as a next step. The Metering component supports reading the BGP routing table over
SNMP (Simple Network Management Protocol) from a router and provides
information based on the routing table to the Controller. The SIS DB is implemented
using the Java Hibernate persistence service, making it independent of the underlying
database server. The prototype uses a MySQL database server, but it supports any
relational database systems. The Admin component provides a Web interface to
configure and manage the system. It is implemented using the JavaServer Pages (JSP)
technology. The Security component provides the authentication and authorization to
log in to the admin interface.
The final prototype will include all three mechanisms and will be deployed in a
real environment, i.e. in the premises of an existing ISP, in order to evaluate the
performance of these mechanisms and complement existing simulative and theoretical

evaluations.
4. Mapping of the Architecture to ETMs
The ETMS provides a service to the overlay network to offer any ETM mechanism,
which is supported by components involved and of the respective functionality. In
order to support a specific ETM mechanism architectural components are extended
with the desired functionality that implements the specific ETM algorithm. Depending
on the algorithm, a subset of components presented in the previous section is extended.
In any case the Controller must be extended with the specific ETM logic and the
Admin interface is adjusted to enable parameter configuration. Furthermore, SIS DB is
extended to store the required data per mechanism. Changes in further components
depend on the mechanism, but typically only few components must be extended.
4.1. Support for Locality Promotion
The mechanism for promoting locality (BGP-Loc) requires two features to be

supported by the architecture: (i) the ability to obtain locality information from the
underlay and (ii) the provision of the pre-processed locality information to the overlay
application. The first feature is supported by the Metering component, which acquires
underlay information, like routing information from ISP’s routers. This information is
used by the Controller to characterize peers according to an underlay metric, e.g., their
AS, POP (Point-of-Presence), or any other relevant topology information like peering
agreements among ISPs. One such metric is the BGP routing preference that combines
several BGP attributes to provide the final rating value [10].
For the second feature, the Controller implements a generic rating algorithm that
can provide ratings for a peer based on various metrics. This rating value is used by the
SIS Client (residing in the peer) to bias the neighbor selection and unchoking
algorithms [11] in a manner that promotes connecting to and exchanging data with
peers of the same or of a nearby domain. For this mechanism, the extension of the
client is crucial to take advantage of the locality promotion.
The extension of dynamic locality enforcement requires the Metering component
to gather information related to the load level of interconnection links, as well as to the
charging level of flowing traffic (e.g., 95th percentile). By doing so, the Controller is
able to know, when it is required to promote locality to both, while keeping charging
levels below an ISP-defined threshold and limiting the intervention of the ISP to
overlay-related procedures. This decision on whether to promote or not locality can be
seen as another parameter in the Controller’s generic rating function.
4.2 Support for ISP-owned Peer
The IoP [12] involves deploying special peers (actual IoPs) in the ISP’s domain. These
peers act as locality-aware ultra-peers and bias the overlay traffic for higher locality
degree. The IoP support requires the EMTS architecture to acquire both underlay and
overlay information to allow the IoP to make right decisions regarding the swarm,
neighbor, and unchoke management. Therefore, the IoP and the Controller need to
communicate, in order for the IoP to identify popular swarms to join, and decide on
how much bandwidth to allocate to a swarm. The Controller provides estimates on the
popularity of various swarms by collecting overlay statistics from local peers.
Additionally, the Controller can advertise the IoP(s) by including it to the list of peers
sent for rating by local peers, thus combining the IoP and locality promotion
mechanisms.
4.3 Support for Highly Active Peers
In case of the HAP mechanism, the Controller decides, based on underlay and overlay
metrics, which peers to promote to HAPs. By doing so, special policy profiles will be
activated for those peers by the QoS Manager. These profiles provide additional upload
and/or download capacity, for which purpose the QoS Manager communicates with the
NMS or Traffic Shaping devices depending on the ISP’s infrastructure and access type
of the user.
The behavior of HAPs is monitored to decide whether their extra resources should
be maintained and to what extent. Peers promoted to HAPs can be rewarded, e.g., in
terms of monetary discounts or for contributing to enhance the overlay’s performance.
But the main incentive to be a HAP is a better overlay performance (in terms of
valuable upload capacity) resulting in better contribution rankings, e.g., for BitTorrent
networks, and higher download rates experienced by the users. In order to avoid the
misuse of the HAP status by peers, per-user statistics are collected by the Metering
equipment and provided to the Controller to adjust HAP promotion decisions.
Alternatively, the overlay application can provide its own statistics to the Controller
that allows offloading NMS equipment. Unlike the BGP-Loc and the IoP, this
mechanism does not require any changes to or support of the overlay protocol.
4.4 Support for InterSIS Collaboration
For the refinement of local decisions, SIS instances must implement an InterSIS
protocol and decide on which information to exchange and how to use it. This protocol
connects the Controllers of different SIS instances (probably run by different ISPs or
other entities). Again, this information is translated to another parameter to be
considered by the generic peer rating algorithm that affects the overlay behavior of
local peers.
Table 1: Overview of Architectural Adjustments
Supported ETM mechanism Involved Components
BGP-Loc Controller, Peer, Metering, (SIS DB, Admin)
IoP Controller, IoP, Peer, (SIS DB, Admin)
HAP Controller, QoS Manager, Peer or Metering, (SIS DB, Admin)
InterSIS Controller, (SIS DB, Admin)
5. Test-bed Trials and Preliminary Trial/Prototype Results
The SmoothIT test-bed has been designed to validate the ETMS implementation in a
medium scale scenario. The first mechanism validated is BGP-Loc. For this purpose,
the ModelNet emulator [13] has been used which is a large-scale network emulator that
allows users to evaluate distributed networked systems in realistic Internet-like
environments. ModelNet enables the testing of unmodified prototypes running over

unmodified operating systems across various networking scenarios.
In order to evaluate the impact of the BGP-Loc mechanism implementation,
scenarios with different ISPs having different interconnection models, different access
types, and distribution of peers have been generated. The topology that has been
emulated in ModelNet is shown in Figure 2.
Figure 2. Internal Trial Topology
The main advantage of this environment is that it allows for the configuration of
multiple network conditions in order to evaluate the performance of different
mechanisms. In particular, while assuming a homogeneous distribution of the seeds (1
seed per domain) and leechers (8 leechers per domain) in different domains, the first
scenario being evaluated shows the effectiveness of the BGP-Loc mechanism,
especially when both ISPs B and C deployed the SIS with that ETM mechanism. These
results are shown in Figures 3 and 4. Note that due to the limited scale of these
experiments (small swarm size) these results are indicative.

/ŶƚĞƌͲĚŽŵĂŝŶƚƌĂĨĨŝĐ ;DͿ

ŽǁŶůŽĂĚdŝŵĞƐ;ƐͿ

/^WƐ
Figure 3. Download times Figure 4. Inter-domain traffic
As shown, the usage of the BGP-Loc ETM can lead to a win/non-lose scenario,
where clients download the content without any degradation in the service and the
operator attains a reduction of the inter-domain traffic from those links that are more
expensive (those ones related to transit interconnection agreement) in the short
scenario, e.g., the reduction of the inter-domain traffic in the transit link in the
download direction (that can be represented in the traffic from the ISP A to Carrier 1) is
around 3%.
Additional tests were conducted to evaluate the impact of this mechanism in other
scenarios. E.g., if the domain that implements locality has more seeds, then the
download time is reduced significantly. Therefore, the BGP-Loc ETM can benefit from
other mechanisms that: a) either provide incentives to seeds or b) deploy additional
components that provide more upload capacity, such as the IoP or the HAP ETM
mechanism. This is an observation that should be specifically considered if the ISP
deploying the SIS offers low capacity access links to its clients. In this case, the usage
of the pure BGP-Loc ETM may lead to degradation of the performance for end users,
as they benefit by uploading content from external seeds with a higher upload
bandwidth rather than from local ones that have slower connections.
These practical and experimental results are aligned with the simulation results
presented in [14], where the BGP Loc mechanism was demonstrated as an effective
procedure to reduce intra-AS traffic and peering traffic in scenarios with larger swarm
sizes and varying peer distributions per domain, thus eliminating the inevitable
limitations of the test-bed experiments.
6. Economic Implications
As introduced in Section 2, the presented ETM mechanisms aim at achieving a

TripleWin situation. This is attained, with a simplifying discussion, by focusing mostly
on incentives of the ISP and users. Note that these incentives of overlay providers are
in general compatible with those of users, in the sense that an overlay provider can be
reasonably assumed to benefit also whenever users of his application are better off.
Also, the SmoothIT approach does not take for granted a collaboration of overlay
providers (by accepting a modification of the tracker), as appears to be the case in [3]
and [6].
In the case of the locality promotion mechanism (BGP-Loc), on one hand, the
incentive of the ISP addressed is the reduction of the inter-domain traffic, and thus of
the resulting interconnection costs. On the other hand, regarding the user, the incentive
addressed is the improvement of performance. This pair of objectives also applies to
other locality mechanisms, such as for [3], [4], [5], and [6]. Locality is in general a
“win” for the ISP under the criterion of inter-domain traffic and costs. This is apparent
from results of these aforementioned approaches, and confirmed in the overall
assessment of locality in [1]. Moreover, locality is often a “win” for the user, or at least
a “no lose”; (i.e. maintains performance, without improvement), but not always, as
mentioned in [1]. This is due to the fact that certain local peers may have less upload
bandwidth to offer than the remote ones that would be discovered by the original
version of the application, particularly in cases where a bandwidth criterion is adopted
for the selections made at the application level.
Therefore, if locality is not imposed in a compulsory way, it is likely that certain
users can do better by not adopting it. This depends on the swarm distribution among
ISPs and access resources of various users. Thus, the benefit of locality may vary in
time, even for the same user within a certain swarm, since swarms are highly dynamic.
However, with the SmoothIT approach, locality is offered to the user as an option.
Hence, users have the possibility to verify that the mechanism is to their benefit or at
least not harmful. That is, a user can ignore from time-to-time the recommendation
given by the SIS and examine, whether such a bypassing of the mechanism leads to any
noticeable improvement or deterioration of the QoE (Quality-of-Experience). To the
best of our understanding, among the locality mechanisms of the aforementioned
articles, only those of [4] and [5] can function in a contestable way as SmoothIT
mechanism does. Moreover, to this end also, it is more meaningful for assessment of
BGP-Loc to mostly focus on situations where it is employed only by those users that do
benefit.
Under the other two ETM mechanisms, the ISP-owned Peer (IoP) and the Highly
Active Peer (HAP), the ISP tries to be “by definition” compatible with selections
performed by the overlay optimization mechanism: This is achieved by putting in place
more resources in his own network, thus making the IoP(s) or the HAP(s) more
attractive. With the right policy for the utilization of these additional resources, peers
that reside in this network prefer uploading from IoP(s) or the HAP(s). Therefore, these
approaches can attain both a “win” for the user regarding performance incentives and
traffic localization for the ISP. Whether this situation is indeed beneficial for the ISP
depends on the trade-off between the cost for these additional resources and the
reduction of the inter-connection costs. Note also that an ISP employing such an
approach may have a longer-term benefit, because it may improve its reputation and
thus increases its customer basis and revenues. Such cost-benefit analysis is left for
future work in the assessment of these approaches.
Regarding the “coordination” of traffic localization decisions between different
ISPs, the inter-domain collaboration mechanism (InterSIS) provides a new
communication “channel” for ISPs to resolve any information asymmetry. ISPs have
an incentive to collaborate so that they can be sure that their decisions will have the
desired positive impact on their inter-domain costs, or even be more effective than in
the absence of this collaboration. For example, under BGP-Loc, the existence of
asymmetric routes may result in unexpected increase of certain inter-domain costs, in
the case of a mutli-homed ISP. The collaboration between source and destination ISPs
may identify and resolve any such side-effects, leading to a “win” situation for both
ISPs. Of course, the effectiveness of such a collaboration heavily depends on the
truthfulness of the ISPs when reporting routing information. It is plausible that in
certain cases an ISP may not want to fully reveal his routing paths or any other routing-
sensitive information that depends on his business relationships with other ISPs.
Compared to the scenario with BGP-Loc only in place, such cases may result in a “no-
lose” situation for the ISPs, in the sense that they can collaborate by providing
information up to the level that their business position permits..
7. Summary and Future Work
In this work, a set of ETM mechanisms have been outlined to show various alternatives
that exist in order to promote localization of overlay traffic compared to existing work
in the literature. More specifically, this paper described three different mechanisms that
promote (directly or indirectly) the localization of overlay traffic, namely the BGP-Loc,
the IoP, and the HAP mechanisms. Furthermore, the ETMS system developed has been
presented, which can accommodate these mechanisms, while highlighting how
different mechanisms can be combined under the generic architectural approach. This
approach is backed by preliminary results of internal test-bed trials and referred to
simulations undertaken, too. Finally, the work has analyzed incentives behind these
mechanisms proposed and commented on the detailed difference of SmoothIT
approaches with respect to relevant mechanisms proposed in the literature. The
circumstances under which a TripleWin situation is achieved are highlighted, too.
Future work will include the implementation and testing of the HAP mechanism,
the evaluation of the IoP in the internal trial test-bed, and the deployment of all three
ETM mechanisms in a real environment to evaluate their performance under realistic
circumstances and in operational networks. Moreover, SmoothIT as a project will
continue simulative and theoretical evaluations of different ETM mechanisms and
plans to identify the key conditions under which each of them is most effective, thus,
resulting in operational guidelines for operators and end users.
Acknowledgements
This work has been performed in the framework of EU ICT Project SmoothIT
(FP7-2007-ICT-216259). Furthermore, the authors would like to thank all SmoothIT
project members for providing insights and their discussions, especially the University
of Würzburg team for their simulation work backing the implementation results in a
larger scale.
References
[1] E. Marocco, A. Fusco, I. Rimac, V. Gurbani: Mythbustering Peer-to-peer Traffic Localization, Internet
Draft, July 2009.
[2] M. Piatek, H. Madhyastha, J. John, A. Krishnamurthy, T. Anderson: Pitfalls for ISP-friendly P2P
Design, 8th ACM Workshop on Hot Topics in Networks (Hotnets), New York, U.S.A., October 2009.
[3] R. Bindal, P. Cao, W. Chan, J. Medved, G. Suwala, T. Bates, A. Zhang: Improving Traffic Locality in
BitTorrent via Biased Neighbor Selection, 26th IEEE International Conference on Distributed
Computing Systems, Lisboa, Portugal, July 2006.
[4] V. Aggarwal, O. Akonjang, A. Feldmann: Improving User and ISP Experience through ISP-aided P2P
Locality, 11th IEEE Global Internet Symposium 2008 (GI '08), Phoenix, Arizona, U.S.A., 2008.
[5] D.R. Choffnes, F.E. Bustamante: Taming the Torrent: A Practical Approach to Reducing Cross-ISP
Traffic in Peer-to-peer Systems, ACM SIGCOMM Computer Communications, Vol. 38. No. 4, October
2008, pp 363-374.
[6] H. Xie, Y.R. Yang, A. Krishnamurthy, Y. Liu, A. Silberschatz: P4P: Provider Portal for Applications,
ACM SIGCOMM Computer Communications, Vol. 38, No. 4, October 2008, pp 351-362.
[7] The SmoothIT Project, http://www.smoothit.org/, January 2010.
[8] P. Racz, S. Soursos, M.A. Callejo, S. Spirou, F. Hecht, I. Papafili, G.D. Stamoulis, Hasan, B. Stiller:
Economic Traffic Management for Overlay Networks, ICT-Mobile Summit 2009, Santander, Spain,
June 2009.
[9] The P2P-Next Project: http://www.p2p-next.org/, January 2010.
[10] P. Racz, Z. Despotovic: An ALTO Service based on BGP Routing Information, Internet Draft, June
2009.
[11] S. Oechsner, F. Lehrieder, T. Hoßfeld, F. Metzger, K. Pussep, D. Staehle: Pushing the Performance of
Biased Neighbor Selection through Biased Unchoking, IEEE P2P 2009, Seattle, Washington, U.S.A.,
September 2009.
[12] I. Papafili, S. Soursos, G.D. Stamoulis: Improvement of BitTorrent Performance and Inter-Domain
Traffic by Inserting ISP-owned Peers, 6th International Workshop on Internet Charging and QoS
Technologies (ICQT'09), Aachen, Germany, May 2009.
[13] UCSD Computer Science: ModelNet, Systems and Networking, https://modelnet.sysnet.ucsd.edu,
January 2010.
[14] The SmoothIT Consortium: ETM Models and Components and Theoretical Foundations (Final),
Deliverable D2.3, http://www.smoothit.org/, October 2009.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-11
Modeling the economics of Loc/ID Split

for the Future Internet
Luigi IANNONEa,1 and Tapio LEVÄ b
a
Deutsche Telekom Laboratories – Technische Universität Berlin, Germany
b
Aalto University School of Science and Technology, Finland
Abstract. The network research community is actively working on the design of

the Future Internet, aiming at solving scalability issues that the current Internet is
facing. It is widely recognized that the Locator/ID Split paradigm fits well the
requirements for the new, more scalable, Future Internet architecture. Both the
academy and the industry have already produced several technical proposals, with
their own peculiarities and merits. However, despite such an effort, it is still
unclear, how the Locator/ID Split will be deployed, what are the drivers of its
adoption, who will adopt it, and how the adoption process will most likely evolve
in time. In this paper, we answer to these questions by presenting an adoption
model for the Locator/ID Split paradigm.
Keywords. Locator/ID Split, Future Internet, Routing, Adoption Model.
Introduction
Nowadays, there is a growing concern on scalability issues the current Internet is

facing ([1], [2]), with the most pressing issue being the super linear growth of the BGP
routing table [3]. This does not mean that the Internet is approaching a hard scalability
limit that, once reached, will cause it to collapse. Rather, the key point is that the whole
Internet is evolving toward such a complex system that the Operational Expenses
(OpEx) cannot be sustained anymore.
Almost three years ago, the Routing Research Group (RRG [4]) of the IRTF
(Internet Research Task Force) was expressly re-chartered to design a new and cheaper
Future Internet architecture. So far the main outcome has been the recognition that
splitting the IP addressing space into an end-system addressing space (the identifiers -
IDs) and a routing addressing space (the locators - Loc) will solve or at least alleviate a
large part of the issues [5]. The technical implication of such architecture, which is
currently referred as Loc/ID Split paradigm, is the need to maintain mappings between
IDs and Locators [6]. These mappings are distributed through a Mapping Distribution
System (MDS) (e.g., [7]), and then stored in a local cache for the ongoing
communications. Additionally, tunneling or address translation operations are needed,
since IDs are not injected anymore in the BGP routing infrastructure (hence the
improved scalability).
1
Corresponding Author: Luigi Iannone, Deutsche Telekom Laboratories – Technische Universität
Berlin, Ernst-Reuter-Platz 7, 10587 Berlin, Germany. E-Mail: luigi@net.t-labs.tu-berlin.de
12 L. Iannone and T. Levä / Modeling the Economics of Loc/ID Split for the Future Internet
Although the idea of improving the Internet architecture with some form of
separation of the identity and the location dates back to the mid-90s ([8], [9], [10]), it
has gained wide support only lately due to the apparent explosion of the OpEx. Indeed,
the success of Loc/ID Split technology depends not only on its technical merits, but
also on the economical aspects of its deployment. In this paper we shed light on this
last point by creating an economic model of the adoption process of the Loc/ID Split
paradigm without focusing on any specific technical proposal. Our aim is to understand
how the cost evolution influences the adoption process, who will adopt such a
technology, and what are their reasons for adoption. We start with a high level analysis
of the stakeholders in Section 1. Then, we introduce the cost model in Section 2 and
use it in Section 3 to analyze the cost evolution and its impact on adoption process.
Finally, we conclude our findings in Section 4.
1. Stakeholder analysis
Loc/ID Split is a general paradigm that can be applied in several different places of the
Internet, depending on where the split is actually done. For instance, Loc/ID Split can
be done on end-host systems, like in the case of Shim6 [11] and HIP [12], introducing
benefits mostly related to multi-homing support and resiliency to location change.
Alternatively, Loc/ID Split can be done on domain border routers, like in LISP [13],
directly targeting the reduction of the prefix entries in the BGP routing table. Other
benefits are introduced in both cases, e.g., improved traffic engineering and reduced
provider lock-in. Regardless of their importance, they are not the main objective.
In this paper, we focus on the deployment of Loc/ID Split on border routers (i.e., à
la LISP). We believe that the main economic driver for the deployment of such
technology will be the reduction of OpEx, obtained reducing the number of prefix
entries that need to be managed, stored, and propagated to maintain full connectivity.
To this end, it is important to identify the existing stakeholders interested in deploying
Loc/ID Split.2 In such a context, Network Domains (NDs) are the main stakeholders,
since they target at reducing their OpEx by reducing the size of the BGP routing table.
Nevertheless, NDs have different costs and benefits in adopting Loc/ID Split,
depending on where they are positioned in the Internet:
Stub NDs are leafs of the Internet topology, being only source/destination of traffic,
without providing transit connectivity. Their benefits mainly consist in avoiding
provider lock-in, gaining more control on the inbound traffic, and reducing the size
of the routing table (since their prefixes will not be injected anymore in the BGP
infrastructure). The main costs are related to the physical deployment of the Loc/ID
Split technology on their border routers, which also include interoperability
solutions to guarantee connectivity with legacy NDs (i.e., NDs not using Loc/ID
Split).
Core NDs are rather at the centre of the Internet topology, providing the core
connectivity infrastructure. Reduced routing table size is also Core NDs' key benefit
but it is dependent on the Stub NDs adoption of Loc/ID Split. Further, since Stub
NDs are the ones generating most of the churn, an additional gain is the reduction
2
Due to space constrains, we omit the analysis of possible new stakeholders (e.g., mapping service
providers), which in turn can generate new business models.
L. Iannone and T. Levä / Modeling the Economics of Loc/ID Split for the Future Internet 13
Figure 1. Internet before (left) and after (right) Loc/ID Split adoption.
of such a churn. There are no direct costs for Core NDs, unless they are willing to
deploy Loc/ID Split to further increase the welfare of the Internet.
The difference of benefits between Stub and Core NDs plays a key role on who will
start deploying Loc/ID Split. As we will show in the remainder of the paper, cost
reduction can be small for early adopters. In this case Stub NDs have stronger
incentives, since, even if cost reduction is small, by adopting Loc/ID Split they avoid
provider lock-in and have full control of inbound traffic. Core NDs benefit from Stub
NDs adopting Loc/ID Split, since their own BGP tables will shrink as well. However,
as we will show in Section 3, with well engineered solutions the cost reduction will
become important as long as NDs adopt Loc/ID Split, hence strengthening the
incentives for Core NDs to deploy the Loc/ID Split technology.
2. Cost model of Loc/ID Split adoption
As mentioned earlier, we believe that the main driver for adopting Loc/ID Split is the
reduction of the information (entries) that NDs have to deal with in order to maintain
end-to-end connectivity. In the context of Loc/ID Split, the generic term “entry” does
not refer only to the entries in the BGP RIB, but also the entries in the local cache, as
well as the entries maintained locally in the Mapping Distribution System. Figure 1
shows a snapshot of today's situation with large BGP RIB (left), and what will be the
situation once the Loc/ID Split adoption process has completed (right).
Each type of entry represents an operational cost as well as a capital cost in terms
of resources (e.g., memory). Regardless the specific relationship with the monetary cost
and neglecting the switching cost, it is appropriate and sufficiently general to adopt the
number of entries as the cost metric when modeling the adoption of Loc/ID Split.
More specifically we model the number of entries per ND needed for the full
connectivity. Currently each ND has to store one entry per each other ND (cost = 1),
but thanks to Loc/ID split it is possible to reduce the number of entries per Network
Domain (cost < 1).
Following an approach similar to the one proposed by Joseph et al. [15], Equation
(1) formulates the total cost CT for a generic ND as the average number of entries
stored per-ND:
(1)
Where C(L→B)(XL) and C(B→L)(XL), which are detailed in the next sections, have the
following meaning:
C(L→B)(XL) is the cost (i.e., the number of entries stored per-ND) for a domain that has
adopted Loc/ID Split, including the cost to assure connectivity to legacy BGP NDs.
C(B→L)(XL) is the cost (i.e., the number of entries stored per-ND) for a legacy domain
that has not adopted Loc/ID Split, including the cost to assure connectivity toward
Loc/ID Split enabled NDs.
2.1. Cost for Loc/ID Split NDs
The cost C(L→B)(XL) can be modeled as the sum of four terms: 1) the cost of the cache,
2) the cost of the connectivity infrastructure, 3) the cost to reach legacy BGP NDs, and
4) the cost of the Mapping Distribution System (MDS).
The cost of maintaining a cache of mappings can be simply formalized as αXL.
The parameter α (ranging from 0 to 1) represents the percentage of Loc/ID Split
enabled NDs that are in average present in the cache. Otherwise stated, αXL expresses
the average size of the mapping's cache in terms of entries for the ongoing
communication. Even if this quantity is traffic driven, it is possible to have an average
estimation of the size of Loc/ID Split cache, by means of traffic analysis. An example
of such estimation can be found in the work of Iannone et al. [6].
The connectivity infrastructure cost is proportional to the number of Core NDs
that have adopted Loc/ID Split and can be formalized as γXLCI. CI represents the
percentage of prefixes that have to be maintained in order to guarantee the connectivity
existing in the Default Free Zone (DFZ). In other words, this can be seen as the size of
the Locator addressing space. CI can be easily evaluated by counting the number of
Core ND prefixes in the BGP routing table. γ (ranging between 1 and 0) is an
aggregation factor expressing the fact that once Stub NDs have switched to Loc/ID
Split, a large part of de-aggregation present in today's Internet can be avoided, which
reduces the infrastructure connectivity cost.
The cost to reach legacy BGP NDs is simply given as the percentage of networks
domains that have not yet adopted Loc/ID Split (1 - XL) and thus need to be present in
the BGP's RIB.
The cost of the Mapping Distribution System is proportional to the number of
entries that it has to manage in order to guarantee connectivity among Loc/ID split NDs
and can be formalized as ωXL. The parameter ω (ranging from 0 to 1) expresses what
percentage of the mappings present in the MDS needs to be stored locally.3 Note that
this term is present only in the case that the network domain is part of the Mapping
Distribution System otherwise the cost is zero.
Putting together all of the abovementioned costs leads to the following
formalization of the cost for a Loc/ID Split ND in Equation (2):
(2)
2.2. Cost for legacy BGP NDs
The cost C(B→L)(XL) for a legacy ND that has not adopted Loc/ID Split can be modeled
as the sum of two terms: 1) the cost to reach other legacy BGP NDs and 2) the cost to
reach Loc/ID adopters.
The cost to reach other legacy BGP NDs is simply the percentage (1-XL) of NDs
that have not adopted Loc/ID Split.
The cost to reach Loc/ID Split enabled sites can be formalized as βXL, where β
(ranging from 0 to 1) represents an aggregation factor. To make Loc/ID Split adopters
reachable from legacy BGP NDs, a proxy-based solution, like for instance [14], can be
3
This should not be confused with the mapping cache. The cache temporarily stores mappings that are
needed for the ongoing communications, while the mapping distribution system is basically a distributed
database of all available mappings.
Table 1. Summary of the parameters introduced in the adoption model.

Name Description Range
C(L→B) Cost (i.e., the number of entries stored per-ND) for a Loc/ID Split adopter ND [0 – ∞]
C(B→L) Cost (i.e., the number of entries stored per-ND) for a legacy BGP ND [0 – ∞]
CT Total cost for a generic ND (i.e., the average number of entries stored per-ND) (0 –∞]
XL % of NDs that are in Loc/ID Split enabled NDs [0 – 1]
CI % of NDs necessary to maintain the Connectivity Infrastructure (0 – 1]
α Cache Aggregation Factor (0 – 1]
β Legacy ND Proxy Aggregation Factor (0 – 1]
γ Connectivity Infrastructure Aggregation Factor (0 – 1]
ω Mapping Distribution System Load Factor [0 – 1]
used. This injects large aggregates of the ID space in the BGP routing infrastructure.
The factor β expresses such a degree of aggregation.
By adding up the two abovementioned costs we formalize the cost for a legacy ND
in Equation (3):
(3)
2.3. Total cost
By substituting Equations (2) and (3) in Equation (1), it is possible to derive the total
cost CT in Equation (4):
(4)
The different parameters and quantities of the equation, which have been introduced
throughout the whole section, are summarized in Table 1.
3. Cost evolution analysis
In this section we use the proposed model to analyze the cost evolution during the
adoption process of Loc/ID Split. We first look at the cost evolution for single NDs,
namely C(L→B) and C(B→L), then at the total cost CT evolution. Finally we draw some
conclusions concerning the adoption of Loc/ID Split where we assume that NDs make
their adoption choice based on the global welfare (i.e., minimized global costs).
3.1. Single Loc/ID Split ND
The cost in terms of entries for a Loc/ID split ND has been formalized in Equation (2).
In order to analyze evolution of this cost we have to define suitable values for the cache
cost, interconnectivity cost and MDS cost.
Cache cost: Extensive measurements performed by Iannone et al. [6] show how a
cache can be engineered by tuning the cache timeout, in order to reduce its size with
only a small decrease in the hit ratio. In particular, it is possible to have a cache as
small as 3.3% of the BGP prefix space, while maintaining a hit ratio as high as 94%.
This means that a realistic value of α is around 3.3% of the percentage XL of NDs that
have adopted Loc/ID Split: α = 0.033⋅XL.
Interconnectivity cost: Adopting Loc/ID Split does not mean that the BGP routing
infrastructure in the Default Free Zone (DFZ) will disappear, but rather that the BGP
tables will shrink to smaller size. The smaller BGP tables are represented in our model
by the factor γCI. Simulation study of Quoitin et al. [5] showed that by withdrawing the
prefixes of stub networks from the DFZ it is possible to have a higher degree of
aggregation and reduce the size of BGP tables up to a factor of 10. This means that a
good estimation of γ is 10%. Nevertheless, it is unlikely that the aggregation is high
from the beginning. Hence γ can be modeled in a way that it lowers to 10% as more
NDs adopt Loc/ID Split: γ = 0.10 + 0.9(1-XL). The other factor to take into account is
CI. In the current Internet, 60% of the prefixes are announced by transit network
domains: CI = 0.6.
Mapping Distribution System cost: The parameter ω expresses the local cost
imposed by the mapping distribution system. The smaller the factor, the lower is the
cost, since it means that fewer mappings need to be maintained locally. Note, however,
that the whole MDS stores always all of the existing mappings. A network domain can
even decide to outsource the MDS functionality. This means that it will not directly
participate in the MDS infrastructure, but it rather relies on the possibility to just query
the MDS which is maintained by other network domains or by a third party. In the case
of outsourcing the cost is obviously 0, since the network domain does not need to
maintain any entry for the mapping distribution service.4
In the case of the NDs participating in the MDS infrastructure the cost depends on
the architecture used to implement the distributed mapping database. It is possible to
identify three different main architecture types:
Flat Pull: Flat Pull architecture consists of a distributed infrastructure without
hierarchical organization; the requested information can be pulled through a simple
query. Main examples of this type of architecture are DHT-based lookup
infrastructures [7]. The average number of entries (in percentage) in such a
structure is given by the number of nodes present in the infrastructure divided by
the total number of prefixes in the ID space. The best case is when every ND has
only one node in the infrastructure. Taking today's number of entries in the BGP
table (~300,000), this is equivalent to having a cost of around 0.0003% per network
domain.
Hierarchical Pull: Contrary to the previous case, this one is a distributed infrastructure
with a hierarchical organization. The needed information can be pulled through a
query that can recursively propagate through the hierarchy. This kind of
infrastructure is very similar to the DNS system. The average number of entries per-
domain (in percentage) in such a structure is given by the average proportion of
entries of Flat Pull architecture (the lowest level of the hierarchy) multiplied by the
logarithm of number of levels in the hierarchy. Assuming the best case of the flat
pull and a balanced binary tree, the load is 5 times greater than in the Flat Pull case.
Push: This kind of architecture has the opposite approach compared to the previous
two. Instead of pulling the information from the infrastructure when needed, the
infrastructure pushes the information to all nodes that are part of the system. This
means that every node has global knowledge of all available mappings and no
cache is needed anymore. In this particular case ω = 1 while α = 0.
4
Note that this does not count for the monetary cost of the service from a third party.
Figure 2. Cost evolution of the mapping distribution Figure 3. Cost evolution for Loc/ID Split network
model. domains (including mapping cost).
The cost evolution for all of the three mapping architectures is depicted in Figure 2,
where the cost axis is in log scale because the costs of Flat Pull and Hierarchical Pull
are very close to each other and decrease very fast with the increasing proportion XL of
adopters. This is due to the fact that when the number of adopters increases, the cost
per-single ND becomes very small since the cost is evenly distributed between all
adopters. On the contrary, in the Push model the cost is always increasing and
proportional to the number of adopters.
Figure 3 finally shows the entire cost for Loc/ID Split adopters. As can be observed,
the mapping cost in the case of the Pull model is very small and has almost no impact.5
On the contrary, in the case of Push model the cost rises until reaching its maximum in
the middle of the adoption process, and then lowers. The decrease of the cost is not due
to reduction of the mapping cost, since in reality it increases linearly with the number
of adopters. Rather, the reduction is due to the fact that the connectivity infrastructure
will allow aggregating prefixes as long as the number of adopters increases. In other
words, the decreasing γ allows overall cost reduction.
3.2. Single Legacy BGP ND
The cost in terms of entries for a legacy BGP NDs has been formalized in Equation (3).
Figure 4 presents the cost evolution for a legacy ND as the function of XL. This cost
decreases with a slope that depends on the factor β.
Let us first analyze the case where aggregation factor β is constant throughout the
adoption process (dashed lines in Figure 4). On one hand, in the case β = 1, there is no
cost reduction at all. This is due to the fact that prefixes that are withdrawn from legacy
ND's BGP RIB are now announced unchanged by the proxy solution. From this we can
observe that any interconnectivity solution based on a proxy approach provides benefits
only in the case that prefixes of Loc/ID Split NDs are massively aggregated.
On the other hand, the case β = 0 shows the steepest decrease in the cost. However,
β = 0 cannot be considered, since it means that no prefixes are announced to reach
Loc/ID Split NDs from legacy BGP NDs. This would result in no interconnectivity,
which makes this case unacceptable.
5
For simplicity we just plot the Flat Pull cost, since the Hierarchical Pull model is pretty close.
Figure 4. Cost evolution for legacy BGP network Figure 5. Total cost evolution for different values
domains. of β (not considering the mapping cost).
Assuming constant β is clearly an unrealistic hypothesis. A more realistic

assumption is to consider a linear decrease of β for increasing values of XL. In this case,
the cost reduces slowly when the number of adopters is small, but the pace accelerates
when the number of adopters increases. This matches with the probable evolution of
the adoption. At the beginning the prefixes of few adopters are not easily aggregatable
by the proxy solution but the chances for aggregation increase along with the
increasing number of adopters.
3.3. Total Cost Analysis
The total cost CT for a generic ND as the average number of entries stored per-ND is
formalized in Equation (4). With some trivial mathematical transformations, this
equation can be re-written in the form:
(5)
Equation (5) is used in Figure 5 to draw the evolution of the total cost as a function
of the number of NDs that adopt Loc/ID Split. The figure neglects the mapping cost
(i.e., ω = 0), keeps (α + γCI) constant and shows the cost evolution for several constant
values of β as well as for a linearly decreasing value of β (i.e., increasing aggregation).
If no ND adopts Loc/ID Split, the cost is equal to CT(XL = 0) = 1. Since all the
quantities are expressed in a relative form this translates in having 100% of the actual
cost (i.e., the cost of current BGP RIB). Otherwise, if all the NDs adopt the technology,
the total cost becomes CT(XL = 1) = (α + γCI). On one hand, this shows the correctness
of the model, since once every ND has adopted the technology the cost does not
depend on the interoperability technology (i.e., the β factor). On the other hand, it
correctly shows that the final cost depends only on the size of cache (α) and the
connectivity infrastructure (γCI).
In the same plot, it can be observed that the cost reduction is slow at the beginning,
but accelerates for increasing number of adopters. Nevertheless, this is not always true.
As shown in Figure 6, if the final cost is small, the curve has a steep slope, thus making
even late adopters to decrease the cost. However, if the final cost is high, the trend of
the slope can even be inversed, making the late adopters increase the cost. This last
point leads to the conclusion that if Loc/ID Split does not provide sufficient reduction
in the cost, i.e., high benefits, the adoption process of the technology will never
complete, because late adopters thinking about global welfare have no sufficient
incentives for adoption (they may even have deterrence since the cost increases).
Figure 6. Total cost evolution for different values Figure 7. Total cost evolution including mapping
of (α + γCI) (not considering the mapping cost). cost.
Table 2. Total cost for different mapping models.

Distribution Model Cache Mapping Interconnectivity Total Cost
Flat Pull 3.3% 0.0033% 6% 9.3%
Hierarchical Pull 3.3% 0.0165% 6% 9.3165%
Push 0 100% 6% 106%
Finally, in Figure 7 we present the evolution of total cost including the mapping
cost (both pull and push model). As can be observed, the Pull model (flat or
hierarchical) introduces some costs, i.e., some entries that need to be managed, but it
does not represent the major part of the overall cost.
From a static perspective the cost of the MDS is not high. However, it has to be
noted that the current analysis does not take into account the dynamics of the system,
meaning that it does not model the load in terms of queries that the system has to
support. Nevertheless, the load of the MDS is similar to the current load of the DNS
system [6], and thus it is not a critical issue.
The use of Push model leads to increased total cost in the end of the adoption
process. However, it is interesting to note that this is not the case all the time. During
the adoption process the overall cost can be reduced, even if the reduction is slower
than in the Pull case. This is not because of the mapping system itself, but rather due to
the fact that the interconnectivity infrastructure can be strongly aggregated (i.e., the
term γCI can be very small), which reduces the overall cost. Nonetheless, using a Push
model will basically lead to a world where the adoption process will never complete
since late adopters will increase the overall cost of the Internet. This is better shown in
Table 2, which summarizes the final total cost for the different mapping distribution
system architectures when all of the NDs have adopted Loc/ID Split.
4. Conclusion
The Loc/ID Split cost model and analysis proposed in this paper is a useful tool in
deriving the relation between important architectural parameters, incentives, and the
possible deployment scenarios. In summary, Loc/ID Split adoption depends on -how
much- the cost can be reduced and -how efficient- deployed components are.
In particular, the proposed analysis shows that to have a cost reduction, and hence
incentives to adopt Loc/ID Split, the sum of the cost of the cache (α), the connectivity
infrastructure (γCI), and the mapping distribution system (ω) must be lower than the
original cost of today's BGP Internet. The adoption process will offer more incentives
if the interoperability technology (β) greatly reduces the number of prefixes through
aggregation. Nevertheless, if the interoperability technology performs too well, late
adopters can actually increase the overall cost, which may prevent complete adoption.
The current assumption that NDs would base their adoption decision on the global
cost minimization is naive in the commercial Internet. Thus in the further work we will
analyze the adoption incentives assuming selfish NDs that try to minimize only their
own costs. This analysis will also take into account the switching costs and possible
obstructions for deployment, which can have major impact on the adoption decision.
Acknowledgements
This work has been partially supported by the European Commission within the
INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org).
References
[1] D. Meyer, L. Zhang, and K. Fall: IETF - RFC 4984, Report from the IAB Workshop on Routing and
Addressing. 2007.
[2] T. Narten: IETF - draft-narten-radir-problem-statement-05.txt, Routing and Addressing Problem
Statement. 2010.
[3] BGP Routing Table Analysis Report: http://bgp.potaroo.net
[4] RRG - Routing Research Group: http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
[5] B. Quoitin, L. Iannone, C. de Launois, and O. Bonaventure: Evaluating the Benefits of the
Locator/Identifier Separation, ACM Sigcomm Workshop on Mobility in the Evolving Internet
Architecture (MobiArch), 2007.
[6] L. Iannone, O. Bonaventure: On the Cost of Caching Locator/ID Mappings, ACM CoNEXT 2007, 2007.
[7] L. Mathy, L. Iannone: LISP-DHT: Towards a DHT to map identifiers onto locators, ACM CoNEXT
Workshop on Re-Architecturing the Internet (ReArch), 2008.
[8] J. Saltzer: IETF - RFC 1498, On the Naming and Binding of Network Destinations, 1993.
[9] R. Hiden: IETF - RFC 1955, New Scheme for Internet Routing and Addressing for IPNG, 1996.
[10] M. O'Dell: IETF - draft-ietf-ipngwg-gseaddr-00.txt, GSE - An Alternate Addressing Architecture for
IPv6, 1997.
[11] E. Nordmark, M. Bagnulo: IETF - draft-ietf-shim6-proto-12.txt, Shim6: Level 3 Multihoming Shim
Protocol for IPv6, 2009.
[12] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson: IETF - RFC 5201, Host Identity Protocol, 2008.
[13] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis: IETF -- draft-ietf-lisp-01.txt, Locator/ID Separation
Protocol (LISP), 2009.
[14] D. Lewis, D. Meyer, D. Farinacci, and V. Fuller: IETF - draft-ietf-lisp-interworking-00.txt, Interworking
LISP with IPv4 and IPv6, 2009.
[15] D. A. Joseph, J. Chuang, and I. Stoica: Modeling the Adoption of new Network Architectures, ACM
CoNEXT, 2007.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-21
Business Aspects of Multipath TCP

Adoption
Tapio LEVÄa,1, Henna WARMAa, Alan FORDb, Alexandros KOSTOPOULOSc,
Bernd HEINRICHd, Ralf WIDERAd, and Philip EARDLEYe
a
Aalto University School of Science and Technology, Finland
b
Roke Manor Research, United Kingdom
c
Athens University of Economics and Business, Department of Informatics, Greece
d
T-Systems International GmbH, Germany
e
British Telecommunications plc, United Kingdom
Abstract. Multipath TCP (MPTCP) is a resource pooling mechanism which splits

data across multiple subflows (paths) and ensures reliable data delivery. Although
Multipath TCP is a relatively small technical change to the TCP protocol
providing improved resilience, throughput and session continuity, it will have
considerable impact on the value networks and business models of Internet access
provisioning. In this paper, we evaluate the viability of different MPTCP
deployment scenarios and present what new ISP business models might be enabled
by the new flexibility that MPTCP brings. This allows the research community to
focus on the most promising deployment scenarios.
Keywords. Future Internet, multipath TCP, resource pooling, business models,

deployment scenarios, adoption incentives, virtual multipath operator
Introduction
The resource pooling principle [1] advocates making improved use of the Internet’s
resources by allowing separate resources (such as links or processing capability) to act
as if they were a single large resource. One particular manifestation of this principle is
the development of multipath transport protocols (specifically Multipath TCP [2]),
whereby multiple paths between two endpoints can be pooled to appear to the
application as a single transport connection through dynamic scheduling of traffic
across the available paths. MPTCP provides higher resilience to link or node failure.
Furthermore, it increases bandwidth and resource utilization due to coordinated
congestion control for the multipath data transfers [3].
From a technical point of view, MPTCP needs only a relatively small change to the
TCP/IP stack at the end hosts which is currently being standardized in the IETF [4].
Although, at first sight, MPTCP may seem simply to be about technology, it will also
significantly change the value networks between stakeholders in the Internet
connectivity market.
1
Corresponding Author, email: tapio.leva@tkk.fi
Acknowledgement: This work has been supported by the European Commission within the INFSOICT-
216372 TRILOGY Project (www.trilogy-project.org).
22 T. Levä et al. / Business Aspects of Multipath TCP Adoption
The main contribution of this paper is to present different scenarios for MPTCP
deployment and evaluate their viability based on 1) end-user costs and benefits
(Section 3), and 2) the business opportunities for ISPs (Section 4). In particular, we
present some new ISP business models that will be enabled by the different deployment
scenarios. We also propose a new market player, a virtual multipath operator.
1. Stakeholder analysis
The first thing to note about Multipath TCP is that its deployment but not necessarily
its success is dependent upon endpoints only. There are no technical adaptations
required at intermediate providers in order to support its deployment. That does not
mean, however, that other stakeholders do not have an interest in MPTCP. Therefore
we identify the stakeholders and their motivations regarding the deployment and use of
MPTCP, and show how these motivations will impact each other.
Figure 1 visualises identified stakeholders along with their level of interest in
MPTCP deployment. This two-axis separation illustrates at what point during the
development and deployment of MPTCP the stakeholder becomes interested, and
whether they are actively involved in its development and deployment, or whether they
are just passive observers.
Figure 1. Stakeholders' interests in MPTCP deployment
End-users
The term “end-user” is widely used to cover not only individuals like domestic and
mobile users but also large sites, such as corporate or academic sites, and
content/service providers. These stakeholders have an active interest at “run time”
(deployment and post-deployment), but also have an interest before deployment since
they are in a position to influence other stakeholders, particularly software authors, to
provide the MPTCP solution. For the further analysis in Sections 2 and 3 end-users are
classified as 1) light, 2) heavy or 3) content provider since each of them will have a
different notion to deploy MPTCP. The classification is based on users’ intensity of
Internet usage and their resilience requirements.
T. Levä et al. / Business Aspects of Multipath TCP Adoption 23
Connectivity providers (ISPs)

Connectivity providers can be categorised as either access providers (tier 2) or transit
providers (tier 1). Although both can be passive to the end-user driven deployment of
MPTCP, it is likely that they will have significant post-deployment interest because of
the changes in traffic or business models due to MPTCP use. Tier 1 ISPs are likely to
be passive beneficiaries of resource pooling, in that MPTCP should shift load away
from congested bottlenecks if alternative paths are available. Tier 2 ISPs, however,
have much higher interest since MPTCP’s prerequisite for multihoming increases the
demand for connectivity and enables new business models (see Section 4).
Software (OS) authors and equipment vendors
These are the stakeholders who actually make the decision to implement and supply
MPTCP support. By its very nature this interest lies in pre-deployment. There must be
a motivation, however, for the software authors to provide MPTCP support, and this
pressure will come primarily from end-users who wish to make use of multipath
functionality. The benefits of adding MPTCP will initially be as a product differentiator,
and later followed as a necessity to maintain the same functionality as competitors.
Open source software will likely provide a significant driver here. Additionally,
vendors who are also content-providers (i.e. they have control over hosts at both client
and server side), e.g., Nokia with its Ovi services or Apple with its iTunes Store and
App Store, may see business opportunities in MPTCP. However, this interesting
business case is left for a future research topic.
The deployment scenarios illustrated in Section 3 (except one version of Scenario
1) presuppose that MPTCP support is available in end-user hosts, and thus the role of
the software and equipment vendors is not discussed further in this paper.
Router and infrastructure vendors
Although no changes are required at routers to support MPTCP, router and
infrastructure vendors may have a vested (passive) interest in its deployment. For
example, if ISPs are concerned about multipath TCP having an impact on their traffic
engineering or business models, and vendors who supply boxes to support traffic
engineering see MPTCP as a threat, then they may act to prevent MPTCP deployment.
2. Costs and benefits of multipath TCP
Before diving deeper to the pros and cons of different deployment scenarios in Section
3, it is necessary to understand what are the general costs and benefits of MPTCP
deployment for end-users and ISPs.
2.1. End-user’s costs and benefits
In order to get MPTCP benefits, there are potentially two separate costs for end-users.
Firstly, there is a cost involved with the deployment of MPTCP software, potentially
monetary but primarily due to time and effort involved. Deploying MPTCP may take
the form of installing a specific extension (i.e. the end-user is aware and makes an
explicit choice), or it may come bundled as part of an operating system (in which case
the end-user may not be aware, or may need to enable/configure it). Early adopters will
have the highest costs in deployment due to relative complexity. As MPTCP becomes
available and enabled by default in operating systems, this cost will tend towards zero.
Secondly, there is the cost of additional physical connectivity. In order for hosts to
get resource pooling benefit across a MPTCP connection, at least one endpoint must be
multihomed to create the requisite multiple paths. This can create an additional cost,
e.g. through buying an additional DSL or WLAN connection. However, many large
providers and mobile end-users are already multihomed, and with a little network
reconfiguration they could quite easily make use of existing multi-addressing.
The benefits of MPTCP are seen differently by different end-user groups:
• Higher resilience: This is relevant to all end-users; however the larger sites
will typically see a larger benefit since there are more people that could be
inconvenienced in the case of failure. Furthermore, companies’ need for
business continuity increases their demand for resilience.
• Session continuity: In addition to resilience, in the event of deliberate changes
in connectivity, MPTCP will allow the session to continue. This is
predominantly of interest to (light or heavy) mobile users.
• Higher throughput: Most relevant to heavy users (domestic/sites, i.e. humans),
however indirectly it is also of benefit to providers as it gives a perception of a
better service. For content providers, higher throughput also potentially means
more sales.
It is important to note that these benefits do not directly create revenue for end-
users. They are rather enhancements that, through greater availability or better
perceived service, bring in more business for suppliers, less hassle for domestic users,
and more productive time for companies.
2.2. ISPs’ costs and benefits
Due to higher visibility of throughput and network performance enabled by MPTCP,

ISPs may become more comparable in real time. This increased competition and
reduction in provider lock-in may be seen as a “cost” by ISPs, although innovative ISPs
should see this as an opportunity to attract more customers through better or more
MPTCP-tailored services.
The main benefit for ISPs is indirect and based on increased demand for
connectivity, and new business opportunities. However, MPTCP may also allow ISPs
to run closer to capacity, since spikes on load can be spread across links more
effectively. Additionally, support calls are a major cost for ISPs, and if MPTCP can
mask occasional, unexpected outages then it is likely that ISPs will have fewer such
calls to deal with.
3. Potential MPTCP deployment scenarios
In this section, we consider different technical architectures which illustrate how

MPTCP can be deployed in the access part of the network. We concentrate on the end-
user perspective and at the end of the section we evaluate the attractiveness of each
deployment scenario to end-users.
With the deployment of MPTCP, an end-user can be connected to either one or
many ISPs through one or many access technologies. To simplify the following
analysis, we restrict the number of physical connections to ISPs and the number of ISPs
that an end-user is connected to two here, and we state that two can be generalized to n.
3.1. Scenario 1: End-user with single physical access to one ISP
Figure 2 illustrates the technical architecture of a scenario where the end-user has only
one physical connection, such as a DSL access link, to a single ISP. This kind of
deployment scenario also requires the involvement of the ISP1 in order to have
MPTCP deployed because it is the ISP1 that shares the traffic into separate routes.
It is up to the ISP1 how it splits the end-users’ traffic into multiple paths. First
opportunity for the ISP is to provide the multipath feature through a proxy, splitting the
end-user traffic into two independent paths to different transit providers. In this case,
the end-user’s host does not have to be MPTCP capable but there has to be a way how
the different MPTCP flows are separated from each other in the network. If the end-
user’s host is MPTCP capable, the ISP can give the end-user multiple IP-addresses and
provide many sessions over the single access link. The ISP ensures that traffic flows
originating from the different end-user source addresses get routed to different transit
providers to enable disjoint multipath connections through the Internet.
ISP2
Internet
ISP1 Cloud
ISP3
Figure 2.Technical architecture of deployment scenario 1.
This implementation provides the benefits of MPTCP, such as improved

throughput. However, the throughput increment depends highly on the performance of
the ISP. On the other hand, improvements in resilience only exist further into the
network, beyond ISP1, because the traffic is operated between the end-user and its ISP
through only one link. If the single access link fails there is no other path where the
traffic could be re-routed. Also, in the proxy case the end-user does not have control
over the load balancing - ISP1 decides on routing of MPTCP traffic flows.
3.2. Scenario 2: End-user with dual physical access to one ISP
Another possible scenario is the end-user having at least two separate physical
connections towards a single ISP. The physical links can be either similar, such as two
DSL connections, or dissimilar, such as a DSL connection and a 3G connection. Figure
3 illustrates the technical architecture of the deployment scenario with two different
access technologies. In this case, the end-user host has to have its protocol stack
updated to support MPTCP. This type of scenario can be deployed without the
involvement of the ISP because the MPTCP functionality is implemented at the end-
users’ host.
In this kind of scenario the end-user has the control of the links and the host is able
to balance the load between the access links. Also, the end-user is given transparency
of the multipath links provided by MPTCP and has the power to assess the
performance of the links. But if the disparity between bandwidths of the access links is
large, the throughput advantage of acquiring two access links is limited. With two
physical connections the user gets better resilience, since the access link is normally the
least reliable part of the end-to-end path.
Internet
ISP1 Cloud
Figure 3.Technical architecture of deployment scenario 2.
Because end-users need to contract with their ISPs for using multiple physical
connections, the increased costs of Internet connectivity may be a drawback of this
scenario. Additionally, an end-user still relies on a single ISP which might become a
bottleneck.
3.3. Scenario 3: End-user with dual physical access to different ISPs
Finally, we introduce a deployment scenario where the end-user has multiple similar or
dissimilar access links to, at least, two different ISPs. In Figure 4, we present the
technical architecture of the scenario where the end-user uses different access
technologies to connect different ISPs.
ISP1
Internet
Cloud
ISP2
Figure 4. Technical architecture of deployment scenario 3.
In this scenario, the end-user needs to contract with at least two different ISPs for
using their access links. On one hand, this gives more bargaining power to the end-user
but on the other hand it entails the burden of handling many contracts and paying
multiple bills. The end-user is not dependent on only one ISP and the Internet
connection is not lost even though one of the operators fails.
If the end-user uses dissimilar types of technologies to connect to the ISPs, the
links have different characteristics in reliability and throughput. Thus the end-user
loses some of its ability to compare the ISPs. This scenario also increases the end-
users’ monetary costs of Internet connectivity. Additionally, for mobile users, the use
of multiple radio interfaces at the same time will increase the power consumption and
shorten the battery life.
3.4. Viability of deployment scenarios
All the deployment scenarios we have presented in this section have their costs and
benefits located at the end-user. In this section, we evaluate the viability of different
scenarios by presenting the attractiveness for the different types of end-users and the
most important advantages and drawbacks of each scenario. Table 1 summarizes our
evaluation.
A typical light user is a domestic consumer who is not interested in deploying
MPTCP if it brings additional costs such as effort or monetary costs. Heavy users or
content providers, on the other hand, may have incentives to invest time and money for
getting the benefits entailed by MPTCP. Thus heavy users will want to enjoy the best
possible performance and full resilience of MPTCP, while light end-users prefer lower
monetary costs and a simple deployment.
In some cases, the attractiveness of MPTCP to an end-user depends on whether the
scenario with similar or dissimilar physical connections is in question. We find that
scenarios where the end-users are able to use multiple access technologies are more
attractive compared to a deployment with multiple similar connections. Current laptops
and mobile devices already support multiple access technologies and MPTCP allows
more efficient usage of the available connectivity resources. 3G enables ubiquitous
connectivity while WLAN, e.g. in the office, offers higher bandwidth. Also seamless
handover, when, e.g., a mobile user returns home and starts using WLAN for higher
bandwidth, is a remarkable benefit.
If MPTCP capability is not rolled out to end-user hosts, the ISP has to provide this
functionality through an additional proxy as we stated in Section 3.1. This deployment
scenario is attractive only to light end-users and it is questionable if ISPs want to take
the effort addressing this user group which is reluctant to pay more for the increased
network throughput and reliability. All other scenarios require the implementation of
MPTCP at the end-users host. Hence, this issue should be driven with software
providers.
Table 1. Evaluation of deployment scenarios based on their attractiveness, advantages and drawbacks.
Attractiveness
Deployment Light Heavy Content

scenario end-user end-user provider/Site Advantages Drawbacks
Limited benefits
1. ISP acts as a Requires the least
due to single
multipath Medium Low Low effort from the
access line, e.g.,
operator end-user
limited resilience
2. Disjoint End-users are still

Double access
connectivity to Low High Medium dependent on one
under one contract
a single ISP ISP
3. Disjoint Burden of having

Power to race
connectivity to Low High High multiple contracts
ISPs
different ISPs and bills
To conclude our evaluation we can say that for a light end-user the deployment of
MPTCP is not that attractive. For heavy end-users and content providers the scenarios
which offer additional incentives or where multihoming capability exists already for
other reasons are most interesting. For example, mobile end-user variants of Scenarios
2 and 3 with high capacity fixed or nomadic access supported with low capacity mobile
access have potential because mobile devices already support multiple access
technologies and different access connections complement, not substitute, each other.
Similarly, the fixed multihoming architecture of Scenario 3 is already today a reality
for content providers and large sites, so harvesting additional benefits through MPTCP
adoption would be reasonable for them.
To assess whether the ISPs are eager to encourage adoption of this technology by
the end-users, we have to evaluate the possible ISP business models enabled by each
deployment scenario, which is done in the following section.
4. ISP business models
In this section we move the focus to ISPs and their business opportunities related to the
introduction of MPTCP. We present a specific business model enabled by each
deployment scenario. The attractiveness of a business model and the corresponding
deployment scenario from an ISP’s perspective is evaluated by using SWOT analysis.
4.1. ISP offers MPTCP as a value added service (enabled by Scenario 1)
Upgrading a single access link with a multipath feature will bring a unique selling
proposition to the ISP. With the proxy solution, ISPs can give end-users an early start
to gain MPTCP’s benefits before the roll-out of MPTCP in computer operating systems.
This advantage will be chargeable to end-users, together with the MPTCP inherent
benefits of connection reliability, compensating for the ISPs efforts to provide the
proxy. There is also chargeable added value to the end-user in the other case, where
ISP provides many sessions (i.e. multiple IP addresses) over a single access link.
The customer target groups of these scenarios are end-user’s in need of multipath
functionality, but not willing to pay for a second access link, such as consumers and
SMEs (Small/Medium Enterprises) with a single DSL connection. However, also
mobile scenarios of consumers or business users are possible. The ISP can offer this
multipath-upgrade as a premium feature to its current customer base to retain customers
with increased demands.
Table 2. ISP SWOT analysis of “MPTCP as a value added service” business model
Strengths Weaknesses
• Ownership of customer access line • May require additional peering contracts if ISP1
• Existing customer relationship will be was previously connected only to one Tier 1 ISP
maintained • Cost to establish a solution facilitating disjoint
• Improved resilience and thus service quality MPTCP paths
because of multiple peering ISPs • Potential dependency on software vendors to
develop MPTCP-proxy functionality
• Throughput dependencies on the performance of
the upstream ISPs
Opportunities Threats
• Revenue by access provision • Possible visibility of bad network or proxy
• Unique selling proposition for MPTCP performance may lead to complaints and loss of
provisioning customers
• Warranty of reliable throughput can be charged • Customers may not be willing to pay for the
to customers service to sufficiently compensate for the ISP’s
additional costs
4.2. Access connection bundling (enabled by Scenario 2)
Although Scenario 2 does not require ISP involvement, the ISP can attract customers
through lucrative access connection bundles. Target customers could be, for example,
professional/heavy end-users or large sites with two DSL connections, or end-users
with a fixed (or WLAN) and mobile access from the same provider. The ISP can
market the bundle with MPTCP features like flexibility, seamless transition from fixed
or nomadic to mobile access, and resilience against the failure of one of the access
connections. Further, the ISP can offer full resilience by using the routing techniques
described in Section 3.1 to achieve disjoint paths beyond the access connections.
What makes access bundling especially interesting is that by offering multiple
connections itself the ISP can avoid the increased competition and comparability of
Scenario 3 where the end-user has multiple connections from different ISPs.
Furthermore, bundling allows sustaining or even increasing the provider lock-in. When
mobile end-users are concerned, traffic can be moved away from the congested mobile
access links to fixed access links when available.
Table 3. ISP SWOT analysis of “Access connection bundling” business model
• Ownership of customer access lines • Full benefits of MPTCP require offering routing
• Existing customer relationship will be functionalities
maintained
• Provider lock-in can be increased
• Revenue by access provision • Possible visibility of bad performance of
• Warranty of reliably throughput can be charged individual paths may lead to complaints and loss
• Part of the load on congested mobile access links of customers
can be moved to fixed links when available • Customers unlikely to be willing to pay double
price for dual access
4.3. Virtual multipath operator (enabled by Scenario 3)
We also see the potential of a new type of service provider, Virtual Multipath Operator
(VMPO), entering the ISP market. VMPO will provide multipath access to end-users
by bundling and reselling access products of other ISPs. The VMPO is not in the
possession of its own IP access or backbone network. However, an ISP may also
decide to act as a VMPO through a separate business unit.
Even though a VMPO can be involved in all deployment scenarios, it suits most
naturally Scenario 3 where it can remove end-users’ burden of multiple contracts while
offering all the benefits of full multihoming. The simplified value network is presented
below in Figure 5.
ISP1
VMPO
ISP2
Figure 5. Value network of VMPO business model in the deployment scenario 3.

It is likely that a VMPO could negotiate significantly reduced price deals with the
ISPs by purchasing access provisioning in bulk, as well as eliminating the ISP’s costly
interactions with the end-user. This scenario opens an additional, though indirect, sales
channel for the ISP to the MPTCP user market, without having to put additional
technical changes to its infrastructure. The main disadvantages for the ISP is that it has
no direct customer relationship and it will be under price pressure from the VMPO. The
power of the VMPO will depend on the development of the market. Will ISPs address
the multipath market themselves by other presented business models? Or will VMPOs
be the first innovators and have a unique selling proposition for a long time?
Table 4. ISP SWOT analysis of “VMPO” business model
• Ownership of at least one customer access line • Loss of direct customer relationship
• ISP is in a good position for becoming a VMPO • Limited control over throughput allocation
player itself between two independent links
• Inability to provide multipath without
involvement of a second access ISP
• Revenue by wholesale access provision in • Because of visibility of network performance
addition to direct sale the VMPO can compare ISPs and terminate the
contract with a bad performing ISP
• VMPO may put pressure on wholesale access
pricing, and could control a large customer base
5. Conclusion
Although MPTCP is a relatively small technical change to the TCP protocol, it will
have considerable impact on the business models of Internet access provisioning. The
direction of the impact will depend on the way end-users choose to set up their access
links. Different deployment scenarios suit different types of end-users and the possible
market pull depends on how much each group value the benefits of MPTCP.
Consequently, introducing MPTCP is most feasible in the scenarios which offer
additional incentives to end-users or where multihoming capability exists already for
other reasons.
Even though the ISPs are not required to have any technical involvement to deploy
MPTCP, they can support the deployment in all the scenarios, for example, by offering
MPTCP as a value added service or introducing multihoming through attractive access
connection bundles. Additionally, a virtual multipath operator, a new type of market
player, can offer the maximized MPTCP benefits to end-users without the burden of
multiple contracts. In the end, the success of these business models depends on the end-
users’ willingness to pay for the benefits they offer.
References
[1] D. Wischik, M. Handley, and M. Bagnulo Braun, The Resource Pooling Principle, ACM SIGCOMM
CCR, volume 58, issue 5, (October 2008), 47–52.
[2] A. Ford and C. Raiciu, TCP Extensions for Multipath Operation with Multiple Addresses, IETF Internet-
Draft (work in progress), draft-ford-mptcp-multiaddressed, (July 2009).
[3] C. Raiciu, M. Handley, and D. Wischik, Coupled Multipath-Aware Congestion Control, IETF Internet-
Draft (work in progress), draft-raiciu-mptcp-congestion-00 (October 2009).
[4] Multipath TCP BOF, http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription, (June 2009).
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-31
The Economics of Utility Services in the

Future Internet
Man-Sze LI 1
IC Focus, UK
Abstract. “Utility” is by no means new a new concept in ICT. At the time of

writing, the European Union is putting forward the argument to extend “universal
service” to broadband communication services. The universal service argument
may in future be extended beyond broadband to other Internet services, or services
running on top of the communications infrastructure of the Internet. This paper
considers the economic underpinnings of utility services in the Future Internet
context. It examines a number of relevant economic models and basic economic
assumptions in an attempt to answer the question: are utility services economically
viable? It identifies several key issues and spells out some implications for the
Future Internet service models on the basis of that analysis. The paper concludes
that market forces alone are unlikely to be sufficient for utility service provision in
ICT; utility service markets have the intrinsic characteristics of a monopoly. We
need new and bold economic models for the emerging and future Internet
scenarios.
Keywords. Utility services, utility, economic models, economic bases, service

markets, Future Internet
1. Introduction
Since the 1980s, basic telephony as a universal service [1] has been widely enshrined in
telecommunications legislation in US, Europe, and other parts of the world. The
attributes of a universal service in telecoms typically involve affordability, accessibility,
availability and quality. Fundamental to the universal service, which justifies its
regulation in a market economy requiring legally binding obligations of the provider
and in some cases arguments for government subsidy, is the notion that such services
are a utility. Very simply stated, a utility is essential for the basic condition of living in
society; therefore, the individual has the right to the service in question.
At the time of writing, the European Union is putting forward the argument to
extend universal service to broadband communication services, which would require
network providers to extend broadband coverage to all geographic areas of the EU,
regardless of whether it makes economic sense or not from the viewpoint of the
provider [2]. The central premise of this paper is that the universal service argument
may in future be extended beyond broadband to other Internet services, or services
running on top of the communications infrastructure of the Internet. For example, the
“Internet of Services” may be considered as a collection of utility services, on which
customer-facing and customer-centric value added services could be built. There are
1
IC Focus, 42 Clifton Road, London N8 8JA, UK; E-mail: msli@icfocus.co.uk.
32 M.-S. Li / The Economics of Utility Services in the Future Internet
several arguments to support this view, including: (a) the economic argument: ICT
trends towards commoditisation, continuously eroding the cost base of providing
services; (b) the public interest argument: some services offered over the Internet are
part of the fabric of the economy and society, essential for all businesses or for
minimum “quality of life”; (c) the competition argument: a level playing field in basic
(utility) service provisioning for advancing open competition, greater transparency and
unfettered innovation through new, value added services. Note however that these
arguments are inter-linked. For example, the commoditisation trend could be mitigated
by market rules which sanction exclusivity (monopoly) for whatever reasons; the
pricing of basic or essential services may be such that it artificially suppresses what
could have been universal demand; and an open competition model may need to be
adjusted in light of a wider set of public interests in order to protect other legitimate
concerns.
The economics of utility services are a key factor in shaping the above arguments.
The purpose of this paper is to consider the underpinning of that economics, and
provide pointers to answering the question: are utility services in principle
economically viable in the Future Internet?
For the purpose of this paper, we differentiate utility services from non-utility (i.e.
value added) services on the basis of economic properties (excludability and rivalry), as
well as the trade-off between cost and functionality, as shown in Figure 1.
High
Cost / Added Value

Exclusivity
Value Added Services
Low Volume
High Margin
Utility Services
High Volume
Low Margin
High
Nil / Low Functionality /
Rivalry
Figure 1. Classification of Utility Services and Value Added Services (Source: Li [3])
We adopt the characterisation of utility services as put forward by Michael Rappa:

necessity, reliability, usability, utilisation, scalability and exclusivity [4]. But unlike
Rappa, who considers utility services in the context of business models for future
computing services, we consider those services in the context of economic models for
future Internet-based services.
M.-S. Li / The Economics of Utility Services in the Future Internet 33
2. Economic Models for Utility
In classical economics, the doctrine of utilitarianism prescribes the maximisation of

utility as a moral criterion for the organisation of society 2 . Morality aside, a key
concern about the provision of universal or utility services is whether market efficiency
alone can produce the optimal utility from the standpoint of society, while ensuring that
rights are fulfilled as in “nobody is left behind”. For example, there may not be
sufficient economic incentives for the provider to provide for adequate availability, to
provide access to all, to hold the price down, and/or to meet certain criteria for quality.
In more recent decades, new economic models have been proposed in an attempt
to take account of the changing nature of firms and their processes of value creation,
the shift from a production-oriented to a service-oriented economy, intangibles as a
new factor of production, as well as new markets and market conditions enabled by the
Internet. In the following, we give a snapshot of the range of economic models that are
available by focusing on three contrasting varieties: the market efficiency model, the
value chain model, and the network economics model.
2.1. Economic Model based on Efficiency
Let us briefly examine whether the market efficiency model could provide a sound
economic basis for utility services. That model is based on Adam Smith’s notion of the
competitive market as a social mechanism for regulating the economy – the market is
an invisible hand leading the participants; by pursuing own interest, a market
participant promotes the interest of society more effectually than when he really intends
to promote it [5]. The invisible hand of competitive markets generates a level of total
economic product that is as high as possible. A competitive market therefore is also an
efficient market in allocating resources, particularly by balancing supply and demand
through the pricing mechanism. Such a market produces the “best” price by rationing
demand and eliciting supply. On the demand side, anyone unwilling to pay the market
price does not get the good or service. On the supply side, any organisation that can
make a good or provide a service for less than the market price has a powerful financial
incentive to do so. Supply and demand are perfectly balanced. In economics, such
markets are sometimes described as Pareto efficient or optimal. Moreover, as the
economic pie grows larger, everyone can have a larger slice 3 .
Even before the latest global financial crisis, the efficient markets model has been
one of the most contested models among social scientists. Already observed by Paul
Samuelson, generally considered a founding father of modern economics, more than 40
years ago [7], in an "informationally" efficient market (a key basis for open competitive
markets), price changes must be unforecastable if they fully incorporate the information
and expectations of all market participants. Some more recent scholarship goes further
by suggesting that in the most efficient market of all, where prices fully reflect all
available information, price changes are completely random and unpredictable [8]. In
other words, the efficiency argument should at the very least be decoupled from the
2
This could entail, e.g., the greatest benefit for the greatest number (Jeremy Bentham and John Stuart
Mill), the greatest benefit for the least advantaged (John Rawls), or just the greatest benefit (Derek Parfit).
Other theorists focus on the starting position, rather than the outcome, as in free exchange from a just starting
position (Robert Nozick), which also echoes Rawls’ supplementary view of fair equality of opportunity.
3
Some economists have formalised this into The Efficiency Principle, and moreover attribute this principle
as an important social goal in its own right, see, for example [6].
pricing argument. With completely indeterminate future prices and no reliable means of
forecast, the financial incentives for firms to organise and adjust outputs in accordance
with expected demand as reflected in price are no longer available. More
fundamentally, the principle of supply and demand of traditional economics - where the
intersection of the supply and demand curves determines an “equilibrium” of price and
quantity that satisfies both producers and consumers - is put into question. On this
reading, contrary to conventional wisdom, an “Internet economy” which rests on
greater transparency of information does not produce a more friction-free economy by
better communications between the market actors. The opposite is closer to reality.
Debates such as those in the area of Net Neutrality provide one illustration of such
opposing views.
2.2. Economic Model based on Value Chain
The value chain concept, developed by Michael Porter [9], provides an analytical
framework to investigate value creation at the firm level. The value chain depicts major
segments of the business that contribute to the lifecycle of a product to deliver value to
a customer. Business functions - such as human resource management, finance and
accounting - are depicted as supporting services since they do not contribute directly to
the production of customer value.
Central to value chains is the concept of Margin - the difference between total
value and the collective cost of performing the value activities. Each value producing
activity can be associated with a Competitive Differentiator which is a characteristic of
the product or service. The Competitive Differentiator is a Margin for which the
organisation has a relative advantage compared to other organisations which produce a
competitive product or service. These values are in turn related to a particular
Competitive Strategy of which Porter identifies three generic versions: Cost
Leaderships, Differentiation and Focus. These strategies are derived from five forces
which drive a competitive situation for any given industry: threat of new entrants,
threat of substitute products and services, bargaining power of suppliers, bargaining
power of customers, and rivalry among existing firms.
Intuitively, the concept of Margin could be applied to ascertain the added value of
business functions and services of a firm, and value chain comparison could help with
distilling what is common and necessary (the utility) for businesses to enable and
produce value. However, the value chain analysis provides no guidance as to how value
is created and no specific insight into how competitive forces and external factors may
impact on a firm’s capabilities, its resource allocation and function re-organisation.
Instead, it is assumed that certain business functions would create value and, further,
those business functions are fixed along a stable, immutable value chain. Firms are
static structures organised around such chains. These chains are combined into a
similarly structured as well as static value system comprising complementary value
chains (of surrounding business partners) within the context of producing a particular
product. Technology, including the Internet 4 , does not detract from such principles.
Value is measured by total revenue. True economic value, measured by sustained
4
Which Porter views as just another technology development: “But for all its power, the Internet does
not represent a break from the past; rather, it is the latest stage in the ongoing evolution of information
technology”; the Internet architecture is comparable with “complementary technological advances such as
scanning, object-oriented programming, relational databases, and wireless communications” [10].
profits, is the arbiter of business success. To compete, companies must operate at a

lower cost and/or command a premium price, either through operational effectiveness
or by bringing something different to customers.
Overall, the value chain analysis is more applicable to production-oriented than
service-oriented activities, for an age when business relationships were straightforward
as well as relatively fixed, and for an economic context based solely on a simple
pricing model derived from the cost of production. Porter’s Value Chains reflect only
the internals of a single organisation. The externals of that organisation are seen purely
in terms of the acquisition of competitive advantage. There is no “collaborative
advantage”. A utility that brings common resources to all has no place in a scheme
which in essence is concerned only with the value accretion and control flows of single
firms, within a well defined market structure predicating on fairly stable and
predictable interacting parties and forces.
2.3. Economic Model based on Networks
Network economics emerged in the 1980s when a growing number of contributions on

standards attracted the attention of economic science researchers. Researchers noticed
that firms in the information economy often face highly competitive markets with
volatile market shares and the threat of new or established entrants with superior
technology, in contrast with firms in the old industrial economy often dominated by
oligopolistic markets with quite stable market shares [11]. The central concept of
network economics is positive feedback - the overall value of a network as well as the
value for the individual participant both depend on the number of other participants in
the same network [12]. As a consequence, networks are dependent on the expectations
of potential customers, with the demand side predominantly driving the market
dynamics. These network effects introduce a new form of externalities in economics,
sometimes called network externalities or demand-side economies of scale. In contrast
with traditional economics, the average demand increases with scale and then tapers
off. Also, a network good is by definition an intangible based on ICT services - its
supply therefore is in principle perfectly elastic. This demand and supply situation is
illustrated in Figure 2.
Figure 2. Demand and Supply for a Network Good (adapted from Varian et al, [13])
Another important insight of network economics is the central role of critical mass.
Unlike conventional supply and demand, there are three equilibriums: the two outer
equilibriums are stable and the middle equilibrium (representing the critical mass) is
unstable. If the product does not reach this critical mass, the network size is likely to
fall back to the zero equilibrium. But if the network size surpasses the critical point,
positive feedback unfolds its strength and leads the network good to success [13]. The
crucial determinant is the relationship between critical mass, which is based on the
number of participants, and the network subscriber’s willingness to pay.
In practice, a network good rarely exists in isolation from other complementary
goods, which also have a direct input to how critical mass is achieved - the demand for
the basic good depends on the price of both the basic good and the complementary
good. According to Varian et al, there are five possibilities to improve the vendor’s
situation:
x Integrate: One of the vendors acquires the other to internalise the external
effects
x Collaborate: The firms negotiate a revenue sharing arrangement so that one of
them sets the price for the whole system
x Negotiate: Both firms can agree on cutting their prices which could ensure the
adoption of the complementary goods
x Nurture: One firm cooperates with other firms outside their industry to reduce
costs
x Commoditise: One firm attempts to motivate competition in the
complementor’s market by pushing down the price of the basic good.
Researchers also observe that there are complex relationships between critical
mass, cost/pricing and vendor strategies on the one side, and market dynamics on the
other. An assessment by Mayer [14] suggests that network markets have five major
characteristics, which set them apart from the traditional production-based markets of
physical goods. Compared with the latter, network markets are subject to a much
higher degree of instability, inertia, as well as excessive momentum. These arise
because of the complex and rapid feed-back between what is on offer by the supplier
and what is expected by the (would be) customer. Network markets are not only highly
volatile, they are also considerably more difficult to conquer. But the impression of
open competition is deceptive. Network markets which reach a critical mass have a
monopolistic tendency by virtue of control over the network, as opposed to control
exercised through a specific good. In other words, compared with traditional markets,
lock-in is a lot more insidious and subtle, leading to Pareto-inferior market results.
Such measures may include standardisation 5 , artificial pricing, “dumping” and product
bundling. It has also been observed that in network economics under increasing returns,
there is no rule to stop market penetration like marginal costs equal marginal benefits
[15].
Network economics provides a useful conceptual basis for assessing the economic
viability of utility services. The principal hypotheses are:
x The network effect of utility services could, over time, provide compensation
for the initial investment
5
It should be borne in mind that standards and standardisation may constitute a barrier to innovation,
depending on the participants’ motivation, the mechanisms involved, the IPR policy etc. Not all standards are
“open”.
x The market dynamics of utility services are crucial for the success and
sustainability of such a market; there are in principle measures available to
steer the dynamics in a certain direction
x Strategies for provisioning of utility services need to be complemented by
strategies for “complementary products”, i.e. value added services
x Networked economics may however cause utility services markets to generate
various negative effects, including Pareto inferiority and lock-in
x The inherent instability of a utility services market is a critical issue,
regardless of business prospects.
However, networked economics does not by itself offer the conceptual tool for
creating the initial valuation model of utility services. Additionally, the high probability
of abrupt and total market collapse, due to inability to reach critical mass quickly, can
be an enormous barrier to investment particularly in the start-up phase.
2.4. Other Economic Models
Granted that a function of economics is to help make choices (usually involving some
form of trade-offs), and that all economic models are rested upon assumptions which
may never exist in reality (such as perfectly competitive markets or frictionless value
chains), are there other models that might help in analysing utility services?
Our research so far suggests that other established economic models, are – similar
to the market efficiency model - equally problematic as possible models for assessing
utility services in the Future Internet context. The transaction cost economic model [16]
adopts as a starting point the efficiency market to establish price, which is shown above
to be at least unsuitable for the purpose at hand. The resource-based economic model
[17] focuses on complementarity of capabilities of firms, which could be useful only
after the economics of utility (and therefore also the capabilities conferred upon by
those utilities) becomes more firmly grounded. The economic model based on
coordination theory [18] could be useful for analysing the interrelation and
dependencies between the different services in question, but it contributes little towards
the economic foundation for those services. The latest innovation economics 6 holds out
promises. Its narrative of economic growth based on innovation could potentially be
applied to utility services, and offer new arguments, accounting techniques and value
metrics for the “innovation potential” facilitated by those services. However,
innovation economics needs to provide a clear(er) framework to explain the complex
interactions between knowledge, technology, entrepreneurship, innovation and
productivity. Very specifically, innovation economics tends to favour mixed
institutional arrangements and modalities such as public-private partnership. However,
innovation cannot function in isolation of (imperfect) market logic and (imperfect)
rationality of the human agent. In short, a mix of economic insights – as opposed to a
single economic model – is almost certainly needed to analyse utility services. To
accomplish that, we need to go back to basics, i.e. the founding principles of economics.
6
Which has been variously described including in the work of Paul Romer, Elhanan Helpman, Brian
Arthur, Robert Axtell and Eric Beinhocker, to name but a few.
3. Economic Bases for Utility
As already mentioned, the notion of utility has a long history in economics. It is subject
to the scarcity principle which originally gave economics its purpose: the resources
available are limited - either by nature (as in natural resources) and/or by infrastructure
limitations (as in the power plant for energy or the network infrastructure for
telecommunications, which takes time and costs a lot to build). For all these reasons, a
utility provider traditionally enjoys considerable market power: a large degree of
control over the inputs (including the infrastructure as a capital investment) and
economies of scale for the output (increasing returns which are disproportionate to the
inputs once the infrastructure is built, and the capital outlay is compensated for over
time). Economies of scale are usually associated with “natural” monopolies; hence the
original monopolistic, national telephone companies, regardless of whether they are
state-owned. Furthermore, because the resource in question is “essential”, it cannot be
readily substituted for. In other words, its demand is not elastic – consumers cannot
switch to substitutes even when confronted with large increases in prices, or artificial
prices that not justified by the cost of provision. That has been the primary rationale for
injecting competition into a market which has the attributes of natural monopolies,
including opening up the telecommunications market with the initial anti-trust lawsuit
of the US Department of Justice filed against AT&T in 1974. Equally, the lock-in
effect, arising from an inability to switch to alternatives on the demand side, explains
why concerns about market power and competition have been a driving force for the
(de-)regulation of telecommunications.
However, as already widely noted during the dot.com era, digital services and
other information goods are not subject to the scarcity principle. In fact, the opposite is
true with regard to utility services in the Future Internet – they are inherently abundant.
That abundance is derived from the economic properties that we have used to define
utility services in the beginning of the paper: non-excludable (service consumption by
one consumer does not exclude consumption by others) and non-rivalrous (service
consumption by one consumer does not prevent simultaneous consumption by other
consumers). Without excludability, providers cannot force consumers to become
buyers, and thus to pay for what they use. It has been argued that in the absence of
excludability, the relationship between producer and consumer becomes more akin to a
gift-exchange relationship than a purchase-and-sale one [19].
However, it is unclear how a modern market which is defined by a standard way of
economic exchange (typically money) would function where the currency of exchange
is defined totally ad hoc. Moreover, if we add pro-sumption to the picture, consumers
are likely to acquire at least some bargaining power over how and what they are being
charged for, assuming that it is at all possible to devise a general model to cost-account
for who contributes what (which is highly doubtful where services can in principle
become infinitely composable and fine-grained). Without rivalry, the standard cost
structure using marginal cost to compute price begins to break down. If two or more
consumers can consume as cheaply as one, then charging per unit price artificially
restricts distribution and reduces overall economic welfare. If the marginal cost of
reproduction of the utility services (being a digital good) is near zero, then
conventional economics require that the price is similarly near zero 7 . In an open
competitive market, an influx of non-rivalrous goods may trigger what has been
7
in the absence of price fixing or other anti-competitive practices such as collusion among providers.
described as a “race to the bottom” [20], which is hardly an attribute for ensuring stable,
uninterrupted service provision. Such markets are unlikely to be sustainable.
4. Issues and Conclusion: Implications for Future Internet Service Markets
Up to now, ICTs are generally modelled or measured in terms of the cost and benefit of
connectivity; issues of engagement and inclusion are understood primarily in terms of
barrier to access. But the technology perspective applies only imperfectly to the
Internet, which is as much a socio-economic construct as a specific set of technologies,
services and applications. That said, our research suggests that the established
economic models and assumptions are not particularly helpful in providing the
conceptual basis for utility services. Other than crude cost-based calculations, and
drawing on connectivity investment profiles of the telecoms industry, it remains
unclear how the economic viability of utility services can be assessed in any
meaningful or systematic way. It would be tempting to adopt a particular business
model of say, Google, eBay or Amazon, deduce from that some economic baselines or
even equations, and then build a case for a set of capex-opex-revenue-profit forecasts.
Not only would such an exercise be highly arbitrary, it would also detract from
deepening our understanding of the value that utility services may bring.
Our analysis so far suggests that the pricing model based on the supply and
demand model of market economy is unlikely to work for utility service provision in a
Future Internet scenario. Market mechanisms alone do not provide sufficient economic
incentives for market agents to become providers of utility services only, within a
timeframe acceptable to commercial operators, or for market agents to remain in
business if the pricing model is simply based on cost.
Unless there is a reform of market rules and/or an alternative to pure market
arrangements (e.g. public private partnership), the analysis suggests that:
x Utility services will need to be bundled in some manner with value added
services
x Market agents will always tend to defend market barriers in order to prevent a
truly competitive market that drives down price
x The race to the bottom favours market staying power and larger and therefore
also incumbent actors who can afford price subsidy between a portfolio of
mixed service offerings till the challengers are squeezed out
x Utility service markets have the intrinsic characteristics of a monopoly;
competition in the conventional sense will not be applicable to such a market,
nor will competition be sustainable even if “artificially” imposed
x Market consolidation in the services market will continue and the utility
service markets are likely to be dominated by a handful of organisations over
time; there is a question about whether commercial interest on its own would
be sufficient for ensuring good governance of such markets.
The analysis shows that networked economics could potentially provide a
conceptual underpinning to assess the economic viability of utility services; with the
economic viability critically hinging upon the confidence of would-be customers in
those services. However, economics is a guide for making choices, it is not a substitute
for policy decisions. Specifically, networked economics is not a magic wand to
mitigate potentially negative or harmful market effects.
The research indicated in this paper is work in progress. A more formal model to
structure the main findings presented above is being developed. We will also be
seeking to apply the model to sample business cases in the ICT landscape, including
the collection of quantitative data to validate the model.
Acknowledgement: The paper is mainly based on work performed in the project

COIN (EU FP7 Project 216256; www.coin-ip.eu) funded by the European Commission
within the FP7 ICT Programme. It is work in progress. As such, it does not necessarily
represent the view of the COIN Project. The author thanks other partners of COIN for
the relevant discussions, as well as Claudia Guglielmina of TXT and colleagues at VTT
for logistic support in connection with the preparation of this paper.
References
[1] US Communications Act of 1934 and its update in US Telecommunications Act of 1996.
[2] EU Telecoms Reform Package, Official Journal of the European Union, L337, Volume 52, 18 December
2009.
[3] M-S Li, Meeting the Grand Challenges of the Enterprise Interoperability Research Roadmap – a Business
Perspective. In: Expanding the Knowledge Economy: Issues, Applications, Case Studies, Paul
Cunningham and Miriam Cunningham (Eds.), IOS Press, Amsterdam, 2007.
[4] M.A. Rappa, The utility business model and the future of computing services, IBM Systems Journal, Vol
43, No 1, 2004.
[5] Adam Smith, The Wealth of Nations (London:1776), Cannan edition, p.423.
[6] R.H. Frank and B.S. Bernanke, Principles of Economics, Third Edition, McGraw-Hill, New York: 2007.
[7] P. Samuelson, Proof that Properly Anticipated Prices Fluctuate Randomly, Industrial Management
Review 6 (1965), p.41-49.
[8] A. W. Lo, The Adaptive Market Hypothesis, The Journal of Portfolio Management, 30th Anniversary
Issue, 2004.
[9] M.E. Porter, Competitive Advantage: Creating and Sustaining Superior Performance, New York: Free
Press, 1985.
[10] M.E. Porter, Strategy and the Internet, Harvard Business Review, March 2001 edition.
[11] J.H. Rohlfs, Bandwagon Effects in High Technology Industries, Cambridge, Mass: MIT Press, 2001.
[12] C. Shapiro and H.R. Varian, Information Rules - A Strategic Guide to the Network Economy, Boston:
Harvard Business School Press, 1998.
[13] H.R. Varian, J. Farrell, C. Shapiro, The Economics of Information Technology – An Introduction,
Cambridge University Press, 2004.
[14] P. Mayer, Economic Theories of Interoperability, 2006. A working document of the FP6/IST ATHENA
Project.
[15] W.B. Arthur, Increasing returns and the new World of business, Harvard Business Review, 74 (July-
August 1996), pp. 100-109.
[16] R.H. Coase, The Nature of the Firm, Economic (1937) pp. 386-405.
[17] M.A. Peteraf, The Cornerstones of Competitive Advantage: A Resource-Based View, Strategic
Management Journal 3 (1993) p.179-191.
[18] T. Malone and K. Crowston, The Interdisciplinary Study of Coordination, ACM Computing Surveys 1
(1994) p.87-119.
[19] G. Akerlof, An Economic Theorist’s Book of Tales, Berkeley: University of California Press, 1985.
[20] C. Andersen, Free: The Future of a Radical Price, Hyperion, 2009.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-41
Towards Security Climate Forecasts1

Stephan NEUHAUS 2 and Fabio MASSACCI
Università degli Studi di Trento, Trento, Italy
Abstract. The complexity and interdependencies of deployed software systems has

grown to the point where we can no longer make confident predictions about the
security properties of those systems from first principles alone. Also, it is very com-
plex to state correctly all relevant assumptions that underlie proofs of security, so
that attackers constantly seek to undermine these assumptions. Complexity metrics
generally do not correlate with vulnerabilities and security best practices are usu-
ally founded on anecdotes rather than empirical data. In this paper, we argue that
we will therefore need to embrace empirical methods from other sciences that also
face this problem, such as physics, meteorology, or medicine. Building on previous
promising work, we suggest a system that can deliver security forecasts just like
climate forecasts.
Keywords. Large System Security, Empirical research, Climate forecasts
Introduction
Software systems have become so complex that we can no longer effectively understand
the behaviour of the entire system from the behaviour of its smallest parts alone: in order
to find out about the security of a complex system, it is no longer sufficient to know
the precise semantics of an if or while statement. This is not because such knowledge
is useless, but rather because the amount of interaction between program statements,
interpreters, compilers, libraries, operating systems and the run-time environment creates
an explosion in interconnection that makes predicting system behaviour uncertain at best
and impossible at worst. This situation is worsening as we progress towards the Future
Internet, where applications will consist of large numbers of interacting components,
written by different organisations according to different development standards.
Physicists face a similar problem when asked to describe the behaviour of an ideal
gas: from Newtonian mechanics, it should be possible to compute the temperature or
pressure of a gas by calculating the movements of individual gas moecules, but in prac-
tice there are so many that this is impossible. Thus, high-level gas laws describing the
behaviour of a gas as a whole were invented. In a similar way, medical researchers and
meteorologists use models based on differential equations to forecast the spread of in-
fectious diseases and to make climate forecasts, respectively.
We propose to use a similar approach, where we no longer infer the macroscopic be-
haviour of a system from properties of its microscopic constituents such as library com-
1 Research supported by the EU under the project EU-IST-IP-MASTER (FP7-216917)
2 Corresponding author
42 S. Neuhaus and F. Massacci / Towards Security Climate Forecasts
ponents, programming language statements or even machine instructions, but where we

make statistical predictions about the system’s behaviour from simpler, higher-level met-
rics. Note that our point is not that it is only complexity, as understood by software engi-
neers and expressed in complexity metrics, that is causing the inability to predict system
behaviour. If that were the case, adding more computing power would make predictions
possible again. Rather, it is that causes and effects of vulnerabilities are non-local (i.e.,
can occur at widely separated points in the same source code, in different source codes,
between code in one system and code in a library, in the interaction between some code
and the operating system, etc.) and are hence not accessible to source code complexity
metrics. Vulnerability is a systemic issue.
In the rest of this paper, we will first show case studies of two very large and widely
deployed software systems (Section 1) in order to make the point that the sheer size of
software makes it important to make reasonably precise predictions about the location of
vulnerabilities: otherwise, quality assurance teams won’t know where to look. Next, we
briefly review the state of the art in software security (Section 2), and then propose our
solution to the problems that we identified (Section 3). We finish with the outline of a
research program that could address these points, and conclude (Section 4).
1. Case Studies
1.1. Mozilla
Mozilla3 is a large software system: As of 4 January 2007, Mozilla contained 1,799

directories and 13,111 C/C++ files, which can be combined into 10,452 components,
which are files whose names only differ in their suffixes. These files have a large degree
of interconnection: there are over ten thousand unique #include statements, and over
ninety thousand unique function calls. At the same time, the Mozilla Foundation has
published 134 Mozilla Foundation Security Advisories (MFSAs), which caused 302 bug
reports. Of all 10,452 components, 424 or 4.05% were found to be vulnerable. [16]
Studies by Shin and Williams [19] have looked at a particularly vulnerability-ridden
part of Mozilla: the JavaScript engine. JavaScript is a way to execute code from within
Web pages; it is executed inside a sandbox, which regulates all access attempts by the
JavaScript program to the outside world. Still, attacks using JavaScript have shown an
remarkable ability to break out of their sandboxes into the execution environment.
Shin and Williams have looked at the correlation between code complexity metrics
and vulnerabilities inside Mozilla’s JavaScript engine and found only low correlations;
such correlations would not be enough to predict which components inside the JavaScript
engine had as yet undiscovered vulnerabilities. This supports our point, since code com-
plexity metrics operate under the assumption that vulnerabilities are local phenomena;
after all, code complexity metrics are, by definition, computed at the source code level.
Let us now put ourselves in the shoes of a Mozilla QA engineer. The new release
is days away and we have the suspicion that there are components with undetected vul-
nerabilities. Yet, even with a large staff, we cannot hope to inspect comprehensively all
10,000 components: we have to make a choice, since our QA resources are finite. Out of
3 http://www.mozilla.org/
S. Neuhaus and F. Massacci / Towards Security Climate Forecasts 43
Figure 1. Location of vulnerabilities in Mozilla source code.
those 10,000 components we can perhaps choose ten for a thorough inspection. Which
ten are going to be the lucky ones?
Going only by personal experience, we would probably tend to use the anecdotal
knowledge floating around in our QA team and look closely at those modules that already
have reported vulnerabilities and are therefore known troublemakers. How good would
such an approach be?
In our own study of Mozilla [16], we we first mapped Mozilla Foundation Secu-
rity Advisories (MFSAs) back to those source files that were fixed as a consequence of
these MFSAs. From this purely empirical approach, we got two main results. The first is
shown in Figure 1, which contains a graphical depiction of the distribution of vulnerabil-
ities in Mozilla’s source code. There, named rectangles represent directories, unnamed
rectangles represent components. The size of a rectangle is proportional to the size of
the component in bytes, and a rectangle is shaded the darker the more vulnerabilities it
has had. The JavaScript engine, the object of Shin and Williams’s study above, occu-
pies the lower left-hand corner of the picture, and it is apparent that JavaScript is indeed
vulnerability-ridden. But what can also be seen from the picture is that there are subsys-
tems that are almost as bad, such as the “layout” subsystem (above the JavaScript rectan-
gle), which is concerned with cascading style sheets and the like. Overall, the distribution
of vulnerabilities is very uneven: there are also large parts that have no vulnerabilities.
The second result is shown in Figure 2 (left). In this figure, we counted how many
MFSAs applied to a vulnerable component. The most striking feature is that there are
more than twice as many components with one fix than there are components with two
or more fixes. This is apparent from the tall spike at the left, and the subsequent series of
bars that decrease so rapidly in height that there is be no discernible height difference for
6 and 14 MFSAs. To return to our QA perspective, components with many vulnerabilities
Distribution of RHSAs
Distribution of MFSAs
600
300
500
Number of Components
Number of Packages
400
200
300
50 100
200
100
0
0
1 3 5 7 9 11 13
1 9 19 30 41 73 88 112 129
Number of MFSAs Number of RHSAs
Figure 2. The number of components versus the number of MFSAs in Mozilla (left), and distribution of Red
Har Security Advisories (right)
are rare whereas components with only one vulnerability are common. Therefore, if we
looked only at components with an established history of vulnerabilities, we would waste
effort: past history of vulnerabilities is not a good predictor for future vulnerabilities.
1.2. Red Hat
We also looked at the packages in Red Hat Linux [15]. It showed that out of a total of
3,241 packages, 1,133 or 35% had vulnerabilities reported in 1,646 Red Hat Security
Advisories (RHSAs) between January 2000 and August 2008, inclusive. Again, there is
no evidence that the developers of those packages were negligent, and again, the study
shows that most vulnerable packages have one or two vulnerabilties, so again, finding
promising candidates for QA measures will be difficult; see Figure 2 (right).
For Red Hat, the situation is even more dire than for Mozilla. Mozilla is at least
developed in a single language, C++. The packages in Red Hat, however, are deveoped in
a variety of languages. For some of these languages, like Python, general static analysis
tools do not even exist outside of research prototypes [23].
2. State of the Art
The typical answer to code security problems is usually to employ formal methods, ei-
ther as static source code analysis tools that check source code for known classes of
defects, or as proof assistant systems that allow the rigorous verification that a piece of
code conforms to its specification. Another attempt to control security problems is with
complexity metrics or with security best practices.
Static analysis tools can provide huge benefits, if properly employed: every bug they
catch and which is subsequently fixed is a bug that won’t make it into production. On the
other hand, static analysis has false positives, and therefore will sometimes flag practices
that may look insecure but which might actually be perfectly safe [4]. Combined with
the anecdotally reported tendency of managers to demand “zero defects”, but actually
meaning “zero complaints from the static analysis tool”, this may lead developers to “fix”
perfectly good code for the sake of shutting up the static analysis tool.
Another problem is that static analysis will generally only catch bugs (defined as
an “implementation-level software problem”), but not flaws (defined as “a problem at
a deeper level[, . . . ] present (or absent!) at the design level”) [10]. As static analysis
makes bugs easier to find and harder to exploit, we believe that attackers will tend to go
more after flaws. This trend is visible in the decline of the buffer overflow and the rise of
cross-site scripting and request forgery attacks [6]; also, see below.
Let us look now at proof assistant systems. They promise the freedom from bugs and
flaws by first requiring rigorous specification of the desired system behaviour, usually in
the form of some kind of formal logic, and then helping to construct a proof that shows
that the implementation fulfils the specification. The practical problems with proof assis-
tants are manifold. First, they have a steep learning curve that many software engineers
find impossible to scale [8, Chapter 4]. Second, they do not work on legacy systems like
Microsoft Windows or Linux, since they do not have a formal specification and cannot
retroactively be equipped with one. Third, proof assistants are very difficult to deploy
for very large systems. To the author’s knowledge, only one industrial-strength system
has been developed in this way, in the Verisoft project4 , and development speed has been
anecdotally reported as about one page of fully verified C code per developer per week,
even though the developers were MS and PhD students who were all highly trained in
formal logic. Development and verification of a string function library was so difficult as
to be accepted as an MS thesis [21]. Finally, even when the system is fully specified and
the implementation proven to be correct, there may still be practical attacks.
That last point is usually surprising to advocates of proof assistants, but is in reality
true of every scientific modeling, including the one we are proposing. Practical attacks
arise not because the security proof is wrong; rather, they arise because an attacker has
found a clever way to subvert the assumptions of the security proof. For example, a key
recovery attack on AES succeeded because the (explictly stated) assumption that array
accesses would take constant time was found to be wrong [1]. Proof assistants can carry
out their promise of defect-free systems only if all the relevant assumptions have been
stated and correctly stated, and that is simply very difficult to do.
Therefore, to paraphrase a point made by Brian Chess for static analysis tools [5],
having a system certified as defect-free by a proof assistant does not mean that good
design principles like defense in depth can be ignored. So one of the main benefits of
employing proof assistants—guaranteed freedom from defects—is weakened.
Now, let us look at complexity metrics. As we have already said above, the one
major study of the correlation between code complexity metrics and vulnerabilities [19]
found very weak correlations (ρ ≤ 0.21), even for a piece of code that has so many
vulnerabilities as Mozilla’s JavaScript subsystem. The only other major study that we
know of was done on five large subsystems of Microsoft Windows, to find if metrics
correlated with defects, a more general class than vulnerabilities [13]. They found that for
every subsystem there were metrics that gave weak to moderate correlations (generally,
ρ < 0.5), but that there was no single metric that would perform well for all subsystems.
Finally let us look at security best practices, which are usually coding or process
guidelines. These best practices are based on anecdotal evidence that some development
4 http://www.verisoft.de/
practice is better or worse than another, but which are not generally founded on actual
data. For example, the SANS System Administrator Security Best Practices [18] contains
such blanket statement as “know more about security of the systems you are adminis-
tering” (know more than what?), “The system console should be physically protected”
(which does not work on a laptop), or advice on user passwords that absolutely goes
against what can be expected from users [17].
At best, best practices are derived from carefully questioning practicioners and find-
ing out what works and what doesn’t, such as the Building Security In Maturity Model
(BSIMM) [11]. This approach is much more in line with what we have in mind, but has
two drawbacks. First, scientific truths cannot in general be elicited by polls and ques-
tionnaires. Second, the answers that one gets when asking people running large-scale
software security initiatives in many domains, such as finance, software and so on, will
necessarily be very general and very broad: the advice in the BSIMM is more on the
organisational side of things and probably not helpful when we need to decide which of
the ten thousand Mozilla components to examine before the next release.
3. An Empirical Approach
As we have seen in the last section, static analysis, while useful, has a number of prob-
lems, such as high rigidity, focus on bugs instead of flaws, and false positives. Proof as-
sistants can not be usefully deployed in the majority of software development projects
today due to its learning curve and system size restrictions. Metrics simply fail to cor-
relate enough to make vulnerability prediction possible, and security best practices are
unfounded or very general.
To remedy this situation, we propose a two-step program. In a first step, there would
have to be empirical studies, in order to get reliable information on the kinds and distri-
bution of real vulnerabilities in real software. This addresses the problem that security
best practices usually are not founded on actual data.
The second step (which can in fact be done concurrently with the first) would build
predictive models that predict the location of vulnerabilities, vulnerability trends, or any
other interesting vulnerability metric. The models would need to be evaluated against
real software. This addresses the problems of rigidity, focus, and correlation.
The question is, does this work? In other words, could high correlation actually
result? What about the learning curve and the sizes of systems that can be analysed in
this way? We give three examples of our own empirical work that have shown promise.
We studied Mozilla in 2007 [16] and apart from the purely empirical results we were
interested in predicting which files in Mozilla would need fixing because of unknown vul-
nerabilities. We found that imports (#include preprocessor statements) and function
calls were excellent predictors of vulnerability: show me what you import (or what func-
tions you call), and I tell you how vulnerable you are. We used a machine learning tool
to create a model that would allow us to predict how many vulnerabilities a component
ought to have. We applied the model to the about 10,000 components that had no known
vulnerabilities in January 2007, and took the top ten components. When we looked again
in July 2007, about 50 of those 10,000 components needed to be fixed because of newly
discovered vulnerabilities. Our list of ten contained five of those 50; see table 1. Random
selection would on average have produced no hits.
Table 1. Top ten Mozilla components that we predicted in January 2007 to have vulnerabilities. The compo-
nents marked ‘’ actually had vulnerabilities discovered in them between January and July 2007.
No. Component No. Component
1 js/src/jsxdrapi 6 cck/expat/xmlparse/xmlparse
2 js/src/jsscope 7 layout/xul/base/src/nsSliderFrame
3 modules/plugin/base/src/nsJSNPRuntime 8 dom/src/base/nsJSUtils
4 js/src/jsatom 9 layout/tables/nsTableRowFrame
5 js/src/jsdate 10 layout/base/nsFrameManager
Precision versus Recall

0.9
● SVM
●● ● ● Decision Tree
●● ●
● ●●●●●●● ●
●● ●●●●
●
● ● ●● ●●
●●●
●●
● ●
●● ●●●●
0.8
● ● ●
0.7
Precision
0.6 0.5
0.4
0.4 0.5 0.6 0.7 0.8 0.9

Recall
Figure 3. Performance of two different machine learning methods when predicting vulnerable packages in
Red Hat. Good predictors have high x and y values, so better methods have symbols more to the top right.
Similarly, we studied Red Hat Linux and vulnerabilities in its packages [15]. Using
techniques such as Formal Concept Analysis we were able to identify packages with
a high risk of containing unidentified vulnerabilities. We also found that we could use
machine learning again to extend the results from Mozilla: show me on which packages
you depend and I tell you how vulnerable you are. Results for two different machine
learning methods are shown in Figure 3. In this picture, a better prediction method will
have symbols that are located higher and more to the right than an inferior method. What
can be seen from this picture is that different methods have different prediction power.
We will return to this point later. Finally, just as with Mozilla, we used the regression
model to prepare a list of packages that we predicted would develop vulnerabilities.
Out of the top 25 packages, nine actually were fixed within six months of making the
prediction; see Table 2. Again, random selection would have produced no hits.
Both systems are very large, yet building models was very fast: for Mozilla, bulding
a complete regression model took less than two minutes on a MacBook. For Red Hat,
building a model was even faster. Both approaches give information that is easy to un-
derstand (“Package/Source File x likely contains unknown vulnerabilities”) and that do
not require one to scale a learning curve.
For a completely different example, we looked at the database of Common Vulner-
abilities and Exposures (CVE) [12] with the goal of automatically finding vulnerability
trends [14]. We used topic models [9,3,22,2] on the entire corpus of the CVE entries and
Table 2. Top 25 predicted Red Hat packages. Packages marked ‘’ actually had vulnerabilities.
No. Package No. Package
#1 mod_php #13 dovecot

#2 php-dbg #14 kde2-compat
#3 php-dbg-server #15 gq
#4 perl-DBD-Pg #16 vorbis-tools
#5 kudzu #17 k3b
#6 irda-utils #18 taskjuggler
#7 hpoj #19 ddd
#8 libbdevid-python #20 tora
#9 mrtg #21 libpurple
#10 evolution28-evolution-data-server #22 libwvstreams
#11 lilo #23 pidgin
#12 ckermit #24 linuxwacom
#25 policycoreutils-newrole
found a number of prevalent topics. Figure 4 shows our main results. The x axes show
the year from 2000 to 2008, inclusive. The y axis shows the relative frequency of the
topic: if the value is 0.1, this means that 10% of all CVE entries in that year were about
this topic. All topics are shown using the same y axis to facilitate comparison. What we
can see from that figure is that SQL injection, cross-site scripting and cross-site request
forgery are all on the rise since 2000, whereas insecure defaults and buffer overflows are
on the decline since 2000. An earlier publication [6] comes to a different conclusion with
respect to cross-site request forgery, but from analysing this data, we agree with Jeremiah
Grossman, who has called cross-site request forgery a “sleeping giant” [7]. Interestingly,
there are also some topics to which we could not assign suitable names, so these might be
examples of as yet unknown trends. Again, the data set is very large: the CVE contains
data as far back as 1988. And again, the information we extract is easy to understand
(“Vulnerability type x is rising/falling”).
4. Research Program and Conclusion
Building on the successes of the above programs in order to produce climate forecasts
for security would involve two distinct steps:
Data Sets. There is no scarcity of vulnerability information. Still, it is often very diffi-
cult to compare research that was done using different data sets, even when such research
is topically close. This is because different data sets such as Mozilla and Red Hat vulner-
ability data are maintained for different purposes and are often of different quality levels.
Data sets such as the CVE cannot even be said to be internally consistent with respect to
quality, since many people can make entries. This leads to an enormous spread in entry
quality, ranging from almost useless entries to complete descriptions of a vulnerability’s
cause and its remedy. However, comparability of data sets is highly desirable, since it is
otherwise impossible to consistently apply and rank different prediction methods.
Therefore, data sets will have to be analysed with the goal of finding good indicators
of their quality, and of finding ways to make them comparable. Perhaps standards can be
Topics
Arbitrary Code Buffer Overflow Cross−Site Request Forgery Cross−Site Scripting
0.10 0.10 0.10 0.10
0.00 0.00 0.00 0.00

Format String Insecure Defaults Link Resolution PHP
0.10 0.10 0.10 0.10
0.00 0.00 0.00 0.00

Privilege Escalation Resource Management SQL Injection 2000 2004 2008
Year
0.10 0.10 0.10
0.00 0.00 0.00

2000 2004 2008 2000 2004 2008 2000 2004 2008
Year Year Year
Figure 4. Relative frequency of some topics identified by topic modelling the CVE corpus.
devised that would ensure comparability of results on different data sets that were done
using the same methods. It would also be possible to develop benchmark data sets on
which researchers and practicioners can try out their methods.
Prediction Models. The two studies on Mozilla and Red Hat have shown that it is possi-
ble to construct high-precision forecasts on vulnerability locations. However, the predic-
tor (imports, function calls or package dependencies) was not arrived at by a systematic
process. Therefore, other models would need to be developed that predict vulnerabilities
in different dimensions, such as:
• granularity (method, file, package, . . . );
• predictors (dependencies, developers, complexity metrics [19], day-of-work of
committing the source code [20], . . . );
• degree of interaction: does reacting to the predictions coming out of the model
improve security, and how do predictors change when such interaction is done?
• robust trend analysis: can we predict whether classes of vulnerabilities will be-
come more or less prevalent, and can we find as yet unknown trends in data?
These models need to be applied to wide ranges of data in order to see where they
work and where they don’t. At the end of this process, we would ideally understand how
vulnerabilities appear in software and therefore arrive at a theory that would allow us to
make predictions just like climate forecasts.
To conclude, building on previous successful work in predicting vulnerabilities in large
software systems, we proposed a system which could produce high-precision climate
forecast-like security predictions. Such a system would deal with the following undesir-
able properties of conventional approaches:
• It would be based on real data, not on anecdotal evidence.
• It would be as project-specific as need be, not constrained by built-in rules of
what is unsafe programming and what is not.
• Its results would be actionable.

• It could handle projects of any size.
• It could be used on legacy projects.
• It would have a comparatively flat learning curve.
References
[1] Dan Bernstein. Cache-timing attacks on AES. http://cr.yp.to/papers.html\
#cachetiming, 2004.
[2] David Blei and Jon McAuliffe. Supervised topic models. In J.C. Platt, D. Koller, Y. Singer, and
S. Roweis, editors, Advances in Neural Information Processing Systems 20, pages 121–128, Cambridge,
MA, 2008. MIT Press.
[3] David M. Blei and John D. Lafferty. Dynamic topic models. In ICML ’06: Proceedings of the 23rd
international conference on Machine learning, pages 113–120, New York, NY, USA, 2006. ACM.
[4] William R. Bush, Jonathan D. Pincus, and David J. Sielaff. A static analyzer for finding dynamic
programming errors. Software Practice and Experience, 30(7):775–802, 2000.
[5] Brian Chess and Gary McGraw. Static analysis for security. IEEE Security and Privacy, 2(6):76–79,
2004.
[6] Steven M. Christey and Robert A. Martin. Vulnerability type distributions in CVE. http://cwe.
mitre.org/documents/vuln-trends/index.html, May 2007.
[7] Jeremiah Grossman. CSRF, the sleeping giant. http://jeremiahgrossman.blogspot.com/
2006/09/csrf-sleeping-giant.html, September 2006.
[8] Peter Gutmann. Cryptographic Security Architecture. Springer Verlag, October 2003.
[9] David Hall, Daniel Jurafsky, and Christopher Manning. Studying the history of ideas using topic mod-
els. In Proceedings from the EMNLP 2008: Conference on Empirical Me thods in Natural Language
Processing, pages 363–371, October 2008.
[10] Gary McGraw. Software Security: Building Security In. Addison-Wesley, February 2006.
[11] Gary McGraw, Brian Chess, and Sammy Migues. Building Security In Maturity Model v 1.5 (Europe
Edition). Fortify, Inc., and Cigital, Inc., 2009.
[12] MITRE. Common vulnerabilities and exposures. http://cve.mitre.org/, September 2009.
[13] Nachiappan Nagappan, Thomas Ball, and Andreas Zeller. Mining metrics to predict component failures.
In 27th International Conference on Software Engineering, May 2005.
[14] Stephan Neuhaus. CVE trend forecasting with topic models. Technical report, Università degli Studi di
Trento, September 2009. to appear.
[15] Stephan Neuhaus and Thomas Zimmermann. The beauty and the beast: Vulnerabilities in Red Hat’s
packages. In Proceedings of the 2009 Usenix Annual Technical Conference, Berkeley, CA, USA, July
2009. USENIX Association, USENIX Association.
[16] Stephan Neuhaus, Thomas Zimmermann, Christian Holler, and Andreas Zeller. Predicting vulnerable
software components. In Proceedings of the 14th ACM Conference on Computer and Communications
Security (CCS), New York, New York, USA, October 2007. ACM Press.
[17] Shannon Riley. Password security: What users know and what they actually do. Usability News, 8(1),
2006.
[18] Harish Setty. System administrator security best practices. White paper, SANS Institute, 2001.
[19] Yonghee Shin and Laurie Williams. An empirical model to predict security vulnerabilities using code
complexity metrics. In Proc. Second Int’l. Symposium on Empirical Software Engineering and Mea-
surement (ESEM 2008), pages 315–317, 2008.
[20] Jacek Sliwerski, Thomas Zimmermann, and Andreas Zeller. Don’t program on fridays! how to locate
fix-inducing changes. In Proceedings of the 7th Workshop Software Reengineering, May 2005.
[21] Artem Starostin. Formal verification of a c-library for strings. Master’s thesis, Saarland University,
2006.
[22] Xuerui Wang and Andrew McCallum. Topics over time: a non-markov continuous-time model of topical
trends. In KDD ’06: Proceedings of the 12th ACM SIGKDD international c onference on Knowledge
discovery and data mining, pages 424–433, New York, NY, USA, 2006. ACM.
[23] Andrzej Wasylkowski. Statyczne sprawdzanie poprawności typowej programów napisanych w pythonie.
Master’s thesis, Wroclaw University, July 2005.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-51
Conceptual Design and Use Cases for a

FIRE Resource Federation Framework
Sebastian WAHLEa and Thomas MAGEDANZb and Anastasius GAVRASc
a
Fraunhofer FOKUS, Berlin, Germany
b
Technische Universität Berlin, Berlin, Germany
c
Eurescom GmbH, Heidelberg, Germany
Abstract. Projects of the Future Internet Research & Experimentation (FIRE)

initiative are building an experimental facility that shall serve the needs of Future
Internet research and development. The main design principles are virtualization
of resources and federation. Federation is a means to meet requirements from
Future Internet research that cannot be met by individual testbeds. In particular, to
support large scale experiments utilizing heterogeneous resources, a federation of
experimental facilities is needed. While several initiatives are currently
establishing large scale testbeds, the mechanisms for federating such
environments across the boundaries of administrative domains are unclear. This is
due to the lack of established and agreed federation models, methods, and
operational procedures. In this article we propose a federation model that defines
high level conceptual entities for federating resources across administrative
domains. A first prototype implementation of the functional components derived
from the model has been realized and evaluated. This is demonstrated by the
discussion of use cases that depict the flexibility of the proposed approach. The
model can guide future testbed developments and harmonize the currently
scattered efforts across several FIRE projects in order to establish an agreed
resource federation framework. This framework shall be the basis for Future
Internet research and experimentation in Europe and provide experimental facility
services to academia and industry.
Keywords. FIRE, Federation, Experimental Facility, Model, Use Case, Panlab,

Teagle, Future Internet, Experimentation, Testing
Introduction
The pace of network convergence and technology evolution has dramatically decreased
infrastructure lifetime – the time an infrastructure remains at the technology’s cutting
edge – making investments in expensive isolated and specialized infrastructures more
risky than they were already. This applies in particular to complex cross-layer and
cross-technology infrastructures. For this reason existing and future test and
experimental infrastructures increasingly endorse federation principles.
While the concept of federation can be applied to a number of fields such as
identity management, networking, or trust, in this paper we focus on the federation of
testbeds. A federation is understood to be an organization within which smaller
divisions have some internal autonomy (Oxford definition). Merriam-Webster defines
federal as: (1) formed by a compact between political units that surrender their
individual sovereignty to a central authority but retain limited residuary powers of
52 S. Wahle et al. / Conceptual Design and Use Cases for a FIRE Resource Federation Framework
government; (2) of or constituting a form of government in which power is distributed

between a central authority and a number of constituent territorial units.
This concept, clearly stemming from a political background, enables combining
infrastructural network resources and services of more than one administrative domain
which enhances significantly the utility of the infrastructures. Federation enables access
to additional resources increasing scale, or access to resources with unique properties to
enrich experiments. Furthermore, combining resources from different communities
promotes the collaboration between these and the related research groups [1].
Large research programs address both the development of new Internet
architectures and suitable experimental platforms. Examples are the NSF programs
GENI (Global Environment for Network Innovations) [2] and FIND (Future Internet
Design) [3] as well as the European FIRE initiative [4], [5]. GENI focuses on the
deployment of experimental platforms whereas FIND addresses foundational concepts
and methods for the Future Internet. In the GENI programme five competing testbed
control frameworks are under development (TIED [6],[1], PlanetLab [7], ProtoGENI
[8], ORCA [9], ORBIT [10]). In FIRE, several projects are contributing to the
experimental facility (e.g. Onelab2 [11], Federica [14], PII [12],[13]). In Asia similar
programs have been launched such as AKARI [15] in Japan. Joint Asian activities are
carried out under the APAN (Asia-Pacific Advanced Network) [16] initiative, the Asia
Future Internet Forum (AsiaFI) [18] as well as PlanetLab CJK (China, Japan, Korea), a
joint PlanetLab cooperation by China, Japan, and Korea [17]. An in-depth discussion
and comparison between the different control framework approaches for experimental
facilities has been published earlier by the authors [19].
1. FIRE Federation Model
In this section we will present the Base Model of our framework and will derive from it
different levels of “surrender”; the Central Scenario and the Distributed Scenario.
The Base Model follows the definition of federation given in the previous section
which uses the concept of surrendering individual sovereignty to a central authority.
This understanding is extended for our field to support resource federations on a par.
Figure 1. Federation model entities. Figure 2. Full surrender scenario.
Independent of the level of surrender similar functional entities must be provided

to enable cross-domain and cross-technology federation. The entities are shown in
Figure 1 and are defined below. They constitute the proposed FIRE federation model.
S. Wahle et al. / Conceptual Design and Use Cases for a FIRE Resource Federation Framework 53
Resources (r): The model abstracts from concrete resource types. A resource can
be anything that can be controlled by software. Examples are: physical and virtual
machines, software packages, dedicated hardware such as sensors and routers, as well
as abstract constructs such as for example domains, accounts, databases, and identities.
Resources may contain other (child) resources.
Domain manager (m): software that controls resources inside an administrative
domain. It exposes resource management functionalities at the border of a domain and
connects to a resource registry. Supported operations on resources are typically the
CRUD (create, read, update, delete) commands for controlling resources via a common
interface. Proper security mechanisms and policies need to be supported in order to
protect administrative domains from resource misuse.
Registry (reg): holds data records for domain resources. Registries may or may not
expose an interface to (external) setup utilities (set).
Creation / setup tool (set): resides within or outside of a domain and communicates
with domain managers and registries. Set utilities provide a user interface for the
configuration, deployment, and monitoring of virtual resource groupings.
Virtual grouping of resources (dotted rectangle): each administrative domain
enables access to a number of resources. Jointly, all administrative domains provide a
large pool of resources. Experiments usually require only a subset of the total resources
that need to be provided in a certain configuration. This subset may or may not span the
border of several domains and is here referred to as a virtual grouping.
Administrative domain (solid rectangle): is typically represented by an
organization such as a research institute and provides a collection of resources.
The Central Scenario is what we also call the full surrender scenario in Figure 2
where the resources committed from domain B can be fully controlled via domain A.
An example of the full surrender scenario is the Panlab federation [12], [26] where
all Panlab member domains allow Teagle (section 2.4), the central setup tool (set), to
control resources in their domain. It relies on a central registry where resources from all
member domains are registered. The advantage of this scenario is that resource
representations backed by centrally administered resource models and operational
procedures can be simplified. As all central solutions, this approach faces scalability,
trust, and availability issues. An implementation of this scenario is described in section
3.1.
Figure 3. Federation on a par scenario.
The Distributed Scenario is what we also call the federation on a par scenario in
Figure 3 where the participating domains allow the mutual control of resources across
the borders of their domains.
Here, the set utilities are allowed access to each other’s domain managers and
registries. This enables the full scale of resource sharing across organizational
boundaries. However, in order to achieve this, a number of agreements need to be in
place such as common resource descriptions and management interfaces. Legal and
operational procedures are more difficult to realize compared with the central scenario.
This scenario has been implemented to federate Panlab resources and resources from a
private PlanetLab installation and is described in section 3.2.
Other scenarios that implement something in between the two extreme scenarios
explained above are possible and can be applied to meet other requirements and
constraints in specific federation contexts. For example only the registries of domains
might be shared allowing users to “roam” between domains and use other domain’s
resources. Such concepts that partly reflect the flexibility of our model are discussed in
the literature under the term federated identity management. An application is allowing
network access to visiting scholars among federated universities where home
authentication credentials are used to obtain Internet access at peer institutions.
2. FIRE Resource Federation Prototype Implementation
Based on the presented model, a prototype implementation has been realized and is
currently being extended. Here we discuss the model entities (r, m, reg, etc.), their
corresponding prototype implementation, and design decisions. Figure 4 shows the
components and interfaces of the prototype and their mapping to the model entities.
Figure 4. FIRE resource federation prototype framework and mapping to the model entities.
2.1. The Resources and How to Control Them
A resource can be anything that can be controlled by software. In our prototype

implementation resources are controlled by resource adaptors (RA) that are plugged in
to the Domain Manager (DM) framework (see next subsection). RAs are implemented
following the DM framework guidelines for pluggable modules. An RA can be seen as
a device driver that supports resource specific communication on interface T2.

Examples for T2 communication are Service Provisioning Markup Language (SPML)
based messages, the Simple Network Management Protocol (SNMP), or command-line
interface (CLI) commands. Any type of resource can be supported by the DM as long
as an RA can be implemented and the configuration options can be described and
modeled so that the set and reg entities can handle them. This approach allows us to
manage heterogeneous resources that support a variety of different communication
mechanisms, reside in different layers and belong to different administrative domains.
Example resources for which RAs have been implemented are virtual machines
(network, storage, computation parameters can be controlled), software packages
(Presence Server, MySQL, DNS server, IP Multimedia Subsystem (IMS) components
such as Home Subscriber Server, Call Session Control Functions, etc.), the
interconnection component (IGW) for interconnection of domains, and abstract
constructs like system users, IMS domains, DNS domains, or database tables.
Further RAs are under development to control (i) sensors, (ii) cloud computing
resources, (iii) more advanced interconnection components such as lightpath equipment,
(iv) WiFi mesh network resources, (v) 3GPP Evolved Packet Core (EPC) for Next
Generation Mobile Networks (NGMN), (vi) monitoring systems, as well as (vii) further
software packages that are frequently needed such as mail server, messaging server,
and multimedia media software.
2.2. The Domain Manager
This subsection describes our DM prototype implementation that is mapped to the m

model entity and which has been implemented in Python and Java.
T1
Domain Manager &

NDF-RO
SPML XML RPC Fraunhofer FOKUS

Adaptor Adaptor Domain
T2
XML RPC XML RPC XML RPC XML RPC

Manager Manager Manager Manager
Software Depl. Resource HSS SNMP XEN
Adaptor Adaptor Adaptor Adaptor Adaptor
A1
Software Physical Machine Virtual Virtual Virtual
A1 HSS MachineMachine Machine
Package
Physical Machine T2 SNMP
Physical Machine Physical Machine Physical Machine
A1
Physical Machine
Figure 5. Overview of Fraunhofer FOKUS administrative domain and its domain manager framework [26].
As shown by Figure 5, the DM controls several resources in its domain. This is

enabled by several RAs, e.g. XEN adaptor, SNMP adaptor, etc. Through its modular
structure, the DM supports multiple resource provisioning schemata and languages, and
enables the incorporation of various resources and their native communication
mechanisms. For example it is possible to instantiate several virtual machines on a
physical machine and deploy software RAs on the virtual machines themselves in order
to control both the container and the actual software resource residing inside the virtual
node. Resources that already natively support a provisioning schema, such as SPML,
can be directly controlled. We call this concept that supports both pluggable resource
adaptors (SNMP, CLI, etc.) as well as pluggable provisioning schemata (SPML, XML-
RPC, etc.) Network Domain Federation Remote Objects (NDF-RO).
Generic management operations supported by the resources are exposed as REST
(Representational State Transfer) services on interface T1. This allows for a flexible
support of heterogeneous resources. Together with the management operation, an XML
document is send via T1 to the DM, carrying configuration parameters to be applied to
a specific resource.
Next steps in the DM and NDF-RO development will be the realization of a
software repository to allow different types and versions of software images to be
accessible via our control framework, as well as the incorporation of specialized
resources such as more hardware devices, sensors, wireless nodes, etc.
2.3. The Registry
The registry holds data sets related to other federation entities and is designed as an
information persistence store for Teagle (section 2.4). The structure of this information
follows a generally accepted information model to promote interoperability.
All information in the registry is model based. In particular we have defined a DM
model for storing information about registered DMs, a configuration model that
underlies the structure of each resource configuration, a reservation model to support
resource availability and scheduling, a virtual resource grouping model, as well as a
person and organization models to cater for the definition of ownerships. An
information model can also be used to manage the legal and operational aspects of
federations, such as Service Level Agreements (SLAs) and enforcement of policies. Of
particular interest is the resource information model that is necessary for managing the
large number of heterogeneous resources and services in the federation. The
information model provides the structure and the framework allowing Teagle to
catalogue, search, reserve, connect, and configure resources that shall be provisioned
within a custom experimental facility setup, which we call virtual resource grouping.
A common information model facilitates the automatic orchestration of a testbed setup
by the set entity. The DEN-ng information model [20] was re-used and is currently
being adapted to suit the FIRE resource federation framework’s requirements.
The necessary data models that are stored in the registry have been automatically
derived from the information models following a model driven architecture approach.
2.4. The Extended Creation / Setup Tool Teagle
Our prototype implementation considerably extends the set entity of the proposed
model. The functions provided by our prototype are collectively called Teagle [27].
Teagle is the central search and composition engine of our prototype implementation of
the proposed resource federation framework. It provides a web-based interface that
allows browsing through the federation’s offerings, enables the definition of virtual
resource groupings and executes the provisioning thereof. A virtual resource grouping
is an isolated network where the experimenter has direct access to the resources and
configurations provisioned by Teagle. Each experimenter operates inside its own
virtual resource grouping and has no access to other groupings. Currently, Teagle
implements the following functions (see also Figure 4):
x Registry (users, resources, configurations, as described in the previous
section)
x Creation Environment (setup and configuration of virtual resource groupings,
this is the VCT tool)
x Request Processor (validates configurations and triggers setup execution)
x Orchestration Engine (generates an executable workflow that orchestrates
services form different domains to actually provision resources for the
experimenter)
x Web Portal (exposes search, configuration interfaces, and general information)
3. Use Cases
3.1. Phosporus & HPDMnet integration
This use case demonstrates the central scenario described in section 1 where a central
set utility and a central resource registry are used to control the resources offered by
participating domains. The involved domains are part of already existing, successful
and very advanced networking testbeds: Phosporus [21] and HPDMnet [22].
Phosphorus addresses some of the key technical challenges to enable on-demand end-
to-end network services across multiple domains over high speed optical networks. It
uses the Harmony service interface. HPDMnet builds a high performance digital media
network that provides end-to-end network services across multiple domains like
Phosphorus but focuses on high bandwidth media streaming like uncompressed high-
definition video streaming. It uses the Chronos interface which is a Harmony derivative.
Figure 6. Phosporous (Harmony interface) and HPDMnet (Chronos interface) integration.
The prototype implementation allows establishing a high bandwidth network path

across the Phosphorus and HPDMnet testbeds using the central set utility Teagle. Both
testbeds can create dynamic network services modeled as Teagle resources. The use
case has been successfully implemented within 4 weeks in July 2009, demonstrating
that integrating complex existing testbeds for central federation control can be done
with reasonable efforts. We implemented RAs for the Harmony (Phosphorus) and the
Chronos (HPDMnet) interfaces and demonstrated the setting up of a path with specific
bandwidth from Canada to Spain using Teagle and its corresponding control and
federation framework.
This use case was easy to implement as no resource description or model mappings
were needed. All that was necessary were the implementation of the two RAs and the
definition of configuration parameters (start/end time of the reservation, bandwidth,
target/source IP address endpoints) as part of a virtual resource in Teagle.
Figure 7. Phosporus and HPDMnet reservations and its configuration options in Teagle.
3.2. PlanetLab & SFA or FIRE-GENI Federation
In this section we discuss the proposed federation scenario on a par. Our prototype
implements a full federation between a private PlanetLab (at Fraunhofer FOKUS
premises, domain A) and a Panlab domain (also at Fraunhofer FOKUS, domain B).
Both domains maintain their own registry services and provide a domain manager to
allow the other party to provision resources in their domain. As this has been published
earlier [23], [24] we only give a brief overview.
3.2.1. Federation Scenario

Users and administrators interact with their local creation tools (Teagle on the Panlab
side and slice manager on the PlanetLab side) to create and manage virtual resource
groupings (VCTs in Panlab terminology, slices in PlanetLab/SFA [25] terminology)
which may span both federations. The slice managers delegate look-up requests to their
local registry which will in turn query the foreign registry if necessary. Provisioning
requests are issued directly to the respective domain managers which forward these
requests to their components. The Panlab federation mechanisms have been adapted for
this scenario through the implementation of an aggregate manager module and
lightweight SFA registry to support the PlanetLab Central (PLC) and Slice-based
Facility Architecture (SFA) mechanisms.
As a proof of concept, we have chosen to realize a two-way scenario that shows

the implementation’s capabilities to provide services towards both domains of the
meta-federation:
x A researcher affiliated with PlanetLab uses his PLC credentials to access the
PlanetLab slice manager. He creates a slice and subsequently requests slivers
from a PlanetLab and a Panlab node to be part of his slice.
x A researcher uses her Panlab credentials to log into the Teagle portal and
create a new VCT (Virtual Customer Testbed), a virtual resource grouping in
terms of our model. Using the VCT tool she adds a PlanetLab node to her
testbed and additionally chooses to deploy a software package onto it.
We implemented a module, called SFAAdapter, which acts as a bridge between
the internal semantics and protocols of a Panlab domain manager (denoted as PTM in
the following) and the SFA. From the viewpoint of the SFA, this module appears just
as any other federation partner, exposing the interfaces of a registry and aggregate
manager.
Figure 8. Implementation layout; the arrows indicate the directions in which requests are issued.
Internally, the SFAAdapter comprises three parts, shown in Figure 8 as squares

inside the box labeled SFAWrapper. In detail, these elements and their duties are:
Aggregate manager (AM): This entity acts as an aggregate manager as specified by
the SFA. It will advertise the resources the PTM can provide when queried by the slice
managers of federation partners. Furthermore, it receives provisioning requests which it
will translate towards the PTM core to acquire resources.
Resource Adapter (RA): This entity acts as the counterpart to the aggregate
manager. It queries foreign aggregate managers about the resources they have to offer
and relays the information to the PTM. Subsequently, it issues provisioning requests
received from the PTM side towards other aggregate managers. Towards the PTM, it
behaves as a native RA. It is responsible for deploying PTM RAs for the acquired
resources so they can be managed by the PTM.
Registry (Reg): This module provides a registry service as specified by the SFA. It
can be queried by the PTM as well as by remote registries and provides information
about the SFA objects which this domain is responsible for. The information is
obtained from a database shared between the different parts of SFAAdapter.
The modules providing SFA interfaces (aggregate manager and SFA registry) are
based on the original SFA implementation by Princeton. This means that existing SFA
front-end clients can interact with them without modifications.
3.2.2. Proof of Concept

This subsection shows a glimpse of how a researcher could access federated services
from each side of the federation by walking through a number of steps to set up a
simple testing environment. Note that in the example shown, the output is occasionally
truncated for brevity and readability.
3.2.2.1. PlanetLab Perspective
A PlanetLab researcher wishes to use his PLC credentials to create a testbed
environment via SFA. He has already been added to the SFA registry by a PlanetLab
administrator and owns a slice (plc.fokus.s1) which, however, does not have any slivers
associated yet:
#sfi.py resources plc.fokus.s1
<RSpec ...>
<networks>
<NetSpec name="plc" .../>
</networks>
</RSpec>
Therefore, he first procures an overview over all available resources while at the
same time saving the output for later use:
#sfi.py resources –o all.rspec
<Rspec ...>
<networks>
<NetSpec name="ptm" ...>
<nodes>
<NodeSpec name=”pnode-0.ptm”>
<net_if>
<IfSpec addr="10.0.0.10" .../>
</net_if>
</NodeSpec>
</nodes>
</NetSpec>
</networks>
<networks>
<NetSpec name="plc" ...>
<nodes>
<NodeSpec name=”pln0.plc”>
<net_if>
<IfSpec addr="10.0.0.20" .../>
</net_if>
</NodeSpec>
</nodes>
</NetSpec>
</networks>
</Rspec>
From this information, he learns that he has two nodes at his disposal, pln0.plc from
the domain plc and pnode-0.ptm from the domain ptm. He adds them to his slice:
#sfi.py create plc.fokus.s1 all.rspec
The PlanetLab slice manager will now contact the PTM’s aggregate manager and
request it to instantiate a sliver on pnode-0.ptm. The PTM in turn contacts the
appropriate RA, asking it to set up a virtual node and to configure it to be PLC
compatible. To give simple access to researchers, this means installing corresponding
user credentials and configuring the sliver’s SSH server. The researcher can now access
the sliver in the same way he would access a sliver acquired from PLC:
#ssh –i .ssh/id_rsa focus_s1@pnode-0.ptm sudo su –
3.2.2.2. Panlab Perspective

The Panlab researcher mentioned in our use case opens the VCT tool via the Teagle
portal. After entering her Panlab credentials, she starts assembling a new testbed
comprising an installation of the MySQL software package on a node committed by
PlanetLab (see Figure 9). After carefully reviewing her setup, she issues the
provisioning requests. Upon receiving these, the PTM contacts the SFA resource
adapter which in turn will relay the request towards the aggregate manager of the
PlanetLab side.
Figure 10. Configuration page for a PLC

Figure 9. VCT tool view. node in Teagle.
Since a sliver must always be part of a slice, the latter must obviously exist for the
provisioning to take place. However, PTM dynamically creates those internally and
hides this detail from the user. After the sliver is created by PLC, PTM accesses it and
installs a number of resource adapters; among them the so called SoftwareAdapter
which it will subsequently use to deploy the requested MySQL package.
The researcher can now bring up the configuration page of the newly provisioned
resource to learn some of its details (Figure 10).
4. Outlook & Future Work
The power of federation and the proposed model lies in the generic way resources can
be combined, controlled, and used. One part of our future efforts will be to apply it to
more application domains such as Cloud Computing, the vertical integration of Service
Delivery Platforms, and Smart Cities. While heterogeneity can be overcome with our
approach, standardization efforts are needed. Live migration of virtual machines and
seamless service migration across administrative domains, needs to the backed, in
addition to the underlying technical concepts, by legal, business, and operational
procedures and are difficult to realize today. However, many regional data and service
providers like governmental authorities, insurance companies, power suppliers, etc.
would benefit from federating their data, infrastructure, and services to enable the
composition of new applications for the benefit of our society.
References
[1] Ted Faber, John Wroclawski, A federated experiment environment for emulab-based testbeds, Testbeds
and Research Infrastructures for the Development of Networks & Communities, International
Conference on, pp. 1-10, 2009
[2] National Science Foundation, GENI website: http://www.geni.net
[3] National Science Foundation, FIND website: http://www.nets-find.net
[4] European Commission, FIRE website: http://cordis.europa.eu/fp7/ict/fire
[5] Gavras, A., Karila, A., Fdida, S., May, M., and Potts, M. 2007. Future internet research and
experimentation: the FIRE initiative. SIGCOMM Comput. Commun. Rev. 37, 3, 89-92 (2007)
[6] Faber, T., Wroclawski, J., Lahey, K.: A DETER Federation Architecture, DETER Community Workshop
on Cyber-Security and Test (2007)
[7] Peterson, L. and Roscoe, T: The Design Principles of PlanetLab. SIGOPS Oper. Syst. Rev. 40, 1, 11-16
(2006)
[8] GENI Project Office, ProtoGENI Control Framework Overview, GENI-SE-CF-PGO-01.4 (2009)
[9] Chase, J et al.: Beyond Virtual Data Centers: Toward an Open Resource Control Architecture, Selected
Papers from the International Conference on the Virtual Computing Initiative (ACM Digital Library)
(2007)
[10] Ott, M et al.: ORBIT Testbed Software Architecture: Supporting Experiments as a Service, Proceedings
of IEEE Tridentcom 2005 (2005)
[11] OneLab project website, http://www.onelab.eu/
[12] Anastasius Gavras, Halid Hrasnica, Sebastian Wahle, David Lozano, Denis Mischler, and Spyros
Denazis. Towards the Future Internet - A European Research Perspective, chapter Control of Resources
in Pan-European Testbed Federation, pages 67 - 78. IOS Press, ISBN 978-1-60750-007-0 (2009)
[13] Website of Panlab and PII European projects, supported by the European Commission in its both
framework programmes FP6 (2001-2006) and FP7 (2007-2013): http://www.panlab.net
[14] Campanella, M.: The FEDERICA Project - A federated infrastructure for Future Internet research,
EURESCOM mess@ge, issue 2/2008 (2008)
[15] AKARI project website: http://akari-project.nict.go.jp/eng/index2.htm
[16] Asia-Pacific Advanced Network initiative website: http://www.apan.net/
[17] Maoke Chen, Sue Moon, and Akihiro Nakao. Goals and Blueprint for PlanetLab CJK. Presentation at
Conference for Future Internet 2008 PlanetLab BoF, June 19th, 2008, Seoul, Korea.
[18] Asia Future Internet Forum website: http://www.asiafi.net/
[19] Thomas Magedanz and Sebastian Wahle. Control Framework Design for Future Internet Testbeds. e &
i Elektrotechnik und Informationstechnik, 126(07/08):274-279, July 2009.
[20] Strassner J.: Policy Based Network Management. Morgan Kaufman, ISBN 1-55860-859-1
[21] S. Figuerola, N. Ciulli, M. de Leenheer, Y. Demchenko, W. Ziegler, and A. Binczewski.
PHOSPHORUS: single-step on-demand services across multi-domain networks for e-science.
DOI:10.1117/12.746371
[22] HPDMnet website, http://www.hpdmnet.net
[23] Sebastian Wahle, Thomas Magedanz, and Konrad Campowsky. Interoperability in Heterogeneous
Resource Federations. In International Conference on Testbeds and Research Infrastructures for the
Development of Networks and Communities (TRIDENTCOM 2010). ICST/Springer, 2010. To appear.
[24] Konrad Campowsky, Thomas Magedanz, and Sebastian Wahle. Resource Management in Large Scale
Experimental Facilities: Technical Approach to Federate Panlab and PlanetLab. In 12th IEEE/IFIP
Network Operations and Management Symposium (NOMS 2010). IEEE/IFIP, 2010.To appear.
[25] Peterson, L., et al. Slice Based Facility Architecture. Princeton, 2007.
[26] Sebastian Wahle, Konrad Campowsky, Bogdan Harjoc, Thomas Magedanz, and Anastasius Gavras.
"Pan-European Testbed and Experimental Facility Federation – Architecture Refinement and
Implementation." Inderscience International Journal of Communication Networks and Distributed
Systems(IJCNDS), Special Issue: Recent Advances in Test-bed Driven Networking Research. To
appear.
[27] TEAGLE portal website: http://www.fire-teagle.org
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-63
Virtual Infrastructures in Future Internet

Mauro CAMPANELLAa1, Vasilis MAGLARISb and Martin POTTSc
a
Consortium GARR, Via dei Tizii 6, 00185 Roma, Italy
a
National Technical University of Athens, Zografou, 157 80, Athens, Greece
a
Martel Consulting, Dorfstrasse 97, 3073 Gümligen, Bern, Switzerland
Abstract. Virtualization in both computer systems and network elements is

becoming increasingly part of the Internet. Apart from posing new challenges,
virtualization enables new functionalities, and hints at a future Internet architecture,
which contains a physical, but polymorphic, substrate on which various parallel
infrastructures can be created on demand. This article explores such a new
“architecture of virtual infrastructures”. The FEDERICA project and the recent
evolution trends in the National Research and Education networks are taken as
examples of this new type of network infrastructure, which is an evolution of the
classic network.
Keywords. Virtualization, networking, NREN, GÉANT, FEDERICA,

infrastructure, Future Internet architecture, IaaS, cloud computing
Introduction
Recent advances in virtualization technologies, enabled by powerful hardware in

ASICs and CPUs, have made it extremely easy to decouple the operating system from
the physical components in computers. On a single hardware platform, more than one
operating system can be active at the same time and the fairness of the sharing is
enhanced by dedicated hardware. The enabler is usually a thin software layer (e.g.
XEN[1], VMware[2], KVM[3]), which abstract the physical resources to a standard
(virtual) system. Such advances create more degrees of freedom for the end users and,
at the same time, more capabilities. The “cloud computing” [4] [5] paradigm is a clear
example of the new type of services available.
In data networks, virtualization has also been present since the beginning as a way
to decouple the physical infrastructure from the service offered and it is still subject to
research and development [6]. A single network infrastructure, like e.g. the GÉANT[7]
backbone in Europe is currently hosting many virtual networks. Network virtualization
technologies like MPLS (Multiprotocol Label Switching) and VLANS are common in
commercial networks.
At the same, the use of the Internet is evolving towards a very content-rich platform, in
which computing power and data easily accessible from everywhere are the key
elements. When virtualization technologies are added to all the basic elements, the new
Internet infrastructure becomes even more useful and efficient. It enables a more
efficient use of the physical resources through resource “slicing”, and makes the logical
topology of important functionalities (routing, monitoring, computing and storage) less
1
64 M. Campanella et al. / Virtual Infrastructures in Future Internet
dependent on the physical topology, by introducing dynamic capabilities. Such an

environment can be considered to be a polymorphic substrate capable of hosting user
equipment and able to adapt rapidly to users’ needs and events. Such an architecture
exhibits a fabric (a physical substrate) composed of computing and network elements,
each capable of virtualization.
The FEDERICA project [8][9][10] is operating an infrastructure fully based on
such an architecture as a service for Future Internet researchers and a platform for
evaluating, understanding and validating this new architecture.
In the following, section 1 summarizes the developments in the NREN networks
relevant for this article. Section 2 provides an overview of the FEDERICA architecture
and section 3 its implementation. Section 4 consider a possible architecture for virtual
infrastructures and section 5 lists challenges. Section 6 briefly compares with the cloud
computing environment and section 7 concludes the article.
1. Experience in the NRENs
The purpose of the NRENs[11] is to serve and support researchers in networking. The
users’ requirements are increasingly for services that allow communities to work
together ubiquitously, dynamically and rapidly. As a consequence, the development of
NRENs in Europe and worldwide has created a strong multidomain hybrid network
infrastructure with advanced capabilities. These networks no longer provide to the
users just IPv4 and IPv6 connectivity, but are also capable of creating many “virtual”,
parallel, infrastructure for the users on the same physical footprint. Such infrastructures
are enabling better or novel uses of dedicated facilities, such as radio telescopes, large
particle colliders and fusion reactors. Virtualization in various flavours is used to slice
capacity both at the packet (VLANs, MPLS) and the circuit level (using Generic
Framing Procedure as an example). Virtualization is also used to decouple the IP
topology from the physical topology and to perform traffic engineering.
In recent years the developments related to virtualization are in two main areas:
• Multidomain services, such as Bandwidth-on-Demand, security and authentication.
The services are either in the trial or production phase. In particular the dynamic
circuit network (DCN) [12] in ESnet and Internet2 and the AutoBAHN[13] service
in GÉANT deal with the creation of virtual circuits on large scale. The challenge is
to provide a real-time service, reducing the set-up time of a point-to-point virtual
circuit. These multidomain services require the development of new standards for
protocols, resource representation and functionalities in equipment, as the NRENs
have to create networks in an environment, which is intrinsically multi-vendor and
multi-technology.
• Monitoring, management and control of the infrastructure. These ancillary services
become very complex when the same physical infrastructure hosts many virtual
networks. The approach has been to develop a modular, multidomain, distributed
monitoring system (PerfSONAR[14]). The capability to monitor the virtual
elements of the network is strongly determined by the functionalities provided by
the network equipment.
The NRENs are continuing to reduce the number of transmission protocols used.
At the same time they are increasing the number of Interdomain protocols and the use
of virtualization to provide advanced services. The NREN infrastructures are already
supporting environments based on virtualization, which are evolving in size and
M. Campanella et al. / Virtual Infrastructures in Future Internet 65
complexity. The introduction of computing elements in the network topology is

mandated by the need to control and manage all the virtual infrastructures created on
the same multidomain physical environment and it will permit a step further in the
virtualization of the infrastructure functionalities like routing, monitoring, capacity
offering.
2. FEDERICA
Research on Future Internet technologies and architectures has become a hot topic in
computer science. There are many initiatives worldwide, e.g. GENI [15] in the United
Stated and FIRE [16] in Europe. Such research requires new environments that
combine flexibility and a minimum set of constraint for the researchers. FEDERICA
(Federated E-infrastructure DEdicated to Researchers Innovating in Computer
Architectures) is a European Commission co-funded project started in January 2008
and operational until June 2010, that created a scalable, Europe-wide, clean slate,
infrastructure to support experiments on Future Internet. Its architecture is a working
example of an infrastructure completely based on virtualization and it is described in
the following.
2.1. Project Goals and Objectives
The main project objective is to create an e-Infrastructure for researchers on Future

Internet allowing researchers a complete control of set of resources in a “slice”,
enabling disruptive experiments and placing the lowest possible set of constraints to
researchers. Research on the use of virtualization in e-Infrastructure and facilitating the
collaboration between experts are also key goals.
2.2. Architecture
2.2.1. Requirements
As the scope is focused on a research environment on new technologies, the
following set of requirements for the infrastructure have been assumed:
• Be technology agnostic and neutral (transparent) to allow disruptive and novel
testing, as to not impose constraints to researchers. The requirement is valid for all
networking layers, not just the application layer and extends to the operating
system used.
• Ensure reproducibility of the experiments, i.e. given the same initial conditions, the
results of an experiment are the same. This requirement is considered of particular
importance.
• Provide to the user complete control and configuration capabilities within the
assigned resources.
• Allow more than one user group to run experiments at the same time, without
interference.
• Open to interconnect / federate with other e-Infrastructures and the Internet. This
last requirement plans for access to slices, access to the control of slices,
management of experiments, interoperability and migration testing.
2.2.2. Framework and Design.

The requirements suggest two key framework choices for the infrastructure, which
are at the core of the design:
• The simultaneous presence of computing and network physical resources. These
resources form the substrate of the infrastructure.
• The use of virtualization technologies applied both to computing and network
resources. Virtualization will allow creating virtual, un-configured resources.
Virtualization is defined as the capability to create a virtual instance of a physical
resource, both in the computing and network environment. The virtual resources (e.g. a
virtual circuit, a disk partition, a virtual computer) are usually created by segmenting a
physical resource. Virtualization may create non-configured (clean) virtual resources,
e.g. an image of the hardware of a computing element on which (almost) any operating
system can be installed, a point-to-point network circuit, a portion of disk space. Those
resources can be then tailored to various needs and even moved from one
virtualization-aware platform to another.
Such framework leads to a design in which the infrastructure is considered to be
built in two distinct layers:
1. The virtualization substrate. The physical infrastructure which contains all the
hardware and software capable to create the virtual resources;
2. The layer containing all the virtual infrastructures. Each containing the virtual
resources and the initial network topology connecting them.
The virtualization substrate is a single administrative domain. The virtual
infrastructures (VI or “slices”) may be in principle unlimited, in practice a large
number, restricted by the physical resources available and the requested characteristics
for the slice.
Two basic resource entities are defined:
1. Connectivity. In the form of a point to point circuit with or without assured
capacity guarantees and with or without a data link protocol (a “bit pipe”);
2. A computing element, offering the equivalent of a computer hardware
containing at least RAM, CPU and one network interface, mass storage is
optional, although usually available. The computing element is capable of
hosting various operating systems and also to perform functionalities (e.g.
routing).
To minimize the load on the physical resources and the interference between
virtual resources, the network topology has a high level of meshing. As most of the
network interfaces for computers do not have virtualization assistance in hardware,
more physical interfaces are installed. The infrastructure has been designed to favour
testing of functionalities, protocols and new ideas, rather than providing a laboratory
for very high performance studies.
Following the framework outlined above, FEDERICA is designed in two layers.
The lower layer is the substrate, which is made of physical resources, both network and
computing elements, each capable of creating “virtual” resources of their kind. The
resource sets, or slices, managed by the user, compose the upper layer.
Given the sophisticated NREN network architecture, a distributed infrastructure
can be engineered, with various Points of Presence on the top of the GÉANT [7]
backbone, interconnecting several NRENs in Europe. Figure 1 shows pictorially the
design of the infrastructure built on top of the existing NREN and GÉANT production
environment. The virtual infrastructures (slices) are shown on the top of the picture.
More than one slice is active at the same time.
Figure 1: Pictorial representation of FEDERICA.
Figure 1 represents the slice in vertical format for the sake of clarity and to show
that there is no dependency or hierarchy between them. Each slice may contain a
virtual resource coming from any part of the substrate. The same physical node, as an
example, can provide virtual systems to more than one slice. A virtual router can be
created in a Juniper node (ensuring complete independence between the virtual routers)
or by a virtual system running the routing suite.
3. The FEDERICA Infrastructure Implementation
The infrastructure is built using:

• A mesh of Ethernet circuits at 1 Gigabit per second provided by the GÉANT
backbone. The circuits are initially at 1 Gbps as this capacity allows slicing to
relatively high -speed links and yet is still affordable as contribution by the
participating NRENs. Most of the circuits are created over SDH using generic
framing procedure and virtual concatenation. Fig. 2 represents the current topology.
• Network equipment. Programmable high -end routers/switches: Juniper Networks
MX480 with dual CPU and one line card with 32 ports at 1Gbps Ethernet. The MX
functionalities include virtual and logical routing, MPLS, VLANs, IPv4, IPv6. The
MX480 are installed in 4 core Points of Presence and 2 MX480 are equipped with
Ethernet line cards with hardware QoS capabilities. Smaller multi-protocol
switches (Juniper EX series) are installed in non core PoPs.
• Computing equipment. PC based nodes (V-Nodes) running virtualization software,
capable of implementing e.g., open source software routers and emulating end user
nodes. Each PC contains 2 x Quad core AMD running at 2 GHz, 32GB RAM, 8
network interfaces, 2x 500GB disks. The V-Nodes are connected to the Juniper
routers.
The initial choice of the virtualization software for the V-Nodes is VMware [2],
the free version of ESXi. This choice has been made after a review of other
virtualization software (e.g. XEN). In particular the Application Programming Interface,
the availability of usage examples and expertise and an upgrade path to better
management using a commercial version of the software were important aspects of the
evaluation process. The capabilities and performance of the free version have been
adequate for the current requirements.
These building blocks of the substrate pose very few constraints to the user. In the
current status of the infrastructure the most significant one is that the data link layer is
fixed to Ethernet framing. Future development may permit access to optical equipment
to overcome this limitation.
3.1. Topology
The topology is composed of 13 physical sites. Of these Points of Presence (PoP) a
full mesh of 4 is equipped with MX router/switches and is considered as the core. The
9 non-core nodes are equipped by EX switches.
Fig. 2: FEDERICA topology on a map of Europe
The core nodes are equipped with 2 V-Nodes the non-core PoPs host 1 node each.
The physical topology is depicted in Fig. 2. The design placed particular importance on
the resiliency and load balancing of the network, based on GÉANT’s infrastructure,
and resources availability at partners’ locations.
The substrate is configured as an IPv4 and IPv6 Autonomous System with both
public and private addresses. The infrastructure is connected to Internet using the
Border Gateway Protocol and receives full routing tables in the four core PoPs.
The infrastructure is centrally managed and monitored by a Network Operation
Centre. The NOC has also the task to create the slices. The infrastructure (substrate) is
a single domain that contains all the physical resources (point to point circuits, nodes)
in all PoPs. The domain does not contain the optical equipment of GÉANT used to
transport the circuits between PoPs.
3.2. Resource Virtualization and Slice Creation

The process to create a virtual system is rather straightforward and can be based on
an image provided by the user or on template of various operating systems. The
virtualization capabilities in the network are also evolving, as described in [6]. The
article reviews the current research in a Network Virtualization Environment (NVE)
and the many challenges associated. The initial choice is to use VLANs and use QoS
techniques for circuit virtualization; MPLS may be applied when needed.
The slice creation procedure definition is constantly developed and may change
slightly to incorporate the feedback received after the first user feedback. The slice
creation includes a manual step to map the virtual resources to the physical substrate.
The step is manual to ensure that the mapping ensures the best reproducibility of the
behaviour of the virtual resources.
The current slice creation process consists of the following steps. First, the
researcher that wants to perform an experiment is required to provide the NOC with the
desired topology, including requirements for the nodes and the network (each V-Node
RAM size, CPU power, mass storage space, topology and bandwidth between the V-
Nodes, routing or switching functionalities, protocols).
Once the NOC receives the slice description and resource requirements, the NOC
maps the logical topology requested on the physical topology of the substrate and
chooses the sites (PoPs) from which physical resources will be allocated. The NOC
needs to instantiate an extra virtual machine, that act as a gateway between Internet and
the slice: the Slice Management Server. Access control of the Slice Management
Server is performed by means of identity credentials managed by a RADIUS server.
The next step for the NOC is to instantiate Ethernet VLANs to connect the slice
resources and create the topology required by the researcher.
3.3. User Access And Support
When the NOC has finished the slice creation process, they inform the researchers
that the slice is ready to use. In the example in Figure 3 the user has requested a simple
slice consisting of two virtual servers connected through a Juniper logical router. The
NOC has already setup these three resources, connected them through a VLAN (black
line at the bottom of the Figure), instantiated the Virtual Slice Management Server and
created the Slice Management Network (the cloud at the centre of the figure). The
researcher connects to the Virtual Slice Management Server using the credentials
provided by the NOC, and is authenticated against the FEDERICA Authentication
RADIUS Server. If the authentication is successful, the user can access all his/her
nodes via the management IP interfaces.
Besides remote access to the resources, another complimentary mechanism is
under investigation. Access to VMware virtual machines can be granted through
remote VNC connections (the virtual machine clients would connect to a special port of
the physical machine where VMware is installed). By exploiting this mechanism users
would have access to the console of their virtual servers, but they would also be able to
interact with graphical user interfaces and to even access the BIOS of the server; i.e.
they would have full control of the virtual machine.
During the initial operations, all the steps explained are performed either manually
or using a heterogeneous set of tools (web portal for users, VMware Infrastructures
application, the remote console of the devices, VNC clients, monitoring tools).
However, a tool bench that provides a unified environment to operate the
infrastructure and to use the slices is being developed, and will be progressively
deployed and used by the NOC and the users.
4. An architecture for virtual infrastructures
The project’s architecture described in section 2.2.2 represents an implementation of a

domain based on virtualization and capable of a large set of services, similar to the ones
provided by cloud computing and augmented to include wide area networks
communication. The substrate creates the possibility to host many infrastructures, each
configured differently and simultaneously active. Domains containing such
infrastructures can connect between them at the substrate level to offer common
services. Such infrastructure can also connect with domains not based on virtualization,
like the current Internet. The interconnection can be done by the substrate and by each
slice in parallel, in this case a careful planning of the traffic routing and addressing is
needed. The flexibility in configuration of the virtual environments, usage optimization,
scalability and resiliency of the infrastructure make it appealing for a large variety of
uses.
5. Challenges
The initial list of challenges for virtual infrastructures which has been identified are:
• The reproducibility and the stability of the behaviour of a single virtual resource.
In the case of a researcher experimenting on a virtual infrastructure, the behaviour
of each virtual resource is key to allow reproducible experiments. Two
independent causes may generate instability:
• The sharing of the physical resource with other virtual resources
• The virtualization technology itself, usually a layer placed between the
physical resources and the virtual ones.
Hardware assistance for virtualization has been introduced recently in computers
to reduce these differences. Since 2005, the main CPU manufacturers have added
virtualization friendly extensions, in particular related to protection rings.

Hardware enhancements have been introduced also in networking equipment to
provide, as an example, queuing and forwarding of different classes of packet
traffic in separate memory buffers.
Reproducibility represents a feature of the quality of the services offered based on
virtual resources. Providing assurances on the behaviour of a single resource is
possible through a careful engineering of the hardware and software, but there is
the lack of a general set of rules and procedures. As an example, computing
elements in FEDERICA have been chosen to provide specific functionalities in
hardware, like virtualization aware CPUs. Some circuits are connected to network
QoS capable line cards in the Juniper MX. In other cases, where hardware was not
available, the physical resources have been adequately dimensioned, to avoid any
overbooking and minimize contention. While it is then possible to create a slice
with a set of resources, each with reproducibility guarantees, providing
reproducibility to the global behaviour of the resources connected in a slices is
much more complex and, the complexity increases with the number of resources
involved. The classic problem of guaranteeing the end-to-end QoS of an IP flow
exemplifies the issue. In case of virtual infrastructures, as in the case of Internet
traffic, the project’s experience is that most of the virtual infrastructures are not
required to have strict reproducibility guarantees, and rather a “best effort”
behaviour is sufficient for the researcher’s scope.
• Virtualization services definition in an infrastructure capable of both wide area
network and computing virtualization. In both the cloud computing environment
and in the network environment the developments of services is proceeding. Effort
on standardization of resource representation, management and control is needed
and also a standard infrastructure description language. Such language can be an
evolution, as an example, of the network description language effort [17]. Such
developments open the possibility to federate infrastructures and to develop new
business models featuring a user ‘s virtual infrastructure extending in more than
one domain.
• Complexity. The complexity of the systems based on virtualization, in particular
when coupling network and computing resources, increases fast with the increase
of number of resources. In addition, the possibility of having recursive
virtualization resources on the same physical resource generates additional
challenges to the monitoring system, privacy and security model, and management
and control architecture. The complexity may actually reduce the reliability and
the quality of the system, increasing its operational cost for management and
problem resolution. This challenge requires a focused effort on standardization in a
short timeframe, to avoid un-compatible implementation of services, applications
and architectures. It also requires a broader set of competences in selected experts
to plan and operate such services.
6. Infrastructure relation with “cloud computing”
The generic term “clouds” is a rapidly developing paradigm shift. It is often associated
to “computing” [4][5] and refers to a set of “services” of type application (e.g. Google
apps), platform (e.g. Windows Azure) and infrastructure (e.g. Amazon EC2). These
services are offered through Internet with a simple user interface and leverage
virtualization technologies.
Those services can be offered by an infrastructure like FEDERICA fully based on
virtualization. The more natural comparison is with an Infrastructure as a Service
(IaaS) offering with which it shares a simple user interface, neutrality to user’s
operating system and application, scalability and parallelism in users’ utilization.
There are also some noticeable differences in respect to current cloud computing
offerings. In FEDERICA virtualization is available in all elements (including network
ones, like switches and routers) and specific importance and careful engineering is
placed on the reproducibility (QoS in brief) of the single elements behaviour. This will
enhance the possible service offering and the overall capabilities of a slice as research
infrastructure when and where needed. A strong coordination and collaboration for the
definition of standards is also envisaged.
7. Conclusion
The use of virtualization technologies in Internet is increasing and expanding. The

advantages of adding computing capabilities to the network infrastructure are evident
when coupled with virtualization. Such an infrastructure based on virtualization in all
of its components and built with both computing and network resources may represent
a new architecture for parts of Internet, in particular it can provide an ideal
environment for innovative research and rapid service development.
The virtual infrastructures created, or slices, may contain any combination of the basic,
“raw” fundamental virtual resources in arbitrary topologies and hosting any operating
system and application type. Such virtual infrastructures allow full control to their
owner, may easily connect to other infrastructures and are configurable in a short
amount of time. The physical infrastructure in the NRENs and the telecommunication
environment are already capable of supporting virtualization in many of their
components. The FEDERICA project is an example of the capabilities of current
hardware and is researching on the many challenges of virtualization. The project will
continue to support researchers and to develop the architecture of virtualization based
infrastructures. A strong connection to the research and standardization in cloud
computing is expected.
References
[1] Paul Barham et al, Xen and the Art of Virtualization, SOSP’03, October 19–22, 2003, Bolton Landing,
New York. ACM 1-58113-757-5/03/001. http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-
xensosp.pdf
[2] VMware Inc. is a provider of virtualization software founded in 1998. http://www.vmware.com
[3] Kernel-based Virtual Machine (KVM), see http://www.linux-kvm.org/page/Documents
[4] For a definition of Cloud Computing, see NIST Definition of Cloud Computing, P. Mell, T. Grance,
Version 15, 10-7-09, http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc
[5] IEEE Computing now, October 2009: System Virtualization, September 2009: Cloud Computing:
Opportunities and Challenges, http://www.computer.org/portal/web/computingnow/articles
[6] Chowdhury, N. M. M. K., Boutaba, R.,: Network Virtualization: State of the Art and Research
Challenges. IEEE Communications Magazine, July 2009, 20-26 (2009)
[7] GÉANT, the European Research and Education backbone, http://www.GÉANT.net
[8] FEDERICA, “Federated E-infrastructure DEdicated to Researchers Innovating in Computing

Architectures”, European Commission co-funded in the 7th Framework Work Programme, project n.
RI-213107, http://www.fp7-federica.eu/
[9] P. Szegedi, S. Figuerola, M. Campanella, V. Maglaris, C. Cervello-Pastor: "With Evolution for
Revolution: Managing FEDERICA for Future Internet Research", IEEE Communications Magazine
Vol.47 No.7 pp. 34-39, July 2009
[10] M. Campanella, "The FEDERICA Project: creating cloud infrastructures", In Proceedings of
Cloudcomp 2009 (CloudComp), October 19-21, 2009, Munich, Germany. ISBN 978-963-9799-77-6, to
be published in LNICST
[11] For a detailed analysis of NRENs in Europe and their role, see the documents (in particular the
TERENA compendium) available at http://www.terena.org/publications/
[12] Internet2 Dynamic Circuit Network, at http://www.internet2.edu/network/dc/
[13] M. Campanella, R. Krzywania et al, Bandwidth on Demand Services for European Research and
Education Networks, Proceeding of the 1st IEEE International Workshop on Bandwidth on Demand,
Nov. 2006, San Francisco, USA, Volume 1, Nov. 2006 Page(s): 65 – 72
[14] B. Tierney, J. Boote, E. Boyd, A. Brown, M. Grigoriev, J. Metzger, M. Swany, M. Zekauskas, Yee-
Ting Li, and J. Zurawski, “Instantiating a Global Network Measurement Framework”, LBNL Technical
Report LBNL-1452E, January 2009. See also http://www.perfsonar.net/publications.html
[15] Global Environment for Network Innovation, http://www.geni.net
[16] Future Internet Research and Experimentation, http://cordis.europa.eu/fp7/ict/fire/
[17] Freek Dijkstra, Bert Andree, Karst Koyman, Jeroen van der Ham and Cees de Laat. A Multi-Layer
Network Model Based on ITU-T G.805 Computer Networks, Vol. 52, Issue 10, pp. 1927-1937, July
2008 and the web site http://www.science.uva.nl/research/sne/ndl/
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-75

!#$* +>\>^+ _ +> +
$^`{+
+

{
|
+
}++ }>
+
}

}
+
}

+
> +

}
|

+>+}+
++

+
+} {++

+
+>}
++
++++

+
}

++}
+

+
+

+ + +
+

++
+}
++

>

>

$
+
+ }

+
+ +}
}

$
}
+ + >+}

}}
+ ++ +

+ }
}

> }}
+
} +
+} +} + +

> + +
+

+ +

+
> + + +
++}

++} +}
+ +>

+
}
++ + >
+
+ }++>+}}++

+ + +>

}

+ >
}
} + { +} +
} +
++

+

$ !!!
+++

}
+ +} + >
+}}
>+}
+

+} +

}
> +

}+}
}+
+

$

++} +
+
+ +
++ +
> +
+

|
}
+

}

+
} }>+ +
}$+
+

+

+ +
} >
{+}
++

\

}
76 D. Lagutin et al. / Publish/Subscribe for Internet: PSIRP Perspective
$ +

+

+} }++ }
++
> } \>`*>`>+}*`++

++

+
}}
*+}

>

++

+}
+++++
$

++} }

+
}+

+
}
+>

+
++++

}+}
+
++

+ +

+
} > + +
+

}
+ +}
|
+}+}+
+}
} }+ $
+

}+
|
+ +} + $+
+ }
+

\
+} }

}++

+ +> +} + + +

+

}

+
}
+

}++ } + `* +

++} + * +
}
+
+
++
+} }+

`*+
+
}+
+>+ >
++
+ +|

}+++}
++`*
++}

+
+}}+`*+}+}>+}
++
+}

+
}
>+
+
#}`*>}++
+
}+

> }++}++> +|
>+}
+}++

+|
+$+
}+++
+ + }++
$ *
+}++ }++
++
+ ++}+++
+ +*

+

}++
}
+
>+}+}

}++

} }+++ +
+
}}+}>+
++
+

+ }}++
+$*

+
}} >
+
+}
}
+++
} } }+}+
>

++ }+ ++ + +++}+
+

}*
++ } ++++}+ +} }
+}
$ *
++
+
}
+ +} >
+
+
}
+}+}}

$

+} +
*>
+
+
}+

++

++ +
{ >
> +} }

+ + + } +}} +

`+}>
*
+

+ >+}
$
+
+

}}} }

+

+
+
D. Lagutin et al. / Publish/Subscribe for Internet: PSIRP Perspective 77
\ +

+

+
+ + } +}+}+++

+} } + }

}

!"

} +
}+} +}}
+}
+ + }} +
> +
+

> + +
+ + } +} }++ +

+ +}!^ } >!!+

} }+++
+ $+

+}
+

+} } \+
+
+

++}++

}+ + +}}
+

+

+
++
+

$ + +
+
+ +
+ +} +
+}

+
+

+>
}++}
+ }++

+ > + ++

+

++} + +

}
+
+ +
+
+ +}
+}}
+ }
+
+ + +
+

+
>+

}
}
}
+
++

+ }

+ } +
+
+}+

++
+
+}

+
+ }
+}
}
}+}
+

+
+
}
}
}
+
"#$

+
}
` +

}+}
}
}+++
>+++}+>+}++

#$

+
}
+
% }>
+}
}+} } }+ +
$++
+
+ + }++

}
+ + $

} +

+}++

+} ++ + } }}++
$+ }
>

+!
+
+

} $

+
>
+

}++

+}

> + > ++ > ++ + >
+ >

>
> +}
+

+ +

+ } } }++
+
}

$ } >+ ' }>}
++
} ++}

} ++}++}
}
+

+++ >
+ }> +}
++ > }
+
}+ +

}+

"#"

}
+} }
} +

> +} + }

}} + +}
+ ++
`*> }
+} }
+
}+
>+ >
+
+>+}
++ ++++}

+ + + + +
$
+
}+
} +}
} $++}+
+ + }+

+
+ }+} }++} >

+
+ + +
}+ +
>
}++
+} +
} + + +
+
}++}+>
}+

+ }}
} +
+
}> +
+
+
+

}

+>+++} *

}
} ++}+ +
+
+
}

+
} } }
+
+ >

}+

+
++ + + +
$

+ }+}+
+
+ +
++
+}

+
\>+
++}+
>
++
+ >}++

+
+}
+

`
+}}++
+
+

+ +

+}

+

}}++

+}

> ++
+
>}
+ ++
+++
+

}+
}++

+}}

>+
+++
+ +

$+
+++ }

+

+

}++
+
"#*

+

+
+

>

}
}+} }+ }+

+¡+} }

¡ +> } } +5 ! 67
896'7 :$;"<$<9= +} }}
+5 ! > 8 ?@ ?= +
}+ + } ++
++ }+
++J'+ :$;"<$<=?+
+}J?
}+}+

}+

} }
} }
+

>
+
+ }

+
} + +
}}
+>
+}+}
++
+ > }++
++ ++ + + +
+}

+>

+ }} +
+ +
+ + } }

++

+
# "
$ +

}
+
¢}
>> >
+}+} $

}

+
+ + +

$}

+
+
+ }}+

+}

+
+> +
}++

++ +

} ++ }}+ >
++

+ + >+}+ +

++}+
+}+ }
+}++
+}$

} +} }
+ + +}++++

}}+

+>++ +
} }

+ }
+} $}+ } +

}+ }}

+} £
$+ +
++ }
+} +}

+ ++
} +

}
++ ++
+ }
++} + } +

++$
+
+
+ }++

++}+
+
+} }$+ +
++ +}
+}
+
++
+} }}
*#$Q
+
+

+

+

+ ++ +

}
+ }+ +
+}+ +
++

+}

}
$*>+ }
*>+}+} }
*+
+

"WXY
ZX' % ' #
+
+>$*
+

++ +}+ >+}
++*
>+}+ }+ +

+!
+ }+ $*
+
+ *

}+
*
+

+

+}
}++

+}+ ++
+

+ + > + }
+
+

} } + }++ +
+} +
+
} +

+ +

+ $ +}+ ++
+

++
}++
> } + ++

++ }
}+ +++
+ }}+
+}
+
}
+
+ }+} } +
}+
$

+

+
+ +}+

}+}+
+
+

+
} +}+ ++

++}+
} >+ ++

+

+

*
+
> +
> +} + +} +
+ +
+
+ +
}+} + } *
+
} +
} } + +} +}
*
+}$*

+
*
+ ++ }+ > + +} + +

}+ }
}

+ $
+> +

+
+} }+
>+++ } }+
+
}
}++}}++
+}+

}
++

+

+

+}++}}+++}

+
+}+

+
}

+ $
+}
+
+ +}

+ }

+ + + +
+ +
}+ }}
+ +}

}

++}
+} £
*#"Z%
}

}+ +
+}

$
}

} }}}

*+ }

+ +
+ +}

}

+

}
}

*
+

*+
}

} +*
+
+*
+
}

+
+} + +
} + }

+*+
+
}+
}+`*

>+
$}

++}
+ + +$\¤
+
}}
} }+*
+}

+++++$++ +

+++

+
} $ +
}++ +

+
}
+ +}} +

+

+}
} }+ +
+} +
}

+

*
$

+
} +
+
++ +}
+

}

}+ ++++
}
}+ }}
}
+ +} \\
*#*X !!!
++

+

>+
}++
+ } +
+}

+ +

%' *

}
>*+}

}

*>+

}
+}

+ } }+
}> }+ +}
+

+}

+}+*

>}

+
+
}+

}

+}
*

+
>

+
}++

+}
+
++
}

+
+}
}++

+

+
+}

+
+
} +

} } ++>
} }

+>

+
} }

+}+} +
+ + ++ }

+
*#['
$++

+}+
>
+
} } +
+ }+ +
+
++ > +} }+
+ + + }+
+
++
!

\ +
+} }
+}

++
}++
> +
+
\6Q+

}

+
+
+>+
+
+ } > +}

} ]Z
+ + }
+++}++}+

+
+}
>
+} }
++}
+
}+
\6Q +
++ +

+
}+}
+
+ }

*}
}+++ }
>
+
+}}

*#;Y
}+ }

++
>

+ ++ |
}
++

$+
+

} ++ + +} } +
++
$

+
}

>

> +} ++ ++}
+ *++>
+

}
+

|

++
$+

+
+}+ }
+}
+} +
> +}
+ }++
} }

++ }

+\> +
}

+}
+

+\¤
+

+
+\¤
> + }} }
+} }
+
+ + \>

+ +
+
> }
>+ +}++ +

}
}
+}

+ >+}+ +
}
+
+} + +
+
+
>+}+
}
+ + +
}} +} +}+ ++ >
+ +
+ }

}\
+}

+

>
}

++>+} ++ } ++
++
$
++ \
+
+
} + >
++ }+ }+
> +} + }
} + +
+

+}

+
> +

+++
++ } > +++} +
++++

+> +

}
|

}}
}
+}+
+
>

+ +}+ } +
$ "%'%''(
$ +
} +

$

+
}
$
+ +
+

+ +}
+
}+} $
+

++}

}+
+} +
>+ +

+
}}
++ +
}
+ + } $
+

} + }+++}+

+ +
$}
} + +
} +
+
++
}
¥ +} +
+
} *! }
+}\ >
+
++ ++}
+}+
++ !
>
+} }

+
} +}+> +

$+ +
+}+ + }>+

+
}}$
+

+>
+}
+> + $+
}
+}
}
+ # +W
$ }
+ > +} *! +}
+ >+
+
}+

}!+}

>+}
++ +}+}\£
++ +
+ }}

+

$}
+

>+
+
+ }
#

$\+

+}

}
+
+ +} }
+ +

) *
$
+}
}+ +} + >+++

+

++}
+

+}+
} >
+}
++ $+

+}
+
+

+
> + +
} + } ++}

++
+} +> +

++ `+

++> +}
>+}
+
+
{+ +

+ } $ }

}}>
}+}++} +
}++
+
++}

+}
+ +

>
+}
+
+ }} +>

+} +

+
}
+ $
}+
}+

+ + }
+}

}+ +

+ }
+
> +}

+ + + $

}

+
+}
+} > +

+
++$++}}++ }+ +

+

+
}
|

+
{ +

++}

>

+}+

}}

+}++ + +
$+ +

}+
}}
+++}+}
(
\ +> }

> ¥+> > +} ++> } +
>
X Y
>^^]@"<<"
¤¤
$^ >++` }+}}* > X Y
>^]@@
"<<_>^>¦++>
¤¤
{+
+#>` ++>X Y
>^]@@"<<`
+>+>
¤¤#
_ ¦+
# * *+} > X \^@ ^6q "<<z > +>
¤¤
$++> { > +} ^ _
++> $

++}

>'>\¤§\\\>¤¤£
¦ +> }> +} +> }} +

}
> { $+
+

>>
> ££>*\£
+ # $

+ $|
> { $+
+

* >\>
> >¤¤
£ ^_
++>+ >+} $++>* + ++` } >
X Z\{<z>¤¤
¦+>¥+
>
> ++>+}* +}> * }

* >X Y
>^]@@"<<z>++> + >
¤¤
\¤ !+
+>^!+} >!+ +{ +>+ !{+
$
+ +
|¤>¤¤> >¤¤
\\+++>¦# +$¤¤¤+ }
>
¤¤ + ++$``
\ > + $+}
+
} +
> \^@^
\>
>>\ ¤
\ { >_ >#

+> X ^Z7X]{|;W\
^>
\£
\ + }
$ + + + + +|

>

#
$> +}>¦¤¤£
\ ¦
>^¦¨ >+}¦ ¨+ + +}+ +
+
$ + + +

+}©© +©}
\
> +

+++

+
>
X ^ ^6' Q +^"6Q=>{ +>+>*
¤¤
\ *! + +++
\£ > } + ++
}+}

\ $\\¤\¤ +
++ + +

#
$ + ++
+ +
\\¤\¤
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-85
IDentity Engineered Architecture (IDEA)

Joao GIRAO a and Amardeo SARMA a,1
a
NEC Network Laboratories Europe, Heidelberg, Germany
Abstract. This paper introduces an identity engineered approach for the Future
Internet that puts usability and privacy concerns at the core. The goal is to achieve
a solution that scales to billions of users and entities that could want to connect to
the Internet. Digital Identities that conceptualize the properties of users under their
control play a key role in making sure the needs of the user become part of the
target architecture. The concept of intentity makes the initiation of communication
and services depend on the intention of the user or, more generally, the entity.
Keywords: Future Internet, Virtual Identity, Session Concept, Intentity, privacy
Introduction
The Internet has emerged as a support infrastructure to allow people to communicate

freely with computers. Today, such communication has become a cheap commodity. It
has grown from a research and military tool to a people’s and commercial tool that
deals with all sorts of information about people, public records, enterprise data, medical,
things. More freedom to access uncensored information has come with the problems of
privacy and the ability to balance masses of information and quality.
Too much of the Internet’s design effort was spent on machines and computers,
while the people aspect was strongly underrepresented in the architecture. Just as
security is often an afterthought, privacy of data – in particular of identifiable data –
has been put on the backburner. The terminal has become the mandatory end-point of
communication instead of the user for many scenarios. Furthermore, the Internet
became the storage place for information. The infrastructure inevitably becomes the
bottleneck of our communications infrastructure. A solution is needed that allows
services to scale to billions of users and entities that rely on the Internet to connect
them.
We propose a different approach to the Internet in which people should be able to
communicate with people or things and consume services. They may be
communicating in real-time or over-time. The context may be business, social,
entertainment, medical or yet unknown purposes. The context of communicating or
service consuming entities must match to make sense. Our new Internet approach starts
with an entity that wants to communicate with one or more other entities, where the
entity may be a user or thing. Our approach is to create a scalable digital
communication infrastructure which mirrors the structure we have always had in the
real world: people talking to people (or things), in our case, modelled by digital
identities communicating with each other or consuming each other’s service.
1
Corresponding Author
86 J. Girao and A. Sarma / IDentity Engineered Architecture (IDEA)
1. Relating Concepts to Reality
There has been a lot of confusion in the identity debate because of the meanings and
associations of some of the used terms. We chose an approach based on ontological
realism and the abstract nature of concepts reflected in M. Bunge in [1][2]. In the real
world, entities communicate with each other and consume each others’ services. We
conceptualize them, their properties and how we believe they could interact. We further
develop models, concepts and specifications in the abstract domain, which humans can
communicate to each other via languages, formal and informal. These may be
implemented as data, software or hardware in the real domain mainly of computers and
communication channels as shown in the top of Fig. 1. The top real domain in Fig. 1 is
a subset of the lower real domain, not all of which are artefacts that can be changed.
We have chosen not to follow the widely used term subject [3] and chose entity for
reasons of clarity and precision. The larger issue with the term subject is that it is not
clear whether the real person or thing is implied, or whether we are talking about the
concept of a person or thing in the abstract domain. When in [3] the assertion is made
that “the independent existence of a thing is moot” because “it may well be an aspect of
something else” the realm of constructs (here properties, such as colour) and real
objects (such as a real book) is being confused. If we take subject to mean the
abstraction of a real entity, we run into another problem. It would not allow us to
differentiate between a virtual (fictional) person, say Peter Pan, and a real person.
The term claim carries more semantic baggage than needed by connecting it with
“being in doubt” [3]. We refer in the abstract domain to constructs that may range from
models (representing say a full enterprise) via propositions (interpreted as statements)
to properties. No automatic “truth” value is attached to claims, assertions or
propositions, and the choice of one of these three terms is likely to depend on the
informal semantics attributed to the term. The truth value can only determined as
formal truth by mathematics or as empirical truth by testing. Nonetheless, to be as
compatible as possible with related work, we use the widely accepted term claims.
Data, comparable to linguistic objects or marks, designate the concepts, some of
which may refer to real entities. If the reference is to virtual entities, such as Peter Pan,
we remain in the virtual domain, in fact this turns out to be a self reference.
Figure 1: Relations between entities, concepts and data

J. Girao and A. Sarma / IDentity Engineered Architecture (IDEA) 87
Virtual identities shown in Fig. 1 above refer to a set of claims, and we adopt and reuse
the definitions in [3], in which attributes or properties are parts of claims (or
propositions). Digital identities are the designation of virtual identities in the real world
of signs and computers.
In today’s Internet, the user and companies are not conceptualized in architectures,
and we are confined to only considering programmable entities (top level of Figure 1).
If at all, an informal picture may show people or companies, but these have no impact
on the actual systems being developed or used. We are restricted to conceptualizing
devices, nodes and address nodes by only representing the device locator. Today, we
do not build on concepts that refer to communicating or consuming entities with all the
communicating channels and interim nodes.
Similar problems occur when developing a process, since its designation in the
model is broken down in almost independent parts (e.g. transport, service, application).
The model currently used in the Internet, including the way it is represented and
implemented, limits the way applications, services and networks perceive the endpoint
and the channel. The abstraction or model is bound to a particular instance in the real
domain. Flexibility is lost both in terms of addressing endpoints and adapting network
and service parameters, such as path, device or application, once the different layers
have been instantiated.
Many of the latest developments in the current Internet are patches to deal with the
misrepresentation of our abstract concepts. For example, HIP [5] or NodeID [6]
reference the device rather than a particular interface on that device to separate locator
from identifier. While this solves one part of the reference for a device, it still does not
include the entity behind the device. We need a solution that supports the evolution of
networks and services but also for increasing the privacy of the Internet’s endpoints,
such as people, organizations and providers.
2. Identities and Privacy
Privacy has been the concern of a large number of activities and projects over the last
years, and a good overview with many of the issues has been found in [7], which
includes current approaches for privacy in the network. A section on communication
privacy deals with how anonymizing techniques have been used for privacy including
the underlying trust models, in general solutions on top of existing networks. In Part III
of [7], privacy enhancing technologies including enforcement of privacy policies and
obfuscation are dealt with.
As a first problem in this paper, we begin by addressing how we handle identities
and privacy by the conceptualization and representation of entities. This will later also
help us with obfuscating schemes when we move data to the network. In this scheme,
the representation of an individual, or in this case an entity, is a collection of its claims
containing attributes in an abstract way that allows us to conceptualize the entity as the
endpoint. This virtual identity or VID is designated by identity data spread amongst
services and networks, but which can be linked to the concept of the same identity. The
linking of data does not mean that this linkage is accessible by all. In fact, in some
cases, the user himself might be the only one who holds the required references and
chooses to disclose them at his or her will.
Privacy and security become compartmentalized under one virtual identity and a
real person can have as many virtual identities as needed. For example, a person at
work acts in a business context, while a person at home acts in a private context. This
segmentation of who we are does not hamper our uniqueness but allows for a
compartmentalization of our different aspects in life. Figure 2 shows a few examples.
Figure 2: Uses of Virtual Identities for accessing services and networks.

In the Future Internet, we should move to addressing virtual identities representing
arbitrary entities in the real world, and not just devices. By doing so, we enable
communication and interactions between general entities as part of the architecture
itself, allowing features such as people moving between devices and maintaining a
communication session. Also, even from the point of the underlying architecture, it is
the person (if needed) that is addressed irrespective of which device he or she currently
intends to use. Binding the virtual identity to a role will allow a person to distinguish
different intended uses (or charging) of services and enable different roles to remain
unconnected, if so desired, while making the overall system easier to use.
Out approach further allows both utilizing useful data in the network to enhance
the operation of the network or infrastructure, while eliminating data that is not needed,
such potentially revealing IP addresses. This supports privacy intrinsically while
constraining available data at any point to the essentials as shown in Figure 3 below.
ŵĂŬĞƐĞŶƐĞŽĨŝƚ
Digital ID designate /ĚĞŶƚŝƚǇ refer to Entity
Used partial ID Ideal target: no link
Figure 3: Enabling privacy.

Only a part of the digital ID is used to enhance the power of communication and
accessibility of the network or infrastructure. Such a partial digital ID may be
anonymized or obfuscated using cryptographic schemes to enhance privacy by
providing unlinkability. The partial digital identity can be used in the network to denote
entities such as adjacent nodes or designate functions such as routing to be carried out.
This data should as a default only enable the required functions and purpose in the
network, for example enabling packets to reach the destination. To enhance privacy,
personally identifiable data [8] should be avoided or eliminated. Clearly, this is not a
trivial task and may require compromises to work. Nonetheless, this approach at least
makes the problem to be solved transparent, instead of ignoring it. Privacy add-ons,
such as Tor [9], will still be possible, but will be added on top of a higher privacy
platform compared to today.
Most of the user’s privacy protection today is enforced in the different layers. A
privacy enhancing technique at the network level will guarantee that certain data is not
leaked to the wrong network elements while application-level privacy will protect users
in the same application domain. While there are exceptions to this, our observation is
that most privacy solutions exist for problems in the horizontal layers. However, many
privacy problems occur when information from one layer, for example the network
layer, is exploited at a different layer, such as the application or service layers. A
service can analyze network data to determine whether that is the same user or a
different one. With our approach and the way a user’s identity data is bound to the
network, services and applications are orthogonal to the user’s device ID as seen from
the network. Data disclosure can be minimized from a utilization perspective,
independent of the network, service or application. A second type of privacy problem is
the linkage of data about the user between different providers, or even at the same
provider, when the user has more than one account. This problem can be easier to
identify if the user maps privacy rules to its concept of virtual identity.
While the particular location where data is stored is part of the implementation and
deployment of the system, which we do not address in this work, the model can be
adjusted to different levels of privacy where either the user is assisted by a network
component, to optimize data transfer, or, in the extreme case, the user can hold the data,
and the links amongst the data, locally and under her full physical control.
3. Session Concept
The second problem we address in this paper is the designation of real world processes
to concepts and their implementation. When a user wants to access a service, he or she
usually undergoes a series of manual operations that will later lead to the service. For
example: the user must login in the PC, configure network access, open the right
application, type a pre-known identifier (or search for it), login again in the service
provider, select the right part of the service he needs (which may involve more
identifiers) and finally start the task she had initially thought of. The service provider,
on the other hand, also has only a limited view on the service instance and knows
nothing about networks, applications, and other parameters.
We propose that, in the sequence of a user selecting a task, a session be created
based on that task. A session is no more than the implementation of a task and, just like
in the case of a digital identity, can also be used to designate the conceptual intent of
the user. Since the session represents the task the user initially thought of, all actions
pertaining to the task are also linked to this event. The authentication, network and
service parameters, digital identities at the endpoints, resource allocation, are all
abstracted into this session. Several applications, services and digital identities can now
interact with this identifiable session without loss of the user’s initial intent.
Figure 4: Session Concept.

A session is built iteratively based on the step by step dependencies and actions in the
system, as shown in Figure 5. It brings different processes together to fulfil a certain
requirement or dependency to the user’s intent. The session may also involve multiple
devices from the user, expanding on existing mobility concepts and further supporting
media, application, protocol and network independent handovers, without ever losing
sight of the user’s true intention.
Figure 5: Session Build Up

A session can also be addressable. This permits two ways of how the system
understands the communication; either through the collection of actions and endpoints
or through the channel and associated processes. The strength of this approach is that
we can move between these two concepts, enabling both the underlying transport and
concerned application to define how the session should function or be used. While a
core router may choose to map a session to a label, the application on top can still
continue to use the endpoint and service as the addressable entity.
Addressing a session can also be useful to request information about its

participants, processes or state. Much like the identities described in the previous
section, session information is no less important in terms of user privacy. Similar
mechanisms to those applied for user data can also be applied to session data
referencing the data from the actual session. We become able to implement
mechanisms that protect the dereferencing with access control such that no one entity
can obtain data relevant to a session without proper authorization.
While we describe the session concept as an all-encompassing abstraction, the
session management protocols should be decentralized. Each domain responsible for a
part of the session data has full control over the data and determines who should have
access and can audit those services.
The same rules of privacy apply here as anywhere else. Only data that is needed to
run, maintain and update the session will be stored, scoped to where it is needed, in
particular pertaining to the communicating entities. If another entity requires session
data, access control comes into effect. Pseudonimity and other privacy enhancing
techniques can decrease the risk of linkability of the partial Digital Identity available
here with any real entities without collusion with owners of data available elsewhere,
as illustrated in Figure 3. This allows an optimized balance between the functions to be
supported and the privacy required by end users.
4. Intentity
We now address the concept of Intentity (Figure 6), which aggregates the two views
previously described. On the one hand, the word is composed of Intent, which refers to
the concept of a session (or channel) linked to a task and, on the other hand, the word
Entity (person, service provider, enterprise, or otherwise) at the endpoint of the
communication represented by the virtual identity.
Intentity
Entity: focus on
Intent: task
the identinet
driven internet
where identities
architecture
are at the edges
Figure 6: Intentity
The new Internet should weave the concepts of “intentity” into its design if the goal is
to support people (entities) communication based on the intent, or task to perform. By
presenting a communications model that better recreates our own communication and
interaction experience, Intentity is a better fit to our patterns and real-world business
models than the existing Internet model. Intentity is also a good design pattern for
developers. Whether we are dealing with an application, a service or a network
component, the abstractions in place offer rich common interfaces to manage sessions,
their participants and their tasks. New transport protocols can also make use of these
abstractions to balance flexibility in the payload and headers in terms of explicit or

referenced data, reducing packet size and setup time.
One more feature of intentity is the end-to-end security association that can be
established in terms of the channel, across endpoints and processes, instead of per layer
or application. By protecting the channel and associating key material with the
identities at the endpoints, the user can be better defended against phishing, spoofing
and hijacking attacks. Needless to say, privacy rules will be applied here as well.
5. Better usability and privacy with IDEA
In the current Internet, users are burdened with a manual step of discovery of how to
connect to other users and services. For example, a user wanting to access a bank
account to do a bank transfer would need to find and address the specific URL or
address of the bank for that specific purpose. At the network level, transferred IP
packets reveal that that particular user is accessing that specific bank.
The approach presented here would allow the Future Internet to create a session,
including the resolution step, to communicate with the account server of the bank. If
maximum privacy is chosen, packets in the network will not disclose the end user and
the service, but rather, in the last hops only, the end points related to the devices. These
could, if so desired, obscure the identity of partners in the communication. The
situation is shown in Figure 7 below.
Figure 7: Connecting to a service with IDEA

Once the session is established, if the user now wants to call the bank, additional end
points related to the phone devices will be set up at both ends. This will allow the
service to connect to the right department of customer service and access the history of
the previous transactions, allowing a higher level of understanding of the user’s needs.
The user is here in control. With a press of a button, the user could call the ABC Bank
Account or just ABC bank in a new session just like today.
A similar simultaneous enhancement of usability and privacy can be achieved
when a person wants to contact another e.g. in the “family” context. IDEA allows
controlled resolution and reachability with the identification of the permitted end
devices for this context. A policy control could only allow a limited number of persons
to call (access control) and define which best device relates to this context. The session
set up for this context would only have the network parameters needed for the
connection without knowing either that this was a “family” call or, for a privacy
enhanced solution, who is talking with whom.
6. Conclusions and Future Work
In this paper, we have brought up a number of issues towards an identity-engineered

architecture for the Future Internet as an approach addressing critical needs and
shortcomings of the current Internet. The fundamental issues relating to how virtual
and digital identities relate to the real world has been addressed and need further
discussion. We have presented our approach as it applies to user privacy and how
virtual identities and the digital identities designating them may be used in the network
while preserving privacy. The approach presented has opened a number of issues to be
addressed in future research, in particular related to data and its obfuscation in the
network. The session concept addresses a more robust approach on how to connect
applications with the underlying transport and infrastructure. Finally, the Intentity
concept puts the user’s intent at the centre. We expect this combined set of approaches
to provide a more sustainable basis for the Future Internet that addresses key issues,
such as user intentions, usability, scalability, privacy and data protection.
This paper is based on work done in the EU ICT SWIFT project [10]. We
acknowledge the contributions and work of SWIFT partners that have been the basis
for the concepts described here. We also thank participants of the Future Internet
Assembly Stockholm and preparatory workshops of the FIA events in Stockholm and
Valencia for their valuable feedback. Finally, we thank M. Mahner, Centre for Inquiry,
Germany, for helpful comments on Section 1.
References
[1] M. Bunge, Sense and Reference, Treatise on Basic Philosophy, Volume 1, Semantics I, D. Reidel
Publishing Company, Dordrecht / Boston, 1974.
[2] M. Bunge, Interpretation and Truth, Treatise on Basic Philosophy, Volume 2, Semantics II, D. Reidel
Publishing Company, Dordrecht / Boston, 1974.
[3] K. Cameron, The Laws of Identity, http://www.identityblog.com/stories/2004/12/09/thelaws.html (as in
Oct 2009).
[4] A. Sarma, J. Girao, Identities in the Future Internet of Things, Wireless Personal Communication,
Springer, 49 No. 3 (2009), 363–364.
[5] R. Moskowitz, P. Nikander, P. Jokela and T. Henderson, Host Identity Protocol, RFC 5201 (April
2008).
[6] B. Ahlgren, J.i Arkko, L. Eggert and J. Rajahalme, A Node Identity Internetworking Architecture, 9th
IEEE Global Internet Symposium (April 2006).
[7] A. Acquisti, S. Gritzalis, C. Lambrinoudakis, S. De Capitani di Vimercati, Digital Privacy – Theory,
Technologies, and Practices, Auerbach Publications (2008).
[8] OECD: OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data,
http://www.oecd.org/document/18/0,3343,en_2649_34255_1815186_1_1_1_1,00.html
[9] R. Dingledine, N. Mathewson, P. Syverson, Tor: The second-generation onion router, 13th USENIX
Securiy Symposium (2004), see also http://www.torproject.org/
[10] EU ICT SWIFT, Ref. No. 215832, http://www.ist-swift.org
IOS Press, 2010
An experimental path towards Self-

Management for Future Internet
Environments
Apostolos Kousaridas a,1, Gérard Nguengang b, Julien Boite b, Vania Conan b, Vangelis
Gazisa, Tilemachos Raptisa, Nancy Alonistiotia
a
Department of Informatics and Telecommunications, University of Athens,
Athens, Greece
{akousar, gazis, traptis, nancy}@di.uoa.gr
b
Thales Communications SA
Paris, France
{Gerard.NGUENGANG, Julien.BOITE,Vania.CONAN}@ fr.thalesgroup.com
Abstract. The current challenge for the network systems is the reduction of human
intervention in the fundamental management functions and the development of
mechanisms that will render the network capable to autonomously configure,
optimize, protect and heal itself, handling in parallel the emerging complexity.
The in-network cognitive cycle will allow the continuous improvement of
management functions of individual network elements and collectively of a whole
network system. This paper proposes the software components for the engineering
of an innovative self-managed future Internet system that will support visionary
research through experimentation.
Keywords. Self-management, cognitive networks, future internet, experimentation
1. Introduction
Communication networks are growing both in term of size and complexity. Existing
systems have serious deficiencies in effectively addressing the changing landscape of
application demand and traffic patterns. In order to address the increasing complexity,
the embodiment of autonomic capabilities in Future Internet networks and management
systems emerge as the most appealing solution. In this paper we present the concrete
experimental steps that we are investigating in evaluating the application of autonomic
management principles to real network systems and equipment. Firstly, we review the
major ingredients of self-management, and describe in particular the Monitor-Decide-
Execute (MDE) loop concept. We then outline the architecture of the distributed
software platform we are developing that implements these principles for the
management of Future Internet networks. Finally, we apply the approach to the
challenging problem of autonomic wireless network management. We conclude with a
discussion of major challenges that lie ahead.
1
2
2. Network Systems Self-Management Background
The management systems of future Internet networks are expected to embed autonomic
capabilities in order to face the increasing complexity of communication networks that
make them difficult to manage [1], [2]. This autonomic enablement implies that
networks are able to self-manage their operational features (i.e. self-configure, self-heal,
self-optimize, self-protect) [3]. Their behaviour is set from high-level policies that they
implement by dynamically adapting network parameters (e.g., routing, protocols, queue
sizes, radio frequencies) according to the varying network conditions (e.g., changes in
topology, resource availability, traffic demands).
Designing an autonomic system for network management involves several
technologies and disciplines and has received significant research effort the last decade
([4], [5], [6], [7]). Moreover, several European research projects are working towards
this direction e.g., ANA [8], BIONETS [9], 4WARD [10]. On the implementation side,
attempts are made to add more flexibility in network protocol design: Keller et al.
propose a framework for self-composing protocol stacks in multiple compartments to
replace the existing non-flexible Internet layers [11], and Manzalini provides a platform
for autonomic services composition [12]. Focused on the middleware part of the
framework, another research trend consists in integrating mobile agents in the network
to collect distributed information or perform remote computations [13]. A combination
of both mobile and stationary agents to manage mobile ones is proposed in [14].
Cognition development is an important aspect of future Internet self-managed
systems, which complements and advances the automation of configuration actions. An
in-network cognitive cycle will allow communication systems to improve their
inference and reasoning capabilities, by exploiting the feedback from previous events
or from historic data that are stored locally. In the literature, there are several simple or
more complex multidisciplinary models for cognition development e.g., [15], [16].
However, the majority of them have not being designed considering the restrictions or
capabilities that communication networks have. On the other hand, the cognitive
models that refer to communication systems do not describe in many cases the
available options and how they could be applied in a holistic networking context. Thus,
there is the need to present how such ideas could be engineered in a real-world
implementation.
3. Cognition Development
In the Autonomic Network vision, each network device (e.g., router, gateway, access
point), is potentially considered as an autonomic element. The latter is capable of
monitoring its network-related state and modifying it based on conditions that
administrators have specified. This cognitive cycle consists in constantly monitoring
this network state, making decisions and executing reconfiguration actions (see Figure
1). The cognitive cycle is implemented in software, and the autonomic element
executing this function is further referred to as the cognitive network manager (CNM).
Thanks to its inference capability, a CNM can perform rapid detection of device
anomalies or network services disruption, diagnose the root cause, compute possible
corrective actions to finally select and enforce the one that best fits the operator’s goals
and objectives. The monitoring process is carried out by the CNM’s sensors, while
effectors perform the execution of reconfigurations.
3
Figure 1. Cognitive Network Managers implement the cognitive cycle
Network devices are physically distributed and the configuration of particular

element often interplays with other nodes’ configuration. As a consequence, the
representation of the network context that each CNM uses for making decisions cannot
be limited to its local point of view. The adoption of a centralized approach in order to
provide this broader picture is not considered effective, since scalability and fault
tolerance issues incur. Thus, cooperation among neighboring autonomic elements is
required so as to exchange information that is necessary for the decision making
process.
Broadcasting messages throughout the entire network is not an efficient option,
since the autonomic management system should limit the communication to a defined
range. Considering that knowledge about an entire network is not necessary in order to
make fast local decisions either, information exchange is limited to compartments
(subsets of neighbouring network elements). As a consequence, each CNM makes local
decisions based on a situated knowledge (i.e. information gathered and exchanged
between neighbouring entities in the defined compartment view). Figure 2 represents
the compartment view of two CNMs, namely A and B. In this example, the
compartment is limited to a one hop neighbourhood, but this range can dynamically be
extended if the capturing of a broader view of the network state is necessary. However,
there is a trade-off between extending this local view and limiting the communication
cost for the management of the compartment: the larger the compartment, the more the
amount of exchanged information increases.
In the case that information broader than the knowledge confined in the
compartment view of a CNM is required for making some decisions (e.g., regarding
end-to-end connectivity), the Domain Cognitive Network Manager (DCNM) is used.
The DCNM, as it is depicted in Figure 2, is a more sophisticated CNM that can deal
with higher-level knowledge, collected by a set of subsuming CNMs in the specified
domain that it manages. Domain CNMs having this richer knowledge possibly
complemented with interactions with other DCNMs, can proceed with global decision
making, thus solving problems that standard CNMs cannot address locally, adjust
policies to fit the desired system behaviour and learn from previous experiences to
improve the impact of future decisions (upper part of Figure 1).
4
Figure 2. One-hop compartment views
4. Engineering the Cognitive cycle for Network Management
4.1. Software requirements
Implementing the architecture described in section 3, where distributed cognitive

managers are embedded in network elements, implies meeting several software
requirements. First of all, the network management framework needs to be fully
distributed in order to scale up to large or constrained networks and to be fault tolerant.
Moreover, it should provide features that are necessary to implement the cognitive
cycle. This includes functionalities allowing a CNM to:
• perceive the network state and act on it
• communicate with neighbouring entities
• make fast decisions in order to deal with applications or services that are not
tolerant to delays.
This last point implies that a CNM manipulates knowledge (representation of the
network context, operator policies). The distribution of entities means that knowledge
is distributed. As a consequence, the knowledge representation must be uniform in
order for entities to exchange understandable information.
Besides the requirements that are needed in order to implement the cognitive cycle,
a key issue for the viability of the proposed in-network management solution is the
integration in network devices. The various characteristics of such equipment imply
specific software requirements that should also be considered. In fact, devices in
today’s networks are widely heterogeneous and often resource-constrained. In order to
fit these characteristics, the software solution must be easily adaptable. Modularity is
necessary not only to plug the platform easily on any type of devices but also to load
only required parts of it on resource-constrained devices.
4.2. Framework description
The framework we have implemented in the Self-NET project [17] meets the
requirements stated above. Developed in Java, its main characteristics are full
distribution of cognitive entities and components modularity. A java-based solution has
5
Figure 3. Software modules of the Cognitive Network Manager
been selected for the experimentation, since it offers platform-independence and

embedded distributed computing features. However, alternative programming
environments (e.g., scripting languages) could be selected, especially in the case of
resource-constrained devices (e.g., wireless mesh network router).
Figure 3 depicts the different components of the platform, which main benefit
resides in the simplicity of adding, deleting or changing one of its components (e.g.,
network element controllers need to be adapted to the type of device the CNM is
embedded in). This modularity has been brought by developing the framework in a
component-oriented way, on top of OSGi (Open Services Gateway initiative) [18].
Each component of the cognitive network manager is implemented as a module, called
a bundle in the OSGi terminology.
Some of these modules undertake to capture the network context or to enforce the
decided (re-)configurations:
• Topology service: based on a regular exchange of hello messages, constructs,
updates and exchanges adjacency tables that reflect the physical network topology.
• Discovery service: maintains information concerning neighbouring cognitive
network managers (e.g., IP addresses, network interfaces used to reach them).
• Network Element Controller: gathers network equipment status and publishes
these different pieces of information (interfaces, routing…) in the blackboard. It
also provides means to enforce reconfigurations in the network device.
The Blackboard is a key component of the framework. It provides writing and
reading facilities in a shared space, where information are semantically organized in
different topics. This component can be seen as the short-term memory of the system,
where recently gathered information can be published or retrieved.
6
A Cognitive Network Manager needs to communicate with neighbouring entities.

This function is assured by the Communication Service that provides communication
functions with high-level semantics (communication acts, content identification).
During the execution of the cognitive cycle, some specific tasks might be
necessary (e.g., sending information periodically or computing some specific
information needed for possible reconfigurations). Behaviours are in charge of these
specific tasks and can be configured to be executed only once or periodically. The
execution of a behaviour is triggered by the Scheduler.
Finally, the reasoning capabilities of a CNM rely on the Inference Engine module,
which can be seen as the brain of the system. The Jess inference engine has been
integrated in our framework for such purpose [19]. A-priori knowledge is loaded into it.
This a-priori knowledge is composed of operator policies and an ontology [20], which
is the appropriate tool providing a uniform way to represent the “world” and capture a
domain technical know-how. During the execution of the cognitive cycle, collected
information are confronted to the policies defined by administrators to autonomously
detect anomalies and face them. The inference engine makes high-level decisions that
may need additional information for reconfiguring the network equipment. Such
specific additional information are computed by behaviours and published in the
blackboard.
Each CNM and Domain CNM, runs this set of modules. The difference between
them is mainly the level and scope of knowledge they manipulate. In fact, Domain
CNMs manipulate richer knowledge, resulting from CNMs inferred data or coming
from exchanges with other DCNMs. Moreover, computations and decisions a DCNM
makes are different from those a CNMs processes. Being at a higher level, the response
time of their decisions can be longer whereas CNMs role is to react fast.
5. Experimentation on Capacity Optimization of Future Internet Wireless

Networks
One of the key target areas where Autonomic management can bring significant
benefits is wireless networks. In such a wireless infrastructure, network (self-)
management is particularly challenging because of the volatile and unpredictable nature
of the wireless medium and the mobility patterns of terminal devices. Due to the strong
demand for efficient wireless resources utilization, wireless network planning and
management is a sophisticated task, which requires expert knowledge, especially in a
dense urban environment. Network nodes (e.g., access points) that have several
configuration capabilities and observe their local operational status should coordinate
to improve overall performance and the complex problem of efficient wireless resource
management that arises. A centralized approach is not effective due to scalability and
complexity issues. Thus, a more localized and distributed architecture is necessary for
the orchestration of the various heterogeneous or homogenous access points (APs).
5.1. Radio Resource Allocation Problem in Wireless Networks
The CNM model is applied to the coverage and capacity optimization of future Internet
wireless network in order to illustrate how collective interaction of CNMs can
automate and solve a network management problem about resource allocation. In order
to present and test the key functionalities of the CNM model, we have selected a
specific network management problem, from the family of coverage and capacity
7
Figure 4. Sample Wireless Topology and CNMs
optimization of Future Internet wireless network.

Particularly for IEEE 802.11a/b/g, efficient radio resource allocation in a dense
urban environment can be quite a challenge, due to the finite number of interference-
free channels available. Channel allocation in IEEE 802.11a/b/g systems may result in
conflict where more than one adjacent (in terms of radio coverage) access points use
the same or different channels but with a substantial nonetheless spectrum overlap, thus
causing a substantial drop in performance. Channel assignment is a determinant factor
of performance in WLAN installations that requires intelligence and coordination to
achieve maximum potential.
In the huge mass consumer market segment targeted by modern WLAN
technologies, the typical consumer does not possess the technical expertise required to
fully comprehend and efficiently solve resource allocation problems e.g., frequency
planning. Moreover, existing standards for popular wireless access technologies do not
provide the capacity to interact with peers on the basis of local and exchanged
information for purposes of improving coverage and capacity. Therefore, the
introduction of an autonomic mechanism (i.e. CNM) that undertakes the discovery of
conflicting frequency plans and initiates reactive measures to adapt frequency
assignments, collaboratively among the concerned network elements is necessary.
5.2. Cognitive Network Managers for dynamic optimization of Frequency Channel
In this sub-section it is presented how the CNM framework is used in order to handle
and automate the problem that is described in section 5.1. Moreover, the role of each
component of the CNM is outlined.
We consider a dense wireless network environment consisting of several APs (e.g.,
IEEE 802.11), each embedding the CNM, while a Domain CNM is assigned for the
underlying APs (Figure 4). The CNM that is placed per AP undertakes a) to make
deductions about its operational status b) to proactively prepare solutions to face
possible problems and c) to react fast when a problem occurs by enforcing the
anticipated reconfiguration actions, thus seizing the need for human intervention.
In the context of the frequency allocation problem, the knowledge that the CNMs
need in order to reason and make decisions refers to the operational status of an AP that
is deduced through various metrics (e.g., Signal to Interference plus Noise Ratio,
packet error rate, number of associated mobile devices). In order for a CNM to
understand its current operational state, the metrics that it gathers from the AP are
8
ED͗<ŶŽǁůĞĚŐĞ ĂƐĞ
;KŶƚŽůŽŐǇ͕WŽůŝĐŝĞƐͿ ED͗/ŶĨĞƌĞŶĐĞ ŶŐŝŶĞ ED͗ůĂĐŬďŽĂƌĚ ED͗E ED͗ĞŚĂǀŝŽƵƌ
0: Loading Ontology and Policies 1: Periodic gathering of metrics

into the IE (at bootsrap) values, written on the
blackboard
2.2: Information retrieval

2.1: Retrieval of information needed to compute specific tasks
3.2: Checking that 3.1: Results of the specific computation are published on the BB
expected conditions
are met
5: Retrieve actions to be
executed
4: If a condition is not met,
publish the action resulting
from the decision-making 6: Retrieve specific parameters
process possibly necessary to enforce a
7: Enforcement of the
new configuration (result(s) of new configuration on
behaviour(s) specific the network
computation(s)) equipment
Figure 5. Flow Chart for internal interaction of CNM modules
mapped to the concepts that are described in the ontology, including the concept of
“InterferenceLevel”. Moreover, the decision making process relies on a set of policies
defined by the operator. For instance in our use case, two rules can be defined:
• A first one in order to estimate the level of interference (the value of threshold
can be configured):
If ( SINR ) >= threshold Then InterferenceLevel is HIGH
• A second one in order to actually make the decision of changing the channel
frequency to face a detected HIGH level of interference:
If ( InterferenceLevel is HIGH ) Then ChangeFrequency
The initial step of a CNM after its initiation includes the loading of the ontology
and the rules that are defined above into the inference engine that is responsible for
reasoning. The interactions of the CNM modules are briefly depicted in Figure 5, and
the role of the essential CNM components instantiated for this particular scenario are
presented as follows:
• Step 1: at regular intervals of time, the Network Element Controller (NEC)
provides updates of specific metrics and performance parameters of the access
point (e.g., Signal to Interference plus Noise Ratio (SINR), packet error rate,
number of associated devices, operational channel) and publishes these raw data
into the appropriate topic of the blackboard (e.g., SINR values are published in a
topic named “Interference”).
• Steps 2 and 3: this step is composed of multiple tasks executed in parallel, where
different components realize the following processes, respectively:
o Inference Engine (2.2 and 3.2 in Figure 5): retrieves information stored in
the different topics of the blackboard to check if expected conditions are met.
In our example, measurements gathered by the NEC and stored in the
blackboard are retrieved and compared to the defined rules in order to
determine whether the interference level is acceptable (LOW or MEDIUM
levels) or not (HIGH). In the case where interference level is considered
HIGH, the second rule (presented above) is triggered thus producing the
order of executing the action ChangeFrequency.
9
o Behaviours (2.1 and 3.1 in Figure 5): realize specific tasks regarding to the
problem that a CNM addresses. For instance, in the described use case, a
behaviour uses the Communication Service to exchange information with
neighbouring CNMs (e.g., currently used channel). All the information that
is received from neighbours is maintained in the Discovery Service.
Another behaviour is in charge of executing the specific task of selecting the
most appropriate frequency channel to use. To achieve this, needed
information is retrieved from the corresponding topics in the blackboard
(local metrics) or from the Discovery Service (frequency channels used by
neighbours and number of devices connected to them). The most appropriate
frequency channel is then selected by minimizing the objective function
b
∑
i =a
w ∗ Overlap(Ch , Ch ) , where:
i i j
- Ch i is the channel of the APs that are sensed by the AP j,

- wi is the number of users that are connected per neighbouring AP,
- Overlap (Ch i , Ch j ) provides the level of channels i and j theoretical
interference overlap. An example of this function is provided in [21].
The result of this channel selection is published in a dedicated topic of the
blackboard, named “optimalFrequencyChannel”.
• Step 4: in the case that the Inference Engine triggers a rule that orders a
reconfiguration action, this last is published in a dedicated topic of the
blackboard, named “actions”. For instance, the “changeFrequency” resulting from
the second rule, in this use case, is stored in the topic “actions” of the blackboard
in order for the Network Element Controller to deal with the corresponding
reconfiguration in the following steps.
• Steps 5, 6 and 7: these steps actually involve the Network Element Controller
in dealing with the reconfiguration order. The NEC is triggered when an action is
ordered in the respective topic of the blackboard (entitled “action”) and should
change the network equipment accordingly. In the specific example, the action
includes the change of the existing channel of the AP with the most appropriate
value, computed by the corresponding behaviour and stored in the topic
“optimalFrequencyChannel” of the blackboard. Finally, the NEC retrieves this
optimal frequency channel and enforces the new configuration.
As a result, the Cognitive Network Manager locally executing the cognitive control
loop, as it is discussed in this section, provides an efficient way to optimize frequency
channel allocation in a dense wireless network environment.
Furthermore, the domain CNM supports the behaviours of local CNMs as well as
some additional behaviours that emerge due to the greater spatial situation awareness
and configuration capabilities that is collectively provided by the underlying CNMs. In
the specific network management case the domain CNM can include the following
behaviours: a) check the coverage levels of the network area, b) activate an Access
Point, c) deactivate an Access Point. Similarly, the domain CNM uses the
communication means that its device offers in order to provide the Topology service,
the Discovery service, and the Communications service.
The CNM model described above could be applied to various other network
management problems, for coverage and capacity optimization, such as load balancing,
handover parameter optimization, QoS parameter optimization or even for fault
management tasks e.g., cell outage detection.
10
6. Conclusions
The automation of the existing network management systems is very limited as well as
their ability to collectively address complex management problems. The degree of
cognition is very small, since machine learning techniques or reasoning tools are not
extensively used. CNM attempts to provide the software architecture for a realistic and
implementable self-managed network system. The inherent distribution of cognitive
agents as well as components modularity, and the adoption of an open standard (i.e.
OSGi) assure the applicability of CNM in the Future Internet.
Acknowledgement
This work is supported by the European Commission Seventh Framework Programme

ICT-2008-224344 through the Self-NET Project (https://www.ict-selfnet.eu).
References
[1] Strassner, J. K., “Autonomic Systems and Networks: Theory and Practice”, 10th IEEE/IFIP Network
Operations and Management Symposium,(NOMS) , pp. 588-588, 2006.
[2] Ganek, A. G., “The dawning of the autonomic computing era”, IBM Systems Journal, 2003.
[3] Horn, P., "Autonomic computing : IBM's perspective on the state of Information Technology", 2001.
[4] M. A. Siqueira, F. Luciano V. Rafael Pasquini, M. Magalhães, “An Architecture for Autonomic
Management of Ambient Networks”, Autonomic Networking, pp. 255-267, 2006.
[5] C. Foley, S. Balasubramaniam, E. Power, M. Ponce de Leon, et al. “A Framework for In-Network
Management in Heterogeneous Future Communication Networks”, MACE, 2008.
[6] Jennings, B., Van der Meer, S., Balasubramaniam, , et al. .“Towards Autonomic Management of
Communications Networks”, IEEE Communications Magazine 45(10), pp. 112–121, 2007.
[7] R. Chaparadza, S. Papavassiliou, T. Kastrinogiannis, M. Vigoureux, et al. Creating a viable Evolution
Path towards Self-Managing Future Internet via a Standardizable Reference Model for Autonomic
Network Engineering. FIA Prague 2009 Conference, published in the FI Book produced by FIA, 2009.
[8] The ANA Project, [Online]. Available: http://www.ana-project.org [Accessed: Jan. 20, 2010]
[9] The BIONETS Project [Online]. Available: http://www.bionets.eu [Accessed: Jan. 20, 2010]
[10] The 4WARD Project [Online]. Available: http://www.4ward-project.eu [Accessed: Jan. 20, 2010]
[11] A. Keller , T. Hossmann , M. May, G. Bouabene, C. Jelger, C. Tschudin, “A System Architecture for
Evolving Protocol Stacks”, Computer Communications and Networks. (ICCCN), pp. 1-7, 2008.
[12] Manzalini A., Zambonelli F., “Towards Autonomic and Situation-Aware Communication Services: the
CASCADAS Vision”. Proceedings of the IEEE Workshop on Distributed Intelligent Systems:
Collective Intelligence and Its Applications (DIS’06) , pp. 383-388, 2006.
[13] Lefebvre, J. Chamberland, S. Pierre, S. “A Network Management Framework Using Mobile
Agents”, Journal of Computer Science , 2005.
[14] P. Ray, N. Parameswaran, L. Lewis, G. Jakobson, “Distributed Autonomic Management: An Approach
and Experiment towards Managing Service-Centric Networks”, Internat. Conf. on Service Systems and
Service Management, pp. 1-6, 2008.
[15] Dave Cliff, “Biologically-Inspired Computing Approaches To Cognitive Systems: a partial tour of the
literature”, Technical Report, http://www.hpl.hp.com/techreports/2003/HPL-2003-11.html.
[16] D. Vernon, G. Metta, G. Sandini, “A Survey of Artificial Cognitive Systems: Implications for the
Autonomous Development of Mental Capabilities in Computational Agents”, IEEE Transactions on
Evolutionary Computation, Special Issue on Autonomous Mental Development, 2007.
[17] Self-NET Project, [Online]. Available: https://www.ict-selfnet.eu. [Accessed: Jan. 20, 2010]
[18] OSGi Alliance, [Online]. Available: http://www.osgi.org. [Accessed: Jan. 20, 2010]
[19] Jess: The rule Engine for the Java Platform, [Online]. Available: http//www.jessrules.com
[20] D. Fensel, “Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce”,
Springer-Verlag, 2001.
[21] Arunesh Mishra, Suman Banerjee, William A. Arbaugh: Weighted coloring based channel assignment
for WLANs. Mobile Computing and Communications Review 9(3): 19-31, 2005.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-105
Manageability of Future Internet Virtual

Networks from a Practical Viewpoint
J. Rubio-Loyolaa,1, A. Astorgab, J. Serratb, L. Lefevrec, A. Cheniourc, D. Muldowneyd,
S. Davyd, A. Galise, L. Mamatase, S. Claymane, D. Macedof, Z. Movahedif, G. Pujollef,
A. Fischerg and H. de Meerg
a b
CINVESTAV Tamaulipas, Universitat Politècnica de Catalunya, cINRIA, d Waterford
Institute of Technology, eUniversity College London, fLIP6, gUniversity of Passau
Abstract. The Autonomic Internet project [1] approach relies on abstractions and
distributed systems of a five plane solution for the provision of Future Internet
Services (OSKMV): Orchestration, Service Enablers, Knowledge, Management
and Virtualisation Planes. This paper presents a practical viewpoint of the
manageability of virtual networks, exercising the components and systems that
integrate this approach and that are being validated. This paper positions the
distributed systems and networking services that integrate this solution, focusing
on the provision of Future Internet services for self-configuration and self-
performance management scenes.
Keywords. Virtualisation, Management Plane, Knowledge Plane, Service

Enablers Plane, Orchestration Plane, Self-configuration, Self-performance
Introduction
Networks are becoming service-aware. The network’s design is moving towards a

different level of automation, autonomicity and self-management. The Future Internet
(FI) will have many of its core features and functions based on virtualized resources [1].
As such management of Virtual Networks becomes a fundamental capability in Future
Internet. The Autonomic Internet (AUTOI) solution [2] consists of distributed
management systems described with the help of five planes: Orchestration, Service
Enablers, Knowledge, Management and Virtualisation Planes. These distributed
systems form a software-driven network control infrastructure that will run on top of all
current networks and physical infrastructures, to provide an autonomic virtual resource
overlay. The five planes gather observations, constraints and assertions, and apply rules
to these to generate service-aware observations and responses in order to converge to
optimal service deployments and optimal service maintenance.
A number of European projects are currently addressing Future Internet research
problems that include, the design and validation of Autonomic Network Architectures
[4], Biologically-inspired Autonomic Networks [5], Component-ware for Autonomic
Situation-aware Communications and Services [6], Opportunistic Communications [7],
1
On the leave from Universitat Politècnica de Catalunya, now at CINVESTAV Tamaulipas – Km. 5.5
Cd. Victoria-Soto La Marina, 87130 Tamaulipas Mexico. jrubio@tamps.cinvestav.mx
106 J. Rubio-Loyola et al. / Manageability of Future Internet Virtual Networks
new Future Internet architectures [8] and self-* properties in wireless networks [9].
The Autonomic Internet (AUTOI) approach consists of orchestrated autonomic
management systems [3]. The blocks of the AUTOI approach are graphically
represented in Fig. 1. Each autonomic system contains policy, context, discovery and
other supporting services. Autonomic management systems are federated through
orchestration services of the same nature i.e. policy, context, discovery, etc.
Figure 1. Functional Blocks Architecture of the Autonomic Internet (AUTOI) Approach
1. Future Internet Application Scenario
Consider an application service that provides large amounts of diverse-nature

information, such as multimedia files or information to users with different profiles.
Such information stored on servers distributed in a given geographic area. Users use
different types and terminal manufacturers and their position changes continuously. In
order to cope with different types of users, especially users with security requirements,
the system will establish virtual private networks (VPN) probably with encryption.
Users access the network by means of various wireless access technologies. We
assume a mobile Internet environment offered by the family of IEEE standards.
Specifically, it is assumed that there are access points for local area network IEEE
802.11 (Wi-Fi), wide area network fixed and mobile (IEEE 802.16 and IEEE 802.16e
respectively) and regional area network IEEE 802.22 (WRAN). Change between access
technologies (Vertical Handover) should be automatic and transparent to the user,
depending on factors like: offered service characteristics; user's profile; signal
intensity; time response of the switching process; position, speed and direction of
movement of the users; traffic, load and applications supported by the sub-networks;
cost and grade of service.
The above scenario will need a management system that ensures a transparent and
fast delivery of the service that the clients have contracted. This will require among
others, the following tasks: Deploy appropriate management systems that can support
the provision of the services within the appropriate resources; Setting up VPNs on
demand, depending on the user and network’s context; Support for automatic vertical
handover to ensure the best possible access to the network; Support for the
management communication overlays’ setting up with uniform distribution of traffic
load; Reaction to Quality of Service degradations identifying their causes and restoring
the services concerned in a transparent manner.
J. Rubio-Loyola et al. / Manageability of Future Internet Virtual Networks 107
2. Functional Components of the AUTOI Approach
This Section describes the functional blocks of the AUTOI solution.
2.1. Autonomic Network Programming Interface (ANPI)
The Autonomic Network Programming Interface (ANPI) implements the functionality

of the Service Enabler Plane (SEP) [2]: new programmatic enablers to allow code to be
deployed and then executed or activated on the Network entities, and a safe and
controlled deployment of any kind of services (resource- and consumer-facing services).
The ANPI provides a programming interface that is used by the AMSs and DOCs (both
described below), in order to deal with the deployment and administration of services
and management components. The ANPI consists of a Service Deployment Daemon,
which can be run in any virtual machine/router and/or a physical machine. Once it is
instantiated, the ANPI takes care of commands to enable in-network programmability.
2.2. Autonomic Management System (AMS)
Autonomic Management Systems implement functionalities of the Management Plane

and Knowledge Plane [2]. It uses a dedicated set of models and ontologies. Mapping
logic enables the data stored in models to be transformed into knowledge and combined
with knowledge stored in ontologies, to provide a context-sensitive assessment of the
operation of one or more virtual resources. The AMS interface with one or more
Distributed Orchestration Components (DOC, described later), which enable the former
to federate with other AMS as to provide end-to-end context-aware services. This
component reacts to context-change events that can be for example, on-demand service
requests, statistical fluctuations of QoS, faults taking place in the network, and so forth.
This component is currently being validated with a Context-aware Policy-Based
System with ontology-based reasoning capabilities.
2.3. Distributed Orchestration Component (DOC)
The Distributed Orchestration Component (DOC) provides a set of framework network

services and partially implements the functionality of the Orchestration Plane [2].
Framework services provide a common infrastructure that enables all components in
the system managed by the Orchestration Plane to have plug-and-play and unplug-and-
play behaviour. Applications compliant with these framework services share common
security, metadata, administration, and management services.
2.4. Context & Information Service Platform (CISP)
The Context & Information Service Platform (CISP) is a narrow functionality

Knowledge Plane [2]. It is an infrastructure for collection, processing and
dissemination of context information, as a support for the deployment, evolution and
autonomy of communication services and applications (context-aware applications and
services). Context-aware control functions is essential in guaranteeing both a degree of
self-management and adaptation as well as supporting context-aware communications
that efficiently exploit the available network resources.
2.5. Virtualisation System Programmability Interfaces (vSPI)
The vSPI [2] is used to enable the Orchestration Plane (and implicitly the AMSs under
control of the Orchestration Plane) to govern virtual resources, and to construct virtual
services and networks that meet stated business goals having specified service
requirements. The vSPI contains the “macro-view” of the virtual resources that a
particular Orchestration Plane governs, and is responsible for orchestrating groups of
virtual resources in response to changing user needs, business requirements, and
environmental conditions.
2.6. Virtualisation Component Programmability Interfaces (vCPI)
The vCPI [2] is an interface that allows managing Virtual Resources (e.g. Virtual
Routers) from within a Physical Component. It provides methods that support the self-
configuration for Virtual Links and Virtual Routers Management. Links Management’s
methods provide support to instantiate, remove, and modify virtual links. Virtual
Routers Management’s methods are used for example to register, start and shutdown a
Virtual Router. Other supporting methods are used for example to get associative
identifiers with Virtual Routers and Virtual Links on a component respectively. It also
implements methods that allow monitoring information and that are the key
instruments to enforce the self-performance and -fault management functions. A
selection of these methods are: cpuUsage, availableCPUs, availableRAM, totalRAM,
assignedRAM, stateCurrent (e.g. state of a Virtual Router), usedBW, pktsLost, etc.
Methods are invoked by the AMSs, the DOCs or even the ANPIs.
2.7. Model-based Translator (MBT)
The Model-based Translator (MBT) [2] is a software package that translates commands
and messages from a technology independent “network” language to device specific
commands and configurations, and also can convert device specific monitoring
messages into a technology independent language. The MBT uses a detailed
information model of communications networks in combination with model-to-text
translations templates to carry out the translations. It is intended for use by network
management software designed to manage heterogeneous networking equipment and
services without understanding the associated data models. This component is used by
the AMSs to decouple their management decisions from the network and resource
technology in which the services are deployed.
3. Self-configuration Management Support
This section describes with the help of illustrative interacting methods the support that
the above software components provide in self-configuration scenes.
3.1. On-demand Setting-up of Virtual Infrastructures
Virtual infrastructures are set up prior service deployment. The components’

interactions for this initial step are shown in Fig. 2.
DOC AMS vSPI vCPI ANPI CISP
defineManageableResources()
registerManageableResources()
manageableResourcesRecognition()
discoverBasicServices()
defineScopeOfMgmtPlane()
registerMgmtPlane()
setStartUpHighLevelGoals()
detectUser(profileX)
Authorisation,
Authentication, Accounting
updateContextInfo:
newServiceInvocation[Service] LocationA
orchestrateServiceDeployment [Service]
Figure 2. Relevant Interactions for Setting-Up of Virtual Infrastructures

The availability of resources is defined by the Virtualisation Component
Programmability Interfaces (vCPI) that control the physical resources
(defineManageableResources() in Fig. 2). Once these are defined, the management
entities and components need to have references to these available resources
(registerManageableResources()). This information is registered in the Context &
Information Service Platform (CISP). The Autonomic Management Systems (AMSs)
in turn recognize these resources (manageableResurcesRecognition()), so that they can
define the scope of the resources they control (defineScopeOfMgmtPlane()). The
Autonomic Network Programming Interface (ANPI) performs the discovery of basic
services that reside in the manageable resources (discoverBasicServices()) and registers
them in the CISP. At this stage the CISP is updated with resources and basic services
that are subject to management tasks for further usage.
The next step is the registration of AMSs in the Distributed Orchestration
Component (DOC) (registerMgmtPlane())for orchestration purposes. Based on the
scope of the AMSs the DOC pushes initial high-level start up goals
(setStartUpHighLevelGoals() in Fig. 2), so that the AMSs can define the internal
mechanisms and policies with which they would control their resources and basic
services during the start up of their network infrastructures. High-level start-up goals
are intended to create a cooperative environment in which the AMSs could share
information with other domains, all in all, orchestrated by the DOC.
Consider an end-user approaching the wireless environment in Location A as
graphically shown in Figure 3, where a unique wireless access controller is able to
connect the end-user. The ANPI (Autonomic Network Programming Interface) detects
the user profile (detectUser(profileX) in Fig. 2) and makes sure that the end-user is
subscribed to an AUTOI service (Authorization, Authentication, Accounting (AAA) in
Fig. 2). Successful invocations are updated in the CISP (updateContextInfo: LocationA
in Fig. 2), namely user’s Location A. The ANPI communicates with the AMSs that a
new service is being invoked and that it needs to be provisioned with specific
guarantees (newServiceInvocation[Service] in Fig. 2). As the AMS Wireless is not
capable of providing the content to the end-user on its own, the DOC is required to
orchestrate the deployment of the content service with the help of other AMSs that it
has subscribed (orchestrateServiceDeployment[Service] in Fig. 2).
Figure 3. End-user Service Configuration

End-user service deployments can be started on demand by the end user contacting
an Autonomic Management System (AMS) domain, or contacting the user interface of
the Distributed Orchestration Component (DOC). In any case, a number of negotiation
rounds among Fixed and Wireless AMS systems are coordinated by the DOC using its
behaviours’ tools with the aim to define what services are provisioned by which AMS.
The services are anything needed to provision the application services to the user:
content services, connectivity services, management services, storage services, access
services, and so forth. Negotiation-wise [2] the DOC supports a service marketplace
where the AMSs offer and publish their services (svceOffer&Publish:[Services] Fig. 4).
The negotiation phase is supported by the core functionalities of the Distributed
Orchestration Components, taking into account the self- governance, -distribution and -
federation behaviours of the AMSs. Negotiations are triggered by the DOC and are
represented as a loop between all functional entities (coordinateNegotiation:[Service]
in Fig. 4). The aim is to determine the specific AMS that will provision the end-user
application service and the management services and resources that will be
compromised for such a purpose. The DOC starts the deployment of the AMSs
(startAMSDeployment [AMSs, HLGoals,Svc]) supported by the ANPI to deploy the
corresponding management components into the virtual resources
(newAMSDeployement[AMS, HLGoals, Svc] in Fig. 4). It is worth mentioning that the
configuration and maintenance of application services passes through an effective and
systematic refinement process of the high-level directives that the DOC provides to the
AMSs (deriveEnfPolicies(AMS, HLPoliciesAndGoals):ContextInfo, EnfPolicies) for
each AMS in Fig. 4). The AMS administrator instantiates a policy continuum and
refines the corresponding policies that will be used to govern the management entities.
A data model is created with the help of the vCPI interfaces for each AMS and it is
registered in the CISP platform (createDataModel(AMS, ContextInfo) in Fig. 4). It
describes the characteristics of all virtual resources and virtual links/topologies that are
used for the provision of the application services. It also describes the associations
between Components and virtual resources to minimize impact on the to-be-deployed
and recently instantiated AMSs. To create this data model the local context
environment of the AMSs is used.
DOC AMS AMS vSPI vCPI ANPI CISP

Fixed Wireless
svceOffer&Publish: [Services]
svceOffer&Publish: [Services]
coordinateNegotiation: [Service]
Negotiation, Negotiation, Negotiation, Negotiation, Negotiation, Negotiation,

Distribution, Distribution, Distribution, Distribution, Distribution, Distribution,
Federation, Federation, Federation, Federation, Federation, Federation,
Governance Governance Governance Governance Governance Governance
startAMSDeployment [AMSs, HLGoals, Svc]

newAMSDeployment [AMS Wireless, HLGoals,Svc]
newAMSDeployment [AMS Fixed, HLGoals,Svc]
deriveEnfPolicies(AMS, HLPoliciesAndGoals): ContextInfo, EnfPolicies

deriveEnfPolicies(AMS, HLPoliciesAndGoals): ContextInfo, EnfPolicies
instantiateAMSDesployment
(AMS, EnfPolicies, ContextInfo) instantiateAMSDesployment(AMS, EnfPolicies, ContextInfo)
createDataModel(AMS, ContextInfo)
createVirtualNetworks(Wireless Virtual Elements)
createVirtualNetworks(Fixed Netwrok Elements)

subscribeToContextInfo(AMS Wireless, ContextInfo)
subscribeToContextInfo(AMS, ContextInfo)
subscribeToContextInfo(DOC, ContextInfo)
Figure 4. Interactions for the negotiation and setting up of virtual infrastructures

The AMSs now have all the information they need to create Virtual Infrastructures
that will support the services they compromised during the negotiation. The AMSs
enforce configuration policies to create the Virtual Routers and Links and to activate
the network and resource facing services as well as content services
(createVirtualNetworks(Virtual Elements) in Fig. 4, see also Virtual Infrastructures
pointers in Fig. 3). Each AMS exhibits self-governance properties. AMSs have internal
policies for the creation of virtual infrastructures which control virtual and non-virtual
resources, e.g. CPU processing, memory assignment, and distribution of traffic load for
the services, etc. Having the AMSs created the virtual infrastructures, AMSs subscribe
to relevant context information identified earlier (subscribeToContextInfo (AMS,
ContextInfo) in Fig. 4) with the aim to react to statistical changes of the to-be-
configured service. Similarly, the DOC subscribes to relevant context information that
will drive the inter-AMS domain management functions, e.g. setting up, activation and
release of virtual links between AMS domains.
3.2. On-demand Deployment of End-user Services
This Section describes the actual deployment of the end-user service.

In our running scenario the setting up of the virtual infrastructure is preceded by an
end-user approaching the wireless environment in Location A. This is updated in the
Context & Information Service (CISP) Platform (updateContextInfo:LocationA in Fig.
5). The Autonomic Management System (AMS) Wireless senses the end-user location
and grants it access. This is sensed by the AMS_C (contextSensing(user):LocationA in
Fig. 5) as this information is part of the context information to which it subscribed
earlier. AMS_C executes the management tasks to fulfill the end-user requirements
according to its profile and the high-level goals compromised with the Distributed
Orchestration Component (DOC). The result of these management tasks is the setting
up of a VPN between an edge of its management domain (defined by the DOC in the
High-Level goals) and the edge router with which the wireless access controller A will
hand in the content to the end user (setUpVPNC1(ingress, egress) in Fig. 5). The
setting up of VPNC1 is achieved with the help of the vCPI and the ANPI components.
Similarly, AMS_B sets up a VPN for the same purposes (setUPVPNB1(ingress,
egress)). Finally, the DOC interconnects the domains (due to security concerns) with
the help of the Virtualisation System Programmability Interfaces (vSPI) and the
Autonomic Network Programming Interface (ANPI). The end-user service is finally
deployed and this information is updated in the CISP (deploymentUpdate() in Fig. 5)
by the ANPI. Eventually, the availability and the context information of the
deployment is made available by the CISP to all other planes
(updateContextInfo:serviceDeployed, LocationA in Fig. 5). The DOC subscribes to
inter-AMS-domain contextual information for coordination and maintenance purposes
(subscribeContextInfo(OP_ContextInfo) in Fig. 5). The actual End-to-End
configuration of the service is graphically depicted in Figure 3.
DOC AMS_B AMS_C AMS vSPI vCPI ANPI CISP

Wireless
updateContextInfo:
contextSensing(user):
contextSensing(user): contextSensing(user): LocationA
LocationA
LocationA LocationA
connectUser()
updateContextInfo:
setUpVPNC1(ingress, egress) LocationA
contextSensing(): setUpVPNB1(ingress, egress)
LocationA, VPNB1,
VPNC1
interConnectDomains(AMSs)
deploymentUpdate()
updateContextInfo:
serviceDeployed, LocationA
subscribeContextInfo(OP_ContextInfo)
Figure 5. Interactions for the Deployment and Activation of Service
4. Self-performance Management Support
Autonomic Management Systems (AMSs) exhibit self-governance properties while

enforcing their management decisions, aligned to their internal policies, and also to the
previously agreed goals.
Consider that AMS_B in our scenario has subscribed to track packet losses in two
Virtual Routers (VR) VRa1 and VRb1 that support the end-user content service of our
use case. Packet losses are retrieved periodically from the Virtualisation Component
Programmability Interfaces (vCPI) and updated periodically in the Context &
Information Service (CISP) Platform. Specifically for VRb1 these are represented with
interaction getPerformanceInfo(VRb1):packetLoss in Fig. 6. When VRb1 has packet
losses higher than a given threshold (updateContextInfo:VRb1 PktLssUP_THR Fig. 6)
the CISP issues an alarm that is basically a context change event indicating that such a
threshold has been crossed upwards. This is sensed by AMS_B (contextSensing(VRb1):
pktLssUP_THR in Fig. 6) which eventually triggers a recovery process in component B
(reassignResources(C): ComponentB in Fig. 6). This process entails a reassignment of
resources that results in the migration of the end-user content service traffic from VRb1
to a less used VR to reduce congestion of the former (migrateService(contentService)).
AMS_B reserves some spare capacity for eventual QoS degradation recovery. The
migration is enforced by the AMS_B in the vCPI with the programmability support of
the ANPI. Other resources reassignment options include increasing the CPU for the
affected router or a migration of part of the supported services to spare resources.
Finally, AMS_B updates its subscription to context variables monitoring aligned to the
updated assignment and service deployment (subscribeToContextInfo(AMS,
ContextInfo) in Fig. 6).
DOC AMS_B AMS_C AMS vSPI vCPI ANPI XINA CISP

Wireless
getPerformanceInfo(VRb1):packetLoss
updateContextInfo: VRb1
contextSensing(VRb1) PktLssUP_THR
: pktLssUP_THR
reassignResources(C):
ComponentB migrateService(contentService)
subscribeToContextInfo(AMS, ContextInfo)
deploymentUpdate()
updateContextInfo:
serviceMigrated:AMS_B
Figure 6. Selected Intra-AMS Self-performance Management Interactions

The ultimate goal of the AUTOI components is to maintain services taking the best
proactive actions in case the service performance is degraded. Figure 7 shows the result
of a self-performance management scene like the one described above. The picture
depicts that around time 10:38, a deployed service has experienced a sensible reduction
of service rate, namely experiencing service degradation. The proactive actions taken
by the AUTOI components result in the partial migration of the service to a new virtual
infrastructure maintaining the service rates as when the service was deployed originally.
This way, the self-performance management capabilities have reacted to a sensible self-
performance scene with the best option available.
Performance Degradation
Figure 7. Rate of Deployed Service in Self-performance management execution

5. Conclusions
This paper has presented the manageability of virtual networks from a practical
viewpoint according to the AUTOI approach [1]. We have described an application
scenario and the functional AUTOI components that support the provision of Future
Internet Services. We have also provided the description of the components
interactions, for which illustrative descriptions of self-configuration and self-
performance management scenarios have been described. In addition, we have
provided the result of a self-performance management scene of a real service
deployment as part of the validation efforts being carried out in our project. The
software components described in this paper are released as Open Source components
for experimental purposes [2]. Future work will be mainly devoted to validate our
approach in large-scale deployments. Large scale deployments of the AUTOI concept
will be executed in the GRID5000 (French Nationwide Experimental Platform
embedding 5000 cores) test-bed and relevant results of this effort will be further
disseminated to the Future Internet research community.
We strongly believe that Future Internet service provisioning relies on embedded
in-network management functionalities and orchestrated management systems that can
take advantage of virtualisation and programmability principles that can support
dynamic and statistical changes of the network conditions, insuring stability and
convergence to optimal service provisioning results. We expect that the components’
descriptions, use case scenarios and partial results described in this paper encourage
Future Internet research community to target these and other research challenges
towards conceiving a Future Internet with guaranteed service provisioning capabilities.
References
[1] A. Galis et al. “Management and Service-aware Networking Architectures (MANA) for Future Internet
Position Paper: System Functions, Capabilities and Requirements” - Invited paper IEEE 2009 Fourth
International Conference on Communications and Networking in China (ChinaCom09) 26-28 August
2009, Xi'an, China; http://www.chinacom.org/2009/index.html.
[2] European Union IST 7th Framework Programme AUTOI Project (Autonomic Internet) Deliverables
http://ist-autoi.eu
[3] A. Galis, S. Denazis, A. Bassi, A. Berl, A. Fischer, H. de Meer, J. Strassner, S. Davy, D. Macedo, G.
Pujolle, J. R. Loyola, J. Serrat, L. Lefevre, A. Cheniour – “Management Architecture and Systems for
Future Internet Networks” – in “Towards the Future Internet – A European Research Perspective” –
ISBN 978-1-60750-007-0, pp350, April 2009, IOS Press, http://www.iospress.nl/
[4] EU IST FP6 ANA Project “Autonomic Network Architectures” http://www.ana-project.org/
[5] The EU IST BIONETS http://www.bionets.eu/ project “Biologically-inspired autonomic Networks and
Services” http://www.bionets.eu/
[6] IST FET CASCADAS Project “Component-ware for Autonomic Situation-aware Communications, and
Dynamically Adaptable Services” http://www.cascadas-project.org
[7] The EU IST FP6 HAGGLE project (An innovative Paradigm for Autonomic Opportunistic
Communication) http://www.haggleproject.org/index.php/Main_Page
[8] EU IST FP7 TRILOGY Project “Re-Architecting the Internet: An Hourglass control Architecture for the
Internet, Supporting Extremes of Commercial, and social and Technical Control” http://www.trilogy-
project.org
[9] EU IST SOCRATES project “Self-Optimisation and self-ConfiguRATion in wirelEss networkS”
http://www.fp7-socrates.org
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-115
Monitoring Service Clouds in the Future

Internet
Stuart CLAYMAN a , Alex GALIS a , Clovis CHAPMAN b , Giovanni TOFFETTI c ,
Luis RODERO-MERINO d , Luis M. VAQUERO d , Kenneth NAGIN e ,
Benny ROCHWERGER e
e-mail: sclayman@ee.ucl.ac.uk e-mail: a.galis@ee.ucl.ac.uk
a
Dept. of Electronic Engineering, University College London (UCL)
e-mail: c.chapman@cs.ucl.ac.uk b Dept. of Computer Science, UCL
e-mail: toffettg@lu.unisi.ch c University of Lugano
e-mail: rodero@tid.es, lmvg@tid.es d Telefonica I+D, Madrid
e-mail: nagin@il.ibm.com, rochwer@il.ibm.com e IBM Research, Haifa
Abstract. Service Clouds are a key emerging feature of the Future Internet which
will provide a platform to execute virtualized services. To effectively operate a
service cloud there needs to be a monitoring system which provides data on the
actual usage and changes in resources of the cloud and of the services running in the
cloud. We present the main aspects of Lattice, a new monitoring framework, which
has been specially designed for monitoring resources and services in virtualized
environments. Finally, we discuss the issues related to federation of service clouds,
and how this affects monitoring in particular.
Keywords. monitoring, cloud computing, service cloud, federation, service
management, SLA
Introduction
The Future Internet will have many of its core features and functions based on virtualized
resources. The virtualization of resources has been in use for some time now, and there
are several projects and initiatives working towards the virtualization of networks in the
Future Internet, such as [1] [2] [3] [4]. The virtual resources which will be part of the
Future Internet offerings also include virtual machines which will execute either virtual
routers or virtualized service elements. These virtual resources will be combined together
to create service clouds. In order to manage these virtual resources, there needs to be a
monitoring system which can collect and report on the behaviour of these resources.
This paper presents the Lattice monitoring framework which can be used as a funda-
mental part of the management of an Internet scale deployment of Service Clouds. Lat-
tice has been designed for monitoring resources and services in virtualized environments.
The monitoring of virtualized resources and services has many features, requirements,
and criteria which are not relevant for monitoring systems that are used for traditional
fixed network resources.
Traditionally, the architecture for monitoring has needed to adapt to an arbitrary
network structure, but in a Service Cloud environment the infrastructure is structured as
116 S. Clayman et al. / Monitoring Service Clouds in the Future Internet
a federation of large clusters of distributed hosts. Consequently, we can design and build
a monitoring system that factors in this major difference.
In the work presented in this paper we use the Lattice monitoring framework as a
real-time feed for the management of a service cloud. Monitoring is a fundamental as-
pect of Future Internet elements, and in particular for service clouds, where it is used
for both the infrastructure and service management. We first present the issues relating
to the management of service clouds, discussing the key design requirements and how
these are addressed in the RESERVOIR project [5]. Then, in section 2 we present the
Lattice monitoring framework, discussing its main features and also giving and overview
of its design and implementation, together with a presentation of its use within RESER-
VOIR. This is followed, in section 3, by a presentation of the issues related to federation
within service clouds and how this affects monitoring in particular. Finally, we state our
conclusions and suggest further work.
1. SERVICE CLOUDS
The emerging cloud computing paradigm [6] [7] [8] [9] for hosting Internet-based ser-
vices in virtualized environments, as exemplified by the Amazon Elastic Compute Cloud
(EC2) [10] or Google’s AppEngine [11], aims to facilitate the creation of innovative In-
ternet scale services without worrying about the computational infrastructure needed to
support such services. At present, no single hosting company can create a seemingly in-
finite infrastructure capable of serving the increasing number of on-line services, each
having massive amounts of users and access at all times, from all locations. To cater
to the needs of service providers, it is inevitable that the service cloud is going to be
composed of a federation of sites from various infrastructure providers [12]. Only by
partnering and federating with each other, can infrastructure providers take advantage of
the diversity factor and achieve the economies of scale needed to provide a seemingly
infinite compute utility.
Service clouds are just the latest incarnation of a concept that has been around since
the 1960’s, namely the manifestation of a general-purpose public computing utility [13].
Throughout the history of computing we have seen such utilities appear in one form
or another. Even though some success stories exist, such as in in the area of high per-
formance scientific computing, where grid computing [14] [15] [16] made significant
progress over the past decade, none of these attempts materialized into a true general
purpose compute utility that is accessible by anyone, at any time, from anywhere. Now
however, the advent of new approaches utilizing an always-on Internet and virtualization
[2], has brought about system designs which will enable the desired progress [17]. An
example of such a system design is the RESERVOIR Compute Cloud, which is described
in the next section.
1.1. RESERVOIR
RESERVOIR [5] is a service cloud which has a new and unique approach to Service-
Oriented cloud computing [18]. In the RESERVOIR model there is a clear separation
between service providers and infrastructure providers. Service providers are the entities
that understand the needs of particular business and offer service applications to address
S. Clayman et al. / Monitoring Service Clouds in the Future Internet 117
those needs. Service providers do not need to own the computational resources needed by
these service applications, instead, they lease resources from an infrastructure provider.
The infrastructure provider owns or leases a computing cluster, which supplies the ser-
vice provider with a seemingly infinite pool of computational resources. The cluster is
presented as a service cloud site which is capable of allocating resources to many service
providers.
The high-level objective of RESERVOIR is to significantly increase the effective-
ness of the compute utility enabling the deployment of complex services on a service
cloud that spans infrastructure providers and even geographies, while ensuring QoS and
security guarantees. In doing so, RESERVOIR will provide a foundation where resources
and services are transparently and flexibly provisioned and managed like utilities.
1.2. RESERVOIR Architecture
The essence of the RESERVOIR service cloud is to effectively manage a service which
has been specified as a collection of virtual execution environments (VEEs). A service
cloud, such as RESERVOIR [12] [17], operates by acting as a platform for running virtu-
alized applications in VEEs, which have been deployed on behalf of a service provider.
The service provider defines the details and requirements of the application in a Service
Definition Manifest. This is done by specifying which virtual machine images are re-
quired to run, as well as specifications for (i) Elasticity Rules, which determine how the
application will scale across a cloud, and (ii) Service Level Agreement (SLA) Rules [19],
which determine if the cloud site is providing the right level of service to the application.
Within each service cloud site there is a Service Manager (SM) and a VEE Manager
(VEEM) which provide all the necessary management functionality for both the services
and the infrastructure. These management components of a cloud system are presented
in more detail here.
The Service Manager (SM) is responsible for the instantiation of the service appli-
cation by requesting the creation and configuration of VEEs for each service component
in the manifest. In addition, it is the Service Manager that is responsible for (i) evaluating
and executing the elasticity rules and (ii) ensuring SLA compliance [20], by monitor-
ing the execution of the service applications in real-time. Elasticity of a service is done
by adjusting the application capacity, either by adding or removing service components
and/or changing the resource requirements of a particular component according to the
load and measurable application behaviour.
The Virtual Execution Environment Manager (VEEM) is responsible for the place-
ment of VEEs into VEE hosts (VEEHs). The VEEM receives requests from the Service
Manager to create VEEs, to resize VEEs, and to also finds the best placement for these
VEEs in order to satisfy a given set of constraints. The role of the VEEM is to optimize
a site and its task is to place and move the VEEs anywhere, even on remote sites, as long
as the placement is done within the constraints set in the Manifest, including specifica-
tions of VEE affinity, VEE anti-affinity, security, and cost. In addition to serving local
requests, the VEEM is the component in the system that is responsible for the federation
of VEEs to and from remote sites.
The Virtual Execution Environment Host (VEEH) is a resource that can host a cer-
tain type of VEEs. For example one type of a VEEH can be a physical machine with
the Xen hypervisor [21] controlling it, whereas another type can be a machine with the
Figure 1. RESERVOIR Service Cloud Architecture
kvm hypervisor [22]. In a service cloud hosting site there is likely to be a considerable
number of VEEHs organised as a cluster.
These three main components of the service cloud architecture interact with each
other using well defined interfaces, namely SMI, VMI, and VHI, within a site and also
use the VMI interface for site-to-site federation via the VEEM. In figure 1 the relation-
ship between these components and interfaces is shown.
As can be seen in figure 1, the RESERVOIR platform has a Service Provider speci-
fying the details and requirements of his application in the Service Definition Manifest.
The Manifest also has the specifications of Elasticity Rules, which determine how the ap-
plication will scale across the cloud, and the Service Level Agreement (SLA) Rules [20],
which determine if the platform is providing the right level of service to the application.
Within each site the resource utilization is monitored and the placement of VEEs
is constantly updated to achieve optimal resource utilization. Similarly, the execution of
the service applications is monitored and their capacity is constantly adjusted to meet the
requirements specified in the manifest. These on-going optimizations are done without
human intervention by the management components. Within the Service Manager there
are components which dynamically evaluate Elasticity and SLA rules and implement
their actions in order to maintain effective running of the application. For these rules to
be evaluated A service cloud needs a monitoring sub-system which sends measurement
data, collected from the whole system, to be fed into the rules [23]. This measurement
data can come from the following sources:
1. raw data gathered from probes in the underlying infrastructure,
2. raw data gathered from probes attached to the virtual machines,
3. data gathered from probes embedded in the application,
4. data which is the combination of the raw data into composed Key Performance
Indicators (KPIs), and
5. data derived from the analysis of historical raw data and KPI data held in a data
store.
In a large distributed system, such as a RESERVOIR service cloud, there may be hun-
dreds or thousands of measurement probes which can generate data. It would not be ef-
fective to have all of these probes sending data all of the time, so a mechanism is needed
that controls and manages the relevant probes. Therefore, a service cloud requires a mon-
itoring system that has a minimal runtime footprint and is not intrusive, so as not to
adversely affect the performance of the cloud itself or the running service applications.
As a consequence, we need to ensure that components such as the VEEM, and Service
Manager elements such as the Elasticity Rules Engine and the SLA Rules Engine only
receive data that is of relevance.
2. REQUIREMENTS FOR MONITORING SERVICE CLOUDS
Existing monitoring systems such as Ganglia [24], Nagios [25], MonaLisa [26], and
GridICE [27] have addressed monitoring of large distributed systems, but they have not
addressed a rapidly changing and dynamic infrastructure seen in service clouds.
The monitoring system needs to be designed and built to be fit for the purpose of in-
frastructure and service monitoring. It needs to be for the whole of service management,
and so it should cover SLAs, elasticity, QoS, etc. It is important to recognise that it is
the monitoring mechanism that closes the loop from the initial deployment, through ex-
ecution, and back to the Service Manager. The monitoring system is there to gather data
from all the components within a cloud architecture and so monitoring is a fundamental
aspect of a service cloud that is used by the infrastructure and for service management.
The monitoring system for a service cloud needs to feed data into the Service Man-
ager so that it can manage the services deployed on the cloud. Over time it is expected
that the management capabilities of the Service Manager will expand to include new
functions. As a consequence we need the monitoring system to be adaptable, flexible,
and extensible in order to support the expanding functionality.
To address all of the requirements and functionality of the service cloud environment
we have determined that the main features for monitoring which need to be taken account
of are:
• scalability - to ensure that the monitoring can cope with a large numbers of probes
• elasticity - so that virtual resources created and destroyed by expanding and con-
tracting networks are monitored correctly
• migration - so that any virtual resource which moves from one physical host to
another is monitored correctly
• adaptability - so that the monitoring framework can adapt to varying computa-
tional and network loads in order to not be invasive
• autonomic - so that the monitoring framework can keep running without inter-
vention and reconfiguration
• federation - so that any virtual resource which reside on another domain is moni-
tored correctly
To establish such features in a monitoring framework requires careful architecture and
design. In the following section presents the Lattice Monitoring Framework which we
have designed and built for the purpose of monitoring environments such as service
clouds.
2.1. The Lattice Monitoring Framework
A management system for service cloud requires a monitoring system that can collect
all the relevant data in an effective way. The monitoring system has to have a minimal
runtime footprint and not be intrusive, so as not to adversely affect the performance of
the network itself or the running service applications. As a consequence, we need to
ensure that the management components only receive data that is of relevance. In a large
distributed system there may be hundreds or thousands of measurement probes which
can generate data. It would not be effective to have all of these probes sending data all of
the time, so a mechanism is needed that controls and manages the relevant probes.
2.1.1. Producers and Consumers

The monitoring system itself is designed around the concept of producers and consumers.
That is there are producers of monitoring data, which collect data from probes in the
system, and there are consumers of monitoring data, which read the monitoring data.
The producers and the consumers are connected via a network which can distribute the
measurements collected.
The collection of the data and the distribution of data are dealt with by different
elements of the monitoring system so that it is possible to change the distribution frame-
work without changing all the producers and consumers. For example, the distribution
framework can change over time, say from IP multicast, to an event bus, or a publish /
subscribe framework. Making this change should not affect other parts of the system.
2.1.2. Data Sources and Probes

In many monitoring systems probes are used to collect data for system management [28]
[24]. In this regard, Lattice follows suit. However, to increase the power and flexibility
of the monitoring we introduce the concept of a data source. A data source represents an
interaction and control point within the system that encapsulates one or more probes. A
probe sends a well defined set of attributes and values to the consumers. This can be done
by transmitting the data out at a predefined interval, or transmitting when some change
has occured.
The measurement data itself is sent via a distribution framework. These measure-
ments are encoded to be a small as possible in order to maximise the network utilization.
Consequently, the measurement meta-data is not transmitted each time, but is kept sepa-
rately in an information model. This information model can be updated at key points in
the lifecycle of a probe and can be accessed as required by consumers.
The goal for the monitoring system is to have fully dynamic data sources, in which
each can have multiple probes, with each probe returning its own data. The data sources
are able to turn on and turn off probes, or change their sending rate on demand.
2.1.3. Data Distribution Mechanism

In order to distribute the measurements collected by probes within the monitoring sys-
tem, it is necessary to use a mechanism that fits well into a distributed architecture such
as a service cloud. We need a mechanism that allows for multiple submitters and multi-
ple receivers of data without having vast numbers of network connections. For example,
having many TCP connections from each producer to all of the consumers of the data
for that producer would create a combinatorial explosion of connections. Solutions to
this include IP multicast, Event Service Bus, or publish/subscribe mechanism. In each of
these, a producer of data only needs to send one copy of a measurement onto the network,
and each of the consumers will be able to collect the same packet of data concurrently
from the network. Such an approach works well for a service cloud because we have
both multiple producers and multiple consumers.
2.2. Utilization of Lattice within RESERVOIR
Using the Lattice framework we have built a monitoring system suitable for service cloud
management as part of the RESERVOIR project. As stated earlier, measurement data
can come from raw data gathered from probes in the underlying infrastructure and from
raw data gathered from probes attached to the virtual machines. Consequently, we have
written probes for monitoring physical resources and for monitoring virtual resources.
Furthermore, we have embedded probes inside the applications themselves in order to
gather application specific data. These probes have been deployed into a testbed which
implements the RESERVOIR functionality and are evaluated here.
2.2.1. Monitoring Physical Resources

To monitor the underlying infrastructure of the testbed we have created three differ-
ent probes. The probes monitor CPU usage, memory usage, and network usage of each
VEEH in the testbed. First, the CPU probe collects data on CPU usage for each core of
a server. It runs regularly in order to collect this data in real time. Second, the memory
probe collects data on memory usage on the server. It too runs regularly to collect data
in real time. Third, the network probe collects data on the network interface of a server.
By running at a regular interval it can determine the amount of traffic on the network
interface for each sample.
2.2.2. Monitoring Virtual Resources

To monitor VEEs we have created some probes that collect data on the virtual machines
running on a particular host. These probes interact with the hypervisor to collect data on
each VEE executing under hypervisor control. Each of these probes runs on a regular
basis, collecting data on CPU usage, memory usage, and network usage of each VEE.
2.2.3. Monitoring Service Applications

To monitor the Services that are deployed onto a service cloud it is necessary to embed
probes into the environment of the applications that are executing inside each VEE. The
data from these probes are sent from the VEE, via the infrastructure network, into the
Service Manager. As an example of such a probe, we developed and installed one that
collects the length of the job queue for a virtualized Sun Grid Engine application [29].
The queue length was used directly by one of the elasticity rules for this application,
so that (a) when the queue length was high new virtual machines were allocated auto-
matically, or (b) when queue length went low existing virtual machines were shutdown
automatically. By adapting to the queue length the Service Manager and the VEEM op-
timized the running of the whole Sun Grid Engine application on RESERVOIR.
Summary of the Lattice Monitoring Framework
The Lattice framework provides a platform from which various monitoring systems can
be built. It provides the building blocks and the glue from which specific monitoring
elements can devised.
We can write probes which collect data for any specific purpose and then write con-
sumers which process that data in any way necessary. Lattice itself does not provide a
pre-defined library of probes, data sources, or consumers. Rather, it allows the probes,
data sources, and consumers to be written and deployed as needed. For different applica-
tions, we can write a completely different monitoring system that is based on the Lattice
monitoring framework. As an example of this, we have written a monitoring system for
the virtual network project AutoI [30] for which we have written separate probes.
3. MONITORING FEDERATED SERVICE CLOUDS
When Service Clouds are federated to accept each other’s workload there needs to be
a consideration of how monitoring will behave in the presence of the federated VEEs.
Monitoring needs to continue to work correctly and reliably when a service executes
across federated clouds. When some VEEs are migrated to another cloud, the data distri-
bution mechanism will need to cross cloud boundaries. It is essential that the interfaces
and formats between clouds is standardised in order that federation monitoring should
work in heterogeneous environments. This will ensure that that the monitoring data for
all the VEEs of a service will be connected, whether local or remote.
Monitoring in a service cloud presents us with some interesting issues. Although the
service cloud infrastructure is a distributed system, it is structured in a very particular
way, with one large grid of machines acting as one cloud. Most of the monitoring data
stays within the site, as all of the consumers are within the site. The exception is for
federated VEEs. With many monitoring systems the sources and consumers are often
distributed arbitrarily across a network, and so the paths of data flow and the patterns
of interaction are different. Within a service cloud the pattern is more predictable, and
so we need to design and build for this. In figure 2 we can see how the monitoring for
the VEEs in one service are connected by the data distribution mechanism within each
cloud, and how these are connected together to form a single service.
When a VEE is migrated from one site to a remote site, the monitoring data from
that VEE still needs to be collected by the Service Manager. However, by migrating to
a remote site the originating site loses direct control of the VEE. However, in order to
ensure a continuous monitoring capability, some fundamental issues need to considered.
They are:
• how does monitoring behave when a VEE is sent to a remote cloud
• what operations need to be done in each of the clouds to activate this federation
• what components and objects need to be created and/or managed when federation
occurs.
Figure 2. The Federation of VEEs for a Single Service
Figure 3. The Federation of VEEs on Different Clouds
As the remote VEEs have crossed another cloud’s boundaries, there is not really a direct
connection between the VEEs as seen in figure 2. Each cloud will be on its own network,
hence the VEEs residing within it will not have direct contact with VEEs in another
cloud. There is a need for a component in each cloud, such as a gateway or a broker, to
act on behalf of the VEEs. Such a configuration is shown in figure 3, where all of the
VEEs are still connected, but using this intermediate component.
For federated monitoring, there needs to be consideration all of the operations, com-
ponents, and objects that may be involved in federation of VEEs. It is important to note
that the data distribution mechanism crosses cloud boundaries as VEEs migrate. Al-
though the data distribution mechanism for monitoring connects all of the VEEs, this
cannot happen for free. There are many issues to consider. For this process to work cor-
rectly the system needs to:
• address the setup of the federation in the home and remote cloud
• address the setup of the remote migration
• address the connection for sending measurements back to the home cloud
• address the tear-down of remoting in both the the home and remote cloud
• ensure that remote and connected VEEs must be kept separate from other ser-
vices.
For each of these steps we need to control the operations that need to be done in each of
the clouds to activate this federation, and interact with the components and objects need
to be created and/or managed when federation occurs.
Figure 4. The Federation of VEEs for Multiple Services
Furthermore, as a service cloud will be used for more than one service, we need to
also consider how we address the federation of multiple services. Each service needs to
be kept separate and secure from all of the other services. As a consequence the process
of splitting data distribution into multiple segments and having each segment connected
using a component onto an external network will have to be done per service. Such a
scenario is shown in figure 4 where there are multiple services across the thee clouds.
4. CONCLUSIONS
Monitoring in service clouds, such as RESERVOIR, presents us with some interesting

issues. Although the service cloud infrastructure is a distributed system, it is structured
in a very particular way, with one large cluster of machines acting as one cloud site. Most
of the monitoring data stays within the site, as all of the consumers are within the site.
The only exception to this is for federated VEEs. We see that the monitoring system is
pervasive to a service cloud as:
1. it is required by most of the components of the service cloud;
2. it cuts across the layers of the service cloud creating vertical paths; and
3. it spans out across all the clouds in a federation in order to link all the VEEs of a
service.
With many monitoring systems the sources and consumers are often distributed arbitrar-
ily across a network, and so the paths of data flow and the patterns of interaction are dif-
ferent. Within a service cloud the pattern is more predictable, and so we have designed
and built for this situation.
The use of the Lattice framework allowed us to build a monitoring infrastructure
that collects, processes, and disseminates network and system information from/to the
entities at real-time, acting as an enabler for service management functionality. We have
seen that monitoring is a fundamental feature of any service cloud management system.
We have also shown that Lattice can provide such monitoring for systems in which the
virtualized resources are highly volatile as they can be started, stopped, or migrated at
any time by the management.
The paper has presented the Lattice framework, which has been successfully used
in the RESERVOIR project [5] for monitoring service cloud components. We can build
many different monitoring systems using the framework, where different implementa-
tions of probes, data sources, and consumers are envisaged. Such an approach has been
undertaken within the AutoI project [31] to allow the monitoring of virtual networks.
4.1. Further Work
There is much further work to do in the areas of service cloud management and monitor-
ing.
Within RESERVOIR, there is a full monitoring system lifecycle integration within
the Service Manager, from the initial Service Definition Manifest presentation, through
the first service deployment, and then the continual execution of the service. To support
fully dynamic on-the-fly functionality these lifecycle and control functions will need to
use a control plane of the monitoring framework. Using this control plane the Service
Manager will be able to activate, deactivate, and set the data rate of probes, as necessary.
Furthermore, to ensure the continuous operation of the monitoring system, it needs
to be self-aware of its operation and its effect on the whole RESERVOIR system. In
order to make it this way, the monitoring system needs its own adaptable controller with
policies which can control the whole of the monitoring system. All of these elements are
considered as part of the further work.
A further goal for the Lattice monitoring system is to have the ability to add new
probes to a data source at run-time. By using this approach we will be able to instru-
ment components of the service cloud without having to restart them in order to get new
information.
Acknowledgment
This work is partially supported by the European Union through the RESERVOIR project
[5] of the 7th Framework Program. We would like to thank the members of the RESER-
VOIR consortium for their helpful comments.
References
[1] “Future Internet Assembly (FIA).” http://www.future-internet.eu/.

[2] A. Galis, H. Abramowicz, M. Brunner, D. Raz, P. Chemouil, J. Butler, C. Polychronopoulos, S. Clay-
man, et al., “Management and service-aware networking architectures for future internet position pa-
per: System functions, capabilities and requirements,” in IEEE 2009 Fourth International Conference
on Communications and Networking in China (ChinaCom09), August 2009. Invited paper.
[3] “GENI design principles,” Computer, vol. 39, pp. 102–105, 2006.
[4] “Future Internet Design (FIND) program.” http://www.nets-find.net/.
[5] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, et al., “The RESERVOIR model and architecture for
open federated cloud computing,” IBM Journal of Research and Development, vol. 53, no. 4, 2009.
[6] N. Carr, The Big Switch - Rewiring the World from Edisson to Google. W. W. Norton, January 2008.
[7] “Open cirrus - open cloud-computing testbed.” www.opencirrus.org.
[8] P. Wallis, “Understanding cloud computing, keystones and rivets.” http://www.keystonesandrivets.com/

kar/2008/02/cloud-computing.html, February 2008.
[9] “Above the clouds: A berkeley view of cloud computing.” http://www.eecs.berkeley.edu/
Pubs/TechRpts/2009/EECS-2009-28.pdf.
[10] “The Amazon Elastic Compute Cloud (Amazon EC2) web site.” http://www.amazon.com
/gp/browse.html?node=201590011.
[11] “What is the Google App Engine.” http://code.google.com/appengine/docs/whatisgoogleappengine.html.
[12] B. Rochwerger, D. Breitgand, D. Hadas, I. Llorente, R. Montero, P. Massonet, E. Levy, A. Galis, M. Vil-
lari, Y. Wolfsthal, E. Elmroth, J. Caceres, C. Vazquez, and J. Tordsson, “An architecture for federated
cloud computing,” Cloud Computing, 2010.
[13] R. M. Fano, “The MAC system: The computer utility approach,” IEEE Spectrum, vol. 2, p. 5644, January
1965.
[14] I. Foster, C. Kesselman, and S. Tuecke, “The anatomy of the grid: Enabling scalable virtual organiza-
tions,” International J. Supercomputer Applications, vol. 15, no. 3, 2001.
[15] I. Foster, C. Kesselman, J. Nick, and S. Tuecke, “Grid services for distributed system integration,” Com-
puter, vol. 35, no. 6, 2002.
[16] I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist,
R. Subramaniam, J. Treadwell, and J. V. Reich, “The Open Grid Services Architecture, Version 1.0,”
tech. rep., Open Grid Forum (OGF), January 2005.
[17] B. Rochwerger, A. Galis, D. Breitgand, E. Levy, J. A. Caceres, I. M. Llorente, Y. Wolfsthal, M. Wusthoff,
S. Clayman, W. Emmerich, E. Elmroth, and R. S. Montero, “Design for future internet service infras-
tructures,” in Towards the Future Internet - A European Research Perspective, p. 350, IOS Press, April
2009.
[18] B. Rochwerger, A. Galis, E. Levy, J. A. Caceres, D. Breitgand, Y. Wolfsthal, I. M. Llorente, M. Wusthoff,
R. S. Montero, and E. Elmroth, “Management technologies and requirements for next generation service
oriented infrastructures,” in 11th IFIP/IEEE International Symposium on Integrated Management, June
2009.
[19] J. Skene, D. Lamanna, and W. Emmerich, “Precise Service Level Agreements,” in Proc. of the 26th Int.
Conference on Software Engineering, Edinburgh, UK, pp. 179–188, IEEE Computer Society Press, May
2004.
[20] A. Sahai, S. Graupner, et al., “Specifying and monitoring guarantees in commercial grids through sla,”
in Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid
(CCGrid’03), pp. 292–299, 2002.
[21] P. Barham, B. Dragovic, K. Fraser, S. Hand, et al., “Xen and the art of virtualization,” SIGOPS Oper.
Syst. Rev., vol. 37, no. 5, pp. 164–177, 2003.
[22] A. Kivity, “kvm: the linux virtual machine monitor,” in OLS ’07: The 2007 Ottawa Linux Symposium,
pp. 225–230, July 2007.
[23] J. Skene, A. Skene, J. Crampton, and W. Emmerich, “The Monitorability of Service-Level Agreements
for Application-Service Provision,” in Proc. of the 6th Int. Workshop on Software and Performance
(WOSP), Buenos Aires, Argentina, pp. 3–14, ACM Press, Feb. 2007.
[24] M. L. Massie, B. N. Chun, and D. E. Culler, “The ganglia distributed monitoring system: Design, im-
plementation and experience,” Parallel Computing, vol. 30, p. 2004, 2003.
[25] “Nagios.” http://www.nagios.org/.
[26] H. Newman, I. Legrand, P. Galvez, R. Voicu, and C. Cirstoiu, “MonALISA : A distributed monitoring
service architecture,” in Proceedings of CHEP03, La Jolla, California, 2003.
[27] S. Andreozzi, N. De Bortoli, S. Fantinel, A. Ghiselli, G. L. Rubini, G. Tortone, and M. C. Vistoli,
“GridICE: A monitoring service for grid systems,” Future Gener. Comput. Syst., vol. 21, no. 4, pp. 559–
571, 2005.
[28] A. Cooke, A. J. G. Gray, L. Ma, W. Nutt, et al., “R-GMA: An information integration system for grid
monitoring,” in Proceedings of the 11th International Conference on Cooperative Information Systems,
pp. 462–481, 2003.
[29] “Guide to Sun Grid Engine 6.2 Installation and Configuration,” white paper, Sun Microsystems, Septem-
ber 2008.
[30] A. Galis, S. Denazis, A. Bassi, P. Giacomin, et al., Management Architecture and Systems for Future
Internet Networks. IOS Press, http://www.iospress.nl, ISBN 978-1-60750-007-0, April 2009.
[31] “Autonomic Internet (AutoI) Project.” http://www.ist-autoi.eu/, 2008-2010.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-127
Scalable Cloud Defenses for Detection,

Analysis and Mitigation of DDoS Attacks
Joseph Latanicki a , Philippe Massonet b , Syed Naqvi b , Benny Rochwerger c and
Massimo Villari d
a
Thales − Theresis, France; E-Mail: Joseph.Latanicki@thalesgroup.com
b
Centre d’Excellence en Technologies de l’Information et de la Communication;
E-Mail: Philippe.Massonet(Syed.Naqvi)@cetic.be
c
IBM Haifa Research Lab., University Campus, Haifa 31905, Israel;
E-Mail: rochwer@il.ibm.com
d
Università degli Studi di Messina, Facoltà di Ingegneria;
E-Mail: mvillari@unime.it
Abstract. Distributed denial of service (DDoS) is considered as one of

the most serious threats to emerging cloud computing infrastructures.
It aims at denying access to the cloud infrastructure by making it un-
available to its users. This can cause important economic and organi-
zational damage depending on the type of applications running on the
cloud that have become unavailable. This paper proposes an extension
to a federated cloud architecture to use scalability and migration of vir-
tual machines to build scalable cloud defenses against cloud DDoS at-
tacks. The architecture is validated by showing how three DDoS attack
scenarios are handled by the DDoS countermeasures.
Keywords. Future Internet, Cloud Computing, IaaS, Security Architecture,
Virtualization infrastructure, Cloud Threats and countermeasures.
1. Introduction
The Internet is having a profound impact on our global economic and social world.
The Future Internet aims to identify the long term societal and economic trends of
future on line societies [1], how they may impact the underlying network and ser-
vice technologies, and how they subsequently drive research requirements. Cloud
Computing can be seen as an enabling technology for a service based economy
and related related business processes[2][3]. In particular federated and heteroge-
neous Clouds pose new challenges that have to be addressed in terms of dynamic
resource provisioning and elasticity, SLAs between users and clouds, transpar-
ent resource management, and security mechanisms. These constraints forces the
IT security teams to develop adequate security safeguards for virtualized infras-
tructures and provide assurance to the various stakeholders such as Infrastruc-
ture Providers (IPs), Service Providers(SPs), Network Service Providers (NSP),
end-users(E-Us).
128 J. Latanicki et al. / Scalable Cloud Defenses for Detection, Analysis and Mitigation
In this paper, we consider a federated IaaS cloud architecture, analyse the

new threats, analyse Distributed Denial of Service (DDoS) attacks and propose
possible solutions. The federated IaaS cloud architecture from the RESERVOIR
[4] European project is extended to deal with DDoS attacks. This architecture
provides technologies and specifications to build open and federated IaaS.
This chapter is organized as follows. After a brief presentation of the State of
the Art on DDoS and Cloud Computing (sec. 1.1), Section 2 introduces federated
IaaS by describing the RESERVOIR reference architecture. Section 3 provides an
overview of the DDoS threat, its costs and implications. In particular, we identify
three possible types of DDoS cloud attacks. A scalable cloud defense architecture
is then presented in section 4. Section 5 validates the extended architecture by
describing the counter measure behavior for the three attack scenarios described
in 3.1. The last section provides some conclusions and describes future work (Sec.
6).
1.1. DDoS State of the Art
Distributed Denial of Service (DDoS) is a coordinated attack that aims to disrupt

routine functioning of computing and/or network resources generally by flood-
ing the target nodes with large amounts of traffic. DoS attack, the forerunner
of DDoS attack, could be mitigated by identifying and eventually blocking the
unique source. The distributed nature of DDoS, that involve several computers
that launch attacks, makes it more difficult to identify them, and more challenging
to build DDoS defenses. These attacks are frequent: it has been found that there
were on average 1200 DDoS attacks each day across 38 ISP networks in 2007 with
at least one DDoS attack of one million packets per second every working day
[5]. February 2000 saw the very first massive DDoS attack that brought havoc to
a number of websites and inflicted losses of hundreds of thousands of dollars [6].
The following years have not brought any relief to the ISPs as DDoS attacks have
gradually increased a hundredfold by reaching the size of 40 gigabits per second
in 2007 [7]. This situation led the ISPs to spend most of their available security
resources combating DDoS attacks. A broad range of available tools to launch
DDoS attacks [8] further exacerbates the situation.
The recent successful DDoS attack on the Amazon Cloud [9] is an eye-opening
incident that requires serious attention from Cloud security designers. Detection
of the DDoS attacker’s IP address can provide a significant breakthrough in pro-
tecting the cloud resources by creating effective deterrence. The Internet Engi-
neering Task Force’s RFC2827 [10] proposes a method for using ingress traffic
filtering to prohibit DoS attacks that use forged IP addresses. These IP addresses
are generally propagated from the aggregation point of the ISP. The authors in
[11] have proposed a framework to detect a number of DDoS attacks through
monitoring propagation of abrupt traffic changes inside NSP domains followed
by characterizing flows that carry attack traffic. The inherent limitation of any
detection mechanism is their ability to only detect the known attack patterns.
They cannot cope with the attacks launched by smart attackers whose attack
patterns are frequently changed. Very recently [12] has proposed a proactive de-
tection method for DDoS attacks. This method selects nine features of network
traffic to classify the current status of a network.
J. Latanicki et al. / Scalable Cloud Defenses for Detection, Analysis and Mitigation 129
2. Federated IaaS Cloud architecture
The Future Internet of services aims to enable the deployment and delivery of
complex and large scale services to consumers with agreed upon qualities of ser-
vice (QoS). A single provider of IaaS can provide scalable and cost effective in-
frastructure services on demand to users [13]. Users will experience an impression
of unlimited resources that can be requested on demand. In reality the resources
of a single infrastructure provider are limited and in cases of overload will lead to
SLA violations. A solution is to create federations of infrastructure provider [14].
This will allow infrastructure level resources be shared between IaaS providers
and allow them to deal with excess demand.
In this section, we briefly describe the RESERVOIR architecture [4]. RESER-
VOIR introduces an abstraction layer to develop a set of high level management
components that are not tied to any specific implementation. This abstraction is
designed for a federation of heterogeneous physical infrastructures. Every site is
Figure 1. RESERVOIR architecture with three different management layers. Furthermore the
interfaces exposed to DDoS threats are shown.
partitioned by a virtualization layer into virtual execution environments (VEEs).

These environments are fully isolated runtime modules that abstract away the
physical characteristics of the resource and enable sharing. A RESERVOIR cloud
has three different layers (see Figure 1 RESERVOIR Site, the dashed-rectangle)
described as follows:
• Service Manager (SM): is responsible for the instantiation of the service
application by requesting the creation and configuration of VEEs for each
service component, in agreement with the SP manifest, ensuring Service
Level Agreement.
• Virtual Execution Environment Manager (VEEM): is responsible for the
placement of VEEs onto VEE hosts. It receives requests from the SM to
create and re-size VEEs and decides what is the best placement for these
VEEs to optimize a site utility function given a set of constraints (set by
the SM). The VEEM has the full control of the VEEH along with Virtual
Host Interface (VHI).
• Virtual Execution Environment Host (VEEH): it represents a virtualized
resource hosting a certain type of VEEs. VEEM issue generic commands
to manage the lifecycle of VEEs, and VEEHs are responsible for translat-
ing these commands into commands specific to the virtualization platform
abstracted by each VEEH.
3. The DDoS Threat: general concepts
Federated IaaS presents advantages if the new cooperating framework is able to

guarantee QoS and Security. In order to take decisions about the IaaS security
architecture, information security, policy creation and enforcement, an analysis
of the various kinds of threats facing the IaaS architecture, its applications, data
and information systems is required. Focusing on threats analysis, we provided
an early classification in “External” and “Internal” threats.
In the “External Threats”, we have all the issues related with the Internet
connection. The main goals of these threats are to gain unauthorised access to
systems, to impersonate another entity on the network and to make the system
resources unavailable. Others threats are aimed toward provoking a system crash,
leading to the inability to perform functions normally. Although DDoS attacks are
not new and are not directly related to the use of cloud computing, we underline
that in CC, the risk of a DDoS attack is not only “external”. There is also the risk
of an internal DDoS attack through the portion of the IaaS provider’s network
used by customers (separate from the IaaS provider’s infrastructure network).
That “internal”’ (non-routable) network is a shared resource, used by customers
for access to their non-public VEE instances.
3.1. The DDoS Threat: three typologies identified
In the context of federated IaaS, three sub-types of DDoS attacks have been iden-
tified. Three attack scenarios are introduced to describe how they are carried out
and which cloud entities are involved. Figure 2) shows the three attack scenarios
Figure 2. The three scenarios in which “Attackers” perform DDoS attacks toward Cloud Infras-
tructures and vice-versa.
(from Left to Right), and the IaaSs capabilities used in each case:
• An external botnet attacking a set of virtual machines running in a Cloud

(External to Internal)
• An internal botnet attacking a set of virtual machines running on the same
Cloud or a federation of clouds (Internal to Internal)
• An Internal botnet attacking a target running somewhere on Internet (In-
ternal to External)
In the DDoS External to Internal attack, the first goal of the attacker is to
saturate the Internet gateway of the Cloud infrastructure. Even if the gateway is
still running, the second goal is to saturate the servers themselves. The attacker
not only targets the virtual machines of a given client but also the other virtual
machines running on the same physical servers.
In the case of the DDoS Internal to External attack, the attacker must first
succeed in loading a trojan horse in a client’s virtual machine running in the
Cloud. If the trojan horse is able to spread over all the customer’s virtual machines
(could be hundreds of VMs) it will become a botnet. The botnet can be the
source of a DDoS attack toward an external target. If the Cloud isolation is
not safe enough, the Cloud becomes a source of an almost infinite number of
attacking servers. A legal question is then raised: who is responsible, the customer
or the Cloud infrastructure provider. The propopsed architecture provides logging
services that can be used to resolve legal responsibility issues.
As in the internal to external DDoS attack, the DDoS Internal to Internal attack
involves an internal botnet that attacks another internal target. The impact of
such an attack is that it may break down all infrastructures and in the case of a
federation of clouds the federation itself. For Internal to Internal we are referring
to an attack within the federated infrastructure. It is trivial to assume the DDoS
attack inside one single RESERVOIR site (internal DDoS VEEs toward VHI) as
a simplification of what is described at this stage.
4. Federated Cloud DDoS Defense
Cloud infrastructure designers need to address the DDoS threat by defining some
powerful mitigating techniques. In this work, we are proposing a scalable solution
for mitigating DDoS attacks by leveraging the cloud capabilities. The idea is to
use the scalability of federated cloud infrastructures to build scalable cloud DDoS
defenses that can deal more efficiently with DDoS attacks and restore availability
of the cloud infrastructure more quickly. For example, when abnormal activity is
detected, IaaS defenses could scale up, e.g. “increased monitoring of interfaces”,
or speed up “correlation analysis”.
4.1. Requirements for a DDoS countermeasure
The main requirement of a DDoS countermeasure is to maintain availability of

the cloud infrastructure during a DDoS attack. Availability must be guaranteed
for the different stakeholders of the cloud infrastructure to carry out their tasks:
the service providers who deploy VM on the cloud infrastructure, the end users
of the deployed services, and the cloud infrastructure managers.
To achieve the above general requirement the following functional require-

ments must be addressed by the countermeasure:
• R1: Early and rapid detection of DDoS attack and its perimeter.
• R2: Delay as much as possible the effects of the DDoS attack.
• R3: Rapid migration of virtual machines from attacked physical machines
to non attacked ones.
• R4: Maintain ability to migrate VM during attack by guaranteeing network
bandwidth.
• R5: End the DDoS attack as soon as possible
4.2. Possible solutions to reveal and reduce the DDoS attack effects
Figure 3. The new RESERVOIR architecture able to prevent and avoid DDoS attacks.
Even though federated IaaS is an attractive target for DDoS attacks, it also
provides a good environment to build a countermeasure. The detection of DDoS
is difficult without considering a global view of the phenomenon. Collaboration
between federated IaaS can lead to more effective detection of malicious use of
resources. The use of different kind of probes can allow to collect more data and
investigate more types of threats. To address requirement R1 scalable cloud based
monitoring is needed to rapidly provide detailed monitoring data on demand.
To address R1 we also need scalable inter-Cloud Data Correlation Analysis that
can provide early detection of the DDoS attack. To address R2 the ability to
scale on demand of IaaS can be used to maintain critical functionality during
the attack, e.g. by scaling up the gateways under attack so they can continue to
handle network traffic. To address requirement R3 we need a counter measure that
maintains availability of the VEE under attack. The ability of federated IaaS to
perform virtual machine migration can be used to move VEE affected by the DDoS
attack to physical machines that are not affected by the DDoS attack (service
migration). To address requirement R5 we need to perform DDoS traffic re-routing
in cooperation with the NSP (traffic divert). We underline that these solutions
rely on the ability to cooperatively detect the global network issues. In particular
successful DDoS detection strongly depends on useful monitoring at different
architectural levels and correct inter-sites cross correlation analysis. The new
“managers” that we introduce, will be responsible for these new functionalities.
4.3. DDoS Cloud Counter Measure Architecture
Figure 3 presents a federated IaaS architecture that meets the requirements de-
fined in section 4.1. It extends the architecture presented in Figure 1 with the
DDoS countermeasures described in the previous section. The Figure shows a
federation of two Reservoir sites A and B. In particular it is possible to see the
synergy and coordination among sites and NSPs throughout the communication
channel. Figure 3 also shows the new components necessary for DDoS defense.
The main component is called: “DDoS federated coordination manager” (DDFed-
eratedM1 .) This entity belongs to the “Federation Manager”, the RESERVOIR
module responsible to manage the cooperation among IaaSs. The “Federation
Manager” is located at VEEM level and interacts with it and with the Security
Operation Centers(SOC) console. The SOC is responsible for interacting with the
security officer, and provide monitoring and control of the DDoS countermeasure
process. If necessary security officers can react using the “manual” counter mea-
sures procedures. The security officers should be able to communicate and send
alerts messages to other SOCs. Each site has two isolated areas: one for the client
VEE and another for the infrastructure VEEs. The Figure also shows that “sys-
tem resources”are isolated from the the “client resources”, in order to guarantee
a higher degree of security. The dashed-rectangle shows this safety area, where
the “Federation Manager” can communicate with the VEEM, SOC, NSPs and
other “Federation Managers” of federated sites.
Figure 4. RESERVOIR architecture: simplified internal representation with the modules for
DDoS Defense.
Figure 4 shows the simplified internal representation of a RESERVOIR site,

and the internal structure of the DDFederatedM. The DDFederatedM coordinates
1 This acronym contains double DD to identify the concepts of DDoS and the final capital
letter M like Manager. In the rest of the paper we are using the same notation for all the
acronyms.
the Distributed Data System Monitoring and the Counter measures Executors.
The distributed data system monitoring is composed of a DDoS Probe Manager
(DDProbeM) and a DDoS Correlation analysis Manager (DDCorrelationM). The
counter measures executors are the DDoS Migration Manager (DDMigrationM)
and the DDoS ReRoute Manager (ReRouteM). In the paragraphs below, we pro-
vide an in-depth description of the role they cover in the architecture and what
their main tasks are.
Scalable Cloud DDoS Probe Manager. The DDProbeM is responsible for
monitoring the user Internet access to detect DDoS attack coming from the In-
ternet, the internal networks owned by the customers, and the management and
supervision network used by the infrastructure provider. The monitoring is per-
formed by the probes and monitoring events are communicated using a pub-
lish/subscribe monitoring component. All events are logged by a logging service
(for backup, archive and correlation). The probes and their manager use the elas-
ticity of the Cloud to avoid and delay saturation as much as possible if attacked.
Figure 4 shows where the probes are placed for the Public Interfaces 1, 2 and
3. They are placed before and after the firewall (see the wall icons close to the
routers). This monitoring allow us to distinguish attempted attacks from success-
ful ones and provide more meaningful cross correlation analysis. The DDProbeM
provides “early” DDoS detection.
Scalable Cloud DDoS Correlation Analysis Manager. The DDCorrelationM
is responsible for performing correlation analysis in each Cloud infrastructure. In
the case of federated IaaS the correlation engine should be able to access logs
from other sites and correlate the information.
DDoS Cloud Migration Manager. The DDMigrationM is responsible for main-
taining availability by migrating attacked VEE to physical machines not under
DDoS attack. The DDMigrationM is triggered by the DDFederatedM under con-
trol of the SOC. It interacts with other federation sites, chooses the best one
according to the migration policies, manages the migration process and reports
back to the DDFederatedM. The NSPs are also involved in the migration process.
They contribute to inform the IaaS providers and other NSPs of the white-list
of better places to move the VEE, i.e. via a network segment that is not under
attack. The DDMigrationM is informed of the status of each VEE.
The DDMigrationM is also responsible for moving the VEE back once the
DDoS attack is finished. In the case of an internal attacker the DDMigrationM
counter measure is given by the possibility to reinstall the previous VEE version
free from any malware. The Virtual Images storage system is involved together
with the Virtual Machine checkpoint management to isolate the bad VEE, put
it in quarantine, and reinstall the new one either from the scratch or from last
uninfected status (VEE recovery from the last good checkpoint). VEE in quar-
antine can not perpetrate any attack, but it becomes the real proof for any legal
controversial responsibility assumption among customers and IaaSs. The check-
pointing service is responsible for making regular snapshots of virtual machines,
and is responsible for managing them.
DDoS Cloud ReRoute Manager. The ReRouteM is responsible for rebuild-
ing the network interconnections, to avoid the DDoS effects. To achieve this the
ReRouteM sends a request to the NSPs to reroute the attacking traffic. It pro-
vides a set of target IP addresses, protocol and port, and a set of attacker IP
addresses. The ReRouteM is also responsible for managing the IP addresses, and
re-allocates them when the NSP informs him that the attack is finished. The NSP
informs the ReRouteM when the attack is finished and when IP addresses can
be re- allocated again by the ReRouteM. When the NSP has changed public IP
addresses in the DNS he is responsible for confirming to the ReRouteM when it
is done. The ReRouteM needs a strong relationship with NSPs in order to restore
the communication efficiently. The ReRouteM is responsible for requesting the
NSP(s) to change the attacked public IP addresses in the DNS. By combining
the VEE provision (VEE migration) and the reroute technique, all attacked VEE
can be moved in the federated Cloud, and availability restored since they can be
reached through new network segments (new IPs) in different IaaSs. The ReRoute
counter measure falls into an enlarged ecosystem, in which NSPs and IaaSs are
collaborating to end the DDoS attack. The traffic rerouting counter measure can
use virtualization power itself. NSPs are using virtualisation to provide new flex-
ible networks, i.e. virtual networks that are easily configurable and manageable
by end users (i.e. SPs). Virtual networks can provide new useful connectivity so-
lutions to users’ requirements. NSP can allocate network resources dynamically
[15]. Furthermore, users can request a virtual infrastructure (“slice”) composed
of a combination of circuits. These “slice” can include: routed IP virtual circuits
(IPv4, IPv6 unicasting and multicasting) and/or system(s) and/or virtual routers.
It is clear that, in a coordinating system able to reduce the DDoS attack, the
synergy among NSPs and IaaSs is very important to identify and remove the
effects of different types of attack. The ability to control the behavior of virtual
circuits between IaaSs and NSP, allows to reroute the traffic at the source of the
problem, i.e by modifying the routing table of NSPs’ Virtual Routers.
5. The strategies for the DDoS counter measures
This section describes how the architecture deals with the three scenarios pre-
sented in 3.1. The role of the different architectural components is described for
each case.
5.1. External to internal attack counter measure
In the case of an external to internal attack the DDProbeM monitors all incoming
network connections for the public IP addresses. The DDProbeM monitors all
events from the probes, and starts monitoring in more detail if abnormal activity
is detected. If abnormal activity is confirmed, the DDFederatedM is informed and
correlation analysis is triggered. An alert is sent to the SOC by the DDFederat-
edM. The DDCorrelationM accesses all relevant DDoS logs in the federation. If
the attack is confirmed, the DDFederatedM alerts the SOC and starts the DDMi-
grationM. The DDMigrationM uses the perimeter of the attack to identify all
VEE that must be migrated. The DDMigrationM then triggers the migration in
collaboration with the VEEM. The SOC monitors the migration process. The
DDMigrationM monitors that sufficient network bandwidth is available to carry
out the migration. The DDFederatedM, under the control of the SOC, then in-
teracts with the ReRouteM and the necessary NSP to modify the attacked public
IP addresses and reroute the attacking traffic.
5.2. Internal to external attack counter measure
In the case of the internal to external attack, the DDProbeM monitors all outgoing
traffic with the probes. When abnormal outgoing IP traffic is detected, e.g. a lot
of traffic is being sent to one or two machines, the DDFederatedM is informed.
If the DDoS attack is confirmed by the DDCorrelationM, the DDFederatedM
informs the client that some of his VEE have been infected by a botnet. In this
attack scenario no migration of the infected VEE is needed. Only the uninfected
VEE of other clients that happen to run on the same physical machines must
be migrated by the DDMigrationM. The ReRouteM inform the NSP(s) of the
attack, and informs them that compromised packets to attacked IP addresses can
be filtered. This stops the attack on the target IP addresses. The DDFederatedM
in collaboration with the client must agree on how to stop the infected VEE.
5.3. Internal to internal attack counter measure
In the case of an internal to internal attack, the roles of DDProbeM and DDCor-
relationM are the same as in the previous attack. Once the attack is confirmed
by the DDCorrelationM, the DDFederatedM under control of the SOC informs
the attacked client. The DDMigrationM migrates the attacked VEE as quickly as
possible in order to minimize any service disruption. The DDFederatedM under
control of the SOC inform the attacking client and collaborate with him to stop
the attacking VEE as quickly as possible. Logs of the attack and the countermea-
sures are kept for legal purposes, e.g. to prove the good faith of the cloud provider
and the attacking client. The logs can be analysed to show how and when the
VEE were infected.
DDoS attacks target availability of the cloud infrastructure. They are one of the
most serious threats to cloud computing. This paper has described how a federated
cloud architecture could be extended to deal with the DDoS threat. The result is a
scalable cloud defense architecture for dealing with DDoS. The architecture builds
on the ability of federated IaaS to scale and migrate VEE within the federation.
The countermeasure aims to delay the attack sufficiently to migrate all attacked
VEE toward machines outside the attacked zone, thus guaranteeing availability.
Future work aims at validating the architecture by integrating the countermeasure
in a federated IaaS architecture, and carrying out experiments in a testbed. The
main aim of the experimentation will be to verify experimentally whether the
scalability of the DDProbeM and DDCorrelationM delays the attack sufficiently
to migrate attacked VEEs. Performance analysis is required to determine under
which conditions the architecture can manage cloud DDoS attacks.
Acknowledgements. The research leading to the results presented in this paper

has received funding from the European Union’s seventh framework programme
(FP7 2007-2013) Project RESERVOIR under grant agreement number 215605.
Acronyms: DDoS = Distributed Denial of Service, DDProbeM = DDoS Probe

Manager, DDCorreltationM = DDoS Correlation analysis Manager, DDMigra-
tionM = DDoS Migration Manager, DDFederatedM = DDoS Federated coor-
dination Manager, IaaS = Infrastructure as a Service, NSP = Network Service
Provider, SP = Service Provider, ReRouteM = DDoS ReRoute Manager, SOC
= Security Operation Centers, VEEH = Virtual Execution Environment Host,
VEEM = Virtual Execution Environment Manager.
References
[1] J. Z. Jeffrey Voas, “Cloud computing: New wine or just a new bottle?,” IT Professional,
vol. 11, pp. 15–17, March-April 2009.
[2] N. Leavitt, “Is cloud computing really ready for prime time?,” Computer, vol. 42, pp. 15–
20, Jenuary 2009.
[3] D. D. S. L. Youseff, M. Butrico, “Toward a unified ontology of cloud computing,” pp. 12–
16, Grid Computing Environments Workshop, 2008. GCE ’08, November.
[4] R. M. Juan Caceres and B. Rochwerger, “Reservoir: An architecture for services, the first
issue of the reservoir architecture document.” http://www.reservoir-fp7.eu/fileadmin/
reservoir/delivarables/080531-D1.1.1-c.pdf, June 2008.
[5] K. J. Higgins, “Report: Attacks on isp nets intensifying.” http://www.darkreading.com/
security/management/showArticle.jhtml?articleID=208804736, September 2007.
[6] G. Sandoval and T. Wolverton, “Leading web sites under attack.” http://news.cnet.
com/2100-1017-236683.html, February 2000.
[7] A. Networks, “Worldwide infrastructure security report.” http://www.arbornetworks.
com/report, November 2008.
[8] P. Kumar and S. Selvakumar, “Distributed denial-of-service (ddos) threat in collaborative
environment - a survey on ddos attack tools and traceback mechanisms,” in Proceedings
of the IEEE International Advance Computing Conference 2009 (IACC-2009), pp. 1275–
1280, March 2009.
[9] L. Eagle, “Ddos attack hits amazon cloud customer hard.” http://www.thewhir.com/
web-hosting-news/100609_Outage_Hits_Amazon_Cloud_Customer_Hard, October 2009.
[10] P. Ferguson and D. Senie, “Network ingress filtering: Defeating denial of service attacks
which employ ip source address spoofing.” http://www.ietf.org/rfc/rfc2827.txt, May
2000.
[11] R. C. J. B.B. Gupta and M. Misra, “An isp level solution to combat ddos attacks using
combined statistical based approach,” Journal of Information Assurance and Security,
pp. 102–110, March 2008.
[12] H.-V. Nguyen and Y. Choi, “Proactive detection of ddos attacks utilizing k-nn classifier
in an anti-ddos framework,” International Journal of Electrical, Computer, and Systems
Engineering, vol. 4, no. 4, pp. 247–252, 2010.
[13] C. Vázquez, E. Huedo, R. S. Montero, and I. M. Llorente, “Dynamic Provision of Com-
puting Resources from Grid Infrastructures and Cloud Providers,” in Proceedings of the
International Conference on Hybrid Information Technology, pp. 113–119, 2009.
[14] I. R. Ian Foster, Yong Zhao and S. Lu, “Cloud computing and grid computing 360-
degree compared,” in Grid Computing Environments Workshop, 2008. GCE ’08, pp. 1–10,
November 2008.
[15] “Federica - federated e-infrastructure dedicated to european researchers innovating in
computing network architectures.” http://www.fp7-federica.eu/.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-139
Vulnerabilities and Protection of Satellite

Networks interconnected with terrestrial
segments
F.BELLIa, M. LUGLIOa, C. ROSETIa,1
a
Centro Radioelettrico Sperimentale Marconi CRESM, Tor Vergata research unit, via
del Politecnico 1, 00133, Rome.
Abstract. Integration of different networks enhances sustainable applications but

specific vulnerabilities must be faced up too. New network components often are
introduced to efficiently adapt different technologies, whereas in some cases they
can be exploited as sources for generation of anomalous events in the
interconnected networks attributable to security attacks. This paper deals with
security for heterogeneous and inter-operable communication networks including a
satellite segment, focusing on the application of an Intrusion Detection System
(IDS) on the target scenario. The baseline envisages the presence of Performance
Enhancing Proxies (PEPs) at the edges of satellite links, which implies the twofold
effect of improving TCP performance but also increasing a PEP-related
vulnerability due to the violation of the end-to-end semantic of TCP. The paper
addresses the above mentioned issue through the realization of a test bed including
a real geostationary satellite link operated by Telespazio. Outcomes of experiments
show the effectiveness of the application of the proposed IDS system.
Keywords. IDS, PEP, TCP, security, satellite, emulation
Introduction
One of the major trends in the commercial communications market is the adoption of
wireless technology. In addition, the need to exchange information anywhere and
anytime requires the adoption of system architectures composed of different inter-
operable and cooperative subsystems based on different technologies and standards. In
this context, geostationary (GEO) satellite systems are particularly suited to support
broadband applications over large areas with meaningful flexibility.
From a security perspective, the utilization of a satellite segment in an integrated
architecture leads to vulnerabilities that can be classified as follows:
• “Satellite-specific” vulnerabilities, which completely rely on satellite
characteristics and technologies (usually involving lower protocol layers); both
exploitation of these vulnerabilities and possible remediation are bounded in the
satellite domain with only an indirect impact on the interconnected networks;
some examples are the eavesdropping, the satellite jamming, the unauthorized
access to broadcast services, etc.
1
140 F. Belli et al. / Vulnerabilities and Protection of Satellite Networks Interconnected
• “Non satellite-specific” vulnerabilities, which are common to all the IP-based

networks (i.e. IP data corruption, interception, etc.); both vulnerability
exploitation and remediation are irrespective of the target communication
segment;
• “Satellite intersection-based” vulnerabilities, which rely on satellite technology
needed to support interconnection with terrestrial networks.
The latter class is the most compliant with the scopes of the INTERSECTION
project [1], which is aimed to both design and implement an Intrusion Detection
System (IDS) for the detention of anomalous events in the interconnected networks. An
important framework concerns technology solutions aimed to guarantee good
performance over the satellite link. In fact, the use of traditional TCP/IP stack and
related paradigms [2] implies poor performance since the basic features of the protocol
design don’t match with the actual environment characteristics. Scientific literature and
commercial products have largely addressed this issue proposing a vast gamut of
protocol and architectural solutions [3][4][5].
A common baseline envisages the use of PEPs at the edge of satellite links with the
main scope to “accelerate” TCP over satellite [3]. PEP is mainly based on a splitting
architecture, which divides end-to-end connections into multiple sub-connections, each
one adopting a transport protocol suited to the link characteristics: i.e. delay, bandwidth,
Bit Error Rate (BER). Over the satellite link, ad-hoc transport protocols usually replace
standard TCP.
Although performance improvement is significant, PEP-based architecture is
intrinsically vulnerable due to the violation of the TCP end-to-end semantic. A PEP
intentional or unintentional failure (i.e. dropping of locally acknowledged packet
before reaching actual destination) leads to an irreversible break of the end-to-end
reliability. Implications on security are straightforward since TCP is used to provide
transport services also to comply with severe requirements in terms of reliability.
This vulnerability is addressed by the developed IDS, which has been properly
tailored to detect anomalous events along interconnected networks and provide
countermeasures to avoid system failure. More in detail, the overall IDS architecture
envisages distributed modules for detection, modules for reaction/remediation and
modules for the visualization. Both target vulnerability and IDS have been
implemented in a demonstration test bed composed of three real interconnected
domains:
• a satellite domain,
• a terrestrial wired domain operated by a mobile telecommunications provider,
• a terrestrial wired domain operated by a telephone operator.
IDS configuration for the PEP-related vulnerability has been then validated using a
real satellite environment composed of a GEO link operated by Telespazio [6] and
some Linux-based emulated machines, which reproduce main elements/dynamics of a
Digital Video Broadcasting – Return Channel on Satellite (DVB-RCS) satellite
network.
1. Reference scenario and performance optimization
The reference scenario is represented in Figure 1. It envisages a star based architecture

with multiple RCS Satellite Terminals (RCSTs or STs) connected to a Gateway/Earth
Station via a transparent GEO satellite. Each ST offers an Internet access to one or
F. Belli et al. / Vulnerabilities and Protection of Satellite Networks Interconnected 141
more end-systems. On the other side, the satellite gateway provides interfaces with the
Internet and then with remote servers.
DVB-S (DVB over Satellite) standard [7] is adopted for data broadcasting in the
satellite forward link. DVB-RCS [8] allows bidirectional communications allowing up
to 2 Mbit/s in the return link. STs share the bandwidth on a Multi Frequency-Time
Division Multiple Access (MF-TDMA) discipline [8][9] through a Demand
Assignment Multiple Access (DAMA) scheme. A Network Control Centre (NCC)
assigns time slots as a response to explicit requests (Bandwidth on Demand) coming
from STs issuing the Terminal Burst Time Plan (TBTP) broadcasted through the
forward link every superframe. DVB-RCS standard allows fixed or dynamic time slot
allocations according to five different schemes:
1. Continuous Rate Assignment (CRA), which is a fixed and static allocation of
resources agreed between the ST and the NCC in the initial set up phase;
2. Rate-Based Dynamic Capacity (RBDC), which allocates capacity dynamically
requested on the basis of rate measurements performed by the ST;
3. Volume-Based Dynamic Capacity (VBDC) allocates capacity dynamically
requested on the basis of data volume measurements performed by the ST (these
requests are cumulative);
4. Absolute Volume-Based Dynamic Capacity (AVBDC) is similar to VBDC, but
requests are absolute. AVBDC is used for loss recovery in the VBDC mode;
5. Free Capacity Assignment (FCA) allocates capacity to STs from “spare” capacity
that otherwise would be unused.
Figure 1: Reference scenario
Users accessing the network resources through STs are supposed to utilize
common IP services and more specifically TCP-based applications (i.e. WWW, FTP, e-
mail, etc.). TCP suffers from a certain number of factors when runs over satellite links
[4][10][11][12][13]. The Slow Start phase performed by TCP to probe for available
capacity becomes inefficient over satellite links. Specifically, the high latency, up to
two orders of magnitude larger than latency in terrestrial networks, drastically slows
down the TCP congestion window (cwnd) growth and most of the typical TCP
transfers (from dozens of kbytes up to several Mbytes) conclude before TCP reaches its
optimal window. This implies a huge waste of the available capacity. Furthermore, in a
DVB-RCS environment, the use of DAMA mechanisms implies that TCP experiences
an actual Round-Trip Time (RTT) well above the two-way propagation delay and the
available capacity may vary strongly and abruptly [14][15].
In literature a large number of solutions have been proposed to improve TCP
performance over satellite links [13]. A possible classification of proposed solutions is
the following:
• Non-TCP enhancements – provision of enhanced lower layers; in other words,
TCP can indirectly benefit from mechanisms running at different protocol layers;
• TCP standard enhancements – extensions compliant to standard TCP protocol
specification;
• TCP variants – modifications of the standard flow, congestion and error recovery
schemes;
• PEPs – modifications of the TCP end-to-end semantic (including architectural
modifications) [3].
Transport protocol over DVB-RCS is defined into Interoperable-PEP (I-PEP)

specification [16], which includes the use of several TCP enhancements as either
mandatory (i.e. new Selective Negative ACKnowledgement-SNACK option [16]) or
optional (i.e. Timestamps [17]). In addition to standard TCP congestion control
algorithm, also TCP Vegas [18] is allowed as TCP default variant. On the other hand,
[16] allows to add on PEP an optimized TCP-based transport protocol with the
constraint of guaranteeing interoperability with other PEPs supporting only default
transport protocols. In this frame, TCP Noordwijk [20] is an optimized transport
protocol for I-PEP that hereinafter is considered as an efficient solution for satellite
DVB-RCS communications. A validation is provided in [20][21][22], while some
further details about involved technology are presented in the next sub-sections.
2. Description of the PEP-based vulnerability
A PEP-based vulnerability is based on the violation of the TCP end-to-end semantic. In

fact, PEP, after having received TCP packets, forwards them towards TCP receiver and
generates/sends local acknowledgements (ACKs) towards TCP sender. The rationale is
to make faster TCP congestion window growth, and then increase the actual
transmission rate, since it depends on ACK reception timing. In this context, a PEP
intentional or unintentional failure after an ACK sending but before checking the
correct arrival of the corresponding packet to the actual receiver leads to an irreversible
break of the end-to-end reliability, which is one of the main assumptions of TCP
protocol. Implications on security are extremely harmful since TCP can be used to
provide transport services to application with severe reliability requirements (i.e. bank
transfers, mails, etc.). Figure 2 shows a possible attack scenario.
Specifically, a malicious user in the same network of a target legitimate TCP
source can access PEP in front of satellite gateway with the aim of installing a malware
application that performs the task to drop either a part or all TCP packets flying
towards Internet through the satellite link. Different harmful effects can be caused
depending on both malware implementation and considered application protocol:
• loss of several packets within a connection, which causes continuous
retransmissions, for instance after a retransmission timeout expiration, increasing
transfer time;
• packet dropping, which does not allow the application to successfully conclude its
operations whereas sender application is aware of the negative transfer outcome;
• packet dropping, which is transparent to applications that trusts on a successfully
transfer.
Figure 2: Threat exploiting PEP-related vulnerability

The first effect is not strictly related to a classical attack, since file transfer is
finally achieved although delayed and forced retransmissions require additional
satellite resources (usually very expensive). This is a logical attack that leads to Quality
of Service (QoS) degradation and increases both the service costs and congestion level
of satellite return link, which usually represents the bottleneck of the whole link.
The second effect is a typical Denial of Service (DoS) attack. All TCP-based
transfers fail. Furthermore, in case the user terminal is downloading a file from the
Internet, packet dropping is performed after having crossed the satellite link. Therefore,
satellite transport service is accounted although not actually exploited.
The last effect is surely the most harmful as far as the security is concerned. In fact,
TCP sources (i.e. FTP clients performing file uploads) trust on a correct progress and
completion of transfers, while packets do not reach the desired destination. The
acknowledgment to have correctly transferred a file can imply, in the worst case,
cancelation of the sent file. This attack has an intrinsic heterogeneous nature since it
exploits a vulnerability of the satellite network; it is generated from terrestrial network
and it impacts on a server located along the Internet.
3. IDS for satellite network protection
To face with the above described scenario (vulnerability of interconnected networks)

an IDS has been developed. It integrates different functions and components
(monitoring, detection, reaction, remediation, visualization and topology discovery),
which cooperate to increase network protection and security in a real-time and

automated fashion. The goal is to gather data from probes and network elements, to
analyze it, to detect intrusions, and to select the most suitable remediation action
against the detected attack. In addition, off-line functions aim at using data coming
from the network or provided by the real-time part of the framework in order to help
the human operator in analyzing the network state and make the network more secure.
Monitoring implies distributed, freely configurable measurements and employs
different processing methods. Data can be read from various network probes and
exported using IPFIX standard messages.
The network-level IDS analyzes traffic metrics provided by the network
monitoring component to identify the attack occurrence. If an attack is detected, an
alert raised by the IDS is sent to the reaction component. Such a component processes
the received signals of either anomalies or other network changes and deploys the most
suitable remediation mechanism able to restore correct service. In more details,
network-level IDS includes several functional entities: a set of nodes (Detection
Engines), able to analyze the information provided by network probes, evaluating the
traffic descriptor parameters to identify possible anomalies; a Decision Maker that
determines if the detected anomaly can be forwarded as an attack or not to an external
entity; a central traffic manager (Data Broker) which forwards the incoming network
probes’ data to the proper detection engine. Detection Engine is in charge to correlate
information coming from diverse and multiple data feeds, such as the network-level
IDS, the Operating System-level probes, and the application-level probes, and taking
the final decision on whether the collected information represents a potential attack or
not.
3.1. IDS configuration for PEP-based attacks
An intrusion system based on the above architecture has been designed to deal with
attacks exploiting PEP vulnerability.
Satellite IDS exploits two types of probes based on OpenIMP [23]: the SYN
detector and the TCP traffic analyzer. The “SYN detector” is installed on the satellite
gateway and is in charge to monitor all the TCP traffic in order to create an IPFIX
record for every SYN/FIN exchange through the satellite link. Each record includes the
parameters identifying the specific connection and it is enhanced with the time
information. “TCP traffic analyzer” probes run on the access router of all the networks
interfaced to the satellite segment. Such probes aim to collect statistics about TCP
traffic coming from and going to the satellite network. Specifically, a TCP traffic
analyzer grabs the number of transferred bytes over any active TCP connection. A time
interval must be defined for such measurements. A large value allows a better
measurement accuracy, but it slows down statistic updates for the attack detection
matters. On the contrary, a low value could be affected by transitory traffic dynamics,
as for instance unexpected traffic spikes or idle times. Therefore, a trade-off value of 10
s has been chosen as default.
All the probe records are collected by a data broker, which represents the first
functional element of the IDS. Data broker is in charge to forward the received records
to the Detection Engine, which implements the following detection logic:
Step 1 - Compare the number of SYN and FIN records coming from the SYN
detector probe; if #SYN #FIN, regular operations are assumed; otherwise
(i.e. #SYN - #FIN > threshold = 90) detection process moves to step 2;
Step 2 - Delete <SYN ; FIN> pairs related to a same connection; residual SYN
records will provide information on networks involved in possible attack.
Step 3 - For each connection under investigation, compare the amount of bytes
crossing corresponding source-destination networks; results are computed in
the form of “byte differences”.
The achieved results are then forwarded to the decision maker that determines if
what has been detected as an anomaly can be interpreted as an attack from an external
entity and thus forward the relative commands. Basically, decision maker compare the
“byte difference” metric with a pre-determined threshold.
The Reaction and Remediation (ReaRem) subsystem involves a Reaction Engine, a
repository of scripts used for the attack remediation, and a Remediation Point, which
represents the network element where such scripts will be run. Specifically, when an
attack is detected (decision maker issues a trigger), the Reaction Engine downloads the
proper script from its repository to stop PEP misbehavior. This script, executed in the
Remediation Points/PEPs, performs a procedure aimed to temporary disable PEP
involved in the attack in order to recover correct settings: delete of the malware and
reset PEP routing tables.
Deployment of the overall IDS system over the considered scenario is shown in
Figure 3.
Figure 3: IDS for PEP-related vulnerability
4. Tests on PEP related attack, detection and remediation
4.1. Test configuration
Target vulnerability has been reproduced in a communication scenario where a satellite

geostationary link, operated by Telespazio (TSP) [6], is used to interconnect a remote
terrestrial LAN, belonging to Polska Telefonia Cyfrowa (PTC) [24], with an Internet
Service Provider (ISP) represented by Telefonica (TID) [25]. TID interfaces the
satellite terminal, while PTC interfaces satellite gateway. For both links, GRE tunnels
[26] are set up.

Test bed core relies on hardware in the loop configuration where a real satellite
link (Intelsat IS906 @ 64° E) operating at Ku band with a channel of 300 kHz is
accessed by two satellite modems. At the edges of such a satellite link, both a Satellite
Gateway/Network Control Centre (satGW/NCC) and RCST functionalities are
emulated through Linux-based machines. PEP agents are installed in both satGW/NCC
and RCST machines.
The application implemented for test purposes is based on a traffic generator,
running on a TID machine. Basically TCP connections with a machine installed in PTC
are generated over different ports on the basis of the following input parameters:
average rate of the overall data flow and the amount of bytes to transfer over any
connection. In the tests presented below, the average rate is set to 200 kbit/s and the
amount of byte in a single connection is taken equal to 100 kbytes.
4.2. Test description
The test can be divided in 4 phases, each one triggered by a specific event.
1. TCP traffic generator located in TID starts file uploads on a remote server (PTC).
Operations are regular in the sense that transfers are correctly performed with
performance optimized thanks to the PEP acceleration.
2. A malicious user in the TID network access the PEP and install on it a malware
able to drop all the TCP packets crossing over some specific ports (attack could
also address a subset of the connections) after that they are correctly
acknowledged by the PEP itself.
3. After a certain amount of time, IDS detects a traffic anomaly and sends an alert
signal.
4. The alert signal triggers in turn an early remediation procedure first aimed to
guarantee service continuity. Such a remediation relies on the disabling of PEP
functionalities for the networks involved in the attack. Then, service is restarted
although performance is no longer optimized.
4.3. Results
Results are summarized in Figure 4 and Figure 5. Over the first 210 s of simulation,
ordinary operations are detected on the network: the number of active connections
oscillates around the expected average (50) and throughput measured at both sides of
the satellite link is similar. In fact, IDS configuration envisages an active connection
threshold of 90 s and a threshold for the throughput asymmetry equal to 75 kbit/s. In
general, these values have to be tuned on the basis of a training period where
characteristics of the ordinary traffic profile are observed.
At 210 s, malware starts running. Malicious packet dropping does not allow
correct connection terminations. As a consequence the number of active connections
grows more and more (see Figure 4). At about 250 s, the number of the active
connections overcomes the threshold value. Then, IDS performs the second step of the
detection process comparing measured throughput at the edges of the PEP-PEP satellite
link. From Figure 5, it is evident the high experienced asymmetry. During the attack,
TCP senders (Figure 5-a) continue to transmit without suspecting any packet dropping.
On the other side, TCP receivers receives only a minimum part of packets (attack is
designed to allows transmission of sporadic packets in order to keep connections on)
and experienced throughput is much lower than the one measured at the sender side.
The joint compliance of the above conditions with characteristics assumed for the
attack profile leads to the issue of an alert message that, in turn, triggers the
remediation procedure. Then, after a short time needed to disable PEPs instances
involved in the attack, a reliable connectivity is restored and connections starting
afterwards are successfully performed. With a particular reference to the Figure 5-b, it
is possible to observe a decrease of the overall throughput due to the stop of TCP
acceleration provided by PEPs.
Figure 4: Track of the “SYN detector” records
(a) Throughput at the client side (b) Throughput at the server side
Figure 5: Tracks of the “TCP traffic analyzer” records
5. Conclusions
This paper presents the design of an IDS tailored to security issues coming from the
adoption of PEP at the edges of the satellite link for a network composed of different
segments. PEP is utilized to improve TCP performance over satellite links, but it is
intrinsically vulnerable because it implies the violation of the TCP end-to-end-
paradigm. The proposed IDS addresses PEP-related vulnerability with the aim to make
possible the combination of optimized performance and network protection, as
requested by the future Internet framework. The whole system has been reproduced and
tested on a test bed including a real satellite link operated by TSP. Achieved results are
promising and demonstrate that the combination of detection and remediation methods
in an automatic procedure can actually improve security. Security management is then

in charge to the system itself, which sorts target objectives as follows: security, service
continuity, optimized performance. The presented IDS can represent a valid baseline
for the architecture of the future Internet associating security to performance-oriented
solutions.
References
[1] INTERSECTION project (Seventh Framework Programme under the Area 5 subprogramme: “Security,
Privacy and Trust in the Future Internet”), http://www.intersection-project .eu
[2] W. Stevens, “TCP/IP Illustrated. Vol.1”, Ed. Addison Wesley, 1994.
[3] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby. Performance enhancing proxies intended to
mitigate link-related degradations. RFC 3135, IETF, June 2001.
[4] C. Partridge, T. J. Shepard, “TCP/IP Performance over Satellite Links,” IEEE Network, September
October 1997, pp. 44-49.
[5] C. Caini, R. Firrincieli, M. Marchese, T. De Cola, M. Luglio, C. Roseti, N. Celandroni, F. Portontì,
Transport Layer Protocols and Architectures for Advanced Satellite Networks, International Journal of
Satellite Communications and Networking, Vol. 25, Oct. 2007, pp. 1-26, DOI:10.1002/sat.855.
[6] http://www.telespazio.it
[7] ETSI, “Digital Video Broadcasting (DVB): DVB Framing Structure, Channel Coding and Modulation for
11/12 GHz Satellite Services”, EN 300 421.
[8] ETSI, Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems, DVB-
RCS standard, EN 301 790.
[9] ETSI, Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems,
Guidelines for the use of EN 301 790, TR 101 790, V. 1.2.1, 2003.
[10] M. Allman, C. Hayes, H. Kruse, and S. Osterman, TCP Performance over Satellite Links. 5th Int.
Conference on Telecommunication Systems Modeling and Design, 1997, pp. 1-13.
[11] Y. Zhang, Interworking and Computing over Satellite Networks. Kluwer Academic Publishers, 2003.
[12] T. Lakshman, and U. Madhow, The Performance of TCP/IP for Networks with High Bandwidth-Delay
Products and Random Loss. IEEE/ACM Transactions on Networking, vol. 5, n. 3, 1997, pp. 336-350.
[13] M. Allman, D. Glover, L. Sanchez, Enhancing TCP over Satellite Channels using Standard Mechanism,
RFC 2488, January 1999.
[14] M. Luglio, C. Roseti, F. Zampognaro, “Improving Performance of TCP-Based Applications over DVB-
RCS Links”, IEEE International Conference on Communications, 2009, (ICC’09), 14-18 June 2009
Page(s):1 - 6 DOI: 10.1109/ICC.2009.5199077.
[15] C. Roseti, E. Kristiansen, TCP behavior in a DVB-RCS environment, in Proceedings 24th AIAA
International Communications Satellite Systems Conference (ICSSC), San Diego, Jun. 2006.
[16] Interoperable PEP (I-PEP), Transport Extensions and Session Framework for Satellite
Communications: Air Interface Specification, Oct. 2005.
[17] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, May 1992.
[18] L. Brakmo and L. Peterson. TCP Vegas: End to End Congestion Avoidance on a Global Internet. IEEE
Journal on Selected Areas in Communication, Vol 13, No. 8 (October 1995) pages 1465-1480.
[19] ESA ARTES-1 project, “Transport Protocol for DVB-RCS Interactive PEP”,
http://telecom.esa.int/telecom/.
[20] C. Roseti, E. Kristiansen, “TCP Noordwijk: TCP- Based Transport Optimized for Web Traffic in
Satellite Networks “, accepted to the 26 International Communications Satellite Systems Conference
th
(ICSSC), San Diego (CA), 10-12 Jun. 2008.

[21] M. Luglio, C. Roseti, F. Zampognaro, “Improving Performance of TCP-Based Applications over DVB-
RCS Links”, IEEE International Conference on Communications, 2009, (ICC’09), 14-18 June 2009
Page(s):1 - 6 DOI: 10.1109/ICC.2009.5199077.
[22] C. Roseti, M. Luglio, F. Zampognaro, Analysis and Performance evaluation of a burst-based TCP for
Satellite DVB RCS links, accepted on IEEE/ACM Transactions on Networking.
[23] http://openimp.sourceforge.net
[24] http://www.era.pl/
[25] http://www.telefonica.com
[26] D. Farinacci, T. Li, S. Hanks, D. Meyer, P.Traina, “Generic Routing Encapsulation (GRE)”, RFC 2784,
Mar. 2000.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-149
Creating a Reference Architecture for

Service-Based Systems -
A Pattern-Based Approach
Vanessa Strickera, Kim Lauenrotha, Piero Corteb, Frédéric Gittlerc,
Stefano De Panfilisb, and Klaus Pohla
a
University of Duisburg-Essen, Germany
b
Engineering Ingegneria Informatica S.p.A., Italy
c
HP Hewlett Packard European Laboratories – Bristol, UK
Abstract. The variety of technologies and standards in the domain of service-

based systems makes it complex to build architectures which fit specific project
contexts. A reference architecture accompanied by guidelines for deriving context-
specific architectures for service-based systems can ease this problem. The
NEXOF-RA project is defining a reference architecture for service-based systems
that serves as a construction kit to derive architectures for a particular project
context. Experience in developing the reference architecture over the last two
years has shown that the service-oriented context results in different and
sometimes contradicting demands for the reference architecture. Therefore, the
development of a single and integrated reference architecture is not feasible.
Instead, for constructing the reference architecture, the project has chosen a
pattern-based approach that allows the consideration of different types and
demands of service-based systems. Thus it can deal with contradicting demands of
different types of service-based systems and is extensible to include new future
trends of service-based systems. This paper will present the structure of the
pattern-based reference architecture and explain how it addresses the needs of a
reference architecture for service-based systems.
Keywords. Service-Based Systems, Service-Oriented Architecture, Reference

Architecture, Pattern-Based Reference Architecture.
1. Introduction
Shaping the Future Internet around the new service-oriented paradigm has become an
important task in research and industry, especially, considering the importance of this
infrastructure as information, service, and networking means to the overall society
world-wide. Taking the open world assumption of the Internet into account, the path
towards the Future Internet reveals an omnipresent trend towards the integration and
federation of heterogeneous service-based systems (SBS) from various domains.
Different trends like software as a service, cloud computing, Internet of Services,
Internet of Things, and web 2.0/3.0 result in the need for different types of architectures
to support these different SBSs. Thus, the Future Internet needs to be architected in a
way that allows the integration and federation of these SBSs.
Considering the large number of technologies and standards that emerged to
address different aspects of architectures for SBSs, defining a specific architecture that
150 V. Stricker et al. / Creating a Reference Architecture for Service-Based Systems
meets designated requirements is not an easy task. A reference architecture for SBSs as
it is created within the NEXOF-RA 1 project under the umbrella of the European
Technology Platform NESSI 2 (Networked European Software & Services Initiative)
will allow providing guidance in this process. NEXOF, the NESSI Open Service
Framework, is “[…] an integrated, consistent and coherent set of technologies and
associated methods and tools […]”.
The need to capture and address the different (sometimes contradicting)
requirements of different types of SBSs and their characteristics has resulted in the
adoption of a pattern-based approach within the NEXOF-RA project. The pattern-based
approach has been implemented to allow the derivation of specific architectures for
specific contexts in different domains following the generally known idea of
architectural or design patterns (cf. [3], [4]). In this sense, the approach fosters the
creation of a reference architecture as a system of patterns as described by Buschmann
et al. (cf. [5], [6]) that can be composed to a specific architecture according to specific
requirements. Accordingly, each different type of SBS is described by a system of
patterns. In comparison to other existing reference architectures such as the OASIS
reference architecture, this pattern-based reference architecture allows the integration
and federation of different types of SBSs as well as the possibility to cope with new
emerging trends in the future.
In its ambition to provide a reference architecture that allows the easy derivation
and creation of specific architectures, the pattern-based reference architecture can be
seen as a construction kit that provides a system architect with necessary instruments.
This ambition raises different expectations going beyond the scope of traditional, well-
known architectures. This paper presents the structure of the reference architecture that
has been defined around the pattern-based approach considering all these goals.
In order to develop a reference architecture that addresses the creation of SBSs the
first step is to choose a structure for this reference architecture. This means to
understand the goals the reference architecture needs to satisfy and to identify the
elements that constitute the reference architecture. Related work that addresses these
questions for traditional reference architectures in software engineering is discussed in
Section 2. Section 3 discusses the implications for the pattern-based reference
architecture based on the related work and explains why its goals go beyond traditional
reference architectures known in the software engineering community. In Section 4 the
resulting structure of the pattern-based reference architecture, its individual elements
and their relationships is explained. Furthermore, the relevance of the different
elements for deriving specific architectures is explained. In Section 5 finally, the
presented results are discussed critically and an outlook on future work is given.
2. Structures of Traditional Reference Architectures
Reference architectures and the definition of their content have a long tradition in
software engineering as well as information science research. They play an important
role because of several reasons. Different authors classify them in a slightly different
way but one main reason for their usage that all definitions have in common, is the
notion of reuse to ease the creation of new systems by building upon proven knowledge
1
www.nexof-ra.eu
2
www.nessi-europe.com
V. Stricker et al. / Creating a Reference Architecture for Service-Based Systems 151
and experience. By proposing a framework for a systematic reuse of knowledge and

software they can for example shorten development time while increasing the quality.
“As shown for the reuse of software artifacts in software engineering, it is assumed that
this reuse is especially efficient if it is not performed ad hoc but systematic, planned,
and supported by sound methods.” [11]
Reference architectures can be refined and adapted to derive different specific
architectures [7]. Bass et al. [10] also consider reference models to be an important
artifact accompanying reference architecture construction and usage: “A reference
model is described as a division of functionality together with data flow between the
pieces. […] Arising from experience, reference models are a characteristic of mature
domains. [...] Whereas a reference model divides the functionality, a reference
architecture is the mapping of that functionality onto a system decomposition.”
In the following two different classifications of reference architectures and their
characteristics are presented which served as a basis for deriving the goals, and the
structure of the pattern-based reference architecture.
2.1. Beneken
Beneken [8] defines a reference architecture as an abstract software architecture

that defines structures and types of software elements as well as their possible
interactions and responsibilities applicable for all systems in this domain. Beneken
distinguishes between three different types of reference architectures.
x Functional reference architectures separate the functional range of systems into
logical functional concerns. The collaboration and the data flow between those
concerns as well as their responsibilities and hierarchical dependencies are
specified.
x Logical reference architectures define structures using layers and components as
well as their hierarchy and communication dependencies. Defining the structure in
an implementation manner without making implementation decisions or using
specific technologies is the primary focus of this type.
x Technical reference architectures define components as a unit of implementation
and deployment and determine a specific technology to realize them. Several
technical reference architectures can adhere to one logical reference architecture.
Components that are defined in the technical reference architecture refine
components of the logical reference architecture.
These different types of reference architectures are designed to achieve different
goals. While a functional reference architecture will be relevant in the early phases of
the software development, a technical reference architecture will most likely be used
when the detailed architecture needs to be specified and implemented. Beneken also
distinguishes the following different elements and related views that should be
documented by the reference architectures:
x Architectural overviews only provide an informal description of the coarse-grained
structure of the software systems in a specific domain.
x Textures describe the structures, principles, and design concepts that are frequently
used in software systems of a specific domain. Structures of components can be
described in terms of their responsibilities, communication dependencies, and
potential interfaces. Principles that address crosscutting aspects can be described,
by defining design and implementation rules as well as policies.
x Reference interface specifications describing external visible behaviour allow

components to become independent of any implementation and thus exchangeable.
x Infrastructures described by a reference architecture constraint the communication
dependencies between components as well as the behaviour of the system during
runtime. This view defines which basic services are provided by the used resources.
While functional reference architectures most likely only provide an architectural
overview and name some of the interfaces, the logical and technical reference
architectures provide views for the overview, the textures, the interfaces as well as the
infrastructure focusing on different aspects. The infrastructure, for example, would
only be described in its fundamental elements in a logical reference architecture while
it would be fully and precisely described in a technical reference architecture.
2.2. Vogel et al.
Vogel et al. [9] also define reference architectures as a means to combine general
architectural knowledge and experiences with specific requirements to derive an
architectural solution in a certain context: “They [reference architectures] define
structures of systems, essential building blocks, their responsibilities, and their
collaboration.” Reference architectures can be used by a system architect to derive a
specific architecture specification. They differentiate between different types of
reference architectures focusing on their usage context:
x platform-specific reference architectures should be adopted without any adaptation
x industry specific reference architectures focus on the needs of companies in a
specific area
x industry crosscutting reference architectures cover more than one industry
x product line architectures describe architectures for similar software products
The description of the reference architectures should be based on well known and
proven principles, types, and patterns. For each reference architecture a reference
model should be defined that captures the functionalities and the information flow
between functional blocks of a problem space addressed by a certain reference
architecture. The reference architecture specifies how functional building blocks are
distributed on system building blocks as well as their responsibilities and collaborations.
In order to enable the usage of the reference architecture, sufficient documentation and
guidelines towards a stepwise adaptation should be provided. These documentations
should provide a mapping between the reference model and the reference architecture
and describe which architectural means, decisions, and impacts have been considered.
3. Towards the Pattern-Based Reference Architecture
The basic research on reference architectures presented in the last section was used
within the NEXOF-RA project to identify the implications for the pattern-based
reference architecture for SBSs.
3.1. Implications for the Reference Architecture
On the one hand, the reference architecture for SBSs should provide a framework that
allows the integration of research results, allowing the identification of gaps in the
current solution landscape. To construct such a reference architecture, existing

solutions, standards and technologies should be used and combined in a way that
reasonable system architectures can be derived. This is a crucial aspect of the reference
architecture since there are already hundreds of standards and partial solutions out there
and there is no need to invent from scratch.
On the other hand, the reference architecture aims at being a construction kit from
which specific architectures can be derived allowing SBSs to be integrated, federated,
and also to be implemented. The ambition of the pattern-based reference architecture is
that all steps that need to be performed from the requirements to the real
implementation of a SBS can be supported by providing all these architecture views.
The pattern-based reference architecture furthermore tries to address several domains
and not only one as it is generally assumed for reference architectures. Although, all of
the addressed architectures are defined for SBSs, these systems can be very different in
their goals, scope, and needs.
Considering these ambitions the reference architecture developed in the NEXOF-
RA context cannot be classified as one of the above mentioned types (cf. Beneken [8])
of reference architectures without any overlaps. It needs to specify different views
providing functional aspects, a logical decomposition but also technical information.
The elements addressed by Beneken in the architectural overview, the textures, the
interfaces, and the infrastructure views should all be provided in the pattern-based
reference architecture.
In order to cope with these needs a well defined structure has been developed for
the reference architecture. The pattern-based reference architecture is aimed to be
domain independent and will be accompanied with a sound methodology and tools to
be properly instantiated into a broad range of application domains by a number of end-
user communities (including Large, Medium, and Small Enterprises) on different
technologies. This reference architecture will mainly consist of a set of integrated
specifications recommending different solutions.
The central part of the reference architecture depicts a system of patterns as
described by Buschmann et al. (cf. [5], [6]) that allows the integration of different
families of systems addressing different types of SBSs, e.g. a family for Enterprise
SOA or the Internet of Services. However, the specification of this pattern system is
not sufficient to provide a valuable reference architecture from which specific
architectures can be derived. It is accompanied with several other elements that foster
the instantiation.
3.2. The Pattern-Based Approach
One of the fundamental principles of software engineering that is largely used when
designing a software system is known as the “separation of concerns”. In short, this
principle states that a larger problem is more effectively solved when decomposed into
a set of smaller problems or concerns. This gives software engineers the option of
partitioning solution logic into capabilities, each designed to solve an individual
concern. Related capabilities can be grouped into units of solution logic. The main
benefit of solving problems this way is that a number of the solution logic units can be
designed to solve immediate concerns while still remaining agnostic to the greater
problem. This provides the constant opportunity to reuse the capabilities within those
units to solve other problems as well.
The NEXOF-RA approach is based on the principle of separation of concerns. The

objective of the pattern-based reference architecture is to address the problem of
specifying service-based software system architectures by partitioning the overall
solution into several pieces of the design solution: patterns. In particular, the need for a
development methodology to develop large-scale complex systems and, at the same
time, learn from the experiences of other system designers in solving recurring design
problems has been recognized. “A pattern can be thought of as a set of constraints on
an architecture – on the element types and their patterns of interactions – and these
constraints define a set or family of architectures that satisfy them.” [10]
In 1994 the Gang of Four already recognized the need to make a design evolvable
and proposed the usage of patterns to ensure this: “The key to maximize reuse lies in
anticipating new requirements and changes to existing requirements in designing your
systems so that they can evolve accordingly. To design the system so that it’s robust to
such changes, you must consider how the system might need to change over its
lifetime. […] Design patterns help you […] by ensuring that a system can change in
specific ways. Each design pattern lets some aspect of system structure vary
independently of other aspects, thereby making a system more robust to a particular
kind of change.” [4]
Usually, the documentation of design patterns, as it stands, describes details about
the problem space that needs to be addressed as well as an according specific
design/architectural solution for a sub-system, i.e. its structure, component behaviors,
component interaction, and global properties. Furthermore, the solution provided by a
pattern is given in terms of architectural choices and statements that claim how these
architectural choices affect the quality attributes of a system that is compliant to such a
pattern. Bass et al. [10] have stated that “One of the most useful aspects of patterns is
that they exhibit known quality attributes. This is why the architect chooses a particular
pattern and not one at random.” Effects on a set of predefined quality attributes are
clearly stated within the pattern descriptions in order to foster the derivation of
adequate architecture instances.
The approach is also focused on how to compose these patterns together to develop
complete systems. A complete system cannot nor will ever be built from a single
pattern. It is the integration and composition of patterns that makes a whole system.
Therefore, a structural approach to use patterns as first class design elements is adopted,
i.e. they can be used in the design of a system as any other design element: class,
module and component. This kind of patterns is called constructional patterns.
A constructional pattern is an architectural/design pattern with additional
constraints that allow their composition and integration. A constructional pattern is a
first-class design element that encapsulates a solution to a frequently recurring design
problem, it hides lower level design decisions, and it offers interfaces to other design
artifacts. In this sense, a constructional design pattern becomes a design component
with interfaces. Specifying a pattern as a design element leverages the interest in a
pattern to a higher design level that hides later design details and preserves consistency
with lower levels. The structural approach includes three types of patterns pre-defining
a hierarchy among different patterns.
1. Top-level patterns describe the characteristics of service framework families.
Currently three different types of families are under construction to be integrated
into the pattern-based reference architecture in the NEXOF-RA context: the
Enterprise SOA (ESOA) top-level pattern, the Internet of Services top-level pattern
and the Cloud Computing top-level pattern. Other system families addressing for
example the Internet of Things can easily be integrated into the reference
architecture as a new system of patterns.
2. The top-level patterns are refined by abstract design patterns which refer to
abstract components and patterns. They can be defined and refined on several
levels of abstraction until at least one specific component becomes part of the
solution.
3. Patterns referring to specific implementation components are called
implementation design patterns. The ESOA system of patterns currently includes
42 patterns beside the ESOA pattern itself which are all on an abstract level.
Implementation design patterns will be developed in the next step.
The approach aims at producing a pattern map to show relationships between all
the produced patterns. In order to allow the patterns to be interrelated, the following
five types of relationships between patterns are identified in the pattern-based
approach:
x extends: when a pattern completely refines another pattern;
x isPartOf : when a pattern refines a part of another pattern;
x complementsWith: when a pattern is strongly recommended to be used with
another pattern;
x competesWith: when two patterns provide two mutually exclusive solutions;
x isApplicableTo: when a pattern can be applicable to a part of the design solution
provided by another pattern.
Enterprise SOA
isPartOf(Designer Tool, Runtime,

isPartOf(Security Tool) Management Tool) Designer and
Security in E-SOA Runtime Tools for E-
SOA
isPartOf
isPartOf (Monitoring Tool) (GUIDesigner,
Monitoring in E-SOA GUIRuntime)
Front End in E-SOA
isPartOf(ESB)
Distributed ESB in E-
SOA isPartOf
Multi-tier (ServiceRuntime)
isPartOf Transactional
(ComputationalResouce Service- Runtime
Virtualization of ManagementTool)
Computational isApplicableTo
Resources in E-SOA
isApplicableTo
isPartOf(Registry) Horizontal
Federated Registry in Vertical Replication
Replication
E-SOA
isApplicableTo
isApplicableTo
Figure 1. Excerpt of the ESOA system of patterns

Figure 1 shows an excerpt of the ESOA system of patterns 3 containing the ESOA
pattern itself and two levels of abstract design patterns that refine the abstract
components described by the solution proposed in the ESOA top-level pattern. The
Distributed ESB in E-SOA pattern for example has the dependency isPartOf towards
the Enterprise SOA top-level pattern. The relationship type is annotated with a list of
strings in brackets which refer to the components of the higher-level pattern that are
affected by the refining pattern. In this case the need to include an Enterprise Service
3
The complete system of patterns can be found on http://www.nexof-
ra.eu/?q=node/526
Bus (ESB) in an Enterprise SOA is addressed by a component ESB in the ESOA

pattern for which a more concrete solution with certain architectural choices is
specified in the refining pattern. Due to the competesWith relationship the system of
patterns could also contain an alternative refinement of the ESB component that takes
different, conflicting architectural choices which might apply in a different problem
space. The two patterns Horizontal Replication and Vertical Replication are connected
to the Federated Registry in E-SOA and the Multi-tier Transactional Service-Runtime
patterns with an isApplicableTo relationship. The two replication patterns deal with the
crosscutting issues of high availability and scalability by replicating certain
components of the derived system. Thus, they can be applied in different solution
contexts and not just for one problem space. An important part of these patterns is the
assumption description, that specifies the join points in terms of components,
relationships or certain characteristics of the architectural solution at which the
replication can be applied. The result of the ongoing work will be a pattern map for
ESOA that shows relationships between all the produced patterns and thus allows the
derivation of a comprehensive, architectural solution.
4. The Pattern-Based Reference Architecture
In order to meet the implications discussed in Section 3.1 specifying solely a map of
patterns is not sufficient for the creation of a reusable reference architecture for SBSs.
Instead, a structure that is composed of several elements has been defined for the
pattern-based reference architecture that provides a sound method for systematic reuse
of architectural knowledge in order to derive new architectures for SBSs in certain
context settings. This structure is described in the following section in order to explain
how it is used to construct the pattern-based reference architecture as well as to
describe how it supports the derivation of specific architectures.
4.1. The Structure of the Reference Architecture
The pattern-based reference architecture is composed of several parts, capturing the

information necessary to design service-oriented systems (see Figure 2). The main
constituents of the pattern-based reference architecture are the following three
elements:
The guidelines and principles: This captures on the one hand the principle
underlying the construction of the framework as well as the set of reference properties
associated with each of the components and patterns in the reference architecture.
Capturing this knowledge explicitly allows the pattern-based reference architecture to
be an evolvable, dynamic reference architecture that can be continuously created by an
open community in order to cope with new upcoming trends in the Future Internet.
On the other hands this part captures the guidelines used to instantiate a specific
system architecture according to its requirements. Since the reference architecture will
provide a huge set of architectural solutions and information it is crucial to have sound
methodology that supports system architects during the derivation of actual
architectures for a specific context. This can for example be a decision tree for a certain
part of a system of patterns that helps the architect to evaluate which patterns are the
appropriate ones for a certain context considering the different tradeoffs of the quality
attributes that are associated with them.
The reference architecture model: This is the conceptual model describing the
essential entities that constitute SBSs as well as the relationships between these entities
and the key elements in the context. While the systems of patterns only specify the
internal characteristics of the architecture for a service-based system the model also
considers the applications and services that can be deployed on top of a platform
realizing a derived architecture. Thus, the model tries to capture the whole SBS.
Differentiating between the platform and the whole system is crucial in order to
understand how the platform realizing a derived architecture is used by its surrounding.
Using this knowledge, appropriate architectural solutions can be provided by the
reference architecture. The model provides several different views focusing on
different aspects of SBSs. These views follow the well-know approach of separating
structure, behavior and functionality (cf. [12]). Following the classification of reference
architectures by Beneken [8] the functional decomposition thus can be seen as what is
named a functional reference architecture. Furthermore, part of it can be seen as an
architecture overview of a logical reference architecture.
In addition to the different model views, this section of the reference architecture
contains also a glossary, which defines the terms used across the whole pattern-based
reference architecture. Thus, the reference model is part of the reference architecture
and does not accompany it as an external document as proposed by Vogel et al. [9] or
Bass et al. [10].
S S
Top-level Patterns XXX SOA YYY SOA About:
S S
(system families) • construction principles
S S P P P P P P P P • reference properties
• instantiation guidelines
Guidelines
Standards Catalog and Principles
Pattern 1 Pattern 2
Concrete Abstract
Abstract P S P C C P P
(refers to (class of Glossary
products) products)
Design Patterns
S S Pattern 3 Pattern 4
c C C S C C C C P
SS
c Pattern 5
About:
S c S P C
• actors
C Implementation
Design Patterns • functionality
S Pattern 6 Pattern 7 • information
c c S c c c S c c Conceptual
Model
Component Catalog
(aka. Building Blocks) Pattern Ensemble Reference Model
Reference Specification
Reference Architecture
Figure 2. Structure of the pattern-based reference architecture

The reference architecture specification: This contains three collections: The
standards catalogue describes the standards referred to in the reference architecture.
Each standard is linked to the relevant elements of the guidelines and principles as well
as to the concepts it addresses.
The level of granularity considered in the reference architecture is that of
components, which roughly correspond to coherent sets of functionality delivered as
software products or software components, which can be configured separately. The
component catalogue groups both, abstract descriptions of components (e.g. an UDDI
registry) as well as product or software-based components (e.g. the jUDDI library).

Each description refers to the standards it implements, the concepts it addresses as well
as its behavioral characteristics.
The System of Pattern, as described above, represents the actionable part of the
reference architecture. The specified patterns define various ways of realizing some
functionality by associating components and other patterns in a defined manner. The
architecture specification includes the three presented types of patterns: top-level
patterns, abstract design patterns, and implementation design patterns Relationships
between patterns are explicitly described. Each pattern description also refers to the
standards it implements, the concepts it addresses, as well as its behavioral
characteristics.
To better support the production of a set of inter related patterns, a top-down
production process has been adopted for the pattern-based reference architecture.
Starting from the production of top-level patterns, i.e. the most general and abstract
patterns, other patterns are produced with respect to other already committed patterns.
This way, the problem they address and the context where they are applicable are
clearly and well-defined. Taking the ESOA family (see figure 1) into account, the
Distributed ESB in E-SOA pattern for example can only be specified after the
Enterprise SOA top-level pattern has been created and the use of the ESB component
as well as its relationships to other components are clearly defined and thus can be
refined in a separate pattern. This approach simplifies the verification of the
consistency of the overall set of patterns and makes it more controllable.
The top-level patterns play a particular role in the application of the design
methodology as they define different classes (or families) of SBSs that will be
implemented. The principle of independence from the application domains means that
the pattern-based reference architecture must be useable to instantiate compliant
systems for many different application domains, such as enterprise systems,
manufacturing systems, real-time systems, sensor networks, and automotive
communications. In essence, the properties of SBSs used for each of these applications
is different enough from the others that it constitutes a system type on its own rather
than a variant in a common system family. However, once the system family (or top
level pattern) has been identified, its association with abstract and implementation
design patterns follows a strict structure of dependencies and refinements.
As mentioned above, the pattern-based reference architecture does not distinguish
between the actual architecture description and the reference model but includes both
of it. Thus, the section reference architecture specification in the presented structure
constitutes the part that is traditionally referred to as reference architecture in literature.
The different types of patterns and different levels of abstraction that are covered by
them provide all the information that should be given in a logical as well as a technical
reference architecture. The component and the standards catalogue accompany the
system of patterns to make the patterns directly reusable adhering to the construction
kit concept.
4.2. Application of the Reference Architecture
As identified by Fettke et al. [11] there are two processes that need to be distinguished:
the construction of the reference model and the construction of company-specific
information models based on these reference models. This differentiation can also be
made for the pattern-based reference architecture. On the one hand it is important to
have a sound method as presented in the previous section describing how the reference
architecture is build to allow the evolution of it in the future. The described approach
tries to foster an adaptable and dynamic evolvable reference architecture that can cope
with new trends beyond the NEXOF-RA project to provide a framework for integrating
experiences and research results.
On the other hand, the process of adopting the reference architecture to derive
specific architectures needs to be addressed by providing sufficient guidance. As
described as part of the guidelines, the pattern-based reference architecture will come
with a methodology that support system architects during the derivation of concrete
architecture instances. The combination of all elements defined as part of the pattern-
based reference architecture allows deriving specific instances of a software
architecture for SBSs that adhere to specific requirements. The principles and
guidelines provide guidance for the whole process and especially provide a starting
point by describing how the requirements can be mapped towards the reference
architecture.
Once a system family has been identified for the system under development, a
functional decomposition should be performed based on the requirements that apply to
the specific context and the different model views. These functionalities should be
mapped to the functional decomposition that is provided by the reference architecture
model. Such a functionality mapping is a solid baseline to actually derive the
architecture instance since the various elements that are part of the pattern-based
reference architecture are all interlinked. The pattern descriptions for example, map
functionalities that are provided via interfaces by the specified architectural solution to
the functionalities described in the model. Together with the instantiation guidelines
the reference-architecture can be tailored to the specific context.
Starting from the top-level pattern of the identified system family, for all selected
functionalities, the according abstract patterns can be selected following the path
through the pattern map down to the implementation patterns. The functional
decomposition of the model comprises, for example, functionalities addressing the
issue of discovering services. More specifically it distinguishes between the
functionality to search a service and the functionality to browse for a service. The
ESOA top-level pattern specifies a functionality “find” that is mapped to the discovery
functionality and that is related to the component Registry within the ESOA pattern.
Within the ESOA family a pattern Service Discovery is specified that refines the
Registry component. Thus, the architectural solution provided by this pattern should be
included for an architecture instance that includes the discovery functionality in its
functional decomposition. For different types of discovery different abstract design
patterns refining the Service Discovery pattern are specified, e.g. the Template-based
Discovery and the Multi-Phase Discovery abstract design patterns.
Considering the dependencies between the patterns, the appropriate patterns can
be selected and combined on in order to describe the system architecture for a specific
context. The final result will be a technical architecture that is accompanied by
implementation components provided in the components catalog. The ideal scenario is
that there will be enough implementation components so that the derived architecture
already comes with an interoperable implementation. During the derivation, the
interoperability of specific combinations of the different components should be
guaranteed by interoperability levels specified in the guidelines.
5. Conclusion and Future Work
This paper presented a pattern-based approach towards the definition of a reference

architecture for SBSs. This approach constitutes a reasonable solution that allows the
consideration of the various types of SBSs that have been identified as relevant in the
Future Internet till now. The system of patterns that has been presented allows
addressing the different characteristics and requirements of the different types of SBSs
that should be considered. Furthermore, the approach is dynamically extensible in order
to integrate patterns that provide solutions for problems that have been identified for
new trends and thus promises to become a long living framework for the derivation of
SOAs of any kind. The future work towards this system of patterns will mainly deal
with the definition of pattern families describing the current trends such as the Internet
of Services and the Internet of Things. Furthermore, the definition of instantiation
guidelines is crucial in order to make this reference architecture a useable and thus
valuable framework for the derivation of specific well-defined architectures that will
constitute parts of the Future Internet.
6. Acknowledgements
Research leading to these results has received funding from the EC’s Seventh
Framework Programme FP7/2007-2013 under grant agreement 216446 (NEXOF-RA).
We cordially thank all NEXOF-RA members, Nelufar Ulfat-Bunyadi and Marian Daun
for fruitful discussions and insightful comments that improved this paper.
References
[1] G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, T. Zahariadis, Towards
the Future Internet – A European Research Perspective, Future Internet Assembly May 2009., Prague,
IOS Press, 2009.
[2] NESSI, NESSI Strategic Research Agenda. NESSI Research Priorities for FP, Public Vol. 3.2 Revision
2.0, 10. May 2009.
[3] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, S. Angel, A Pattern Language,
Oxford, University Press, New York, 1977.
[4] E. Gamma, R. Helm, R. Johnson, J. M. Vlissides, Design Patterns: Elements of Reusable Object-
Oriented Software, Addison-Wesley Professional, illustrated edition, 1994.
[5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture,
A System of Patterns, Volume 1. John Wiley & Sons Ltd, 1996.
[6] F. Buschmann, K. Henney, D. C. Schmidt, Pattern-Oriented Software Architecture, On Patterns and
Pattern Languages, Volume 5, John Wiley & Sons Ltd, 2007.
[7] M. Jazayeri, A. Ran, F. van der Linden, Software Architecture for Product Families: Principles and
Practice, Addison-Wesley Longman Publishing Co. Inc., 2000.
[8] G. Beneken, Referenzarchiteckturen, In: R. Reussner, W. Hasselbring (Ed.): Handbuch der
Softwarearchitektur, dpunkt.verlag, Heidelberg, 2006 (in German).
[9] O. Vogel, I. Arnold, A. Chughtai, E. Ihler, U. Mehlig, T.Kehrer, U. Zdun, Software-Architektur,
Grundlagen – Konzepte – Praxis, 2. Auflage, Spektrum Akademischer Verlag, 2009 (in German).
[10]L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, SEI Series in Software Engineering,
Addison-Wesley Longman, 2nd edition, Amsterdam, 2003.
[11] P. Fettke, P. Loos, Methoden zur Wiederverwendung von Referenzmodellen – Übersicht und Taxonomi,
In: J. Becker; R. Knackstedt (Ed.): Referenzmodellierung 2002 - Methoden - Modelle – Erfahrungen,
Pages 9-33, 2002 (in German).
[12]K. Pohl; Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, to appear in
2010.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-161
SOA4All: Towards a Global Service

Delivery Platform
Reto KRUMMENACHERa,1, John DOMINGUE b, Carlos PEDRINACI b and Elena
SIMPERL a
a
Semantic Technology Institute, University of Innsbruck, Austria
b
Knowledge Media Institute, The Open University, Milton Keynes, UK
Abstract. Establishing Web services as resources on the Web opens up productive,

but challenging new possibilities for open, highly dynamic and loosely-coupled
service economies. In addition, lifting services to the semantic level provides a
sophisticated means for automating the main service-related management
processes and the composition of arbitrary functionalities into new services and
businesses. In this article we present the SOA4All approach to a global service
delivery platform. By means of semantic technologies, SOA4All facilitates the
creation of service infrastructures and increases the interoperability between large
numbers of distributed and heterogeneous functionalities on the Web.
Keywords. SOA, Semantic Web services, Global Service Delivery Platform
Introduction
The Web service technology stack offers various means for making software
functionality accessible as remote components, independent of particular programming
languages and platform implementations. Significant work was done in specifying
architectures, middleware, languages, communication protocols and process execution
engines that can support the creation of complex distributed systems by seamlessly
coordinating Web services. Service-Oriented Architectures (SOAs) foster the
development of such distributed and loosely-coupled solutions whereby service
providers advertise the services they offer, and solution providers and software
developers access the service repositories to search for suitable services to invoke for
the given purpose or to build and execute processes.
Within SOA4All, the core ideas of SOA are re-thought with the aim of making
services ubiquitous on the Web. The chosen approach is to combine the principles that
underpin the Web, Web 2.0, semantics, context and SOA and to derive an architecture
based on these principles. In particular, from the Web we take openness,
decentralization, and the fact that communication is driven by a ‘persistent publish and
read’ paradigm rather than by messaging. Semantic Web languages are leveraged to
provide automation and increase understanding of various common tasks during the
life-cycle of services, such as their discovery and composition. From Web2.0 we take
the value of easy-to-use interfaces and of social networks. Finally, automated context
1
Corresponding Author: Activity Leader, University of Innsbruck, Technikerstr. 21A, 6020 Innsbruck,
Austria; E-mail: reto.krummenacher@sti2.at.
162 R. Krummenacher et al. / SOA4All: Towards a Global Service Delivery Platform
adaptation capabilities are embedded within the architecture in order to support the use
of services in unforeseen contexts. In provisioning a Web were services number in the
billions, we argue that the SOA4All architecture provides a Web-minded example of a
global service delivery platform. In particular, by empowering Web services as
resources on the Web, SOA4All yields the fundamental building blocks for the creation
of new business options in the form of open and loosely-coupled service economies.
SOA4All addresses the Web of Services in which millions of users work with
billions of services. In order to manage the resulting wealth of resources – e.g., service
descriptions, user profiles or process models – there is a significant need for
automation. Without automation it would neither be feasible to scale to the dimensions
of the Web, nor to offer a service delivery platform. Automation relies on metadata to
create more abstracted views of real objects. Semantic technologies are thus central to
automation and scalability, and were successfully applied in recent projects on services
to lift their descriptions to a level of abstraction that deals with machine-understandable
conceptualizations. This decreases the dependency upon human users, and at the same
time increases the uptake of service computing, as the complex wealth of interrelated
standards in the area are abstracted at the semantic level.
In this chapter we first present the conceptual architecture of the SOA4All service
delivery platform. Section 2 presents the integration middleware in the form of
federations of distributed service buses. In Section 3, the platform services are
introduced; platform services provide the basic components of a service delivery
platform, such as the discovery and composition services or the reasoning engines.
Section 4 depicts a consolidated example of how the service delivery platform
integrates in order to establish an executable process. To conclude the chapter, we
provide a wrap-up and depict some future directions.
1. SOA4All Conceptual Architecture
A global service delivery platform (GSDP) is an open platform through which domain
independent services can be used to build problem-specific service solutions. SOA4All
establishes an instance of a service delivery platform that targets Web services (WS-*
stack-based services, RESTful services and Web APIs). In this respect, we focus on
those elements of the GDSP that rely on Web2.0 and semantics, and do not respond to
related issues such as service management or non-Web-based services such as mobile
services or sensor networks that need to be integrated in order to fully enable the
‘Everything as a Service’ paradigm.
The SOA4All platform focuses on automating the management of services that are
traditionally driven by technologies such as WSDL and SOAP, and on empowering
RESTful services. Automation is advocated through the application of semantics and
hence by means of Semantic Web services. In other words, services are annotated by
means of Semantic Web languages, and the platform services operate on the semantic
descriptions of services and processes, rather than the actual software implementation
or the physical endpoints. In fact, the services turn into utilities, which disappear in the
Web that becomes the platform and a public, open and distributed alternative to private
legacy systems. The service capabilities and the offered quality of service become the
decisive characteristics, rather than the endpoint location or provider.
In the following, we present the SOA4All conceptual architecture with service bus,
platform services and user-front end (SOA4All Studio) that are depicted in Figure 1.
R. Krummenacher et al. / SOA4All: Towards a Global Service Delivery Platform 163
Figure 1. SOA4All architecture.
1.1. Distributed Servicee Bus
The Distributed Service Bus enables Web-style communication and collabooration via
semantic spaces and serrvice bus technology, and yields the core runtime infrrastructure.
The DSB augments entterprise service bus technology with distributed servicee registries,
the layering of the servvice bus on top of established Internet-enabled middleeware, and
the enhancement of the t communication and coordination protocols by means of
semantic spaces. Spacees are seen to significantly increase the scalability of the bus in
terms of interaction bettween distributed and autonomous services [1]. A moore detailed
description of the DSB and semantic spaces is given in Section 2.
1.2. SOA4All Studio
The SOA4All Studio iss a Web-based user front-end that consists of three coomponents
which offer service provvisioning at design time, consumption and analysis at runtime:
The Provisioning Platform has two main purposes: i) tools to seemantically
annotate services; andd ii) a process editor that allows users to create, share, and
annotate executable proocess models based on a light-weight process modelingg language.
Service annotations arre based on WSMO-Lite [2], a minimal extensioon to SA-
WSDL [3] that empow wers the creation of lightweight semantic service desccriptions in
RDFS. In parallel, MicroWSMO [4] is used to annotate services that are nott described
using WSDL, such as RESTful
R services or Web APIs. MicroWSMO is a microformat-
based language that uses similar constructs from WSMO-Lite, but adapted to support
the annotation of HTM ML-based descriptions, as they are usually available foor this type
of software exposure. Finally,
F SOA4All provides a minimal service modell in RDFS
that yields an overarchiing conceptual model able to capture the semantics forr both Web
services and Web APIs, thus allowing both kinds of services to be treated
homogeneously within SOA4All.
The Consumption Platform is the gateway for service consumers. It allows users
to formalize goals. A goal is a formal specification of an objective and as such yields
an implicit specification of the services that need to be executed. User objectives are
transformed into processes that are compositions of service descriptions and so-called
service templates together with control and data flow information and potentially
further constraints on the services and their execution. Service templates define
process-internal activities instead of concrete services whenever flexibility in service
selection is desired. At runtime, service templates are resolved to specific services that
are selected on the basis of conditions and informed by contextual knowledge which
may include monitoring data, user location or other aspects that affect the
appropriateness of a service endpoint.
The Analysis Platform collects and processes monitoring events from the service
bus, extracts and produces meaningful information out of it and displays the results to
users. Monitoring events come from data collectors that perform basic aggregation
from distributed sources in the service delivery platform. Data collectors are installed at
the level of the bus and the execution engine, and are installed to cover all aspects of
monitoring necessary in the context of SOA4All: monitoring of process executions, of
service end-points that are invoked through the service bus, and finally of the
infrastructure itself. While users can select particular services to be monitored in terms
of quality of service attributes, simpler and less comprehensive data can also be
collected for all other services that are empowered through the bus, but that are not
explicitly monitored upon user request, e.g. the moving average for response time.
1.3. Platform Services
Platform services provide the minimally necessary functionality of a service delivery

platform, such as service discovery, ranking and selection, composition and invocation.
These components are offered as Web services via the service bus and are consumable
in the same manner as any other published business service. Although distinct in their
purpose, they have in common that they operate with semantic descriptions of services,
service templates and processes rather than with the syntactical representation of those,
as it is traditionally the case in service-oriented infrastructures. The SOA4All platform
services, shown at the bottom of Figure 1, are detailed in Section 3.
1.4. Business (Web) Services and Processes
Figure 1 was discussed so far with respect to the central components of the SOA4All
service delivery platform – the ensemble of DSB, SOA4All Studio and platform
services. Jointly, they deliver a fully Web-based service experience: global service
delivery at the level of the bus, Web-style service access via studio, and automated
service processing and management via platform services. Moving to the corners of
Figure 1, we enter the domain of semantic service descriptions and processes: (1)
represents the semantic service descriptions, either in the form of annotated RESTful
services (3) or WSDL endpoints (4); (1) thus represents the so-called Semantic Web
services. The semantic descriptions are used for reasoning with service capabilities
(functionality), interfaces and non-functional properties, as well as contextual data.
In the top right corner of Figure 1, (2) represents processes and mash-ups.
Processes are orderings of Semantic Web services, service templates with associated
constraints, data and control flow. A mash-up is a data-centric model of a composition
that is almost entirely executable by coordinated access to data in a semantic space.
Although being comparably simple, mash-ups provide a promising approach to Web-
style service computing, a pre-requisite for light-weight service economies.
2. A Federation of Distributed Service Buses
Earlier in this chapter we stated that the decisive factor in choosing a service is no
longer the endpoint, but the functionality and quality of service, and that alternative
implementations might complement or replace services in a process. Consequently,
distributed functionalities are leveraged by communities and no longer by dedicated
individuals. In such scenarios, average users become prosumers of services, leading to
thousands of new services and business profiles created almost on-the-fly.
Services shared by a community are being composed in the associated marketplace
that the actors delimit. Partnerships arise as coalitions, translating directly in the need
to interconnect marketplaces into peered and more hierarchically structured federations,
thus yielding a unique, but not flat global service economy. The SOA4All service bus
embodies the marketplace for the offering of services at Internet-scale, and a
middleware that scales to the dimensions of millions of users and billions of services.
Although ESBs deliver the core functionality for service computing, they are
generally restricted to corporate settings, and do not suffice in terms of dynamics,
openness and scalability. In order to dynamically scale, SOA4All enhances ESB
solutions with state-of-the-art technologies in distribution and semantics and
incorporates storage, monitoring, and communication for a virtually global Internet-
scale ecosystem. An important step in establishing federations over distributed buses is
the provisioning of message routing that does not require point-to-point connections
between bus nodes. SOA4All leverages a multi-level, hierarchical organization of bus
nodes [5]. The bus relies on a one level hierarchy, as federations are created between
distributed service buses of different corporations with the first level being the
enterprise level and the second one the inter-enterprise level given by the Internet.
As stated previously, the DSB is further enhanced with semantic spaces that are
motivated by the ‘persistent publish and read’ paradigm of the Web. This allows
SOA4All to provide additional communication patterns – such as publish-subscribe,
event-driven, and semantic matching – that further decouple the communicating
entities in terms of time, processing flow and data schema. Semantic spaces have
gained momentum in the middleware community, as a response to the challenges of
data sharing and service coordination in Web environments. Semantic spaces fuse tuple
space computing from parallel processing; publish-subscribe-style notification services
and semantics to create a distributed data management platform [1]. The spaces provide
operations for publishing RDF data, querying SPARQL end-points, and coordination
via graph pattern-based notification services. Semantic spaces enable the creation of
virtual containers in the form of subspaces or federations. The latter are temporary
views over multiple virtual containers, comparable to read-only views in relational
databases. Subspaces and federations are used to create dedicated interaction channels
that increase scalability by grouping collaborating services and related data.
The semantic spaces exploit established P2P overlays and the same Internet-scale
communication platform as the DSB, which fosters the co-existence of space and bus
nodes (Figure 2), to ensure scalability. Spaces are indexed in a Chord ring [6] and each
node of the ring maintains references to peers of a CAN overlay [7] in which the triples
of the spaces are indexed and distributed. A 3-dimensional CAN overlay yields a
natural solution to the storing of RDF triples; the axes represent the subjects, predicates
and objects of RDF statements and values are ordered lexographically.
Figure 2. Federation of DSB and semantic spaces.
3. Delivering Services: The Platform Services
In the previous section we have presented the runtime infrastructure, and turn now to
the platform services. Platform services are conceptually well-known SOA components
and their existence is not novel, but distinct in terms of provisioning and leveraging the
light-weight semantic service descriptions. Jointly, they provide the first instance of a
GSDP, which is an innovation of SOA4All. A first category of platform services –
service location – provides users with the functionality to find and rank services
according to their needs and context.
Crawler: The crawler service is fundamental for service discovery [8]. It collects
technical descriptions associated with services from the Web and manages this data for
enabling efficient and intelligent retrieval of service-related artifacts. The collected data
includes files such as Web site, documentation, pricing and licensing information, and
can be delivered either as RDF metadata, or as a consolidated non-RDF archive file.
Service Repository: The service repository – iServe – is used to store and maintain
semantic service descriptions, and provides processing capabilities for SA-WSDL and
MicroWSMO annotations. The repository offers a RESTful API for users to browse,
query and upload semantic annotations and have them automatically exposed as
RDF [9]. Through iServe, service annotations become part of the Linked Data cloud
(www.linkeddata.org). The alignment with the Linked Data initiative increases public
awareness and brings the annotations into context.
Discovery: Service discovery matches user needs to service descriptions. SOA4All
uses service templates that abstractly describe a user’s objective as a set of RDF triples.
Service templates (Table 1) can be mapped into SPARQL to be resolved by iServe: the
hasFunctionalCategory property shadows the functional classification reference that
types services according to WSMO-Lite; the input and output properties are used to
specify the input and the expected output of a service; requirements and preferences
link further constraints. These values match roughly the pre-conditions and effects in
WSMO-Lite and are generally more complex than RDF only; e.g., WSML [10].
The discovery service currently offers two types of search: i) full text-based
discovery that mostly exploits keyword matching over service descriptions and related
documents from the crawler; ii) semantic discovery that leverages service templates. In
the simplest case, discovery is reduced to the resolution of the derived SPARQL query.
For more sophisticated searches, for example when using requirements and
preferences, the discovery service makes use of reasoning over semantic descriptions.
Table 1. RDF Schema for service templates
ServiceTemplate rdf:type rdfs:Class .

hasFunctionalCategory rdf:type rdf:Property .
hasInput rdf:type rdf:Property .
hasOutput rdf:type rdf:Property .
hasPreference rdf:type rdf:Property .
hasRequirement rdf:type rdf:Property .
Ranking and Selection: This service provides the means to rank services
according to user preferences and non-functional properties [11]. A first method uses
logical rule reasoning to compute ranking scores for services based on aggregated non-
functional values and their matching degree to user requirements. A second approach is
a fuzzy logic-based mechanism that considers a model of preferences that includes
vagueness information.
The second category of platform services provides the means to construct and
execute the service compositions. SOA4All focuses on empowering non-technical
users to construct services, and bases its work on languages that foster re-usability and
flexibility in design. The language used is called Lightweight Process Modeling
Language (LPML [12]) – the term lightweight explicitly refers to the usability of the
language. LPML is a combination of process modeling concepts found in BPEL, and
SOA4All-specific extensions. LPML simplifies BPEL by only considering relevant
subsets and extends the existing languages with means to interleave service templates.
Furthermore, LPML defines how semantic annotations can be attached to process
elements such as activities, goals, input and output parameters, and introduces the
concept of data connectors that specify the data flow in service compositions; again
emphasizing the specialization of our platform services towards light-weight semantics.
Design-Time Composer: The design-time composer provides semi-automatic
assistance in resolving unbound activities within a process specification. As such, the
service supports the studio’s process editor. In other words, the design-time composer
assists the entire life-cycle of service composition, from supporting the process
specification through elaboration of process and template expansions to the discovery
and binding of service endpoints. This includes data mediation at the level of service
inputs and outputs via service connectors and semantic link operators.
Composition Optimizer: The input to the composition optimizer is a complete
service composition for which an optimized and executable process is sought [13].
Although the composer helps to bind service endpoints, there remain aspects in a
process that cannot be treated at design-time. A task of the composition optimizer is to
bind remaining service templates to relevant services. The composition optimizer uses
the reasoner when necessary, and considers an extensible quality criteria model by
coupling non-functional properties and the semantic descriptions of the process.
Execution Engine: The execution engine offers operations to deploy executable

processes in an execution environment and to expose processes as invocable Web
services. Furthermore, the execution service provides tools to transform light-weight
process descriptions into standardized process modeling notations, e.g. BPEL. In
SOA4All, the execution engine includes a set of basic mechanisms for adaptive run-
time reconfiguration of execution plans in order to react to changes in the execution
environment.
To conclude this section we present an additional platform service that offers
reasoning support for most of the previously named platform services.
Reasoner: The reasoning service exposes a framework of robust and scalable
reasoning components that are tailored for each of the WSML language variants [10].
A variety of interfaces allow for schema/instance reasoning, satisfiability/entailment
checking and query answering. The reasoning service has configurable links to service
repositories to load service descriptions, and to semantic spaces to access domain
ontologies that are required as input to the desired reasoning tasks.
4. Service Delivery Example
Service delivery in the context of SOA4All focuses on the two areas of service
location and service construction; although the latter at least partly subsumes the
former in order to bind service endpoints to service templates. In this section we
exemplify how the different platform services coordinate in order to jointly realize the
global service delivery platform.
As a starting point for our example, we assume that there are semantic service
descriptions provided and stored in iServe. The service descriptions were likely created
via provisioning tools such as SWEET or SOWER of the SOA4All Studio [14], which
are used for annotating Web APIs or WSDL files respectively. In order to find the
service endpoints and the corresponding documentation, a SOA4All user can profit
from the crawler that provides background knowledge to formalize service annotations.
In principle, it would also be possible that the crawler detects not only service
endpoints, but semantic descriptions, which then, without manual intervention, can be
stored in the repository. Our assumed starting point thus covers most of the actions for
which the provisioning platform is developed: service endpoint selection, semantic
description creation, annotation management and storage in the service repository.
In terms of functional processes that are enabled by SOA4All, the actions triggered
through the consumption platform are much more informative. A core component of
the consumption platform is the aforementioned process editor that provides a
graphical user interface for the modeling of processes. Service compositions are
expressed in terms of LPML, which is understood and further manipulated by all
service construction-related platform services. An example process with two activities
– and without data flow for clarity – is shown in Table 2; note that the example shows
the LPML model after the invocation of the design-time composer, and hence a
potential Web service is already bound to each of the two activities. The first goal of
the process is to determine the latitude and longitude of a city in order to retrieve
information on the wind speed from the nearest weather station in a second step. Both
services are offered by ws.geonames.org. Data mediation is not necessary in this case
since the output of the first activity maps directly onto the input of the second one.
Table 2. LPML process description in XML
<org.soa4all.lpml.impl.ProcessImpl>
…
<activity class="org.soa4all.lpml.impl.ActivityImpl">
<operation>getGeoLocationByName</operation>
<conversation class="org.soa4all.lpml.impl.ConversationImpl">
<goal class="org.soa4all.lpml.impl.GoalImpl">
<semanticAnnotations> <org.soa4all.lpml.impl.SemanticAnnotationImpl>
<referenceURI>http://www.example.org/geolocation#location</referenceURI>
<type>FUNCTIONAL_CLASSIFICATION</type>
</org.soa4all.lpml.impl.SemanticAnnotationImpl> <semanticAnnotations>
</goal>
<services>
<serviceReference>http://ws.geonames.org/search</serviceReference>
</services>
</conversation>
<inputParameters>
<org.soa4all.lpml.impl.ParameterImpl>
<referenceURI>http://www.example.org/geo#locationString</referenceURI>
<type>META_DATA</type>
</org.soa4all.lpml.impl.SemanticAnnotationImpl> </semanticAnnotations>
</org.soa4all.lpml.impl.ParameterImpl>
</inputParameters>
<outputParameters>
<referenceURI>http://www.w3.org/2003/01/geo/wgs84_pos#long</referenceURI>
<type>META_DATA</type>
</org.soa4all.lpml.impl.SemanticAnnotationImpl> </semanticAnnotations>
<referenceURI>http://www.w3.org/2003/01/geo/wgs84_pos#lat</referenceURI>
…
</outputParameters>
</activity>
<activity class="org.soa4all.lpml.impl.ActivityImpl">
<operation>getWindSpeed</operation>
<conversation class="org.soa4all.lpml.impl.ConversationImpl">
<goal class="org.soa4all.lpml.impl.GoalImpl">
<referenceURI>http://www.example.org/weather#WindSpeed</referenceURI>
…
</goal>
<services>
<serviceReference>http://ws.geonames.org/findNearByWeatherXML</serviceReference>
</services>
</conversation>
<inputParameters> … </inputParameters>
<outputParameters>
<referenceURI>http://www.geonames.org/ontology#windSpeed</referenceURI>
…
</outputParameters>
</destination>
...
The first platform service involved in our example is the design-time composer. It
is iteratively invoked during the process specification to assist in binding services,
expanding templates, checking I/O compatibilities and creating data flow via
connectors. Although matching user requirements and process-specific constraints, the
outcome of this interactive editing task does not necessarily yield an optimized model.
In fact, the design-time composer works mainly on local solutions only and does not
deal with the global optimization of a process specification. Therefore it is necessary to
work with the completed compositions for performance optimization, context
adaptation or for honoring specific user preferences. The composition optimizer
accepts complete process models for which it seeks a better global cost function in
terms of functional (including semantic similarity of inputs and outputs) and non-
functional properties such as Quality of Service (QoS). The optimizer uses Genetic
Algorithms to transform compositions into their optimal versions by replacing service
bindings and modifying the data flow without changing the control flow. The
transformations are influenced by the context in which a service composition is to be
used, and require reasoning support and service discovery for finding concrete and
optimized service bindings.
Once a complete model satisfies a user’s preferences and requirements in terms of
functionality and performance, the process is deployed in the execution engine and
exposed as a Web service. As described in Section 3, the execution engine transforms
the complete LPML model into a BPEL model enhanced with some SOA4All-specific
extensions. Additionally, a corresponding WSDL endpoint is specified, and the
execution engine offers one more public service for any deployed process, in addition
to the default ‘deployProcess’ service that the engine hosts.
As the first part of our example has shown, discovery is an essential sub-task of the
service construction process. The definition of activity, and in particular the goal
element within the LPML process specification, can be mapped onto the properties of
the service templates (Table 1), which are at the basis of semantic discovery. The
annotations of type functional classification that are used to annotate a goal element are
transferred to values of the hasFunctionalCategory property. The operations, given
through inputOperation and outputOperation in LPML are converted to hasInput and
hasOutput. Finally, there are other semantic annotations that can be attached to
activities, which are of type requirement and non-functional property. These map to
hasRequirement and hasPreference accordingly. Table 3 shows a concrete service
template that was directly derived from mapping the LPML goal element in Table 2
onto the RDF schema for service templates given in Table 1. The ‘st’ prefix stands for
the service template namespace pointing to http://cms-wg.sti2.org/ns/service-template#.
Table 3. Concrete service template for the wind speed service
windSpeedService rdf:type st:ServiceTemplate ;

st:hasFunctionalCategory <http://www.example.org/weather#WindSpeed> ;
st:hasInput rdf:type <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ;
st:hasInput rdf:type <http://www.w3.org/2003/01/geo/wgs84_pos#long> .
SPARQL queries can be derived from the service templates that can be executed
against the semantic service descriptions in iServe. A possible SPARQL query for the
template in Table 3 is depicted in Table 4. Note that the classes and predicates are no
longer taken from the service template schema but from the minimal service model
(prefixed with msm) which borrows some elements from SA-WSDL, identified with
the prefix sawsdl. The query selects services that match exactly the functional category
that is searched, and that offer operations with the given input types. Had our service
template contained hasOutput specifications, those would have appeared in the query in
a similar way to the input types. More sophisticated query specifications that are
investigated in the context of service location consider, in addition to the exact match
achieved with the example in Table 4, plug-in, subsumes, and fail match degrees
common in the literature. One approach to do this is to use subclass relations in the
SPARQL query, i.e. the service classification does not reference wind speed directly,
but rather any subclass of the concept. Executing the SPARQL query against the
repository results in a collection of service endpoints that match the functional
classification and the input and output parameters.
Table 4. SPARQL query to be executed against the service repository
SELECT ?service ?operation ?endpoint

WHERE {
?service rdf:type msm:Service ;
rdfs:isDefinedBy ?endpoint ;
msm:hasOperation ?operation ;
sawsdl:modelReference <http://www.example.org/weather#WindSpeed> .
?operation msm:hasInputMessage ?input ;
msm:hasOutputMessage ?output .
?input sawsdl:modelReference <http://www.w3.org/2003/01/geo/wgs84_pos#long> ;
sawsdl:modelReference <http://www.w3.org/2003/01/geo/wgs84_pos#lat> .
This passage from a goal specification to a set of possible service endpoints is

followed for all goal elements in the LPML model. At the level of the design-time
composer, any of the discovered endpoints might be selectable, as they fulfill the basic
requirements: typing, as well as input and output parameters. In order to optimize a
process, it is however necessary to choose the service that best fits a user’s objectives
and expectations, and ranking becomes important. The ranking and selection service is
invoked with the set of possible service endpoints as input, and the best match will be
selected for invocation.
5. Conclusion
Embracing service-oriented architectures in the context of the Web raises new

challenges: increased size and load in terms of users and services, distribution, and
dynamism. The SOA4All project addresses these issues in order to bring (up until now)
business-minded service technologies to the masses. SOA4All paves the way for a Web
of billions of services, overcoming many of the drawbacks of current Semantic Web
service technology by leveraging existing Web and Web 2.0 principles and lightweight
semantic annotations for services and processes in a global service delivery platform.
In this chapter we have presented the concepts and architecture of SOA4All’s
service delivery platform that is grounded in a federated distributed service bus
infrastructure and a set of platform services that deliver the minimal functionality
needed to locate and construct services. The platform is central to the achievement of
the project’s main objective: offering billions of services to millions of users in novel,
Web-scale service economies. In this context it becomes evident that automation is
required, otherwise the wealth of service and process descriptions, the users and their
context, and the monitoring data that is gathered during the life-time of services cannot
be managed. Considering that there is no automation on the Web without semantics,
not least due to the heterogeneity and dynamics of resources, SOA4All invests in novel
techniques, languages and components for annotating services, and for creating, finding
and manipulating services and processes at the semantic level.
Further work is aimed at the realization of comprehensive functional processes for
the global service delivery platform. Other work is concerned with the concretization of
more tight bounds between SOA4All and established Web technologies. Finally,
significant work is required to bring SOA4All results to the market and to leverage the
technologies in large scale and open service economies.
Acknowledgment
The work presented is funded by the SOA4All project (www.soa4all.eu) under

European Union grant FP7-215219. The authors thank the team working on service
location from Karlsruhe Institute of Technology, Seekda and the University of
Innsbruck; the team on service construction from Atos Origin, TXT e-Solutions,
CEFRIEL, University of Manchester, and SAP; and the colleagues from INRIA, EBM
WebSourcing and the University of Innsbruck that are developing the service bus.
References
[1] L. Nixon, E. Simperl, R. Krummenacher and F. Martin-Recuerda, Tuplespace-based computing for the
Semantic Web: A survey of the state of the art, Knowledge Engineering Review 23 (2008), 181-212.
[2] T. Vitvar, J. Kopecky, J. Viskova, and D. Fensel, WSMO-Lite Annotations for Web services, 5th
European Semantic Web Conference, June 2008: 674-689.
[3] J. Farrell and H. Lausen, Semantic Annotations for WSDL and XML Schema (SAWSDL), W3C
Recommendation, August 2007.
[4] M. Maleshkova, J. Kopecky and C. Pedrinaci, Adapting SAWSDL for Semantic Annotations of
RESTful Services, Beyond SAWSDL Workshop at OnTheMove Federated Conferences & Workshops,
November 2009: 917-926.
[5] F. Baude, I. Filali, F. Huet, V. Legrand, E. Mathias, Ph. Merle, C. Ruz, R. Krummenacher, E. Simperl,
Ch. Hammerling and J.-P. Lorre, ESB Federation for Large-Scale SOA, 25th Symposium On Applied
Computing, June 2010.
[6] I. Stoica, R. Morris D. Karger M.F. Kaashoek and Hari Balakrishnan, Chord: A Scalable Peer-to-peer
Lookup Service for Internet Applications, ACM SIGCOMM, August 2001: 149-160.
[7] S. Ratnasamy, P. Francis, M. Handley, R. Karp and S. Schenker, A Scalable Content-Addressable
Network, ACM SIGCOMM, August 2001: 161-172.
[8] N. Steinmetz, H. Lausen and M. Brunner, 7th Web Service Search on Large Scale, International
Conference on Service Oriented Computing, November 2009: 437-444.
[9] C. Pedrinaci, J. Domingue and R. Krummenacher, Services and the Web of Data: An Unexploited
Symbiosis, AAAI Spring Symposia, March 2010.
[10] J. de Bruijn and H. Lausen and A. Polleres and D. Fensel, The Web Service Modeling Language
WSML: An Overview, 3rd European Semantic Web Conference, June 2006: 590-604.
[11] I. Toma, D. Roman, D. Fensel, B. Sapkota and J.M. Gomez, A Multicriteria Service Ranking Approach
Based on Non-Functional Properties Rules Evaluation, 5th International Conference on Service-
Oriented Computing, November 2007: 435–441.
[12] F. Schnabel, L. Xu, Y. Gorronogoitia, M. Radzimski, F. Lecue, G. Ripa, S. Abels, S. Blood, M.
Junghans, A. Mos and N. Mehandjiev, Advanced Specification Of Lightweight, Context-aware Process
Modelling Language, SOA4All Project Deliverable, September 2009.
[13] F. Lécué, Optimizing QoS-Aware Semantic Web Service Composition, International Semantic Web
Conference, October 2009: 375-391.
[14] M. Maleshkova, C. Pedrinaci and J. Domingue, Supporting the Creation of Semantic RESTful Service
Descriptions, Workshop on Service Matchmaking and Resource Retrieval in the Semantic Web at 8th
International Semantic Web Conference, October 2009.
IOS Press, 2010
Real time energy management in smart

cities by Future Internet
Mikhail SIMONOVa,b,1, Marco MUSSETTAb,c, Andrea PIRISIb , Francesco
GRIMACCIAb, Davide CAPUTOb and Riccardo E. ZICHb
a
ISMB, Via P.C. Boggio 61, 10138 Torino, Italy
b
Politecnico di Milano, Dipartimento di Energia, Via La Masa 34, 20156 Milano, Italy
c
Politecnico di Torino, DELEN, Corso Duca degli Abruzzi 24, 10129, Torino, Italy
simonov@ismb.it, {mikhail.simonov , marco.mussetta, andrea.pirisi,
francesco.grimaccia, davide.caputo, riccardo.zich}@polimi.it
Abstract. Human behavior, both individually and socially, is aimed at maximizing

some objective functions, and this is directly reflected in energy dynamics. New
issues are emerging now, such as the unpredictability of some renewable sources
generation and the new technologies enabling real time energy optimized use in
smart cities. Here the role of the Future Internet in the smart grids is addressed, in
particular enlightening how the anticipatory knowledge of the future occurrences
of the energy consumption dynamics may be effectively promptly exchanged
between competing actors.
Keywords. Future Internet, cooperative environments, smart cities, smart grids,

real time energy management
1. Introduction
Nowadays more than 50% of the overall population of the world lives in urban
contexts, contexts that are involved in a “natural” evolution process towards “smart”
cities. The growing of this percentage makes smart urban environments dense and
complex spaces, in which the energy distribution component, known as smart power
grid, day after day presents a growing need of a new distributed intelligence in order to
effectively manage all the incoming issues. Furthermore, the reduction of the carbon
footprint of the cities is a pressing issue, necessitating a sophisticated control and
management of the energy use on both the supply and demand sides over all aspects of
city life. Much of the current studies on smart cities focus on this aspect. Future
Internet [1] in a smart urban environment appears to us as the most effective tool that
can enable the infrastructure to manage, control, optimize, and improve these aspects at
both the micro- and the macro- level. For example, the detection of some repetitive
events happening locally in real life, might impact on more cooperating or competing
entities, suggesting the accounting and propagation of such events because of the
expected consequences maturing elsewhere. This work is exactly focused on how to
model, measure, monitor, optimize and control complex interdependent event flows
happening in power grids, representing a significant infrastructure characterizing smart
1
2
cities. The use of Future Internet (FI), providing the means for a multiplicity of services,
enabling the management of many different aspects of urban life, will be proposed and
discussed in detail.
Human beings, especially in smart cities, rely on external sources of energy in
order to achieve their personal and social goals. They consume every day a
combination of different kinds of energy for above-mentioned dynamic processes,
taking the real-time electric energy from the smart power grids. Nowadays, the energy
in power grids is monitored using smart metering devices, but the load forecasting and
control systems are separate fieldbus/SCADA entities, considering the under-frequency
and shapes, but ignoring at all the human behavior influence on them because of the
complexity [2]. Becoming smart requires a proactive awareness and semantic
knowledge about the processes happening in real life. Modern electric energy networks
have a distributed grid structure [3] with static nodes. Smart grids were originally
designed following the top down approach, but they have been gradually adapted to
accept bi-directional energy flows coming from the distributed energy generation, such
as photovoltaic (PV hereafter) one. Since the PV production is weather-dependant,
because of the solar activity, the season and the clouds, it is intrinsically characterized
by production drops. In particular the cloud migration is a continuous natural process,
which replicates the drops manifesting in one point of the topology at other nodes after
't time elapsed. The monitoring of the PV drop due to the clouds shows a great
industrial interest. The local negative PV production dynamics anticipate the future
energy production drops at other locations, permitting to set up in advance some
control actions which enable the optimization and management of the blackout
conditions, as shown in Fig. 1.
Figure 1 – Cooperating photovoltaic plants
Future Internet plays a new role: it interlinks completely independent fieldbus

systems in one system-of-system topology, enabling new business scenarios impossible
in the near past. The broadband communication supports the automated transactions at
static nodes in real time, publish-subscribe assures the prompt actuation, while mobile
and wireless loops extend the mobility. However the “intermittent” entities – not
managed by current paradigms - go off-line frequently and stay in the gap between the
Internet of Services (IoS hereafter) and Internet of Things (IoT hereafter). Future
Internet can solve the extended cooperation business challenge, linking smart city
entities in a way, permitting the optimization of the individual (profit) and collective
(low carbon footprint) goals and generating concrete social benefits. Real time
knowledge about causes of events becomes an IoT entity, capable to predict, rule and
optimize the behavior of the whole network. It can be shared and made available,
3
bringing the anticipatory knowledge about the relevant events which are going to
happen at other sites. Hereunder we exploit this potential of Future Internet by one
concrete photovoltaic distributed generation application class, showcasing how to
network autonomous stakeholders in optimizing multi-agent cooperative system.
2. Anticipatory knowledge for extended cooperation
Currently the energy production is highly distributed with a significant contribute

from small PV and wind plants which complement the energy needs of smart cities.
Independent business actors run the above power stations injecting the produced energy
into the grids. Their local fieldbus systems are not necessarily integrated in TCP-IP
networks. Individually they try to maximize profits taking autonomously the energy
trading commercial decisions. The decision making is based on the local information
about the energy production dynamics, without any cooperation with the competing
neighborhood. The renewable PV and wind energy is in some extent unpredictable
because it depends on weather conditions which limit the maximum percentage of
available renewable energy. The weather forecast can be provided to the individuals by
different sources, including locally installed sensors and weather stations, but
nowadays this information is not exchanged among the different energy production
plants, which not necessarily have awareness about each other. The negative energy
production dynamics satisfy the cause-effect relationship while the mobility of the
clouds is a process that evolves and propagates continuously over the space. The lack
of the anticipatory knowledge about the forthcoming production drops is a drawback of
the independent distributed generation. Here we propose the knowledge sharing
between PV power plants. The knowledge in advance of the expected production drop
enables to set up a better load management strategy, offering an additional 't time for
the real time decision making. The transformation of the topology composed by
autonomous PV generation entities in an inter-linked multi-agent cooperative topology
able to process the anticipatory knowledge, eliminates the above-explained drawback
and offers an improved energy efficiency. Let us observe a number of photovoltaic
plants ubiquitously available in a smart city, which are interconnected – thanks to FI -
and share the digitized energy events. The first plant that discovers negative energy
production dynamics (“energy fall” event) now propagates this knowledge to
neighborhood, advising about the cloud movement (Fig. 2).
Figure 2 – An example of the use of anticipatory knowledge propagation over a FI infrastructure for
forecasting PV production drops due to bad weather conditions in interconnected smart power grids.
4
The cooperating neighbors calculate their respective 'ti times and estimate the
events which are going to happen in a near future. The elaborated forecast, based on the
anticipatory knowledge, can be used now to perform an anticipatory control, enhancing
the efficiency of the cooperative load management strategies and optimizing the future
energy injection/trading flows (Fig. 3).
In the liberalized energy markets, the price changes in real time and the users –
energy consumers or renewable sources producers – should trade energy automatically,
using advanced data management algorithms. This approach will give the possibility of
choosing from different energy partners in real time, but it will require the exact
information about the own - both current and expected - energy dynamics scheme. The
precision and the accuracy of the estimation should be sufficient to cover time slots,
corresponding to the expected commercial transactions, hourly or daily. This requires a
real time data analysis plus the correlation of the available (historical) data with the real
time conditions. In a PV distributed generation context, the wrongly estimated cloud
variability might result in economic losses and energy imbalance, a factor to account
before contracting any power selling. We propose a reference application class which
comprises local weather sensors, the forecast, and (multi-agent) intelligent algorithms,
contributing in the short-term trading decision. The knowledge of the exact position
and displacement of the clouds is relevant to the neighbors, because it permits to
forecast their sites’ future load conditions; thanks to the FI, this knowledge can now be
shared, enabling the collective optimization of the expected energy resources.
Power [kW]
3 SM 4200S (2)
1 Sunny day with rainstorm PV

(PV plant 1, single day view) plant 2
0
Day 148.3 148.4 148.5 148.6 148.7 148.8 148.5 148.6
anticipatory knowledge DEi - PV drop to happen at plant 2
Figure 3 – Anticipatory knowledge about photovoltaic energy production dynamics
In addition, the above-said decisions – as a new entity - might be also shared for a-
posteriori assessment, introducing further self-learning and self-correction capabilities
in the distributed cognitive system. The complexity of this example highly increases;
however it exemplifies the use of the anticipatory knowledge in smart power grids.
3. New challenges
In a new forthcoming business scenario the local automated networks over fieldbus
will be integrated as entities of the FI system-of-system, contributing in the creation of
the new cognitive distributed smart power grid. In order to improve the predictability it
is necessary to overcome the local unmanageability of the aggregated entities,
proposing them some extended cooperation advantages. An issue is the integration of
the billions of fieldbus subsystems (transformers LV/MV/HV separate physically PLC
lines), and the WWW Legacy, challenging the adoption of intermediate servers and
5
ubiquitous computing. Drawbacks of this approach are that the fieldbus protocols to
integrate are different, in any case they bring some vulnerability, and the data flows are
intense. The main research question now is how FI will help to ensure the real time
proactive manageability of smart cities. Among the additional research questions we
see: 1) how to calculate the expected timing/duration of the phenomena manifesting at
a given node; 2) how to estimate precisely the entity of the expected transaction; 3)
how to optimize the future flows and so on. The support comes from the semantic
awareness about the dynamics of complex evolving systems.
We anticipate a possible architecture and define some tools for enabling an open
electricity market managed in real time through IoT and IoS components, bridging
between fieldbus components and IP network and allowing new roles for stakeholders.
In our vision smart metering devices perform the real time energy digitization and the
relevant events filtering, broadcasting them for the further elaboration done by
intelligent servers with cognitive capabilities. The energy consumption dynamics are
correlated with the formalized knowledge in Ontology about the firm relationships
impacting on the energy dynamics. For example the Fuzzy rule “IF cloud THEN
photovoltaic drop” permits to trigger the anticipatory knowledge and proactive reaction
in a distributed context. The collective decision making in an inter-linked smart grid
becomes a self-managed entity, offering a higher efficiency and safety. The capability
to support real time transactions with digitized energy between prosumers on the open
liberalized energy markets appears pre-competitive today, but it changes the way of
operating power grids, because B2B automated operations by service delivery platform
become new e-services and replace Legacy.
The FI will bring the openness to different business models already existing on the
market and will support in particular new models, ensuring new roles for digital energy
brokers, such as energy advisors, user needs consultants and other advanced functions.
Service platform, being enriched by knowledge technologies, contribute in semantic
understanding of the events; this enables self-configurability and adaptation to the
changing requirements of the evolving markets, nowadays still in their definition phase.
Moreover, the FI services create borderless B2B marketplace of the global energy
services, enabling to operate from different geo-political realities, eliminating the
national diversities and making other technical aspects transparent for the final users.
4. Future Internet for smartness
Modern smart cities, and smart power grids as integral part of them, can be seen as
a common distributed information space, where people interoperate using the artifacts
with communication capabilities. This topology from the ICT viewpoint has a structure
shown on Fig. 4, where arrows show the information and knowledge exchange.
6
Since smart city with an embedded power grid is a distributed environment, it can
be assumed as a system-of-system topology in which a continuous information and
knowledge flows exist.
The main backbones of this topology are served by TCP-IP connectivity, where the
power line supports the data communication over the local topologies such as
households and industries, by linking the fieldbus of the devices belonging to the same
voltage segments. This solution requires an additional technical solution to overcome
the limitation imposed by the physical peculiarity of the voltage transformers, by
physically separating High Voltage (HV), Medium Voltage (MV), and the Low
Voltage (LV) segments that should be considered as linked layers, integrated in the
global Web. The collection of the automated metering devices [4] belonging to a given
power grid becomes the set of the static nodes – IoT entities – and it defines the
topology of the distributed environment.
Take into account that the Web of communicating electric devices it is not only an
abstract distributed environment, but it is an important candidate for e-business in a
liberalized electricity market, that it is made possible by information about the real
asset (energy), such as digital information representing the real energy in the virtual
Internet of Things world [5]. Since the storage-less smart power grids have static nodes,
a suitable commercial policy aims to make the energy trend of the nodes as much
predictable as possible. In this sense, the cooperation between multi-agent PV systems
and electric vehicle will play a crucial role electric in future smart cities, since electric
vehicles can be used as local storage units [6] for PV energy production. For those
reasons, a predictable oncoming scenario is expected to rely on dynamic FI nodes,
which aspects are discussed in [7].
The experience about the management of users energy demand will trigger the
decision-making tools that operate in smart power grids, and it will also make available
the possibility to realize the best clustering of the virtual communities [8].
5. Distributed and cooperating photovoltaic grid
Energy management by means of FI requires high computational capability in order to

realize a real-time optimization of energy production, distribution, storage and
consumption in smart cities, villages and also rural areas [9, 10]. In fact, it is possible
to conceive an energy hub as a micro-grid where electrical loads and small generation
systems (such as renewable energies in the range of 25-100kW) are integrated into a
Low Voltage (LV) distribution network with micro-storing systems (composed e.g.. by
the integration of electric vehicle into the grid infrastructure). By this point of view, an
energy hub appears as a micro-marketplace since it should be composed by generation
units, storing devices and a small number of consumers and it can operate
interconnected to the main distribution grid or in autonomous way in case of external
fault. By integrating FI into the architecture of energy hubs, it is possible to have
instant access to load forecasting, demand side management, economic scheduling of
micro-generators and to trade energy and information with local providers [11].
FI network is a framework where energy is produced, distributed, stored and used
by systems that are deeply connected each other. New high-voltage and low-losses
underground lines can be designed with 'smart' feature nodes that will provide
consumers with sophisticated information and easy-to-use tools in order to increase the
efficiency of the network with a sensible reduction of costs. In such a smart system,
7
customers will be equipped with smart measuring instruments that report their real-
time power consumption to the authority that will be able to optimize the energy
production in order to reduce the number and the size of energy demand peaks. The
distributed information management techniques contribute in the above domain since
the nodes of the power grid are ubiquitously distributed and integrated by FI. Further
details on this topic can be found in [12].
Load forecasting has always been crucial for the effectiveness of the electrical
system. Power load forecasting is a area of interest for many companies that rely upon
traditional prediction methods [13]. However, since the relationship between power
demand and load parameters is nonlinear, it is difficult to model the behavior of the net
by using traditional prediction methods.
Since the complexity of this scenario requires the capability to predict the
dynamics of the system and to offer an optimal management it has been proposed the
application of an Artificial Neural Network (ANN) integrated to an optimization
algorithm in order to create a predictive model of the physical system and to provide an
efficient control of resources and information [8]. To implement this approach,
evolutionary optimization procedures adaptively and dynamically analyzing consumer
profiles have been defined. Through FI smart cities provide a complex amount of data
with a relevant number of profiles, which can be effectively managed in real-time by
evolutionary neuro-fuzzy tools.
In recent years, renewable energy sources have increased the complexity of this
scenario: solar power is getting more and more important as an alternative and
renewable energy source, especially for small autonomous electrical power systems,
villages and also rural areas. PV plants can also be connected to the traditional grid for
energy distribution, but variations in solar power can cause, in general, voltage and
frequency fluctuations.
Advanced forecasting through evolutionary computation techniques provide
utilities with reliable production predictions and the opportunity to plan for additional
power supply and to make proactive actions. This aspect can have an impact on the
economic balance of the systems especially in an integrated smart grid solution
perspective. These tools provide the ability to use stored energy or electric vehicle load
to firms and renewable productions, increasing their intrinsic value. On the other hand,
in this way the system-plant management is capable to plan appropriate preventive
maintenance strategies in order to minimize energy losses due to unproductive
suspensions. It can be estimated savings up to 0.5 M$/MW per year adopting these
predictive algorithms in the renewable energy sector and at least the 10% of these are
due to an optimized operating efficiency [14, 15].
It is possible to increase the solar power penetration if suitable measures are taken
concerning solar radiation forecasting. This procedure may also affect the energy
efficiency of the conventional power stations, since it affects the operating point of
power units. Solar power forecast is therefore important for the efficiency of load
management in the system and it can rely on the use of ANNs, as suggested in
literature [16].
Artificial Neural Networks (ANNs) are particularly appealing because of their
ability to model an unspecified nonlinear relationship between load and weather
variables. In fact, the complex nature of many engineering problems may involve Soft
Computing techniques in order to solve optimization tasks. In particular an ANN is an
adaptive system that changes its structure based on external or internal information that
flows through the network during the learning phase. Among many ANN
8
implementations, the multilayered perceptron (MLP) is a well-known universal

approximate and has been extensively used in engineering. It consists of an input layer,
one or more hidden layer, and an output layer. In a MLP, the function f(x) is defined as
a recursive composition of other functions gi(x), thus leading to the network structure
depicted in Fig. 5, where the dependencies between variables are represented by the
connections among neurons. The input composition in each neuron is made by a
nonlinear weighted sum,
§ ·
f x k ¨ ¦ wi g i x ¸¸ (1)
¨
© i ¹
where k(x) is a nonlinear activation function which models the activity of biological
neurons in the brain. This function is modeled in several ways; the most common is the
hyperbolic tangent, which ranges from -1 to 1:
k(x) = tanh(x) (2)
Figure 5 – Simplified view of the implemented feed-forward ANN with details on input, output, and
hidden layers.
One of the most critical phase in managing an ANN is the training one, when the
best weights of the neural connections have to be defined. There are three major
learning paradigms, each corresponding to a particular abstract learning task:
supervised learning, unsupervised learning and reinforcement learning.
Supervised learning is commonly used for tasks like pattern recognition,
classification, regression and approximation. The supervised learning paradigm can be
also applied to speech recognition. Its implementation includes a function that provides
continuous feedback on the quality of solutions obtained thus far.
In supervised learning, we are given a number N of set of example pairs (xi, yi),
where xi X, yi Y, and the aim is to find a function f : X o Y that matches the
examples. In other words, ANN wish to infer the mapping implied by the data; the cost
function is related to the mismatch between the proposed mapping and the data and for
this reason it must contains prior knowledge about the problem domain. The
parameters of the network have to be optimized in order to reach a good and accurate
output. Therefore the learning process should result in finding the weights
configuration associated to the minimum output error, namely the optimized weights
configuration. A commonly used cost is the mean-squared error which tries to
minimize the average squared error between the network's output, f(x), and the target
value y over all the example pairs.
9
The MLP can be trained by several strategies, such as gradient descent based
strategies, like the Error Back-Propagation algorithm (EBP) or evolutionary methods,
like GA or PSO [17]. For network training, a data set of geometrical configurations of
the patch is generated and the corresponding phase delays are estimated.
Trained ANN is tested on a Validation Set (VS) in order to validate its ability to
properly reconstruct the correct data model. When the training is performed, the rms
errors of both the training and validation processes decrease with increasing iterations.
As shown in fig. 5, weather prediction is a key input when the ANN is used for
forecasting. But, in case of rapid changes in solar radiation or temperature at the
analyzed day, the produced power changes greatly with respect to the forecast value. In
traditional prediction methods the ANN uses a pattern of comparable data to learn the
trend of the days with very like weather. However, learning all similar days' data is
quite complex, and it does not help if weather conditions change suddenly. Therefore,
it is necessary to integrate the neural network structure with real time information
coming from local meteorological stations and, in particular, from surrounding regions
and cities, where the weather change has already occurred. FI infrastructures among
smart cities could provide the integration of all these data by real-time connecting all
the sources of useful information for the load and energy production forecasting.
The results reported in fig. 6 show a more accurate forecasting obtained by using
traditional weather forecasts. The integration of real-time information helps to estimate
and correct the uncertainty in the weather forecast.
30
Power [kW]
P SM 35C (4)
20
Bright sunny day
10
(single day view)
0 Day
144.2 144.3 144.4 144.5 144.6 144.7 144.8 144.9
Power [kW]
Cloud and rainy day SM 4200S (3)

3
(single day view)
2
Day
0
136.3 136.4 136.5 136.6 136.7 136.8 136.9
Figure 6 – Real time information integrating PV plants in smart cities
6. Conclusions
Future Internet deeply changes smart cities enabling new distributed business
transactions on e-markets: it transforms former competitors in entities cooperating in
the optimization of the collective social functions. The role of the anticipatory
knowledge and its business contribute by considering a network of distributed
photovoltaic generators that make possible an inter-operable system in smart power
10
grid have been addressed. A Use Case on how one Internet of Things digital entity can
enable an extended collaboration and knowledge management in smart grids has been
presented. The Use Case about photovoltaic plants has been selected as representative
of the concrete business potential, justifying the research effort required. In particular
the authors suggest some models of the solar radiation based on artificial intelligence,
such as ANNs, in order to improve the efficiency of short-range forecasting. Moreover,
this predictive model has been enhanced by the integration with the real-time
information coming from the surroundings, in the framework of the future IoT. Better
predictability and observability improve the ratio between renewable and non-
renewable energy. Future work will be related to the development of new algorithms to
support FI dynamic entities and experimentations.
References
the Future Internet – A European Research Perspective, IOS Press, Amsterdam, 2009.
[2] J. Frunt, W.L. Kling, J.M.A. Myrzik, F.A. Nobel, D.A.M. Klaar, “Effects of Further Integration of
Distributed Generation on the Electricity Market”, Proceedings from UPEC ’06: The 41st Intl. Univ.
Power Engineering Conf. 1 (2006), pp. 1–5.
[3] Jiyuan Fan, S. Borlase, The evolution of distribution”, IEEE Power and Energy Magazine, 7(2) (2009),
pp. 63–68.
[4] T. Singh, P.K. Vara, “Smart Metering the Clouds”, 18th IEEE Int. Workshops on Enabling
Technologies: Infrastructures for Collaborative Enterprises (2009) , pp. 66–71.
[5] L.H. Tsoukalas, R. Gao, “From smart grids to an energy internet: Assumptions, architectures and
requirements”, Third International Conference on Electric Utility Deregulation and Restructuring and
Power Technologies (2008), pp. 94–98.
[6] A. Brooks, “Integration of electric drive vehicles with the power grid-a new application for vehicle
batteries”, The 17th Annual Battery Conference on Applications and Advances (2002), p.239.
[7] J.A. Pecas-Lopes, P.M. Rocha-Almeida, F.J. Soares, “Using vehicle-to-grid to maximize the integration
of intermittent renewable energy resources in islanded electric grids”, International Conference on
Clean Electrical Power (2009), pp. 290–295.
[8] M. Simonov, M. Mussetta, R.E. Zich, “Digital Energy: Clustering Micro Grids for Social Networking”,
International Journal of Virtual Communities and Social Networking 1(3) (2009), pp. 75–93.
[9] R.B. Chedid, S.H. Karaki, C.El-Chamali, “Adaptive fuzzy control for wind-diesel weak power
systems” IEEE Trans. Energy Conversion 15 (2000), pp. 71–78.
[10] A.N. Celik, “A simplified model for estimating the monthly performance of autonomous wind energy
systems with battery storage”, Renewable Energy 28 (2003), pp. 561–572.
[11] J.A. Pecas Lopes, “Advanced Microgrids as a Component for Active Management of Distribution
Networks”, Proc. Int. Conf. on Power Engineering, Energy and Electrical Drives, PowerEng '09
(2009), pp. 7–8.
[12] A. Soro, E. Vargiu, G. Armano, and G. Paddeu (eds.), Information Retrieval and Mining in Distributed
Environments, Springer, 2010 (in press).
[13] T. Senjyu, H. Takara, K. Uezato, “Two-hour-ahead load forecasting using neural network,”
Proceedings International Conference on Power System Technology, 2 (2000), pp. 1119–1124.
[14] Nazarko, J. El-Saadawi, M.S. Dehghan, B. Kiani, A. Kazemi, A. Parizad, “Optimal Sizing of a Hybrid
Wind/PV Plant Considering Reliability Indices”, World Academy of Science, Engineering and
Technology, 56 (2009), pp.527–535.
[15] R. Karki, R. Billinton, “Reliability/cost implications of PV and wind energy utilization in small isolated
power systems”, IEEE Trans. on Energy Conversion, 16(4) (2001), pp. 368–373.
[16] W. Taylor, and R. Buizza, “Neural network load forecasting with weather ensemble predictions,” IEEE
Transactions on Power Systems, 17(3) (2002), pp. 626–632.
[17] E. Grimaldi, F. Grimaccia, M. Mussetta, R. Zich. “PSO as an effective learning algorithm for neural
network applications”, Proc. of the 3rd International Conference on Computational Electromagnetics
and Its Applications, (2004), pp. 557–560.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-183
The Human side of the Future Internet

Jose SIMOES a,1 , Peter WEIK a and Thomas MAGEDANZ a
a
Fraunhofer Institute FOKUS, Kaiserin-Augusta-Allee, 31, 10589 Berlin, Germany
{jose.simoes, peter.weik, thomas.magedanz}@fokus.fraunhofer.de
Abstract. Despite all the uncertainties regarding the architectures, protocols and
technologies to be used in an Internet of the future, it is clear that it will be shaped
for humans, carrying with it major social and economical impact. In this sense,
aiming at improving the user perceived Quality of Experience in the Internet of the
Future, our paper presents common ground work for designing a unified generic hu-
man profile structure and correspondent architecture capable of seamless interact-
ing with a myriad of things and services, independently from their associated tech-
nologies. Moreover, supported by its reality, social and context awareness concep-
tion principles, it will enable human behavior to be leveraged to any entity present
in every single next generation ecosystem.
Keywords. Future Internet, Generic Human Profile, Quality of Experience, Social-
aware, User-centric
1. Introduction
Humans in all cultures, at all times tend to form complex social networks. This happens
because they are validated by shared perceptions of worth. Likewise, social networks
among individuals who may not be related can be validated and maintained by agreement
on objectives, social values, or even by choice of entertainment. Therefore, and mainly
due to the growing success and adoption of online social networks, it is easy to fore-
see that the services of the future will become multi-context and social-aware capable.
However, to enable such vision we need a ubiquitous technological platform (the Future
Internet) that is prepared to address the associated challenges. In this sense, the Internet
of the Future can be seen as a seamless fabric of classic networks and networked objects
that will not only co-exist but also be intimately bound up with our human world. It will
be an Internet with Things, where the content and services it facilitates will be all around
us, always on, everywhere, all the time [1].
Nevertheless, despite all the technological revolutions, for the end user (Humans) it
is the perceived Quality of Experience (QoE) that counts, where QoE is a consequence
of a user’s internal state (e.g., predispositions, expectations, needs, motivation, mood),
the characteristics of the designed system (e.g., usability, functionality, relevance) and
the context (or the environment) within which the interaction occurs (e.g., social set-
ting, meaningfulness of the activity) [2]. In other words, services must become person-
alized, contextualized, adapted, interactive, mobile, etc. while still concerning privacy.
To achieve such scenario it is critical to know more about the users. Consequently, it is
1 Corresponding Author.
184 J. Simoes et al. / The Human Side of the Future Internet
mandatory to find a unified and standardized way of managing users data; that is, access-
ing, storing, creating and modifying it. However, before focusing on the methodologies,
protocols or technologies, it is important to understand what kind of data will leverage
an optimized user experience in the Internet of the Future. Hence, in a first instance our
work proposes a user identity data structure/profile that encompasses: user preferences,
social networks and relationships, policies, devices, profiling algorithms, new knowledge
generation, among others. Based on this data structure we developed an architecture that
allows security, trust and privacy to be assured throughout the entire data management
process.
The remainder of this paper is organized as follows. Section 2 outlines work related
to user data management and associated challenges. Further, section 3 describes the pro-
posed generic human profile concept, its taxonomy, and discusses the technologies in-
volved. Based on the previous principles, section 4 presents the proposed architecture
and explains how the system works. Section 5 introduces the implementation work as
well as its evaluation. The last section concludes the paper by outlining future work.
2. The Challenges of User Profile Management
Current service creation trends in telecommunications and web worlds are showing the
convergence towards a Future Internet of user-centric services. In fact, some works [3]
already provide user-oriented creation/execution environments, but these are usually tied
to specific scopes and still lack on the capability to adapt to the heterogeneity of devices,
technologies and the specificity of each individual user. Based on these limitations, the
research in [4] identifies flexibility as the foundation for users’ satisfaction, where the
demand for different types of awareness needs to be present across the entire value of
chain of a service. Despite most initiatives require or propose some sorts of user pro-
file management systems; these are usually proprietary and include limited information
about user preferences and contexts. Therefore, in order to make use of user information
for a range of services and devices, there is a need for standardization of user related data
and the architecture that enables their interoperability. These efforts have been seen at
both fixed and mobile worlds and are usually taken under the European Telecommunica-
tions Standards Institute (ETSI), the Third Generation Partnership Project (3GPP), Open
Mobile Alliance (OMA), among others.
Considering data requirements from a wide range of facilities and from different
standardization organizations is the concept of Common Profile Storage (CPS) defined
by 3GPP in [5], a framework for streamlining service-independent user data and storing
it under a single logical structure in order to avoid duplications and data inconsistency.
Being a logically centralized data storage, it can be mapped to physically distributed
configurations and should allow data to be accessed in a standard format. Indeed, several
approaches have been proposed to guarantee a certain interoperability degree and can
be grouped into three main classes: syntactic, semantic and modeling approaches. The
work in [6] proposes a combination of them to enable interoperability of user profile data
management for a Future Internet. However, standardization, interoperability, flexibility
and management are not the only challenges.
To improve the degree of services personalization it is important to generate new
information from the existing one. In this sense, user modeling and reality mining tech-
J. Simoes et al. / The Human Side of the Future Internet 185
niques can be empowered to study patterns and predict future behaviors. Using these
techniques, the work in [7] models users profiles into short-term and long-term interest.
For that reason, user profiles should be capable of storing not only fixed parameters but
also variable data structures. Furthermore, as the research initiative in [8] shows, privacy,
security and trust are major topics that deserve a special focus in what concerns user pro-
file and identity management. Moreover, there are other non-technical challenges related
to a diversity of distinct regulations and high-level interests that sometimes are higher
than the desired harmonization and user satisfaction.
3. Generic Human Profile
3.1. The Concept
The Generic Human Profile (GHP) represents a set of properties built within a generic
structure that allows the services of the future to use user related information, while re-
specting their privacy, needs and concerns. Opening the door for opportunistic commu-
nications, user context is disclosed according to contextual privacy policies and settings,
enabling systems and devices to sense how, where and why information and content are
being accessed and respond accordingly. In addition, by using semantic, ontology and
keyword technologies that understand the meaning of information and facilitate the ac-
cessibility and interconnection of content, it is possible to generate/infer new types of
knowledge that can relate to users’ behaviors, needs or intentions.
Nevertheless, despite the utility of such profiling algorithms, the user should be in
control during the entire process. People will wish to manage their identities in different
ways, sometimes opting for full disclosure, at other times disclosing only in an anony-
mous way that preserves their privacy. This is essential for establishing and managing
trust and for safeguarding privacy, as well as for designing and implementing business
security models and policies. By storing users external contexts, it will be possible to
compare different sorts of data, so far not correlated improving on the one hand the al-
gorithms, but on the other hand the user overall satisfaction as services become more
contextualized, adapted and consequently personalized. Moreover, GHP envisages the
integration of social data from different platforms, providing a unified way to access
users’ (Humans) friends’ lists, among others, combining both online and offline social
networks data. In the end, a crucial step will be the Profile Description Framework (PDF)
to handle the transformation of a technical profile into a tradable and interoperable good.
In this sense we believe that PDF will be at the heart of the GHP and the Future Internet.
3.2. Requirements and Technological Considerations
When thinking about the implications towards a Future Internet, user related data raise a
series of questions. In what concerns security, we will need multi-factor authentication
and authorization mechanisms that can be achieved by combining context-aware pol-
icy admission points with identity providers, providing an open and standardized data
management service.
As for data storage and distribution, it is very likely to see trusted cloud service
providers (probably telcos) embracing this opportunity, where all attribute data related to
users in a specific context can be easily accessed and aggregated. Although a distributed
but interconnected standardized logic to access this data is required, its physical storage
can be done within walled garden domains. In this sense, it is expected that context itself
will have a signaling protocol and a complementary distribution one. Depending on the
evolution of mobile devices, there is also the possibility to assist to a shift where some
of the users associated data is stored locally. In fact, a first step towards the combination
of the previously enunciated mechanisms (local vs. remote storage) is being explored by
the newly launched Vodafone 360 service.
Regarding the business aspect, it is necessary that the solution is flexible enough to
allow different entities to be involved in the value chain and therefore contribute to over-
all service offering. Furthermore, scalability and performance will be crucial for the roll
out of such initiative. Billing and revenue distribution are also topics that need to be ad-
dressed, otherwise, when ignoring them, the overall solution may become compromised.
3.3. Generic Human Profile Taxonomy
For our purposes, besides user’s personal data, the system was also capable of collecting
their affiliations as well as their friends. Figure 1 presents the taxonomy of the afore-
mentioned user profile. As depicted, users have the possibility to control who views, dis-
tributes or modifies their information, what type of data is accessible and under which
circumstances this occurs, including the possibility to control the way the profiling (rea-
soning and prediction) algorithms work. In addition, the GHP is capable of storing in-
formation from different social networks, where the information stored can vary from
one community to the other. It is also possible to acquire external contexts that can be
very helpful for new knowledge generation. Moreover, by aggregating data regarding
user devices and their properties, it will enable services to easily adapt themselves to end
terminals.
Figure 1. Generic Human Profile Taxonomy.

4. Architectural Approach
In order to realize the vision previously described it is necessary to transpose the Generic
Human Profile concept into an manageable format. In this sense, this section presents the
architecture, the components needed, as well as some some use cases, exemplifying how
the system works.
4.1. General Overview
With the goal of achieving an efficient and secure way of managing user related data, our
main concerns were:
• Advanced data management - allow the functions of data creation, modification,
deletion, storage, acquisition, subscription, notification and syndication in a se-
cure and efficient way.
• Authentication - act of confirming that someone is authentic and that the claims
made by or about the subject are true.
• Authorization - function of specifying access rights to resources, according to a
set of access policies.
To accomplish these objectives and to be compliant with the requisites specified
in section 3.2, the architecture is mainly supported by a single component, the Human
Enabler, and its associated modules. Nevertheless, other entities may be added to tailor
extra functionalities. Figure 2 represents the disposition of the involved elements.
Figure 2. Overall Human data management architecture.
Before presenting how the system works, it is essential to understand which are the
entities involved and what they do.
4.1.1. The Human Enabler

Acting as the main component of the entire architecture, the Human Enabler is composed
by four distinct but complementary modules that are logically tight together, but can be
physically separated (as long as basic security mechanisms are assured). They are:
Human Context Broker. Responsible for managing and processing all requests
coming from the outside. Its interfaces allow direct access to recently cached informa-
tion (context has always an expiration date) or an API for historical data. For the case
of real-time context, it can be requested or subscribed. If the last occurs, when context
changes, a notification is sent to the previously subscribed entity. Furthermore, it allows
information to be updated, created or deleted using a specific ContextML format [9].
Human Profile Repository. Where all the users related information is stored (both
real-time and historical). Basically it represents the physical implementation of the
Generic Human Profile specified in section 3.
Policy Evaluation & Enforcement. This component implements an interceptor that
may be applied on all critical interfaces and act as an intermediate system between the
resource requestor and target resource. It intercepts both the request and the response.
Based on the evaluation results, this entity decides to forward the message to the destina-
tion or send a deny message to the message originator. The Policy Evaluation Engine’s
main activity is the evaluation of policy conditions and execution of associated actions.
In order to perform this activity, it has to first identify and return relevant policies from
the policy repository based on the input data. The Policy Enforcement Engine of which
the evaluation process is part of, builds an enforcement decision based on the results
of the evaluation process execution and of the processes that imply invocation of other
resource capabilities (request delegation) that are stipulated into evaluated policies.
Authentication Module. Responsible for authenticating all requests coming from
third-party applications or on behalf of other users. It interacts with the Identity Provider
to confirm the authenticity and integrity of the requests intercepted by the policy inter-
ceptor.
4.1.2. Identity Provider

An identity provider will allow users and 3rd party applications to come to a commonly
agreed level of authentication for users and shall be able to produce the necessary for-
matting of authentication and authorization tokens. Even though self-asserted identity
attributes will still be very prevalent in the GHP, there are also scenarios possible where
the workflows will require token assertions of trusted attribute from identity providers.
For an easy management of the roles or personas of users in this context, an identity
provider will play the central role in such a user-centric setup. The identity providers in
that sense can offer a secured life-cycle management of digital identities for users.
4.1.3. Human Context Providers

Entities capable of obtaining basic or reasoned contexts from sensors, networks, devices,
social networks or other data sources. Moreover, they provide and deliver this informa-
tion in an interpretable manner, making it available to other components. They can act
as standalone applications or publish their information into the Human Enabler through
specific control mechanisms [9].
4.1.4. Third Party Applications and Users

Represent the entities responsible for requesting Human related information. A third-
party application can make requests on behalf of particular users or by itself (considered
as well as a user in the system).
4.2. How the System Works
Assuming that the main functionality of such architecture is to request user related data,
we will use this use case to demonstrate how the different components/modules commu-
nicate between themselves. Figures 3 and 4 illustrate these interactions.
Figure 3. Authentication procedure for user related data requests or subscriptions.
In the future it is expected that most applications have some Internet based depen-
dency. In this sense, all user requests must be somehow authenticated (1). In our partic-
ular scenario, the user is given the option to choose his favorite Identity Provider (IdP).
When he does this, his request is redirected accordingly (2). Afterwards the user will
authenticate according to the desired level of permission of the 3rd party application
(3-4). The offered authentication methods can vary according to each IdP’s capabilities
of validating user identities. While offering tailored service towards users, applications
might require extended user related information (e.g., list of friends, location, weather,
preferences, recommendations). Within the proposed solution, all requests are sent (5)
to the Human Context Broker (HCB). Prior to being processed, these are intercepted (6)
by the Policy Evaluation & Enforcement module (PEEM). Before checking or enforcing
any type of policy, the component forwards the request (7) towards the internal Authen-
tication module so that the assertions provided by the third party application can be cross
checked (8). Once this is done, the PEEM is informed (9) and continues its operations.
After the request is duly authenticated and authorized, the PEEM requests the de-
sired context information (10). Then, the information contained inside the response is
initially evaluated towards the provider/operator policies (stored inside the PEEM) and
then cross checks against user self defined policies (the ones owning the context). De-
pending on the implementation, this information may be located inside the Human Pro-
file Repository (HPR). In this situation, these policies need to be fetched (11) so that the
response can be verified and correctly authorized. The main reason why requests are not
evaluated right upon a request is sent to the HPR is related to the fact that in some cases,
the policies are temporally or spacially dependent and therefore they can only be evalu-
ated when the response/trigger occurs (this applies particularly for subscribed informa-
tion). After being evaluated, the response is enforced towards the HCB (12), which is
in charge of forwarding the message towards the third party application (13). Using the
requested context data together with the remaining application logic, the user is targeted
with a personalized and adapted service experience (14).
Policy Evaluation 10. Request Human Profile

3rd Party Human Context Context
Application 13. Human Broker 12. Human & Enforcement Repository
Context Data Context Data
11. Request
Policies
14. Personalized
User Experience
Users
Figure 4. Authorization procedure for user related data requests or subscriptions.
Although not depicted, the Human Context Providers are usually the entities that
trigger system responses (when some context is updated) and consequently the autho-
rization process. Based on the aforestated principles, it is up to the application (entity
requesting context) to adapt delivery and customization accordingly. Within the C-CAST
project we used several components distributed across session, network and transport
layers aiming to improve the balance between efficiency and personalization for mul-
tiparty multimedia delivery in group communications [10]. Such implementation based
on the presented architecture allowed the improvement of real-time Quality of Service
(QoS) management, consequently increasing the user overall perceived QoE.
5. Implementation and Evaluation
With the purpose of evaluating the proposed system architecture, we developed a testbed
environment involving the aforementioned components. The PEEM was represented by
the FOKUS XPOSER [11], [12], an Open Mobile Alliance (OMA) compliant imple-
mentation for policy evaluation and enforcement. As an Identity Management Provider
we used FOKUS Generic Unified IDentity Enabler (GUIDE) [13], which supports mul-
tiple state-of-the-art identity management technologies, such as the Security Assertion
Markup Language (SAML) 2.0 [14] and OpenID 2.0. Both the HPR and the HCB were
implemented as an extended version of the UASO Context Broker [15], whose scopes
(contain the description of a specific type of context) were extended to integrate a simpli-
fied version of the GHP taxonomy introduced in Figure 1. The Context Providers (CxP)
used within the tests were developed under the C-CAST European Project [16] and in-
volve, Device CxP, Weather CxP, Location CxP, Social Networks CxP, among others.
It is important to notice that in our testbed we assume that a trust relationship exists
between all the components inside the Human Enabler, otherwise, extra security mech-
anisms should be enforced. Finally, we developed an augmented reality application to
explore the potential of the presented architecture.
What if there was a way for users to simply point their mobiles at people and au-
tomatically know more about them? By using the phone location, compass APIs and
the context information about other users (accessible through the Human Enabler), it is
possible to emerge in a new way of interacting with people. To show how this translates
into context and policies stored within the Human Enabler, figure 5 gives a short exam-
ple. On the other hand, figure 6 provides some examples of what could be possible to
a) b)
Figure 5. a) Policy example b) Piece of user ’Jonny’ context data.
achieve. In scenario a), the user wants to know more about the publicly available infor-
mation regarding the Facebook profile of the person currently being tracked, while b) on
the other hand provides basic profile information that the person in the picture decided
to share at that precise moment within that context, improved with the system inferred
information. Case c) presents a summary of keywords that better define a person’s profile
within the Digg community (this could give a quick overview of someone’s interests). In
this sense, we can see that the services presented can be provided directly by the Human
Data Repository (exposed by the Human Enabler) but at the same time, be a combination
of previously reasoned information (can be provided by other applications) with specific
application data itself.
Figure 6. Example of a Human Social application: a) Facebook option, b) Personal Profile option, c) Digg
option.
As mentioned earlier, all the information disclosed by the user is dynamically man-
aged by himself (through the policies) and can be updated in real-time (using the Human
Enabler). Depending on the time of the day or event the user is attending, he can decide
which information can be retrieved by the system. Such applications will also help to
promote collaboration and enrichment of existing content, as they can provide the in-
terfaces to interact with it and consequently the user himself. Again, such personalized,
contextualized, interactive, mobile and adapted experiences will allow users to engage
with next generation services as these will respect their privacy but at the same time ad-
dress their needs, concerns and desires. For third party applications the benefits are even
more evident, as technology will allow them to better understand their customers and
therefore tailor their solutions accordingly.
Merging digital and physical worlds will create unprecedented ubiquitous user interfaces
enabling a set of seamless rewarding user experiences. In our work, by extending regular
user profile data (user preferences) to accommodate social, context, device and policy
related information, we open the path to a new era of services where these can become
user behavior aware, paving the way to understand their needs, desires and intents. To-
gether with other security considerations (authentication, privacy and trust) this work
may have considerable social and economical impact in the Internet of the Future. In a
way, it will improve users perceived Quality of Experience by changing the way they
see, use, consume and interact with content and services in any futuristic scenario.
References
[1] J. Hourcade et al., Future Internet 2020: Visions of an Industry Expert Group, European Commission
Information Society and Media, Apr. 2009.
[2] M. Hassenzahl, N. Tractinsky, User experience - a research agenda, Behavior & Information Technology,
Vol. 25, No. 2, pp. 91-97, April 2006.
[3] C. Baladron et al., User-Centric Future Internet and Telecommunication Services, Towards the Future
Internet, IOS Press, 2009.
[4] F. Liberal et al., QoE and *-awareness in the Future Internet, Towards the Future Internet, IOS Press,
2009.
[5] G. Bartolomeo, T. Kovacikova, User Profile Management in Next Generation Networks, Proceedings of
the 5th Advanced International Conference on Telecommunications, Venice, May 2009.
[6] 3GPP TR.32.808: 3rd Generation Partnership Project: Technical Specification Group Services and Sys-
tem Aspects; Telecommunication management; Study of Common Profile Storage (CPS) Framework
for User Data for Network Services and Management (Release 8).
[7] C. Wei, C. Haung, H. Tan, A Personalized Model for Ontology-driven User Profiles Mining, Proceedings
of the International Symposium on Intelligent Ubiquitous Computing and Education, May 2009.
[8] C. Sorge, J. Girao, A. Sarma, Privacy-enabled identity management in the Future Internet, Towards the
Future Internet, IOS Press, 2009.
[9] Delverable 12 - Specification of context casting service enablers, context management and context bro-
kering, C-CAST Project (ICT-2007-216462), http://www.ict-ccast.eu/deliverables.php 2009
[10] S. Sargento et al., Context-Aware Multiparty Services Delivery: Evaluation and Experimentation, Future
Network Mobile Summit 2010, Florence (Accepted for Publication)
[11] XPOSER - an eXtended POlicy-based, Semantically enabled sErvice bRoker, www.open-soa.de/xposer/
[12] N. Blum et al., A Service Broker providing Real-time Telecommunications Services for 3rd Party Ser-
vices, 33rd Annual IEEE International Computer Software and Applications Conference, 2009
[13] A FOKUS Generic Unified IDentity Enabler - www.id.open-ims.org
[14] J. Hughes, E. Maler, Security Assertion Markup Language 3 (SAML) 2.0 Technical Overview,
http://saml.xml.org/, 2005.
[15] M. Knappmeyer, N. Baker, S. Liaquat, R. Tonjes, A Context Provisioning Framework to Support Perva-
sive & Ubiquitous Applications, 4th European Conference on Smart Sensing and Context, 2009.
[16] Context to Content Casting - European 7th Framework C-CAST Project (ICT-2007-216462) - Provide
an End-to-End Context-Aware Communication Framework, http://www.ict-ccast.eu/
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-193
Self-Improving Personal Smart Spaces for

Pervasive Service Provision
Ioanna G. ROUSSAKIa,1, Nikos K. KALATZISa, Kevin J. DOOLIN b, Nick K.
TAYLORc , Guido P. SPADOTTO d, Nicolas D. LIAMPOTISa, and M. Howard
WILLIAMS c
a
National Technical University of Athens, Athens, Greece
b
TSSG, Waterford Institute of Technology, Waterford, Ireland
c
Heriot-Watt University, Edinburgh, UK
d
Soluta.Net, Treviso, Italy
Abstract. Current research in pervasive computing, as well as in the fields of

mobile telecommunications and device manufacture are opening the way for
convergence between mobile telecommunications and the traditional Internet
towards the Future Internet. The ubiquitous computing paradigm integrates
information processing into the objects that surround us in our environment and
permits both global control of these objects and global access to the information
they can provide. One aspect of this is the notion of smart spaces where the
integration of communication and computational devices is being used to create
intelligent homes, offices and public areas, which provide intelligent support for
the user. The Persist project (PERsonal Self-Improving SmarT spaces) is
investigating a novel approach to this convergence through the introduction of the
concept of self-improving Personal Smart Spaces.
Keywords. Personal Smart Spaces, Pervasive Services, Context-awareness,

Learning & Reasoning, Self-Improvement, Proactivity, User Intent prediction
1. Introduction
The first basic paradigm for computer usage was that of a single computation device,
originally the mainframe and later on the desktop computer. However, over the past
two decades [1], the notion of ubiquitous or pervasive computing [2] has evolved to
capture environments where humans are surrounded by a large number of different
devices and technologies that “weave themselves into the fabric of everyday life until
they are indistinguishable from it”. These technologies support a range of services,
which capture processes and exchange information to serve the needs of humans.
Recently, the term “everyware” has been used to describe these [3]. The importance of
this new paradigm has been recognised both by the academic/research and the
industrial community; and the area of Ubiquitous Computing has been identified in two
of the seven major global challenges for Computer Science over the next decade [4].
1
Corresponding Author. Contact details:
Address National Technical University of Athens, School of Electrical and Computer Engineering,
Department of Communications, Electronics and Information Engineering, 9 Heroon Polytechneiou Str, 157-
73 Zographou, Athens, GREECE. Telephone +30 210 772 2422. Fax +30 210 772 2530. E-mails
nanario@telecom.ntua.gr, Ioanna.Roussaki@cn.ntua.gr.
194 I.G. Roussaki et al. / Self-Improving Personal Smart Spaces for Pervasive Service Provision
Thus, much research has been devoted to the development of ubiquitous or

pervasive systems over the past decade. One class of system that has emerged from this
process is that of fixed Smart Spaces, which aim mainly to create intelligent buildings.
Here research has focused on developing techniques to support building automation (or
domotics), such as intelligent light controls, window shutters, security systems, kitchen
appliances, etc. In particular, there has been considerable interest in developing
intelligent smart homes that can provide support for elderly and disabled residents,
making it safe for them to live at home. This approach is basically concerned with a
fixed space that is required to provide intelligent features that adapt to the user’s needs.
Another class of systems that has emerged aims to address the needs of mobile
users. This introduces different and more challenging problems. In this case there are
strong requirements regarding the delivery of services irrespective of the user’s
location and the devices that are accessible to him/her. A ubiquitous system is expected
to provide access to devices and services in the user’s current environment, no matter
what time it is, or where the user is located. A typical example is that of the use of
personal biometric sensors that might communicate with home controls for
illumination, heating or air conditioning in a room to provide the ideal environment for
a user or the best compromise for a group of users. Likewise, a user’s location might be
used to select different network options and services when the user is at work from
those selected when he/she is at home. This is also applicable to situations where the
user is travelling in a car or walking outdoors.
However, these two classes of systems are generally completely disjoint, as
research in the domain of fixed smart spaces is associated with buildings and is quite
independent of ubiquitous or pervasive systems for mobile users. This has resulted in
the existence of “islands of pervasiveness” within which fully functional pervasive
services are provided, but outside of which there is limited (if any) support of pervasive
features. This makes it very difficult to combine these two classes of system. For
example, Smart Homes control devices and services within their physical boundaries,
but they cannot easily share these with the mobile networks of the residents or of
visitors.
Persist (PERsonal Self-Improving SmarT spaces) (http://www.ict-persist.eu/) is an
EU funded project, which aims to overcome this problem through the notion of self-
improving Personal Smart Spaces (PSSs). PSSs aim to couple the facilities offered by
next generation mobile communications and the Future Internet with the features
provided by static smart spaces to support a more ubiquitous and personalised smart
space that is able to follow the user wherever he/she goes.
This chapter presents some of the concepts, features and approaches underpinning
Personal Smart Spaces. The rest of this chapter is structured as follows. Section 2
elaborates on the nature of Personal Smart Spaces and provides some concept
definitions. Section 3 describes an illustrative PSS use case scenario that highlights
some of the main features and capabilities of Personal Smart Spaces. Section 4 presents
the PSS architecture and describes the roles and functionality of its core component
blocks. Section 5 investigates how Personal Smart Spaces contribute to the Future
Internet and benefit from it. Finally, in Section 6 conclusions are drawn and future
plans are exposed.
2. Personal Smart Spaces (PSSs)
In order to explain what a Personal Smart Space (PSS) is, this section first discusses
what a smart space implies, and then elaborates on the key features of a PSS. Smart
I.G. Roussaki et al. / Self-Improving Personal Smart Spaces for Pervasive Service Provision 195
Spaces usually target real physical spaces as in HP’s Cooltown project [5], rather than
“Smart Places”. A common definition from this point of view is the following: “A
smart space is a multi-user, multi-device, dynamic interaction environment that
enhances a physical space by virtual services” [5][6]. The services are the means of
interaction between participants, objects and the smart spaces. Another definition
describes them as “ordinary environments equipped with visual and audio sensing
systems that can perceive and react to people without requiring them to wear any
special equipment” [7], which is more or less the vision in several projects and
prototypes [8][9][10][11][12]. The common aspect in these definitions and most
approaches to smart spaces is the need for infrastructure and sensor-equipped rooms.
They neglect the costs of installation and maintenance and the difficulties related to a
market entry. If Smart Spaces are to have a wider impact they must be enabled to work
without sophisticated infrastructure in specially enhanced rooms and to allow for user
mobility. This leads us to one of the key features of PSSs.
A PSS is able to interact with other PSSs, fixed or mobile, in its vicinity, and
thereby share information and services. Thus, as the owner of a PSS moves to different
locations, his/her PSS interacts with other PSSs in the surrounding environment,
offering services to these other PSSs or accepting services from them, thereby offering
a unique support for pervasive service provisioning. In a nutshell, a Personal Smart
Space can be defined as a set of services within a dynamic space of connectable devices,
where the services are owned, controlled, or administered by a single user [13]. It
facilitates interactions with other PSSs, it is self-improving and is capable of pro-active
behaviour. Thus, a PSS is user centric and controlled by a single user; it is mobile, it
allows for interactions with other PSSs and is capable of self-improvement and
proactive behaviour.
Figure 1. Interaction between PSSs: a) a PSS interacts with a fixed Smart Space, b) two PSSs interact via a
fixed Smart Space and c) two PSSs interact without the intervention of a fixed Smart Space.
The Persist vision is of a Personal Smart Space that will provide an interface
between the user and the various services and sensors which are, or will be, available
globally via the Internet. PSSs will be able to interface to local devices and sensors
even when no Internet connectivity is available to the user. Moreover, PSSs will be
able to interact with one another to create a more powerful and flexible environment for
users, enabling them among other things to obtain indirect access to the Internet by
chaining from a user who does not have Internet access through to a Personal Smart
Space which can supply such connectivity. In this framework, three main PSS
interactions will be supported (Figure 1), i.e. PSS interactions with fixed Smart Spaces,
PSS to PSS interactions via fixed Smart Spaces and PSS to PSS interactions without
the intervention of fixed Smart Spaces or infrastructure in general.
As already stated, a PSS is mobile, i.e. its physical boundary moves with the user,
and thus, the availability of PSS services is determined by their reachability, and a set
of rules defining admissibility to the PSS. This allows PSSs to overlap in a given
physical area, and gives an intuitive way to manage the interactions between them.
Furthermore, a PSS has a single “owner”, the person or legal entity on whose behalf the
smart space operates. This allows any PSS to be personalised, and by extension,
personalisation of transient services from another visited PSS, subject to conflict
resolution between their preferences. In order to provide appropriate support, a PSS
should be capable of operating in both infrastructure and ad-hoc network environments.
This promotes the widest possible use of the PSS, as an integrator of devices.
Additionally, applications within a PSS must be able to adapt to the current situation.
To facilitate this, the PSS offers “enabling” services for context, preference, privacy,
application management, etc. Each application service must interact with these
“enabling” services of the PSS middleware, and react on any notified changes. A PSS
facilitates applications in their interaction with the environment. Finally, a PSS can
learn from previous interactions. Self-improvement is achieved by mining the
information stored in the PSS to identify trends, and infer conditions when preference
or user behaviour changes are manifested. This allows recommendations to be made
when a PSS interacts with neighbouring PSSs, or for it to act proactively based on
reasoning on user intent. A PSS can also use historic information to reason about the
trustworthiness of other PSSs in order to protect the privacy of the user.
To support the PSS components involved in the decision making processes, a
library based approach has been adopted, enabling them to access a collection of
algorithms via a single access point. This library is open and extendible allowing for
new algorithms to be added. As learning and self-adaptation are among the focal PSS
properties, the library includes modular and pluggable learning algorithms. Examples
of such algorithms used in the PSS prototype are Bayesian filtering for context
refinement, diffusion models for proximity estimation, clustering techniques in order to
discover recurring locations, as well as decision tree models, statistical analysis and
markov chains in support of user intent prediction and preference learning [14].
Furthermore, in order to support the PSS recommender system, algorithms and
techniques such as attribute/search based correlation, statistical summary based
correlation, user-to-user correlation, item-to-item/content based correlation and hybrid
approaches have been adapted to address the requirements of the PSS mobile users.
In a nutshell, a PSS supports the following functionality: context awareness;
personalization; service management, discovery and composition; dependability and
privacy protection; user grouping and service sharing; user intent prediction;
recommender systems; pro-active behaviour; learning and reasoning; self-
improvement; user, device and session mobility; ad-hoc connectivity and
communication.
3. A PSS use-case scenario
This section describes an illustrative PSS use-case scenario and from this identifies the
scene segments where each of the PSS features is demonstrated. It is assumed that the
actors may carry various portable devices, such as smart phones, laptops and tablet PCs
that constitute their PSSs. It is also assumed that communication between the devices
of the same PSS or of different PSSs is supported, while third party services and
sensing devices (or context information) is provided by the infrastructure that interacts
with the PSSs.
3.1. Smart Conference and Reconfigurable Room use case
Mark is about to participate in a scientific conference. At the meeting venue

information regarding the conference is available to the attendees via an infrastructure-
fixed Smart Space that forms a digital workspace. As Mark enters the entrance hall, his
PSS interacts with the fixed smart space and Mark is automatically identified as a
preregistered attendee of the conference. This enables Mark to access information such
as the meeting agenda, the list of attendees, the lunch menus, internet access tokens,
third party services, etc. In a similar manner Mark’s PSS may disclose his food
preferences to the fixed Smart Space so that the meeting organizers can adapt the food
they will serve accordingly. The negotiation and the respective decisions for the
disclosure or not of personal information are based on trust assessment negotiations
between Mark’s PSS and the fixed Smart Space based on Mark's privacy preferences
and the organizers’ privacy policy. Attendees can also indicate their seat location on the
seating map and enable other attendees to see their digital business card.
As the meeting proceeds, updated information is available via fixed displays or
PSS devices of attendees. For example, Mark’s PSS is updated with data regarding
people sitting close to him and having similar research interests. Furthermore, Mark’s
PSS provides him recommendations about the rooms and the topics of the next sessions
that he might be interested to attend.
The meeting’s fixed Smart Space can be proactive and pre-load presentations
allowing easy sharing and display. Projector services, as well as other common services,
can be made available to attendees in a proactive way, based on agenda information
and users’ current context. For instance, the air conditioning service of the room where
the presentation takes place is proactively configured according to all attendees’
preferences and priorities. Potential conflicting temperature preferences are resolved by
negotiation among the participants PSSs that form a group of users sharing this service.
After a presentation is finished, attendees can give feedback or write their
comments and make them available to others. As Mark is impressed by the
presentation he had just watched and he has put it down as very interesting, his PSS is
automatically printing the slides and his comments. The proactive decision is based on
Mark’s previous behaviour, as he did the same thing manually several times in the past.
Mark’s printing requirements for each occasion are retrieved and addressed by the
printing service.
As the conference is nearing an end, group photos of the speakers and attendees
are distributed automatically by email, as well as travel information, while taxi
booking/sharing services are offered to the PSSs of the attendees. The taxi sharing
service provided by the fixed Smart Space has arranged for Mark to share a taxi with
another person wishing to be at the airport at the same time. Mark accepts the sharing
and both PSSs receive information on where and when to wait for the taxi.
When Mark arrives at the airport after the conference, his navigation service
directs him via audio-visual means to the appropriate check-in counter. His buddy-
finder service also notifies him that a very good friend Mary is also in the airport and
that an Instant Message (IM) has already been sent to his friend stating Mark’s location.
Their two buddy-finder services interact with their location services to work out the
most suitable meeting point. An IM is sent to both PDAs saying: “Do you want to meet
up with Mary/Mark at Murphy’s Bar in departures in 15 minutes?” Mark and Mary
both respond positively. Mark’s navigation service guides him to Murphy’s Bar.
When Mark arrives home and enters his living room, his PSS transforms it based
on his preferences. At this time of day Mark uses the room as an office. A desk and
chair emerge from the floor. Filing cabinets emerge from the wall. Wallpaper appears
on all the walls with various stock market movements depicted in the wallpaper pattern.
A weather satellite image for the next 24 hours appears on one window pane. Three
clocks appear on the wall set to London, New York and Tokyo times. Mark sits down
and interacts with the tablet, which forms the surface of the table.
Later on, Mark’s friend Robbie arrives. Mark is alerted to his arrival when
Robbie’s PSS comes into contact with his. Robbie’s PSS makes two recliners emerge
from the floor. Mark moves over to one of the recliners and all work related items and
displays vanish. Instead, Mark’s free time items and displays appear around the room.
Robbie sits on the other recliner. They are going to watch the football finals. All items
on the walls disappear and the wallpaper changes to display a football stadium. The
lights dim and Mark and Robbie feel as though they are in the stadium.
3.2. Scenario Analysis
A Personal Smart Space provides a number of innovative features as described in detail

in Section 2. In the above use case scenario, the following PSS features are
demonstrated in the scene segments identified below.
• Context awareness: Context information is monitored and used in all the scenes
that involve location, presence, proximity, personal preferences, environmental
data, time, sensors, etc. For example, the system infers, based on contextual
information together with data from the agenda, that a person is about to make a
presentation and so the projector service is proactively configured for the presenter.
• Personalisation: It is used when services are adapted based on user preferences. In
the scenario, temperature preferences are used to adjust the air conditioning service
and printing preferences to configure the printer, while Mark’s room is
reconfigured based on his current needs.
• Service Management, Discovery and Composition: In all scenes where service
provisioning is involved, the services are discovered, composed and managed
automatically to address the user requirements in the best possible manner.
• Dependability and Privacy: This feature is demonstrated in various situations
where personal information is about to be disclosed. For example, disclosure of
food preferences or user’s location occurs only once trust assessment negotiations
between the parties involved have taken place and after the users’ privacy
preferences and the service’s privacy policy have been considered.
• Grouping and Sharing: The feature of sharing a service among the members of a
group of users is demonstrated in the air conditioning adaptation scene although
there is also considerable potential for the formation of dynamic groups.
• User Intent Prediction: This feature is demonstrated at the scene where Mark’s
PSS automatically decides to print the session slides and again when his PSS
selects the taxi sharing service. In the latter instance, his PSS predicts that he is
about to depart. A sequence of Mark’s actions indicates that his work in the
meeting is ending and that he intends to depart by taxi.
• Recommender Systems: These systems are used in the scene where Mark receives
recommendations about the rooms and topics of the next sessions that he might be
interested to attend, based on others attendees’ opinions and his personal history.
This feature is also demonstrated in the selection of a specific taxi service.
• Pro-active Behaviour: The system uses predictions of user intent, coupled with
user preferences and other people’s recommendations, to discover, configure and
initiate services automatically. For example, proactivity is demonstrated when the
PSS initiates a negotiation to share a taxi and when it reconfigures Mark’s room
when Robbie arrives.
• Learning and Reasoning: This functionality is demonstrated in all the scenes
where inference or predictions are made. This refers to context information, user
preferences, user behaviour & intentions, and service discovery, selection,
composition and configuration.
• Mobility and Infrastructure: In all scenes of the smart conference scenario, ad-hoc
network connections are established, supporting intra- and inter-PSS
communication among devices, enabling user and device mobility, and a robust
runtime environment is available on all devices.
4. The PSS Architecture
The PSS architecture adopts a layered approach, as depicted in Figure 2. More

specifically, the architecture consists of five different layers, each addressing a well
defined part of the PSS functionality. The names and purpose of these layers are
presented hereafter.
Figure 2. Functional view of the PSS Architecture.

Layer 1 - Devices
The PSS definition suggests that a single PSS can span across many different devices.
Depending on their processing and networking capabilities, these devices may either
implement the entire PSS stack or part of it, or simply interact with the rest of the PSS
Framework. The device classification that follows, aims to identify the devices that
may be part of a PSS and is based on a survey of current market-leading technologies
grouped by functional/technical commonalities.
• Server: An independent computer dedicated to provide one or more services

over a computer network (e.g. Windows Media Center, Apple Itheatre, PCs).
• Laptop: A small portable computer (e.g. Mac Book, Sony Vaio, Tablet PC).
• Mobile phone: A pocket-sized handheld computing device (e.g. iPhone, HTC
Tytan, Nokia N90, PDAs).
• Sensors: A group of devices that can measure a physical quantity and convert
it into a signal, which in turn can be read by an observer or an instrument.
They can be embedded into other devices (e.g. RFID readers, GPS location
estimators, accelerometers, thermometers, altimeters, barometers, air speed
indicators, signal strength measurers).
• Smart object: A resource-constrained device (e.g. WiFi photoframe, Chumby,
Nabaztag, home eAppliance, surveillance camera) that can be connected to
the Internet or a LAN via a WiFi connection, ethernet, GPRS, 3G etc., usually
intended for displaying multimedia content such as a combination of text,
audio, still images, animation and video.
• Interactive entertainment electronic device: An Interactive entertainment
electronic device producing a video display signal (e.g. set-top box, gaming
console), which can be used with a display device (a television, monitor, etc.)
to display a video game or an external source of signal (e.g. IPTV).
Layer 2 - System Run-Time Environment (RTE)
The System Run-Time layer serves as an abstraction layer between the underlying
device operating system and the PSS software in order to achieve as much platform
independence as possible. Essentially, this layer is what makes a device PSS-capable.
Hence, employing an "off-the-shelf" implementation of a virtual machine run-time will
offer PSS portability over a wide range of software and hardware platforms.
Layer 3 - Overlay Network Management (ONM)
The Overlay Network Management layer provides the PSS architecture with a Peer-to-
Peer (P2P) management and communication layer. The services within this layer
provide functionality for PSS peer group management, peer discovery and message
routing between peer networks.
Layer 4 - Service Run-Time Environment
This layer provides a container for the PSS services. It supports service life cycle
management features and provides a service registry and a device registry. Moreover, it
allows for service management in a distributed fashion among multiple devices within
the same PSS. In this context, it delivers fault tolerance as well as device resource
management. The Service Run-Time Environment also provides advanced information
management features for achieving high data availability and addressing storage
requirements of PSS services.
Layer 5 - PSS Framework
The PSS Framework layer is the core of the PSS architecture. Its functions include
discovering and composing PSS and 3rd party services, as well as managing context
data and user preferences. Moreover, the PSS Framework layer supports automatic
learning of preferences and user behaviour, as well as inference of context data & user
intentions. This information, together with data from recommender systems, enables
the proactive behaviour of the PSS platform. Grouping of context data and preferences
as well as conflict resolution and resource sharing are also provided by this layer.
5. Personal Smart Spaces in the Future Internet
The Internet was designed to enable computers to communicate and this is reflected in
the way humans interact with it. Technical details are still predominant in the Human-
Internet interaction: firstly a connection has to be made, then services have to be
identified and located, and finally accounts must be created for each service to be used
before one can run them. Moreover, the main interaction device is typically a full-
blown computer that is not usually portable or constantly at hand and provides a
primitive “point-and-click” interaction style. The Future Internet (FI), on the other hand,
will focus on end-user needs, providing pervasive and seamless access to services and
the information that will represent each of us in the digital realm. The FI will be
ubiquitous and transparent so that one is only aware that it exists when it is unavailable.
As we have seen, a PSS provides a cocoon around a user through which all their
interactions with pervasive systems are mediated. The PSS is able to assess the
trustworthiness of services and resources which are offered by pervasive environments
and negotiate the disclosure of personal data to entities in that environment. The
philosophy underlying PSSs could be extended to encompass all of a user’s interactions
with digital entities, providing them with a Personal eSpace [15]. A Personal eSpace
would extend into the logical space of the Internet wherever the user goes. It would be
the arena in which they undertake all their computer mediated contact. It would stand
between them and the people and services with whom or with which they make contact.
It would be aware of a user’s history, context and preferences and use them to assess
the contacts they make and the situations in which they find themselves.
Another extension of the PSS paradigm offers a way to meet the future demands of
a particular use of the Internet that has seen a meteoric rise in popularity in recent
years: social networking. We are already witnessing the first tentative steps towards a
convergence between social and pervasive computing. An example of this is Twitter’s
geo-tagging location feature launched in November 2009 [16]. We can expect future
social networking users to demand the context-aware and more highly personalisable
“everyware” services which pervasive systems aim to provide anywhere at any time. In
order to address this demand the SOCIETIES international consortium is being formed
to develop the concept of a Community Smart Space.
Figure 3. Five individuals using their CSSs to form four communities.

A Community Smart Space (CSS) is based on the PSS paradigm and aims to
enable individuals to dynamically form themselves into communities (Figure 3). CSSs
will inherit all of the context, personalisaton, privacy and service management
functionality of PSSs and will bridge the gap between current web-based social
networking and the pervasive next generation of social networking. The context-
awareness of CSSs need not be limited simply to the location-awareness which is
already starting to appear on mobile devices however. The sensor information available
to a CSS can report a host of measurable characteristics about a user’s environment,
health and activities, and relay them to other members of the communities to which
they belong: their work colleagues, medical centre, Twitter followers, Facebook or
MySpace Friends, etc.
In its simplest manifestation, the integration of CSSs with social networks could
permit the online "poke" or "nudge" to morph into an image of the poker appearing on
any kind of display in the poked person’s vicinity to alert them to a contact. More
advanced convergence could unify the two concepts entirely. The people in one’s
social network will be locatable and, if in sight, identifiable, within the limits of the
personal privacy policies of the individuals concerned. People with shared interests are
likely to belong to a common social network group. They are likely to attend the same
events or places of interest and, if at such a place concurrently, CSSs can alert them to
each other’s presence and enable them to meet physically. CSSs will enable people to
leave messages about exhibits, restaurants, etc. which can be picked up automatically
by other CSS community or social network group members who visit the same place at
a later date.
CSSs also promise significant benefits in areas such as disaster management.
Typically, disaster scenes attract diverse teams of international rescue experts, all of
whom have to be briefed and kept up to date on the current situation as it evolves. The
specialist skills of these experts need to be rapidly deployed to appropriate locations as
soon as they become available. The dynamic community formation and management
facilities which become possible via CSSs will enable international rescue teams to
exchange multi-modal information and collaborate with each other and integrate their
efforts with those of the local emergency services to optimal effect.
6. Conclusions
The industry expert group report “Future Internet 2020” [17] published in May 2009
provides a detailed overview on European expectations for the Future Internet in terms
of key research challenges for Europe, key technology enablers, critical blocking points
and recommendations for FI research. Rather than an evolution of the Internet, this
report specifies that “radically new approaches are needed: new architectures; …; new
ways of integrating all the different internet entities – devices, sensors, services, things
and, of course, people” [17].
The Persist project addresses the issue of Personal Smart Spaces intersecting
together and with fixed (e.g. home, office) smart spaces support the FI notion of a
“seamless fabric of classic networks and networked objects”. The innovative PSS
concept demonstrates that this vision of the FI is possible, but raises challenging
technical issues. The most important one, which guides all the architectural choices, is
the requirement for a “natural”, hassle-free interaction with the FI. This is achieved in
PSSs by context awareness and personalisation which permit customized individual
experiences conditional upon situations, preferences and habits. Learning and
reasoning are also employed to reduce the number of questions that the end-user is
required to answer, and the capacity for pro-active behaviour ensures that actions are
initiated on the user’s behalf automatically whenever appropriate. Interoperability is
another requirement that has had a major impact on the design decisions within the PSS
framework. Network interoperability has led to the design of a Network layer based on
peer to peer communication protocols, while the dynamic aspects of pervasive and
mobile communications have led to support for Mobile Ad-hoc Networks. To this end,
issues such as scalability and complexity prove to be among the most challenging. The
PSS architecture has studied several approaches in order to deal with situations where
very high numbers of PSSs interact and share services and data. The evaluation of the
adopted approaches catering for the scalability of PSSs lies among our future plans. On
a higher level, the need to manage a large number of services required modification of
SOA-based architectures and concepts to meet the demands of the mobile realm. To
maximize the perceived usefulness of PSS services, they have been augmented with
semantic metadata that makes it possible for the framework to improve and orchestrate
itself with the most appropriate selection of available PSS services at any given time
and place. Finally, the more pervasive and knowledgeable a system is, the greater the
risks to privacy and disclosure of confidential data. To avoid this, an extensive system
for Identity and Privacy management has been built into the framework and a
negotiation system based on trust assessments ensures that personal data is disclosed in
a controlled and verified manner. The identity management components also provide a
level of accountability that most business models will expect. We believe that all these
features will need to be addressed to formulate and realise the FI vision. Thus, Personal
Smart Spaces can be seen as a significant step towards the grand FI vision, and it is
expected that future research work will build on the presented results by integrating the
PSS concept with social networks and crowd computing.
References
[1] M. Weiser, R. Gold, J.S Brown, The origins of ubiquitous computing research at PARC in the late 1980s,
IBM Systems Journal 38(4) (1999), 693–696.
[2] U. Hansmann, Pervasive Computing: The Mobile Word, Springer-Verlag, Berlin Heidelberg New York
2003.
[3] A. Greenfield, Everyware: the dawning age of ubiquitous computing, Peachpit Press, Berkley USA, 2006.
[4] T. Hoare, R. Milner, The UK Grand Challenges Exercise, Computing Research News 16(4) (2004).
[5] T. Kindberg et al., People, Places, Things: Web Presence for the Real World, 3rd IEEE Workshop on
Mobile Computing Systems and Applications, Monterey, CA, USA, 2000.
[6] C. Prehofer, J. van Gurp, C. di Flora, Towards the Web as a Platform for Ubiquitous Applications in
Smart Spaces, 2nd Workshop on Requirements and Solutions for Pervasive Software Infrastructures at
UBICOMB 2007, Innsbruck, Austria, 2007.
[7] R. Singh, P. Bhargava, S. Kain, State of the art Smart Spaces: Application Models and Software
Infrastructure, ACM Ubiquity 7(37) (2006), 2–9.
[8] G. Abowd, E. Mynatt, Designing for the human experience in smart environments, Smart Environments:
Technology, Protocols, and Applications, Wiley, New Jersey USA, 2005.
[9] R. Krummenacher, T. Strang, Ubiquitous Semantic Spaces, 7th International Conference on Ubiquitous
Computing, Tokyo, Japan, 2005.
[10] M. Coen, et al., Meeting the computational needs of intelligent environments: The Metaglue system, 1st
International Workshop on Managing Interactions in Smart Environments, Dublin, Ireland, 1999.
[11] X. Wang, J. Dong, C. Chin, S. Hettiarachchi, D. Zhang, Semantic Space: An Infrastructure for Smart
Spaces, IEEE Pervasive Computing 3(3) (2004), 32–39.
[12] H. Chen, et al., Intelligent Agents Meet Semantic Web in a Smart Meeting Room, 3rd International
Joint Conference on Autonomous Agents & Multi Agent Systems, New York, USA, 2004.
[13] I. Roussaki, et al., Persist Deliverable D2.5: Revised architecture design, Technical report, Persist
project (FP7-ICT-2007-1), 2009.
[14] K. Frank, et al., A Hybrid Preference Learning and Context Refinement Architecture, Workshop on
Intelligent Pervasive Environments, In conjunction with AISB 2009, Edinburgh, UK, 2009.
[15] N.K. Taylor, Personal eSpace and Personal Smart Spaces, 2nd IEEE International Conference on Self-
Adaptive and Self-Organizing Systems (SASO 2008 Workshop), Venice, Italy, 2008.
[16] I. Paul, Twitter Geotagging: What You Need to Know, Today @ PC World, November 20, 2009.
[17] DG Information Society and Media Directorate for Converged Networks and Service, Future Internet
2020: Visions of an Industry Expert Group, European Commission Report, May 2009.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-205
Scalable Video Coding: Source for Future

Media Internet
Naeem RAMZAN, Toni ZGALJIC, and Ebroul IZQUIERDO
School of Electronic Engineering and Computer Science,
Queen Mary University of London
Abstract. A flexible wavelet-based scalable video coding framework (W-SVC) is

proposed to support future media internet, specifically content delivery to different
display terminals through heterogeneous networks as the Future Internet. Scalable
video bit-stream can easily be adapted to required spatio-temporal resolution and
quality, according to the transmission and user context requirements. This enables
content adaptation and interoperability in Internet networking environment.
Adaptation of the bit-stream is performed in the compressed domain, by discarding
the bit-stream portions that represent higher spatio-temporal resolution and/or
quality than the desired. Thus, the adaptation is of very low complexity.
Furthermore, the embedded structure of a scalable bit-stream provides a natural
solution for protection of the video against transmission errors inherent to content
transmission over Internet. The practical capabilities of the W-SVC are
demonstrated by using the error resilient transmission and surveillance
applications. The experimental result shows that the W-SVC framework provides
effusive flexible architecture with respect to different application in future media
internet.
Keywords. Scalable video coding, wavelet-based video coding, transcoding,

unequal error protection, turbo codes, surveillance centric coding.
Introduction
In recent years, there have been increasing developments in technologies for

transmission of and access to multimedia content over Internet. When video is
delivered to the user it usually needs to traverse network paths with very different
traffic capacities: from very high bandwidth on dedicated glass fibre connections to
very low bit-rate connectivity for wireless transmissions. Furthermore, the same
content needs to be accessible from a variety of devices at the user side, which have
different displaying and computational capabilities [1]. To tackle this challenge, the
compression technology used in the transmission system should ideally provide two
important features; first, it has to be highly efficient in terms of compression and
second, it has to provide flexible, low-complexity, real-time content adaptation to the
network and user’s device properties.
Conventional compression technologies can provide solutions for video adaptation
based either on transcoding [2] or storing and transmitting different instances of the
same content. In the first approach the content is adapted by decoding and re-encoding
using compression settings tailored to the user context parameters, such as available
bandwidth or user-device capability (due to Internet diversity). This process is,
however, computationally expensive and therefore may not meet the requirement for
low-complexity adaptation. The second approach is based on storing and transmitting
206 N. Ramzan et al. / Scalable Video Coding: Source for Future Media Internet
multiple streams encoded with different parameters, where each stream represents an
instance of the same content. Then the stream that most closely matches the user
context parameters is decoded at the user’s side. Here, low computational complexity
of adaptation is ensured, but this approach generally provides inefficient solution in
terms of trade-off between space / bandwidth required to store / transmit multiple
streams and the quality of decoded content [3].
Scalable Video Coding (SVC) [1]-[5] is a relatively recent approach to video
coding [6]-[9], which enables encoding of video content to produce a single scalable
bit-stream that can be seamlessly adapted to network or terminal properties while
providing high compression efficiency. A bit-stream is scalable if it is composed of a
hierarchically embedded family of content instances at different resolution levels. The
underlying multiresolution family of content instances should be embedded in the sense
that when looking at two different instances of the same content at two different
resolution levels, the two representations must match exactly over the extent of the
lowest one. Any instance of the content embraces all representations for lower
resolutions. The representation gets more accurate as the resolution increases. This
allows very low complexity of adaptation as lower resolutions can be extracted from a
higher resolution directly in the compressed domain, thus without performing
computationally expensive transcoding. In addition, for a given resolution the
representation should be good if not optimal. For instance, just attaching a whole high-
resolution version to a low-resolution one does not qualify as hierarchically embedded
content.
SVC also provides a natural solution with a truncateable bit-stream for error-prone
transmissions inherent to Internet. In addition, channel coding methods can be
adaptively used to attach different degrees of protection to different bit-layers
according to their relevance in terms of decoded video quality. Usually, Joint Source
Channel Coding (JSCC) [4] applies different degrees of protection to different portions
of the bit-stream. This means that Unequal Error Protection (UEP) is used according to
the importance of a given portion of the bit-stream. In this context, scalable coding
emerges as the natural choice for highly efficient JSCC with UEP.
The JSCC approach proposed in this chapter performs a joint optimization of a
wavelet-based SVC (W-SVC) and a Forward Error Correction method (FEC) based on
Turbo Codes (TC) [10]-[11] to provide a smooth delivery of video over Internet. The
proposed JSCC [12]-[14] scheme minimizes the reconstructed video distortion at the
decoder subject to a constraint on the overall transmission bit-rate budget. The
minimization is achieved by exploiting the source Rate- Distortion (RD) characteristics
and the statistics of the available codes. Here, the critical problem of estimating the Bit
Error Rate (BER) probability in error prone applications is also discussed. Regarding
the error rate statistics, not only the channel coding rate, but also the interleaver and
packet size for TCs are considered in the proposed approach. The aim is to improve the
overall performance of the underlying JSCC.
In addition to transmission over Internet, SVC is apt for an event driven adaptation
as a potential application for Future Internet. For instance, in surveillance applications,
the scene remains essentially static for seconds and even minutes in some cases. During
these periods of time nothing interesting happens from the surveillance standpoint, and
the video resembles a still picture for long periods of time with no other activity than
random environmental motion. An approach to reduce the bit-rate of the encoded video
segments that are irrelevant from the surveillance standpoint is discussed that enables
increased protection of bit-stream for seamless delivery of video over Internet. This
N. Ramzan et al. / Scalable Video Coding: Source for Future Media Internet 207
approach combines background subtraction and W-SVC. This produces a single

scalable bit-stream that contains segments of video encoded at different qualities
and / or spatio temporal resolutions. The irrelevant segments are encoded using low
resolution / quality while the relevant segments are encoded at high resolution / quality.
The performance evidence of W-SVC in different scenarios i.e. event driven
coding and transmission is demonstrated in this chapter. This chapter starts with the
introduction of W-SVC and its bit-stream organization in section 1. Section 2 explains
the event driven scalable video coding. The joint scalable source and channel coding is
explained in section 3. The conclusion is explained in the last section where it is
envisaged that SVC is the potential candidate for the future media internet.
1. Scalable Video Coding
During the last two decades a significant amount of research has been dedicated to
scalable video coding with the aim of developing the technology that would provide a
low-complexity video adaptation, but retain the comparable compression efficiency and
decoding complexity to those of conventional (non-scalable) video coding systems.
This research evolved from two main branches of conventional video coding: 3D
wavelet [5] and hybrid video coding [6] techniques. Although some of the earlier video
standards, such as H.262 / MPEG-2 [7], H.263+ and MPEG-4 Part 2 [8] included
limited support for scalability, the use of scalability in these solutions came at the
significant increase in the decoder complexity and / or loss in coding efficiency. The
latest video coding standard, H.264 / MPEG-4 AVC [6] provides a fully scalable
extension, SVC, which achieves significant compression gain and complexity reduction
when scalability is sought, compared to the previous video coding standards.
Although a hybrid based technology was chosen for standardisation within MPEG,
a great amount of research continued also on Wavelet-based Scalable Video Coding
(W-SVC). Several recent W-SVC systems (e.g. [5]) have shown a very good
performance in different types of application scenarios, especially when fine granular
quality scalability is required. In the proposed approach a W-SVC [5] framework is
used for source coding and its brief overview is given in the remainder of this section.
The scalability is usually required in three different directions (and their
combinations). We define these directions of scalability as follows:
• Temporal scalability refers to the possibility of reducing the temporal resolution
of encoded video directly from the compressed bit-stream, i.e. number of frames
contained in one second of the video.
• Spatial scalability refers to the possibility of reducing the spatial resolution of
the encoded video directly from the compressed bit-stream, i.e. number of pixels
per spatial region in a video frame.
• Quality scalability, or commonly called SNR (Signal-to-Noise-Ratio) scalability,
or fidelity scalability, refers to the possibility of reducing the quality of the
encoded video. This is achieved by extraction and decoding of coarsely
quantised pixels from the compressed bit-stream.
An example of basic scalabilities is illustrated in Figure 1, which shows a typical
SVC encoding, extraction and decoding chain. The video is encoded at the highest
spatio-temporal resolution and quality. After encoding, the video is organised into a
scalable bit-stream and the associated bit-stream description is created. This description
indicates positions of bit-stream portions that represent various spatio-temporal
Figure 1: A typical scalable video coding chain and types of scalabilities by going to lower-rate decoding.
resolutions and qualities. The encoder is the most complex between the three modules.
The compressed video is adapted to a lower spatio-temporal resolution and / or quality
by the extractor. The extractor simply parses the bit-stream and decides which portions
of the bit-stream to keep and which to discard, according to the input adaptation
parameters. An adapted bit-stream is also scalable and thus it can be fed into the
extractor again, if further adaptation is required. The extractor represents the least
complex part of the chain, as its only role is to provide low-complexity content
adaptation without transcoding. Finally, an adapted bit-stream is sent to the decoder,
which is capable of decoding any adapted scalable video bit-stream.
1.1. High level architecture of the W-SVC framework
A typical W-SVC encoder is shown in Figure 2. First, the input video is subjected to a
Spatio-Temporal (ST) decomposition, which is based on wavelet transform. The
purpose of the decomposition is to decorrelate the input video content and provide the
basis for spatial and temporal scalability. The ST decomposition results in two
distinctive types of data: wavelet coefficients representing the texture information
remaining after the wavelet transform, and motion information (obtained from Motion
Estimation (ME)), which describe spatial displacements between blocks in
neighbouring frames. Although generally, the wavelet transform performs very well in
the task of video content decorrelation, some amount of redundancies still remains
between the wavelet coefficients after the decomposition. Moreover a strong
correlation also exists between motion vectors. For these reasons, further compression
of the texture and motion vectors is performed.
Wavelet
coefficients Scalable texture
Input encoding
video
Bit-stream
ST decomposition & ME organisation Compressed
scalable
bit-stream
Motion
information
Motion
coding
information
Figure 2: A high-level structure of a W-SVC encoder.
Texture coding is performed in conjunction with so-called embedded quantisation (bit-

plane coding) in order to provide the basis for quality scalability. Finally, the resulting
data are mapped into the scalable stream in bit-stream organisation module, which
creates a layered representation of the compressed data that is explained in next
subsection in detail. This layered representation provides the basis for low-complexity
adaptation of the compressed bit-steam, as discussed in the introductory section of this
chapter.
1.1.1. Bit-stream Organisation

In order to achieve efficient layered extraction, scalable video bit-stream consists of
packets of data called atoms. An atom represents the smallest entity that can be added
or removed from the bit-stream. Following such an organisation the extractor simply
discards atoms from the bit-stream that are not required to obtain the video of the
desired spatial resolution, temporal resolution and / or quality. Each atom can be
represented by its coordinates in 3D temporal-spatial-quality space, denoted as
(T, S, Q). The maximum coordinates are denoted as (TM, SM, QM), where TM, SM, QM
represent the number of refinement layers in temporal, spatial and quality directions,
respectively. Except for refinement layers, a basic layer in each direction exists, which
is denoted as zeroth layer and cannot be removed from the bit-stream. If (m, n, i),
m ∈ {0, 1, …, TM}, n ∈ {0, 1, …, SM} and i ∈ {0, 1, …, QM}, represents the desired
temporal resolution, spatial resolution and quality (bit-rate), respectively, then the
atoms with the coordinates T > m, S > n, Q > i are discarded from the bit-stream during
the extraction process. For simplicity we have assumed an equal number of atoms
corresponding to each spatio-temporal resolution. Generally, this is not the case as the
number of atoms corresponding to different spatio-temporal resolutions may be
different. Moreover, the atoms corresponding to different qualities can be truncated at
any byte, in order to achieve fine granular scalability. However, the principle of
extraction remains the same.
2. Event-based Scalable Coding
The basic principle behind the event-based scalable coding is to use different
compression settings for time segments representing events of different importance in a
video sequence. For this purpose the temporal segments of the video sequence are
classified into two types:
• temporal segments representing an essentially static scene (e.g. only random
environmental motion is present – swaying trees, flags moving on the wind,
etc.)
• temporal segments containing non-randomised motion activity (e.g. a vehicle is

moving in a forbidden area).
To enable the above classification, background subtraction and tracking module from
[15] is used as Video Content Analysis (VCA). It uses a mixture of Gaussians to
separate the foreground from the background. Each pixel of a sequence is matched with
each weighted Gaussian of the mixture. If the pixel value is not within 2.5 standard
deviations of any Gaussians representing the background, then the pixel is declared as
the foreground. Since the mixture of Gaussians is adaptive and more than one
Gaussians are allowed to represent the background, this module is able to deal robustly
with light changes, bimodal background like swaying trees and introduction or removal
of objects from the scene. The output of the module defines parameters of compressed
video, which is encoded with the W-SVC framework.
Figure 3: Event-based scalable video encoding framework.
At each time instance the W-SVC encoder communicates with the VCA module, as
shown in Figure 4. When the input video is essentially static the output of the
background subtraction does not contain any foreground pixels. This signal to the W-
SVC encoder to adapt captured video at low spatio-temporal resolution and quality.
This allows, for instance, storing and/or transmitting the portions of the video
containing long, boring, static scenes using low quality frame-rate and spatial
resolution. On the other hand, when some activity in the captured video is detected, the
VCA module notifies the W-SVC encoder to automatically switch its output to a
desired much higher spatio-temporal resolution and quality video. Therefore, decoding
and use of the video at different spatio-temporal resolutions and qualities
corresponding to different events is achieved from a single bit-stream, without
multicasting or complex transcoding. Moreover, additional optional adaptation to lower
bit-rate is also possible without re-encoding the video. This is very useful in cases
where video has to be delivered to a device with a low display capability. Using this
approach, the bit-rate of video portions that are of low interest is kept low while the bit-
rate of important parts is kept high. Since in many realistic applications it can be
expected that large portions of the captured video have no events of interest, the
proposed model leads to significant reduction of resources without jeopardizing the
quality of any off-line event detection module that may be present at the decoder.
Subjective results of the event-based scalable encoding module are presented in
Figure 4. The top-left figure in Fig 4a and Fig 4b shows original frames. The top-right
figure represents the foreground. The bottom row of Fig. 4a shows the reconstructed
sequence whose essentially static segments (no event) were encoded at lower spatial
resolution (bottom-left) or at lower quality (bottom-right). The bottom row of Fig 4b
(event occurs) shows the reconstructed sequence, which is encoded at the original
spatial resolution and higher quality.
Event-based scalable encoding can be used in Future Internet to perform rate-
optimization for transmission and storage according to the event significance in a video
sequence.
3. Bit-stream protection for transmission
SVC provides different bit-layers of different importance with respect to decoded video
resolution or quality as explained in section 1.1.1. Thus, the JSCC can apply UEP
according to the importance of a given portion of the bit-stream. In this context,
scalable coding emerges as the natural choice for highly efficient JSCC with UEP.
The JSCC approach proposed in this chapter exploits the joint optimization of the
wavelet-based SVC and a Forward Error Correction method (FEC) based on Turbo
Codes (TC) [9]. Regarding channel coding, TC are one of the most prominent FEC
techniques having received great attention since their introduction in 1993. Its
popularity is mainly due to its excellent performance at low bit error rates, reasonable
complexity, and versatility for encoding packets with various sizes and rates. In this
research work Double Binary TC (DBTC) [10] is used for FEC rather than
conventional binary TC, as DBTC usually performs better than classical TC in terms of
better convergence for iterative decoding, a large minimum distance and low
computational cost [10].
3.1. System Overview
The proposed framework consists of two main modules as shown in Figure 5: scalable
video encoding and UEP encoding. At the transmitter side, the input video is coded
using the wavelet-based scalable coder. The resulting bit-stream is adapted according to
channel capacities. The adaptation can also be driven by terminal or user requirements
when this information is available. The adapted video stream is then passed to the UEP
encoding module where it is protected against channel errors. Three main sub-modules
make up the UEP encoding part. The first one performs paketisation, interleaver design
and CRC. The second one estimate and allocate bit rates using a rate-distortion
optimization. The last UEP encoding sub-module is the actual DBTC.
After Quadrature Phase Shift Keying (QPSK) modulation, the video signal is
transmitted over a lossy channel. At the receiver side, the inverse process is carried out.
The main processing steps of the decoding are outlined in Figure 5. In this chapter
Additive White Gaussian Noise (AWGN) and Rayleigh fading channels are considered.
However, the proposed method can be equally applied to other lossy channels.
Figure 5: Communication chain for video transmission.
In the proposed JSCC framework DBTC encoding is used for FEC before BPSK/QPSK
modulation. CRC bits are added in the packetisation of DBTC, in order to check the
error status during channel decoding at the receiver side. Effective selection of the
channel coding parameters leads to a minimum overall end to end distortion, i.e.,
maximum system PSNR, at a given channel bit rate. The underlying problem can be
formulated as:
min Ds + c subject to Rs + c ≤ Rmax (1)
max ( PSNR )s + c subject to Rs + c ≤ Rmax (2)
where Rs + c = RSVC / RTC , Ds + c is the expected distortion at decoder, Rs + c is the overall
system rate, RSVC is the rate of the SVC encoded video, RTC is the channel coder rate
and Rmax is the given channel capacity. Here the index notation s + c stands for
combined source-channel information.
The constrained optimization problem (1)-(2) can be solved by applying unconstrained
Lagrangian optimization. Accordingly, JSCC aims at minimizing the following
Lagrangian cost function J s + c :
J s + c = Ds + c + λ ⋅ Rs + c , (3)
with λ as the Lagrangian parameter. In the proposed framework the value of λ is
computed using the method proposed in [11]. Since quality scalability is considered,
Rs + c can be defined as the total bit rate over all quality layers:
QM
Rs + c = ∑ Rs + c ,i . (4)
i =0
To estimate Ds + c in (3), let Ds ,i be the source coding distortion for layer i at the
encoder. Since the wavelet transform is unitary, the energy is supposed to be unaltered
after wavelet transform. Therefore the source coding distortion can be easily obtained
in wavelet domain. Assuming that the enhancement quality layer i is correctly
received, the source channel distortion at the decoder side becomes Ds + c ,i = Ds ,i . On
the other hand, if any error happens in layer i , the bits in this layer and in the higher
layers will be discarded. Therefore, assuming that all layers k , for k < i are correctly
received and the first corrupted layer is k = i , the jointly source-channel distortion at
any layer k = i, i + 1,..., QM at the receiver side becomes Ds + c , k = Ds ,i −1 . Then, the
overall distortion is given by
QM
Ds + c = ∑ pi ⋅ Ds ,i , (5)
i =0
where pi is the probability that the i-th quality layer is corrupted or lost while the j-th
layers are all correctly received for j = 0,1, 2,..., i − 1 . Finally, pi can be formulated as:
⎛ i −1 ⎞
( )
pi = ⎜⎜ ∏ 1 − pl j ⎟⎟ ⋅ pli , (6)
⎝ j =0 ⎠
where pli is the probability of the i-th quality layer being corrupted or lost. pli can be
regarded as the layer loss rate [11].
According to (6) the performance of the system depends on the layer loss rate, which in
turn depends on the DBTC rate, the packet size and the interleaver. Once the channel
condition and the channel rate are determined, the corresponding loss rate pli can be
estimated by applying an iterative algorithm to estimate minimum distance between the
zero code word and any other codeword d min in the DBTC. Assuming that d min is
available, pli can be estimated as:
pli ∝ (1 d min ) (7)
Using (7), pi can be evaluated from (6). As a consequence the problem of finding pi
boils down to find d min that is explained in [11].
3.2. Performance Analysis
The performance of the proposed JSCC [11] framework has been extensively evaluated
using the W-SVC codec. For the proposed JSCC UEP optimal channel rate, packet size
and interleaver for DBTC were estimated and used. as described in this section. The
proposed technique is denoted as “ODBTC”. Two other advanced JSCC techniques
were integrated into the same SVC codec for comparison. The first technique used
serial concatenated convolutional codes of fixed packet size of 768 bytes and pseudo
random interleaver [12]. It is denoted as “SCTC”. The technique using product code
proposed in [13] was used for the second comparison. This product code used Reed
Solomon (RS) code as outer code and Turbo codes as inner code, so it is denoted by
“RS+TC”.
After QPSK modulation, the protected bit-streams were transmitted over error-
prone channels. Both AWGN and Rayleigh fading channels were used in the
experimental evaluation. For each channel emulator, 50 simulation runs were
performed, each using a different error pattern. The decoding bit rates and sequences
for SNR scalability defined in [5] were used in the experimental setting. For the sake of
conciseness the results reported in this section include only certain decoding bit rates
and test sequences: Soccer at CIF (352 × 288) resolution and several frame rates.
Without loss of generality, the t + 2D scenario for W-SVC was used in all reported
experiments. The average PSNR of the decoded video at various BER was taken as
objective distortion measure. The PSNR values were averaged over all decoded frames.
The overall PSNR for a single frame is averaged over all colour components.
A summary of PSNR results is shown in Figure 6 and Figure 7. These results show
that the proposed ODBTC consistently outperforms SCTC, achieving PSNR gains at
all signal to noise ratios ( Eb / N o ) for the AWGN channel. We have observed similar
pattern of PSNR also for the Rayleigh fading channel. For the Sequence soccer up to 3
dB can be gained over SCTC when low Eb / N o , or high channel errors, are considered
for both AWGN channel and Rayleigh fading channel. It can be observed that the
proposed scheme achieves the best performance for different channel conditions. As
the channel errors increase or Eb / N o decrease, a gap between the proposed scheme
and SCTC becomes larger. The performance of RS+TC is almost comparable to
ODBTC, with a slight PSNR degradation in most of the cases. However, it should be
noted that RS+TC uses product code, where a much larger complexity is introduced by
encoding and decoding of the RS codes and TC together.
38 37.5
AWGN Channel Rayleigh fading channel
36 Rs+c = 720 knps 37
Eb/No = 7 dB
36.5
34
PSNR [dB]
PSNR [dB]
36
32
35.5
30
35
ODBTC ODBTC
28 SCTC 34.5 SCTC
RS+TC RS+TC
26 34
0.5 1 1.5 2 600 800 1000 1200 1400 1600
Eb/No [dB] Rs+c [Kbps]
Figure 6: Average PSNR for Soccer CIF Figure 7: PSNR performance of Soccer CIF at
sequence at 30 Hz at different signal to noise 30 Hz at different bit rates.
ratio for AWGN channel.
These results demonstrate that for the considered channel conditions, the proposed
ODBTC consistently outperforms SCTC, achieving PSNR gains at all tested bit-rates.
Specifically, for the Sequence Soccer up to 1 dB can be gained for Rayleigh fading
channel at 7 dB. RS+TC performs better than SCTC: it is comparable to ODBTC.
However, at high SNR, the gap widens up to 0.4 dB. As the error rate probability of
Gilbert-Elliot (GE) is very similar to Rayleigh fading channel as explained in [14].
Hence similar behaviour of the proposed technique can be observed for other channels
like GE. In this chapter, we presented the result of low SNR as this is more critical in
terms of error rate, however quite stable results can be observed at high SNR with the
proposed technique.
Conclusions
In this chapter, practical implementation of scalable video coding with respect to future
media internet was presented. The event-driven scalable video coding is introduced as
the potential application for future internet. The approach reduces the bit-rate for those
temporal segments of a sequence that do not contain important events. Furthermore an
efficient joint scalable source and channel coding scheme elucidated. The rate
optimization of the joint SVC and a forward error correction was proposed. UEP is
used to minimize the end-to end distortion by considering the channel rate at given
channel conditions and limited complexity. The results of simulations show that the
proposed techniques provide comprehensive bit-rate optimisation and a more graceful
pattern of quality degradation that can be a candidate for the future media internet.
References
[1] H. Schwarz, D. Marpe and T. Wiegand, “Overview of the scalable video coding extension of the
H.264 / AVC standard,” IEEE Transactions on Circuits and Systems for Video Technology, Vol. 17, Iss. 9,
pp. 1103 - 1120, September 2007.
[2] I. Ahmad, X. Wei, Y. Sun and Y.-Q. Zhang, “Video transcoding: an overview of various techniques
and research issues,” IEEE Transactions on Multimedia, Vol. 7, Iss. 5, pp. 793 – 804, October 2005.
[3] M. Wien, H. Schwarz and T. Oelbaum, “Performance analysis of SVC,” IEEE Transactions on Circuits
and Systems for Video Technology, Vol. 17, Iss. 9, pp. 1194 – 1203, September 2007.
[4] L. P. Kondi, F. Ishtiaq and A. K. Katsaggelos, “Joint source-channel coding for motion-compensated
DCT-based SNR scalable video,” IEEE Trans. Image Process., vol. 11, no. 9, pp. 1043–1052, Sep. 2002.
[5] M. Mrak, N. Sprljan, T. Zgaljic, N. Ramzan, S. Wan and E. Izquierdo, Performance evidence of
software proposal for Wavelet Video Coding Exploration group, ISO/IEC JTC1/SC29/WG11/
MPEG2006/M13146, 76th MPEG Meeting, Montreux, Switzerland, April 2006.
[6] ITU-T and ISO/IEC JTC 1, Advanced video coding for generic audiovisual services, ITU-T
Recommendation H.264 and ISO/IEC 14496-10 (MPEG-4 AVC).
[7] ITU-T and ISO/IEC JTC 1, Generic coding of moving pictures and associated audio information – Part
2: Video, ITU-T Recommendation H.262 and ISO/IEC 13818-2 (MPEG-2 Video).
[8] ISO/IEC JTC 1, Coding of audio-visual objects – Part 2: Visual, ISO/IEC 14492-2 (MPEG-4 Visual)
[9] C. Berrou and A. Glavieux, “Near-optimum error-correction coding and decoding: Turbo codes,” IEEE
Trans. Commun., vol. 44, no. 10, pp.1261-1271, Oct. 1996.
[10] C. Doulliard and C. Berrou, “Turbo codes with rate-m/(m+1) constituent convolutional codes,” IEEE
Trans. Commun., vol. 53, no. 10, pp 1630-1638, Oct. 2005.
[11] N. Ramzan, S. Wan and E. Izquierdo, “Joint Source-Channel Coding for Wavelet-Based Scalable
Video Transmission Using an Adaptive Turbo Code,” EURASIP Journal on Image and Video Processing,
vol. 2007, Article ID 47517, 12 pages.
[12] B. A. Banister, B. Belzer and T. R. Fischer, "Robust video transmission over binary symmetric
channels with packet erasures", in Proc. Data Compression Conference, DCC2002, pp. 162 - 171, Apr. 2002.
[13] N. Thomos, N. V. Boulgouris and M.G Strintzis, “Wireless image transmission using turbo codes and
optimal unequal error protection”, IEEE Trans. Image Process. Vol. 14, no 11, pp. 1890 – 1901, Nov. 2005.
[14] Hatem Boujemâa, Mimouna Ben Said and Mohamed Siala, “Throughput Performance Of Arq And
Harq I Schemes Over A Two-States Markov Channel Model”, in Proc. of 12 international conference on
Electronics, Circuits, and Systems, Dec. 2005.
[15] C. Stauffer, W. E. L Grimson. “Learning patterns of activity using real-time tracking”, IEEE
Transactions on Pattern Analysis and Machine Intelligence, 22, pp. 747-757, (2000).
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-217
Accelerating Media Business

Developments with the MPEG Extensible
Middleware
Christian TIMMERERa,1, Filippo CHIARIGLIONE b, Marius PREDA c, and Victor
Rodriguez DONCELd
a
Klagenfurt University, Austria / b SmartRM, Italy
c
Institut TELECOM, France / dUniversitat Politècnica de Catalunya, Spain
Abstract. This document provides an overview of the MPEG Extensible

Middleware (MXM), one of ISO/IEC MPEG’s latest achievements, defining an
architecture and corresponding application programming interfaces (APIs) which
enable accelerated media business developments. The paper describes the vision
behind MXM, its architecture, and a high level overview of the API. Additionally,
example MXM applications are given.
Keywords. Middleware, API, MPEG, Media Applications.
Introduction
The development of media business-related applications is currently becoming a very

challenging task due to short deployment cycles and the huge amount of applications
flooding the market (e.g., ‘app stores’). This calls for standardized and platform-
independent application programming interfaces (APIs) for well known media-related
functions (e.g., coding, packaging, storing, delivering) so that they do not have to be re-
implemented each time a new kind of end user device – possible running on a new
platform – emerges on the market. ISO/IEC MPEG working group has recognized this
fact and started the development of an MPEG Extensible Middleware (MXM) [1]
which exactly addresses this issue.
The paper is organized as follows. Section 1 describes the MXM vision on how
media business developments can be accelerated and overviews of the MXM
architecture and its APIs are presented in Section 2 and 3 respectively. A selection of
MXM applications [2][3][4] that have been developed during the course of the MXM
standardization is presented in Section 4. Section 5 concludes the paper.
1. The MXM Vision
With the establishment of the MPEG-21 Multimedia Framework it has been stated that
“every human is potentially an element of a network involving billions of content
1
Corresponding Author. Email: christian.timmerer@itec.uni-klu.ac.at. Phone: +43/463/2700 3621.
218 C. Timmerer et al. / Accelerating Media Business Developments with MXM
providers, value adders, packagers, service providers, resellers, consumers ...” [5]. In
particular, MPEG-21 enables the transaction of Digital Items among Users. The former
is defined as a structured digital object with a standard representation, identification
and metadata whereas the latter may be any kind of creator, end user or intermediary
that makes use of Digital Items in the MPEG-21 framework or interacts with other
Users. Thus, MPEG-21 is a framework covering the complete range of MPEG
technologies defined so far, i.e., from systems (e.g., file formats, delivery formats) to
audio/video codecs (e.g., MPEG-2, MPEG-4, AVC) and description formats (e.g.,
MPEG-7).
However, a framework is almost nothing without a platform on which it can
operate and the Digital Media Project (DMP) [6] specifies one such platform.
Therefore, DMP specifies an interoperable DRM platform (IDP) by adopting most
MPEG-21 technologies and adding a few that were missing [7]. Furthermore, DMP
provides an open source software implementation called Chillout® [8] for the functions
and protocols defined in or referenced by IDP.
One issue when defining a platform is the portability to other platforms which calls
for a middleware to be used in a platform-independent way. That is, the next step is
from platform to middleware which is referred to as MPEG Extensible Middleware
(MXM) [1][9] or MPEG-M, a standard designed to promote the extended use of digital
media content through increased interoperability and accelerated development of
components, solutions and applications. For this regard, MXM introduces the notion of
MXM devices, MXM applications and MXM engines. The MXM standard is organized
in the following parts:
• Part 1: Architecture and technologies [10] provides the definition of the
architecture and technologies (by reference) used within MXM. This will
ensure that MXM devices will be able to run (or play) MXM applications.
• Part 2: MXM API [11] includes normative APIs to so-called MXM engines on
top of which MXM applications can be developed independent of the actual
engine implementations to be used.
• Part 3: Conformance and reference software [12] as open source software.
• Part 4: MXM protocols [13] enabling means for interoperable communication
of MXM devices and, hence, MXM applications.
The advantages of having a normative API to MPEG technologies are the

following. First, there is no need to have in-depth knowledge of specific MPEG
technologies in order to use them. The API provides simple methods to call complex
functionalities inside MXM engines leading to “thin” applications because the
complexity is hidden in the MXM engines. Second, it offers the possibility of replacing
the individual “blocks” (i.e., the MXM Engines) with optimized ones with zero cost for
integration thanks to the normative API. Third, it enables the development of
innovative applications based on multiple MPEG technologies combined in specific
ways. Finally, an infinite number of innovative business models based on MPEG
technologies could be developed at much reduced costs. For example, new applications
can be developed (and deployed) as soon as reference software for a new video codec
becomes available following the normative MXM API. As soon as an optimized
version of this video codec becomes available it can be exchanged with the reference
software without affecting the application running on top of it.
C. Timmerer et al. / Accelerating Media Business Developments with MXM 219
2. The MXM Architecture and Technologies
The "MXM architecture and technologies" [10] specifies the MXM architecture and
references the technologies that are part of an MXM implementation. The architecture
is depicted in Figure 1 and comprises a set of MXM engines for which APIs are
defined on top of which applications can be developed. The current list of MXM
engines includes functionalities for content creation/search, adaptation,
streaming/delivery, domain management, IPMP, rights expression, licensing, metadata,
event reporting, security, etc. A special role takes the Orchestrator Engine which
provides access to higher-level functionalities by implementing common scenarios
utilizing various MXM Engines in a pre-defined way (e.g., adaptation of content
according to the usage context).
Figure 1. The MXM Architecture.

In order to enable interoperable communication between MXM devices the
standard defines MXM protocols as shown in Figure 2. An instantiation example of
various MXM devices communicating with each other is illustrated in Figure 3. Let us
note that only the payload format, which is XML-based, is specified and it may be
actually delivered using any suitable transport protocol (e.g., HTML, Web Services).
Figure 2. MXM Protocols.
Figure 3. MXM Protocol Instantiation Example.
3. The MXM Application Programming Interface (API)
The MXM API [11] of each engine have been divided with respect to the targeted
functionality into creation (e.g., encode a raw audio track, create an MPEG-7 metadata
description), access (e.g., get data from a Digital Item, decode a video), editing (e.g.,
add an elementary stream to a multiplexed content), and engine-specific APIs (e.g.,
authorize a license as part of the REL Engine).
The next sections introduce two selected APIs – Media Framework Engine and
Metadata Engine. For the other APIs the interested reader is referred to [1].
3.1. Media Framework Engine API
The Media Framework Engine API defines a set of APIs related to different media
modalities such as image, audio, video, and graphics. At the time of writing of this
paper it provides means for creating (i.e., encoding) and accessing (i.e., decoding) of
audio, graphics 3D, image and video resources.
The API is organized in a hierarchical fashion where higher levels provide more
generic functions applicable to all types of media (e.g., play, pause, seek) and lower
levels provide specific functions only applicable to certain media types (e.g.,
setVolume for audio or getDecodedImage for image).
3.2. Metadata Engine API
This API can be divided into two parts, one being generic to potentially all kinds of
metadata standards (including those developed outside of MPEG) and one being
specific to MPEG-7 metadata. As for the Media Framework Engine, this API provides
means for creating and accessing metadata. For example, the former could be used by
authoring software to create metadata associated to actual content whereas the latter
could be used for parsing the metadata at the consumption stage.
In particular, the generic metadata creator/parser provides an interface defining the
methods to create/parse generic metadata structures in possibly any format depending
on the specific implementation of the metadata engine of choice. Similarly, the MPEG-
7 creator and parser define methods for creating and parsing metadata structures
compliant to the MPEG-7 standard respectively.
4. Examples of MXM Applications
4.1. Fully Interoperable Streaming of Media Resources in Heterogeneous

Environments
This section describes an MXM-based architecture for the fully interoperable streaming
of media resources (i.e., scalable and non-scalable) in heterogeneous usage
environments (i.e., with different and varying terminal capabilities, network conditions,
and user preferences) [14].
The architecture for this framework is depicted in Figure 4 and in the following we
will give a brief walkthrough.
Figure 4. MXM-based Architecture for a Fully Interoperable Streaming Framework of Media Resources in
Heterogeneous Environments.
• Query for available Digital Items (Steps 1-5): The terminal requests its local
MPEG Query Format (MPQF) engine to issue a query for the available Digital
Items to its counterpart on the server side (1-2). The MPQF engine at the server
examines its repository and responds to the client with a list of available Digital
Items which are presented to the user on the terminal’s display (3-5). In this case
the MPQF is transmitted via HTTP.
• Select Digital Item (Steps 6-13):
The user is now able to select the desired Digital Item she/he wants to
consume. Therefore, the corresponding identifier is provided to the Request
Content / Digital Item Adaptation (DIA) client which also assembles the user
preferences, terminal capabilities, and network conditions into a Usage
Environment Description (UED) and Universal Constraint Description (UCD).
This information is included within the MXM Request Content protocol which
is transmitted via HTTP to the server (6-7). The server responds with an
personalized RTSP URL (8b) which is then used by the Media Streaming
Client in the subsequent stage to initialize the actual streaming session (13).
At the server, the DIA information (i.e., UED and UCD) together with the
Digital Item Identifier (DII) is passed to the Adaptation Decision-Taking
Engine (ADTE) which is used to configure the Adaptation Engine based on
metadata (i.e., AdaptationQoS) associated with the DII (8a-10). The
Adaptation Engine adapts the media resource according to the parameters
provided by the ADTE and forwards the adapted media resource bitstream to
the Media Streaming Server (11-12).
• Streaming of adapted the media resource (Steps 14-16): The Media Streaming
Client requests the adapted media resource bitstream from the Media Streaming
Server via RTSP and the server provides it via RTP (14-15). Finally, the bitstream
is presented to the user at the terminal’s display (16). Optionally it is possible to
update the UED information during streaming (e.g., change in available network
bandwidth) and the corresponding bitstream is adapted during the streaming
session. That is, everything starting from step 6 is repeated in a loop except that a
new RTSP URL is issued (steps 8b, 13, and 14). The updated version of the
adapted media resource bitstreams becomes visible as soon as the client receives
this information as the adaptation is performed in a timely manner.
For further details the interested reader is referred to [14].
4.2. Including MPEG-4 3D Graphics in Third-Party Application
Including audio, image, and video resources (e.g., MP3, AAC, JPEG, MP4) in third-
party applications is nowadays a beginner job. The complexity of such codecs is hidden
behind a very simple communication interface once the content is decoded, i.e., matrix
of pixels for images and wave samples for audio. Transposing the same principle in the
computer graphics world is a challenge due to the variety of representation forms and
also the complexity and heterogeneity of data to be transferred, i.e., vertex
position, normals and tangents, color and texture as well as their variation in time.
The application introduced in this section shows how using the MXM
3DGraphicsEngine and its set of APIs to simplify the complex integration work.
Specifically, with only some lines of code, Ogre3D – a very well known 3D graphics
rendering engine – is transformed into an MPEG-4 3D graphics player.
Ogre3D is a simple and easy to use oriented object interface designed to minimize
the effort required to render 3D scenes, and to be independent of 3D implementation,
i.e., Direct3D/OpenGL. It provides advanced features for object definition and
rendering (mesh, appearance and animation) as well as scene management.
Built on top of VRML97, MPEG-4 contained, already in its first specifications
from ten years ago [15], tools for the compression and streaming of 3D graphics assets,
enabling to describe compactly the geometry and appearance of generic, but static
objects, and also the animation of human-like characters. Since then, MPEG has kept
working on improving its 3D graphics compression toolset and published two editions
of MPEG-4 Part 16, AFX (Animation Framework eXtension) [16], which addresses the
requirements above within a unified and generic framework and provides many more
tools to compress more efficiently generic, textured, animated 3D objects. While the
3D content is a complex data structure involving the coexistence of heterogeneous data
types (geometry, that can be specified as surface or volume, appearance that exposes
material properties and texture and finally animation that can be obtained from a
variety of rigid motion or deformation models), it is relatively easy to specify a
formalism for representing such data. For this reason, there are currently several tons of
formats for describing 3D content. MPEG-4 AFX is not yet another format for
representing 3D data since its key contribution is related to compression more that to
the representation itself. Recent standardization activity formalized in MPEG-4 Part 25
shows how the MPEG-4 tools for compressing 3D assets can be applied to other
formalisms such as COLLADA and X3D. However, in order to make the compression
layer transparent to the application developer, the MXM API transport the information
between the media framework engine and the developed application in a flat format,
very similar to the ones used by Direct3D or OpenGL. Thus after loading an MPEG-4
3D object the engine exposes to the application the corresponding vertex, normal,
texture coordinates buffer and the associated index buffers in a data structure ready for
rendering. Figure 5 shows several MPEG-4 3D objects loaded in the Ogre engine by
using the MXM engine for data decoding.
Figure 5. MPEG-4 3D objects loaded in the Ogre engine.
4.3. Sharing Content in a Smart Way
MXM can be used in a variety of environments and can serve for multiple purposes.
This section describes how MXM is employed by SmartRM (http://www.smartrm.com),
an innovative system for sharing content while retaining control of it.
SmartRM is a viral service based on social networks enabling everyone to share
confidential content with friends or colleagues in a protected way. The SmartRM
software allows its users to convert confidential files (e.g., PDF documents, videos or
audio tracks) into encrypted MPEG-21 files that can be shared with others: only the
contacts that have been enabled can read, view, listen, print, etc. the protected content,
at the conditions that have been specified. The SmartRM service makes it possible to
know when and how many times a protected file has been accessed by someone, as
well as grant or remove permissions dynamically.
The SmartRM system architecture is based on a client-server model. The client is a
Mozilla Firefox plug-in based on MXM [17]. Most of the Web browsers available
today, in fact, are capable of initializing, creating, destroying, and positioning plug-ins
inside the browser window when certain events occur, often through standard APIs
such as NPAPI [18]. Figure 6 shows an example of a high-level architecture of the
SmartRM client software.
Figure 6. High-level architecture of the SmartRM MXM-based Firefox plug-in.

The SmartRM functionalities can be accessed either by code running on an HTML
page (e.g., Javascript) or by other Firefox plug-ins, extensions or components through
an API described in IDL. By relying on MXM, the SmartRM Firefox plug-in delegates
media access and presentation, as well as security-related functionalities to C++ MXM
engines that encapsulate the complexity of those functionalities inside easily-
manageable modules that can be replaced at ease because access to them is made
through the standard MXM APIs.
At the same time, most of the communication between the SmartRM client and the
SmartRM server is done by exchanging ISO/IEC 23006-4 (MXM Protocols) messages
over SOAP and XMPP. Both the client and the server are then relieved from the
complexity of generating, dispatching and interpreting such messages, as this
operations can be done by MXM engines.
4.4. Tracking the Intellectual Property Value Chain
This section describes an MXM-based scenario where intellectual property attribution

and trace of the value chain is put in a first place of importance. MXM is about
handling multimedia, and the content represented by the Digital Items most of the
times representing something that is protected by intellectual property laws. Going
beyond the elementary task of representing who is the copyright owner of this
“something”, MXM also provides engines, devices and protocols to trace the complete
intellectual property value chain, being possible to find out who was the original author,
the adaptors who made derivative works, the performers, the producers or the
distributors or broadcasters who took part in the chain. Moreover, within the MXM
framework it is possible to categorize precisely the kinds of objects subject to the
intellectual property protection, as well as the different actions taken on the Digital
Items which are relevant in regard to the intellectual property.
All of this is accomplished by means of the role verification device, a server
application able to receive notice of the important events for the intellectual property
and answer queries. This server hosts the Media Value Chain Ontology (MVCO) [19],
implementing an API on top of it (the MXM MVCO Engine), and maintains a set of
ontology class instances corresponding to all the relevant users, intellectual property
entities and actions taken, being able to respond to the queries as the result of the
execution of an ontology reasoner.
Figure 7. MXM-based architecture for tracking the intellectual property value chain.
To describe the interoperation of the devices in the presented scenario (see Figure
7), an example is given. In this scenario, the user called Alice creates a content. She
does not merely create a resource, i.e., a Digital Item, she is a creator in the sense that
she makes a new artistic work. Then, by means of the Content Creation Device,
uploads her content to the Content Identification Device (an abstract reference called
work and a first manifestation of the work). The Role Verification Device is also
informed of this novelty, and will keep record of it.
Thus, when another user, called Bob, wants to make an adaptation of that work, he
will need to identify the nature and creator of the work, and manage to get a license
authorizing him to register an adaptation. The license Alice has to issue for this regard,
given by the License Provider Device, can be verified to satisfy the intellectual
property requirements as a check against the role verification device. Perhaps then a
third user called Chang may upload a performance of Bob’s adaptation, and a
distributor called Diana may offer the resulting record for purchase. Thanks to the role
verification device these – and other – actions on the material can be performed
assuming the originator has granted the right to do so and it provides means for
tracking the whole process. For example, the end user Erik may be interested in
knowing the original composer of the work or wants to know which role does Bob play
in this. Additionally, the License Provider Device may verify the conformance of the
licenses issued in the process to the intellectual property model, certifying, for example,
that the performance Chang made took place with the necessary consent of Alice, etc.
5. Conclusions
In this paper we have introduced the MPEG Extensible Middleware enabling

accelerated media business developments by defining a normative APIs to the vast
amount of MPEG technologies currently available (i.e., systems, audio, video, 3D
graphics, metadata, etc.). Thanks to these normative APIs, applications can be
developed on top of these APIs even though the underlying technologies (e.g.,
advanced audio/video codec or delivery format) are still, for example, subject to
standardization and where only proof-of-concept reference software is available. At a
later stage this software can be replaced by optimized one at no cost thanks to the
standardized API. Furthermore, the middleware effectively hides the complexity below
the API and, thus, almost eliminates the burden for newcomers to enter the highly
competitive media business. That is, complex media applications become very tiny and
easy to develop without digging into thousands of pages of various MPEG standards.
Acknowledgments
Although only a few names appear on this paper, this work would not have been possible without the
contribution and encouragement of many people, particularly Leonardo Chiariglione (CEDEO.net), Michael
Eberhard (Klagenfurt University), Ivica Arsov (Institut TELECOM), Angelo Difino (CEDEO.net), and
Wonsuk Lee (ETRI).
References
[1] MPEG Extensible Middleware, http://mxm.wg11.sc29.org/, (last access: January 2010).

[2] M. Eberhard, C. Timmerer, H. Hellwagner, “Fully Interoperable Streaming of Media Resources in
Heterogeneous Environments”, 1st Int’l MXM Developer’s Day, London, UK, June 2009. Available at
http://mxm.wg11.sc29.org/ (last access: January 2010).
[3] I. Arsov, M. Preda, “Including MPEG-4 3D graphics in your application”, 1st Int’l MXM Developer’s
Day, London, UK, June 2009. Available at http://mxm.wg11.sc29.org/ (last access: January 2010).
[4] A. Difino, F. Chiariglione, “An MXM-based application for sharing protected content”, 1st Int’l MXM
Developer’s Day, London, UK, June 2009. Available at http://mxm.wg11.sc29.org/ (last access:
January 2010).
[5] I. Burnett, F. Pereira, R. Van de Walle, R. Koenen (eds.), The MPEG-21 Book, Wiley, 2006.
[6] Digital Media Project, http://www.dmpf.org/, (last access: January 2010).
[7] Digital Media Project, Interoperable DRM Platform v3.2, October 2008.
http://www.dmpf.org/project/ga20/idp-32.html.
[8] Chillout, http://chillout2.dmpf.org/wordpress/, (last access: January 2010).
[9] L. Chiariglione, “The MXM Vision”, 1st Int’l MXM Developer’s Day, London, UK, June 2009.
[10] ISO/IEC 23006-1, Information Technology – MPEG extensible middleware (MXM) – Part 1: MXM
architecture and technologies, Final Committee Draft, London, UK, June 2009.
[11] ISO/IEC 23006-2, Information Technology – MPEG extensible middleware (MXM) – Part 2: MXM API,
Final Committee Draft, London, UK, June 2009.
conformance and reference software, Final Committee Draft, London, UK, June 2009.
protocols, Final Committee Draft, London, UK, June 2009.
[14] M. Eberhard, C. Timmerer, E. Quacchio, and H. Hellwagner, “An Interoperable Streaming Framework
for Scalable Video Coding Based on MPEG-21”, IEEE Wireless Communication, vol. 16, no. 5, pp. 58-
63, October 2009.
[15] ISO/IEC 14496-2, Information technology – Coding of audio-visual objects – Part 2: Visual,
September 2009.
[16] ISO/IEC 14496-16, Information technology – Coding of audio-visual objects – Part 16: Animation
Framework eXtension (AFX), December 2009.
[17] A. Difino, “Use of MXM in a web browser environment”, ISO/IEC JTC1/SC29/WG11/M16836, Xian,
China, Oct 2009.
[18] Netscape Plugin Application Programming Interface (NPAPI), http://en.wikipedia.org/wiki/NPAPI (last
access: January 2010).
[19] V. Rodriguez-Doncel, J. Delgado, “A Media Value Chain Ontology for MPEG-21”, IEEE MultiMedia,
vol. 16, no. 4, pp. 44-51, October 2009.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-227
Towards a Content-Centric Internet

Theodore ZAHARIADISa,1, Petros DARAS b, Jan BOUWENc, Norbert NIEBERTd,
David GRIFFINe, Federico ALVAREZf, Gonzalo CAMARILLOg
a
Synelixis Solutions Ltd, 10 Farmakidou Av., Chalkida, Greece
b
CERH/ITI, Thermi, Thessaloniki, Greece
c
Alcatel-Lucent, Copernicuslaan 50, Antwerp, Belgium
d
Ericsson, Kackertstraße 7-9 52072 Aachen, Germany
e
University College London, Gower Street, London, UK
f
Universidad Politécnica de Madrid, Madrid, Spain
g
Ericsson, Hirsalantie 11, Jorvas 02420, Finland
Abstract. In most cases, current Internet architecture treats content and services
simply as bits of data transported between end-systems. While this relatively
simple model of operation had clear benefits when users interacted with well-
known servers, the recent evolution of the way the Internet is used makes it
necessary to create a new model of interaction between entities representing
content. In this paper we study the limitations of current Internet and propose a
new model, where the smallest addressable unit is a content object, regardless of
its location.
Keywords. Content-Centric Internet, Content Networks, Internet Architecture
Introduction
The Internet as we know it today is heavily based on a model that interconnects

interfaces of end-hosts – both servers and user devices – that are usually identified by
IP addresses. The wealth of information and applications we enjoy today is all hosted
on computers and invisible to the basic operation of the Internet, which treats content
and services simply as bits of data transported between end systems. While this
relatively simple model of operation had clear benefits in the early days of the Internet
when users interacted with well-known servers using services such as file transfer or
remote terminal access, the recent evolution of the way the Internet is used makes it
necessary to create a higher level platform for the interaction with digital entities
representing content of all kinds – to make a Content-Centric Internet (CCI) rather than
today’s computer-centric one. In a CCI the content is addressable, regardless of its
location. In the following, we will study current Internet's limitations, analyse the
benefits of a CCI approach, and provide the design principles and the requirements of a
Content Centric Internet architecture.
1
Corresponding Author: Theodore Zahariadis, Synelixis Solutions Ltd, 10 Farmakidou Av. GR 34100,
Chalkida, Greece; Email: zahariad@synelixis.com
228 T. Zahariadis et al. / Towards a Content-Centric Internet
1. Limitations of the Current Internet Architecture
Today, the vast majority of the Internet usage concerns content and services discovery
& retrieval, content delivery and streaming and Web services access. The user cares
only about the content or service itself and proper delivery, while he/she is oblivious to
their location. That is, the user knows that he/she wants news from the BBC, videos
from YouTube or weather information, concrete and delivered in suitable quality and
format, but does not know or cares on which machine the desired data or service
resides, as soon as reliability, security and privacy are guaranteed. This functionality is
realised by the current Internet Architecture as shown in Figure 1. It consists of the
following types of nodes:
a) Content Servers or Caches,
b) Centralised, decentralised or clustered Servers, including Search Engines and
Supporting Servers (e.g. DNS servers, AAA servers, DRM servers, etc.),
c) Core and edge Routers and Residential Gateways (represented as R1 to R5) and
d) Users, connected via fixed, wireless or mobile terminals.
Figure 1. Today’s Network Architecture, Content Discovery, Retrieval and Streaming

The initial step is Content Discovery by the Search Engines: the Search Engines crawl
the Internet or inspect the routed packets to find, classify and index content or services.
Alternatively, users may publish content and manually inform the search engine. The
second step is Content Discovery by the User: if the user does not know where the
content resides, she queries a Search Engine and gets as feedback a number of URLs,
where the content is stored. The last step is Content Delivery/Streaming: the user
selects a URL and the content is delivered or streamed to her/him. Alternatively, in
case of live communications services (e.g. VoIP or video conference), User A and User
B are communicating using their IP addresses as reference.
In the scenario shown in Figure 1 if both User A (UA) and User B (UB) ask for the
same content to the same Search Engine, they will both get as an answer that the
content is stored at Content Server 1 (CS1). The above schema works for current
applications and usage, and will continue to do so provided there is sufficient resource
in the system to deliver it. “Resource” may mean bandwidth capacity in a given link or
it may mean the capacity to route a packet of data with a sufficiently low delay.
But what happens as billions of devices become connected? When users demand
image resolutions in video that require bandwidths greater than can be supported over
T. Zahariadis et al. / Towards a Content-Centric Internet 229
the typical link lengths? If more and more users conduct delay-critical real-time video
and audio communications using the Internet? These changes will only be supported in
the current Internet through massive investment, and even then the architecture may
exhibit unstable characteristics. An intelligent evolution of the Internet architecture will
lead to much more efficient use of the available resource (bandwidth, routing capacity)
and provide a business environment that encourages investment. However some
changes to this schema would make better use of the available resources. For example:
a) if content could be stored/cached closer to the end users, not only at the end-
points as local proxies, but transparently in the network (routers, servers, nodes,
data centres) then content delivery would have been much more efficient,
b) if routers could identify/analyse what content is flowing through them, the
search engines would gain much better knowledge of (even the streaming)
content location and provide information even on “live” video streams,
c) if the network could identify what is the best path to the user (less congestion,
lower delay, more bandwidth), it could provide a better way to deliver data
d) if content could be selected and adapted to the context, the user would have a
much easier life e.g. when entering a living room, a phone TV session could
transfer to the big screen and adapt to the resolution offered there.
2. From Content to Services to Media Experiences
In the debate about the shape of future Internet, three powerful concepts drift to the
surface, vying for attention: User, Service and Content. Each of the three presents itself
as a powerful force that is able to explain recent evolution and that claims the right to
drive the future Internet. The user-centric perspective emphasises the end-user
experience as the driving force for all technological innovation, observing how today
the Internet is a network of active social users rather than a connection of devices. The
service-centric view has roots in both enterprise IT solutions and the Web 2.0 mash-up
culture, showing how valuable applications can be built faster and more efficiently if
service components can be reused in flexible ways. The content-centric view refers to
the central role that rich media content is playing in attracting users to Internet services,
as content consumers are increasingly also as content producers, and how the transfer
of media content can impact the network operation. As the three views are emphasising
different aspects rather than expressing opposing statements, merging or homogenizing
towards an encompassing perspective may help towards the right design choices for a
future Internet.
To satisfy user experience, a content-centric Internet will depend on the realisation
of a set of content-specific services. In this way, the content-centric perspective adds
new service components to the service-centric view. Content-centric services include
content distribution networking for both on-demand and live media distribution,
content publishing, discovery, adaptation and processing services, DRM services,
conferencing services, media annotation, indexing and search services. Figure 2 shows
the interrelations between the different components. In more details, we may define:
x Infrastructure (both private and public) will consist of transport, storage and
processing functions in a distributed manner. This cloud offers the opportunity
to deal with active content objects, rather than unstructured bitstreams.
x Content is any type and volume of raw information that can be combined,
mixed or aggregated to generate new content and media. Content may be pre-
recorded, cached or live, static or dynamic, monolithic or modular.
x Information is the product of a number of functions applied to the content or
recursively to the information. By combining, mining, aggregating content and
pieces of information, new information may be extracted or generated.
x Service is the result of a set of functions applied to the content, to pieces of
information or recursively to services. By (manually or automatically)
handling, managing, combining, personalising, adapting content, information
or services, new services may be composed or generated.
x Security and Privacy will be a property of content, information, services and
Infrastructure, allowing much more efficient control over content objects.
x User/Media experience encompasses all aspects of the end-user's interaction
with the services and the Media. True user experience goes far beyond giving
customers what they say they want, or providing checklist features.
Figure 2. Future Content-Centric Internet components interrelation
2.1. Impact of the User-Centric Perspective

Taking the end-user with his/her needs and desires as the initiating force for the design
of the Future Internet and the applications it will support, we consider the following
requirements that will have an impact on the Service/Media layer:
x The end-user is the endpoint, rather than his/her device. Users should be able to
easily find each other and engage in interactions, even if they use multiple devices
in parallel without falling in the trap of limiting the user to one single identity.
x Universal accessibility for services with user experience; various users will
approach the offered services with different levels of competency, and this level
will evolve over time as they make use of the service.
x Universal accessibility for content generation; users already act as content
producers, implying that if a Service-Centric network offers components for end-
user experience creation, they should be usable by all users.
x If the network is enhanced with a certain intelligence to optimize the user
experience, this should not lead to a feeling of loss of control with the user,
dealing with an unpredictable environment.
2.2. Impact of the Service-Centric Perspective

Although the Internet is supporting a wide variety of applications, several functional
building blocks are common between large groups of applications. The Service-Centric
perspective therefore argues that it makes sense to design a network environment that
supports the flexible creation, publishing, discovery and use of common service
components. Flexibility here refers to easy location-independent detection and
invocation of service components. Just-in-time inclusion of service components – i.e. at
the moment of the creation of the end-user experience – allows optimization of network
services and supports rapid innovation. The common service components that are
typically listed include user identification, authentication and authorization, security
and DRM, bandwidth management, storage, power management, payment, location
and time context information, user activity, content adaptation, search and indexing
functions. Some of these – user authentication and authorization, content adaptation to
devices and user context – can be seen as driven by the User-Centric perspective.
2.3. Impact of the Content-Centric Perspective

The Content-Centric perspective highlights the driving role that rich multimedia
content has played and is expected to play in the growth of the Internet, in terms of
usage and traffic. The web has become a true Media Web, and the volume of
transferred content will continue to rise sharply, as the quality of the media content
further increases (High-Definition and Ultra High-Definition Content, 3D and
stereoscopic content, multi-view content etc), as more experience of content becomes
active and social and as more users evolve from mere consumers to active creators
and/or repurposes of content. The Media Web is furthermore evolving to a Real-Time
Media Web with live content streams and multimedia person-to-person or group
communication. This can be a separate application experience or it can be embedded in
frame experiences like gaming, education and users collaboration.
Figure 3. The convergence of three different perspectives
To satisfy user experience, a Content-Centric Internet will depend on the

realisation of a set of content-specific network services. In this way, the Content-
Centric perspective adds new service components to the Service-Centric view -
indispensable for media experiences, or emphasises already identified ones. Content-
Centric services include content distribution networking for both on-demand and live
media distribution, content publishing, discovery, adaptation and processing services,

DRM services, conferencing services, media annotation, indexing and search services.
Figure 3 schematically depicts the convergence of the three different, yet
complementary perspectives.
3. The Concept of Content Objects
Currently, media content is the result of an off-line, cumbersome and lengthy creation
process, whereby content components are composed into a meaningful and appealing
presentation. The distribution over the network for consumption is then the transfer of
the finalised complete media presentation in the form of bit streams, followed by a
play-out at the end-user’s device. The key concepts for the Service-Centric perspective
as explained above are the identification and separation of meaningful service
components and the just-in-time on-the-fly flexible integration of such components into
an application experience. It is expected that this evolution for software and network
functions will also take place for rich media, i.e. that media experiences will be created
as the just-in-time composition of content component objects that are easily located,
synchronised, reused and composed.
Such an approach can already be discerned in virtual world applications where
users contribute to the content creation: the virtual world representation on the end-
user’s device is the composition of objects that have been created by various authors
and are fetched as they are required for representation. Figure 4 represents a possible
mixed-reality scene for a person-to-person interaction, combining stored and live media
objects from a multitude of sources and engagement of many senses.
Flower made by Jeff

Live 3D video stream from 3D scan
of Versailles chateau
Interpolated stream Free table model
from camera array from Ikea.com
Ann
String quartet
remix by DJ Tamino
Live video of
Jeff’s face
textured on
head model
Captured
hand’s
gestures Jeff
Stylish clothes
from
clothesmodels.com
Figure 4. On the fly generation/reconstruction of semantically enriched worlds
The availability of the constituent content objects and their spatial and temporal
relationships, rather than an opaque stream of pixels and audio samples, opens up new
opportunities for content creation and consumption:
x Re-use of components from existing content for the creation of new audio-visual
content becomes much less cumbersome, allowing fast and easy media mash-ups.
x On-line collaborative audio-visual content creation.
x Personalisation enters a new stage, evolving from a selection of prepared content

to a just-in-time composition.
x The insertion of stored audio-visual content into real-time communication is
greatly facilitated.
x The combination of captured audio-visual content with synthetic 3D content
creates exciting mixed-reality experiences.
x The possibility for the user to actively intervene and mould content components
through natural, non-verbal interfaces enhances the experience and provides
authoring capabilities to the users, e.g. by enabling them to reshape, personalize,
and re-experience in unique ways audiovisual content, including layered metadata.
3.1. A forward-looking alternative for content objects
The classic layered approach may not be the ideal match for the content object
vision: the advanced content treatment service functions that are required may exhibit
characteristics that differ substantially from the non-content-driven service
components, leading to the definition of service components that are positioned in a
blurred area between content, service and user layers. An alternative is a clean-slate
approach for the network design, starting from the content object itself, a content-
centric network architecture, the Autonomic Layer-Less Object Architecture
(ALLOA). In Figure 4, we have already introduced the concept of content objects,
which can ad-hoc, on the fly generate/reconstruct semantically enriched 3D augmented/
virtual worlds in order to create an orchestrated immersive media experience. Here we
further expand this concept to “Content Objects”. A Content Object is an autonomous,
polymorphic/holistic container, which may consist of media, rules, behaviour,
relations and characteristics or any combination of the above.
x Media are the actual content pixels. It can be anything that a human can perceive/
experience with his/her senses (a dancing person, the second violin in a
symphonic performance, a tear on your cheek).
x Rules can refer to the way an object is treated and manipulated by other objects or
the environment (discovered, retrieved, casted, adapted, delivered, transformed,
and presented). Rules can for instance be used to specify if the media in the object
would allow rescaling and that it would accept a delivery delay of 2 seconds, but
that it should certainly arrive for presentation at the end-user side before a child
object: the object knows its purpose in the integrated media experience and
therefore its priority for transfer. Also the options for manipulation by the end-
user at the moment of presentation could be included.
x Behaviour can refer to the way the object affects other objects or the environment.
x Relations between an object with other objects can refer to time, space, and
synchronisation issues. Relations could for instance describe that an audio object
of a singing person is related to an animated 3D model of the singer and that lip
synchronisation is required.
x Characteristics meaningfully describe the object and allow retrieval of its related
objects: user interaction with a ‘coq-au-vin’ object may visualise in the immersive
3D environment the ingredients and their current prices or may lead to the ad-hoc
building of 3D replicas of the restaurants where the dish is available.
Objects can be hierarchically organised, like the constituting instrument channels

of a music band, and can trigger the generation of new objects. An object can be
divided/ spit into new objects or multiple objects can be combined/merged and finally
create new objects, and these operations may happen while objects are “travelling”
over the network.
An object can be cloned. The clone keeps the characteristics of its “parent” object
but knows that it is a clone. This is also associated with issues like cashing (object
lifetime, check for updates) and Digital Rights Management (DRM). The cloning has
implications in the opening of novel business models around “actively experience
audiovisual content”: for example, the same audiovisual content can be distributed with
different characteristics: for example for a music, ranging from a simple MP3 file to a
more complex music content in which the user has authoring capabilities to reshape the
music piece, thanks to the availability of further metadata and higher level
representations enabling this user a number of degrees of freedom in real-time, e.g. in
terms of re-orchestrating the music, re-arranging (post-production), shared (social)
active fruition.
The autonomous objects will travel over the network, split and combine to
generate the new service or a virtual world object. The Future Content Centric Internet
will support the content objects in order to meet their relations.
An example of a content object is shown in Figure 5. We can assume that “Barbie”
is a Content Object mash-up. It consists of different other basic objects E.g. It has
“skin”. The “skin” is a content object, which has different colours or textures. It has
hair. The “hair” is a content-object, which has different colour, length, style. It has
“eyes”. The “eyes” is a content-object, which has different colour, length, style,
shadows. It wears “cloths” and carries “accessories”. Both “cloths” and “accessories”
are components mash-ups, which may change based on the time, context (school, dace,
gym), emotions. What really differentiates this example from today’s technologies is
that any digital object may be decomposed or composed into Content Objects: the
environment, the cars, the buildings, the things, etc., generating in real–time new
content in the same sense that SOA may support service mash-ups.
Figure 5. A Barbie Content Object

Another potential use of the Content Object approach can be seen in Figure 6,
where a user simply sketches (in two-dimensions) the scene of interest. Each individual
item of the sketch can be thought as a Content Object, which contains all the
information that characterises it. Thus, each Content Object can serve as an
autonomous rich item, containing both low-level and high-level features. Similar 3D
objects (to each 2D sketched item) are then automatically retrieved from the CCN and
placed in a 3D environment which can also be a Content Object.
Figure 6. From user generated 2D sketches to 3D worlds

It is currently very difficult to imagine what a network architecture that support objects
would look like. An attempt to map the characteristics of the layered approach which is
depicted in Figure 2 into the novel “layer-less” concept of the object is shown in the
Figure 7, where one or more layers are mapped to one or more entities of the object.
Figure 7. Mapping a layer-based Content-Centric Internet Architecture into “Objects”

More specifically, transfer and integration of objects for the purpose of the creation of
an orchestrated “Media” experience clearly demands intelligence that combines
application (“Service/Media”) and “Content” information. The intelligence could be
embedded in the objects themselves, retrieving information from the network and
providing instructions for routing and transformation, or the intelligence could be
hosted in network nodes that attempt to satisfy the requests of the objects as they are
described in the ”Rules”, “Behaviours” and “Relationships” (which take input from the
“Information/Adaptation”, “Content” and “Infrastructure” layers). Finally, the
“Characteristics” that meaningfully describe an object take, mainly, input from the
“Information/Adaptation” layer.
4. Conclusions
We believe that in order to achieve the vision of a future Internet fully suited to future
users’ needs, several aspects need to be considered. Among others, network structure
complexity vs. engineering design simplicity, scaling vs. delivering quality and
response time, efficiency vs. user friendliness, services and content location, user and
network mobility, societal aspects and issues of trust and security, just to name a few.
Moreover, the decision on following a revolutionary or a clean-slate approach is
heavily under discussion. Yet, an incremental approach starting from a Virtualised
Network towards Content Object Mash-ups is a possible scenario.
Figure 8. Research and Deployment for Future Content Centric Internet
5. Acknowledgements
This work is based on discussions carried out by a selected group of experts from the
Future Content Networks session of the Future Internet Assembly (FIA) and expresses
authors’ opinion. Yet, the authors would like to acknowledge input from a number of
documents mainly generated from the Future Media Internet (FMI) Task Force, the
Media Delivery Platforms (MDP) and the User-Centric Media (UCM) clusters and
selected projects, RFCs and other studies. Part of this paper has been discussed in the
EU funded projects COAST, ENVISION, I-Search and nextMEDIA.
References
[1] R. Bush, D. Meyer, “Some Internet Architectural Guidelines and Philosophy,” RFC 3439, Dec. 2002
[2] W. Willinger, J. Doyle, "Robustness and the Internet: Design and evolution”, 2002,
http://www.maoz.com/~dmm/complexity_and_the_internet/robustness_internet_design_ evolution.pdf
[3] Future Media and 3D Internet Task Force, “Future Internet and NGN: Design requirements and
principles for a Future Media and 3D Internet,” Networked Media Unit, February 2009
[4] D. Clark, J. Wroclawski, K. Sollins, R. and Braden: Tussle in Cyberspace: Defining Tomorrow's
Internet, 2002 Conference on Applications, Technologies, Architectures, and Protocols For Computer
Communications, SIGCOMM '02, (2002), New York, NY, 347-356
[5] Future Content Networks Group, “Why do we need a Content-Centric Internet? Proposals towards
Content-Centric Internet Architectures,” White paper. 2009
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-237
Efficient Streaming in Future Internet

Theodore ZAHARIADISa,1,Christos KATSIGIANNISb,Ahola JARIc,Roberta FRACCHIAd
Janne VEHKAPERAc, Federico ALVAREZe, Thierry FILOCHEf, Harilaos KOUMARASg
a
Synelixis Solutions Ltd, 10 Farmakidou Av, Chalkida, Greece
b
National Technical University of Athens, Greece
c
VTT, P.O. Box 1000, FI-02044, Finland
d
THALES, 160 Valmy, 92704 Colombes, France
e
Universidad Politécnica de Madrid, Madrid, Spain
f
Thomson, Colombes, France
g
NCSR Demokritos, Agia Paraskevi Athens, Greece
Abstract. The Future Internet is not envisaged to be simply a faster way to go

online. What is expected to fundamentally change the way that people use the
Internet is the ability to produce, and seamlessly deliver and share their own
multimedia content. In this paper, we introduce and analyse innovative
architecture components to offer media scalable content delivery, increasing the
robustness, enriching the PQoS and protecting the content from unauthorized
access over heterogeneous physical architecture and P2P logical overlay network
topologies. Technology pillars in which the system is based are described: i.e.
Multi-layered/Multi-viewed content coding, Multi-source/multi-network streaming
& adaptation, content protection and lightweight asset management.
Keywords. Multi-layered/Multi-viewed content coding, SVC/MVC, MDC, Multi-

source/multi-network streaming & adaptation
Introduction
The Future Internet is expected to fundamentally change the way that people use the
Internet: i.e. the ability to produce, and seamlessly deliver and share their own
multimedia content. We expect that in a few years everyone will be multimedia content
producer (by publishing digital pictures, video recordings, smart home surveillance,
etc.), multimedia content mediator (by storing/forwarding streaming content) and
multimedia content consumer (digital television, video on demand, mobile
broadcasting and alike). In this context, we consider the Future Internet as a dynamic
and distributed environment, which enables new services and seamless, scalable and
trusted multimedia content delivery, increasing the robustness and resiliency, enriching
the PQoS both within the network and/or at the end-user terminal.
The first step to introduce seamless content distribution is to take advantage of the
sufficient uplink capacity that most access technologies typically offer. Individuals may
operate as content creators and service providers by distributing their personal content
including but not limited to video streams. Moreover, novel “follow me” like services
may be introduced, where the home-based equipment may operate as service mediator
1
Corresponding Author: Theodore Zahariadis, Synelixis Solutions Ltd, 10 Farmakidou Av. GR 34100,
Chalkida, Greece; Email: zahariad@synelixis.com or zahariad@teihal.gr
238 T. Zahariadis et al. / Efficient Streaming in Future Internet
and content forwarder and a subscriber may consume personalised streaming services,
properly adapted to network characteristics/conditions and his mobile phone/PDA
capabilities, while on the move.
However, the major envisaged potential of the Future Internet is shown in Figure 1
by introducing trusted Peer-to-Peer (P2P) overlay topologies and cloud computing in
the broadband, heterogeneous architecture. This is also compatible with the increasing
and expanding WiFi community networks architectures. In this case, services may be
offered not only by centrally located media streaming servers, but by groups of end-
user devices, acting as distributed content repositories. Given content protection and
management is in place, network operators and service providers may offer value-
added streaming services with remarkable PQoS, while avoiding the nightmare of
network scaling and the expenses in network infrastructure upgrades, as the content (at
least the most popular one) and the network resources (traffic load) may be distributed
and thus balanced to a large number of peers. Moreover, individuals may produce their
own (real-time) content and make it publicly available to a larger audience, without
having to rely on a specific, expensive networking infrastructure. In this environment,
video streaming scalability, resilience and PQoS may be exponentially increased, as not
only multiple-networks, but also multiple-sources may stream video segments,
enriching the content on-the-fly either at the network and/or at the end-user terminal.
Figure 1: The proposed Future Internet logical network architecture

In order to realize the above service provisioning scenarios, a number of issues
have to be considered and tackled. Advanced scalable and multiview video coding,
knowledge of the network conditions, innovative cross layer optimization, real-time
service adaptation, on-the fly PQoS enrichment, content protection are some of the
issues that have to be solved. In this paper, we highlight and analyse the main pillars
and introduce technologies and solutions that could be applied in the envisaged
seamless content delivery in the Future Internet network evolution. The work is mainly
based on the outcomes of the projects OPTIMIX2 and SEA3.
2
The OPTIMIX project (INFSO-ICT-214625) focuses on studying innovative solutions enabling
enhanced video streaming in an IP based wireless heterogeneous system, based on cross layer adaptation of
the whole transmission chain.
3
The SEA project (INFSO-ICT-214063) offers a new experience of seamless video delivery,
maintaining the integrity and, wherever applicable, adapting and enriching the quality of the media.
T. Zahariadis et al. / Efficient Streaming in Future Internet 239
1. Proposed Network Architecture Innovations
Advanced coding schemes like Scalable Video Coding (SVC), Multi-View Coding
(MVC), Multi-Description Coding (MDC) will facilitate video distribution with
enriched QoS, especially in case of high-end multi-modal terminals able to receive and
reconstruct multiple video streams segments (i.e. layers, views, descriptions). However,
home terminals or low-cost mobile terminals may be only capable for decoding at a
particular bit-rate or may be only feasible to correctly display up to a particular image
resolution. Thus, in order to meet all proposed innovative features, the media delivery
service architecture should be content aware and have knowledge of the access
technologies as well as to the utilised end-user device capabilities and characteristics.
The Future Internet network architecture has to provide the relative adaptation
functionalities to seamlessly support the majority of terminals. It should be able to
support terminal mobility, including service continuity, between different (radio)
access technologies, or maintaining and supporting the same capabilities of access
control (authentication, authorization), privacy and charging when moving between
different (radio) access technologies. IP service continuity should be maintained, i.e.
the network should hide the impact of mobility events to the end user and the IP
application(s), i.e. the service can continue without user intervention or special
application support to mask the effects of a mobility event.
Figure 2: Proposed Content Delivery Network Architecture

In case of building a service architecture upon the described variety of access
networks, it is desirable to have as much information and adaptation at the lower layers
(up to the network layer) as possible, along with scalability functionality coming with
the media codec. Certain functions such as content caching in the network, content
adaptation and cross-layer optimization would certainly need knowledge of the
network conditions/characteristics. In order to overcome this problem, wherever
applicable in the proposed Future Internet architecture, we introduce intelligent media/
network aware entities. These could be new nodes of the foreseen network architecture
or enhanced nodes for new network installations. In the first case, we propose two
MANE types: a) streaming Home Media Gateway (sHMG), located at the edge of the
extended home environment and b) streaming Network Media Gateway (sNMG). The
sNMG could form a layered approach, while the sHMG could be considered as end
nodes. Figure 2 summarizes these considerations, while Figure 3 provides a mapping of
these MANE nodes to the 3GPP Service Architecture Evolution (SAE) network
topology.
Figure 3: Mapping of proposed MANE to the SAE architecture

The proposed MANE nodes will support the intelligent, seamless content
distribution. They will offer functions like network and terminal awareness, content
enrichment and content protection. In the longer term, they may be integrated on
Internet Multimedia Systems (IMS) as define by ETSI TISPAN. They will offer
multimedia storage, dynamic content adaptation and enriched PQoS by dynamically
combining multiple multimedia content layers from various sources. Moreover, as they
will have knowledge of the underlined networks, they will provide information on the
network conditions/characteristics, which will be utilised by the Cross Layer Control
(CLC) mechanism and adapt the multimedia streams to the next network in the delivery
path. This will be extremely important in case of a low bandwidth, but guaranteed QoS
mobile networks and in the broadband, but best effort P2P topologies.
2. Key Technology Pillars and Trends
For the introduction of novel services and new business models, including efficient,
resilient, enriched Perceived QoS (PQoS) and seamless content delivery over the future
Internet, apart from the network architecture, we expect that key-content pillars should
be introduced. Some of them are summarized in this section:
x Multi-layered/Multi-view personalised content coding. In order to maximize
video portability, scalability and error resilience across a number of
heterogeneous terminals, we propose the H.264 Scalable Video Coding (SVC) as
the major encoding standard. The concept of Multi View Coding (MVC) is to
allow for different views of video streaming without drastically increasing the
data rate for the media delivery.
x Multiple Description Coding (MDC). Future Internet should provide for inherited
mechanisms for resilient content distribution. One method that could be applied is
the Multi Desription Coding (MDC) approach.
x P2P video streaming. The Future Internet should address P2P challenging topics
including: a) peer retrieval optimization and b) application of proper coding
techniques. Another important topic will be the distribution of multiple views

over a P2P overlay and optimization of the visual quality and PQoS via
exploitation of advanced source coding techniques (SVC, MVC, MDC).
x Cross Layer Control (CLC) and Optimisation. Existing CLC provide
significant improvements in the PQoS under specific networking and transmission
conditions. However, none is directly applicable to the Future Internet concept, as
the terminal will not necessarily know the actual physical layer infrastructure.
Especially in the case of P2P topologies, the physical infrastructure may even be
an arbitrary, timely varying combination of links belonging to different networks.
3. Cross Layer Signaling Architecture for Adaptive Transmission
The Future Internet should be able to provide seamless media delivery within
heterogeneous networks and terminals with dynamic scalability across the whole
delivery chain. Local adaptation within a single system layer has proven not to be the
most efficient way to achieve dynamic scalability. At the same time, cross-layer
adaptation and controlling among different layers has been studied very extensively
recently and it has proven to give better performance and better adaptivity than the
traditional techniques. However, these studies quite commonly neglect the delivery and
signaling of cross-layer information within and between entities. An efficient signaling
architecture is crucial for the success of cross-layer adaptation and controlling and due
to these issues, we propose an end-to-end architecture for cross-layer signaling.
3.1. The OPTIMIX Cross Layer Solution
The cross-layer and end-to-end signalling solution used in OPTIMIX system is

based on Triggering Framework introduced in [1]. In this architecture, the triggering
framework is used for transferring cross-layer signals both locally, that is, between
entities located on the different layers of the local protocol stack, and remotely,
between entities in different network nodes (i.e. the mobile station, the server, and the
base station). Together with the IEEE 802.21, Media Independent Handover (MIH)
Services, standard, it provides an end-to-end solution for cross-layer signalling. This
architecture is illustrated in Figure 4 and more detailed description of the proposed
architecture is given in the following sections.
Figure 4: OPTIMIX Cross-layer Signalling Architecture

3.1.1. Low-level cross-layer signaling - IEEE 802.21

The IEEE 802.21 working group has published the first standard to facilitate
heterogeneous handovers in January 2009. It provides three main services - command
service, information service, and event service - to collect information from links and
networks in range, and to initiate IEEE 802.21 assisted seamless network changes.
Despite the main target of the standard, the provided services offer usage also beyond
handovers, which are capitalized on and experimented in our architecture. For instance,
event service enables receiving timely and consistent information about current link
conditions. This information can be used, for instance, to trigger mechanisms to
accommodate the current video stream to the varying link conditions, without
executing a handover in the first place after the video quality start degrading.
The main entity of IEEE 802.21 framework [2] is called MIH Function (MIHF),
which interfaces with the local link layers and MIH User (MIHU). MIHU is a common
name for an entity having all logic and intelligent related to the usage of the
information available through IEEE 802.21. IEEE 802.21 allows peer-MIHF entities to
register with each other and exchange messages using MIH protocol. This way, for
instance, MIHF on a Base Station ( BS) can subscribe for a particular set of events
from the Mobile Stations (MSs) it is affiliated with and monitor the link conditions of
each MS separately. This is the main usage of IEEE 802.21 in our signaling
architecture; to provide timely low layer events from MSs to BSs in a lightweight and
fast way over Layer-2 communication. Since upper layer events (Layer-3 and above)
and end-to-end communication are out of scope of IEEE 802.21, IEEE 802.21 does not
contend with Triggering Framework in the architecture but collaborates [3].
3.1.2. Signaling between network elements - Triggering Framework

The central functional element of Triggering Framework is Triggering Engine
(TRG) that manages the cross-layer signalling between the different entities. The
strength of TRG is in its generic nature: the TRG offers generic socket or SOAP based
interfaces for the collection and dissemination of cross-layer information and formats
the information as triggers with a predetermined but flexible structure: ID, type, and
value. Each trigger can be identified through a unique ID that also defines its source,
that is, the entity that produced it (e.g. the video streaming application, L3 mobility
management software, or a WLAN NIC). The different triggers produced by one
source can be differentiated based on the type field of the trigger. Finally, the actual
cross-layer information is carried in the value field. The structure of the value field is
not fixed by TRG specification, and it thus can be used for carrying virtually any kind
of feedback information that is useful for the trigger consumers within the system.
In addition to its role as a trigger collector and distributor, TRG provides trigger
management and processing services in terms of access control, trigger filtering, and
temporary storage for the triggers. Besides these operations, TRG remains agnostic to
the contents of the triggers and additional entities need to be introduced into the system
to perform more advanced trigger processing functions such as the trigger aggregation.
Our signalling system uses the cascaded TRGs feature of Triggering Framework
[4] to enable end-to-end signalling. TRG cascading means that TRG running in a
network node is capable of receiving triggers from TRGs located in other nodes of the
system. The video streaming server is thus capable of receiving feedback information
from all remote streaming clients connected to it via Triggering Framework. In this
type of remote triggering, the triggers coming from different nodes are distinguished
based on; for example, the IP addresses of the source nodes.
3.1.3. Cross-layer feedback messages and data aggregation

Although Triggering Framework allows using filters (to limit the value range of
interest) in the subscriptions, the feedback message exchange will cause overhead for
the total network traffic. The amount of message exchange could easily become
enormous if each information source (e.g. streaming application, mobility manager
software) will send a trigger every time something changes in the status of the source
and especially when numbers of clients with similar functionalities will do the same. In
order to mitigate the feedback overhead, we have developed a client-side aggregation
mechanism for Triggering Framework. The proposed trigger aggregation bundles
multiple triggers into a single trigger, which is periodically sent to the consumers
subscribed to it. Aggregated triggers enable trigger consumers to subscribe triggers of
their high interest with strict filters and still get information about the values of these
triggers periodically. For example, the Network Media Gateway can subscribe to a
single aggregated trigger which includes information from the application, transport
and physical layers of an MS and use this for adaptation purposes.
3.2. The SEA Cross Layer Solution
The cross-layer and end-to-end signalling solution used in SEA system is based on
MPEG-21 approach [5]. However, signalling has been adapted to follow the IETF
(SDP [6] and RTSP [7]) approach. Taking into account the SEA architecture, the SEA
network nodes and the final terminal capabilities (ranging form laptops to mobile
phones) [8], within SEA we adopt a general adaptation network architecture as shown
in Figure 5. In this view, we assume that in the path from the Content Provider
(including content prosumers) to the terminal, we may have N+1 Adaptation Engines
(AE). Each engine is responsible for adapting the video stream to the next network in
the path i.e. AEi adapts the video stream to the characteristics/capabilities of Network i,
always taking into account the final terminal capabilities and user requirements.
Figure 5: SEA Adaptation network architecture

As the adaptation options may be limited, some adaptation engines may perform
stream adaptation, or some of them may just forward (relay) network, streaming,
terminal or user characteristics to the next AE along the connection path. It is important
to note however, that the last adaptation engine will also have the responsibility to
terminate the adaptation in case the terminal is not able to handle it. For example in
case of P2P streaming, the terminal may not be able to handle the required extended
buffering and streaming reconstruction, and this functionality may be handled by the
Last Node AE (AEL). For simplicity reasons, we’ll assume that the AEL will always
terminate the adaptation process, reconstruct the streamed video according to the
terminal needs, and then stream the re-constructed video to the terminal4. Moreover,
the AEL will be responsible for streaming A/V content optimised for the end-user’s
terminal and access connection. Taking into account the above architecture we may
summarize a number of scenarios, as follows.
The architecture of Figure 5 is further analysed in Cross Layer Adaptation and
Control functional nodes as shown in Figure 6. It has to be noted, that the AEL which is
the Adaptation Engine of the Last Node, while the SEA Media Node may be realised/
instantiated as either a sNMG or a sHMG node.
Peer Nodes Peer Nodes Peer Nodes
CSM CSM CSM
CSM AEM AEM AEM AEM
ADM ADM ADM ADM

CSM
NAM NAM NAM NAM NAM TAM
Content Provider SEA Media Node SEA Media Node In the network NAM Terminal
(optional)
A/V Stream Application Signalling SDP signalling or MPEG-21 metadata
Figure 6: Cross Layer Modules communication
The major CLC nodes in SEA are the Adaptation Decision Module (ADM) and the
Adaptation Execution Module (AEM), which offer the following functionality:
Ͳ Adaptation Decision Module (ADM): This module is able to decide if and what
adaptation has to take place. Based on a multi-criteria decision framework, and
network and terminal capabilities sensing, ADM will allow tuning of the
encoding/streaming parameters, optimizing the end-to-end rate, the distortion
image quality and the resilience strategies at the application layer, as well as
information regarding the connecting terminals.
Ͳ Adaptation Execution Module (AEM). This module is the context aware
module, which actually performs the A/V handling. AEM functions include
dropping or combining SVC layers or MVC views and initiating MDC
distribution over different paths.
The ADM and the AEM modules will be located on all intelligent SEA Media
Nodes i.e. the Content Provider node, the sHMG, the sNMG and the terminal. It should
be noted that the “Content Provider” maybe a professional content provider; however
user generated content is going to be the wide majority in the future scenarios. Thus,
content provider may be considered as the initial content server, supported by a P2P
4
In case the terminal is able to handle the adaptation process itself, we can assume that the AEL is
collocated at the terminal.
network. Additionally, based on the business model, the ownership of the nodes and
the capabilities of the terminal, three supporting entities may also be defined:
Ͳ Content Storage Module (CSM). This module is utilised to store or cache the
A/V content segments (layers, views, descriptions). It may act as an A/V server
or a peer node in a P2P environment supporting on-the fly content enrichment.
Ͳ Network Awareness Module (NAM): This module has knowledge of the
physical characteristics of the network (multiple access, QoS classes, coverage).
Moreover, it may be able to measure or probe network parameters e.g. number of
users, available bandwidth, etc. This module may be located at all intelligent
SEA nodes. Moreover, it may be optionally located in the network, providing
additional information which is directly retrieved by the network nodes.
Ͳ Terminal Awareness Module (TAM): This module is located at the user
terminal and has knowledge of the physical characteristics of the terminal
(display, network interfaces, processing power, decoding capabilities). Moreover,
it may be able to measure parameters at the terminal e.g. CPU load, battery life,
free storage space, and network conditions e.g. SNR, BER, etc.
3.2.1. The SEA adaptation engine architecture

Within SEA we assume that the received stream may be SVC (base layer with or
without enhanced layers), MVC (with a number of views), MDC encoding different
types of video (e.g. SVC base layer, MVC), P2P video chucks (either used as transport
where P2P is unaware of the video format that it is carrying or the P2P network is
aware and gives different priorities to the different chunks) and a number of their
combination. Thus, a more detailed view of the Adaptation Engine is shown in Figure 7.
ServerorAEnͲ1 sHMG/sNMG orAEn TerminalorAEn+1
P2P P2P P2P
SVC SVC SVC

MDC MDC
MVC MVC MVC
MDC AdaptationExecution MDC

AEM AEM
in Module in
RTSP RTSP RTSP RTSP

Server Client Server Client
ADM ADM
AdaptationDecisionModule
NAM NAM NAM TAM NAM
MPEG21 DIA metadata/IETF compliant optional param P2P Video Streaming

MPEG21 UCD/UED SVC Video Streaming
RTSP Session SDP/ IETF compliant streaming MVC Video Streaming
VLC_VAR i/f MDC Video Streaming
Figure 7. Adaptation Engine Architecture

As shown in Figure 7, in a first layer the NAM/TAM modules provide input to the
ADM module. In a second layer, the ADM modules communicate horizontally to
exchange information and make decisions. It is important to note that each ADM is
making a decision for the network that will follow, while in VoD cases this information
is propagated to the ADM modules that are closer to the Video Server. In a third level,
the ADM communicates with the AEM to perform the content adaptation.
4. Conclusions
In this paper, we have introduced and analysed two innovative approaches (OPTIMIX
and SEA) to offer media scalable content delivery, increasing the robustness and
enriching the PQoS over heterogeneous physical architecture and P2P logical overlay
network topologies. The OPTIMIX approach faces the problem in a more general
network centric approach, while the SEA approach a more service oriented approach.
Yet, the combination should be considered as an evolutionary step towards Future
Media Internet.
5. Acknowledgment
This publication presented the authors opinion. Yet, it is based on work performed
in the framework of the Media Delivery Platform (MDP) and the projects SEA
P2PNext, ADAMANTIUM, COAST, nextMedia and OPTIMIX.
References
[1] J. Mäkelä and K. Pentikousis: Trigger Management Mechanisms, Proc. of the IEEE International
Symposium on Wireless Pervasive Computing ( ISWPC'07), 5-7 February 2007, San Juan, Puerto Rico.
[2] IEEE 802.21 WG. IEEE Standard for Local and Metropolitan Area Networks. Part 21: Media
Independent Handover Services. IEEE Std 802.21-2008, 2009
[3] E. Piri, T. Sutinen, J. Vehkaperä. Cross-layer Architecture for Adaptive Real-time Multimedia in
Heterogeneous Network Environment. In Proc. European Wireless 2009, May 2009, Aalborg, Denmark
[4] M. Luoto and T. Sutinen: Cross-layer Enhanced Mobility Management in Heterogeneous Networks. In
Proc. of the International Conference on Communications, Beijing, China, May 2008.
[5] MPEG-21, Digital Item Adaptation, FCD, ISO/IEC JTCI/SG29/WG11 N5845, 2005
[6] M. Handly, V. Jacobson and C.Perkins, “SDP: Session Description Protocol”, IETF RFC 4566, July
2006, http://tools.ietf.org/html/rfc4566
[7] H. Schulzrinne, A. Rao, R. Lanphier: "Real Time Streaming Protocol (RTSP)", IETF RFC 2326, April
1998, http://tools.ietf.org/html/rfc2326
[8] SEA consortium, “D4.1: Cross layer control, adaptation modelling and metadata specification,” 30
September 2008, http://www.ist-sea.eu/Public/SEA_D4.1_SYN_FF_20080930.pdf
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-247
The SENSEI Real World Internet

Architecture
Vlasios Tsiatsis a,1, Alexander Gluhak b, Tim Bauge c, Frederic Montagut d,Jesus
Bernat e, Martin Bauer f, Claudia Villalonga g, d, Payam Barnaghi b, Srdjan Krco h
a
Ericsson Research, Ericsson AB, b University of Surrey, UK, c Thales Research and
Technology, d SAP AG, Switzerland, e Telefonica I+D, f NEC Europe Ltd., gETH Zurich,
h
Ericsson d.o.o., vlasios.tsiatsis@ericsson.com, a.gluhak@surrey.ac.uk,
timothy.bauge@thalesgroup.com, frederic.montagut@sap.com, bernat@tid.es,
martin.bauer@nw.neclab.eu, claudia.villalonga@sap.com, p.barnaghi@surrey.ac.uk,
Srdjan.krco@ericsson.com
Abstract. The integration of the physical world into the digital world is an
important requirement for a Future Internet, as an increasing number of services
and applications are relying on real world information and interaction capabilities.
Sensor and actuator networks (SAN) are the current means of interacting with the
real world although most of the current deployments represent closed vertically
integrated solutions. In this paper we present an architecture that enables efficient
integration of these heterogeneous and distributed SAN islands into a
homogeneous framework for real world information and interactions, contributing
to a horizontal reuse of the deployed infrastructure across a variety of application
domains. We present the main concepts, their relationships and the proposed real
world resource based architecture. Finally, we outline an initial implementation of
the architecture based on the current Internet and web technologies.
Keywords. Real World Internet, Sensor and Actuator Networks, Resource,

Resource Discovery, Context-awareness
1. Introduction
Internetworking physical world objects and integrating them into the network of
the future is one of the most important aspects of a Future Internet [7]. The objective of
our research is to enable this real world dimension of future networking. Wireless
Sensor and Actuator Networks (WS&ANs)[6], ubiquitously deployed at the edges of
the networks, will provide an infrastructure that enables the augmentation of the
physical world and interaction with it, without the need for direct human intervention.
Sensing interactions are concerned with capturing information about the state of the
physical world and making it available as contextual information at different levels of
granularity. This information can be further augmented and processed by the core
infrastructure before being delivered to interested consumer endpoints. Actuation
interactions, on the other hand, enable actions upon the real world that may have a
1
Vlasios Tsiatsis, Ericsson Research, Ericsson AB, Faeroegatan 6, SE-16480, Stockholm, Sweden
248 V. Tsiatsis et al. / The SENSEI Real World Internet Architecture
direct or indirect impact on the physical state of the real world objects which can range
from simple activations to complex control loops.
In this paper we present the architecture [2][4] of a framework designed to enable
efficient integration of smart objects, which has been developed as part of the European
ICT-FP7 SENSEI [10] project. Building on top of the communication service layers of
the current or future Internet, our architecture weaves heterogeneous SAN and
processing resources into a homogeneous resource fabric, enabling an open market
space for real world context and interaction. The underlying design principles of our
architecture [1] are heavily influenced by service oriented architecture [9], the REST
architectural style [3] and evolutionary design [8].
Our contribution is the adaptation of these principles and the synthesis of these
concepts into a coherent architecture. Another contribution described in this paper is
the realisation of the architecture, which includes the specification and design of a set
of key enabling services and an initial implementation of those based on current
Internet and web technologies.
1.1. Key Innovations
The proposed architecture offers basic sensor, actuator and processing services
with which a user can access sensor data, control actuators or process raw sensor data.
This is done by a user contacting directly a communication endpoint locator or address
(e.g. an IP address) for a sensor, actuator or processing element. For users that do not
have these communication endpoint locators the proposed framework offers discovery
services of varying type of sophistication. The simple discovery services in our
framework are not different from other relevant systems such as the Open Geospatial
Consortium (OGC) SWE [15] (e.g. Sensor Observation Service). However, our
framework builds on these primitive types of services to offer advanced discovery
services as well as context and actuation management services by providing an
abstraction level corresponding to the real world consisting of Real World Entities or
Entities of Interest (EoI). An EoI represents an element of the real world such as a
person, place or object. These entities are linked to sensor or processing services that
provide information about the real world. Similar models are introduced to allow
sophisticated actuation tasks and control loops on top of primitive sensor, actuator and
processing services. Given the fact that such context services and actuation tasks can
include sophisticated processing of sensor data and actuation commands that is not
always known at the time of the user request, SENSEI offers architectural support for
dynamic service composition. The semantically-rich models and descriptions of
sensors, actuators and processing elements are designed to enable machine processing
that facilitates the dynamic composition and instantiation of new services. To the best
of our knowledge the context model, context services, actuation tasks and dynamic
service composition of both primitive and advanced services is the first of its kind for
the realization of the Real World Internet.
A comprehensive Authentication, Authorisation and Accounting (AAA) solution
has been specifically designed to provide more efficient access to WS&AN resources
than possible with existing approaches.
In today’s mobile networking environment, one cannot exclude the possibility of
the providers of context or control services of being mobile. Mobility of sensors and
actuators is an assumption that a framework such as the one described in this paper
V. Tsiatsis et al. / The SENSEI Real World Internet Architecture 249
factored in the framework architecture. As a result, our framework offers an innovative

mobility management mechanism residing in a higher layer than the network mobility
management and operates in a complementary fashion.
2. Architecture Overview
2.1. High level overview
On a high level the SENSEI architecture follows a layered model with three major
horizontal layers, as shown in Figure 1(a). It extends the Internet architecture by adding
a (Real World) Resource Layer on top of the Communication Service Layer, which
forms the connectivity substrate of the current or Future Internet. The Resource Layer
encompasses all necessary functions that facilitate the interaction of applications and
services with the Real World Resources. The concept of the Resource is central to the
proposed architecture as it provides a unifying abstraction for simple devices such as
sensors, actuators, processors or software components (e.g. data fusion). Apart from the
Resources, the Resource Layer encompasses Support services that enable discovery,
composition and dynamic creation of Resources and support long term interactions
(sessions). Furthermore it includes a set of functions that provide identity management
for all entities in the system, consumer and provider account handling, privacy and
security features summarized as the Community Management.
)
Figure 1 : High level overview of the SENSEI Architecture and SENSEI core concepts
The separation between a Resource Layer and the Communication Services Layer
allows mapping of the Communication Services Layer either to a connectivity substrate
based on the evolution of the current Internet for near-term deployment or to a more
revolutionary clean slate design of the underlying network infrastructure.
On the Application Layer multiple diverse applications and services gain unified
access to real world information and interaction capabilities via interfaces provided by
the Resource Layer. The Resource Layer also aims to support system management
applications in a unified manner. As a result the Resource layer enables
horizontalisation through the reuse of constrained devices such as sensors or actuators
by a multiple different types of applications.
This paper introduces the resource concept and focuses specifically on the support
services. For information on other aspects of the architecture readers can refer to [16].
2.2. The resource concept
The resource concept lies at the heart of our architecture [2][4]. Resources provide
capabilities such as sensing, actuation, processing of context and sensor data or
actuation loops, and management information concerning sensor/actuator nodes,
gateway devices or entire collections of those that form a common administrative
domain.
Figure 1 (b) provides an overview of the key concepts that relate to the resource
concept. A resource has an embodiment in the physical world, the Resource, which
could be sensor, actuator a processing component, or a combination of these. A
Resource End Point (REP) is the software process which implements one or more
Resource Access Interfaces (RAIs) to the resource. A Resource Access Interface is
used by a user (referred to as Resource User or RU) to access the services that a
resource provides (e.g. sensor data, actuator commands). A REP is uniquely
addressable within the real world resource layer. Differentiation between, REP and
resource and the roles of REP host and Resource host allows a separation of concern
between different required mechanisms in the architecture. The device hosting a
resource is referred to as the resource host. A REP host is a device that executes the
software process representing the REP. Resources may be associated with one or more
Real World Entities (e.g. person, place or objects) for which they can either provide
information or for provide control over their surrounding environment.
3. Support Services
3.1. Resource layer components
The Support Services are depicted in Figure 2. For simplicity we depict the REP as
being inside the Resource. Resource Users are typically context-aware applications that
require real world information, applications that require real world actuation,
management applications that are used for the management of one or more WS&ANs,
or composite Resources that make use of other Resources. A Resource User interacts
with a Resource via the Resource endpoint (REP) using the Resource Access Interface
(RAI) [11].
The Resource Directory implements a loosely coupled rendezvous mechanism
between Resource Users and Resources. In order to be discoverable by Resource Users
in the Resource Layer, a Resource must be registered with the Resource Directory [2].
Using the Resource Publication Interface (RPI), the Resource Publication function (RP),
that the resource provider controls, registers one or more Resources with the Resource
Directory. This information is maintained for lookup within a structured Resource
repository. Using the Resource Lookup Interface (RLI), Resource Users can interact
with the Resource Lookup function to discover Resources of interest in the Resource
Layer.
The Entity Directory maintains the associations and dependencies between Real-
World Entities and Resources. The Entity Directory complements the Resource
Directory in that the focus of the Resource Directory is on Resources themselves while
the Entity Directory focuses on Entities. To be discoverable through the Entity Lookup
Interface (ELI), a link between a Real World Entity and a Resource has to be registered
using the Entity Publication Interface (EPI) through the Entity Publication function
(EP) [11].
Figure 2 : Support Services in the Resource Layer Architecture

The Semantic Query Resolver receives queries from Users interested in particular
Resources or Entities of Interest. High level declarative queries can be submitted via
the Semantic Query Interface (SQI). These queries are analysed by the Query Analysis
function and decomposed in (a set of) Resources and a corresponding execution plan
with the help of the Task Planning function. An Abstract Task Plan Database can store
templates to assist this process. The Semantic Query Resolver builds on the
information available in the Resource Directory and uses the RLI interface for
interactions.
In the case that no adequate Resource exists to answer a high level query of a
Resource User, the Semantic Query Resolver can trigger the Dynamic Resource
Creator to create the required Resource via the Resource Creation Interface (RCI) on
the fly. A Dynamic Resource Creation function creates a new Resource that may be
based on available Resources in the system and components (e.g. algorithms) from the
Component Database. The newly created Resource is instantiated and deployed by the
Resource Deployment function at a Resource Host using the Resource Deployment
Interface (RDI). At the same time a new REP is also instantiated. The host registers the
newly created Resource with the Resource Directory and the associated Real World
Entity to the Entity Directory through the RP and the EP, respectively.
The functions of the execution management system component are implemented
by the Execution Manager [11]. Using the Request Execution Interface (REI), the
Semantic Query Resolver can invoke the Execution Manager to process requests for
real world context and actuation tasks. A Request Management function keeps track of
incoming queries and invokes appropriate Resources. Additionally, it can set up
sessions between Resource Users and Resources using the RAI in case of long lasting
requests (e.g. events). In this case, the Session Monitoring performs the adequate
adaptation when resource availability changes in the system.
3.2. System Interactions
To illustrate the operation of the system, this section provides a brief description of
some example use cases with the required system interactions. The system architecture
supports a wide range of different resource users with different requirements. It
provides support at design time and, more importantly, at runtime.
In the basic scenario, resource users need to interact with a fixed set of known
resources. These resource users assume a rather static setting with stationary sensor and
actuator resources. This fits the more traditional setting where applications are directly
deployed on top of wireless sensor networks. Here, the system supports the developer
to find the required resources through Resource Directory (Figure 3, 1.1). The RAI
description provides the required information for implementing the client-side. At
runtime, the resource user directly interacts with the required resources (Figure 3, x.2)
and the system only provides support functionalities such as authentication,
authorisation, and accounting.
Figure 3 : Basic System Interactions

In cases where resources are mobile, their point of attachment to the network can
change. This means that the REP locator through which they are reachable changes;
however the resource identifiers remain unchanged. Whenever the network attachment
changes, the resource host updates the REP locator information in the resource
description stored at the Resource Directory. Using the resource identifier, resource
users can look up the current REP locator of resource in the Resource Directory at
runtime (Figure 3, 2.1) and interact with it as before (Figure 3, x.2). This is similar to
the use of the Home Location Register in GSM, where information about the current
attachment of a mobile phone is updated and can be looked up [13].
The system also supports cases where the set of resources is not known at design
time, but has to be determined at runtime. For example, this is needed when the
resource user is utilising a mobile device and needs to interact with available resources
in its respective environment that provide the required information - which we expect
to be a common case when we achieve our goal of horizontalisation. In this case the
lookup functionality is utilised for discovering the required resources. In the basic
scenario, the Resource Directory is queried for resources of interest (Figure 3, 3.1). To
query a resource, users can submit a set of tags that are matched against the tags
provided in the resource descriptions.
Resource users that are designed to operate across heterogeneous environments do
not need to know the details of all resources in the different environments. For these
resource users it is advantageous to specify what information they require or what
actuation task they need to execute rather than having to know how this information is
provided by different resources or how certain actuator resources execute an actuation
task. The Semantic Query Resolver allows resource users to issue declarative requests
specifying what context or sensor information is required or what actuation task is to be
executed (Figure 4, 4.1). The Semantic Query Resolver then analyzes the request and
finds resources that can be used to satisfy the request. In the planning step, the
Semantic Query Resolver creates an execution plan. If all required resources do not
exist, it is checked whether the Dynamic Resource Creator can create them (Figure 4,
x.2, x.3); otherwise the request cannot be executed. Finally, the information about the
required resource(s) can be returned to the resource user.
Figure 4 : Advanced System Interactions
In the described case, it would still be up to the resource user to interact with the
resources directly for executing the request (Figure 4, 4.4). Alternatively, the Execution
Manager can execute the request on behalf of the resource users (Figure 4, 5.4, 5.5).
This simplifies the writing of high-level applications as they do not have to deal with
the execution of the request itself.
In the simple one-time request scenario, the Execution Manager directly executes
the request and returns the information. In the long-term subscription scenario, the
Execution Manager sets up sessions [14] between the resources and the resource user
according to the execution plan (Figure 4, 6.5). This separation of control and data flow
leads to a more scalable system. The Execution Manager only handles the control
aspects, whereas the data flow happens directly between the resources and resource
users (Figure 4, 6.6) and thus it is completely decentralised.
For long-term requests, important aspects for the request execution may change
over time, e.g., resources become unavailable, new resources become available,
resources are no longer suitable because resource or resource user are mobile and have
moved. It is important to ensure the continuity of information provisioning and
actuation task execution in such cases. The Execution Manager allows setting up the
monitoring of these aspects. If a relevant change is detected, the re-planning of the
request by the Semantic Query Resolver is triggered. If these results are in a changed
execution plan, the request execution will be changed without the need for an
intervention of the resource user.
4. Realisation on the Current Internet
In this section we briefly describe a realisation of the SENSEI architecture which

makes use of the existing web technologies to implement the main service functions of
the architecture. The implementation is based on a RESTful design [3] using the
RESTlet framework [5]. Each component is available as a REST resource on the web,
identifiable by a unique URI and accessible through the HTTP protocol main
primitives: GET, POST, PUT, DELETE that allow manipulation of the resource (get
information about the resource, set or update the resource parameters or delete
resource).
The first version of the implementation illustrates simple scenarios of the Resource
Layer using a set of heterogeneous resources, framework components involving the
Semantic Query Resolver, the Entity Directory, the Resource Directory and resource
users as depicted in Figure 5. The resources represent a mix of native SENSEI
WS&AN islands, legacy WS&ANs and mobile phone based gateway:
• A 6LowPAN enabled sensor network represents a native SENSEI WS&AN. Each
sensor node is able to directly host an end-point (i.e. REP) for the resource it
provides. End-to-end transparent access is enabled with the implementation of
Binary Web Service protocol. This uses Efficient XML Interchange (EXI)
encoding to compress the exchanged messages for efficient transfer through the
WSN.
• A WS&AN island based on ZigBee protocol stack is used as a legacy type of
resource. We enhanced a Zigbee gateway to host a Resource End Point for each
available Zigbee sensor and provide resource and Entity Publication functionality.
• An Android phone served as an example of a mobile platform, hosting a Resource
End Point for its built-in sensors.
• A context processing server hosted composite processing resources that were able
to combine input form multiple Resource End Points to provide higher layer
context information.
Context aware applications, acting as resource users, are implemented on an

application server, which provides a browser based access interface to fixed and mobile
clients.
Figure 5 : Setup of test deployment

A typical interaction in the setup involved a context aware application issuing a
semantic query to the Semantic Query Resolver. Upon receipt of a request, the query is
analysed and the relevant Real World Entity is identified. The Semantic Query
Resolver looks up the Entity Directory in order to retrieve the Resource associated with
the latter Entity of Interest. The Resource Directory is then queried to retrieve the URI
of the relevant resource. The latter information is finally sent back to the client who can
in turn invoke the adequate resource.
5. Conclusions and Outlook
This paper presents the design and initial implementation of an architecture that
provides the enabling foundation of a Real World Internet. The architecture has been
developed as a part of a large co-ordinated effort in Europe to create an underlying
architecture and corresponding services for the Future Networked Society. The
architecture provides the necessary functionality to enable a range of services for
accessing sensor data, actuator and processing commands as well as offering context
management for real world entities. Our architecture being the results of both technical
and business-oriented research enables a Real World information marketplace and the
creation of a business ecosystem around Real World Services.
We have demonstrated the feasibility of the Real World Internet concept and an
initial realisation of the key architectural components in lab deployments. The work is
ongoing to enhance the existing components, complete the implementation of the
architecture with new components and evaluate the presented architecture and its
services on larger scale. For this purpose a PAN European testbed is currently being
created, integrating heterogeneous sensor and actuator networks across the facilities of
19 partners, including sensor network testbed deployments from ISSNIP, an affiliated
Australian research network.
Acknowledgment
This paper describes work undertaken in the context of the SENSEI project,
Integrating the Physical with the Digital World of the Network of the Future
(www.sensei-project.eu). SENSEI is a Large Scale Collaborative Project supported by
the European 7th Framework Programme, contract number: 215923.
References
[1] A. Gluhak and M. Bauer and M. Johansson and J. Bernat and V. Stirbu and F. Montagut and M. Presser.
Towards an Architecture for a Real World Internet, “Towards the Future Internet – A European
Research perspective. IOS Press, 2009.
[2] F. Carrez (Editor), T. D.3.2 –Reference Architecture. SENSEI, Public Deliverable D.3.2, 2009,
http://www.sensei-project.eu/.
[3] R. T. Fielding, and R. N. Taylor, Principled design of the modern Web architecture. ACM Trans.
Internet Technol., 2(2):115--150, 2002.
[4] T. Bauge (Editor), D.3.3 - Components for End-to-End Networking, Management and Security and
Accounting. SENSEI, Public Deliverable D.3.3, 2009, http://www.sensei-project.eu/.
[5] RESTlet framework. http://www.restlet.org/.
[6] I. F. Akyildiz,, W. Su, Y. Sankarasubramaniam, and E. Cayirci. Wireless sensor networks: a survey.
Comput. Netw., 38(4):393--422, 2002.
[7] D. Clark, C. Partridge, R. Braden, B. Davie, S. Floyd, V. Jacobson, D. Katabi, G. Minshall, K.
Ramakrishnan, T. Roscoe, I. Stoica, J. Wroclawski, and L. Zhang. Making the world (of
communications) a different place. SIGCOMM Comput. Commun. Rev., 35(3):91--96, 2005.
[8] D. Clark, J. Wroclawski, K. Sollins, and R. Braden . Tussle in cyberspace: defining tomorrow's internet.
IEEE/ACM Trans. Netw., 13(3):462--475, 2005.
[9] T. Erl. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice Hall, 2005.
[10] ICT FP7 SENSEI Project: http://www.sensei-project.eu/
[11] M. Rossi (Editor), “D.2.3 - Preliminary Context Model, Interfaces and Processing Mechanisms for
Sensor Information Services”, SENSEI Public Deliverable D.2.3, 2009, http://www.sensei-project.eu/.
[12] Z. Shelby, M.I. Ashraf, M. Luimula, J. Yli-Hemminki, and A.P. Castellani, "BinaryWS: Enabling the
Embedded Web" submitted to EWSN2010, FWN2010
[13] M. Mouly and M. Pautet. The GSM System for Mobile Communications. Telecom Publishing, 1992
[14] M. Strohbach, M. Bauer, E. Kovacs, C. Villalonga and N. Richter. Context Sessions - A Novel
Approach for Scalable Context Management in NGN Networks. Proceedings of Workshop on
Middleware for Next-generation Converged Services and Applications (MNCNA), held in conjunction
with Middleware 2007, 2007.
[15] M. Botts, G. Percivall, C. Reed and J. Davidson. OGC Sensor Web Enablement: Overview and High
Level Architecture. Technical report, OGC, 2007.
[16] T. Bauge (Editor), “D.3.3 - Components for End-to-End Networking, Management and Security and
Accounting”, SENSEI, Public Deliverable D.3.3, 2009, http://www.sensei-project.eu/.
IOS Press, 2010
doi:10.3233/978-1-60750-539-6-257
SENSEI traffic impact on mobile wireless

networks
Igor TOMIĆa,1, Srdjan KRČOa, Divna VUČKOVIĆa,
Alexander GLUHAK b and Pirabakaran NAVARATNAM b
a
Ericsson d.o.o, Serbia
b
University of Surrey, United Kingdom
Abstract. With an increasing number of connected devices and the coming wave
of Internet of Things services, it is important to understand how the modern
communication networks will cope with the additional traffic load. In this paper,
an analysis of several Internet of things scenarios as envisioned by the FP7
SENSEI project have been performed to understand how the traffic is being
generated in each of the scenarios. Based on the analysis, a traffic model is derived
and then used to assess its impact on wireless mobile networks from the networks’
dimensioning point of view. The results of this analysis are then presented.
Keywords: Internet of things, Future Internet, traffic modeling, M2M
Introduction
FP7 SENSEI project focuses on integration of heterogeneous wireless sensor and

actuator networks (WS&AN) into a common framework of global scale [1]. It relies on
the connectivity substrate provided by future networks to realize the various
interactions between SENSEI resources (sensors, actuators and in general Internet of
Things devices), resource users, and other components [3].
Today, there are more than 4 billion mobile subscribers. While the deployment of
connected Internet of Things (IoT) devices and services will be initially incremental, it
is expected that it will rapidly grow in scale, dwarfing the number of current end hosts
on the Internet by orders of magnitude. The type and amount of traffic generated by the
interactions with these devices may differ from the existing traffic patterns for which
the current networks (in particular modern mobile networks WCDMA and LTE) have
been dimensioned. Currently, mobile networks are dimensioned using standard traffic
models, which are based on a typical subscriber behavior expressed in typical time
spent using speech service, number of sent/received messages (SMS, MMS) and the
amount of data subscriber is downloading. These traffic models do not take into
account traffic generated by smart devices. It is therefore essential to understand how
these smart devices will generate the network traffic and to take that traffic into
account when designing and optimizing current and future communication networks,
including Future Internet.
1
Igor Tomić, Ericsson d.o.o., Vladimira Popovića 6, 11070 Novi Beograd, Srbija, E-mail:
igor.tomic@ericsson.com.
258 I. Tomić et al. / SENSEI Traffic Impact on Mobile Wireless Networks
In this paper we present an approach to model the Internet of Things traffic based
on a set of representative scenarios together with the initial results of dimensioning a
representative mobile network using a new traffic model that combines the standard
traffic mix with the traffic generated by smart devices participating in selected IoT
scenario.
1. IoT Scenarios – Input for Traffic Model Definition
Internet of Things scenarios and applications are wide and diverse, with a variety of
user interactions, message sequences, requirements and QoS expectations. The
SENSEI project has defined 18 different IoT scenarios [2] that span across several
application domains. In order to build a representative IoT traffic model the foreseen
scenarios were analyzed to identify how the information is being generated and
exchanged in each of the scenarios (who generates what information, how often it is
transferred and over what type of the network, what is the message size and frequency,
etc.). As the focus of our research was on analysis of traffic impact on mobile access
networks, we focused on scenarios that primarily utilize mobile networks for
information transfer. After identifying the interactions between different entities in the
system for each of the scenarios and determining the frequency of message exchanges,
the size of each message and the quality of service (QoS) requirements for each
scenario, the Multimodal traveler scenario [2] has been selected as the representative
IoT scenario for assessing the impact of IoT traffic on mobile networks.
This scenario was selected for several reasons. It generates the highest and most
demanding traffic load on the mobile networks. Actors in the scenario are mobile
across a wide area and are thus generating traffic in different parts of a network
therefore influencing a number of the network nodes. This is important as the analysis
of the impact of the additional traffic on mobile networks can be more sophisticated
when the traffic growth is spread across the network. The scenarios that take place in a
limited area like the Smart factory or Smart places scenarios [2] can be taken care of by
simple installation/upgrade of hotspot base stations and as such are not of interest.
In order to take into account the impact of traffic generated in other scenarios and
potential increase of the IoT services and devices over time, we introduced a
multiplication factor k. By increasing this factor, we were able to simulate an increased
traffic load generated by other scenarios and or new users. The following section
analyzes the selected scenario in detail.
1.1. Multimodal traveler scenario analysis
Five different scenes have been defined for this scenario: Web Based Car Pool, Web
Based Journey Planner, Passenger Drop Off, Public Transport Passenger Behaviour
Sensor Network and the Public Transport Ticket Service scene. The last scene was
excluded from the analysis as practically no traffic over mobile networks is generated
in the scene.
All messages transferred through the system are classified into one of the
following two groups:
I. Tomić et al. / SENSEI Traffic Impact on Mobile Wireless Networks 259
• Application traffic, generated by new applications, for example Web Based

Car Pool or Web Based Journey Planner;
• System traffic, generated by interactions in the SENSEI resource layer [3].
Consequently, possible message sequences were identified and classified according to
the traffic types defined above for each identified scene. For the identified messages,
the message sizes and the frequency of message exchanges (where applicable) were
defined. Based on that, an estimation of the traffic generated by an active user was
made. In the following subsections, each of the scenes is first described and analysed
from the application and system traffic perspectives.
1.1.1. Web Based Car Pool Scene Analysis

Story: Web Based Car Pool application enables citizens to use proactive car-pooling,
depending on their real-time situation and agenda.
Application traffic analysis
This scene consists of the following application traffic related activities:
• Assume user #1 is a driver and users #2 and #3 are the passengers. At the
beginning, all three users download the Car pool service web page.
• In the initial message, users provide information about the starting points of
their journeys, destinations etc.
• The Car pool service sends the “car pool offer” messages to users #2 and #3
informing them about the proposed journey (pick up places and times, the
route, etc). If they agree with the proposal they reply with request messages
asking for a place in the car.
• The Car pool service sends a request message to user #1. After user #1 sends a
confirm message, where he accepts the proposed route, a confirmation
message is sent to users #2 and #3.
The message exchanges for this scene are shown in Figure 1, with the direction
(uplink/downlink) and estimated size of each message. Based on this we can define the
total amount of the application traffic for all three users: 192 KB on downlink and 34
KB on uplink which gives 64 KB/BH (busy hour) on downlink and 12 KB/BH on
uplink per single active user.
1.1.2. Web Based Journey Planner Scene Analysis

Story: Web-Based Journey Planner application located in a car receives live
information from the road authority on the state of the roads (including traffic jams,
accidents and various weather conditions), while at the same time transmits
information to the road authority collected from different sensors built in a car (speed,
distance, use of windscreen wipers…).
Information received by the journey planner application from the road authorities about
state of the roads is considered to be application traffic (i.e. not using SENSEI
protocols). It will be modelled with 120 messages per hour, where size of each message
is estimated to be 1 KB.
Figure 1 Web Based Car Pool Scene – Application traffic

SENSEI resource layer traffic analysis
For the purpose of this analysis we assume:
• The Road Authority is a resource user;
• Car gateways connecting sensors built into the cars and providing information
about the speed, position, weather conditions, etc. are acting as the REPs
(Resource End Point);
Based on this, the following system level activities at the resource layer can be
identified:
• REP registers with the RD at the beginning of the journey.
• REP periodically updates the RD with interval Texp.
• Resource user continuously requests data from the REPs periodically, with
period Treq using the RAI.
Resource SQR Execution Resource REP

User Manager Directory
publishResource()
request() RLI confirm()
lookupResource()
listReso urce() RPI
request() getResource()
result() Texp
result()
Treq result()
RAI
REI
SQI
updateResource()
confirm()
request()
RPI
publishResource(), result(), updateResource() - message size = 10KB Texp = 10 min Treq = 1 min
confirm(), getResource() - message size = 1KB
Figure 2 Web Based Journey Planner Scene – SENSEI system traffic

Figure 2 shows the corresponding SENSEI resource layer interactions for this scene.
From the radio network interface perspective, messages of interest are considered to be
the messages sent or received by a REP, either through RAI or RPI interface. Further,
we assume Treq=1minute, Texp=10minutes, message size of 10KB for publish(),
updateResource() and result() messages, and message size of 1 KB for confirm() and
getResource() messages.
1.1.3. Passenger Drop Off Scene Analysis

Story: While passing by a bus stop, the driver is alerted by the dashboard that he must
drop off a passenger to let him or her continue their travel using the multimodal public
transport system.
The activities related to the application traffic are the following:
• The car pool service informs User 1 to stop the car and drop off Users 2 and 3.
• The car pool service informs Users 2 and 3 to proceed with public
transportation.
• All three users are awarded Carbon credits for using the car pool service.
Figure 3 shows the corresponding messages that are being exchanged including the
direction (uplink/downlink) and an assumption of the size of each message .
Figure 3 Passenger Drop Off Scene – Application traffic
1.1.4. Smart Public Transportation Stations Scene Analysis

Story: Public Transportation Stations are equipped with sensors which track the
travelers use of stops and provide real-time data on customer levels across the
network..
SENSEI resource layer traffic analysis
The activities at the resource layer are the following:
• REP updates the RD whenever the first person waiting for a bus on a certain
line comes to a station. RD is updated with a tag dedicated to that bus number
(i.e. the bus stop informs the RD that it has interest in line XYZ).
• Resource user subscribes (lookup subscription) to all bus stops to get informed
about any changes in the list of bus lines with passengers waiting
• Resource users use the RAI to access the REPs and retrieve required
information (i.e. number of people waiting for specific bus, average waiting
time, etc.)
Resource SQR Execution Resource REP

User Manager Directory
notify()
getResource()
result()
RAI Texp
notify()
getResource()
result()
RAI
result() - message size = 50KB Texp = 1 min

notify(), getResource() - message size = 1KB
Figure 4 Smart Public Transportation Stations Scene – system traffic

Figure 4 shows the corresponding resource layer interactions for this scene. We
assumed that on average, the public transportation system communicates with the
Public Transportation Authority once per minute, where the result() message size is
50KB, while message size for the notify() and getResource() messages is 1KB.
2. Traffic Model
Based on the analysis presented in the previous section, it is now possible to specify the
traffic generated by an active IoT user over a mobile network. In order to combine the
IoT traffic with the standard mobile wireless network traffic (traffic generated by
mobile users today: voice, data, SMS and MMS) and to build an aggregated traffic
model, the IoT traffic has to be scaled and expressed in the same manner as the
“standard” traffic, i.e. as the traffic generated per mobile subscriber during a busy hour.
The first step toward this modeling is the estimation of the number of potential
active users at a given moment. In the selected scenario there are three types of users:
(i) travelers, (ii) cars, and (iii) public transportation stations (devices). An estimation of
the number of active users can be derived based on a study of transport for the city of
London (UK) in [6] and [7]. According to the study, the total number of travelers
during a peak hour in London is 1.8 million, of which 875000 are traveling by car and
the remaining 925000 are using the public transport. Based on the assumption that
penetration of the selected scenario is 2/3 [5], it is assumed that there are 1.2 million
“IoT” travelers, of which 583000 are using cars, while 617000 use the public transport.
Moreover, the number of “IoT” enabled cars has to be estimated, since a certain
amount of traffic is generated per vehicle, not per traveler. We will assume that the
ratio of the “IoT” enabled cars and the car travelers involved in the selected “IoT”
scenario is 1:2, i.e. the number of the “IoT” enabled cars is two times smaller than the
number of the “IoT” car travelers (292000 cars). The number of the public transport
station sensors is considered to be 15050 according to [6] and [7].
Based on these estimates and knowing that there are 5 million mobile subscribers
in London out of the total 7.5 million people, it is possible to scale the total number of
the “IoT” users to match the London scale. Following the above assumptions and
estimations, the traffic per mobile subscriber in the selected scenario can be computed.
Table 1 summarizes the IoT traffic model.
Summary of the developed traffic model shows that one of the main differences of
the IoT traffic mix in comparison to the existing traffic models is a more intensive
traffic on uplink than on downlink. Although the calculations here are based on one
selected scenario, this trend is noticeable in all analyzed IoT scenarios. Therefore, we
believe that the traffic model presented in Table 1, reflects well the patterns of the IoT
communication activities. This traffic model can be varied by controlling the
multiplication factor k, to simulate higher penetration of IoT users.
Table 1 SENSEI MMT based traffic model summary
Traffic per Active Penetration Traffic per mobile

user [KB/BH] (ratio between active subscriber [KB/BH]
Scene Traffic Type
users and number of
mobile subscribers)
Uplink Downlink Uplink Downlink
Web Based Car

Application 12 64 24% (travelers) 3 15
pool
Web Based Journey Application 0 120 0 7

5.9% (cars)
Planner
Resource layer 660 66 39 4
Passenger Drop Off Application 1 12 24% (travelers) 0 3

Smart Public
Transportation Resource layer 3060 60 0.3% (stations) 9 0
Stations
MMT based traffic
51 31
model
3. Traffic Impact Analysis
The scope of the analysis is to dimension the size of a radio network required to carry
the regular mobile network traffic with and without the IoT traffic, in order to compare
the results and assess the impact of the IoT traffic on the mobile access networks in
terms of the infrastructure requirements like the number of base stations and the
corresponding hardware units. The analysis has been done using Ericsson’s simulation
tool for radio network proposals.
The regular mobile network traffic (consisting of voice, SMS, web browsing, etc.)
was modelled with standard Ericsson’s traffic model. Parameters described by this
model are: speech and video call traffic (which is expressed in
miliErlangs/BusyHour/subscriber units), data traffic (which is expressed in

KiloBytes/BusyHour/subscriber units), and distribution of terminals according to the
data transfer capabilities (WCDMA R99, HSDPA, HSPA, expressed in percentage of
each terminal type). The IoT traffic is added to the Ericsson traffic mode. Other IoT
scenarios and increased number of IoT users are taken into account by using different
multiplication factors - k, (k = 1, 2.5, 5, 7.5, 10).
Dimensioning of the mobile network was done for an area of an average European
city. According to the EUROSTAT Urban Audit research performed in 2003/2004 [8],
which covered 371 city in EU countries, including Norway, Switzerland, Croatia and
Turkey, an average European city has population of approximately 400000 citizens and
covers 150 square kilometers. The number of mobile subscribers is estimated to 2/3 of
population, or 266 000 citizens. Distribution of the urban/suburban area was considered
to be 50/50. All results are expressed in relative units compared to the existing radio
network (k=0, i.e. no IoT traffic, standard mobile traffic only). It can be expected that
this trend will not change in different geographical areas. The following assumptions
were used as input to the network dimensioning:
• 266 000 mobile subscribers, 75 square kilometres of urban area, 75 square
kilometres of Suburban area.
• Traffic model: Ericsson traffic model + IoT traffic model.
• Three sectors Node Bs, with 20W amplifier per each sector, one 5 MHz
channel available;
• Five HSDPA SF16 codes per cell, 16QAM modulation;
• Area coverage probability: Urban (95% for speech, video call and R99 packet
data service; 90% for HSPA service), Suburban (90% for speech, video call,
R99 packet data service, HSPA service with target throughput 1.5Mbps)
• Okumura-Hata radio propagation model (A=155.1 dB for Urban and A=147.9
dB for Rural);
• Other to own cell interference factor (F=Ioth/Iown): F=0.72 for downlink and
F=0.73 for uplink. Downlink Orthogonality factor: A=0.64
4. Results
The main output of the analysis is the number of required sites (a site is a location
where a base station is placed) and the hardware units required to be deployed in each
base station. The amount of hardware units is expressed as the number of necessary
channel elements. One channel element corresponds to a NodeB hardware and
processing power needed to serve one speech call. Based on the number of sites and the
number of channel elements, the overall cost (CAPEX) of a radio network can be
calculated.
Estimation of the number of required radio sites, for different amount of the total
IoT traffic modeled by the multiplication factor k, is presented in Table 2 and Figure 5.
It can be seen that for the lower values of k (k < 3) introduction of the selected IoT
service does not impact the number of radio sites significantly which means that the
existing mobile infrastructure is sufficient to cope with the initial IoT traffic. With the
increase of IoT users and services (k>3), the number of required radio sites grows and
optimization of mobile network protocols might be required (i.e. capacity expansion by
introducing additional 5Mhz channels) to limit their growth and minimize CAPEX.
Table 2 Number of required base station sites and cell range

Multiplication factor
0 1 2.5 5 7.5 10
Number of BS sites, Urban 52 52 52 59 71 85
Number of BS sites, Rural 34 34 42 56 70 84
Number of BS sites, Total 86 86 94 115 141 169
Cell range , Urban [km] 0.86 0.86 0.86 0.81 0.74 0.67
Cell range, Suburban [km] 1.06 1.06 0.96 0.83 0.74 0.68
Figure 5 Number of required base station sites
The uplink hardware requirements as a function of the multiplication factor are

given in Figure 6. These requirements have a steeper growth rate than the number of
radio sites. In this case, a more significant increase of the uplink hardware requirements
is visible already for k>1. Downlink hardware requirements also increase with the
increase of the multiplication factor k, but at a lower rate, so the uplink hardware
requirements are more sensitive on the IoT traffic growth.
5. Conclusion
Modeling of IoT traffic is a complex task as the IoT domain covers a wide and diverse
range of applications, each with own specific way of working and characteristics. In
this paper, we analyzed 18 different IoT scenarios spanning a number of application
domains and created a traffic model that captures the main characteristic of the IoT
services: demanding uplink traffic requirements. The level of IoT traffic was modeled
using a multiplication traffic.
The estimation of the number of required base station sites showed that for
intensive IoT traffic (k>5) a significant number of new sites is needed. Further, it is
HW needed - uplink
45000 250
40000
CE UL relative growth
200
35000
Channel elements UL
Channel elements relative

Channel elements
30000
150
growth [%]
25000
20000
100
15000
10000
50
5000
0 0
0 1 2.5 5 7.5 10
Multiplication factor
Figure 6 Hardware requirements
also observed is that the dimensioning of the uplink hardware elements is critical as its
rate of increase is more rapid than in the case of the number of radio sites.
Further work will be focused on a more detailed analysis and simulation of traffic
impact for a concrete network as well as performing similar analysis for LTE networks.
References
[1] www.sensei-project.eu, last accessed on 19 Jan 2010

[2] SENSEI WP1 deliverable report D1.1: SENSEI Scenario Portfolio, User and Context Requirements,
available online www.sensei-project.eu
[3] SENSEI WP3 deliverable report D3.2: Reference Architecture, available online www.sensei-project.eu
[4] SENSEI WP3 deliverable report D3.3: Components for End-to-End Networking, Management and
Security and Accounting, available online www.sensei-project.eu
[5] SENSEI WP1 deliverable report D1.6: Requirements for Field Trials and Demonstrations, available
online www.sensei-project.eu
[6] London Travel Report 2007, Mayor of London/Travel for London, 2007,
http://www.tfl.gov.uk/assets/downloads/corporate/London-Travel-Report-2007-final.pdf
[7] Travel in London, Key Trends and developments, Report number 1, Mayor of London/Travel for London,
2009, available online at http://www.tfl.gov.uk/assets/downloads/corporate/travel-in-london-report-
number-1.pdf, last accessed on 20 Dec 2009
[8] http://epp.eurostat.ec.europa.eu/portal/page/portal/region_cities/city_urban), last accessed on 20/12/2009
The Future Internet, A European research Perspective, IOS Press, May 2009.
IOS Press, 2010
Subject Index
adoption incentives 21 M2M 257
adoption model 11 Management Plane 105
API 217 MDC 237
architecture 1 media applications 217
business models 21 middleware 217
climate forecasts 41 model 51
cloud computing 63, 115, 127 modular design 1
cloud threats and monitoring 115
countermeasures 127 MPEG 217
cognitive networks 95 multi-layered/multi-viewed
Content Networks 227 content coding 237
Content-Centric Internet 227 multipath TCP 21
context-awareness 193, 247 multi-source/multi-network
cooperative environments 173 streaming & adaptation 237
deployment scenarios 21 network security 75
economic bases 31 networking 63
economic models 31 NREN 63
Economic Traffic Management Orchestration Plane 105
(ETM) 1 overlays 1
empirical research 41 Panlab 51
emulation 139 pattern-based reference
experimental facility 51 architecture 149
experimentation 51, 95 Peer-to-Peer (P2P) 1
federation 51, 115 PEP 139
FEDERICA 63 Personal Smart Spaces 193
FIRE 51 pervasive services 193
Future Internet 11, 21, 31, 51, 75, privacy 85
85, 95, 127, 173, 183, 257 proactivity 193
Future Internet architecture 63 publish/subscribe networking 75
GÉANT 63 Quality of Experience 183
generic human profile 183 real time energy management 173
global service delivery platform 161 Real World Internet 247
IaaS 63, 127 reference architecture 149
IDS 139 Resource 247
incentives 1 Resource Discovery 247
infrastructure 63 resource pooling 21
intentity 85 routing 11
Internet architecture 227 satellite 139
Internet of things 257 scalable video coding 205
Knowledge Plane 105 security 139
large system security 41 security architecture 127
learning & reasoning 193 self-configuration 105
Locator/ID Split 11 self-improvement 193
268
self-management 95 TCP 139

self-performance 105 Teagle 51
semantic Web services 161 testing 51
Sensor and Actuator Networks 247 traffic modeling 257
service cloud 115 transcoding 205
Service Enablers Plane 105 turbo codes 205
service management 115 unequal error protection 205
service markets 31 use case 51
service-based systems 149 user-centric 183
Service-Oriented Architecture user intent prediction 193
(SOA) 149, 161 utility 31
session concept 85 utility services 31
SLA 115 virtual identity 85
smart cities 173 virtual multipath operator 21
smart grids 173 virtualization 63, 105
social-aware 183 virtualization infrastructure 127
surveillance centric coding 205 wavelet-based video coding 205
SVC/MVC 237
IOS Press, 2010
Author Index
Alonistioti, N. 95 Jari, A. 237
Alvarez, F. 227, 237 Kalatzis, N.K. 193
Astorga, A. 105 Katsigiannis, C. 237
Barnaghi, P. 247 Kostopoulos, A. 21
Bauer, M. 247 Koumaras, H. 237
Bauge, T. 247 Kousaridas, A. 95
Belli, F. 139 Krčo, S. ix, 247, 257
Bernat, J. 247 Krummenacher, R. 161
Boite, J. 95 Lagutin, D. 75
Bouwen, J. 227 Latanicki, J. 127
Callejo Rodriguez, M.Á. 1 Lauenroth, K. 149
Camarillo, G. 227 Lefevre, L. 105
Campanella, M. 63 Levä, T. 11, 21
Caputo, D. 173 Li, M.-S. 31
Chapman, C. 115 Liampotis, N.D. 193
Cheniour, A. 105 Lotz, V. ix
Chiariglione, F. 217 Luglio, M. 139
Clayman, S. 105, 115 Macedo, D. 105
Conan, V. 95 Magedanz, T. 51, 183
Corte, P. 149 Maglaris, V. 63
Daras, P. 227 Mamatas, L. 105
Davy, S. 105 Massacci, F. 41
de Meer, H. 105 Massonet, P. 127
de Panfilis, S. 149 Montagut, F. 247
Domingue, J. 161 Movahedi, Z. 105
Doncel, V.R. 217 Muldowney, D. 105
Doolin, K.J. 193 Mussetta, M. 173
Eardley, P. 21 Nagin, K. 115
Filoche, T. 237 Naqvi, S. 127
Fischer, A. 105 Navaratnam, P. 257
Ford, A. 21 Neuhaus, S. 41
Fracchia, R. 237 Nguengang, G. 95
Galis, A. ix, 105, 115 Niebert, N. 227
Gavras, A. ix, 51 Pedrinaci, C. 161
Gazis, V. 95 Pirisi, A. 173
Girao, J. 85 Pohl, K. 149
Gittler, F. 149 Potts, M. 63
Gluhak, A. 247, 257 Preda, M. 217
Griffin, D. 227 Pujolle, G. 105
Grimaccia, F. 173 Pussep, K. 1
Heinrich, B. 21 Racz, P. 1
Iannone, L. 11 Ramzan, N. 205
Izquierdo, E. 205 Raptis, T. 95
270
Rochwerger, B. 115, 127 Timmerer, C. 217

Rodero-Merino, L. 115 Toffetti, G. 115
Roseti, C. 139 Tomić, I. 257
Roussaki, I.G. 193 Tsiatsis, V. 247
Rubio-Loyola, J. 105 Vaquero, L.M. 115
Sarma, A. 85 Vehkapera, J. 237
Serrat, J. 105 Villalonga, C. 247
Simoes, J. 183 Villari, M. 127
Simonov, M. 173 Visala, K. 75
Simperl, E. ix, 161 Vučković, D. 257
Soursos, S. 1 Wahle, S. 51
Spadotto, G.P. 193 Warma, H. 21
Spirou, S. 1 Weik, P. 183
Stamoulis, G.D. 1 Widera, R. 21
Stiller, B. ix, 1 Williams, M.H. 193
Stricker, V. 149 Zahariadis, T. ix, 227, 237
Tarkoma, S. 75 Zgaljic, T. 205
Taylor, N.K. 193 Zich, R.E. 173
View publication stats

Towards The Future Internet PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Towards The Future Internet PDF

Caricato da

Copyright:

Formati disponibili

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Towards the Future Internet - Emerging Trends from European Research

Book · April 2010

Alex Galis Anastasius Gavras

SEE PROFILE SEE PROFILE

Srdjan Krco Elena Simperl

SEE PROFILE SEE PROFILE

H2020 SliceNet View project

FI-STAR: Future Internet Social Technological Alignment Research View project

The user has requested enhancement of the downloaded file.

Amsterdam • Berlin • Tokyo • Washington, DC

ISBN 978-1-60750-538-9 (print)

Distributor in the USA and Canada

PRINTED IN THE NETHERLANDS

Directorate General for Information Society and Media

Mário Campolargo Luis Rodríguez-Roselló

Although the current Internet, as a ubiquitous and universal means for

• Explicit multi-faceted unification, integration and orchestration of polymorphic

• Facilities for the large scale provisioning, management and deployment of

Trust and Identity

Future Internet Research Experimentation

This book contains 25 selected papers presenting a variety of European research

1.1 Future Internet Socio-economics Research Challenges

Paper #1 “ETMS: A System for Economic Management of Overlay Traffic”

Paper #3 “Business Aspects of Multipath TCP Adoption” presents an overview of

1.2 Future Internet Trust and Identity Research Challenges

Paper #14 “Vulnerabilities and Protection of Satellite Networks Interconnected

Ultimately, a trusted Future Internet is made up by people interacting with each

1.3 Future Internet Research and Experimentation Challenges

In paper #7 “Virtual Infrastructures in Future Internet” describes how virtualisation

1.4 Future Internet Management and Service-aware Networking Architectures

MANA research covers the management, the networking, the service-aware

The Future Internets would be built as service-aware and self-aware federated

Paper #8 “Publish/Subscribe for Internet: PSIRP Perspective” describes the

Paper #9 “Identity Engineered Architecture” describes the identity-engineered

Paper #11 “Manageability of Future Internet Virtual Networks from a Practical

1.5 Future Internet Service Offer Research Challenges

Paper #15 “Creating a Reference Architecture for Service-Based Systems” presents

1.6 Future Content Networks Research Challenges

It is a common belief that the Internet is evolving towards providing more

Paper #19 “Self-Improving Personal Smart Spaces for Pervasive Service

Adaptation should be supported by a network independent middleware platform

1.7 Real World Internet Research Challenges

Paper #25 “SENSEI Traffic Impact on Mobile Wireless Networks” analyses a

2. FUTURE INTERNET ASSEMBLY (FIA)

3rd March 2010

Alex Galis – University College London, United Kingdom

ETMS: A System for Economic Management of Overlay Traffic 1

Monitoring Service Clouds in the Future Internet 115

The SENSEI Real World Internet Architecture 247

Subject Index 267

ETMS: A System for

Abstract. The concept of Economic Traffic Management (ETM) encompasses

Keywords. Overlays, Peer-to-Peer (P2P), Economic Traffic Management (ETM),

2. Economic Traffic Management Mechanisms

Figure 1. The ETMS Architecture

• The QoS Manager checks the availability of network resources, guarantees

The ETMS architecture designed has been implemented as a prototype. It follows a

performance of these mechanisms and complement existing simulative and theoretical

4. Mapping of the Architecture to ETMs

4.1. Support for Locality Promotion

The mechanism for promoting locality (BGP-Loc) requires two features to be

4.2 Support for ISP-owned Peer