Framework Architecture Definition Framewor… · The reTHINK Perspective (Chapter 5), reference...

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

© reTHINK consortium 2015 of (151)

Deliverable D2.1

Framework Architecture Definition

Editor: Rebecca Copeland, Institut Mines Telecom, (Telecom Sud-Paris)

Deliverable nature: (R) Document, Report

Dissemination level: Public (PU)

Contractual delivery date: 31/07/2015

Actual delivery date: 31/07/2015

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

Version: Release 1.0

Total number of pages: 151

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), extensive study of the state of the Art (Annex A) and use-cased (Annex-B). 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, using collaborating networks of special web media gateways. 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.1

of (151) © reTHINK consortium 2015

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.1 Technical Requirements derivation, T2.2 Reference Architecture Design Document title: Framework architecture definition Editor: Rebecca Copeland, IMT – TSP Work-package leader: Eric Paillet, Orange

Copyright notice

2015 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 (human to human and machine to machine). 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. The reTHINK architecture is built around these Hyperlinked Entities (hyperties). 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. Other aspects of interoperability are also considered by the solution, for independent identity management and for collaborating transport networks.

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.

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.

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 Special 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 Contribution

IMT

Rebecca Copeland

General edit, Requirements, abstract, executive Summary, The reTHINK Perspective (Chapter 5), reference architecture diagrams, SotA summary, , IMS SotA, positioning between VoLTE and OTT (SotA), architecture summary (Chapter 10)

Ahmed Bouabdallah Context SotA, Policy Management

Ibrahim Javed webRTC SotA

Orange

Eric Paillet Requirements, SotA, Architecture overview diagram

Simon Bécot Requirements, run-time architecture, apps interoperability

Ewa Janczukowicz Specialized Network Services (SNS) and its CSP Hosted Functions

Kevin Corre Identity and Trust management

Jean-Michel Crom Identity and Trust management

PTIN Paulo Chainho Hyperty and ProtoFly concepts, Requirements, SotA for SOA/IMF, Architecture overview, Dynamic overview

TUB Felix Beierle SotA, Identity, Directory/Registry, Graph, Context

Sebastian Göndör SotA, Identity, Directory/Registry, Graph, Context

Apizee Frédéric Luart Requirements, CDR transfer solution

FOKUS

Adel Al-Hezmi Requirements, SotA on Device Management (DM), SotA on M2M, Architecture new component

Andreea Ancuta Corici Apps interaction, Comments

Marc Emmelmann Overview of concepts that can be enabled with well-known core and DM

INESC-ID

Ricardo Lopes Pereira P2P SotA, directory services

Ricardo Chaves Identity and Trust Management SotA, security policies

Nuno Santos Identity and Trust Management SotA, security policies



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 About This Document ............................................................................................................ 14

2 Requirements ................................................................................................................................ 16

2.1 The Requirement Scope ........................................................................................................ 16

2.2 Actors’ Role Definition........................................................................................................... 16

2.2.1 Identifying Actors .......................................................................................................... 16

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

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

2.4 Requirements Capture .......................................................................................................... 20

2.4.1 Business Requirements ................................................................................................. 20

2.4.2 Testing Requirements.................................................................................................... 20

2.4.3 Non Functional requirements ....................................................................................... 21

2.4.4 Functional requirements ............................................................................................... 22

3 State of the Art (SotA) ................................................................................................................... 29

3.1 Research Topics within the reTHINK Scope........................................................................... 29

3.1.1 SotA for User Context Environment .............................................................................. 29

3.1.2 SotA for Service Architecture ........................................................................................ 29

3.1.3 SotA for the Delivery Platform ...................................................................................... 29

3.1.4 SotA for Independent Identity Management ................................................................ 30

3.1.5 SotA for Policy and Security .......................................................................................... 30

3.1.6 SotA for Special Network Service .................................................................................. 30

3.1.7 SotA for Device Management ....................................................................................... 30

3.2 List of annexed State of the Art studies ................................................................................ 31

4 ReTHINK Architecture Perspective ................................................................................................ 32

4.1.1 Global Reach and Ubiquity ............................................................................................ 32

4.1.2 ‘Best Effort’ and Guaranteed QoS ................................................................................. 32

4.1.3 Comparing Client-Server with Peer-to-Peer .................................................................. 32

4.1.4 Independent Identities & Traditional ID Numbering .................................................... 33



4.1.5 The concept of the Hyperty ........................................................................................... 33

4.1.6 Achieving Interoperability via ProtoFly ......................................................................... 34

4.1.7 Service Delivery via Roaming, OTT Apps and ProtoFly .................................................. 34

4.1.8 Leveraging the Best of Both .......................................................................................... 34

5 ReTHINK Architecture Overview ................................................................................................... 35

5.1 The reTHINK Framework ....................................................................................................... 35

5.2 Session Management ............................................................................................................ 36

5.2.1 Distributed Session Control ........................................................................................... 36

5.2.2 Messaging Services ........................................................................................................ 37

5.3 Identity Management (IdM) .................................................................................................. 38

5.3.1 Identity Assumptions ..................................................................................................... 38

5.3.2 Trust Manager Functionality ......................................................................................... 39

5.3.3 Granting Authorization .................................................................................................. 39

5.4 Specialised Network Services (SNS) ...................................................................................... 39

5.5 Network-Side Services ........................................................................................................... 40

5.5.1 Catalogue ....................................................................................................................... 40

5.5.2 Registry .......................................................................................................................... 40

5.5.3 Discovery ....................................................................................................................... 41

5.5.4 Governance ................................................................................................................... 41

5.6 Communication Applications ................................................................................................ 41

5.6.1 End-user Services .......................................................................................................... 41

5.6.2 Applications Types ......................................................................................................... 42

5.6.3 Monitoring Presence, Availability and Context ............................................................. 42

6 ReTHINK Innovative Instruments .................................................................................................. 43

6.1 The Hyperty (Hyperlinked Entity) .......................................................................................... 43

6.1.1 Example1: WebRTC Conference .................................................................................... 44

6.1.2 Example 2: WebRTC Multiparty Conference in a Star Topology ................................... 44

6.1.3 Example 3: Contact List enriched with Presence Status ............................................... 45

6.1.4 Example 4: Data Processing in the Cloud ...................................................................... 46

6.2 Hyperty Communication ....................................................................................................... 46

6.2.1 Assumptions .................................................................................................................. 46

6.2.2 Hyperty Application API ................................................................................................ 47

6.2.3 Hyperty Communication Modes ................................................................................... 47

6.3 Hyperty Compatibility ........................................................................................................... 48

6.3.1 Interworking Options .................................................................................................... 48

6.3.2 Compatibility via Schema .............................................................................................. 48



6.3.3 Hyperty Types ................................................................................................................ 50

6.4 Protocol-on-the-Fly (ProtoFly) .............................................................................................. 50

6.4.1 The ProtoFly Interfaces ................................................................................................. 50

6.4.2 Main ProtoFly Procedures ............................................................................................. 51

6.5 Effects of Hyperty and ProtoFly ............................................................................................ 53

6.5.1 Concerns about Performance and Protocol Conversion ............................................... 53

6.5.2 One-Sided CSP Connection ............................................................................................ 53

6.5.3 Enterprise security concerns about accepting downloads............................................ 54

6.5.4 Capacity at the Endpoint ............................................................................................... 55

6.5.5 Service Compatibility and ProtoFly ............................................................................... 55

6.5.6 Impact on Device Power Consumption ......................................................................... 55

6.5.7 Impact on Network Traffic ............................................................................................ 56

7 Identity Management for H2H and M2M ..................................................................................... 57

7.1 Identity Management Concepts ............................................................................................ 57

7.1.1 Identifiers ...................................................................................................................... 57

7.1.2 IdP Design Assumptions ................................................................................................ 57

7.1.3 Multiple IdPs and multiple identities ............................................................................ 58

7.1.4 Identities when switched off ......................................................................................... 59

7.2 Graph Connector and GraphID .............................................................................................. 59

7.2.1 Proposed reTHINK GraphID ........................................................................................... 59

7.3 Identity Management Hyperty .............................................................................................. 61

7.4 M2M/IoT Identities ............................................................................................................... 62

8 Service Delivery and Interoperability ............................................................................................ 63

8.1 Application Interoperability .................................................................................................. 63

8.1.1 Application Interoperability .......................................................................................... 63

8.1.2 Case 1: Temporarily Enrolling or Using Service B .......................................................... 64

8.1.3 Case 2: Protocol on the Fly to integrate B into A .......................................................... 65

8.1.4 Case 3: Fully interoperable A and B............................................................................... 66

8.1.5 Summary of Use Cases .................................................................................................. 67

8.2 CSP to CSP Interoperability ................................................................................................... 67

8.2.1 CSP to CSP Interoperability ........................................................................................... 67

8.2.2 User Discovery Services ................................................................................................. 67

8.2.3 Global Registry............................................................................................................... 68

8.2.4 Session Reports and CDRs ............................................................................................. 69

9 Specialized Network Services ........................................................................................................ 71

9.1 CSP and NSP Relationship...................................................................................................... 71



9.1.1 CSP Hosted Services Assumptions ................................................................................. 71

9.1.2 NSP Assumptions ........................................................................................................... 71

9.1.3 CSP and NSP relationship .............................................................................................. 71

9.1.4 Brokering NSPs .............................................................................................................. 71

9.2 Managing QoS and Security Levels for User Sessions ........................................................... 72

9.3 Delivery Network Interoperability......................................................................................... 72

9.3.1 Case 1: Brokering ........................................................................................................... 73

9.3.2 Case 2: Hosting infrastructure interaction .................................................................... 73

9.3.3 Case 3: Neutral Collaboration ....................................................................................... 74

10 ReTHINK Architecture Summary ............................................................................................... 76

References ............................................................................................................................................. 79

State of the Art (SotA) ....................................................................................................... 84 Annex A

A.1 User Communication Environment ....................................................................................... 84

A.1.1 Modes of Communications ........................................................................................... 84

A.1.2 Contextual Communication ........................................................................................... 86

A.1.3 Online Social Networks.................................................................................................. 87

A.1.4 M2M Communication ................................................................................................... 90

A.2 Service Architecture .............................................................................................................. 91

A.2.1 IMS and VoLTE ............................................................................................................... 91

A.2.2 Client Server Architecture versus Endpoint Centric Approach ..................................... 95

A.2.3 Web Services and SOA ................................................................................................... 95

A.2.4 RESTful APIs ................................................................................................................... 97

A.3 The Delivery Platform Framework ........................................................................................ 98

A.3.1 TMF Service Delivery Platform ...................................................................................... 98

A.3.2 Peer to Peer Architecture .............................................................................................. 99

A.3.3 WebRTC Media ............................................................................................................ 101

A.3.4 Signalling protocols and Gateways .............................................................................. 104

A.4 Identity and Trust Management ......................................................................................... 105

A.4.1 IdP Capability – Current Status .................................................................................... 105

A.4.2 The generic Identity Management model ................................................................... 106

A.4.3 Identity Management by Telecom Operators ............................................................. 107

A.4.4 Identity Management in Online Social Networks ....................................................... 109

A.4.5 Web identity (and SSO) ............................................................................................... 109

A.4.6 Server-side Trust management .................................................................................. 111

A.4.7 Blockchain.................................................................................................................... 114

A.4.8 Directory Services ........................................................................................................ 115



A.5 Policy and Security .............................................................................................................. 118

A.5.1 Security Policies ........................................................................................................... 118

A.5.2 Policy Management ..................................................................................................... 123

A.5.3 Policy deployment architectures ................................................................................. 124

A.6 Specialized Network Services (SNS) .................................................................................... 126

A.6.1 Why SNS are needed ................................................................................................... 126

A.6.2 How SNS can be offered .............................................................................................. 127

A.6.3 What is expected of SNS.............................................................................................. 128

A.7 Device Management (DM) .................................................................................................. 128

A.7.1 Smart Objects .............................................................................................................. 128

A.7.2 OMA DM ...................................................................................................................... 129

A.7.3 OMA LWM2M .............................................................................................................. 129

Case Studies ..................................................................................................................... 131 Annex B

B.1 H2H Communication high level view .................................................................................. 131

B.1.1 Registration with External Identity Use Case .............................................................. 134

B.1.2 User Login with External Identity ................................................................................ 135

B.1.3 Inter-domain Conversation with different CSPs and IdPs (Detail) .............................. 137

B.1.4 Invitation ..................................................................................................................... 140

B.1.5 Alice Identity Assertion and Invitation Accepted by Bob ............................................ 142

B.1.6 Bob Identity Assertion and Communication Setup Completed .................................. 143

B.2 M2M Case Studies ............................................................................................................... 144

B.2.1 M2M Always Connected in Trustful Domains for Multi vendor devices .................... 144

B.2.2 Device Authentication ................................................................................................. 146

B.2.3 Device Registration ...................................................................................................... 147

B.2.4 Context Discovery ........................................................................................................ 148

B.2.5 PUB-SUB M2M Communication Setup ........................................................................ 149

B.2.6 P2P M2M Communication Setup ................................................................................ 150



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

The goal of this work is to shape the overall reTHINK architecture and to coordinate the technical work on the reTHINK framework and platforms. 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.

The scope of this document is to present the design of the 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

The expected output is a reference model that fulfils the overall objectives of the reTHINK project, expressed by:

Provision of a comprehensive view of the reTHINK Framework architecture,

Validation of the overall reTHINK architecture through dynamic views.

1.2 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 a 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 indicates possible functional implementations. 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 an 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.1 of the project, which is one of three deliverables of the architecture work:

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 DoW (Document of Work) states: “The main goal of the reTHINK project is to design and prototype a new, non telecom centric, but Web-centric P2P Service Architecture, enabling dynamic trusted relationships among distributed applications called Hyperlinked Entities (“hyperties”) that support use-cases beyond commoditized telephony such as contextual and social communications, M2M/IoT and content oriented services. This project will enable any type of service delivery through specialized end-to-end network quality commitments, powered by specialized P2P and/or Cloud services (delivered as SaaS, PaaS or IaaS).”

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)

Techniques of conversion of signalling and media.

In producing a prototype solution, some of the above will be implemented and simulated, but these are not the goals for the reTHINK project.

The output of the architectural design should be:

Definitions of the functional roles

Definitions of the architectural functional elements

Definitions of the exposed interfaces to be standardised or satisfied by existing protocols

Definitions of APIs, with their input and output data and high level functionality

Definition of the functionality of the hyperty and its interaction

Network diagram of signalling interaction

Network diagram of the media flow

Network diagram of the Identity service and data flow

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 ‘actor’s 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.

Platform/ Enabler Combines the roles such as business “Broker” or “Identity Provider” as well as Platform or Hosting Providers.

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 a service to a service consumer.

Developers - Professionals who design and produce software.

Regulator Authority

-

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

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 Role Descriptions

2.2.2.1 End User or Service consumer:

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.

2.2.2.2 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.3 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.4 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.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 OpenID Connect Discovery services. It is likely that any IdP would also provide such a discovery service.

2.2.2.6 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 classified and allocated to the project iteration where it will be addressed. Such allocation will be reviewed according to feedback received from design and implementation tasks.

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:

One or more related use case coming

A referral to a reference document

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.

2.4 Requirements Capture

The requirements have been captured under four headings: business requirements, testing requirements, non-functional requirements and functional requirements.

2.4.1 Business Requirements

The business requirements describe consideration of costs, feasibility, business relationships, flexibility of business models, as well as functionality of chargeability and accounting features. Some of them have been defined in work package 1 and some others are included in Functional requirements.

2.4.2 Testing Requirements

Testing requirements identify what needs to be included in the tests of the proof-of-concept.

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



2.4.3 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

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

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

NF3 M Architecture design

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

DoW

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

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.

NF6 M Terminal independence

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

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.

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.

NF9 M Secured Communication Communication between entities must be trusted and secure DoW



Id Name Description Related to

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

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.

2.4.4 Functional requirements

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

Table 5 Functional Requirements

Id Name Description Related to Category

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

F2 S Explicit trust level on identity

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


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

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

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


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.





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

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

F9 C Network QoS Management

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

DoW Network Connectivity

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

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).


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.


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

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

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.

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

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.




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.

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.

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.

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.

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

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

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




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.


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.


F28 M Discovery of Communication Peers

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

Human Context

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

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

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).


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.





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.


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


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


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





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


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

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


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.





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

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



3 State of the Art (SotA)

3.1 Research Topics within the reTHINK Scope

The reTHINK project aims to prototype delivery of communication services over the Internet, which provides good quality services that support both Voice/Video and M2M real-time interactions. Such an undertaking requires investigation of all aspects of modern communications, encompassing advanced Internet mechanisms, emerging IT architectures and platforms, and Telecom standards and frameworks. An extensive State of the Art (SotA) has been conducted by the project partners on a wide range of topics. The full study is attached in Appendix A. It comprises literature research and standards reports on the following:

3.1.1 SotA for User Context Environment

The reTHINK solution is designed for the evolving user digital ‘habitat’, which merges web information sharing with mobility and immediacy. The user environment today requires new modes of communications, involving a variety of social applications, Internet of things, and context based ad-hoc or click-to-talk communications. A thorough study was conducted on the future user communication environment and the roles /actors and stakeholders who combine their effort to satisfy the requirements, which were captured in scenarios and use-cases, to guide the development of the solution.

3.1.2 SotA for Service Architecture

Recently, strong arguments have been made (as in [42]) that Telco’s delivery platforms should not only interwork with web architecture, but that the infrastructure should evolve towards a new control plain, while using the Web as the media transport network. H. Sinnerich [44], one of the ‘fathers’ of SIP (Session Initiation Protocol), calls for Voice and Video real time communications to be shifted to the web, to provide richer Internet applications to larger numbers of consumers, at a lower cost. He suggests moving all VOIP data transport to HTTP and placing the VOIP service logic at the endpoints.

This view is adopted by the reTHINK project. The project focus is providing a new service framework with session control in the endpoints, while enabling communication applications to utilize network resources and facilities that enhance the service delivery by improved QoS and security.

To understand the new paradigm, the evolution of the service framework is investigated, from the IT world concepts (SOA, ROA, TMF Framework), legacy Telecom core networks evolution (IMS, VoLTE), evolving Cloud, and virtualized functions. The IMS service architecture main failing is that it does not fit the modern landscape of context based and browser-based communication services. The evolving independence of network layers means that devices, access, core networks and applications are no longer provided by a single network service provider. Hence, a new way for multiple stakeholders to interact and collaborate has to be devised, allowing for autonomy of applications, session control, service media transport, as well as the user’s identity and privacy preferences.

This service environment requires adopting Resource Oriented Architecture (ROA), where resources are provided by different service providers. Inspired by common web services, this service environment should rely on data transfer oriented techniques (e.g. RDF - Resource Description Framework) more than standard protocols and dialogues.

3.1.3 SotA for the Delivery Platform

This delivery ‘platform’ for reTHINK has to be highly distributed, allowing for service providers to operate in a global market. This platform should provide complete independence of the underlying technology (protocols) and underlying Operating System (OS) software base, with high extensibility



and modularity. Hence, various service frameworks, including peer-to-peer, are studied in this SotA, and peer-to-peer protocols are examined closely. Service architecture (SDN/NFV, virtualization, Cloud, service orchestration, smart edge) and new internet-based collaboration that enables web calling apps to incorporate APIs and redirect to alternative web services, are also studied. The mechanisms that are investigated are browser based Media stream management (webRTC, webSocket, HTML5…), and gateway protocols (TURN, STUN, ICE…), which can be utilized as the basis for innovative media management for QoS based web communication. Web technologies are utilized in preference to SIP (Session Initialisation Protocol), to enhance programmability and address webRTC issues, such as the JSEP (JavaScript Session Establishment Protocol) architecture, which is based on JavaScript.

3.1.4 SotA for Independent Identity Management

The new architecture necessitates that users have independent identity authentication process, which is not reliant on a single service provider, but enables users to manage their identity. Internet Identity mechanisms are developing this concept with methods such as OpenID, webID, SSO, OSN and FOAF, and latest W3C and IETF documents standardise how identity is described, discovered and verified independently of any service or network membership. The role of the IdP (Identity Provider) is investigated, and the wider scope of identity management is explored, including what information is provided by additional resources and how privacy of such information is maintained.

To support the new web-based communication service, user directories and discovery services are required, so existing directories (e.g. DNS) are considered. In addition, techniques borrowed from the Online Social Networks world, such as social network graph, may lead to new ways of linking users and find destinations.

3.1.5 SotA for Policy and Security

While the ‘open’ Internet is regarded as ‘unmanaged’, the reTHINK solution introduces QoS and security management of the media payload flow, using special media gateways when routing through the Internet. This requires defining and conveying policies and rules that protect users and ensure appropriate use of resources. Recently, issues concerning policy management, privacy and security have led to growing volumes of studies, embracing numerous concepts, some of which are explored. Such concepts were previously developed for fully managed ‘federated’ networks, so they need to be adapted to web communications, with looser control of merely ‘collaborating’ parties, Internet-style. This project needs to address the way policies are described, negotiated and enforced in this different paradigm. This includes defining applicable operations (refinement, composition), self adapting policies in autonomous computing, and policy consistency analysis.

3.1.6 SotA for Special Network Service

The difference between current Internet communication applications and the proposed solution lies in the enabling of open APIs that offer applications the use of special hosted network services. It is envisaged that any service and network provider will publish a set of capabilities that can amount to a complete communication service, or just particular facilities.

3.1.7 SotA for Device Management

Since the proposed solution centres on downloading software to endpoints, where session control is executed, the management of devices must be taken into account. The OMA standards and lightweight management of M2M devices are considered in terms of running the reTHINK solution.



3.2 List of annexed State of the Art studies

As there is a wide range of topics of interest, for which extensive state of the art studies were made, the full text has been placed in an attached annex (A). The list of studies in the appropriate sections of annex A is given in the following table.

Table 6 Annex listing of State of the Art Studies

Topic Description

A.1.1 User Communication Environment

