Final design of the Architecture - bscw.rethink-project.eu Final design of the... · Final design of the Architecture Editor: Eric Paillet, Orange Labs Deliverable nature: (R) Document,

Deliverable D2.3 645342 — reTHINK — H2020-ICT-2014

© reTHINK consortium 2016 Page 1 of (110)

Deliverable D2.3

Final design of the Architecture

Editor: Eric Paillet, Orange Labs

Deliverable nature: (R) Document, Report

Dissemination level: Public (PU)

Contractual delivery date: 30/09/2016, extension to 31/10/2016

Actual delivery date: 31/10/2016

Suggested readers: Service providers’ designers and product managers, operators’ strategists and senior managers, developers

Version: Release 1.0

Total number of pages: 110

Keywords: Fixed: Communication networks, media, information society

Free: Hyper-linked entities, Future Internet architecture, Trustful communications, Social trustful networks, WebRTC, Independent Identity, IdP, Peer-to-peer communications,H2H, M2M, Graph ID

Abstract

This document describes the overall architecture for the reTHINK project. The document contains an architecture frame work (chapter 1-10), use-cases (Annex-A). The architecture describes a new paradigm, where connectivity control is executed by downloaded software (‘hyperties’) to the endpoints, and compatibility is achieved by downloading matching software to both parties (‘ProtoFly’). This allows a single service provider to initiate communication set up directly with the destination user, and to deliver the service media over the Internet, in a peer-to-peer fashion. Quality of service and security are optionally enhanced by hosted services. This architecture also utilizes independent identity providers to provide end-users greater choice and service mobility, with flexible social-network style association, for both Human-to-Human and Machine-to-Machine users.

645342 — reTHINK — H2020-ICT-2014 Deliverable D2.3

Page 2 of (110) © reTHINK consortium 2016

Disclaimer

This document contains material which is the copyright of certain reTHINK consortium parties and may not be reproduced or copied without permission. The information contained in this document is the proprietary confidential information of the reTHINK consortium and may not be disclosed except in accordance with the grant agreement and consortium agreement.

The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the reTHINK consortium as a whole nor a certain part of the reTHINK 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 Horizon 2020 research and innovation program under grant agreement No 645342. This publication reflects only the author’s view and the European Commission is not responsible for any use that may be made of the information it contains.

Impressum

Full project title: Trustful hyper-linked entities in dynamic networks Short project title: reTHINK Number and title of work-package: WP2 –Overall Architecture Number and title of task: T2.1Technical Requirements derivation, T2.2Reference Architecture Design T2.3 Data Model T2.4 Interfaces Document title: Framework architecture definition Editor: Eric Paillet, Orange Work-package leader: Eric Paillet, Orange

Copyright notice

2016 Participants in project RETHINK

This work is licensed under the Creative Commons “Attribution-NonCommercial-NoDerivatives 4.0 International” License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/

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

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



Executive summary

The reTHINK project describes a framework that provides solutions to manage real time communication capabilities. This framework will integrate and react to contextual information in a secured way while respecting privacy. It provides also a quality of experience beyond ‘best effort’. The framework intends to meet the requirements that are derived from Use Cases described in the deliverable D1.1, and support a data model that is described in D2.2.

To achieve this, the reTHINK framework solution involves the creation of dynamic web-based service named ‘hyperties’, which remain active for the duration of the particular service logic that has instigated their creation. Such hyperties may be concerned with peer-to-peer communication, identity management and context management.

Hyperties are software modules that are maintained by the service providers, hence can be accepted as trusted software that is well maintained and is kept secure. These modules are deployed at runtime environments of devices and edge-servers, and interact with the local web browser or the native apps.

The solution also leverages the protocol-on-the-fly (ProtoFly) concept to avoid creating or modifying standard network protocols, but moving instead towards an API based flat service architecture. To enable another device or server (generally referred to as ‘endpoints’) to communicate with a reTHINK-based user, the appropriate software module is downloaded to the destination, using simple file transfer, creating a ‘foothold’ at the destination. This downloaded software will then perform the communication with the initiating party and will also provide translations and conversions as required, generating data that the destination can consume usefully.

reTHINK aims also to provide identity that is independent of both the front-end applications and the communication providers, using an independent and unique identifier. This identity should be managed by the user, not the service provider, and is verified by a user-chosen independent trusted entity. The identity provider delivers authentication tokens, which are sent to any involved stakeholder. This independent ID would be used for any participating service and users will be free to change service providers, where the subscription changes do not affect user reachability.

A user can be a human being, a group or, a connected object (e.g. building room with sensors). Users have independent identities that are maintained by Identity Providers (IdPs) that are independent organizations. On enquiry, these IdPs vouch for users’ authenticity and return the URL of the users’ domain, which enables finding destination users. The users’ identities are based on their personal and confidential data, which is verified by other solicited data, but such private information is only divulged under user-controlled privacy rules.

The reTHINK architecture can deliver QoS ‘on-demand’ over the Internet, selected only where necessary, according to network conditions, user preference and service requirements.

The reTHINK project envisages a global network of interconnected hyperties that are executed in web runtime environment on endpoints or edge-network servers. Such a global network could be seen as the well-known hyperlink concept of the Web extended to programmable links. Hyperties communicate with each other by exchanging messages in peer-to-peer (P2P) mode, and they manage, for example, the payload as WebRTC P2P media and data streams. Protocols and governance functionalities are abstracted by the web runtime procedures, using web services and local APIs.

The reTHINK architectural functions are based on a series of such hyperties that are generated by the service provider, and are downloaded to the users’ endpoints, so that communication traffic is only required for initiating the sessions. The hyperty modules represent a set of services that are stored in a Catalogue. The instantiated versions of these hyperties are registered in a Registry, which



represents authenticated users who are available for in-coming connectivity service. Therefore, the Registry serves as a location manager and is used for user discovery.

The reTHINK architecture relies heavily on the devices to execute session control and media flow management in an advanced peer-to-peer structure. This implies that the domains’ core server has much reduced loading and only few tasks, such as the management of downloading software, the registration of ‘live’ users, the discovery of available users registered within the domain, and responding to requests of network services via APIs.

Thanks to the reduced processing that is required by session control signalling, this architecture is more cost-effective to install and manage, and can support low-charge, even free-of-charge web services. Scalability is achieved by the ever-increasing power of user devices, not by expanding core systems. The increase in network activities for downloading software is borne by the growing capability and quality of the 4G and 5G broadband networks.

This architecture achieves simplicity of communication control and (inter)operability, but it raises several important issues that will be addressed during the project implementation:

Security of such downloads onto non-subscribing users, and their acceptance of this practice

Efficiency of constant downloading to edge devices

The impact on the devices in terms of battery life, processing capacity, ports etc.

QoE (Quality of Experience) of recipients of incoming connections

Integration with context-calling and click-to-dial type of user applications.

This architecture has inspired further innovation, which the partners have already identified, for example:

Interoperability at network level for the delivery of Specialized Network Services

Using Online Social Network techniques for linking available users (GraphID)

Context calling with user-controlled context decision making

Enhanced identity management using trust circles, based on independent identities

Integrating end-user policies with network policies for service delivery

Transfer concepts towards smart city environments

Dynamic, ad-hoc or automatic integration of objects into context based human communication

Modelling QoS and security levels, to position reTHINK between VoLTE and best-effort OTT.

These new ideas build on the main reTHINK notion of facilitating session control processing at the endpoints and empowering users to manage their identity information, yet enabling the communication to benefit from trusted service providers’ experience and offered services, including enhanced quality of service, policy and security.



List of authors

Company Author

Altice Labs Paulo Chainho

Apizee Arnaud Vallée

Frédéric Luart

DTAG – Deutsche Telekom AG Steffen Druesedow

Frank Oberle

Fraunhofer – Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.

Adel Al Hezmi

Marc Emmelmann

Andreea Ancuta Corici

Alice Cheambe

INESC-ID Ricardo Chaves

Ricardo Lopes Pereira

Nuno Santos

IMT – Institut Mines-Telecom Ahmed Bouabdallah

Ibrahim Javed

Rebecca Copeland

ORANGE Eric Paillet

Ewa Janczukowicz

Jean-Michel Crom

Kevin Corre

Simon Bécot

QUOBIS – Quobis Networks SL Anton Roman Portabales

Santiago Troncoso

Yudani Riobò

TUB – Technische Universität Berlin Felix Beierle

Sebastien Göndör



Table of Contents

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

List of authors .......................................................................................................................................... 5

Table of Contents .................................................................................................................................... 6

Abbreviations ........................................................................................................................................ 11

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

1 Introduction ................................................................................................................................... 14

1.1 Objective of this document ................................................................................................... 14

1.2 Key Adjustments of the reTHINK Architecture ...................................................................... 14

1.3 About This Document ............................................................................................................ 15

2 Requirements ................................................................................................................................ 17

2.1 The Requirement Scope ........................................................................................................ 17

2.2 Actors’ Role Definition........................................................................................................... 17

2.2.1 Identifying Actors .......................................................................................................... 17

2.2.2 Role Descriptions ........................................................................................................... 18

2.3 The requirement structure and documentation rules .......................................................... 21

2.4 Requirements update ............................................................................................................ 21

2.4.1 Non Functional requirements ....................................................................................... 22

2.4.2 Functional requirements ............................................................................................... 23

3 ReTHINK Architecture Overview ................................................................................................... 29

3.1 The reTHINK Framework ....................................................................................................... 29

3.2 Session Management ............................................................................................................ 30

3.2.1 Distributed Session Control ........................................................................................... 30

3.2.2 Messaging Services ........................................................................................................ 32

3.3 Identity Management (IdM) .................................................................................................. 32

3.3.1 Identity Assumptions ..................................................................................................... 33

3.3.2 Trust Management Functionality .................................................................................. 33

3.3.3 Granting Authorization .................................................................................................. 33

3.4 Policy Management ............................................................................................................... 34

3.5 Specialized Network Services (SNS) ...................................................................................... 36

3.6 Network-Side Services ........................................................................................................... 37

3.6.1 Catalogue ....................................................................................................................... 37

3.6.2 Registry .......................................................................................................................... 37

3.6.3 Discovery ....................................................................................................................... 37

3.7 Communication Applications ................................................................................................ 38



3.7.1 End-user Services .......................................................................................................... 38

3.7.2 Application Types .......................................................................................................... 38

3.7.3 Monitoring Presence, Availability and Context ............................................................. 39

4 ReTHINK Innovative Instruments .................................................................................................. 40

4.1 The Hyperty (Hyperlinked Entity) .......................................................................................... 40

4.1.1 Example1: WebRTC Conference .................................................................................... 41

4.1.2 Example 2: WebRTC Multiparty Conference in a Star Topology ................................... 42

4.1.3 Example 3: Contact List enriched with Presence Status ............................................... 43

4.1.4 Example 4: Data Processing in the Cloud ...................................................................... 43

4.2 Decentralised Communication Framework ........................................................................... 44

4.3 Protocol on-the-fly (protofly) and Protostubs....................................................................... 45

4.4 Protocol-on-the-Fly (ProtoFly)............................................................................................... 46

4.4.1 The ProtoFly Interfaces ................................................................................................. 46

4.4.2 Main ProtoFly Procedures ............................................................................................. 47

4.5 P2P Data Synchronisation: Reporter - Observer Model ........................................................ 49

5 Identity Management .................................................................................................................... 51

5.1 Identity Management Concepts ............................................................................................ 51

5.1.1 Identifiers ...................................................................................................................... 51

5.1.2 IdP Design Assumptions ................................................................................................ 51

5.1.3 Identity at the Endpoint ................................................................................................ 52

5.1.4 Identities when switched off ......................................................................................... 53

5.2 Graph Connector ................................................................................................................... 53

5.3 Server-side identity ............................................................................................................... 54

5.4 M2M/IoT Identities ............................................................................................................... 54

5.4.1 M2M connector ............................................................................................................. 54

6 Service Delivery and Interoperability ............................................................................................ 56

6.1 Application Interoperability .................................................................................................. 56

6.1.1 Application Interoperability .......................................................................................... 56

6.1.2 Case 1: Temporarily Enrolling or Using Service B .......................................................... 57

6.1.3 Case 2: Protocol on the Fly to integrate B into A .......................................................... 58

6.1.4 Case 3: Fully interoperable A and B............................................................................... 59

6.1.5 Summary of Use Cases .................................................................................................. 60

6.2 CSP to CSP Interoperability ................................................................................................... 60

6.2.1 CSP to CSP Interoperability ........................................................................................... 60

6.2.2 User Discovery Services ................................................................................................. 60

6.2.3 Global Registry............................................................................................................... 61



6.2.4 Session Reports and CDRs ............................................................................................. 62

7 Specialized Network Services and Internet QoS ........................................................................... 64

7.1 CSP Assumptions ................................................................................................................... 64

7.2 Specialized Network Services for OTT communication services ........................................... 64

7.2.1 Relationship between NSPs, CSPs and their clients ...................................................... 65

7.2.2 Managing QoS ............................................................................................................... 65

7.2.3 Technical interoperability .............................................................................................. 66

7.3 Internet access services optimized for real-time traffic ........................................................ 66


7.3.2 Managing QoS ............................................................................................................... 67

7.3.3 Technical Interoperability.............................................................................................. 67

7.4 QoS management for private networks ................................................................................ 67


7.4.2 Managing QoS ............................................................................................................... 68

7.4.3 Technical Interoperability.............................................................................................. 68

7.5 QoS management services built over internet access services............................................. 68

8 The data Model ............................................................................................................................. 70

8.1 The stable part of the Data Model ........................................................................................ 70

8.2 The modified part of the Data Model ................................................................................... 70

8.3 The new part of the Data Model ........................................................................................... 70

9 Interfaces ....................................................................................................................................... 71

9.1 General considerations ......................................................................................................... 71

9.1.1 Interfaces with Proto-fly support .................................................................................. 71

9.1.2 CRUD operations and roles ........................................................................................... 71

9.1.3 HATEOAS principle ........................................................................................................ 71

9.1.4 Resource access ............................................................................................................. 72

9.1.5 Adapting the REST API to constrained devices. ............................................................. 73

9.1.6 reTHINK interfaces ........................................................................................................ 73

9.1.7 Security considerations ................................................................................................. 74

9.2 Domain Registry Interface ..................................................................................................... 75

9.2.1 Description of Registry Interface ................................................................................... 75

9.2.2 CRUD operations over Registry Data Objects ............................................................... 75

9.2.3 Proposed Protocol for Registry Interface ...................................................................... 78

9.3 Catalogue Interface ............................................................................................................... 79

9.3.1 Description of Catalogue Interface ............................................................................... 79

9.3.2 CRUD operations over Catalogue Data Objects ............................................................ 79



9.3.3 Resource access in the Catalogue interface .................................................................. 82

9.4 Identity management interface ............................................................................................ 82

9.4.1 Description of Identity Management Interface............................................................. 82

9.4.2 CRUD operations Identity Management Interface ........................................................ 83

9.4.3 Proposed Protocol for Identity management interface ................................................ 84

9.5 Messaging interface .............................................................................................................. 85

9.5.1 Description of the Messaging interface ........................................................................ 85

9.5.2 CRUD operations over messaging interface .................................................................. 85

9.5.3 Proposed Protocol for the messaging interface ............................................................ 87

9.6 Real Time Interface ............................................................................................................... 87

9.6.1 Introduction ................................................................................................................... 87

9.6.2 Security aspects of Real-Time interface ........................................................................ 87

9.6.3 Connectivity aspects of Real-Time interface ................................................................. 88

9.6.4 Considerations about Real-Time interface .................................................................... 88

10 ReTHINK Architecture Summary ............................................................................................... 89

References ............................................................................................................................................. 92

Annex A Case Studies ....................................................................................................................... 97

A.1 H2H Communication high level view .................................................................................... 97

A.1.1 Runtime load ............................................................................................................... 100

A.1.2 Identity selection ......................................................................................................... 100

A.1.3 Hyperty load ................................................................................................................ 100

A.1.4 Getting access token ................................................................................................... 100

A.1.5 Binding the hyperty to an identity .............................................................................. 100

A.1.6 Inter-Hyperty communication ..................................................................................... 100

A.1.7 Protostub load: ............................................................................................................ 101

A.1.8 ID Token generation .................................................................................................... 101

A.1.9 ID token assertion ....................................................................................................... 101

A.1.10 Verifying identity assertion in incoming message ....................................................... 101

A.1.11 Connector Hyperty dynamic-view ............................................................................... 101

A.2 M2M Case Studies ............................................................................................................... 103

A.2.1 M2M Always Connected in Trustful Domains for Multi vendor devices .................... 103

A.2.2 Device Authentication ................................................................................................. 105

A.2.3 Device Registration ...................................................................................................... 106

A.2.4 Context Discovery ........................................................................................................ 107

A.2.5 PUB-SUB M2M Communication Setup ........................................................................ 108

A.2.6 P2P M2M Communication Setup ................................................................................ 109





Abbreviations

Abbreviation Definition Short Description

ASP Application Service Provider For web based or native applications

CDN Content Delivery Network

CDR Call Data Record

COD Code on Demand Enhancing existing clients with downloaded JavaScript’s

CSP Communication Service Provider Provider of communication services to web apps

DHT Distributed Hash Table

DM Device Management For on device capabilities information and status

DoW Document of Work Agreed project scope in the accepted project proposal

EPC Evolving Packet Core

FFS For Further Study Open issues that needs further investigation

HLR Home Location Registrar 2G-3G mobile subscriber data, including IP location

HSS Home Subscriber Service IMS/VoLTE subscriber data, including IP location

IdM Identity Manager Managing identity access rights

IdP Identity Provider Service provider who verifies users identities

IMS IP Multimedia Subsystem 3GPP core network standards which are used in VoLTE

LTE Long Term Evolution) Also known as 4G

LWM2M Lightweight M2M OMA protocol for device management

NAT Network Address Translation

NNI Network to Network Interface Connections between CSPs

NSP Network Service Provider

OS Operating System

OSN Online Social Network



OTT Over The Top

P2P Peer to Peer

QoS Quality of Service In both computing platforms and network sessions

QoE Quality of Experience

RCS Rich Communication Suite

RDF Resource Description Framework A framework for representing information in the Web

REST Representational State Transfer APIs for distributed hypermedia systems

ROA Resource Oriented Architectures

SAML Security Assertion Markup Language

SDK Service Development Kit

SDP Session Description Protocol

SDP Service Delivery Platforms

SLA Service Level Agreement

SNS Specialized Network Services Hosted and wholesale network services

SOA Service Oriented Architecture

SSO Single Sign On

STUN Session Traversal Utilities for NAT

TURN Traversal Using Relay NAT

VoLTE Voice over LTE

WCS Web Communication Service Communication service provided by the CSP

Webco Web Company

webRTC Web Real-Time Communication Browser based standard for streaming media



Definitions

Term Description

Catalogue (Directory)

The communication services that can be accessed by applications are stored in a repository (directory) of hyperties.

Web Communication Service (CS)

A service that allows users to have real-time communication over the Internet (not over carriers’ managed packet networks), which is using web technologies (browser, webRTC) and not carriers’ mobile technologies (IMS /VoLTE, GPRS or GSM).

CSP APIs APIs which expose standalone hosted services provided by the CSP core platform, which can supplement the service logic, to provide QoS levels, variable levels of security, identity verification and IdP brokering.

GraphID The permanent graph-based identifier of the user which is associated temporarily with a currently running hyperty instance, to provide continuity of users’ association, e.g. graph-style address book or social network circle.

Identity Management

The Identity Management is the function that provides Authentication features, which are provided by the Identity Provider ‘actor’, and further identity services that are potentially provided by the communication service provider.

Messaging Services

A real time message oriented service that handles signalling and manages the service logic for each session. Such signalling messages are transmitted between the control function towards other functions, such as identity enquiries, session setup negotiation between network providers, and notifications to the users and the instigating apps.

Registry

The repository of ‘live’ hyperty instances that are in runtime mode. The Registry is used to reach available users. When Hyperty instances are created, they are registered on the Registry, and when they are deactivated, they are removed from the Registry, thus user communication registries represent users’ availability.

User Communication Application

User Communication Applications are defined as those that use APIs to enable the reTHINK Communication Service. These applications enable two parties or more to communicate in real-time, using the reTHINK methods. Users access such applications via browsers or directly as native or downloaded software on the user’s device. These applications range from providing the whole range of communication features, to only a link facility to hosted communication services.



1 Introduction

1.1 Objective of this document

This document aims at describing the final, overall reTHINK architecture. It is written as an update of the initial architecture deliverable D2.1 [105] consequently replacing the former to provide to the reader a solitary description of the final reTHINK architecture. Besides, this document integrates the specification on reTHINK data models and interfaces from D2.2 [106]. For the latter, in addition to high-level UML descriptions, this document provides links to the detailed, formal specifications as provided to the public via the reTHINK github repositories. Thus, this document supersedes D2.2.

This document package is dealing with the main principles of the framework:

Stakeholders definitions and their relationships,

Network functions and their interactions and reference points,

Architecture Functional diagrams

Network diagrams showing the interworking of network nodes for both signalling and media

Examples that clarify the building blocks of the solution.

Data models and interface description

The scope of this document is to present the final reTHINK architecture. The work was based on the following input:

ReTHINK scenarios and use cases, as defined by deliverable D1.1 of the project, see [73]. It is important to gather all the interactions between components in the project. Based on different scenarios (more technical context), this document includes many dynamic views for each scenarios.

Vocabulary list, a cross-project effort to elaborate a common glossary of terms used in the project (reflected in this document in the Definitions section),

Work Package level architecture work

Feedback from the implementation, use-case and scenario, and demonstration work packages, namely: WP3, WP4, WP5, and WP6 that was used to fine-tune architectural aspects.

The output of this document is the description of the final reference model that fulfils the overall objectives of the reTHINK project, expressed by:

Provision of a comprehensive view of the final reTHINK Framework architecture,

Validation of the overall reTHINK architecture through dynamic views.

Description of reTHINK data model and interfaces

References to formal specifications in the reTHINK repositories on GitHub.

1.2 Key Adjustments of the reTHINK Architecture

While updating the description of the initial reTHINK architecture as documented in D2.1 [105], the following key adjustments were made and are reflected in this updated architecture description:

Requirements o updates from WP1 and WP6

Architecture perspective o merged with the Executive summary

ReTHINK Architecture overview o updates

ReTHINK innovative instruments o updates



Identity management o updates

Service delivery and interoperability o minor updates

Specialized Network Services o updates

