Download System Architecture Definition and Specifications

WP2
System Architecture Definition
and Specifications
WP2 - System Architecture Definition
and Specifications




WP2 Leader ERC
Duration [M01-M08]
Status Completed
MMs Allocation Planned vs. Spent
ADAMANTIUM
2
WP2
2009-05-28
WP2 Progress Towards Objectives:
Progress
Report
Defined the system architecture at
the various levels necessary for
the rest of work packages to carry
out their work.
Objective Fulfilled
D2.1, D2.2, D2.3
Produced detailed specifications
of the various modules to be
implemented in the demonstrator
testbed and also for further
exploitation after the project end.
Objective Fulfilled
D2.1, D2.2, D2.3
Defined all the required interfaces
for communication between the
modules integrating the system.
Objective Fulfilled
D2.1, D2.2, D2.3
Defined the applications that will
be targeted for experimentation to
demonstrate
to
interested
organisations,
businessmen,
industries or authorities the
technical
features
of
the
developed technology.
Objective Fulfilled
D2.1, D2.2, D2.3
Objective
ADAMANTIUM
3
WP2
2009-05-28
WP2

Novelty of WP2


ADAMANTIUM central module (MCMS)
 Communicates seamlessly with already existing IMS
modules and interfaces
 Fully IMS compliant
 Composed of modules based on IMS signalling (preferably
SIP/SDP) for communication, processing and interaction with
the rest IMS modules and interfaces
Analysis of possible AEM implementations considering
 Expert Systems
 Machine Learning
 First version of AEM module with the introduction of an
Expert System with simple rules
ADAMANTIUM
4
WP2
2009-05-28
Achievements of WP2

ADAMANTIUM has defined the specifications of the
various components that are included in the proposed
architecture [Reported in D2.1]







various elements and interfaces that the proposed management entity
(i.e. the MCMS) interacts with
Media Service Resource Function (MSRF)
DiffServ/MPLS core network
UMTS access network
ADAMANTIUM-compatible terminal devices
Terminal Adaptation Module – TAM
ADAMANTIUM has described specific user-case
scenarios, which

Clarify the functionality and the efficiency of the proposed monitoring
and adaptation management system
 Describe various cases where the PQoS degradation is managed by
different points of the media delivery chain [Reported in D2.1]
ADAMANTIUM
5
WP2
2009-05-28
Achievements of WP2 (II)

ADAMANTIUM defined and specified MCMS modules

Three monitoring modules (ANMM, TNMM, MSMM)
 Three adaptation modules (ANAM, TNAM, MSAM)
 The central decision node (AEM)


For each monitoring/adaptation module, internal and
external interfaces have been defined for maximizing
interoperability, compatibility and adaptability of
proposed MCMS architecture to future mobile platforms
beyond IMS. [Reported in D2.2]
ADAMANTIUM defined specifications of applications and
adaptation schemes for IPTV & VoIP [Reported in D2.2]

IMS-compliant PQoS-aware
 Expand existing management capabilities of IMS infrastructure
 Aims to optimize delivered PQoS with real time cross layer adaptations
ADAMANTIUM
6
WP2
2009-05-28
Agenda



Objectives
Introduction
Description of the work






Task 2.1 Overall System Architecture
Task 2.2 Access Network Definition & Specifications
Task 2.3 Core Transport Network Definition & Specifications
Task 2.4 Server/Client Definition & Specifications
Task 2.5 MCMS Definition & Specifications
Task 2.6 Services Definition & Specifications
ADAMANTIUM
7
WP2
2009-05-28
Objectives

The objectives achieved in WP2 consisted on



Defining and specifying the overall system and subsystems
architecture
Defining the interfaces of the various modules
This comprises




Architecture and specifications of the MCMS (Multimedia
Content Management System)
Definition and description of modules and subsystems inside
Study, design and definition of communication between the
ADAMANTIUM system modules
Integration with the IMS platform
ADAMANTIUM
8
WP2
2009-05-28
Introduction

Advantages of ADAMANTIUM

QoS degradation detection and dynamic cross-layer
adaptations

Central controller system
 Multimedia Content Management System (MCMS)
 Decides the best adaptation for maintaining quality

Two-phase alarms performed
 Warning alarm  Monitoring phase
 Red Alarm  Adaptation phase
ADAMANTIUM
9
WP2
2009-05-28
Objectives

Non-ADAMANTIUM
IMS basic structure



Different services
provided
QoS set at starting point
Degradation of QoS not
controlled
ADAMANTIUM
10
WP2
2009-05-28
Objectives

Enhanced IMS


ADAMANTIUM
approach
IMS QoS assured
by MCMS system




Different services
provided
QoS set at starting point
Degradation of QoS
controlled by MCMS
Control Points
 Access Network
 Transport Network
 Multimedia Sessions
ADAMANTIUM
11
WP2
2009-05-28
Introduction

The MCMS is composed by 7 modules

