ADAMANTIUM Project WP3 IMS-based MCMS Modules and Services Development 1.

ADAMANTIUM ProjectWP3

IMS-based MCMS Modules and Services Development

1

Outline

Overview Objectives, Progress and Achievements Tasks

T3.1T3.2T3.3

Conclusions

2

WP3: IMS-based MCMS modules and services development WP3 Leader: TGV Duration: M4-M24 Status Completed

3

WP3 Progress Towards Objectives

4

Objective Progress Report Designed and developed the modules and

interfaces that are necessary for the system integration and evaluation (i.e. IMS HSS, P/I/S-CSCF, PCRF).

Objective Fulfilled Small-scale Test Bed at DEM

premises

Designed and developed a fully operational small scale DiffServ autonomous system as the core network of ADAMANTIUM. Objective Fulfilled

Small-scale Test Bed at DEM premises

Defined, designed and developed the MCMS Action Engine Module (AEM) and its algorithm. Objective Fulfilled D3.1F

Designed and developed the Transport Network and MSRF modules of the MCMS for monitoring and adaptation (i.e. TNMM, TNAM, MSMM, MSAM).

Objective Fulfilled D3.2F

Designed and developed the Access Network and MSRF modules of the MCMS for monitoring and adaptation (i.e. ANMM, ANAM).


Defined, designed and the ADAMANTIUM specific (IPTV & VoIP) services, their generation and adaptation, including the server and client modules.


WP3: Setup of small-scale development testbeds For testing and validating the developed modules within WP3,

the following testbeds have been setup: At ERC premises, a testbed with two servers for developing and testing.

Objectives: Developed new features for AEM module inside an isolate space with a source code version

control and backup software Testing and validating the AEM module (O/I files and rules of System Expert testing them for

simulated different situations and scenaries) At DEM premises, a testbed with IMS CSCF and HSS elements, core

network Diffserv-based and IMS PCRF Objectives:

Testing and validating the implementation of the Transport Network related modules (i.e. IMM, EMM, TNMM, TNAM);

Testing and validating the implementation of the Access Network related modules, based on PCRF (i.e. IMM, EMM, ANAM, ANMM).

At TGV premises, a testbed with core IMS elements (CSCF-related) based on OpenIMS, and end-points elements (Server/Client)

Objectives: Testing the IPTV service distribution and adaptation (i.e. MMIF, MSMM, MSAM); Validating the Server (MSRF) and client related modules (i.e. TAM).

At UOP premises, a testbed with the Open IMS core, video server, Asterisk/VoIP server, IMS clients (IMS-Communicator and Android emulator) and SHUNRA/Storm network emulator

Objectives: Testing the VoIP service distribution and adaptation; Validating the VoIP related modules.

5

Task 3.1- Design and Development of MCMS AEM (1/3)

Defined, designed and developed the final version of Action Engine Module (AEM) AEM prototype description

AI technology with basic CLIPS expert system used in the inference engine AEM decomposed into main components

AEM logic, which is the main component containing the system intelligence Database where all data required by the logic is stored Adapter between logic and database Interface between logic and the rest of MCMS modules

Functionality: Terminal reports alarm to AEM AEM collects monitoring information and generates adaptation commands to be sent to adaptation

modules, applying cross-layer adaptation Combination of monitoring information from different modules Information coming from monitoring modules (related to the same user) used as input to decide the

adaptations Adaptation commands can be sent to different layers (adaptation modules)

Implementation details MCMS implemented as a distributed process model where every module (monitoring, adaptation,

AEM) is a process (multi-process implementation) that shares data using a communication interface Communication library that defines a simple interface based in function calls that hides the

communication mechanism, allowing exchange of session data, data monitored and adaptations Synchronous communication with MCMS monitoring modules Knowledge base composed by AEM complex rues stored in a Data Base

6


7

Dynamic Database /Directory

Static Database /Directory

Inference Engine

Subscriber Information

Subs. Data

Adapter Engine

Session Data

