d2.3-fi-star back-end platform services modules beta

Deliverable D2.3

FI-STAR Back-End Platform Services Modules Beta: Development & Access Support

Editor: Paolo Zampognaro, Engineering Ingegneria Informatica

Adel Al-Hezmi, Fraunhofer FOKUS

Deliverable nature: R

Dissemination level: (Confidentiality)

Restricted to Programme (PP)

Contractual delivery date:

M22 (January 2015)

Actual delivery date: 16 February 2015

Suggested readers: FI-STAR Infrastructure Managers, FI-STAR Applications Developers, FI-STAR Applications Provider

Version: 1.0

Total number of pages: Main document: 78

Keywords: FI-STAR Catalogue, FI-STAR Specific Enabler, FI-STAR Reference Cloud Environment, FI-STAR Platform Provider

Abstract

This document provides (i) a report about the development activity of the FI-STAR Back-End Platform Services (SEs) for the Beta release and (ii) a report about the interactions, by all the actors, with the FI-STAR Catalogue and its integration with a solution to support the automatic shipment modality by the Application Provider.

Deliverable D2.3 FI-STAR FP7-ICT-604691

© FI-STAR consortium 2015 of (78)

Disclaimer

This document contains material, which is the copyright of certain FI-STAR consortium parties, and may not be reproduced or copied without permission.

All FI-STAR consortium parties have agreed to make this document available on request to other framework programme participants.

The commercial use of any information contained in this document may require a license from the proprietor of that information.

Neither the FI-STAR consortium as a whole, nor a certain part of the FI-STAR consortium, warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, accepting no liability for loss or damage suffered by any person using this information.

This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 604691.

Impressum

Full project title: Future Internet Social and Technological Alignment Research

Short project title: FI-STAR

Number and title of work-package: WP2: Back-End Platform Design and Development

Number and title of task: T2.3: FI-STAR Back-End Platform: Modules Development; T2.4 FI-STAR Platform Access Support: for (prototype BE-α) and refinement (prototype BE-β)

Document title: FI-STAR Back-End Platform Services Modules Beta: Development & Access support

Editors: Adel Al-Hezmi Fraunhofer FOKUS, Paolo Zampognaro ENG

Work-package leader: Paolo Zampognaro, ENG

Copyright notice

2015 Participants in project FI-STAR

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0

http://creativecommons.org/licenses/by-nc-nd/3.0/

http://creativecommons.org/licenses/by-nc-nd/3.0/



Executive summary

This deliverable is a follow-up on the previous deliverable D2.2 which, is worth to mention, covered (i) the previous ALPHA release of the FI-STAR Back-End platform (in PartA section) and (ii) the requirements analysis related to the FI-STAR Platform access and the consequential design of the FI-STAR Catalogue offering the main access point to the Platform itself (in PartB section).

This deliverable reports about the evolution on both these aspects.

In particular in the PartA the document covers the technical realization of the FI-STAR Back-End platform. It describes in detail the BETA (and therefore according to the development plan final release) of the software modules that have been developed in the course of work package WP2 to support the application development of the FI-STAR trial use cases. These services modules are specified as Application Support Services called FI-STAR Specific Enablers (SEs).

This part also tries to better qualify the adoption of the FI-WARE GEs and demonstrate the modularity of the SE, which allows to build upon existing FI-WARE GE implementations, as it has been asked in the Technical Review Report by the European Commission – Ares(2015)369120 – 30/01/2015.

The report covers following Specific Enablers:

Connectivity Service Back-End

Event Service SE

Targeting and Profiling SE

Security and Privacy SE

Mediation Service SE

Health questionnaire Service SE

Device Management Service SE

Real Time Communication Service SE

Time Service SE

Monitoring Service SE

The technical specifications described in this section are supposed to support the application implementation of the FI-STAR trial use cases and the realization of the BETA roll-out.

The Part B of this deliverable, instead, reports, about how the different actors (i.e. FI-STAR Application Developers, FI-STAR SE Owner, FI-STAR Application Provider) interacted with the Catalogue, to accomplish their tasks, during this second development cycle. It is worth to mention that from this interaction report comes out also the increasing interaction of external partners (i.e. Phase 3 SMEs from the main FI-PPP accelerators) giving evidence of the concrete engagement of the FI-STAR Platform by these partners. In this section is described, furthermore, the design of the solution to support the FI-STAR SEs automatic shipment modality offered to the Application Providers. With respect to this last point details are provided about (i) requirements identification (ii) architecture design and data model specification (ii) programmatic and GUI interfaces.

A list of references supporting the findings of the document provides the reader with specific detailed information.



List of authors

Company Author Contribution

ENG Paolo Zampognaro

Alessandro Avolio

Editor

Executive Summary, Introduction,

Part B: Chapters 2, 2.1, 2.3

Fraunhofer FOKUS Adel Al-Hezmi

Ancuta Corici

Konrad Campowsky

Mikhail Smirnov

Editor

Part A: Chapters 1, 1.1, 1.7

Part B: Contribution to 3.1

TUB Tran Quang Thanh

Benjamin Ertl

Yahya Al-Hazmi

Part A: Chapters 1.2, 1.3, 1.4, 1.10

Part B: Contribution to 3.1, 3.2

TSI-TUC Stelios Sotiriadis

Part A: Chapters 1.9

Part B: Contribution to 3.1, 3.2

TEK Patricia Casla Part A: Chapters 1.6


ITTI Tomasz Springer Part A: Chapters 1.8


C2K Stefano Nunziata Part A: Chapters 1.5


AGE Adrian Koepe, Tomasz Poslada,

Andrei Pintea


ENU John Brogan Part B: Contribution to 3.1



Table of Contents

Executive summary ......................................................................................................................... 3

List of authors ................................................................................................................................. 4

Table of Contents............................................................................................................................ 5

List of figures .................................................................................................................................. 8

List of tables .................................................................................................................................... 9

Abbreviations ................................................................................................................................ 10

Definitions ..................................................................................................................................... 13

Introduction ................................................................................................................................... 14

Objectives of this document....................................................................................................... 14

Specifications of this document ................................................................................................. 14

Deliverable structure ................................................................................................................. 14

Part A – FI-STAR Back-End Platform: Development Report ......................................................... 15

1 Implementation Activities ......................................................................................................... 16

1.1 Connectivity Service Back-End ......................................................................................... 18

1.1.1 Reported bugs and requirements ............................................................................... 18

1.1.2 New Interfaces ........................................................................................................... 18

1.1.3 Old Specified Interfaces ............................................................................................. 19

1.1.4 FI-Ware GE specification ........................................................................................... 20

1.1.5 FI-Ware GE uptake .................................................................................................... 21

1.2 Event Service ................................................................................................................... 21


1.2.2 New Interfaces ........................................................................................................... 22



1.2.5 FI-Ware GE uptake .................................................................................................... 24

1.3 Targeting and Profiling Service ......................................................................................... 24


1.3.2 New Interfaces ........................................................................................................... 25



1.3.5 FI-Ware GE uptake .................................................................................................... 27

1.4 Security and Privacy – Integrated Access Control ............................................................ 27


1.4.2 New Interfaces ........................................................................................................... 28



1.4.5 FI-Ware GE reference implementation ....................................................................... 29



1.5 Mediation Service ............................................................................................................. 30


1.5.2 New Interfaces ........................................................................................................... 30



1.5.5 FI-Ware GE uptake .................................................................................................... 33

1.6 Health Questionnaire Service ........................................................................................... 33


1.6.2 New Interfaces ........................................................................................................... 34




1.7 Device Management ......................................................................................................... 38


1.7.2 New Interfaces ........................................................................................................... 39



1.7.5 FI-Ware GE uptake .................................................................................................... 41

1.8 Real-time Communication Service .................................................................................... 41


1.8.2 New Interfaces ........................................................................................................... 42



1.8.5 FI-Ware GE uptake .................................................................................................... 43

1.9 Time Service..................................................................................................................... 43


1.9.2 New Interfaces ........................................................................................................... 43




1.10 Monitoring Service .......................................................................................................... 44

1.10.1 Reported bugs and requirements ............................................................................. 44

1.10.2 New Interfaces ......................................................................................................... 44

1.10.3 Old Specified Interfaces ........................................................................................... 46

1.10.4 FI-Ware GE specification ......................................................................................... 46

1.10.5 FI-Ware GE reference implementation ..................................................................... 46

Part B – FI-STAR Platform Access Support .................................................................................. 48

2 Solution for an Automatic Shipment and Deployment .............................................................. 49

2.1 Preliminary Concerns ....................................................................................................... 49



2.2 Application Provider: Platform Access .............................................................................. 49

2.3 Design details ................................................................................................................... 53

2.3.1 Details about the Human Machine Interaction Design ................................................ 55

3 The Catalogue: Usage Experience Report .............................................................................. 65

3.1 SE Owners report ............................................................................................................. 65

3.2 Cloud Platform Managers Report ...................................................................................... 72

3.3 Application Providers Report ............................................................................................ 74

3.4 Bugs analysis and improvements ..................................................................................... 75

3.5 Final considerations .......................................................................................................... 77

References ................................................................................................................................... 78



List of figures

Figure 1: FI-STAR Functional SEs Architecture ............................................................................ 17

Figure 2: FI-STAR Connectivity Back-End Service and FI-Ware enabled components ................. 20

Figure 3: FI-STAR Event Service and FI-WARE enabled components .......................................... 23

Figure 4 FI-STAR Targeting and Profiling service and FI-WARE enabled components ................. 26

Figure 5: High level architecture .................................................................................................... 27

Figure 6: FI-STAR Mediation Service and FI-Ware enabled components ..................................... 32

Figure 7: FI-STAR Device Management Service and FI-Ware enabled components .................... 41

Figure 8 – The Catalogue: Subscription Area ................................................................................ 50

Figure 9 – shipment modality evaluation results ............................................................................ 50

Figure 10 – Architecture to enable the automatic shipment ........................................................... 52

Figure 11 – Data Model: Overview ................................................................................................ 53

Figure 12 – Data Model: Deployment Options detail ..................................................................... 53

Figure 13 – Catalogue Agent: download window .......................................................................... 55

Figure 14 - Catalogue Agent Installation Wizard ........................................................................... 55

Figure 15 – Preliminary initialization actions .................................................................................. 56

Figure 16 - Catalogue Authorisation GUI – User Authentication .................................................... 56

Figure 17 - Catalogue Authorisation GUI – Agent Application Authorisation.................................. 56

Figure 18 – Agent Installation STEP 1: external or internal Configuration Manager. ..................... 57

Figure 19 - Agent Installation STEP 2: external or internal Deployment Service. .......................... 57

Figure 20 - Agent Installation STEP 3: Wizard completed ............................................................. 58

Figure 21 – Configuration Manager Main Page ............................................................................. 58

Figure 22 – Configuration Manager: New Customer Form ............................................................ 59

Figure 23 – Configuration manager: User Preferences Section..................................................... 59

Figure 24 – Configuration manager: Geographic Constraints ........................................................ 60

Figure 25 – Configuration Manager: Deployment Preferences ...................................................... 60

Figure 26 – Deployment Manager: Main Page .............................................................................. 61

Figure 27 – Deployment Manager: Default Platform Provider Preferences ................................... 62

Figure 28 – Deployment Manager: Platform Provider Preferences for SE ..................................... 62

Figure 29 – Deployment Manager: New Cloud Node creation form ............................................... 63

Figure 30 – Agent: Main Page....................................................................................................... 64



List of tables

Table 1: Reported bugs and requirements of the Connectivity Service back-end SE .................... 18

Table 2: New interfaces of the Connectivity Service back-end SE ................................................ 19

Table 3: Old Specified Interfaces of the Connectivity Service back-end SE .................................. 20

Table 4: Reported bugs and requirements of the Event Service SE .............................................. 22

Table 5: Old Specified Interfaces of the Event Service SE ............................................................ 23

Table 6: Reported bugs and requirements of the Targeting and Profiling SE ................................ 25

Table 7: New interfaces of the Targeting and Profiling SE ............................................................ 25

Table 8: Old Specified Interfaces of the Targeting and Profiling SE .............................................. 25

Table 9: New requirements of the Security and Privacy IAC ......................................................... 28

Table 10: New interfaces/operations of the Security and Privacy IAC ........................................... 28

Table 11: Old Specified Interfaces/Operations of the Security and Privacy IAC ............................ 29

Table 12: Old Specified Interfaces of the Mediation Service Enabler ............................................ 31

Table 13: Reported bugs and requirements of the Device Management SE ................................. 39

Table 14: Old Specified Interfaces of the Real-Time Communication SE ...................................... 42

Table 15: Reported requirements of the Monitoring SE ................................................................. 44

Table 16: New interfaces of the Monitoring SE ............................................................................. 45

Table 17: Old Specified Interfaces of the Monitoring SE ............................................................... 46

Table 18 – FI-PPP Phase3 SMEs: Accounts Creation Status ....................................................... 74

Table 19 - Catalogue: Subscriptions Administration Area .............................................................. 75

Table 20 – IssueTracker: issues related to the Catalogue ............................................................. 76



Abbreviations

ABAC Attribute Based Access Control

AES Advanced Encryption Standard

API Application Programming Interface

ASN.1 Abstract Syntax Notation One

ATNA Audit Trail and Node Authentication

BPPC Basic Patient Privacy Consents

CEP Complex Event Processing

CIMI Cloud Infrastructure Management Interface

CMP Cloud Management Platform

CPU Central Processing Unit

DC Data Center

DCRM Data Center Resource Manager

DEN Document Encryption

DM Device Management

DNS Domain Naming Server

EPC Evolved Packet Core

ESP Enterprise Service Bus

ETSI European Telecommunications Standards Institute

FBB Functional Building Block

GCP Global Customer Platform

GE Generic Enabler

GUI Graphical User Interface

IaaS Infrastructure as a Service

IdM Identity Management

IHE Integrating the Healthcare Enterprise

LWM2M Lightweight M2M

KPI Key Performance Indicators



M2M Machine to Machine

NaaS Network as a Service

NGSI Next generation Services Interface

NTP Network Time Protocol

OAuth Open Authorization

OF Open Flow

OMA Open Mobile Alliance

ORM Object Relational Mapping

OTT Over The Top

PaaS Platform as a Service

PAP Policy Administration Point

PCRF Policy and Charging Rules Function

PDP Policy Decision Point

PKI Public Key Infrastructure

POP Point Of Presence

QoS Quality Of Service

ReSTFul Representational State Transfer

RTC Real-Time Communication

SaaS Software as as Service

SAML Security Assertion Markup Language

SCIM System for Cross-Domain Identity Management

SDC Software Deployment Configuration

SE Specific Enabler

SIS Secure Internet Service

SLA Service Level Agreement

SLO Service Level Objective

SM Service Management

SPP Service Provider Platform



SSH Secure Shell

SSO Single Sign On

STUN Session Traversal Utilities for NAT

TLS Transport Layer Security

TSL Trust Service Status List

