You are on page 1of 191

D3.

4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Socially-aware Management of
New Overlay Application Traffic with
Energy Efficiency in the Internet
European Seventh Framework Project FP7-2012-ICT- 317846-STREP

Deliverable D3.4
Prototype Implementation, Validation and
Selected Application

The SmartenIT Consortium
Universität Zürich, UZH, Switzerland
Athens University of Economics and Business - Research Center, AUEB, Greece
Julius-Maximilians Universität Würzburg, UniWue, Germany
Technische Universität Darmstadt, TUD, Germany
Akademia Gorniczo-Hutnicza im. Stanislawa Staszica w Krakowie, AGH, Poland
Intracom SA Telecom Solutions, ICOM, Greece
Alcatel Lucent Bell Labs, ALBLF, France
Instytut Chemii Bioorganicznej PAN, PSNC, Poland
Interoute S.P.A, IRT, Italy
Telekom Deutschland GmbH, TDG, Germany

© Copyright 2015, the Members of the SmartenIT Consortium
For more information on this document or the SmartenIT project, please contact:
Prof. Dr. Burkhard Stiller
Universität Zürich, CSG@IFI
Binzmühlestrasse 14
CH—8050 Zürich
Switzerland
Phone: +41 44 635 4331
Fax: +41 44 635 6809
E-mail: info@smartenit.eu

Version 1.0

Page 1 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Document Control
Title:

Prototype Implementation, Validation and Selected Application

Type:

Public

Editor:

George Petropoulos

E-mail:

geopet@intracom-telecom.com

Author(s):

George Petropoulos, Sergios Soursos, Jakub Gutkowski, Łukasz
Łopatowski, Grzegorz Rzym, Piotr Wydrych, Andri Lareida, Daniel Dönni,
Thomas Bocek, Fabian Kaup, Matthias Wichtlhuber, Sabine Randriamasy,
Zbigniew Duliński, Rafał Stankiewicz, Krzysztof Wajda, Ioanna Papafili,
Paolo Cruschelli, Burkhard Stiller

Doc ID:

D3.4-v1.0.doc

Amendment History
Version

Date

Author

Description/Comments

v0.1

January 30, 2015

George

Table of contents

v0.2

March 31, 2015

George

Updated table of contents

v0.3

April 15, 2015

George, Fabian, Lukasz, Jakub,
Grzegorz, Sabine, Andri, Daniel

Integrated input to chapters 4, 5, 6 and 7.

v0.4

April 21, 2015

George, Sergios, Matthias, Lukasz,
Jakub, Grzegorz, Daniel, Piotr

Integrated input to all chapters.

v0.5

April 24, 2015

Ioanna, Paolo, Burkhard

Internal review

v1.0

April 30, 2015

George, Sergios, Lukasz, Grzegorz,
Matthias, Daniel, Sabine, Thomas

Final version

Legal Notices
The information in this document is subject to change without notice.
The Members of the SmartenIT Consortium make no warranty of any kind with regard to this document,
including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The
Members of the SmatenIT Consortium shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the furnishing, performance, or use of this
material.

Page 2 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Table of Contents
1 Executive Summary

5

2 Introduction

6

2.1
2.2

Purpose of Deliverable 3.4
Document Outline

6
7

3 Architecture Overview
3.1
3.2
3.3

8

Overview
Entities/Components/Interfaces
System Deployment

8
9
11

4 Implementation Framework
4.1

4.2

4.3
4.4
4.5

14

Tools
4.1.1 Specification Language
4.1.2 Programming Languages
4.1.3 Libraries
4.1.4 Tool chain
4.1.5 Testbed
4.1.6 Version Control
4.1.7 Issue Tracking
4.1.8 Continuous Integration Server
Procedures
4.2.1 System Release Process
4.2.2 Development Process
4.2.3 Roles
4.2.4 Meetings
System tree layout
Open-Source releases
Deployment Instructions

14
14
14
15
16
16
16
16
17
17
17
18
18
19
19
22
22

5 The Dynamic Traffic Management (DTM) mechanism
5.1

5.2

24

SBox
5.1.1 Quality of Service Analyzer
5.1.2 Network Traffic Manager
5.1.3 Economic Analyzer
5.1.4 Inter-SBox Communication Service
5.1.5 SBox-SDN Communication Service
5.1.6 Database
5.1.7 User Interface
SDN Controller
5.2.1 Interfaces
5.2.2 Floodlight

24
24
37
57
64
64
64
69
78
78
80

6 The Replicating Balanced Tracker - Home Router Sharing based on Trust (RBHORST) mechanism
90
6.1

6.2

uNaDa
6.1.1 Cloud Traffic Manager
6.1.2 Overlay Manager
6.1.3 Topology Proximity Monitor
6.1.4 Social Monitor
6.1.5 Social Analyzer
6.1.6 uNaDa-End-User Interface
6.1.7 Database
6.1.8 User Interface
End-User

90
90
99
103
106
107
109
111
119
128

7 The Multi-Criteria Application End-Point Selection (MUCAPS) mechanism
Version 1.0

134

Page 3 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

7.1

7.2

Mapping to the SmartenIT Architecture
7.1.1 Required SmartenIT components and entities
7.1.2 Embedding MUCAPS on the SmartenIT architecture
Implementation and Deployment
7.2.1 Description of the MACAO related functional blocks
7.2.2 MUCAPS implementation and execution: entities and interfaces
7.2.3 In-network transparent deployment

8 The Virtual Incentives (vINCENT) mechanism
8.1
8.2

Mapping to the SmartenIT Architecture
Implementation and Deployment

9 The Mobile Network Assistant (MoNA) mechanism
9.1
9.2

Mapping to the SmartenIT Architecture
Implementation and Deployment

10 The SDN-based DC selection (SDNDC) mechanism
10.1 Mapping to the SmartenIT Architecture
10.2 Implementation and Deployment
10.2.1 Implementation Environment Description
10.2.2 Implementation

134
135
136
137
137
140
145

147
147
148

151
151
152

155
155
157
157
158

11 System Releases

162

11.1 Release v1.1
11.1.1 Features
11.1.2 Tests
11.1.3 Issues
11.2 Release v1.2
11.2.1 Features
11.2.2 Tests
11.2.3 Issues
11.3 Release v2.0
11.3.1 Features
11.3.2 Tests
11.3.3 Issues
11.4 Release v2.1
11.4.1 Features
11.4.2 Tests
11.4.3 Issues
11.5 Release v3.0
11.5.1 Features
11.5.2 Tests
11.5.3 Issues
11.6 Release v3.1
11.6.1 Features
11.6.2 Tests
11.6.3 Issues

163
163
163
163
163
163
164
165
166
166
167
172
172
172
173
174
174
175
175
176
177
177
177
179

12 Summary

180

13 SMART Objectives Addressed

182

14 References

184

15 Abbreviations

186

16 Acknowledgements

188

Page 4 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

1 Executive Summary
The aim of Deliverable 3.4 “Prototype Implementation, Validation and Selected
Application” is to document the final release of the SmartenIT prototype, with respect to
the implementation framework, the design and the implementation of the SmartenIT
system. Moreover, D3.4 also documents any standalone implementations that were made
by SmartenIT partners but were not integrated to the core system.
D3.4 is the outcome of four WP3 tasks, namely T3.2 “Technology Scouting and Definition
of Implementation Framework”, T3.3 “Development of Prototype Components”, T3.4
“Implementation of Selected Application” and T3.5 “Integration of Prototype and
Validation”. Hence, this deliverable covers all SmartenIT prototype implementation
aspects. Additionally, D3.4 provides an overview of the standalone implementations
carried out throughout the duration of the project.
D3.4 is the last deliverable of WP3 “Architecture Design and Engineering” and with its
submission, the activities of WP3 are concluded. Thus, this deliverable provides the final
documentation of the SmartenIT prototype and can be used by third parties to extend the
software. For this reason, the SmartenIT consortium has already published the source
code of the prototype as Open Source, under the Apache License v2, available at [39].
The objectives and outcomes of D3.4 are summarized below:
A detailed description of the technologies and libraries used in the SmartenIT
prototype, along with the implementation framework (i.e., processes, tools, roles).
Detailed instructions on how to build the source code and deploy the artifacts on
the recommended hardware.
Detailed documentation of the two main mechanisms implemented by the
SmartenIT prototype, namely the “Dynamic Traffic Management” (DTM) and the
“Replicating Balanced tracker & Home Router Sharing based on Trust” (RBHORST) mechanisms. The documentation includes a per-component breakdown of
all the involved classes and interfaces, thus providing a full explanation of the
structure of the code, the functionality implemented, as well as the accompanying
tests for the validation of the components.
Documentation of the standalone implementation of certain SmartenIT
mechanisms which were not however integrated to the core prototype, due to either
their low maturity or the different direction decided to be taken by the SmartenIT
consortium. The documentation includes a description of the functionality
implemented, a mapping to the SmartenIT architecture and details of the
implementation and deployment. The mechanisms that fall under this category are
“MUlti-Criteria Application endPoint Selection” (MUCAPS), the “Virtual Incentive”
(vINCENT), the “Mobile Network Assistant” (MoNA) and the “SDN-based DC
selection” mechanisms.
A complete list of all the SmartenIT prototype releases, with the implemented
functionality in each of them, along with the respective integration tests.
To summarize, this deliverable stands as the engineering and implementation
documentation of the final release of the SmartenIT prototype and standalone
implementations and concludes the works of WP3.

Version 1.0

Page 5 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

2 Introduction
The focus of the SmartenIT project is to devise management mechanisms for traffic
generated by applications running on the Cloud and/or forming overlays. The main axes
around which such solutions evolve are: i) social awareness, ii) incentive compatibility, iii)
energy efficiency, and iv) QoE awareness. In this context, WP2 “Theory and Modeling”
has described a number of traffic management mechanisms that deal with certain
aspects. In the most recent deliverable of WP2, D2.4 “Report on Final Specification of
Traffic Management Mechanisms and Evaluation Results” [26], the final list of those
mechanisms is included, where each one of them is specified and evaluated. In
collaboration with WP3, WP2 has selected some of those mechanisms to be implemented
into a SmartenIT prototype according to the procedure described in [26]. The selected
mechanisms are specified in full details in [26] and comprise the core “Dynamic Traffic
Management” (DTM) mechanism, along with certain extensions so as to be combined with
the “Inter-Cloud Communication” (ICC) mechanism, as well as the “Replicating Balanced
tracker & Home Router Sharing based on Trust” (RB-HORST) mechanism. For more
details on these mechanisms, please consult [26].
WP3 on the other hand, has defined a modular architecture that can encompass any of
the functionality required for the SmartenIT prototype. In this sense, in the context of Task
3.1, Deliverable D3.3 “Final Report on System Architecture” [3] has documented all the
details of the SmartenIT architecture and has provided a mapping of all the identified
mechanisms to it. In the meantime, WP3 (through Tasks 3.3, 3.4 and 3.5) has started
implementing the first release of the SmartenIT prototype, which mainly involved the
implementation of the DTM mechanism. The details of this first release were documented
in D3.2 “Technologies, Implementation Framework, and Initial Prototype” [2].
With the next releases, WP3 started incorporating additional functionality and
mechanisms into the prototype system. In parallel, certain standalone implementations
were pursued by partners with focus on specific aspects of functionality that were not
addressed by the core system.

2.1

Purpose of Deliverable 3.4

The purpose of this deliverable is to fully document all the implementation work performed
by the consortium, by describing the final status of the SmartenIT prototype. More
specifically, D3.4 aims at:
describing in full detail the technologies and libraries used in the SmartenIT
prototype, along with the implementation framework (i.e., processes, tools, roles).
providing detailed instructions on how to build the source code and deploy the
artifacts on the recommended hardware.
documenting the mechanisms implemented by the SmartenIT prototype, including
a per-component breakdown of all the involved classes and interfaces, along with
the respective class and sequence diagrams, as well as the accompanying tests for
the validation of the components.
providing documentation of any standalone implementations of certain SmartenIT
mechanisms, not however integrated to the core prototype.

Page 6 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

providing a complete list of all the SmartenIT prototype releases, with the
implemented functionality in each one of them, along with the respective integration
tests.

2.2

Document Outline

Chapter 3 briefly reminds to the reader the entire SmartenIT architecture, as documented
in D3.3 [3], including the entities, components and interfaces required to encompass the
envisioned functionality.
Chapter 4 is the outcome of Task 3.2, which includes all the technologies and tools used
to support the development and deployment of the selected traffic management
mechanisms. The generated system tree and build instructions are also included.
Chapter 5 presents the implementation details of the DTM mechanism and its extensions,
describe per entity and per component, and including description of the functionality, the
interfaces, the design and the related tests.
Chapter 6 provides the same details for the RB-HORST mechanism.
Chapter 7 documents the standalone implementation of the “MUlti-Criteria Application
endPoint Selection” (MUCAPS) mechanism, by describing the functionality implemented,
a mapping to the SmartenIT architecture and details of the implementation and
deployment.
Chapter 8 provides the same information for the “Virtual Incentive” (vINCENT)
mechanism.
Chapter 9 does the same for the Mobile Network Assistant (MoNA) mechanism, and so
does Chapter 10 for the “SDN-based DC selection” (SDNDC) mechanism.
Chapter 11 provides the list of the different system releases for the DTM and RB-HORST
mechanisms, by identifying the functionality implemented in each release (in the form of
features addressed), the respective integration tests and the remaining issues to be
addressed by next releases.
Chapter 12 provides a brief summary of the deliverable’s conclusions, including the final
implementation framework, the implemented components of the DTM and RB-HORST
mechanisms and the list of standalone implementations.
Finally, the SMART objectives, which are defined in the Description of Work [31], are
addressed in Chapter 13.

Version 1.0

Page 7 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

3 Architecture Overview
The SmartenIT architecture was finalized in D3.3 [3], hence this chapter presents a
synopsis of the most relevant aspects of the SmartenIT architecture that is necessary to
understand D3.4. Initially, a brief overview of the final SmartenIT architecture is given in
Section 3.1, presenting all components and interfaces, as well as their grouping to entities.
Sections 3.2 and 3.3 illustrate the mapping of the two integrated mechanisms to the
generic SmartenIT architecture and their deployment diagrams, respectively.

3.1

Overview

The component diagram in Figure 1 shows all the components of the SmartenIT
architecture together with an overview of main interfaces. The color-coding of the
components denotes whether a component already exists in external systems (white
components) or is already implemented by SmartenIT (blue components).

Datacenter/NaDa/Cloud Manager
Traffic
Redirector

Load
Balancer

Workflow
Manager

Hypervisor

Overlay
Manager
Inter DC/Cloud/NaDa
communication

E.g. ALTO

Billing/
Accounting

E.g. inter-ALTO

Economics
Analyzer

Traffic Manager
Cloud Traffic Manager

Social Monitor

E.g. Facebook
API

Inter-domain
communication

Fixed/Mobile
Network Traffic Manager

Social Analyzer

SDN Controller

E.g. REST
E.g. Vimeo API

Online
Social Networks
(e.g. Facebook)

Content
Portals (e.g.
Vimeo)

QoS/QoE
Analyzer

Network
Analyzer

Energy
Analyzer

E.g. SNMP,
BGP, Netflow

QoE Monitor

QoS Monitor

E.g. OpenFlow

Topology/
Proximity
Monitor

Energy Monitor

Switching/
Forwarding

Figure 1: The SmartenIT component diagram.
Moreover, the components may coexist on a number of entities. The mapping of
components to entities is presented in Figure 2. In this figure, the grey boxes denote
Page 8 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

entities. In addition, the interfaces between entities’ components are presented.
Depending on the mechanism, each entity may run a subset of components and
interfaces.

Datacenter
ove1

Datacenter
Overlay
Manager

Traffic
Redirector

Load
Balancer

Workflow
Manager

Hypervisor

S-Box
iscs1

Inter-Sbox
Communication Service

ALTO
Energy
Monitor

eco1

Economics
Analyzer

Traffic Manager
Cloud Traffic Manager

UI

Social Analyzer

ntm1
Fixed/Mobile
Network Traffic Manager

DB

SDN Controller

soc2
Network
Analyzer

QoS/QoE Analyzer

uNaDa
ALTO

DB

UI

Energy
Analyzer

qos1
ove1

qoe1

top2

ene1

top1

ove2

Cloud Traffic
Manager

Overlay Manager

Topology/
Proximity Monitor

QoS/QoE
Analyzer

Network Entity

qoe1

soc3

End User Entity
qos1
soc2

soc2

ene1

soc1
Energy
Analyzer

Topology/
Proximity
Monitor

Switching/
Forwarding

Energy Monitor

ene1
Switching/
Forwarding

Traffic Manager
Vimeo

QoS Monitor

Topology/
Proximity
Monitor

Social Monitor

Energy Monitor

Energy Monitor
QoE Monitor

QoS Monitor

Social Analyzer

Social Monitor

ntm2

Facebook
ALTO

DB

UI

Figure 2: Components’ mapping to entities.
In the following subsections, the entities, components, interfaces and the deployment
diagrams of the two integrated prototypes, DTM and RB-HORST, are presented. The
mapping of the standalone implementations to the SmartenIT architecture are briefly
described in their respective chapters.

3.2

Entities/Components/Interfaces

Figure 3 and Table 3-1 present the instantiation of the SmartenIT architecture for the DTM
mechanism. This diagram includes both the architectural components, and the
implementation-specific ones, used to provide support functionalities. In addition, the
implemented interfaces are also defined. The white colored components were not
implemented, but used, as well as the grey colored Network Entity interfaces.
Table 3-1: List of Entities for DTM implementation
Entity

Components

Reference

SBox

Inter-SBox Communication Service
(ISCS), Database (DB), User Interface
(UI), SBox-SDN, Economics Analyzer,
QoS/QoE Analyzer, Fixed/Mobile

Section 5.1

Version 1.0

Page 9 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Network Traffic Manager
SDN Controller

SDN Controller, Interfaces

Section 5.2

ui
sdn1

S-Box

SDN Controller
Interfaces

ssdn

iscs1
ISCS

UI

Sbox-SDN

sdn2
iscs2

ntm3

SDN
Controller

ui
db
DB

Fixed/Mobile Network
Traffic Manager

openflow
netconf
ntm1

ntm2
Economics
Analyzer

Network Entity
Switching/
Forwarding

QoS Analyzer

eca1

snmp
QoS Monitor

Figure 3: The DTM mechanism entities/components/interfaces diagram.
On the other hand, the RB-HORST mechanism uses the entities and components,
presented in Figure 4 and also summarized in Table 3-2.
Table 3-2: List of Entities for RB-HORST implementation
Entity

Components

Reference

uNaDa

Cloud Traffic Manager (CTM), Overlay
Manager (OM), Social Monitor (SM),
Social Analyzer (SA), Topology
Proximity Monitor (TPM), Database
(DB), User Interface (UI), uNaDa-Enduser interface, Proxy

Section 6.1

End-User entity Traffic Manager, DB, UI

Section 6.2

Page 10 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

uNaDa

End-User Entity

ctm2
ctm1
Mobile Network
Traffic Manager

Cloud Traffic Manager

Proxy

sa1

om1

db1

om2
Overlay
Manager

Social Analyzer

DB

Social Monitor

UI

UI

DB

om3
Topology
Proximity
Monitor

ui1

vimeo

facebook

Vimeo

Facebook

Figure 4: The RB-HORST entities/components/interfaces diagram

3.3

System Deployment

In this section, the deployment diagrams of the two integrated and released prototypes,
DTM and RB-HORST, are presented, including the required hardware, processes,
artifacts and protocols.
Diagram in Figure 5 presents the devices, processes and artifacts used, to deploy an
instantiation of the final version of the DTM mechanism.
More specifically, the SBox is deployed on an x64 server with Ubuntu 14.04 [32] installed,
and requires the installation of Java [6] and the Jetty Web server [13], in which the
sbox.war artifact is deployed. The sbox.war contains all the required components (UI and
DB) for the SBox Web application, exposing an HTTP/HTTPS Web interface, accessible
by any Web browser from the administrator’s PC. In addition, the sbox.jar is the main
executable of the SBox, including all components implementing DTM mechanism’s
functionalities. It uses the JBoss Netty NIO framework [33] to expose the ISCS (Inter-SBox
Communication Service) interfaces using a custom SmartenIT-protocol over TCP, and
access the SDN Controller’s REST API over HTTP. The Sqlite [14] is also used as the
SBox’s database.
The SDN Controller also requires an x64 server, with Ubuntu 14.04 [32] as its operating
system, requiring Java [6] to be installed. The sdn.jar executes all the Floodlight [23] SDN
Controller’s processes, extended with DTM functionalities, and the Interfaces component,
which provides the SBox-SDN communication over HTTP.
Finally, the DTM mechanism requires also network devices, which, depending on the
localization in the network, must be Openflow-compatible [35], support SNMP [34] and

Version 1.0

Page 11 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

NETCONF [19]. QoS Analyzer of SBox retrieves SNMP measurements via SNMP.
NETCONF is used by the Network Traffic Manager to enforce configuration related with
delay tolerant traffic management. The network device also interacts with the exposed
Floodlight SDN Controller’s interface using the OpenFlow protocol.
SBox (Server)
Jetty Container

SDN Controller (Server)

sqlite

HTTP
sbox.war

HTTP
(JSON)

sdn.jar
Floodlight
0.90

jdbc

sbox.jar
TCP

Inter-SBox
Communication
Service

OpenFlow

DB
NETCONF

Traffic Manager
Economic
Analyzer

QoS
Analyzer

Network Device

SNMP

Figure 5: DTM deployment diagram.
For the RB-HORST mechanism, the presented system architecture is mapped onto the
deployment diagram of Figure 6, which presents the hardware, processes and artifacts
used to deploy an instantiation of the RB-HORST entities, as well as the interfaces and
protocols between entities and external systems.
For the reference implementation of RB-HORST, the Raspberry Pi [30] was selected as
the home gateway hardware. It is a low cost credit-card-sized single-board computer that
can be used for various purposes in a home environment, and specifically in our
implementation with the addition of an external WiFi dongle, it plays the role of an accesspoint. Any hardware setup including a low-cost computer with minimum RAM of 256 MB, a
WiFi dongle that supports 2 SSIDs, and an SD-card with a light Linux flavor installed, can
host the uNaDa software. More details on the hardware setup can be found in D4.1 [4].
Raspbian OS is selected since it is optimized for the Raspberry Pi hardware and includes
thousands of packages and utilities, which ease development and optimize user
experience.
The uNaDa software is a Java 7 [6] Web application, which is packaged as a war file and
is deployed in the Jetty Web server [13], running the social and overlay prediction
algorithms, and managing system's cache. The mitmproxy software [17] acts as the
system's proxy, intercepting end-users' requests, caching watched videos and rewriting
end-user requests when the requested video exists in the local cache. An additional Web
server, lighttpd [16], is used to serve cached contents to connected end-user devices,
while h2 [15] is the system's database. Two additional services, hostapd and dhcpd, are
installed to provide the 2 SSIDs and DHCP capabilities, so that Raspberry Pi can act as
an access-point. On the contrary, the end-user entity is implemented as an Android [7]
application, packaged as an apk file and is installed in any Android smartphone or tablet.

Page 12 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 6: RB-HORST deployment diagram.
Each uNaDa advertises and/or asks other overlay peers for content, location or other
metadata, using TomP2P [29] library, a distributed hash table which provides a
decentralized key-value infrastructure for distributed applications. The Facebook [27] and
Vimeo [28] APIs are periodically queried over HTTP by the Social Monitor, aiming to
retrieve and store social information. In addition, each uNaDa exposes a Web user
interface, accessible through any Web browser, where end-users can login with their
Facebook credentials, and manage their local cache and access-point. Finally, a REST
API is exposed and triggered by the RB-HORST Android application, used for end-users'
authentication in remote uNaDas, which returns private SSID credentials using JSON.

Version 1.0

Page 13 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

4 Implementation Framework
The implementation framework of the SmartenIT project includes all required tools to
design, develop, test and deploy the created software, and the necessary methods and
support platforms to organize and support the implementation process. These tools are
used by the SmartenIT implementation team to implement their respective components,
as well as by prototype integrators to produce a coherent, integrated system. The initial
implementation framework was briefly described in D3.2 [2], mainly involving all the
required tools and technologies used in the DTM prototype development and release. This
chapter presents the final implementation framework for the two integrated and released
prototypes, DTM and RB-HORST, including the tools used, and the final system tree
layout and deployment instructions. Standalone mechanisms’ implementation framework
will be presented in their respective chapters.

4.1

Tools

The implementation framework tools consist of a specification language for designing the
SmartenIT system, programming languages used to develop components, the libraries
used to support the software development, the tool chain for compiling and building the
source code, the version control platform for archiving source code, the issue tracking
system for organizing and planning the implementation work, as well as tracking and
resolving found bugs and issues, the continuous integration server for automatically
building system’s components and the validation testbed created to validate each
release’s features and functionalities.
4.1.1 Specification Language
The SmartenIT system is designed and modeled using UML specification language. As
also indicated in D3.2 [2], Microsoft Visio [5] is the key tool for the sequence, class,
architecture and deployment diagrams presented throughout this document.
4.1.2 Programming Languages
The selected programming languages for the SmartenIT entities are presented in Table
4-1.
Table 4-1: Entities’ programming languages.
Entity

Programming
Language(s)

Development Kit

SBox

Java

Oracle JDK 1.7.0_51 [6]

SDN Controller

Java

Oracle JDK 1.7.0_51 [6]

uNaDa

Java

Oracle JDK 1.7.0_51 [6]

End-User

Java

Android SDK API 14 [7]

Page 14 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

4.1.3 Libraries
The external dependencies of each component are presented in Table 4-2.
Table 4-2: Components’ libraries.
Entity

Component

Libraries
sqlite-jdbc-3.7.2

Database

jdbi 2.53
jackson-annotations 2.3.3

Interfaces
(Inter-SBox and SBox-SDN)

User Interface
SBox

netty 4.0.21.Final
jackson-databind 2.2.3
wiremock 1.46
javax.servlet 3.0
jsf-api, jsf-impl 2.2.6

QoS Analyzer

snmp4j 2.2.5

Economic Analyzer

commons-math3 3.0

Network Traffic Manager

netconf-java 1.0.1
slf4j 1.7.7

Commons

logback 1.1.2
commons-configuration 1.10
commons-logging 1.1.3
org.restlet, org.restlet.ext.jackson, org.restlet.ext.simple,
org.restlet.ext.slf4j 2.1-RC1
org.simpleframework 4.1.21
netty 3.2.6.Final
args4j 2.0.16
concurrentlinkedhashmap-lru 1.2

Floodlight
SDN
Controller

jython-standalone 2.5.2
libthrift 0.7.0
easymock 3.1
jsonassert 1.2.3
logback 1.0.0
slf4j 1.6.4

Interfaces

Database
uNaDa
User Interface

jackson-databind 2.2.3
jsonassert 1.2.3
h2 1.4.184
jdbi 2.53
javax.servlet 3.0
jsf-api, jsf-impl 2.2.6

Version 1.0

Page 15 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

restfb 1.6.16
Social Monitor

httpclient 4.3.5
simplelatlng RELEASE
tomp2p-all 5.0-Alpha24

Overlay Manager

jackson-databind 2.2.3
com.maxmind.geoip2 2.1.0

Topology Proximity Monitor

netty 4.0.21.Final

Cache Manager

vget 1.1.23

uNaDa-end-user inteface

jersey-media-json-jackson, jersey-test-frameworkprovider-jetty 2.12
slf4j 1.7.7

Commons

logback 1.1.2
commons-configuration 1.10
commons-logging 1.1.3
gson 2.3.1

End-User

App

android 4.1.1.4
facebook-sdk
support-v4 r7

4.1.4 Tool chain
Apache Maven [8] is used as the dependency management and build automation tool for
the SmartenIT prototype, as also defined in D3.2 [2]. The project’s system tree,
dependencies and build/execution commands are presented in Section 4.3.
4.1.5 Testbed
For the validation of both integration prototypes, the basic testbed design and extensions
were used. The initial design was defined in D3.2 [2] and further details on the basic
testbed’s design and configuration are provided in the D4.1 [4].
4.1.6 Version Control
Apache Subversion [9] is used as the version control system of SmartenIT. The
Subversion server is hosted and administrated by PSNC.
In addition to the internal SVN repository, the project consortium has setup a Github [10]
account and created a Github repository, to host and release the project’s source code as
open-source. The SmartenIT Github repository will be later presented in Section 4.4 and is
available at [39].
4.1.7 Issue Tracking
Atlassian Jira [11] is a software implementation management and issue-tracking tool, used
to organize and plan the work of developers and the integrator. The Atlassian Jira server
is hosted and administrated by PSNC.
Page 16 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

4.1.8 Continuous Integration Server
Jenkins [12] is a continuous integration tool, used to automatically and frequently build our
system. The Jenkins server is hosted and administrated by PSNC.

4.2

Procedures

A set of common software prototype development procedures was defined and agreed on
by the involved partners in order to assure a smooth and efficient prototype development
process and successful delivery of software in incremental releases.
This section includes information about the system release and development processes
(both represented in form of cycles) implemented in the project. Project partners played
specific roles in these processes. Specific types of meetings where organized throughout
the development process.
4.2.1 System Release Process
The SmartenIT system release process followed the agile development model and was
divided into (approximately) 2 month release cycles. Each release cycle (Figure 7)
consisted of:
Feature planning, where the consortium identified and prioritized features and tasks
for next release;
Development of the required features by the responsible partners;
Integration of the developed components and basic sanity tests;
System validation, where the developed system was tested in the testbed for the
required release features;
System release and preparation of system release report.

Figure 7: System release cycle.

Version 1.0

Page 17 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

4.2.2 Development Process
The SmartenIT development process utilized the concept of continuous integration, in
which developers commit frequently (daily if possible) their code, aiming to prevent
integration problems and identify issues rapidly. This process was supported by
automated tools such as Jenkins (see Section 4.1.8).
The implementation process (Figure 8) comprised 4 phases:
Developers write code and tests,
Perform unit tests locally,
If tests pass, then commit their code to the repository, and
In case the build fails they are notified to fix the issue, otherwise continue their
development work.

Figure 8: Development process.
4.2.3 Roles
A set of roles involved in the overall implementation process was decided that would
support processes that are described above. Each role was assigned a list of
responsibilities and responsible project partner. Those roles and related assignments are
presented in Table 4-3.
Table 4-3: Defined roles in the development process.
Role

Responsibilities

Responsible
Partner

Responsible
Person

Product Manager Sets the high-level
requirements and features of
each release.

ICOM

Spiros Spirou

Tools
Administrator

PSNC
(&ICOM)

Jakub Gutkowski

Manages and maintains
implementation framework
tools.

Page 18 of 191

Łukasz Łopatowski

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Release Master

Provides access to tools.

George Petropoulos

Facilitates the system release ICOM
process.
(&PSNC)

George Petropoulos
Łukasz Łopatowski

Contact point of the
implementation team.
Implementation
Team

Consists of all the people,
responsible for the design,
development, integration,
testing and deployment of the
SmartenIT prototype.

UZH, TUD,
AGH, ICOM,
ALBLF,
PSNC

As appointed by
each Partner.

4.2.4 Meetings
In each release cycle defined in Section 4.2.1, three types of the meetings took place:
feature planning meeting, weekly meeting and release review meeting. For more details
please see Section 5.2.4 in D3.2 [2].

4.3

System tree layout

D3.2 [2] presented the initial system tree layout of the SmartenIT source code, including
only the DTM entities and components. This section will define the final system tree
layout, including the RB-HORST entities and components.
The SmartenIT source code is organized as a Maven [8] multi-module project. Each entity
(sbox, sdn, unada, enduser, network, dist) is also a Maven multi-module project,
which can be packaged as a single jar with the use of a certain maven plug-in (mavenassembly-plugin). Each entity’s component (e.g. main, interfaces) is a Maven module,
which may be divided into further maven modules or packages, based on component
owner’s preferences. In the defined system tree, certain components were divided into
sub-modules to isolate developers’ work, as well as avoid possible dependencies’
conflicts.
The final SmartenIT system tree is presented below. Parentheses define the type of
packaging, indicating whether a module either consists of other sub-modules (pom
packaging), or is packaged as a (a) Java archive (jar), which aggregates all classes and
configuration files into one single executable, (b) a Web application archive (war) which
compresses all classes, Web pages, and resources into one executable which can be
deployed to any Web server, (c) an Android library (aar), (d) an Android archive (apk),
which compresses all classes, resources and files, which can be installed in an Android
device.
smartenit (pom)
o sbox (pom)

main (jar)

interfaces (pom)
inter-sbox (pom)

Version 1.0

Page 19 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o client (jar)
o server (jar)
sbox-sdn (jar)

db (pom)
dao (jar)
dto (jar)

web (war)

ntm (jar)

qoa (jar)

eca (jar)

commons (jar)

o sdn (pom)

floodlight-0.90 (jar)

interfaces (pom)
sbox-sdn (jar)

o unada (pom)

interfaces (pom)
unada-enduser (jar)

db
dao (jar)
dto (jar)

ctm (pom)
cache (jar)

tpm (jar)

om (jar)

sa (jar)

web (war)

sm (jar)

commons (jar)

o enduser (pom)

app (pom)
facebook (aar)
SIT (apk)

Page 20 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

SIT-TEST (apk)
o network (pom)
o dist (pom)
The system can be built with the use of the following command at the smartenit base
directory:
mvn clean install
The aforementioned command, cleans all previously generated artifacts, compiles,
packages and installs all modules, as well as runs all test cases. To avoid executing all
test cases, the user may execute the following command:
mvn clean install -DskipTests
All the aforementioned commands also generate the SmartenIT software release artifact,
which is the smartenit-${project.version}.zip, created at the dist/target
directory.
The final release which implements the two integrated and released prototypes, DTM and
RB-HORST, the zip file contains the following executables and configuration files per
entity:
sbox
o main.jar: The main executable of the SBox application, which initializes all
modules, and executes the DTM mechanism.
o web.war: It’s the war file, deployed to the Jetty Web server.
o sbox.properties: It includes all the required SBox configuration
parameters.
o logback.xml: It defines the logging level of the SBox application.
o realm.properties, jetty.xml: Configuration files that override default
Jetty configuration.
sdn
o floodlight-0.90.jar: The executable of the Floodlight SDN controller,
extended with SmartenIT functionality.
unada
o unada.war: The executable of the uNaDa software, which is deployed in
the Jetty Web server and executes the RB-HORST mechanism.
o unada.sh: A script that automatically starts the uNaDa processes.
o vimeo_proxy.py: A script used during initialization of mitmproxy software
for proxying and filtering end-user requests.
enduser:
o sit-app.apk: The HORST Android application, which will be deployed in
an Android smartphone or tablet.