3 Monitoring Modules
 Multimedia Session Monitoring Module (MSMM)
 Transport Network Monitoring Module (TNMM)
 Access Network Monitoring Module (ANMM)

3 Adaptation Modules
 Multimedia Session Adaptation Module (MSAM)
 Transport Network Monitoring Module (TNAM)
 Access Network Monitoring Module (ANMM)

1 Central Decision Module
 Action Engine Module (AEM)
ADAMANTIUM
12
WP2
2009-05-28
WP2
Task 2.1 Overall System
Architecture
Overall system Architecture

ADAMANTIUM project proposal

IMS-compatible system
 PQoS-aware system
 No further requirements, changes or prerequisites to existing
architecture

Central controller system
 Multimedia Content Management System (MCMS)

Real-time monitoring and adaptation of QoS of Multimedia
Services
ADAMANTIUM
14
WP2
2009-05-28
ADAMANTIUM project architecture
ADAMANTIUM
15
WP2
2009-05-28
ADAMANTIUM project architecture

MCMS module




Multimedia Server & Resource
Function (MSRF)




Monitors parameters of Multimedia Session
Detects degradation of PQoS
Selects adaptations
IMS-based MRF
Controls services IPTV and VoIP
Monitors and adapts parameters of
services
IP Core DiffServ/MPLS Compatible TN


Delivery the requested multimedia service
All core network nodes
 Inter-cooperate
 Treat market traffic properly
ADAMANTIUM
16
WP2
2009-05-28
ADAMANTIUM project architecture

UTMS Access Network


Provides service/bearer
classification mechanisms for
providing QoS constraints
Terminal Adaptation Module
(TAM)


Sends statistics and alarms of the
End User Terminal PQoS to the
MCMS module
Performs the required adaptations
on the End User Terminal
ADAMANTIUM
17
WP2
2009-05-28
IMS Network

ADAMANTIUM project




Multimedia session Mgmt and QoS signalling


Based on 3GPP Release 7
Testbed IMS functionalities based on



Based on Next Generation Network IMS infrastructure
Aims at developing within NGN environment an integrated
PQoS-aware management system
Real-time maximization of end user satisfaction when PQoS
degradation is noticed
FOKUS Open Source IMS Core (OSIMS)
HSS components
IMS policy control is based on

UCT Policy Control Framework
ADAMANTIUM
18
WP2
2009-05-28
Session Establishment
SIP Messages
DIAMETER Messages
ADAMANTIUM Messages
RTP Data
MCMS
•Originating endpoint
•Destination endpoint
•Media flow description
•QoS required = yes | no
•Bitrates [UL | DL]
•CoS Session
OK
Media Sessions DB
HSS
IMS
S-CSCF#1
S-CSCF#2
PC
R
F
ISMF
SIP
INVITE
TAM
Rx
IMM
RN
C
SG
SN
P-CSCF#1
P-CSCF#2
Session
Media
Data
Progress
(Best
(…)
Effort)
Gx
LSR
GG
(PC SN
EF
)
B NODE
EMM
IP-MPLS
MSRF
IMM
LER
EMM
Background PDP Context Activation
LER
LSR
MSMM
Best Effort queue
ADAMANTIUM
19
Best Effort LSP
WP2
2009-05-28
Session Management
SIP reINVITE
STATS
SIP Messages
DIAMETER Messages
ADAMANTIUM Messages
RTP Data
MCMS
HSS
Monitoring
Info DB
IMS
S-CSCF#1
S-CSCF#2
PC
R
F
ISMF
SIP
ALARM
TAM
Rx
IMM
RN
C
SG
SN
P-CSCF#1
P-CSCF#2
Gx
LSR
GG
(PC SN
EF
)
B NODE
EMM
IP-MPLS
MSRF
IMM
LER
EMM
Background PDP Context Activation
LER
LSR
MSMM
ADAMANTIUM
20
WP2
2009-05-28
Defined Use Cases

IPTV VoD unicast




User would like to watch a unicast IPTV video session
User terminal detects quality degradation, with CNR OK
 Problem at Server Side
 Problem at Core Network
 Problem at Access Network
User terminal detects quality degradation, with low CNR
Live IPTV multicast



User would like to watch a multicast IPTV video session
User terminal detects quality degradation, with CNR OK
 Problem at Server Side
User terminal detects quality degradation, with low CNR
ADAMANTIUM
21
WP2
2009-05-28
Defined Use Cases

VoIP



User would like to have a VoIP session
User terminal detects quality degradation, with CNR OK
 Problem at Server Side
 Problem at Core Network
 Problem at Access Network
User terminal detects quality degradation, with low CNR
ADAMANTIUM
22
WP2
2009-05-28
Testbed in NCSR Demokritos

Components installed

HSS
 P-CSCF
 S-CSCF
 I-CSCF
 Policy Control Framework (PCF)

UCT PCF






Open Source, Freely distributed (under GLPv3)
Including Policy and Charging Rule Function (PCRF) and Policy and
Charging Enforcement Point (PCEF)
Experimental tool for QoS and Policy Contro Research
Does not include Charging functionality
Follows 3GPP Release 7 Specifications
Services supported

