The S-CSCF is located in the home network and performs session control and registration services for users. During a session, S-CSCF maintains a session.
An Enhanced IMS Architecture Featuring Cross-Layer Monitoring and Adaptation Mechanisms Lemonia BOULA, Harilaos KOUMARAS, Anastasios KOURTIS Institute of Informatics and Telecommunications, NCSR Demokritos, Patriarchou Grigoriou, Aghia Paraskevi, Athens Greece Tel: +30 210 650 3107, Fax: + (30) 210 653 21 75 Email: {lboula,koumaras, kourtis}@iit.demokritos.gr Abstract IP Multimedia Subsystem (IMS) entails novel business opportunities for pioneering and emerging multimedia services, such as IPTV and VoIP video call applications. However, this strong commercial interest on this promising convergent IMS environment is balanced by the lack of efficient user/customer-centric network management mechanisms. ADAMANTIUM project proposes an IMS-compatible Multimedia Content Management System (MCMS) focused on performing dynamic cross layer in terms of perceptual quality for IPTV and VoIP services. This paper specifies and defines the various monitoring and adaptation modules that must be developed within Open Core IMS testbed architecture towards this enhanced IMS architecture. Keywords: IMS, PQoS, VoIP, IPTV, Video.
1. Introduction The convergence of multimedia services with mobile/fixed networks and broadcast-interactive applications is creating new demands for high quality and user responsive service provision management. The predominant candidate for this convergence is IMS, originally defined by 3GPP for next generation mobile networking applications based on SIP (Session Initiation Protocol) as the basic common signalling protocol [1]. As recent public trials have shown, IMS technology still suffers a number of confining factors, amongst them are adaptation/monitoring mechanisms [2]. ADAMANTIUM project proposes an enhanced IMS 3GPP Release 7 architecture by the design, implementation and development of a central management node, namely MCMS (Multimedia Content Management System), which is in charge of interfering in the media delivery process when PQoS (Perceived Quality of Service) [3] degradation occurs
at the end user by performing real time cross layer adaptation across the media delivery chain, aiming at enhancing and optimizing the delivered PQoS level of the degraded service session. Towards this, when PQoS degradation [4] occurs at the user terminal, a PQoS alarm initiated by the mobile terminal device and initiated the MCMS monitoring interfaces, according to which a decision is taken what adaptation actions are necessary to be done in order to improve the delivered PQoS. This paper defines the specifications of the various components that are required by the proposed architecture of ADAMANTIUM (i.e. the IMS infrastructure), as well as the various elements and interfaces that are considered within the concept of the project, i.e. the Monitoring and Adaptation Modules across the media delivery chain, the Media Service Resource Function (MSRF), the DiffServ/MPLS (Differential Services/Multiprotocol Label Switching) core network, the Universal Mobile Telecommunications System (UMTS) access network, the ADAMANTIUM-compatible terminal devices (i.e. Terminal Adaptation Modules – TAM) and the proposed management entity: the innovative IMScompatible MCMS. The rest of the paper is organized as follows: Section 2 presents the proposed overall architecture of IMS Testbed, while Section 3 presents the monitoring and adaptation modules of the MCMS component. Section 4 presents the cross-layer adaptation scenario. Finally, Section 5 concludes the paper.
2. The proposed testbed architecture The PQoS-aware dynamic cross layer adaptation will be performed according to a. The monitored PQoS degradation at the end-user terminal device, which is also the triggering event for the initiation of the adaptation procedure, b. The time varying conditions of the Access and Transport network, c. The type of
the delivered service (i.e. Voice and/or Video for VoIP (Voice over IP) and IPTV applications), and d. The content dynamics (i.e. Action movie/Talk show or High/Low dynamic conversation).
d.
The Serving Call Session Control Function. (SCSCF)
The S-CSCF is located in the home network and performs session control and registration services for users. During a session, S-CSCF maintains a session state and interacts with service platforms and charging functions. There may be multiple S-CSCFs with (possibly) different functionalities within a network. These basic IMS components communicate with each other in order to handle user registration, establish sessions and provide the available services. The core IMS component communicates using signals with the users in order to set up sessions, the Media Server Resource Function (MSRF), as well as with the server components.
Figure 1. Overall Architecture of IMS Testbed Figure 1 depicts the overall architecture of IMS Testbed, which consists of five basic components: i. IMS (core system). The core IMS consists of the following components: a.
The Home Subscriber Server (HSS).
The HSS is the main data storage component for all subscriber and service-related data of the IMS. The main data stored in HSS include user identities, registration information, access parameters and service-triggering information. HSS contains IMS access parameters which include parameters like user authentication, roaming authorization and allocated SCSCF names. b.
The Interrogating Function.(I-CSCF)
Call
Session
Control
The I-CSCF has the role of a stateless proxy that, by using the indicated public identities of the caller or the callee, queries the Home Subscriber Server (HSS) and based on responses routes the message to the correct SCSCF. c.
The Proxy Call Session Control.(P-CSCF)
The P-CSCF handles signalling between users and the IMS and validates the request, forwards it to selected destinations and processes and forwards the response. There can be one or more P-CSCFs within an operator's network. P-CSCF communicates with ICSCF, S-CSCF and the user, so as to forward SIP requests and responses and handle session related information, like registration events, timers, policy issues, e.t.c. P-CSCF also communicates with the Policy Control Fuction (PCF).
ii.
Server Components (Application Servers)
The Server components are co-located within S-CSCF and include: a.
SIP Application Server. (SIP AS)
The SIP Application Server is the service relevant part in the IMS. The defined APIs enable developers to use almost any programming paradigm. The SIP AS is triggered by the S-CSCF which redirects certain sessions to the SIP AS based on filter information obtained from the HSS. Based on local filter rules, the SIP AS then decides which of the applications deployed on the server in which order should be selected for handling the session. During the execution of the service logic it is also possible for the SIP AS to communicate with the HSS to access additional subscriber related information. The Application Server may be located in the user's home network or in a third-party location (in a network or stand-alone AS). b.
The ParlayX Gateway.
The OCS-X, which handles the available web applications, is an implementation of the Parlay X Web Services specification for telecommunication networks. These interfaces provide a network abstraction through a very simple and easy to use API based on Web Services technology which can be used remotely from 3rd party domains and service providers. In the context of the 3GPPIMS these APIs are part of an Application Server, but they do not host the services itself. These interfaces enable third party service providers to make use of network resources remotely and host applications themselves.. c.
The XML (XDMS)
Document
Management
Server.
The XML (Extensible Markup Language) Document Management defines a common mechanism that makes user-specific service-related information accessible to the service enablers (e.g., PoC (Push-to-Talk over Cellular), IM (Instant Messaging), Conferencing, etc.) that need them. Such information is stored in the network at the IMS Application Layer on an XDMS where it can be located, accessed and manipulated. d.
The Presence Server.
The presence service is one of the most well known and used services in today's real time media applications as it has an enabler service role for many applications like Instant Messaging, Push To Talk over Cellular, Video Calls/Conferences and many others. The Presence Server came to fulfill all the internal projects requirements related to presence event, and in the same time, was designed with interoperability issues in mind: Implementing a standard compliant service on the top of IMS. iii.
Access Network.
The Access Network is a UMTS Network which provides wireless access to terminals like cell phones, PDAs, laptops etc. For performing the adaptation actions at the access network an IMS-compatible Policy Control Function (PCF) will be used and integrated. PCF’s components are the Policy and Charging Rule Function (PCRF) which uses dynamic and static domain policies that are stored in XML format and can be stored locally or remotely on an XDM Server (using OpenXCAP). Second, the Policy and Charging Enforcement Function (PCEF) is a Linux DiffServ router where policy rules are enforced using IP Tables.) A DiffServ prioritization queue is setup on the primary interface and the PCEF enforces the policy rules. iv.
Media Server Resource Function. (MSRF)
The MSRF has all the functionalities that can be found in an IMS-based MRF module and also includes the IMS Application Servers for IPTV. The MSRF, besides being a media server, provides mechanisms for bearer-related services such as bearer transcoding, through a controller (MRFC) and a processor (MRFP), and these tasks are performed in compliance with the MCMS decisions. From a practical point of view, the MSRF can be seen as a twofold entity composed of a MRF (according to IMS terminology) and a Media Server that enables and delivers IPTV. v.
Core Network.
The Core Network is the main transport network of the system mixes the capabilities of DiffServ/MPLS
technologies with final scope the best efficiency of a network which carries IPTV and VoIP services. MPLS in computer networking and telecommunications is a data-carrying mechanism, which emulates some properties of a circuit-switched network over a packetswitched network. The DiffServ architecture is based on a simple model, where traffic entering a network is classified and possibly conditioned at the boundaries (i.e. edge routers) of the network. MPLS and DiffServ appear to be orthogonal, which means that they are not inter-dependent since they are both different network policy techniques of providing QoS to network services. Therefore, both MPLS and DiffServ can be simultaneously and seamlessly used in a single network, optimizing the respective NQoS management.
3. The MCMS The proposed MCMS consists of several components each communicating with a part of the system in order to perform either monitoring or adaptation operation. Monitoring and adaptation operations are based on the algorithms proposed in [4] and [5]. The MCMS architecture will be based on a central decision module, the Action Engine Module (AEM), responsible for taking optimal adaptation decisions based on the monitoring of network and perceptual statistics, gathered by IMS-based (preferably SIP/SDP-based) monitoring and adaptation modules. Afterwards, the AEM exploiting theoretical mapping frameworks between NQoS (Network QoS) and PQoS will process all the selected statistics and define a perceptually optimal cross layer adaptation action. More specifically, for monitoring purposes the following modules are considered: −Multimedia Service Monitoring Module (MSMM) −Transport Network Monitoring Module (TNMM) −Access Network Monitoring Module (ANMM) For adaptation purposes, ADAMANTIUM considers the following modules, through which the optimal adaptation actions for PQoS optimization are applied: −Multimedia Service Adaptation Module (MSAM) −Transport Network Adaptation Module (TNAM) −Access Network Adaptation Module (ANAM)
Figure 2.MCMS Monitoring/Adaptation Modules 3.1 MCMS Monitoring Modules 3.1.1 Multimedia Service Monitoring Module (MSMM). The MSMM module in ADAMANTIUM is responsible for performing monitoring actions both at IMS Session Control level and at the endpoints of the communication. The information gathered and sent contains session identifier, caller/callee IPs and realms, media description according to 3GPP TS29214 v7.1.0 (application id, media type, max requested bandwidth ul/dl, flow status, sender/receiver (rs/rr) bandwidth, codec data) and the QoS class.
3.1.2 Transport Network Monitoring Module (TNMM). The TNMM module is used during the dynamic cross layer adaptation procedure for monitoring network statistics like packet loss, jitter, delay etc. at the DiffServ/MPLS core transport network. Towards this, the appropriate External Marking Modules (EMM) interface will be developed and integrated at the egress edge router of the core transport network for enabling interaction and communication with the TNMM of the MCMS. Considering the software-based nature of the AEM, the TNMM should be defined as a class within AEM source code, which will receive the provided the monitoring data from the egress core network router and provide them to the AEM. Considering this, the following monitoring actions will be performed by the egress router through the TNMM interface: Packet Loss, PQoS, Bit rate (bandwidth) per class.
3.1.3 Access Network Monitoring Module (ANMM). The ANMM (Access Network Monitoring Module) monitors the UMTS access network statistics
on a “per node” basis, exploiting historical data, which are updated in near real time by the UMTS performance management system at frequent time periods. Towards this, the appropriate External Marking Modules interface will be developed and integrated at the egress edge router of the access network for enabling interaction and communication with the ANMM of the MCMS. The AEM receives from ANMM the following information including source/destination address and port, qos_class_identifier – authorized qos classes, max_requested_bandwidth_uplink/downlink, quaranted_bitrate_uplink/downlink, session_id – flow_id (for each of the flows in a session), source/destination realms, usage, status and media description. In general, the monitoring modules of MCMS manipulate parameters such as the estimation of the perceived QoS, statistics about errors in the transport stream, information about both the sender and the receiver (IP, port) and the destined class that the estimation refers to. 3.2 MCMS Adaptation Modules 3.2.1 Multimedia Service Adaptation Module (MSAM). The MSAM (Multimedia Service Adaptation Module) performs adaptation actions at the end-user terminal device and in the MSRF (Multimedia Service Resource Function). The parameters that can be adapted for voice content and for video content are the jitter buffer size and buffer mode or buffer algorithm selection and the packetization parameters (frame numbers in a packet for voice or packet size for video). Codec type and codec mode (i.e. sender bit rate) can be adapted only for voice content. On the other hand, quantisation index (which can vary the video quality and bit rate), frame rate (or temporal resolution), video size (or spatial resolution), packet/frame dropping mechanism (whereby packets from less important frames such as the B-frames in MPEG codec are dropped first) and filtering scheme for dropping high frequency DCT domain coefficients can be adapted only for video content The MSAM can also send adaptation actions to the MSRF. The parameters that can be adapted in the MSRF are the following: codec type; bit rate; video resolution.
3.2.2 Transport Network Adaptation Module (TNAM). The TNAM applies the adaptation actions to the DiffServ/MPLS-enabled core transport network
through the Internal Marking Module (IMM), which will be developed and integrated at the ingress router of the core network. The IMM receives the adaptation actions from the TNAM and translate them to DiffServ/MPLS compatible commands, which are finally applied by marking appropriately the incoming traffic. Considering the software-based nature of the AEM, the TNAM should be defined as a class within AEM source code, which will receive the adaptation actions from the AEM and provide them to the IMM of the ingress core network. Considering this, the following adaptation actions are performed by the IMM: MPLS LSP update, DiffServ Behaviour Aggregate update (DS Mark), Combined update of them.
achieve end-to-end PQoS maximization. As shown in the figure, real-time monitoring provides important information, includes from source (e.g. content dynamics), core/access network (e.g. network/link QoS) and terminal (e.g. delivered PQoS). Cross-layer adaptation includes service layer adaptation (e.g. source/terminal coding parameters and FEC), network layer adaptation (e.g. traffic policies) and link layer adaptation (e.g. service classification), and is controlled by an intelligent action engine within the MCMS system. The two most promising multimedia services, i.e. VoIP (voice/video call) and IPTV (live IPTV and Video on Demand) will be used as a vehicle to demonstrate PQoS-aware MCMS system in the project.
3.2.3 Access Network Adaptation Module (ANAM). The ANAM applies the adaptation actions, decided by the AEM of the MCMS, to the UMTS access network through the IMS PCF module. The PCF in turn applies them at the GGSN (Gateway GPRS Support Node) by performing service bearer classification in order to improve its QoS characteristics and therefore enhance the delivered PQoS level. The AEM sends to the ANAM information including source/destination address and port, qos_class_identifier – authorized qos classes, max_requested_bandwidth_uplink/downlink, quaranted_bitrate_uplink/downlink, session_id – flow_id (for each of the flows in a session), source/destination realms, usage, status and media description. Adaptation modules of MCMS manipulate parameters such as the estimation of the perceived QoS, statistics about errors in the transport stream (per class), information about both the sender and the receiver (IP, port, buffer size and algorithm used, codec used),information about the destined class that the adaptation command refers to (class identifier, guaranteed bitrate), information about the current session (framerate, video dimensions).
4. The Cross-Layer Adaptation Scenario An overview of the proposed PQoS-aware MCMS concept is depicted in Figure 3. On the left, a multimedia service provision full cycle from content creation, content transport (via core and access networks) to content consuming is shown (from top to bottom). On the right, Multimedia Content Management System (MCMS) interacts with each element in the service provision chain via real-time monitoring and adaptation/control mechanisms to
Figure 3: Conceptual diagram of the MCMS The new MCMS management system moves away from traditional NQoS-centric adaptation/management scheme and will be able to achieve an end-to-end PQoS optimisation based on a user/customer-centric approach. This will provide an efficient solution/approach for future networked multimedia making it possible to maintain the quality of the media at every step of the media lifecycle from creation to consumption. Towards this, at the Service/Multimedia Server the proposed MCMS module will be able to monitor and adapt the encoding parameters (e.g. spatial and temporal resolution, encoding scheme structure, bit rate) and the respective streaming/packetization schemes (i.e. streaming protocol, packet size, hinted encoding for streaming optimization). Moreover depending on the content dynamics of the requested service, the optimal FEC value will be applied in order to enhance the error resilience of the service. In the
framework of the ADAMANTIUM Project the latest encoding/compression techniques will be used in both IPTV and VoIP services (e.g. MPEG-4, H.264 for video and AMR, iLBC for voice applications). The IPTV refers to the service where a digital television stream is delivered using the Internet Protocol over a network infrastructure. IPTV is often provided in conjunction with Video on Demand (VoD) and may be bundled with Internet services such as Web access and VoIP. At the Core/Transport Network Operator, a DiffServ/MPLS policy mechanism is considered, which is capable of treating the incoming traffic according to the respective DiffServ/MPLS marking and classification rules applied by the edge routers. The MCMS, depending on the nature of the delivered service (i.e. Video and/or Voice for IPTV or VoIP), its dynamics level (High or Low) and the perceptual importance of the respective traffic packets (e.g. some packets are perceptually more important than others due to the interdependency of the encoded multimedia service) will perform the appropriate DiffServ/MPLS Marking at the edges of the transport network. In this framework ADAMANTIUM project will research the perceptual impact of the various DiffServ/MPLS Traffic Classes (i.e. Assured Forwarding--AF, Expedited Forwarding-EF, Best Effort-BE) on the delivered multimedia services, in order to develop a decision repository according to which, the appropriate traffic marking and classification will be selected for retaining/enhancing the requested/delivered perceptual level. Moreover, during the streaming/delivery of the multimedia services through the core network, the MCMS will monitor and use the respective NQoS statistics, such as delay, jitter and packet loss as a decision point on applying the appropriate traffic classification and policy decision. At the access network, a UMTS technology is considered, where the MCMS is able via the GGSN to perform traffic policy adaptations to the incoming traffic (i.e. the service bearers) by exploiting the UMTS service classes (e.g. background class, media class etc.). This service prioritization provides specific QoS constraints to the adapted service, which in turn cause perceptual enhancement and therefore improvement of the user experience. Moreover, the MCMS will be able to monitor near real time traffic statistics for the access network that will be further processed by the MCMS for defining the optimal adaptation action for PQoS optimization. Finally, at the end-user equipment, except from the monitoring of the delivered PQoS level and the Carrier-to-Noise Ratio (CNR), adaptation actions at the service level are considered, which enhance the
robustness and the error resilience of the streaming service.
5. Conclusions In this paper, it is shown that the existing IMS Release 7 can be updated in order to include PQoS-aware cross layer adaptation actions by adding the MCMS, without any further requirements, changes or prerequsites to the existing architecture. Based on SIP/Diameter messages, the proposed overall ADAMANTIUM architecture is proven to be easily applicable and fully compatible to already installed and deployed IMS infrastructure. Therefore, the switch-over from the legacy IMS to the novel PQoS-aware one, based on the specification of this deliverable, can be performed efficiently and in an affordable way from the business aspect, without further requirements for changes to the infrastructure.
Acknowledgement The work in this paper has been performed within the research framework of FP7 ICT-214751 ADAMANTIUM Project.
References [1] M. Poikselka, G. Mayer, H. Khartabil, A. Niemi, “The IMS IP Multimedia Concepts and Services”, Wiley, 2006. [2] G. Camarillo, M. A. Garcia-Martin “The 3G IP Multimedia Subsystem”, Wiley, 2004. [3] H. Koumaras, A. Kourtis, D. Martakos, J. Lauterjung, “Quantified PQoS Assessment Based on Fast Estimation of the Spatial and Temporal Activity Level”, Multimedia Tools and Applications, Springer Editions, 34(3), 355-374, Sep. 2007. [4] H. Koumaras, F. Liberal, L. Sun, “PQoS Assessment Methods for Multimedia Services”, Chapter contribution in "Wireless Multimedia: Quality of Service and Solutions", Editors Dr. Nikki Cranley, Dr. Liam Murphy, IGI Global Pub. ISBN: 978-1-59904-820-8, July 2008 [5] H. Koumaras, A. Kourtis, “End-to-End Prediction Model of Video Quality and Decodable Frame Rate for MPEG Broadcasting Services”, International Journal On Advances in Networks and Services, Vol.1, No.1, Jan 2009