Interfaces o updates from D2.2 [106]

Governance and policies o updates from D2.2 [106]

ReTHINK Architecture Summary o updates

As the state-of-the-art remains unchanged from D2.1, this document refrains from including the SoTA section.

1.3 About This Document

This document outlines the framework for a new architecture that enables communication over the Internet, using web technologies (e.g. webRTC), but also enabling carriers and service providers to provide network services that utilise their assets in support of communication applications.

The document summarizes the state of the art and the technologies that enable the merging of the Telecom world with the Internet world. It does not include detail design, specific business models or protocol definitions, nor does it contain use cases and implementation details.

This document outlines the assumptions made in building the reTHINK framework, and defines the stakeholders’ roles in delivering communication applications over the Internet, allowing for multiple business models. The technical solution includes the high-level architecture that determines how, where, and who-by network functions are performed; and describes the functional implementations conducted in reTHINK. The framework architecture allows for notional roles that may belong to a single entity, but could also be performed by independent parties. Hence, this document describes the final reTHINK infrastructure with functional components and their interfaces that can be executed by separate parties, but not those that are deemed to be internal.

The reTHINK project aims to design and prototype a new non-IMS Web Centric P2P Service Architecture, enabling dynamic trustful relationships among distributed nodes that support use-cases beyond commoditized telephony, such as contextual and social communications, M2M/IoT and content oriented services. This architecture will enable any service delivery through specialized end-to-end network quality commitments. This architecture will also provide extensible APIs designed for service developers, and will be based on secured, certified and portable identities.

This document is the deliverable D2.3 which updates and integrates the initial framework architecture definition in D2.1 and data model and interface specification in D2.2.



Table 1 Framework Architecture Deliverables

Deliverable Name Milestone Deliverable Description

D2.1 Framework architecture definition

M7 Defines technical requirements, describes the main concepts and the overall architecture of reTHINK framework.

D2.2 Data Models and Interface Specification of the framework

M8 Details the data models used to describe hyperties and Governance policies and the interfaces of the core framework.

D2.3 Final design of the Architecture

M21

The initial architecture will be updated according to adjustments made for implementation purposes and also new requirements coming from the feedback provided by the trials.

The document summarizes the work of two tasks (highlighted) out of four:

Table 2 Framework Architecture Tasks

Task Type Partners Description

Task 2.1

Technical Requirements Derivation

ORANGE (lead), DTAG, PTIN, Fraunhofer, Apizee, IMT, INESC, TUB

Derive technical requirements for the reTHINK architecture, with input from WP1 Use cases and Business models. Each requirement will be classified and allocated to the project iteration where it will be addressed.

Task 2.2

Reference Architecture Design

ORANGE, DTAG, PTIN, Fraunhofer, Apizee, IMT (lead), INESC, QUOBIS, TUB

Design and maintain reTHINK reference architecture and associated concepts, describing the reTHINK main sub-systems with their main dependencies and interfaces. Identify main entities roles, in particular the Hyperty and Manager roles. Demonstrate the power of the architecture and its possibilities beyond the existing state of the art.

Task 2.3

Data Models

ORANGE, DTAG, PTIN, Fraunhofer, Apizee, IMT (lead), INESC, TUB

Produce detailed data models that describe hyperties and Governance policies. This will be used to describe hyperties capabilities and the Governance Directory Service (to publish and discover hyperties). The Governance policy data model may create a new policy descriptor language for QoS and security rules.

Task 2.4

Interfaces Design

ORANGE (lead), DTAG, PTIN, Fraunhofer, Apizee, IMT, TUB, INESC, QUOBIS,

This task will provide a detailed design of reTHINK interfaces (including messages) to be implemented by main sub-systems notably hyperties, Management and Messaging Nodes.



2 Requirements

2.1 The Requirement Scope

The reTHINK project requirements refer to the proposed architecture, i.e. the network elements, their functionality and their exposed interfaces that require standardisation. However, the scope of the reTHINK does not cover:

Specific application design, except as a demonstration

Software implementation design which determines hardware and software platforms

Specification of internal software that is not exposed (though it will be simulated)

Technics of conversion of signalling and media.

The current update of the requirements is based on the first phase requirements, and the experience that we gained from the developments of the reThink Framework. It is also the fruit of the assessments that have been conducted in the evaluation phase and the first mini-hackathon.

2.2 Actors’ Role Definition

2.2.1 Identifying Actors

This section describes the actors involved in the reTHINK platform. They have been primarily defined in the Deliverable D1.1-Use Cases and Sustainable Business models for reTHINK [73] and confirmed as ‘roles’ in the architecture.

Table III shows the main roles involved in the functional ecosystem of reTHINK. While a variety of actors can be identified in a number of scenarios and use-cases, in the technical architecture, only particular stakeholders are defined such that they have a specific role in the instigation and delivery of web communication. Use case actors may combine several architectural roles, and stakeholders may play several roles in a single service delivery.



Table 3 Communication Roles in Web Communication

Use-Case Actor Role Description

Service consumer End-User Service User

User Represents an individual, organization or organization unit that consumes a service delivered by a Service Provider, e.g. Citizens, Tourists, Event Agency[73].

Network Service Provider

NSP Sells bandwidth or network access by providing direct internet backbone access.

Identity Provider IdP broker

IdP

Identity Provider creates, maintains, and manages identity information for service consumers and provides consumer authentication, allows trusted verification and discovering destination addresses of called users to other service providers.

Communication Service Provider

CSP Manages the delivery of basic H2H communication service such as voice, video and textual communication to customers as well as M2M services.

Application Service Provider

ASP Represents an organization that manages the delivery of an application to a service consumer.

Developers Developer Professionals who design and produce software.

Regulator Authority

Regulator

Responsible to govern digital service delivery by codifying and enforcing rules and regulations and imposing supervision or oversight for the benefit of the public at large. Examples: Government, City Authorities

Figure 1 shows the roles of the stakeholders, with their main interaction content.

Figure 1. Roles main functions and dependencies

2.2.2 Role Descriptions

2.2.2.1 User:

The Service Consumer represents an individual, physical objects, organization or organization unit that consumes a service delivered by a Service Provider. The End User usually have one or more Identities (managed by the IdP), but may consume the services anonymously too.

User

IdP

NSP

CSP

NSP

APIs for QoS/Sec+ other APIs

ASP

Get route with required QoS

Verify subscribing users, logging-on users and destination users

Agree QoS &security to be

enforced



2.2.2.2 Developer

Developers are professionals who design and produce software. Some of the requirements of this document are targeting developers.

Developers are the first ones who will use the reThink framework to develop new services and applications. The architecture should thus be designed to be first easy to understand by them.

2.2.2.3 Application Service Provider:

The Application Service Provider (ASP) represents an organization that offers web applications or terminal based applications to a service consumer, which require network services to facilitate communications. In this document, the ASP is a provider of such applications, which may be chosen by the user on ad-hoc basis, habitual basis or subscription basis. Such applications rely on the CSP services for the delivery of network connectivity and optionally other network services:

The App can be a full communication package, e.g. SKYPE, Facebook or GoogleTalk, if they wish to take advantage of QoS and security levels via managed transport. In this case the look-and-feel and all the communication features are provided by the app.

The App can also be concerned with entirely different things, but allowing users to click on a communication service. In this case, no communication features are provided by the app. Such ad-hoc communication will need to set up some default standard calling features.

The App may be provided by a CSP, with all the communication features and the GUI for different devices. Such apps should interact with the standards of reTHINK on an equal footing as any other Apps. Hence, the provider of such apps is regarded as an ASP.

Application based on reTHINK should provide in a way or another interoperability (meaning at least that they can be used with more than one IdP).

The web app is always used to initiate and manage the Communication Service. Such an app could be a well-known Internet Network provider, a new entrant seeking to compete in a special space, or a CSP’s own application that utilises the CSPs assets. Web apps choose which CSP they wish to collaborate with, and integrate the CSP’s own APIs into their apps, so that they can activate the communication services on the appropriate CSP platform.

2.2.2.4 Communication Service Provider:

A Communication Service Provider may provide different types of services like Communication Services (e.g. telephony), Identity Management Services (e.g. social network), and Connectivity Services (e.g. Internet Access):

The role of CSP can be adopted by carriers (mobile operators), major Web portals (e.g. Yahoo, Google), or any ASP with user relationships (e.g. eBay, Amazon).

CSP doesn’t need to have its own managed network, but could have the ability to negotiate managed routing end-to-end with NSPs (as a hosted service governed by SLA).

The CSP maintains wholesale accounts for participating Apps where users’ usage is aggregated. Per-user accounts may or may not be managed at the CSP, depending on the hosting levels of services for Apps. While established Internet players will not divulge any user information, new entrants may require hosted accounting services per user.

By incorporating specific CS stacks in the devices, the device will be linked to a particular CSP, but it can be linked to more than one.

There is no direct relationship between users and CSP unless it is through an App, but it is envisaged that CSP will offer their own calling apps, and have direct relationship through them.

The CSP platform software is driven by the App. It receives service requests from APs who have agreed to use the CSP’s own APIs.



The CSP’s negotiates the media path with its NSPs partners, and launches the service according to the agreed session parameters.

2.2.2.5 Identity Provider (IdP):

The IdP role is to provide independent management of user identity that allows trusted verification of users’ identity.

The IdP, as already established in the web world, provides several identity management functions that encompass: authentication, verification, and access to user information.

The IdP is a service provider that performs authentication and provides a security token to other websites or application, thus enabling SSO (Single Sign On)

Authorization to access a resource/service is usually not provided by the IdP. In other words the authorization to use the service or access the content still rests with the ASP, not the IdP.

The Identity Management function is wider than what is provided by the IdP:

The IdM function, as already established in the IT world, checks credentials as well as privileges and access control lists (ACL), performing access control (e.g. RBAC -Role Based Access Control-), hence its range of functions goes further than merely authentication and verification. However, IdM is not necessarily independent from the service, because authorizing service access or service spending is specific to each service or app.

The reTHINK project introduces a concept of Discovery Service as a necessary function that arises from the concept of IdP independence, allowing users to choose their IdPs and change which IdP they use at will. The Discovery Service enables finding users across any IdP globally, for example it could be enabled with OpenIDConnect Discovery services. It is likely that any IdP would also provide such a discovery service.

2.2.2.6 Network Service Provider:

The NSP role is a provider of network transport on a collaborative basis as common in the Internet, rather than as federated roaming partner – as in mobile networks.

Participating NSPs must have compliant router networks that enables IP tunnelling with QoS guaranteed and variable levels of security. This entails a network of special media bearing gateways that support TURN, STUN and ICE, among other protocols.

NSPs negotiate session admission with the CSP at the entry point, i.e. when they are selected as the first NSP in the session path, but this NSP has to determine the rest of the routing.

The NSP acts as a wholesale provider of transport resources, to any requesting CSPs.

The NSP business relationship with the CSP can be similar to access network, i.e. per session usage or per aggregated usage, under SLA.

NSPs may also be access network providers, but there are numerous cases when they are not. For example, ‘WiFi Calling’ is facilitated by any WiFi provider, including hospitality (hotels, cafes, airports), enterprise own WLAN and home WiFi gateway. In such cases the transports providers are often terrestrial carriers, with DSL as well Cable.

The NSP carries the webRTC media across its network towards the destination via media gateways that perform TURN, STUN and ICE functions.

The NSP has peering agreements with other NSPs who also have the ability to tunnel managed QoS data through TURN servers

2.2.2.7 Regulation Authority:

The role of the Regulation Authority in the context of a smart city is to make sure that especially the newly retrieved city – citizen data are used under strict security and privacy aspects.



This implies to either run such a smart city platform under city control, thus developing RG into a service provider.

Usage and economic value of the retrieved data should be controlled by RA.

2.3 The requirement structure and documentation rules

This section lays the foundation of the requirements that have to be met by the framework and the services designed and developed within the reTHINK project. The requirements are divided into two parts, functional and non-functional requirements, and are coming from different sources:

The document [2] which describes the main principles of the architecture we want to build,

The T2.1 task, which has generated the basic requirements

Input from Use cases and Business models, that leads to particular technical requirements.

Each requirement is assigned:

An Identity number, which will be referred to in this and other documents and in the implementation documentation.