VoIP
 IPTV
ADAMANTIUM
23
WP2
2009-05-28
WP2
Task 2.2 Access Network
Definition & Specifications
Access Network Architecture
ADAMANTIUM
25
WP2
2009-05-28
Access Network Architecture

ANMM


External Monitoring Modules (EMM)



Interface integrated at egress edge router Access Network
Enables interaction and communication with the ANMM
ANMM



Monitors UMTS Access Network statistics on a “per node” basis
Receives monitoring data from EMM at egress Access Network
router
Applies adaptation actions decided by AEM to UMTS Access
Network through IMS PCRF (Policy & Charging Rules Function)
PCRF applies adaptation actions at GGSN
performing service bearer classification to
improv QoS characteristics and enhance PQoS
ADAMANTIUM
26
WP2
2009-05-28
Access Network Architecture

ADAMANTIUM provision of QoS mechanism



UTMS traffic differentiation by the GGSN
5 layers with a different QoS scheme
 End-to-end
 UMTS
 Radio Access Bearer
 Radio Bearer
 Interface unit
ADAMANTIUM Interfaces with Access Network


PCF Internal Marking Module (IMM)
 Mark multimedia traffic according MCMS commands
 Connect MCMS (ANAM) with PCF-GGSN
PMS External Monitoring Module (EMM)
 Monitor UMTS network statistics
 Connect MCMS (ANMM) with PMS
ADAMANTIUM
27
WP2
2009-05-28
Access Network QoS Class

3GPP defined four UMTS QoS traffic classes
Conversational
(Real Time)
Traffic Class
Streaming
(Real Time)
Interactive
(Best Effort)
Background
(Best Effort)
Characteristics
•
Preserve time
relation
(variation)
between
information
entities of the
stream
• Conversational
pattern,
therefore, very
low delay and
jitter
•
Preserve time relation
(variation) between
information entities of
the stream
• Delay and jitter
requirements are not
as strict as with the
conversational class
•
Request/response
pattern
• Retransmission of
payload content inroute
•
Example
Applications
Voice over IP
Streaming audio and
video
Web browsing
Downloading
email
Diffserv Class /
Map to DSCP
Expedited
Forwarding Class
Assured Forwarding 2
Class
Assured Forwarding
3 Class
Best Effort
ADAMANTIUM
28
WP2
Destination is not
expecting the data
with a stringent
time
• Retransmission of
payload content
in-route might
occur
2009-05-28
Access Network Class attributes
Traffic class
Conversational class
Streaming class
Interactive class
Background class
<= 256 000 (2)
<= 256 000 (2)
<= 256 000 (2)
<= 256 000 (2)
Yes/No
Yes/No
Yes/No
Yes/No
<=1 500 or 1 502 (4)
<=1 500 or 1 502 (4)
<=1 500 or 1 502 (4)
<=1 500 or 1 502 (4)
(5)
(5)
Yes/No/- (6)
Yes/No/- (6)
Yes/No/- (6)
Yes/No/- (6)
Residual BER
5*10-2, 10-2, 5*10-3, 10-3, 104, 10-5, 10-6
5*10-2, 10-2, 5*10-3, 10-3, 104, 10-5, 10-6
4*10-3, 10-5, 6*10-8 (7)
4*10-3, 10-5, 6*10-8 (7)
SDU error ratio
10-2, 7*10-3, 10-3, 10-4, 10-5
10-1, 10-2, 7*10-3, 10-3, 10-4,
10-5
10-3, 10-4, 10-6
10-3, 10-4, 10-6
100 – maximum value
300 (8) – maximum value
<= 256 000 (2)
<= 256 000 (2)
Maximum bitrate (kbps)
Delivery order
Maximum SDU size (octets)
SDU format information
Delivery of erroneous SDUs
Transfer delay (ms)
Guaranteed bit rate (kbps)
Traffic handling priority
Allocation/Retention priority
Source statistic descriptor
1,2,3 (9)
1,2,3
1,2,3
Speech/unknown
Speech/unknown
1,2,3
Signalling Indication
1,2,3
Yes/No (9)
ADAMANTIUM
29
WP2
2009-05-28
WP2
Task 2.3 Core Transport Network
Definition & Specifications
Transport Network Architecture
MPLS: MultiProtocol Label Switching
ADAMANTIUM
31
WP2
2009-05-28
Transport Network Architecture

ADAMANTIUM provision of QoS mechanism
using DiffServ/MPLS



MPLS: Data-carrying mechanism
Differentiated Services: Data-classifying, providing QoS
ADAMANTIUM Interfaces with Network


DiffServ/MPLS internal Marking Module (IMM)
 Mark multimedia traffic according MCMS commands
 Connect MCMS (TNAM) with ingress routers
External Monitoring Module (EMM)
 Monitor network statistics
 Connect MCMS (TNMM) with egress routers