Version 1.0

Page 21 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

4.4

Open-Source releases

The SmartenIT consortium has decided to release its major releases as open-source, in
order to be accessible by academic and research communities. For that purpose, a Github
[10] account and a repository were created (see Figure 9), available at [39]. The source
code is available under Apache v2 license [18].

Figure 9: SmartenIT Github repository.
Each time the integrated prototype was tested and internally released, the integration
team was also pushing the source code to the Github repository. Therefore, releases 1.1,
1.2, 2.1 and 3.0 were committed to the Github repository, while it is planned that final
version 3.1 will be also released to the general public.

4.5

Deployment Instructions

This section will provide the instructions to deploy the DTM and RB-HORST executables
to the targeted hardware.
The prerequisites to deploy and run the DTM executables are:
Oracle JDK 7 update 51 (Configure JAVA_HOME and PATH) [6],
Jetty 9.2.3.v20140905 (Configure JETTY_HOME and PATH) [13],
Sqlite 3 [14].
To deploy and run the SBox entity, check the following instructions:
Page 22 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

1. Copy (and replace) the jetty.xml and realm.properties included in jetty-conf folder to
the $JETTY_HOME/etc directory: cp sbox/web/jetty-conf/jetty.xml
$JETTY_HOME/etc/jetty.xml;
cp
sbox/web/jettyconf/realm.properties $JETTY_HOME/etc/realm.properties
2. Copy the provided sbox.war file to the $JETTY_HOME/webapps directory: cp
sbox/web/sbox.war $JETTY_HOME/webapps/sbox.war
3. Initialize jetty ($JETTY_HOME/
module=https

directory):

java

-jar

start.jar

--

4. Open a Web browser and browse at https://<machine-ip-address>/sbox/admin or
http://<machine-ip-address>:8080/sbox/admin, where <machine-ip-address> is the
SBox's ip address (or localhost). Signin with admin/admin credentials.
5. Edit the sbox.properties file with the correct path to the smartenit.db file, and the
rest of required parameters.
6. To run the main SBox application: java -jar sbox.jar
To deploy and run the SDN Controller:
1. To run the extended SDN Controller: java -jar sdn.jar
The prerequisite software to deploy and run the RB-HORST mechanism entities are:
Oracle JDK 7 update 51 (Configure JAVA_HOME and PATH) [6],
Jetty 9.2.3.v20140905 (Configure JETTY_HOME and PATH) [13],
h2 [15],
lighttpd (Modify "server.document-root" of /etc/lighttpd/lighttpd.conf file to be equal
to $HOME directory, e.g. server.document-root = "/home/pi") [16],
mitmproxy (pip install mitmproxy) [17].
To deploy and run the uNaDa entity:
1. Copy
vimeo_proxy.py
~/vimeo_proxy.py

to

$HOME

directory:

cp

vimeo_proxy.py

2. Start the mitmproxy software ($HOME/ directory): mitmdump -T --host -s
vimeo_proxy.py
3. Copy the unada.war to $JETTY_HOME/webapps/:
$JETTY_HOME/webapps/unada.war

cp

unada.war

4. Add a relevant iptables rule to proxy all HTTPs requests to the mitmproxy: sudo
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j
REDIRECT --to-port 8080
5. Initialize Jetty ($JETTY_HOME/ directory):
etc/jetty.xml -Djetty.port=8181

java

-jar

start.jar

6. uNaDa Web interface is available at: http://192.168.40.1:8181/unada. If you are the
owner of the uNaDa you must login with your Facebook credentials.
To install the end-user entity:
1. Copy the sit-app.apk to the Android device, accept permissions and install it.
Version 1.0

Page 23 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

5 The Dynamic Traffic Management (DTM) mechanism
DTM is used to manage traffic exchanged between domains in which a Cloud or Data
Center (DC) is located. It is deployed by network operators on servers on both sides of an
inter-DC communication, since operators need to cooperate to achieve traffic transfer cost
reduction.
DTM functionalities, as defined in Deliverable D2.4 [26], map onto two architecture
entities, namely SBox and SDN Controller. Subsequent sections provide detailed
descriptions of the implemented software components being part of the respective entities.
Moreover the DTM specification defines two types of ISP network elements which are
involved in the network configuration which enables the DTM operations:
Data center Attachment point (DA): A point (router or switch) where DC inbound
and outbound traffic is passed to an ISP network;
Border Router (BG): An ISP border router on which inter-domain links are
terminated.
These devices are configured accordingly to the DTM specification however no SmartenIT
software is running on them.

5.1

SBox

SBox main functionalities comprise retrieving and aggregating SNMP measurements from
the network entities, calculating and distributing compensation and reference vectors,
delay-tolerant traffic management and finally, configuring the remote SDN Controller.
It includes certain components that are required to store and access DTM parameters
(Database and User Interface), retrieve and aggregate monitoring data from the network
devices (Quality of Service Analyzer), perform necessary calculations (Network Traffic
Manager, Economic Analyzer) and also interact with remote SBoxes and the SDN
Controller (Inter-SBox and SBox-SDN Communication Services).
Each component’s functionality, interfaces, design and finally unit tests are further
described in the following sections.
5.1.1 Quality of Service Analyzer
The Quality of Service (QoS) Analyzer component is responsible for periodical execution
of the following actions:
collection of incoming traffic counter values from all inter-domain links from a set of
configured BG routers;
collection of incoming traffic counter values from all tunnels from a set of configured
DA or BG routers (depending on which router given tunnel is terminated);
calculation of link traffic vector (X vector) and a list of tunnel traffic vectors (Z
vector) for each local AS;
distribution of information about new traffic vectors to Economic Analyzer and
Network Traffic Manager components;

Page 24 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

archiving of traffic statistics in form of a text file.
The QoS Analyzer component supports two traffic charging rules defined in the system,
namely the total traffic volume based rule and the 95th percentile rule. Certain rule can be
enabled in the SBox user interface presented in Section 5.1.7 on the DTM settings page.
The above listed actions are executed at intervals specific to the used charging rule. In the
case of total traffic volume based rule, the calculation of vectors and the distribution of
information is performed at intervals defined by the length of the so called reporting
period. When the latter rule is enabled two different intervals are used, i.e. DTM reporting
period (X vector calculated and sent to NTM) and EA reporting period (X and Z vectors
sent to EA).
Counter values collection from network devices is performed by means of SNMP.
In order to improve performance and ensure that counters from all routers are read almost
exactly at the same moment, counters are read in multiple parallel threads (one thread per
router).
5.1.1.1 Interfaces
The QoS Analyzer does not provide any methods to be called by other SBox components.
5.1.1.2 Design
The QoS Analyzer consists of 23 classes organized into two packages:
eu.smartenit.sbox.qoa – main package;
eu.smartenit.sbox.qoa.experiment – extension to the QoS Analyzer
component added in order to support experimenters from WP4 with the ability to
store traffic statistics in form of a text file.
Following is the description of the most important classes from the main package of QoS
Analyzer component (see Figure 10). Please note that only public methods are listed.
DTMQosAnalyzer: Main class of the QoS Analyzer component. Communicates
with Economic Analyzer (EconomicAnalyzer class) and Network Traffic Manager
(DTMTrafficManager class).
o public DTMQosAnalyzer(DTMTrafficManager trafficManager,
EconomicAnalyzer
economicAnalyzer): The constructor with
arguments: instances of DTM external interface classes of Network Traffic
Manager and Economic Analyzer;
o public void initialize(): Initializes SNMPTrafficCollector class and
starts scheduled traffic counters values collection tasks according to
configured time schedule parameters;
o public void updateXVector(XVector xVector): Updates Network
Traffic Manager (DTMTrafficManager class) with link traffic vector calculated
after reporting period (or DTM reporting period);
o public
void
updateXZVectors(XVector
xVector,
List<ZVector> zVectors): Updates Economic Analyzer with link traffic

Version 1.0

Page 25 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

vector and a list of tunnel traffic vectors calculated after reporting period (or
EA reporting period).
SNMPTrafficCollector: Class used to schedule traffic counter collection tasks
and calculating traffic vectors once all counters are read after each reporting period
(or DTM reporting period). Calculated vectors are provided to DTMQosAnalyzer for
further distribution.
o public SNMPTrafficCollector(DTMQosAnalyzer analyzer): The
constructor with argument: instance of the DTMQosAnalyzer which should
be updated with calculated traffic vectors;
o public
void
configure(List<AS>
systems,
List<DC2DCCommunication> communications): Populates helper
data structures with links and tunnels that will be monitored. Triggers
collection of SNMP OID numbers for links and tunnels counters;
o public void scheduleMonitoringTasks(): Schedules counters
values collection tasks according to configured time schedule parameters;
o public
void
notifyNewCounterValues(int
asNumber,
CounterValues counterValues): Calls MonitoringDataProcessor to
calculate new link traffic vectors with data fetched from counters. Updates
DTMQosAnalyzer with the new link and tunnel traffic vectors;
o public MonitoredLinksInventory getMonitoredLinks(): Getter
method for monitored links inventory;
o public MonitoredTunnelsInventory getMonitoredTunnels():
Getter method for monitored tunnels inventory.
TrafficCollectorTask: Task class responsible for collecting counter values
from BG and DA routers. Implements Runnable interface.
o public
TrafficCollectorTask(SNMPTrafficCollector
trafficCollector, int asNumber): The constructor with arguments:
instance of the SNMPTrafficCollector from which information about
monitored links and tunnels will be read and which will be notified once all
counters are read; and number of the AS for which this task is launched
(relevant if SBox manages more than one AS);
o public void run(): Method launched when thread is started.
Responsible for fetching data from router counters and updating
SNMPTrafficCollector with collected data.
CounterCollectorThread: Thread class responsible for collecting counter
values from specific interfaces of a given router. Implements Callable interface.
o public
CounterCollectorThread(List<Link>
links,
List<Tunnel> tunnels,
BGRouter bgRouter): The constructor
with arguments to be used when monitoring a BG router;
o public
CounterCollectorThread(List<Tunnel>
tunnels,
DARouter daRouter): The constructor with arguments to be used when
monitoring a DA router;

Page 26 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public CounterValues call() throws Exception: Thread's main
method responsible for fetching data from counters on given router and
updating TrafficCollectorTask.
SNMPWrapper: Wrapper class for the snmp4j library.
o public String snmpGet(OID oid, Target target): Triggers
snmpget command on given router specified by target argument and
given OID (object identifier). Returns the response received from the SNMP
agent;
o public List<String> snmpWalk(OID oid, Target target):
Triggers snmpwalk command on given router specified by target
argument and given OID. Returns the response received from the SNMP
agent;
o public void startClient() throws IOException: Starts SNMP
client;
o public void stopClient() throws IOException: Stops SNMP
client;
o public Target prepareTarget(String routerAddress, String
snmpCommunity): Prepares Target class instance with router address and
SNMP community to be used in snmpGet and snmpWalk method calls;
o public OID prepareOID(String oid): Prepares OID class instance
to be used in snmpGet and snmpWalk method calls.
SNMPOIDCollector: Helper class for preparing SNMP OID numbers for link and
tunnel counters.
o public SNMPOIDCollector(MonitoredLinksInventory links,
MonitoredTunnelsInventory tunnels): The constructor with two
arguments: links and tunnels to be monitored;
o public void collectOIDsForLinks() throws IOException:
Triggers OID information collection for all link counters from all BG routers;
o public void collectOIDsForTunnels() throws IOException:
Triggers OID information collection for all tunnel counters from all DA and
BG routers.
MonitoringDataProcessor: Used to handle monitoring data (i.e. counter
values) and calculating link traffic vector and tunnel traffic vectors by means of
XVectorCalculator class and ZVectorCalculator class, respectively.
o public
MonitoringDataProcessor(MonitoredLinksInventory
monitoredLinks,
MonitoredTunnelsInventory
monitoredTunnels): The constructor with two arguments: all monitored
links and tunnels;
o public
XVector
calculateXVector(int
asNumber,
CounterValues
lastValues,
CounterValues
newValues):
Calculates link traffic vector by means of XVectorCalculator class based on
provided counter values for inter-domain links of given AS;
Version 1.0

Page 27 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public
List<ZVector>
calculateZVectors(int
asNumber,
CounterValues
lastValues,
CounterValues
newValues):
Calculates a list of tunnel traffic vectors by means of ZVectorCalculator class
based on counter values for tunnels in given AS.
o public ZVector aggregateZVectors(List<ZVector> zVectors):
Aggregates vector values from given tunnel traffic vectors and returns a
single Z vector.
VectorCalculator: Base abstract class for traffic vector calculators comprising
data structure used to store counter values from previous reporting periods.
o protected
CounterValues
getOrCreateLatestVectorValues
(int asNumber): Returns stored instance of CounterValues for given AS if
exists. If not, creates and returns new instance.
XVectorCalculator: Implements link traffic vector calculation based on current
counter values collected from links in given AS and previous values of those
counters. Extends VectorCalculator class.
o public
XVector
calculateXVector(int
asNumber,
CounterValues lastValues, CounterValues newValues): Method
calculates new link traffic vector for given AS. It should be launched after
each reporting period.
ZVectorCalculator: Implements tunnel traffic vector calculation based on
current counter values collected from tunnels in given AS and previous values of
those counters. Extends VectorCalculator class.
o public
ZVectorCalculator(MonitoredTunnelsInventory
monitoredTunnels): The constructor with all monitored tunnels as an
argument;
o public
List<ZVector>
calculateZVectors(int
asNumber,
CounterValues lastValues, CounterValues newValues): Method
calculates new set of tunnel traffic vectors for given AS. Each ZVector class
object corresponds to a single DC2DCCommunication. It should be launched
after each reporting period.
CounterValues: Data container class used to store counter values (as 64bit
numbers) on per LinkID and per TunnelID basis.
o public
void
storeCounterValue(LinkID
linkID,
counterValue): Stores counter value for given link in the structure;

long

o public void storeCounterValue(TunnelID tunnelID, long
counterValue): Stores counter value for given tunnel in the structure;
o public
void
addLinksAndTunnels(CounterValues
counterValues): Populates the local structure with provided links and
tunnels counters data;
o public
void
addCounterValue(LinkID
linkID,
long
counterValue): Adds counter value to existing entry in the structure or
creates a new entry.

Page 28 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public Map<LinkID, Long> getLinkCounterValues(): Retrieves
counter values for all links stored in the structure;
o public
Map<TunnelID,
Long>
getTunnelCounterValues():
Retrieves counter values for all tunnels stored in the structure;
o public Set<LinkID> getAllLinkIds(): Retrieves identifiers of all
links stored in the structure;
o public Set<TunnelID> getAllTunnelsIds(): Retrieves identifiers of
all tunnels stored in the structure;
o public Long getCounterValue(LinkID linkID): Retrieves 64-bit
counter value for given link from the structure;
o public Long getCounterValue(TunnelID tunnelID): Retrieves 64bit counter value for given tunnel from the structure.
o public
List<LocalVectorValue>
toLocalVectorValues():
Returns new list of LocalVectorValue based on stored counter values for
links.
MonitoredLinksInventory: Data container class used to store information
about routers and monitored links on per AS number basis. Provides specific query
methods to retrieve information.
o public void populate(List<AS> systems): Method to be called to
populate inventory with monitored link information that is obtained from list of
local Autonomous Systems;
o public List<Link> getLinks(int asNumber): Retrieves all interdomain links for given local AS;
o public List<Link> getLinks(BGRouter bgRouter): Retrieves all
links from given BG router;
o public List<BGRouter> getBGRouters(): Retrieves all BG routers
stored in the structure;
o public
List<BGRouter>
getBGRoutersByAsNumber(int
asNumber): Retrieves all BG routers from given local AS;
o public int getAsNumber(BGRouter bgRouter): Returns number of
the AS to which given BG router belongs;
o public Set<Integer> getAllAsNumbers(): Returns numbers of all
local ASs stored in the structure.
MonitoredTunnelsInventory: Data container class used to store information
about DA routers and monitored tunnels. Provides specific query methods to
retrieve information.
o public
void
populate(List<DC2DCCommunication>
communications): Method to be called to populate inventory with
monitored tunnels information that is obtained from list of
DC2DCCommunications terminated in local ASs.

Version 1.0

Page 29 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public List<Tunnel> getTunnels(int asNumber): Retrieves all
monitored tunnels from given local AS;
o public Tunnel getTunnel(TunnelID tunnelID, int asNumber):
Retrieves Tunnel instance for given TunnelID;
o public
List<Tunnel>
getTunnels(DARouter
Retrieves all monitored tunnels from given DA router;

daRouter):

o public
List<Tunnel>
getTunnels(BGRouter
Retrieves all monitored tunnels from given BG router;

bgRouter):

o public List<Tunnel> getTunnels(DC2DCCommunicationID id):
Retrieves all tunnels from inter-DC communication with given identifier;
o public List<DARouter> getDARouters(): Retrieves all DA routers
stored in the inventory;
o public
List<DARouter>
getDARoutersByAsNumber(int
asNumber): Retrieves all DA routers from given local AS;
o p. List<DC2DCCommunicationID> getAllDC2DCCommunicationIDs
(int asNumber): Retrieves identifiers of all inter-DC communications
terminating in given local AS;
o public Set<Integer> getAllAsNumbers(): Retrieves numbers of all
local ASs stored in the inventory.

Page 30 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 10: Quality of Service Analyzer class diagram.
The classes contained in the eu.smartenit.sbox.qoa.experiment package of QoS
Analyzer are described below (see Figure 11):
ExtendedSNMPTrafficCollector: Extends SNMPTrafficCollector class to
enable writing traffic details to file.

Version 1.0

Page 31 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public
ExtendedSNMPTrafficCollector(DTMQosAnalyzer
analyzer): The constructor with arguments;
o public
boolean
configure(List<AS>
systems,
List<DC2DCCommunication> communications): Populates helper
data structures with links and tunnels that will be monitored. Triggers
collection of SNMP OID numbers for links and tunnels counters;
o public void scheduleMonitoringTasks(): Schedules counters
values collection task according to configured time schedule parameters;
o public
void
notifyNewCounterValues(int
asNumber,
CounterValues counterValues): Calls MonitoringDataProcessor class
to calculate new link traffic vectors with data fetched from counters. Updates
DTMQosAnalyzer class with the new link and tunnel traffic vectors. Extended
to enable writing traffic details to file.
ExtendedTrafficCollectorTask:
enable writing traffic details to file.

Extends

TrafficCollectorTask

class

to

o public void run(): Scheduled task responsible for fetching data from
router counters and updating SNMPTrafficCollector class with collected data.
ExtendedCounterCollectorThread: Extends CounterCollectorThread class to
enable writing traffic details to file.
o public ExtendedCounterCollectorThread(List<Link> links,
List<Tunnel> tunnels, BGRouter bgRouter): The constructor with
arguments to be used when monitoring BG router;
o public
ExtendedCounterCollectorThread(List<Tunnel>
tunnelsByDARouter, DARouter daRouter): The constructor with
arguments to be used when monitoring DA router.
ExtendedCounterValues: Extends CounterValues class to enable writing traffic
details to file.
o public
void
storeReceivedPackets(LinkID
linkID,
ReceivedPackets packetsInfo): Method used to store the number of
received packets on link;
o public
void
storeReceivedPackets(TunnelID
tunnelID,
ReceivedPackets packetsInfo): Method used to store the number of
received packets on tunnel;
o public
ExtendedCounterValues
calculateDifference
(ExtendedCounterValues
toBeSubtracted): Method used to
calculate difference between stored and provided values for all links and
tunnels;
o p… Map<LinkID, ReceivedPackets> getLinkReceivedPackets():
Returns map with number of packets for all links;
o public
Map<TunnelID,
ReceivedPackets>
getTunnelReceivedPackets(): Returns map with number of packets for
all tunnels.

Page 32 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

ReceivedPackets: Data container class used to store information about the
number of three types of packets.
o public ReceivedPackets(long unicast, long
long broadcast): The constructor with arguments;

multicast,

o public long aggregate(): Method used to calculate packets sum;
o public
ReceivedPackets
calculateDifference
(ReceivedPackets toBeSubtracted): Method used to calculate
difference between stored and provided values;
o public long getUnicast(): Returns amount of unicast packets;
o public long getMulticast(): Returns amount of multicast packets;
o public long getBroadcast(): Returns amount of broadcast packets.
ExtendedSNMPOIDCollector: Extends SNMPOIDCollector class to enable
writing traffic details to file.
o public
ExtendedSNMPOIDCollector(MonitoredLinksInventory
links, MonitoredTunnelsInventory tunnels): The constructor
with arguments.
FileManager: File manager class created to enable writing traffic details to file.
o public void updateFile(String path, String fileName,
String newRecord): Method used to update file with new record.

Figure 11: Class diagram for extension to Quality of Service Analyzer.
Version 1.0

Page 33 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Sequence diagram in Figure 12 presents how the Quality of Service Analyzer interacts
with other SBox components, i.e. the Economic Analyzer and Network Traffic Manager.
After the TrafficCollectorTask finishes its execution, meaning that all counter values
are read from monitored routers, it passes new counter values to the
SNMPTrafficCollector which in turn instructs MonitoringDataProcessor to
calculate new X and Z vectors. Later on the QoSAnalyzer is used to pass information
about those new vectors to proper EconomicAnalyzer and DTMTrafficManager
instances.

Figure 12: Quality of Service Analyzer sequence diagram.
5.1.1.3 Tests
In order to test the functionality of the Quality of Service Analyzer a set of 22 test classes
was implemented comprising JUnit [19] tests for not only particular single methods or
group of methods but also simple workflows internal to QoS Analyzer component. Mockito
library [21] was used in several cases to mock components external to QoS Analyzer, e.g.
Database, Economic Analyzer and Network Traffic Manager.
The implemented test classes with test methods are listed below (please note that all
provided names of test methods are preceded with public void in the source code):
DTMQosAnalyzerTest contains test methods for DTMQosAnalyzer class
workflow launched after each reporting period including: new counter values
collection from routers, traffic vectors calculation and Economic Analyzer and
Network Traffic Manager updates:
o shouldUpdateXAndZVectors()
o shouldReturnFalseForInitialization()
SNMPTrafficCollectorTest
SNMPTrafficCollector class:

contains

following

test

methods

for

o shouldCalculatXVextor()
Page 34 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o shouldCalculaZXVextors()
o shouldUpdateXVector()
o shouldUpdateZVectors()
o shouldTriggerFiveScheduledTasks()
o shouldPrepareLogForScheduleMonitoringTasks()
o shouldPrepareErrorForAsNumbersValidation()
o shouldCalculateInitialDelay()
TrafficCollectorTaskTest
TrafficCollectorTask class:

contains

following

test

method

for

o shouldNotifyNewCounterValues()
TrafficCollectorTaskFailureScenarioTest contains following test method
for TrafficCollectorTask class:
o shouldMaxFetchingTimeExpire()
BGRouterCounterCollectorThreadTest contains following test methods for
collecting counter values from specific interfaces of BG routers:
o shouldParseCounter()
o shouldThrowExceptionForParseCounter()
o shouldThrowExceptionBecauseOfLackOfBGRouter()
o shouldThrowExceptionBecauseOfLackOfLinks()
o shouldCalculateCounterValues()
DARouterCounterCollectorThreadTest contains following test methods for
collecting counter values from specific interfaces of DA routers:
o shouldParseCounter()
o shouldThrowExceptionForParseCounter()
o shouldThrowExceptionBecauseOfLackOfDARouter()
o shouldThrowExceptionBecauseOfLackOfTunnels()
o shouldCalculateCounterValues()
SNMPWrapperTest contains following test methods for SNMP4J library wrapper
class named SNMPWrapper:
o shouldThrowExceptionForTimedOutForSnmpget()
o shouldThrowExceptionForNullResonseForSnmpget()
o shouldThrowExceptionBecauseOfErrorForSnmpget()
o shouldStarClient()
o shouldStopClient()
o shouldNotStopClient()
o shouldPrepareTargetForTheAddressWithPort()
o shouldThrowExceptionBecauseOfSnmpSendException()
Version 1.0

Page 35 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o shouldThrowExceptionBecauseOfLackOfSnmpClient()
SNMPOIDCollectorTest contains following test methods for SNMPOIDCollector
class:
o shouldParseInterfaceNumber()
o shouldSetOutboundInterfaceCounterOID()
o shouldSetInboundInterfaceCounterOID()
o shouldCollectOIDsForLinks()
o shouldCollectOIDsForTunnels()
o shouldThrowExceptionBecauseOfLackOfSnmpWalkResponse()
o shouldThrowExceptionBecauseOfLackOfPhysicalInterfaceName
()
XVectorCalculationTest contains following test methods for link traffic vector
calculation logic implemented by XVectorCalculator class and triggered by
MonitoringDataProcessor class:
o shouldCalculateFirstXVector()
o shouldCalculateSecondXVector()
o shouldCalculateLaterXVector()
o shouldCalculateXVectorEvenIfCounterValueIsLessThanZero()
o shouldCalculateXVectorWithLastXVector()
ZVectorCalculationTest contains following test methods for tunnel traffic
vector calculation logic implemented by ZVectorCalculator class and triggered by
MonitoringDataProcessor class:
o shouldCalculateFirstZVectors()
o shouldCalculateSecondRoundOfZVectors()
o shouldCalculateZVectorsWithLastZVectors()
ZVectorsAggregationTest
aggregation:

contains following test method for Z vector

o shouldAggregateZVectors()
CounterValuesTest contains following test methods for store and get methods
of CounterValue class:
o shouldStoreOneLinkAndTunnelEntry()
o shouldStoreTwoEntries()
o shouldReplaceOneOfTwoEntries()
o shouldValidateTwoCounterValueInstancesAsEqual()
o shouldAddCounterValueToExistingEntry()
o shouldCreateNewEntryWhenAddingCounterValue()
o shouldConverToListOfLocalVectorValues()

Page 36 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

MonitoredLinksInventoryTest contains following test method for population
and data retrieval methods of MonitoredLinksInventory data container class:
o shouldPopulateInventory()
MonitoredTunnelsInventoryTest contains following test methods for
population and data retrieval methods of MonitoredTunnelsInventory data container
class:
o shouldPopulateInventoryAndExecuteQueries()
o shouldPopulateInventoryWithSomeTunnelsAtBGRouters()
BGRouterTunnelTest contains following test method for tunnels terminated at
BG routers:
o

shouldFetchDataForTunnels()

QoaLogicTest contains following test method for analyzing Quality of Service
Analyzer component logic:
o shouldSendProperXAndZVectors()
SNMPTrafficCollectorSupportFor95thPercentileTest
following test method for 95th percentile charging rule:

contains

o shoulNotifyNewCounterValuesFor95thPercentile()
ExtendedCounterValuesTest
ExtendedCounterValues class:

contains

following

test

methods

for

o shouldStoreOneLinkAndTunnelEntry()
o shouldReplaceOneOfTwoEntries()
o shouldCalculateDifference()
FileManagerTest contains following test method for operations allowing file
updates:
o shouldCreateFile()
LogToFileTest contains following test method for traffic details log generation
and storage to file:
o shouldLogToFile()
LogToFileWithBGRouterTunnelsTest contains following test method for
traffic details log generation in case when tunnels are terminated at BG routers:
o shouldLogToFile()
TrafficDetailsWriteToFileTest contains following test method for traffic
details log generation:
o shouldWriteTrafficDetailsToFile()
5.1.2 Network Traffic Manager
The main functionalities provided by the Network Traffic Manager (NTM) can be grouped
into two sets. When NTM is running on SBox deployed in AS that receives data traffic

Version 1.0

Page 37 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

generated by one or multiple inter-DC communications, NTM provides the following
functionalities:
periodically receives information about link traffic vectors from QoS Analyzer
calculated after each reporting period and about reference vectors calculated by
Economic Analyzer after each accounting period;
calculates a new compensation vector after each link traffic or reference vector
update using the algorithm specified in Section 5.1.2.2.1;
sends the compensation vector (with the reference vector after accounting period)
to remote SBox instances that are deployed in ASs from which the received data
traffic originated;
(if delay tolerant traffic management is enabled) at the beginning of new accounting
period configures policers on the underlying BG routers with bandwidth limits for
each link;
when informed by the Economic Analyzer during an accounting period that on
some links the reference vector has been already achieved undertakes appropriate
actions: calculates next compensation vectors according to the algorithm specified
in Section 5.1.2.2.2 and (if delay tolerant traffic management is enabled)
deactivates filters on given links on BG routers till the end of current accounting
period.
When considering SBox located at the data traffic sender end of an inter-DC
communication, the NTM is responsible for:
initial configuration of the underlying SDN controllers (by means of SBox-SDN
Client) with information about tunnels established between local and remote DCs,
corresponding DA router ports and remote DC prefixes;
receive compensation and reference vectors from the Inter-SBox Communication
Service server and distributing them to the SDN controllers that will distribute the
outgoing traffic among all configured tunnels accordingly.
The NTM component supports two traffic charging rules defined in the system, namely the
total traffic volume based rule and the 95th percentile rule.
In a general case, the SBox and therefore the NTM supports both ends of inter-DC
communication since DCs in a local AS will most likely both receive and send traffic
from/to remote ASs at the same time.
5.1.2.1 Interfaces
The Network Traffic Manager provides in total 5 methods to be called by other SBox
components. Three of them are implemented by DTMTrafficManager class:
public
void
updateXVector(XVector
xVector)
throws
IllegalArgumentException: Method called by QoS Analyzer to update
information about link traffic vector calculated every reporting period.
o Input parameters:

xVector: New link traffic vector

Page 38 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o Thrown exceptions:

IllegalArgumentException when given xVector argument is invalid

public
void
updateRVector(LocalRVector
rVector)
throws
IllegalArgumentException: Method called by Economic Analyzer to update
information about reference vector calculated every accounting period.
o Input parameters:

rVector: New reference vector

o Thrown exceptions:

IllegalArgumentException when given rVector argument is invalid

public
void
updateLinksWithRVectorAchieved(int
asNumber,
List<LinkID> links) throws IllegalArgumentException: Method
called by Economic Analyzer to update information about inter-domain links in
given AS for which the reference vector has been already achieved in the current
accounting period.
o Input parameters:

asNumber: Number of the AS to which provided links belong

links: List of inter-domain links

o Thrown exceptions:

IllegalArgumentException when provided list is null or empty

The
remaining
two
interface
methods
are
implemented
by
DTMRemoteVectorsReceiver class and are called by Inter-SBox Communication
Service server component.
public
void
receive(CVector
cVector)
throws
IllegalArgumentException: Method called to update information about
compensation vector calculated every reporting period in remote SBox.
o Input parameters:

cVector: Compensation vector calculated in remote SBox

o Thrown exceptions:

IllegalArgumentException when given cVector argument is invalid

public void receive(CVector cVector, RVector rVector) throws
IllegalArgumentException: Method called to update information about
compensation and reference vectors calculated every reporting and accounting
period, respectively in remote SBox.
o Input parameters:

cVector: Compensation vector calculated in remote SBox

rVector: Reference vector calculated in remote SBox

o Thrown exceptions:
Version 1.0

Page 39 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

IllegalArgumentException when either of given vector arguments is
invalid

5.1.2.2 Design
The NTM component implementation consists of 25 classes. Its main functionalities fall
into two areas related with reacting on incoming traffic volumes by providing compensation
and reference vectors to remote SBoxes and adapting BG routers configuration for delay
tolerant traffic handling as well as outgoing traffic distribution by means of SDN based on
received compensation and reference vectors. These functionalities are implemented by
disjoint sets of classes depicted in Figure 14 and Figure 19, respectively.
In Figure 13 a top level view on the NTM design is presented with classes that are used by
other components of the SBox:
NetworkTrafficManager: Main class of the Network Traffic Manager
component. Represents an entry point for the NTM component common for all the
implemented traffic management mechanisms. Manages the lifecycle of the major
NTM internal objects that implement traffic management mechanisms interfaces
and logic.
o public void initialize(): Method that should be called in order to
initialize the NTM component (e.g. read required data from data base) in
default DTM mode.
o public
void
initialize(NetworkTrafficManagerDTMMode
mode): Method that should be called in order to initialize the component in
provided NetworkTrafficManagerDTMMode mode.
o public DTMTrafficManager getDtmTrafficManager(): Returns an
instance of DTMTrafficManager class that should be used by QoS Analyzer
and Economic Analyzer to provide updated vectors to DTM logic
implemented as part of the Network Traffic Manager.
o public DTMRemoteVectorsReceiver getDtmVectorsReceiver():
Returns an instance of DTMRemoteVectorsReceiver class that should be
used by Inter-SBox Communication Service server to provide received
remote vectors to DTM logic implemented as part of the Network Traffic
Manager.
NetworkTrafficManagerDTMMode: Enumeration class that represents three
DTM running modes:
o TRAFFIC_SENDER: DTM instance is run on SBox that manages AS(s) that
only sends traffic to remote ASs. In this case some of the modules do not
need to be initialized.
o TRAFFIC_RECEIVER: DTM instance is run on SBox that manages AS(s)
that only receives traffic from remote ASs. In this case some of the modules
do not need to be initialized.
o TRAFFIC_SENDER_AND_RECEIVER: General case enabled by default.
DTMTrafficManager: Implements DTM external interface methods that are used
by QoS Analyzer and Economic Analyzer to update information about link traffic
Page 40 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

