migration report - rethink project migration... · etc.). for gprs and lte: it establishes a...

Deliverable D6.2 645342 — reTHINK — H2020-ICT-2014

© reTHINK consortium 2017 of (37)

Deliverable D6.2

Migration Report

Editor: Ancuta Corici, Fraunhofer

Deliverable nature: R - Report

Dissemination level:(Confidentiality)

PU

Contractual delivery date:

30 April 2017

Actual delivery date: 15 May 2017

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

Version: 1.1

Total number of pages: 37

Keywords: IMS, reTHINK, architecture, AAA, migration path

Abstract

This report identifies and analyses the key requirements to enable the migration path from IMS to the reTHINK technology on the control level of Rich communication service sessions.

Detailed design of aspects required for enabling Rich communication services approached in reTHINK is provided in this document. The objective is to provide the specifications to be used in the implementation of migration path of the Telco infrastructures towards reTHINK supported services.

645342 — reTHINK — H2020-ICT-2014 Deliverable D6.2

of (37) © reTHINK consortium 2017

Disclaimer

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

All reTHINK consortium parties have agreed to full publication of this document.

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 programme 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: WP6

Number and title of task: T6.3 Interoperability and Migration

Document title: D6.2 Migration Report

Editor: Ancuta Corici, Fraunhofer

Work-package leader: Marc Emmelmann, Fraunhofer

Copyright notice

2017 Participants in project reTHINK

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

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

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



Executive summary

The reTHINK project describes a framework that provides solutions to manage real time communication capabilities, both human to human and machine to machine. This framework will integrate and react to contextual information in a secured and privacy respectful way while it intends to meet the requirements that are derived from Use Cases described in D1.1 [2]. Based on the service scenarios provided D5.1, the general architecture, data models and interfaces of the reTHINK framework provided in D2.1 and D2.2, the components described in D3.1 and 4.1, this document specifies the key requirements for enabling the migration path from Telco infrastructures like 3GPP IMS services and reTHINK technology and Rich Communication Services (RCS).

The first chapter introduces the objectives of the interoperability between the reTHINK framework and IMS.

The second chapter provides a detailed description of both IMS and reTHINK technologies, ending with a comparison between then, in order to be able to design the general solution presented in chapter 3.

Chapter 4 gives guidelines on the migration path to be taken in order to achieve the interoperability for the selected Rich Communication Services. Chapter 5 gives information on the general solution validation on a testbed shared between the reTHINK partners.



List of authors

Company Author

DTAG Steffen Druesedow

Fraunhofer Andreea Ancuta Corici

Marc Emmelmann

Robert Ende

Paul Zuehlcke

Apizee Arnaud Vallee

Jamal Boulmal

Quobis Anton Roman Portabales

Yudani Riobo

David Vilchez



Table of Contents

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

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

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

Abbreviations .......................................................................................................................................... 7

1 Introduction ..................................................................................................................................... 8

1.1 Objective of this document ..................................................................................................... 8

1.2 Methodology ........................................................................................................................... 8

2 Technology Analysis ........................................................................................................................ 9

2.1 IMS ........................................................................................................................................... 9

2.1.1 Architecture Overview .................................................................................................... 9

2.1.2 Communication Services ............................................................................................... 11

2.1.2.1 IMS Registration ........................................................................................................ 11

2.1.2.2 Service: IMS Call ........................................................................................................ 11

2.1.2.3 Service: IMS Chat ....................................................................................................... 12

2.1.2.4 Location Services ....................................................................................................... 13

2.2 reTHINK ................................................................................................................................. 13

2.2.1 Architecture Overview .................................................................................................. 13

2.2.2 Communication Services ............................................................................................... 15

2.2.2.1 Scenarios ................................................................................................................... 17

2.2.2.2 Group Chat Hyperty ................................................................................................... 18

2.2.2.3 Location Hyperty ....................................................................................................... 18

2.2.2.4 Connector Hyperty .................................................................................................... 18

2.2.2.5 Group Call Hyperty .................................................................................................... 18

2.3 Technology Comparison ........................................................................................................ 19

2.3.1 Scope and approach of the Comparison ....................................................................... 19

2.3.2 Functional requirements ............................................................................................... 19

2.3.2.1 Common hyperty requirements ................................................................................ 19

2.3.2.2 Hyperty specific requirements .................................................................................. 20

2.3.2.3 Summary of functional requirements ....................................................................... 20

2.3.3 Identification of functional blocks and reTHINK/IMS equivalents ................................ 21

2.3.4 Identification of functional gaps and adaptation requirements ................................... 22

2.3.4.1 Identity- and Address- formats ................................................................................. 22

2.3.4.2 Authentication ........................................................................................................... 22

2.3.4.3 Discovery ................................................................................................................... 22



2.3.4.4 Syncher framework and support for different data-object schemes........................ 22

2.3.4.5 WebRTC media support............................................................................................. 22

3 General Solution Design ................................................................................................................ 23

3.1 Architecture ........................................................................................................................... 23

3.2 reTHINK originating service, IMS terminating service ........................................................... 24

3.2.1 Message Flow ................................................................................................................ 24

3.2.2 reTHINK Nodes .............................................................................................................. 24

3.2.2.1 High level implementation description ..................................................................... 26

3.2.2.2 Authentication scheme ............................................................................................. 26

3.2.3 IMS Nodes ..................................................................................................................... 27

3.3 IMS originating service, reTHINK terminating service ........................................................... 27

3.3.1 Message Flow ................................................................................................................ 28

3.3.2 IMS Nodes ..................................................................................................................... 28

3.3.3 reTHINK Nodes .............................................................................................................. 28

3.3.3.1 High level implementation description ..................................................................... 29

4 Service Migration Path .................................................................................................................. 30

4.1 IMS-reTHINK .......................................................................................................................... 30