ADAMANTIUM
32
WP2
2009-05-28
Transport Network QoS Class
CLASSES
DESCRIPTION
EF
Best class for IPTV sessions
AF1X
Best class for VoIP sessions
AF2.X
Medium class for VoIP sessions
BE
Basic class for all kind of session
ADAMANTIUM
33
WP2
2009-05-28
Transport Network Architecture

AEM determines specific adaptation actions for
improving PQoS




Regarding DiffServ/MPLS transport network
Appropriate IMS-based adaptation actions are forwarded from
the TNAM to Action Receiver interface of Internal Marking
Module (IMM)
It translates received adaptation action into DiffServ/MPLS
classification commands
The actions are forwarded to DiffServ/MPLS Marking interface of
the IMM, which applies them into the ingress router (i.e. LER 1)
of the transport network, where the packet marking and traffic
classification is performed
ADAMANTIUM
34
WP2
2009-05-28
Transport Network Architecture

Marked/classified media flow is treated by
DiffServ/MPLS-enabled Label Switch Routers
across Transport Network

External Monitoring Module (EMM) calculates
network-related statistics of each flow



NQoS statistics are calculated by DiffServ/MPLS EMM
Monitoring Interface
And forwarded to TNMM Monitoring Forward Interface
According to statistics from TNMM, and considering monitoring
statistics from MSMM and ANMM, AEM decides optimal
adaptation action for improving PQoS level of delivered IPTV or
VoIP applications
ADAMANTIUM
35
WP2
2009-05-28
WP2
Task 2.4 Server/Client Definition /
Specifications
Server / Client

Service Provision based on Client/Server
architecture

Both Client and Server




Compatible with IMS architecture
Connected to MCMS for monitoring and adaptation functions by
different interfaces
Support IPTV and VoD applications
Support VoIP services
ADAMANTIUM
37
WP2
2009-05-28
Server / Client
IMS
NETWORK
TAM
MCMS
MSMM
MMIF
MSAM
ADAMANTIUM
38
WP2
2009-05-28
Server / Client

Server Side

MSRF is a IMS-based MRF module that includes IMS
application servers for IPTV

Responsibilities
 IPTV service generation, session management and
streaming
 Monitoring of content and encoding/streaming parameters
 Parameters adaptation according MCMS commands

Interfaces
 IP Core Network through the DiffServ/MPLS IMM
 MCMS through the MMIF interface (MSRF/MCMS InterFace)
ADAMANTIUM
39
WP2
2009-05-28
Server Requirements

Services


Video codecs


MPEG 2, H.264 (MPEG 4 AVC), XViD, WMV
Protocols





Live IPTV and Video on Demand
Streaming over RTP
Media control with RTSP
Session control with SIP
Multicast session subscription with IGMP
Adaptation



Codec adaptation (transcoding)
Bitrate and framerate adaptation (transrating)
Video resolution adaptation (scaling)
ADAMANTIUM
40
WP2
2009-05-28
Server / Client

MMIF (MSRF/MCMS Interface)
 MSRF


Process adaptation messages from MCMS (MSAM)
SIP-based “MESSAGE” with XML payload
 Codec to use
 Session ID
 Video width and height
 Bit rate
 FEC
 Frame rate
 MSRF

adaptation interface
QoS monitoring interface
Monitoring elements of each delivered stream
 Encoding bit rate
 Resolution
 Frame rate
 Delivered bit rate
 Type of content
 Dynamics of the content
ADAMANTIUM
41
WP2
2009-05-28
Server / Client

Client Side
 End


IMS-Compatible
Support SIP messages
 TAM



user client terminal
is the interface between Terminal and MCMS
Provide monitoring service of QoS
 Continuity errors
 PQoS
 Transport errors
Provide adaptation service according MCMS control
commands
 Buffers size and algorithmic
 Video Size
 Codec parameters
 Bit rate
Light application in the terminal
ADAMANTIUM
42
WP2
2009-05-28
IPTV Client Requirements

Supported services



Protocols


H.264 and MPEG 2 video content
Adaptation



SIP, RTP, IGMP and RTSP
Codecs


Live IPTV
Video on Demand (VoD)
With session renegotiation  Transcoding
Without session renegotiation  Transrating, scaling
Video control

Play, pause, stop
ADAMANTIUM
43
WP2
2009-05-28
Server / Client
ADAMANTIUM
44
WP2
2009-05-28
WP2
Task 2.5 MCMS Definition &
Specifications
MCMS Overview

Multimedia Content Mgmt System (MCMS)


Central module of ADAMANTIUM architecture
Features





Real-time dynamic cross layer adaptation
Optimization of the user Perceived QoS
Services selected
 IPTV (LiveIPTV, VoD)
 VoIP
IMS – compatible signalling
Functions
 Monitoring
 Decision
 Adaptation
ADAMANTIUM
46
WP2
2009-05-28
MCMS Overview

Layers affected




Service layer
 Multimedia Server
 User Terminal
Network layer
 Transport Network
Operator
Access layer
 Access Network