and reference vectors calculated every reporting and accounting period,
respectively. Additionally Economic Analyzer may inform DTM that for some links
the reference vector is already achieved in current accounting period what triggers
appropriate operations.
o public void initialize(): Method that should be invoked during
component initialization to set initial values to control variables, populate
internal structures with data loaded from the Database as well as load a
default reference vector from file (if such exists).
o public
void
updateXVector(XVector
xVector)
throws
IllegalArgumentException: DTM external interface method used to
update information about link traffic vector calculated every reporting period.
Traffic vector values are accumulated from the beginning of accounting
period (reception of updated R vector). Triggers subsequent actions in a new
thread.
o public void updateRVector(LocalRVector rVector) throws
IllegalArgumentException: DTM external interface method used to
update information about reference vector calculated every accounting
period. Link traffic vector value for given AS is reset. Also, if delay tolerant
traffic management is enabled, policer limits are configured on BG routers
for the next accounting period. Triggers subsequent actions in a new thread.
o public void updateLinksWithRVectorAchieved(int asNumber,
List<LinkID> links) throws IllegalArgumentException: DTM
external interface method used to update the list of inter-domain links for
which the number of collected 95th percentile traffic samples with values
less than the reference vector value calculated for that link is greater than
95% of the number of all samples collected during a single accounting
period. For those links any configured bandwidth limits should be disabled till
the end of current accounting period since the reference vector is already
guaranteed to be achieved. Also compensation vector calculation algorithm
is adapted to current situation.
DTMRemoteVectorsReceiver: Implements DTM external interface methods that
are used by Inter-SBox Communication Service server side component to update
information about reference and compensation vectors calculated in remote
SBoxes.
o public void initialize(): Method that should be invoked during
component initialization to load required data from the database, populate
internal structures and initialize all SDN controllers.
o public
void
receive(CVector
cVector)
throws
IllegalArgumentException: DTM external interface method used to
update information about compensation vector calculated every reporting
period in remote SBox.
o public void receive(CVector cVector, RVector rVector)
throws IllegalArgumentException: DTM external interface method
used to update information about compensation and reference vectors

Version 1.0

Page 41 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

calculated every reporting and accounting period, respectively in remote
SBox.

Figure 13: NTM partial class diagram: top level.
In Figure 14, a partial NTM class diagram is presented with the following classes
(DTMTrafficManager class was already described in the previous paragraph):
VectorProcessingThread: Base abstract class that implements the Runnable
interface. Each vector processing procedure implemented by the subclasses of this
base class is executed in separate thread of execution.
o public
VectorProcessingThread(XVector
xVector,
LocalRVector
rVector,
List<SBox>
remoteSboxes): The
constructor with three arguments: link traffic and reference vectors to be
used during compensation vector calculation and a list of SBoxes which
should be updated once the calculation is complete.
o public VectorProcessingThread(List<SBox> remoteSboxes):
The constructor with one argument. The compensation vector is calculated
outside of this thread and sent to given list of SBoxes.
CVectorProcessingThread:
Extends
VectorProcessingThread
class.
Implements new compensation vector calculation after new link traffic vector is
received followed by sending compensation vector to remote SBoxes. Those
actions are performed in separate thread.
o public
CVectorProcessingThread(XVector
xVector,
LocalRVector
rVector,
List<SBox>
remoteSboxes): The
constructor with arguments.
o public CVectorProcessingThread(XRVectorPair vectorPair,
List<SBox> remoteSboxes): The constructor with arguments.
o public CVectorProcessingThread(CVector preparedCVector,
List<SBox> remoteSBoxes): The constructor with arguments.
Page 42 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public void run(): Method launched when thread is started. Constructs
compensation vector with CVectorConstructor or uses already prepared
vector and sends it to remote SBoxes using an instance of
DTMVectorsSender.
CRVectorProcessingThread:
Extends
VectorProcessingThread
class.
Implements new compensation vector calculation after new reference vector is
received followed by sending both compensation and reference vectors to remote
SBoxes.
o public
CRVectorProcessingThread(XVector
xVector,
LocalRVector
rVector,
List<SBox>
remoteSboxes): The
constructor with arguments.
o public CRVectorProcessingThread(XRVectorPair vectorPair,
List<SBox> remoteSboxes): The constructor with arguments.
o public void run(): Method launched when thread is started. Constructs
compensation vector with CVectorConstructor and sends both vectors to
remote SBoxes using instance of DTMVectorsSender.
CVectorConstructor: Constructs compensation vector from values calculated
by CVectorValuesCalculator.
o public CVector construct(XVector xVector, LocalRVector
rVector): Constructs new compensation vector based on provided
arguments:
link
traffic
vector
and
reference
vector.
Uses
CVectorValuesCalculator to calculate vector values.
CVectorValuesCalculator:
calculation logic.

Implements

compensation

vector

values

o public
CVectorValuesCalculator(XVector
xVector,
LocalRVector rVector): The constructor with arguments: link traffic
vector and reference vector to be used during calculation.
o public
List<LocalVectorValue>
compensation vector values.

calculate():

Calculates

DTMVectorsSender: Implements methods that forward requests for inter-SBox
vector information update to the InterSBoxClient component.
o public void send(SBox sbox, CVector cVector): Method calls
proper method of the InterSBoxClient class instance in order to send
information about updated compensation vector to given remote SBox.
o public void send(SBox sbox, CVector cVector, RVector
rVector): Method calls proper method of the InterSBoxClient class
instance in order to send information about updated compensation and
reference vectors to given remote SBox.
InterSBoxClientFactory: Static factory class used by DTMVectorsSender to
obtain instances of InterSBoxClient class to be used for communication with remote
SBoxes.

Version 1.0

Page 43 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public static InterSBoxClient getInstance(): Method returns
an instance of the InterSBoxClient class according to the currently enabled
client creation mode. By default the so called unique client creation mode is
disabled.
CVectorHistory: Stores information about compensation vectors calculated over
time. Implements static methods for storing, retrieving and displaying entries
represented by CVectorHistoryEntry.
o public synchronized static void storeInHistory(CVector
vector): Stores information about new compensation vector encapsulated
in CVectorHistoryEntry object.
o public static List<CVectorHistoryEntry> entries(): Returns
all entries from the history.
CVectorHistoryEntry: Encapsulates CVector class object in order to be placed
in CVectorHistory.
o public CVectorHistoryEntry(CVector vector): The constructor
with arguments.
CVectorUpdateController: Implements compensation vector updates handling
logic. If the controller is activated, compensation vector updates are sent to remote
SBoxes only if required and not necessarily every time new vector is calculated.
Updates are sent periodically according to the value of the compensation period
defined in the TimeScheduleParameters class as well as if the current vector differs
significantly from the one previously sent. Moreover, if certain conditions are met,
i.e. the reference vector on specific links is already achieved in the current
accounting period, the controller itself calculates new compensation vectors
according to specific algorithm.
o public
static
CVectorUpdateController
getInstance():
Returns the single existing instance of the controller. If such instance does
not yet exists it is created.
o public static void activate(): Activates the controller.
o public static void deactivate(): Deactivates the controller.
o public
synchronized
boolean
updateRequired(CVector
cVector): Method checks whether it is required to send an update of given
compensation vector to remote SBoxes. It checks if the compensation period
elapsed, or if the values of current compensation vector in comparison with
the one previously sent meet some predefined conditions.
o public void increaseCount(): Method called after each reporting
period.
o public void sent(CVector cVector): Method called to inform about
new compensation vector that was just sent. This vector is stored as the
previous vector for given AS.
o public void reset(): Method called to reset stored values when new
accounting period begins.

Page 44 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public
boolean
isCVectorPreparedByController(int
asNumber): Checks if there are already some links in given AS for which
the R vector is already achieved. This would mean that the compensation
vector for given AS should be calculated by the CVectorUpdateController.
o public CVector prepareCVector(int asNumber, LocalRVector
rVector): Calculates and returns proper compensation vector to be used
for given AS. This method should be called if at least one link in given AS
has the reference vector already achieved.
o public void updateLinksWithRVectorAchieved(int asNumber,
List<LinkID> links): Updates the list of links with R vector achieved in
given AS.
DelayTolerantTrafficManager: Uses NetConfWrapper class to execute
operations related with delay tolerant traffic management requested by the
DTMTrafficManager.
o public
void
updatePolicerLimitsOnLinks(LocalRVector
rVector): Sets bandwidth limits for hierarchical policer to be used during
next accounting period. Target router and interface details with new
bandwidth limit values are retrieved from the given reference vector.
o public void deactivateFiltersOnGivenLinks(List<LinkID>
links): Updates locally stored list of links for which filters should be
deactivated and triggers proper operations on routers using
NetConfWrapper.
o public void activateFiltersOnAllLinks(): Activates filters on all
links on which they have been previously deactivated.
NetConfWrapper: Implements router configuration operations by means of
NETCONF protocol.
o public static NetConfWrapper build(BGRouter bgRouter):
Returns an instance of NetConfWrapper configured based on the provided
BGRouter class instance.
o public boolean updatePolicerConfig(String interfaceName,
long bandwidthLimit): Redirects the operation execution to another
method providing default value of burst size limit.
o public boolean updatePolicerConfig(String interfaceName,
long
bandwidthLimit,
long
burstSizeLimit):
Updates
hierarchical policer configuration on an interface with given values of
bandwidth limit and burst size limit.
o public
boolean
activateHierarchicalFilter(String
interfaceName): Activates hierarchical filter on given router interface.
o public
boolean
deactivateHierarchicalFilter(String
interfaceName): Deactivates hierarchical filter on given router interface.
RemoteSBoxContainer: Data container class used to store SBox objects
representing SBoxes in remote ASs from which traffic is sent to the local AS. Those
SBoxes are grouped on per local AS number basis.
Version 1.0

Page 45 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public void populateFromDB(): Populates structure containing
SBoxes grouped on per local AS basis with data loaded from data base.
o public List<SBox> getRemoteSBoxes(int asNumber): Returns list
of remote SBoxes (with no duplicates) for given AS obtained based on
existing inter-DC communications.
VectorsContainer: Data container class used to store XVector and
LocalRVector objects representing link traffic vectors and reference vectors
organized in pairs (XRVectorPair class) by AS number.
o pu… XRVectorPair accumulateAndStoreUpdatedXVectorValues
(XVector xVector): Stores data from new link traffic vector in the
container. If XRVectorPair for given AS already exists it is updated, meaning
that the current counter values are increased by the values from the new link
traffic vector. If not, new XRVectorPair is created.
o public void resetXVectorValues(int asNumber): Resets the
counter values of link traffic vector stored for given AS.
o public
XRVectorPair
storeUpdatedRVector(LocalRVector
rVector): Stores new reference vector (LocalRVector) in the container. If
XRVectorPair for given AS already exists it is updated. If not, new
XRVectorPair is created.
o public XRVectorPair loadCurrentVectorPair(int asNumber):
Retrieves XRVectorPair for given AS from the container.
o public Set<Integer> getListOfAsNumbers(): Retrieves a list of all
ASs for which vector pairs are currently stored in the container.
XRVectorPair: Used to store two related vector objects (XVector and
LocalRVector) representing link traffic vector and reference vector, respectively.
o public
XRVectorPair(XVector
xVector,
LocalRVector
rVector): The constructor with arguments that sets both vectors. These
vectors can be later on retrieved with appropriate getter method.
o public boolean areBothVectorsSet(): Checks whether both vectors
comprising the pair are already set.
o public int getAsNumber(): Returns the number of the AS for which
both of the vectors were calculated. Note: Both vectors should have the
same value of source AS number field.

Page 46 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 14: NTM partial class diagram: traffic receiver side.
Sequence diagrams in Figure 15 and Figure 16 present the NTM interactions with other
SBox components after reporting period in two cases depending on whether the reference
vector is already achieved on one or both links in given AS.
Presented actions are related to the NTM operations performed on the traffic receiving
side of inter-DC communication.
After reporting period elapses, in typical situation presented in Figure 15, the
DTMQoSAnalyzer updates DTMTrafficManager with a new X vector value. This

Version 1.0

Page 47 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

triggers the execution of CVectorProcessingThread which constructs a new C vector
using CVectorConstructor. When CVectorUpdateController confirms that
compensation vector update is required the DTMVectorSender is instructed to send the
new value to a remote SBox. InterSBoxClient is called to perform the actual C vector
transfer.
Figure 16 presents the specific situation mentioned above. After reception of the new X
vector DTMTrafficManager asks the CVectorUpdateController if it will prepare the
new compensation vector instead of the CVectorConstructor. In this case the answer
is positive so the C vector is retrieved from the CVectorUpdateController and passed
to CVectorProcessingThread and later on sent to a remote SBox.

Figure 15: NTM sequence diagram after reporting period: traffic receiver side.

Figure 16: NTM sequence diagram after reporting period: traffic receiver side (R vector
achieved on a link).
After
accounting
period
elapses
(as
presented
in
Figure
17)
the
EconomicAnalyzerInternal updates DTMTrafficManager with a new R vector
value. In turn DTMTrafficManager requests DelayTolerantTrafficManager to
update policer limits on BG router interfaces corresponding to the inter-domain links with
new values calculated from the reference vector that will be used during next accounting
period. Moreover hierarchical filters on all those interfaces should be activated since they

Page 48 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

may have been deactivated during the last accounting period. The NetConfWrapper is
used to execute these requests on the routers using the NETCONF protocol [19]. This
also triggers the execution of CRVectorProcessingThread which calculates a new C
vector and sends both newly calculated C vector and received R vector to a remote SBox.

Figure 17: NTM sequence diagram after accounting period: traffic receiver side
During the accounting period the EconomicAnalyzerInternal may also update the
DTMTrafficManager with a list of inter-domain links on which the reference vector is
already achieved. This triggers appropriate actions presented in Figure 18.
DTMTrafficManager requests DelayTolerantTrafficManager to deactivate
hierarchical filter for specific links what is later on executed by the NetConfWrapper.
Information about the links is also sent to the CVectorUpdateController.

Figure 18: NTM sequence diagram: update of list of links with R vector achieved.
In Figure 19, a partial NTM class diagram is presented with the following classes
(DTMRemoteVectorsReceiver class was already described in the previous paragraph):
SDNControllerConfigBuilder: Prepares ConfigData class object specific for
given SDN controller based on DC2DCCommunication objects stored in the data
base.
Version 1.0

Page 49 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public
static
ConfigData
prepareConfig(SDNController
controller): Method prepares configuration data for given SDN
controller.
SDNConfigPusher: Implements methods that forward requests for SDN controller
vector information update or configuration to the SboxSdnClient component.
o public SDNConfigPusher(Set<SDNController> controllers):
The constructor with arguments: set of SDN controllers to which subsequent
requests called on this object will be directed.
o public void updateVectorInfo(CVector cVector): Method uses
SboxSdnClient to update compensation vector information in selected SDN
controllers.
o public void updateVectorInfo(CVector cVector, RVector
rVector): Method uses SboxSdnClient to update compensation and
reference vectors information in selected SDN controllers.
o public void initializeSDNController(ConfigData data):
Method uses SboxSdnClient to initialize selected SDN controllers with
configuration data.
SDNClientFactory: Static factory class used by the SDNConfigPusher to obtain
instances of SboxSdnClient to be used for communication with remote SDN
controllers.
o public static SboxSdnClient getInstance(): Method returns an
instance of the SboxSdnClient according to currently enabled client creation
mode. By default the so called unique client creation mode is disabled.
ThetaCoefficientHandler: Implements logic for manipulating compensation
vector values based on theta coefficients.
o public CVector normalizeCVector(CVector cVector, RVector
rVector): Method normalizes compensation vector values based on theta
coefficients provided as part of reference vector for given AS.
SDNControllerContainer: Data container class used to store information about
SDN controllers that manage DA routers on which tunnels were configured towards
AS with given AS number.
o public void populateControllersFromDB(): Used to initialize
internal structures based on data stored in data base.
o pub… List<SDNController> getControllersByRemoteASNumber
(int asNumber): Returns a list of SDN controllers that manage DA
routers with tunnels towards given remote AS.
o public List<SDNController> getAllControllers(): Returns a list
of all SDN controllers in local ASs.
DAOFactory: Static factory class used to obtain an instance of specific DAO class.
Contains a set of static methods that return locally stored instances of DAO
classes. Following DAO classes are supported: DC2DCCommunicationDAO,

Page 50 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

SystemControlParametersDAO,
LinkDAO.

TimeScheduleParametersDAO,

ASDAO

and

Figure 19: NTM partial class diagram: traffic sender side.
The sequence diagram in Figure 20 presents the Network Traffic Manager interactions
that take place on the traffic sending side of inter-DC communication. During NTM
component initialization, DTMRemoteVectorsReceiver is requested to initialize all SDN
controllers
with
initial
configuration
data
prepared
by
the
SDNControllerConfigBuilder. This request is passed to SDNConfigPusher which
in turn communicates with SboxSdnClient to transfer required ConfigData to the SDN
controller over HTTP. Later on during SBox operation, DTMRemoteVectorsReceiver
periodically receives from InterSBoxServer new C and R vectors updated by remote
SBoxes. SDNConfigPusher is used to pass those vectors to appropriate SDN
controllers. The actual transfer is done by SboxSdnClient.

Version 1.0

Page 51 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 20: NTM simplified sequence diagram: traffic sender side.
5.1.2.2.1

First compensation vector calculation algorithm

Following is the first, primary compenstation vector calculation algorithm presented in form
of a pseudocode. This algorithm uses as input information about current, aggregated link
traffic vector and reference vector. It is used in the case when on none of the links in a
given AS the reference vector is yet achieved.
factor=(xVector(1)+xVector(2))/(rVector(1)+rVector(2));
for(each link) {
cVector(k)=factor*rVector(k)–xVector(k);
}
5.1.2.2.2

Second compensation vector calculation algorithm

The second algorithm presented below is used only in specific situation in which at some
time during the accounting period the reference vector is already achieved on one or both
links as indicated by the Economic Analyzer. This algorithm is used only in the case when
95th percentile based traffic charging rule is enabled. It uses information about either
reference vector or previous compensation vector to direct all the traffic to a single link on
which the reference vector is already achieved or to distribute the traffic equally if vector is
already achieved on both links.
// flagSamplesBelowR – information received from Economic Analyzer; if equal to
1 for given link (link ids: 0 or 1) indicates that on this link the R vector is
achieved;
// flagSamplesBelowRActivated – information stored locally; if equal to 1 for
given link (link ids: 0 or 1) indicates that information about the R vector

Page 52 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

achieved on this links was already received and this link is already treated
accordingly;
if(flagSamplesBelowRActivated[1]==0 && flagSamplesBelowR[1]==1) {
cVector(1)=100*(rVector(1)+rVector(2));
cVector(2)=-100*(rVector(1)+rVector(2));
flagSamplesBelowRActivated[1]=1;
}
else if (flagSamplesBelowRActivated[2]==0 && flagSamplesBelowR[2]==1) {
cVector(1)=-100*(rVector(1)+rVector(2));
cVector(2)=100*(rVector(1)-rVector(2));
flagSamplesBelowRActivated[2]=1;
}
else if(flagSamplesBelowRActivated[1]==1 && flagSamplesBelowRActivated[2]==1) {
cVector[1]=-previousCVector[1];
cVector[2]=-previousCVector[2];
}

5.1.2.3 Tests
In order to test the DTM features provided by the NTM component a set of 18 test classes
was implemented comprising JUnit [19] tests for not only particular single methods or
group of methods but also simple workflows internal to NTM component. Mockito library
[21] was used in several cases to mock components external to NTM, e.g. Database,
SBox-SDN Communication Service and Inter-SBox Communication Service.
The implemented test classes with test methods are listed below (please note that all
provided names of test methods are preceded with public void in the source code).
Test classes are grouped in three packages.
There is one class in the eu.smartenit.sbox.ntm package.
NetworkTrafficManagerDTMTest contains following test methods for
NetworkTrafficManager class initialization of DTM modules in three modes as
specified in NetworkTrafficManagerDTMMode enum class:
o shouldCreateAndInitializeNTMInSenderOnlyMode()
o shouldCreateAndInitializeNTMInReceiverOnlyMode()
o shouldCreateAndInitializeNTMInGeneralMode()
o shouldCreateAndInitializeNTMInDefaultMode()
There are 13 test classes in eu.smartenit.sbox.ntm.dtm.receiver package.
These classes include tests of DTM features running in the NTM in the SBox deployed in
the traffic receiving domain.

Version 1.0

Page 53 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

XVectorUpdateTest contains following test methods for workflow triggered by
DTMTrafficManager class after receiving updated link traffic vector from QoS
Analyzer component:
o shouldThrowExceptionOnVectorNull()
o shouldThrowExceptionOnInvalidVectorASNumberArgument()
o shouldThrowExceptionOnInvalidVectorValuesListArgument()
o shouldSkipCalculationAfterXVectorUpdate()
o shouldCalculateCAndUpdateCVectorNoCVectorUpdateControlle
r()
o shouldCalculateCAndUpdateCVectorWithCVectorUpdateControl
ler()
XVectorUpdateChargingRuleTest contains following test methods for
workflow triggered by the DTMTrafficManager class after receiving updated link
traffic vector from QoS Analyzer for both charging rules:
o shouldDistributeCVectorChargingRule95thNoController()
o shouldDistributeCVectorChargingRule95thWithController()
o shouldDistributeCVectorChargingRuleVolume()
XRVectorsUpdateDetailedTest contains following more detailed test methods
for workflow triggered by DTMTrafficManager class after receiving updated traffic
vectors from QoS Analyzer and Economic Analyzer component:
o shouldDistributeCRVectorsAfterAccountingPeriodEnd()
o shouldDistributeCVectorBeforeAccountingPeriodEndSingleXV
ector()
o shouldDistributeCVectorBeforeAccountingPeriodEnd()
o shouldDistributeCVectorBeforeAccountingPeriodEndWithCVec
torController()
RVectorUpdateTest contains following test methods for workflow triggered by
DTMTrafficManager class after receiving updated reference vector from Economic
Analyzer component:
o shouldThrowExceptionOnVectorNull()
o shouldThrowExceptionOnInvalidVectorASNumberArgument()
o shouldThrowExceptionOnInvalidVectorValuesListArgument()
o shouldSkipCalculationAfterRVectorUpdate()
o shouldCalculateCAndUpdateCRVectorsAfterRVectorUpdate()
CVectorValuesCalculatorTest
compensation
vector
values
CVectorValuesCalculator class:

contains following
calculation
logic

test methods
implemented

for
in

o shouldCalculateFromTwoDimentionVectors()
o shouldCalculateWithOneXVectorValueZero()

Page 54 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o shouldCalculateWithEqualRAndXVectorValuesRatio()
o shouldCalculateWithAllXVectorValuesZero()
o shouldCalculateWithXVectorEqualRVector()
o shouldCalculateFromFiveDimentionVectors()
CVectorConstructorTest contains following test methods for compensation
vector construction from values calculated by the CVectorValuesCalculator class:
o shouldConstructCVector()
o shouldThrowIAESinceXVectorNull()
o shouldThrowIAESinceRVectorNull()
o shouldThrowIAESinceBothVectorsNull()
o shouldThrowIAESinceInvalidVectorSize()
o shouldThrowIAESinceVectorSizeBelowTwo()
o shouldThrowIAESinceInvalidLinkIDs()
CVectorUpdateControllerTest
compensation
vector
updates
CVectorUpdateController class:

contains following test methods
management
logic
implemented

for
in

o shouldUpdateAfterCompensationPeriod()
o shouldUpdateFirstCVector()
o shouldUpdateOnThresholdExceeded()
o shouldNotUpdateThresholdNotExceeded()
o shouldUpdateControllerNotActivated()
DelayTolerantTrafficManagementTest contains following test methods for
functionalities related with delay tolerant traffic management:
o shouldTriggerPolicerConfUpdates()
o shouldNotTriggerPolicerConfUpdates()
o shouldThrowExceptionOnNullListOfLinks()
o shouldDeactivateAndActivateFiltersOnGivenLinks()
LinksWithRVectorAchievedHandlingTest contains following test methods
for functionalities related with handling links with reference vector achieved:
o shouldReturnProperStatusOfCVectorPreparation()
o shouldReturnPreparedCVector()
o shouldThrowExceptionOnInvalidASNumber()
o shouldThrowExceptionOnRVectorNull()
o shouldThrowExceptionOnInvalidRVector()
o shouldThrowExceptionOnInvalidASNotFound()
o shouldThrowExceptionOnInvalidASWithZeroLinks()

Version 1.0

Page 55 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

NetConfWrapperTest contains following test methods for all device configuration
operations that are supported by the NetConfWrapper class:
o shouldActivateFilter()
o shouldDeactivateFilter()
o shouldSetBandwidthLimit()
o shouldReturnFalseOnDeviceNull()
LoadingDefaultRVectorDuringInitTest contains following test methods for
loading default reference vector from file specified in SBox configuration file:
o shouldLoadCorrectRVectorAndUpdateRemoteSBox()
o shouldNotUpdateRemoteSBoxWhenRVectorFileNotExists()
VectorsContainerTest contains following test methods for store and load
methods of VectorsContainer class:
o shouldCreateNewPairOnEmptyContainerWithUpdatedXVector()
o shouldCreateNewPairWithUpdatedXVector()
o shouldCreateNewPairOnEmptyContainerWithUpdatedRVector()
o shouldCreateNewPairWithUpdatedRVector()
o shouldAccumulateAndUpdateExistingPairWithUpdatedXVector(
)
o shouldResetXVectorValuesInExistingPair()
o shouldUpdateExistingPairWithUpdatedRVector()
o shouldReturnNullIfAsNumberIsNotSet()
RemoteSBoxContainerTest contains following test method for populate and get
methods of RemoteSBoxContainer class:
o shouldPopulateContainerStructures()
There are 4 test classes in eu.smartenit.sbox.ntm.dtm.sender package. These
classes include tests of DTM features running in the NTM in the SBox deployed in the
traffic sending domain.
RemoteVectorsUpdateTest contains following test methods for workflow
triggered by DTMRemoteVectorsReceiver class after receiving new compensation
and reference vectors from remote SBoxes:
o shouldProcessAndUpdateAfterRemoteCVectorReceived()
o shouldProcessAndUpdateAfterRemoteCAndRVectorsReceived()
o shouldProcessAndUpdateAfterMultipleRemoteCAndRVectorsRec
eived()
o shouldProcessAndNotUpdateWhenNoSDNControllers()
o shouldThrowExceptionOnCVectorNull()
o shouldThrowExceptionOnRCVectorsNull()
o shouldThrowExceptionOnInvalidCVectorASNumberArgument()

Page 56 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o shouldThrowExceptionOnInvalidCRVectorASNumberArgument()
o shouldThrowExceptionOnInvalidCVectorValuesListArgument()
o shouldThrowExceptionOnInvalidCRVectorValuesListArgument(
)
SDNControllerContainerTest contains following test method for store and
load methods of SDNControllerContainer class:
o shouldPopulateContainerStructures()
SDNControllersConfigTest contains following test methods for the SDN
Controllers configuration process launched during DTMRemoteVectorsReceiver
class initialization:
o shouldInitControllers()
o shouldConstructProperConfigData()
ThetaCoefficientHandlerTest contains following test methods for the logic
implemented in ThetaCoefficientHandler class:
o shouldReturnTheSameCVectorIfThetaNull()
o shouldReturnTheSameCVectorIfThetaNotNull()
5.1.3 Economic Analyzer
The Economic Analyzer (EA) component works out the strategy for inbound traffic
distribution between inter-domain links for the next accounting period. This distribution is
represented in a compact form of the reference vector. EA creates a cost map for traffic at
the end of the accounting period and predicts the possible optimal traffic pattern (the
expected traffic amount on each inter-domain link which minimizes the total cost of
transfer via these links). This information forms the basis for the reference vector
calculation. Each reference vector component represents expected traffic amount on a
particular inter-domain link. Each time a new reference vector is calculated it is sent to the
NTM for calculation of compensation vectors and distribution to remote domains in which
sources of traffic are located.
The EA receives information about the amount of traffic transmitted through each interdomain link during the accounting period from the QoS Analyzer (which collects values of
appropriate traffic counters from BG and DA routers) in the form of link traffic and tunnel
traffic vectors.
The EA component supports two traffic charging rules defined in the system, namely the
total traffic volume based rule and the 95th percentile rule. Depending on the charging
rule, the traffic samples are received from QoS Analyzer at different intervals. Typically
when total traffic volume based rule is enabled traffic vectors are received every 30
seconds. On the other hand, in the case of 95 th percentile rule, traffic updates are
received every 5 minutes what corresponds to the 95 th traffic sample collection time. Also
according to the currently enabled charging rule traffic samples are processed,
accumulated and stored differently.
If the 95th percentile charging rule is enabled, during accounting period EA counts for
each link traffic samples with values less than the value of reference vector component for

Version 1.0

Page 57 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

that link. If the number of such samples reaches 95% of all samples collected during an
accounting period it is certain that the reference vector for given link will be achieved in
current period. This information is sent to the NTM so that compensation vectors are
calculated differently since the whole traffic can from now on be sent to the given link.
5.1.3.1 Interfaces
The Economic Analyzer provides one interface method to be called by other SBox
component. The following method is implemented by the EconomicAnalyzer class.
public void updateXZVectors(XVector xVector, List<ZVector>
zVectors): Method called by QoS Analyzer to update information about link traffic
vector and tunnel traffic vectors.
o Input parameters:

xVector: New link traffic vector

zVectors: New list of tunnel traffic vectors

5.1.3.2 Design
The Economic Analyzer consists of 10 top level classes. Figure 21 presents all the
involved classes with selected relationships between them.
Following is the description of those classes:
EconomicAnalyzer: Main class of the Economic Analyzer. Implements external
interface method used by the QoS Analyzer to update traffic information. Uses
EconomicAnalyzerInternal to handle traffic samples and trigger actions within a
single Autonomous System.
o EconomicAnalyzer(DTMTrafficManager
dtmTrafficManager):
The constructor with arguments. Takes in the DTM Traffic manager instance
as the input variable in order to proceed to the following methods eventually.
o void
updateXZVectors(XVector
X_in,
List
<ZVector>
Z_in_list): Economic Analyzer external interface method used to update
information about link traffic vector and tunnel traffic vectors.
EconomicAnalyzerInternal: Class that implements Economic Analyzer
operations within a single Autonomous System.
o EconomicAnalyzerInternal(DTMTrafficManager
dtmTrafficManager,
SimpleLinkID
link1,
SimpleLinkID
link2): The constructor with arguments: instance of DTMTrafficManager
(that should be updated once new reference vector is calculated or on some
link the reference vector is achieved) and identifiers of two considered interdomain links.
o void
updateXZVectors(XVector
xVector,
List<ZVector>
zVectors): Updates link and tunnel traffic data. If accounting period
elapsed, calculates new reference vector and sends is to configured NTM
instance. Updates NTM with a list of links on which the R vector has been
already achieved in the current accounting period.

Page 58 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

TrafficSamplesContainer: Base class for traffic data containers used by
EconomicAnalyzerInternal to store data received from QoS Analyzer.
o public
TrafficSamplesContainer(SimpleLinkID
link1,
SimpleLinkID link2): The constructor with arguments: identifiers of two
inter-domain links.
o public abstract void storeTrafficValues(XVector xVector,
List<ZVector> zVectors): Stores traffic values from report/sample.
o public abstract void resetTrafficValues(): Resets aggregated
traffic information (after the accounting period has expired).
o public abstract long[] getTrafficValuesForLinks(): Returns
a vector of link traffic samples to be used in reference vector calculation.
o public
abstract
long[]
getTrafficValuesForTunnels():
Returns a vector of tunnel traffic samples to be used in reference vector
calculation.
TotalVolumeSamplesContainer: Container for accumulated traffic samples.
Extends TrafficSamplesContainer class.
o public TotalVolumeSamplesContainer(SimpleLinkID link1,
SimpleLinkID link2): The constructor with arguments: identifiers of two
inter-domain links.
o public abstract void storeTrafficValues(XVector xVector,
List<ZVector> zVectors): Accumulates and stores link and tunnel
traffic values.
o public abstract void resetTrafficValues(): Resets aggregated
traffic information (after the accounting period has expired).
o public abstract long[] getTrafficValuesForLinks(): Returns
a vector of link traffic values to be used in reference vector calculation.
These values correspond to traffic accumulated over the whole accounting
period.
o public
abstract
long[]
getTrafficValuesForTunnels():
Returns a vector of tunnel traffic samples to be used in reference vector
calculation. These values correspond to traffic accumulated over the whole
accounting period.
The95PercentileSamplesContainer: Container for 95th percentile traffic
samples. Extends TrafficSamplesContainer class.
o public
The95PercentileSamplesContainer(SimpleLinkID
link1, SimpleLinkID link2): The constructor with arguments:
identifiers of two inter-domain links.
o public
The95PercentileSamplesContainer(SimpleLinkID
link1,
SimpleLinkID
link2,
int
samplesInAccountingPeriod): The constructor with arguments:
identifiers of two inter-domain links and the number of samples collected
during entire accounting period.

Version 1.0

Page 59 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public abstract void storeTrafficValues(XVector xVector,
List<ZVector> zVectors): Stores link and tunnel traffic values. Checks
if for some links the reference vector is already achieved.
o public abstract void resetTrafficValues(): Resets structures
holding traffic samples and other supporting fields (after the accounting
period has expired).
o public
abstract
long[]
getTrafficValuesForLinks():
Calculates and returns 95th percentile traffic samples for all links.
o public
abstract
long[]
getTrafficValuesForTunnels():
Calculates and returns 95th percentile traffic samples for all tunnels.
o public
boolean
isChangeInLinksWithRVectorAchieved():
Checks whether after storing latest traffic samples the reference vector was
achieved on new link or links.
o public List<LinkID> getLinksWithRVectorAchieved(): Returns
current list of links on which the reference vector has been achieved.
o public void setCurrentRVector(LocalRVector rVector): Sets
reference vector to be used to determine the number of traffic samples with
values less than the reference vector component value.
o public
The95thPercentileSamplesHistory
getHistory():
Returns the whole history of traffic samples stored in previous accounting
periods.
ReferenceVectorCalculator: Implements the reference vector calculation
algorithm.
o public
ReferenceVectorCalculator(SimpleLinkID
link1,
SimpleLinkID link2, List<CostFunction> costFunctions,
TimeScheduleParameters
timeScheduleParameters):
The
constructor with arguments: identifiers of two links, cost functions used on
those links and additional control parameters.
o LocalRVector calculate(long[] X_V, long[] Z_V, int
sourceAsNumber): Calculates the reference vector for AS from given
aggregated traffic values.
DInterval: Represents an interval bounded by two alpha end points.
o DInterval(long lowerBound, long upperBound): The constructor
with arguments. Creates a DInterval class instance for a given set of lower
and upper bounds.
o boolean contains(long x): Returns true if the parameter value passed
as an argument is contained within the two bounds (including boundaries).
o long getLowerBound(): Returns the lower bound of the interval.
o long getUpperBound(): Returns the upper bound of the interval.
Area: Represents the intervals which make up an area.