Session Data Adapter Engine

Knowledge Base (Rules)

Rule Data Adapter Engine

Database/Directory

Server

IMS Session Handle

r

MSMM

PQoS Alarm

Handler

MSAM Out

If

ANMM

ANAM Out

If

TNAM Out

If

TNMM

Monitoring Info

Collector

Configuration Data

Conf. Data Adapter Engine

MSAM

ANAM

TNAM

MSMM In

If

MSMMAdapter

MSMM Out

If

TNMM Out

If

ANMM Out

If


Final version of the AEM/MCMS developed in 2nd project year Models for PQoS have been applied in the AEM logic implementation Complex set of rules defined and stored in the data base Cross-layer monitoring and adaptation Development for integration with different development and execution

environments used All modules are integrated with this final AEM version at the DEM small scale

ADAMANTIUM prototype

8

Significant Results of the 2nd project year: Development of the IPTV & VoIP Monitoring and Adaptation

Modules Development of the Transport’s Network Monitoring and

Adaptation Modules Development of the Access’ Network Monitoring and Adaptation

Modules

9

Task 3.2 Development of MCMS monitoring & adaptation modules

Multimedia Service Monitoring Module (MSMM) containing an internal (wrt to MCMS) communication agent, i.e. the InterProcess

Communications Agent (IPC Agent) for request/response messages forwarding to/from the AEM

external communication agents which are the SIP Agent and the Socket Communication, for request/response messages forwarding to/from the MSRF and the TAMs

a Message Adaptor, for request/response message adaptation (formatting) between the above mentioned interfaces

10

Task 3.2 Development of MCMS monitoring & adaptation modules (MSMM)

Architecture of the MSAM andits relations with the AEM,the MSRF and the TAM in VoIP terminals MSRF

Implementation of MSAM for IPTV application

11

Task 3.2 Development of MCMS monitoring & adaptation modules (MSAM)

Monitoring in TNMM includes the following procedures: Routers collect data about the traffic Routers send the collected data to the MonitoringSocketServer of the

EMM, where the total data calculation takes place by the Total Data Calculator

AEM communicates with the EMM's TNMMSocketServer through the MCMS TNMM in 3 steps:

AEM calls the TNMM’sfunction for data collection

MCMS TNMM triggers thesocket client which gets thedata from the socket server on the EMM

MCMS TNMM returns the data to the MCMS AEM

12

Task 3.2 Development of MCMS monitoring & adaptation modules (TNMM)

Adaptation in TNAM includes the following steps: MCMS AEM communicates with TNAMSocketServer on IMM

by triggering the TNAMSocketClient MCMS AEM calls MCMS TNAM function for adaptation MCMS TNAM triggers TNAMSocketClient and sends TN

Adaptation command to TNAMSocketServer on IMM TNAM performs adaptation as soon as TNAMSocketServer

receives Adaptation Data from TNAMSocketClient When Transport Network socket server on Ingress router

receives TNADAPT.dat content it performs adaptation using following linux command:

iptables –L –v –x Creation of new flows between the two clients with the

desired class

13

Task 3.2 Development of MCMS monitoring & adaptation modules (TNAM)

Monitoring in ANMM includes the following procedures: PCEF monitors the access network traffic MCMS AEM receives a WARNING ALARM from the TAM MCMS AEM retrieves current status of the network traffic

from PCF via MCMS ANMM MCMS AEM calls onReceiveANMMXX function of MCMS

ANMM MCMS ANMM requests

monitored data from PCEF MCMS ANMM gets

monitored data from PCEF and creates ANMonitoredData object

MCMS ANMM returns ANMonitoredData object to the AEM

14

Task 3.2 Development of MCMS monitoring & adaptation modules (ANMM)

Adaptation in ANAM includes the following steps: MCMS AEM receives RED ALARM from TAM MCMS AEM takes decision and communicates with PCF Adaptation

Module through MCMS ANAM. MCMS AEM communicates with MCMS ANAM and calls its adaptation-