A priority rate, which will follow the MoSCoW method: M, S, C, W for Must, Should, Could, Won’t. Please see [3] (http://en.wikipedia.org/wiki/MoSCoWmethod.

A name, describing the requirement in brief

A description, giving further details, if possible, specifying measurement criteria. The description of the requirements should refer to well-known elements, described in the definition table, and all actors involved in the requirements should be defined in the section 2.1 Actors definition.

A source, giving the origin of the requirement. This source can be: o One or more related use case coming o A referral to a reference document o The name of a reTHINK work team

A category, classifying functional requirements (some are coming from the classification of the WP1 use cases). On the non-functional requirements, the category allocation is optional.

Each requirement was classified and allocated to the project iteration where it has to be addressed. Such allocation has been reviewed according to feedback received from design and implementation tasks, so some of them are already assessed, some maintained some abandoned.

2.4 Requirements update

For each requirement table, a status column has been added. The status can take the following values:

OK: means that the requirement has been completed in the phase 1.

TODO: means that the requirement is still valid but has not been assessed in phase 1

A: means that the requirement is not valid anymore (abandoned). A justification is provided.

Most of these requirements have been assessed in the deliverable D6.3 of the project. Please refer to this doc to have a more complete view of the justifications of the status.

http://en.wikipedia.org/wiki/MoSCoWmethod



2.4.1 Non Functional requirements

The non-functional requirements include requirements of platform performance, stability and maintainability etc.

Table 4 Non-Functional Requirements

Id Name Description Related to Status

NF1 M Loose coupling

The reTHINK defined framework aims more agility in service development by reducing the dependencies possible between modules (loosely coupled architecture)

DoW OK

NF2 M

Scalability The reTHINK defined framework should be easily scalable (Fabrics in each layer offer scalable mechanisms for the registration, look-up and discovery of hyperties as well as communication between them).

DoW OK

NF3 M Architecture design

The main architecture is based on Web principles: service oriented, session management, stateless APIs.

DoW OK

NF4 S Usability for developers

Different types of stakeholders are targeted by the project, and among them Developers. Ease of development means that APIs are simple and common protocols are re-used.

DoW TODO

NF5 S

Framework management

The architecture may have several areas of management that belong to different stakeholders. Autonomy of management is paramount. Stakeholders (not users) may want to integrate the management with current systems, e.g. HSS and CRM.

TODO

NF6 M Terminal independence

The design should avoid any restrictions on terminal compatibility or new terminal embedded software

OK

NF7 M

Browser and apps compatibility

The reTHINK framework should not dictate unnecessary features or any visible display, in order to facilitate other applications fully and non-invasively. It should aspire to the highest compatibility possible to internet services as implemented in most browsers.

OK

NF8 W Instantiation of software module

The realization of multiple software replicas on different processors and servers is a matter of implementation by the network owner. Such instantiated software is out-of-scope for reTHINK.

OK

NF9 M Secured Communication

Communication between entities must be trusted and secure DoW OK



Id Name Description Related to Status

NF 10 S Service Mobility

Architecture should support "liquid applications", i.e. application deployments that follow the mobile user on the fly / service execution close to the consumer

OK

NF 11 M Coexistence of multiple architectures

reTHINK must not be another closed domain (silo). It is intended to be coexisting and connecting multiple architectures.

TODO

2.4.2 Functional requirements

Functional requirements include requirements of user features, data structure and support functions.

Table 5 Functional Requirements

Id Name Description Related to Category Status

F1 S Authenticated anonymity

A user should be able to authenticate itself to its IdP but remain anonymous for other participants in the conversation. Other participants would only know that the user is authenticated by its IdP. The user can choose to disclose its identity at will.

WP1-UC #85

Identity management

TODO

F2 S Explicit trust level on identity

A user should be able to get explicit trust level or measure about other’s participant identity.

WP1-UC #38

Identity management

TODO

F3 S Interoperability between identity providers

Two or more end users registered in a different IdP should be able to communicate with the same communication service provider (CSP)

WP1-UC #3

Interoperability OK

F4 S Interoperability between service providers/domains

Two or more end users registered in a different IdP and a different communication service provider (CSP) should be able to communicate

WP1-UC #95

Interoperability OK

F5 M Service Subscription with external Identity

End-users must be able to subscribe new services by using Identities from external Identity Providers. It should be possible that the Identity Provider is set by the end-user even if there is no previous trustful relationship established with the Service Provider

WP1-UC #84

Identity management

OK

F6 M Authentication with external Identity

End-user must be able to authenticate and register with a Service Provider using an Identity from a separated Identity Service Provider.

WP1-UC #81

Identity management

OK




F7 S Establishment of a real time communication

The end user should be able to establish a real time, voice, video, or data (texting) communication channel with one or more other parties

DoW H2H Communication

TODO

F8 S Exchange of data between two (or more) peers

The end user should be able to exchange data with one or more other peers (parties) DoW H2H Communication

OK

F9 C Network QoS Management

The network QoS could be provided if requested. This functionality should be loosely coupled and optional.

DoW Network Connectivity

OK

F10 S Negotiated QoS It should be possible for the CSP to negotiate the delivery path which assures a level of service across several delivering parties (NSP).

Network Connectivity

A

F11 S Security Level It should be possible for the CSP to negotiate the delivery path which assures a level of security across several delivering parties (NSP).


A

F12 S User QoS management

By users' option or their communication web apps, sessions may be determined as 'best effort', so no QoS and no selectable security levels are guaranteed, but P2P free sessions can be delivered. Where users subscribe to QoS service, their CSP should be able to negotiate levels of QoS and security with the destination CSP, before commencing to transport media.


OK

F13 S Terminating a session

Termination may occur by user action, app action or network event (e.g. congestion). Capping actions are regarded as app actions. The app should be notified before executing session termination.

Endpoint management

OK

F14 S User Availability for incoming calls

It should be possible to ascertain when destination users are available or not and return notifications to the initiating user.

Entity Presence OK

F15 M Choosing which endpoint per user

Incoming calls need to establish which endpoint is available, since each one is addressable separately by a unique global URL. Re-directing to another endpoint may be performed by the recipient web app.

TODO

F16 M Alerting users for incoming calls

It is the responsibility of the users' chosen web apps to alert them to incoming call. Endpoint management

OK

F17 M

Choosing the mode/media for the session by arbitration

The mode and media for the communication is negotiated between the parties at session initiation time. This depends on the chosen recipient endpoint device and may influence the choice of that device, when the user is available on several of them.

OK




F18 M Calling web app The software that initiates web-based communications is regarded as web app, even if it has a client or stack in the endpoint. The user may utilize several such web apps, ad-hoc or habitually.

OK

F19 M Recipient web app Called parties need not activate the same web app as the called party, but the recipient web app must be compatible with the originating CSP's APIs, i.e. the reTHINK standard APIs.

OK

F20 S Standard APIs

The communication service provider should be able to define APIs that determine how software is accessed, but what input parameters are required and what output results are returned should be standardized by reTHINK. Such APIs do not need globally unique URLs each, but the address of the whole platform is provided for those that have subscribed to the service. This enables the CSP to develop its own platform without constraints.

OK

F21 W Calling features Displaying caller ID, returning calls, address book, blocking malicious calls and any other call features are the responsibility of the user-end web app and out-of-scope of reTHINK.

OK

F22 S Emergency service It is envisaged that there may be regulatory free services, such as SOS calling. TODO

F23 M Access control for remote peers

Some form of access control can be set up by each user, controlling, e.g., who can access the data his/her device is offering.

Online Social Network

TODO

F24 C Endpoint discovering

It could be possible to discover and to register endpoints that should be used reTHINK Framework (e.g. SmartHome devices, IoT). For each endpoint, one could store its capabilities (able to display something, its screen characteristics etc., able to play an audio message …) and the related communication API (protocol used, parameters).

M2M Communication

F25 M

M2M Ad-hoc Connection initiated by new device that registers in a trustful domain

As soon as the device is turned on and connected to the network, it must be able to automatically register in the front-end platform domain (gateway), discovers and connect with other devices or subscribe to certain events from other devices. Devices can be provided by different manufactures.

WP1-UC #5

M2M Communication

TODO




F26 M

M2M Ad-hoc Connection initiated by existing device when new device registers in a trustful domain

As soon as the device is turned on and connected to the network, it must be able to automatically register in the front-end platform domain (gateway). Other existing devices must be able to be notified about the new registered device and connects to new device to request data, publish data or to subscribe to certain events/data. Devices can be provided by different manufactures.

WP1-UC #5

M2M Communication

TODO

F27 M Trustful Inter-domain M2M Ad-hoc Connections

According to its Access Control policies, a Device must be able to be discovered and automatically accept requests to connect from other devices registered in a different but trustful domain.

WP1-UC #6

M2M Communication

TODO

F28 M Discovery of Communication Peers

Cross domain Context or Keyword-based discovery of communication peers WP1-UC #74 - #80

Human Context TODO

F29 M enable endpoints to be mobile

Endpoint hyperties should be able to function even when the endpoints are mobile, i.e. IP address is linked to the endpoint URL dynamically

OK

F30 M Inter-domain H2H Communication usage experience

In Inter-domain H2H Communication it must be possible that each end-user has the usage experience set by its Service Provider

WP1-UC #2

H2H Communication

OK

F31 S

Ad-hoc Trustful H2H Connection (with no setup signalling)

Trustful Humans should be able to directly talk and share images or other digital resources (photos) between each other with no need to perform the usual call setup procedure (invite, ring, accept).

WP1-UC #4

H2H Communication

TODO

F32 M Dynamic Network Side Service provisioning

It must be possible to have network side services (e.g. telephony gateway, media processing like media recording or audio and video bridges for multiparty) dynamically discovered, selected and provided before or during the Conversation.

WP1-UC #13

H2H Communication

TODO




F33 S Network side service registration and context

As soon as a Network side service (see above) is deployed and activated it must be able to register in its domain with its context in order to be discoverable by end-users. Network side Service context should include: - availability status - connectivity description e.g. IP addresses and ports - service resource profile e.g. available storage, CPU, in/out - service resource load e.g. storage, CPU, in/out Context change should be published e.g. service resource load, when certain policy conditions are satisfied.

WP1-UC #13

H2H Communication

OK

F34 M Multiparty H2H Communication

It must be possible to have Multiparty conversations where different resources can be shared among participants including audio, video, chat, files, etc. One or more participants may play the organisation role having permissions to control the conversation including to mute/unmute and kick-out other participants from the conversation

WP1-UC #86

H2H Communication

TODO

F35 M Communication history

All communications and associated metadata (including participants Ids, main activities, time, etc.) must be stored and accessible to authorised users according to certain authorisation policies

WP1-UC #92

H2H Communication

TODO

F36 S Ad-hoc Collaborative Assistant Services

It should be possible to enrich H2H Conversations with specialised assistant features that are provided by different Service Providers e.g. services to assist business negotiations among participants, purchase orders, professional training, job interviews, software development, professional design, project architecture. It should be possible that each Conversation participant has their one user experience set by its own assistant service provider

WP1-UC #97

H2H Communication

TODO

F37 S Assistant Services modes

It should be possible to have Assistant services attached to the conversation in different modes including: - Assistant Services are involved in the Conversation from the very beginning - Assistant Service is only used by one Participant e.g. Job Interview assistant is only used by the Interviewer participant - Assistant Service is provided by one of the Participants to all other participants e.g. professional training assistant is provided by the teacher Participant

WP1-UC #97

H2H Communication

TODO




F38 M Context publish

The condition to publish end-user context can be ruled by policies including: -Every time an end-user registers or unregisters from its domain. - when the Context change satisfies one or more conditions e.g. when network connectivity degrades below a certain level. Authorised end-users or services will be notified about the new published Context.

WP1-UC #64

Context Management

TODO

F39 M Aggregation of Context sources

Depending on the Context Service provided, Context data is the aggregation of data from different sources, including: - availability status explicitly set by Bob - connectivity status derived from events received from the network - connectivity description e.g. IP Address and ports - device profile e.g. available resources including media (mic, cam), data sources (sensors) and associated codecs. - activity status derived from data collected from sensors - localisation collected from sensors - environmental data (e.g. temperature, light, noise) derived from data collected from sensors

WP1-UC #64

Context Management

OK

F40 S Context Access End-users or services should be able to ask for authorisation to subscribe or to get access to a certain end-user context. Authorisation requests must be managed by authorisation policies that may require explicit authorisation by the end-user.

WP1-UC #64

Context Management

TODO

F41 M End-user Service Usage data

It must be possible that End-users authorizes Service Providers to collect service usage data to build the end-user Profile

WP1-UC #91

TODO

F42 M End-user Service Usage data ownership

It must be possible that End-user profile is managed and owned by the end-user including: -to change profile (create, update, delete); -to export it to other service provider

WP1-UC #91

OK



3 ReTHINK Architecture Overview

3.1 The reTHINK Framework

The reTHINK Framework enables communications between several entities: people (Human-to-Human, H2H), objects (IoT, smart cities…) and server apps (e.g. M2M). The reTHINK framework represents users (entities) by their ‘hyperties’, i.e. web presence that is facilitated by hyperlinked software. Hence, hyperties can be instantiated and used on:

an end user Equipment,

an object (e.g. IoT),

a machine (e.g. CSP server).

These hyperties perform in situ (i.e. at the endpoint) a variety of functions on behalf of the users, enabling interaction between multiple users and servers.

The reTHINK Framework enables calling upon specialized network services (e.g. QoS, security, priority, enhanced ID management etc.) that are provided by service providers to applications. Figure 2 depicts the main elements of the general architecture envisioned.

Figure 2. Functional Architecture Overview

This framework identifies the main processing components:

Hyperty type discovery based on the hyperty catalogue of the CSP,

Hyperty instance reachability, based on the hyperty registry at the CSP,

Identity management, aided by independent IdPs,

Special Network Services, provided as APIs to requesting service providers.

Figure 3 shows the way hyperties are produced, catalogued, discovered, downloaded and registered. It also shows the different stakeholders: the CSP platform (right), the ASP (top), the Identity Provider (bottom), and the users (left), who may be persons or groups that may have multiple terminals, or machines for IoT or M2M service. In the middle the devices are shown containing appropriate hyperties.



The diagram depicts the main interactions between the stakeholders:

Users uploading personal details to IdP and enquiring on destinations URL address

Discovery of appropriate hyperty service type via the catalogue of hyperties

User/device logging on to the CSP service and registering the hyperty instance on the Registry

Downloading the hyperty software to the devices for endpoint-based session control

Find available user/device via the Registry

ProtoFly procedure with the destination endpoint, for compatible communication.

The CSP link to IdP is used to verify destinations or sources of requests (e.g. ASPs), but may also have hosted services supporting identity management.

Figure 3. The CSP platform management of hyperties

3.2 Session Management

3.2.1 Distributed Session Control

The functional architecture as shown in Figure 4 describes the functions and services that the reTHINK project addresses. These functions reside not only at the CSP platform, but also across the user devices, where software is downloaded and locally executed, thus enabling a peer-to-peer implementation of session control, but also providing CSP services. Software modules which are dynamically downloaded to the endpoint devices are ‘hyperties’.

Identity Management

User Discovery & Registration

Communication Service Provider

Governance

Messaging Services

Service Hyperty Discovery

CSP Services

Archive

Specialized Network Services

NSP Services

QoS Security Routing Charging

Device B1(not logged in)

IdP

Device A

Device B2

Upload User’s own details

Service Request

Incoming call alert

Hyperty A

Hyperty B2

User AInstigating

ASPWeb App /Native App

Verify destination users

User BDestination

Hyperty type selection & download

Catalogue

Find Destination User

Registry



Figure 4. High Level Functional Architecture



3.2.2 Messaging Services

Messaging Services provide real time message oriented communication functionalities used by user services to communicate (Message Routing). They should provide different communication patterns including publish/subscribe communication. Figure 5 expands the Messaging Services function (as shown in Figure 3 above), showing the main components: routing, communication set-up, access control and session management.

Figure 5. Messaging Services Functionalities

Message Routing, including pub/sub Subscriptions, are subject to Access Control in co-operation with authentication and authorisation provided by Identity Management functionalities.

Session Management functionalities are used to control messaging connections to service provider back-end services including allocation of messaging addresses to user services in cooperation with authentication and authorisation provided by Identity Management functionalities. For example, when user turns-on the device and connects to its domain, providing credentials as required by Identity Management functionalities.

Initial establishment of stream communication between User Services (e.g. Audio and Video media streams) is achieved via the Communication Setup functionality.

Messaging Services are agnostic of the User Service type. They play a key role in reTHINK architecture, by providing functionalities to support Hyperty instances communication, for instance:

to support signalling messages exchange between peers to set-up and control H2H media communication;

to support the exchange of messages between context providers and context consumers (e.g. to handle presence status management or for IoT applications).

3.3 Identity Management (IdM)

The Identity Management service verifies the Identity of an End-User, provides End-user authentication, authorisation and access to End-User profile information. Users may utilise an independent identity provider and provide their security tokens to the CSP, but the CSP has to verify the user further, to ensure that if, and at what level, service delivery is authorized. This process may involve the interaction between the CSP and the ASP.

User Id can be determined by different kind of identifiers: email, webID, OpenID, URL, mobile phone number or any other global identifier, and may have more than one authentication factor. CSP’s identity management may provide means of relating various identifiers and devices to a single user account.



3.3.1 Identity Assumptions

The IdP does not maintain availability on a particular device (it is the responsibility of the Registry functionality – see §3.6.2).

The Identity Provider is an actor whose main business is the delivery and verification of Identity assertion to other actors, especially Service Providers.

IdP should provide registration possibilities for Service Providers. In this case, a Service Provider can use the IdP to delegate its authentication features, and it’s a guarantee of trust.

In the context of reTHINK, the End-User can choose its IdP, regardless of the service used. The user selects which IdP to use, and provides that IdP with various personal details that allow independent verification.

Managing multiple identities per user is a matter for IdP policies. Discovering the user’s identity (unique or multiple) is performed by each IdP or by some Identity Broker (which may reside on the user device).

3.3.2 Trust Management Functionality

Trust management is a wider research topic that is germane to the reTHINK project. Indeed, in modern open web communications the need to estimate trustworthiness of the communicating participants may become crucial in some cases. Merely verifying user identity will not guarantee that the user is trusted. Thus, trust needs to be evaluated and displayed with the verification process before each user decides to participate in communication. Various parameters can be considered for the computation of trust between two entities: for instance the reputation of the authentication assertion issuer (i.e. the IdP used).

3.3.3 Granting Authorization

Granting authorization per session is not part of identity management, but is essential for the logic flow of service provision. While in traditional network authorization is often provided in the same process of identification, notably by AAA servers (Authentication, Authorisation, and Accounting), in the reTHINK paradigm, the authentication of an independent user is separated from the commitment of resources for a user.

User accounting is also changed, due to the prevailing Internet-based business models. Authorisation functionalities and Authentication functionalities are not necessarily provided by the same Actors. Therefore, the reTHINK new business models will affect who is actually authorising the network providers to allocate resources to the requested service.

Since authentication is devolved to the IdP, the IdP authenticates the user’s credentials, using provided information and solicited independent information, but it is not in charge of authorizing usage of resources.

Service authorization is provided by the parties who provide communication services or applications that have agreements with the network delivery providers to commit resources on behalf of the user. These parties are aware of the context of the request and the user status. Therefore, ASP /CSP authorization empowers the CSP, and in turn the NSPs, to deliver the service, based on prior agreements.

Authorization can only be given by the instigating application that knows if, how and when usage is charged for – whether it is charged to the user or to the requesting application, or any other funding parties. A CSP may authorize usage of its own resources in certain circumstances, e.g. emergencies, or when the CSP has direct relationship with the user.



3.4 Policy Management

The CSP takes the responsibility of several supporting services the implementation of which is distributed between backend servers in the CSP infrastructure and in the end users devices. These various entities may exchange sensitive information under the control of a classical PDP/PEP/Policy Repository structure [94]. We summarize below the approach followed to implement the policy control structure in the end device, in the core network and the policy model defined to cope with the requirements of the reTHINK project. A detailed treatment can be found in the deliverables dedicated to the security issues [108], [109].

At the end user side, the behaviour of the involved Hyperties executing in the runtime of the device have to obey to the policies defined by the CSP. On the other hand, since the Hyperties might be received from remote providers, their executions must also be controlled on behalf of the user to ensure that the Hyperty does not compromise the device security. The runtime includes several mechanisms, such as sandboxes and user defined policies. These policies must define the allowed access to local resources and the communications with other entities of interest. The policies involved in the end device are of two types as shown in the Figure 6. On one side, the policies defined by the CSP and accepted by the end user in its subscription or when downloading the Hyperty. On the other side, the policies specific to the device, the goal of which is to maintain its native security level by controlling the communications of the Hyperty together with the allowed access to locale resources.

Figure 6. Policy deployment in the end device

In the core network, exchanges with the Domain registry, the Discovery and additionally the Catalogue are under the control of policies. The access to the trust engine or to the Identity manager which by themselves carry out control must clearly not be restricted. The communication service provided by the Messaging Node involves a cut-off control in the manner of a firewall. The global picture pointing out the role of policies in the CSP infrastructure is outlined in the figure below.

The reasonable mutualisation of the PDPs is not suitable for the distributed nature of the CSP domain. To cope with the presence of multiple dedicated PDPs operating in a distributed way, we



introduce a Policy Orchestrator the role of which is to maintain a global coherence between the different points of policy evaluation and enforcement. Different CSPs may be led to dynamically and punctually negotiate specific policies to be applied to inter-domain sessions. Such negotiations can be carried out by a Policy Broker located with the Policy Orchestrator.

Figure 7. Policy deployment in the CSP domain

A policy model exactly tailored to the currently identified needs of the project has been developed. An ad-hoc analysis conducted on a corpus of policies extracted from a first set of deliverables of the project led to the definition of the model below [109]. Such analysis additionally helped us to determine the expressiveness of the specification language required to describe policy implementations. We keep however in mind that the selected approach must be easily extendable to cope with new posterior requirements.

Suppose that some principal wants to execute Ac(p) some action Ac with some parameters p, the goal of the targeted policy is to regulate the execution of Ac(p) by permitting or prohibiting it. Such regulation which may depend of conditions out of the scope of the principal has the following general structure:

no authorization: the action Ac(p) is blocked and another action Ac’ may eventually be substituted to Ac

partial authorization: the action is authorized but with others parameters Ac(p’)

complete authorization: the action Ac(p) is executed

The scope of a policy is defined by the principal concerned by the policy. In reTHINK project, we have to deal with three kind of principals end user, application, Hyperty. The abstract description of a policy should at least involve the actions depending from an authorization, the scope of the associated policy, the eventual « out-of-scope conditions » to be satisfied, the level of authorization required by the policy: null / partial / complete.

The description of a policy can be done using existing access control and messages exchange policy languages, in particular XACML expressed using XML specification language. Following [110] we can however point JSON as a valuable and “fat-free” alternative to XML. Despite its interesting properties, XACML is in fact not well suited to data interchange. The main drawback rests on its heavy verbose nature which prevents it to suitably match with the data model of its hosting programming language. Another major argument advocating the use of JSON concerns the reTHINK framework where JSON is systematically and consensually used to represent the data. Having a data



format that is interchangeable with programming language built-in data structures eliminates translation time and reduces complexity and processing time. Furthermore the strengths of XML are also present within JSON and the two are functionally equivalent [111].

Policies can be used to specify preferences about groups of other users, subscription preferences to data objects, or context variables, e.g., the time of the day, physical location or events on Google Calendar. Policies can apply not only to every message going through the runtime, but also to specific messages addressing, for example, a given hyperty or user identity. To allow for this differentiation, the identity associated with the targeted hyperty or user identity are loaded along with general policies from a policy repository and verified. Policy verification is carried out in three steps:

1. Loading system attributes validated by the policy rules, e.g., fetching the current system time;

2. Verification of the fetched value against the conditions specified in the policy, e.g., verifying if the current system time is within the established limits;

3. If the verification succeeds, the authorization decision associated to the policy is added to the set of individual decisions.

If any policy has not been successfully verified, then the final authorization decision is that the message is to be blocked and an error is returned to the sender. Otherwise, the message is forwarded to its destination. The specification of a policy may have actions associated with its verification, e.g. reroute the message to other identity or send an automatic message back to the sender, which is a feature independent from the authorization decision to allow further expressiveness.

3.5 Specialized Network Services (SNS)

The reTHINK solution aims to provide the option to enhance the service delivery, despite using the open, unmanaged and uncontrolled Internet. This is achieved for instance by ‘semi-managed’ service delivery that routes sessions over a mesh of media gateways that are capable of enforcing QoS and security, such as TURN/STUN gateways. Such gateways are maintained by network service providers (NSPs) who will collaborate with each other, forming new type of business models.

The reTHINK architecture enables CSPs to offer hosted services that enhance Internet communications. This involves:

Setting up sessions with the appropriate levels of QoS and security

Enforcing network policies (QoS and security) through collaborating Network Service Providers, who Guaranteeing reliable delivery, using special nodes (STUN and TURN)

Negotiating agreements with ASPs and monitor fulfilment.

Specialized Network Services are enforced by participating Network Service Providers. NSPs can negotiate parameters for the passage of media, but must guarantee that the agreed network policy is enforced. Inter-network transport accounting may be handled as wholesale volume re-conciliation, but other business models can be considered. Over-capacity can be rented to congested services.

It is assumed that reTHINK sessions could have variable levels of both QoS and Security, where these levels are negotiated by the CSPs with their partners along the required path to connect the parties. It is assumed that despite the Peer-to-Peer media exchange between users, QoS, Identity, and usage-reporting/charging (CDRs) are provided via the messaging services at the CSP platform, i.e. by the Communications Setup module, which handles the policy negotiation with the network providers.



3.6 Network-Side Services

Server-side services (to distinguish from device-side as well as web based services) are services that need to be provided from the network to the communicating endpoints, e.g. Media Server services or MCU bridging for conferencing, or other data centre facilities.

3.6.1 Catalogue

Catalogue is the functional element that lists the services available within a domain (namely a service provider). It provides access to service assets including service descriptions, software, policy, documentation, and other assets or artefacts that are essential to the operation of the service.

In the reTHINK context, the catalogue is a service provider's list of available services (which generates runtime hyperty instances), that are available to any application with valid permissions to use it. It is the place where you describe available hyperties, independently of where they will run. The catalogue items include information like type, description, input/output data formats, code and interfaces.

Each Service Provider can broadcast its hosted services to the community of developers and existing application providers, in order to invite them to subscribe to its hosted services. This entails viewing of the catalogue of services and their capabilities, as well as exposed SDK (Service Development Kit).

3.6.2 Registry

The Registry service in reTHINK encompasses two sets of directory services that register connected users and running hyperty instances, and thus help reach communicating peers.

First, each CSP runs a Domain Registry service that resolves domain-dependent user identifiers to the actual information about this user’s hyperty instances (a live hyperty used by a user in one device). The Domain Registry logs currently active hyperty instances when they are launched and are indexed by a pointer (e.g. a URL). Information provided for each registered instance by the Domain Registry comprises current network location, type of hyperty (communication, identity…), description, start time etc. A list of registered hyperty instances for a specific user can be retrieved through a lookup function. Since the Registry records actively running hyperties, it provides information about a user’s presence and availability for incoming calls and services.

When users (or services) initiate hyperty instances to be launched, the hyperty information is ‘published’ in the Domain Registry, and these records are maintained to keep the Registry up to date. For this purpose, the Domain Registry provides an interface for registration and deregistration of hyperty instances, as well as for keeping the published information up to date.

Second, the Global Registry is a distributed directory service that stores and manages identity datasets in the reTHINK ecosystem in order to find CSP accounts of a user. In reTHINK, users (entities) are identified by globally unique, domain-agnostic identifiers called GUID (Global User IDentifier) that remain stable and unchanged throughout the entire lifespan of a user account and can be used to address and identify users and devices. By querying the Global Registry, a GUID is resolved to a dataset that comprises some user’s current endpoints, i.e. this user account within a CSP’s domain (UserIDs).

3.6.3 Discovery

In the reTHINK architecture, user discovery is the service used to find destination users, whichever device they are currently logged on, in order to launch a connectivity request towards them. It should be easy and friendly to use event though the user will probably be more nomadic than services that can simply rely on plain old DNS.



The basic idea is to apply the search engine experience, usual when finding services (Google) or even objects (Shodan), to determine persons’ reachability address. Granting that called party GUID is known, the Global Registry will enable the discovery service to get CSP domains where the requested peer is enrolled. Subsequently, requesting the Domain Registry of a CSP may provide live hyperty instances used by the requested user. So a channel between hyperties may now be established.

Moreover some additional criteria may be used for a more efficient discovery process. And obviously all data disclosure must be protected by user-defined policies for privacy reasons.

The Discovery service may be available as a standalone service or included within other applications through the use of REST APIs.

3.7 Communication Applications

3.7.1 End-user Services

End User Services are services running in end-user devices (e.g. smartphones, IoT devices, etc.). End-user services can be imported by web applications, launched from a browser or by native applications installed in the device from online application downloading services, such as Google Apps Marketplace or Apple App Store.

The end-user can be a human being or a connected object (e.g. building room with sensors). End-user devices for non-human beings are usually gateways that are able to interact with IoT sensors and / or actuators. A non-human being may also act as a representative for a group of ‘things’ in which case it provides M2M connection services. For such cases, the End-User exposes via a hyperty an interface to its M2M connector running on the device.

An End-User can be reached by another using discovery service that makes use of the registries. An End-User can subscribe to several applications, through Identity Management functionalities that allow CSPs to associate various identities of the same user.

In reTHINK context, End-User Services are features that are provided to support hyperty communications, to distinguish from application features. An entity that act as a CSP, may also offer its own apps (native or web-based), with front-end features and user interfaces, thus combining the ASP and the CSP roles.

3.7.2 Application Types

A web communication app is a browser based web application that facilitates web communications (WebRTC or similar). Its user interface is used to initiate webRTC sessions by direct calling (address book or dialling app) or by context-communication (click to talk from any web page).

A native CSP application that is compatible with reTHINK should provide the same facilities in terms of webRTC interface and APIs. The applications provided by different ASPs still need to be able to interoperate with the CSP hyperties. End-User Services provided by different Service Providers must be able to interoperate on different levels:

at communication control level (e.g. with Protocol on the fly),

at service level ( downloading the full Applications),

at identity level (relating to the hyperty-identity association).

Applications can provide communication service in an anonymous way. If so, the parties involved should be clearly warned that the other parties are anonymous and/or untrusted parties.

Applications may execute logic remotely, as website pages do, or at the endpoints, on the devices, as native software clients do. In either case, the application can access the CSP’s communication facilities, and interact with the hyperties on the device.



3.7.3 Monitoring Presence, Availability and Context

Applications often require knowledge of user presence and availability, and need to establish context for the requested service. In the reTHINK architecture, one possibility is to assign a separate service (implemented as a hyperty), running in end-user’s device, that is in charge of providing and publishing user’s context, using different sources. The Domain Registry of this Service Provider will store this information against the relevant hyperty instance. The user context topic should be secured against non-authorised users. Other end-users (or functional elements) interested in this information, will need to obtain authorisation from the IdP functional element. If authorisation is granted, a user context listener will be registered into user context topic.

In reTHINK, users’ availability is reflected by their hyperty instances being registered on their CSP’s Domain Registry. It is immaterial whether the destination user is logged on to another communication service, VoIP website or native applications, because compatibility is achieved by downloading the same software as used by the calling party. Hence, user availability is recognized by the running hyperties, of any reTHINK CSPs.



4 ReTHINK Innovative Instruments

The reTHINK project is formed to explore new mechanisms that empower the endpoints in peer-to-peer communications, while providing compatibility that does not require rigid rules and many years of standardisation. In particular, the reTHINK solution is constructed around two software instruments: Hyperty and ProtoFly.

4.1 The Hyperty (Hyperlinked Entity)

Hyperties are cooperative Microservices [107] that are executed in devices on behalf of users through simple but sophisticated Identity Management techniques. This means, Hyperties are independently deployable components each one providing a small set of business capabilities, using the smart endpoints and dumb pipes philosophy i.e. Hyperties don't depend on complex and sophisticated communication middleware like Enterprise Service BUS (ESB). Instead, Hyperties rely on a very light but powerful decentralised Messaging Framework concept. On the other side, Hyperties follow emerging Edge and Fog computing paradigms as opposed to more popular Cloud Computing. Hyperties can also be executed in Network Servers for specific Business Capabilities (e.g. Media Servers) or when End-user devices don't have enough capabilities in terms of computing resources and/or power.

The hyperty software is the code to be deployed, which is created and maintained by the CSP, and the hyperty instance is the running code, which is dynamically downloaded to the endpoint.

The main characteristics of hyperty, as shown in Figure 8. :

It is a Reusable Script implementing a Service Logic (e.g. a JavaScript file). If Javascript is used, any existing device featuring a Browser or a NodeJS can be used today to execute Hyperties without requiring the installation of any new software. This means, billions of devices are already Hyperty enabled and ready to participate in the reTHINK ecosystem. The Hyperty Core Runtime, provides additional features not natively supported by current Web Runtimes that are required to safely manage the deployment and execution of Hyperties. The Hyperty Core Runtime is also programmed in Javascript ECMA5/6 and is deployed on-the-fly along with the Hyperty if not done before.

The User Identity associated to an Hyperty is decoupled from the Hyperty Service Provider. I.e. Identity Management is handled under the scene and the Developer does not have to care about it and just have to focus on the development of Business Capabilities. This also means, the end-user has the power to decide which is the Identity to be securely associated to a certain Hyperty instance. Users associated to Hyperties can be Human beings, physical objects, physical spaces, organizations. The User can be anonymous in some cases. If the hyperty is instantiated to provide backend or middleware service it can be associated with the service provider (organization, for example if it provides a Network service).

Hyperties are inhenterly inter-operable by using a decentralised communication framework thanks to the protocol-on-the-fly concept and to the P2P Reporter-Observer pattern. (put link section here)

http://martinfowler.com/articles/microservices.html

https://github.com/reTHINK-project/specs/blob/master/tutorials/hyperty-messaging-framework.md

https://en.wikipedia.org/wiki/Edge_computing

https://en.wikipedia.org/wiki/Fog_computing

https://github.com/reTHINK-project/specs/blob/master/runtime/readme.md

https://github.com/reTHINK-project/specs/blob/master/runtime/readme.md



Figure 8. Hyperty related concepts

A User registers (enrols or subscribes) to a Service Provider to be able to use it. This is done once. When the User logs in to the service, it creates a service instance (hyperty instance) that registers into the registry, for the duration of the User staying logged on.

When compared with other Communication Service Frameworks, Hyperties provides a few unique advantages:

Hyperty reinforces modular structure, which is particularly important for larger and complex Applications.

Hyperties are inherently interoperable. Only data formats are required to be standardised to ensure interoperability. No standards are needed for network protocols or for APIs, radically reducing standardisation efforts.

Hyperties uses a simple but powerful Trust model where the User Identity is decoupled from the Hyperty Service Provider enabling the end-user to decide which is the Identity to be used with a certain Hyperty instance.

Hyperties follow edge computing principles, promoting a more effective usage of computing and network resources, as well as decreasing communication latency.

The development of Hyperties and Applications is very easy and flexible, giving the freedom to the developer to select its favourite web framework.

Hyperties can be used on any Application Domain, but they are specially suitable for Real Time Communication Apps (e.g. Video Conference and Chat) as well as IoT Apps.

4.1.1 Example1: WebRTC Conference

As mentioned above, the hyperty is the code to be deployed, and the hyperty instance is the running code. For example a hyperty can be web software e.g. one or more JavaScript files, that can be reused (imported) by Web Applications. A Web Video-conference Application can reuse a Communicator hyperty that runs on top of the WebRTC engine to support Video Conferences between Web browsers. In this example, each Browser involved in the Web Conference will have a hyperty Instance that communicates with other remote hyperty instance for the Video Conference.



Figure 9. Hyperty Web Conference Example

4.1.2 Example 2: WebRTC Multiparty Conference in a Star Topology

This is an extension of Example 1 but for Multiparty Web Conferences in a star topology i.e. each party has a peer connection established with a central media server supporting MCU/SFU features. In this example, besides the hyperty instances running in each party browser there would be Network Server Hyperty instance running in the Media Server providing focus related functionalities. It should be noted that fully meshed multiparty conferences can also be supported without any server side hyperty instances, only with end-user hyperty instances (basically, example 1 but with more than two parties). However, this has various limitations regarding the numbers of connected parties, mixing the media, devices’ processing capacity and supporting multiple ports.

Figure 10. Hyperty Multiparty Web Conference Communication Example



4.1.3 Example 3: Contact List enriched with Presence Status

A WebRTC Application featuring Contact Lists with presence can reuse a Context Producer hyperty instance to collect and publish End-User presence status. On the other hand, the Web App reuses one or more Context Consumer Hyperty instances to listen and update presence status of users in the contact list.

Figure 11. Hyperties Example for Presence Enriched Contact List

4.1.4 Example 4: Data Processing in the Cloud

A Context Producer hyperty Instance collects data from end-user device sensors and publishes it to the cloud where Data Analytics Apps uses Consumer Hyperty Instances to process it, according to some algorithm.

Figure 12. Hyperties Example for Data Processing in the Cloud



4.2 Decentralised Communication Framework

Hyperties communicate each other with a Resource Oriented Messaging model implemented by a simple Messaging Framework. The Hyperty Messaging Framework, supports different messaging patterns including publish/subscribe and request/response messaging patterns. The higher level Reporter - Observer communication pattern works on top of these basic messaging patterns.

The Message delivery is based on a simple message Router functionality where messages are delivered to all found listeners, which can be other Routers or end-points (Hyperties). Thus, the Hyperty Messaging Framework is comprised by a network of Routers where each Router only knows adjacent registered Routers or end-points.

Listeners are programmatically registered and unregistered by Routing Management functionalities, which decide the listeners to be added according to a higher level view of the Routing Network.

The Messaging Framework works at three layers:

At the Runtime Sandbox level where Hyperties are executing.

At the Runtime level where Sandboxes are hosted (e.g. in a Browser or in a NodeJS instance).

At Domain Level, message delivery is provided by the Message Node functionality by using the Protofly mechanism, i.e. communication between Message BUS and Message Nodes and

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/routing-network.png

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/routing-management.png



among Message Nodes are protocol agnostic. This also means that the Message Node can be provided by any Messaging solution as soon as there is a Protostub available.

At runtime level (MessageBUS and MiniBUS), it is used a standard CRUD based JSON Message Model, which is easily mapped into Restfull APIs (reference to message data model section).

4.3 Protocol on-the-fly (protofly) and Protostubs

Protocol on-the-fly leverages the code on-demand support by Web runtimes (eg Javascript), to dynamically select, load and instantiate the most appropriate protocol stack during run-time. Such characteristic enables protocols to be selected at run-time and not at design time, enabling protocol interoperability among distributed services, promoting loosely coupled service architectures, optimising resources spent by avoiding the need to have Protocol Gateways in service's middleware as well as minimising standardisation efforts. The implementation of the protocol stack, e.g. in a javascript file, that is dynamically loaded and instantiated in run-time is called Protostub:. For security reasons, Protostubs are executed in isolated sandboxes and are only reachable through the Runtime MessageBUS and the Protostub Sandbox MiniBUS.

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/mofly.png

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/protofly.png



4.4 Protocol-on-the-Fly (ProtoFly)

The Protocol On-the-fly concept extends the Signalling On-the-fly (SigOfly) concept introduced in WONDER project [74] to handle WebRTC Signalling to any other service domain where protocol stacks can be executed in a Web Runtime (e.g. protocol stacks can be implemented in JavaScript).

Thus, ProtoFly concept supports the code on-demand facility on Web runtime (e.g. JavaScript), by dynamically selecting, loading and instantiating the most appropriate protocol during runtime. Such characteristic enables protocols to be selected at runtime and not at design time, enabling protocol interoperability among distributed services, promoting loosely coupled service architectures, optimising resources spent by avoiding the need to have Protocol Gateways in the services middleware as well as minimising standardisation efforts.

4.4.1 The ProtoFly Interfaces

Implementation of ProtoFly involves the following concepts:

Protocol Stub: The implementation of the protocol stack e.g. JavaScript file that can be dynamically loaded and used to support interoperability between distributed services.

Messaging Services: Services that are provided by the service provider’s domain server to route messages between distributed hyperties and other network-side services.

Communication Hyperty Messaging Server: A server within the communication hyperties that supports the exchange of messages between the distributed services as well messaging towards the CSP platform.

The different types of interfaces supported by ProtoFly are:

ProtoFly Domain Message Interface: the communication channel that is established with domain’s messaging server as soon as a domain‘s user is logged in;

ProtoFly Transient Message Interface: the communication channel that is established, typically with a foreign messaging server (i.e. from another domain) for inter-domain service interoperability;

ProtoFly P2P Messaging Interface: a P2P communication channel that is directly established between two distributed services without using any core Message Services in between.

ProtoFly Client-Server Interface: a communication channel between two distributed services without using any core Message Services in between, supported on a Client-Server protocol e.g. HTTP REST Interface.

The different ProtoFly types of interfaces are depicted in Figure 13. :



Figure 13. ProtoFly Interfaces

Besides the WebRTC Signalling Use Cases via a Message Services that are supported by the SigOfly, the ProtoFly can also support the following Use Cases:

WebRTC P2P Signalling using a ProtoFly P2P Messaging Interface

WebRTC IdP Proxy using a ProtoFly Client-Server Interface to support communication with a remote Identity Management Server.

Service Registration and Service Discovery using a ProtoFly Client-Server Interface to support communication with a remote Registry Server.

4.4.2 Main ProtoFly Procedures

To illustrate the procedures, the classic Alice and Bob example is used, assuming that they are already registered in different Service Providers’ domains that are compliant with the reTHINK solution. In the case where Alice wants to talk to Bob by using Bob’s identifier e.g. [email protected], the following steps will be performed:

Information about the Identity of Bob including Bob’s Protocol Stub URL is provided and asserted by Bob’s IdP,

Alice downloads and instantiates Bob’s Protocol Stub in her browser to setup a Transient Channel with Bob’s domain Messaging Service,

Once the Transient Message Interface channel is established, Alice can send an Invitation message to Bob containing her SDP offer,

Since Bob is connected in the same Messaging Service via his Domain Message Interface channel, he will receive Alice’s invitation in his Browser. If Bob accepts the invitation, a message containing Bob SDP response will be send to Alice.

As soon as Alice’s browser receives Bob’s SDP, the media and/or data streams can be directly connected between the two browsers.

mailto:[email protected]



Figure 14. ProtoFly for H2H Communication hosted by called Party

This scenario implies that the conversation is hosted by the called party by using its Messaging Services. This requires consent to download the protocol stub before the user is known or verified. It also means that the called party domain is spending more resources than the calling party domain. In case this solution is not acceptable, conversations can also be hosted by calling parties. The main differences are:

An endpoint notification service, as is supported on the emerging IETF/W3C Web Push protocol, is asserted by Bob’s IdP, and is used to push an invitation message towards Bob device,

The Identity of Alice, including Alice’s Protocol Stub URL, is provided by Alice and is asserted by Alice’s IdP,

When Bob accepts Alice invitation, Bob downloads and instantiates Alice’s Protocol Stub in his browser, to setup a Transient Message Interface channel with Alice’s domain Messaging Services,

As soon as the Transient Message Interface Channel is established, Alice can send Bob her SDP offer, and Bob can respond back to Alice with his counter-offer SDP.

Since Alice is connected in the same Messaging Service via her Domain Message Interface channel, she will receive Bob’s SDP and the media and/or data streams via the directly connected two browsers.

https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

https://github.com/hypercomm/wonder/raw/master/docs/images/signalling-on-the-fly.png



Figure 15. ProtoFly for H2H Communication hosted by calling Party

4.5 P2P Data Synchronisation: Reporter - Observer Model

The usage of Observer models in Web Frameworks (eg ReactiveX) is becoming very popular. However, current solutions require server-side databases that are not compliant with edge computing Hyperty principles.

Hyperty Reporter - Observer communication pattern goes beyond current solutions by using a P2P data stream synchronisation solution for JSON Data Objects, here called Hyperty Data Object or Sync Data Object. To avoid concurrency inconsistencies among peers, only one peer has granted writing permissions in the Hyperty Data Object - the Reporter hyperty - and all the other Hyperty instances only have permissions to read the Hyperty Data Object - the Observer hyperty.

The Hyperty Messaging Framework allocates to each new created Hyperty Data Object a Global Unique Identifier URL that is independent from the Hyperty instance creator and from the Hyperty Runtime, in order to support mobility of the Data Object between different Hyperty Runtimes and also to support delegation of the Reporter role to other Hyperty instances. However, at this point Reporter delegation is only supported between Hyperty instances from the same domain.

Each Hyperty Data Object is formally described by a JSON-Schema that is identified by a Catalogue URL. This allows to check whether two different Hyperties are compliant by cross checking each supported Hyperty Data Object schema. At this point the following Hyperty Data Object schemas are defined:

Connection Data Schema : Hyperties supporting this schema are able to handle WebRTC Peer Connections between the Hyperty Runtime instances where they are running

http://reactivex.io/documentation/observable.html

https://github.com/reTHINK-project/specs/blob/master/datamodel/connection

https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC

https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC

https://github.com/hypercomm/wonder/raw/master/docs/images/Conversation Hosted by calling peer.png

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/reporter-observer.png



independently of the signalling protocol used. The URL Scheme for Connection Data Objects is "connection" (example: "connection://example.com/alice/bob201601290617").

Communication Data Schema : Hyperties supporting this schema are able to handle different communication types including Textual Chat, Audio, Video, Screen Sharing and File sharing. Such communication can be supported on top of WebRTC protocol streams by using the Connection Data Schema. The URL Scheme for Communication Data Objects is "comm" (example: "comm://example.com/group-chat/rethink201601290617").

Context Data Schema : Hyperties supporting this schema are able to produce or consume Context Data, usually collected from sensors. The URL Scheme for Communication Data Objects is "ctxt" (example: "ctxt://example.com/room/temperature201601290617").

In order to allow use cases like Group Chat where all involved Hyperties are able to write in the Sync Data Object, the Parent - Child Data Sync Objects is introduced.

A Data Object Child belongs to a Data Object Parent children resource and can be created by any Observer of the Data Object Parent as well as by its Reporter. The Reporter - Observer rules still apply to Data Object Child i.e. there is only one Reporter that can update the Data Object Child, which can be an Observer of the Data Object Parent, as mentioned earlier.

The creation, update and delete of an Data Object Child is performed in the Data Object Parent itself:

All other Hyperties observing or reporting the Data Object Parent, will be notified every time a new Data Object Child is created, updated or deleted:

https://github.com/reTHINK-project/specs/blob/master/datamodel/communication

https://github.com/reTHINK-project/specs/blob/master/datamodel/context

https://github.com/reTHINK-project/specs/blob/master/messaging-framework/parent-child-sync.png



5 Identity Management

The concept of independent user identity is crucial to the reTHINK idea. A user identity that is represented by a particular identifier gets linked to a specific communication hyperty that is running in the user’s currently used device, however, the same identifier may be used on other devices. Unlike the traditional mobile identifier that is attached to the SIM card, this association is not limited by firmware or device type. Multiple user identifiers may be used by multiple communication hyperty instances on multiple devices.

The reTHINK paradigm of placing service logic and data as close as possible to the user is enhanced by the reTHINK identity management principles that require user identifiers to be independent of the hardware, the service provider and the application, bestowing greater control and flexibility upon the users themselves. This reTHINK identity management allows users to choose what identity to use and which IdP to subscribe to.

When a user registers a particular identity from a particular device (perhaps every time the browser is started or the device is turned on), having subscribed to the preferred IdP, the user endpoint receives a token that asserts the user’s authentication. This token can be sent to the CSP or remote (destination) CSP, or any enquiring parties who wish to communicate with this user. This minimises the need to have intensive communications between Service Provider and IdP and optimises usage of network resources by promoting local transactions at the user device.

5.1 Identity Management Concepts

5.1.1 Identifiers

User Identity can be determined by different kind of identifiers: email, webID, OpenID, URL, mobile phone number or any other global identifier, and may have several authentication factors. User directories and registries gather the reachable identifiers of associated identities.

Identifiers are translated into endpoint addresses through the discovery phase (see §3.6.3).

5.1.2 IdP Design Assumptions

The IdP functionality includes:

Authenticate a user for the benefit of CSPs and ASPs, and also for applications

Provide a user and/or his hyperty instances (or more precisely the runtime they run on)with identity assertions (tokens)

Check the validity of identity assertion on user request

It may also include some trust-related features:

Assert to a service provider that a given user identity identifier is valid

Assert to the user agent that the requested service provider is bona fide

Provide to a user agent the appropriate service provider to connect to

Provide to a user agent who the destinations’ IdP is (IdP service brokering)

Discover on behalf of a user agent the destination address and domain name.

For the reTHINK project, the following is assumed:

The IdP does not maintain availability on a particular device.

An IdP may provide registration service for the Service Provider, If hyperties log on the IdP when they are launched.

The IdP service can provide a hosted authentication service.

The IdP provides a guarantee of trust for the Service provider to the users.



In reTHINK, the End-User chooses the IdP, regardless of the service used.

Several business models for IdP operation can apply.

Identity Management included in an Application/Service can provide Authorization features.

IdP may provide a service to allow for transient user registrations, anonymous users, or non-registered services that are nevertheless bona-fide. Users and services provide their own information, but they cannot be trustful unless the information is verified by independent, reliable sources. Trust must also exist in the IdP service. Such IdP qualification may be provided by separate reputable organizations or Authorities that certify IdPs.

IdP already provides a stable URL that indicates only the domain, which then needs to be resolved to a current IP-address by a service similar to DNS. Since DNS, and even ‘Dynamic DNS’, cannot cope with mobile connectivity, the reTHINK solution proposes the concept of the Domain Registry, which is maintained by on the CSP core platform. The Domain Registry maintains the association of user identifiers with the current IP address of the communication hyperties, which are registered when the user logs in, and are de-registered when the user logs out or the device is turned off. Hence, the Domain Registry is effectively the CSP’s location manager.

To achieve domain-independence a thus global reachability and portability (i.e. the user may switch CSP or IdP at will) reTHINK fosters an additional layer of identifiers: the GUIDs (Global User IDentifiers). As aforementioned (see §3.6.2) this life-stable identifier encompass all domains and enable global discovery of the user. It is also used as a basis for the distributed social graph built by Graph connector (see §5.2).

This option requires the deployment of a distributed Global Registry that maintains stable associations of GUIDs with their respective user domains, without knowledge of their devices or current locations, while the dynamic location management of hyperties is processed on the CSP core platform. This means that the CSP, who has strong motivation to maintain the Domain Registry to a high level of performance, can manage IP locations for its own users, and respond to the interrogation of the Domain Registry for any incoming service requests.

5.1.3 Identity at the Endpoint

For hyperties to be instantiated and attached to an end user we need some component dealing with identity management at each network node. This identity module should be controlled by the appropriate end user, who can choose which identity should be used in the service being instantiated. It will also store some security tokens provided by IdPs, therefore should have access to some secure storage area: ideally in a physical vault, when available.

More specifically, for hyperty instances running on the device, an Identity Module should be deployed to enable the end user to choose the identity and store credentials and/or identity tokens. It may also be a placeholder for some user- or service-defined policies: for instance restricting identity choice based on usage type (sensitivity, context, etc.).

This Identity Module may gain some more value by having some autonomy features:

it may be usable offline;

it may also provide some privacy enhancements by preventing IdPs to monitor any hyperty instantiation.

On the other hand some isolation between processes and identities attached must be maintained by the runtime to prevent security breaches and privacy threats. Here again, availability of a physical security element will provide better functionality.



5.1.4 Identities when switched off

If the user is ‘at rest’, i.e. not using any application, and if the user has not registered to any CSP, then there is no activated hyperty, and incoming requests to communicate will remain unanswered. Furthermore, if there is no record of a registered user, unanswered calls will not be logged. To avoid this, the device client should register as soon as it is switched on.

5.2 Graph Connector

Hyperty instances allow users and services to communicate with each other. Therefore, managing a list of known communication endpoints would allow users to stay connected to other users, independently of their affiliations, location or context. Maintaining such a local address book would further allow users to specify access permissions in access control lists (ACLs), in order to allow or deny access to particular personal information, e.g. one’s current location. In this context, each hyperty instance can be viewed as a part of a (social) graph.

However, the hyperties do not remain at the same address, and users may change their domain or their chosen Identity Manager. In addition, users may have several devices, hence several possible hyperties to connect to. These devices are portable and have no stable IP address.

Therefore, it is proposed that the mechanism of graph connector, as for social networks, can be used to provide a connectivity view of the user, and enable users to maintain addresses of friends and colleagues. It relies on the aforementioned GUID (see above §3.6.2).

One GUID can thus be associated with multiple live hyperties, so GUIDs are linked. To prevent fraudulent usage of GUrIDs, its generation relies upon a public/private key pair that is created the first time a user wants to use the reTHINK architecture.

This graph vision encompasses human actors and connected things. Figure 16. gives an example of forming GUID between users and objects.

Figure 16. Linking GUIDs on a Graph Connector

The graph is stored in a distributed manner with the entities of the graph themselves: each entity knows its own connections – similar to an address book or a contact list. However, the graphs are connected via the ‘Graph Connector’, to form a greater community of linked hyperties. The idea of the graph connector is to enable online social networking capabilities via the live hyperties, which is preserved even after the hyperties are terminated and re-instated. For example: Smartphone users can store their social profile on their device, and the graph connector with unique GUIDs can be used set up access control policies for that profile. Figure 17. visualizes the dependencies between Discovery, Hyperty Registry, and Graph:



Figure 17. Discovery and Registry using Graph Connector

The general idea is the following:

To connect to new or unknown entities: use Discovery that will use Registry services to map to current live hyperty instances

To connect to known entities already being in relation via the Graph: lookup current connection details in the Registry.

5.3 Server-side identity

If the Server is using a runtime then it can use the same approach used in the device runtime. The Identity Module calls an identity selection method. This method receives a list of possible Identities to be used and returns the selected one. Moreover the user can also define the default identity to be used. The same approach can be used in the server (if a user interaction exists to select an identity). If no interaction is to occur, then a default identity must be defined from the start. In this case no user interaction is needed.

5.4 M2M/IoT Identities

The difference between H2H and M2M communications is essentially the difference between human identities and machines. The communication procedures may be the same, but there are variations in the way the identities and the service features are handled.

Both humans and objects may be seen as users of the frameworks, and thus all may be referenced through domain-bound identities or GUIDs.

5.4.1 M2M connector

Additional context, e.g. deriving from M2M devices such as sensors or actuator, may be provided as raw information or accumulated / processed data to other parties. For such cases, a M2M connector may be provided as a SNS, achieving the integration of any M2M device within the reTHINK architecture.

Registry

Graph Discovery

finding people/things by search termsreturns GUIDs then endpoints URLs

stored on devices (distributed)connections between entities

enables online social networking features

resolves GUID to service-bound identifiers (Global Registry) then endpoints URLs (Domain Registry)



The M2M Connector enables any M2M device (sensor or actuator) to be integrated within reTHINK framework. It covers mainly three functionalities:

Device management: to manage device configuration, reachability and possibly software update.

Connectivity management: to enable the interaction with the device following reTHINK approach and to interwork with the device (sensor and actuator) according to its technology and protocol adapters.

Security and privacy management: To manage and evaluate access control request for retrieving collected data or for interconnecting to a dedicated actuator.

The M2M connector can be deployed on the edge (e.g. as an M2M gateway or as end-user device) or on the backend as Network Specialised Device. The connector may represent one device or a collection of devices. The security and privacy functionality is performed from local perspective rather than from reTHINK global perspective.



6 Service Delivery and Interoperability

In this section, service delivery procedures and stakeholders interactions are described. The interoperability of the various architectural functions and their stakeholders is discussed, identifying potential issues and seeking resolutions.

6.1 Application Interoperability

Based on the main functional elements and concepts described above, this section describes the ways it is put into practice. To best illustrate, we tried to use the reTHINK use case scenarios. Figure 18. depicts an overview of the interaction between the management services and Application using hyperty instances. Here an application is first discovering the endpoint to communicate and the hyperty to install.

Figure 18. Interaction between applications, hyperties and management services

6.1.1 Application Interoperability

The reTHINK project supports the idea to simplify interoperability by adopting a simpler way, which is radically different from the methods used in the Telco world, as it is explained in [2].

In the real time communication services world, interoperability is usually illustrated by the simple Use Case “Alice Calls Bob”, when Alice and Bob are not using the same communication service provider. We could generalize the question to “how a service A could reach and interoperate with a service B”, as the hyperty framework may provide further features than mere Voice communication.

We have identified three types of interoperability that affect the user experience and the architecture. These options are presented and discussed in [75]. To illustrate this in reTHINK, we consider the mentioned above “Alice calls Bob” use case, assuming that Alice has already discovered a reachable identifier for Bob, and that Bob’s service provider (or domain) is known (or given in the identifier). Alice’s service provider is “A”, and Bob’s service provider is “B”. Then Alice calls Bob. The three possibilities are:

Case 1: Alice is temporarily enrolled on or using service B

Case 2: Alice uses protocol on the fly to integrate B into A



Case 3: A and B are fully interoperable

Two services may use the same signalling technology or language but provide different or even incompatible services. Signalling interoperability requires both parties to use the same language to communicate. Service interoperability means that the same features are provided to both parties. Signalling interoperability is essential to having any contact with the other ‘side’, while service interoperability can be negotiated and compensated, or at least report on failure.

6.1.2 Case 1: Temporarily Enrolling or Using Service B

Alice is normally using “A” application, and Bob is enrolled on “B” application. In the OTT style, in order for Alice to communicate with Bob, she must be using “B” too, and get Bob to be registered on Alice’s contact list for application “B”.

The proposal here is different: Alice doesn’t need to enrol on “B” service. Alice finds Bob and his service; she follows the link to be able to join Bob on “B” Service. Two possibilities can be seen:

“B” Service is reached through a Web Page (server executed or JS client execution – this is transparent to the user). Alice can connect on this page and try calling Bob. This is a “Come in to my Home” way for Bob to be joined.

Second possibility, “B” Service needs a client to be downloaded (this can be the case on a mobile). Alice downloads the application client and uses it.

For both possibilities, Alice uses her own IdP for authentication, and is authorized automatically – possibly temporarily - on the “B” service. This is possible if the IdP and the Services are using a protocol such as OpenID Connect, and if the Services and the Users authorize it.

Case 1 allows for a user to be contacted and keeps the user-chosen application with complete set of features, as if you invite someone to your home: your guest may not like your wallpaper but you don’t change it for him/her. Concerning IoT, this allows to automatically getting any kind of feature. The only interoperability needed is at the identity authentication/authorization layer.

Figure 19. Case 1, Identity interoperability

This case raises some Issues for further investigation:

How would Alice know which application, if Bob uses several of them?

Media

Bob device

Alice device

Back ends

B

A

a

b

b

The hyperty B can either be downloaded or just accessed through a web page



How can temporary joining of an application be performed?

Users may have to adopt many unwanted applications

Users will need to operate different applications, without time to learn how to use them.

6.1.3 Case 2: Protocol on the Fly to integrate B into A

Alice connects to “A” service, and “A” calls “B” Service through its interface. This is possible because “A” and “B” Services are compatible with the reTHINK architecture and compliant with reTHINK “protocol on the fly” mechanism, as described in [74]. This means that the “B” service provides a specific API that enables downloading its signalling stack.

From Alice point of view, nothing specific happens, and she reaches Bob as if Bob was a user of “A” service. Bob is reached through his own interface as if Alice was a user of “B” service. The features provided during the communication will be a common set of features that are provided by “A” and “B” services. For example: “A” service is providing IM, Voice, and Video, “B” service is providing Voice and document sharing. The only possibility of communication will be Voice (other possibilities will be disabled).

Case 2 allows for a User to connect to any of his contacts with the same user experience. No common protocol standardization is needed (thanks to protocol on the fly), but a set of typical features has to be defined and shared. If the called service has a rather different set of features, it is not likely to work. For example, if Alice calls a temperature sensor with her phone, even if the communication is established, the exchanged data will not be interpreted correctly.

Figure 20. Case 2, Interoperability with protocol on the fly

This case raises the following issues:

Protocol on the fly cannot sort out features that are delivered differently by different applications, even for the common set of functionalities that appear to be similar.

It is not reasonable to assume that any applications can provide downloadable clients for un-enrolled members.

Alice QoE - she needs to learn Bob’s application for the sake of this session interaction (but it is better than asking the called party to do that).

The IdP independence does not remove the need for the applications service provider to have ‘accounts’ per user, but it helps to accept anonymous (but trusted) temporary users.

Media

Bob device

Alice device

Back ends

B

A a

b

b

B signalling stack is downloaded in A to ensure interoperability



6.1.4 Case 3: Fully interoperable A and B

Alice connects to “A” Service and “A” Calls “B” service from the Server side. Bob is joined by Alice through his service in a Server to Server fashion. This is implies that “A” and “B” service providers have a common communication protocol (possibly through APIs).

The features provided during the communication will be the common set of features that are provided by “A” and “B”. Example: “A” service is providing IM, Voice, and Video, “B” service is providing Voice and document sharing, the only possibility of communication will be Voice (other possibilities will be disabled).

The Case 3 allows for a User to contact any of his contacts with the same user experience. A common protocol standardization (or set of APIs) is needed, and a set of typical features (through a common grammar) has to be defined. It is likely that the Services “A” and “B” have a close type of features if they already made the effort of connecting their back ends, or if not they may have bridged some of them (for example video stream used as document sharing). Another possibility is to use protocol on the fly between two servers that would go back to case 2.

This case requires all applications to conform to standardization of features. It also requires applications to agree to collaborate.

Figure 21. Case 3, Interoperability between servers

Media

Bob device

Alice device

Back ends

B

A a

b

Communication by peer but possibly through a media relay (for example for legacy interconnection)

A common connector has been designed to setup the call, or ProtoFly may be used



6.1.5 Summary of Use Cases

The following table summarizes the three cases and their characteristics:

Table 6 Interoperability Cases

Case 1 Case 2 Case 3

Service Interoperability No Negotiation Negotiation

Signalling Interoperability No Yes Yes

Comment Alice is using B with Auto/Temporary Enrolment

Alice is using A Alice is using A (State of the art, Matrix.org…)

The reTHINK aims to support Case 1 and Case 2 interoperability approaches, exploring new ways of achieving interworking, even if the results are not perfect and the users’ QoE is not the highest. Such an approach is justified by the success of various web based offerings that have been hugely popular, despite such weaknesses. However, Case 3 represents the traditional approach, which is out of scope since it requires fully standardisation of features and protocols at the service layer, which is not explored here.

6.2 CSP to CSP Interoperability

6.2.1 CSP to CSP Interoperability

While it is not entirely ruled out that CSPs communicate between them (server-side), the general reTHINK approach is to devolve as much as possible to the endpoints. However, there may still be occasions that require reTHINK CSPs to communicate server to server. Such cases may include:

Transferring usage reports and CDRs to the destination CSPs,

Some system notifications as a result of interaction with the CSP’s hyperties,

Some service feature interactions.

6.2.2 User Discovery Services

The User Discovery Service enables finding users across any IdP globally: it is agnostic of domains. It may rely on service/hyperty registries (instances lists); however these are distributed over different service providers.

Discovery services may be provided by several entities. For instance, it is likely that IdPs would provide user discovery service.

For “Alice calls Bob” scenario, the process could be:

1. Alice uses the discovery service to get a list of CSP where Bob is enrolled and a set of relevant identifiers (which can be obfuscated).

2. Alice chooses one of these identifiers and requests a list of running hyperty instances from the appropriate registry.

3. Alice starts communicating with one of the found hyperty instances.



Figure 22. Discovery service dynamic view

6.2.3 Global Registry

The Registry at the CSP core platform contains current login registrations that represent the presence of users on the network and their availability to receive incoming communications. It is proposed to conduct the search for destination users via inter-Registry links, forming a ‘global Registry’ for all reTHINK compatible CSPs.

In order to look up other users and to get in contact with them, some kind of directory service / lookup service is needed, as described in [46]. Because it should be able to look up any registered user, we use the term “Global Directory” see Figure 23. . It can be seen as similar to a DNS, but instead of IP addresses for domain names, users can look up contact information by hyperty IDs. To offer services like search, recommendations, and discovery to users, data about the users is needed. We imagine different directories that perform such tasks (“distributed directories”). User can publish data to such a directory, which in turn offers search, recommendations and can serve as a creator of groups within the context- and location tier social graph.

Global Directory

Decentralized Directory

Decentralized Directory

Look Up Users

InteractionInteraction

Publish Context/LocationRegister

Search

Recommend Create Context-Tier orLocation-Tier Groups

Look Up Users Look Up Users

...

Figure 23. Architectural Approach for realizing the three-tiered view of the social graph; from [46].



Further study is required to ensure that such a search requires minimal inter-domain interactions, and is fast enough to support real-time communications.

6.2.4 Session Reports and CDRs

It is assumed that storing session information as a record of usage is still desirable, whether the user is billed or not. Usage records are used for capping, for example. The CSP needs CDRs for reporting to partnering web apps, and web apps need them for their relationship with the user. Records of usage are also crucial to user behaviour analysis and marketing/ advertising decisions. While it is conceivable that the next few years will not alter the current trend of providing free-of-charge services on top of subscription fees, user data records still represent valuable assets that are used for advertising and information mining. Hence, CDRs or their equivalents are still required to be logged, reported and stored.

With communication hyperties running in the endpoint in full P2P mode, the CDR production must rely on the endpoint to notify end of session. This may be open to fraud and abuse. Alternatively, event reporting may be possible between the media node and the CSP communications, which will provide information on the session ending.

A CDR is produced when the terminating time is recorded. The termination of the connection is observed at both endpoints, hence it is possible for the destination hyperty to create the CDR locally. This, however, may be open to abuse, especially if such CDRs are used in charging. Another option is to seek notification of end-of-media-flow from the nearest media gateway. However, this involves special logic at the gateways, or CDR storage on them.

Lack of CDRs at the destination is demonstrated by the call flow in Figure 24. :

Figure 24. Destination service provider’s awareness of sessions

A server-side solution for providing CDRs to the destination CSP is possible, where CDR creation is performed server-side, at the calling party’s CSP, and the CDR is transferred to the destination domain. The transfer can be executed without setting standards and protocols, by means of ProtoFly or by means of a simple file transfer. Once the destination domain CSP receives the CDR data, it can utilize them or not, at their own discretion. The data interpretation requires the destination CSP to



have the format of the record, which could be conveyed as a data schema, but also commonly utilised CDR structure can be deployed.

Figure 25. shows the call flow for server-side CDR reporting at the end of the interaction between the two parties. It requires the destination hyperty to accept the CDR data before finally hanging up, thus the end-time for the session is given as the calling party’s moment of terminating the connection.

Figure 25. Transferring CDRs by ProtoFly



7 Specialized Network Services and Internet QoS

Specialized Network Services (SNS) are services for communication service providers that are usually provided by NSPs, in access networks and in interconnection networks that carry media. SNS are optimized for specific content and applications, for specific level of quality. Therefore, Specialized Network Services have to be distinguished from Internet access services which are used for various types of content and applications.

Solutions proposed by reTHINK can be divided in several parts:

Specialized Network Services for OTT communication services.

Internet access services optimized for real-time interactions

QoS management for private networks

QoS management services built over internet access services

Different business models can be considered:

Internet QoS (improving the quality in general for NSP customers)

Specialized Network Services on either public or private networks (e.g. Enterprises private network).

7.1 CSP Assumptions

The role of CSP can be adopted by a player providing over-the-top communication service but also by carriers (mobile operators), major Web portals (e.g. Yahoo, Google), or any ASP with user relationships (e.g. eBay, Amazon).

A user can be linked to more than one CSP.

7.2 Specialized Network Services for OTT communication services

SNS comply with the negotiated (by NSP and CSP) network quality level. The SNSs should ensure QoS for a given communication flow, by providing and collecting necessary information.

In reTHINK, QoS is provided to communication services in loosely or decoupled ways: technical and commercial integrations between communication services and networks are minimized or removed.

Beside these (de)coupling aspects, reTHINK establishes QoS engineering practices for the new “OTT” or Web Companies (WebCos) media plane mechanisms. Indeed, compared to previous Telco solutions that assumed non-adaptive media transmission over controlled network conditions, QoS engineering developed in reTHINK is designed for WebCos media plane mechanisms that adapt media transmission to various (and varying) network conditions (i.e. their congestion controls).

reTHINK proposes different solutions to provide SNS:

depending on the business cases,

according to the envisaged relationship between NSPs, CSPs and their clients.

To address the case where the CSP or its clients are primarily in demand of QoS, reTHINK proposes a solution based on an access controlled QoS on shared resources for registered CSP.

It includes:

A QoS broker that isolates the communication service providers in demand of QoS from the complexity of dealing with a large number of network service providers and with associated networking technologies (wireline, cellular…).

Specific QoS treatments depending on the access: o Diffserv for wireline access



o Dedicated bearer for mobile access

Figure 26. access controlled QoS on shared resources for registered CSP

7.2.1 Relationship between NSPs, CSPs and their clients

Each CSP interested in providing this solution of QoS management has to be registered in the Broker database. The Broker can be seen as an intermediate between the CSP and all the NSPs involved in this QoS management solution.

An agreement is needed between the Broker provider and the NSPs. At least, each NSP providing some QoS management has to register its TURN servers to the Broker.

7.2.2 Managing QoS

The general idea is that QoS management is based on shared resources (backhaul, RAN).

According to the access network, QoS management is provided by different ways:

Fixed lines : DSCP marking for media flows and differentiated IP treatments (Diffserv)

Mobile : dedicated bearers for a differentiated treatment at radio level

Access control to Specialized Network Services is realized by the NSP through the Broker. Access control can be based on:

CSP identification: it must be registered and known by the Broker to have rights to request QoS for its clients. A unique identifier is assigned to each authorized CSP and distributed to its clients through the CSP’s Web Application.

Web App identification: as it is handling the CSP’s identifier, the Broker is able to verify that a QoS request from a Web App is allowed or not. The Web App is also asked to provide a specific session identifier (related to the Web App or to the client logged in). This session identifier is stored by the broker and gives the opportunity to trace each single activity of every user for a given CSP.



User identification: when an authorized Web App sends a request to the Broker, the response contains the TURN’s IP address and also the credentials to use for this session. The credentials are dynamically generated for each request and checked by the TURN server when the Web App first contacts it.

7.2.3 Technical interoperability

The broker enables creating a single contact point allowing any OTT communication service provider to request specialized network service from different network operators.

Either for fixed or mobile access, the techniques used for traffic management are the same as for managed VoIP.

Interconnection between NSP is achieved over the open internet: there is no need of any new interface.

Interoperability between the Device or the Browser or an Operating System (OS) on one hand, and the network on the other hand is realized by:

DSCP marking for fixed network,

Dedicated bearer for mobile network.

7.3 Internet access services optimized for real-time traffic

To address the case where the “network service provider” is primarily in demand of QoS, reTHINK implements and evaluates solutions meant to enhance the quality of real-time interactive communications whatever the communication service providers (aka “neutral” solutions).

The types of solutions implemented and evaluated can be distinguished into two groups:

1. A single Active Queue Management (AQM) solution is applied to all flows. Here the AQM setting maximizing the customer experiences for the whole traffic mix (including real-time interactive media, short upstream/downstream TCP flows, long upstream/downstream TCP flows…) needs to be found i.e. the best trade-off between low queuing delay and low queuing losses for the whole traffic mix.

2. A latency loss trade-off type of solution where the service provider indicates to the network whether a flow prefers low-delay at the expense of packet loss or the opposite. The expectation here is to further maximize the customer experience compared to the previous solution, at the expense of a more complex solution.

Figure 27. Internet access services optimized for real-time traffic




With these solutions, no commercial or technical relationship is needed between CSP and NSP.

On the other hand, there is an agreement to find between the NSP and its customers to determine the best settings in terms of customer experience satisfaction.

7.3.2 Managing QoS

1. In case of a single queue, the usual AQM techniques can be used. Therefore, there is nothing to do at the application level.

2. When two queues are used (one queue to optimize the latency and another one dedicated to the throughput), the application must be able to indicate which trade-off between low queuing delay and low queuing losses it prefers to be applied. It implies to find the best compromise regarding the user experience.

7.3.3 Technical Interoperability

To provide QoS management with this solution over several networks, there are two possibilities:

rely on DSCP marking,

use a new approach, for instance SPUD.

7.4 QoS management for private networks

Enterprises see cloud (aka web, aka OTT) communication quality as a hurdle. They should be able to arbitrate the cost/quality of Web and Mobile applications (professional, shadow IT, personal) consuming their network capacities. reTHINK answers this hurdle by empowering Enterprises with control on the QoS to apply on their cloud communication applications. This solution can be named as Per Web App QoS selection by customers on their private network resources.

As opposed to previous technologies, cloud communications rely on technologies (general purpose devices, p2p, encryption, cloud servers) that do not allow the networks to easily identify their flows. This is a major roadblock to apply differentiated traffic management.

“Enterprise policies” and “Mobile device management” solutions allow IT services to customize the web browsers and mobile OS according to the need of the enterprises (security rules, proxy address...). reTHINK proposes to extend those solutions to allow them to control WebRTC flow marking according to the application. This allows the networks to easily identify flows that should benefit from differentiated traffic management.

In order to configure differentiated traffic management in the network, reTHINK relies on the knowledge developed about the interaction between WebRTC congestion control and traffic management capabilities in networks



Figure 28. Per Web App QoS selection by customers on their private network resources


In this case, no commercial or technical relationship is needed between CSP and NSP.

Regarding NSP and its customers, the administrator has to define which applications he wants to prioritize and NSP must be able to provide different level of traffic management policies.

7.4.2 Managing QoS

The endpoints (browsers or applications) must be able to indicate to the NSP which traffic management policy it must apply, under the control of customers (through Enterprise Policies or Group Policies).

7.4.3 Technical Interoperability

The customer must be able to define his policies independently from the endpoints (e.g. by using Active Directories).

7.5 QoS management services built over internet access services

Last Hop Connectivity Broker (LHCB) focuses on last hop connectivity brokerage which is based on dynamically registering end-devices at a LHCB within the reTHINK network architecture in order to hold at the LHCB information about currently available, alternative connection mechanisms to connect the client with the network. The methodology is based on reusing concepts from LWM2M device management which provides a standardized way for the LHCB registration and update functionality independent of network service providers' core components.



Figure 29. Last Hop Connectivity Broker



8 The data Model

The main structures defining the reTHINK data model as presented in the deliverable D2.2 [106] remain valid. This data model designed in the spring and summer of the year 2015 has however evolved to take into account several improvements brought by the efforts of the consortium to develop the prototype of the architecture underlying the reTHINK project. Instead of uselessly recalling the complete model, we focus below exclusively on the variations between the initial data model and the current one by pointing:

the stable components

the modified components

the new components

8.1 The stable part of the Data Model

We find in this category :

The User Identity data model ([106] cf. §5.7 - p.44)

The User Hyperty Account data model ([106] cf. §8.2 - p.96)

The Hyperty Domain data model ([106] cf. §8.3 - p.97)

8.2 The modified part of the Data Model

This class contains:

The Address data model [https://github.com/reTHINK-project/specs/blob/master/datamodel/core/address]

The Catalogue data model [https://github.com/reTHINK-project/specs/blob/master/datamodel/core/hyperty-catalogue] the modifications of which, impact :

o The Hyperty Descriptor data model o The Protocol Stub Descriptor data model o The Hyperty Runtime Descriptor data model o The Data Object Schema data model

The Registry data model [https://github.com/reTHINK-project/specs/blob/master/datamodel/core/hyperty-registry] the modifications of which, impact :

o The Hyperty Instance data model o The Hyperty Data Object Instance data model o The Hyperty Runtime Instance data model

The Hyperty Resource data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/core/hyperty-resource]

The Message data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/core/message]

The Communication data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/communication]

The Connection data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/connection]