Page 60 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o Area(DInterval d1, DInterval d2): The constructor with arguments
that is responsible for creating an Area object.
o DInterval getD1(): Returns the interval on the x1 axis.
o DInterval getD2(): Returns the interval on the x2 axis.
The95thPercentileSamplesHistory: Stores 95th percentile traffic samples
collected during past accounting periods.
o public void store(Map<SimpleLinkID, List<TrafficSample>>
linkTrafficSamples,
Map<SimpleLinkID,
List<TrafficSample>> tunnelTrafficSamples): Adds new entry to
the history.
o public List<Entry> getEntries(): Returns the whole history.
DAOFactory: Static factory class used to obtain an instance of a specific DAO
class. Contains a set of static methods that return locally stored instances of DAO
classes.
Following
DAO
classes
are
supported:
CostFunctionDAO,
SystemControlParametersDAO and TimeScheduleParametersDAO.

Figure 21: Economic Analyzer class diagram.

Version 1.0

Page 61 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Sequence diagram in Figure 22 presents Economic Analyzer interactions with other SBox
components, namely QoS Analyzer and Network Traffic Manager.
Periodically the QoS Analyzer updates EA with new link and tunnel traffic vectors
calculated from traffic counters values collected over some period of time (e.g. 5 minutes).
For this purpose an interface method of EconomicAnalyzer class is used. New vectors
are passed to an instance of EconomicAnalyzerInternal corresponding to the AS for
which traffic vectors were prepared. EconomicAnalyzerInternal uses one of two
container classes to store traffic samples depending on the charging rule enabled in the
system. Sequence diagram depicts the workflows assuming that the 95th percentile based
rule is used. Please note that only a subset of presented messages is exchanged in the
case when total traffic volume charging rule is in use. During the accounting period,
EconomicAnalyzerInternal
stores
received
traffic
data
in
The95thPercentileSamplesContainer and checks whether there are some new
links on which the reference vector has been already achieved. If yes, new list of
identifiers of such links is sent to an instance of DTMTrafficManager. After the
accounting period, EconomicAnalyzerInternal retrieves the 95th percentile traffic
samples from the container and passes them to ReferenceVectorCalculator for
reference vector calculation. Finally new reference vector is sent to
DTMTrafficManager.

Figure 22: Economic Analyzer sequence diagram.

Page 62 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

5.1.3.2.1

Reference vector calculation algorithm

The main responsibility of the Economic Analyzer component is the periodical calculation
of reference vector after each accounting period. The detailed description of the algorithm
is available in section 6.1.3.3.1 of Deliverable 3.2 [2].
5.1.3.3 Tests
In order to test the DTM features provided by the Economic Analyzer component a set of
6 test classes was implemented.
Those classes with their test methods are listed below (please note that all provided
names of test methods are preceded with public void in the source code):
ReferenceVectorCalculationTest contains following test methods for
reference vector calculation logic implemented by the ReferenceVectorCalculator
class.
o firstTestData()
o secondTestData()
o thirdTestData()
o fourthTestData()
o fifthTestData()
o sixthTestData()
o seventhTestData()
o eightTestData()
o ninthTestData()
o tenthTestData()
o eleventhTestData()
The95thPercentileWorkflowTest contains a test method for workflow
triggered by the EconomicAnalyzer after receiving updated link and tunnel traffic
vectors in the case the ChargingRule.the95thPercentile is enabled.
o shouldCalculateRefVectorAfterAccountingPeriod()
TotalVolumeWorkflowTest contains a test method for workflow triggered by the
EconomicAnalyzer after receiving updated link and tunnel traffic vectors in the case
the ChargingRule.volume is enabled.
o shouldCalculateRefVectorAfterAccountingPeriod()
TotalVolumeReportsAggregationTest contains test methods for handling
traffic updates when ChargingRule.volume is enabled. Traffic values are
aggregated during an accounting period and then reset.
o prepareTotalVolumeXVBeforeAccountingPeriod()
o prepareTotalVolumeZVBeforeAccountingPeriod()
o prepareTotalVolumeXVAfterAccountingPeriod()
o prepareTotalVolumeZVAfterAccountingPeriod()

Version 1.0

Page 63 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o asNumberMatch()
o linkIDConsistence()
The95thPercentileSamplesContainerTest tests methods for handling 95th
percentile samples implemented by the The95PercentileSamplesContainer class.
o shouldStoreXAndZVectorTrafficSamples()
o shouldStoreManyXAndZVectorTrafficSamples()
o shouldThrowExceptionOnInvalidInput()
HandlingSamplesBelowRVectorTest contains following test methods for
handling of 95th percentile samples by the The95PercentileSamplesContainer with
the focus on samples with values less than corresponding reference vector
component value.
o shouldStoreSamplesAndHandleSamplesBelowRVector()
o shouldStoreAndHandleDifferentNumberOfSamples()
5.1.4 Inter-SBox Communication Service
The Inter-SBox Communication Service component functionality and design have been
documented in Section 6.1.5 of D3.2 [2] and have not changed since then.
5.1.5 SBox-SDN Communication Service
The SBox-SDN Communication Service component functionality and design have been
documented in Section 6.1.5 of D3.2 [2] and have not changed since then.
5.1.6 Database
The Database (DB) component is responsible both for relational tables creation and the
application connection to the actual database. It is partitioned into the following packages:
dto: Contains all the Data Transfer Objects (DTO) of the database, namely all the
Java classes that correspond to the relational tables of the DB, and some additional
helper entities, which are used by certain components, but are not stored into the
database.
dao: Contains all the Data Access Objects (DAO) one for each table. Each of them
contains the methods provided to external components for reading from or writing
to the corresponding table. The dao package also includes the five subpackages
that follow.
o binders: Contains the binder classes.
o mappers: Contains the mapper classes.
o gen: Contains for each table an abstract class, behaving as interface, with
the actual necessary SQL commands wrapped each from a Java method
which is the one called by the above mentioned DAO method.
o util: Contains auxiliary, utility classes. For the moment it has only the
Tables class which creates and deletes all tables.
Page 64 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

test: Includes the JUnit tests one for each DAO class.
The DB contains the SQL tables described in the Design Subsection 5.1.6.2.
5.1.6.1
Interfaces
The DB component provides its services by exposing for each table a number of methods.
These methods, which reside for each table-entity in the corresponding DAO class,
named <entity-name>DAO, constitute the DB interface to the other components. Each of
these methods wraps up one or more SQL commands, located in the corresponding
Abstract<entity-name>DAO. In the case of multiple SQL commands, these may reside in
more than one Abstract<entity-name>DAO.
There is a set of methods which are implemented by almost all DAOs, while few others
are more specific, more complicated therefore implemented usually by a single (or more
cooperating) DAO. The common methods are briefly described as follows.
public void createTable(): The method that creates the corresponding
table.
public void deleteTable(): The method that deletes the corresponding
table.
public void insert(<entity type> e): The method that inserts an entity
to the corresponding table.
o Input parameter: The entity to be inserted.
public List<entity type> findAll(): The method that finds all the
stored entities from the respective table.
o Returns: The list of stored entities.
public <entity type> findById(<primary-key-type> pk): The
method that finds a stored entity by the corresponding table’s primary key.
o Input parameter: The primary key.
o Returns: the entity indexed by the primary key.
public <entity type> findLast(): The method that finds the last stored
entity.
o Returns: The most recent stored entity.
public void update(<entity type> e):The method that updates a stored
entity into its table.
o Input parameter: The entity to be updated.
public void deleteById(<primary-key-type> pk): The method that
deletes a stored entity by its table primary key.
o Input parameter: The primary key.
public void deleteAll(): The method that deletes all the stored entities
from the respective table.

Version 1.0

Page 65 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

The DAO-specific methods were described in Section 6.1.4.2 of Deliverable 3.2 [2], and
have been enhanced with new fields, which will be presented in the following section.
5.1.6.2
Design
The DB schema contains the following SQL tables depicted in Figure 23:

ASSYSTEM: The table where each Autonomous System is stored. A unique
number that identifies each AS, its ASNUMBER, it is table’s primary key.

BGROUTER: The table where the Border Gateway Is stored. The prefix of the router
management IP address is the table’s primary key.

CLOUDDC: The table where all the different clouds are stored. The cloud name is
the primary key.

COSTFUNCTION: The table where all the different cost functions are stored. The
pair <local link id, ISP name> is the primary key.

DAROUTER: The table where all the different Datacenter Attached Routers are
stored. The router IP address is the primary key.

DC2DCCOMMUNICATION: The table where the various connections between any
pair of datacenter are stored. Each such pair is uniquely identified by a combination
of 6 parameters: the communication number, the respective symbol, the name of
the local cloud, the name of the remote cloud, the local AS number and the remote
AS number.

ISP: The table where all the different ISPs are stored. The ISP name is the primary
key.

LINK: The table where all the different links are stored. The pair <local link id, ISP
name> is the primary key.

PREFIX: The table where all the different address prefixes we use are stored. An
auto incremented numerical identifier is the primary key.

SDNCONTROLLER: The table where all the different SDN controllers are stored. The
controller address is the primary key.

SEGMENT: The table where all the different segments are stored. An auto
incremented numerical identifier is the primary key.

SYSTEMCONTROLPARAMETERS: The table where the single system control
parameters record is stored. An auto incremented numerical identifier is the primary
key.

TIMESCHEDULEPARAMETERS: The table where the single time schedule
parameters record is stored. An auto incremented numerical identifier is the primary
key.

TUNNEL: The table where all the different tunnels are stored. The pair <local link id,
ISP name> is the primary key.

Page 66 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 23: SBox database schema.
Figure 24 presents the class diagram for the AS table-related classes. All other entities
conform to the same logic. For this simple case, 5 cooperating classes are involved to
provide read/write access to the respective table in a transparent fashion. Specifically, the
ASDAO class provides the necessary interface to all the other modules, and uses the
respective functions of the AbstractASDAO class, which execute all the SQL queries and
updates. Additional classes, BindAS and ASMapper provide the necessary mapping of
SQL result sets and columns to and from the respective DTO (AS class). The following
description of the aforementioned classes applies to all *, *DAO, Abstract*DAO, Bind*
and *Mapper classes.
AS
o All the ASDAO methods have arguments and/or return value an AS entity
object (the application language). It is the DTO class, therefore contains only
constructors, getters and setters.
ASDAO

Version 1.0

Page 67 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o It is the only interface used by applications either to issue commands to or
receive responses from the database.

All its methods were described in Section 5.1.6.1.

AbstractASDAO
o Belongs to the gen package, contains all SQL queries, each one defines a
java method. These methods only get called from the ASDAO methods. The
ASDAO methods are the ones exposed to any application requesting to read
or write to the database.
BindAS
o Translator from application-entity to the database-table when commands
issued to the DB.
o It is an interface that includes a static class ASBinderFactory which
implements BinderFactory interface i.e a build() method that
instantiate a Binder object for the AS type using the bind() method
whose description follows

public void bind(SQLStatement q, BindAS bind, AS
arg): It maps the parameters of an sql statement in
AbstractASDAO into AS parameters.

ASMapper
o Translator from the database-table to application-entity dialect, when the DB
responds to an issued command, using the below described map method.

ASMapper:
AS
map(int
index,
ResultSet
r,
StatementContext ctx): The method that translates a received
resultset into an AS object.
Input parameter: index The index.
Input parameter: r The received result set.
Input parameter: ctx The statement context.
Returns: The AS object.

Page 68 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 24: AS table-related class diagram.
5.1.6.3
Tests
The JUnit tests are identical as the ones defined in Section 6.1.4.4 of Deliverable 3.2 [2],
enhanced with assertions verifying new fields.
5.1.7 User Interface
The User Interface (UI) of the SBox is the module responsible for configuring relevant
parameters for the execution of the DTM mechanism. It is operated by the administrator of
the Network Service Provider, which is also the SBox administrator, and exposes a Web
interface accessible by any Web browser, where the following parameters may be
inserted, modified or deleted:
Local and remote autonomous systems that are involved in DTM mechanism
execution,
Local BG and DA routers,
SDN controllers and their attached routers,
Inter-domain links,
Tunnels,
Local cloud information,

Version 1.0

Page 69 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Remote clouds,
Inter-cloud communications, and,
System and general DTM settings.
5.1.7.1
Interfaces
The User Interface pages were presented in Section 6.1.7 of D3.2 [2] and only a few fields
in certain pages have changed since then.
In the BG and DA routers page (Figure 25), the intra-domain routers can be configured.
BG routers’ insertion requires the number of the AS they belong, and their username and
password to access them, while both types of routers require their SNMP community.
Besides, DA routers require the OpenFlow switch identifier, as well as their list of ports.
All inter-domain links are configured in the Links page (Figure 26). Link parameters
include: ID, ISP name, IP address, physical interface name, VLAN number, the BG router
it belongs, the tunnel end prefix and a list of Segments (left border, right border, a and b
constants) that comprise its cost function.
In the Tunnels page (Figure 27), the administrator may insert, modify and delete traversing
tunnels. More specifically, information about tunnels’ name, number, source and
destination end addresses, physical interface name, the local router address and the interdomain link they traverse are expected.
Finally, in the Settings page (Figure 28), required DTM execution parameters are set: the
start date of the DTM execution, and the duration of the accounting, reporting, sampling
and compensation periods. In addition, certain system control parameters can be
configured: the charging rule (95th percentile or volume-based), the operation mode of
SDN controller (proactive or reactive, with or without compensation vector), the
compensation threshold and a Boolean value defining whether the SBox operates with
delay-tolerant traffic management.

Page 70 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 25: BG and DA routers page.

Version 1.0

Page 71 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 26: Links page.

Page 72 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 27: Tunnels page.

Version 1.0

Page 73 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 28: DTM settings page.
5.1.7.2
Design
The SBox User Interface is a Web application designed and implemented based on the
Model-View-Controller (MVC) pattern, which defines 3 different but interconnected layers,
in order to separate data representation from business logic. In the generalized case, the
model layer includes all the application data, the view provides their output representation
and finally the controller is the coordinating component receiving user requests, calling
appropriate functions and returning results.
In the SBox User Interface, the model is represented by the Database component, which
consists of all the SBox database tables, their mapping to data transfer objects, as well as

Page 74 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

the data access objects to query and update those tables. The database component was
described with details in Section 5.1.6.
The controller layer is implemented by several *Bean classes, one for each page, which
include all the required functions that:
a) receive user’s requests and input from the Web application pages,
b) interact with the database and,
c) return output and/or navigate to other pages.
The list of controlling bean classes and their mapping to their controlling page is presented
below:
DashboardBean: It’s the session controlling bean, which is initialized on
successful login and terminated when the administrator logs off.
InterDatacenterBean: inter-datacenter communications page
IspBean: autonomous systems page.
LinksBean: links page (Figure 26).
LocalCloudsBean: local clouds page.
RemoteCloudsBean: remote clouds page.
RoutersBean: BG and DA routers page (Figure 25).
SdnControllersBean: SDN controllers page.
SettingsBean: system control DTM parameters page (Figure 28).
TunnelsBean: tunnel page (Figure 27).
Additional classes are also implemented, either providing support and converting functions
used in pages (WebUtils, IntegerListConverter), or managing certain required
functionalities (DB connection handling), when the Web application context is initialized or
terminated (SBoxWebAppListener).
Each *Bean class implements all the required functions to manage its respective page.
Specifically, the Web interface pages are used to insert, edit or remove specific entries
from the respective database tables, e.g. the IspBean manages the ISP and AS tables,
calling the respective DAO methods. Figure 29 presents such an example and is similar to
all *Bean classes.
Figure 30 presents a simple sequence diagram of an AS insertion through the User
Interface, which is triggered when the updateAS function is called. DashboardBean
calls the insert(AS) function of DB component’s ASDAO class, which subsequently
calls the related method from the AbstractASDAO, which executes the AS table update.
Afterwards, the findAll() is executed, to get all the AS entries and populate the table
presented in the page. The same action applies for all pages and methods defined above.

Version 1.0

Page 75 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 29: IspBean class diagram.

Figure 30: AS insertion sequence diagram
Finally, the view layer consists of all the pages, files and forms for the representation of
existing entries in the SBox database, and user’s request handling. The list of files is as
follows:
admin/: It’s the directory where all Web application pages exist:
o index.xhtml: The home page summarizing the User Interface features.
o interdatacenter.xhtml: The inter-datacenter communications page.
When the user inserts an inter-datacenter communication, the
updateDC2DC of the DashboardBean is called, while the list of stored
DC2DCCommunication entries is rendered. The user can also delete an
inter-datacenter communication by pushing the “Delete” button, which calls
the deleteDC2DC function. The changeLocalAS and changeRemoteAS
functions are also used to dynamically adjust local and remote AS numbers,
based on user’s selection of local and remote cloud names respectively.
o isp.xhtml: The autonomous systems page. The user may update the
ISP’s name (the updateIspName function is called), check stored
autonomous systems, add new ones (updateAS), update (editAS) or
delete (deleteAS) them.
Page 76 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o links.xhtml: The links page (Figure 26). The SBox administrator can
insert new links (updateLink), as well as update (editLink) or delete
(deleteLink) existing ones. The addSegment and deleteSegment
support functions are also used to add and delete, respectively, a Segment
for a selected Link.
o localclouds.xhtml: The local clouds page. The existing local clouds are
presented, and the user may insert (updateCloud) a local cloud, edit
(editCloud) or delete (deleteCloud) a stored one.
o remoteclouds.xhtml: The remote clouds page. The existing remote
clouds are presented, and the user may insert (updateRemoteCloud) a
remote cloud, edit (editRemoteCloud) or delete (deleteRemoteCloud) a
stored one.
o routers.xhtml: The BG and DA routers page (Figure 25). In this page,
the SBox administrator can insert (updateBGRouter, updateDARouter)
new BG and DA Routers, as well as delete (deleteBGRouter,
deleteDARouter) stored ones.
o sdncontrollers.xhtml: The SDN Controllers page. The SBox
administrator may check stored SDN Controllers, add new ones
(updateSDNController), update (editSDNController) or delete
(deleteSDNController) them.
o settings.xhtml: The DTM settings page (Figure 28). In this page, the
DTM execution and system parameters are configured and stored in the
database (updateTimeParams, updateSystemParams).
o tunnels.xhtml: The Tunnels page (Figure 27). The SBox administrator
can insert new tunnels (updateTunnel), as well as update (editTunnel)
or delete (deleteTunnel) existing ones.
css/: This directory includes all the css files used to format and style the Web
application pages. Besides, the 2 files (sbox-main.css and sbox-signin.css)
that describe the SBox UI style and format, the directory includes all the Twitter
Bootstrap css and theme files.
fonts/: It includes all Twitter Bootstrap fonts.
js/: This directory includes all the javascript files. These files are used to support
certain
Twitter
Bootstrap
components
(bootstrap.js,
bootstrapdropdown.js, bootstrap-modal.js, bootstrap-datetimepicker.js,
jquery.js, moment.js), and support the validation of the user input. In the
second case, the bootstrapValidator.js acts as the key element of forms’ validation,
highlighting correct/incorrect fields and enabling/disabling “Submit” button, while
additional javascript files (between.js, integer.js, ip.js, notEmpty.js)
provide individual fields’ validation, providing relevant error messages.
WEB-INF/: This directory includes the web.xml file, including Web application’s
configuration. The Web application supports FORM authorization method, which
means that a new or session-expired request will be always redirected to a sign-in

Version 1.0

Page 77 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

page to provide its username and password. Currently, access is limited only to
administrators, with credentials encrypted in Web server’s configuration files.
signin.jsp: The sign-in page of the Web application. In case of incorrect
credentials it redirects user to signinError.jsp page, otherwise to
index.xhtml.
signinError.jsp: The error page, when the user inserts incorrect credentials.
5.1.7.3
Tests
No automated tests were implemented for the User interface. The Web application was
tested during integration and system tests.

5.2

SDN Controller

The main purpose of SDN Controller is the selection of proper output interface of
OpenFlow-based switch in order to ensure traffic forwarding continuity in accordance with
current traffic statistics and the value of the Reference and Compensation vectors
received from SBox. Code of DTM module of SDN controller was updated since version
1.1 presented in D3.2 [2] in order to meet requirements of extended mechanism (DTM++).
Additionally, new working modes were introduced: reactiveWithReferenceVector,
reactiveWithoutReferenceVector,
proactiveWithReferenceVector
and
proactiveWithoutReferenceVector.
5.2.1 Interfaces
The SDN controller exposes the SBox-SDN Server Interface containing constants and
helper methods used commonly by the SBox and by the SDN controller.
5.2.1.1 Interfaces
The SBox-SDN Server exposes following constant URLs on which the SDN controller
listens:
public static final String BASE_PATH – Base path URL.
public static final String DTM_R_C_VECTORS_PATH – Path used by
server-side resource used for editing and retrieving RCVectors, i.e., RVector and
CVector.
public static final String DTM_CONFIG_DATA_PATH – Path used by
server-side resource used for editing and retrieving ConfigData.
Moreover, the helper methods for serialization, deserialization, and conversion from tunnel
id to OpenFlow switch port id are exposed:
public static <T extends
object) – Generic serializator.

Serializable>

String