4.1.1 Rich Communication Service: Audio/Video Call ............................................................ 30

4.1.1.1 Architecture ............................................................................................................... 30

4.1.1.2 Message Flows .......................................................................................................... 31

4.1.1.3 Possible Migration Stages ......................................................................................... 31

4.1.2 Rich Communication Service: Chat ............................................................................... 31

4.1.2.1 Architecture ............................................................................................................... 31

4.1.2.2 Message Flows .......................................................................................................... 32

4.1.2.3 Possible Migration Stages ......................................................................................... 32

5 Architecture Validation ................................................................................................................. 33

5.1 Setup...................................................................................................................................... 33

5.1.1 Identity Management .................................................................................................... 33

5.1.2 PSTN Interworking ......................................................................................................... 33

5.2 Results ................................................................................................................................... 33

5.2.1 reTHINK initiated call, IMS terminating call .................................................................. 33

5.2.2 IMS initiated call, reTHINK terminating call .................................................................. 34

6 Conclusion ..................................................................................................................................... 36

References ............................................................................................................................................. 37



Abbreviations

AAA Authentication, Authorization and Accounting

API Application Programming Interface

AS Application Server

CSP Communication service provider

CSCF Call Session Control Function

UE User Equipment

H2H Human to Human communication

HTTP Hypertext Transfer Protocol

HSS Home Subscriber Server

ICE Information and Content Exchange

IdP Identity Provider

IMS IP Multimedia Subsystem

I-CSCF Interrogating Call State Control Function

P-CSCF Proxy Call State Control Function

PIDF Presence Information Data Format

RCS Rich Communication Services

REST Representational State Transfer

RTP Real Time Protocol

RTCP Real Time Control Protocol

SCIM System for Cross-domain Identity Management

S-CSCF Serving Call State Control Function

SIP Session Initiation Protocol

SDP Session Description Protocol

STUN Session Traversal Utilities for NAT

TURN Traversal Using Relay NAT

UML Unified Modeling Language

URL Uniform Resource Locator

W3C World Wide Web Consortium

WebRTC Web Real-Time Communication



1 Introduction

1.1 Objective of this document

This document aims to provide the design of the migration path that IMS and reTHINK infrastructures have to undergo in order to be interoperable in the sense that an IMS User Endpoint can consume reTHINK services and the other way round. Based on the services scenarios described in D5.1 "Service Scenarios Specification"[6], this document describes a technology migration path for communication services (Comm. Services), as the key services that are deployed on Operator Core Network infrastructures targeted to be interoperable with the reTHINK Framework (see Figure 1).

1.2 Methodology

In order to achieve the objective of this document the applied methodology was:

Comparison of the architecture, enabled services from 3GPP IMS and reTHINK technology and identification of the key functional elements. As a result the equivalent of the functional elements in both the architectures are analyzed.

Identification of fundamental system migration requirements and design general solutions of migration in order to enable the services.

Theoretical validation of the solutions for each selected service.

Practical evaluation for a selected service.

Figure 1: Overview of Operator Services



2 Technology Analysis

In this section, both IP Multimedia Subsystem and reTHINK are analyzed from the technology point of view, comprised of architecture and enabled services, so that a general solution for the interoperability between the two of them can take place on the common services.

2.1 IMS

The IMS Core provides session signalling based on Session Initiation Protocol (SIP) [3] and AAA capabilities based on Diameter protocols [4].

IMS control and content Application Servers (AS) can be dynamically connected to IMS Core for processing the signalling to initiate, modify and terminate sessions.

2.1.1 Architecture Overview

The IMS is an Overlay Session/Service Control Architecture on top of the Packet domain based on IP technologies and protocols (Figure 2). The signalling at the IMS Core is managed by four types of server S-CSCF (Serving Call Session Control Function) which the IMS anchor point in the home network which also is in charge of registering the UEs. The I-CSCF (Interrogating Call Session Control Function) provides topology hiding; the P-CSCF (Proxy Call Session Control Function) is the entry point into the IMS network and the Application Servers (AS) which add the capability to build new and different services to the network. Regarding the media the main server roles are the MRF (Media Resource Function), which is a Media Server hosting special resources and the MGCF (Media Gateway Control Function) for interworking with the legacy networks.

The PCC (Policy Charging & Control) servers enable the integration of QoS Control and provides charging capabilities to the IMS Application Layer. The HSS (Home Subscriber System) is a Database with a Diameter interface which maintains subscriber and AS profiles (Application Server Function) for specific applications or enabling services.

The main protocols used to implement IMS are the IETF standards Session Initiation Protocol (SIP) and Diameter (see Figure 3).

The building blocks of the IMS communication services are:

User Endpoint (UE): may contain s sim card for authentication, public and private user ids, User Network address, Security algorithms and keys. The UE Contains: the IMS client and may contain additional IMS enabler client software. The UE provides for the media transport the protocols along with various media codecs (audio, video, etc.). From the connectivity

Figure 2: IMS Functional Overview



point of view, the UE may support different bearer networks (UMTS, WLAN, WiMAX, LTE etc.). For GPRS and LTE: it establishes a context for Signalling (either dedicated or a general one), so that the Media transport is correlated between session control and QoS reservation on the underlying core network.

Call Session Control Functions (CSCFs) are SIP servers. The functionalities expand over: o SIP Call set-up/termination and state/event management o Address Analysis, translation, modification if required, address portability, mapping

of alias addresses o Interaction with HSS in the home domain to receive profile information for the user o Provision of access to application servers through filter mechanisms o Interaction with MRF in order to support multi-party calls and other services

The three main types of CSCF exist: Proxy, Interrogating and Serving – CSCFs (see Figure 4).

Home Subscriber Server (HSS): maintains subscription information about the users, including the:

o user profile information indicating private and public identities of the user o authentication information (credentials and algorithm) o services and medias the user is eligible for using filtering criteria for choosing