TURN Traversal Using Relays around NAT

UDP User Datagram Protocol

VDC Virtual Data Center

VM Virtual machine

VOIP Voice Over IP

VPN Virtual Private network

XACML eXtensible Access Control Markup Language



Definitions

FI-STAR SE specification

The specification of a FI-STAR Platform software module. Specification requires the definition of an API and of an internal design.

Provided Interface Set of functionalities provided by a software module to an external actor.

Required Interface Set of functionalities requested by a software module to an external software module.

Interaction view Graphical representation of the external modules with which a software module interact with exchange of information.

Application module In the context of this document, application module is a specific part of a system component build leveraging the FI-STAR Platform Module (i.e. the FI-STAR SE)

Graphical User Interface (GUI)

Graphical User Interface (GUI) is a type of external interface that allows users to interact with the application through graphical icons and other visual elements (as opposed to text-based interactions or command line interfaces). It is intended for use by human users.

Application Programming Interface (API)

Application Programming Interface (API) is a type of external interface that supports interactions between the application and external systems (that is, non-human users).

Functional building block (FBB)

Functional building block is a group of one or several functionalities that belong together (in terms of similar design and/or implementation character, role in the solution, etc.). It is a synonym for an application module.



Introduction

Objectives of this document

The main objective of deliverable D2.3 is to provide a report about the second cycle of the development activity of the FI-STAR Back-End Platform components. Such development took care from one side to implement that part of the specification, delivered in D2.1, but not yet covered by the ALPHA development cycle and, on the other, to cover new requirements coming from the issue tracker.

A further objective is to provide a report about the evolution of the Catalogue to support the access to the enablers, by the Application Providers, trying to fulfil their need of a better control of the private cloud access and of an automatic shipment modality. Details are also provided about the Catalogue usage experience of all the actors during this second phase (similarly to what already made in D2.2).

Specifications of this document

Deliverable D2.3 was completed by mid-February 2015 (M23). The actual delivery date is aligned with the planned one by DoW.

The deliverable D2.3 is based on the achievements and outcomes of tasks 2.3 and 2.4 and the implementation activates performed in the period M16-M22. Scope and content of the document are aligned with the definitions and relevant sections of the Description of Work (new DoW contained in the amendment request).

Deliverable structure

The present document consists of two major parts.

Part A – Development Activity Report, describes the development activity of the FI-STAR Back-End Platform SEs by focusing on organisational and management aspects and on the details of the development step. In particular, for each SE is provided an overview section, a table showing the implementation advancement status, for each interface provided in the specifications, and a final report about the FI-WARE technology adoption degree.

Part B – FI-STAR Platform Access Support, describes the offered support to access the FI-STAR Platform. In particular the Section 2 covers the Catalogue system by focusing, in Section 2.1, on the requirements specification (use cases and actors are described in Section 2.1.1 and Section 2.2.2). In Section 2.2, instead, focus is on the design with particular attention to the graphical interface definition (in Section 2.2.1). Finally Section 2.3 takes care to report the experiences and the implemented activities executed by each expected actors, by interacting with the Catalogue itself. Finally Section 3 and Section 4 provide a description of the environments, adopted within the FI-STAR project, as Reference Cloud Environment for the platform deployment.

References present the list of referenced sources.



Part A – FI-STAR Back-End Platform: Development Report

The Part A will give status report of the implementation activities executed in T2.3 during the Beta phase period (i.e. from July 2014 to December 2015). In addition, this section will provide the description of the application that has been recently developed as a joint activity between WP2 and WP3 with the aim of evaluating the interworking of most specific enablers in the front-end and back-end.



1 Implementation Activities

The development activities carried out by WP2 are covering the implementation of a set of Specific Enablers (SE), which may rely on FI-Ware GEs such as Event Service or are loosely de-coupled from FI-Ware GEs such as the Real-time communication service SE. The implementation of the required service modules in the back-end is going to be achieved within a two one-year-spiral-model prototype cycle based on the design specifications delivered by task 2.2.

The implementation activities were carried out in two phases: Alpha and Beta. Those were specified and aligned with the entire project plan and the other working packages, particularly WP3 and WP4. The Alpha phase lasted from mid of Feb/M11 until June/M15 2014. The Beta phase started in Aug/M16 and ended in Dec/M20.

In the Alpha phase, all SEs released the first implementation with a set of supported interfaces (up to 60%) according to the design and specification deliverable D2.1. In the Beta phase, non-implemented interfaces are completed. In addition, SE users have the ability to report bugs and submit new functionalities that are needed through the catalogue, as explained in part B of this deliverable. Based on this information, the SE owner is able to: track reported bugs, solve them, and decide which requirements will be implemented according to the implementation plan and required effort.

In order to validate the interworking capabilities of several SEs on the front-end and back-end, WP2 and WP3 team developed an end-to-end application. The application covers few sensors connected to an Android application through a set of front-end SEs and the collected data is sent to the back-end SEs and rendered web-based application in real-time. The implementation was presented and discussed with all FI-STAR partners in an interactive workshop during the 7th plenary meeting in Rome. The meeting’s purpose was to provide to all FI-STAR developers, a “hands-on” training on the use of various FI-STAR SEs in an end-to-end scenario.

The project analysis showed progress in the implementation. Status was (and continues to be) monitored via the project-level-information documented in the wiki pages. However, the SE owners keep maintaining the latest version of the SE implementation in FI-STAR catalogue. The development activities are going to last until the end of 2014.

The following results were achieved:

The implementation of all SEs is available for all FI-STAR partners/users in FI-STAR catalogue.

The implementation follows the plan defined in the wiki page: http://wiki.FI-STAR.eu/wiki/Beta_implementation_plan.

Development Plans are document by SE. The summary of all SE implementation status and responsible partners is available in the wiki page: http://wiki.FI-STAR.eu/wiki/Development_Plans#FI-STAR_Specific_Enablers_-_Phase_Beta.C2.A0

SE associated wiki page includes a page for each SE and covers four subsections: new requirements, reported bugs, new identified interfaces, and old designed interfaces, which are not implemented in the Alpha phase.

A demo that shows the interworking across different SEs on the front-end and back-end, including two application interfaces in both front-end (patient device) and on the top of the back-end

Each SE supports a set of interfaces and operations that can be validated by other working packages such as WP4, WP5 and WP6.

Figure 1 gives an overview of most of FI-STAR SEs on the front-end and back-end platform. The figure illustrates a potential deployment scenario, which has been validated by means of two applications developed jointly by the WP2 and the WP3 team. The demo focuses on patient monitoring application, where a patient requires observation of his/her health status by means of measured heartbeats. Therefore, the front-end application first renders the collected data to the patient locally on his smart mobile phone and simultaneously sent periodically to the FI-STAR infrastructure. The back-end application retrieves the data from the back-end SE (i.e. the Event Service), where a doctor can track patient heart rate in a real-time through a web-browser. The

http://wiki.fi-star.eu/wiki/Beta_implementation_plan

http://wiki.fi-star.eu/wiki/Beta_implementation_plan

http://wiki.fi-star.eu/wiki/Development_Plans#FI-STAR_Specific_Enablers_-_Phase_Beta.C2.A0

http://wiki.fi-star.eu/wiki/Development_Plans#FI-STAR_Specific_Enablers_-_Phase_Beta.C2.A0



reference implementation of both applications and description are available for all FI-STAR partners. With this regard, an interactive workshop for all FI-STAR partners has been conducted during the 7th plenary meeting.

Figure 1: FI-STAR Functional SEs Architecture

The interfaces between FI-STAR SEs are listed as following:

NGSI-9 and 10 are a set of interface specifications defined by OMA (Open Mobile Alliance) and adapted by FI-WARE GEs specification [19].

ETSI M2M is a set of specifications defined by ETSI as a middleware layer between a set of service capabilities and M2M applications, which both can be deployed in the front-end and back-end [20 – 22]

ICE-STUN is a specification defined by IETF in RFC 5245 to allow the client (e.g. a VoIP or WebRTC agent) to resolve its IP address behind the NAT [23 – 24]

OCSP (Online Certificate Status Protocol) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 [25]

The following subsections will give detailed information of the recent implemented interfaces. In case the SE uses a FI-Ware GE, the associated FI-Ware GE version is going to be listed.

FI-STARBack-EndFI-STARFront-End

Connec vityService

SensorDataCollec onService

No fica onService

LocalDataProcessing

Connec vityService

LocalDataStorage

Applica onReal- me

Communica on

Targe ng&profil

i

ng

EventService

DeviceManagement

Privacy&Security

Applica on

ETSIM2MOMALWDMNGSI-9/10ICE-STUN

ETSIM2M

NGSI-9/10

NGSI-9/10

NGSI-9/10 NGSI-9/10

NGSI-9/10

OCSPOCSPICE-STUN

ETSIM2MOMALWDM

Targe ng&profil

i

ng

LegacyEHR



1.1 Connectivity Service Back-End

The connectivity Service Back-End provides a secure connection between the FI-STAR Front-End and back-end service enablers based on CoAP, HTTPs and CoAP-DTLS. Furthermore, it allows applications to trigger the mobile core for resource allocation or retrieve information about the current connectivity status of the mobile device.

1.1.1 Reported bugs and requirements

The following table listed all bugs and submitted new requirements:

ID Summary Status Category Version Reporter Real Name

29 How to configure the SE correctly?

RESOLVED Support Request

ALPHA WP4_APP_DEV_NORWAY

20 Connectivity Service (BE) instance access request for RTC

SE owner


ALPHA REAL_TIME_COMMUNICATION_SERVICE_OWNER

30 Can't find openmtc-ngsi package RESOLVED Bug Report


78 Including communication from the Connectivity Service BE to

the FE

RESOLVED Improvement

Request

ALPHA WP4_APP_DEV_SPAIN

84 Allow integration with the Publish/ Subscribe Context

Broker GE

CONFIRMED Improvement

Request

BETA WP4_APP_DEV_SPAIN

45 web GUI for visualizing the data RESOLVED Improvement

Request

BETA WP4_APP_DEV_ROMANIA

55 pyxb 1.2.3 require; is not mentioned in documentation

RESOLVED Bug Report


79 HTTP Error 400: BAD REQUEST when trying to connect to Event Service

IN PROGRESS

Support Request


87 Documentation mentions non-existing files

CONFIRMED Bug Report

BETA WP4_APP_DEV_NORWAY

47 Se services not available on RTC SE owner instance of

BCON (10.9.5.7.)


ALPHA WP4_APP_DEV_POLAND

Table 1: Reported bugs and requirements of the Connectivity Service back-end SE

We have solved 7 issues out of 10. Some of the issues required implementation improvement and lead to beta version, some related to documentation were fixed within 2 weeks at most.

1.1.2 New Interfaces

The following interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.



Interface/operation Description Beta candidate

Specified in FI-Ware GE

Implemented by FI-Ware GE

Comments

OTT_Interface create/start session for QoS allocation

POST request to create session, triggers EPC Rx session initiation. The payload should contain the information needed to create the session.

Yes Yes Yes

OTT_Interface delete session/stop session for QoS allocation

DELETE operation to delete a session that has been created.

Yes Yes Yes

OTT_Interface retrieve connectivity information from the EPC

GET operation to retrieve the information about the IP connection with the mobile device

Yes Yes Yes

OTT_Interface subscribe to QoS session info

POST operation to allow the PCRF to notify about any change in the status of the connection. The body of the operation request should include the notification address

Yes Yes No

OTT_interface modify QoS session

UPDATE operation to update the parameter of the session.

Yes Yes No

RTC SE – STUN request Retrieve the mapped (public) IP address (NAT address) and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) connections to remote hosts

Yes No No

Table 2: New interfaces of the Connectivity Service back-end SE

Detailed description of all OTT interfaces can be found in FI-STAR wikipage [15]. The objective of the OTT interface is to allow the applications to trigger QoS parameter over a mobile core following the 3GPP Evolved Packet Core (EPC).

In order to enable the OTT interface to trigger any QoS parameter (i.e. to execute all the operations of the OTT interface), the PCRF (Policy and Charging Resource Function), deployed in the EPC, has to have the Rx interface configured and with the peer associated with the Back End Connectivity SE.

For the RTC interfaces the STUN/TURN/ICE open source project from [23] can be installed.

1.1.3 Old Specified Interfaces

The following interfaces have been specified during the design phased, but implemented in the Beta phase:

Interface/operation Description Specified in FI-

Ware GE


Comments

Secure and Reliable Connection and Transport – Receive data

Receive Data operation to receive data over HTTPS and DTLS

No No Based on use case requirement defined in D2.1



Secure and Reliable Connection and Transport – Send data

Send Data operation to send data over HTTPS and DTLS

No No Based on use case requirement defined in D2.1

Mobility Management To send access network discovery and selection policies to the end device

Yes Yes Based on FI-WARE S3C CDI GE

Table 3: Old Specified Interfaces of the Connectivity Service back-end SE

1.1.4 FI-Ware GE specification

The Connectivity Back-End Service supports two secure communication channels based on HTTP and CoAP-DTLS. It allows triggering QoS parameters over 3GPP EPC through the Rx interface and following FI-Ware I2ND S3C-OTT specification. Furthermore, it provides interface to manage the mobility of the end devices following FI-Ware I2ND S3C-CDI specification. The Connectivity Back-End Service SE is composed of the following modules:

HTTP/HTTPs and CoAP/CoAPs Proxy: This module allows external components to transmit HTTP and CoAP messages between applications and user equipment over a secure channel. During the TLS or DTLS handshake, the Connectivity Service SE will require the CA certificate and validation of the UE certificate before application data can be sent by the UE. In this regard, it interconnects with the security and privacy SE to validate UE certificate. It allows infrastructure component (e.g. the Event SE) to register for certain selective data, which can be forwarded in event-based model. As this module is defined according to new requirements defined in FI-STAR, this module does not relay on FI-Ware GEs.

Figure 2: FI-STAR Connectivity Back-End Service and FI-Ware enabled components

NAT Traversal Server: This module allows the FI-STAR devices behind the NAT to be reachable from outside, especially for those applications that act as server e.g. WebRTC client.

FI-STA

RPla

orm

FI-W

AREPla

orm

Resourcemanagement

HTTP/HTTPsandCoAP/CoAP-DTLSproxy

Connec vityServiceBackend

S3C-OTT

EPC-PCRF

QoS

ETSIM2M

OMALWDM OCSP:Validatecer ficate

NGSI-9/10

NATTraversalServerICE-STUN AdminGUI



Resource Management: This module allows the application to push QoS requirements into the mobile core based on 3GPP Rx reference point exposed by the PCRF. For example, an application would like to improve the data transmission quality towards the end user and it will either send a policy to the end user to select another access network or it will use the current access network and enforce the QoS of the communication channel (bearer). The specification of this module follows Fi-Ware S3C EPC-OTT specification.

1.1.5 FI-Ware GE uptake

This SE is designed to be configurable in order to interact with the following components:

- FI-STAR front-end device follows ETSI M2M specification and OMA-Lightweight Device Management. The data is transmitted via HTTP and CoAP, HTTPs or CoAP-DTLS. These delivery capabilities are new features, which are not supported in FI-Ware GEs.

- FI-STAR back-end enabler exposing the FI-WARE NGSI Open RESTful API. Actually, the instances created within the FI-STAR Cloud Environment are proposed to interwork with the Event SE in order to communicate with the front-end users; nevertheless, it is possible to interwork with any component following the current specification.

- This SE forwards all device management messages to the Device Management SE. - This SE interworks with the Security and Privacy SE in order to validate the UE certificate. - This SE exposes the S3C-OTT interfaces through a new reference implementation as FI-

Ware I2ND S3C-OTT implementation has several restrictions and technical limitation. For further details, we recommend to read D2.2.

Although the software above can be used in isolation, it is very useful to consider its usage in conjunction with other FI-STAR enablers (Front-end Connectivity SE, Event SE, Security and Privacy Enabler and Device Management SE) to design more interesting applications. In such scenario the Back-end Connectivity SE mediates messages between the front-end SEs and the back-end SEs. The certificates used in the secure transmission can be generated with the Security and Privacy SE and configured/burned on the Connectivity Front-end SE.

1.2 Event Service

The Event Service SE is used by two parties, Event Sender and Event Receiver.

Event Sender: are system components that issue events in order to inform other system components of user interactions or system changes.

Currently identified Event Sender:

Real Time Human to Human Communication components: VOIP components, WebRTC components

Health Monitoring

Patient GUI

Front-End Notification Service (or Front-End Connector Service / Front-End Gateway)

Event Receiver: are system components that receive events in order to react on user interactions or changes in other parts of the system.

Currently identified Event Receiver:

Profiling/Targeting component interested in content-related events to learn patient interests and patient interaction events in general to provide inactivity monitoring and alarms

Local Data Processing and Decision Support Service interested in measurement events

User monitoring and analysis interested in user GUI interactions


The following table lists all bugs and submitted new requirements:




19 Access to Event Service at XIFI Berlin from TUC Questionnaire SE

RESOLVED Bug Report

ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER

66 Local instance availability RESOLVED Support Request

BETA WP4_APP_DEV_ENGLAND

13 Event Service instance access request for RTC SE owner.


BETA REAL_TIME_COMMUNICATION_SERVICE_OWNER

81 Event sink not notified properly upon updateContext



16 NGSI methods callback causes server error 500.



83 VPN problem with Event Service instance at Berlin node

RESOLVED Bug Report


18 queryContext method returns data for attributtes does not exists at Event Service SE

RESOLVED Bug Report


50 BEVE instance for RTC SE owner don't respond (10.9.5.3)


ALPHA WP4_APP_DEV_POLAND

12 Method to Request Access Token for EventService SE



76 Local instance availability RESOLVED New Feature Request

BETA WP4_APP_DEV_GERMANY

14 Compliance inconsistent with NGSI specification

RESOLVED Bug Report

ALPHA WP4_APP_DEV_ITALY

82 Question: for how long is context data stored in the Event Service?



17 Cross domain problem with JavaScript callbacks



Table 4: Reported bugs and requirements of the Event Service SE

All issues have been resolved during the ALPHA and BETA development phases.


No new interfaces have been determined as new interface, based on the recent requirements listed in the previous subsection.


The following interfaces have been specified during the design phased, but implemented in the Beta phased:

Name Description Covered by a FI-WARE GE

API

Implemented by a FI-WARE GE



Specification

int updateContext(event) update context entities

yes no

int queryContext(event) query context entities

yes no

int subscribeContext(String...) subscribe to context

yes no

int updateContextSubscription(String..) update context subscription

yes no

int unsubscribeContext(String...) unsubscribe to context

yes no

int registerContext(event) register context yes no

Table 5: Old Specified Interfaces of the Event Service SE


Figure 3: FI-STAR Event Service and FI-WARE enabled components

The Event Service enabler represents an application made of different software layers. As for the architecture above we have:

WEB APP module

This is a web application, which was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:

• Authentication Interfaces: Allow to configure OAuth 2.0 access mechanisms and the interaction with the Security and Privacy enabler

Management Interfaces

Authentication Interfaces

ContextBrokerGE

FI-STA

RPla

orm

FI-W

AREPla

orm

Secured

RestAPI

EventService

WebApp

Secured

RestA

PI

FI-WARE NGSI Open RESTful API

Event DB

Event Log

XMLRPC

API

XMLRPC

API

http://wiki.fi-star.eu/wiki/Event_Service#Related_FI-Ware_GEs








• Management Interfaces: Allow to manage events and to configure and enable the Context Broker GE

SECURE REST API module

This is a REST web service, packaged with the same WEB APP module, conceived to offer the following capabilities:

• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification

• Possibility to secure the API via OAuth 2.0 with the built-in mechanisms or via the Security and Privacy SE

All these capabilities are offered via REST interface. The full documentation of such REST interface is available in D2.1 and within the User and Programmers guide within the Documentation section.

XMLRPC API module

This is a XMLRPC based web service, packaged with the same WEB APP module in order to extend the FI-WARE NGSI Open RESTful API to allow an additional standardized way of interaction with the Context Broker GE.

All these modules are actually available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators. Access the Get Your SE area to proceed.


This enabler is designed to be configurable in order to interact with any enabler exposing the FI-WARE NGSI Open RESTful API. The instances created within the FI-STAR Cloud Environment, offered to the users, are created adopting the Orion Context Broker GE for publish/subscribe of events.

The presented architecture highlights how this enabler can interact with other enablers in a typical usage scenario. If the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Targeting and Profiling Enabler, Security and Privacy Enabler) to enrich the application with more features. In such scenario, the Event Service will notify the Targeting and Profiling enabler on new data, while the secure REST API configuration is done via the Security and Privacy enabler.

1.3 Targeting and Profiling Service

The Targeting and Profiling Service SE is used to target and profile patients based on events generated by the patients’ context, e.g. measurements or patient-triggered events. It is closely related to the Event Service SE and can be categorized as an Event Receiver. According to the Event Service SE specification, Event Receiver are system components that receive events in order to react on user interactions or changes in other parts of the system. The Profiling and Targeting component is interested in content-related events to learn patient interests and patient interaction events in general to provide inactivity monitoring and alarms and to monitor and analyse user GUI interactions.




74 Executable version requested

CONFIRMED New Feature Request

BETA WP4_APP_DEV_GERMANY

41 Enable setting of rules by rest service

CONFIRMED New Feature Request

ALPHA WP4_APP_DEV_ITALY



85 Receive events from Context Broker GE

CONFIRMED Improvement Request


Table 6: Reported bugs and requirements of the Targeting and Profiling SE

All issues and new feature request have been implemented during the BETA development phase.



Provided Interface

Operation Interfaces

Covered by

FIWARE API/

Implemented by FIWARE

GE

cep

addRule yes yes

deleteRule yes yes

updateRule yes yes

Table 7: New interfaces of the Targeting and Profiling SE



Interface/operation Description Specified in FI-Ware GE


Comments

Data analysis Interface(s) for Big Data analysis Yes Yes

Table 8: Old Specified Interfaces of the Targeting and Profiling SE




Figure 4 FI-STAR Targeting and Profiling service and FI-WARE enabled components

The Targeting and Profiling enabler represents an application made of different software layers. As for the architecture above we have:

WEB APP module

This is a web application that was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:

• Advanced Data Analysis Interfaces: Allowed to configure and enable the Big Data Analysis GE.

• Authentication Interfaces: Allowed to configure OAuth 2.0 access mechanisms and the interaction with the Security and Privacy enabler.

• Management Interfaces: Allowed to manage the CEP Rules, to configure and enable the Data Handling GE as well as the data model.

SECURE REST API module

This is a REST web service, packaged with the same WEB APP module, conceived to offer the following capabilities:

• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification.

• Possibility to secure the API via OAuth 2.0 with the built-in mechanisms or via the Security and Privacy SE.


Management Interfaces

Authentication Interfaces

Advanced Data Analysis Interfaces

DataHandlingGE

BigDataGE

FI-STA

RPla

orm

FI-W

AREPla

orm

Targe ng&

Profiling

WebApp

Secured

Rest

API

(viaOAuth2.0)

FI-WARE NGSI Open RESTful API

SecuredRest

API

(viaOAuth2.0)




This enabler is designed to be configurable to interact with any enabler exposing the FI-WARE Data Handling GE API. The instances created within the FI-STAR Cloud Environment for this enabler (that are offered to the user) are created adopting the Esper4FastData GE to process complex events.

This enabler also adopts the Big Data GE for big data analysis. The enabler comes with a built-in WebHDFS adapter that can be used with the Big Data GEi or any other enabler exposing the same APIs.

All these modules are available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators.

The presented architecture highlights also how this enabler can interact with other enablers in a typical usage scenario. In fact also if the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Event Service Enabler, Security and Privacy Enabler) to design a more complex and interesting application. In such scenario the Event Service will notify the Targeting and Profiling enabler on new data, while the secure REST API configuration is done via the Security and Privacy enabler.

1.4 Security and Privacy – Integrated Access Control

This Integrated Access Control enabler (IAC) provides RESTful APIs to be accessed by any consumers that require Authentication, Authorization and Audit Logging functionality. These APIs, on the one hand, leverage relevant security standards (e.g. OAuth2, XACML, SCIM, Syslog etc.) and FIWARE security technologies. On the other hand, several enhancements have been taken into account (e.g. the capability to support HL7 FHIR specific attributes, aligned with current interested standard works such as IHE IUA profiles) to adapt with the requirements from healthcare domain. The high level of the architecture and adopted standards are presented as follows:

Authentication (OAuth, OpenID Connect, SAML)

Authorization (OAuth, Fine-grained Access Control via XACML)

Audit Logging (HTTP + Syslog)

Provisioning: User and Role (SCIM), Access Policy (XACML)

Figure 5: High level architecture




There were no reported bugs. However, several requirements are identified and taken into account. The following table listed these new requirements:

Req. Nr.

Feature Description Type Beta candidate

1 Securing access to exposed APIs

Exposed APIs should be protected from unauthorized access.

Requirement Yes

2 Specific user attributes support

The IdM enabler needs to support healthcare specific attributes (e.g. care provider, emergency contact etc.). Such attributes are important in various use cases for user identification and authorization.

Requirement Yes

3 More APIs Some APIs are implemented and updated to better support application developers/consumers.

Requirement Yes

Table 9: New requirements of the Security and Privacy IAC

In order to protect all sensitive published APIs, the FI-WARE access control model is adopted and implemented. As a result, an OAuth access token at HTTP request header is required when accessing such APIs. Moreover, some HL7 FHIR user attributes are taken into account to support our use case requirements. Such attributes can be configured and activated when need. Some new and updated APIs are briefly described as follows. For the detail, please check our documents in the FI-STAR catalogue.


SCIM-related APIs are introduced in version Beta to manage user identity. To identify a user, a SCIM ID is utilized. Often such ID is not easy to remember when comparing with another unique user attribute like username. As a result we introduce an API allow accessing given user profile through username. Another similar API is for getting Group/Role information. On the other hand, to support patient emergency use case, a sensitive user attribute “emergency” has been specified and two APIs were implemented to manage such attribute.

Interface/ operation Description Specified in FI-Ware GE

Implemented by FI-Ware

GE

GET /Users/username Return detail information about the given user by username

No No

GET /Users/<username>/emergency

Return emergency status of given user

No No

PUT /Users/<username>/emergency

Update emergency status of given user

No No

GET /Groups/<name> Return detail information about the given group by username

No No

Table 10: New interfaces/operations of the Security and Privacy IAC


Additionally to the new APIs, some interfaces/operations have been updated in the Beta phased either to comply with FI-WARE API open specification (e.g. Authorization PDP GE) or to enhance their capabilities (e.g. audit logging APIs).



Interfaces/Operations Description Specified in FI-Ware GE


PUT /scim/Group/<groupid> Update membership information (e.g. add/remove a user from given group/role)

No No

POST /authz/domains/<domain>/pdp/authorize Return access control decision (Allow or Deny)

No No

POST /authz/domains/<domain>/pdp Return access control decision (Allow or Deny)

Yes Yes

GET /authz/domains/<domain>/pap/policySet Return all access policies

Yes Yes

POST /authz/domains/<domain>/pap/policySet Create new XACML access policy

Yes Yes

DELETE /authz/domains/<domain>/pap/policySet/<policyid>

Remove the given policy

Yes Yes

GET /authz/domains/<domain>/pap/policySet/<policyid>

Return detail information about given policy

Yes Yes

GET /log View log messages based on given criteria (e.g. date, keyword)

No No

GET /log/<userid> View log messages of given user

No No

Table 11: Old Specified Interfaces/Operations of the Security and Privacy IAC


The FI-STAR Security and Privacy IAC is compliant with the FIWARE GE architecture and took into account two GEs: IdM GE and Access Control GE (the new name is Authorization PDP), to provide centralized authentication and authorization service (adopting FI-WARE access control model). Moreover, it is worth to mention that this enabler adopts FI-WARE API Access Control model to protect its sensitive APIs.

1.4.5 FI-Ware GE reference implementation

The security and privacy SE has taken into account two FI-WARE GE open specifications: IdM GE and Authorization PDP GE. We have also investigated existing related FI-WARE implementations. Due to our specific requirements, the adopted IdM GEi needs to support several security standards such as OAuth2, OpenID Connect, SAML etc. and our specific user attributes as mentioned above. Several FI-WARE implementations can provide such functionalities like GCP IdM or DigitalSelf. However, at that point in time, we cannot make use of them because they only provide as service. In FI-STAR, the provided solutions must be deployable not only on cloud but also in customer



premise (e.g. hospital). There is one open source IdM named KeyRock that can fulfil part of our requirements, still several functionalities are missing such as the capabilities to support new healthcare specific attributes or the support identity federation standard SAML. We also contacted with FIWARE GE owners and such functionalities will not be available in upcoming releases and the only way is to modified the given source code. Our initial idea when designing our enabler is that it should be API-centric (our implementation should communicate with FIWARE GE through available APIs). As a result, we have selected a popular open source solution in our implementation: WSO2 Identity Server (version 4.6.0). Such solution provides functionalities of both FI-WARE IdM and Authorization PDP. However, as the architecture is API-centric, such functionality can be given by other implementations in the future.

Furthermore, with respect to the recommendation to increase a direct adoption of the FI-WARE GEs products we have recognized it and stressed the modularity design principle as much as possible also within the FI-STAR enablers. The Security & Privacy IAC architecture are now updated and will be implemented to be flexible enough in order to interact with any implementations of the IdM GE and Authorization PDP GE.

1.5 Mediation Service

The Mediation Services offers the possibility to create services to mediate messages, combining the available mediation tasks. In FISTAR, it allows to interact with legacy system in the health sector (existing eHR, existing hospital systems, etc.), including tasks and templates of services that fulfil the requirements aroused along the project.