serialize(T

public static <T extends Serializable> T deserialize(String
text, Class<T> clazz) – Generic deserializator.

Page 78 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

public static short toPort(TunnelID tunnelID) – Converter of tunnel id to OpenFlow
switch port id.
5.2.1.2 Design
The SBox-SDN interfaces have been implemented in four classes, all within package
eu.smartenit.sdn.interfaces.sboxsdn. They are presented in Figure 31.
public class URLs (non-instantiable) holds information on common constant
URLs (BASE_PATH, DTM_R_C_VECTORS_PATH, and DTM_CONFIG_DATA_PATH)
public class Serialization (non-instantiable) defines serialization and
deserialization helpers (serialize and deserialize)
public class SimpleTunnelIDToPortConverter defines converter of
simple tunnel id object to OpenFlow switch port number. It contains one method:
o public static short toPort(TunnelID tunnelID) – converts
tunnel id object to OpenFlow switch port number.
public final class RCVectors implements Serializable provides a
container for reference and compensation vectors. It contains two fields (with
getters and setters):
o private RVector referenceVector – reference vector;
o private CVector compensationVector – compensation vector.

Figure 31: SBox-SDN Server Interface classes.
5.2.1.3 Tests
One JUnit [19] class with seven test methods has been implemented:
public class SerializationTest:
o public void
RCVectors

testSerializeRCVectors() – tests serialization of

Version 1.0

Page 79 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public void testSerializeConfigData() – tests serialization of
ConfigData
o public void testDeserializeRCVectors() – tests deserialization of
RCVectors
o public void testDeserializeConfigData() – tests deserialization
of ConfigData
o public
void
testLinkBGRouterBiDirReferenceSerialization() – tests if bidirectional reference between Link and BGRouter are correctly
(de-)serialized.
o public void testTunnelLinkBiDirReferenceSerialization() –
tests if bi-directional reference between Tunnel and Link are correctly
(de-)serialized.
o public void testCloudDCASBiDirReferenceSerialization() –
tests if bi-directional reference between CloudDC and AS are correctly
(de-)serialized.
5.2.2 Floodlight
The SDN Controller is a component responsible for flow distribution in the remote
autonomous system. Depending on the selected mode Floodlight uses both, Reference
and Compensation vectors received from NTM (reactiveWithReference and
proactiveWithReference
modes)
or
only
Compensation
vector
(reactiveWithoutReference and proactiveWithoutReference modes).
The SDN controller provides generally following functionalities:
receiving of ConfigurationData, Reference and Compensation vectors via
northbound interface (REST),
OpenFlow flow rules establishment,
initial configuration of OpenFlow-based switch via OpenFlows messages,
traffic statistics collection from tunnels (in modes with Reference vector).
5.2.2.1 Interfaces
The SDN controller runs a HTTP server on port 8080 and exposes two REST interfaces
under following URLs:
URLs.BASE_PATH + URLs.DTM_R_C_VECTORS_PATH – used to send (using
POST request) and retrieve (using GET request) reference and compensation
vector in JSON-encoded RCVectors container; the reference vector may be set to
null – in this case it is not updated.
URLs.BASE_PATH + URLs.DTM_CONFIG_DATA_PATH – used to send (using
POST request) and retrieve (using GET request) configuration data in JSONencoded ConfigData object.

Page 80 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

5.2.2.2 Design
The SDN controller is designed as an extension to the Floodlight 0.90 controller [23]. The
functionality
has
been
implemented
in
packages
eu.smartenit.sdn.floodlight090.dtm
and
eu.smartenit.sdn.floodlight090.dtm.restlet. The former consists of six
classes, and the latter – of three classes. They are presented in the Figure 32.
public class DTM (singleton) – main DTM class; holds information on current
compensation vector, reference vector, and traffic transmitted; it contains following
methods:
o public static DTM getInstance() – returns DTM singleton; creates
one if necessary;
o public static void resetInstance() – sets DTM instance to null.
When the instance will be requested next time it will be created. This method
is mainly meant to be using in tests;
o public
IFloodlightProviderService
getFloodlightProvider()/public
void
setFloodlightProvider(IFloodlightProviderService
floodlightProvider) – returns/set FloodlightProvider;
o public
synchronized
void
setConfigData(ConfigData
configData)/public ConfigData getConfigData() – update/return
configuration;
o public
synchronized
void
setReferenceVector(RVector
referenceVector)/public RVector getReferenceVector() –
update/return reference vector;
o private
Set<Short>
getAllDARouterPorts(ConfigData
configData) – returns all switch OF port numbers;
o public synchronized void setCompensationVector(CVector
compensationVector)/public
CVector
getCompensationVector() – update/return compensation vector;
o public synchronized void setSwitch(IOFSwitch sw)/public
IOFSwitch getSwitch() – update/return switch on which DTM operates;
currently, only one switch is supported;
o private synchronized void transmittedBytesMapUpdated() –
modifies flow rule for proactiveWithReferenceVector controller mode;
o public long getTransmittedBytes() – returns traffic counter on
selected switch’s port;
o public Map<Short, Long> getTransmittedBytesOnAllPorts() –
returns statistics of transmitted bytes on all switch ports
o private
synchronized
void
resetTransmittedBytesStart(short daRouterOfPortNumber) –
resets traffic start counter on selected switch's port;

Version 1.0

Page 81 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public long getTransmittedBytesStart() – returns traffic start
counter on selected switch’s port;
o public void setOFPacketIn(OFPacketIn msg) – updates OpenFlow
PacketIn message on whitch DTM operates;
o public OFPacketIn getOFPacketIn() – returns OpenFlow PacetIn
message;
o public String intToStringIp(int i) – parses integer IP address to
string;
o public void sendStaticFlowRule(Map<NetworkAddressIPv4,
Short> dcPrefixOutOfPortMap) – sends static flow rule to switch
mapping output IP address to switch output port;
o public
synchronized
Map<NetworkAddressIPv4,
Short>
getProactiveOutOfPortNumber() – returns map of destination IP
address with output port in proactive modes; see pseudocodes in sections
5.2.2.2.3 and 5.2.2.2.4;
o public
synchronized
short
getReactiveWithReferenceOutOfPortNumber() – returns output port
of switch for a new flow for reactiveWithReference mode; see pseudocode in
section 5.2.2.2.1;
o public
synchronized
short
getReactiveWithoutReferenceOutOfPortNumber() – returns output
port of switch for a new flow for reactiveWithoutReference mode; see
pseudocode in section 5.2.2.2.2;
o private void validateConfigData(ConfigData configData) –
validates ConfigData;
o private
void
validateReferenceVector(RVector
referenceVector) – validates Reference Vector;
o private
void
validateCompensationVector(CVector
compensationVector) – validates Compensation Vector;
public class DTM.PortStatisticsPoller extends TimerTask – timer
task
responsible
for
getting
swithchport
statistics
every
PORT_STATISTICS_POLLING_INTERVAL ms; it contains one method:
o public void run() - requests port statistics (tx bytes) from switch and
saves the state upon success;
public class DTMFloodlightModule implements IFloodlightModule
– Floodlight module responsible for adding message listener, switch listener, and
RESTlet routable; it contains following methods:
o public Collection<Class<? extends IFloodlightService>>
getModuleServices()
and
public
Map<Class<?
extends
IFloodlightService>,
IFloodlightService>
getServiceImpls() – do nothing and return null; this module does not
implement any services;

Page 82 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public Collection<Class<? extends IFloodlightService>>
getModuleDependencies() – returns a list of modules that this module
depends on, i.e., IFloodlightProviderService IRestApiService;
o public
void
init(FloodlightModuleContext
initializes DTM module;
o public void startUp(FloodlightModuleContext
starts DTM module;

context)

context) –

public class DTMMessageListener implements IOFMessageListener
– adds a new flow when a packet in message is received from a switch; it contains
following methods:
o public Command receive(IOFSwitch sw, OFMessage msg,
FloodlightContext cntx) – processes new packet and add a flow for
it;
o public String getName() – returns the listener name;
o public
boolean
isCallbackOrderingPrereq(OFType
type,
String
name)
and
public
boolean
isCallbackOrderingPostreq(OFType type, String name) –
return false - this listener does not have pre/post-requisites.
public class DTMSwitchListener implements IOFSwitchListener –
listens for new switches and configures main DTM class.
o public void addedSwitch(IOFSwitch sw) – fired when a switch is
connected to the controller, and has sent a features reply; propagates the
information to DTM;
o public void removedSwitch(IOFSwitch sw) – fired when a switch is
disconnected from the controller; propagates the information to DTM;
o public void switchPortChanged(Long switchId) – fired when
ports on a switch change (any change to the collection of OFPhysicalPorts
and/or to a particular port); does nothing;
o public String getName() – returns the listener name;
public class Flows (non-instantiable) – manages flows; contains following
methods:
o public
static
void
init
(IOFSwitch
sw,
IFloodlightProviderService
floodlightProvider,
FloodlightContext cntx, short dcPort, short inetPort) –
initializes flow table in switch(adds return flows); adds flow for given switch,
outgoing port, and DC switch port; constructs OFMatch and instructs switch
to send all packets from the given interface to dcPort interface; the controller
sends the switch one OpenFlow message: ofp_flow_mod (with
OFPFC_ADD action);
o public
static
void
add(IOFSwitch
sw,
IFloodlightProviderService
floodlightProvider,
FloodlightContext cntx, short outPort, OFPacketIn pi) –

Version 1.0

Page 83 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

adds flow for given switch, outgoing port, and incoming packet; constructs
OFMatch from the incoming packet and instructs switch to send all packets
from the flow to be sent to given outgoing port; the received packet is sent
do switch for forwarding; the controller sends the switch two OpenFlow
messages:
ofp_flow_mod
(with
OFPFC_ADD
action)
and
ofp_packet_out;
o public
static
void
del(IOFSwitch
sw,
IFloodlightProviderService
floodlightProvider,
FloodlightContext cntx, String dcIP, int dcMask) – deletes
flow for given switch and destination DC IP; constructs OFMatch and
instructs switch to delete particular flow from its flow table; the controller
sends the switch a OpenFlow message: ofp_flow_mod (with
OFPFC_DELETE action);
o public
static
void
mod(IOFSwitch
sw,
IFloodlightProviderService
floodlightProvider,
FloodlightContext cntx, String dcIP, int dcMask, short
outPort) – modifies particular flow rule in switch; ; the controller sends the
switch
a
OpenFlow
message:
ofp_flow_mod
(with
OFPFC_MODIFY_STRICT action);
public class DTMRestletRoutable implements RestletRoutable –
Configures RESTlet resources; contains two methods:
o public Restlet getRestlet(Context context) – returns the restlet
that will map to the resources; two resources are mapped:
RCVectorsResource ConfigDataResource;
o public String basePath() – returns the base path URL where the
router should be registered;
public class ConfigDataResource extends ServerResource – Serverside resource used for editing and retrieving ConfigData; contains two mehods:
o public String
configuration data;

handleGet()

returns

JSON-serialized

DTM

o public String handlePost(String text) – sets JSON-serialized
new DTM config data; returns JSON-serialized current DTM config data;
public class RCVectorsResource extends ServerResource – Serverside resource used for editing and retrieving RCVectors, i.e., RVector and CVector;
contains two methods:
o public String handleGet() – returns JSON-serialized current R and C
vectors;
o public String handlePost(String text) – sets JSON-serialized
new R and C vectors; returns JSON-serialized current R and C vectors.
The Floodlight classes were all left unchanged. The only modifications to the controller
that have been done were the configuration files – the DTM module has been enabled
and the Forwarding module has been disabled.

Page 84 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 32: SDN Controller based on Floodlight 0.9 classes.

Version 1.0

Page 85 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

5.2.2.2.1

Pseudocode for reactiveWithReference mode

r_inv[1] = r[2];
r_inv[2] = r[1];
counter_start[1]=read_counter(1);
counter_start[2]=read_counter(2);
for(each new flow packet){
tunnel=1;
compensate=false;
If(C[1]>0){
tunnel=1;
compensate=true;
}
If(C[2]>0){
tunnel=2;
compensate=true;
}
if(compensate){
for(each timer=1sec) if(read_counter(tunnel)-counter_start[tunnel]>
C[tunnel]/r_inv[tunnel]){
for(k=1 to 2) counter_start[k]=read_counter(k);
tunnel=(tunnel mod 2) +1;
compensate=false;
}
send_SDN_rule(tunnel);
}
else {
for(each timer=1sec){
traffic_1=read_counter(1) - counter_start[1];
traffic_DA-B=traffic_1 + read_counter(2) - counter_start[2];
if(traffic_1/ traffic_DA-B < = r[1])
tunnel=1;
else
tunnel=2;
send_SDN_rule(tunnel);
}
}
}

5.2.2.2.2

Pseudocode for reactiveWithoutReference mode

for(each new flow packet){

Page 86 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

If(C[1]==0) tunnel=1;
If(C[1]>0) tunnel=1;
If(C[2]>0) tunnel=2;
send_SDN_rule(tunnel);
}

5.2.2.2.3

Pseudocode for proactiveWithReference mode

r_inv[1] = r[2];
r_inv[2] = r[1];
counter_start[1]=read_counter(1);
counter_start[2]=read_counter(2);
for(each new C){
tunnel=1;
compensate=false;
if(C[1]>0){
tunnel=1;
send_mod_SDN_rule(tunnel, wildcard);
compensate=true;
}
if(C[2]>0){
tunnel=2;
send_mod_SDN_rule(tunnel, wildcard);
compensate=true;
}
}
if(compensate){
for(each timer=1sec)
if(read_counter(tunnel)-counter_start[tunnel]>
C[tunnel]/r_inv[tunnel]){
for(k=1 to 2) counter_start[k]=read_counter(k);
compensate=false;
tunnel=(tunnel mod 2) +1;
send_SDN_remove_rule(all);
break;
}
else {
for(each new flow packet){
send_SDN_rule(tunnel);
for(each timer=1sec){

Version 1.0

Page 87 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

traffic_1=read_counter(1) - counter_start[1];
traffic_DA-B = traffic_1 + read_counter(2)
- counter_start[2];
if(traffic_1/ traffic_DA-B < = r[1])
tunnel=1;
else
tunnel=2;
}
}

5.2.2.2.4

Pseudocode for proactiveWithoutReference mode

for(each new C){
if(C[1]== 0) tunnel=1;
if(C[1]>0) tunnel=1;
if(C[2]>0) tunnel=2;
send_mod_SDN_rule(tunnel,wildcard);
}

5.2.2.3 Tests
Eight JUnit [19] classes were developed to test the implementation:
public class DTMConfigProcessingTest – tests configuration processing
by DTM module; contains following tests:
o public void testGetInstance() – tests if DTM.getInstance() returns
the same value in subsequent calls;
o public void testSetConfigData() – tests the configuration data
setter;
o public void testSetSwitch() – tests OpenFlow switch setter;
public class DTMFlowDistributorTest – main DTM test class for single-tosingle DTM setup; contains following tests:
o public
testGetReactiveWithReferenceOutOfPortNumber()
algorithm for reactiveWithReference mode;

o public
testGetReactiveWithoutReferenceOutOfPortNumber()
algorithm for reactiveWithoutReference mode;
o public
testGetProactiveWithoutReferenceOutOfPortNumber()
algorithm for proactiveWithReference mode;

Page 88 of 191

void
tests

void
tests
void
tests

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

public class DTMFlowDistributorTwoDCsTest – main DTM test class for
multi-DC DTM setup; contains following tests:
o public
testGetReactiveWithReferenceOutOfPortNumber()
algorithm for reactiveWithReference mode;

void
tests

o public
testGetReactiveWithoutReferenceOutOfPortNumber()
algorithm for reactiveWithoutReference mode;
o public
testGetProactiveWithoutReferenceOutOfPortNumber()
algorithm for proactiveWithReference mode;

void
tests

void
– tests

public class DTMTestCase – contains test cases for the purpose of flow
distribution tests;
public class DTMVectorsProcessingTest – tests vector processing by
SDN controller; contains following tests:
o public void testSetReferenceVector() – tests setup of single
Reference Vector;
o public void testSetMultipleReferenceVectors() – tests setup
of multiple Reference Vectors;
o public void testSetCompensationVector() – tests setup of single
Compensation Vector;
o public void testSetMultipleCompensationVector() – tests
setup of multiple Compensation Vector;
public final class FakeStatisticsProviderOFSwitch – class providing
fake OpenFlow-enabled switch for reactive mode tests;
public class FlowDistributorSetUpHelper – helper class with constant
values of Compensation Vector for DTMFlowDistributorTest
and
DTMFlowDistributorTwoDCsTest classes;
public class TestSetUpHelper – helper class with constant values of
ConfigData and fake OpenFlow PacketIn message;

Version 1.0

Page 89 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

6 The Replicating Balanced Tracker - Home Router
Sharing based on Trust (RB-HORST) mechanism
RB-HORST mechanism focuses on end-users and is deployed on devices owned and
controlled by them. Therefore, the mechanism’s functionalities map onto two architecture
entities: the user Nano-Datacenter (uNaDa), which implements the social monitoring,
social and overlay prediction, content prefetching and WiFi offloading functionalities and is
expected to be hosted on domestic WiFi access point devices or home gateways, and the
End-User application, which is deployed in end-user devices, e.g. smartphones, tablets.
The aforementioned entities and their respective components’ functionality, interfaces,
design and local tests will be presented in the sections that follow.

6.1

uNaDa

The uNaDa entity includes all the required components to execute the RB-HORST
mechanism. The following sections will provide a brief description for each component,
and document their exposed interfaces, design details, and local tests executed to
validate their correctness.
6.1.1 Cloud Traffic Manager
The Cloud Traffic Manager (CTM) component is the coordinating element of the uNaDa. It
is responsible for:
initializing the social monitoring function,
periodically querying the Overlay Manager and Social Analyzer components for the
ranked list of predicted contents,
managing the uNaDa’s cache, either by checking the ranked content list deriving by
the social and overlay prediction, or periodically cleaning the least accessed
contents,
implementing the content prefetching functions, either from the Vimeo servers or
other overlay peers.
6.1.1.1 Interfaces
The Cloud Traffic Manager exposes 4 interfaces:
CacheManager: The cache management interface. It includes methods to update
the cache based on the received sorted lists of content from the social and overlay
prediction and periodically delete the expired contents. This interface is called
internally upon uNaDa initialization.
o void
updateCache(List<Content>
socialContentList,
List<Content> overlayContentList): The method that updates the
cache based on the received sorted lists of content from the social and
overlay prediction. It receives the following input parameters:

Page 90 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

socialContentList The sorted list of contents from the social
prediction.

overlayContentList The sorted list of contents from the overlay
prediction.

o void deleteExpired(): The method that deletes the expired contents
from the local cache and database.
ContentAccessLogger: It updates the content access log for a specific content
and user. This interface is called when a content access is received in the uNaDaend-user REST interface (Section 6.1.6.1) through the proxy component.
o boolean updateAccessLog():The method that updates the access log
for a specific content and user. If the recent accesses are very near to the
current time, then the access log is not updated.

It returns a Boolean, which is the outcome of the update.

ContentManager: It includes methods to delete contents from the database and
the local cache, prefetches content, either from Vimeo or other uNaDas and inserts
them to the local cache. This interface is called internally by the CacheManager
interface.
o void deleteContent(Content content): The method that deletes a
content from both the local cache and the database.

It receives as input the content to be deleted.

o void deleteContents(List<Content> contents): The method that
deletes a list of contents from both the local cache and the database.

It receives as input the list of contents to be deleted.

o void prefetchContent(Content content): The method that
prefetches a content, and inserts it to the local cache and the database.

It receives as input the content to be prefetched.

o void prefetchContents(List<Content> contents): The method
that prefetches a list of contents, and inserts it to the local cache and the
database.

It receives as input the list of contents to be prefetched.

o void
deleteContents(List<Content>
contents,
long
threshold): The method that deletes a list of contents from both the local
cache and the database, that were not accessed since the given time
threshold. It receives as input

The list of contents to be deleted,

The time threshold, after which contents which were not accessed
should be deleted.

VideoDownloader: The video downloading interface. It downloads the content,
either from the Vimeo servers, or other overlay peers. It is called, either from other

Version 1.0

Page 91 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

internal interfaces, or when a content download request is received in the uNaDaend-user REST interface (Section 6.1.6.1) through the proxy component.
o void downloadVideo(): The method that downloads a video and stores
it in local cache.
The implementation and internal functionality of each interface will be presented in the
following section.
6.1.1.2 Design
Figure 33 presents the class diagram of the CTM component. It includes all the interfaces,
classes and their associations and dependencies, as well as their parameters and
implemented methods. The key classes and methods are described below:
CacheManagerImpl implements CacheManager: It includes methods to
update the cache, based on the received sorted lists of content from the social and
overlay prediction.
o public void updateCache(List<Content> socialContentList,
List<Content> overlayContentList): The method that updates the
cache based on the received sorted lists of content from the social and
overlay prediction.
o public void deleteExpired():The method that deletes the expired
contents from the local cache and database.
o private int contentExistsInList(List<Content> list, long
contentID): The method that checks whether a content belongs a content
list.
o public
void
updateSocialContentListWithSizes(List<Content>
contentList): The method that updates the social content list with their
sizes, as retrieved from Vimeo.
ContentAccessLoggerImpl
Runnable:

implements

ContentAccessLogger,

o public boolean updateAccessLog(): It updates the content access
log for a specific content and user.
o public boolean updateAccessLog(): The method that updates the
access log for a specific content and user. If the recent accesses are very
near to the current time, then the access log is not updated.
o public void run(): The default thread start method.
ContentManagerImpl implements ContentManager: It includes methods to
delete contents from the database and the local cache, prefetches content, either
from Vimeo or other and inserts them to the local cache.
o void deleteContent(Content content): The method that deletes a
content from both the local cache and the database.

Page 92 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o void deleteContents(List<Content> contents): The method that
deletes a list of contents from both the local cache and the database.
o void prefetchContent(Content content): The method that
prefetches a content, and inserts it to the local cache and the database.
o void prefetchContents(List<Content> contents): The method
that prefetches a list of contents, and inserts it to the local cache and the
database.
o void
deleteContents(List<Content>
contents,
long
threshold): The method that deletes a list of contents from both the local
cache and the database, that were not accessed since the given time
threshold.
OverlayDownloader
implements
VideoDownloader,
Runnable: It
includes methods that retrieve content information from the overlay, and download
the content, if not present in the cache.
o public
void
run():
OverlayDownloader thread.

The

method

that

executes

the

o public void downloadVideo(): The method that downloads the video
from the overlay. It checks whether the content is cached, otherwise it
downloads it and stores it in the local cache.
VimeoDownloader implements VideoDownloader, Runnable: It includes
methods that retrieve content information from Vimeo, and download the content, if
not present in the cache.
o public void run(): The method that executes the VimeoDownloader
thread.
o public void downloadVideo(): The method that downloads the video
from Vimeo. It checks whether the content is cached, otherwise it downloads
it and stores it in the local cache.
o public Path getVideoStorage(VGet v): The method that extracts
the path where the video will be downloaded.
o public long getVideoID(String url): The method that retrieves the
content ID from the request url.
VimeoInfoRetriever: It includes a method which retrieves a Vimeo's video
information from the Vimeo.
o public VideoInfo retrieveVideoInfo(String url): The method
that retrieves the content information from Vimeo.
UnadaOrchestrator implements Runnable: It bootstraps the uNaDa Web
application functions.
o public void run(): The method running the bootstrap method. If its
outcome is successful, then thread is over, otherwise runs the bootstrap
again after 2 minutes.

Version 1.0

Page 93 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public boolean bootstrap(): The method bootstrapping all the
uNaDa functionalities: (a) starting or joining the overlay, (b) advertising
content to the overlay, (c) start social monitoring and, (d) start social and
overlay prediction.
PredictionTask implements Runnable: It initializes the social and overlay
prediction algorithms.
o private void predict(): The method that requests the ranked content
list from the social and overlay prediction algorithms and then provides them
to the cache manager to perform the required content downloads, deletions
and updates.
o public void run(): The method that starts the thread.
CacheCleanerTask implements
contents from the cache.

Runnable: It removes expired cached

o public void run(): The method that runs the thread.
Figure 34 presents which functions are initialized when the uNaDa Web application starts.
The coordinating class is the UnadaOrchestrator, which is triggered by the
bootstrap() method. It then queries the UnadaConfiguration and Owner tables
to check whether the required configuration parameters are set, as well as the user has
logged in with his Facebook credentials, hence has gained ownership of the uNaDa. In the
positive case, the uNaDa joins the overlay through the joinOverlay() function of the
OverlayManager, and starts the social monitoring function, by calling the
startMonitoring() method of SocialMonitor. Finally, the periodic prediction and
cache cleaning tasks are also initialized.
When the PredictionTask is called, it runs periodically and executes the social and
overlay prediction algorithms, and subsequently the cache management task. Specifically,
it retrieves from the OverlayManager and the SocialAnalyzer the sorted list of
predicted contents, through the predicting() and getPrediction() methods
respectively, and then provides them to the CacheManager to update the cache, through
the updateCache() method. Figure 35 presents the aforementioned function calls, as
well as a simple case, when some of the predicted contents are prefetched, by calling the
relevant ContentManager method, and each one is downloaded through the
VimeoDownloader downloadVideo() function. In addition, the low-ranked contents
are either ignored or deleted –if are stored- from the cache, by triggering the
deleteContents() method.

Page 94 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 33: CTM class diagram.

Version 1.0

Page 95 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 34: CTM orchestrator sequence diagram.

Figure 35: Cache management sequence diagram.
6.1.1.2.1

Cache management algorithm

The simplified pseudocode for the handling of the ranked content lists, provided by the
social and overlay prediction algorithms, and the basic cache management is presented
below. In principle, the contents predicted by the overlay prediction have a slight
advantage, since they can be downloaded by close peers and save unnecessary interdomain traffic. Close peers are considered the uNaDas that belong to ASes up to 1 hop
away. In this sense, if a content item belongs to both the overlay and social ranked lists,
then it will be downloaded from the overlay, unless the closest peer is more than 1 hop
away. Otherwise, it will be downloaded from Vimeo servers. Of course, the projected size
of the cache (sum of current cache size and content size) is always taken into account,
before adding the content to the ones that can be prefetched. The deleteIgnored()
function will either delete a content if it exists in the cache, or ignore it.

Page 96 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

updateCache(socialContentList, overlayContentList):
foreach content in socialContentList:
if content does not exists in overlayContentList:
if socialScore > socialThreshold AND (currentCacheSize +
contentSize < cacheSize):
VimeoDownloader.download(content)
else:
ignoreList.add(content)
foreach content in overlayContentList:
if (overlayScore > overlayThreshold) AND (currentCacheSize +
contentSize < cacheSize):
if overlayHops <= 1:
OverlayDownloader.download(content)
else:
VimeoDownloader.download(content)
else:
ignoreList.add (content)
deleteIgnored(ignoreList)

6.1.1.3 Tests
The JUnit [19] tests that validate the correctness of the aforementioned functions and
algorithms are presented below:
CacheManagerTest
o public void testDeleteContents(): Tests the deleteContents()
function.
o public void testUpdateCacheFetchOneIgnoreOne(): Tests the
updateCache function, for one content above and one content below
threshold
o public void testUpdateCacheFetchAll(): Tests the updateCache
for multiple contents above threshold.
o public void testUpdateCacheIgnoreAll():Tests the updateCache
for multiple contents below threshold.
o public
void
testUpdateCacheFullCacheAboveThresholdIgnoreAll():Tests the
updateCache for multiple contents above threshold, but for full cache.
o public
void
testUpdateCacheFullCacheBelowThresholdIgnoreAll():Tests the
updateCache for multiple contents below threshold and full cache.

Version 1.0

Page 97 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o public
void
testUpdateCacheNearFullCacheAboveThresholdIgnoreSecond():
Tests the updateCache for multiple contents above threshold, but with
cache near to full, hence the second is ignored.
o public void testUpdateCacheFetchAllSocialOverlay(): Tests
the updateCache for multiple contents above threshold.
o public void testUpdateCacheContentInBothListsLowScore():
Tests the updateCache for contents belonging in both social and overlay
list, but with low score.
o public void testUpdateCacheContentInBothListsGoodScore():
Tests the updateCache for contents belonging in both social and overlay
list, with good score.
ContentManagerTest
o public
void
testDeleteNullContent():
deleteContent() for a null one.

Tests

the

o public void testDeleteContent(): Tests the deleteContent().
o public
void
testDeleteNullContents():
deleteContents() for a null list.
o public
void
testDeleteEmptyListContents():
deleteContents() for an empty list.

Tests
Tests

the
the

o public void testDeleteContents(): Tests the deleteContents()
for existing ones.
o public
void
testPrefetchNullContent():
prefetchContent() for a null one.

Tests

the

o public
void
testPrefetchSocialContent():
prefetchContent() for one belonging to the social list.

Tests

the

o public
void
testPrefetchOverlayContent():
prefetchContent() for one belonging to the overlay list.

Tests

the

o public
void
testPrefetchContents():
Tests
the
prefetchContents() for multiple ones belonging to social and overlay
lists.
FileUtilsTest
o public void testDeleteFile(): Tests the deleteFile() function.
o public void testGetRootPath(): Tests a method which finds its root
directory.
OverlayDownloaderTest
o public
void
testDownloadVideoNotCached():
Tests
the
downloadVideo() for a non-cached video, hence the video is
downloaded.

Page 98 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public
void
testDownloadVideoCached():
downloadVideo() for a cached video.

Tests

the

o public
void
testUpdateAccessLogNoMAC():
Tests
updateAccessLog() method when no MAC address is provided.

the

VimeoAccessLoggerTest

o public void testUpdateAccessLogNoTrustedUser(): Tests the
updateAccessLog() method when the user is not trusted.
o public void testUpdateAccessLogNoContentAccess(): Tests the
updateAccessLog() method for the first time.
o public
void
testUpdateAccessLogRecentContentAccess():
Tests the updateAccessLog() method when recent access logs for the
same user exist.
o public void testUpdateAccessLogNotRecentContentAccess():
Tests the updateAccessLog() method when no recent access logs for the
same user exist.
VimeoDownloaderTest
o public void testDownloadVideoMobileNotCached(): Tests the
downloadVideo() function for a non-cached mobile video.
o public
void
testDownloadVideoCached():
downloadVideo() function for a cached video.
o public
void
testGetVideoStorage():
getVideoStorage() method.

Tests
Tests

the
the

o public void testGetVideoID(): Tests the getVideoID() method.
VimeoInfoRetrieverTest
o public
void
testRetrieveVideoInfo():
retrieveVideoInfo() method.

Tests

the

o public
void
testRetrieveVideoInfo2():
retrieveVideoInfo() method.

Tests

the

o public
void
testRetrieveFalseVideoInfo():
retrieveVideoInfo() method for a false video URL.

Tests

the

VimeoPatternsTest
o public void testPatterns(): Tests the Vimeo patterns.
6.1.2 Overlay Manager
The Overlay Manager (OM) component is the communicating component of the uNaDa. It
is responsible for:
initializing and maintaining the overlay network,
calculating the overlay prediction,
Version 1.0

Page 99 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

sending messages between uNaDas,
downloading content from other uNaDas.
6.1.2.1 Interfaces
The IOverlayManager interface is the external interface of the Overlay Manager (OM) that
should be used by components relying on the OM. It offers all the methods called by the
Cloud Traffic Manager (CTM). The overview of methods is depicted in Figure 36.

Figure 36: The external interface of the Overlay Manager.
The methods offered allow a user to join, create, or update and overlay network. To join
an IP address and port number of an existing peer is required. To create a new overlay
nothing is required but interface name or IP address to be used for binding can be
specified. Update must be used if the IP address of the host changes.
Further methods are offered to advertise content to the other uNaDas, send messages to
other uNaDas, calculate an overlay prediction, to download a specific content from
another uNaDa, and to retrieve a list of close uNaDas that share a content. The
getuNaDaInfo() method returns the address and ID of the local uNaDa. The
shutDown() method is used to gracefully leave the overlay network and let others know
that this uNaDa is leaving the system.

Page 100 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 37: Class diagram of the logical classes of the OM.
Version 1.0

Page 101 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

6.1.2.2 Design
Internally the OM is much more complex than the interface offered to other components.
Figure 37 depicts the classes of OM excluding messages which shall be explained later.
The OverlayManager is the main class of the component orchestrating the three
functional areas of overlay, downloading, and neighbor relations. These functional areas
are covered by three delegate classes shortly explained:
The Overlay class is responsible for all overlay related functionality like joining, leaving,
or creating a network as well as DHT lookups and sending messages.
The ContentDownloadHandler class manages the downloading process from other
uNaDas. It uses methods from OverlayManager to find providers for a given content.
Furthermore, it handles chunking an error checking of transferred data.
The NeighborDatabase mainly acts as a storage facility for known uNaDas. It keeps
them sorted according to as hops and acts as a cache for discovered AS paths. It makes
sure no traceroutes for discovered uNaDas are executed.
Figure 38 shows all messages used in the OM component. There is one abstract super
type called BaseMessage from which all messages inherit and which is used by OM to
send and execute messages.
The concept of the execute()method helps reduce boilerplate code like “if instance of
XY then ….” since every message contains the logic it has to trigger in the receiving
uNaDa. This pattern also avoids casting deserialized messages. Typically, messages are
pairs of request and replies and therefore a request message’s execute method will
somehow trigger the response message being sent back to the sender.

Figure 38: Messages used in the in Overlay Manager.

Page 102 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

6.1.2.3 Tests
OverlayManagerMessagingTest
o public void basicMesagingTest() tests if a message can be sent
from one OM to another.
o public void requestProviderTest()tests the queryProviders()
method of OM
o public
void
requestContentInfoTest()tests
request and reply messages.

getContentInfo

OverlayManagerPredictionTest
o testPrediction()tests the getPrediction() method of OM with a
mocked network.
OverlayManagerTest
o public void testJoinOverlay() tests if a uNaDa can successfully
join the DHT and retrieve its own uNaDa information.
o public void testUpdateOverlay() tests if a uNaDa can update its
uNaDa information
6.1.3 Topology Proximity Monitor
6.1.3.1 Functionality
The Topology Proximity Monitor is an entity responsible for determining the distance
between the local uNaDa and a number of remote ones. The distance is measured as a
number of AS hops on the path from a remote uNaDa and the local one. The list of AS
hops is determined by perfoming a traceroute and converting IPd to ASNs.
6.1.3.2 Interfaces
TPM provides other components with a TopologyProximityMonitor interface
containing two methods:
public
List<ASVector>
sortClosest(Collection<UnadaInfo>)
throws InterruptedException returns a list of unique uNaDa identifiers
sorted from the nearest to the furthest as well as the list of AS hops on the path
from each uNaDa on the list and the local one.
public
List<Integer>
getASVector(UnadaInfo)
throws
UnknownHostException, IOException, InterruptedException returns
a list of AS hops from on the path from the local uNaDa to the remote one.
6.1.3.3 Design
The component consists of five classes:

Version 1.0

Page 103 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

public class ASVector implements Comparable<ASVector> is a helper
structure holding a remote uNaDa identifier and a list of AS numbers on the path
from the local uNaDa to the remote one.
public
class
TopologyProximityMonitorImpl
implements
TopologyProximityMonitor is an implementation of the interface provided by
the component. When a sortClosest method is called on a local uNaDa, it uses
the Overlay Manager to send remote traceroute request to each of the remote
uNaDas. When a remote uNaDa TPM receives the remote traceroute request, it
executes the getASVector method, performs a traceroute using the tools built
into Windows or Linux (depending on host OS), and parses the traceroute output.
Then the IP addresses are converted to the AS numbers by using the Team Cymru
IP to ASN Mapping service. The list of the AS numbers is sent back to the
requesting uNaDa through the overlay. When the local uNaDa receives all remote
traceroute replies (or a timeout occurs), it sorts the remote uNaDas ascending by
the AS hops count.
public class TeamCymruWhoisClient is a helper class – a Team Cymru IP
to ASN Mapping service client.
public
class
TeamCymruWhoisClientHandler
extends
SimpleChannelInboundHandler<String> is a helper class – an inbound
handler capable to handle and parse rensponse from Team Cymru IP to ASN
Mapping service
public
class
TeamCymruWhoisClientInitializer
extends
ChannelInitializer<SocketChannel> is a helper class – a channel initializer
for TeamCymruWhoisClientHandler.
The classes and their relations are depicted in Figure 39.

Page 104 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 39: TPM class diagram.
6.1.3.4 Tests
TopologyProximityMonitorImplTest
o testSortClosest()
tests
sortClosest(Collection<UnadaInfo>) method

if

the

processes remote traceroute requests and replies properly,

handles reply timeout,

sorts the uNaDas in the correct order.

Version 1.0

Page 105 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o testGetASVector() tests if the getASVector(UnadaInfo) method
prepares the ASVector structure properly after parsing the traceroute output.
o testParseTraceroute() tests if the traceroute output is parsed properly
on current platform.
o testParseWindowsTraceroute() test if the Windows tracert output is
parsed properly.
o testParseLinuxTraceroute() test if the Linux traceroute output is
parsed properly.
TeamCymruWhoisClientTest
o testIsSpecialPurposeAddress() test if the TeamCymruWhoisClient
is able to determine if an IP addess is as special purpose one or a routable
one.
o testIpToASN() tests if the ipToASN(Collection<Inet4Address>)
method connects to the Team Cymru IP to ASN Mapping service and is able
to gather AS numbers from the service properly.
6.1.4 Social Monitor
The Social Monitor is the instance which is responsible for retrieving social data from
Facebook and Vimeo. The Social Monitor is designed such that it can run in the
background.
6.1.4.1 Interfaces
The Social Monitor does not provide any interfaces.
6.1.4.2 Design
The Social Monitor designed such that it can run in the background and therefore provides
methods to start and stop the monitoring process. The two methods provided are:
public ScheduledFuture<?> startMonitoring(Owner owner): Starts
retrieving data for a given owner.
public
void
stopMonitoring(ScheduledFuture<?>
retrieving data for a given ScheduledFuture instance.

sf):

Stops

An UML diagram of the Social Monitor is provided in Figure 40.

Figure 40: UML diagram of Social Monitor.
Page 106 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

The Social Monitor class wraps the MonitorRunner class which contains the actual data
retrieval logic. The run method described below encapsulates the complete retrieval logic:
public void run(): Method that invokes the MonitorRunner
A UML diagram of the MonitorRunner is shown in Figure 41.

Figure 41: UML diagram of Monitor Runner.
6.1.4.3 Tests
The Social Monitor and the Social Monitor Runner are tested in the following classes:
SocialMonitorTest
o
public void runSocialMonitor(): Tests the operation of
SocialMonitor
o
public void getFriendsTest(): Tests friend list retrieval
MonitorRunnerTest
o public void test(): Invokes the test procedure.
6.1.5 Social Analyzer
The Social Analyzer is the component which is responsible for analyzing social data
obtained by the Social Monitor. Based on specific properties of content items, namely its

Version 1.0

Page 107 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

age, the geographic distance from its download location, the number of accesses in the
local database, the number of views, and the number of Facebook friends who reposted
the content item, a prediction score is calculated. This prediction score is calculated to
determine the probability whether some particular Facebook user will use the content item
in question.
6.1.5.1 Interfaces
The Social Analyzer does not expose any interfaces but it does provide public methods.
The Social Analyzer consists of a single class exposing a single public method, named
predicting(). The prediction algorithm is invoked by calling the predicting() method of the
Social Analyzer class.
public List<Content> predicting(): Invokes the prediction algorithm and
returns a List of Content items, sorted by their score (ascending)
6.1.5.2 Design
The UML diagram of the Social Analyzer class is shown in Figure 42. The class holds the
complete logic for the prediction algorithm. A complete description of the individual
methods is omitted at this point because its complexity is tremendous. The design of
these methods can be summarized though.
private List<FeedItem> getFeedItems(): Retrieves FeedItems from the
database

Figure 42: UML diagram of Social Analyzer.

Page 108 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Once the feed data required for the calculation is retrieved from the database, the
calculation phase starts. It consists of a well-defined sequence of get* methods which
retrieve necessary data from the database and calculate* methods which are responsible
for calculating separate parts of the prediction score. Finally, the feed items are sorted by
their prediction score and returned in a list.
6.1.5.3 Tests
SocialAnalyzerTest
o
public void predictionTest(): Tests the correctness of the
prediction algorithm.
6.1.6 uNaDa-End-User Interface
The uNaDa-End-User interface module exposes the uNaDa’s interfaces towards the enduser device, as well the proxy component deployed within the uNaDa. It specifically
implements the login interface, which is accessed by the End-User application to provide
the remote user’s credentials and connect to the uNaDa’s private SSID, as well as the
download and access interfaces, which are used by the proxy component to download a
specific content and log a content access respectively.
6.1.6.1 Interfaces
The uNaDa-End-user interface component exposes 3 REST interfaces, each one
implemented by the respective *Service class:
LoginService: The login REST API of the uNaDa towards the end-user device.
It listens for GET end-user application login requests to the following URL:
http://<unada-ip-address>:<unada-port>/unada/rest/login/<facebookID> for the
specific facebookID:
o public RemoteLoginReply login(@PathParam("facebookID")
String facebookID, @Context HttpServletRequest request):
The login method. It checks whether the user is a trusted one. If yes, then it
executes an ARP request and updates its entry with his MAC address and
finally returns the private SSID parameters (SSID name and password) in
JSON format. Otherwise, it returns a negative reply.
It receives as input the user’s Facebook identifier.
DownloadContentService: The download REST API of uNaDa. It listens for
GET requests at the following URL: http://<unada-ip-address>:<unadaport>/unada/rest/download/<contentID> to download a specific video with the
specified contentID:
o public boolean download(@PathParam("contentID") String
contentID): The download method. It downloads a Vimeo video with
contentID.
It receives as input the content identifier to be downloaded.

Version 1.0

Page 109 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

AccessContentService: The content access REST API of the uNaDa. It listens
for
POST
requests
to
URL:
http://<unada-ip-address>:<unadaport>/unada/rest/access to log an access of a specific video request to local cache
path.
o public
boolean
access(String
path,
@Context
HttpServletRequest request): The access POST method. It inserts
an access entry for the specified content, if it exists in local cache path.
It receives as input the path of the requested content.
6.1.6.2 Design
The component consists of the aforementioned 3 classes, which are also presented the
class diagram of Figure 43.

Figure 43: uNaDa-End-user class diagram.
Figure 44 presents the sequence diagram when the login service at URL: http://<unada-ipaddress>:<unada-port>/unada/rest/login/<facebookID>. It initially checks whether there is
a trusted user with the provided facebookID, and if in the positive case, it retrieves the
latest uNaDa configuration including the private SSID credentials, as well as executes an
ARP request to get the device’s MAC address and updates its entry.

Figure 44: The login service sequence diagram.

Page 110 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

6.1.6.3 Tests
One class implements the JUnit [19] tests for the login service:
LoginServiceTest: The LoginServiceTest class implementing tests for the login
REST API.
o public void testNonExistingTrustedUser(): The test case for a
non-existing trusted user.
o public void
trusted user.

testExistingTrustedUser(): The test case for a

6.1.7 Database
The Database (DB) component is responsible both for relational tables’ creation and the
application connection to the uNaDa database. It includes the following modules:
dto: Contains all the Data Transfer Objects (DTO) of the database, namely all the
Java classes that correspond to the relational tables of the DB, and some additional
helper entities, which are used by certain components, but are not stored into the
database.
dao: Contains all the Data Access Objects (DAO) one for each table. Each of them
contains the methods provided to external components for reading from or writing
to the corresponding table. The dao module also includes the 4 following
packages:
o binders: Contains the binder classes.
o mappers: Contains the mapper classes.
o impl: Contains the implementation of each abstract class defined in the
root directory.
o util: Contains helper classes.
The DB contains the SQL tables described in the Design Subsection 6.1.7.2.
6.1.7.1
Interfaces
The DB component provides its services by exposing for each table a number of methods.
These methods, which reside for each table-entity in the corresponding DAO class,
named <entity-name>DAO, constitute the DB interface to the other components. Each of
these methods wraps up one or more SQL commands, located in the corresponding
Abstract<entity-name>DAO. In the case of multiple SQL commands, these may reside in
more than one Abstract<entity-name>DAO.
There is a set of methods which are implemented by almost all DAOs, while few others
are more specific, more complicated therefore implemented usually by a single (or more
cooperating) DAO. The common methods are briefly described as follows.
public void createTable(): The method that creates the corresponding
table.

Version 1.0

Page 111 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

public void deleteTable(): The method that deletes the corresponding
table.
public void insert(<entity type> e): The method that inserts an entity
to the corresponding table.
o Input parameter: The entity to be inserted.
public List<entity type> findAll(): The method that finds all the
stored entities from the respective table.
o Returns: The list of stored entities.
public <entity type> findById(<primary-key-type> pk): The
method that finds a stored entity by the corresponding table’s primary key.
o Input parameter: The primary key.
o Returns: the entity indexed by the primary key.
public <entity type> findLast(): The method that finds the last stored
entity.
o Returns: The most recent stored entity.
public void update(<entity type> e):The method that updates a stored
entity into its table.
o Input parameter: The entity to be updated.
public void deleteById(<primary-key-type> pk): The method that
deletes a stored entity by its table primary key.
o Input parameter: The primary key.
public void deleteAll(): The method that deletes all the stored entities
from the respective table.
6.1.7.2
Design
The DB schema contains the following SQL tables depicted in Figure 45:
UNADACONFIGURATION: It includes all the required unada configuration
parameters, including the bootstrap node’s IP address and port, the uNaDa’s MAC
address, and location, the open and private SSID name and password, and the
social, overlay and prediction intervals,
SOCIALPREDICTIONPARAMETERS: It includes the social prediction parameters
CACHE: It includes the cache configuration parameters, including the total size of
the uNaDa cache, its threshold, as well as the time-to-live for cached contents.
CONTENT: It is used to store entries for the cached contents. Its entries include
information about a content’s size, url, storage path, quality and cache date and
score.
CONTENTACCESS table stores the content accesses of a specific content by a
specific facebook identifier

Page 112 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

VIDEOINFO: The table that stores metadata for posted videos in the user’s
Facebook News Feed. Metadata include the publication date of the video, and its
views number.
TRUSTEDUSER: It includes the list of the uNaDa’s trusted users, providing the
Facebook identifier of the user, his MAC address and the last access timestamp.
FRIEND: It includes the list of uNaDa owner’s Facebook friends.
OWNER: It provides information about the uNaDa’s owner.
FEEDITEM: It stores the list of Facebook feed items, as these are published in
uNaDa owner’s Facebook News Feed. This table includes the content identifier, the
user Facebook identifier, the post’s type and timestamp.

Figure 45: uNaDa database schema.
Figure 46 presents a class diagram including all data transfer objects and their
relationships. The class diagram maps to the aforementioned database schema.

Version 1.0

Page 113 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 46: Data Transfer Objects class diagram.
Figure 47 presents the class diagram for the CONTENT table DAO-related classes. The
logic is similar to the one presented in SBox DB component implementation (Section
5.1.6) and all other entities conform to this. Overall, five different classes are required to
provide read/write access to the respective table. Specifically, the ContentDAO class
provides the necessary interface to all the other components, and uses the respective
functions of the AbstractContentDAO class, which executes all the SQL insertions,
updates and queries. Additional classes, BindContent and ContentMapper provide the
necessary mapping of SQL result sets and columns to and from the respective DTO
(Content class). The following description of the aforementioned classes applies to all *,
*DAO, Abstract*DAO, Bind* and *Mapper classes.
Content
o The DTO class, which maps to the CONTENT database table.
ContentDAO
o It is the only interface used by applications either to issue commands to or
receive responses from the database. All its methods were described in
Section 5.1.6.1.
AbstractContentDAO
o The abstract class which belongs to the gen package, and implements all
SQL queries, insertions and updates. Its methods are called by respective
functions of the ContentDAO class
BindContent
o It is an interface that maps the parameters of the Content DTO class into
respective
SQL
arguments.
It
includes
a
static
class
ContentBinderFactory which implements BinderFactory interface of
the JDBI library, with the following method:

Page 114 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

public void bind(SQLStatement q, BindContent bind,
Content arg): It maps the parameters of an sql statement in
AbstractContentDAO into Content parameters.

ContentMapper
o The class which translates the SQL arguments and results of a query into
the respective DTO class. It uses the following method:

public
Content
map(int
index,
ResultSet
r,
StatementContext ctx): The method that translates a received
resultset into an Content object.
Input parameter: index The index.
Input parameter: r The received result set.
Input parameter: ctx The statement context.
Returns: The Content object.

Version 1.0

Page 115 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 47: Content table DAO-related class diagram.
Besides the key functions which were described in the previous Section 6.1.7.1, and are
used to perform the basic insertions, updates and queries per primary key or for all stored
entries, a few additional and more complex queries were implemented. The complete list
of DAOs and their additional functions is presented below:
CacheDAO:
o No additional methods were implemented.
ContentAccessDAO:

Page 116 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

o public
synchronized
List<ContentAccess>
findByContentID(long contentID): The method that finds all
accesses of the specified content id.
o public
synchronized
ContentAccess
findLatestByContentIDFacebookID(long contentID, String
facebookID): The method that finds the latest access of a specific content
id, by the user with the specified facebook id.
o public
synchronized
ContentAccess
findLatestByContentID(long contentID): The method that finds
the latest access of a specific content id.
o public
synchronized
void
deleteByContentID(long
contentID): The method that deletes all accesses of a specific content id.
ContentDAO
o public synchronized Content findByPath(String path): The
method that finds the content with the specified cache path.
o public synchronized List<Content> findByCacheType(String
cachetype): The method that finds and returns the list of contents for the
given cache type.
o public synchronized List<Content> findAllNotPrefetched():
The method that returns all contents which were not prefetched by social or
overlay prediction.
o public synchronized List<Content> findAllWithAccesses():
The method that returns all the contents that were accessed in the past.
o public synchronized long findTotalSize(): The method that
returns the total size of the cached contents, meaning the sum of the sizes.
o public synchronized List<Content> findAllOutDated(long
cacheThreshold): The method that returns the list of contents that were
cached before the given cache threshold.
o public synchronized List<Long> findAllIDs(): The method that
returns the list of stored content ids.
o public synchronized void deleteBatch(Iterator<Content>
contents): The method that deletes a list of contents.
o public
synchronized
boolean
deleteNotAccessedContent(Content
content,
long
threshold): The method that deletes a content if it was not accessed
before the provided threshold.
FeedItemDAO
o public List<FeedItem> findAllByContentID(long contentID):
The method that finds all FeedItem entries which have the content id.
FriendDAO:
o No additional methods were implemented.

Version 1.0

Page 117 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

OwnerDAO:
o No additional methods were implemented.
SocialPredictionParametersDAO:
o No additional methods were implemented.
TrustedUserDAO
o public TrustedUser findByMacAddress(String macAddress):
The method that finds a TrustedUser entry by its MAC address.
UNaDaConfigurationDAO
o No additional methods were implemented.
VideoInfoDAO
o No additional methods were implemented.
6.1.7.3
Tests
The list of JUnit [19] tests, which validate the correctness of the DAO functions, is
presented below:
CacheDAOTest
o public void testFunctions(): It tests all the basic functions of the
CacheDAO.
ContentAccessDAOTest
o public void testFunctions(): It tests all the basic functions of the
ContentAccessDAO.
o public void testThreads():It tests how the functions perform under
multiple threads.
ContentDAOTest
o public void testFunctions():It tests all the basic functions of the
ContentDAO.
o public void testBatchFunction(): It tests all the batch functions of
the ContentDAO.
o public void testThreads(): It tests how the functions perform under
multiple threads.
FeedItemDAOTest
o public void testFunctions(): It tests all the basic functions of the
FeedItemDAO.
FriendDAOTest
o public void testFunctions(): It tests all the basic functions of the
FriendDAO.

Page 118 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

OwnerDAOTest
o public void testFunctions(): It tests all the basic functions of the
OwnerDAO.
SocialPredictionParametersDAOTest
o public void testFunctions(): It tests all the basic functions of the
SocialPredictionParametersDAO.
TrustedUserDAOTest
o public void testFunctions(): It tests all the basic functions of the
TrustedUserDAO.
VideoInfoDAOTest:
o public void testFunctions(): It tests all the basic functions of the
VideoInfoDAO.
UNaDaConfigurationDAOTest
o public void testFunctions(): It tests all the basic functions of the
UNaDaConfigurationDAO.
6.1.8 User Interface
The User Interface of the uNaDa exposes the graphic interface towards the end-users to
configure the access point, monitor their cache and administrate their device. It specifically
provides the following pages and functions:
The login page, in which the user logins to the HORST Facebook application with
his Facebook credentials, and acquires administration of his device.
The settings page, where the private and public SSIDs information are configured,
The overlay page, including the overlay-related information,
The social page, where the social prediction parameters can be manually defined,
The cache page, where the cache parameters can be configured, and the list of
prefetched contents is presented, and,
The administration page, where the uNaDa administrator can monitor all the tables
and block access to external users.
6.1.8.1 Interfaces
The login page, presented in Figure 48, provides the initial page of the uNaDa towards the
end-user. The end-user logins with his Facebook credentials, and gains ownership of the
uNaDa, and initializes the social and overlay monitoring functionalities.
If the user has not registered with his Facebook credentials before, he is redirected to the
permissions page presented in Figure 49, where he must accept the HORST Facebook
application permissions.

Version 1.0

Page 119 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Upon successful login, the user is redirected to the uNaDa configuration page (Figure 50),
where he may change the private and public SSIDs and passwords, as well as configure
the monitoring and predictions’ intervals.
Additional configuration pages include the overlay page (Figure 51), where the overlayrelated parameters (bootstrap node IP address, port, chunk size, uNaDa location) are set,
the social page (Figure 52) where the social prediction parameters can be manually
configured, and the cache page (Figure 53), where the administrator can manage the
uNaDas local cache parameters (cache size, threshold size, social and overlay prediction
score thresholds) and contents.
Finally, the administration page, presented in Figure 54, provides all the necessary tables
and functions, so that the uNaDa administrator can modify and delete trusted users, video
information and feed items.

Figure 48: The uNaDa login page.

Page 120 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 49: The permissions page.

Figure 50: The uNaDa configuration page.

Version 1.0

Page 121 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 51: The uNaDa overlay configuration page.

Figure 52: The social prediction parameters configuration page.

Page 122 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 53: The uNaDa cache management page.

Figure 54: The uNaDa administration page.

Version 1.0

Page 123 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

6.1.8.2 Design
The uNaDa User Interface is a Web application designed and implemented based on the
Model-View-Controller (MVC) pattern, which was already described in the description of
SBox User Interface (Section 5.1.7).
The controller layer of the uNaDa Web application is implemented by the list of controlling
bean classes presented below, also providing their mapping to the respective pages:
AdministrationBean: administration page (Figure 54).
CacheBean: cache management page (Figure 53)
DemoBean: demo page.
LoginBean: login page (Figure 48).
SocialBean: social parameters page (Figure 52).
UnadaConfigurationBean: uNaDa configuration pages (Figure 50, Figure 51).
UnadaSessionBean: The user that handles the session of the Web application
and also the response from the Facebook server, upon permissions page (Figure
49).
Each *Bean class implements all the required functions to manage its respective page.
Specifically, the Web interface pages are used to insert, edit or remove specific entries
from the respective database tables, e.g. the UnadaConfigurationBean manages the
UnadaConfiguration table, calling the respective DAO methods. Figure 55 presents
such an example and is similar to all *Bean classes.

Figure 55: UnadaConfigurationBean class diagram.
Figure 56 presents a simple sequence diagram of an UnadaConfiguration update
through the User Interface, which is triggered when the Submit button is called.

Page 124 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

UnadaConfigurationBean calls the insert(UnadaConfiguration) function of DB
component’s
UnadaConfigurationDAO
class,
which
executes
the
UnadaConfiguration table update. Afterwards, the findLast() is executed, to get
all the UnadaConfiguration entries and populate the page fields. The same action
applies for all pages and methods defined above.

Figure 56: UnadaConfiguration insertion sequence diagram.
The view layer of the uNaDa Web application consists of all the pages, files and forms for
the representation of existing entries in the uNaDa database, and user’s request handling.
The list of files is as follows:
/: In the root directory all the Web application pages exist:
o login.xhtml: The login page (Figure 48) which provides a button for the
end-users to connect to the uNaDa Web application, with their Facebook
credentials. This button calls the login() function of the LoginBean,
redirects to Facebook servers, where user inserts his Facebook credentials,
then redirects to the permissions page (Figure 49), where user accepts the
HORST Facebook application permissions and finally redirects to the
UnadaSessionBean, initializing a new session.
o index.xhtml: The initial uNaDa configuration page (Figure 50), where
user configures the basic uNaDa parameters. This page uses
updateUnadaConfiguration()
method
provided
by
UnadaConfigurationBean to update the inserted parameters into
database.

the
the
the
the

o overlay.xhtml: The second uNaDa configuration page (Figure 51), where
the overlay-related parameters are set. This page calls the same method
from the UnadaConfigurationBean as the page above.
o social.xhtml: The social parameters page (Figure 52), where the social
prediction parameters are manually configured. This page triggers the
updateSocialParameters() function of the SocialBean to update the
parameters’ set into the respective database table.
o cache.xhtml: The cache management page (Figure 53), where the user
can configure the parameters of his uNaDa’s cache, as well as monitor and

Version 1.0

Page 125 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

manage the cached contents. The respective CacheBean provides a few
functions:

updateCache(): The method that updates the cache parameters
into the Cache database table.

delete(Content c): The method that deletes a specific content,
when the user pushes the respective button in the page.

o admin.xhtml: The administration page (Figure 54) where the user can
monitor all the uNaDa database tables’ entries and delete all or specific
ones. The AdministrationBean provides the following functions:

deleteTrustedUser(TrustedUser t): The method that deletes
a specific TrustedUser entry.

deleteVideoInfo(VideoInfo v): The method that deletes a
specific VideoInfo entry.

deleteVideoInfos(): The method that deletes all VideoInfo
entries.

deleteFeedItems(): The method that deletes all FeedItem
entries.

deleteFriends(): The method that deletes all Friend entries.

o demo.xhtml: The demonstration page, used for demonstration purposes.
css/: This directory includes all the css files used to format and style the Web
application pages. Besides, the 2 files (unada-main.css and unadalogin.css) that describe the uNaDa UI style and format, the directory includes all
the Twitter Bootstrap [22] css and theme files.
img/: It includes the image files used in the uNaDa Web application.
js/: This directory includes all the javascript files. These files are used to support
certain Twitter Bootstrap [22] components (bootstrap.js, bootstrapdropdown.js, bootstrap-modal.js, jquery.js), and support the validation
of the user input. In the second case, the bootstrapValidator.js acts as the
key element of forms’ validation, highlighting correct/incorrect fields and
enabling/disabling “Submit” button, while additional javascript files (between.js,
integer.js,
ip.js,
notEmpty.js,
mac.js,
numeric.js,
greaterThan.js) provide individual fields’ validation, providing relevant error
messages. In addition, there is a geolocation.js file, which is used to
automatically find the uNaDa’s geographical location and fill the respective fields in
the uNaDa configuration page.
WEB-INF/: This directory includes the web.xml file, including Web application’s
configuration.
Besides the *Bean classes, which manage the UI pages, the current component also
implements some additional support classes. The UserSessionFilter implements the
Filter class of the javax.servlet package and handles the user’s session, and the
SizeConverter, MinutesConverter and HourConverter classes, implement the

Page 126 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Converter class of the javax.faces.convert package and transform certain pages’
fields into relevant Java objects. The component also initializes all the required functions
of the Cloud Traffic Manager, namely the overlay joining, the social monitoring and the
cache management functionalities via the UIWebAppListener class. The class diagram
of the implemented classes which support these functionalities is presented in Figure 57.
The
key
class
is
the
UIWebAppListener,
which
implements
the
ServletContextListener class of the javax.servlet package, and specifically the
2 methods: contextInitialized() which is triggered before the Web application
context is initialized, and the contextDestroyed(), which is called before the Web
application is terminated. Upon contextInitialized() is called (Figure 58), all the
database tables are created and then, the bootstrap() function of
UnadaOrchestrator is called, which initializes all the Cloud Traffic Manager
functionalities and was described in Section 6.1.1.2.

Figure 57: Additional UI class diagram.

Version 1.0

Page 127 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 58: WebAppListener sequence diagram.
6.1.8.3 Tests
No automated tests were implemented for the User interface. The Web application was
tested during integration and system tests.

6.2

End-User

The RB-HORST End-User application allows the user to automatically connect to
encrypted WiFi networks of friends provided by the uNaDas. For this, the installation of the
Android application on the user’s phone is required, handling the automatic WiFi
configuration. The development of the application was focused on minimizing the
interactions required by the user, and thereby maximizing its utility. The sequence of
interactions is detailed in Figure 59.
The application is a single screen activity, and hence consists of one activity only. This
connects to the service controller, handling the individual tasks. The only call from the
Activity to the service is when the Facebook login is triggered. This loads the Facebook
login screen from the Facebook SDK, returning the user id on success, null otherwise.
The class diagram of both classes is given in Figure 60.

Page 128 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 59: Sequence Diagram of the Facebook App.

Figure 60: Classes within the App package.
The service controller executes the tasks running in the background. These are grouped
into three different packages: the WifiService, Timers, and SDK packages. These
communicate only via the ServiceController.

Version 1.0

Page 129 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

The FacebookAccount package (cf. Figure 61) draws the Facebook login window on top
of the current activity when called. It also handles the communication with the uNaDa to
request the network configuration of the configured private network. Further, the network
configuration is stored in the CredentialManager.

Figure 61: Classes within the FacebookAccount package.
The WifiService package (cf. Figure 62) handles the WiFi scanning, switching and
configuration. The WifiScanner is activated if the device is not connected to a WiFi
network. It scans for networks with the SSID HORST_{*} or other known networks once
every 6 seconds. If a correct SSID is discovered, the WifiSwitcher is called with this
SSID and the corresponding key, if available. The WifiSwitcher then uses the Android
WifiManager to connect to the given SSID.
In case of the HORST_{*} SSID, and no configured private SSID the uNaDa is requested
for the corresponding network configuration. This is handles by the FacebookAccount
package.

Page 130 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 62: Classes within the WifiService package.
The Timers package (cf. Figure 63) contains the timers required for periodic tasks and
related information. Currently, the package only contains the WifiScanTimer,
periodically triggering the WiFi scans and checking the discovered networks. If a
configured network is found, the WiFi Switcher is called to connect to the corresponding
SSID.

Version 1.0

Page 131 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 63: Classes within the Timers package.
The CTM package (cf. Figure 64) contains the configuration models of the discovered
uNaDas and the corresponding WiFi configurations. Further, a log handler is implemented
allowing to write important events to the system log.

Page 132 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 64: Classes within the CTM package.
Figure 65 presents the user interface of the HORST Android application. These
screenshots include the screens where the user logins with his Facebook credentials,
accepts the RB-HORST service’s permissions and finally, the WiFi scanning procedure
starts.

Figure 65: Screenshots of the HORST Android Application.
The RB-HORST Android application has been made available to Google Play Store at
[40].

Version 1.0

Page 133 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

7 The Multi-Criteria Application End-Point Selection
(MUCAPS) mechanism
MUCAPS stands for "MUlti-Criteria Application endPoint Selection" and has been
specified in Section 4.11 of Deliverables D2.2 [25] and D2.4 [26]. MUCAPS addresses the
EFS scenario, in particular the use cases “Locality in UNaDa” and “Service and content
placement” for users. The MUCAPS added value to application traffic management and
SmartenIT is a contribution to the optimization of overlay application traffic. To this end,
MUCAPS revises the initial Endpoints selection done by the application overlay by
involving awareness on the underlying network topology and on transport costs with
information not available by traditional end to end on-line measurement mechanisms. The
selection criteria used in MUCAPS are an abstraction of end-to-end performances on
application paths. This abstraction relies itself on an ISP-centric abstraction of the Internet
topology, that is available to applications via the IETF ALTO protocol, documented in [24].
MUCAPS leverages proposed ALTO protocol extensions, extending the base protocol set
of ALTO metrics and allowing ALTO transactions with multiple metrics and constraints
combined with multiple logical operators allowing richer compromises. So MUCAPS can
help out any SmartenIT mechanism that supports applications having multiple candidate
resources locations and that have no awareness of the underlying network.
The ALTO protocol is integrated in the SmartenIT architecture: the ALTO Server stores
and provides abstracted transport network information to requesting ALTO Clients
associated to applications. However, the ALTO Client alone cannot automatically decide
what information to request and how to process it once received. MUCAPS builds the
decision making around the ALTO Client. It assists the choice of the location from which
to download content. Locations can be various entities including Video Server, Data
Center, uNaDa and Peers. Content covers video streams as well as computing resources
for virtualized or distributed applications. MUCAPS is suitable for applications having the
choice among several feasible Application Endpoints (AEPs) and supports multi layer and
multi party incentive decision making by involving the following aspects in the AEP
selection:
Topology distance: number of hops (inter or intra AS), impacting delay,
Routing cost: reflecting the ISP policy in terms of AS peering agreements,
ISP preferences in terms of resources availability (e.g., path bandwidth).

7.1

Mapping to the SmartenIT Architecture

The initial selection of overlay Endpoints, referred to in MUCAPS as Application Endpoints
is usually produced by gathering functions such as DNS Servers and Clients, DHTs, Peer
Trackers and referred to in MUCAPS as Application EndPoint Gathering (AEPG)
functions. Figure 66 illustrates how MUCAPS is involved in a content downloading
scenario, as detailed in SmartenIT deliverables D2.2 [25] and D2.4 [26]. In this figure, the
term MACAO stands for Multi Access and Cost ALTO. Basically, the MACAO Client block
does (or performs) the following actions:
decides for which metrics an ALTO Client must request values,
decides which weight is applied to the metrics, and then
Page 134 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

uses the obtained values to rank the AEPs.
Indeed an ALTO Client has no intelligence to perform these three MUCAPS operations as
ALTO is mainly a transport means for abstracted network information.
MUCAPS comprises three parts: a MACAO Service Client (MARC) that requires from the
MACAO Service interface (MARS) an additional ranking of the initial AEP selection. The
MARC is hooked to an AEPG that may call it for enhanced ranking and hands it from it the
initial list of AEPs, identified in the current implementation, by their IP addresses. The
MARS is just an interface to the MACAO block that does the actual selection and ranking.
The MACAO block with its MARS is entirely deployed in the provider network. Finally, the
MARC and the MARS communicate via a simple IP Socket carrying a light message. The
message typically includes: a list of AEP IP addresses, the MUCAPS service ID pointing
here to “AEP Ranking” and the number of AEPs to rank.

Figure 66: MACAO Request Service: function, interface and client.
7.1.1 Required SmartenIT components and entities
The MARC is hooked to AEPGs that in the SmartenIT architecture are typically part of an
End User Entity or the Overlay Manager where for instance the AEPG produces a sorted
list of socket addresses of providers of a resource, where the closest addresses are first in
the list. In this case, MUCAPS may revise the order of this initial list w.r.t. additional
provider network aware evaluation metrics.

Version 1.0

Page 135 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Therefore MUCAPS has a footprint in the following entities where it involves the following
SmartenIT components, as illustrated in Figure 67.
The SBox: hosts the MACAO Client block and its MARS Interface to the MARC.
Note that MUCAPS is a super set including the ALTO Server and Client. Physically,
the ALTO Server and the MACAO Client block may be located on different
machines,
The Overlay Manager in the uNaDa and DC: includes an AEPG invoking the
MARC,
The AEPG in the End User Entity (EUE): in cases where an application gets a set of
candidate AEPs via an AEPG located in the end user entity. A MARC is hooked to the
AEPG that calls it to get the AEP ranking service from MUCAPS.
Thus the MARC is not in the SBox but linked to the Overlay Manager and EUEs
associated to the SBox. All decision burden is offloaded from these entities to the SBox in
the network.
7.1.2 Embedding MUCAPS on the SmartenIT architecture
The impact of MUCAPS on the architecture is shown in Figure 67 with following
modifications:
The ALTO component in the SBox is replaced by the set {MACAO block, MARS
interface and ALTO Server}. The ALTO Client is now in the MACAO block.
There is no more need to have an ALTO Client in end systems involved in overlay,
that is: Data Centers, uNaDas and End User Entities. Instead, the ALTO Client
there is replaced by the MARC that sends to the MARS in the SBox, MUCAPS
requests, that is requests to re-order the candidate AEP list w.r.t. ALTO based
network information.
The MARC is invoked by the Overlay Manager or the application of EUEs and
communicates with the MARS located in the SBox via a simple IP socket.
An alternative mapping of MUCAPS to the SmartenIT architecture is also described in
deliverable D3.3. It consists in replacing the ALTO (Client) component in the Overlay end
systems by the MARC, thus keeping the current interfaces established with
MUCAPS/ALTO replacing ALTO. This setting must however assume that the MARC can
be hooked with an AEPG function located in the Overlay Manager of the Data Center and
the uNaDa or in some appropriate place in the End User Entity.
The following SmartenIT architecture extensions are needed:
A placeholder is needed in the EUE for an AEPG that could call the MARC.
Interfaces should now be established between the MUCAPS/ALTO block and the
MARCs.

Page 136 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 67: Entities and components involved in MUCAPS.

7.2

Implementation and Deployment

In the sections that follow, the implementation and deployment details of the MUCAPS
mechanism will be presented.
7.2.1 Description of the MACAO related functional blocks
Figure 68 shows details on the functions involved in MUCAPS, while the operations
sequencing will be explained in a further section.

Version 1.0

Page 137 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 68: Details on the functions involved in MUCAPS and operations sequencing.
The MACAO Request handling Server (MARS) InterFace (IF), bridges the MUCAPS block
with the MARC requesting evaluation and/or ranking of (S,D) pairs or application paths
and providing the initial selection of (S,D) pairs or application paths together with the ID of
the MACAO Service to request: typically “Endpoint Ranking and/or Evaluation” or “Path
Ranking or Evaluation”. The MARS IF returns the new evaluation and/or ranking of (S, D)
pairs or application paths done by MUCAPS. The MUCAPS block communicates with the
ALTO Server via its embedded ALTO Client.
The MARS receives and services requests issued, via an IP Socket, by a MARC that is
hooked to an AEPG function. For requests issued by “un-trusted” MARCs located in
“public” devices, the services include at least “EP ranking” and “e2e Path ranking”. These
services map respectively to the ALTO EP Cost Service and the ALTO Cost Map Service.
The evaluation services providing “real-values” are preferably restricted to “trusted”
MARCs since they provide numerical ISP scores or costs and are less transparent. It
returns to the MARC, via the MARS IF, the list of (S,D) EPs with requested evaluation
information: generically the rank of (S,D) pairs or e2e paths.
The MACAO Request handling Server (MARC) communicates with the MARS IF through
an IP socket, and exchanges a light data structure containing at least: the MACAO Service
ID, typically a Multi-Cost ranking or Evaluation Service, the list of application paths or
(S,D) endpoint pairs to evaluate, and fields for their values and/or rank. The MARC is
typically hooked to the function providing the initial selection of application endpoints or
paths, called AEPG for Application Endpoints Gathering Function, that can itself be
located in various places such as end user devices, the application network or its ISP
managed part. The MARC may customize its response to the calling AEPG function so as
to mimic the format of the values returned by the AEPG function so as to make the MARS
operations transparent to the applications.
The AMWS functionselects the ALTO metrics w.r.t. the application type and possibly time.
It also sets the weight associated to the metrics, w.r.t. application needs or context
Page 138 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

information related to the UEP such as access type. The AMWM can optionally fine-tune
the metric weights w.r.t. the network access type and possibly time. The AMWM maps
metric ID and weight values to the application and other information contained in the
MARC currently by using a Look Up Table. The values of this LUT are periodically
updated from an ISP managed AMWM configuration setting function.
The AMWS Config Settings function is a Graphical User Interface (GUI) integrated in an
end system also able to access the AMWS Function. This function is to be managed by
the ISP. Via the GUI, the “ALTO ON” the “ALTO auto metric” and the “ALTO auto weight”
modes are activated. As an option, it updates the values associated to the configurations
mapped to groups of AEPs. For example: a group of AEP identified by their IP addresses
is identified as Video Servers. AEPs of this group must therefore be selected w.r.t. a set of
metrics including typically “routing cost” and “bandwidth score”. However, in some
circumstances as low peak hours, the ISP may consider that “bandwidth score” does not
need to be involved in the selection, or with a lower weight. Thus, the LUT always points
to the same file but the latter may have a varying content. A simplifying option is however
to set the values of the configuration files of the AMWS function as constant and avoid
thus implementing complex interactions.
The Multi-Criteria AEP evaluation function (MCEVAL) ranks the EPs w.r.t. the metric
values and their weights. It uses a vector-based multi-objective ranking method, based on
the proximity of a candidate solution to some “ideal” solution.
The ALTO Server The ALTO Server serves requests received by ALTO Clients according
to the capabilities exposed in its Information Resources Directory and specified by the
ALTO protocol (RFC7285)
The ALTO Client The “ALTO Client” then sends a request to the ALTO Server to get cost
values among the source and destination (S,D) endpoints (or among end to end paths for
the Path Ranking MARS Service). Its behavior complies with the specifications of
RFC7285.
The ALTO optimization information base (AOIB) This function stores, according to their
“freshness”, Multi-Cost ALTO responses as well as the evaluation and ranking results on
paths and endpoints pairs, so as to faster serve frequently repeated queries on the same
set of (S,D) pairs or paths.
The ALTO agent (AoA) The AoA is a central function that is hooked with all the other
functions for the sake of modularity and robustness: it knows the semantics of ALTO and
the functions using the ALTO information, passes information and requests among the
entities it is hooked with. The AoA:
Receives a Service request via the MARS Interface (IF) along with the MARS
Service ID, the list of candidate paths or source and destination endpoints (S,D)
EPs,
Checks its “ALTO optimization information base” to see if the needed ranking is
already available and therefore still valid,
If no stored response is available, the AoA prepares the arguments for the MultiCost ALTO request to be sent by the ALTO Client: (ALTO Service ID, list of (S, D)
EPs, cost metrics, cost mode by default numerical).
o To identify the cost metrics, the AoA calls the AMWS function,

Version 1.0

Page 139 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

o The ALTO Cost mode is by default “numerical”,
o The (S,D) pairs are included in the request sent by the MARC
o The ALTO Service ID is mapped from the MACAO Service ID (path
ranking/EP ranking)
Once the ALTO Client requests and gets the information from the ALTO Server it
hands it to the AoA that translates it into a form exploitable by the MCEVAL.
The AoA sends the ALTO-based EP information to the MCEVAL, together with the
applicable metric weights,
Once the MCEVAL has performed its multi-criteria evaluation it hands the result to the
AoA that translates it into a format exploitable by the MARS so as to be sent back to the
MARC.
7.2.2 MUCAPS implementation and execution: entities and interfaces
In the current MUCAPS deployment, the MARC is located in the ISP network. This is the
case for instance when the ISP wants to ensure that the DNS selection of the application
network is compliant to its policy in resources usage. In that case, the ISP captures the
response of its DNS Resolver, processes it with the MACAO module and sends the
MACAO selection to the DNS Resolver that sends it to the DNS Client. All this is done in a
transparent way for end users and applications.
As illustrated in Figure 69, the MACAO functional block has an external interface called
MARS for “MACAO Request handling Server” allowing it to comunicate with a MARS
Client (called MARC) hooked to the AEPG.
The network-side deployment enables a lightweight transaction between MUCAPS and
the ISP DNS resolver by: adding to the MUCAPS block a MARS service interface,
becoming thus a MACAO Request Server (MARS). This deployment includes the following
steps:
1. The application client queries the DNS server for the list of content servers to
download/upload from.
2. The DNS Server,
2.1. selects the MACAO Service “Endpoint Ranking”
2.2. hands to its embedded MARC its query result, that is the list of the candidate
Application Endpoint IP addresses, together with the IP address of the User
Endpoint, that is the DNS Client associated to the user device,
3. sends this light information to the MARS IF via an established IP Socket, as a query to
perform the multi-cost ranking of the AEPs,
4. The MUCAPS block performs the ranking and the MARS sends the reordered list of
AEPs to the MARC.
The MARC passes it to the AEPG/DNS Server that sends it to the requesting AEPG/DNS
Client.

Page 140 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 69: MUCAPS entities and interfaces: MARC integrated in a network located
AEPG, here a DNS server.
Figure 70 shows the sequence diagram between the entities involved in the MACAO AEP
ranking. The acronym MSR stands for MUCAPS Service Request and represents a simple
object structure named “alto_service”, exchanged between the MARC and the MARS and
specified as follows:
struct _alto_service
{
int service_type;
char* source_endpoint;
char** application_endpoint;
int num_of_application_endpoint;
};
int service_type: is the identifier of the service requested to the MACAO
block. For the MUCAPS implementation, it corresponds to the “ranking” service that
re-orders the set of AEPs.
char source_endpoint[1][]: is the list of IP addresses of User Endpoints
receiving the application resources. By default, this list contains 1 element which is
the User EP
char application_endpoint[][]: is the list of IP addresses of the AEPs.
o When sent from the MARC to the MARS, this list is ordered following the
DNS transaction
o When sent from the MARS to the MARC, this list is re-ordered by the
MACAO block, in decreasing order of performance level, so that the best
AEP is listed first.
Version 1.0

Page 141 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

int num_of_application_endpoint: the number of AEPs.

Figure 70: Interaction between entities involved in the MACAO AEP ranking.
The ALTO Client and ALTO Server communicate according to RFC 7285 [24]. The
requested ALTO Service is the “Endpoint Cost Service” as specified in RFC 7285 [24].
The communication between the DNS Server AEPG, the MARC, the MARS and the
MACAO Block is depicted in Figure 71.
The MARS has received the MSR structure “_alto_service” described above. It then
initiates a structure called “struct _altoa_endpoint_evaluate_service_t” specified
below.
struct _altoa_endpoint_evaluate_service_t
{
struct _altoa_alto_config_t* config;
struct _altoa_endpoint_evaluate_request_t* request;
struct _altoa_endpoint_evaluate_reply_t* reply;
struct _altoa_endpoint_evaluate_result* result;
int (*request_set)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv,
int service_byte,
endpoint_address* eps_src,
int num_of_eps,
endpoint_address* eps,
int num_of_metrics,
int* metrics,
double* metric_weights,
int topN);
int (*perform)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv);

Page 142 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

int (*destroy)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv);
int (*result_get)(struct _altoa_endpoint_evaluate_service_t* ep_eval_serv,
char** str_result);
};