appropriate AS

The HSS acts as Diameter server by connecting:

Through Cx interface to S-CSCF and I-CSCF. In relationship with the registration, the HSS assists the I-CSCF in choosing the appropriate S-CSCF, downloads user profile upon registration into S-CSCF and stores actual S-CSCF per user

Figure 3: IMS Functional Architecture

Figure 4: IMS CSCFs



Through Sh interface to the Application Server (AS) through Sh interface. The HSS can act as a data store for AS and can inform AS about user changes

2.1.2 Communication Services

2.1.2.1 IMS Registration

During the registration procedure, the user will be authenticated accordingly to the authentication algorithm specified in the initial registration message. The I-CSCF and S-CSCF interface with the Home Subscriber Server on the Cx Diameter interface for authenticating the access. When the user is allowed, the association between his IMS Identity and the current IP and port will be stored at the P-CSCF and S-CSCF, as these components are receiving UE originating, other UEs or IMS-AS terminating services (see Figure 5).

Required functionalities

In the table below we briefly describe the functionality required for Registration and the components used for that feature.

Functionality IMS Components Protocol (if the case)

Comments

IMS SIP Registration message processing

P-CSCF, I-CSCF, S-CSCF

SIP

User Authentication I-CSCF, S-CSCF, HSS Diameter

IMS Registration association storing P-CSCF, S-CSCF -

2.1.2.2 Service: IMS Call

For an IMS Call, in the most general case, the caller and the callee are registered to two different IMS providers. The Rich Communication session is established using SIP signaling from the caller, through the S-CSCF of its home IMS provider and then through the S-CSCF of the home IMS provider of the called party, reaching the called party device (see Figure 6).

Figure 5: IMS Registration message flow



The message flow is described in Figure 7.

Required functionalities

In the table below we briefly describe the functionality required for IMS Calls and the components used for that feature.

Functionality IMS Components Protocol (if the case)

Comments

IMS SIP Signalling P-CSCF, I-CSCF, S-CSCF SIP

IMS Call dialog state storing

P-CSCF, S-CSCF -

Media content forwarding

User A, User B, Any other media server from one or both the IMS infrastructure

RTP

2.1.2.3 Service: IMS Chat

In the case of the IMS Chat, the functionality is similar to the one of the IMS call, but in this case, the media is not audio/video, but text. The protocol used to exchange messaging is MSRP (Figure 8).

Figure 6: IMS Call overview

Figure 7: IMS call session message flow



2.1.2.4 Location Services

Location in IMS is conveyed in a Presence Information Data Format Location Object (PIDF-LO) in the SIP body and processed at the Emergency-CSCF (E-CSCF) in the case of Emergency Services [5] or at the Application Server (AS) in the case of non-emergency services.

2.2 reTHINK

2.2.1 Architecture Overview

reTHINK is a framework that provides solutions to manage real time communication (human to human and machine to machine). The framework integrates and reacts to contextual information in a secured way while respecting privacy. To achieve this, the reTHINK framework solution involves the creation of dynamic web-based services 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.

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 (see Figure 9).

The functional architecture describes the functions and services that the reTHINK project addresses. The functional descriptions of the architecture components are given in the figure below. 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.

Figure 8: IMS chat session message flow



The building blocks of the functional architecture were defined in deliverable D2.1 [7] and are depicted in Figure 10:

Messaging Services: provide real time message oriented communication functionalities used by user services to communicate (Message Routing). They provide different communication patterns including publish/subscribe communication. 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, credentials are 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 signaling 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).

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 further user, 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 kinds 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.

Figure 9: reTHINK Framework Overview



The Catalogue is the functional element that lists the services available for a 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. 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, interfaces and the executable code. 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).

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.

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

2.2.2 Communication Services

The reTHINK architectural functions are based on a series of 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.

Hyperties cooperate with each other through a Resource Oriented Messaging model implemented by a simple Messaging Framework. The Hyperty Messaging Framework, supports different messaging patterns including publish/subscribe and request/response messaging patterns. The higher level Reporter - Observer communication pattern works on top of these basic messaging patterns The Message delivery is based on a simple message Router functionality that performs a lookup for



listeners registered to receive the Message (the "Message.to" Header field is the only information looked up for). The Message is posted to all found listeners, which can be other Routers or end-points (Hyperties). Thus, the Hyperty Messaging Framework is comprised by a network of Routers where each Router only knows adjacent registered Routers or end-points.

The Messaging Framework works at three layers: At the Runtime Sandbox level where Hyperties are executing, message delivery is provided by the MiniBUS component. At the Runtime level where Sandboxes are hosted (e.g. in a Browser or in a NodeJS instance), message delivery is provided by the Message BUS component, which is an extension of the MiniBUS.

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

Figure 10: reTHINK Functional Architecture



Message Nodes are protocol agnostic. This also means that the Message Node can be provided by any Messaging solution as soon as there is a Protostub available. Currently, a Vertx Message Node, a Matrix Message Node and a NodeJS Message Node are provided.

Hyperties cooperate with each other through a Data Synchronisation model called Reporter - Observer. Hyperty Reporter - Observer communication pattern is using a P2P Synchronisation solution for JSON Data Objects, here called Hyperty Data Object or Sync Data Object. To avoid concurrency inconsistencies among peers, only one peer has granted writing permissions in the Hyperty Data Object - the Reporter hyperty - and all the other Hyperty instances only have permissions to read the Hyperty Data Object - the Observer hyperty. Through very simple APIs, Hyperties can create Synchronized Data Object or subscribe to them.

2.2.2.1 Scenarios

D1.1 [2] and D5.1 [6] provides a complete collection of service scenarios around the topic “Smart Cities and Smart Enterprises”. The list of scenarios can be found in Table 1:

Table 1: reTHINK Service and their Hyperties

reTHINK Service Scenarios

Hyperties Functional Requirements