No bugs aroused and no new requirement submitted.


No new interfaces.



Interface/operation

Description Specified in FI-

Ware GE


Comments

iemail

sendEmail. This operation is used to send an

email message

Input: Structure with data to be sent in email:

Subject, content, from, to, cc, user, password

Output: A boolean value to indicate the execution result

No No

iManagement

Operation: updateMediationTask. This is the

basic operation to manage operation tasks. if the

task does not exist is created if the task exists is

updated and if the task is empty is deleted

Input: The expected task to be updated

Output: Identification of the task or error code

Mediator GE

No

iEvents provided

Operation: registerContext. This operation is

used route the petition to the event service to

create the “context” or event for the notification

Input: The expected request body is an instance

No No



of registerContextRequest

Output: The expected response body is an

instance of registerContextResponse Interface

Operation: subscribeContext. This operation is

used to route the creation of a subscription for a

specific event of the notification


of subscribeContextRequest


instance of subscribeContextResponse

Operation: unsubscribeContext. This operation is

used to route the deletion of a subscription for a

specific event of the notification


of unsubscribeContextRequest

Output: The expected response body is an instance of unsubscribeContextResponse

event required

Operation: registerContext. This operation is

used to create the “context” or event for the

notification


of registerContextRequest


instance of registerContextResponse

Operation: updateContext. This operation is used

to update the value of the event of the notification


of updateContextRequest


instance of updateContextResponse

Operation: subscribeContext. This operation is

used to create a subscription for a specific event

of the notification


of subscribeContextRequest

Output: The expected response body is an instance of subscribeContextResponse

No No

iOauth

Operation validate token

Input: message request with token access

Output: message response with validation status

No No

Table 12: Old Specified Interfaces of the Mediation Service Enabler




Figure 6: FI-STAR Mediation Service and FI-Ware enabled components

Mediation Service enabler implements Mediator GE Open restful specification. These describe iManagement interfaces.

Other Interfaces are dedicated to the specific domain and represent the mediation services that satisfies requirement aroused during the FI-STAR project.

Our Mediation Services enabler really represents a whole application made of different software layers. As for the architecture above we have:

WEB APP module

This is a web application, which was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:

• Management Interfaces: Allow to manage mediation services and to configure and instantiate new mediation interfaces

Mediator Open RESTful specification compliant ENABLER

This is a REST web service, packaged with the same module, conceived to offer the following capabilities:

• Possibility to manage mediation services, using the available mediation tasks.

Mediation Services module

This is a REST web service, packaged with the same module, offering examples and templates of mediation services that fulfil requirements of the health domain aroused during FI-STAR project.

The package is conceived to offer templates and examples of preconfigured services with the following capabilities:

• Possibility to send an email message.

• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification.

• Possibility to secure the APIs via OAuth 2.0



• Possibility to mediate the message to SOAP, REST,

• Possibility to re-map the contents,

• Possibility to translate to and from HL7


All these modules will be available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators. Access the Get Your SE area to proceed.

Really the presented architecture highlights also how this enabler can interact with other enablers in a typical usage scenario. In fact also if the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Event Service Enabler, Target and profiling enabler, Security and privacy enabler) to design a more complex and interesting application. In such scenario our enabler interacts with the rest of the software using events managed by event services. Typically messages are mediated towards legacy systems (hospital system) and messages are secured with the interaction with Security and privacy.

It is designed to be able to receive messages directly from other modules in NGSI and JSON format (i.e. Target and profiling enabler)


Our enabler should have been built on top of Mediator GE, but this was discontinued. The last release did not include the forecasted Management APIs.

1.6 Health Questionnaire Service

Questionnaires are widely used in the healthcare sector. The Health Questionnaire SE allows to:

Create simple assessment (on-demand) and monitoring (periodicity based) questionnaires;

Schedule monitoring questionnaires;

Collect the results from the questionnaires;

(optionally) to store questionnaire models and results into the repository based on configuration options;

Access questionnaires logs (i.e. historical data) in the questionnaires are stored locally;

Keep audit trail (i.e. log of actions as read, accomplish, identifying the user that accesses the information and the accessed user information);

Publish (optional) new questionnaire context event into the Publish/Subscribe Context Broker GE and Event Service SE to be used by other components, based on configuration options.




60 The questionnaire schedule should include the reference to the telecare program in order to be able to define

different telecare programs

RESOLVED Bug Report ALPHA WP4_APP_DEV_SPAIN

62 Include new operations to get the list of pending questionnaires (status, health,

drug follow up and side effects questionnaires)

RESOLVED Improvement Request




10 Include a new operation to generate the schedule of the monitoring questionnaire based on their

periodicity, completion interval and collection time intervals.

RESOLVED New Feature Request


64 Include new operations to get the list of pending questionnaires for current

date-time



40 NGSI content type for Answers event is wrong


BETA WP4_APP_DEV_ITALY

72 Keep audit trail log RESOLVED New Feature Request


57 Update field types into de data base model in order to support DB

independence



80 Include integration with the Publish/ Subscribe Context Broker GE


BETA HEALTH_QUESTIONNAIRE_SERVICE_OWNER

61 Include new operations to access historical data



9 Include specific operations to get the questionnaire model and to save the

results of the assessment and monitoring questionnaires



63 Include new operation to get the total number of pending monitoring

questionnaires



11 Include a new operation to get the scheduled monitoring questionnaire



65 Include new operation to allow the professional to access the results of a

specific patient



56 Include a new field in the database RESOLVED Improvement Request


73 include operation to configure the SE RESOLVED Improvement Request


Table 13: Reported bugs and requirements of the Health Questionnaire SE

We have resolved all the issues within 2 weeks (i.e. average. time) from notice.


The following provided interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.



Provided Interface/operation

Description Beta candidate

Specified in FI-

Ware GE


GE

Comments

iQuestionnaireUI/ getQuestionnaireMonitoringScheduleNum

Gets the number of pending scheduled monitoring questionnaires (for current date time)

Yes Not applicable

Not applicable

Due to R7.2 (Issue 63)

iQuestionnaireUI/ getQuestionnaireStatusList

Gets the list of pending scheduled status monitoring questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireStatusList

Gets the list of pending scheduled status monitoring questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireHealthList

Gets the list of pending scheduled health status questionnaires (for current date time)

Yes Not applicable


iQuestionnaireUI/ getQuestionnaireDrugFollowUpList

Gets the list of pending scheduled drug follow up questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireDrugSideEffectsList

Gets the list of pending scheduled side effects questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getListQuestionnaireItemsStatusDrugFollowUp4User

Gets the list of status monitoring and drug follow up questionnaire items related to an user)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getListQuestionnaireItemsStatusDrugFollowUp4User

Gets the list of status monitoring questionnaire items related to an user)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getListQuestionnaireItemsDrugFollowUp4User

Gets the list of drug follow up questionnaire items related to an user)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireStatusDrugFollowUpFilter

Filters status monitoring questionnaires and drug follow up questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireStatusFilter

Filters status monitoring questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ Filters drug follow up Yes Not Not Due to



Provided Interface/operation


Specified in FI-

Ware GE


GE

Comments

getQuestionnaireDrugFollowUpFilter

questionnaires (for current date time)

applicable applicable R8.1 (Issue 61)

iQuestionnaireUI/ getQuestionnaireHealthFilter

Filters health monitoring questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireDrugSideEffectsFilter

Filters side effects questionnaires (for current date time)

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireModelWithResuts

Gets the log (stored information) of the selected questionnaire. Includes audit trail log

Yes Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireModelData

Gets the results of a specific patient. Includes audit trail log

Yes Not applicable

Not applicable


iQuestionnaireAdmin/ setQuestionnaireConfiguration

Sets SE configuration values Yes Not applicable

Not applicable

Due to R9.1 Issue (73)

iQuestionnaireAdmin/ getQuestionnaireConfiguration

Gets SE configuration value Yes Not applicable

Not applicable

Due to R9.1 Issue (73)

Table 14: New provided interfaces/operations of the Health Questionnaire SE

The following required interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.

Required Interface/operation




Comments

iEvents/ queryContext

To query the “context” or event for the notification (Context Broker GE)

Yes Not applicable

Not applicable


iEvents/ updateContext

To create/update the value of the event of the notification (Context Broker GE)

Yes Not applicable

Not applicable


Table 15: New required interfaces/operations of the Health Questionnaire SE


The following interfaces have been specified during the design phase or developed during the Alpha phase, but they have been updated or implemented in the Beta phase:





Comments

iQuestionnaireUI/ getQuestionnaireModel

Gets the model of a concrete questionnaire in a particular language, including audit trail log.

Not applicable

Not applicable

Included in Alpha and updated in Beta release due to R10.1 (Issue 72)

iQuestionnaireUI/ saveQuestionnaireModel

Saves the collected data from a questionnaire in data storage and/or publish to event service, including audit trail log.

Not applicable

Not applicable

Included in Alpha and updated in Beta release due to R10.1 (Issue 72); R2.16 (issue 40)

iQuestionnaireUI/ setQuestionnaireMonitoringSchedule

Executes the schedule of monitoring questionnaire (taking into account telecare program).

Not applicable

Not applicable


iQuestionnaireUI/ getQuestionnaireMonitoringSchedule

Gets a descriptive list of the monitoring questionnaires scheduled for a specific date interval and use (taking into account telecare program)

Not applicable

Not applicable


iQuestionnaireAdmin/ loadFile

Loads the questionnaire model from a file and stores it (local file at machine instance).

Not applicable

Not applicable

Included in Alpha and updated in Beta release due R2.14 (issue 56); R2.15 (Issue 57).

iQuestionnaireAdmin/ Load

Loads the questionnaire model from a file and stores it (file is included as a parameter).

Not applicable

Not applicable

New in Beta release. Simplifies questionnaire model loading and replaces dismissed administrative operations.

Table 16: Old Specified Interfaces of the Health Questionnaire SE that have been updated or developed in the Beta phase

Several administrative operations such as:

(1) setQuestionnaire ,

(2) updateQuestionnaire,

(3) deleteQuestionnaire,

(4) setQuestionnaireItem,

(5) updateQuestionnaireItem,

(6) deleteQuestionnaireItem,

(7) setQuestionnaireItemAnswerSet,

(8) updateQuestionnaireItemAnswerSet and

(9) deleteQuestionnaireItemAnswerSet) are dismissed due to work prioritisation.

New, not initially planned, operations and updates have been included in the Health Questionnaire during Alpha M2 and Beta to cover new improvements and features requests. The loadFile and



Load operations already allow loading questionnaire models into the database. The dismissed administrative interfaces only tried to provide another way to load the questionnaire model but do not provided new capabilities.

The following interfaces were specified during the design phase and developed during the Alpha phase, but they have been updated or implemented in the Beta phase:



GE

Comments

iAuthoriisation/ createUserToken

Set the valid user & token Not applicable Not applicable Developed in Alpha phase.

iAuthoriisation/ deleteUserToken

Delete user & token Not applicable Not applicable Developed in Alpha phase.

iAuthoriisation/ updateUserToken

Delete user & token Not applicable Not applicable Developed in Alpha phase.

iAuthoriisation/ getUserToken

Gets the User token Not applicable Not applicable Developed in Alpha phase.

uthoriisation/ getUserTokenLIst

Gets the list of valid user token

Not applicable Not applicable Developed in Alpha phase.

iQuestionnaireUI/ etQuestionnaireResult

Gets the results of a specific questionnaire in JSON format


iQuestionnaireUI/ getQuestionnaireResultXML

Gets the results of a specific questionnaire in XML format


Table 17: Old Specified Interfaces of the Health Questionnaire SE that have been developed in the Alpha phase and have not been changed


The Health Questionnaire SE is a completely new Specific Enabler coming from the analysed requirements. No FI-Ware specification has been adapted and possibly extended while the implementation of the Beta phased.


Not applicable. Refer to the above section.

1.7 Device Management

The Device Management service SE supports various management functions on the end devices. It allows the application or administrator to discover, configure and monitor the end devices. In order to meet FI-STAR requirements for support constrained devices, the Device Management SE follows the OMA Lightweight M2M Device Management (LW M2M DM) specification, which is based on CoAP protocol. Furthermore, it exposes ETSI M2M REST APIs (based HTTP) to the applications and admin GUIS.





Req. Nr.

Feature Description Type Requester Beta candidate

39 Change any Zephyr parameter from outside, using API