The functions of this structure are performed by the MACAO block.
request-set(): calls the AMWS module to identify:
o the missing arguments of the ALTO request (besides the endpoint
addresses), which are metric types (int* metrics).
o The metric weights that will be used by the MCEVAL module.
o topN: is by default equal to num_of_application_endpoint,
maximum number of ordered AEPs to be used for the application.

the

Perform():
o Gets the performance values for the AEPs on the set of metrics int*
metrics from the ALTO Server via the ALTO Client.
o Calls the MCEVAL module to order the set of (eps_src, eps) w.r.t. their
metric value and weight.
Result-get(): shapes the resulting ranking for the MARS and MARC
communication semantics.

Version 1.0

Page 143 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 71: Interaction between the DNS Server AEPG, the MARC, the MARS and the MACAO Block.
Page 144 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

7.2.3 In-network transparent deployment
MUCAPS has been deployed as an in-network overlay traffic management mechanism as
illustrated in Figure 72. The MUCAPS service, in this case is requested by a MARC
hooked to an AEPG located in the ISP network. In the evaluated deployment, the APEG is
the DNS resolver located in the ISP network and connected to the DNS client located at
the UEP side.
MUCAPS has been implemented and demonstrated as a prototype. Functional platform
tests have been conducted to verify whether MUCAPS behaves as expected in the
specifications. Besides, it has been evaluated w.r.t. the performance metrics mentioned
above. MUCAPS attempt to optimize performances that go beyond the sole user
perceived QoE, in particular OPEX in terms of ISP routing costs.
The prototype has been tested with a set-up illustrated in Figure 72 and composed of the
following entities:
A End-User (EU) device with a DNS client and a VLC client,
An AEPG which is a DNS Server with a MARC,
An ALTO Server,
A MARS hooked to the MACAO block and with an interface to the MARC,
3 video servers corresponding to AEP1, AEP2, AEP3.