Real-time monitoring
and adaptations
performed to maintain
quality of media
ADAMANTIUM
47
WP2
2009-05-28
Introduction

The MCMS is composed by 7 modules

3 Monitoring Modules
 Multimedia Session Monitoring Module (MSMM)
 Transport Network Monitoring Module (TNMM)
 Access Network Monitoring Module (ANMM)

3 Adaptation Modules
 Multimedia Session Adaptation Module (MSAM)
 Transport Network Monitoring Module (TNAM)
 Access Network Monitoring Module (ANMM)

1 Central Decision Module
 Action Engine Module (AEM)
ADAMANTIUM
48
WP2
2009-05-28
MCMS External Interfaces

Interfaces
between the
MCMS and




UMTS Access
Network
DiffServ/ MPLS Core
Network
MSRF
User Equipment/
Terminal
ADAMANTIUM
49
WP2
2009-05-28
MSMM & MSAM External Interfaces

MSMM – MSRF communication

SNMP (Simple Network Mgmt Protocol)
 In this protocol, alarm messages, are defined based on the SNMP MIB
(Management Information Base)

MSAM – MSRF communication


MSAM – TAM communication


SIP messages, to provide adaptation to the IPTV established sessions
SIP MESSAGE method to provide adaptation actions
SIP-based MESSAGE method

The information is encoded and sent in the message body through an
XML format
ADAMANTIUM
50
WP2
2009-05-28
TNMM & TNAM External Interfaces

TNMM – IMM/EMM communication



Proprietary protocol solution
Compatible for executing remotely shell scripts and commands
TNAM – IMM/EMM communication


Proprietary protocol solution
Compatible for executing remotely shell scripts and commands
ADAMANTIUM
51
WP2
2009-05-28
ANMM & ANAM External Interfaces

ANMM – IMM/EMM communication




ANAM – IMM/EMM communication


Based on proprietary protocol solution
Compatible for executing remotely shell scripts and commands
Special consideration will be given on the ultra weight nature of
the proprietary protocol.
IMS-based (e.g. SIP/SDP)
IMM (Internal Marking Module) – EMM (External
Monitoring Module) communication

TCP/IP based
ADAMANTIUM
52
WP2
2009-05-28
MCMS Internal Interfaces
MSAM
MSMM
ANMM
AEM
Access Network
Access Network
Adaptations
Monitoring data
ANAM
TNAM
TNMM
ADAMANTIUM
53
WP2
2009-05-28
MSMM – AEM Interface

MSMM



Monitors service session at the end-user terminal device and at
the service generation entity
Interacts with IMS functional entities in order to set-up the AEM
with actual multimedia sessions currently being provisioned
Primitives




onReceiveQPSNR (PULL) invoked by AEM
onReceiveTransportStreamQoS (PULL) invoked by AEM
onReceiveAlarm (PUSH) invoked by MSMM
onReceiveCQI (PULL) invoked by AEM
ADAMANTIUM
54
WP2
2009-05-28
MSAM – AEM Interface

MSAM performs adaptation actions at



End-user terminal device for voice content (the IPTV stream
comes adapted to end user terminal)
MSRF (Multimedia Service Resource Function) for IPTV content
Primitives (all invoked by AEM)





onSendTerminalBufferAdaptation (PULL)
onSendTerminalPacketizationAdaptation (PULL)
onSendTerminalCodecAdaptation (PULL)
onSendTerminalVideoAdaptation (PULL)
onSendMSRFVideoAdaptation (PULL)
ADAMANTIUM
55
WP2
2009-05-28
TNMM – AEM Interface

TNMM



Monitors network statistics at DiffServ/MPLS core transport
network
Interacts with IMM and EMM at the ingress and egress routers
Primitives




onReceiveTNMPQoS (PULL) invoked by AEM
onReceiveTNPacketLoss (PULL) invoked by AEM
onReceiveTNBandwidth (PULL) invoked by AEM
onReceiveTNAlarm (PUSH) invoked by TNMM
ADAMANTIUM
56
WP2
2009-05-28
TNAM – AEM Interface

TNAM




Applies adaptation actions to DiffServ/MPLS-enabled core
transport network through Internal Marking Module (IMM)
Receives adaptation actions from the AEM
Provides adaptation actions to IMM
Primitive

onSendTNClassification (PULL) invoked by AEM
ADAMANTIUM
57
WP2
2009-05-28
ANMM – AEM Interface

ANMM




Monitors UMTS access network statistics
Receives monitoring data from the EMM at the egress access
network router
Provides that information to the AEM
Primitives





onReceiveANMPQoS (PULL) invoked by AEM
onReceiveANBandwidth (PULL) invoked by AEM
onReceiveANBitrate (PULL) invoked by AEM
onReceiveANPacket_Loss (PULL) invoked by AEM
onReceiveANAlarm (PUSH) invoked by ANAM
ADAMANTIUM
58
WP2
2009-05-28
ANAM – AEM Interface

ANAM