Is it possible to change any Zephyr parameter using API (i.e. to control Zephyr sensing's parameter from outside / Smartphone)

New Feature Request

FZI_SE_owner

Yes

Table 13: Reported bugs and requirements of the Device Management SE

This requirement was created for the front end Sensor Data Collection Service SE. This requirement was further generalized into Configuration management and Remote actuation for the Device Management SE to allow remote operation of the sensors and actuators. This request was fixed as beta delivery.


A Web GUI to display the registered user endpoints and their available eHealth devices is implemented. The web GUI allows selecting which devices to connect or disconnect and triggered from the SDCS Beta requirements.

The Device Management SE is extended for processing the Device Capability Management Object introduced by oneM2M as an extension to Lightweight M2M standard.

The Lightweight M2M standard is based on CoAP, an extension for supporting also web interface is be implemented.


Interface/operation Description Beta candidate

Specified in FI-

Ware GE


GE

Comments

Device Property Management – Discovery

The Discovery operation allows the user/admin to discover and retrieve all endpoints and devices.

Yes No No

Device Property Management – endable-device

The enable-device operation allows the user/admin to enable dedicated device.

Yes No No

Device Property Management – disable_device

The disable_device operation allows the user/admin to disable a dedicated device.

Yes No No

Device Property Management – enable_property

The enable- property operation allows the user/admin to enable dedicated property or certain device

Yes No No

Device Property Management – disable_property

The enable- property operation allows the user/admin to disable dedicated property or certain device, e.g. of such property: RemoteConfiguration

Yes No No



Device Connectivity retrieval

Monitor_connectivity operation allows the service provider to monitor the local connectivity of the mobile device.

Yes No No

Sensor Device information retrieval

Manufacturer, Serial Number, Model name, Attached sensing instruments (A sensor device can measure multiple phenomenon).

Yes No No Can include battery level, and firmware version, but the Protocol Adapter does not support them

Sensor supported commands retrieval

Expose the command list the sensor is supporting.

Yes Yes Yes

Sensor Connectivity retrieval

Monitor connectivity of a sensor to the mobile device.

Yes No No

Device Actuation Send a command to a Sensor attached to the end device.

Yes Yes Yes, not tested

Device Configuration

Allow an App to configure remotely a sensor connected to a mobile device.

Yes Yes Yes

Web GUI Web-based GUI to allow the user/admin to perform all perform all operation listed above.

Yes No No

Table 19: New interfaces of the Device Management SE


We focused mainly on the Alpha implementation on scalability of the SE as we did not have further interfaces to be implemented.




Figure 7: FI-STAR Device Management Service and FI-Ware enabled components

The specification of the Device Management SE service follows the FI-Ware IoT Configuration Management GE and the operations of the IoT Device Management GE, as depicted in Figure 7. To meet the requirements of FI-STAR concerning device constrains due to power and resources, we decided to follow the OMA Light-weight M2M device management specification based on CoAP for device management rather than ETSI M2M followed by FI-Ware IoT Device Management GE specification, which is based on HTTP. In spite of that, this SE exposes its functions to an admin interfaces following ETSI M2M specification. Furthermore, this SE extends FI-Ware specification with new operations listed in Table 20. The LWM2M protocol can be used for software and firmware update, lock & wipe mechanism to prevent further use after a device is stolen.

FI-STAR SE is aligned with ETSI M2M specification towards the application, while the FIWARE GE Back End Device Management relies on SensorML with HTTP as transport. On the other hand, OMA LW M2M specification is designed for constrained devices by saving energy though the use of CoAP as transport protocol instead of HTTP, which is used by the FIWARE GE. As the FI-WARE device management GE supports the ETSI M2M interface towards the device, it can theoretically use this SE to manage end devices, which support only OMA LW M2M.


We have tested both FI-Ware GEs, the back-end Device Management GE and the Configuration Management GE. Due to FI-STAR requirements and the evaluation results for using one or both GEs were not successful, we decided to implement the envisioned functionalities in one SE rather than in two separated components. The results of the evaluation have been explained in D2.2.

1.8 Real-time Communication Service

The Real Time Communication Service (H-H) (BE) SE offers services enabling audio-video conferencing session management capabilities according to the WebRTC protocol. In particular, for the FI-STAR project, this SE enables conducting online audio-video medical consultations and

FI-STA

RPla

orm

FI-W

AREPla

orm

DeviceManagement

DeviceManagementServer

AdminGUI

Configura onManagement

Configura onManagement

OMALightweightDMbasedonCoAP

DeviceManagement

NGSI-9/10NGSI-9

ETSIM2M

ETSIM2M

Connec vityMonitoring

Remoteactua on



remote supervised rehabilitation sessions. The main functionality of this SE is to provide signaling, presence, session management and monitoring infrastructure for WebRTC streaming clients (peers). The media streaming (audio, video) and front-end clients are a matter of a particular WebRTC implementation and are out of the scope of this FI-STAR back-end platform element. The objective of this SE is to provide a Back-End infrastructure for webRTC protocol.


There were no additional requirements issued for the Real-Time Communication Service.

The following table listed all submitted bugs:

Req. Nr.


1.1 Problems with parallel video sessions

Only one session at the time can be conducted for only two peers. Bug was not issued by Issue Tracking systems - direct email used. Bug is resolved. Appropriate changes introduced on both cloud FI-STAR environments.

Bug WP3 Leader

YES

Table 20: Reported bugs and requirements of the RTC SE


There was no need to provide new interfaces or methods due to no additional requirements issued for the Real-Time Communication Service.



Interface/operation

Description Specified in FI-Ware GE


PUT /admin/sessions/close-all

Close all active sessions without

interrupting on going video-conferences.

After this call users will not be able to join

previously created sessions.

No No

GET /admin/users List all registered users (active & inactive). No No

PUT /admin/block Restrict / allow access to the

SessionManager by user name. If a user

is blocked from accessing a video

session, all calls to /sessions?

user=[USER] will return an empty list. This

call will not interrupt on-going

videoconferences.

PUT

/admin/users/__[USER]__?active=__[true|

false]__

No No

GET /admin/status Return current status of the

SessionManager.

No No

Table 14: Old Specified Interfaces of the Real-Time Communication SE




The FI-STAR Real-Time Communication SE is a completely new Specific Enabler designed and implemented based on specific FI-STAR requirements. The FI-STAR Real-Time Communication SE does not relay on FI-WARE GE specification due to the fact that by the time it was designed no FI-WARE p2p video conferencing GE was not identified. However the concept of the advanced Stream Oriented GE available currently is similar to the capabilities offered Real-Time Communication and could be potentially merged with the Stream Oriented GE.


The Real-Time Communication SE implementation is a new software component. Currently, FI-WARE offers the Stream Oriented GE and its Kurento implementation offering similar capabilities to the Real-Time Communication SE (basing on WebRTC protocol, node.js web sockets and RESTful API). Real-Time Communication SE implementation in future can be potentially substituted by Stream Oriented GE or can be included extending its capabilities.

1.9 Time Service

The Time Service SE enables other modules to use it and to get accurate time for orchestrating events to be occurred, keep transaction integrity high and maintain authentication and logging features. To this purpose, the Time Service SE synchronizes with an official - source time information and makes time and date data available as a service. This time information is distributed over several stages within the FI-STAR Back-End Platform and offered upon request to other platform components. The Time Service SE provides a RESTFul API solution that uses a custom HTTP scheme to allow communication.




46 No documentation for img file Resolved Support Request


44 No documentation for img file Resolved Support Request

ALPHA WP5_APP_PROV_NORWAY

48 Should http://server/time-service/time be redirected to

time.php etc?

Resolved Support Request


Table 22: Reported bugs and requirements of the Time Service SE

We have resolved all the requests for support (3) and we have provided direct support, guidelines and training material in the FIWARE e-learning platform (a number of 3 out of 3 issues within 1 week from notice).


No new services have been developed.


No old services have to be developed.


We have not found any FI-Ware GE specification available to follow.




We have not found any FI-Ware GE implementation available to use.

1.10 Monitoring Service

The Monitoring Service SE provides monitoring information about the used resources as well as the deployed services to multiple stakeholders: administrators, end-users and other FI-STAR Back-End Platform components. It supports cross-layer monitoring from low-level infrastructure resources (physical and virtual) up to application level. In this prospective, several system related metrics, such as processor load, RAM consumption, network throughput and latency, as well as services specific parameters like availability, load, throughput, downtime and failure rate, are measured. It allows its user to define own customized (user-defined) metrics. Measurement data is provided on-demand through different interfaces.


There were no reported bugs. However several requirements in terms of supporting different kind of user roles are identified.

The following table listed these new requirements:

Req. Nr.


1.1 APIs should support tenant & app KPIs

list of KPIs/metrics related to monitoring the running tenants as well as the apps being developed needs to be measured and provided through the monitoring service SE

requirement

Technical Leader

Yes

Table 15: Reported requirements of the Monitoring SE



Interface/ operation




JSON-RPC API /

create

Create the following metrics through probes (python scripts) that needs to be done by the admin of the monitoring service SE:

No. of created tenants

List of tenants (their names)

No. of SEs per tenant = list of instances per tenant

Allocated no. of vCPU per tenants (aggregated item

of all SEs) (provided as well in graph that can be

shown through the Portal)

Allocated RAM per tenant (aggregated item of all

SEs) (provided as well in graph that can be shown

through the Portal)

Allocated hard disk space per tenant (aggregated

item of all SEs) (provided as well in graph that can

be shown through the Portal)

Used CPU user time per tenant (aggregated item of

all SEs) (provided as well in graph that can be shown

through the Portal)

Used Memory per tenant (aggregated item of all

SEs) (provided as well in graph that can be shown

Yes No No



through the Portal)

Used Bandwidth (aggregated item of all incoming

traffic on interfaces of all SEs) per tenant (provided

as well in graph that can be shown through the

Portal)

Time consumed to develop an App = operating time

of a tenant

Lines of code per App (this can be supported

through a script that I created to include any user-

defined, app-specific metric that is configured to

send a REST call for instance to github asking for

lines of code committed)

Log data probe (a python script that can be executed

either by an SE user or after rebooting the image if

the zabbix agent is already running, it can be

configured to provide the location of any log file

needed to be stored in the monitoring service SE)

No. of logins App (supported through log data probe

to log the data of the context broker and gunicom log

files in the event service SE)

JSON-RPC API / get

get<Metric_Name>

Retrieving information about the above listed metrics.

Yes No No

JSON-RPC API /delete

delete<Metric_Name>

Delete an existing metric of the above listed metrics.

Yes No No

JSON-RPC API /

update

update<Metric_Name>

Update an existing metric (the above listed metrics) with new measures

Yes No No

JSON-RPC API / exist

exist<Metric_Name>

Check whether an metric the above listed metrics exist

Yes No No

RESTfull API / get

get list of graph IDs per host in order then to browse

these from anywhere as long as you are

authenticated and authorised to get data. These

graphs represent measurement data of particular

KPIs that needed to be visualised and shown as

GUIs and probably integrated with the FI-STAR

provided portals. List of graphs of the supported

KPIs:

Allocated no. of vCPU per tenants

Allocated RAM per tenant

Allocated hard disk space per tenant

Used CPU user time per tenant

Used Memory per tenant

Used Bandwidth per tenant

CPU Load per SE

Memory consumption per SE

Network traffic on interfaces per SE

Swap memory per tenant

Yes No No

Table 16: New interfaces of the Monitoring SE




The following interfaces have been specified during the design phased, but implemented in the beta phased:

Interface Operation Description Specified in FI-Ware GE


JSON-RPC API & RESTful API

getNetworkLatency Provides the network latency between two machines

Yes No


getPacketLoss Provides the packet loss between two machines

Yes No


getServiceAvailability Provides information about the availability status of the deployed SEs and/or services

No No


getServiceLoad Provides information about the service load

No No


getServiceAccessLog Provides access log data of any service

No No

RESTful API getGraphs Provides list of supported graphs that shows the measures in form of graphs

No No

Table 17: Old Specified Interfaces of the Monitoring SE


The FI-STAR monitoring SE is compliant with the initial FIWARE Cloud Monitoring GE architecture based on Zabbix product. However, the GE’s API specification was preliminary based on TCloud specification. The specification was not positively evaluated by its users (e.g. FI-STAR and XIFI projects) as it does not fulfil their needs. This has been already reported in FI-STAR D2.1 and D2.2.

The developers of the FIWARE Cloud Monitoring GE who are also involved in the XIFI project decided to change the architecture as well as the specifications completely with the focus on multi-region, federation support as required by the XIFI project. The new FIWARE Monitoring GE is more complex and consists of several other FI-WARE GEs such as the Context Broker GE, BigData GE as well as NGSI Adapters and BigData connecters, etc. At the beginning of FI-STAR project, which is the same time in which XIFI project started, there was neither clear specification nor implementation ready.

FI-STAR is aware of all these changes as TUB which is developing the FI-STAR monitoring SE is also involved in XIFI project and closely working with the XIFI monitoring team.

Furthermore, the requirements driving the new FIWARE Monitoring GE are different that those of FI-STAR that are derived from FI-STAR use-cases (e.g. SEs/services/development oriented KPIs).

In this perspective, FI-STAR has started developing the monitoring SE. In addition to exposing JSPN-RPC it offers a RESTful API to be in line with the FIWARE technologies.


According to what discussed in Section 1.10.4, FI-STAR provides its implementation. Considering the work done in parallel to our implementation, the implementation of the new FIWARE Monitoring



GE offers the data in context format stored in the BigData GE. Although they also provide RESTful API specification focuses on federation aspects, there is no implementation available in the FIWARE catalogue yet.



Part B – FI-STAR Platform Access Support

The Part B will give evidence of the activities executed in T2.4 during the Beta phase period (i.e. from July 2014 to December 2015). Coherently with such task description, section 3 will give witness about how the different actors exploited the Catalogue (already described in D2.2) to accomplish their activities during this second phase. Section 2, instead, will describe the design and implementation activities which were needed to enable the automatic shipment and deployment by an Application Provider/Platform Provider in order to better support the software to data paradigm and, at same time, to evolve the Catalogue in the direction of a Marketplace.

It is worth to mention that, considering this document is an evolution of D2.2, it will be avoided to provide explanation on concepts already described there assuming the reader is aware about them.



2 Solution for an Automatic Shipment and Deployment

In this introduction some aspects not completely specified previously will be better explained. In particular a better explanation about the interaction between the Application Developer and the FI-STAR Catalogue and between the Application Developer and Application Provider is reported in the following Preliminary Concerns I section (Sec. 2.1). In Sec. 2.2 is described, instead, the solution designed and implemented, to improve the access of the Application Provider to the (Beta) FI-STAR enablers in order to offer a better support to the software to data paradigm.

2.1 Preliminary Concerns

The delivery model of the FI-STAR BE enablers follows the approach as service for development purposes. Then, as described in D2.2, the Application Developer accessing the GetYour SE Area

of an enabler will have the opportunity to submit a request in order to obtain his own instance available within the FI-STAR Cloud reference environment. Then he can proceed by integrating the related endpoint in his application modules.

In this respect, to speed up the integration process a “Development Web Platform” was made available to developers where they can directly manage their enablers instances, configure and integrate them in their own applications Such facility is accessible by requesting an account to the Berlin Cloud Manager directly.

It is important to mention that the enablers instances offered to the developers are conceived exclusively for development purposes. This

implies that when the Application Developer will interact with an Application Provider, in a business relationship, the application will not be directly executable within the Application Provider environment (or within the environment of one of his final customers).

For the reason just described, the Application Provider will have, in turn, to interact with the Catalogue, as detailed in the next sections, in order to submit a

subscription for the needed enablers. Such subscription will allow downloading the enablers VM files. In fact, coherently with the software to data paradigm, an (Health) Application Provider aims to obtain directly the software to deploy in his own private cloud environment or in that one’s of his final customers.

2.2 Application Provider: Platform Access

As reported in D2.2, the possibility of subscription for one or several enablers was already made available, to an Application Provider for the alpha release (from July 2014). Anyway the offered shipment options were, at that time, exclusively the “manual” and “via FI-STAR Cloud”.

It is worth to mention that, in the manual case, at the end of the subscription the Application Provider can download, from the Catalogue, the FI-STAR enablers VMs files and, then, proceed, again manually, to the deployment. With the second option, instead, the Application Provider delegates to the FI-STAR Cloud Manager the registration of his (or his customer) Cloud Node and the instantiation there of the enablers VMs (see Figure 8).



Figure 8 – The Catalogue: Subscription Area

Both the options were evaluated with respect to the dimensions considered more critical within the project: the automation degree and the (Private Cloud) access control.

Automation Degree Private Cloud Access Control

Manual Shipment

Exploit FI-STAR Cloud Platform

Automatic Shipment

Figure 9 – shipment modality evaluation results

Manual Shipment

AUTOMATION DEGREE: Low. No kind of automation is supported. The Application Provider is forced, once notified, to access the Catalogue to get the updated enabler VM file. Then he is forced, as well, to interact with the IaaS admin interface of the final customer (or of a trusted platform provider) to proceed with the deployment.

ACCESS CONTROL: High. The Application Provider has full control about which customer (private) IaaS or (trusted) platform provider IaaS to access for deployment.



Exploit FI-STA Cloud Platform

AUTOMATION DEGREE: Mid. Application Provider is not forced to manually download enabler VM file anymore. At the end of subscription process and at each update, the FI-STAR Cloud Manager will be notified in order to proceed with the instantiation. Anyway it is always up to him to manually interact with a IaaS GUI admin to proceed with the deployment

ACCESS CONTROL: Low. This option allows that the enabler (i) or are made available within the FI-STAR Cloud (ii) or are instantiated within a federated cloud node (for instance of the final customer). The first case is clearly a limit. In the second case the control about the federation and the instantiation itself is under the control of the FI-STAR Cloud Manager which could be something not desired.

For the reasons just described it was decided to introduce a new approach which allows to reach the best score on both the dimensions.

Automatic Shipment

AUTOMATION DEGREE: High. With this option are made (optionally) automatic both the enabler VM file shipment and also its deployment in the final cloud node.

ACCESS CONTROL: High. This option offers the possibility, for the Application Provider, to select the (trusted) Cloud Platform Provider also in the extreme case the Application Provider itself needs to have this role. In this way the enablers or are made available in the cloud of a trusted (Cloud) Platform Provider or the federation of the final customer cloud node and the enabler instantiation there is operated, automatically, by a trusted (Cloud) Platform Provider.

Beta Requirements

More detailed requirements related to the envisaged solution are reported below:

[R1] possibility, for the Application Provider, to take in charge the deployment action or to select an external (trusted) Platform Provider

[R2] possibility, for the Application Provider, to specify the system holding the Customers preferences

[R3] possibility to choose if to automate only the enabler VM downloading or also the deployment.

[R4] to check the subscription status for an enabler and to trigger an automatic download and (optionally) an automatic (re) deploy

[R5] to take into account specific customer configuration before proceeding with the (re) deployment (e.g. specified time slot for deployment\re deployment)



Figure 10 – Architecture to enable the automatic shipment

Architecture Description

The Agent Service component is installed within the Application Provider domain as part of a web application. It takes care to periodically check the status of the (SEs) subscriptions, submitted on the Catalogue, by the Application Provider. The communication\polling activity is secured by exploiting an access token obtained by interacting with an Oauth2.0 server (IdM KeyRock) during the initialization step. If a subscription status changed (e.g. new SE version is available, the subscription duration period is expired etc…) then this component will notify the Deployment Manager component which will take care to properly serve the updating requests.

The Configuration Manager is the component offering the functionalities to store and retrieve some Customer preferences. Actually this component holds the preferences related to the Geographic Constraints (affecting all the SEs involved by the health applications of this Customer) and the Deployment Configuration associable to each single SE. Both these information will be made available within a Deployment Option object but new Customer constraints can be easily added (see Figure 11 and Figure 12). Within the Geographic Constraints it is possible to specify if the Customer wish to use its own cloud node to host his applications SEs (LOCAL option) or, instead, if he accepts to rely on the (Cloud) Platform Provider infrastructure. In this last case he can specify\impose, anyway, the (Cloud) Platform Provider has to use exclusively the cloud node located in the country of the Customer (NATION option) or can use whatever (cloud) nodes (EUROPE option1). Synthetically the Geographic Constraints capture the Customers preferences related to “where” the deployment has to happen. Within the Deployment Configuration, instead, the Customer can indicate its preferences related to “how” and “when” such deployment should occur. In fact he can choose only to be notified (NOTIFY option) when a deployment action should be performed (no automatic action) or he can enable a full automatic deployment (AUTOMATIC option) or both (AUTOMATIC&NOTIFY option). In the last two cases the Customer can also specify the time slot when the deployment should be (automatically) performed.

It is worth to mention that in principle an Application Provider could already use a separate system to hold his Customer preferences. For this reason this design document constraints only the interfaces exposed\required by this component and the data model, but the web application, offered to the Application Provider, can be configured also to use an external Configuration Manager (as long as it is compliant with such specification).

1 in order to allow the best performance of an health application also in case of mobility of the final consumer

(e.g. Doctors).



The Deployment Manager is the component which, notified by the Agent, takes care, concretely, to execute the deployment\undeployment of the SEs VMs as consequence of new subscriptions status. For instance if for a SE the subscription policy is of type “Always updated” and a new version for such SE is uploaded within the Catalogue, such module will retrieve, from the Configuration Manager the needed Deployment Options in order to proceed. The way such deployment will take place depends by the information contained within the Deployment Options and already described above. The Deployment Manager could use its own Deployment Configuration for the specific enablers, in case they were not specified by the Customer.

In principle an Application Provider could delegate to third trusted (cloud) Platform Provider the deployment task. For this reason this design document constraints only the interfaces exposed\required by this component and the data model, but the web application offered to the Application Provider, can be configured also to use an external Deployment Manager.

Figure 11 – Data Model: Overview

Figure 12 – Data Model: Deployment Options detail

2.3 Design details

Catalogue Service

Provided interface IOAuth operations:



getUser(accessToken:String):User

createToken(email:String, password:String): String

Provided interface ISubscriptions operations:

subscriptionsByToken(token: String ): List<Subscription>

o This operation allows to retrieve the Subscriptions of an Application Provider identified by an Oauth access token. In details it checks the access token against the IdM-KeyRock in order to retrieve protected information of the Application Provider used to retrieve and return his subscriptions.

Agent Service

Provided interface IAgentGUI:

The Agent provides a WebGUI to manages the agent activity and to monitor the application provider’s subscriptions.

Requested interface IDeployerServiceGUI.

Requested interface IConfigurationManagerGUI.

Requested interface IOAuth operations:

getUser(accessToken:String):User

createToken(email:String, password:String): String

Configuration Manager Service

Provided interface IConfigurationManagerGUI:

The configuration manager provides a WebGUI to allow to configure some customer preferences that will be mapped into CustomerConstraint and DeploymentConfiguration objects which compose, in turn, the DeploymentOptions. Such DeploymentOptions will be accessible programmatically (see IConfiguration interface).

Provided interface IConfiguration operations:

getDeploymentOptionsBySE(SEName:String): List <DeploymentOption>

o This operation allows to retrieve the DeploymentOption of the specified SE. Considering the SE could be involved in applications for several customers this method returns a list of such options (one for each customer). If the Customer did not set the DeploymentConfiguration for a SE, the one set by the Platform Provider is returned within the DeploimentOption (@see DeploymentOption for details).

setKeyConstraintToCustomer(customerName:String, publickey:String, privatekey: String): List <DeploymentOption>

o This operation allows to set the public/private key associated to the customer’s VMs. Such information are made available within the DploymentOption (@see getDeploymentOptionsBySE (SEName: String))

Deployment Manager Service

Provided interface IDeployerServiceGUI:

The Deployer Service provides a WebGUI allowing the (Cloud) Platform Provider (i) to configure his preference (DeploymentOption) and (ii) to define the cloud nodes of his own cloud environment.

Provided interface INotification operations:

notifyNewSpecificEnabler(vminfo: VmInfo, typeOfNotification: ETypeOfNotification, confManager: URI) :DeploymentStatus

o This operation allows the Deployer to be notified each time a SE Virtual Machine, linked to Application Provider's Subscriptions, is changed. The typeOfNotification parameter indicates



if the notification is to trigger an update of a VM or is due to an expired subscription. In first case this method will check the cloud's status and updated/deploy the new vm using also the customer preferences coming from Configuration Manager. In the second case it will undeploy all the VM instances.

2.3.1 Details about the Human Machine Interaction Design

In this section some screenshots of the user interfaces to support the final users in accomplishing the activities expected into requirements will be presented. It is not a complete survey for the sake of simplicity but it will cover the more meaningful user interactions.

- Agent Web Application: download and initialization

After the Application Provider had subscripted some SEs (see sec. 2.2.1 D2.2 for details) the catalogue lets him download the Agent Web Application (see Figure 13).

Figure 13 – Catalogue Agent: download window

It will be deployed within the Application Provider trusted domain and, during its first start up, a Wizard will support the installation process (see Figure 14). Just after the Wizard has been started, some initialization actions will be transparently executed (e.g. Data Base set up) (see Figure 15).

Figure 14 - Catalogue Agent Installation Wizard



Figure 15 – Preliminary initialization actions

Before proceeding with the Wizard steps, it is needed the Application Provider authorises the agent to access some of his information hold in the catalogue. It was decided, for this purpose, to rely on the Oauth 2.0 protocol and, then, the FI-WARE IdM GE – KeyRock has been integrated within the Catalogue service to provide authorization capabilities.

Such a way the wizard, during the initialization step, will forward the Application Provider to the Catalogue authorization GUI in order to allow him: (i) to authenticate himself and (ii) to authorise the Agent for the access. The authorization step ends with the obtainment of an access token which will be used, from this moment, as unique information to trust and authenticate all the Agent’s requests to the Catalogue.

Figure 16 - Catalogue Authorisation GUI – User Authentication

Figure 17 - Catalogue Authorisation GUI – Agent Application Authorisation



The wizard continues and shows the page for the specification of the Configuration Manager system end-point. The Configuration Manager is the component allowing to express the Customer preferences and the wizard let the Application Provider to choose if to rely on an external implementation or on a default one, provided along with the Agent application (see requirement [R2]). See Figure 18 for details.

As for requirement [R1] the wizard allows the Application Provider, also to choose if to take in charge by himself the deployment action (the two roles of Application Provider and Cloud Platform Provider collapse in this case) or to select an external deployment service offered by a (trusted) Cloud Platform Provider (see Figure 19).

Figure 18 – Agent Installation STEP 1: external or internal Configuration Manager.

Figure 19 - Agent Installation STEP 2: external or internal Deployment Service.

When the wizard ends the user has the possibility to access the GUI related to the Agent or that one of the Configuration Manager or of the Deployment Manager. (see Figure 20).



Figure 20 - Agent Installation STEP 3: Wizard completed

- Configuration Manager

Configuration Manager's GUI allows the Application Provider to manage the customers who has bought his health applications.

In particular the GUI offers the possibility to add a new customer, by clicking the Add Customer button from the main page (see Figure 21), and to specify the application(s) he has bought (see Figure 22).

Figure 21 – Configuration Manager Main Page

For the Customer, just created, the Application Provider can edit some preferences. Actually the system supports, as described above, the possibility (i) to specify geographic constraints and (ii) to indicate preferences about the deployment modality.



Figure 22 – Configuration Manager: New Customer Form

About the first type of preference (see Figure 23), the Application Provider, selecting the Edit Geographic Constraint button, can “constrain”, for the current customer, where the Deployment Manager will have to instantiate the VMs for all the enablers needed to the applications of that customer. In Figure 24 the three types of geographic constraint are showed:

Figure 23 – Configuration manager: User Preferences Section



Figure 24 – Configuration manager: Geographic Constraints

- Europe: in this case the Customer has neither an own (cloud) node nor a favourite nation. So the final (cloud) node which will be used will depend, exclusively, by the Deployment Manager implementation (based for example on a balance algorithm).

- Nation: in this case the Customer hasn't an own (cloud) node but the constraint forces the Deployment Manager to use the (cloud) node available in the Customer’s nation.

- Local: in this case the Customer desires to use his own (cloud) node. Then the form allows to insert the Customer's node endpoint and credential that the Deployment Manager will have to use to finalise the deployment action.

About the second type of preference, it is possible to define, for each specific enabler of a Customer (i.e. enablers required by the applications of that Customer), also a preference about the deployment modality (see requirement [R3]).

The Application Provider, by clicking on the button Add preference for a SE, can select a specific enabler and set if the Customer desires: (i) no automatic deployment but only to be notified (ii) a full automatic deployment (iii) a full automatic deployment and a notification. In the last two cases it is possible also to indicate the time slot, preferred by the Customer, to proceed with the automatic deployment.

Figure 25 – Configuration Manager: Deployment Preferences



Figure 25 shows the most complex case when, for the Customer (Ferrara Hospital in the example), it has been selected to send a notification via email and to automate the instantiation of new enabler VMs at the 03:00 P.M. of first Tuesday after February 14th. The expression power on the date lets user to define many different types of time preferences.

- Deployment Manager

Deployment Manager's GUI allows to define the (Cloud) Platform Provider preferences about where and when to instantiate the enablers VMs notified by agent.

In fact the main page of such GUI (see Figure 26) is subdivided in two areas: Platform Provider Preferences and Platform Provider Cloud nodes.

Figure 26 – Deployment Manager: Main Page

The Platform Provider Preferences section allows to specify the “default” Deployment Configuration by selecting the button Edit Default Platform Preferences. This configuration will be used to deploy all the enabler VMs in the case neither the Customer (see the previous section) or the Platform Provider (see below) provided specific preferences for those enablers.

The default platform preferences editing form allows to define, also in this case, the action type (notify, automatic, automatic and notify), the schedule time and the contact email address for the notification.

The Platform Provider can also override the global default preferences (valid for all the SEs) with a new one specific for each SE. He can do it simply by selecting the button Add Preferences for a SE. The editing form is the same as for the global case but with a field in addition where to indicate the SE for which the overriding preferences are submitted (see Figure 28).



Figure 27 – Deployment Manager: Default Platform Provider Preferences

Figure 28 – Deployment Manager: Platform Provider Preferences for SE

In conclusion the final DeploymentConfiguration that the deployment service of the (Cloud) Platform Provider will use is based on the following priority order:

1. Customer’s SE Preference

2. (Cloud) Platform Provider’s SE Preference

3. (Cloud) Platform Provider’s Default Preferences



The Platform provider cloud nodes section, instead, shows the cloud nodes that compose the platform provider’s cloud infrastructure. From this section the (Cloud) Platform Provider can add a new node by selecting the button add new node and filling the related creation form.

Such form allows to insert the country, where the new cloud node is located, the related endpoint and the credentials to access it.

Figure 29 – Deployment Manager: New Cloud Node creation form

It is worth to remember that the cloud nodes which form the cloud infrastructure of the Cloud Platform Provider will be used, for the deployment action, only if the Customer specified a Geographic Constraint of type EUROPE or NATIONAL. In the first case the deployment service will adopt an algorithm to balance the number of active VMs, among all the nodes configured in the system, in the second case, instead, the node available in the same nation of the Customer will be used.

If the Geographic Constraint is of type LOCAL, instead, the cloud node of the Customer will be automatically federated and used, by the deployment service, for the deployment action.

- Agent

The agent’s main page (see Figure 30) shows the subscriptions that the Application Provider activated on Catalogue (see section Specific Enabler Subscriptions Status).

In order to automatically check the status of such subscriptions and trigger appropriate actions in case of changes, the Application Provider has to select the button start polling. This action activates a polling process querying the catalogue service periodically. When changes are identified the Agent will notify the configured Deployment Manager about them.

For tracking and monitoring purposes a log area (see section Agent’s Log) shows the logs related to the subscriptions checking activity and to the feedbacks due to the deployment actions.



Figure 30 – Agent: Main Page



3 The Catalogue: Usage Experience Report

3.1 SE Owners report

In this section are reported, for each enabler, a summary of the information available within the Catalogue [16] to reflect the updates\new contents added within the period from July 2014 to January 2015 (i.e. Beta development phase). Such updates could have been finalised to improve the Documentation section to make it clearer or they could affect the release of further training material (e.g. audio\video courses uploaded within the FI-WARE e-learning platform [17]) or they could be finalised to update the Terms And Conditions section to better qualify the software availability, not only to FI-PPP partners, but also to External actors (i.e. when the project will end).

- Connectivity Service BE SE

Overview Documentation SW upload Terms And Conditions

The Connectivity Service SE is available in the catalogue as BETA release, last updated on 20-February-2014.

Contact details and more information are also available in the Catalogue

Documentation is given in the catalogue Overview and Documentation section of the SE for the BETA version. An additional Installation & User Development Guide has been produced and is also available

Software for the BETA version has been uploaded and is available for the download.

The SE can be requested as an instance at the Berlin node.

Copyright © 2014 FOKUS – All Rights Reserved

External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected]