Figure 72: MUCAPS demonstration and functional evaluation setup.
The MUCAPS deployment has led to the following implementations:
The MARC, MARS and MUCAPS block have been implemented in C,

Version 1.0

Page 145 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

The DNS Server code is the open source “djbDNS” suite implemented by D.J.
Bernstein, that allowed thus to integrate the MARC and its interaction with it,
The ALTO Server is a reference implementation in Java.
The functional behavior of MUCAPS is assessed by computing the numerical performance
of the selected EPs in different scenarios, mainly with or without MUCAPS. When
MUCAPS is activated, cases are further refined to evaluate performances when one or
more metrics are selected.

Page 146 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

8 The Virtual Incentives (vINCENT) mechanism
The vINCENT mechanism addresses the end-user focused use case “Mobile offloading”
from cellular communication to WiFi. It was specified in Deliverable 2.2 [25] and
Deliverable 2.4 [26]. vINCENT provides an incentive for users to open their access point to
other users. The mechanism interacts with the RB-HORST mechanism in a well-defined
way and can be understood as an extension to the respective mechanism specification.
Conceptually, vINCENT replaces the offloading mechanism of RB-HORST.
vINCENT has a distributed nature. The main part runs on a user controlled Nano
Datacenter (uNaDa), which is established on the end users’ home router. The mechanism
assumes a flat rate pricing scheme for the access. Moreover, he has to install the
vINCENT firmware to his home router, and he needs a Facebook account. He has to
install a Facebook app which is part of the vINCENT mechanism and is responsible for
user authentication and manages the access to WiFi.
Just as RB-HORST, the vINCENT firmware establishes two separate WiFis (a private and
a shared WiFi) and enables mobile data offloading by broadcasting a special SSID (of the
shared WiFi) which can be recognized by a mobile device. Every vINCENT user can
request access to the shared WiFi of every uNaDa. An offloading, mobile user’s
connection quality is shaped by the mechanism according to the offloading services
provided by the user’s very own uNaDa.

8.1

Mapping to the SmartenIT Architecture
Datacenter
ove1

Datacenter
Traffic
Redirector

Load
Balancer

Workflow
Manager

Hypervisor

Overlay
Manager

S-Box
iscs1

Inter-Sbox
Communication Service

ALTO
Energy
Monitor

eco1

Economics
Analyzer

Traffic Manager
Cloud Traffic Manager

UI

Social Analyzer

ntm1
Fixed/Mobile
Network Traffic Manager

DB

SDN Controller

soc2
Network
Analyzer

QoS/QoE Analyzer

uNaDa
DB

UI

Energy
Analyzer

ALTO

qos1
ove1

qoe1

top2

top1

Overlay Manager

Topology/
Proximity Monitor

QoS/QoE
Analyzer

Network Entity

qoe1
End User Entity
qos1
soc2

soc2

ene1

soc1
Energy
Analyzer

Topology/
Proximity
Monitor

Switching/
Forwarding

Energy Monitor

ene1
Switching/
Forwarding

Traffic Manager
Vimeo

QoS Monitor

Topology/
Proximity
Monitor

Social Monitor

Energy Monitor

Energy Monitor
QoE Monitor

QoS Monitor

Social Analyzer

Social Monitor

ene1

ove2

Cloud Traffic
Manager

soc3

ntm2

Facebook
ALTO

DB

UI

Figure 73: VINCENT mapping to the SmartenIT architecture.
The RB-HORST-VINCENT mechanism implements the elements marked as dashed
boxes in the architecture diagram. It mainly affects the following components and entities:
Version 1.0

Page 147 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Table 8-1: Component/Entity mapping
End-User Entity

SBox

uNaDa

Overlay Manager

-

Offloading History,
Regression Model
Calculation

WiFi Access
Provisioning

Social Analyzer
and Monitor

-

Friendship Relation
Analysis

-

Fixed/Mobile
Traffic Manager

WiFi Mgmt on
Laptop

-

-

The basic logic is defined by the SBox, which is an entity providing a complete view of the
offloading acitivies in the network and serves as secure endpoint for terminating offloaded
connection via VPN. This endpoint can be provided by a Telco provider to extend the base
of hotspots or a social data provider such. The Overlay Manager component, the
offloading history of all access points is recorded and the regression model calculation as
defined in D2.2 [25] /D2.4 [26] is performed to calculate offloading scores for all users of
the system based on their provided service. Moreover, the SBox can analyze the social
relations between users and can also grant unlimited access to users based on direct
relationships, which is essentially the offloading as initially defined by the pure RB-HORST
mechanism. On the uNaDa, the Overlay Manager manages the provisioning of the WiFi
networks, while the Fixed/Mobile Traffic Manager handles the accessing of WiFi networks
to be used for offloading.

8.2

Implementation and Deployment

The interfaces are illustrated in Figure 74 and are described as follows: The abstract class
IOffloadingStrategy provides basic features for saving histories and manages the uNaDato-owner relationships. It owns an object of the type IOffloadingDataType allowing to
define different data types that can be used to estimate an access point’s performance
using a regression model as described in D2.2 [25] / D2.4 [26]. In particular, an accounting
for provided Volume, Bandwidth, and Session count, i.e., the number of offloaded WiFi
sessions at a certain uNaDa is implemented.
IOffloadingStrategy is implemented by IWithGracePeriodStrategy. This subclass of
IOffloadingStrategy performs a preparation of history data. Th class IncentiveStrategy
implements the regression model calculation using the GNU Scientific Library and
provides means to determine the service that should be provided for a given uNaDa and
mobile user relation.

Page 148 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 74: Interfaces developed in the scope of VINCENT.
The history structure that is maintained by IOffloadingStrategy is shown in Figure 75.
Every access point has a list of already connected clients. The clients have a tuple of
session-IDs (how often they have connected to the respective access points) and the
amount of offloaded data. Consequently, the data structure contains all data on which the
Volume, Bandwidth, and Session classes rely.

Figure 75: History Data Structure.
The VINCENT was implemented in C++ as a simulation model for OMNET++.
Nevertheless, OMNET offers possibilities to perform a deployment on a testbed.

Version 1.0

Page 149 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 76: Deployment Entities.
In the model as well as in the real-world deployment, the role of the SBox is taken by an
HTTP server (server) that is also acting as a proxy for all content requested. All devices
are connected via a single router. The access points (ap) run a DHCP server (dhcpServer)
to handle the configuration of IPs. Finally, the mobile client accessing the WiFis for mobile
offloading is represented by a laptop.

Page 150 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

9 The Mobile Network Assistant (MoNA) mechanism
The Energy Aware Mobile Traffic Management intially focused on reducing the energy
consumption on mobile devices by intelligently scheduling network traffic generated on the
mobile device. Offloading traffic using WiFi networks can save between 75% and 90% of
the energy used for network transmissions compared to 3G connectivity [36]. At the same
time, the risk of network caused stalls may be reduced by increased data rates on WiFi,
improving the QoE of the end-user. The traffic management is based on QoS maps, user
mobility prediction, energy models, and QoE models. As core functionalities, the energy
models and a monitoring framework remain.
Consequently, as part of the project, means for measuring and predicting energy
efficiency of network access were implemented and a monitoring framework was provided.
In the following, the general purpose monitoring implementation for smart phones and
uNaDas is presented.

9.1

Mapping to the SmartenIT Architecture
Datacenter
ove1

Datacenter
Traffic
Redirector

Load
Balancer

Workflow
Manager

Hypervisor

Overlay
Manager

S-Box
iscs1

Inter-Sbox
Communication Service

ALTO
Energy
Monitor

eco1

Economics
Analyzer

Traffic Manager
Cloud Traffic Manager

UI

Social Analyzer

ntm1
Fixed/Mobile
Network Traffic Manager

DB

SDN Controller

soc2
Network
Analyzer

QoS/QoE Analyzer

uNaDa
ALTO

DB

UI

Energy
Analyzer

qos1
ove1

qoe1

top2

top1

Overlay Manager

Topology/
Proximity Monitor

QoS/QoE
Analyzer

Network Entity

qoe1
End User Entity
qos1
soc2

soc2

QoS Monitor

Topology/
Proximity
Monitor

Switching/
Forwarding

Topology/
Proximity
Monitor

Social Monitor

ene1
Energy Monitor

Energy Monitor
QoE Monitor

QoS Monitor

Social Analyzer

Social Monitor

ene1

ove2

Cloud Traffic
Manager

soc3

ntm2

soc1
Energy
Analyzer

Energy Monitor

ene1
Switching/
Forwarding

Traffic Manager
Vimeo

Facebook
ALTO

DB

UI

Figure 77: MoNa mapping to the SmartenIT architecture.
The MoNa energy efficiency mechanism implements the elements marked as dashed
boxes in the architecture diagram. It mainly affects the following components:
Table 9-1: Component/Entity Mapping

Energy

End-User Entity

uNaDa

Measurement of

Measurement of

Version 1.0

Page 151 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Monitor/Energy
Analyzer

smartphone energy
efficiency

uNaDa energy
efficiency

The basic logic is implemented in the Energy Monitor/Energy Analyzer component of the
respective entity. In particular, a number of classes were implemented to record and store
system utilization data. Moreover, a set of hardware-validated power models were
implemented to convert the system utilization data into energy measurements.

9.2

Implementation and Deployment

In the following, the measurement framework implementation for uNaDas, in particular,
the Raspberr PI used as a uNaDa platform is described, as it is representative for the
smart phone measurements as well.
The RaspberryPIMeasuerment Project provides classes to observe measurements for
RaspberryPi device. The implementation follows the observer pattern with a few
extensions to compute and store power measurements.

Figure 78: Basic pattern of monitroing implementation.
The main actors of the pattern are the PowerMonitor and MeasurementObserver Java
classes. In this case the observeable is the PowerMonitor and the observers are other
devices or applications that are interested in the measurements. The
MeasurementObserver class is an extension of the Observer class. It includes a circular
FIFO buffer and a Hash map of all registered observable devices. Every new observed
measurement is stored in the circular buffer.

Figure 79: Device Power Model Class.

Page 152 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

The DevicePowerModel class serves as an abstraction of the device’s power model, in
this case the RaspberryPi device. In order to augment varying power models for the
devices in experiments, it is possible to randomize the variance of the power by passing a
variance parameter in constructor. The main method of this class is the
getPowerConsumption() method. It returns the most current measurement depending on
the utilization and device information.

Figure 80: PowerMonitor Class.
The PowerMonitor class maintains the DevicePowerModel and device Information.
Furthermore it has a calculatePowerMeasurement() method, to compute the current
measurement of the given DevicePowerModel. At the end of the computation all
registered observers will be notified about the new measurement.
For testing purposes, there are regression tests in the Monitor package. In particular, the
UtilizationGeneratorExample class serves as a main test class. It provides a genUtil()
method to generate utilization, defaultDeviceInfo() to create device information based on
RaspberryPi device and a run() method to execute the test. After executing the
UtilizationGeneratorExample class, an output the observed power measurements and the
device name is dumped to the console. The computation happens using the given
sampling interval.
The power monitoring framework can run stand alone or can be integrated in the
Facebook App and RB-HORST software. The diagram below shows a sample deployment
as demonstrated for the SmartenIT Advisory Board Meeting. Therefore, the Energy
Monitoring instance was deployed on two smartphones and a uNaDa, which were invoked
from a remote energy analyser instance running on a measurement server and visualizing
the consumption of the devices in the network.

Version 1.0

Page 153 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Figure 81: MONA Deployment as demonstrated during SmartenIT Advisory Board
Meeting.

Page 154 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

10 The SDN-based DC selection (SDNDC) mechanism
The collaboration of Internet Service Providers (ISPs) and Cloud Service providers was
shown to be beneficial for both parties in a number of recent works. Influencing Cloud
Service data center (surrogate) selection allows the ISP to manage the rising amount of
traffic originated from cloud services in order to reduce the Operational Expenditures
(OPEX) of the infrastructure, e.g., by preventing peered traffic.
At the same time, including the ISP’s hidden network knowledge in the surrogate selection
process influences the Quality of Service (QoS) a cloud service provider can deliver
positively. As a large amount of cloud traffic is Video on Demand (VoD) traffic [38], this
work investigates the topic of Cloud Service/ISP collaboration from a perspective of high
volume, long living flows. These types of flows are hardly manageable with state-of-the-art
Dynamic Name Service (DNS) based redirection, as a reassignment of flows during the
session is difficult to achieve. Consequently, varying load of surrogates caused by flash
crowds and congestion events in the ISP’s network are hard to compensate.
SDN based DC selection (SDNDC) presents a novel approach promoting ISP and Data
Center collaboration based on a minimal deployment of Software Defined Networking
(SDN) switches in the ISP’s network. The approach complements standard DNS based
redirection as used by many cloud service providers and CDNs by allowing for a migration
of high-volume flows between surrogates in the backend even if the communication has
state information, such as HTTP sessions. In the following, the proof of concept
implementation done in the course of the SmartenIT project is presented.

10.1 Mapping to the SmartenIT Architecture
Datacenter
ove1

Datacenter
Traffic
Redirector

Load
Balancer

Workflow
Manager

Hypervisor

Overlay
Manager

S-Box
iscs1

Inter-Sbox
Communication Service

ALTO
Energy
Monitor

eco1

Economics
Analyzer

Traffic Manager
Cloud Traffic Manager

UI

Social Analyzer

ntm1
Fixed/Mobile
Network Traffic Manager

DB

SDN Controller

soc2
Network
Analyzer

QoS/QoE Analyzer

uNaDa
DB

UI

Energy
Analyzer

ALTO

qos1
ove1

qoe1

top2

top1

Overlay Manager

Topology/
Proximity Monitor

QoS/QoE
Analyzer

Network Entity

qoe1
End User Entity
qos1
soc2

soc2

ene1

soc1
Energy
Analyzer

Topology/
Proximity
Monitor

Switching/
Forwarding

Energy Monitor

ene1
Switching/
Forwarding

Traffic Manager
Vimeo

QoS Monitor

Topology/
Proximity
Monitor

Social Monitor

Energy Monitor

Energy Monitor
QoE Monitor

QoS Monitor

Social Analyzer

Social Monitor

ene1

ove2

Cloud Traffic
Manager

soc3

ntm2

Facebook
ALTO

DB

UI

Figure 82: SDNDC mapping to the SmartenIT architecture.

Version 1.0

Page 155 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

The implementation of the SDNDC mechanism affects the Overlay Manager in the
Datacenter and the Cloud Traffic Manager and SDN Controller in the SBox, which is
owned and operated by the ISP. Moreover, the network entities of the ISP are affected for
redirecting flows (Switching/Forwarding), as well as the QoE Monitor running on the End
User Entity.
Data Center

SBox

Network Entity

End-User Entity

Decides on
redirection of traffic
(jointly with Cloud
Traffic Manager)

-

-

-

Cloud Traffic
Manager

-

Decides on
redirection of traffic
(jointly with Overlay
Traffic Manager)

-

-

SDN/Contoller,
Switching,
Forwarding

-

Dynamic redirection
of traffic by
rewriting flows

Dynamic redirection
of traffic by
rewriting flows

-

-

Monitor QoE and
signal Overlay
Manager if quality
drops due to
congestion

Overlay Manager

QoE Monitor

-

-

The basic meachnisms of the implementation work as depicted in the Figure shown
below.

Figure 83: SDNDC Selection mechanism overview.
Before going into the details of the implementation, a brief overview of the involved entities
is given following the illustration in Figure 83. The proposed architecture consists of a
single-tier approach based on a minimal deployment of SDN switches at the edge of the
ISP’s network. As a main building block, the Overlay Manager (OM) inside the ISP’s
network is introduced.
1) First, the client requests content from a cloud provider. The URL of the request is
resolved recursively by an authoritative DNS server. Contrary to the usual

Page 156 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

redirection the DNS-record points to the next ISP owned OM. From this point on,
the request is handled within the ISP’s network, only.
2) The OM terminates the TCP session of the user as if the OM would deliver the
actual content. In parallel the optimal Data Center (DC) surrogate capable of
delivering the content is calculated and selected by the OM.
3) Without requiring another HTTP redirect, the complete state of the TCP and HTTP
session representing the connection to the client is migrated from the OM to a
suitable DC surrogate. In order to ensure a seamless migration, the OM takes care
of signaling the edge Broadband Remote Server (BRAS) close to the client.
Extended with an OpenFlow switch the flows from and to the client are redirected to
ensure a working migration of the TCP flow.
4) Finally, the content is delivered to the client from the selected DC surrogate. The
process itself is transparent for the client only involving the resolving of a content
URL without any HTTP redirects. If necessary, the OM can reassign the flow to
another DC surrogate whenever necessary.

10.2 Implementation and Deployment
10.2.1 Implementation Environment Description

Figure 84 : Overview of Implementation and Deployment
As a testing environment for the implementation, a virtual machine based setup was
chosen. The implementation is running on four VMs. As a hypervisor, Kernel-based Virtual
Machine (KVM) running on an Intel i7 (4 cores, Hyper Threading) based machine is used.
All VMs are configured to use each one core and between 512 MB RAM and 1024 MB
RAM depending on the demands of the tasks they execute. The setup of the VMs was
carefully chosen such that the limitations of virtual RAM and CPU do not impose a
bottleneck.

Version 1.0

Page 157 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

The interaction and tasks of the VMs is depicted in Figure 84. The ISP’s topology is
running on a dedicated VM (Mininet VM) using the Mininet tool. For experiments, this VM
can easily be substituted by a real network. Mininet allows for the emulation of OpenFlow
switch topologies. Core switches are emulated by means of the Open vSwitch software
switch (version 1.9) supporting OpenFlow 1.1.
In order to assess whether the approach is applicable in ISP networks, it is necessary to
evaluate it using realistic ISP topologies. A number of scripts running inside the Mininet
Test Environment VM sets up topologies parsed from well known ISP databases such as
TopologyZoo. An additional set of scripts (Topology/Route/Latency Setup) sets up the
topology, the routes based on shortest path calculation, and allows varying latency
between switches during the experiments. The setup relies on an OpenFlow controller
built on top of the Ryu controller software.
Moreover, the Mininet VM is dynamically configured to provide a number of virtual
interfaces, thus enabling access from the other VMs to an edge node of the topology. The
connection of edge nodes and virtual interfaces can be randomized between the
experiments to measure the variance caused by the topology. Furthermore, it is possible
to emulate congestion by defining fine grained parameters along a specific path.
A Python-based Ryu controller app communicates through a REST interface with the OM
application and pushes rules to the edge switches. The other VMs (OM, Surrogates and
End-User Entity VM) are connected to the virtual interfaces of the Mininet VM using a
software switch running on the hypervisor.
10.2.2 Implementation
Since the implementation is built aut of several distinct components Figure 85 provides an
overview. The complete system is a collaboration of distinct software parts which mainly
communicate via HTTP. Experiments are loaded via a shell script which then starts
automatically a predefined testing environment.

Figure 85: Overview of Prototype implementation.

Page 158 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

The deployment consists of an ISP topology which is represented by a Mininet topology.
Switches inside the topology are represented by connected Open vSwitch bridges. The
bridges communicate via the Open Flow protocol with the Topology-App which runs inside
the RYU-Framework. DC surrogates and users are controlled via a Representational State
Transfer (REST) interface, just as the Topology-App.
The rest of the description is structured as follows. Mininet and the topology parser are
presented first followed by the RYU framework and the Topology-App. Furthermore, the
server and client application and the stall detection are described.
10.2.2.1
ISP Topology Emulation
The following describes the topology parser and how to couple the topology to a real
network. Topology and Mininet run inside one dedicated VM as shown in Figure 87. The
topology information is loaded via a script as explained earlier. Furthermore, real
interfaces can be connected to the topology at every node as if they were a part of the
topology.
In order to evaluate different ISP topologies it is necessary to extend Mininet with the
capability of loading arbitrary topologies. Several topology formats are supported by the
implementation. Furthermore, it is possible to annotate the complete topology with Mininet
information like port numbers, link information and weights. All this information is retrieved
automatically by the Topology Parser and added to the topology before it is serialized.
This information is needed later on to set up the static routing information.
In order to decouple the emulation of the topology and the client and server application,
arbitrary network interfaces can be added to the Mininet topology. This enables the
topology to be used with multiple VMs or real network hardware without affecting flexibility
of the Mininet approach. A node from the Mininet topology can be picked to be assigned
to a network interface, which can be any Linux interface like an Ethernet device or even
another virtual interface. The according Open vSwitch instance is configured to add the
newly assigned interface as a new port. In parallel to the switch instances, the Mininet
topology information is updated with the newly available egress and ingress port on the
chosen switch. The information is required later on to ensure that routing rules are
correctly installed. Furthermore, it is important to verify that the added interface accepts all
the traffic passing through and the correct configuration of the connected network. As an
alternative or extension to the Open vSwitch it is thus also possible to include real
switching hardware in the topology.
In order to provide reproducible randomness throughout the experiments, a random node
assignment of the DC VMs to the Mininet topology based on fixed seeds is provided.
10.2.2.2
Overlay Manager/Open Flow Controller Application
The controller represents the control plane of the network and is responsible to configure
the underlying (virtual) hardware correctly. Multiple frameworks exist supporting the
implementation of network applications which can be easily deployed.
Using the Ryu framework, the prototype implements a topology application which handles
routing and rerouting inside the Mininet topology. The newly implemented Topology App
building upon the existing wsgi and switch application provides a simple HTTP server for a

Version 1.0

Page 159 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

REST interface enabling the remote configuration of the controller. Switch lookup by name
in the topology is provided by the switches application.
OpenFlow events are distributed through events like explained in the previous paragraph.
The topology application is responsible to emulate the nearly static routing behaviour in
ISP topologies and for the proposed dynamic rerouting. Based on the Mininet topology
and knowledge of the location of IP subnets the controller pushes OpenFlow rules to the
switches. Topology and changes can be dynamically submitted to the controller by using
the REST interface. The REST interface is shown in Figure 86 and only uses HTTP GET
operations for the sake of simplicity. Requests are used by the experiment to enable
routing for a new topology or set the migration rule for a number of clients. If, for example,
a Type of Service rewrite is deployed, a new Open Flow rule is submitted to the edge
switches.

Figure 86: REST interface of OpenFlow controller
10.2.2.3
Video Streaming Application and Server
The video streaming application consists of a server app mimicking the DC surrogate and
a client application which receives the streamed video content. Both applications need to
be capable of dynamically setting the ToS field in the IP header. Moreover, they are
capable to implement different buffer behaviours which are derived from real world
measurements. Additionally, in order to quantify changes in the QoE the client implements
a video stall detection mechanism.
The server application represents the DC surrogate streaming server. In order to provide a
preferably small memory footprint and maximum performance, the application is written in
C. After a client has connected, the server waits for requests for new content of the client
application.
As stated before, both applications implement a dynamic changing of the ToS field, which
is used to match the flow using OpenFlow. The flow is dynamically redirected to another
DC depending on the ToS field as depicted in Figure 87.

Page 160 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 87: Dynamic ToS redirection - FlowTable
For more details on the SDNDC mechanism and the underlying implementation, please
refer to [37].

Version 1.0

Page 161 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

11 System Releases
As indicated in Section 4.2.1, the agile development model was adopted and the
development work for the two prototypes, DTM and RB-HORST was divided into small
release cycles. Each release cycle either introduced new features, or resolved issues from
previous releases.
The complete list of SmartenIT system releases, their changelog and release dates are
presented in Table 11-1.
Table 11-1: Summary of SmartenIT system releases
Version

Changelog
implementing

Release Date

Notes

1.0

Initial version,
mechanism.

DTM 15/07/2014

1.1

Fixed reference vector calculation in 26/08/2014
Economic Analyzer, added central
dependencies
and
plugins
management.

Open-source

1.2

New tunnel identifier and inter-domain 18/11/2014
link identification based on tunnel end
addresses, added support for multiple
traffic receiving DCs, and added
feature to QoS Analyzer to write
received traffic details to file.

Open-source

2.0

Second version, implementing RB- 20/11/2014
HORST mechanism.

2.1

Fixed social prediction algorithm 11/02/2015
candidates, introduced enhancements
in
content
advertisement
and
neighboring in the overlay network,
updated content prefetching to
consider AS hops towards the overlay
peers, and added demonstration
enhancements in uNaDa and enduser
user interface.

Open-source

3.0

Support for 95th percentile billing rule, 12/02/2015
added new system control variables
and time schedule parameters, added
SDN Controller operation modes
(proactive vs reactive), Compensation
vector handling in Network Traffic
Manager to reduce the number of
updates
sent
towards
remote
domains.

Open-source

3.1

Added BG router configuration using 30/04/2015

Will be released

Page 162 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

NETCONF protocol, support for delaytolerant traffic management, and
introduced new compensation vector
calculation in the case when reference
vector is achieved on one or more
links.

as open-source.

The following sections will present the full list of features, issues and tests for each of the
aforementioned versions, excluding version 1.0, which was described in D3.2 [2].

11.1 Release v1.1
Version 1.1 was the first sub-release of v1.0, which was presented and documented in
D3.2 [2].
11.1.1 Features
Its purpose was a fix in the reference vector calculation algorithm in Economic Analyzer of
SBox, and some additional support code fixes and improvements (Figure 88).

Figure 88: v1.1 features.
11.1.2 Tests
The test cases were the same as v1.0 and were documented in Appendix A of D3.2 [2].
11.1.3 Issues
No issues were found during tests and v1.1 was successfully released.

11.2 Release v1.2
Version 1.2 of the SmartenIT software includes a set of improvements and additional DTM
features.
11.2.1 Features
Based on the updated version of DTM specification a set of JIRA issues was identified.
These are presented in Figure 89.
The major changes introduced in this version are the following:
new tunnel identifier and inter-domain link identification based on tunnel end
addresses;
Version 1.0

Page 163 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

added support for multiple traffic receiving DCs;
added feature to QoS Analyzer to write received traffic details to file.

Figure 89: v1.2 features.
11.2.2 Tests
After the implementation of all improvements and additional DTM features planned for
release v1.2 a set of integration tests were executed. First of all already implemented tests
for releases v1.0 and v1.1 presented in Appendix A of D3.2 [2] were updated and
executed to verify that recent changes in the code did not break the already implemented
and tested functionalities. In addition some new test cases were designed, implemented
and executed. These test cases are described in Table 11-2.
Table 11-2: v1.2 integration test cases.
Description

Components

Environment

Configuration/Execution

Expected Outcome

Complete
chain
with
total traffic
volume
based
charging
rule and one
receiving
DC.

QOA,
NTM,
SBox

JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

NTM at sending domain is
initialized
with
mocked
SBox-SDN client which is
later on used to verify
interactions with the SDN
controller.
Inter-SBox
server is launched. At the
receiving domain NTM,
Economic Analyzer and
QoS Analyzer components
are
initialized.
Mocked
DAOs are used instead of
the real DB and return
preconfigured
structures
representing two domains
with two inter-connected
DCs.

Values of C and R vectors
passed to SBox-SDN client
are verified against known
values.

ECA,
inter-

QoS Analyzer reads preconfigured counter values
from
mocked
SNMPWrapper, calculates
X and Z vectors and

Page 164 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

passes them to ECA and
NTM. ECA calculates R
vector after accounting
period. NTM calculates C
vector after each reporting
period and updates remote
NTM with new C and R
(after accounting period)
vectors. Received C and R
vectors are passed to a
mocked instance of SBoxSDN client.
Test
is
run
for
4
consecutive
accounting
periods.
Complete
chain
with
total traffic
volume
based
charging
rule and two
receiving
DCs.

QOA,
NTM,
SBox

Basic Sanity
testing
for
release v1.2

ALL

ECA,
inter-

JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

Initialization of components
is performed as in previous
test but in this case there
are two receiving domains.

Values of C and R vectors
passed to SBox-SDN client
are verified against known
values.

C and R vectors are sent to
sending NTM from two
receiving NTMs.
Test
is
run
for
4
consecutive
accounting
periods.

WP4 testbed
at PSNC.

Configure the database of
each
SBox
with
the
required
domain
information.

No exceptions or logs that
indicate failures.

Run 1 SBox in receiving
domain. Run 1 SBox and 1
SDN controller in sending
domain.

Compare logs and verify
that
reference
and
compensation vectors are
sent to the sending domain,
and then to the SDN
Controller.

SDN
controller
should
initially
receive
the
configuration data.

Verify that test traffic
generated between DCs is
distributed through tunnels.

QOA in receiving domain
reads
counters
from
deployed software routers
and provides X and Z
vectors to NTM and ECA.
Periodically, the R and C
vectors are sent to the
SBox in the sending
domain and then the SDN
controller is also updated.

11.2.3 Issues
No major issues were identified during the integration testing. After issues were fixed v1.2
was released successfully.

Version 1.0

Page 165 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

11.3 Release v2.0
Version 2.0 is the first release implementing features of the RB-HORST mechanism.
11.3.1 Features

Figure 90: v2.0 features.
This release includes all the RB-HORST basic functionalities, including:
uNaDas’ overlay creation, and maintainance,
Overlay prediction algorithm,
Page 166 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Social monitoring from Facebook and Vimeo,
Social prediction algorithm,
WiFi offloading for trusted users,
Video caching and prefetching,
User requests’ proxying and serving from local Web server.
11.3.2 Tests
To test the integrated RB-HORST prototype, a simple testbed was designed and deployed
(Figure 91). It consists of 3 NSP domains, 2 access (AS1 and AS3) and 1 transit one
(AS2), and 3 users (Andri, Sergios and George), each one having Internet access through
their respective ISP. The transit NSP provides access to the rest of the Internet, e.g.
Facebook and Vimeo servers.
In each user’s premises there is a uNaDa, which is a Raspberry Pi hosting the RB-HORST
software, is assigned to him with his Facebook credentials and provides 2 SSIDs, one
open but with no Internet access, and one private with full Internet access. In addition,
each user owns an Android smartphone to access the Internet, with RB-HORST Android
application and at least a Web browser, installed. Of course, depending on the
experiment, we could have multiple users, with their respective Android smartphones,
accessing and connecting to the uNaDas.

Figure 91: FB-HORST integration testbed.

Version 1.0

Page 167 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Version 2.0 integration tests included both tests performed in 2 uNaDas, specifically
Sergios’ uNaDa B and George’s uNaDa C, as well as JUnit tests, which integrate and test
certain components. Table 11-3 presents the description, involved components,
configuration and outcome of v2.0 integration tests.
Table 11-3: v2.0 integration tests.
Description

Components

Environment

Configuration/Execution

Expected Outcome

uNaDa Web
interface

UI,
DB,
Facebook
Application

uNaDas
A
and B of RBHORST
testbed

Successful Facebook login
for both users.
Each user becomes owner
of the uNaDa, meaning that
no one else can access it.
Successful
uNaDa
parameters configuration.

uNaDa
REST API

DB, uNaDaEnduser
interface

uNaDas
A
and B of RBHORST
testbed

HORST
Android
Application
+
uNaDa
REST API

Enduser
application,
DB, uNaDaEnduser
interface

uNaDas
A
and B of RBHORST
testbed

Social
Monitoring

SM,
DB,
Facebook
application,
Vimeo

Junit tests

Initialized uNaDa software
in both RPis, accessed
uNaDa’s Web interface
from N5s.
George Petro logins to RPi
A and Sergios Soursos to
RPi B, both using their
facebook credentials. They
both configure their uNaDa
properties
and
logout.
George Petro tries to
access RPi B.
Initialized uNaDa software
in RPi A.
George Petro calls the
REST API from the N5
browser, using his
facebook ID, and the REST
API should return the wifi
configuration of the private
SSID.
Sergios calls the REST API
using his facebook ID, and
the REST API should return
the wifi configuration of the
private SSID, because he is
George’s friend, thus a
trusted user.
Random user tried to call
the REST API, but receives
negative response.
Initialized uNaDa software
in RPi A.
Sergios Soursos enables
WiFi in his N5 B, and opens
the Android application.
Logins to Facebook and
waits to connect to the
private SSID of George
Petro’s uNaDa (RPi A).
JUnit tests using George
Petro’s access token.
The tests check whether
social monitor fetches all
required information.

Social
Analyzer

SM, SA, DB,
Facebook

Junit tests

JUnit tests using George
Petro’s access token.

Page 168 of 191

Owner receives private
SSID credentials.
Trusted users receive
private SSID credentials.
Non trusted users always
receive a negative answer.

Connect to remote uNaDa
private SSID and gain
access to the Internet.

Social Monitor should fetch
George’s friends, his and
his friends’ feed items, and
also save them in the
database. It should also
fetch video information from
Vimeo and store them as
well.
Social Monitor should fetch
George’s friends, his and
Version 1.0

© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Prediction

application,
Vimeo

Cache
managemen
t

CTM,
Vimeo

DB,

Junit tests

Proxy
requests

CTM,
Vimeo

DB,

Junit tests

URI
rewriting

CTM, DB

uNaDa

SM,

The tests check whether
social monitor fetches all
required information, and
then whether Analyzer
selects some contents that
could be prefetched.
For that reason, Sergios
Soursos posted 1 Vimeo
video in George Petro’s
facebook wall, and 1 Vimeo
video in his own wall.
The tests check whether
CTM will prefetch contents
from Vimeo and update the
database. A list of Vimeo
contents is provided as the
outcome of the social
analyzer prediction, and
CTM should prefetch them
all.
Afterwards, the cleaning
task is also performed and
should delete all contents in
the database, because they
are outdated.
The Unit tests check
whether CTM proxies only
Vimeo requests.
Specifically, a non-Vimeo
request is initially
performed, then a Vimeo
request for a content that is
not cached, and finally a
request for a cached
content.