Context communication, ubiquitous communication, online social network communication, M2M communication, and the future communication environment inspiring the use-case selection,

A.1.2 Service Architecture Existing architectures, including IMS, SOA, Server/Client, SOA framework, RESTful APIs, ROA (Resource Oriented Architecture), and Code-on-Demand.

A.1.3 The Delivery Platform Framework

The TMF platform in contrast with peer-to-peer, media using webRTC, webRTC control layer, signalling protocols and gateways.

A.1.4 Identity, Trust and Directories

The concept of IdP (Identity Provider), identity management, legacy Telecom identity structure, social networks identities and graph connectors, web identities (OpenID, WebID), server-side authenticated identity, trust framework, directories services.

A.1.5 Policy and Security Security and privacy policy, policy languages, policy enforcement, web browser security, policy management, lifecycle and deployment architecture.

A.1.6 Special Network Services (SNS)

Defining why SNS are required, what they can offer, and what can be expected from them.

A.1.7 Device Management

Smart objects and M2M devices, standards by OMA, including Lightweight M2M (LWM2M).



4 ReTHINK Architecture Perspective

The reTHINK architecture can be positioned at the half-way house between web based VoIP on one hand, which is provided as OTT (Over The Top) services that do not involve the domain or the network providers, and fully managed packet network VoLTE (Voice over LTE), which is provided by mobile operators, with their own native applications.

4.1.1 Global Reach and Ubiquity

OTT service characteristics are typical to web applications, which enjoy global reach. They are unlicensed and unfettered by regulation (though compliant with the country’s laws), hence enjoy greater flexibility. However, only the most well known web players gain full consumers’ trust.

By contrast, Mobile communications are constrained by their licensed territory, and are subject to strict regulation, but they engender higher consumer trust.

In reTHINK, global reach is achieved via web-based signalling and media transport, which is provided by trusted entities with good business track record, even when the front-end application is a new web start-up, thus combining innovation and flexibility with trustiness and stability.

4.1.2 ‘Best Effort’ and Guaranteed QoS

As VoLTE (Voice over LTE) is now rolling out in Mobile networks, the traditional Telecom communication systems provide privately managed delivery networks that guarantee levels of QoS and security, according to agreed service level agreements. This paradigm is now challenged by the advent of webRTC communications that promise to exceed the capabilities of previous VoIP services.

The OTT service is ‘unmanaged’, delivered by the Internet ‘best-effort’, which is entirely dependent on the underlying access and the Internet usage fluctuation. This is particularly noticeable with real-time Voice/Video connectivity, which requires steady, predictable, high quality delivery, as is delivered by managed Voice networks, which can provide QoS and policy guarantees. Delivery of QoS in reTHINK is only restricted by the implementation of the network Turn/STUN servers by the participating NSPs, but is not based on cross-network agreements, such as roaming.

The reTHINK architecture enables activating QoS and policy as selectable options, via APIs to the service providers. While OTT services have no such choice, and Mobile services automatically provide managed QoS over managed packet network, the reTHINK architecture can deliver QoS ‘on-demand’ over the Internet, selected only where necessary, according to network conditions, user preference and service requirements.

4.1.3 Comparing Client-Server with Peer-to-Peer

The OTT services are web-based, with a server-client architecture, where session processing is performed in the network-based servers, which are now utilizing cloud technology to gain ubiquity. Mobile applications are native, built-in the mobile handsets or downloaded from app stores. Such mobile apps may execute only locally, but many connect to the web server in client-server architecture style.

By contrast, 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.

4.1.4 Independent Identities & Traditional ID Numbering

The OTT applications are exclusive – they exclude anyone who is not a subscriber. Subscription-bound applications allocate user IDs, which are unique to the specific application (or the responsible service provider), but are not globally routable. Recognizing the vulnerability of this method, as well as its unfriendliness, web identities are evolving towards various ‘single-sign-on’ arrangements and independent verification of users.

Mobile networks identities are SIM-bound, but they provide globally routable identities in the international numbering scheme, where cross domain connectivity is achieved by close co-operation of all the federated mobile networks. Unique numbering is achieved by structuring parts of the identifiers by association to entities (operators) who manage numbers that are allocated to them. The provision of non-regional numbers (‘non-geographical numbers) and even country independent numbers is still performed via operators the issuing SIMs, who have been allocated blocks of numbers, thus routing is executed via the involved operator.

In reTHINK, the aim is 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.

4.1.5 The concept of the Hyperty

The reTHINK project explores the idea of the Hyperty (Hyperlinked Entity) as the mechanism of dynamic software distribution that enables communications. Such hyperties may be concerned with peer-to-peer communication, identity management and context management.

The communication hyperty is a means for enabling peer to peer communication, where session control is downloaded and executed at remote devices and edge servers, i.e. - not at the core servers on the service provider’s platform, as in traditional architectures, and not at the website server, as in the traditional Internet based VoIP (Voice over IP). Hence, this represents a new concept that reTHINK explores.

Communication 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.

As these hyperties are terminated when the runtime service shuts down, new hyperties instances are downloaded whenever the device is switched on, or the service is initiated. Therefore, up-to-date ‘clean’ versions are always available at the endpoints.

Communication hyperties gain a certain level of autonomy, which will be explored in the design phase. They manage session initiation via the service provider’s core platform to allow for destination discovery and authentication, and for QoS-based routing, etc. However, the communication hyperties manage the session media flow independently and can interact with local apps and other hyperties.

Running communication hyperties represent ‘live’ users who are available for incoming communications. Each service provider’s domain retains knowledge of its ‘live’ hyperties and enables connectivity with other domain’s running hyperties.



4.1.6 Achieving Interoperability via ProtoFly

Interoperability has always been the corner-stone of the Telecom networking ideas, where each carrier or service provider complies with well structured agreed standards. The web world achieves compatibility by de-facto prevailing mechanisms that can morph and evolve much faster, but particular services are dominated by few large players, who require all users to join, with no inter-service interworking.

The reTHINK project offers a solution to the issue of interworking without waiting for new standards. 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. This process is named ‘ProtoFly’ – Protocol on the Fly.

4.1.7 Service Delivery via Roaming, OTT Apps and ProtoFly

The OTT services achieve inter-operability by forcing all users to become subscribers of the same service, running the same software features with the same protocol stack. Mobile services achieve features interoperability by standards (e.g. CAMEL), and by relaying service messaging to the Home network from the Visited network. This means that services logic is executed at the remote home network, but messages are relayed across by roaming agreements and standard dialogues.

In reTHINK, interoperability is simply provided by downloading the software of the initiating domain onto the destinations’ endpoints, using the ProtoFly process. If such downloading is accepted, connectivity is assured even without the destination user having a subscription (unlike OTT), so users need not share the same application or the same domain to be connected.

4.1.8 Leveraging the Best of Both

As shown above, the reTHINK architecture can be positioned between the two extremes of VoLTE and OTT, leveraging the best of both in terms of selectable QoS and policy, non-exclusive participation, low cost peer-to-peer session control, independent global identity and Light-touch compatibility. As a middle-way service, it provides another alternative to delivering advanced communications.



5 ReTHINK Architecture Overview

5.1 The reTHINK Framework

The reTHINK Framework enables communications between people (Human-to-Human, H2H) but also communications with objects (IoT, smart cities…) or with 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 between 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.

In Figure 3, the way hyperties are produced, catalogued, discovered, downloaded and registered is shown. It shows the stakeholders: the CSP platform (right), the ASP (top), the Identity Provider (bottom), and the users (left), who may be a person or a group, and may have multiple terminals, or a machine 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

5.2 Session Management

5.2.1 Distributed Session Control

The functional architecture describes the functions and services that the reTHINK project addresses. The functional descriptions of the architecture components are given in Figure 4. These functions reside not only at the CSP platform, but also across the user devices, where software is downloaded and executed locally, 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

5.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 User Service type agnostic playing a key role in reTHINK architecture, by providing functionalities to support Hyperty instances communication.

Usage examples:

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).

5.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.

5.3.1 Identity Assumptions

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



The Identity Provider is an actor whose main business is the delivery of Identity assertion functionalities to other 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 IdP per user (if allowed at all) is a matter for IdP policies. Discovering the user’s IdP (unique or multiple) is performed by each IdP or by an Identity Broker.

5.3.2 Trust Manager Functionality

Trust management is a wider research topic that is germane to the reTHINK project. The touching points of reTHINK and trust management include (but not exhaustively) the following:

Users linkage with Hyperty identifier

Non-transient Inter-hyperty links that form social ‘circles’ of trust and contact lists

IdP Brokering, IdP search

Policies for multiple IdP per user

Authority that certificates IdP

Temporary and transient IdP registration

Anonymous users via IdP.

5.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 Interne-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.

While authentication is devolved to the IdP, this means that the IdP authenticates the user’s credentials, using provided information and solicited independent information, but it is not able to authorize 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 a priori 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.

5.4 Specialised 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 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 than previously prevailed in Telecom.

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.

Specialised 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 responsible CSP 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’s platform, i.e. by the Communications Setup module, which handles the policy negotiation with the network providers.

5.5 Network-Side Services

Server-side services (to distinguish from device-side as well as web based services) are those 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.

5.5.1 Catalogue

Catalogue is the functional element that lists the services available for service domain (namely a service provider). It provides access to Services assets including service descriptions, software services, 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).

5.5.2 Registry

The Registry is a specific component of the reTHINK architecture, dedicated to hyperties. The hyperty Registry provides functionality of a directory service to find users’ addresses and availability. The Register 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 hyperty 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 hyperty Registry, and these records are maintained to keep the Registry up to date. For this purpose, the hyperty Registry provides an interface for registration and deregistration of hyperty instances, as well as for keeping the published information up to date.

5.5.3 Discovery

In the reTHINK architecture, user discovery is the service used to find destination users, on whichever device they are currently logged on, in order to launch a connectivity request towards them.

The reachability of users hinges on associating hyperty instances with users. Users requesting connectivity establish the CSP domain for the target destination via a search of IdPs, who may need to establish first which IdP has the destination’s address.

The proposed process involves the instigating software sending an enquiry towards the domain hosting the destination user, according to the URL. On receiving the enquiry, the destination CSP performs a looks up procedure on its Registry of active hyperties, and responds with the hyperty’s address, if found there. If not found, the user is unavailable.

The CSP registry is, in fact, a location manager for ‘live’ user hyperties. Such always-on registries can form a mesh of servers that may (with appropriate security measures) allow inter-registry search. This mechanism is essentially the same as above, but with a direct approach, basing the procedure on a search engine of distributed dynamic data, similar to ‘Dynamic DNS’.

5.5.4 Governance

The governance of the reTHINK platform includes supporting the management of hyperties life-cycle, Users (including devices and “things”) accounts life-cycle as well as business partnership life-cycle. These functions must support the identified non-functional requirements and the business models that will be developed for reTHINK. Governance functions also include Privacy Policy Management and local user accounting.

5.6 Communication Applications

5.6.1 End-user Services

End User Services are services running in end-users 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 App Market Place Apple App Store.

The end-user can be a human being, or a non-human being, but 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 via CSP search of the Registry. 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.

5.6.2 Applications Types

A web communication app is a browser based web application that facilitates webRTC (or similar) communications. 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 term 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 mobile software clients do. In either case, the application can access the CSP’s communication facilities, and interact with the hyperties on the device.

5.6.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 (hyperty), running in end-user’s device, that is in charge of providing and publishing user’s context, using different sources. The registry from the (hyperty) Service Provider will store this information against the relevant hyperty. 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 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.



6 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.

6.1 The Hyperty (Hyperlinked Entity)

Hyperty is a service deployable in a runtime environment, in an end-user device that can interwork with a Web Browser or native app. Hyperties may also reside on a networked server that acts as a user agent or a server-based endpoint. 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 6 are:

It is a Reusable Script implementing a Service Logic (e.g. a JavaScript file)

An instance is usually associated to a “User” (e.g. Human beings, physical objects, physical spaces, organizations) through an Identity, even if this 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).

It has communication capabilities. This means that it can be considered as an endpoint of a communication. This also implies that it is reachable, for example, in a Human to Human communication (Audio call) the E.164 address could be considered the reachable address of the person associated of the hyperty service used for the call. We can consider that hyperties are provided by a Service Provider, and authenticated by Identity Management functionality.

Figure 6. 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 the User logs out, the hyperty is de-registered and destroyed. This hyperty registration is done each time the service is used.



6.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 7. Hyperty Web Conference Example

6.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 8. Hyperty Multiparty Web Conference Communication Example

6.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 9. Hyperties Example for Presence Enriched Contact List



6.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 10. Hyperties Example for Data Processing in the Cloud

6.2 Hyperty Communication

Hyperties can communicate with each other in two ways:

Message communication where asynchronous messages are exchanged among hyperty instances.

Stream Communication where media streams are established among hyperties instances to support audio, video and data communication among hyperties instances.

6.2.1 Assumptions

The hyperty should leverage the simplicity of REST-based Web Services in a P2P Networking Architecture (i.e. opposed to the REST client-server Architecture). This means hyperties are both suppliers and consumers of resources that can share tasks or workloads. Hyperties are also manageable Software Enabled Services (SES), leveraging work done by TM Forum SDF/SES Community where SOA (Service Oriented Architecture) principles are applied in Telco domain.

The reTHINK service can operate even when streaming data is not involved. In some cases, message communication is all that is needed, for example in IoT services.

If stream communication is needed, it is supported by the WebRTC standards.

The candidate solution to support message communication is the ProtoFly concept. ProtoFly enables seamless interoperability between different domains with no need to standardize the protocol used but only the messages data model.

The ProtoFly procedures should be applied at the end-user client but it is also feasible between Messaging Services. For example, in highly secured networks (like the banking industry) where end-users are not allowed to download software, the server will vet and verify the downloaded software on behalf of the user devices.

https://github.com/hypercomm/wonder/wiki/Signalling-on-the-fly



6.2.2 Hyperty Application API

In addition to the communication between remote hyperties and between hyperties and Server nodes described above, the hyperties expose local (JavaScript) APIs that can be used within the runtime that executes them, to be used by the Web applications.

Assumptions

Hyperty API is not subject to standardisation, since the communicating hyperties are produced by the same CSP platform.

Hyperties seamless interoperability between domains is assured, since the Protocol on-the-fly is used.

The main impact is that Applications will have a dependency on the hyperty API used.

6.2.3 Hyperty Communication Modes

Hyperties support two communication modes:

media stream mode through WebRTC

message mode, in a REST fashion.

Different communication types can be identified:

communication with messaging services e.g. via web sockets

communication with rest API as a client and/or a server (In this case, a server node may not be useful, as they could in certain conditions has a direct P2P REST communication).

"pure" P2P communication on top of WebRTC Data Channels.

A hyperty (see Figure 11) is a service with an internal business logic. To be able to be reached and used, the hyperty instance provides Interfaces. Some of these interfaces are related to the communication setup (called “Communication Handshake”). This part, which is mandatory, contains for example, the ICE negotiation of WebRTC.

Figure 11. Hyperty Interfaces

The Functional Interface provides a way of using the Internal Business Logic. This Functional Interface can provide local APIs to be used inside the device Runtime environment and some remote Interfaces for the hyperty communications. The remote interface may be standard WebRTC Voice/Video P2P connection, APIs called over standard WebRTC Data Channel, or APIs directly by using HTTP calls (REST…).

In the case of two hyperties instances that are provided by the same service (i.e. instances of the same hyperty) and of the same domain, there is no need for interoperability. In the case where they are not, interoperability in all aspects is provided by the protocol on the fly concept of downloading the same software to both ends.



After the Handshake and the initial setup, the functional interfaces provides possibilities to communicate, in P2P (WebRTC), or with APIs. These APIs can be used for any other service logic, and can involve a Server (e.g. presence). Here again, the protocol on the fly is a way to ensure interoperability.

6.3 Hyperty Compatibility

6.3.1 Interworking Options

Hyperty functions are performed not only across a distributed Service Provider platform, but also within user devices, where software is downloaded and executed locally, thus enabling a peer-to-peer implementation of session control, while providing services.

Hyperties leverages the ProtoFly concept to interoperate each other without the need to standardize protocols and, instead, to standardize more flexible runtime APIs. However, the ProtoFly per se does not ensure that hyperties are compatible and that can interoperate, i.e., ProtoFly handles interoperability at protocol level but not at Service level.

Service interoperability is usually only supported at design time by setting up a contract between services e.g. by providing some formal (e.g. WSD) or informal (e.g. just textual documentation) description of an API. The API description should provide information about how the Service interfaces can be used. This is currently the most used approach e.g. in HTTP RESTful API, which means that some concepts have to be abstracted if we want to allow "partial interoperability". The API description can be provided by the Service Instance or by separated Service Catalogue server.

For example: A service is designed to provide a live video stream from a Webcam, and give the temperature. In this example, there would be a VideoAPI (API1) to provide the video stream and sensor API (API2) that retrieves the value of the floating temperature. Thus, if a second service wants to use only the Live Video stream feature, the developer would have to consult API1 description for the implementation. However, design-time hyperty interoperability would diminish the benefits of protocol on-the-fly.

A second approach is to agree at design time on a set of generic operations applied on a common data object model framework. Emerging standards like ETSI M2M/One M2M and OMA LWM2M are recently following this approach by using CRUD Operations extended with a few more operations on a standard Resource Tree. For the example introduced above, it would imply to standardise on a Video Communication object and on a Temperature Data Object. This second option would enable interoperability at run time but constrain it by the standardised data object, while the first option only enables interoperability at design time, but is more open and allows richer interoperability.

6.3.2 Compatibility via Schema

Hyperty interoperability mechanism is based on the second approach but enables the extension of Standard Data Objects with non-standardised resources to keep it open and allow richer interoperability if needed:

1. Hyperties are described with a descriptor following a data resource tree schema. Let's call it hyperty schema.

2. Generic CRUD operations are applied on each resource and associated attributes: Hyperty Operations. The usage of additional generic operations like Observe, Execute, used elsewhere like in OMA LWM2M, requires further study.

3. Standard Hyperty schemas are compliant with the standard reTHINK data model schema in reTHINK deliverable D2.2. For example if, two Hyperties are fully compliant with Hyperty Communication schema and included hyperty resource schema, they can interoperate.



4. Hyperty schemas will have a minimum set of data to enable ad-hoc interoperation between different hyperties. Such model can be extended with extra resources without breaking interoperability with fully standardised hyperties descriptors.

5. Interoperability should still be possible between hyperties that are partially compliant e.g. one hyperty that supports AV and Chat Resource schema can interoperate with an hyperty that only supports Chat schema.

6. Hyperty compliance check should be performed during Discovery process by matching the hyperty descriptors. A hyperties Compliancy check is independent of the hyperty type since there is a valid and standard schema to describe it. These schemas are going to be described in D2.2. Thus, interoperability would be supported on the match between hyperty Descriptors not by the hyperty Type.

7. Hyperty descriptors are provided by the Catalogue functionality or by the hyperty instance itself avoiding the need to always have to discover instances through the backend, enabling direct discoveries in the runtime devices.

With such hyperty interoperability mechanism, both simplicity and extensibility are supported. Non-standardised data object or pointers to data schemas defined somewhere else can be added without compromising compliancy with the standard hyperty schema. The main interfaces and functionalities used to support hyperty interoperability are shown in Figure 12.

Figure 12.

Figure 12. Main Interfaces and Functionalities used to Support Hyperty Interoperability



6.3.3 Hyperty Types

Different types of hyperties may be developed. Hyperties are described according to the data schema handled by them. The following hyperty types are proposed:

Identity (User) Hyperty handles Identity Management related functionalities modelled by the Identity Data Object schema;

Communication Hyperty provides communication control functionalities through the [Communication Data Object schema);

Context Producers / Consumers Hyperty supports that data collected from sensors (producers) are accessed by other services (consumers) through the Context Data Object schema.

If new hyperty types are needed, it will be a question of defining an appropriate schema to describe the data objects to be handled by this new hyperty type.

6.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.

6.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 13Figure 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.

6.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

6.5 Effects of Hyperty and ProtoFly

6.5.1 Concerns about Performance and Protocol Conversion

Compatibility of protocols and interworking should be provided from day 1. Message Communication is supported by the Protocol on-the-fly concept, to facilitate seamless interoperability between different domains. In this way, there is no need to standardize the protocol used, but only the messages format and data model. However, this entails software downloads to remote devices that belong to users on different domains and from different background and affiliations, who may not find this practice acceptable.

The creation of the hyperty, populating it with instantiated software and interworking add-ons, all performed remotely where the hyperty may be located, can result in inadequate response time. This may be exacerbated by the Internet response time, which is already slower than privately managed networks, so this may cause even greater delays, perhaps beyond user tolerance.

To resolve the overhead of downloads, it is suggested that hyperties that are habitually required in particular devices are not downloaded every time, but are stored locally.

6.5.2 One-Sided CSP Connection

Unlike traditional networks, in the reTHINK context, only the session-initiating communication service provider is fully aware of the connections made by the endpoints in its domain, but the destination domain CSP remains unaware. This is much the same as it is for OTT services, which run on top of the delivering network, involving the endpoints without knowledge of their service providers. In the reTHINK solution, setting up the session policy is not negotiated between CSPs in both originating and terminating domains. While both Telecom operators are required to commit resources for a Telecom session, in reTHINK, the affected resources are only those of the communication service provider who is setting up the connection (i.e. their core platform), and those of the NSPs, i.e. the transport layer. The destination domain provider is in fact, not impacted.

Session signalling in such a one-sided connection only flows towards the initiating CSP platform and to both originating and destination hyperties, not towards the destination CSP. The media flows

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



along a route of managed NSPs’ media gateways, as agreed only by the instigating CSP, not the destination.

Hence, the reTHINK solution involves only one CSP that performs the session set-up, and there is no need for formulating a new standard for CSP to CSP policy negotiation. The session-instigating CSP determines QoS and security policies according to the user’s requirements and the capability of the NSP-provided network path, but it does not consult the destination CSP. This service mode of ‘one-sided CSP connection’ raises a few issues regarding functions that are commonly operating in traditional services:

Consulting the destination CSP before committing resources

Informing the destination CSP that the user is engaged in a service

Informing the destination CSP that the user is now free

Notifying end-of-media to note session termination

Producing session reports (CDRs – communication Data Records).

In the case of the reTHINK architecture, there is no need for the destination domain to commit any resources, therefore it is arguably not necessary to provide for inter-CSP negotiation for session parameters. Only the stakeholders who are actively involved in the service delivery, need to be consulted, i.e. the instigating CSP and the participating NSPs along the path of the media.

Activity notification and user status (‘busy’, ‘no-answer’ etc.) are deemed unnecessary in modern communications, where multiple sessions can be maintained simultaneously.

However, the recipient domain may wish to keep records of its users’ usage for the purpose of analysis.

6.5.3 Enterprise security concerns about accepting downloads

Security issues regarding such intensive downloading of software between ‘strangers’ may exclude certain types of communication services. There are further concerns about the communication of hyperties running in highly secured environment network - like banks or industrial networks, where executed code is under strict control and cannot be modified, and where communication ports are restricted and very limited. It is doubtful that the mechanism of downloads of software on the fly will be accepted in such cases.

To allay concerns of enterprises (with lesser strict security requirements), the Independent Identity Management facility can be used to verify to the CSP credentials, and ensure that the software to be downloaded is secure. Another option is to reverse roles, so that the recipient called party’s own software is downloaded to the originator, who is requesting the connection – assuming that the destination is a reTHINK subscriber.

Another concern is the case of inter-domain communications between two highly secured domains that do not trust each other. Such cases occur, for example, when a state security agent is calling defence ministry or army officers of another country, or airline collaborating with another airline. Such organizations may resist any attempt to download software to their protected devices.

In such cases, it is possible to use Interfaces between the servers (two nodeJS, for instance), avoiding the need to download the hyperties. Highly secured domains may accept runtime environment that is configured to use one or more static trustful protocol stacks that have a ’domain channel‘ established to the enterprise Messaging Server. It may be possible for a server to act as an endpoint and receive the downloaded hyperty, with the role of the reTHINK ‘Messaging Server’ played by the one that is downloading the protocol stacks, thus establishing transient channels with other server (see Figure 16). With this approach, the protocol-on-the-fly is used between two servers, thus avoiding the need to standardize inter-domain protocols.



Figure 16. Enterprise to Enterprise acting as peer-to-peer

6.5.4 Capacity at the Endpoint

The ProtoFly procedure requires using two ports simultaneously to establish connectivity, and allow for the ‘back-to-back’ protocol translation. There has to be an open port with each call party, one connection to the server, and then exchange between servers, leaving only one port between client and server. This may cause some capacity concerns. For example, Chrome has some limitations when several (i.e. 4 or 5) webSockets are opened - in particular latency issues. It should be mandatory to limit connection numbers on the hyperty side, to avoid such networks issues. This restriction persists in other cases too and also exists with socket.io in long-polling.

It should be noted that it is not mandatory to use web sockets for the signalling protocol transport. For instance, using REST APIs, like the ones used by MATRIX solution, is a possible Messaging Protocol solution. However, where Web Sockets are used, the runtime and the protocol stack should be designed to handle this limitation, e.g. by using frameworks like sock.js or primus (https://github.com/primus/primus) that are able to choose the most appropriate and available transport protocol. Further tests will be conducted to assess the impact of this limitation.

6.5.5 Service Compatibility and ProtoFly

While downloading the same stack of protocols to both parties can solve the issue of compatibility of communication dialogue, the same is not true for compatibility of communication applications and features. The ProtoFly solution may transfer service logic as well, but this cannot automatically integrate with the destination stored user’s features, preferences and policies. Thus, only the calling party’s preferences are adhered to in determining the session parameters, while the called party’s preferences are ignored. In addition, the recipient called party will be unfamiliar with the presented call features of the originator’s domain and the general look and feel, unless both users share the same CSP. In particular, traditional terminating services (such as Freephone, Voicemail) cannot operate in the called party’s own applications.

Nevertheless, this solution enables connecting parties who do not subscribe to the same application via some basic features, which should be kept as generic as possible by the issuing service provider. The inevitable inferior QoE for the destination user remains as an implementation issue, but this can be seen as a trade-off, in order to achieve universal compatibility without the long lead time for developing standards and adopting them.

6.5.6 Impact on Device Power Consumption

Where the communication hyperty is designed to start up when the device is turned on, and continue running until it is switched off, the effect of the running process is likely to be detrimental to battery life. This issue requires attention for portable devices and mobile phones in particular.

Enterprise Msg Server

Enterprise Msg Server

Alice Bob

Domain channel Domain

channel

Protocol stack downloaded from other server



Solutions range from improving battery usage to techniques using ‘sleep mode’ and processing filtered system interrupts.

6.5.7 Impact on Network Traffic

The process of downloading hyperties involves frequent communication sessions of a file-transfer nature, which increases the pressure on the backhaul network between the core and the endpoints. However, the ‘payload’ of binary code is negligible, compared with the packet volumes of voice and Video. At the same time, having gained certain autonomy, the endpoints communications reduce the volumes of messaging between the endpoints and the core platform.

Techniques of reducing the volumes of downloads will be considered in implementation. They include software management that require a download only when a new revision is released, for example, and other Cloud and content distribution methods.



7 Identity Management for H2H and M2M

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 mobile SIM identifier, 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.

7.1 Identity Management Concepts

7.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.

7.1.2 IdP Design Assumptions

The IdP functionality may include:

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 Returning URL and/or IP Address

Several options exist in terms of what can be retrieved from an IdP:

7.1.2.1 Option 1: Hyperty IP address

IdP could provide the current login address of a user that directly points at a specific ‘live’ hyperty, with its IP address. This means that users must log on to the IdP when the device is turned on or the hyperty communication service is initiated. This address must be refreshed if the device is moved or switched off and on. This option needs no further lookup than the IdP, with no involvement of the destination user’s CSP, which supports the goal of user independence and lightweight interworking management.

However, the IdP would have to support intensive hits, time-critical fast response time, dynamic location registrar, similar to the HLR or the HSS function in Mobile communications. It will have to cope with frequent up-to-the-second updates of hyperty locations, and numerous enquires for every connection to each user hyperty. It makes the IdP the sole custodian of users’ locations. This extends the role of the IdP well beyond current industry thinking. It requires the IdP to maintain always-on, high availability, fast response-time systems, without which the connectivity will not be assured. This means that CSPs will depend on the IdP’s effectiveness, performance and responsiveness for every connection, while they have no say in the choice of IdP.

7.1.2.2 Option 2: Domain URL

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 Registry, which is maintained by on the CSP core platform. The 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 Registry is effectively the CSP’s location manager.

This option requires only few updates on the IdP, i.e. only when users subscribe to a particular CSP. The IdP maintains stable associations of users with their 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 registry to a high level of performance, can manage IP locations for its own users, and respond to the interrogation of the registry for any incoming service requests.

This solution requires some inter-domain interaction for connections between remote users, in different domains. Having retrieved the destination URL from the IdP, the owning domain CSP registry has to be searched for the current IP address, in a similar fashion to interrogating destination HLR/HSS in mobile systems, all be it without the ‘roaming’ facility.

7.1.3 Multiple IdPs and multiple identities

Multiple IdPs can be a real problem, because it can lead to indecision and ambiguity of location. If an end-user has more than one IdP, it follows that he/she has several identities, one for each IdP. There is no coupling between several identities under a single root identity, and no official link between identifiers and a particular IdP. Insisting on a 1:1 association of an identifier with an IdP could be achieved by validation rules that check that the user does not use the same identifier in another IdP. Forcing the user to create a separate ID is a way of ensuring unique addressing. If this becomes awkward, it is up to the user to amalgamate identities.



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 there is one 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.

7.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 must register as soon as it is switched on.

7.2 Graph Connector and GraphID

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 additions, 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 use to represent the user, providing a connectivity view of the user, and enabling users to maintain addresses of friends and colleagues.

7.2.1 Proposed reTHINK GraphID

It is proposed that a unique GraphID is allocated to each user, to enable connecting to entities from the graph after re-instantiating the hyperty and selecting an IdP. This GraphID should not change by switching off devices and is independent of the IdPs and their user identifiers, or the user’s domain, but it must be able to associate users with their hyperties.

Definition: GraphID - The unchangeable GUID of the user, represented by a hyperty instance (or multiple) at any one time.



One GraphID can thus be associated with multiple live hyperties, so GraphIDs are linked. To prevent fraudulent usage of GraphIDs, they might be the public key from a public/private key pair that is generated the first time a user wants to use the reTHINK architecture.

Figure 17 gives an example of forming GraphID between users and objects.

Figure 17. Linking GraphIDs 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 GraphIDs can be used set up access control policies for that profile. Figure 18 visualizes the dependencies between Discovery, Hyperty Registry, and Graph:

Figure 18. Discovery and Registry using Graph Connector

The general idea is the following:

To connect to new and unknown entities: Discovery



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

The Registry provides services that facilitate resolving identifiers for users (GraphIDs) to information about hyperty instances that are associated with this GraphID. GraphIDs are domain-independent, unique identifiers assigned to users or groups of users. Such identifiers do not change unless explicitly requested. Hence, connections to other users and their hyperty instances can be managed by keeping a list of known GraphIDs. Resolving a GraphID using the hyperty Registry will return a list of data records, one for each registered hyperty instance for this user. Each record includes information about one hyperty instance.

7.3 Identity Management Hyperty

An ‘identity hyperty’ is a type of hyperty that is instantiated at the endpoint to manage functions such as uploading credentials, requesting authentication token, relaying own authentication token, enquiring on destination user identity/location at etc. Identity hyperties do not need to be registered on the CSP’s Registry, since there is no need for a discovery or search on them. However, the same mechanism of software management by the CSP and downloading latest releases will apply

It is assumed the user is authenticated by the independent identity provider before the registration data is requested by the service provider. A user is associated with an Identity every time the browser is started or the device is turned on. The user logs in at the IdP platform and receives a security token. The Identity Hyperty functions include forwarding this token when external entities enquire on this user’s identity. This minimises the impact on the IdP or the CSP, who otherwise would have to respond to such enquiries centrally.

The interactions between the user device and the Service Provider, as well as the user device and external enquirers, are handled by a module in the Identity hyperty, shown as "Service Provider Hyperty" in Figure 19. In addition, the Identity Hyperty is responsible for more advanced identity management facilities, such as the proposed GraphID and the Graph Connector, which will provide identity services to local applications, e.g. address book.

Hence, while the service provider’s module contains the reTHINK identity services, there is a separate component in this hyperty that is responsible for the user’s basic identity authentication by the IdP. This component must interwork with the IdP’s service logic and protocols. Since the CSP has to support any IdP chosen by its users, this module must be compatible with current standards that most IdPs implement. This can be achieved in two ways:

In the first option, the identity hyperty is programmed to interact with the IdP, implementing their protocols and using their data models. It may be possible to deploy ProtoFly to overcome the communication protocol differences, if the IdPs will consent to it.

In the second option, a webRTC ‘IdP Proxy’ is installed in the endpoint. It is assumed that the IdP can provide the appropriate service logic that is required as IdP clients, which is compatible with the device OS and software environment of the user device. This IdP proxy still requires some service logic to relate information to and from user profiles, and link to identity services.



Figure 19. User Login with External Identity functional blocks

7.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.

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.

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.



8 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.

8.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 20 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 20. Interaction between applications, hyperties and management services

8.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.

8.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 21. Case 1, Identity interoperability

This case raises some Issues for further investigation:

media

Bob device

Alice device

Back ends

B

A

a

b

b

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



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

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.

8.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 22. 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).

media

Bob device

Alice device

Back ends

B

A a

b

b

B signalling stack is downloaded in A to ensure interoperability



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.

8.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 23. 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



8.1.5 Summary of Use Cases

The following table summarizes the three cases and their characteristics:

Table 7 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.

8.2 CSP to CSP Interoperability

8.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.

8.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 24. Discovery service dynamic view

8.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 25. 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 25. 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.

8.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 26:

Figure 26. 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 27 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 27. Transferring CDRs by ProtoFly



9 Specialized Network Services

Specialized Network Service (SNS) are Services that are provided by NSPs, in access networks and in interconnection networks that carry media. They 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.

9.1 CSP and NSP Relationship

9.1.1 CSP Hosted Services 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).

In most cases, CSPs do not own or managed a network. To assure quality at the application level they could deploy specialized network services by agreement with one or more NSPs.

The CSP User accounts may be used for accounting, whether charging to users or to the initiating Application, or any other party.

A user device can be linked to more than one CSP.

9.1.2 NSP Assumptions

NSPs can negotiate parameters for the passage of media, but must guarantee that the agreed quality level is enforced.

Different business models can be considered i.e. monetized SNS or neutral SNS (improving the quality in general for everyone).

A single contact point should be provided to allow CPS to ask for SNSs, e.g. by providing an API or an abstraction layer like broker. Solution must be compatible with application layer technologies and with currently deployed network technologies.

Collaborative (participating) NSPs agree to abide by the reTHINK NNI (Network to Network Interface) standards for setting up QoS/Security tunnels.

9.1.3 CSP and NSP relationship

The connectivity Solutions between CSP and NSP must have global reach and must be able to recognise participating and non-participating NSPs.

Since in some cases there may not be any participating NSPs in the path, only partial quality can be ensured.

Authentication and authorisation mechanisms should be provided (e.g. based on tokens) by NSPs but end users should be managed by the CSPs, not the NSPs.

9.1.4 Brokering NSPs

The NSP-Broker-CSP link carries QoS/Security policy negotiation. Since CSP need to negotiate with several NSPs, an abstraction layer is needed. NSP do not always have access to session control signalling information so the cooperation between NSP and CSP is essential. There may be participating and not participating NSPs, therefore interactions between participating NSPs need to be established.

In Figure 28, the users are linked via a CSP, and also have connections to the identity broker, to manage their own identities and enquire on potential destination users. The link between the CSP and the IdP (or the Identity Broker) consists of CSP search to assert the identity of the instigating web app server, the originating user and the destination user(s). The brokering enables searching globally for the identity provider who is used by a particular network entity.



As shown, the CSP also has to select an NSP path of participating network providers. It is assumed that the routing via special Internet media gateways is performed as it is today, in a collaborative fashion, but the first entry to the network is an NSP that is chosen by the CSP as the single point of contact. Therefore, there is a potential business relationship between the CSP and partnering NSPs, governed by several types of business models.

Figure 28. General Data Flow model

9.2 Managing QoS and Security Levels for User Sessions

Specialised Network Services (SNS) provide control functionalities and context information specific to the domain of a Network Service Provider. Control functionalities allow steering and enforcing network quality in terms of jitter, latency, etc. according to negotiated and subscribed Network Policies by end-users. SNS should provide and collect information to ensure QoS is delivered for a given communication instance.

FFS: The negotiation of session QoS parameters and levels of security between CSPs and NSPs are subject to further study.

9.3 Delivery Network Interoperability

Offering global solutions to Webcos (web Companies) involves addressing the interoperability at the Network level.

Competitive pressure between Internet Access Providers motivates them to invest in network capacity, and provide superior access to web services at a constant price. This, in turn, encourages Webco to launch more demanding services and entice users to purchase more powerful devices with larger screens that require enhanced quality of service. Therefore, given the economical equation, an investment in best-effort capacities doesn’t seem to be the long-term answer to alleviate the problem, especially in real-time communications.

In today’s networks, several QoE problems using best effort have been raised: transient congestion at Internet peering points, congestion problems on long DSL lines, impact of fair cellular radio bandwidth sharing between users with good/bad reception, and data-centre networks.

Additionally, Webcos are seeking to reduce the observable latency of the Web, as delays are known to drive customers away. In the long run, latency of critical applications is expected to increase (the



so called tactile Internet), for example in the field of connected vehicles and industry 4.0. First solutions on the table were based on a redesign of the Web stack (e.g. http2, quic,) which didn’t involve an active network contribution. Newer tracks, such as SPUD and Mobile Edge Computing, go the opposite direction by involving an active network contribution.

9.3.1 Case 1: Brokering

In case 1, there is interaction between operator networks to enable end to end use of the specialized network services. We need a mechanism to allow specific application process at peering points, to avoid traffic congestion. This can be addressed by brokering specialized network services solution developed in the frame of reTHINK (TURN services), and will be experimented in the reTHINK project development phase.

DeviceIAP A IAP B

WebCo

WebCo

Network-Network Interop

Network-WebCo Interop

Broker

CloudSpecialized Network Services

Figure 29. Network Interoperability case 1

9.3.2 Case 2: Hosting infrastructure interaction

In case 2, there is interaction between hosting infrastructures (such as Mobile Edge Computing) in the network operator. The issues addressed here are the placement of the resources in the networks. We need to determine how to use middleware dedicated to real time communication (IaaS or PaaS), to address the edge of the network, thus decreasing access network QoS issues. This is a very promising and innovative solution that was not first proposed in the reTHINK plans, but that we would like to investigate in a second phase if possible.



DeviceIAP A IAP B

WebCo



Edge Computing (In-Network Cloud)

Web

Co

Web

Co

Web

Co

Edge DC


9.3.3 Case 3: Neutral Collaboration

In case 3, there is interaction between OTT and network operator to provide neutral collaboration (i.e. not involving cross charging between players) interfaces (such as in SPUD):

For the network operator, provide the best suited network compromise according to application needs (e.g. trading-off latency/packet-loss/bandwidth/battery consumption),

For the OTT adapt the network behaviour to best suit the application needs with the available (non-infinite) network resources.

This solution is based on a win-win collaboration between the operators and the Webcos. This medium/long term track was not first proposed in reTHINK plans, but may be investigated in a second phase with interested partners.



DeviceIAP A IAP B

WebCo



Neutral collaboration

Neutral

collaboration Neutral

collaboration




10 ReTHINK Architecture Summary

This 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 took into account 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) 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…).

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 first release of the ReTHINK architecture, which will be updated at the following phases, to reflect the design and implementation. The final architecture framework document will be released in deliverable D2.3.

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).



State of the Art (SotA) Annex A

A.1 User Communication Environment

A.1.1 Modes of Communications

A.1.1.1 Migrating from Telecom to Internet Context Communication

The new service environment for communication is likely to be far more context based than before. Users invoke communication from a variety of applications, well beyond the traditional address book and a dialling system. Such applications provide habitual connectivity functions that are associated with Social Networks (e.g. Facebook), or from search engines that provides information but also immediate contactibility (e.g. Google). Rich media communication was envisaged by the Telecom Industry, e.g. RCS apps which are based on IMS, however, the front-end applications fail to compete with the web-based ones, in terms of agility and innovation, as well as ease of integration. Therefore, the rise of context communication also means the shift towards web based communications.

The Internet still evolves and it forces changes in the whole industry. We see that typical Telco operator enabled services such as Telephony, FAX, SMS lose their importance. Communication services like chat and social networks are growing and complementing traditional services at the same time. This process leads us to scenarios and use-cases that combine various services and enable a richer form of communication.

A.1.1.2 Context based communication

In conjunction with the technical evolution of the Internet, user scenarios and usage characteristics have changed. The same applies to communication in general. Traditionally real time communication had a social and strong verbal character. In case of business communication it was used to transport some additional information or comment on information, already available at the receiving party or to be sent after the conversation. This means that information and communication domains and hence the context were mostly separated.

Due to Internet progress, and especially the introduction of WebRTC technology, future communication means will be available in combination with the content. This means instead of separated channels for information and communication, dealing within the same context, both channels are now provided simultaneously. In addition communication services will simply act as a supporting added service at no or low cost.

Communication like phone calls might be combined with additional information about the context (e.g. a certain topic or project name that is currently discussed) or group information (e.g. information that the caller belongs to the family or to a certain company).

A.1.1.3 Context based social messaging