Smart Contextual Assistance

MyContext Hyperty

MyContacts Hyperty

Chat and Group Chat Hyperty

Human Presence Hyperty

Group Call Hyperty

Authorization

Human Discovery & Presence

Machine / Object Discovery

Trust calculation / evaluation

Chat and Group Chat

File Sharing

Enterprise Conversational

Group Call Hyperty

Group chat Hyperty

MyContacts Hyperty

Human/Enterprise Discovery

Group Audio / Video call

Chat and Group Chat

Trust (IdP server)

File Sharing

Screen Sharing

My City Group Chat Hyperty

Notification Hyperty

Location Hyperty

Notifications

Group chat

Participants by location

Survey participation

Hotel Guest Application (M2M)

Hotel Connectivity Hyperty

Room Monitor Hyperty

Control Hyperty

Authentication

Authorization

Monitoring sensing and actuating of devices

Overriding capabilities of administrator over the guest settings

Tourism in a Smart City Connector Hyperty

Peer-to-Peer Data Transfer Hyperty

Address Book

Audio Call

Group Message

Peer-to-Peer Data Transfer



Neighbourhood Connector Hyperty

Group Chat Hyperty

Group Call Hyperty

Location Hyperty

Presence Hyperty

Contact Hyperty

Discovery Hyperty

Catalogue server

Discovery service

Global Registry

Graph-Connector (address book)

Notification service for incoming messages

Group Audio / Video call

Trust engine to check ID token, sent with the call invitation

As illustrated in the table above. All these services have in common the following set of Hyperties: Group Chat Hyperty, Connector(Audio/Video) Call Hyperty, Location Hyperty. We will focus on these most common hyperties in order to compare the IMS and reTHINK functionalities.

2.2.2.2 Group Chat Hyperty

The Group Chat main functionality is to handle Text conversations among groups, including:

Creation of a new Group Chat with possibility to invite users to join it

Notification about invitation to join a Group Chat with options to accept or reject

Send message to group

Receive message from group with identity from sender

2.2.2.3 Location Hyperty

The Location Hyperty main functionality is to collect geolocation data from a device, publish it to a certain Context Resource URL allocated by the Hyperty Runtime and notifying the App about context changes.

2.2.2.4 Connector Hyperty

The Connector Hyperty main functionality is to handle two party audio and voice conversations by using WebRTC technology.

2.2.2.5 Group Call Hyperty

Also called Multiparty WebRTC Communication Hyperty. This Hyperty enables WebRTC conferences in reTHINK. This hyperty is made of two types of hyperties for Client and Server. The client hyperty (called Peer Conference Hyperty in D3.5 [8]) executed on reTHINK runtime browser. Besides, a server hyperty (called Conference Hyperty in D3.5 [8]) loaded and executed on reTHINK Runtime Node.

Figure 11: reTHINK Hyperties interactions



2.3 Technology Comparison

2.3.1 Scope and approach of the Comparison

This comparision is based on the provided and required functionality of the hyperties that have been identitified in the previous chapter. The starting point of this comparision is reTHINK-biased - its initial viewpoint is the reTHINK side - and might therefore leave out IMS features that are not necessary to fulfill the requirements that are identified here.

The next sections will analyse and cluster the functionalities that are required to make the selected hyperties work and derive functional requirements from that. Based on the technology analysis in sections 2.1 and 2.2, functional blocks in both architectures – reTHINK as well as IMS – are identified and assigned to the functional requirements.

The last step is an identification of potential functional gaps resulting from the comparison of the functional equivalents from both technologies as topics of special interest for the architecture solution.

2.3.2 Functional requirements

The functional requirements are derived from the identified core hyperties, that are common to most of the scenarios – as identified in §2.3.

2.3.2.1 Common hyperty requirements

A lot of the functional requirements are common to all of the identified hyperties. This is caused by the design concept of the hyperty framework. Hyperties shall be able to focus on their business task and therefore depend on a number of framework capabilities. The main capabilities that Hyperties rely on are listed in the following table as common functional requirements.

Table 2 : Common functional requirements of Hyperties

No. Functional requirement

Remarks

F1 Authentication, (identity assignment)

Each hyperty is operated on behalf of a user-/entity- identity and must have an authenticated identity assigned during its whole life-time.

F2 Authorization There must be a mechanism to control and enforce the permissions of an authenticated hyperty.

F3 Unique address Each hyperty must be addressable by a unique address across domains.

F4 Discovery mechanism

In order to allow exchange of messages between hyperties with independent life-cycles it is crucial to have a discovery mechanism that provides just-in-time addresses of potential peer hyperties, based on given filter criteria.

F5 Data Synchronisation framework

Each hyperty operates on at least one data object in either reporter- or observer- role. The hyperties rely on a framework that detects data-object changes and forwards them and notifies subscribed peer hyperties.

F6 Subscription mechanism

Hyperties must be able to subscribe for remote data-objects.

F7 Messaging framework

The Data Synchronisation framework requires a mechanism to send and receive messages to and from other addressable hyperties.



2.3.2.2 Hyperty specific requirements

These requirements are derived from the special functionalities of the selected hyperties.

Table 3: Functional requirements of selected hyperties

Hyperty Functional requirements Remarks

Chat Hyperty Support for Message exchange according to the “comm” data-scheme.

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

Group Chat Hyperty

Support for Message exchange according to the “comm” data-scheme.


Location Hyperty

Support for Message exchange according to the “context” data-scheme.

Mechanism to gather location information.

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

Connector Hyperty (WebRTC)

Support for Message exchange according to the “connection” data-scheme.

SDP based media description

DTLS/S-RTP based media transport

2.3.2.3 Summary of functional requirements

This is the merged list of the common and hyperty-specific functional requirements.

Table 4: Summarized functional requirements

No. Functional requirement

F1 Authentication

F2 Authorization