Applies adaptation actions to UMTS Access Network through
IMS PCRF (Policy and Charging Rules Function) module
Receives from AEM
 Multimedia bearer to be considered
 New class of service to be assigned
Primitive

onSendANClassification (PULL) invoked by AEM
ADAMANTIUM
59
WP2
2009-05-28
AEM

Central decision module






ADAMANTIUM implementation



Responsible for taking optimal adaptation decisions
Based on the network monitoring and perceptual statistics
Exploits theoretical mapping frameworks between NQoS and PQoS
Processes all selected statistics
Define a perceptually optimal cross layer adaptation action
Single host, single process  for simplicity
Simple interfaces have been defined with extension
possibilities
AEM

QoS control decisions based on an advanced mechanisms / algorithms
(e.g. such as machine learning, expert systems, etc.)
 Processing information from Monitoring Modules
 Making decisions about the way to improve PQoS
 Sending instructions to the Adaptation Modules
ADAMANTIUM
60
WP2
2009-05-28
AEM – ML

Machine learning

The field of ML is concerned with the question
 “how to construct computer programs that automatically improve
with experience?”
 ML process
 ML builds mathematical models making inference from a sample
 The model may be predictive to make predictions in the future, or
descriptive to gain knowledge from data, or both
 Learning is the execution of a computer program to optimize
parameters of the model
 Although identifying the complete process may not be possible, it is
still possible to detect certain patterns or regularities
 To be intelligent, a system that is in a changing environment should
have the ability to learn
 Algorithms have been invented that are effective for certain types of
learning tasks, and a theoretical understanding of learning is
beginning to emerge
 Many practical computer programs have been developed to exhibit
useful types of learning, and significant commercial applications
have begun to appear
ADAMANTIUM
61
WP2
2009-05-28
AEM – ML

Machine Learning


An application of ML methods to large databases is called Data
Mining
 ML algorithms are being used routinely to discover valuable
knowledge from large commercial databases containing
equipment maintenance records, loan applications, financial
transactions, medical records, etc.
In recent years many successful machine learning applications
have been developed, including
 data-mining programs that learn to detect fraudulent credit
card transactions
 information-filtering systems that learn users' reading
preferences
 autonomous vehicles that learn to drive on public highways
 etc
ADAMANTIUM
62
WP2
2009-05-28
AEM – ES

Expert Systems

SW that attempts to reproduce the performance of one or more human
experts
 Once the system is developed, it is proven by being placed in the same
real world problem solving situation as the human
 There are two main methods of reasoning when using inference rules
 Forward chaining: starts with the data available and uses the
inference rules to conclude more data until a desired goal is
reached
 Backward chaining: starts with a list of goals and works backwards
to see if there is data which will allow it to conclude any of these
goals
 One advantage of expert systems over traditional programming
methods is that they allow the use of "confidences“
 When a human reasons he does not always conclude things with
100% confidence
 The human reasoning can be imitated by using numeric values
called confidences
ADAMANTIUM
63
WP2
2009-05-28
AEM – ES

Standard Expert system






The user interacts with the system through a user interface (menus,
natural language or any other style of interaction)
An inference engine is used to reason with both the expert knowledge
(extracted from an expert) and data specific to the particular problem
being solved
Expert knowledge will typically be in the form of a set of IF-THEN rules
The case specific data includes both data provided by user and partial
conclusions (along with certainty measures) based on this data
Almost all expert systems also have a subsystem to explain its
reasoning to the user and some systems have a knowledge base editor
helping the expert to update and check knowledge base)
One important feature of expert
systems is the way they (usually)
separate domain specific knowledge
from more general purpose reasoning
and representation techniques
ADAMANTIUM
64
WP2
2009-05-28
AEM

Initial design with some specific restrictions




AEM will generate adaptation commands only to the equivalent
adaptation module
Only information from one monitoring module will be used
Only information to one adaptation module
Once the first version is implemented, the
system will be tested to define possible AEM
evolutions
ADAMANTIUM
65
WP2
2009-05-28
AEM

Several questions should be answered for final
AEM version to define if implementing ES or ML






Are there specific rules that can help inferring adaptation
commands from monitoring information?
Does the input from monitoring modules generate an automatic
output for the adaptation modules?
Is information coming from different monitoring modules required
to define an AEM output?
Is it possible to have more efficient adaptation processes when
combining information from different monitoring modules?
Is it possible to provide the AEM with information of results
produced by the adaptation process performed?
Can the system (the AEM) adapt future actions depending on
present actions?
ADAMANTIUM
66
WP2
2009-05-28
ES in ADAMANTIUM







The receiver of ES decision is not a final user
The ES resides within a network functional entity interacting with
other network entities
Monitoring modules provide the case-specific information to AEM
Adaptation Modules The modules receiving the expert system
output are the adaptation modules
The “user interface” and “explanation system” are replaced by
interfaces between AEM and other modules
The base expert system architecture has been extended to take
care of other ADAMANTIUM specific tasks, such as the handling of
IMS sessions
In general, the AEM is decomposed into the following main
components:

AEM logic. Containing the system intelligence
 Database. All data required by the logic is stored
 Adapter between the logic and the database
 Interface between the logic and the rest of MCMS modules
ADAMANTIUM
67
WP2
2009-05-28
ES in ADAMANTIUM
Abstract the Data
Logic Module
Interface
module
Base implementation
• Inference Engine
• Alarm Handle
•Session Handle
Monitoring
data
Adaptation
data
Rules
Session Data
Monitoring Data
Results
ADAMANTIUM
68
WP2
2009-05-28
AEM ES
AEM uses an Expert System
for selecting the best adaptation
Session
Data
Monitoring
Expert
Data
System
Adaptations
Rules
ADAMANTIUM
69
WP2
2009-05-28
AEM Rules Example
Alarm
YE
S
¿IPTV app?
BE
Change AF13
AF13
Change AF12
AF12
Change AF11
AF11
No Change
BE
Change EF
¿TN Class?
NO
YE
S
¿VoIP?
¿TN Class?
EF
No Change
NO
Unknown no Change
ADAMANTIUM
70
WP2
2009-05-28
ES Alternatives
CLPS






Created on 1986 by the NASA
Written in C
System dependence (needs
compilation)


JESS



Faster but less powerful
CLIPS is chosen

Portable and integrable within other
languages
(library solution). Also
• MCMS written in C++
CORBA
for can
interaction
• CLIPS
be easily integrated
C++
Public• in
Domain
Software (Low cost)
CLIPS is public domain SW
documented
There• Fully
is a lot
of documentation
• Integrable in the project as a
library
• ADAMANTIUM prototype
doesn’t require a strong tool
ADAMANTIUM
Based in CLIPS
Written in Java
System independence
71



Virtual Machine could made Jess slower
although it is more powerful
Full interaction with Java code
Interaction with other programs by
CORBA
Use license is required
JDBC connector for storing facts, rules
and decisions on a Data Base
WP2
2009-05-28
WP2
Task 2.6 Services Definition &
Specifications
Overview

IMS technology does not provide any PQoSaware management mechanism

ADAMANTIUM proposes a dynamic cross-layer
adaptation for the optimization of PQoS

Services studied


IPTV (LiveIPTV and VoD)
VoIP
ADAMANTIUM
73
WP2
2009-05-28
IPTV

TV content over IP networks

Supported services

Multicast IPTV (Live IPTV)
 Like analogue TV
 The same TV content to multiple receivers at same time

Unicast IPTV (Video on Demand)
 Personalized TV content sent to multiple receivers
ADAMANTIUM
74
WP2
2009-05-28
IPTV – Live IPTV

LiveIPTV (Multicast)




Multiple subscribers receive the same TV content at the same
time
ISP relay the content to their customers over their own network
infrastructure
Considerable bandwidth is saved since only one stream is
transmitted
Supports multiple channels and sends them at the same time
MSRF (IPTV server)
ISP
Routers
Clients
ADAMANTIUM
75
WP2
2009-05-28
IPTV – VoD

Video on Demand (VoD Unicast)




User receives specific requested content
Depending of the IPTV operator, user may be able to control the
stream reproduction
No bandwidth is saved because multiple streams are
transmitted
Supports multiple channels and sends them at the same time
MSRF (IPTV server)
ISP
Routers
Clients
ADAMANTIUM
76
WP2
2009-05-28
IPTV Protocols

IPTV uses several protocols






Real-time Transport Protocol (RTP)
 Transport of audio or video on top of UDP
MPEG transport stream (MPEG-TS)
 Packetization and encapsulation of video and audio streams
 Sent over RTP
Real-time Transport Streaming Protocol (RTSP)
 Control of media delivery
Session Initiation Protocol (SIP)
 Session initiation and tear down
Session Description Protocol (SDP)
 Negotiation of audio video parameters
ADAMANTIUM is fully compatible with these protocols
ADAMANTIUM
77
WP2
2009-05-28
IPTV Service Specifications



The IPTV service commonly occurs between an UE
terminal and an MSRF IPTV server
The components are connected by an IMS network
Perceived QoS is controlled by the MCMS which sets
the necessary parameters in order to maintain the
needed quality
ADAMANTIUM
78
WP2
2009-05-28
IPTV in ADAMANTIUM

ADAMANTIUM IPTV architecture is fully
compliant with ETSI architecture





User Equipment (UE): initiates and closes sessions using SIP
(via Gm reference point)
CSCF interacts with MSRF with SIP (via y2 reference point)
UE can control media delivery with the RTSP protocol (via the
Xc reference)
MSRF delivers media to UE with RTP protocol (via Xd reference
point)
New extension


UE, Access Network, transport network and MSRF send
monitoring information to MCMS
When PQoS drops below a given threshold, MCMS sends the
correspondence adaptations
ADAMANTIUM
79
WP2
2009-05-28
IPTV QoS



IPTV and VoD
QoS 4 class required According to ITU-T Y1541
Characteristics