related function MCMS ANAM sends adaptation command to PCF Adaptation Module PCF Adaptation module performs adaptation using the linux command:

iptables –L –v –x

Creation of new flows between the two clients with the desired class

15

Task 3.2 Development of MCMS monitoring & adaptation modules (ANAM)

IPTV serverUMTS Base Station emulator (CMU200)

Display for visualisation of IPTV video service

IPTV Test Terminal: Notebook with UMTS modem card + alarm filter, Protocol analyser for IP-related QoS parameters

Task 3.2 Development of MCMS monitoring & adaptation modules R&S IPTV over UMTS testbed

IP reflector application (to forward the received video stream to the test probe)

UMTS modem card

Alarm Filter application (to filter and process received alarms from the test probe)

Task 3.2 Development of MCMS monitoring & adaptation modules IPTV Test Terminal

Video server application (to forward the requested video stream to the UMTS BS emulator)

UMTS BS emulator

RF connection via cable

Task 3.2 Development of MCMS monitoring & adaptation modules IPTV Server and UMTS Base Station emulator

Down-link data rate (blue) and up-link data rate (green) at UMTS BS emulator

DL BLER

AWGN setting

Task 3.2 Development of MCMS monitoring & adaptation modules Setting of UMTS Base Station emulator

Alarm Filter application Responses

of AEM test environmentto warnings/ alarms

qPSNR measurement

Task 3.2 Development of MCMS monitoring & adaptation modules IPTV Test Terminal and AEM responses

Testing for QoS parameters that react sensitively to a decrease of DL quality

•qPSNR only effected if TS packets are missing or corrupted (Transport_error)•TS packets only effected if IP packets missing of corrupted (MDI Media Loss Rate)•MDI Delay Factor and MDI RTP Interarrival Jitter effected by increased repettion of UMTS blocks•Averaging of MDI DF and MDI RIJ is sensitive and allows stable thresholds

Task 3.2 Development of MCMS monitoring & adaptation modules Identification of relevant QoS parameters

Configuration of the alarm filterNumber of continuously monitored parameters Time periods for averaging each parameterType of window for averaging of parameterThresholds for each parameterNumber of threshold violations to trigger a warning or an alarmTime periods for counting threshold violationsType of window for counting threshold violationsCombination of 2 or 3 warning or alarm parametersDefinition for re-setting the warning or alarm

Task 3.2 Development of MCMS monitoring & adaptation modules Alarm filter

Objectives: Development of Terminal Adaptation Module

inside Mobile terminal and Softphone client. Development of PQoS Aware IMS

compatible softphone and mobile terminal. Development of MMIF (Adaptation +

Monitoring) in the MSRF

23

Task 3.3 IPTV/VoIP Services generation & adaptation

TAM: IMS-Communicator softphone


TAM: Android G1 Dev mobile handset


TAM: Achievements

The following have been successfully implemented in IMS-Communicator and G1 mobile handset

• PQoS threshold parameters

• Communication of monitoring parameters to MSMM

• INITSESSION, ENDSESSION, warning and red alarms


TAM: Achievements

• PQoS models

• Communication with MSAM • SIP re-Invite in order to perform adaptation actions


PQoS aware 3G mobile terminals



The G1 mobile developer phone can now perform:-

• IMS registration (SIP REGISTER)

• Session establishment (SIP INVITE)

• Session monitoring (RTCP)

• The adaptation (SIP RE-INVITE)

• Instant messages exchanges with MCMS (SIP MESSAGE)

• Session teardown (SIP BYE)



Achievements

Component status Requirements

TAM Implemented Linux, Windows, Java, Open IMS Core, Android SDK

PQoS Model Implemented Linux, Windows, Java, Open IMS Core, Android SDK

Instant Massage (IM) Implemented Linux, Windows, Java, Open IMS Core, Android SDK Core, Android SDK

SIP stack Implemented Linux, Windows, Java, Open IMS Core, Android SDK