F3 Unique address

F4 Discovery mechanism

F5 Data Synchronisation framework

F6 Subscription mechanism

F7 Messaging framework

F8 Support for Message exchange according to the “comm” data-scheme.

F9 Support for Message exchange according to the “context” data-scheme.

F10 Support for Message exchange according to the “connection” data-scheme.

F11 Mechanism to access location information.









F12 SDP based media description.

F13 DTLS-SRTP based media transport

2.3.3 Identification of functional blocks and reTHINK/IMS equivalents

This chapter will provide an overview of the identified functional blocks for each functional requirement in the reTHINK and IMS architectures. A deeper description of the functionalities in each domain is not in the scope of this section.

Requirement reTHINK IMS

F1: Authentication IDM, IDP-proxies, 3rd party IDPs, token based (adapted from WebRTC standard)

eP-CSCF (P-CSCF enhanced for WebRTC) I-CSCF, S-CSCF, HSS (SIP-register, diameter)

F2: Authorization Policy-engine S-CSCF (?)

F3: Unique address Messaging Node (MN) HSS (SIP-Identity, private and public)

F4: Discovery mechanism

Domain Registry, Global registry, Global discovery service

This mechanism includes implicit presence information, since only “live” hyperties are discovered.

DHCP/DNS discovery of P-CSCF

IMS Presence Service using SIMPLE protocol

F5: Data Synchronisation framework

Syncher component No equivalent

F6: Subscription Mechanism

MiniBus, Message Bus, MN IMS subscribe/publish mechanism

F7: Messaging Framework

MiniBus, Message Bus, MN, Protocol Stubs

P-CSCF, I-CSCF, S-CSCF MSRP messages in the scope of a SIP session.

F8 – F10: support for different data-schemes

Hyperty specific logic No equivalent → Application specific

F11: Location data GeoLocation API in the browser Server side: Location Retrieval Function (LRF) as part of Emergency session.

Client side: PIDF-Location Object, processed at Emergency-CSCF or at an Application Server

F12: SDP support WebRTC engine in the browser Integral part of IMS/SIP signalling.

F13: DTLS-SRTP support

WebRTC engine in the browser eIMS-AGW (IMS Accesss gateway enhanced for WebRTC)



2.3.4 Identification of functional gaps and adaptation requirements

2.3.4.1 Identity- and Address- formats

reTHINK and IMS are using different formats for identities and addresses. A mapping or translation mechanism must be applied to be able to use the identities and entity-addresses from the other technology in the own scope.

2.3.4.2 Authentication

The original IMS authentication mechanisms are not directly compatible with the WebRTC token based mechanism that is adopted in reTHINK. This can be addressed by using an enhanced P-CSCF with support for web-credentials. This enhancement should include a service which exposes a Web-friendly API to get credentials/tokens to perform the authentication against the IMS core from the reTHINK runtime.

2.3.4.3 Discovery

The reTHINK discovery mechanism is used to search and find “live” instances of hyperties as potential communication peers.

The IMS discovery mechanism instead uses a DNS mechanism in order to find the responsible PCSCF for a certain SIP-identity. This will just return the first contact point for a signaling exchange with the IMS domain, but does not include any information about the current presence of the real communication endpoint, i.e. a running and registered IMS client application or phone.

In order to receive also such presence information, the IMS discovery shall be combined with a presence subscription and a presence mechanism on the IMS side (e.g. UA- or server based).

2.3.4.4 Syncher framework and support for different data-object schemes

The reTHINK data synchronization framework in combination with the defined data-object schemes does not have a direct counterpart in IMS.

Therefore the synchronization concept shall be realized outside of the IMS, in a component that detects changes in the corresponding reTHINK data-object and performs a translation to suitable SIP/IMS messages and vice-versa. An example would be a component that detects changes in a “communication” data-scheme from a reTHINK chat application and translates it to a MSRP message for an IMS based chat (and vice-versa).

A logical candidate for such an interworking component would be a protocol stub, that connects a reTHINK chat to an MSRP based IMS chat.

Each of these interworking stubs would provide support for one or more data-schemes (i.e. “application types”).

2.3.4.5 WebRTC media support

In order to support WebRTC media in terms of protocols (SRTP, DTLS) and also of media codecs (e.g. VP8) an IMS Access gateway enhanced for WebRTC (eIMS-AGW) can be used on the IMS side. Such components provide the required support for the establishment of the Secure RTP channels as well as for potentially necessary media conversions.



3 General Solution Design

3.1 Architecture

The present chapter presents a proposal to achieve interoperability between reTHINK and IMS networks. It can be considered as an intermediate step between the existing networks and a fully reTHINK-based system.

As stated in previous chapter WebRTC is the standard chosen for media sessions in reTHINK. One of the references for the proposal has been the architecture defined by the 3GPP for interoperability between IMS and WebRTC (see Figure 12).

The functional components included in the 3GPP architecture are:

WIC = WebRTC IMS Client.

IMS UE with native WebRTC client or WebRTC enabled browser

WWSF = WebRTC Web Server Function

HTTP server for WebRTC IMS Client code

eP-CSCF = P-CSCF enhanced for WebRTC , SIPoverWebSocket (SIPoWS)/XMPP/REST/JSON-RPC enabled P-CSCF

IMS-ALG = IMS Access GateWay enhanced for WebRTC

IMS Media interop node supporting SRTP/DTLS

WAF = WebRTC Authorization Function provides authentication tokens to WWSDF

By adapting the above architecture to the case of reTHINK and IMS, the result can be seen in Figure 13. In this case, the communication parties, Alice and Bob are from reTHINK and IMS worlds respectively. Alice is using as a WebRTC Client (WIC) an Interworking Stub (IWstub) inside a Hyperty running on the reTHINK runtime and calling Bob using SIP over Websockets (SIPoWS). The IMS P-CSCF holds a module to translate the WebRTC signaling. WAF (WebRTC Authorization Function) is an Authentication Server, an Identity Provider that generates a token for the IWstub. The token is included in the SIPoWS Invite message and when it reaches the enhanced P-CSCF (eP-CSCF), the eP-CSCF will validate the token and forward the call to an IMS client or even to PBX clients.