IP packet Transfer Delay (IPTD)
 less than 1s
 Sensitive on data loss but not on time data reached time
 IP packet Delay Variations (IPDV) or jitter
 Unspecified by the ITU
 Sensitive to jitter because of the decoding process
 Should be less than 50 ms
 IP packet Loss Ratio (IPLR)
 Maximum value of 1*10-3
 Direct impact on image and sound quality
 IP packet Error Ratio
 Maximum value of 1*10-4
 Strong impact on the image and sound quality
ADAMANTIUM
80
WP2
2009-05-28
IPTV Features

Scenario



PQoS-aware UE terminal IMS-compatible
IPTV server located in the MSRF, with IMS functionalities
(Deliver VoD or Live IPTV services)
Codec



MPEG-2, MPEG-4, H.263 and H.264
15-30 frames per second
Spatial resolution depends on the user’s terminal
 QCIF video (176 x 144) - mobile phones
 320x240 - PDAs
ADAMANTIUM
81
WP2
2009-05-28
IPTV Features

Transport protocol




Signalling protocol




MPEG transport stream to encapsulate video
RTP for streaming
RTSP for control
SIP session creation and tear down
SDP used to describe the multimedia session
Adaptation messages are sent by the MCMS to the MSRF
User Terminal


Capable of negotiating transmission parameters
PQoS aware
ADAMANTIUM
82
WP2
2009-05-28
VoIP


Allow voice and video services over IP
networks
Provide solutions on every Layer of an IP
network


Voice applications
Low-level quality measurements (packet loss and delay)
ADAMANTIUM
83
WP2
2009-05-28
VoIP Protocols

VoIP uses protocols for setting up and tearing
down a voice/video call on an IP network

Protocols used





Session Initiation Protocol (SIP)
Session Description Protocol (SDP)
Real-time Transport Protocol (RTP)
Real-time Transport control (RTCP)
ADAMANTIUM is fully compatible with these
protocols
ADAMANTIUM
84
WP2
2009-05-28
VoIP QoS



VoIP is extremely bandwidth and delay sensitive
QoS 0 or 1 class required according to ITU-T Y1541
Characteristics




IP packet Transfer Delay (IPTD)
 Between 100 and 400 ms
 300 ms is acceptable especially for satellite transmission
 Less than 150 ms one-way end-to-end for height-quality
IP packet Delay Variations (IPDV) o jitter
 Should be less than 50 ms
IP packet Loss Ratio (IPLR)
 Maximum value of 1*10-3
 Ideally, there should be no packet loss
IP packet Error Ratio
 Maximum value of 1*10-4
 Strong impact on the image and sound quality
ADAMANTIUM
85
WP2
2009-05-28
VoIP QoS



VoIP service must guarantee certain
compensating bandwidth, latency and jitter
requirements
VoIP packets receive the preferential treatment
they require
Features





Supporting dedicated bandwidth
Improving loss characteristics
Avoiding and managing network congestion
Shaping network traffic
Setting traffic priorities across the network
ADAMANTIUM
86
WP2
2009-05-28
VoIP in ADAMANTIUM



VoIP is compatible with the IMS architecture
complementing it by the introduction of MCMS
IMS services architecture unify a wide range of
services
IMS comprises all the core network providing IP
multimedia services



Access Network: access point and links to the user
Transport Network: provides service control
IMS supports multiple application servers
providing traditional telephony and nontelephony services
ADAMANTIUM
87
WP2
2009-05-28
VoIP Service



The VoIP service commonly occurs between a mobile
handset and a SIP voice/video terminal (hard or
softphone)
The components are connected via an IMS network
Perceived QoS is controlled by the MCMS which sets
the necessary parameters in order to maintain the
needed quality
ADAMANTIUM
88
WP2
2009-05-28
VoIP Features

Scenario

Two PQoS-aware UE terminals IMS-compatible (SIP voice/video
terminal softphone or hardphone)
 Adaptation capabilities of ADAMANTIUM would be located at UMTS or
IP network

Codec

Voice compression
 Selected: AMR
 narrow band codec
 8 different bit rates
 Others: iLBC, Speex, G.729
 Video compression
 MPEG-2, MPEG-4, H.263 and H.264
 15-30 frames per second
 Spatial resolution depends on the user’s terminal
 QCIF video (176 x 144) - mobile phones
 320x240 - PDAs
ADAMANTIUM
89
WP2
2009-05-28
VoIP Features

Transport protocol



User Terminal




RTP as voice and video payload transport protocol
RTCP for controlling voice and video data streaming
Capable of negotiating transmission parameters
PQoS aware
Soft or hard phone
Signalling protocol




SIP used as signalling protocol
SDP used to describe the multimedia session
Parameters defined to describe the necessary services and QoS
features
Control session messages are forwarded to the MCMS
ADAMANTIUM
90
WP2
2009-05-28
ADAMANTIUM architecture
ADAMANTIUM
91
WP2
2009-05-28
ADAMANTIUM
92
WP2
2009-05-28