The Context data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/context]

8.3 The new part of the Data Model

The project reaches some maturity level leading to the development of the following new components:

The Sync data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/core/data-synch]

The Graph Connector data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/core/graph-connector]

The Policy Engine data model [https://github.com/reTHINK-project/specs/tree/master/datamodel/core/policy]

https://github.com/reTHINK-project/specs/blob/master/datamodel/core/address

https://github.com/reTHINK-project/specs/blob/master/datamodel/core/hyperty-catalogue

https://github.com/reTHINK-project/specs/blob/master/datamodel/core/hyperty-registry

https://github.com/reTHINK-project/specs/tree/master/datamodel/core/hyperty-resource

https://github.com/reTHINK-project/specs/tree/master/datamodel/core/message

https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/communication

https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/connection

https://github.com/reTHINK-project/specs/tree/master/datamodel/data-objects/context

https://github.com/reTHINK-project/specs/tree/master/datamodel/core/data-synch

https://github.com/reTHINK-project/specs/tree/master/datamodel/core/graph-connector

https://github.com/reTHINK-project/specs/tree/master/datamodel/core/policy



9 Interfaces

9.1 General considerations

This chapter gathers and defines the interfaces that will be used by the Hyperties to interact with the different elements of the reTHINK architecture. The interfaces will be defined from a logical point of view and the scope of chapter is not to provide a complete specifications but a high level specification of the interfaces.

The reTHINK project tries to leave open to the implementer the use of one protocol or another. However, we include examples of real protocols which can be used to implement this interface at the application level of the TCP/IP stack.

The real-time interface, explained in 7.7, is different from the rest of the interfaces. It follows the WebRTC media framework and the definition included here is just for informational purpose.

9.1.1 Interfaces with Proto-fly support

Identity Management and Messaging Node interfaces support Protofly. It means that the Hyperty will have to download first a Protostub to interact with these elements of the architecture. This gives a lot of flexibility to the solution at the cost of having extra BW required to download the JavaScript and an initial delay. The Registry interface can potentially use also the Portofly mechanism but the current implementation is not using it.

9.1.2 CRUD operations and roles

CRUD is an acronym which stands for Create, Read, Update, and Delete. It refers to the basic operations that can be done in a data object and are independent from the protocol used to perform them. The interfaces allow modifying data objects on the remote Hyperties so the operations which can be performed over the interfaces can be easily defined as CRUD operations.

For example, a REST API allows doing CRUD operations over a data object stored in a server. The match between the CRUD operations and the HTTP methods used in a REST API is direct: Create is done with a POST method, Read with a GET, Update with a PUT and Delete with a DELETE. There are other protocols which allow to do out CRUD operations. For example, LWM2M/COAP (RFC7252 [34]) is protocol designed to be used on constrained devices which shares the basic set of request methods with HTTP and therefore it allows to do the same operations.

Not all the Hyperties instances should be able to modify any attribute from a data object. That is the reason why different roles where defined for each interface.

9.1.3 HATEOAS principle

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architectures that distinguish them from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. This causes that the options which can be performed over a data object attribute (a resource using REST terminology) will change depending on the status of that resource and the available operations are discovered from resource representation returned from the server.

This principle was applied in the design of the reTHINK architecture as the application and the Hyperties dealing with the Catalogue, Registry and the rest of services will have to discover dynamically properties which will change with the time e.g. the Protocol Stubs supported by a Hyperty.



9.1.4 Resource access

A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. It is similar to an object instance in an object-oriented programming language, with the important difference that only a few standard methods are defined for the resource (corresponding to the standard HTTP GET, POST, PUT and DELETE methods), while an object instance typically has many methods.

Resource is the terminology used in REST API to design the elements over which the different actions can be performed. In the reTHINK Data Model a clear match can be done between JSON objects properties which are defined in the data model and REST resources. This will allow defining a resource access mechanism based on the REST API approach: URLs. It makes possible to define a unique entry point to perform CRUD operations over the JSON objects and its properties that will contain the data in the different services of the reTHINK architecture.

9.1.4.1 Resource model

Resources can be typically grouped into collections. Each collection is homogeneous so that it contains only one type of resource, and unordered. Resources can also exist outside any collection. In this case, we refer to these resources as singleton resources. Collections are themselves resources as well.

Collections can exist globally, at the top level of an API, but can also be contained inside a single resource. In the latter case, we refer to these collections as sub-collections. Sub-collections are usually used to express some kind of “contained in” relationship.

Figure 30. REST resource model

For example, in reTHINK architecture all the Hyperty Descriptors contained by the Catalogue service will be a collection of resources over which different operations can be applied.

9.1.4.2 Defining the URL schema to be used

reTHINK resource model needs to have one and exactly one entry point and this entry point is a URL. The URL of the entry point needs to be known by the elements which will interact with the reTHINK data model through APIs so that they can find and use it. Each collection and resource in the data model will have its own URL. Following industry best practices the recommended convention for URLs is to use alternate collection/resource path segments, relative to the API entry point.



In order to follow current best practices and make the system easily accessible from lwm2m/CoAP protocol the entry point for the URLs will be “/.well-known” in compliance with RFC6690[45] and RFC5785[46].

The pattern below is proposed to be used within reTHINK architecture to access resources:

URL Description

/.well-known The well-known API entry point

/.well-known /coll1 A top-level collection named coll1

/.well-known /coll1/id The resource id inside collection coll1

/.well-known /coll1/id/subcoll1 Sub-collection subcoll1 under resource id

/.well-known /coll1/id/subcoll1/subid The resource subid inside subcoll1

9.1.5 Adapting the REST API to constrained devices.

In order to support M2M use cases, reTHINK must be able to interact with constrained devices. To achieve that, it is necessary to adapt the reTHINK Representational State Transfer (REST) architecture in a suitable form for the most constrained nodes can be used to interact with constrained devices.

Constrained Application Protocol (CoAP) is a software protocol intended to be used in very simple electronics devices that allows them to communicate interactively over the Internet. It has been standardized by the CoRe WG is working on several draft to enable HTTP/COAP interoperability in order to make possible that REST API cab be used in constrained devices. The draft Guidelines for HTTP-CoAP Mapping Implementations are especially applicable to reTHINK project as they define the guidelines to map HTTP to COAP, so it makes that any API accessible from HTTP is accessible with COAP open it to constrained devices. This document also defines the mapping between HTTP and COAP URIs.

In the Chapter 7 an example of adaptation of the Catalogue interface is done as an example of the process to adapt other interfaces to be compatible with OMA LWM2M 1.0 which is a protocol from the Open Mobile Alliance for M2M or IoT device management used with COAP.

9.1.6 reTHINK interfaces

The diagram below show the main interfaces of reTHINK architecture that will be defined in this chapter.



Figure 31. General Architecture Diagram

9.1.7 Security considerations

Although the scope of this section is not to define the real implementation of the interfaces of the reTHINK architecture, it was considered important to include some security considerations which must be followed:

1. All the interfaces will be transported over a secure transport layer. For example REST APIs will transport over TLS (HTTPS). Protocols transported over UDP (e.g. LWM2M/COAP) must use DTLS (RFC4347) [38] when possible.

2. As Hyperties are also going to be executed in browsers, all the security constrains imposed by them must be considered. It is especially relevant to avoid Cross-Domain issues when different contents of a Web Application are loaded from different domains. Other Cross-Domain issues may be result of mixing content loaded from HTTP and HTTPS in the same application. Using always secure interfaces is also a way to avoid this last type of issues.



3. Some APIs exposed by browsers like Screen-Capture are only usable when the scripts which use the API are loaded over HTTPS. Using secure interfaces will always allow taking advantage of any browser feature once is permitted by the End-user.

4. Valid TLS certificates must be used to avoid the connectivity issues. This is especially relevant for Websockets connections.

9.2 Domain Registry Interface

9.2.1 Description of Registry Interface

Registry services in rethink architecture comprise two main components: Global Registry and Domain Registry. The Global Registry is built on P2P technology and resolves a user’s GUID to the CSP specific UserID. The Domain Registry translates that UserID to the information of the Hyperty instances currently registered by the user.

The Domain Registry provides functionality of a directory service to find users’ addresses and availability. All the Hyperty instances will register on the Registry so that they can be located by other Hyperties which need to contact them or get its status. The main operations which a Hyperty needs to perform over the Registry interface are registration and de-registration, publish context information and get information from other Hyperties. These operations can be directly translated into operations over Data Objects. Not all the elements of the reTHINK architecture are allowed to perform any operation over a data object. This is the reason why roles were defined to assign different permission sets.

9.2.2 CRUD operations over Registry Data Objects

Hyperties and Runtime (User Agents) must be able to create, read and update its own Data Object which represents a registration of itself in the Registry.

Optionally, Hyperties can also create, read and update data in the Registry about (data) objects instances handled by Hyperty Instances e.g. communication data objects.

In a similar way, Runtime (User Agents) can also create, read and update data in the Registry about instances of protocol stubs used to connect the runtime device to domains or other devices.

9.2.2.1 Roles for access policy to Registry Interface

Instance-owner: it is the instance which registers itself in the Registry.

External-Hyperty: it is a Hyperty which consults the Registry to get the instance URL to reach the Instance which wants to contact with.

Registry-manager: this role can check and delete existing Instances for different reasons.

9.2.2.2 Operations allowed per role in the Registry Interface

9.2.2.2.1 Hyperty Instance Object Resources

Instance-owner Role

Data Object Property Permitted operations

id: string CR

url: (URL.HypertyInstanceURL | URL.HypertyRuntimeURL |

URL.RegistryDataObjectInstance)

CRU



descriptor: URL.HypertyCatalogueURL CRU

startingTime: date CR

lastModified: date CR

expires: integer CR

Status: RegistryDataObjectStatus CRU

stubs CRU

stubsConfiguration CRU

Runtime: HypertyRuntimeInstance URL CRU

p2pRequester CRU

External-Hyperty Role


id: string R



R

descriptor: URL.HypertyCatalogueURL R

startingTime: date R

lastModified: date R

expires: integer R

Status: RegistryDataObjectStatus R

stubs R

stubsConfiguration R

Runtime: HypertyRuntimeInstance URL R

p2pRequester R



Registry-manager-role


id: string UD



UD

descriptor: URL.HypertyCatalogueURL UD

startingTime: date UD

lastModified: date UD

expires: integer UD

Status: RegistryDataObjectStatus UD

stubs UD

stubsConfiguration UD

Runtime: HypertyRuntimeInstance URL UD

p2pRequester UD

9.2.2.2.2 Hyperty Data Object Instance Object Resources

Instance-owner Role


owner: URL.HypertyURL CRUD

resources: HypertyResourceType CRUD

name: string CRUD

description: string CRUD

tags: string[] CRUD

HypertyCommunicationDataObjectInstance CRUD

HypertyContextDataObjectInstance CRUD



External-Hyperty Role


owner: URL.HypertyURL R

resources: HypertyResourceType R

name: string R

description: string R

tags: string[] R

HypertyCommunicationDataObjectInstance R

HypertyContextDataObjectInstance R

Registry-manager-role


owner: URL.HypertyURL RUD

resources: HypertyResourceType RUD

name: string RUD

description: string RUD

tags: string[] RUD

HypertyCommunicationDataObjectInstance RUD

HypertyContextDataObjectInstance RUD

9.2.3 Proposed Protocol for Registry Interface

A REST API seems to be a suitable choice for this interface. In environments where constrained devices (typically for M2M use cases) other protocols like LWM2M/COAP should be also supported. However this interface will be used by a Hyperty already instantiated after getting the code from the Catalogue, so a ProtoStub to perform the registration process is also a suitable option. This will allow the Hyperty to choose the protocol which best fits its characteristics (e.g. a constrained device could choose LWM2M/COAP over DTLS instead of a REST API over HTTPS).



9.3 Catalogue Interface

9.3.1 Description of Catalogue Interface

Through this interface Users will be able to discover all available Hyperties as well as supported Protocol Stubs, Runtime devices and data schemas in a Service Provider domain. In addition the code necessary to create instances of the Hyperty or Runtime components can be retrieved and deployed in devices.

9.3.2 CRUD operations over Catalogue Data Objects

Users and Runtime (User Agents) must be able to read Hyperty Descriptors, Protocol Stub Descriptors, Runtime Descriptors and Data Object Schemas stored in the Catalogue.

Catalogue publishers including Product Managers and Developers, are allowed to create, read and update data objects in the Catalogue.

9.3.2.1 Roles for access policy to Catalogue Interface

Catalogue-User: the entities which can consult data and download source code to be instantiated in the runtime including Hyperties and Protocol Stubs.

Catalogue-Publisher: the entities with this role can publish data objects in the Catalogue including Hyperties and protocol stubs data and associated source code. This role normally will be played by the Service Provider (or Developer).

Catalogue-Manager: Catalogue managers are entities which have total control over the Catalogue. They are allowed to create, read, update and delete data objects in the Catalogue.

9.3.2.2 Operations allowed per role in the Catalogue Interface

9.3.2.2.1 Hyperty Descriptor Object Resources

Catalogue-User


type R

hypertyType R

dataObjects R

messageSchema R

configuration R

policies R

constraints R



Catalogue-Publisher


type CRUD

hypertyType CRUD

dataObjects CRUD

messageSchema CRUD

configuration CRUD

policies CRUD

constraints CRUD

9.3.2.2.2 Protocol Stub Descriptor Object Resources

Hyperty-End-user


messageSchema R

configuration R

constraints R

Catalogue-Publisher


messageSchema CRUD

configuration CRUD

constraint CRUD

9.3.2.2.3 Hyperty Runtime Descriptor Object Resources

Catalogue-Use


runtimeType R

hypertyCapabilities R

protocolCapabilities R



Catalogue-Publisher


runtimeType CRUD

hypertyCapabilities CRUD

protocolCapabilities CRUD

9.3.2.2.4 Data Object Schema Resources

Catalogue-User


MessageDataObjectSchema R

HypertyDataObjectSchema

R

Catalogue-Publisher


MessageDataObjectSchema CRUD

HypertyDataObjectSchema CRUD

9.3.2.2.5 Hyperty Interceptor Descriptor Resources

Catalogue-Use


Configuration R

Policies R

Catalogue-Publisher


Configuration CRUD

Policies CRUD



9.3.2.2.6 Proposed Protocol for Catalogue Interface

A REST API seems to be a suitable choice for this interface. In environments where constrained devices (typically for M2M use cases) other protocols like LWM2M/COAP should be also supported. This way the data objects would be accessible by using a REST API exposed by the Catalogue and also through a LWM2M/COAP interface. As this interface is the entry point to the reTHINK architecture proto-fly mechanism has not been considered valid option.

9.3.3 Resource access in the Catalogue interface

The URL-based resource access mechanism defined in 5.1.4.2 can be easily applied to the Catalogue interface. This chapter describes the URL as they were specified at writing time.

The base URL to create, read, update or delete a Hyperty in the Catalogue:

https://catalogue.<csp domain>/.well-known/runtime/Runtime

This URL scheme makes rethink compliant to RFC6690 (Constrained RESTful Environments (CoRE) Link Format) [45] and RFC5785 (Defining Well-Known Uniform Resource Identifiers (URIs)) [46]. This allows the direct support of constrained devices with the current URL scheme..

To access a Hyperty the path would be:

https://catalogue.<csp domain>/.well-known/yperty/<Hyperty_id>/description

https://catalogue.<csp domain>/well-known/.well-known/Hyperty/<Hyperty_id>/sourceCode

Each first level resource at the Catalogue will HypertyDescriptor, RuntimeDescriptor and DataObjectSchema. For example, to access the Hyperty descriptor:

https://catalogue.<cspdomain>.well-known/Hyperty/<Hyperty_id>/descriptor/type

https://catalogue.<csp domain>/.well-known/Hyperty/<Hyperty_id>/descriptor/configuration/<attribute>

(all the configuration attributes are accessible through a URL)

https://catalogue.<csp domain>catalogue/Hyperty/<Hyperty_id>/descriptor/policies

https://catalogue.<csp domain>/.well-known/catalogue/Hyperty/<Hyperty_id>/descriptor/constraints

Both policies and constraints are collections of Runtime Contraints objetcs and HypertPolicy objects so applying a Read operation over them a JSON or XML will be returned with a list of all the existing resources.

9.4 Identity management interface

9.4.1 Description of Identity Management Interface

The Identity Management Interface allows Hyperties to communicate with an IdP. It is used by the Hyperties to upload its identity details, assert it before establishing a communication with another identity and verify the assertion sent by other Hyperty within the messaging.

This interface allows the Hyperty to get an IDtoken which will be used to log in different services with a specific identity. This interface also allows to get AccessToken which are use to get access to



resources owned by servers which can be part of either the reTHINK architecture or an external server.

The use of solutions based on OAUth 2.0 and other authentication protocols will require communication between the Client (the services which requires the authentication of an End-User requesting its services) and the Identity Provider. As this interface will depend on the chosen protocol this has been left out of the scope of this document.

9.4.2 CRUD operations Identity Management Interface

9.4.2.1 Roles for access policy to Identity Management Interface

Hyperty-EndUser: it is a Hyperty instance which can access the IdP to modify its identity data.

IdP Manager: it is an entity which has rights to modify data stored in the IdP. It can be the CSP if the IdP service it is provided by it.

Authenticating-Hyperty: it is the Hyperty which needs to assert its identity before contacting other Hyperty. IdP-client: it is the service which needs to validate the identity assertion of a Hyperty instance from which it has received any message. It also can get the ID token and Access Token from the IdP in orderr to identify and authorize End Users before using its services. Note that we are using IdP typical terminology:

o an End User is a Human participant. In reTHINK the concept can be extended to other non-Human Entities which are things with a separate and distinct existence and that can be identified in a context.

o the Client is the service which uses the IdP to authenticate End-Users. In WebRTC 1.0 defined in [5] the Client role is played by browsers to validate assertions sent in messages.

It is also relevant to mention that the WebRTC 1.0 require the browser to download Javascript code from the IdP so it uses natively a Protocol-on-the-fly approach.

9.4.2.2 Operations allowed per role in the Identity Management Interface

Hyperty-EndUser over its own Identity Data Object:


GUID RUD

Identifier RUD

UserProfile RUD

ServiceAddress RUD

AuthenticationData RD

AuthorizationData RD



IdP Manager:


GUID CRUD

Identifier CRUD

UserProfile CRUD

ServiceAddress CRUD

AuthenticationData CRUD

AuthorizationData CRUD

IdP Client:


GUID R

Identifier R

UserProfile R

ServiceAddress R

AuthenticationData R

AuthorizationData R

Besides ID and Access tokens which are used to be able to authenticate itself and access to services, Hyperties needs to be able to assert its identity when sending a messaging and it also needs to be able to validate these assertions when they are received in a message.

The Authenticating-Hyperty is the role played by a Hyperty which needs to add an assertion with its identity to a message and the IdP-Client needs to validate that assertion included in the message, it would be the Relaying Party. Those roles are inspired in the Identity section from [35].

The Authenticating-Hyperty will need to create an assertion by calling a method createAssertion() which will receive as parameters information derived from the cryptographic certificates which authenticate it. The IdP-Client will call a method validateAssertion() which will receive as parameter the assertion sent by the Authenticating-Hyperty.

9.4.3 Proposed Protocol for Identity management interface

OpenID Connect 1.0 could be a suitable protocol for this interface. It is an identity layer on top of the OAuth 2.0 protocol. It allows Clients (in reTHINK the Clients would be Registry and Messaging Services) to verify the identity of the End-User based on the authentication performed by an Authorisation Server, as well as to obtain basic profile information about the End-User in an inter-operable and REST-like manner.



OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management.

Despite the fact that OpenID Connect is a suitable choice for this interface, there exist other protocols which can be chosen by CSP for investment protection or technical or strategic issues. It is possible to use the Protofly mechanism in the Identity Management Interface show any authentication protocol could be potentially used in this interface.

As mentioned in 5.4.1, the WebRTC API 1.0 exposed by the browser adopted a similar approach. The browser downloads an IdP's JavaScript code which is used to interact with the IdP from the browser.

9.5 Messaging interface

9.5.1 Description of the Messaging interface

Interface used by the Hyperty instances to send messages to its CSP in order to either establish real-time media/data session or send any type of data. This interface is also used by the Hyperties to send messages to Hyperties registered on other CSP.

When the Messaging Interface is used to send messages to a Hyperty instance from another CSP, then the Proto-fly mechanism is used. This interface can be "transient" when after the initial exchange of messages between Hyperty instances they can establish a P2P Datachannel for messaging. The availability of using P2P interfaces between Hyperty instances for messaging will be evaluated during reTHINK project as it presents some problems, for example for billing management.

Note that CSP to CSP NNI is not needed since protocol-on-the-fly will use triangular signalling topologies by using just the signalling server from the called party.

9.5.2 CRUD operations over messaging interface

9.5.2.1 Roles for access policy to Messaging Interface (Communication objet)

In the current rethink specification there are 3 data objects (namely Communication, Connection and Context) which are modified through the messaging interface to enable inter-hyperty communication. In this document will use as an example the communication object. The CRUD operations over the rest of data objects would be equivalent applied to their object properties.

Reporter: It is a Hyperty which reports changes over a data object through the Messaging Interface.

Observer: It is a Hyperty which observes the changes in a data object which has taken place through the Messaging Interface.

Hyperty-End-User: It is a Hyperty which can send messages to other Hyperties registered to the same CSP or a different one. This is generic role which has been defined for the Messaging Interface to support roles not considered at this stage of the project.



9.5.2.2 Operations allowed per role in the Messaging Interface

Hyperty-End-user: it is a Communicator Hyperty which can start and/or receive media sessions.


scheme: “comm” CRUD

startingDate: date CRUD

lastModified: date CRUD

duration: date CRUD

Status: CommunicationStatus CRUD

Participants: participants[0..*] CRUD

Qos: CommunicationQuality CRUD

Children: resources[0..*] CRUD

Reporter:


scheme: “comm” CRUD

startingDate: date CRUD

lastModified: date CRUD

duration: date CRUD

Status: CommunicationStatus CRUD

Participants: participants[0..*] CRUD

Qos: CommunicationQuality CRUD

Children: resources[0..*] CRUD



Observer:


scheme: “comm” R

startingDate: date R

lastModified: date R

duration: date R

Status: CommunicationStatus R

Participants: participants[0..*] R

Qos: CommunicationQuality R

Children: resources[0..*] R

9.5.3 Proposed Protocol for the messaging interface

The Protofly mechanism enables the use of different protocols for this interface. A JSON over Websocket protocol can be a suitable choice for this interface, however REST-based approaches are also . Websocket allows establishing a bidirectional connection between a browser and a server so it can send and receive data asynchronously. Using JSON for messaging is the simpler approach as it can be easily processed in Javascript language and it is well-known by Javascript developers.

9.6 Real Time Interface

9.6.1 Introduction

This interface will transport real-time flows (audio, video and data) between end-users devices and services in a peer-to-peer way.

At wire level, the real-time interface will use the protocols defined by the IETF RTCWEB WG[1] for WebRTC communications. Although existing protocols such RTP/RTCP, ICE and DTLS-SRTP are used, the WG defines all the protocols which have to be mandatory used in any WebRTC communication to meet the all the requirements of real-time communications over the Internet. [2] Describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported.

9.6.2 Security aspects of Real-Time interface

The IETF RTCWEB WG forced WebRTC communications to be secure by default as the framework was designed for data transmission over Internet and from many types of devices. The encryption of the flows is provided by DTLS-RTP which is an adaptation of TLS to be used over datagrams (UDP). It implements a TLS handshake which allows exchanging the key which is going to be used for symmetric encryption of the traffic over the media flow itself. This makes not necessary to exchange the key in the signalling which is not standardized in WebRTC so encryption will not be warranted by default. The Real-time interface will not require any symmetric key exchange at signalling level to encrypt the real-time flows and all the real-time communication are secure by default.



9.6.3 Connectivity aspects of Real-Time interface

Communication over Internet is a challenging engineering task as IP connectivity between peers is almost never possible. The massive adoption of NAT to avoid the lack of IPv4 IPs and the common presence of Firewall to protect domestic and corporate LANs make necessary the use of protocols like ICE.

The RTCWeb WG adopted Interactive Connectivity Establishment (ICE) [3] as the mechanism to achieve an optimal communication between peers. ICE is a complex protocol which uses the STUN messages to discover the best path between the two peers. ICE uses STUN servers, which allow to discover the public IP from which one endpoint is accessing Internet, and TURN servers, which can relay the traffic when both endpoints are behind symmetric NATs or FW. It was initially designed for offer/answer protocols (namely Session Description Protocol) however a new flavour of ICE called Trickle ICE [4] was defined which allows using ICE not only in offer/answer protocols.

ICE requires STUN and TURN servers for each operation in order to provide connectivity. STUN allows to discover the public IP which a device is using to access to Internet in order to provide this information to the rest of peers of the communication.

TURN allows to assign and to reserve public IP/port pairs to each device in order to be able to receive RTP from the other peer when the device is behind symmetric NAT or restrictive Firewalls. When the TURN server is used to transport the real-time flows the flows are not real peer-to-peer and the use of TURN server has an associated cost in terms of BW resources.

ICE tries to find the optimal direct path between peers trying to minimize the use of TURN server to relay the traffic.

The Real-time interface will provide optimal peer-to-peer transmission of the real-time data flows trying to minimize the use of relay servers.

9.6.4 Considerations about Real-Time interface

WebRTC Media Framework is still under development but it is already consolidated and is fully functional and it is the result of the work is the result of the work of the main actors in Telecommunication and IT industry so the reTHINK team considered it as the more natural choice for the project. There are production-ready open source libraries of WebRTC with a huge community behind it.



10 ReTHINK Architecture Summary

The reTHINK architecture represents a radical transformation of real-time communication services by moving the session control layer into the peer-to-peer sphere. It pulls in the best of both worlds: on one hand, web based communication; and on the other - Telco federated, trusted and reliable delivery models. The reTHINK architecture combines web technologies and web attitudes with a trusted worldwide cooperative service delivery model. It allows for different service provider ecosystems to develop communication applications over the Internet, rather than over privately managed core networks.

Thus, the reTHINK architecture can be positioned at the half-way house between web based VoIP, which is provided as OTT (Over The Top) services without involving network providers, and the traditional Telco model - fully managed packet network based VoLTE (Voice over LTE), which is provided by mobile operators, with their exclusive native applications.

The design of reTHINK architecture accounts for current and emerging technologies. A thorough study of the state of the art was conducted, as well as analysis of the technical requirements and a comprehensive set of captured Use Cases. This SotA study (see Annex A in D2.1 [105]) includes topics covering new modes of communications, such as context based, ad-hoc, social network calling, IoT interactions and click-to-talk communications. The reTHINK solution is inspired by the evolution of IT based frameworks, from SOA (Service Oriented Architecture) to ROA (Resource Oriented Architecture), and from OMA and TMF defined service delivery platforms to Code-on-Demand techniques.

The reTHINK architecture fulfils the following architectural goals:

Prototyping the transfer of session control to the endpoints, while using trusted, well maintained CSP software.

Enabling internet based communication to be enhanced with greater QoS and security.

Allowing flexible means of interworking with minimal CSP involvement, to gain easy implementation and fast universal deployment.

Providing greater service mobility and user choice via independent identity management, and extending identity services with Social Networks style enhancements.

The architecture aims at a distributed intelligence approach, rather than client-server that requires an extensive core platform, thus leveraging the increasing power of end-user devices. Hence, this architecture requires that the network policy enforcement is executed by different stakeholders from those initiating the communication – a concept already implemented in LTE policy architecture, but now adopted for web transport over a mesh of collaborating media gateways (TURN, STUN, ICE, etc.).

Under the reTHINK solution, Service Providers will be able to develop and manage the session control software, but download it to the distributed endpoints. The downloaded software can run autonomously for the duration of the service, managing the session media flow over the web, using latest web technologies, such as webRTC. This procedure still enables service providers to offer enhanced service delivery via open APIs, which ensure higher quality of service, when routing the media via special web media gateways that enforce session policy of security and QoS.

To achieve global compatibility, this architecture does not require that service providers negotiate session parameters, but interoperability of users on other domains is ensured by downloading the same software to both endpoints. This avoids the need to formulate new protocols to manage webRTC signalling, for example, or to cope with different calling features. With this facility, end-to-end connectivity can be implemented even with non-subscribers who reside on non-participating domains, thus enabling fast adoption of the reTHINK framework.



To achieve greater user choice and service mobility, the architecture assumes that users are identified and authenticated independently of any service provider. To do that, the reTHINK architecture builds on the emerging principles of independent identity management, using advanced identifiers such as webID and OpenID Connect and interfacing to Identity Providers (IdPs).

This architecture introduces a new web service paradigm in the concept of the ‘hyperties’ - Hyperlinked Entities, which represent ‘live’ web entities that can communicate between them. The hyperties can be deployed either for resource constraint devices like smartphones, or for cloud infrastructures, to deliver peer-to-peer style communications. The identity architecture extends the ideas of social networks in the management of these hyperties, which (it is assumed at this stage) will be associated as a ring of connected users via ‘GraphID’ or ‘M2M Connector’.

The mechanism of enabling remote compatibility via code-on-demand is the ProtoFly (Protocol on the Fly) mechanism. Connectivity software and service logic are matched at run time by downloading them to the other party’s device, thus avoiding the requirement for new standard protocols.

The reTHINK framework comprises of functions that are maintained by the communication service provider (including the endpoint side and the server side), functions that are provided by 3rd parties such as independent identity providers, and services that are provided by network providers via APIs:

End-user communication hyperty: Instantiated endpoint software module is downloaded to the devices (or network-edge servers) from the core platform, and is responsible for the session signalling (once the session is initiated) and for the full user end service logic

Network side communication setup and support: The core network service provider platform provides the initial activation of the end-user hyperty, and the ‘rendezvous’ facility for initiating sessions

Special network services: This set of APIs provide access to various levels of security and quality of service, which are provided by the delivering network

Identity Management services: Although user authentication is performed by external identity provider, there are further services that can be provided to enhance authentication, authorisation and access to End-User profile information. Identity search and verification may occur within the endpoint module, but some identity enhanced functions may execute at the core platform.

The main reTHINK processes at the communication service provider’s platform governs how services are accessed and partners are supported, how hyperties are maintained and logged, and how users are discovered:

Service Catalogue: A list of services offered by the service provider, including types of hyperties, device-specific hyperties and versions compatible with particular Operating System. This catalogue enables access to all the information needed for parties who wish to make use of the offered hosted services

Hyperty Registry: A dynamic repository that contains information about instantiated hyperties while they are running at the end-user devices (or network-edge servers). It provides instance current address, execution context (e.g. device type and user presence), start time etc.

User Discovery: A facility to find destination users, on whichever device they are currently logged on, in order to launch a connectivity request towards them. Such discovery service involves searching the service provider’s own registry, which contains active instantiated hyperties, representing user availability

Governance: A set of routines that support the reTHINK platform, including the management of hyperties life-cycle, accounts for users (including devices and “things”) with user preferences, and the management of business partnership for both network providers and application providers.



As this is a ground-breaking architecture, many technical issues require further investigation. For example, further clarifications are sought for the following issues:

Trust management for identity verification, discovery and graph connector

P2P signalling feasibility within current technologies

The types of policies that can be enforced across multiple domains

Impact of the hyperty execution model on network traffic and device power consumption

Security aspects of downloading software, for enterprises as well as users

Hyperty Interoperability at run time based on modifiable data in Resource Tree model.

The reTHINK architecture details are still evolving, however, this document provides the foundation on which the solution will be designed and built. This document should be read in conjunction with the Use Cases (in D1.1), the Requirements (in D2.1) and the Data Model (in D2.2). This document is the final release of the ReTHINK architecture, interface, and data model specification reflecting minor changes due to feedback from the design and implementation phase of reTHINK.

oOo



References

[1] https://www.reTHINK-project.eu/ [2] Trustful hyper-linked entities in dynamic networks, proposal to the H2020 ICT 5 2014 Call of

the European Union. [3] http://en.wikipedia.org/wiki/MoSCoW_method [4] E. Janczukowicz, S. Tuffin, A.Braud, A. Bouabdallah, G. Fromentoux, J.M. Bonnin. Approaches

for Offering QoS and Specialized Traffic Treatment for WebRTC. In Advances in Communication Networking, pages 59-69. Springer International Publishing, 2014.

[5] D. Clark, S. Bauer, W. Lehr, KC. Claffy, A. Dhamdhere, B. Huffaker, M. Luckie. Measurement and Analysis of Internet Interconnection and Congestion. In TPRC Proceedings, 2014.

[6] S. Bauer, D. Clark, W. Lehr. The Evolution of Internet Congestion. In TPRC Proceedings, 2009. [7] Göndör, Sebastian, and Hussam Hebbo. "SONIC: Towards seamless interaction in

heterogeneous distributed OSN ecosystems." Wireless and Mobile Computing, Networking and Communications (WiMob), 2014 IEEE 10th International Conference on. IEEE, 2014.

[8] https://tools.ietf.org/html/rfc2898#section-5.2 [9] Saint-Andre, Peter. "Extensible messaging and presence protocol (XMPP): Core." (2011). [10] Saint-Andre, Peter. "Extensible messaging and presence protocol (xmpp): Instant messaging

and presence." (2011). [11] K. Graffi, S. Podrajanski, P. Mukherjee, A. Kovacevic, und R. Steinmetz, „A Distributed Platform

for Multimedia Communities“, in Tenth IEEE International Symposium on Multimedia, 2008. ISM 2008, 2008, S. 208–213.

[12] B. Dodson, I. Vo, T. J. Purtell, A. Cannon, und M. Lam, „Musubi: Disintermediated Interactive Social Feeds for Mobile Devices“, in Proceedings of the 21st International Conference on World Wide Web, New York, NY, USA, 2012, S. 211–220.

[13] C. Wilson, T. Steinbauer, G. Wang, A. Sala, H. Zheng, und B. Y. Zhao, „Privacy, Availability and Economics in the Polaris Mobile Social Network“, in Proceedings of the 12th Workshop on Mobile Computing Systems and Applications, New York, NY, USA, 2011, S. 42–47.

[14] N. Kourtellis, J. Finnis, P. Anderson, J. Blackburn, C. Borcea, und A. Iamnitchi, „Prometheus: User-controlled P2P Social Data Management for Socially-aware Applications“, in Proceedings of the ACM/IFIP/USENIX 11th International Conference on Middleware, Berlin, Heidelberg, 2010, S. 212–231.

[15] L. A. Cutillo, R. Molva, und T. Strufe, „Safebook: A privacy-preserving online social network leveraging on real-life trust“, IEEE Communications Magazine, Bd. 47, Nr. 12, S. 94–101, Dez. 2009.

[16] L. Lynch. Inside the Identity Management Game. IEEE Internet Computing, 2011. [17] A. JJnch. Inside the Identity Exploring Different Types of Trust Propagation. In Lecture Notes in

Computer Science Volume 3986, pages 179-192. Springer International Publishing, 2006. [18] G. Goos et al. Human Experiments in Trust Dynamics. In Lecture Notes in Computer Science

Volume 2995, pages 206-220. Springer International Publishing, 2004. [19] D. Artz, Y. Gil. A survey of trust in computer science and the Semantic Web. In Web Semantics:

Science, Services and Agents on the World Wide Web, pages 58-71. 2007. [20] D. Hutchison et al. Trust Management Survey. In Lecture Notes in Computer Science Volume

3477, pages 77-92. Springer International Publishing, 2005. [21] P. Bonatti et al. An Integration of Reputation-based and Policy-based Trust Management. In

Proceedings of the Semantic Web Policy Workshop, 2005. [22] A. Pirzada, C. McDonald. Establishing Trust in Pure Ad-hoc Networks. In Proceedings of the 27th

Australasian conference on Computer science – Volume 26, pages 47-54. 2004. [23] 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2: [Online]. Available:

http://www.3gpp.org/DynaReport/23228.htm [Accessed: 20-Mar-2015].

https://www.rethink-project.eu/

http://en.wikipedia.org/wiki/MoSCoW_method

https://tools.ietf.org/html/rfc2898#section-5.2

http://www.3gpp.org/ftp/specs/archive/24_series/24.229



[24] GSMA Rich Communications Suite, Specs & Product Docs, [Online]. http://www.gsma.com/network2020/rcs/specs-and-product-docs/ [Accessed: 14-Mar-2014].

[25] The Open Group, “SOA Source Book”, Van Haren Publishing, ISBN 978-9087535032, May, 2009 [26] Emekci, F.; Sahin, O.D.; Agrawal, D.; El Abbadi, A., "A peer-to-peer framework for Web service

discovery with ranking," Web Services, 2004. Proceedings. IEEE International Conference on , vol., no., pp.192,199, 6-9 July 2004

[27] Fielding, R.T., Architectural Styles and the Design of Network-based Software Architectures, PhD Thesis, 2000. [Online]. Available: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm [Accessed: 20-Mar-2015].

[28] Fixed and Mobile NGN Evolution Towards the Future Internet [Online]. Available: https://www.fokus.fraunhofer.de/en/ngni/workingareas/future-internet [Accessed: 20-Mar-2015].

[29] TM Forum TR139, Service Delivery Framework (SDF) Overview, Release 2.0: [Online]. http://www.tmforum.org/softwareenabledservices/4664/home.html [Accessed: 20-Mar-2015]

[30] A. K. Dey, « Understanding and using context », Personal and Ubiquitous Computing, vol.5 (1), pp.4-7, ed. Springer 2001.

[31] M.Weiser, « The computer for the 21st century », Scientific american, vol.265(3), pp.281-290, 1991.

[32] [blog1] www.every-ware.fr/ [33] C. Hoareau, I. Satoh, « Modeling and Processing Information for Context-Aware Computing: A

Survey », New Generation Computing, vol. 27, pp.177-196, ed. Springer, 2009. [34] C.Bettinia, O. Brdiczkab, K. Henricksenc, J. Indulskad, D. Nicklase, A. Ranganathanf, D. Ribonia,

« A survey of context modelling and reasoning techniques », Pervasive and Mobile Computing, vol.6(2), pp.161–180, 2010.

[35] [Baldauf&all] M. Baldauf, S. Dustdar, and F. Rosenberg, « A Survey on Context-Aware Systems », International Journal of Ad Hoc and Ubiquitous Computing, Vol. 2(4), pp.263-277, 2007.

[36] [O.Yurur&all] O.Yurur, C.Harold, Z. Sheng, V.C.M. Leung, W. Moreno, K.K. Leung, « Contex-Awareness for Mobile Sensing : A survey and Future Directions », IEEE Communications Surveys and Tutorials, (to appear), DOI 10.1109/COMST.2014.2381246.

[37] A. Fuggetta, G. P. Picco, and G. Vigna. Understanding code mobility. IEEE Transactions on Software Engineering, 24(5), May 1998, pp. 342-361

[38] OASIS. Identity Provider Discovery Service Protocol and Profile. Committee Specification 0127 March 2008

[39] R. Copeland. SOA Case Study – the BT IMS OSIP. BT Technology Journal 2009 [40] R. Copeland. Converging NGN Wireline and Mobile 3G Networks with IMS. ISBN 978-0-8493-

9250-4, Taylor & Francis 2009 [41] OASIS. Telecom SOA Use Cases and Issues Version 1.2, TC Committee Draft, 24 July 2009 [42] E. Bertin et al., “WebRTC, the Day After: What’s Next for Conversational Services+?” Proc. 17th

Int’l Conf. Intelligence in Next Generation Networks (ICIN), 2013, pp. 46–52. [43] S. Loreto and S.P. Romano, “Real-Time Communications in the Web: Issues, Achievements, and

Ongoing Standardization Efforts,” IEEE Internet Computing, vol.16, no. 5, 2012, pp. 68–73. [44] H. Sinnreich and W. Wimmreuter, “Communications on the Web,” Elektrotechnikund

Informationstechnik, vol. 127, 2010,pp. 187–194; [45] Singh, K.; Krishnaswamy, V., "A case for SIP in Javascript," Communications Magazine, IEEE ,

vol.51, no.4, pp.28,33, April 2013 [46] Beierle, F. and Göndör, S. and Küpper, A. (2015). “Towards a Three-tiered Social Graph in

Decentralized Online Social Networks.” Proceedings of the 7th International Workshop on Hot Topics in Planetscale Mobile Computing and Online Social Networking. ACM.

[47] S. D. Kamvar, M. T. Schlosser, H. Garcia-Molina. The EigenTrust Algorithm for Reputation Management in P2P Networks. In WWW '03 Proceedings of the 12th international conference on World Wide Web, 2003.

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

https://www.fokus.fraunhofer.de/en/ngni/workingareas/future-internet

http://www.tmforum.org/softwareenabledservices/4664/home.html

http://www.every-ware.fr/



[48] BIBA, K. J. 1977. Integrity Constraints for Secure Computer Systems. Bedford, MA, USAF Electronic Systems Division.

[49] BREWER, D. F. C. AND M. J. NASH 1989. The Chinese Wall Security Policy. IEEE Symposium on Research in Security and Privacy, Oakland, California, USA, IEEE.

[50] Chugh, R., Meister, J., Jhala, R., Lerner, S., 2009. Staged information flow for Javascript, in: Proceedings of the ACM SIGPLAN 2009 Conference on Programming Language Design and Implementation, ACM Press. pp. 50–62.

[51] Clark, D.D., Wilson, D.R.: A Comparison of Commercial and Military Computer Security Policies. In: IEEE Symposium on Security and Privacy (1987)

[52] Elrad, T., Filman, R.E., Bader, A., 2001. Aspect-oriented programming - introduction. Communications of the ACM 44, 29–32.

[53] Hedin, D., Sabelfeld, A., 2012. Information-flow security for a core of javascript, in: Proceedings of the 25rd Computer Security Foundations Symposium (CSF’12), IEEE Press. pp. 3–18.

[54] Meyerovich, L., Livshits, B., 2010. ConScript: Specifying and enforcing fine-grained security policies for Javascript in the browser, in: Proceedings of the 2010 IEEE Symposium on Security and Privacy, IEEE Computer Society Press. pp. 481–496.

[55] [Mihi08] http://wso2.com/library/3132/ [56] [Mozzilla15] https://developer.mozilla.org/en-

US/docs/Web/Security/CSP/Using_Content_Security_Policy [57] [RFC 3198] https://www.ietf.org/rfc/rfc3198.txt [58] Strassner, John. Policy-based network management: solutions for the next generation. Morgan

Kaufmann, 2003. [59] J. H. Saltzer and M. D. Schroeder. The Protection of Information in Computer Systems. In

Proceedings of the IEEE, Vol. 63, No. 9. (1975), pp. 1278-1308. [60] [OASIS06] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypolicy-1.2-

spec-cd-01.html [61] [OASIS10] XACML Version 3.0. 2010. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-

spec-cs-01-en.pdf [62] Van Acker, S., De Ryck, P., Desmet, L., Piessens, F., Joosen, W., 2011. Webjail: Least-privilege

integration of third-party components in web mashups, in: Proceedings of 27th Annual C [63] Vogt, P., Nentwich, F., Jovanovic, N., Kirda, E., Kruegel, C., Vigna, G., 2007. Cross-site scripting

prevention with dynamic data tainting and static analysis, in: Proceedings of the Symposium on Network and Distributed System Security (NDSS’07), The Internet Sociery.

[64] [W3C14] http://opoto.github.io/secure-element/ [65] [W3C15] https://w3c.github.io/webappsec/specs/content-security-

policy/http://www.w3.org/TR/CSP2/ [66] [AWS-IAM] http://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_Introduction.html [67] Göndör, Sebastian, and Hussam Hebbo. "SONIC: Towards seamless interaction in

heterogeneous distributed OSN ecosystems." Wireless and Mobile Computing, Networking and Communications (WiMob), 2014 IEEE 10th International Conference on. IEEE, 2014.

[68] I. Baumgart, “P2PNS: A Secure Distributed Name Service for P2PSIP“, in Sixth Annual IEEE International Conference on Pervasive Computing and Communications, 2008. PerCom 2008, 2008, p. 480–485.

[69] J. Golbeck and M. Rothstein, “Linking Social Networks on the Web with FOAF: A Semantic Web Case Study”, in AAAI, 2008, No. 8, p. 1138–1143.

[70] B. Schilit, N. Adams, und R. Want, „Context-Aware Computing Applications“, in Proceedings of the 1994 First Workshop on Mobile Computing Systems and Applications, Washington, DC, USA, 1994, p. 85–90.

[71] V. Ramasubramanian and E. G. Sirer, “The Design and Implementation of a Next Generation Name Service for the Internet”, ACM SIGCOMM Computer Communication Review, vol. 34, no. 4, 2004, pp. 331–342.

http://wso2.com/library/3132/








https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy



























http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypolicy-1.2-spec-cd-01.html



























http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf























http://opoto.github.io/secure-element/












https://w3c.github.io/webappsec/specs/content-security-policy/




















http://www.w3.org/TR/CSP2/












http://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_Introduction.html



[72] D. Massey, “A Comparative Study of the DNS Design with DHT-Based Alternatives,” in In the Proceedings of IEEE INFOCOM’06, 2006.

[73] Denise Engert, Use cases and Sustainable Business models for reTHINK, Deliverable D1.1, May 2015.

[74] Paulo Chainho, Kay Haensge, Steffen Druesedow, Michael Maruscheke, “Signalling-On-the-fly: SigOfly, WebRTC Interoperability testbed in contradictive Deployement Scenarios”, Proc. 18th Int’l Conf. Intelligence in Next Generation Networks (ICIN), 2015.

[75] François Toutain, Emmanuel Le Huérou, Eric Beaufils, On webco interoperability, Proc. AWeS '15 Proceedings of the 1st Workshop on All-Web Real-Time Systems.

[76] ETSI M2M specification available in http://www.etsi.org/deliver/etsi_ts/ [77] ETSI M2M TS 102 689: M2M Service Requirements [78] ETSI M2M TS 102 690: M2M Functional Architecture [79] ETSI M2M TS 102 921: mIa, dIa and mId Interfaces [80] oneM2M TS-0001: oneM2M Functional Architecture, www.oneM2M.org [81] oneM2M TS-0008: oneM2M CoAP Protocol Binding [82] [emule] Yoram Kulbak and Danny Bickson, “The eMule Protocol Specification”, The Hebrew

University of Jerusalem, January 2005 [83] [bittorrent1] Bram Cohen, “Incentives Build Robustness in BitTorrent”, In Proceedings of the

1st Workshop on Economics of Peer-to-Peer Systems, Berkeley, USA, June 2003 [84] [bittorrent2] Bram Cohen, “The bittorrent protocol specification”,

http://bittorrent.org/beps/bep 0003.html, January 2008 [85] [eclipse] Atul Singh, Miguel Castro, Peter Druschel and Antony Rowstron, “Defending against

eclipse attacks on overlay networks”, In Proceedings of the 11th workshop on ACM SIGOPS European workshop (EW 11), Leuven, Belgium, 2014, DOI=10.1145/1133572.1133613

[86] [chord] Ion Stoica, Robert Morris, David R. Karger, M. Frans Kaashoek, Frank Dabek and Hari Balakrishnan, “Chord: a Scalable Peer-to-peer Lookup Service for Internet Applications”, IEEE/ACM Transactions on Networking (TON), 11(1):17 – 32, 2003

[87] [pastry] Antony I. T. Rowstron and Peter Druschel, “Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems”, In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001), pages 329–350, Heidelberg, Germany, 2001