At the same time, the eP-CSCF will generate a new temporary identity for Alice so that messages to Bob get the From header populated with the generated identity.

Figure 12: 3GPP IMS-WebRTC interoperability architecture



3.2 reTHINK originating service, IMS terminating service

In the case of interoperability when reTHINK user initiate the call and an IMS client receives the call, the IMS P-CSCF will validate the token and generate an temporary/ephemeral ID (see Figure 14).

3.2.1 Message Flow

Figure 14: reTHINK-IMS authentication diagram flow

3.2.2 reTHINK Nodes

In order to interconnect an IMS and the reTHINK framework a new element has been introduced in the architecture: the IMSStub. The IMSStub enables the interaction with IMS networks by exchanging SIP over Websocket (RFC7118) traffic between a hyperty executed in the runtime and the IMS core. Other signaling alternatives different from SIP over WS could be used to exchange the signalling

Figure 13: reTHINK-IMS interoperability



between the IMSStub and the IMS gateway element, however this approach has been followed to avoid introducing non-standard protocols.

To implement this approach the IMS core has been simulated with a Kamailio instance (the reference Open Source SIP soft switch) and FreeSwitch (an Open Source Media Server) to be able to interact with legacy networks. Kamailio simulates the whole IMS core and can receive SIP over Websocket traffic and performs the routing and identity validation tasks in combination with some new services designed for this integration.

The reTHINK framework has been designed to run in browsers and other devices which can run ECMAScript 6 code. The browsers can only use Websocket as transport protocol for SIP as it is not possible to use either HTTP nor UDP/TCP.

The function of the Media Server is the inter-working between the media with WebRTC profile received from the browser and regular RTP media used in the IMS core. So in our implementation Kamailio will do the interworking between SIP over Websocket and regular SIP for IMS, and the Media Server will carry out the interworking at media level.

The diagram from Figure 15 depicts a high level diagram showing the different elements involved. The reTHINK box includes the elements executed within the reTHINK runtime core. The browser box includes the RTCPeerConnection and the MediaStream which are both part of the native WebRTC API.

The role of the Hyperty is to create a WebRTC PeerConnection with a WebRTC capable browser. The IMSStub is the protocol stub which interacts with the hyperty and the IMS core. The Stub is a core reTHINK element used to abstract the communication between hyperties using the Data Synchronization paradigm and the different types of Message nodes which can be implemented with the reTHINK framework. Please note that three different technologies have been used to implement the Message Node within the scope of the project and other technologies can be added in the future. This is possible thanks to the ProtoStub element. This concept has been also adopted to interact with legacy systems.

The IMSStub exchanges information (mainly the remote and local SDPs used to establish the media connection) with the Connector Hyperty using a synchronized DataObject following the reTHINK common practices. The IMSStub implements SIP over Websocket with the IMS core.

Figure 15 High Level reTHINK-IMS authentication model



3.2.2.1 High level implementation description

The Connector Hyperty gets the SDP from the WebRTC API, and the Data Object synchronized with the IMSStub is updated. Then the IMSStub gets the new SDP and creates an INVITE message and sends it to the IMS core (Kamailio). The IMS core sends the INVITE to the end destination and sends back to the IMSStub a 200OK with an attached SDP. This SDP is received by the IMSStub and sent to the Hyperty connector which calls the WebRTC API and the PeerConnection between the browser and the ISM core (the media server). To finish the call either side can send a BYE message and the call gets finalized both at signaling and PeerConnection levels.

3.2.2.2 Authentication scheme

A strategy based on ephemeral credentials has been used to register reTHINK users in the IMS core. The validation of the identity of the caller is done by a Web Service which must be provided by the operator.

The IMSStub sends an identity assertion to the Webservice, which checks against the IdP that the user is who she claims to be Figure 16. Once the identity has been validated by the IdP, the Webservice checks if the identity is bound to any existing IMS user and if not an ephemeral user is assigned (this is the default behaviour in the current implementation). The ephemeral (or pre-assigned) IMS credentials are sent to the IMSStub and it starts a standard SIP registration process against the IMS core. The IMSstub performs a regular digest authentication and it gets registered in the IMS core. From that point the IMSStub can make and receive calls from the IMS core just like any other UE.

Please note that in the diagram Google is used as identity provider, but the architecture is compatible with any other IdP. The ProtoStub concept has also been successfully used in reTHINK to be able to interact with different IdPs.

Figure 16: Authentication mechanism for reTHINK calling users



3.2.3 IMS Nodes

In the current solution, the P-CSCF component of the IMS Server contains a hash table that maps a real identity to its (latest) ephemeral identity. In case of an incoming registration with an ephemeral identity, the P-CSCF component allows registration and maps the ephemeral identity to the real identity. If the same user registers with the same real identity, but a newer ephemeral identity, the entry in the hash table is updated and the registration with the older ephemeral identity is considered invalid.

After registration with the ephemeral identity, the reTHINK framework is handled like any other user registered at the IMS Server, and the call setup is handled accordingly.

An alternative solution for secure communication is to use an IMS service that generates an IMS identity mapped to a reTHINK supported identity, in order to be able to track calls and other services usage.

This service could be implemented in compliance with the “System for Cross-domain Identity Management” (SCIM) protocol specification [11].

The SCIM protocol specification seeks to manage user identities in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability. It intends to reduce the cost and complexity of user management operations by providing a common user schema and extension model.

Specifically, a SCIM REST server can be used to assign or create an IMS identity to a reTHINK supported identity and provisions the identities in the Home Subscriber Server (HSS).