Enhanced communication services enable new (real time) collaborative working, remote participation and informed decision to be made. The cost of multi-party video conferencing is today much lower than before. The ubiquity of Internet enabled devices allows people to have a say at any time, and not only on elections. The Open 311 protocol (http://www.open311.org/learn/) has been successfully used in the scope of the CitySDK project for enabling citizens to identify issues with the public infrastructures which require municipal intervention. This is crowd-sourcing of public resource allocation. Politicians and authorities can listen to citizens on a daily basis on not only on multi-annual election pools.

Many cities, administrative bodies or governments have begun to digitize their services. However they merely provide static information on web-sites, offer simple exchange options via comments or

http://www.open311.org/learn/



email or in some cases via social media services, such as Facebook and Twitter. While this movement does provide an initial opportunity for information and interaction between representatives and citizens, these services lack real time, context focus, reliability, security and trustworthiness, which should form the foundation of e-government services. Secure e-government social communication service.

Figure 32 illustrates in a layered approach roles and their affiliation for smart city scenario (The general concept is transferable to other user scenarios). The governance layer acts as manager (e.g. are City Hall or city representatives). Prosumers are either human beings like citizens or physical objects like buildings or institutions. From a user and service perspective, the hyperties are the more important aspect of the enabling layer, providing for example communication streams or content. Finally the technical layer, examples HTML5 and WebRTC, acts as general enabler.

Figure 32. Concept overview of m-government scenario roles and entities

From a user and service perspective Manager, Human Beings, Physical Objects and Hyperty roles are interlinked due to the required context - situation and available service.

A.1.1.4 the Internet of Things

The “Internet of Things” (IoT) is beginning to evolve and early solutions are now being implemented. We can find implementations in areas like logistics, farming, industry, home automation and many others. From a business point of view the IoT enables a plethora of new opportunities, use cases and scenarios. From a technical point of view the IoT consists of countless devices, sensors or actuators or simply objects connected to services in the Internet.

The idea of context based communication can also be extended to the IoT. One or more of the simultaneously communication channel can result from IoT devices. Today’s smartphones already have various accessible sensors built in (ex. light, proximity, touch, location, accelerometer, magnetometer, gyroscope, pressure, temperature, humidity etc.). Thus, for example, an incoming WebRTC call could stop the video stream on TV or reduce the background noise of the audio system. What today is only possible in dedicated devices and with specific service, the hyperty concept will address in general since it handles various communication streams whether from an end-user device or from a sensor or actuator of the IoT.



A.1.2 Contextual Communication

A.1.2.1 Ubiquitous architecture

Following the well-accepted definition of A.K.Day [30], context is a piece of information which may contribute to characterize the situation of an entity of interest, per entity it is meant as well a person, a place, a physical device …. This concept appeared in the 90's as the keystone of a new paradigm of computing called ‘ubiquitous computing’, the emergence of which was prophesied in Weiser's paper [31]. The investigation domain (highly respectable scientific buzz) induced by the coined term led to the development of various interesting avatars like pervasive computing, ambient intelligence, context-aware computing, to recently culminate in Everyware [32] as the fusion of everywhere and of (hard/soft)-ware. It is now quite clear and well-accepted that adding context-aware capabilities to a process should allow the latter to adapt its behaviour depending on the perceived state of its environment and make it somehow smarter [33]. We will synthetize below the main points and strong trends currently surrounding context engineering.

A basic classification of context leads to several categories covering almost the entire spectrum (physical, user, social, system) [34]. The physical context may encompass various aspects: spatial (location, position and orientation), temporal (time, day, date, week, season, etc.), environmental (lighting, noise level, temperature, pressure, and more generally all physical relevant variables which can be acquired from the environment).

User context may refer to an explicit profile involving a real identity, a pseudonym or anonymity, a role, preferences, focal interests, perceptual and cognitive characteristics (visual and/or auditory capabilities, knowledge of a domain, level of expertise), current activity (walking, working, driving), the physical presence, availability, emotional state, etc.

The social context may detail physical presence of persons other than the primary user, a collective social activity in progress, the profile of the partners, various structural aspects (organizational, hierarchical, and political) or some social norms specific to a given cultural environment.

Finally the system context usually concerns the hardware/software parts (capacity, performance, load, availability, battery, OS, middleware, applications, etc.) together with the network one (characteristics of the used network).

Context can be sensed from physical, virtual or logical sensors, which correspond to physical, software and higher level combination of the former two sources respectively. All the contextual data in such systems is then stored in a proper model and processed in order to derive significant high level information to be provided to services [35].

The first widespread type of context aware system is the one based on the localisation of mobile devices. This can be easily achieved nowadays with a use of GPS satellites, mobile phone towers, badge proximity detectors, cameras, etc. In addition, today incorporating many more context dimensions that systems can be aware of is also much easier due to the low-cost sensors of motion, light, touch, temperature, etc. available for everyone. Therefore, there is nothing surprising in that many actors in the industry got interested by the potential of being aware of the context and investigate various application domains, as shown in Figure 33.



Figure 33. The categories of context-aware sensing (source O.Yurur&all [36])

A.1.3 Online Social Networks

A.1.3.1 Core Features of Online Social Networks

We can make out six core features of online social networks:

Personal Profile: Each user has a personal profile in which he/she can describe oneself, typically with a profile picture.

Social Graph: The social graph consists of the connections between a user of the OSN with other users or products.

Interaction: Messages, updates, posts, or likes by friends are typically displayed to linked users.

Context Information: The user's context, e.g., current location, availability for instant messaging, etc., is often displayed for linked users or used for group creation.

Search: Search for specific users or users with a similar context.

Recommendations: Recommendations of friends or products, based on social graph and context information, is the most common feature with which users can explore the network around them.

In the context of reTHINK, regarding the Personal Profile, hosting on mobile devices or on some kind of cache server is planned. The social graph should be stored in a distributed fashion. Interaction between users is done by leveraging WebRTC or ProtoFly. The smartphone can be used to collect context and location data. For search and recommendation we envision some form of directory-services that enable users to share (some of) their data in order for the service to have information to perform search and recommendation algorithms on.

A.1.3.2 Three-tiered View of the Social Graph

In traditional online social networks, all connections between users exist because of explicitly defined friendship-relations. In [46], we propose a new, three-tiered view of the social graph. In the friend tier, long-term relations independent from context and location are established. In the location tier, spontaneous groups of people in proximity to each other are formed, e.g., people in a certain neighbourhood or people in a park. In the context tier, users are connected based on common contexts, e.g., taking the same university class or being registered with the same gym. The idea is



that in both location and context tier, users do not need to connect with each other explicitly, but that some service establishes the social graph. The concept is illustrated in Figure 34.

Context-Tier

Location-Tier

Friend-Tier

Figure 34. Three-tiered view of the social graph, [46].

A.1.3.3 Context-aware Online Social Networking Services

In their vision of contextual computing, in 1995, Schilit et al. [70] developed four different types of mobile scenarios for context-aware computing. For the dimensions information and manual, the example is a yellow pages application that takes into account the location of the user and sorts the contents of the yellow pages accordingly. For the dimensions information and automatic, automatic reconfigurations of systems are envisioned, e.g., a whiteboard to which access is automatically granted based on proximity. For command and manual, the idea is that a user can print to the nearest printer or that a button in some graphical user interface appears depending on the location of the user. In the command and automatic category, if-then rules are used to automatically trigger commands based on pre-defined rules.

Most of these scenarios focus on the location aspect. The given examples could today be realized utilizing geo-fences or Bluetooth low energy beacons. An exception might be the example of the automated access to a whiteboard. Here, concerns of access control play an additional role.

Apart from these scenarios that focus on location, other potentially exploitable context data is mentioned:

presence of other users

devices in proximity

changes of these things over time

Additionally, envisioned contextual factors are:

communication bandwidth

communication costs

noise



lighting

social relationship with people nearby (e.g., manager, co-worker)

Dey [30] defines context as something that characterizes an entity that is relevant to the user or application. Furthermore, an important part of the definition of what is to be considered context is that this depends on the application. For an indoor mobile tour guide for example, weather should not be considered a context [30].

Baldauf et al. [35] focus on physical sensors. Here, typical sensors are used to determine the following contexts:

light

visual context

audio

motion, acceleration

location

touch

temperature

physical attributes (e.g., blood pressure)

The authors mention that aspects of security and privacy issues are often disregarded. Locally acquiring context data on the smartphone and letting the user control sharing such data can empower users within the reTHINK project to be able to protect their privacy.

In their survey, Bettini et al. [34] point to an important aspect of context-aware computing: It is important to abstract from low-level sensor information to high-level contexts. For example, sensing the co-location of several co-workers during business hours could hint at the contextual situation “work meeting”. For this, sensor-based data can be combined and looked at from a temporal perspective.

Yurur et al. also conclude that privacy and security are open issues, and that users can feel constantly monitored on by apps tracking context information [36]. Regarding the acquisition of context data, the authors divide sensors into three categories:

physical sensors: captures physical data, e.g., GPS for location or accelerometer for activity

virtual sensors: from software application and/or service, e.g., manually set location or computation power of device

logical sensors: combination of physical and virtual sensors with additional information through various sources like databases or log files

Context itself is divided into four categories:

device context: net connectivity, communication cost

user context: profile, geographic position, neighbours, social situation

physical context: temperature, noise level, light intensity, traffic conditions

temporal context: day, week, month, season, year

Looking back at the first papers concerned with context-aware and ubiquitous computing, the early visions predicted most of the context information that are accessible via physical or virtual sensors. With the advent of online social networks – where information is shared with friends – and smartphones – that are used for communication and almost any other daily computing activity –, much more (profile) information about users is available than the first visions of ubiquitous computing could predict.

To what extend the device context can be known depends on the virtual sensors of the device. The physical and temporal context of a situation can be known through physical sensors provided by smartphones or IoT devices. Regarding the user context, the user’s position can be determined in



relation to multiple things: GPS sensors can give latitude and longitude, while a map can pinpoint the city. Furthermore, through presence of neighbours, the social situation might be inferred.

As for the profile, relevant context data might be spread over several different online services. Data about favourite movies might be stored with iMDb (http://www.imdb.com) or trakt.tv (http://www.trakt.tv), Twitter’s follower-relationships might indicate what companies or celebrities a user is interested in. “Likes” on online social network platforms like Facebook often express general interest in topics, places, companies, or celebrities.

In [46], we argue that most of this information is directly available on the smartphone, through both physical and virtual sensors. Logical sensors are available on the smartphone as well: apps log information about their usage and thus about their user. Information that is usually expressed explicitly by “likes” on traditional online social networks platforms, can be inferred implicitly by, e.g. keeping track of the music the smartphone user listens to. Furthermore, information about users from online social networks is often available through APIs. This data can be used to further enrich the context data collected on the smartphone.

Overall, within the reTHINK project, it might be helpful to work with the definitions for sensors and context provided in [36], highlighted in boldface above. Furthermore, we can distinguish between

explicitly maintained context data, e.g., likes, etc.

implicitly collected context data, e.g., favourite music, location traces, etc.

Derived from the developed user scenarios and use cases, we developed the model of the three-tiered social graph. To support context- and location-tier groups, context and location data has to be provided by the users. Furthermore, access control schemes could be based on such data, allowing, e.g., people with similar interests to access more information of a social profile. Additionally, algorithms for distributed search and recommendations can be based on the concept of mutual friends or contextually similar users.

A.1.4 M2M Communication

More than nine billion devices around the world are currently connected to the Internet, and the estimations form McKinsey Global Institute show that by the end of 2020, there will be one trillion connected devices worldwide. The need for standardization is highly recognized to support interoperability between connected devices and systems in large-scale IoT. Various standards developing organizations (SDO) have recently promoted standardization activities in the M2M domain.

The European Telecommunications Standards Institute (ETSI) standardization work focused on the service middleware layer for M2M platforms aiming to enable the integration of different M2M technology choices into one managed platform [76 - 79]. The Open Mobile Alliance (OMA) develops mobile Service Enabler specifications, and has several standards that can be mapped into the ETSI M2M framework, such as OMA Next Generation Services Interface (NGSI).

In 2012, the oneM2M consortium (http://onem2m.org) was established with the aim of consolidating the standardization work in M2M communication. oneM2M is a consortium of seven standards development bodies working in the M2M communication standardization [80 – 82]. More than 260 participating partners and members has joint oneM2M to participate in the standardization of M2M communication system, including ETSI and OMA. The participating organizations intend to transfer all standardization activities in the scope of M2M service layer to the oneM2M.

oneM2M specifies a high-level architecture (as shown in Figure 35) at both the field and infrastructure domain, to support end-to-end M2M services. The oneM2M functional architecture comprises of following Entities:



Figure 35. oneM2M logical architecture

1. Application Entity (AE): responsible of providing end-to-end M2M logic solution, i.e. eHealth, logistic, Smart Energy, etc.

2. Common Services Entity (CSE): comprises a set of Common Service Functions (CSF) that are common to the M2M environments and exposed to other entities through four Reference Points Mca, Mcn, Mcc and Mcc’. The oneM2M standards have specified 12 different CSFs, some of them can be optionally implemented at a given CSE depending on the implementation domain and device, supported networks, etc. An CSE could be implemented on different kind of nodes such as middle node (i.e. M2M gateways) at the field domain, or infrastructure node (i.e. M2M Server Infrastructure) at the infrastructure domain.

3. Underlying Network Services Entity (NSE): to provide services to the CSEs, such as device management, location services and device triggering.

Four reference points are specified in oneM2M:

Mca reference point: for interaction communication between an AE and CSEs, that enable the AE to use the expose services from the CSE.

Mcn reference point: to allow the CSE to use services provided by the underlying NSEs.

Mcc reference point: to enable the interworking between CSEs. Any CSE could use some functionality provided by anther CSE in order to provide service to other entities.

Mcc’ reference point: The Mcc’ shall be implanted on CSEs at infrastructure nodes to enable inter-domain communication between CSEs at different service provider domains.

A.2 Service Architecture

A.2.1 IMS and VoLTE

The IP Multimedia Subsystem (IMS) is currently the state of the art in terms of standardized Service Architecture for Telecommunication Services. It is an evolution of the Intelligent Network (IN), but based on Internet Protocol (IP) and Information Technology (IT) principles. IMS has been specified by 3GPP in Rel. 5 onwards, as summarized in TS23.228 [23] as the core packet network session control. It supports a layer of communication services that replaces the TDM based IN.

The goal for IMS was to provide Telecom operators a secure, trustworthy session control environment that operators and 3rd party service providers can plug their services into, e.g., Joyn/RCS [24]. However, due to IMS complexity and the traditional restrictive architecture, service

AE AE

Mca Mca Mca

Mcc

Mcn Mcn

CSE CSE

NSE NSE

Field Domain Infrastructure Domain

To Infrastructure

Domain of other

Service Provider

Mcc’



development is slow and cumbersome. At the same time, the technological and business-related innovations in the Internet space have generated a wealth of attractive services, with greater agility and low cost base. These services run over the enhanced 4G infrastructure that is now providing high bandwidth (LTE), and this is exploited by OTT (Over The Top) players, locking out the carriers.

Telecommunication service providers are struggling to match the agility and innovation of web based services, even when they replace conventional Telecommunication services, while the changes in communication habits and user behaviour, e.g. texting and social networking, encourage the shift of users towards web based facilities.

The introduction of VoLTE (IMS over LTE) requires a complete core network replacement based on the 3GPP Evolved Packet Core (EPC) for end-to-end QoS provisioning in LTE networks, with IMS as the session control and service environment for Voice/Video conversational services. This is perceived as a huge effort (manpower, project management, CAPEX, OPEX), while the prospects of new revenues in the increasingly competitive environment of real-time communication services are diminishing.

Figure 36 shows the IMS layered architecture [40], where the layers of session control and service logic have been separated, unlike previous architectures of circuit-based switches and even softswitches. This enables the calling applications to operate independently, while activating the IMS core for session control. Therefore, the current rolling out of VoLTE (IMS over LTE) provides an excellent opportunity for web applications to ‘grab’ the front-end, while still perform like carriers’ IMS systems.

As shown, the media plane is also an independent layer, but it is subject to the session control that determines the media parameters (QoS, priority, security). The media runs directly between the communicating points, while session control signalling traverses the network to the core servers.

Also shown is the range of management functions. Besides CRM, Billing and Provisioning as well as network management, it shows that new facilities for hosting network services are now enabled, due to the modularity of IMS. The implementation of the IMS platform for a large service provider benefits from the ideas of SOA, as described in [39]. The SOA principles can help to provide efficient distributed IMS core, built of modular components that can be scaled independently from each other. It follows that what makes IMS so complex is also the reason for its flexibility and openness.

Figure 36. IMS Layered Architecture

The monolithic approach to communication, where devices, access, backhaul, core and applications were all under a single communication service provider is no longer valid. With the advent of LTE and

Media

Plane Media

ResourcesMedia

Gateways

Admission Control

Session ControlIMS

Control

Plane

Border

Control

Media

Control

Service Control

Applications

Data

Repository

User Management

Resources

Management

Enforcement

IMS

Service

Plane

CRM

Billing

Web portal

Provisioning

Network Management

Hosted User

Management

Management

Systems

Web

ServicesContent

Management

Web

Services



the EPC (Evolving Packet Core), the access network has become an independent layer, hence the IMS core can serve multiple types of access networks. The application layer is also independent, but is still very constraint by the IMS interfaces. As we are now facing new definition of communications within the Internet space using web technologies, it is important to inherit the achievements of IMS while attempting to surpass it in other respects.

In Figure 37 and 38, from Technology (V. Pascual in https://webrtchacks.com/a-hitchhikers-guide-to-webrtc-standardization/), an attempt is made to integrate the webRTC client with the P-CSCF, the IMS user agent function, and converge data from the webRTC portal with its authentication system with HSS user data repository.

Figure 37. WebRTC integration with IMS user agent and data repository

This approach allows IMS functions to be used in session control for webRTC sessions. While this may not be entirely desirable for those who seek new ways of controlling sessions, the requirement to interconnect with IMS is unavoidable, given the growing numbers of IMS systems being installed.

In Figure 38, the NNI (Network to Network Interface) connects elements of the webRTC architecture to IMS gateways. Note that the IBCF (Interconnection Border Control Function) converts webRTC signalling on the fly, just as it does for H.248 to SIP, and that the Translation Gateway (TrGW) converts media codecs on the fly, for webRTC as well as IMS media.

Figure 38. webRTC linking to IMS via NNI



While the IMS core can continue to provide QoS-managed service delivery even when the front-end application is web based, carriers who implement IMS are still constraint by territorial licensing. In addition, the Telecom Industry has failed to provide attractive communication services that match the agility and innovation of the web players. The IMS support of applications is not easy for web developers who find the service interaction via SIP too difficult. SIP, which has been born as a simple way of invoking Voice over Internet, has been extended greatly, and is now perceived as difficult to work with.

The service environment for IMS that integrates HTTP based services, as specified by OMA (Open Mobile Architecture), is given in Figure 39 (see [40]). It shows the main interface to services – the ISC (IMS Service Control) which is SIP based, connecting to service enablers that deal with compatibility and interworking, before linking to application. Although this architecture is comprehensive, it is clear that it does not encourage rapid service development.

Figure 39. OMA based IMS service architecture

An alternative method that improves on the integration of web communication apps is required. The reTHINK project must surpass the IMS alternative in several ways:

Front-end web communications apps must have easy access to session control, without the constraints of the IMS service architecture interfaces (ISC etc.).

Web technologies and protocols are assumed to be used by web developers, for example – using REST and resource based architecture instead of extended Diameter for access to service data.

Different web communication apps may be used by the parties in a single session, each supporting different sets of session features (Caller ID, Do-not-Disturb, no-return-calls, bar last caller).

New applications and modified applications must be able to address users’ devices without having to undergo end-to-end testing, i.e. new features may not work in some cases, but will not disrupt the whole network, while a safe mechanism is provided for updating apps clients.

Terminal Enablers

ETI-2Enabler

Terminal I/f

ApplicationApplication

ISC

P-CSCF

S-CSCF

HSS

OCS

Sh Ro

CCF

Rf

IMS Core

ESI-B Enabler Server I/f (AS)

Application

I0

I0

Gm Gm

ESI-A Enabler Server I/f (AS)

I2 type of interfaces

Ut

I0/I2

Ut

I0/I2

HTTP

Proxy

MbMb

SLF

Dh

HTTP

Proxy

Bearer

Server Enablers

UE

UE

Server

AS

ETI-1Enabler

Terminal I/f



APIs to network facilities, such as QoS policy, Charging/billing and enhanced authentication, must be standardized, so that web apps do not need to change their service logic to link to different CSPs.

A.2.2 Client Server Architecture versus Endpoint Centric Approach

The service webification trend that is powered by the OTT success has modified the client server paradigm which was the prevailing standard in the 90s. Protocols were specialized for each application, for both the User-Network Interface (UNI) and the Network-Network Interface (NNI), and the client application was also specialized (e.g. email client, POP3, SMTP protocols). At the turn of the century, HTML and JavaScript disruption broke up this paradigm in the new data services.

Client applications are now embedded in web browsers, which are made more flexible by improvements brought forth by HTML5 (e.g. WebSocket, local storage). Communication between Web Applications and web servers (UNI) has become commoditized, since it is no longer relying on specific protocols but on API calls, using Web Services or RESTful APIs over HTTP.

In [45], the author discusses methods of distributing network functions between the web server provider (and web app), a proxy gateway and an edge device, i.e. the endpoint. The endpoint approach permits developers to add features independently of the gateway vendor, but this requires all browser vendors to implement WebRTC with the same choice of audio and video codec. The endpoint option is also likely to impact battery life, which must be considered carefully.

Placing a proposed proxy in the hands of an independent party, allows developers to have the freedom to choose their own vendors and domain, but service delivery is then dependent on more parties, each with its own agenda.

A.2.3 Web Services and SOA

Web Services have evolved towards Service-Oriented architecture (SOA), which decouples the services from specific vendors, products or technologies [25]. Typically, the Web Services Description Language (WSDL) describes the services while the Simple Object Access Protocol (SOAP) defines the communications protocols. The SOA architecture is based on a client/server paradigm and centralized service discovery protocols. This leads to high operational and maintenance costs, multiple single points of failures, and scalability limitations [26].

Figure 40 shows the IT architecture for a computing platform that distinguishes between design time and run time of various management functions.



Figure 40. SOA Architectural Building Blocks for Services Layer1

Please note that the terms QoS and Policy here do not refer to communication session QoS and network policies and the policy enforcement only refers to propagating rules across the computing elements – not across multiple network providers.

Figure 41 shows the process of endpoints registering to a service, before the user can launch a service request. Although this is an IT based concepts, this simplistic diagram can also cover the functions of communication endpoints registering to the service.

Figure 41. Interaction Flow for Service Discovery and Location2

In Figure 42, the governess of quality and IT policies are shown, as a service request is being process. It has to be noted that despite some parallel concepts in this diagram, this IT architecture does not reflect communications Services.

1 Source: http://www.opengroup.org/soa/source-book/soa_refarch/services.htm




Figure 42. Interaction Flow for Service Invocation3

A.2.4 RESTful APIs

A.2.4.1 Resource Oriented Architecture

Resource Oriented Architectures (ROA)[27] have emerged to answer some of SOA problems (e.g. its inherent complexity). ROA is based on the resource concept; each resource is a directly accessible distributed component that is handled through a standard, common interface. This property allows the creation of stateless systems where all the information required to process a server’s request is contained along the request. This includes the URL, headers and query parameters, as no information about any previous request is maintained by the server. An application can interact with a resource by specifying the identifier of the resource, the action to execute and the format of the information returned by the server. Exposing a system's resources through a RESTful API enables the simple integration of multiple applications with data formatted under a common standard structure. Using this approach, services can be easily combined or extended to provide new functionalities.

In Figure 43, a multi-layered approach is shown, which adds constraints to resources visibility and accessibility, i.e. this hierarchical layered architecture constraints components’ behaviour so that each component can only ‘see’ and utilise the immediate layer with which it is interacting.

Figure 43. REST Architecture4




The type of connectors and some specific examples are given in the REST Connectors table below.

Table 8 REST Connectors

Connector Modern Web Examples

client libwww, libwww-perl

server libwww, Apache API, NSAPI

cache browser cache, Akamai cache network

resolver bind (DNS lookup library)

tunnel SOCKS, SSL after HTTP CONNECT

A.2.4.2 Code on Demand (COD)

Code-on-demand [37] enables client components that have access to resources to download the software code that they need to process these resources. This function sends a request to a remote server for the code, receives that code, and executes it locally.

The advantage of code-on-demand is the ability to add features to a deployed client, which improves the extensibility and configurability of the services, as well as user-perceived performance and efficiency. It allows adapting to the client's environment rather than centrally controlled through remote interactions. This, however, comes at the price of reduced simplicity, because the local requirements have to be assessed, and because clients’ behaviour is no longer uniform. However, this amounts to edge-processing that off-loads work from a busy server to the clients.

This COD flexibility is a two-way sword. It is possible to extend clients’ functionality by downloading and executing code in the form of applets or scripts after implementation, so that features can be added and modified later. However, although this simplifies initial service launching by reducing the pre-implemented features, it also reduces visibility of what has been downloaded, and may cause undesirable feature interaction. The most significant limitation is the lack of visibility due to the server sending code instead of simple data. Lack of visibility leads to obvious deployment problems if the client cannot trust the servers.

The reTHINK architecture is based on creating hyperties that require downloading of software, hence such techniques as COD are particular relevant.

A.3 The Delivery Platform Framework

A.3.1 TMF Service Delivery Platform

The TM Forum Service Delivery Framework (SDF) Program during 2007 – 2009 was an example of a Telecommunication industry initiative that follows this trend, but its adoption has been weak. As a result, the ability to support a vibrant ecosystem of developers has not materialized. Figure 44 depicts the TMF reference architecture for SDF. This architecture highlights the components of service delivery as well as the service life-cycle, through design, deployment, management, repository management, etc., as well as the operational components.

4 Source: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm



Figure 44. TMF reference architecture for SDF5[41]

A.3.2 Peer to Peer Architecture

In the traditional client-server model, the roles of the server and of the client are well defined: the former provides a service, the latter consumes it. In the late 90's, a new interaction paradigm was defined, the Peer-to-Peer (P2P) model, where all the participants are both consumers and providers of the service. A possible definition of P2P is:

A self-organizing system composed of equal and autonomous entities that intend to provide a service to each other, by sharing distributed resources in a network environment, avoiding centralized services.

P2P has evolved over the years, and the name is also applied to direct communication between only two end-points, without server involvement, such as happens today with WebRTC calls.

The P2P model has been hugely popular for large scale operations such as file distribution, distributed file systems, publish/subscribe, Content Distribution Networks, QoS on top of the Internet, Digital Currency, among others, but also for more personal purposes, such as video-conferencing and Instant Messaging. Today, P2P concepts are being used on different scales, from the Internet, the Data Centre (e.g. for clustering, replication, failure recovery), to small scale sensor networks.

P2P technology first gained notoriety in the late 90's, early 2000's, thanks to P2P file sharing applications such as Napster, eMule [emule], BitTorrent [bittorrent1, bittorrent2] or gnutella. These applications became popular as they allowed users to access multimedia content at a time when no legal alternatives (such as iTunes) existed yet. Even though these applications were instrumental in popularizing the P2P concept, only gnutella is a pure P2P application. Napster and eMule used servers for searching for content and for peers sharing that content. BitTorrent also relies on the use of servers (called trackers) for the process of finding other peers, but it does not use any servers for finding content - this operation is provided by third party search engines. More recently, BitTorrent clients became able to operate in tracker-less mode, by replacing trackers with a Distributed Hash Table (DHT).

5 Source: OASIS, Telecom SOA Use Cases and Issues Version 1.2, OASIS TC Committee Draft, 2009

SDF Service

Repository (ISS)

SDF Service

(@ Design)

SDF ServiceDesign Metadata

SDF ServiceDeployment Metadata

Design

Deploy

Operate

SDF ServiceOperation Metadata

SDF Service Lifecycle

Metadata Coordinator (ISS)SDF Service

(@ Deploy)

SDF

Service

Lifecycle

Metadata

Repository

(ISS)

SDF Service Quality /

Problem Mgmt (MSS)

SDF Service Provisioning

Mgmt (MSS)

SDF Service Billing

Mgmt (MSS)

SDF Service

Usage Monitor (ISS)

SDF Service State

Monitor (ISS)

SDF Service

Resource Monitor (ISS)

SDF Service

Resource Activation (ISS)

SDF Service

Instance

SDF Service Design

Management (ISS)

SDF Service Deployment

Management (ISS)



DHTs are a distributed implementation of Hash Tables, resorting to P2P, where peers store key-value pairs. Data (value) is inserted using a key, and can only be retrieved using that key. In general, DHTs are very scalable, providing access times in the order of O(log n), with n being the number of peers in the network. Access time is thus independent of the number of stored objects, depending only on the number of peers. DHTs normally provide replication mechanisms that prevent data from being lost when a node is offline or unreachable. However, there are several issues that may affect the performance and suitability of DHTs:

Being Hash Tables, there is the risk of key collision. The risk is minimized by using large key spaces (128~160 bit).

Due to network outages and peer failure, data may be lost or temporarily unavailable

In order to mitigate the impact of peer unavailability, replication is often used. This opens the door for synchronization issues, where different versions of the same data may be simultaneously present in the network or deleted data may continue to be retrievable. This limits the rate at which data may be updated. Some DHT implementations use sequence numbers or timestamps to circumvent these issues.

Cryptographic functions are usually used to generate identifiers both for peers and for data keys. This provides inherent load distribution and some privacy, as one does not control in which peers data is stored. However, this may cause some performance imbalance, where peers who are contributing with more resources (CPU, RAM, and bandwidth) get their data stored in slower peers, thus obtaining lower QoS.

In order for a message (e.g. query) to go from a querying peer to the one holding the data, it must either go through several peers (O(log n) hops) or the same number of peers must be queried for routing information. This opens a window for denial of service attacks, where malicious nodes hide or tamper with messages. Malicious peers may also interfere with the route maintenance protocols, hiding other peers, in what is called an Eclipse attack [eclipse].

Distributed Hash Tables only allow data to be retrieved by using their key. DHTs do not support search. A possible solution is the use of a reverse index, where the DHT itself is used to store the list of objects that match each particular keyword. Boolean searches are then translated into set manipulation operations (i.e. interception, union, complement). However, this leads to load imbalance, as some keywords are more popular than others, and may require very frequent updates.

Chord [chord], Pastry [pastry], CAN [can] and Kademlia [kademlia] are some of the most significant DHT algorithms proposed. Kademlia in particular has seen wide adoption in many projects, namely in BitTorrent clients where it provides an alternative to trackers.

In Kademlia each peer and stored object is identified by a 160b ID. Each peer maintains a routing table, with up to 160 entries (~log n), where it keeps information about a few (typical value is 20) peers in each entry. E.g. a node with ID 000 would keep a routing entry for nodes with prefix 1, another for nodes with prefix 01, another for nodes with prefix 001 and so on. In order to find the peer responsible for a certain key, a peer starts by querying the peers with the longest matching prefix that it knows of, for other peers closer to the key. Those peers will be able to provide peers which have a prefix that has at least one more bit in common with the key. As such, in each iteration, the distance (using the XOR metric) to the destination is reduced by half, leading to O(log n) steps for finding the peer responsible for the key.

Kademlia provides several enhancements over previous DHTs to deal with some of their limitations. At each step, several peers are contacted in parallel, leading to higher traffic but ensuring that slow peers do not affect query response time. As only a few answers are needed in order to proceed to the next iteration, the slower or failed peers can be ignored. Kademlia deals with the data synchronization issue by using soft-state: an entry is automatically removed if it was not been re-inserted after some time. As such, deleted data will eventually disappear from the DHT. The typical value is 24 hours, which is suitable for storing peers sharing a file, its original use case. The large



number of peers sharing each file makes it viable to store a significant amount of stale data, as these peers can be ignored and the currently available ones used instead.

The success of P2P services has prompted the development of WebRTC which brings P2P capabilities to web browsers, enabling the distribution of P2P application as web applications, downloaded from a central server and run distributed in web browsers. WebRTC provides innovation on two fronts: it enables web applications to stream video and audio in a P2P fashion using state of the art technology; and it provides a data channel for web applications to exchange data among them, providing an essential building block for large scale P2P technologies.

In the context of reTHINK, the multimedia streaming ability is key for delivering communication services on the browser platform. However, such technologies are complex and difficult to use and WebRTC only defines the multimedia protocols to be used in audio or video communication. At the time of writing, no session management protocol has been standardized, nor protocols for other purposes (e.g. setting up policies for QoS, security and privacy).

P2P technologies and DHTs in particular are also potential candidates for the implementation of key components of the reTHINK architecture, such as the Catalogue /Directory components.

A.3.3 WebRTC Media

Taking a web-centric service perspective on IMS, the complete standard and environment may be considered somehow anachronistic. The value of IMS lies clearly on trust, security, accountability and the integration of managed networks but does not address requirements from an open service environment, such as programmability, extensibility and ease-of-use.

With HTML5, and new WebRTC features, the Communication Industry have an opportunity to reTHINK the full Core Communication Services Infrastructure, unifying communication Web and IoT towards a more agile, simple and open environment. Applying RESTful APIs and light policy driven SOA Governance principles, would lower the barrier, facilitate cloud deployment, and of course the composition with Web applications.

WebRTC is a technology that allows real time communications or Peer to Peer (P2P) data exchanges through web browsers. This was a joint initiative of Google and Ericsson and is being standardized by the W3C and IEFT in a coordinated way. It is a JavaScript framework that builds on top of the HTML5 audio, video and data/messaging elements, allowing a web developer to easily create peer to peer communications applications with no need to install plugins or extensions in the browser or native applications, thus lowering the barrier to entry for the provision of OTT communication services, as the adoption by the users is easier.

Different devices can have access to WebRTC services, such as general user communication and computing terminals, smartphones, tablets, PCs, but also other categories of P2P data communication devices, such as cash machines and ATMs, connected TV…Any device that can run a WebRTC-enabled browser can access to real-time communication services.

Browsers like Google Chrome and Mozilla Firefox were the early adopters of this technology. Apple Safari has not yet announced native support for WebRTC, but there are different ways (via plugins, extensions or native apps) to bring WebRTC capabilities to this platforms. The adoption by Internet Explorer is expected soon, as they have announced the support of Object RTC (or ORTC), a different implementation of WebRTC that will be available in the next releases. Meanwhile, a similar approach based on plugins can be adopted.

If in the early ages webRTC relied on the market penetration of the first browser that supports it (Chrome, Firefox), that now accounts for more than 57% of the market share (desktop & mobile), much more possibilities are now offered to use this technologies like plugins or native apps as stated before. Figure 45 shows the dynamism of the browser market.



Source www.w3counter.com

Figure 45. Browser market Share

It’s important to mention that Apple iOS is blocking the access to WebRTC services from browsers, including Google Chrome or Mozilla Firefox. In this case, native applications have to be installed. These applications can use the signalling and media protocols for WebRTC, so they can establish sessions with WebRTC browser-based endpoints. In addition, frameworks like Apache Cordova allow coding just once (the WebRTC HTML5 application for browsers), then migrating the code automatically to native apps for different smartphones (like Android and iPhone).

WebRTC is a technology focused on media. It defines:

a JavaScript API to manage real time communications between remote entities

NAT traversal using ICE (Internet Connectivity Establishment)

a standard protocol to convey real time media between a browser and a remote entity

A set of mandatory media codecs that all implementations should support for guaranteed interoperability between peers (G.711, OPUS and DTMF for audio, VP8 and, more recently, H.264 for video)

However, WebRTC does not specify how communications are established (e.g. from signalling perspectives). Different initiatives behind the IETF have been adopted to standardize some signalling protocols for WebRTC, but there is no agreement across vendors. SIP over WebSocket, JSON, proprietary APIs and SDKs, standard APIs are options already available by different vendors.

WebRTC services will also require:

Opening network functionalities to developers and users. This will be done by standard-based API and SDKs that will help to avoid vendor lock-in and bring a huge quantity of web developers to the world of real time communications. This way, easy-to-use APIs will be available soon.

Managing quality of service and efficiency with measurement tools. There will be valuable tools to define, implement and test, and some cost-efficient mechanisms to improve the quality of communications.

Building services that deal with all the security concerns. Different services offered as OTT have suffered security threats and attacks, due to the immaturity of their business model, company background, and issues related to lack of ownership to the layers below applications (multi-layer policy servers or firewalls cannot be used here).

WebRTC does not mandate the context in which real time communications are used.

http://www.w3counter.com/#_blank



WebRTC brings web technologies into the communication ecosystem and vice versa. It also enables the establishment of a data channel between two browsers (it can be used to convey anything) with multiple options to cover different usages:

low latency and/or unreliability : for real-time data (e.g. multiplayer games)

reliability: e.g. file transfer

The reTHINK project will investigate WebRTC peer-to-peer capabilities to design a P2P but manageable Service Architecture, where secured and asserted governance policies are enforced.

A.3.3.1 WebRTC Control Frameworks

In [34], a review is given of webRTC related standardization that enables browser to browser multimedia communication. Standardization efforts are conducted by both IETF and W3C Work groups (RTCWeb and WebRTC respectively). The paper indicates that further standardization is still needed for congestion control, selection of audio/video codec and security (including authentication, identification and trust).

Signalling in WebRTC is not standardized and browsers can choose any signalling protocol or use their own customized signalling. The only requirement is to share multimedia session description that describes all the necessary parameters to establish media path. For this purpose instead for the widely used SDP protocol, IETF is standardizing JSEP (JavaScript Session Establishment Protocol), which will be much more suitable for WebRTC proprietary signalling, comparing with SDP.

IETF is also working on multiplexing multimedia traffic in a single RTP session, to avoid ‘punching holes’ for each stream being used. IETF is yet to decide which audio codec (G.711, opus, vorbis etc.) and video codec (H.264, VP8 etc.) will be used.

A.3.3.2 The JSEP Architecture

WebRTC is a media engine, not a service. It doesn’t define the way to communicate, does not handle identity, and how trust is controlled. It doesn't define or detect the end user availability, nor the devices or numbers to use to join someone, etc. Some webRTC attempts to address webRTC issues have already appeared, for example: openWebRTC, matrix.org, PeerJS, EasyRTC, but also TokBox, ApiRTC, etc. The JSEP (JavaScript Session Establishment Protocol) architecture: among them supports the offer / answer protocol for the setting of session description in SDP (session Description Protocol). Figure 46 depicts a high level JSEP architecture.

Figure 46. JSEP Architecture

The goal of signalling protocol is mainly to exchange SDP offers / answers. When this is done, media can be exchanged between the caller and the callee (or depending of network configuration using a

Web

Browser

App App

Browser

Signalling

Session description

Media Flow

Session Initiation

Calling party Called party

http://matrix.org/#_blank



relay server). Media streaming is managed by the RTCPeerConnection which is a WebRTC component integrated in browsers. Figure 47 describes the basic architecture to manage a WebRTC communications, and the proposed reTHINK media flow via TURN gateways. The media that flows between two browsers is the classic webRTC, while the proposed reTHINK media flow requires routing via TURN gateways. Call Control within the WCS communication platform may be provided not by the Apps, as in current webRTC solutions, but by a third party (the CSP), who specializes in communication services. The MCU (Multipoint Control Unit), is usually provided by the application that provides the conferencing facilities. The MCU, acting also as a Media Server, is both signalling (conferencing logic, media control) and media (transcoding on the fly as well as bridging).

Figure 47. WebRTC Communication Architecture

Call Control server:

This server is in charge of signalling management and users’ registration, calls establishments etc.

TURN server:

This server handles STUN & TURN negotiations. STUN is used by client to know their public IP address, TURN is used as a media relay when Peer to Peer communication are not possible due to NAT and Firewall restrictions.

MCU: Multipoint Control Unit

An MCU is used to bridge videoconferencing connections and enables several users to connect

A WebRTC service can then be enhanced to offer several additional features and to enables connections for several different devices types, in particular support of mobile devices operating systems: iOS, Android, Windows Phone, etc. and support of non WebRTC compatible browsers with plugins.

A.3.4 Signalling protocols and Gateways

Interoperability of WebRTC communications and SIP based systems is an inevitable requirement, given the roll out of VoLTE/IMS in both wireline and wireless networks. In [45], a method of ‘SIP in JavaScript’ is proposed, with two options:

In an Endpoint Browser approach, the SIP stack runs in JavaScript in browser, using a SIP proxy server to support Web Socket;

In a network gateway at web serve, it is proposed to have a special gateway to enable interworking. This gateway can be hosted by web provider, VOIP provider or an independent third party.

Internet

Browser Browser

WebRTC Communication Service

ReTHINK Media Flow

Calling party Called party

TURNGW

MCUMedia Server

App App

TURNGW

Classic webRTC Media Flow

Call Control



The paper argues that signalling over Web Sockets (SIP in JavaScript) and media over WebRTC allows keeping tools separate from the applications, which enhances scalability and flexibility. As the last resort, a network gateway capable of translation is used for transcoding signalling and media.

Figure 48 shows the proposed SIP-webRTC gateway, where highlighted areas indicate the differences.

Figure 48. Comparing SIP proxy with SIP-webRTC Gateway

Note, that while SIP is a proxy, the proposed SIP-WebRTC gateway is a B2BUA (Back to Back User Agent), which implies special resident intelligence and decision making, rather than merely represent the user actions to the network.

A.4 Identity and Trust Management

The profusion of independent services over the web has led to ever increasing end-user identifier profusion. Therefore Single Sign-On (SSO) solutions emerged to reduce complexity for end-users: this pattern is organised around 3 party roles: end-user, service provider (also named relying party or RP) and identity provider (IdP).

Beyond sharing identity, transactions and communications between parties need trust. However this concept is not yet defined to a broad consensus.

A.4.1 IdP Capability – Current Status

The functionality of the IdP is already specified in some standards, though a complete consensus is still not achieved. Therefore, it may be possible for the reTHINK project to influence what the IdP performs, what is returned in response to a request, and how trust and privacy are maintained. While all agree that the identity is asserted by the IdP against given and solicited information, opinions are not unanimous on the availability of user discovery service. OASIS (standards for Internet security) defines (since 2008) the IdP role and has produced specification for such identity services in [38], but they do not include all the requirements.

A.4.1.1 Identity Provider (IdP)

The definition of an Identity Provider (IdP) in Wikipedia is give as follows:

“An Identity Provider (IdP), also known as Identity Assertion Provider, is responsible for

providing identifiers for users looking to interact with a system,

asserting to such a system that such an identifier presented by a user is known to the provider,

possibly providing other information about the user that is known to the provider.

This may be achieved via an authentication module which verifies a security token that can be accepted as an alternative to repeatedly explicitly authenticating a user within a security realm.”

Such a function is already performed by websites that allow users to log in with Facebook credentials, where Facebook acts as an identity provider. This means that a user needs to be

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



authenticated only once with SSO (Single Sign-On). The obtained security token is then validated by an Identity Assertion Provider for each system that the user needs to access. Identity Assertion via security token uses several protocols, such as SAML6, SPNEGO, and X.509.

A.4.1.2 Identity Management (IdM)

The concept of identity management is wider than the identity ‘provision’ and assertion, and incorporates not only individuals’ authentication (i.e. identity assertions by their user credentials), but also authorization of service, access rights and privileges within systems or enterprise boundaries. IdM covers issues such as how users gain an identity, the protection of that identity and the technologies supporting that protection (e.g., network protocols, digital certificates, passwords, etc.). As a rule, the term IdP has been used in the Internet space, while the terms "Identity Management" and "Identity and Access Management" (or IAM) are used interchangeably within the enterprise space. The related technologies include Directory services, Digital Cards, Access control, Digital Identities, Security Token Services (STS), OpenID, WS-Security, WS-Trust, SAML 2.0, OAuth and RBAC:

OAuth: https://tools.ietf.org/html/rfc6749

OpenID Connect: http://openid.net/connect/

WS Security: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

WS Trust: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx

RBAC: http://en.wikipedia.org/wiki/Role-based_access_control

A.4.1.3 Identity Service Broker (IdSB)

Since users can choose their Identity Providers, contacting other users will require a discovery mechanism that searches all such service providers, i.e. an Identity service broker. This is a function that is most likely to be provided by each and every Identity Provider and Identity Management system. This is not a separate role. This function may rely on a directory service or other broker mechanism.

A.4.1.4 Evolution of the IdP Functions

These IdP services will provide IP addresses of particular services, but they may not be able to cope with returning IP-address that is invariant against endpoints' movement. The trend to bring web communication services to mobile handsets raises the issue of managing dynamic location addresses, which may require a different approach.

There are various attempts to define a generic identity model for WebRTC, but they may not meet all the application uses cases for this project. See [Beltran, 2014] for such a case.

A.4.2 The generic Identity Management model

This Identity Management service has to deals with identifiers that are prevalent over the Internet, where telephone numbers are not necessarily available, and where users need to be identified by multiple services that collaborate on the communication service delivery. A general representation of this facility is shown in Figure 49.

6 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

http://en.wikipedia.org/wiki/Single_sign-on

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

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

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

http://en.wikipedia.org/wiki/X.509

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


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

http://en.wikipedia.org/wiki/Protocol_(computing)

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

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

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

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


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

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

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

http://en.wikipedia.org/wiki/WS-Security

http://en.wikipedia.org/wiki/WS-Trust

http://en.wikipedia.org/wiki/SAML_2.0

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

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

http://openid.net/connect/

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security



Figure 49. WebRTC Identity model

A.4.3 Identity Management by Telecom Operators

Telecom operators have long managed identities of their subscribers, implementing E164 as a reference for standard exchanges. The fact that phone numbers are identifiers that are used as reaching addresses is a fundamental concept at the core of telecom business. The E164 scheme has achieved global unique identification that is structured by country/operator/user. Mobile phone numbering has continued the fixed line PSTN scheme by assigning MSISDN numbers as the publically known numbers, which are associated with the internal (secret) user account number. Whilst PSTN numbers identify a fixed location, the mobile numbers identify a device, or more precisely the SIM firmware that contains the internal number (IMSI). As we move on to Internet based identifiers, mobility is now required across access type and across devices, hence a new identifiers and a new way of associating them with users are required.

Furthermore, Telecom identifiers were in fact owned by the particular carrier. Over the past decades, due to user demand, number portability across carriers has been established, though not without difficulties. Such flexibility is still highly desirable, because it allows users to choose service provider, and easily migrate at will, while service providers have to compete to retain their users. Such portability can be achieved by Independent Identity Providers, who are not tied to a particular network or a particular service.

Previously, Telecom operators have acted as trusted parties within their networks, and users association with the identifier was through possession – of the mobile device or the fixed line. The reality of the Internet is that identities can be ‘stolen’ or ‘subverted’ in cyber-space, hence a secure method of protecting identities is now sought more than ever. The independent IdP must be a trusted party that keeps personal information confidential and secure, while gaining the trust of other service providers seeking verification of identities.

Identity has also undergone other changes. In PSTN, the physical fixed connection was associated with house/building ownership, and the phone number represented a family or an office department, as well as individuals. In Mobile network, the location was no longer couples with the user identification, and devices became personal, so the individual user is now determined. In web identities, users are associated with numerous service-based identities and multiple devices. The issue now is to link disparate ‘personas’ with a single user identity.

The linking of identity credentials to an application, or more flexibly – to a set of application, has been conceived within the IMS design of user profiles for HSS. The standards allow for multiple

Signalling Server

BobBrowser

AliceBrowser

IdP1

HTTP forwarding ID assertion

HTTP with attached ID assertion

Get ID assertion

Verify ID assertion

JS APIJS API



accounts, identified by the internal numbers IMPI (IP Multimedia Private Identity), which can be linked to one or more public identifiers, i.e. telephone numbers, which are referred to as IMPU (IP Multimedia Public User).

The issue of multiple devices is alleviated by the ‘implicit set’ facility to register the members all at once when just one identity in the set is authenticated. Additionally, each public identifier (IMPU) is associated with a ‘service profile’, which is a set of communication applications that are configured together, to ensure full compatibility and feature interworking. Several IMPUs may be associated with one service profile, to enable easy provisioning. This combination of services/identifier can also be associated with a GRUU (Globally Routable User URI) – that is a particular device IP location, thus linking IP address with a SIM-based identifier temporarily or permanently. The IMS full identity/service structure is shown in Figure 50.

Figure 50. IMS structured subscription with service profiles

This powerful concept of identity composition that links to service composition provides great flexibility, while still ensuring feature interworking and some affiliation of services and devices. Unfortunately, it has not materialized in implementations, because the service layer failed to link to IMS, but moved to the web space instead.

The issues of composing identities and associating them with service profiles are still to be resolved for the webRTC communication services. It is envisaged that there would be less control exercised over the combination of applications in this environment, since users are expected to experiment and find what works for them, while service providers do not provide any guarantees. In such a paradigm, the multitudes of user identities and the choice of applications are not managed by a single service provider, therefore users are given greater powers over constructing their communication services, and service providers need not worry about complex users’ identity – only about verifying it for a particular service.

IMPI-1 Implicit Set of Identities

IMS

Subscription

IMPI-2IMPI-1

IMPU 1 IMPU 3 IMPU 4 IMPU 5IMPU 2

Service Profile-3

AS-1

AS-4

Service Profile-

2

AS-2

Service Profile-1

AS-1

AS-2

AS-3

UE1 UE2

UE3

GRUU

3

GRUU

1

GRUU

2

GRUU

4



A.4.4 Identity Management in Online Social Networks

Creation and management of identities is one of the core aspects of online social networking (OSN) services. While centralized OSN platforms such as Facebook or Google+ function as a trusted party in these networks, they are able to assign and manage user IDs, while assuring uniqueness of these IDs. E.g., Facebook allows each user to choose a user handle, which has to be unique for the Facebook platform, while a user ID is automatically generated for each user. Both, the user handle and the ID can be used to retrieve this user’s profile.

In distributed OSN platforms, this task is rather complicated. In the 90’s, XMPP introduced JabberIDs, which are formatted just like an email address, e.g., [email protected] [[9], [10]]. Here, the username has to be unique for the platform, which again is identified by the domain-part of the JabberID. The same user ID schema has been adopted by several federated OSN platforms, such as Friendi.ca and Diaspora. Here, the social profiles of users can be hosted on any server, referred to as a “pod”, which then communicates with other servers using a federation protocol. The respective pod is responsible for the identity management of the hosted user accounts. A major drawback of this approach is that users have to trust the respective server, while server can be hosted by anyone, with little to no restrictions.

Other approaches in distributed OSN (DOSN) platforms propose different options for ID creation and management. SONIC [[7]] uses a DHT-based p2p network to host signed records for users, while the actual user profiles and the associated content are stored on servers connected by an open federation protocol. Here, PBKDF2 [[8]] is used to generate an ID of 256-bit length from a RSA public key and a ‘salt’. The public key, the salt, the ID, and the actual profile location (i.e. domain) are then signed and stored on the DHT. Users who exchanged these IDs can retrieve the public key and profile location from the DHT and verify it’s authenticity by checking the signature.

In other research projects that leverage P2P technology for decentralized online social networking, there were different proposals to create IDs. LifeSocial.KOM [11] simply states it uses pseudonyms. Within the Safebook project [15], there is a central trusted identification service that assigns unique identifiers and pseudonyms. In the Polaris project, OpenID is utilized [13]. Both Musubi [12] and Prometheus [14] use public keys as identifiers for its users.

A.4.5 Web identity (and SSO)

The profusion of independent services over the web and the inability to share a single unique identifiers among several websites and community lead to an ever increasing burden for end-users. This tendency also raised some concerns about security issues, as users tend to recycle password among accounts.

For these reasons Single Sign-On (SSO) solutions emerged. Relieving users from their burden and bringing new use-cases to web developers. The SSO pattern requires three parties: a end-user, a service provider (relying party or RP) and an identity provider (IdP).

The widespread adoption of the SSO paradigm led to the role of the IdP gaining a large control over its relationship with any given user and their associated identifying data at the expense of RPs [16]. The IdP role and its dominant position is the subject of a large competition between web actors but remains trusted by OTTs. From the user perspective this can be perceived as a privacy issue, hence the emergence of IdP-proxy solutions (BrowserID by Mozilla, etc.).

Two SSO systems in particular are gaining broad acceptance. The relatively mature SAML has been mostly adopted in enterprise, educational networks, and e-government. OpenID Connect is being widely developed and deployed by web actors.



A.4.5.1 SAML

SAML (Security Assertion Markup Language) is a OASIS standard to exchange security assertions (mainly authentication and authorization decisions) between ITs. In particular it formalizes the exchanges needed between an IdP and a SP when using SSO service, using XML structures to implement them.

As it has been built with some abstraction level it may be adaptable to several transport protocols. However it has mostly been deployed on HTTP.

The authentication response contains in this case an authentication assertion, i.e. a signed proof that the IdP has authenticated the user (or subject) at a specific time, for a specific SP (audience), and using a specific means to that purpose (an authentication context). The signature ensures its integrity and non-repudiation.

SAML has also endorsed cascaded authentication request: IdP may delegate authentication process to partner IdPs for foreign users: the trust model implied is called “circle of trust” (CoT), in which each IdP is at the centre of the trust relation ship from its associated SPs, and IdPs may build other higher-level CoTs between themselves.

SAML trust relationships are based upon metadata exchange when establishing business links.

However the XML and signature mechanisms have labelled SAML as complex, so that only big IT has actually implemented part of these specifications.

A.4.5.2 OpenID Connect

OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It enables Clients (RPs) to verify the identity of an End-User based on the authentication performed by an Authorization Server (IdP). Information about the End-User can then be obtained from a UserInfo Endpoint with an Access Token.

The primary extension made to Oauth 2.0 by OpenID Connect to enables End User authentication is the ID Token. The ID Token is a security token that contains Claims about the authentication of an End-User by an IdP. Most notably it contains identifiers for the token issuer (the IdP), the subject (the End-User) and the audience (the RP). The token can optionally define values for the Authentication Context Class (Assurance Levels) and the Authentication Methods. ID Tokens may contain other claims from then one defined in the specification. Claims that cannot be understood must be ignored. Each ID Token must be signed and can optionally be encrypted (after being signed), ensuring authentication, integrity, non-repudiation, and optionally confidentiality.

SP User IdP

---------------------------------------------------------

-------------------- AuthN Request --------------------->

<------- AuthN & AuthZ ---->

<------------------ AuthN Response ----------------------

RP User IdP

---------------------------------------------------------

-------------------- AuthN Request --------------------->

<------- AuthN & AuthZ ---->

<------------------ AuthN Response ----------------------

------------------ UserInfo Request -------------------->

----------------- UserInfo Response ---------------------



OpenID Connect rely on the JSON/RESTful paradigm. As an interoperable identity and authentication protocol, OpenID Connect allows for IdP and RP dynamic discovery. Although in practice it is not used much. Most sites providing OpenID Connect integration only allows authentication with the few major OTT IdPs and sometimes domain specific contenders.

A.4.5.3 BrowserID

BrowserID, defines a mechanism for websites to request, from the user via his/her user-agent, a signed assertion of email-address ownership. This is a simple solution that utilizes the fact that email addresses must be unique within their domain and that they can be verified by the email system. This extends the email verification model to web service login. An identity is defined as an email address and is considered verified if the email domain confirms the user’s email account on that domain.

Web sites can use this mechanism to register users on their first visit and log them back in on subsequent visits. The trust path for these assertions of email-address ownership is federated: individual domains can certify their own users. A fallback identity provider is provided to bootstrap users with email addresses at domains that do not yet support the protocol.

Although BrowserID makes it easier for users to sign-in without having to remember more username and password for each site, it is still awkward to enter the full email address every time, and often an additional password is required. In terms of trust – no further information is provided beyond the email address, which reduces trust but avoids user privacy concerns.

A.4.5.4 Amazon Web Services - Identity and Access Management

AWS Identity and Access Management (IAM) web service enables Amazon Web Services (AWS) customers to manage users and user permissions in AWS [AWS-IAM]. The service targets organizations with multiple users or systems that use AWS products, to allow centralizing the management of users, security credentials, and permissions that control and define the access control. Additionally, it also allows centralizing the user credentials and control over the tasks that particular users or systems are running. IAM enables the creation and management of multiple users/processes that can use AWS products, each with individual security credentials and a single AWS account.

A.4.6 Server-side Trust management

Trust is used by intelligent agents to cope with uncertainty about the behaviour (capability or intention) of other agents [17]. It is a necessary ability for the emergence of social cooperation [18]. Jøsang also make the distinction between [natural] trust of sentient being and artificial trust, e.g. the decision making process of software agent about risks.

An intuitive concept, experienced everyday, trust is nonetheless hard to define because of the broad range of situation and interaction it covers. For a trust relationship to emerge two independent actors are needed. The trustor is an intelligent or software agent while the trustee is a possibly non-intelligent agent that can provide a service to the trustor. Some authors emphasize the dependence of a trust relationship over a specific context. A trust relationship between two agents could thus be only viable in a particular situation, for a specific action or on a larger scope.

The purpose of establishing a trust value (reliability trust) is to make a trust decision, i.e. allowing (or not) the trustee to do an action. This trust decision could be binary (yes / no) or soft (give access to a fixed amount of resources) [Bonatti]. The trustor is dependent over the action. This dependence means that the trustor needs the action to be done, gaining a profit from its success (commercial transaction, computation power, information access). On the other hand there is an inherent risk from the eventuality of a failure to accomplish the action or from malicious actions the trustee could



do. It is to note that trust is only present where there is a possibility of a different outcome than expected or agreed [19], at least as far as the trustor is aware of [20].

Methods to establish trust are commonly categorized between policy and reputation based trust [19]. In the following sections we will describe these categories and ways of combining the two approach.

A.4.6.1 Policy Based Trust

Policies describe the « hard evidence » requirements to obtain trust in a situation where trust in an agent itself is unknown but there is an existing trust in a third party authority [19]. Policies involve the exchange or verification of credentials, provided by the third party [19]. This type of trust is often used for authentication purpose. The scale associated with policy-based trust is often binary (the possession of a credential, or not) [21], although the scale can be more precise with the provision of different and/or several credentials type.

Trust here does not directly concerns the capacity or will of the trustee but more the third party authority delivering the credentials and the robustness of the credentials. Thus, trust as a probability estimation of the trustee behaviour may not be the best meaning for policy based trust.

A.4.6.2 Authentication Assurance Levels

Several governments have specified requirements for user authentication to balance the risk with appropriate authentication assurance. These requirements typically specify a set of Authentication Assurance Levels (AALs). Requirements for each AALs are roughly harmonized across various frameworks.

A.4.6.3 Reputation Based Trust

The concept of Reputation describes the perception of a community on the reliability of an agent part of this community. An opinion is a subjective view of an agent about another agent past behaviour. Reputation in a community is thus formed by the sharing of opinion by means of recommendation. Reputation can only exist in a network where data about agents’ behaviours exist and is available. A typical example of such a reputation network can be found in commercial web sites such as eBay. This sort of web sites allows user to rate other users after the completion of a transaction. The reputation of an eBay user is thus directly formed by the sum of each rating process.

The initial reputation of an agent is an important parameter. Indeed, newcomers’ reputation should be high enough to allow access to the service. On the other hand, malicious users with poor reputation should not benefit from newcomers’ reputation by continuously changing their identifiers [47].

In several reputation based trust system the trust value and the decision to trust are ultimately left to the human agent. Indeed most of these services only display the rough reputation data (the sum of the evaluations) sometimes associated with a colour. It may not be a problem in most circumstances, as it keeps the agent in a position of responsibility. Reputation based trust systems in this case would only be providing input to the human trust algorithm.

One of the main constraints of reputation based trust system is the availability of meaningful data. Not every network gives access or has data about the reliability and previous interaction of its agents. In most examples (commercial, sharing or social network), reputation scores are built by using user agent input.

Pirzada and McDonald describe an interesting trust system [22]. They present a model for trust-based communication in ad-hoc networks. An ad-hoc network of wireless nodes is a temporarily formed network, created, operated and managed by the nodes themselves. In their model, nodes acquire an opinion by using the inherent knowledge of the network (i.e. listening to neighbouring



nodes reactions). Trust values are directly derived from opinions on neighbouring nodes since a node can only directly interact with its neighbour. Although not explicit, this model carries a sense of reputation by way of recommendation. As nodes form an opinion about other nodes and derive trust from it, they share this information by answering route request with trustworthy route. A reputational trust value is thus part of this model.

A.4.6.4 Mixing Policy and Reputation

We think that an overlooked relation between policy and reputation based trust is that reputation cannot exist without a satisfactory trust level on the trustee’s identity. It would serve no point to estimate the probability of an agent’s behaviour if we can’t be sure that we are facing the same agent again.

The opposite is not true, as proved by the large set of services relying on policies alone. However, policies based trust could at best carry only a low confidence on the trust action of the trustee (i.e. an agent possessing credentials from telcolabs.com can be expected to have some knowledge on networking. The confidence we have on its capacity would be much higher if his identity was associated with a number of approved and cited papers).

It would be possible to mix policy and reputation trust either by associating a numerical value to the owning of policy credentials (1) or using a policy language combining the possession of credentials with some reputation level to authorize the access of resources[21]. Nonetheless it is important to stay cautious in order to have meaningful trust values.

What would be the sense of an identity trust value and a behavioural reputation trust value abstracted under a single numerical value using method (1)?

Using method (2), what would be the weight of reputation over the possession of credentials? Especially would we want to let an agent with low credentials but a high reputation access our resources?

A.4.6.5 Oranges and apples?

Policy based trust tends to answer the question: Does agent A (who is providing credentials C) have access to the resource R? Reputation based trust answer the question: What is the generally observed behaviour of agent A? This means that in most cases policy and reputational trust do not carry the same meaning and should not be abstracted under a single global trust value, hiding their differences. Thus method (1) is considered as inappropriate. Method (2) keeps the distinction between reputation scores and credentials (although they are hidden under a single policy rule) and thus seems reasonable. Using this method the possession of a given reputation level can be considered to be another credential, strengthening trust that could be placed in an agent.

A.4.6.6 Circle of Trust

The Circle of Trust (CoT) is an older concept and was defined by the former Liberty Alliance. A Circle of Trust is defined there as a federation of service providers and identity providers that have business relationships as well as architectural, operational and legal agreements. The structure of a CoT may vary depending upon nature and scope i.e. business sector, type and purpose, see [91].

A CoT is a rather static and not flexible construct and requires various multi-lateral contracts and agreements. Examples for CoT are big companies.

A.4.6.7 Trust Frameworks

A less static approach is called Trust Frameworks. In digital identity systems, a trust framework is a certification program that enables a party which accepts a digital identity credential (called the



relying party) to trust the identity, security, and privacy policies of the party which issues the credential (called the identity service provider) and vice versa [1].

Figure 51 shows the eco-system of trust frameworks.

Figure 51. Open Identity Exchange Model

The classic triangle of identity (service) provider is well known, user, and service provider a.k.a. relying party. The trust framework provider is a new role, which describes important criteria for a group of services. An assessor has to prove whether a service or a relying party fulfils the criteria specified by the policy makers.

Kantara Initiative and Open Identity Exchange are jointly developing a Trust Framework for different kinds of services and different levels of identity assurance. The work is mainly inspired and driven by the US-government “National Strategy for Trusted Identities in Cyberspace” (NASTIC). Hence, standards get their requirements mainly from the US currently. The development in Europe is a bit behind the US development. There is currently no visible initiative taking care of 3rd party trust. The working model here is still peer-to-peer trust.

The disadvantage of this approach is that to become certified is quite an effort and might be very expensive especially for small companies.

A.4.7 Blockchain

Blockchains is a technology that has its roots in Bitcoins a financial application dealing with virtual currency. It was introduced by Satoshi Nakamoto in 2009 [90]. A Blockchain contains a record of every transaction made by every participant. The Blockchain can be used to verify transactions and achieve consensus based trust in a decentralized environment. Besides the blockchain, an ordered back-linked list of blocks carries transactions. Satoshi also introduced a decentralized consensus protocol based on blockchains. The core of a blockchain is the transactions. These transactions are signed and then broadcasted to the network of nodes. The nodes validate and propagate these transactions.

Policymakers

user

Assessor Assessor Assessor Assessor

Trust Framework Provider (TFP) Trust Framework Provider (TFP) Identity

Service

Provider

Identity

Service

Provider

Relying

Party Relying

Party

Contracts with the Trust Framework Provider for implementing reuirements set by Policy makersq

Other agreements potentially affected by requirements set by Policy makersl

Policymakers

user



Trust Framework Provider (TFP) Trust Framework Provider (TFP) Trust Framework Provider (TFP) Trust Framework Provider (TFP) Identity

Service Provider

Identity

Service Provider

Identity

Service Provider

Identity

Service Provider

Relying Party

Relying Party

Relying Party

Relying Party



Inside the Bitcoin application the technology is used to prove the flow of coins from one node to another. Therefore, a node can only spend those coins in a transactions that it received in former transactions. Projects like Ethereum (https://www.ethereum.org/) or ADEPT (http://de.scribd.com/doc/252917347/IBM-ADEPT-Practictioner-Perspective-Pre-Publication-Draft-7-Jan-2015) try to use blockchains also in other context.

There concept of blockchain could be reused for reTHINK in order to establish trust in a rather lightweight way. While in classic trust approaches, like circle of trust, trust frameworks are rather hard to setup in terms of business and legal agreements, blockchains for dedicated domains and use-cases are easier to apply.

Blockchains or at least some their principles seem to fit to reTHINK, because:

1. We have singular transactions like conversation between user A and user B or between device A and device B

2. Historic Information like “I already talked to this person” might increase trust in reTHINK scenarios

3. Blockchains also work in distributed scenarios.

The topic of blockchain has still some issues that are yet to be discussed and resolved, for example - blockchain length, privacy issues etc. However, in dedicated context like in reTHINK, blockchains might still be an option for establishing trust between users. See reference in [90].

A.4.8 Directory Services

A.4.8.1 Existing Directories

Directory services are systems that manage, store, and provide access to data, which is usually indexed by a (unique) identifier. Clients use directory services to resolve a known identifier (key) to one or several values. While most directory services such as the Domain Name System or LDAP (X.500) are structured hierarchically, peer-to-peer based approaches exist. In this section, we summarize related work utilizing different approaches in the field of directory services.

DNS

The Domain Name System (DNS) is responsible for resolving domain names to IP addresses. The domain names are easier to read and memorize than IP addresses. Additionally, the decoupling of IP address and domain name allow for a change of the IP address while retaining the domain name. DNS is a distributed naming system; some authoritative name servers are responsible for certain domains.

LDAP (X.500)

The Lightweight Directory Access Protocol (LDAP) describes directory services that allow authorized clients to access data stored on LDAP servers. Among other functionality, LDAP allows to store and maintain a database of contact details, thus allowing to be used as a network-based address repository. LDAP servers may be configured to have a referral server in order to be incorporated in the global directory. The resulting architecture is hierarchical. Though directory services are a de-facto standard for address management, it is optimized for read operations. One of the most prominent implementations of LDAP is Active Directory (AD) by Microsoft for Windows domain networks.

GSLS (Global Social Lookup System)

The research project SONIC [7] uses a DHT-based directory service for lookup of social user profiles in a distributed online social network. The project proposes a globally unique identifier for each profile, which is generated from a public key pair. The identifier is used as the lookup key to retrieve a data record with information about the location of the social profile. Among other data, the record

https://www.ethereum.org/



comprises information such as location, public keys associated with the profile, and a digital signature. As the GSLS is organized as a DHT, all data records are stored in a decentralized fashion. To prevent loss of data or availability, data is replicated and copies are stored at multiple nodes at the same time. The implementation of the GSLS is based on TomP2P, a Java-based and open source DHT implementation. The service provides a RESTful interface for retrieving, creating, updating, and deleting records.

GCM (Google Cloud Messaging)

Google Cloud Messaging (GCM)7 is the push service used for the Android mobile operating system, allowing developers to send messages from servers to GCM-enabled apps and the other way round. The GCM handles the queueing and delivery to and from the target app. To summarize the general process from the perspective of a directory service: There is one central cloud service that handles queueing and delivery of messages to target apps. There is only one background process on the phone that only needs to "talk" to one central server. The corresponding app is started after receiving a new message from the GCM. Data itself can come from 3rd party servers that connect to the GCM Connection Servers.

P2PNS

P2PNS [68] implements a distributed name service. The approach is two-layered. Each node implements both layers. On the first layer, the KBR (key based routing) layer, each node has a fixed nodeID that does not change. Each node maintains a routing table of IP addresses and nodeIDs of neighbour nodes. On top of this KBR layer, there is a DHT (distributed hash table) layer, which stores key-value-pairs. The key can arbitrarily be chosen (in the context of the paper, where the name service is used for SIP telephony, the key is a AoR, Address of Record), the value is the corresponding nodeID. The resolution from chosen identifier to current IP address then uses the DHT to retrieve the nodeID, and then uses the nodeID to retrieve the current IP address. A caching mechanism is used as a third layer to improve performance.

CoDoNS, which is another P2P-based DNS alternative has been proposed by Ramasubramanian and Sirer with similar functionality [71]. A comparative study found that both hierarchical and DHT-based approaches have advantages and drawbacks compared to the traditional hierarchical DNS architecture, while the DHT-based approaches show a high grade of robustness against targeted attacks [72].

A.4.8.2 Graph Connector

The social graph of an online social network (OSN) consists of connections between users. Typically, such a social graph is stored with a centralized OSN service. One of the ideas of reTHINK is, that there are multiple providers for different services, for example multiple identity providers. If there is no single provider in control of the all the users' data, one possible design approach is to store the social graph in a distributed manner: each user would store his/her own contacts. This way, each user has a limited view of the social graph. The social graph is independent from a single service provider, and, as the graph is stored with the clients, there is no need for a social graph service provider. Instead, there have to be methods available for adding/removing someone to/from a contact list.

With telephone numbers, no approval by the other party is necessary to add someone's number to a contact list. With most instant messengers, the approval of the opposite party is necessary. Instant messengers often allow users to see the "presence" of their contacts. The presence of a user indicates their status, e.g., online, offline, or busy. The need for approval before adding another user to a contact list could also be used for automatically allowing or denying connections (i.e., calls or

7 http://developer.android.com/google/gcm/gcm.html



messages) between users. reTHINK hyperties should require the approval of users before adding them to contact list, if it implies some form of access control, e.g., regarding the presence of users.

Regarding the graph, there could be different types of connections between users, as well as directed or undirected edges, and edges could have weights. With respect to web communication and online social networking, the simplest approach of a social graph utilizes only one type of connection, undirected edges and no weights. Usability and ease of configuration can benefit from such simplicity.

To summarize, the following aspects are important with respect to the social graph:

Identity (global identification of users)

Mechanism/method of befriending other users

Nature of the edges in the social graph

Related issues are:

The notion of presence

Access control

A.4.8.2.1 Centralized Online Social Networks

In centralized online social networks, a single provider can generate unique IDs and manage the social graph, the befriending mechanism, and the access control. Regarding the social graph, there usually is only one type of edge between users - undirected and without weight. What the users can configure regarding access control (what other users can see, etc.) is up the OSN provider. The provider’s access to user data typically cannot be controlled.

A.4.8.2.2 Distributed or Federated Online Social Networks

IDs can be made globally unique by using a pattern similar to email. For befriending between different servers, standardized protocols and data formats are necessary. Each server has information about the social graph regarding the users that are registered with this server. Access control can be managed on the basis of globally unique IDs. The user can choose a server or set up their own and thus have some control over what access the operator of the OSN has.

A.4.8.2.3 FOAF (Friend of a friend)

FOAF is a project from the field of the semantic web. Users can be described in RDF format, and "the property foaf:knows is used to create social links between people" [69]. This way, a form of the social graph is stored in the FOAF ontology. An idea behind FOAF is that each website offers RDF data about users. This way, users’ information is publically available and access control concerns are not tackled.

Golbeck and Rothstein published a study that took data from several websites that use FOAF to represent their users. In their work, they identify users that are registered with multiple of such websites. This is done by comparing unique identifies like email address or instant messaging nicknames [69]. This study shows that not each user is represented through a FOAF RDF file, but each user on each website. In the end, FOAF can be seen more as a data format than as a system with the potential to describe a global social graph.

A.4.8.2.4 XMPP

XMPP (Extensible Messaging and Presence Protocol)8 is a communications protocol mostly used for instant messaging. Its naming and identity service works similar to email: servers can interconnect using a standardized protocol, and users are identified via a naming scheme of

8 http://xmpp.org/



"[email protected]”. Also similar to email, users can host their own servers, register with free ones, or buy the service from a company.

XMPP comes closest to the idea of a distributed social graph. Globally unique IDs similar to email addresses are used. A contact list, called “roster”, is used to store the contacts of each user. To add other users to a contact list, approval by the other party is needed. Furthermore, approval is needed to subscribe to the presence9 of other users.

A.5 Policy and Security

A.5.1 Security Policies

Security policies can be defined as sets of rules that determine how access control decisions are carried out in a system by permitting only authorized users or entities (subjects) to access services or resources (objects). Web browsers, for example, prevent JavaScript code from one web site from accessing the cookies of another web site. Traditionally, security policies are formally represented by access control models which allow the proof of properties about an access control system.

A.5.1.1 Security Policies Models

Security policy models have been traditionally divided into discretionary and mandatory access control. The following describes these two approached as well as other alternative approaches to security policy models.

Discretionary access control (DAC)

Discretionary access control (DAC) policies restrict access to objects based on the identity of the subjects and/or groups to which they belong, and are discretionary in the sense that a subject can pass its access permissions on to another subject. Basic definitions of DAC policies use the access matrix model as a framework for reasoning about the permitted accesses. Discretionary policies do not enforce any control on the flow of information once this information is acquired by a process, making it possible for processes to leak information to users not allowed to read it.

Mandatory access control (MAC)

Mandatory access control (MAC) enforces access control on the basis of fixed regulations mandated by a central authority [Bell73]. Lattice-based models were defined to deal with the issue of data confidentiality, and concentrate on restricting information flow in computer systems. This is achieved by assigning a security classification to each subject and each object in the system. Subjects and objects form a lattice based on their classification, which is used to enforce some fixed mandatory policies regarding the actions that subjects can execute on objects. Lattice-based models can also be used for providing integrity of data [Biba77].

Other security policy models

Over the years other security models have been proposed to formalize security policies required for commercial applications. For example the Clark-Wilson model [Clark87] is a well-known one for commercial data processing practices. The Chinese-wall policy [Brewer89] is another of such examples applicable to financial information systems to prevent information flows that cause conflict of interest for individual consultants. The choice of which security policy model to implement in a system will depend on the specific security requirements of the targeted system.

9 http://xmpp.org/rfcs/rfc3921.html



A.5.1.2 Security Policy Languages

In order to formally represent the security policies and the associated Security policy services, security policy languages should be used. These languages provide a verifiable description of the access control the properties for the system.

The following discusses the most relevant specification languages used in the Web.

eXtensible Access Control Markup Language (XACML)

Defined by the Organization for the Advancement of Structured Information Standards (OASIS), XACML [OASIS10] is an XML specification for expressing policies for information access over the Internet. It provides syntax (defined in XML) for managing access to resources in a general-purpose way. Similar to existing policy languages, XACML allows for the specification of a subject-target-action-condition oriented policy in the context of a particular XML document. The notion of subject comprises identity, group, and role and the granularity of target objects is as fine as single elements within the document. The language supports roles, which are defined as collections of attributes relevant to a principal. XACML includes conditional authorization policies, as well as policies with external post-conditions to specify actions that must be executed prior to permitting an access.

The main advantage of XACML is that it is very general and a widely adopted standard with browsers to display and edit the policy specification. However, although XACML supports a fine granularity of access control specification, the policies are rather verbose and complex, and not really aimed at human interpretation. In addition, the language model does not include a way of grouping policies. Furthermore, policy administration and versioning are not standardized.

WS - Security Policy Language

The WS-SecurityPolicy [OASIS06] is a special-purpose security policy language aimed at securing the communication protocols for web services. Integrated in the OASIS standard, WS-SecurityPolicy extends the fundamental security protocols specified in the WS-Security, WS-Trust, and WS-SecureConversation. In particular, it provides a XML-based specification language of security policies for securing the messages exchanged between a Web service and a client.

In WS-SecurityPolicy, a security policy results from the combination of individual assertions using the policy operators of the WS-Policy framework. The assertions can be used in defining individual security requirements or constraints for the communication channel, such as: (i) what algorithms must be used when cryptographic operations are involved and the key sizes to be used, (ii) whether a timestamp must be included in the messages, (iii) whether signatures need to be included, (iv) whether digests need to be added to the message, etc. Overall there are five different assertion types: security binding assertions, protection assertions, token assertions, supporting token assertions, and protocol assertions. Such assertions can then be combined using logical operators and attached to policy subjects [Mihi08].

WS-SecurityPolicy is a powerful tool, but writing security policies can be cumbersome. To be effective, assertions must be correctly structured, and version namespaces need to be consistent. However, mistakes can easily be made, e.g., by using an assertion in the wrong place or by mixing assertion versions within a document. Furthermore, many web services stacks silently ignore these types of mistakes.

A.5.1.3 Content Security Policy

Web browsers implement a layer of security called Content Security Policy [W3C15]. CSP is a W3C specification that aims to mitigate certain types of attacks, in particular Cross Site Scripting (XSS). Protection is attained by enabling web applications to restrict the location and / or the type of resources that are allowed to be loaded into the client browser. Thus, by specifying the domains that the browser should consider to be valid sources of executable scripts, XSS attack vectors can be



reduced or eliminated. Content Security Policy also helps to prevent packet sniffing by specifying which protocols can be used, for example, requiring that all content be loaded using HTTPS. In CSP, a security policy is specified by adding specific directives to the HTTP header. Each of such directives describes security rules for a certain resource type or policy area.

Content Security Policy provides a rich set of policy directives that enable fairly granular control over the resources that a page is allowed to load. However, Content Security Policy has a narrow scope and its support is not standard or fully supported in all major browsers (Firefox/Chrome/IE).

A.5.1.4 Common Information Model (CIM)

The CIM standard is defined and published by the Distributed Management Task Force (DMTF), and is defined in the RFC 3198 [RFC 3198] as an object-oriented information model. It consists of a Specification detailing the abstract modelling constructs and principles of the Information Model, and a textual language definition to represent the Model. CIM was proposed as a way to provide a high-level representation of network elements. Thus, the policies could be "grounded" and applied to a network device. For example, a policy could describe a change in a function of a device.

However, the CIM model is too high-level and confused many people in how policy would be applied. For example, the CIM had no representation of either a physical port or a logical device interface (and this is true even today). This made it very difficult for people to pictures how policies were going to be applied and build [Strassner2003].

Independently of the selected Security Policy Language, the RFC 3198 published by Internet Engineering Task Force (IETF), providing policy-related terminology and recommendations for its use should be considered. This will encourage the use of a common description for the access control properties.

A.5.1.5 Security Policy Enforcement

To enforce the security policies, systems in general rely on Reference Monitors [Saltzer75]. A Reference Monitor provides an abstract model of the necessary and sufficient properties that must be achieved in order to securely enforce access control. In order to secure web content, web browsers implement their own Reference Monitors. The following provides an overview of the most relevant mechanisms that have been developed over the years for this purpose.

A.5.1.6 Basic web browser security

Web Browser is a client-side application with a basic function to fetch the content from the web servers and display it in the browser’s windows. To transfer content from web servers, browsers implement the HyperText Transfer Protocol (HTTP) and its secure version (HTTPS). Remote content normally consists of HTML pages, media files, and JavaScript code, and can be retrieved from multiple sources. Internally, the browser represents fetched web pages using Document Object Model (DOM) and provides a runtime environment for the execution of the JavaScript code. This runtime consists of a JavaScript interpreter and a set of APIs. These APIs allow the script to communicate with other elements of the page (by DOM APIs), local browser data (such as cookies) or remote servers (by several communication APIs), and to manipulate the web page elements and other browser events.

The biggest threats that web browsers are faced with are malicious JavaScript code and cross site scripting. To mitigate such threats web browsers implement several security mechanisms. In a web page, remote content from different sources can be allocated to isolated domains called iframes. An iframe (Inline Frame) is an HTML document embedded inside another HTML document on a website. The iframe HTML element is often used to insert content from another source, such as an advertisement, into a Web page.



To restrict the content of the web page that JavaScript code running on that page can interact with, the browser implements an access control policy named Same-Origin Policy (SOP). SOP basically says that the script can read properties of windows and iframes that have the same origin as the document containing the script (and not the origin of the script itself). The origin of web content can be defined by the protocol, domain, or some other particular aspect of the communication. In order to protect from the attacks such as Cross-site Scripting (XSS), browsers implement Content Security Policy (CSP). To assure this domain isolation the JavaScript code is interpreted inside isolated sandboxes. Access control to local system resources and services is provided by the browser’s JavaScript APIs.

The CSP should be written by a web page developer and contains a set of sources from which the remote content can be loaded and executed on the page. CSP applies to scripts, objects, style sheets, images, media, iframes, and fonts. Since CSP is oriented on disallowing to fetch the content from the forbidden sources, the enforcement of CSP described in the draft does not forbid making an HTTP request, just the HTTP response should be seen by the browser as an empty response.

A.5.1.7 Fine-grained security policies in web browsers

Several techniques have been proposed to enhance web browser security. One class of such techniques extends the browser to further restrict the JavaScript code privileges. Meyerovich and Livshits introduced the ConScript framework [Meyerovich10], which implements fine-grained security policies for browsers based on aspects [Elrad01]. The authors modified the JavaScript engine of Internet Explorer 8 (and, later, of Mozilla Firefox), changing the original implementations of the security-relevant functions.

ConScript policies [Meyerovich10] are either written manually or can be generated through static analysis of server-side code or runtime analysis of client-side code. The authors also present a type system to ensure correctness of the ConScript policies, but they do not provide formal guarantees of the enforcement mechanism.

Van Acker et al. [VanAcker11] proposed WebJail, a new browser-side security architecture that enables least-privilege integration of components into a web mashup, based on aspect weaving (similar to ConScript) while the security policies are specified for every iframe of the page. The language of the security policy is relatively simple and is similar to CSP. The authors first defined categories of security-sensitive APIs. The security policy specifies a self-defined whitelist for every category of APIs. For example, ”extcomm: [ google .com, YouTube .com ]” means that external communications are only allowed for the given domains.

A WebJail policy is a new attribute of an iframe in a mashup, which means that a mashup integrator can impose restrictions on the behaviour of untrusted third-party components. In the iframe policy, particular security-sensitive events can be fully enabled, fully disabled or enabled only for a self-defined whitelist. This approach is different from ConScript because it enforces specific policies for mashup integration, however the policies are still safety properties: the JavaScript programs are not allowed to invoke the APIs that contradict the security policy.

A.5.1.8 Information flow security analysis for JavaScript

Another class of techniques is based on information flow. Information flow security for programming languages is a large field of research. There are two main security properties that can be enforced in a program by information flow control: confidentiality and integrity. Confidentiality defines that the private information processed by the program should not be revealed to a public observer, while integrity means that the public entities should not influence the private information. In the language-based security community, information flow analysis is implemented for a given programming language and it ensures that no private information is leaked into the public outputs of the program.



Vogt et al. [Vogt07] were the first to introduce a hybrid information flow analysis in the web browser setting. Hybrid means that information flow control is performed both at runtime (dynamically) and prior to execution (statically). The dynamic component is the taint analysis that deals only with explicit flows. The static analysis component is invoked for implicit flows and it analyses the scope of every branch in the control flow that depends on tainted values. This analysis ensures that all the assigned variables in both executed and not executed branches are tainted accordingly.

The sources of sensitive information are the sources containing “information that could be abused by an adversary to launch attacks or to learn information about the user”, for example document.cookie, properties of history object, location information and others. To ensure that the tainted data does not leave the page it belongs to, authors monitor the data transmission operations that may send data to a third party. Hence, with this approach, the security policy is a type of information flow policy, where no tainted data is allowed to influence the data to be transmitted to third parties.

Chugh et al. [Chugh09] proposed a step-by-step technique to enforce information flow properties of JavaScript. The idea is to perform heavyweight static analysis of information flow of the available JavaScript code on the server side, and then use the results of this analysis in the succinct residual checks that are done dynamically on the client side. This technique assumes that the inline scripts are fully trusted and are used to compute the residual policy, while the external scripts are potentially malicious. The residual check is then just a syntactic check whether the external scripts comply with the residual policy. A security policy is a confidentiality or integrity policy represented by a set of pairs for which the flow is disallowed.

Hedin and Sabelfeld [Hedin12] introduce a dynamic type system that guarantees information flow security for JavaScript. The authors first propose a core of JavaScript that is interesting for the information flow perspective: objects, higher-order functions, exceptions, eval. A dynamic type system supports the security label upgrades. The technique also handles a number of JavaScript features that were not covered in other language-based information flow analyses. The dynamic type system halts the program execution whenever an illegal information flow is found. This approach was implemented in a JavaScript interpreter written in JavaScript. Differently from previous works on information flow security in the web browser settings, Hedin and Sabelfeld proposed to extend the notions of information that can be marked as a secret (in the other works only variables or APIs are marked by security labels): the information about the structure of the objects in JavaScript or about existence of particular fields; an existence of a variable in a particular scope.

A.5.1.9 Digital Rights Management (DRM) in web browsers

In order to control the use of copyrighted digital content, hardware and software manufacturers have developed a class of technologies called Digital Rights Management (DRM). Up until recently, DRM for web content was being implemented by browser plugins. Microsoft Silverlight and Adobe Flash Player are notable examples of DRM-enabled video player plugins that prevent unauthorized copy of video content in web browsers. With the move to HTML5, web browsers like Google Chrome started to implement built-in DRM mechanisms, eliminating the need for such plugins.

The W3C has taken the first steps to establish a common approach for DRM enforcement in web browsers by proposing Encrypted Media Extensions (EME). EME is part of the HTML5 set of specifications. It enables web applications to interact with content protection systems, to allow playback of encrypted audio and video. EME is designed to enable the same app and encrypted files to be used in any browser, regardless of the underlying protection system. Support for EME and Content Decryption Modules (CDM) has already been deployed by Chrome, Internet Explorer 11+ (Windows 8.1) and Safari (OSX Yosemite), while others, such as Firefox, are expected to support these standards from early 2015.



Note that EME does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server. Furthermore, EME is optional, meaning that if a browser does not support encrypted media, it will not be able to play encrypted media, but EME is not required for HTML spec compliance.

The actions of CDMs are actually not defined by the EME specification. A CDM may handle decoding (decompression) of media as well as decryption. From least to most robust, there are several potential options for CDM functionality:

1. decryption only, enabling playback using the normal media pipeline, for example via a <video> element,

2. decryption and decoding, passing video frames to the browser for rendering, and 3. decryption and decoding, rendering directly in the hardware (for example, the GPU).

A.5.1.10 W3C Secure Element API

The W3C is also working in the specification of the Secure Element API [W3C14], an API that allows applications in web browsers to interact with hardware tokens named Secure Elements. Such hardware devices offer specialized secure services such as tamper-proof storage and cryptographic operations, such as Smart cards or other embedded secure elements. The Secure Element API specification allows the development of web applications making use of these secure element applications. Some typical use cases that applications can address based on this API include authentication, digital signature, electronic payments, and credential provisioning (allowing for the update of the secure element).

As of the writing of this document, the status of Secure Element API specification is work-in-process and is not yet implemented in commodity web browsers.

A.5.2 Policy Management

Security policies and more generally policies represent properties of information processing systems (IPS) [92], whose theoretical foundations have been at our knowledge, truly defined only recently [93]. IPS built on information and communication technologies (ICT) can roughly be seen as distributed programs concurrently running and interacting by exchanging data following various communication disciplines. The tricky point is that the only way to guarantee (At least for all the actually known policy types) that some IPS system S satisfy some policy P, consists in grafting on S another system S' usually functionally distributed [94][95], the purpose of which is to observe S and to verify that its behaviour is compliant to P. The interesting case indeed is when the behaviour of S may conduct to a violation of P. In this case, before reaching a state where the effective behaviour of S differs from its expected one, S' must intervene at the right time to re-orient the behaviour of S, so that it will remain consistent with P. The intervention of S' can follow different modalities, but the most usual one consists in interrupting the execution of S by taking its control. This is the way policies are usually defined in the literature [96]. The reader may consult [97], which provides a clear and comprehensive survey of this topic. We will focus in this part on policy management which should be understood in a broad sense as the description and the organization of all the tasks around policies, from their definition to their deployment.

Just as a system can be grasped at different level of abstraction, there exists a policy continuum [98]. Such a concept formalized in [99] is useful when trying to connect a high abstract level view of a policy merely expressing a business oriented view to a low-level one consistent with devices



deployment and configuration. The policy life-cycle introduced in [99] can be simplified and presented following [100].

Figure 52. Policy lifecycle model [9]

A.5.3 Policy deployment architectures

This section details the « low-level » life-cycle concerning the « Policy distribution and enforcement » set of tasks. The IETF model [100] introduces two main entities namely the PDP (Policy Decision Point) and the PEP (Policy Enforcement Point). The first one which is the smart part of the architecture acts as a controller the goal of which consists in handling and interpreting policy events, and deciding in accordance with the policy currently applicable, what action should be taken. This one is transmitted to the PEP which has to concretely carry it. The model may integrate a Policy Repository maintaining the set of policies of interest.

Figure 53. The IETF policy architecture [94]

IETF developed COPS (Common Open Policy Service) [101] as a dedicated protocol to support policy-based QoS control in the IETF framework [94]. COPS is client/server protocol using a query/answer schema from the clients implementing the PEP (Policy Enforcement Point) to the PDP (Policy Decision Point) acting as a server. Policy objects transported by COPS are self-identifying and may be adapted to dedicated proprietary needs. Such orthogonality between the protocol and the associated

PEPPackets in Packets out

PDPPolicy

Repository

LDAP/SNMP

COPS



transported data defines the COPS extensibility capability, which is quite useful. COPS is stateful and necessitates a reliable transport layer (TCP not UDP).

COPS-based policy control may obey to two main models [102]:

The outsourcing model allows the PEP to delegate on its behalf the responsibility of specific decisions to some external PDP

The configuration or provisioning model (COPS-PR [102]) which allows the PDP to proactively transfer orders to the PEP according to external events, PEP requests or a combination of both.

COPS-PR does not depend of the provisioned policy. A dedicated structure called the PIB (Policy Information Base) [103] defines the COPS-PR underlying data-model. The PIB can be seen as the root of a conceptual tree where the branches define the provisioning classes (PRCs) and the leaves the provisioning instances (PRIs). This approach has been slightly adapted by 3GPP when defining the architecture of control of QoS of the IMS in its first releases (R5 and R6) called Service Based Local Policy (SBLP) [10][105] :

Figure 54. The R5/R6 QoS control architecture of the IMS [15][16]

IMS specification is functional by nature. The PDP entity has been renamed PDF (Policy Decision Function), keeping the same capabilities as the previous PDF. PEP, which is usually deployed in the transport layer, is outside the scope of IMS and remained unchanged. Interface Gq is diameter based while Go used COPS-PR. These interfaces are mainly used to exchange media authorization tokens compliant with SBLP, together with charging data.

IMS Release 6.8.0 introduces a new charging capability: Flow Based Charging (FBC), the goal of which was to extend the SBLP, which led to the definition in R7 of a new architecture devoted to the control in a coherent way of QoS and charging. This new architecture called Policy Control and Charging (PCC), and can be seen as the merge of SBLP and FBC.

Policy Server

IMS Proxy

P-CSCF

PDF

GGSN

PEP

Gq (Diameter)

Go (COPS-PR)



Figure 55. The PCC architecture defined by 3GPP [4]

The main components of PCC are the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) which fundamentally act as PDP and PEP respectively [94]. COPS-PR disappeared in favour of Diameter, which is used on interfaces S9, Rx, Gx, Gy, Gz.

A.6 Specialized Network Services (SNS)

A.6.1 Why SNS are needed

Real-time communication services have become much more than voice services traditionally offered by Telcos. The growing interest in unmanaged communication services offered by Web companies, like e.g. WebRTC solutions, may lead to marginalization of managed VoIP services offered by network operators. As a result network operators search for new opportunities in order to stay relevant in a business value chain. One of these opportunities can be offering Specialized Network Services (SNS) to Web communication service providers.

Managed VoIP services by network operators can offer better reliability than communication services offered by Web companies, because network operators have control over their environment and the network performance, although this is limited to a given territory, according to regulatory and contractual constraints.

Communication services offered by web companies (OTT – Over The Top, i.e. without involving the operators) are different than managed VoIP solutions. They rely on loosely coupled elements and take advantage of flat rate data plans. They operate globally via the Internet global reach, and are not constraint by any regulatory or contractual aspects within each country. They use ‘best effort’ routing (i.e. no guarantees) but they can improve the quality of communications by using mechanisms built within their applications, for example adaptive codecs are used in order to manage variable bandwidth. However, such measures do not appear sufficient to cope with all situations, for instance, large conferences or widely distributed participants which access a conference via different access networks. Another example is a browser congestion mechanism, like Receiver-side Real-time Congestion Control (RRTCC) that is implemented in WebRTC-enabled browsers, but that works only for low delay networks [4].

Application

Function (AF)

Policy and Charging

Rules Function

(H-PCRF)

Policy and Charging

Enforcement

Function

(PCEF)

Subscription Profile

Repository (SPR)

Online Charging

System (OCS)

Offline Charging

System (OFCS)

Policy and Charging

Rules Function

(V-PCRF)

Home Network Visited Network

Rx

Gx

Sp

Gy

Gz

S9



When Web Communication Service (WCS) providers adapt to given network performances by using application layer mechanisms, they sometimes end up adapting to bad quality, so the service performance is changeable and low quality. In order to offer predictable quality services, web companies need a reliable network infrastructure, supporting increasing number of applications and users.

Network performances vary in different network segments, especially wherever congestion is created [5, 6]. The pace of increasing demand affecting network capacity is different than the actual rate of increasing network resources. There are technical and economic aspects that make it difficult to predict exactly the rate of traffic growth and new peaks, and whether new investment in to network is required. Traffic growth is often linked to major service innovation but also to human and social factors that cannot always be anticipated. Traffic unpredictability and congestion is caused by:

Congestion is mostly caused by peer to peer traffic that changes throughout the day, but also by Content Delivery Network (CDN) providers that assure routing management at the application layer based on their own criteria

The number of devices on a single link in wireline access networks is increasing. These devices are mostly used for peer to peer applications with video and rich media content. Since there is no overprovisioning at this point, congestions can be created [3].

In mobile access networks, radio resources are limited since they are shared by multiple users in a cell. However, the congestion risk is mitigated in core networks, because the backbone can be more easily over provisioned than access networks.

At interconnection border points, congestion is caused by peering disagreements. Since the Internet is not controlled by one company, different network providers and Internet service providers need peering agreements to exchange traffic between them. Peering agreements, especially when they are abused, e.g. in case of asymmetric traffic, are mostly the reason for congestion and decreased quality. This problem cannot be alleviated by consumers buying faster Internet connection.

Even in the absence of congestion, when the global demand of bandwidth is satisfied, there may still be insufficient web real-time communication services that are processed as best-effort, hence dedicated specialized network service offered by network operators may fill the gap.

A.6.2 How SNS can be offered

When offering specialized network services two approaches can be used:

Over-the-Top approach that assumes exploiting ‘best-effort’ paths diversity and selecting the most advantageous. It can be done at the application layer, so possibly without network operator cooperation.

In-network approach that assumes exploiting paths with specialized network services. As a result it demands coupling between application and network layers.

There are several issues when offering specialized network service to web communication service providers. They are mostly caused by the fact that there is no coupling between application and network layer, network operator does not have any information about signalling so it is difficult to identify and assure admission control of a given flow. In addition, there is no service fulfilment that can be used to ensure the quality during the whole communication. Additionally, it is difficult to offer a global solution, since there may be multiple (not necessarily cooperating) network operators present in the communication path. In addition, endpoints can belong to different kind of networks (mobile, WiFi, fix) and be controlled by different actors. So far, there is no universal model of exposing and monetizing specialized network services.

Different business models can be used when offering specialized network services to communication service provides: monetized and neutral.



Monetized specialized network services can use B2B2C model that is offering services to third parties, i.e. Web companies, so indirectly provide it to the end users. It is difficult to use B2C model, i.e. provide network services directly to the end users, since users would not understand all aspects and generally consider Web services as free, so would not be willing to pay.

Neutral specialized network services assume improving quality in general for everyone.

A.6.3 What is expected of SNS

Stakeholders have different expectations towards web communication services that should be taken under account when offering specialized network services. Some major requirements allowing providing specialized network services are as follows:

Solution must have global reach and must acknowledge participating and non-participating network operators.

Solution must be compatible with application layer technologies.

Solution must be compatible with deployed network technologies for different network segments.

Depending on a chosen business model (B2B2C or neutral) different use cases should be considered:

Specialized network services with end to end SLA (Service Level Agreement) requiring cooperation between participating actors (defining SLA level, monitoring …).

Specialized network service aimed to improve best-effort, i.e. no explicit SLA but improvement based on QoE (Quality of Experience) metrics. This solution may not be end to end.

A.7 Device Management (DM)

A.7.1 Smart Objects

The device management protocol brings the concept of a device centric approach. An endpoint, be it a WebRTC or M2M service endpoint, has its capabilities described as resources and attached to an endpoint identity. The LWM2M protocol inherits from using a CoAP well-known core design the support for discovery of the resources, subscription to new resources and the CRUD operations with semantics on the access control on a specific attribute (Read, Write, Execute).

Contextual information related to battery status, device manufacturer and model, current connectivity can be exchanged via the LWM2M protocol towards an entity that takes decisions in terms of networking and QoS or tries to extract intelligence from the acquired data. When operations for Create and Write are enabled, recommendations to change connectivity are also enabled.

It is considered that Internet of Things is based on Internet of Smart Objects that are exchanged in a dynamically way. More specifically, a well-known core using the Core Link Format concepts can be used as an aggregator with optimized access to different Resource Types that share the same prefix of the URI. Related to ReTHINK, a hyperty protocol or codec implementations can be modelled as Resources/Smart Objects. Part of the description (attributes) would relate to the capabilities (audio, video, text) and the platform it can run on (the OS version). Another part can be the container of the executable code/script. Recently the formalization of Software Management was added in which an end device can exchange and install software versions and components of a specific application.

All these aspects enable programmability and self-adaptation of the communication node. By having a dedicated management object for this purpose, access control is ensured.



A.7.2 OMA DM

OMA Device Management (DM) specifies the protocol and mechanisms that allows third parties to carry out procedures like configuring devices on behalf of end user. Using HTTP, the DM server sends specific DM commands to the DM client for retrieving or sending management data to/from the data repository. The sender should wait for response before sending another DM message. Although processing of DM message can consume unpredictable amount of time, OMA DM protocol doesn't specify any timeouts. Due to its dependency on HTTP as transport protocol, which is not efficient from the energy consumption prospective, OMA DM is not suitable for future networks that have the goal to lower the consumed power.

A.7.3 OMA LWM2M

Lightweight M2M (LW M2M) version 1.0 is a new technical standard for remote management of M2M devices. The architecture comprises a DM client residing on the M2M device, and a DM Server located on the M2M Service Provider or the Network Provider, as shown in Figure 56.

Figure 56. OMA LWM2M protocol

LWM2M protocol is not only suitable for complex and powerful computing devices, but also can handle constrained devices and work well in unreliable networks. The LWM2M client-server interaction is done using the underlying data transfer protocol over SMS or CoAP/UDP, which decreases the message overhead and enhances efficiency.

The DM message exchange is based on RESTful operations on resources bound to the devices and stored in local or remote well-known core, following the CoRE link format. The related resources are grouped together and handled by objects. The predefined set of objects includes Access Control, Connectivity Monitoring and Statistics, Device, Firmware Update and Location management. In order to extend the model, organizations can define and propose new objects that could be important for a robust device management platform. Objects under design are: Software Management, Connectivity Management, Lock&Wipe.

The LW M2M protocol defines four interfaces:

Bootstrap,

Client Registration,

Device Management

Service Enablement and Information Reporting.

The Client Registration interface includes three operations:



Registration,

Registration Update and

De-registration.

During the Registration the LW M2M client will include a unique Endpoint Client Name as well as the list of resources present at the LW M2M client in a Core Link Format.

The Device Management & Service Enablement interface is used by the LWM2M Server to access Object Instances and Resources available from the LWM2M Client to discover, create, read update, delete, and enforce execution.

The Information Reporting interface includes operations to subscribe, cancel observations and send notifications regarding resource changes.



Case Studies Annex B

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.

B.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 57 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 57. 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 58 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 58. Authentication and Service instantiation



Figure 59 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 59. Alice calls Bob Use Case



B.1.1 Registration with External Identity Use Case

This is logic flow of Service Registration use case (#84) for Variant B. In this use case, the service to be subscribed by the end-user and the Identity to be used in the subscription, are provided by different stakeholders.

Figure 60. Service Registration use case dynamic view

Step 1: Alice turns on the device and the runtime is started.

Step 2: Device Runtime requests the Identity to be used from the IdP.



Steps 3 to 5: Identity token is retrieved (Optional: URL to download the (hyperty) Identity URL is also retrieved).

Steps 6 - 8 (Optional): (hyperty) Identity + associated policies are deployed in the runtime.

Steps 9 - 15: Alice downloads and deploys the new App to be registered along with its associated hyperty, in the runtime.

Steps 16 - 17: the Service Provider hyperty (instance) is associated with Alice Identity provided by an external IdP.

Steps 18 and 19: Service Provider checks whether the IdP used by Alice is trustful.

Steps 23: In case Service Provider decides to trust on the IdP, it asks Alice Identity to get some Data needed for the registration.

Steps 24 - 29: Alice Identity will check local Identity Management policies to be applied on the requested Identity data. Assuming the policies enforce to have explicit consent from the user and that this consent is provided, the requested data is provided to Service Provider hyperty.

Steps 30 - 34: The Service Provider hyperty may request the user for additional specific data needed for the registration which is provided to the Service Provider along with the previously Alice Identity data.

B.1.2 User Login with External Identity

This is the High level view of Service Login variant with external Identity use case for its Variant. In this use case, Alice uses an Identity from an Identity Service Provider to login with a different Service Provider.

Figure 61. User Login with External Identity functional blocks

https://github.com/reTHINK-project/use-cases/issues/81



The detailed description of the main data flows are provided below:

Figure 62. User Login with External Identity Data Flows

Step 1: Alice turns on the device and the runtime is started

Steps 2 - 3: An identity is requested from the IdP but authentication is needed

Step 4 (Optional): Device Runtime downloads and deploys the Identity hyperty and associated protocolStub



Steps 5 - 7: (hyperty) Identity is authenticated with the IdP. Assuming the authentication is successful, an Identity token plus associated policies are retrieved and deployed in the runtime

Steps 8 - 17: Alice downloads and deploys the App along with its associated Service Provider hyperty and protocolStub, in the runtime

Steps 18: the Runtime selects the IdP Identity to be used by the Service Provider Identity

Steps 19 - 20: Runtime connects to the Service Provider Messaging Service with IdP token as credentials. The Messaging Service requests to login the user in the Service Provider domain with IdP token

Steps 21: Service Provider checks whether the token is valid.

Steps 22 - 23: In case the token is valid the login is successful, the user is connected to Service Provider domain through the Messaging Service and associated data and policies are retrieved.

Step 24: Runtime deploys Service Provider hyperty policies and SP hyperty is initialised and associated with IdP Identity

Steps 25 - 26: Service Provider hyperty instance is registered in the Service Provider Registry through the Messaging Service.

B.1.3 Inter-domain Conversation with different CSPs and IdPs (Detail)

This section details the message flows of the conversation setup of Alice and Bob with different CSPs and external IdPs Use Case (D1.1 UC #95). The high level view of H2H inter-domain Conversation with different CSPs and external IdPs is depicted in the Figure 63.

In this use case, Alice and Bob setup a Media stream communication (e.g. AV) each one using different CSPs and external IdPs. At Alice device there are the following features:

An hyperty representing Alice's Communication Service Provider that contains the service logic needed to handle H2H Communications: Alice Communicator hyperty.

Bob's Communicator Proxy, providing the means to reach Bob's Messaging Server through its protocol Stub according to ProtoFly concept. Two options:

Only Bob's Messaging Server protocol stub is used with no additional service logic provided by an hyperty Instance

an hyperty Instance representing Bob's CSP that runs on top of Bob's Messaging Server protocol stub.

Bob's P2P Communicator Proxy setups p2p communication with Bob's device if WebRTC Data Channel is supported and according to the level of control needed by the CSPs. Open Issue: Should it be an hyperty (is there any service logic to be executed?) or just protocol stub?

Alice Identity (an hyperty?) running in the Device initialized by Alice IDP as described in user login use case. The implementation of the Identity Management at user device is still an open issue.

Bob Identity Proxy representing and asserting Bob Identity in Alice's Device.

At Bob's device:

An hyperty representing Bob's Communication Service Provider that contains the service logic needed to handle H2H Communications: Bob Communicator hyperty.

A Protocol Stub to connect to Bob's CSP Messaging Server.

A Protocol Stub enabling P2P signalling with Bob's Device on top of the WebRTC Data Channel. Implementation notes: such protocol stub would handle a opened notification data channel dedicate to receive and handle P2P communication requests. Needed information to reach such notification channel (IP address, port, ICE candidates, etc.) is handled by Bob's CSP



https://github.com/reTHINK-project/architecture/blob/master/docs/dynamic-view/registration%20and%20login/UC81_User%20Login%20with%20external%20Id.md




Registry according to information published by the P2P Communicator hyperty. As soon as the P2P Communication request is accepted, a P2P Communication token is granted and a new data channel is created to support the new p2p connection between devices. P2P signalling could only be used in certain use cases where CSP does not need to fully control the communication.

Bob Identity hyperty (optional): an hyperty that represents the Bob Identity is running in the Device initialized by Bob IDP, as described in user login use case. This implementation of the Identity Management at user device is still an open issue.

Alice Identity Proxy (hyperty?) representing and asserting Alice Identity data (e.g. name, avatar) in Bob's Device (e.g. this data can be used when alerting Bob) initialized by Alice's IDP as described in discovery use case (missing): Alice Identity hyperty.

Figure 63. H2H inter-domain Conversation functional blocks

The detailed message flows are depicted in the next sections for:

Bob Discovery

Bob Invitation

Alice Identity Assertion and Invitation Accepted by Bob

Bob Identity Assertion and Communication setup completed




B.1.3.1 Bob’s Discovery

Figure 64. H2H inter-domain Conversation : Alice discover Bob

Steps 1 - 3: Alice invites Bob which is handled by Alice Communicator hyperty

Steps 4: Alice Communicator requests Bob's Identity Proxy to discover a compliant Bob Communicator.

Option1: Bob's IdP is hyperty enabled

Steps 5 - 11: Bob's Identity Proxy interacts with Bob's IdP Registry to discover Bob's CSP Registry to be completed.

Option2: Bob's IdP is not hyperty enabled

to be completed

Steps 12 - 14: Alice's Communicator interacts with Bob's CSP Registry to discover a compliant Bob's Communicator Proxy URL. According to the level of control required, two options:



1. Bob's Communicator Proxy to interact with Bob's CSP Messaging Server (more control on communication but more resources spent)

2. Bob's P2P Communicator Proxy to interact directly with Bob's Device on top of a Data Channel (less control on communication but less resources spent)

B.1.4 Invitation

There are two options to consider: the invitation may be performed through the core platform signalling server, or the invitation is initiated directly from the endpoint, as a pure peer-to-Peer fashion.

B.1.4.1 Signalling Server Invitation

Figure 65. H2H inter-domain Conversation : Alice invite Bob (Signalling Server)

Steps 1 - 3: Bob Communicator Proxy is downloaded and deployed in Alice's Device

Steps 4 - 10: Alice’s Communicator instantiates the communication object, to handle the communications between Alice and the Device, and to send a request, inviting Bob. The invitation request is forwarded to Bob's Proxy Communicator which delivers it to Bob's CSP Message Server. On receiving the invitation request, Bob's Message Server may interact with CSP Identity Management to request authorisation to route Alice Communication invitation message to Bob.

Steps 11 - 12: Invitation is forwarded to Bob's Communicator which creates the Communication Object to handle the incoming invitation.



B.1.4.2 P2P Signalling Invitation

Figure 66. H2H inter-domain Conversation : Alice invite Bob (P2P Signalling)

Steps 1 - 3: Bob P2P Communicator Proxy is downloaded and deployed in Alice's Device

Steps 4 - 7: Alice’s Communicator instantiates the communication object to handle the communications between Alice and the Device, and to send a request, inviting Bob. The invitation request is forwarded to Bob's P2P Communicator Proxy which directly delivers it to Bob's device communicator which creates the Communication Object to handle the incoming invitation.



B.1.5 Alice Identity Assertion and Invitation Accepted by Bob

Figure 67. H2H inter-domain Conversation: Alice Identity Asserted and Bob Accepts invitation

Steps 1 - 3: Alice's Identity Proxy is downloaded and deployed in Bob's device.

Steps 4 - 7: Alice's Identity Proxy is used to interact with Alice's IdP to assert Alice identity.

Steps 8 (Optional): Bob's Communicator interacts with Alice Identity hyperty to gather additional data from Alice e.g. Alice Avatar

Steps 9 - 12: Bob is alerted about Alice Invitation which is accepted.

Steps 13 - 14: The communication object is updated with Communication Resources (including SDP) and the Identity Token to be used to assert Bob Identity. Alice's side Communication objects is synchronised with messages exchanged between the two device either directly (P2P signalling) or through the Messaging Server.



B.1.6 Bob Identity Assertion and Communication Setup Completed

Figure 68. H2H inter-domain Conversation: Bob Identity Asserted and Communication Setup Completed

Steps 1 - 4: Alice's Communicator interacts with Bob's IdP to assert Bob identity through Bob's Identity Proxy.

Steps 5 - 6: Alice's communicator interactions with the runtime to set Resource description, including remote SDP.

At this point Alice and Bob have established media stream between both devices



B.2 M2M Case Studies

B.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 69. 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.




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



B.2.2 Device Authentication

Figure 70. 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

B.2.3 Device Registration

Figure 71. 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



B.2.4 Context Discovery

Figure 72. 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



B.2.5 PUB-SUB M2M Communication Setup

Figure 73. 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.

B.2.6 P2P M2M Communication Setup

Figure 74. 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]

Framework Architecture Definition Framewor… · The reTHINK Perspective (Chapter 5), reference...

Documents

Transcript of Framework Architecture Definition Framewor… · The reTHINK Perspective (Chapter 5), reference...