[88] [can] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard M. Karp and Scott Shenker, “A Scalable Content-Addressable Network”, In Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM 2001), San Diego, USA, 2001

[89] [kademlia] Petar Maymounkov and David Mazières, “Kademlia: a Peer-to-Peer Information System Based on the XOR Metric”, In Proceedings of the First International Workshop on Peer-to-Peer Systems (IPTPS 2002), Cambridge, USA, March 2002

[90] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. http://www.bibsonomy.org/bibtex/2974d35fdb27dea57296ed2245556aa18/gizmoguy, May 2009

[91] http://www.projectliberty.org/liberty/content/download/2962/19808/file/Liberty%20Legal%20Frameworks.pdf

[92] J. McLean, "A General Theory of Composition for a Class of “Possibilistic” Properties", IEEE Trans. Soft. Eng. Vol.22, N°1, january 1996, pp.53-67.

[93] M. R. Clarkson & F. B. Schneider, "Hyperproperties", Journal of Computer Security 18, 2010, pp. 1157-1210.

[94] R. Yavatkar, D. Pendarakis & R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, IETF, january 2000.

[95] "Policy and charging control architecture", 3GPP TS 23.203. [96] M. Sloman & E. Lupu, "Security and Management Policy Specification", IEEE Network,

March/April 2002, pp.10-19.

