* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download System Architecture Definition and Specifications
Survey
Document related concepts
Multiprotocol Label Switching wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Internet protocol suite wikipedia , lookup
Distributed firewall wikipedia , lookup
Video on demand wikipedia , lookup
Computer network wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Deep packet inspection wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Network tap wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Transcript
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