FI-PPP: The Connectivity Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Device Management Service SE


The Device Management SE is available in the catalogue as BETA release, last updated on 20-Feb-2014.

Contact details and more information are also available in the Catalogue

Documentation is given in the catalogue Overview and Documentation section of the SE. An additional Installation & Admin. Guide, along with a User and Programmer Guide has been produced and is also available for this version.

Software is available for the download.

The SE can be requested as an instance at the Crete node.



FI-PPP: The Device Management Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Event Service SE Owner


The Event Service SE is available in the catalogue as BETA release, last updated on 30-January-2015. Contact details and more information are also available in the catalogue.

Documentation in the catalogue Overview and Documentation section has been improved during the Beta development period. Other than the already available User and Programmer Guide, also an audio\video course has been produced and uploaded within the FI-WARE e-learning

For the BETA version this enabler has been made available also for the download from the Get Your SE area. It remains, as well, the possibility to request this enabler as an instance at the Berlin and Crete cloud, always from the Get

Copyright © 2014 AGE – All Rights Reserved

Copyright © 2014 TUB – All Rights Reserved

External: The BETA version will be made available for external usage such a way: Web App and including REST/XMLRPC modules will be made available under the original BSD license. This SE incorporates the FI-WARE Context Broker Orion which is provided as open source under the AGPLv3 license, but can be used with and enabler exposing the FI-WARE NGSI Open RESTful API specification.