http://www.projectliberty.org/liberty/content/download/2962/19808/file/Liberty%20Legal%20Frameworks.pdf

http://www.projectliberty.org/liberty/content/download/2962/19808/file/Liberty%20Legal%20Frameworks.pdf



[97] R. Boutaba & I. Aib, "Policy-based Management: A Historical Perspective", Journal of Network and Systems Management, 2007 (15), pp.447–480.

[98] J.Strassner, "How Policy Empowers Business-Driven Device Management", Proc. of the Third International Workshop on Policies for Distributed Systems and Networks, 2002. pp. 214 – 217.

[99] S.Davy, B.Jennings & J.Strassner,"The policy continuum–Policy authoring and conflict analysis", Computer Communications 31, 2008, pp.2981–2995.

[100] Y.Zhang, X.Liu & W.Wang, "Policy Lifecycle Model for Systems Management", IT Professional, March-April 2005, pp. 50-55.

[101] "End-to-end Quality of Service (QoS) concept and architecture", 3GPP TS 23.207 V5.10.0 (2005-09)

[102] "Network architecture", 3GPP TS 23.002 V5.12.0 (2003-09) [103] "Network architecture", 3GPP TS 23.002 V6.10.0 (2005-12) [104] "Policy and charging control architecture", 3GPP TS 23.203 V7.12.0 (2009-12). [105] Rebecca Copeland, reTHINK Framework Architecture Definition, Deliverable D2.1, July 2015 [106] Ahmed Bouabdallah & Yudani Riobò, reTHINK Data Models and Interface Specification of the