3.3 IMS originating service, reTHINK terminating service

In the case of an IMS client initiating the call and the reTHINK client receiving it, the eP-CSCF from the IMS Server/Core has to map the ephemeral Identity to the websocket that pertains to the reTHINK client (Figure 17).



3.3.1 Message Flow

Figure 17: Message flow when the call is initiated by IMS client and terminated by reTHINK client

3.3.2 IMS Nodes

The P-CSCF component of the IMS Server contains a hash table that maps a real identity to its (latest) ephemeral identity. On arrival of any SIP request at the IMS Server, the target identity is looked up in the hash table of the P-CSCF component. In case of a match, the SIP request is forwarded to the reTHINK framework that is currently registered as the ephemeral identity. Besides the resolution of real identity to ephemeral identity, any SIP request and call setup is handled as usual.

In the case of using dynamic identity provisioning based on protocols like SCIM, the identity of the reTHINK user would be already known by the IMS and the solution does not need a hash table in the P-CSCF for routing the call to the WebRTC Hyperty endpoint.

3.3.3 reTHINK Nodes

In order to enable the interconnection with the IMS network the main element introduced in the reTHINK framework is the IMSStub. This concept has not only be adopted for this specific integration but also has been used to integrate reTHINK with other legacy networks such as Slack [10]. This mechanism for integration with legacy networks has been described in [9].

The Hyperty Connector is used by applications which require to make real-time media calls. The same hyperty which normally uses a Protostub to be able to synchronize the SDP data with other connectors Hyperties has been used to implement this IMS interconnection.

To achieve this the same synchronization mechanism has been implemented in the IMSStub, so that the SDP which is received via SIP messages appears as new data synchronized to the Hyperty.



3.3.3.1 High level implementation description

In this case the IMS sends an INVITE to the IMSstub, the attached SDP is sent to the Connector Hyperty. It sets the SDP in the WebRTC API and gets a local SDP which is sent to the IMSStub. The IMSStub creates a 200 OK with attached SDP and sends it to the IMS core. From that point on the call flow is identical as for an outgoing call.

For incoming calls a hash table has been implemented to bind the identity of the IMS subscriber with the ephemeral credentials used to register the reTHINK user into the IMS core. Please note that the use of ephemeral credentials can be easily substituted with other identity schemes.



4 Service Migration Path

Rich Communication Services (RCS) technologies provide a comprehensive suite of enablers including:

one to one and group chat and file transfer,

best effort voice and video calls, including the ability to provide context for the call (such as setting up a subject for the call, or sharing a document or picture before the call) and

multi-device experience, with full messages synchronization.

The standard is built in such a way that carriers can add differentiation features, but the following will focus on the baseline offering.

Some services are deliberately left out of the standard, they are key elements for a good user experience but they are understood to be provided by existing platforms in carrier networks or independent services. Two of those enablers critical for a web-based service are Network Address Book, and File Storage. Delivering a RCS experience in a web-based endpoint includes addressing these two on top of RCS proper.

A web-based endpoint does not usually have access to a native address book, and user expectation in many cases is for a seamless, multi-device experience, where the same contacts are shared between all devices and access modes: smartphone (where user might have cloud-based address book in addition to the one provided by the device and contacts stored in the SIM); non-cellular / WiFi tablet; web access.

Similarly, there’s a strong market expectation for seamless access to files sent and received through the service, regardless of the device and access used, requiring cloud-based, secure storage, and the required interfaces and services needed for that.

The address book is the main entry point for RCS, as it is for many chat-based applications in the market today, so a polished user experience on this area is a must for a service migration to succeed.: Synchronization (or lack of) between existing address books; defining which of them act as the master; and, most importantly, explain very clearly to the user what’s going on.

4.1 IMS-reTHINK

4.1.1 Rich Communication Service: Audio/Video Call

4.1.1.1 Architecture

RCS provides best effort audio and video call leveraging existing IMS-based infrastructure. This is a service that leverages capability checking mechanisms to find out whether the other party supports the service, but other than that is mostly independent from other RCS enablers. A basic RCS IP call does not have specific requirements beyond a regular IMS voice call, apart from specific headers and feature tags.

However, one of the most intriguing features of RCS is “Enriched Voice Call”, allowing users to build context for the call, such as defining a subject or sharing a document before, during or after the call. This user experience is built as a mash-up of RCS chat, file transfer and RCS calls, supporting this on a web point would need for a specific RCS API platform or a RCS-aware WebRTC GW, and suitable coordination between those services in the endpoint.

So the use of RCS could be considered as a trial of the 3GPP to open the IMS services to other Webservices such as reTHINK based apps.



4.1.1.2 Message Flows

The diagram below illustrates an example of an integration between reTHINK and IMS using the RCS API to get the capabilities of an IMS user. This Way the Hyperty would be able to know if the remote endpoint could receive, for example, a video call.

4.1.1.3 Possible Migration Stages

The steps to adapt an existing IMS network to be able to interoperate with a reTHINK network could be:

The deployment of a RCS gateway in order to make all the IMS feature easily usable from reTHINK apps through a ProtoStub.

The deployment of a multimedia server which can transcode between IMS/LTE and WebRTC codes. For example, AMR-WD is not supported by browsers which will typically use Opus as the audio codec, both for scenarios for low band width requirements as for High Definition audio.

For a secure communication by enabling tracing the calls of the reTHINK UEs, providers can define an interface towards the reTHINK for adding IMS identities in the Home Subscriber Server (HSS), using a protocol for example SCIM, so that the P-CSCF can use the IMS identity directly and not an ephemeral, generated identity.

4.1.2 Rich Communication Service: Chat

4.1.2.1 Architecture