FI-PPP: The Event Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.

mailto:[email protected]






platform. It is reachable from the Catalogue as well (link)

Your SE area.

- Targeting & Profiling SE Owner


The Targeting & Profiling Service SE is available in the catalogue BETA release, last updated on 30-January-2015. Contact details and more information are also available in the catalogue.

Documentation, in the catalogue Overview and Documentation section, has been improved during the Beta development period. Other than the already available User and Programmer Guide, also an audio\video course has been produced and uploaded within the FI-WARE e-learning platform. It is reachable from the Catalogue as well (link)

For the BETA version this enabler has been made available also for the download from the Get Your SE area. It remains, as well, the possibility to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.

Copyright © 2014 AGE – All Rights Reserved

Copyright © 2014 TUB – All Rights Reserved

External: The BETA version will be made available for external usage such a way: Web App and including REST/XMLRPC modules will be made available under the original BSD license. This SE incorporates the FI-WARE Context Broker Orion which is provided as open source under the AGPLv3 license, but can be used with and enabler exposing the FI-WARE NGSI Open RESTful API specification.

FI-PPP: The Targeting & Profiling Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Monitoring SE Owner


The Monitoring Service SE is available in the catalogue as BETA release, last updated on 10-February-2015. Contact details and more information are also available in the catalogue

Documentation is given in the catalogue Overview and Documentation section for BETA version. An additional Installation & admin. guide, along with a User and Programmer Guide (for this version) have been produced and are also available in the catalogue.

The BETA version of the software has been uploaded into the catalogue and is available for installation (based on installation and administration guide).

Also for this version it is possible to request the enabler as an instance at the Crete and Berlin cloud node.

Copyright © 2014 - TUB. All Rights reserved.

External: The Monitoring Service SE is available for external use under Apache License Version 2.0.

FI-PPP: The Monitoring Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement

- Security & Privacy SE Owner (TUB)


Security & Privacy SE is available in the catalogue as BETA release, last updated on 30-Jan-2015. Contact details and more information are also available in the catalogue.

Documentation is given in the catalogue Overview and Documentation section of the SE.

Both User and Programmer Guide and Installation and Administration Guide are available as well for this version.

Actually the SE can be requested either as a service instance at the Berlin and Crete cloud nodes or as a downloadable Virtualbox image (for local deployment and testing).

A sample PHP web application is also provided for consumer as API illustration.


External: By the end of FI-STAR project, this will be released to external parties by the following open source Apache License 2.0 approach.

FI-PPP: The Security & Privacy SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Access details within the Get Your SE area.

- Security & Privacy SE Owner (ENU)


http://edu.fi-ware.org/course/view.php?id=105

http://edu.fi-ware.org/course/view.php?id=110



Security & Privacy SE is available in the catalogue as ALPHA M1 release, last updated on 25-June-2014. Contact details and more information are also available in the catalogue. The TSL SE provides HTTP REST APIs exposing ETSI TSL (Trust Service Status List) 102.231.

Documentation is given in the catalogue Overview and Documentation section of the SE. An additional Installation & admin. guide, along with a User and Programmer Guide has been produced and is also available in the catalogue.

Software has been uploaded into the catalogue and is available for download and installation (based on installation and administration guide).

The SE can be requested as an instance at the Crete and Berlin cloud node.

Copyright © 2014 - ENU. All Rights reserved.

External: The TSL SE is not available for external use at the moment.

FI-PPP: The TSL Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement

- Time Service SE Owner


The Time Service SE is specified here as a component that enables other modules to use it and to get accurate time for orchestrating events to be occurred and keep transaction integrity high

Documentation is included in the catalogue Overview and Documentation section of the SE. An additional Installation & admin. guide, along with a User and Programmer Guide has been produced and is also available in the catalogue.

Software has been uploaded into the catalogue and is available for download and installation (based on installation and administration guide).


Copyright © 2014 © TSI-TUC . All rights reserved.

External: The concrete licence is available as Open Source under the original MIT license.

This SE includes the NTP server which is available under the GNU General Public License (GPL).

FI-PPP: The Event Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

Good experience using the catalogue for:

a) Providing documentation and general descriptions of the SE

b) Uploading software in the catalogue

c) Interacting with the catalogue administrators regarding issues.

- Real Time Communication SE Owner


The Real Time Communication Service SE is available in the catalogue as BETA release, last updated on 13-Feb-2015. Contact details and more information are also available in the catalogue.

Documentation in a form two separate pdf documents (User and Programmer Guide, Installation & Administration Guide) has been updated in the catalogue for this new version.

It has been uploaded also a guide for a Web Application to use as client to test the RTC SE.

This SE has been uploaded, for the BETA version, into the catalogue and is available for download and installation on 13-Feb-2014.


Copyright © 2014 ITTI sp. z o.o. – All Rights Reserved

External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) in a form of closed-source application.

The Enabler is available for personal and non-commercial use after notifying the owner. For commercial or educational purposes, different Terms and Conditions apply. Please, contact via mail the owner of the specific enabler ([email protected]) to get more details and the enabler itself.

FI-PPP: The RTC Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Health Questionnaire Service SE Owner


The Health Questionnaire Service SE is available in the catalogue as BETA release, last updated on 05-

Documentation is included in the catalogue Overview and Documentation section of the SE. An updated User and Programmer Guide (for BETA version) has been provided. Also a zip containing code

No software has been uploaded to the catalogue yet for the BETA version.

Also for BETA version, the SE can

Copyright © 2014 © Tekniker. All Rights Reserved.

External: At the finalisation of the FI-STAR project the SE will be made available as open source. The concrete license is still under evaluation, further information to be provided



February-2015. Contact details and more information are also available in the catalogue.

samples\test (for BETA version) has been provided.

An audio video course on the FI-WARE e-learning platform is not yet available but is under preparation and will be uploaded soon.

be requested as an instance at the Crete and Berlin cloud node.

soon.

FI-PPP: The Health Questionnaire Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

Contact information for any inquires about licensing is provided.

- Mediation Service SE Owner


The Mediation Service SE is available in the catalogue as BETA release, by the end of February 2015. Contact details and more information are also available in the catalogue

Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide (for BETA version) has been produced and will be made also available in the catalogue by the end of February 2015.


The SE is based on WSO2 ESB. This should be installed following the instruction in the link provided in the catalogue.

Users can download from catalogue the user guide and templates to create required mediation tasks.

By the end of February 2015 it will be possible either to download the enabler or to submit a request for an instance at the Berlin\Crete nodes.

Copyright © 2014 CUP 2000 spa

Copyright © 2014 FUNDACION TEKNIKER

External: The Mediation Service Enabler will be made available for external use as free software under the L-GPL licence. The software is provided "as is" for all parties.

This SE make use of the WSO2 ESB which is distributed under the Apache Software License v2.0

FI-PPP: The Mediation Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Sensor Data Collection Service SE


The Sensor Data Collection Service SE is available in the catalogue as BETA release. Previous release are available as well

Contact details and more information are also available in the catalogue.

Documentation is given in the catalogue Overview and Documentation section of the SE. Code samples are provided to interact with the SDCS while a User and Programmer Guide and an Installation and Administration Guide are available as well in the Documentation area. The BETA version of such software and guides are going to be updated.

Software (BETA version) is available for the download as an APK binary for running on Android.

No possibility to have access as service.



FI-PPP: The Sensor Data Collection Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Local Data Processing Service SE


The Local Data Processing Service SE is available in the catalogue as BETA release, last updated on 10-February-2015.


Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide for the BETA version is going to be produced and uploaded in the catalogue

Software (BETA version) is available for the download as a native Android library (.jar)



External: The Local Data Processing Service SE is available for external use (i.e. out of FI-STAR and FI-PPP) as Open Source under the original BSD license

The SE includes the Esper for Android library, that is available under the GNU General Public License (GPL-2.0)

FI-PPP: The Local Data Processing Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.

- Notification Service SE




The Notification Service SE is available in the catalogue as BETA release, last updated on 02-Feb-2015.


Documentation (for BETA version) is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide (pdf file) is going to be uploaded within the Catalogue.

Software (BETA version) is available for the download as a native Android library (.jar).



External: The Notification Service SE is available for external use (i.e. out of FI-STAR and FI-PPP) as Open Source under the original BSD license and can be found here:

FI-PPP: The Notification Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.

- Connectivity Service SE


The Connectivity Service SE is available in the catalogue as BETA release, last updated on 10-Feb-2015.


Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide and an Installation & Admin. Guide have been produced and are also available in the catalogue

A code sample is provided as Android Studio Project

Software (BETA version) is available for the download (.apk)



External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected].

FI-PPP: The Connectivity Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.

- Local Data Storage Service SE


The Local Data Storage Service SE is available in the catalogue as BETA release, last updated on 10-Februaary-2014.


Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide for the BETA version has been produced and is going to be uploaded in the catalogue

Software (BETA version) is available for the download as a native Android library (.jar)



External: The Local Data Storage Service SE will be made available for external use under the original BSD license.

FI-PPP: The Local Data Storage Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.

- Motion Evaluation SE


The Motion Evaluation SE is available in the catalogue as BETA release, last updated on 04-February-2015.

Contact details and more information are also available in the catalogue, within the Overview area.

Documentation is given in the catalogue Overview and Documentation sections.

The User and Programmer Guide is already uploaded.


For the BETA version, this enabler is available for downloading from the Get Your SE area. It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.

Copyright © 2015 CERTH – All Rights Reserved

Copyright © 2015 DCU – All Rights Reserved

External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) by following an open source approach. In detail:

Motion Evaluation Specific Enabler will be made available under an open source license (Apache License 2.0).

It is worth to mention, anyway, that such software relies in turn on:

ZedGraph library (with license GNU Library or Lesser General Public License version 2.0 (LGPLv2))

NewtonSoft.Json library (MIT License (MIT))

(Optional)

FI-WARE GEi – Orion Context Broker (with license BSD)

FI-WARE GEi – Identity Management - KeyRock (open source



under the GNU Affero General Public License)

FI-PPP: The Motion Evaluation Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.

- Semantic Enricher SE


The Semantic Enricher SE is available in the catalogue as BETA release, last updated on 04-February-2015.



The User and Programmer Guide is already uploaded.

An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon.

For the BETA version, this enabler is available for downloading from the Get Your SE area.

Copyright © 2014 Nissatech Innovation Centre

External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) by following an open source approach. In detail:

Semantic Enricher Specific Enabler will be made available under GNU General Public License (GPL) (GPLv2).


- Joda-Time java library (with Apache 2.0 licence)

- Guava java library (with Apache 2.0 licence)

FI-PPP: The Motion Evaluation Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Terms and Conditions area.

- EHR SE


The EHR SE is available in the catalogue as BETA release, last updated on 04-February-2015.



The EHR Manual is already uploaded. Also some examples of Curl APIs call is are provided as well.

An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon.


It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.

Copyright © 2015 University of Cyprus

Copyright © 2015 InfoTEX Software Solutions LTD

External: The EHR SE layer has been developed by UCY and will be released to external parties (out of the FI-PPP and FI-STAR project) under an open source license (Apache License 2.0).

Furthermore such software depends from the following libraries which in turn are available under the following licenses:

- Hibernate ORM open source software: under the LGPL 2.1 or ASL 2.0 license.

- LCDA Tools: under the Ecliple license - v1.0

For commercial or educational purposes, different Terms and Conditions apply. Pease, contact via mail the owner of the specific enabler

FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area..

- Fall Risk Evaluation SE


The - Fall Risk Evaluation SE is available in the catalogue as BETA release, last updated on 13-February-2015.

Contact details and more information are


The Fall Risk Evaluation User Guide and Installation Guide


It is possible, as well, to request it as an service at the

Copyright © 2015 SingularLogic SA

External: The FRE enabler will be released to external parties (out of the FI-PPP and FI-STAR project) following an open source approach. In particular, the FRE SE will be made available under the Apache License 2.0.

The FRE SE relies on the:

- Orion Context Broker Publish / Subscribe GEi (AGPLv3



also available in the catalogue, within the Overview area.

are available as well while code samples are being prepared.

An audio video course, on the FI-WARE e-learning platform, is not yet available but it is under preparation and will be uploaded soon.

Berlin and Crete cloud node, always from the Get Your SE area.

license)

- Wirecloud GEi (AGPL v3 with a classpath-like exception allowing widgets and operators running onto Wirecloud to be licensed under any license without any restriction)

- The FRE SE interacts with the Identity Managment (KeyRock) GEi (GNU Affero General Public License) for identification purposes.

Furthermore the FRE SE includes the following:

- MySQL Server (GNU GPL v2)

- Apache (Apache License v2.0)

- Flask (BSD License)

- SQLAlchemy (MIT License)

FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area..

- PACS SE

Overview Documentation

SW upload Terms And Conditions

The PACs SE is available in the catalogue as BETA release, last updated on 09-February-2015. Contact details and more information are also available in the catalogue, within the Overview area.


The PACs Manual is not yet available but is under preparation and will be uploaded soon. An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon

For the BETA version, this enabler will be available for downloading from the Get Your SE area by the end of February 2015.

It will be possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.



External: PACs SE will be released to external parties (out of the FI-PPP and FI-STAR project) by following an MPL/GPL/LGPL triple license (similar to Mozilla) approach. In detail:

The PACs SE rest service code is developed by the Hibernate ORM open source software and is under the LGPL 2.1 or ASL 2.0 license. In more detail the:

LGPL 2.1 license is sufficiently flexible to allow the use of Hibernate in both open source and commercial projects.

Moreover, ASL 2.0 license which some Hibernate projects are released under the more permissive ASL 2.0.


-DCM4Chee libraries: These libraries are offered under the MPL/GPL/LGPL triple license (similar to Mozilla). This allows use of the files under the terms of any one of the Mozilla Public License version 1.1 (MPL), the GNU General Public License version 2 or later (GPL), or the GNU Lesser General Public License version 2.1 or later (LGPL).

FI-PPP: The PACS Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.

- ePSOS SE


The EHR SE is available in the catalogue as BETA release, last updated on 04-February-2015.



The EHR Manual is already uploaded. Also some examples of Curl APIs call is are provided as well.

An audio video course, on the FI-WARE e-learning platform, is not yet


It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.



External: The epSOS SE, layer has been developed by UCY and will be released to external parties (out of the FI-PPP and FI-STAR project) under an open source license (Apache License 2.0).

Furthermore such software depends from the following libraries which in turn are available under the following licenses:

Hibernate ORM open source software: under the LGPL 2.1 or ASL 2.0 license.

CDA Tools: under the Ecliple license - v1.0



available but is under preparation and will be uploaded soon.

For commercial or educational purposes, different Terms and Conditions apply. Pease, contact via mail the owner of the specific enabler ([email protected])

FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.

Entries on the Catalogue for the EXPOSE SE and the GEO-FENCING SE were prepared but made not yet public at the time of this document delivery. This to allow the owners to continue working on them but not allowing developers (internal or external to the project) to access them. This is in any case in line with the delivery roadmap of such enablers which, as all the enablers from the Open Call initiative, were expected to be available within the FI-STAR Cloud Infrastructure by the end of February.

3.2 Cloud Platform Managers Report

In this section the Cloud Platform administrators report details about their experience in interacting with the Catalogue in order to serve the requests coming, via Catalogue, by the Application Developers in the period from July 2014 to December 2015 (i.e. Beta development phase)

- XiFI Node Manager (Berlin)

For the period from the Specific Enabler release ALPHA to BETA, end of June to end of January, 27 SEs requests have been submitted to the Berlin node manager via the catalogue and 18 have been served by instantiating the SEs in the Berlin node. Naturally it represents only a screenshot because the process of requests submission is continuously under evolution.

Enabler Requestor

Connectivity Service Back-End WP4_APP_DEV_ROMANIA

Connectivity Service Back-End WP4_APP_DEV_ROMANIA

Connectivity Service Back-End WP4_APP_DEV_POLAND

Event Service WP4_APP_DEV_SPAIN

Event Service HeartHealth_SEs_OWNER

Event Service WP4_APP_DEV_ENGLAND


Event Service WP4_APP_DEV_ROMANIA



Event Service TRILOGIS_SEs_OWNER

Event Service WP4_APP_DEV_POLAND

Event Service MYSPHERA_SEs_OWNER

Event Service WP4_APP_DEV_NORWAY

Targeting & Profiling Service ACREO_SEs_OWNER

Targeting & Profiling Service WP4_APP_DEV_ITALY

Targeting & Profiling Service WP4_APP_DEV_ROMANIA

Health Questionnaire Service WP4_APP_DEV_ITALY

Tab 1- SE Requests Berlin Node Served

The following requests are, instead, still in a pending status:

Enabler Requestor

Connectivity Service Back-End ACREO_SEs_OWNER

Event Service ACREO_SEs_OWNER

Targeting & Profiling Service ANGEL_SINGULARLOGIC_SEs_OWNER



Health Questionnaire Service FI-PPP_FIC3_Yagram

Health Questionnaire Service FI-PPP_FIC3_Yagram

Security and Privacy Service (TUB)

WP4_APP_DEV_ROMANIA

Real Time Communication Service

WP4_APP_DEV_ROMANIA

Time Service SE WP4_APP_DEV_ROMANIA

Time Service SE FI-PPP_FIC3_HearingSoftware

Tab 2- SE Request Berlin Node Pending

The processes for receiving and serving request confirmed also in this period to be clear and understandable, with a good possibility to interact with the SE requester through comments on the request. The catalogue also provides a good mechanism to give feedback and monitor the progress status of a request by assigning corresponding states to the request (Pending, In Progress, Served).

- XiFI Node Manager (Crete)

For the period from the Specific Enabler release ALPHA to BETA, end of June to end of January, 12 SEs requests have been submitted to the Crete node manager via the catalogue and all have been served by instantiating the SEs in the Crete node. The catalogue has been used in order to record the requests and to monitor feedback and request status (pending, in progress, served).

Enabler Requestor

Time Service SE ACREO_SEs_OWNER

Time Service SE UCY_SEs_OWNER

Security and Privacy Service (TUB)

UCY_SEs_OWNER

Health Questionnaire Service ACREO_SEs_OWNER

Health Questionnaire Service WP4_APP_DEV_SPAIN

Health Questionnaire Service WP4_APP_DEV_ITALY

Targeting & Profiling Service WP4_APP_DEV_ROMANIA

Event Service ANGEL_SINGULARLOGIC_SEs_OWNER

Event Service HeartHealth_SEs_OWNER

Event Service UCY_SEs_OWNER


Event Service WP4_APP_DEV_ITALY

Monitoring Service WP4_APP_DEV_ROMANIA

Motion Evaluation HeartHealth_SEs_OWNER

Tab 3- SE Requests Berlin Node Served

- Conclusion

In conclusion from the information reported above it results quite evident a big increase in the number of requests served by the FI-STAR Cloud nodes via the Catalogue channel. The rational is due, mainly, to the fact that, in the reporting period this deliverable refers to, the WP4 Application Developers focused their development activities.

Other than this, it is worth to mention, that in the same period the Catalogue was opened also to the FI-PPP members and SMEs (and Web entrepreneurs) selected by the accelerator projects. Below a brief re-cup:

http://catalogue.fi-star.eu/enablers/security-and-privacy-service-tub

http://catalogue.fi-star.eu/enablers/security-and-privacy-service-tub

http://catalogue.fi-star.eu/enablers/health-questionnaire-service



http://catalogue.fi-star.eu/enablers/targeting-profiling-service



16 June 2014

Berlin Node Crete Node

Total Requests: 8 Total Requests: 5

- 6 served

- 2 pending

- 4 served

- 1 pending

31 January 2015

Berlin Node Crete Node

Total Requests: 27 Total Requests: 14

- 18 served

- 9 pending

- 14 served

- None pending

Berlin Increase: +237%

Crete Increase: +180%

Before closing this section is important to remark the support offered by the project (via Catalogue administrator) in enabling the FI-PPP Phase 3 SMEs to access the FI-STAR enablers. At moment of writing this document the following SMEs were provided (or are going to be provided) of an account as for requests coming from their accelerator representative:

Table 18 – FI-PPP Phase3 SMEs: Accounts Creation Status

3.3 Application Providers Report

The period from the Specific Enabler release ALPHA to BETA (end of June to end of January 2015) was also characterized by the access to the Catalogue, of a new actor: the (WP5) Application Provider. This actor started in submitting the subscriptions finalised to the SE VMs shipment, following the modalities described within D2.2. The objective was to make available, within the remote private cloud of this actor (or of his customers), the enablers needed to deploy and run, within the trial sites, the applications coming from WP4.

It is worth to mention here that during the period of interest only two shipment modalities were available: (i) Manual and (ii) Take advantage of the FI-STAR Cloud Platform. Details about such modalities are available in D2.2 while here a brief report about the interaction with the Catalogue is presented.



Table 19 - Catalogue: Subscriptions Administration Area

31 January 2015

Total: 22 subscriptions

Manual shipment Via FI-STAR (Cloud) Platform

- 20 - 2

3.4 Bugs analysis and improvements

The issue tracker tool, integrated within the catalogue, was set up by following the guidelines reported in the D2.2 - Annex B. Such configuration was conceived to support, from one side, the gathering, during the WP4 application development (alpha and beta), of the issues affecting the whole FI-STAR platform SEs, and, from the other, the gathering of issues affecting the Catalogue itself. In this section will be presented just a summary about the issues associated to the SEs, just to give an idea about the trend in the reporting period, while full description and details can be found in the PartA of this document. On the other hand this section provides a complete analysis of the bugs (and their management) affecting directly the Catalogue.

- SE issues evolution

16-June-2014 31-January-2015

Total increase: +241%

- Catalogue issues

The issues strictly associated to the catalogue are briefly summarised in the figure below:

#ID:2,4,6,7,8 were already analysed and discussed in the D2.2



#ID:31 - How to change email address of account? (type: Bug Report)

WP4_APP_DEV_NORWAY reported about the impossibility to change the mail address for an account. The issue was resolved by explaining that a user has only, just after the log in within the Catalogue, to click on the "edit" tab and, then, to change the mail address found in that area. A screenshot was posted as well for better explanation.

Table 20 – IssueTracker: issues related to the Catalogue

#ID:37 - Event Service download link is missing (type: Bug Report)

WP4_APP_DEV_NORWAY reported about the impossibility to download the Event Service enabler at the "Get your SE" page, although the enabler owner says there should be. The issue was resolved by contacting the Event Service Owner who clarified this enabler were available in that moment only as service instance from the XifFI Berlin\Crete node.

#ID:43 - Cannot download img files for enablers (type: Bug Report)

WP5_APP_PROV_NORWAY reported about the impossibility to download the image files for some enablers he subscribed for. The issue was resolved by making some tests and checking that all worked properly. Furthermore the same reporter advised, later on, they identified the cause of the problem in their firewall which prevented the download.

#ID:52 - No files to download VM images of SEs instances (type: Support Request)

WP4_APP_DEV_POLAND reported about the impossibility to download the image files for some enablers from the Get Your SE area. The issue was resolved by explaining to the requester that the download of the enablers VM images is possible only if he log in with the role of Application Provider.

#ID:75 - Status change disabled (type: Bug Report)

WP4_APP_DEV_GERMANY reported an issue similar to #ID:52 which was solved in a similar way.

#ID:77 - Browser support (type: Bug Report)

WP4_APP_DEV_GERMANY reported the issue tracker seems to not properly work wit IE. He report that clicking on the "My Bugs" list it responds a file, which is prompted to the user, rather than being integrated in the client-side web page. The issue is still in progress because the



Catalogue administrator has repeated the same action, by several IE versions, without capturing this behaviour. The issue will be closed if it will be not possible to repeat this anomalous behaviour.

3.5 Final considerations

In this section we want to highlight FI-STAR worked, during the T2.4 activity, on the development of an own catalogue, which optimises and simplifies the interactions expected by all the involved actors starting from analysis of such actors requirements (see D2.2-PartB). Furthermore the project recognised (as for first review indication) the need to introduce a professional tool for requirements tracking also to support the BETA development step of the platform. Therefore such a tool (based on the professional open source product Bugzilla) was properly customised and seamless integrated within the Catalogue environment (see D2.2-AnnexA).

Anyhow that FI-STAR, as the other Phase 2 projects, has been informed recently, via FI-PPP communication channel, about the intention to import all the enablers within the FI-WAR Catalogue. Such a way the FI-STAR Catalogue will continue to be available until such inclusion process will be completed. In this respect we think that the improvement implemented in our Catalogue (e.g. full automated requests management) and especially the full integration of a professional issue tracker could be something the future “new” FI-WARE Catalogue could take advantage of.



References

[1] https://www.FI-STAR.eu/

[2] FI-WARE DCRM Open Specification. (link)

[3] OMA LWM2M Device Management Protocol http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

[4] CoAP, Constraint Application Protocol, IETF RFC 7252, June 2014, http://tools.ietf.org/html/rfc7252

[5] Constraint RESTfull Environments (CoRE) Link Format, IETF RFC 6690, August 2012, http://tools.ietf.org/html/rfc6690

[6] FIWARE OpenSpecification IoT Back-End Device Management, http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Back-End.DeviceManagement

[7] FI-WARE (Back-End) Device Management implementation, http://catalogue.fi-ware.org/enablers/Back-End-device-management

[8] FI-WARE Configuration Manager-IoT Discovery specification, http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Back-End.ConfMan

[9] FI-WARE Configuration Manager-IoT Discovery implementation, http://catalogue.fi-ware.org/enablers/configuration-manager-iot-discovery

[10] Telefónica I+D (TID), http://www.tid.es/en, last accessed on July 11, 2014.

[11] FI-STAR Deliverable D2.1 Back-end Platform Services Modules Alpha Design.

[12] Nagios: systems and network monitoring; 2nd ed., by Wolfgang Barth, San Francisco: No Startch Press (2008)

[13] Zabbix – open source monitoring system, www.zabbix.com, last accessed on July 11, 2014.

[14] Collctd – The system statistics collection daemon. www.collectd.org, last accessed on July 11, 2014

[15] http://wiki.FI-STAR.eu/wiki/Connectivity_Service_Back-End_Beta

[16] http://catalogue.FI-STAR.eu/

[17] http://edu.fi-ware.org/

[18] NGSI Context Management; Candidate Version 1.0 – 03 Aug 2010: URL:http://www.openmobilealliance.org/

[19] ETSI M2M specification available in http://www.etsi.org/deliver/etsi_ts/, last visit in Feb 26, 2015

[20] ETSI M2M TS 102 689: M2M Service Requirements

[21] ETSI M2M TS 102 690: M2M Functional Architecture

[22] ETSI M2M TS 102 921: mIa, dIa and mId Interfaces

[23] Free open source implementation of TURN and STUN Server https://code.google.com/p/rfc5766-turn-server/, last visit in Feb 26, 2015

[24] RFC 5245: “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols”

[25] RFC 5912: “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”

https://www.fi-star.eu/

https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Cloud.DCRM

http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

http://tools.ietf.org/html/rfc7252

http://tools.ietf.org/html/rfc6690

http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Backend.DeviceManagement



http://catalogue.fi-ware.org/enablers/backend-device-management

http://catalogue.fi-ware.org/enablers/backend-device-management

http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Backend.ConfMan



http://catalogue.fi-ware.org/enablers/configuration-manager-iot-discovery

http://catalogue.fi-ware.org/enablers/configuration-manager-iot-discovery

http://www.tid.es/en

http://www.collectd.org/

http://catalogue.fi-star.eu/

http://edu.fi-ware.org/

http://www.openmobilealliance.org/

http://www.etsi.org/deliver/etsi_ts/



https://code.google.com/p/rfc5766-turn-server/

d2.3-fi-star back-end platform services modules beta

Documents