Framework, Deliverable D2.2, September 2015. [107] http://martinfowler.com/articles/microservices.html [108] Jean-Michel Crom, “Management and Security features specifications”, Deliverable 4.1,

September 2015. [109] Jean-Michel Crom, “Implementation of Governance and identity management components for

phase 1”, Deliverable 4.2, february 2016. [110] D. Crockford, “JSON: The Fat-Free Alternative to XML”, XML 2006 Conference, Boston, dec.

2006, http://www.json.org/fatfree.html. [111] G. Wang, “Improving data transmission in web applications via the translation between XML

and JSON”, in Proceeddings of the Third International Conference on Communications and Mobile Computing (CMC), 18-20 April 2011, China.

http://martinfowler.com/articles/microservices.html

http://www.json.org/fatfree.html



Annex A Case Studies

In this section, case study of scenarios that have been identified for reTHINK in deliverable D1.1 are explored, with their detailed call flows, to validate the overall architecture.

A.1 H2H Communication high level view

This section illustrates the basic H2H communication case, in the context of the scenario “Daily Life in a Smart City – Human-To-Human Communication” that is described in the reTHINK use case document [73], Use Case #95 “H2H inter-domain Conversation with different CSPs and external IdPs”.

Figure 32. gives a high level view of the main building blocks involved in the use case. To explain better the call flow, we have to determine a few hypotheses:

Alice and Bobs are two parties, and Alice calls Bob.

Bob uses the service “TalkNow” and Alice uses the service “Participate”. Alice and bob have their own Identity providers.

We consider that both Bob and Alice are already registered (enrolled) in their services.

Alice knows a reachable identifier for Bob so the discovery phase is not described.

The component AliceIdP and BobIdP are providing Identity Management functions that are under the responsibility of the IdP.

Figure 32. Lisa and Alice functional blocks

uses

uses

Voice

Alice device

Bob device

Back ends

Participate

TalkNow

Participate Hyperty

TalkNow Hyperty

Alice IdP

Bob IdP



Figure 33. gives an overview of the initialisation phase, where Alice logs into the ‘Participate’ service. This phase results in downloading some JavaScript code in her browser, so she can use the ‘Participate’ application with the Hyperty-Participate that features Voice Communication.

Figure 33. Authentication and Service instantiation



Figure 34. illustrates the second part of the call. To simplify the flow, it is assumed that Alice is already logged onto her service ‘TalkNow’. To illustrate interoperability, we have considered the case of temporary enrolment using the protocol on the fly. This can be seen in the message 6, where we can find the reference to Alice hyperty. The protocol stack is downloaded to allow calling “TalkNow” service. Note that this is possible because both services (Participate and TalkNow) provide Voice features, so the exchanged messages represent a common set of objects.

Figure 34. Alice calls Bob Use Case



A.1.1 Runtime load

When Alice opens the application, it loads reTHINK libraries. If the Runtime has not been yet initialized it is created and all the required elements are loaded. This diagram shows the runtime load process: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/deploy-runtime.md

Once loaded the runtime, the App instructs the runtime to use an Identity Provider (IdP). If the IdP proxy (the code which allows the interaction with a specific IdP), has not been deployed yet it is deployed in the service provider Sandbox.

A.1.2 Identity selection

The Alice's application selects the Identity which is going to be used by the Alice to associate to the Hyperty. The Alice needs to authenticate herself against the IdP. This process is described in this document: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-registration.md

A.1.3 Hyperty load

Then the application loads the Hyperty/Hyperties which are going to be used by the application. In this case Alice's app, will deploy a connection Hyperty which can interact with any other compatible connection Hyperty to establish a real-time H2H communication. This process is described in this document: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/app-import-hyperty.md

To implement this scenario, the hyperty loaded must be able to support the Connection Dataobject to enable a real-time WebRTC communication. This is the implementation of this Hyperty doen by rethink team can be found here: https://github.com/reTHINK-project/dev-hyperty/tree/master/docs/connector

A.1.4 Getting access token

Once the Hyperty has been deployed it will send the access token to the back-end of the application in order to validate the token and authorize the access to the service. This process is defined in this diagram: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/domain-login-explicit.png

A.1.5 Binding the hyperty to an identity

Once loaded the hyperty has to be bound to an identity already enabled in the IdP: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-to-hyperty-binding-scheme.png

A.1.6 Inter-Hyperty communication

The communication between hyperties can happen in several ways, depending on the CSP domain of the participants and the runtime where the hyperties are being executed. In this use case we are supossing a inter-domain remote communication, it means, both Alice and Bob are using different runtimes and both or them are registered on different CSPs: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/inter-remote-comm.md

The communication between hyperties can also take place between Hyperties from the same domain and even between from Hyperties running in the same runtime and same or different domains:

Different runtime, different domain:

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/deploy-runtime.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/deploy-runtime.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-registration.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-registration.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/app-import-hyperty.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/app-import-hyperty.md

https://github.com/reTHINK-project/dev-hyperty/tree/master/docs/connector

https://github.com/reTHINK-project/dev-hyperty/tree/master/docs/connector

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/domain-login-explicit.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/domain-login-explicit.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-to-hyperty-binding-scheme.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-to-hyperty-binding-scheme.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/inter-remote-comm.md

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/inter-remote-comm.md



https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/intradomain-remote-communication.png

Same runtime same domain: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/intra-local-comm.md

Same runtime different domains: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/interdomain-local-communication.png

A.1.7 Protostub load:

Once deployed the Hyperty, to interact with Bob, the Hyperty will need to load the protostub required to interact with Bob's Message Node: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/basics/deploy-protostub.md

A.1.8 ID Token generation

In order to assert his identity, Bob can generate an ID Token which can be sent to Alice: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/rt-login.md

A.1.9 ID token assertion

Alice can assert the ID token sent by Bob through the Message Node: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/uid-assertion-seq.png

A.1.10 Verifying identity assertion in incoming message

Once the messaging exchange starts, Bob needs to verify Alice's identity assertion included in the message received from the Message Node: https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/user-identity-assertion.md

A.1.11 Connector Hyperty dynamic-view

From this point on, the diagrams are exclusive for the Connector Hyperty developed by reTHINK team. However other hyperties compatible with the connector Data Object are compatible (it is possible to establish a real-time communication between both of them) and will expose a similar API to the Application layer.

A.1.11.1 Adding listener function:

To be able to receive calls, Both Alice and Bob must add a listener function:

https://github.com/reTHINK-project/dev-hyperty/blob/master/docs/connector/connector-invite.png

A.1.11.2 Initiating the call

To start the call, Alice creates Connection data object:

https://github.com/reTHINK-project/dev-hyperty/blob/master/docs/connector/connector-invite_001.png

Alice starts the conection data object synchronization with Bob. Bob receives the incoming call as a notification to synchronize a Connection data object:

https://github.com/101ethink-project/dev-hyperty/blob/master/docs/connector/connector-bob-accepts.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/uid-assertion-seq.png

https://github.com/reTHINK-project/specs/blob/master/dynamic-view/identity-management/uid-assertion-seq.png

https://github/



A.1.11.3 Accepting the incoming call

Bob accepts the call and creates the peer object where the data from Bob’s connection will be synchronized:

https://github.com/102ethink-project/dev-hyperty/blob/master/docs/connector/connector-alice-acked-bob-accepted-invitation.png

A.1.11.4 Exchanging ICE candidates

During the call setup, both Alice and Bob will exchange ICE candidates, in order to discover the optimal path to exchanged real-time media:

https://github.com/reTHINK-project/dev-hyperty/blob/master/docs/connector/connector-ice-candidates-update.png

A.1.11.5 Finishing the call

When Alice or Bob decide to finish the call, tha App calls the disconnect method which forces the deletion of the synchronized data objects used for the communications:

https://github.com/reTHINK-project/dev-hyperty/blob/master/docs/connector/connector-disconnect.png

https://github/



A.2 M2M Case Studies

A.2.1 M2M Always Connected in Trustful Domains for Multi vendor devices

This is the High level view of M2M Always Connected in Trustful Domains for Multi vendor devices (D1.1 UC #5). In this use case, Alice is an Identified Consumer that purchases a new device from a certain Device Manufacturer which is different from the existing installed devices.

Figure 35. M2M Communication Functional Blocks

Device is configured by the manufacturer to automatically register, discover and connect to certain types of devices belonging to the same domain.

As soon as the device is turned on and connected to the network, it will register in the domain (e.g. residential or enterprise gateway). The new Device automatically discovers other devices to connect with or to subscribe to certain events. The new Device connects to other devices to request data, publish data or to subscribe to certain events / data.

Example: new washing machine is connected and discovers the HEMS (Home Energy Management System) system, subscribes to receive events about its level of voltage notifications.

The existing (HEMS) device features: The Runtime User Agent contains the logic to initialise the device including to download Gateway protostub, Hyperties, codecs and policies and to securely register it in Gateway. All these can be updated by the Residential Catalogue either once an update is available or the next time when the device is contacting the Gateway responsible to manage the runtime and the initial bootstrap including the deployment of the Gateway Protocol Stub and the Identity Hyperty used to initialise the device.

The Residential Gateway Protocol Stub that supports the communication between the Device and Residential Gateway based on the protocol on-the-fly concept. The picture only shows a connection with the Gateway Service but the Protocol Stub could also support direct communication with other Gateway functionalities including Identity Management (authentication, authorisation) and the Registry. The Gateway Protocol Stub would also take advantage of Messaging Service features to enable pub-sub communication between devices.

https://github.com/reTHINK-project/use-cases/issues/5



The Home Energy Context Producer hyperty that contains the service logic to collect data from connected power consumer and producer devices and to calculate the Home Energy Context. It may also control the access to the Home Energy Context from other services.

The Home Identity that handles tokens to secure the communication with other devices and the Gateway.

FFS Issue: Should Home Identity be handled by an Identity hyperty that represents the Alice Home Identity running in the Device or even individuals? Such hyperty would handle Alice (family) profile in terms of energy consumption that could be used in the calculations of the Home Energy Context. Such profile would be used in other energy consumption environments e.g. vacations home.

The P2P Communicator handles p2p communication between devices on top of the WebRTC Data Channel. The new device (e.g. washing machine) features:

Runtime User Agent responsible to manage the runtime and the initial bootstrap including the deployment of the Gateway Protocol Stub and the hyperties: Identity Hyperty, Consumer, Producer Hyperties used to initialise the device and to securely register it in Management Services. See description above.

The Home Energy Context Consumer hyperty that contains the service logic to schedule the power consumption of the device according to the Home Energy Context. It may also control the access to the actuator to turn on and turn off of the device power consumption. Such hyperty would be provided by the manufacturer with the device itself.

The Residential Gateway Protocol Stub as described above for the existing device.

The Home Identity that handles tokens to secure the communication with other devices and the Gateway. This would be the same as the one featured by all other devices connected to the Residential Gateway (including the HEMS) and it is deployed when the Device successfully connects into the Residential Gateway.

The HEMS P2P Communicator Proxy setups p2p communication with the HEMS device if WebRTC Data Channel is supported and according to the traffic pattern.

The detailed message flows are depicted in the next sections for:

Device Authentication

Device Registration

Context Discovery

Communication Setup



A.2.2 Device Authentication

Figure 36. M2M Communication: Device Authentication

Steps 1 - 4: Alice connects and authenticates to the Residential GW, to provision the new device Identity Token (e.g. through a web page served by the new device Residential GW). Optionally, the GW may interact with a remote Device Management service to validate the token.

Steps 5 - 10: Alice turns on the new machine and the Runtime UA retrieves the Gateway protocol stub and the Identity Hyperty from the Gateway, by using some standard URL e.g. my.gateway. GW Protostub and Identity Hyperty are deployed in the Device runtime.

Steps 11 - 17: the Hyperty Identity authenticates using the Device ID Token check ETSI M2M ...), that the Gateway IdM will successfully verify returning an Identity token to be used in the following interactions.



Implementation Note: The current service discovery protocols are based on multicast and allow devices on the same network to share different kind of data including Address/URL without the intervention of centralized services such as DNS. The following list presents in order of importance the most used system discovery protocols:

mDNS - Multicast DNS

SSDP - Simple Service Discovery Protocol

SLP - Service Location Protocol

NDP/SEND -(Secure) Neighbour Discovery Protocol

IPv4LL - IPv4 Link-Local

A.2.3 Device Registration

Figure 37. M2M Communication: Device Registration

Steps 1 - 2: The bootstrap App requests to Register the new Energy Context Consumer hyperty through the Gateway Protocol Stub. It uses the Identity token previously provided in the Authentication phase.

Steps 3 - 5: The Messaging Server requests the IdM for authorisation to proceed with the registration providing the ID token included in the registration request. The Gateway Authorisation service applies the registration policies, verifies with ID token that the device is authenticated and authorises the registration request, returning an authorisation token. Question: since the Gateway services are all running in the same device, the interaction between them don't have to be standardised and can be implemented in a different way. However, in case an external Authorisation service is used (does it make sense in this type of use case?), such interactions would have to be standardised.

Steps 6-8: the Messaging Server forwards the Registration request towards the Registry which successfully registers the new hyperty returning a registration token (do we need this?).

https://github.com/reTHINK-project/architecture/blob/master/docs/dynamic-view/M2M%20Communication/UC5_Device_Authentication.md



A.2.4 Context Discovery

Figure 38. M2M Communication: Context Discovery

Steps 1 - 2: The Energy Context Consumer hyperty requests to discover the Home Energy Context through the Gateway Protocol Stub.

Steps 3 - 5: The Messaging Server requests the IdM for authorisation to proceed with the discovery providing the Registration token included in the discovery request. The Gateway Authorisation service applies the discovery policies, verifies with Registration token that the device is registered and authorises the discovery request, returning an authorisation token.

Steps 6-8: the Messaging Server forwards the Registration request towards the Registry. Registry finds the Energy Context Provider (HEMS) instance in its database. It performs a match between its descriptor and the Energy Context Consumer (Wash Machine) descriptor to verify that both are compliant. Both descriptors can be obtained from the Machines themselves using a URL provided in its registration or from the Gateway repository.

According to the profile of both Context Producer and Context Consumer, the most appropriate communication mode is selected returning needed URLs:

1. Pub-sub communication: the Home Energy Context object URL is returned 2. P2P Communication: the HEMS P2P Communicator URL is returned

https://github.com/reTHINK-project/architecture/blob/master/docs/dynamic-view/M2M%20Communication/UC5_pubsub_comm.md

https://github.com/reTHINK-project/architecture/blob/master/docs/dynamic-view/M2M%20Communication/UC5_p2p_comm.md



A.2.5 PUB-SUB M2M Communication Setup

Figure 39. M2M Communication: PUB-SUB Communication Setup

Steps 1 - 5: the Home Energy Context object URL is returned to the Energy Context Consumer hyperty. The Energy Context Consumer hyperty requests to subscribe to be synchronised with Home Energy Context object.

There are two options to perform the subscription authorisation:

Option1: Subscription Authorisation is enforced at the Message Server

Steps 7 - 8: The Messaging Server requests the IdM for authorisation to proceed with the subscription providing the Registration token included in the subscription request. The Gateway



Authorisation service applies the subscription policies, verifies with Registration token that the device is registered and authorises the subscription request, returning an authorisation token.

Steps 9 -12 : The Messaging Server requests the current Context object which (1) can be provided by the Energy Context Producer hyperty running in the HEMS device or (2) by another hyperty Consumer instance that persists the Context outside the HEMS device.

Option2: Subscription Authorisation is enforced at the Context Producer

Steps 13 - 17: The Messaging Server forwards the subscription requests towards the Context Producer itself which will apply subscription policies to ask the local (hyperty) Identity on whether the new machine is trustful. The (hyperty) Identity will use the Registration token provided in the subscription request to verify that the new machine is authenticated and registered in the gateway.

FFS issue: does this verification require additional interactions between local Identity and the Gateway IdP?

Steps 18 -19: assuming the assessment is positive, the Context Producer returns the current Context object.

Steps 20 - 22: the Context Consumer receives the current Context object and instantiates it locally, applying its logic to schedule the new machine power consumption plan.

A.2.6 P2P M2M Communication Setup

Figure 40. M2M Communication: P2P Communication Setup



Steps 1 - 5: the HEMS P2P Communicator Proxy URL is returned and used to deploy it in the new machine runtime. The Energy Context Consumer hyperty requests to subscribe to be synchronised with Home Energy Context object. Then the HEMS P2P Communicator Proxy is instantiated and a Communication object to control the P2P communication between the new device and the HEMS is created.

Steps 6 - 7: the HEMS P2P Communicator Proxy interacts with remote HEMS P2P Communicator to request to setup a P2P connection between the two devices. The HEMS P2P Communicator will apply P2P incoming communication policies to ask the local (hyperty) Identity on whether the new machine is trustful. The (hyperty) Identity will use the Registration token provided in the P2P Communication request to verify that the new machine is authenticated and registered in the gateway.

FFS issue: does this verification require additional interactions between local Identity and the Gateway IdP?

Steps 8 - 12: assuming the assessment is positive, the HEMS P2P Communicator Proxy accepts the request and a P2P Communication is established between the two devices and its associated Communication Object URL is returned to the Energy Consumer.

Steps 13 - 16: The Energy Context Consumer hyperty requests to subscribe to be synchronised with Home Energy Context object through the P2P Communication channel previously established.

Step 17: the subscription request reaches the Context Producer which will apply subscription policies to ask the local (hyperty) Identity on whether the new machine is trustful. The (hyperty) Identity will use the Registration token provided in the subscription request to verify that the new machine is authenticated and registered in the gateway.

Steps 18 - 19: assuming the assessment is positive, the Context Producer returns the current Context object.

Steps 20 - 21: the Context Consumer receives the current Context object and instantiates it locally, applying its logic to schedule the new machine power consumption plan.

[End of Document]

Documents

Final design of the Architecture - bscw.rethink-project.eu Final design of the... · Final design of the Architecture Editor: Eric Paillet, Orange Labs Deliverable nature: (R) Document,