Junit tests

DB,

uNaDas

A

The Unit tests check
whether CTM rewrites URIs
for cached Vimeo contents.
Initially, a first request is not
Vimeo-related and should
be returned as it is.
Then, another Vimeo
streaming request is
passed, but for content
which does not exist in the
database. It should return
the same URI.
Finally, a Vimeo streaming
request is performed, for
cached content. It should
return the local http server
URI and also add a content
access to the database.
Initialized uNaDa software

Version 1.0

his friends’ feed items, and
also save them in the
database. It should also
fetch video information from
Vimeo and store them as
well.
Social Analyzer should
return at least one content
as candidate for
prefetching.
Vimeo contents should be
fetched and saved in the
expected cache path, and
also their respective
database entries should be
inserted in the database.
In the second iteration,
contents should be deleted
both from the cache, and
also the respective
database tables.

Only Vimeo requests must
be proxied.
Vimeo requests for non
cached videos should be
proxied and also initiate
content prefetching from
Vimeo. Content should be
saved in cache and also
respective rows in the
database.
Vimeo requests for cached
videos should be proxied,
but do not initiate content
prefetching, because
content exists.
Only Vimeo streaming
requests must be taken into
account.
Vimeo streaming requests
for non cached contents
should be ignored.
Vimeo streaming requests
for cached contents should
be rewritten to the local
HTTP server URIs and also
content access entries
should be added to the
database.

Social Monitor should fetch

Page 169 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

social
monitoring

Facebook
application,
Vimeo

and B of RBHORST
testbed

in both RPis.
Social Monitors in both of
them should retrieve and
fetch all required
information from Facebook
and Vimeo.

uNaDa
social
prediction

SM, SA, DB,
Facebook
application,
Vimeo

uNaDas
A
and B of RBHORST
testbed

Vimeo
proxying and
rewriting

CTM,
SM,
SA,
DB,
Facebook
application,
Vimeo

uNaDas
A
and B of RBHORST
testbed

Overlay
creation,
join,
advertiseme
nt,
prediction

OM,
CTM

uNaDas
A
and B of RBHORST
testbed

Initialized uNaDa software
in RPi A.
Sergios Soursos posted 1
Vimeo video in George
Petro’s facebook wall, and
1 Vimeo video in his own
wall.
Social Monitor fetches all
required social information,
and social analyzer
prefetches one of Sergios
Vimeo videos.
Initialized uNaDa software
in RPi A.
Sergios Soursos posted 1
Vimeo video in George
Petro’s facebook wall, and
1 Vimeo video in his own
wall.
Social Monitor fetches all
required social information,
social analyzer prefetches
one of Sergios Vimeo
videos, George tries to
watch this video and video
is served from local HTTP
server.
George tries to browse to
other Websites and no
proxying is done.
George accesses other
Vimeo contents, videos are
downloaded from Vimeo
and are available to be
served in future requests.
George accesses some of
these contents again, and
videos are served from
local http server.
Initialized uNaDa software
in both RPis. RPi A is set
as bootstrap node, RPi B is
configured to join the
overlay and connect to the
A.
The 2 uNaDas must create
and maintain an overlay
Both uNaDas have some
contents watched and
cached. These contents are

DB,

Page 170 of 191

George’s friends, his and
his friends’ feed items, and
also save them in the
uNaDa’s database. It
should also fetch video
information from Vimeo and
store them as well.
Similar procedure should
happen in Sergios uNaDa.
Social prediction should
return and prefetch at least
one content to George’s
uNaDa

No proxying for non Vimeo
requests.
Proxying for Vimeo
requests, and content
download to be available in
the cache.
No URL rewriting for non
cached contents.
URL rewriting for cached
contents, and streaming
from local http server.

Overlay creation, join,
advertisement and
prediction should work.
Contents should be fetched
from the other overlay
nodes and stored in the
local cache.

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Full
prototype
working

ALL

uNaDas
A
and B of RBHORST
testbed

advertised to the overlay.
They have 2 common
contents, hence overlay
prediction should return
their non cached contents
as available for prefetching.
Non common contents
should be prefetched from
overlay and cached to
uNaDas’ databases.
Initialized uNaDa software
in both RPis. RPi A is set
as bootstrap node, RPi B is
configured to join the
overlay and connect to the
A.
The 2 uNaDas must create
and maintain an overlay.
Sergios Soursos posted 1
Vimeo video in George
Petro’s facebook wall, and
1 Vimeo video in his own
wall.
Social Monitor fetches all
required social information,
social analyzer prefetches
one of Sergios Vimeo
videos, George tries to
watch this video and video
is served from local HTTP
server.
Social analyzer prefetches
one content in George’s
uNaDa. George can watch
the video, served from local
http server.
George and Sergios
browse several Vimeo
videos, which are cached in
their uNaDas and also
advertised to the overlay.
They have some common
contents, hence overlay
prediction should return
their non cached contents
as available for prefetching.
Non common contents
should be prefetched from
overlay and cached to
uNaDas’ databases.
They can both connect to
each other’s uNaDa using
the Android application, and
also can watch locally
prefetched and cached
contents.

Version 1.0

Full working prototype

Page 171 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

11.3.3 Issues
Integration tests identified certain issues, which are presented in Figure 92.

Figure 92: v2.0 issues.
The issues were finally resolved and re-tested, and v2.0 was released.

11.4 Release v2.1
Version 2.1 was the first sub-release of v2.0, implementing bug fixes and enhancements
to the RB-HORST mechanism.
11.4.1 Features
Main improvements, which are presented in the form of JIRA tickets (Figure 93), included:
Updated social prediction algorithm, which considers friends’ posts in the News
Feed,
Updated cache management algorithm,
Overlay Manager improvements and AS hops inclusion in sorted content list,
uNaDa UI improvements,
Android application UI improvements.

Page 172 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Figure 93: v2.1 features.
11.4.2 Tests
The integration testbed and the test cases included the ones performed in v2.0 (Section
11.3.2) and certain new and more complex ones (Table 11-4).
Table 11-4: v2.1 integration tests
Description

Components

Environment

Configuration/Execution

Expected Outcome

Social
Prediction

ALL

Full
HORST
testbed

RB-

Video should be prefetched
(or not), depending on the
social
prediction
parameters set and the
configured social prediction
threshold.
The result can be checked
in the George’s uNaDa
logs, the demo screen page
or the cache screen page of
the Web interface.

Overlay
prediction
(content
does
not
exist in the
overlay
nodes)

ALL

Full
HORST
testbed

RB-

Andri posts a Vimeo video
to his Facebook wall.
Content is not cached in
George’s
or
Sergios
uNaDas.
Start George’s uNaDa.
Login to the George’s
uNaDa Web interface and
try
different
social
prediction
parameters
configuration, each time.
Also modify the social
prediction threshold each
time.
Start Andri’s and George’s
uNaDas.
Andri connects to his
private SSID and watches a
Vimeo video.
Content is not cached in
George’s
or
Sergios

Version 1.0

Video should be prefetched
(or not), depending on the
the
configured
overlay
prediction threshold.
In addition, video will be
prefetched by the Vimeo
CDN servers, since the 2
Page 173 of 191

© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

uNaDas.
Modify
the
overlay
prediction threshold each
time.

uNaDas are 2 ASes away.
The result can be checked
in the George’s uNaDa
logs, the demo screen page
or the cache screen page of
the Web interface.
Video will be prefetched by
Sergios’
uNaDa,
since
George’s
and
Sergios’
uNaDas belong to the same
domain.
The result can be checked
in
the
George’s
and
Sergios’ uNaDas’ logs, the
demo screen page or the
cache screen page of the
Web interface.
Video is predicted by both
prediction algorithms, but
will be prefetched by the
Vimeo CDN servers, since
the 2 uNaDas are 2 ASes
away.
The result can be checked
in the George’s uNaDa
logs, the demo screen page
or the cache screen page of
the Web interface.
Video is predicted by both
prediction algorithms, and
will be prefetched by
Sergios’
uNaDa,
since
George’s
and
Sergios’
uNaDas belong to the same
domain.
Monitor the social and
overlay prediction scores of
the predicted content from
the logs.
The result can be checked
in
the
George’s
and
Sergios’ uNaDas’ logs, the
demo screen page or the
cache screen page of the
Web interface.

Overlay
prediction
(content
exists in the
overlay
nodes)

ALL

Full
HORST
testbed

RB-

Start Andri’s and George’s
uNaDas.
Andri connects to his
private SSID and watches a
Vimeo video.
Content is cached in
Sergios uNaDa, hence will
be
considered
as
a
candidate node to be
prefetched from.

Social and
overlay
prediction
(content
does
not
exist in the
overlay
nodes)

ALL

Full
HORST
testbed

RB-

Start Andri’s and George’s
uNaDas.
Andri connects to his
private SSID and watches a
Vimeo video. He also posts
it to his Facebook wall.
Content is not cached in
George’s
or
Sergios
uNaDas.

Social and
overlay
prediction
(content
exists in the
overlay
nodes)

ALL

Full
HORST
testbed

RB-

Start Andri’s and George’s
uNaDas.
Andri connects to his
private SSID and watches a
Vimeo video. He also posts
it to his Facebook wall.
Content is cached in
Sergios uNaDa, hence will
be
considered
as
a
candidate node to be
prefetched from.

11.4.3 Issues
No issues were found during v2.1 integration tests and v2.1 was released successfully.

11.5 Release v3.0
Version 3.0 of the SmartenIT software implements additional DTM features.

Page 174 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

11.5.1 Features
Based on the updated version of DTM specification a set of JIRA issues was identified.
These are presented in Figure 94.
The major changes introduced in this version are the following:
support for 95th percentile billing rule;
added new system control variables and time schedule parameters;
added SDN Controller operation modes (proactive vs reactive);
compensation vector handling in Network Traffic Manager to reduce the number of
updates sent towards remote domains.

Figure 94: v3.0 features.
11.5.2 Tests
The integration testing procedure that preceded the release of SmartenIT software v3.0
comprised the execution of all the test cases defined for release v1.2 presented in section
11.2.2 and additional tests described in Table 11-5.
Table 11-5: v3.0 integration test cases.
Description

Components

Environment

Configuration/Execution

Expected Outcome

Complete
chain
with
95th
percentile
based
charging
rule and one
receiving
DC.

QOA,
NTM,
SBox

JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

NTM at sending domain is
initialized
with
mocked
SBox-SDN client which is
later on used to verify
interactions with the SDN
controller.
Inter-SBox
server is launched. At the
receiving domain NTM,
Economic Analyzer and
QoS Analyzer components
are
initialized.
Mocked
DAOs are used instead of
the real DB and return
preconfigured
structures
representing two domains
with two inter-connected
DCs. The 95th percentile
billing rule is used in the
SBox.

Values of C and R vectors
passed to SBox-SDN client
are verified against known
values.

ECA,
inter-

Version 1.0

Page 175 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

QoS Analyzer reads preconfigured counter values
from
mocked
SNMPWrapper, calculates
X and Z vectors and
passes them to ECA and
NTM. ECA calculates R
vector from 95th percentile
traffic
samples
after
accounting period. NTM
calculates C vector after
each reporting period and
updates remote NTM with
new C and R (after
accounting period) vectors.
Received C and R vectors
are passed to a mocked
instance of
SBox-SDN
client.
Test
is
run
for
2
consecutive
accounting
periods.
Basic Sanity
testing
for
release v3.0

ALL

WP4 testbed
at PSNC.

Configure the database of
each
SBox
with
the
required
domain
information. Configuration
should include the 95th
percentile charging rule and
one of the SDN controller
operation modes.
Run 1 SBox in receiving
domain. Run 1 SBox and 1
SDN controller in sending
domain.
SDN
controller
should
initially
receive
the
configuration data.

No exceptions or logs that
indicate failures.
Compare logs and verify
that
reference
and
compensation vectors are
sent to the sending domain,
and then to the SDN
Controller.
Verify that test traffic
generated between DCs is
distributed by the SDN
Controller running in all four
operation modes.

QOA in receiving domain
reads
counters
from
deployed software routers
and provides X and Z
vectors to NTM and ECA.
Periodically, the R and C
vectors are sent to the
SBox in the sending
domain and then the SDN
controller is also updated.

11.5.3 Issues
No major issues were identified during the integration testing. After issues were fixed v3.0
was released successfully.

Page 176 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

11.6 Release v3.1
Version 3.1 of the SmartenIT software implements additional DTM features.
11.6.1 Features
Based on the updated version of DTM specification a set of JIRA issues was identified.
These are presented in Figure 95.
The major changes introduced in this version are the following:
added BG router configuration using NETCONF protocol;
support for delay-tolerant traffic management;
introduced new compensation vector calculation in the case when reference vector
is achieved on one or more links.

Figure 95: v3.1 features.
11.6.2 Tests
The integration testing procedure that preceded the release of SmartenIT software v3.1
comprised the execution of all the test cases defined for releases v1.2 and v3.0 presented
in sections 11.2.2 and 11.5.2 and additional tests described in Table 11-6.
Table 11-6: v3.1 integration test cases.
Description

Components

Environment

Configuration/Execution

Expected Outcome

Complete
chain
with
95th
percentile
based
charging
rule,
advanced
operations
when
R
vector

QOA,
NTM,
SBox

JUnit
test
case
with
mocked: DB,
SNMP
readouts and
SBox-SDN
client

NTM at sending domain is
initialized with mocked
SBox-SDN client which is
later on used to verify
interactions with the SDN
controller.
Inter-SBox
server is launched. At the
receiving domain NTM,
Economic Analyzer and
QoS Analyzer components
are
initialized.
Mocked

Values of C and R vectors
passed to SBox-SDN client
are verified against known
values.

ECA,
inter-

Version 1.0

Page 177 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

achieved on
link and one
receiving
DC.

DAOs are used instead of
the real DB and return
preconfigured
structures
representing two domains
with two inter-connected
DCs. The 95th percentile
billing rule is used in the
SBox.
QoS Analyzer reads preconfigured counter values
from
mocked
SNMPWrapper, calculates
X and Z vectors and
passes them to ECA and
NTM. ECA calculates R
vector from 95th percentile
traffic
samples
after
accounting period. NTM
calculates C vector after
each reporting period and
updates remote NTM with
new C and R (after
accounting period) vectors.
Received C and R vectors
are passed to a mocked
instance of SBox-SDN
client.
C vector updates are sent
only if specific conditions
are met. Before the end of
accounting period, ECA
sends to NTM a list of links
for which the calculated R
vector value has already
been
achieved.
This
triggers different C vector
calculation algorithm.
Test
is
run
for
2
consecutive
accounting
periods.

Basic Sanity
testing
for
release v3.1

ALL

WP4 testbed
at PSNC.

There are 4 domains
configured in the testbed (2
receiving and 2 sending).
Configure the database of
each of 4 SBoxes with the
required
domain
information. Configuration
should include the 95th
percentile charging rule and
one of the SDN controller
operation modes.
Run 1 SBox per receiving
domain. Run 1 SBox and 1
SDN controller per sending
domain.

Page 178 of 191

No exceptions or logs that
indicate failures.
Compare logs and verify
that
reference
and
compensation vectors are
sent
to
the
sending
domains, and then to the
SDN Controllers.
Verify that test traffic
generated between DCs is
distributed by the SDN
Controllers to DCs via
proper tunnels.

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

SDN controllers should
initially
receive
the
configuration data.
QOA in receiving domain
reads
counters
from
deployed software routers
and provides X and Z
vectors to NTM and ECA.
Periodically, the R and C
vectors are sent to the both
SBoxes in the sending
domains
and
then
respective SDN controllers
are also updated.

11.6.3 Issues
No major issues were identified during the integration testing. After issues were fixed v3.1
was released successfully.

Version 1.0

Page 179 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

12 Summary
In this deliverable, we reported the final outcomes of WP3: the final system architecture,
the final implementation framework, the two integrated and released prototypes, DTM and
RB-HORST and the complete list of their system releases, as well as the standalone
implementations, MUCAPS, vINCENT, MoNA, and SDNDC.
The final SmartenIT architecture was finalized and documented in D3.3 [3]. The two
released prototypes, as well as the presented standalone implementations deploy a
subset of the defined architectural entities, components and interfaces, in order to fulfil
their goals and functionalities.
A common implementation framework has been agreed and set up since the beginning of
WP3 and has been documented in D3.2 [2]. The agile development and continuous
integration concepts were adopted, aiming at 2-month release cycles and rapid code
development, and issue resolution. In addition, certain tools were deployed to support
these concepts: a Subversion source code repository, a JIRA issue management
platform and a Jenkins continuous integration server were deployed in PSNC’s premises.
The first integrated SmartenIT prototype is the DTM, which maps to two architecture
entities: the SBox and the SDN Controller. SBox includes the following components: The
QoS Analyzer retrieves the required SNMP measurements from the network entities, the
Economic Analyzer calculates the reference vector based on links’ costs and the Network
Traffic Manager calculates the compensation vector and also coordinates the interaction
with the other entities (remote SBox, local SDN Controller). The inter-SBox
Communication Service is responsible for sending and receiving the calculated reference
and compensation vector to/from other SBoxes. The SBox-SDN executes the same
functionality towards the local SDN controller, and finally, UI and DB provide the
necessary interfaces to save and access required configuration. The SDN Controller is
built on top of Floodlight controller source code to implement DTM functionality, which
translates received compensation and reference vectors into flow rules. It also exposes
interfaces towards the SBox to receive these vectors and additional configuration
parameters.
The second integrated prototype is the RB-HORST, which implements two architecture
entities: uNaDa and End-user application. The uNaDa is a Java Web application which
consists of the following components: The Social Manager monitors the OSNs for useful
social information, while the Social Analyzer aggregates this information to perform the
social prediction algorithm and return the ranked list of contents, likely to be watched.
uNaDas’ AS hops are calculated by the Topology Proximity Monitor and are given as input
to the Overlay Manager, which sets up the peers’ overlay network, advertises and
prefetches content from other uNaDas and executes the overlay prediction algorithm. The
Cloud Traffic Manager is the coordinating component of the uNaDa, which receives the
results of social and overlay prediction algorithms, prefetches the most-likely to be
watched, and also manages the uNaDa’s cache. DB and UI are components which
support the other components’ basic functionalities, while the uNaDa-End-User interface
exposes an interface towards end-user applications, to authenticate and receive SSID
credentials. The End-user application is an Android application which is used by the endusers to connect to a remote uNaDa’s private SSID, using their Facebook credentials. The
RB-HORST Android application has been released in the Google Play Store [40].

Page 180 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

All the aforementioned tools and procedures aimed at and ensured a commercially
developed and integrated prototype, following industry standards. Three major (1.0, 2.0
and 3.0) and four minor (1.1, 1.2, 2.1 and 3.1) versions of the SmartenIT software were
released by the WP3 integration team, implementing new features and fixing bugs of the
DTM and RB-HORST mechanisms. For every released version, certain test cases were
designed and finally performed in the integration testbeds, validating the prototypes’
functionalities and operation. Version 3.1 concluded the implementation work of WP3,
including the final DTM and RB-HORST prototypes.
The consortium aimed at making the source code of the project available to the general
public. Therefore, key releases of the SmartenIT project (1.1, 1.2, 2.1, 3.0 and 3.1) were
released as open-source to Github [39], under Apache v2 license.
Additional prototypes have been developed to address further goals of the SmartenIT
project, but were not integrated to the DTM or RB-HORST prototypes. MUCAPS optimizes
the overlay application traffic by involving awareness on the underlying network topology
and on transport costs, proposing ALTO protocol extensions. VINCENT proposes and
implements an incentive scheme for users to open their access points to other users,
while MoNA focuses on reducing the energy consumption of end-users’ mobile devices.
Finally, the SDNDC mechanism complements standard DNS based redirection used by
many cloud service providers and CDNs by allowing the migration of high-volume flows
between surrogates in the backend.

Version 1.0

Page 181 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

13 SMART Objectives Addressed
This deliverable addresses certain SmartenIT SMART objectives defined in Section
B1.1.2.4 of the SmartenIT Description of Work (DoW) [31]. Specifically, the deliverable
addresses the WP3 SMART Objective (Table 13-1), two overall SMART objectives (Table
13-2) and one prototyping SMART objective (Table 13-3).
The WP3 Objective is defined in the DoW as follows:
Table 13-1: Work Package 3 SMART objective addressed.
Objective 3 SmartenIT will investigate economically, QoE, and energy-wise such models
in theory by simulations to guide the respective prototyping work in terms of
a successful, viable, and efficient architectural integration, framework and
mechanisms engineering, and its subsequent performance evaluation.
This deliverable is the final outcome of the engineering work performed in WP3, providing
the technical documentation of the two implemented, integrated and released traffic
management mechanisms, DTM and RB-HORST. These prototypes and the additional
standalone implementations, MUCAPS, VINCENT, MoNA and SDN-based DC selection,
address Objective 3, in the sense that “a successful, viable, and efficient architectural
integration, framework and mechanisms engineering” evolved and were finalized.
In addition, the overall SmartenIT SMART objectives presented in Table 13-2 have been
addressed in the current document. The SmartenIT architecture was finalized and
documented in D3.3 [3], covering all aspects and functionalities of the designed WP2
mechanisms, which were later implemented into specific software modules under the
scope of WP3, resulting in functional integrated prototypes. Overall, six mechanisms were
developed and tested, covering all aspects of the SmartenIT DoW.
Table 13-2: Overall SmartenIT SMART objectives addressed.
Measurable

Objective
No.

O3

Specific

Deliverable
Number

Timely
Achievable

Relevant
Mile Stone Number

Framework and
mechanism engineering

D3.2

Implementation

Advanced

MS3.4, MS3.5

Architectural integration

D3.2

Implementation

Complex

MS3.4, MS3.5

Page 182 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Finally, this document addresses the prototyping SMART objective O3.4, with the
implementation of the MoNA mechanism, which monitors and reduces energy
consumption in end-users’ mobile devices.
Table 13-3: Prototyping SmartenIT SMART objectives addressed.
Objective
ID

O3.4

Measurable
Specific

Timely
Achievable

Relevant

Prototyping

Highly relevant
output of
relevance for
users

Metric

How to monitor energy
and take appropriate
coordinated actions?

Number of options
identified to monitor
energy consumption on
networking elements and
end users mobile devices,
investigation on which
options perform best
(yes/no)

Version 1.0

Project
Month

M36

Page 183 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

14 References
[1]

The SmartenIT project: Deliverable D3.1 - Report on Initial System Architecture; April
2013

[2]

The SmartenIT project: Deliverable D3.2 - Technologies, Implementation Framework,
and Initial Prototype; July 2014

[3]

The SmartenIT project: Deliverable D3.3 - Final Report on System Architecture;
October 2014

[4]

The SmartenIT project: Deliverable D4.1 - Test-bed Set-up and Configuration;
October 2014

[5]

Microsoft Visio, online. Available at: http://office.microsoft.com/en-001/visio/

[6]

Java Development Kit, a development environment for building applications, applets,
and components using the Java programming language, online. Available at:
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads1880260.html

[7]

Android - a mobile operating system based on the Linux kernel that is currently
developed by Google, online. Available at: http://www.android.com/

[8]

Apache Maven, online. Available at: http://maven.apache.org/

[9]

Apache Subversion software, online. Available at: http://subversion.apache.org/

[10] GitHub, a web-based Git repository hosting service. Available at: https://github.com/
[11] Atlassian JIRA, online. Available at: https://www.atlassian.com/software/jira
[12] Jenkins open source continuous integration server, online. Available at: http://jenkinsci.org/
[13] Eclipse Jetty, online. Available at: http://www.eclipse.org/jetty/
[14] SQLite - SQL database engine, online. Available at: http://www.sqlite.org/
[15] The
H2
Database
Engine,
http://www.h2database.com/html/main.html

online.

Available

at:

[16] Lighttpd, an open-source Web server optimized for speed-critical environments.
Available at: http://www.lighttpd.net/
[17] Mitmproxy, an interactive console program that allows traffic flows to be intercepted,
inspected, modified and replayed. Available at: https://mitmproxy.org
[18] Apache v2 license, a free software license written by the Apache Software
Foundation (ASF). Available at: https://www.apache.org/licenses/LICENSE-2.0
[19] R. Enns, Ed., "NETCONF Configuration Protocol", RFC 6241, June 2011
[20] JUnit – a programmer-oriented testing framework for Java, online. Available at:
http://junit.org/
[21] Mockito
open
source
testing
https://code.google.com/p/mockito/

framework,

online.

Available

at:

[22] Bootstrap front-end framework, online. Available at: http://getbootstrap.com/
[23] Project Floodlight, online. Available at: http://www.projectfloodlight.org/floodlight/

Page 184 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

[24] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and
R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285,
September 2014.
[25] The SmartenIT project: Deliverable D2.2 - Report on Definitions of Traffic
Management Mechanisms and Initial Evaluation Results; October 2013
[26] The SmartenIT project: Deliverable D2.4 - Report on Final Specifications of Traffic
Management Mechanisms and Evaluation Results; October 2014
[27] Facebook, online. Available at: https://www.facebook.com/
[28] Vimeo, online. Available at: https://vimeo.com/
[29] TomP2P, a distributed hash table which provides a decentralized key-value
infrastructure for distributed applications. Available at: http://tomp2p.net
[30] Raspberry Pi - a low cost, credit-card sized computer, online. Available at:
http://www.raspberrypi.org/
[31] The SmartenIT Consortium: Grant Agreement for STREP: Annex I – Description of
Work (DoW). 2012.
[32] Ubuntu - a Debian-based
http://www.ubuntu.com/

Linux

operating

system,

online.

Available

at:

[33] The Netty project, online. Available at: http://netty.io/
[34] J. Case, M. Fedor, M. Schoffstall, J. Davin, "A Simple Network Management Protocol
(SNMP)", RFC 1157, May 1990
[35] OpenFlow:
Open
Switch
specification,
online.
Available
https://www.opennetworking.org/sdn-resources/onf-specifications/openflow

at:

[36] N. Gautam, H. Petander, and J. Noel, “A comparison of the cost and energy
efficiency of prefetching and streaming of mobile video,” in Proc. MoVid, 2013.
[37] M. Wichtlhuber, R. Reinecke, and D. Hausheer, “An SDN based CDN/ISP
Collaboration Architecture for Managing High-Volume Flows”, IEEE TNSM Special
Issue on Efficient Managementof SDN and NFV-based Systems, vol. 12, no. 1, pp.
406–409, 2015.
[38] “Global Internet Phenomena Report,” Sandvine Inc., Tech. Rep., 2013.
[39] The SmartenIT project, “The source code of the SmartenIT software”. Available at:
https://github.com/smartenit-eu/smartenit
[40]

The SmartenIT project, RB-HORST Android application. Available
https://play.google.com/store/apps/details?id=eu.smartenit.enduser.app

Version 1.0

at:

Page 185 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

15 Abbreviations
ALTO

Application Layer Traffic Optimization, Working group of the Internet
Engineering Task Force

API

Application Interface

AS

Autonomous System

BG

Border Gateway

BGP

Border Gateway Protocol

CTM

Cloud Traffic Manager

DA

Datacenter Attachment

DAO

Data Access Object

DB

Database

DC

Datacenter

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name System

DTM

Dynamic Traffic Management

DTO

Data Transfer Object

ECA

Economic Analyzer

HTTP

Hypertext Transport Protocol

ICC

Inter-Cloud Communication

ISCS

Inter-SBox Communication Service

ISP

Internet Service Provider

JDK

Java Development Kit

JSF

Java Server Faces

JSON

Javascript Object Notation

MIB

Management Information Base

MoNA

Mobile Network Assistant

MPLS

Multiprotocol Label Switching

MUCAPS

Multi-Criteria Application End-Point Selection

NaDa

NanoDatacenter

NSP

Network Service Provider

NTM

Network Traffic Manager

OM

Overlay Manager

OSN

Online Social Network

PC

Personal Computer

Page 186 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

PoP

Point of Presence

QOA

QoS/QoE Analyzer

QoE

Quality of Experience

QoS

Quality of Service

RAM

Random Access Memory

RB-HORST Replicating Balanced Tracker - Home Router Sharing based on Trust
REST

Representational State Transfer

RFC

Request for Comments

SA

Social Analyzer

SBox

SmartenIT Box

SDN

Software Defined Networking

SDNDC

SDN-based DC selection

SM

Social Monitor

SmartenIT

Socially-aware Management of New Overlay Application Traffic with Energy
Efficiency in the Internet, EU STREP project

SNMP

Simple Network Management Protocol

SSID

Service Set Identifier

STREP

Specific Targeted Research Project

TCP

Transmission Control Protocol

TPM

Topology Proximity Monitor

UDP

User Datagram Protocol

UI

User Interface

UML

Unified Modeling Language

uNaDa

user NanoDatacenter

URL

Uniform Resource Locator

VINCENT

Virtual Incentives

VM

Virtual Machine

WP

Work Package

Version 1.0

Page 187 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

16 Acknowledgements
This deliverable was made possible due to the large and open help of the WP3 team of
the SmartenIT team within this STREP, which includes the deliverable authors presented
in the document control, and the internal reviewers Ioanna Papafili, Paolo Cruschelli and
Burkhard Stiller for their valuable feedback. Many thanks to all of them.

Page 188 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

Appendix A. Internal Interfaces Protocol Format
In this section JSON format of the internal interfaces protocol is presented including some
sample values as retrieved from the integration testing logs. A significant modification of
the exchanged data has been introduced since prototype release v1.0 presented in
Deliverable D3.2 [2].

A.1. Reference and Compensation Vectors JSON Format
{"referenceVector":{
"vectorValues":[{"value":1000,"tunnelEndPrefix":{"prefix":"10.1.1.0","pre
fixLength":24}},{"value":1500,"tunnelEndPrefix":{"prefix":"10.1.2.0","pre
fixLength":24}}],"sourceAsNumber":100,"thetaCollection":null},
"compensationVector":{
"vectorValues":[{"value":500,"tunnelEndPrefix":{"prefix":"10.1.1.0","pref
ixLength":24}},{"value":-500,"tunnelEndPrefix":{"prefix":"10.1.2.0","pref
ixLength":24}}],"sourceAsNumber":100}}

A.2. Configuration Data JSON Format
{"entries":[{
"remoteDcPrefix":{"prefix":"10.10.3.0","prefixLength":24},
"daRouterOfDPID":"00:00:00:00:00:00:00:01",
"tunnels":
[{"tunnelID":{"tunnelName":"TUN1","localTunnelEndAddress":{"prefix":"172.
16.16.2","prefixLength":32},"remoteTunnelEndAddress":{"prefix":"172.16.16
.1","prefixLength":32}},"daRouterOfPortNumber":1},
{"tunnelID":{"tunnelName":"TUN2","localTunnelEndAddress":{"prefix":"172.1
6.16.6","prefixLength":32},"remoteTunnelEndAddress":{"prefix":"172.16.16.
5","prefixLength":32}},"daRouterOfPortNumber":2}]}],
"operationModeSDN":"proactiveWithoutReferenceVector",
"localDCPortsConfig":[{"daRouterOfDPID":"00:00:00:00:00:00:00:01","localD
COfSwitchPortNumbers":[5]}]}

Version 1.0

Page 189 of 191
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation, Validation
and Selected Application

Seventh Framework STREP No. 317846

Commercial in Confidence

Appendix B. NetConf XML Messages Format
In order to implement delay tolerant traffic management decisions on BG routers the
NETCONF protocol [19] is being used. Please note that the current prototype
implementation supports only Juniper MX devices1 as BG routers.
Following are XML messages used to perform specific actions on the BG router filled with
some example values (e.g. interface names) used during tests. Please note that the
implementation assumes that a specific configuration was set up on the router manually
beforehand. The names of policers are currently not configurable so need to be strictly
followed. Two names are used, i.e. POLICER_EF_<cap-iface-name> and
POLICER_TOLERANT_TRAFFIC_<cap-iface-name>, where <cap-iface-name> should be
replaced with capitalized name of a specific interface on which given policer is used, e.g.
GE-2/0/4.

B.1. Filter activation and deactivation
<rpc>
<load-configuration action="set" format="text">
<configuration-set>
activate interfaces ge-2/0/4 unit 0 family inet filter input
</configuration-set>
</load-configuration>
</rpc>
]]>]]>
<rpc>
<load-configuration action="set" format="text">
<configuration-set>
deactivate interfaces ge-2/0/4 unit 0 family inet filter input
</configuration-set>
</load-configuration>
</rpc>
]]>]]>

B.2. Policer bandwidth limits update
<rpc>
<load-configuration action="set" format="text">
<configuration-set>
set firewall policer POLICER_EF_GE-2/0/4 if-exceeding bandwidthlimit 100000 burst-size-limit 625000
</configuration-set>
</load-configuration>
</rpc>
]]>]]>
<rpc>
<load-configuration action="set" format="text">
<configuration-set>

1

http://www.juniper.net/us/en/products-services/routing/mx-series/

Page 190 of 191

Version 1.0
© Copyright 2015, the Members of the SmartenIT Consortium

D3.4 – Prototype Implementation,
Validation and Selected Application

Seventh Framework STREP No. 317846
Commercial in Confidence

set firewall hierarchical-policer POLICER_TOLERANT_TRAFFIC_GE2/0/4 aggregate if-exceeding bandwidth-limit 100000 burst-size-limit
625000
</configuration-set>
</load-configuration>
</rpc>
]]>]]>
<rpc>
<load-configuration action="set" format="text">
<configuration-set>
set firewall hierarchical-policer POLICER_TOLERANT_TRAFFIC_GE2/0/4 premium if-exceeding bandwidth-limit 100000 burst-size-limit 625000
</configuration-set>
</load-configuration>
</rpc>
]]>]]>

Version 1.0

Page 191 of 191
© Copyright 2015, the Members of the SmartenIT Consortium