For migrating RCS chat and file transfer to web-based endpoints a suitable RCS API gateway is required. The gateway would implement the protocols required to interact with the network as client, meaning no change to existing IMS core is needed, and all multi device and session processing can be leveraged. Another approach could be using APIs exposed directly by the RCS application server, although this might require significant challenges in terms of security, provisioning, etc.

A client-based strategy, with the RCS chat media protocols (MSRP, OMA-CPM, etc.) are running on the web end-point, involves developing a standard RCS client for each browser and JavaScript platform, a non-trivial effort, and significant, continuous commitment to keep it updated.



4.1.2.2 Message Flows

reTHINK Apps can also take advantage of RCS chat API to be able to send message to other IMS users.

4.1.2.3 Possible Migration Stages

The use of the RCS API also seems a logical way to do a migration from a pure IMS network to a reTHINK based network as it performs the translation between SIP signaling and a REST API usable from any Web-based application. For the specific case of the chat, the deployment of RCS would make things much easier.



5 Architecture Validation

The proposed architecture for interoperability between reTHINK and IMS was validated for selected service:

Call session establishment and termination from reTHINK clients to IMS clients; and

Call session establishment and termination from IMS client and reTHINK clients.

During the validation process, the open source SIP server Kamailio [12] was selected as it supports: IMS deployment, interworking with Web Sockets, generation of temporary identities. For token generation and validation the Google Identity Server was used, as it was already integrated with the reTHINK runtime.

5.1 Setup

The setup itself includes:

An IMS kamailio installation on a public IP server running on Amazon Web Services

A prerequisite of the IMS kamailio [12] interface to WebRTC is a DNS entry on the same domain as reTHINK deployed components (e.g. Message Node) and an associated certificate for support of HTTPS for WebRTC.

A FreeSWITCH [13] server installation at the same server, configured with a public interface to be able to connect with public SIP legacy services from Spain.

5.1.1 Identity Management

In a real deployment there needs to be a binding between the identity of the user which have been used to be authenticated in reTHINK with a private and public IMS identities. In our validation scenario a binding has been made between Google identities and SIP accounts. In the case of a real operator it could be its own IdP. This could be the case of Orange as it has its own authentication service.

5.1.2 PSTN Interworking

To achieve the PSTN interworking a Media Server (FreeSwitch) has been deployed. This server allows to terminate WebRTC calls and to translate them into regular SIP calls. This enables SIP calls to any existing SIP trunking service which allows to send calls to PSTN. In our demo platform a free Twilio account has been used to be able to make calls to mobile and fixed numbers.

5.2 Results

In this section the interoperability solution is quantitatively evaluated. More exactly, having the setup described in the previous section and the IMS core server located on Amazon Web Services from Spain and both reTHINK and IMS clients initiating and terminating the calls from Berlin, Germany. The maximum accepted call establishment duration is considered of 8 seconds by 3GPP.

5.2.1 reTHINK initiated call, IMS terminating call

In this section the reTHINK client is initiating the call and the IMS client is the terminating leg receiving, accepting and ending the call. In Table 5 the corresponding results for initiating, accepting and ending the call are presented. The performance is below 2 seconds and can be considered acceptable for a human user.



Table 5: Measurements for reTHINK initiated call

Invite procedure Accept call End call procedure

≈ 605ms ≈ 1239ms ≈ 42ms

5.2.2 IMS initiated call, reTHINK terminating call

In this section the IMS client is initiating the call and the reTHINK client is the terminating leg receiving, accepting and ending the call. In Table 6 the corresponding results for initiating, accepting and ending the call are presented. The performance is below 2 seconds and can be considered acceptable for a human user.



Table 6: Measurements for IMS initiated call

Invite procedure Accept call End call procedure

≈ 712ms ≈ 1053ms ≈ 68ms



6 Conclusion

This integration shows how the reTHINK framework can be integrated with existing communication infrastructures so that it is possible to define a migration path between existing services and the corresponding services based on a reTHINK network.

The integration with the IMS (and also with Slack) has shown that the main challenge for interworking is the mapping and authentication of identities between different domains. This was the aspect that caused most of the integration efforts and - especially for the IMS part - also some extension on internal IMS components. For the setup of the IMS interconnection a few elements had to be added to the legacy IMS network. This was necessary to be able to perform an authentication between IMS and non-SIP-based systems.

The Protocol on-the-fly concept with the protocol stubs as a central architecture element of the reTHINK infrastructure has proven as very suitable not only for interoperability of different reTHINK compliant service domains, but also for integration with other established systems. Most of the complexity for required protocol translations and mappings can be wrapped in interworking stubs and therefore be hidden from the reTHINK framework.

The implementation and provision of a protocol stub for the own communication system and service offerings opens up the own domain for interoperability with all other reTHINK enabled domains. This effort has to be done just once and not for each potential peer domain individually.



References

[1] https://www.rethink-project.eu/

[2] D1.1-Use cases and Sustainable Business models for reTHINK

[3] 3GPP, TS 24.229, “IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)“

[4] 3GPP, TS 29.228, “IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents”

[5] 3GPP, TS 23.167, “IP Multimedia Subsystem (IMS) emergency sessions”

[6] reTHINK, deliverable D5.1 – Service Scenarios Specification, 31 December 2016

[7] reTHINK, deliverable D2.1 - Framework Architecture Definition

[8] reTHINK, deliverable D3.5 - Hyperty Runtime and Hyperty Messaging Node Specification, 30 November 2016

[9] reTHINK, deliverable D3.3 Runtime and Hyperty Messaging Node Phase 2

[10] Slack chat service, https://slack.com/

[11] IETF, “RFC7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements”, 2015

[12] Open Source SIP server, kamailio, https://github.com/kamailio/kamailio

[13] FreeSWITCH media server, https://www.freeswitch.org/

https://www.rethink-project.eu/

https://slack.com/

https://github.com/kamailio/kamailio

migration report - rethink project migration... · etc.). for gprs and lte: it establishes a...

Documents