RTP stack Implemented Linux, Windows, Java, Open IMS Core, Android SDK


PQoS aware soft phone


PQoS aware soft phone The PQoS Aware IMS-Communicator can

perform the following functions:-

•IMS registration (SIP REGISTER)

•Session establishment (SIP INVITE)

•Session monitoring (RTCP)

•The adaptation (SIP RE-INVITE)

•Instant messages exchanges with MCMS (SIP MESSAGE)

•Session teardown (SIP BYE)


PQoS aware soft phone

Achievements

Component Status Requirements

TAM Implemented Linux, Windows, Java, Open IMS Core, JMF,JAINSIP

PQoS Models Implemented Linux, Windows, Java, Open IMS Core, JMF,JAINSIP

Instant Massage (IM) Implemented Linux, Windows, Java, Open IMS Core, JMF,JAINSIP

SIP stack Implemented Linux, Windows, Java, Open IMS Core, JMF,JAINSIP

RTP stack Implemented Linux, Windows, Java, Open IMS Core, JMF,JAINSIP


IPTV Softphone : Main Achievements

The following have been successfully implemented in IPTV softphone

• Adapter Module allowing renegotiation of media codecs


IPTV softphone

Achievements


Component Implementation status Requirements

SIP Agent implemented Linux, Python, Twisted

RTSP Client implemented Linux, Python, Twisted

Media Controller implemented Linux, Python, Twisted

Media Player implemented Linux, Python, Twisted, VLC/GStreamer

TAM implemented Linux, Python, Twisted

Task 3.3 IPTV/VoIP Services generation & adaptation 19/21

MSRF Architecture

IMS connectivity

Media session monitoring

Media session control Instantiation & tear down

Streaming control

Media streamingRT P

RT CP

M essage Handle r

Request Handle r

RTSP Session Controller

Session Streamer #1

Media Streamer

RT P/RT CP data

SIP Agent

Session Streamer #2

Session Streamer #3

Session Controlle r

Media Controller

RT SPRequest/Response

SIP M essage

M SRF

Request handle r

RTSP Server

Adaptation

MMIF

M onitoring

IM S compliant & QoS aware ADAM ANT IUM M SRF Engine

36


MSRF main components

Sip Agent Handles SIP requests Session initiation and tear down Adaptation messages

Session Streamer One Session Streamer per client

session Stream media to the client using

RTP/RTCP Monitor video parameters Enforce adaptation actions Control streaming with RTSP

RTSP Server Receives RTSP request Dispatches request to destination

session streamer

Media controller Main controller of the MSRF Check for media availability Create / destroy session streamer

37

RT P

RT CP

M essage Handle r

Request Handle r


Session Streamer #1

Media Streamer

RT P/RT CP data

SIP Agent

Session Streamer #2

Session Streamer #3

Session Controlle r

Media Controller

RT SPRequest/Response

SIP M essage

M SRF

Request handle r

RTSP Server

Adaptation

MMIF

M onitoring

IM S compliant & QoS aware ADAM ANT IUM M SRF Engine

MSRF: Achievements

• Communication with MSAM and MSMM • Development of the MMIF Monitoring module

• Improvement of Adaptation with Codec Renegotiation and video scaling adaptation


MSRF

Achievements


Component Implementation status

Requirements

SIP Agent implemented Linux, Python, Twisted

RTSP Server implemented Linux, Python, Twisted


implemented Linux, Python, Twisted

Media Controller implemented Linux, Python, Twisted

Media streamer implemented Linux, Python, Twisted, VLC/GStreamer

MMIF (Adaptation)

implemented Linux, Python, Twisted, VLC/GStreamer

MMIF (Monitoring)

implemented Linux, Python, Twisted, VLC/GStreamer

MMs Allocation Planned vs. Spent

ADAMANTIUM Project WP3 IMS-based MCMS Modules and Services Development 1.

Documents

developed modules

msrf modules

client modules

voip related modules

access network related

ims cscf

client related modules

development of mcms