IP Multimedia Subsystem (IMS) Handbook

IP Multimedia Subsystem (IMS) Handbook IP Multimedia Subsystem (IMS) Handbook Edited by Syed A. Ahson Mohammad Ily...

Author: Mohammad Ilyas | Syed A. Ahson

317 downloads 1967 Views 18MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

IP Multimedia Subsystem

(IMS) Handbook

IP Multimedia Subsystem

(IMS) Handbook Edited by

Syed A. Ahson Mohammad Ilyas

Boca Raton London New York

CRC Press is an imprint of the Taylor & Francis Group, an informa business

CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487‑2742 © 2009 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid‑free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number‑13: 978‑1‑4200‑6459‑9 (Hardcover) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher can‑ not assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copy‑ right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978‑750‑8400. CCC is a not‑for‑profit organization that pro‑ vides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Library of Congress Cataloging‑in‑Publication Data IP multimedia subsystem (IMS) handbook / editors, Syed A. Ahson, Mohammad Ilyas. p. cm. Includes bibliographical references and index. ISBN 978‑1‑4200‑6459‑9 (alk. paper) 1. Internet Protocol multimedia subsystem. I. Ahson, Syed. II. Ilyas, Mohammad, 1936‑ III. Title. TK5105.15.I64 2008 006.7‑‑dc22 Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com

2008032888

Contents Preface...........................................................................................................ix The Editors....................................................................................................xi Contributors............................................................................................... xiii

Section 1 Concepts 1 IMS Service, Models, and Concepts.................................................... 3 Emmanuel Bertin and Noël Crespi

2 IMS—A Secure Architecture for All IP Networks.......................... 27 Muhammad Sher and Thomas Magedanz

3 Peer-to-Peer Features in the IP Multimedia Subsystem................. 73 Adetola Oredope and Antonio Liotta

4 On the Support of Media Functions within the IMS..................... 87 Jean-Charles Grégoire and Admela Jukan

Section 2 Technologies 5 The FOKUS Open IMS Core—A Global IMS Reference Implementation................................................................................ 113 Peter Weik, Dragos Vingarzan, and Thomas Magedanz

6 Next-Generation Grid Support over the SIP/IMS Platform........ 133 Vicente Olmedo, Antonio Cuevas, Victor Villagrá, and José I. Moreno

7 Policy-Based QoS Control for a Convergence Network............... 157 Younghan Kim and Youngsuk Lee

8 OSA Service Capability Server—Parlay/Parlay X......................... 169 Moo Wan Kim and Ryozo Ito

9 Internetworking of 3GPP and WLAN and Wimax Networks..... 191 Fangmin Xu, Luyong Zhang, Zheng Zhou, and Wei Zhong

vi

Contents

10 IM-SSF Application Server—Interworking with CAMEL......... 215 Moo Wan Kim and Ryozo Ito

11 Distributed IMS............................................................................... 243 Marcin Matuszewski

Section 3 Services 12 Service Delivery Platforms and Multimedia Service Design... 265 Christopher J. Pavlovski

13 The Integration of IMS into Service Delivery Platforms Based on Service-Oriented Architectures.................................... 307 Niklas Blum, Peter Weik, and Thomas Magedanz

14 Service Orchestration in IMS......................................................... 329 Anahita Gouya and Noël Crespi

15 Instant Messaging and Presence Service (IMPS)........................ 345 Whai-En Chen

16 Multiparty Services in the IP Multimedia Subsystem............... 363 Iván Vidal, Ignacio Soto, Francisco Valera, Jaime García, and Arturo Azcorra

17 IMS-Based Conferencing Services: An Engineering Approach........................................................................................... 383 Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, and Simon Pietro Romano

18 IMS-Based IPTV.............................................................................. 411 Oliver Friedrich, Stefan Arbanowski, Adel Al-Hezmi, and Robert Seeliger

19 IPTV Modeling and Architecture over IMS................................ 443 David López, Eugen Mikoczy, José Ignacio Moreno, Antonio Cuevas, and Enrique Vázquez

20 SIP-Based Prepaid Application Server......................................... 473 Mario Weber

21 JAIN SLEE Platforms for IMS Application Servers.................... 493 Igor Vukomanović

Contents

vii

22 Role of OSS/BSS in the Success of IMS....................................... 509 Jithesh Sathyan

Index........................................................................................................... 531

Preface Fixed-mobile convergence and voice-data networks have merged next-generation, value-added applications and integrated multimedia services, combining Web browsing, instant messaging, presence, voice over IP, video conferencing, application sharing, telephony, unified messaging, multimedia content delivery, etc. on top of different network technologies. The convergence of the communications networks is motivated by the need to support many forms of digital traffic as well as to amortize implementation and operational costs of the underlying networks. Historically, the approach to build and deploy multimedia services has focused upon single-point solutions. These solutions worked well to address the specific needs of the intended service or related set of services; however, they possess shortcomings in extensibility to cater to the newer and emerging multimedia services. A more pragmatic approach is to develop a single consolidated platform that is capable of supporting a wide variety of multimedia services over several communication networks. The IP multimedia subsystem (IMS) is a standardized next-generation networking architecture that has been conceived for telecom operators willing to provide advanced services on top of both mobile and fixed networks. The IMS is a service-oriented architectural framework that aims to provide existing and future Internet services to both fixed and mobile end users over a multi-access, all-IP platform. The 3rd Generation Partnership Project (3GPP) and 3GPP2 have developed the IMS to provide service delivery platforms for a converged communication paradigm. The IMS provides ways for integrating existing Internet services with future ones. It is a well-designed service platform, using open and standardized Internet protocols and respecting the Internet paradigm of data transport and application separation with links between these two layers. The IMS offers telecom operators the possibility to build an open IP-based service infrastructure that will enable easy deployment of new, rich multimedia communication services mixing telecom and data services. The IP multimedia subsystem grants the network operator the role of service broker. Multimedia calls are a service inherent to the IMS, but many more services are being developed on top of the IMS service platform to build a rich service environment enticing the users to employ it. The IMS is an IP-based architecture designed to provide a set of essential functionalities that support the delivery of the next-generation multimedia services that are envisioned in the future of third-generation networks. The IMS architecture has been defined to provide the user with access to a wide range of services, which are implemented by means of application servers. The IMS has resulted in an environment that introduces new services more quickly than ever before as well as exciting new concepts such as ix

Preface

reusable service components and real-time integration. The IMS fills the gap between the existing traditional telecommunications technology and Internet technology, allowing operators to offer new, innovative, and compelling services; it represents a standardized, reusable platform that provides a better way to roll in, roll out, deploy, integrate, and expand consumer and enterprise voice and data services. There is increased interest in the IMS due to its ability to revolutionize the end-user experience with new and innovative services. The IP Multimedia Subsystem (IMS) Handbook provides technical information about all aspects of the IMS. The areas covered in the handbook range from basic concepts to research-grade material, including future directions. The handbook captures the current state of IMS technology and serves as a source of comprehensive reference material on this subject. There are three sections in the handbook: Concepts, Technologies, and Services. It has a total of 22 chapters authored by 50 experts from around the world. The targeted audience for the handbook includes professionals who are designers or planners for IMS systems, researchers (faculty members and graduate students), and those who would like to learn about this field. This handbook has the following specific salient features: • to serve as a single comprehensive source of information and as reference material on IMS technology; • to deal with an important and timely topic of emerging technology of today, tomorrow, and beyond; • to present accurate, up-to-date information on a broad range of topics related to IMS technology; • to present material authored by the experts in the field; and • to present the information in an organized and well-structured manner. Although the handbook is not precisely a textbook, it can certainly be used as a textbook for graduate courses and research-oriented courses that deal with the IMS. Any comments from readers will be highly appreciated. Many people have contributed to this handbook in their unique ways. The first and the foremost group that deserves immense gratitude is the group of highly talented and skilled researchers who have contributed 22 chapters to this handbook. All of them have been extremely cooperative and professional. It has also been a pleasure to work with Nora Konopka, Jessica Vakili, and Judith Simon of CRC Press and we are extremely grateful for their support and professionalism. Our families have extended their unconditional love and strong support throughout this project and they all deserve very special thanks. Syed Ahson Plantation, Florida Mohammad Ilyas Boca Raton, Florida

The Editors Syed Ahson is a senior staff software engineer with Motorola, Inc. He has played a leading role in and contributed significantly to the creation of several advanced and exciting cellular phones at Motorola. He has extensive experience with wireless data protocols (TCP/IP, UDP, HTTP, VoIP, SIP, H.323), wireless data applications (Internet browsing, multimedia messaging, wireless e-mail, firmware over-the-air update), and cellular telephony protocols (GSM, CDMA, 3G, UMTS, HSDPA). Prior to joining Motorola, he was a senior software design engineer with NetSpeak Corporation (now part of Net2Phone), a pioneer in voice over IP telephony software. Ahson is a co-editor of the three-volume WiMAX Handbook (CRC Press) and has authored “Smartphones,” a research report that reflects on the smartphone market and technologies for the International Engineering Consortium (IEC). He has published several research articles and teaches computer engineering courses as adjunct faculty at Florida Atlantic University in Boca Raton, Florida, where he introduced a course on smartphone technology and applications. He received his MS degree in computer engineering in 1998 at Florida Atlantic University and his BSc degree in electrical engineering from Aligarh University, India, in 1995. Mohammad Ilyas received his BSc degree in electrical engineering from the University of Engineering and Technology, Lahore, Pakistan, in 1976. From March 1977 to September 1978, he worked for the Water and Power Development Authority in Pakistan. In 1978, he was awarded a scholarship for his graduate studies and completed his MS degree in electrical and electronic engineering in June 1980 at Shiraz University, Shiraz, Iran. In September 1980, he joined the doctoral program at Queen’s University in Kingston, Ontario, Canada. He completed his PhD degree in 1983. His doctoral research was about switching and flow control techniques in computer communication networks. Since September 1983, he has been with the College of Engineering and Computer Science at Florida Atlantic University, Boca Raton, Florida, where he is currently associate dean for research and industry relations. From 1994 to 2000, he was chair of the Department of Computer Science and Engineering. From July 2004 to September 2005, he served as interim associate vice president for research and graduate studies. During the 1993–1994 academic year, he was on sabbatical leave with the Department of Computer Engineering, King Saud University, Riyadh, Saudi Arabia. Dr. Ilyas has conducted successful research in various areas, including traffic management and congestion control in broadband/high-speed communication networks, traffic characterization, wireless communication networks, performance modeling, and simulation. He has published one book, eight handbooks, and more than 150 research articles. He has supervised 11 xi

xii

The Editors

PhD dissertations and more than 37 MS theses to completion. He has been a consultant to several national and international organizations. Dr. Ilyas is an active participant in several IEEE technical committees and activities, a senior member of IEEE, and a member of ASEE.

Contributors Adel Al-Hezmi Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany Alessandro Amirante Università di Napoli Federico II, Napoli, Italy Stefan Arbanowski Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany Arturo Azcorra IMDEA Networks, Madrid, Spain Universidad Carlos III de Madrid, Madrid, Spain Emmanuel Bertin Orange Labs, France Telecom, Caen, France Niklas Blum Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany Tobia Castaldi Università di Napoli Federico II, Napoli, Italy Whai-En Chen National I-Lan University, Taiwan, Republic of China Noël Crespi GET-INT—Institut National des Télécommunications, Evry,. France Antonio Cuevas Universität Stuttgart, Stuttgart, Germany Oliver Friedrich Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany Jaime García Universidad Carlos III de Madrid, Madrid, Spain Anahita Gouya Institut National des Télécommunications, Evry, France Jean-Charles Grégoire EMT-INRS University of Quebec, Quebec, Canada Ryozo Ito Hewlett-Packard, Tokyo, Japan Admela Jukan EMT-INRS University of Quebec, Quebec, Canada Moo Wan Kim Tokyo University of Information Sciences, Tokyo, Japan xiii

xiv

Contributors

Younghan Kim Soongsil University, Seoul, South Korea Youngsuk Lee Soongsil University, Seoul, South Korea Antonio Liotta University of Essex, Colchester, United Kingdom David López Universidad Carlos III de Madrid, Madrid, Spain Thomas Magedanz Fraunhofer Institute FOKUS, Berlin, Germany Marcin Matuszewski Nokia, Espoo, Finland Eugen Mikoczy Slovak University of Technology, Bratislava, Slovakia Lorenzo Miniero Università di Napoli Federico II, Napoli, Italy José Ignacio Moreno Universidad Carlos III de Madrid, Madrid, Spain Vicente Olmedo Universidad Politécnica de Madrid, Madrid, Spain Adetola Oredope University of Essex, Colchester, United Kingdom Christopher J. Pavlovski IBM, St. Leonards, New South Wales, Australia Simon Pietro Romano Università di Napoli Federico II, Napoli, Italy Jithesh Sathyan Infosys Technologies Limited, Bangalore, India Robert Seeliger Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany Muhammad Sher Technical University of Berlin, Berlin, Germany Ignacio Soto Universidad Carlos III de Madrid, Madrid, Spain Francisco Valera Universidad Carlos III de Madrid, Madrid, Spain Enrique Vázquez Universidad Carlos III de Madrid, Madrid, Spain Iván Vidal Universidad Carlos III de Madrid, Madrid, Spain Victor Villagrá Universidad Politécnica de Madrid, Madrid, Spain Dragos Vingarzan Fraunhofer FOKUS Research Institute for Open Communication Systems, Berlin, Germany

Contributors

xv

Igor VukomanoviĆ KATE-KOM, Zagreb, Croatia Mario Weber KATE-KOM, Zagreb, Croatia Peter Weik Technical University of Berlin, Berlin, Germany Fangmin Xu Beijing University of Posts and Telecommunications, Beijing, Republic of China Luyong Zhang Beijing University of Posts and Telecommunications, Beijing, Republic of China Wei Zhong Duke University, Chapel Hill, North Carolina Zheng Zhou Beijing University of Posts and Telecommunications, Beijing, Republic of China

Section 1

Concepts

1 IMS Service, Models, and Concepts Emmanuel Bertin and Noël Crespi

contents Introduction.............................................................................................................. 3 The Foundations of IMS Services..........................................................................4 From IN to NGN............................................................................................. 4 From NGN to IMS........................................................................................... 7 IMS Service Capabilities and OMA Enablers.............................................9 IMS Service Model................................................................................................. 12 IMS Brings New Types of Services............................................................ 12 The Link between Services Seen by the User........................................... 13 Technical Functions...................................................................................... 14 Relationship between Service and Technical Function.......................... 16 Example of the Push-to-Talk over Cellular........................................................ 17 PoC Service Seen from the User’s Perspective......................................... 18 PoC Service and Service Enablers.............................................................. 19 Technical Functions for PoC Service.......................................................... 19 A Comprehensive View of IMS Services...................................................22 Conclusion...............................................................................................................22 Glossary................................................................................................................... 24 References............................................................................................................... 24

Introduction NGN (next-generation network) is a concept that has been introduced to take into account the new situation and changes in the telecommunications fields. This new situation is characterized by a number of aspects: the deregulation of markets, the new demand from users for innovative services to meet their needs, and the explosion of digital traffic (increase of Internet usage). The introduction of NGN comprises economic and technical aspects. Economically, it allows increasing productivity by creating new usage [1] based on user preferences and related to voice and data services (e.g., voice over IP,

IP Multimedia Subsystem (IMS) Handbook

instant messaging, presence, streaming, and push to talk). It also permits reducing costs for infrastructure maintenance, with only one type of transport network instead of specific ones for each access network. Technically, NGN makes the network architecture flexible in order to define and introduce new services easily. The cornerstone of the service architecture for next-generation networks is the IMS (IP multimedia subsystem) architecture, standardized by 3GPP (3rd Generation Partnership Project). The IMS offers telecom operators the possibility to build an open IP-based service infrastructure that will enable easy deployment of new, rich multimedia communication services mixing telecom and data services. The conception of IMS services is a key challenge for the telecom market. IMS services are fundamentally tailored to user preferences, rely seamlessly on multiple access networks, and bundle multiple service features (e.g., voice/video connectivity, community tools, presence, conferencing, gaming, and TV broadcasting). The architecture and technical aspects of the IMS architecture are well addressed by the standardization bodies. However, a clear model of what an IMS service is (and what it is not) is not proposed by these bodies. The objective of this chapter is to detail the concepts behind IMS services and to propose a way to link IMS service, service building blocks, and technical functions. This chapter is divided into three sections. In the first section, we present a survey of IMS services, starting by briefly introducing NGN architecture and then describing IMS service architecture and the OMA (Open Mobile Alliance) achievements. In the second section, we present how IMS services can be linked with service building blocks and with technical functions. In the third section, we illustrate the previous section with the case study of the push-to-talk over cellular service (PoC), specified by the OMA.

The Foundations of IMS Services From IN to NGN The concept of intelligent networks (INs) developed in the 1980s was a precursor of the NGN. The principle of INs is to separate clearly the switching functions from the service data and logic located in an external entity: the service control point (SCP). A new functional entity is added to the TDM (Time Division Mutiplexing) switch, the service switching point (SSP), which interfaces between the service logic and the switch itself. An interface based on the intelligent network application part (INAP) protocol family is introduced between the SSP and the SCP. The services are no longer developed in the TDM switch—as with the concept of global system for mobile com-

IMS Service, Models, and Concepts

munications (GSM) and integrated services digital network (ISDN) supplementary services—but rather are implemented in the SCP. The INAP and associated procedures allow the SCP to control and monitor the switch. The intelligent network introduced the concept of a service independent building block (SIB) for reusable service functions. A service could thus be thought of as a composition of various SIBs. But this goal was not fully achieved because of a lack of independence with INAP protocol, a lack of software reusability, and a lack of openness by manufacturers and operators. As a consequence, INs deployed today rely on a monolithic architecture and service platforms do not offer flexible services. In addition, as the service logic is executed in external entities, triggering multiple services for one call requires having service interaction management mechanisms. This issue, known as feature interaction, is one of the most complex problems encountered in IN and considerable work has been done on it. However, this work cannot be directly applied to the NGN because of the service and architectural differences between IN and NGN. The promise of the NGN, as defined in the late 1990s, was to offset these shortcomings by moving from a vertical approach (where access, control, and services are closely tied) to a horizontal approach (where each layer provides reusable elements to other layers). Specification work is ongoing at the International Telecommunication Union (ITU)-T (as described in Knightson, Morita, and Towle [2]) to formalize the separation (e.g., through standard protocols or application programming interfaces [APIs]) between • the transport stratum that is composed of transfer functions from various access networks (UMTS terrestrial radio access network [UTRAN], wireless local area network [WLAN], xDSL) and from the core networks, control functions for these transfer functions (e.g., network attachment control or resource and admission control), the transport user profiles (e.g., to store the data linked to network attachment), and the media handling functions (e.g., for playing announcements or for transcoding); and • the service stratum composed of access-independent service control functions (e.g., session establishment control or service triggering control), application functions, and service user profiles. Application functions should be independent from the service control functions and should offer flexibility (e.g., by using open software mechanisms) to answer user needs. This NGN architecture with two strata is defined at the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (Figure 1.1). The NGN architecture may also be represented with three layers instead of two strata (this is, for instance, the case at the European Telecommunications Standards Institute [ETSI]). In this case, service control functions and transport control functions are grouped into a control layer. The


Service Stratum

Service User Profiles

End-User Functions

Transport User Profiles

Transport Stratum Control flows

Application Functions

Service Control Functions

Transport Control Functions

Media Handling Functions

Transfer Functions

Media flows

Figure 1.1 NGN technical architecture [2].

separation thus involves a transfer layer (with transfer functions), a control layer (with transport control functions and service control functions), and an application layer (with application functions). We can draw a parallel between IN and NGN architectures: The service control function (usually implemented with a session initiation protocol [SIP] proxy) is the NGN counterpart of the TDM switch/SSF (service selection function) and the application function (for example, implemented with a SIP application server) is the NGN counterpart of the service control function (SCF). In both architectures, the triggering criteria have been defined in order not to invoke services systematically but only when required. However, there is a key difference between those architectures regarding the triggering mechanisms. In IN, the SCF controls the SSF using INAP, which is independent of the call control protocols. In the NGN architectures, the application function is inserted in the signaling path; therefore, all SIP signaling requests and responses can be intercepted by the entity controlling the services. Indeed, the IN concept of “point of control” (i.e., an entity that can control the SSP and modify the signaling at any time) does not exist in the NGN context. This concept is replaced by the notion of application function present in the signaling path, which can modify SIP messages to execute a service logic. The consequence of this fundamental difference in signaling and architecture is that mechanisms defined in IN for feature interaction are mostly not applicable for SIP.


From NGN to IMS The IMS architecture is a realization of NGN principles, relying on the SIP protocol for the session control. The IMS specifications [3] define the whole multimedia session control architecture on top of the universal mode telecommunications system (UMTS) packet-switched domain. With IMS, operators provide both reliable session control and better integrated services. Because IMS is solving architectural issues for SIP deployments (as detailed in Bertin, Bury, and Lesieur [4]), it is now seen as a guideline for all SIP deployment using the client/server paradigm. While the IETF (Internet Engineering Task Force) has standardized the SIP protocol but not the associated architectures [5], the 3GPP has defined with precision the architectures and the procedures to ensure roaming, scalability, security, and reliability. Moreover, the IMS specifications are not intrinsically linked to mobile networks [6]. IMS was, for the most part, conceived independently from the UMTS packetswitched domain and can be adapted to other types of access networks. 3GPP has specified the interface between IMS and WLAN access networks (IMS release 6) [7]. The ETSI TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking) project specifies the adaptations controlling xDSL access networks with IMS [8]. In addition to IMS, TISPAN is also defining other subsystems such as public switched telephone network (PSTN)/ISDN emulation for PSTN replacement (which will be needed in Europe between 2008 and 2012). The major elements related to service architecture are the following: • S-CSCFs (serving call state control functions) implement service control functions (session control and service triggering). • HSS (home subscriber server) is the central service and network database. It implements the service user profiles (as well as the transport user profiles). • ASs (application servers) implement the application functions, providing session-related services to users. The ASs offer APIs like OSA/Parlay or SIP servlet for application execution. Concerning user identity, the user is represented in IMS by several identifiers. Public identities are routable addresses that can be communicated to the contacts of the user and can be used to reach this user (e.g., sip:[email protected] or tel:+33123456789). Private identities belong to the IMS operator and are stored in the SIM (subscriber identity module) card. The same user may have several private user identities and several public user identities, but only one private identity is stored per SIM card (Figure 1.2). Concerning service triggering, IMS provides an application triggering architecture based on filter criteria and service points triggers (SPTs) [9]. Initial filtering criteria (iFC) allow the S-CSCF to decide which services should be invoked during a SIP session or transaction and in which order they should apply. The SPTs are the points in the SIP signaling on which filter

IP Multimedia Subsystem (IMS) Handbook Public User Identity IMS Subscription

Private User Identity

Public User Identity Public User Identity

Service Profile

Service Profile

Figure 1.2 IMS user identities in IMS release 5 [3].

Application Server Service Logic Service Platform Trigger Points HSS

SIP Interface SIP

iFC S-CSCF SIP

S P T

Filter Criteria

SIP

Figure 1.3 Application server triggering architecture [9].

criteria can be set. The filter criteria are distributed among the S-CSCF, HSS, and IMS application server, as shown in the Figure 1.3. iFCs are stored in the HSS as a part of the service profile. They are downloaded to the S-CSCF upon user registration or upon a terminating initial request for an unregistered user. They are active during the registration lifetime or until the service profile is changed. Filter criteria should contain the following information, structured in an XML format: • the address of the AS to be contacted; • the priority of the filter criteria providing the sequence in which the criteria will be applied;


• the SPTs, which may contain the following information: SIP method, presence or absence of any header, content of any header, session description information, etc.; • default handling if the AS is not reachable; and • optional service information, added to the message body before it is sent to the AS. During the registration phase, an S-CSCF is assigned to control user services. The service profile (containing iFCs) of the user is downloaded from the HSS to the S-CSCF. When the S-CSCF receives a SIP request matching the iFC, it invokes the associated service by forwarding this SIP request to the AS indicated in the iFC. iFCs are only applied to initial SIP requests (i.e., the requests initiating a SIP session or transaction: INVITE, SUBSCRIBE, REGISTER, OPTION, etc.); consequently, the service invocation can be done only statically in the SIP session or transaction initiation phase. A user may subscribe to several services, and as a consequence several iFCs may be present in the service profile. When the S-CSCF receives an initial SIP request, it checks whether it matches the iFC that has the highest priority for this user. If it does not match, the S-CSCF checks the next iFC, in the predefined priority order. If it matches, the S-CSCF forwards the request to the indicated AS. This AS executes the service logic, eventually modifies the request, and sends it back to the S-CSCF. The S-CSCF performs the same processing with the next unexecuted iFC. The S-CSCF continues this process until all the iFCs are checked. The AS may also suppress the information required to trigger the iFC (e.g., replacement of public identity by a globally routable user agent [UA] uniform resource identifier [URI]) or locally end the request as a part of the service logic (e.g., a prepaid account without remaining credit). These mechanisms will be used to build future communication services with the IMS. 3GPP had specified a SIP AS called service capability interaction manager (SCIM) for managing the interactions between application servers, but neither “the service invocation functionalities over ISC” nor “the service interaction management functionalities of SCIM” are specified in the standards [14]. These points are detailed in Chapter 14, “Service Orchestration in IMS.” IMS Service Capabilities and OMA Enablers The business purpose of the IMS is to enable the building of innovative services in a flexible way. IMS services will include multiple service features like chat, instant messaging, voice, video, presence, address book, and TV broadcasting [10,11]. If all these features are deployed in an uncoordinated way by a service provider, the user will have to handle the interaction between the services (e.g., by entering the same personal preferences several times). In addition, advanced services that combine many service features (like routing voice calls according to the originating community and the availability state)

10


are not possible if there is no coordination between features. The answer to improving user experience is to build a coherent service environment by standardizing the applications functions. Standardization of application functions is today mainly driven by ITU-T, 3GPP, and OMA. Telecom and IT companies regroup within OMA to specify interoperable advanced mobility services. OMA was created in June 2002 as a combination of the WAP forum, the SyncML Initiative, the MMS Interoperability Group, the Wireless Village Initiative, the Mobile Wireless Internet Forum, and the Mobile Games Interoperability Forum. The goal of ITU-T, 3GPP, and OMA is not to standardize complete services but, rather, to standardize functional service building blocks that are reusable at runtime by various services, as defined in Bertin, Bury, and Lesieur [13]. This approach enables the building of innovative and evolving services mostly independently of network considerations. These service building blocks provide key capabilities to ensure interoperability of devices, operators, and service providers. As seen before, ITU-T and 3GPP are standardizing the mechanisms that trigger these building blocks, either separately or in a coordinated way, including the management of interactions between these capabilities, as shown in Gouya, Crespi, and Bertin [14]. These service building blocks are called service capabilities at 3GPP, service support capabilities at ITU-T, and service enablers at OMA. Service support capabilities studied at ITU-T [15] typically include presence, location, group management, message handling, broadcast/multicast, push and session handling, or device management. Service enablers at OMA [16] include, for example, data synchronization, device management, digital rights management, downloading, e-mail notification, instant messaging, presence and mobile location, or multimedia messaging. Service capabilities defined at 3GPP typically include presence [17] and messaging [18] or conferencing [19]. The OMA specifications for service enablers are the most advanced and complete. According to the OMA, • “An enabler is defined as] a technology intended for use in the development, deployment or operation of a service; defined in a specification, or group of specifications, published as a package by OMA” [20]. • “An enabler should specify one or more public interfaces. Examples of OMA enablers include location or device management” [16]. These definitions highlight the normative character of an enabler. A component or a technology is an enabler because it has been defined as an enabler. Moreover, when individual enablers are defined independently, each enabler has to define all functions required to fulfill its requirements. This implies several issues for the service provider—especially the difficulty of providing user-centric services: “Integration and deployment of services is complicated and expensive; high implementation efforts for applications wanting to use


11

several capabilities; there is no common integration of the different services from the point of view of the end user (e.g., no common group management or user profile across multiple services)” [16]. An OMA enabler should thus contain only intrinsic functions that can interact with other functions from the service architecture or from underlying network architecture. Intrinsic functions are defined as “those functions that are essential in fulfilling the intended task of the specified enabler. For example, the position calculation function is intrinsic to secure user plane location; authentication is intrinsic to single sign on; encryption is an intrinsic function of digital rights management” [16]. This separation into intrinsic and nonintrinsic functions is a way of ensuring that various enablers will not include the same function (e.g., authentication function in each enabler). As specified in reference 16, “any requirements or features that are not intrinsic to an enabler should not be specified within the enabler’s specification. An enabler’s specification should only specify the intrinsic functionality required to fulfill its actual function.” This specification of service functions with enablers that are responsible only for their intrinsic functions enhances the ability of service providers to offer a consistent user experience (i.e., reuse of user information, service continuity, etc.). However, the separation into intrinsic and nonintrinsic functions is not obvious but remains subjective, as recognized in reference 16 (“the classification of intrinsic and non-intrinsic is subjective and needs to be done on a per enabler basis”). This implies again that the definition of enablers should result from a normative process. The OMA has specified the OMA service environment (OSE) [16] that provides a common architecture for the integration of enablers and service creation. As shown in Figure 1.4, the OSE architecture consists of enablers that run on an execution environment and are accessible to applications and other enablers through a policy enforcer. Enablers are intended for use in the development, deployment, or operation of a service. They provide their intrinsic functionality through one or more public interfaces called I0 interfaces and may use underlying network resources through I2 interfaces (such as IMS interfaces) The execution environment logically encompasses various functions such as process monitoring, software life cycle management, system support (e.g., thread management, load balancing, and caching), operation, management, and administration. The interface between the execution environment and enablers is called an I1 interface. The policy enforcer provides a policy-based management mechanism to protect resources from unauthorized requests and to manage the use of these requests—for instance, through appropriate charging, logging, and enforcement of user privacy or preferences. The policy enforcer function allows the domain owner to extract and separate policy rules from architectural elements. This element exposes I0 + P interfaces to applications and enablers, where P is additional parameters that must be provided along with a request to an enabler’s I0 interface, when the policies that are to be enforced

12

IP Multimedia Subsystem (IMS) Handbook Applications

Service Provider

Execution Environment

I0+P Policy Enforcer

I0 I1

Enabler I2

I0

I0

Enabler

Enabler

I2

I2

Figure 1.4 The OMA service environment architecture [16].

require additional parameters. Applications can be located inside or outside the service delivery environment.

IMS Service Model IMS Brings New Types of Services Traditionally, telecommunications services are divided into bearer services, teleservices, and supplementary services. “A bearer service is a type of telecommunication service that provides the capability for the transmission of signals between user-network interface” and “a teleservice is a type of service that provides the complete capability, including terminal equipment functions, for communication between users” and “supplementary service modifies or supplements a basic teleservice” [26]. Examples of basic teleservice are telephony, facsimile, or emergency calls. These notions are still in use in some 3GPP or TISPAN standards but can no longer be used by a service provider to design services. Indeed, the added value of IMS for service providers is the ability to build user-centric services that flexibly combine several features and enable the sharing of user information between these features to form a coherent service environment for the user [12]. As explained in the previous section, the OMA enabler or the 3GPP service capabilities are the necessary building blocks for such services. However, a model for IMS services, linking the services from users, enablers, and technical functions, is not defined in standards.


13

Transfer and control functions are extensively addressed by IMS and NGN studies. Application functions are partially addressed by the OMA concerning the service delivery aspects (with the OSE). The foreseen services for IMS will require a coherent integration of multiple loosely coupled features. The integration between these features should be considered not only at the technical level (i.e., the integration within a service delivery environment like OSE) but also at a service level (i.e., how the composition of various technical functions and enablers will provide a coherent service experience to the user). If the integration at the technical level is well addressed by the OMA and ETSI studies, the integration at the service level has not been investigated. To answer these needs, we should describe the relationships between a service perceived by the user and the technical functions and enablers used to implement it. The modeling approach is organized as follows: • modeling the link between services that is seen by the users (e.g., a user is aware that his or her personal information is shared between his services); • modeling the technical functions that are the foundation of IMS; technical functions are those carried out by the systems (e.g., service platforms, terminals) controlled by the service providers; and • modeling IMS service architecture based on service enablers. Service enablers are designed for the reuse of the user information between services and for easy integration of new services. As seen before, service enablers contain and wrap technical functions (intrinsic functions). We propose to characterize an enabler by the information it handles and by the technical functions it wraps. For instance, only one service enabler can produce the presence information and can wrap the technical functions linked to presence, or only one service enabler can produce the location information and can wrap the technical functions linked to location. The Link between Services Seen by the User The first step is to define clearly what a service is. There is a lot of research on the notion of service—not that much in the IT area but, rather, in the economic and business sciences, as surveyed in Ben Yahia et al. [21]. In a generic way, a service can be defined as any business actions or business activities that have a value-added result for a user (a person or a system). This action or activity is offered by a service provider (another person, entity, or system), which profits from providing this action [22,23]. In the telecommunications field, a telecom service is defined by 3GPP as “a component of the portfolio of choices offered by service providers to a user, functionality offered to a user” [24]. The focus area of this study is service usage; hence, we concentrate on the user while the customer is outside the scope of IMS services. The customer is

14


a person or organization that purchases products and services [25]; the user is the person (or system) who uses the service and can be different from the customer. For example, in a family, the customer may be one of the parents, and a child may be the user of the purchased service. The customer usually assigns rights to users to use the services he or she has obtained, and the customer can be a user. Although the user is typically a person, it may also be another actor (e.g., another service provider). Relying on the preceding service definition, we propose a definition for IMS services as follows: IMS services are activities that take place in interactions between a user (i.e., IMS user) and systems controlled by service providers (e.g., IMS user equipment, IMS platforms). These activities have a value-added result for the user; and the service providers profit from providing these activities.

In this definition we highlight two parties: the user and the systems controlled by the service providers. From a user perspective, the purpose of IMS services is to establish a communication session between users that is adapted to user preferences and context. The session manipulated by IMS services may be voice sessions but can also be video sessions, instant messaging sessions, or collaboration sessions. The term session here means only an interactive exchange between two or more persons in order to communicate. From a user perspective, an IMS service is linked to his or her identity and not to his or her access device because the user may access the same services from several IMS devices. When using IMS services, the user is aware that applications within his or her user equipment or within service platforms are sharing and reusing his or her personal information such as presence information, availability rules, personal profile, contact list, or location information. A given service will be responsible for the creation and the modification of each type of information (e.g., presence service for presence information, location service for location information). An IMS service can thus consult a user’s personal information (according to privacy policies) and may be responsible for defined user information. Figure 1.5 proposes relationships of an IMS service, an IMS public user identity, and the user’s personal information. The terms of IMS service in this figure do not name a service in a general way (e.g., presence service) but name the service instance of one specific user (e.g., Bob’s presence service). Technical Functions From a service provider technical perspective, a service is implemented with technical functions. Technical functions are the functions carried out by systems controlled by the service providers (e.g., service platforms, terminals). As seen before, the IMS service architecture may be divided into several technical functions. The first division is among service stratum functions,

15

IMS Service, Models, and Concepts IMS Service

*

1

-is linked to

1

*

* -consult

IMS Public User Identity

-is responsible for

User Personal Information

* 1

*

Figure 1.5 Links seen by the user.

Technical Function

Transport Stratum Function

Service Control Function

Service Stratum Function

Application Function

End-user Function

Service User Profile

Figure 1.6 IMS technical functions.

transport stratum functions, and end-user functions. As we are not dealing here with networking issues, we will focus only on the service stratum. As seen in the first section, this service stratum is divided among service control functions, service user profiles, and application functions [2]. In addition, end-user functions have to be considered. They are not part of the service stratum but are closely related for the delivery of the services through the user interface. Figure 1.6 classifies the IMS (or NGN) technical functions, according to the NGN standards presented in the first section. The service stratum functions are a particular type of technical function. A service stratum function may be:

16


*

-utilizes

IMS Service

Technical Function *

* 1 *

-consult

User Personal Information *

-is responsible for

Figure 1.7 IMS service.

• a service control function that handles common control functions like session establishment control or service triggering control; • an application function that contains the service logic and the manipulation rules for session establishments (e.g., transfers, callback, reachability, call log); • a service user profile that stores the information on user identities and on service triggering; and • an end-user function that includes not only the connection to the IMS (using SIP and bearer protocols) but also the service interface part that resides in the client device. This interface performs the transformation of the technical messages from the application functions into something usable by the user (and vice versa) and thus provides the end user with the ability to initiate and participate in a session. For example, an interface for presence will transform the presence protocols messages into a user interface displaying the presence of the user’s contacts. Relationship between Service and Technical Function An IMS service is the junction between user personal information and technical functions. To illustrate this in Figure 1.7, we can consider the example of an IMS presence service. The presence service is seen by the user as the notification of presence information between a consumer of presence information and sources of presence information, where the presence information is a set of attributes characterizing current properties of the sources (such as status or communication address) [17]. The presence service is performed with technical functions such as end-user presence clients (a presence source client and a presence watcher client), service control mechanisms to route


17

presence messages (the SIP SUBSCRIBE, PUBLISH, and NOTIFY messages), and presence application servers (to process the presence state from the presence sources and to store and send it to the watchers that have subscribed to this presence event). The services are directly responsible for the user’s personal information and are utilizing the technical functions directly. As mentioned, this may lead to building silo architecture, where each service relies on its own technical functions. Service enablers (or service support capabilities or service capabilities) are designed to address this issue by focusing only on their intrinsic functions. This means that there should be no overlap between the service enablers, both from the user perspective and from the technical functions perspective. No overlap from the user perspective implies that different service enablers should not be responsible for the same type of user’s personal information. For example, only one service enabler can produce the presence information and only one service enabler can produce the location information. No overlap from the technical functions perspective implies that the different service enablers should not use the same IMS functions in an incoherent way. For example, only the presence service enabler can process the presence messages and store the presence state and only the location service enabler can process and aggregate user location from various location sources. In IMS service architecture, the IMS services have to rely as much as possible on IMS service enablers. These IMS service enablers wrap a set of technical functions and provide a consistent service interface to IMS services. An IMS service might also use some technical functions directly (e.g., an application server dedicated to a specific service). In addition, only IMS service enablers should be responsible for the user’s personal information (Figure 1.8).

Example of the Push-to-Talk over Cellular In order to illustrate this model, we apply it here to the push-to-talk over cellular (PoC) described in the OMA release program and specifications [27]. The PoC service is a walkie-talkie type of service that allows rapid, short, and spontaneous communications. It is a half duplex voice service that allows person-to-person and person-to-group communications. This service is considered an early example of IMS application in the market. Because PoC is specified as both a service and an enabler, we show the distinction between the service perceived by the user and the functional service building blocks. This illustrates the separation of concern from what is seen by the user, the service enabler, and the technical functions that implement these enablers.

18

IP Multimedia Subsystem (IMS) Handbook * *

*

-consult

-utilizes

IMS Service

*

IMS Service Enabler

* *

*

-consult

User Personal Information

*

-wrap

1

1

*

*

-utilizes

Technical Function

*

-requires

* -is responsible for

Figure 1.8 IMS services and service enablers.

This separation will benefit service providers for the whole service life cycle— especially service composition, service interaction, and service management. PoC Service Seen from the User’s Perspective From a user perspective, a typical PoC session is as follows: The PoC user opens his contact list, where presence features indicate whether contacts or groups of contacts are available or not. The user selects one or more contacts in his contact list, creates a PoC group with these contacts, starts the PoC service, and then talks simultaneously to all the contacts of his PoC group.

This basic session shows that the PoC service is based on the user identity, which is necessary to access the contact list and invite other PoC users to participate in a session. Besides identity, from a user perspective, the PoC service uses: • presence information to be aware of contact availability and reachability; • contact lists to create groups for PoC sessions; and • user profiles. Figure 1.9 shows the PoC service as seen by user “Bob Smith.” This view contains the information that the user owns and that is reused in the PoC service. His personal information could be reused as in another IMS service.

19

IMS Service, Models, and Concepts Another Service of Bob : IMS Service

PoC Service of Bob : IMS Service

Bob Identity : IMS Public User Identity

Bob Profile : User Personal Information

Bob Contact List : User Personal Information

Bob Presence Information : User Personal Information

Figure 1.9 PoC service as seen by “Bob Smith.”

PoC Service and Service Enablers As described in the OMA specifications, the PoC service requires several service enablers that perform specific actions and are responsible for specific information: • push-to-talk over cellular enabler [27] that manages the service logic of the PoC service; • XDM (XML document management) enabler [28] to handle the contact groups in particular; • presence enabler [29]; • IMS enabler [30] to support the service; and • device management enabler [31]. The dependencies between the PoC service and the service enablers and also between the service enablers are described in Figure 1.10 with dotted arrows. Each service enabler is responsible for some type of personal information. Technical Functions for PoC Service As mentioned before, each service enabler is implemented and carried out via a set of technical functions that are shown in Figure 1.11. In this section we split each enabler into its corresponding technical functions. The XML document management (XDM) enabler is implemented with an XDM client (XDMC), a shared XDM server (shared XDMS), and an aggregation proxy. The XDMC is an XCAP (XML configuration access protocol) client

Figure 1.10 Service enablers for PoC service.


Bob Profile : User Personal Information

OMA XDM : IMS Service Enabler


OMA Device Management : IMS Service Enabler

Bob Presence Simple : IMS Service Enabler

IMS in OMA : IMS Service Enabler

OMA PoC : IMS Service Enabler

Bob Contact List : User Personal Information

20 IP Multimedia Subsystem (IMS) Handbook

21


DM Server DM Client Presence Server

Watcher XDMC

SIP/IP Core

Presence Source

PoC Subscriber/User PoC Client

Shared XDMS

Aggregation Proxy

PoC XDMs PoC Server

UE

Figure 1.11 Technical functions of the PoC service (simplified).

that gives access to XML documents stored in the network (e.g., PoC-specific documents in the PoC XDMS, contact lists in the shared XDMS). The aggregation proxy acts as the single contact point for the XDMC. It performs authentication of the XDMC and routes individual XCAP requests to the correct XDMS. The shared XDMS is an XCAP server that manages XML documents (e.g., contact lists) that are shared with other service enablers (e.g., presence). The PoC enabler is implemented into a client part, a server part, and a PoCspecific XDM server. The PoC client resides on the terminal and is used to access the PoC service. The PoC server implements the application logic for the PoC service. The PoC-specific XDM server is an XCAP server, which manages XML documents that are specific to the PoC service (e.g., PoC groups). The presence enabler is implemented on a presence server, a presence source, and a watcher. A presence server is an entity that accepts, stores, and distributes presence information about PoC clients. A presence source is an entity that provides (publishes) presence information, and a watcher is an entity that is notified from presence information. The IMS enabler includes a number of SIP proxies and SIP registrars. It performs functions such as authentication, authorization of PoC user, or maintaining of the registration state. The device management enabler is implemented with a device management client that receives the initial parameters needed by the service provider for the PoC client and a device management server that initializes the entire configuration and updates necessary for the PoC client.

22


All technical functions described here belong to the service stratum. They are thus end-user functions, service control functions, or application functions. PoC client, XML document management client, presence source, watcher, and device management client are end-user functions. IMS core is a service control function. PoC server, PoC XML document management server, aggregation proxy, shared XML document server, presence server, and device management server are application functions. A Comprehensive View of IMS Services Figure 1.12 is an example of the three enablers OMA XDM, IMS in OMA, and OMA presence simple. It defines the suitable dependencies of these three enablers and with the services that make use of these enablers. We take here the examples of the PoC service and of an instant messaging service. All the enablers used by these services are not represented in order to simplify the figure.

Conclusion IMS services cannot be considered independently from the whole service environment of the user [32]. This environment includes at least features such as identity management, community management, availability management, or context management. This service environment should be able to integrate third-party service elements. The service value will reside in the quality of the interactions between all the service elements and in seamless accessibility in a user-centric way. A service control framework handling these interactions is therefore needed for the interactions between the operator services and for intermediation with other service providers. This framework should rely on a common modeling for services, service enablers, and resources. The main interest of the proposed approach lies in the identification of the dependencies between the services and the service enablers. This allows better design of the IMS services by defining clearly which service enabler is involved in which service and how a service enabler is linked to technical functions. This approach optimizes the treatment of service interaction between IMS service enablers by tracing the impact on the user perception of the service. It will also enhance service management aspects by detecting how the failure of one or many technical functions can affect service enablers and the use of the IMS service. It is a tool to identify the user personal information that should be shared between services, to define which service enabler is responsible for which information, and then to design services that reuse this personal information through these service enablers.

OMA Presence SIMPLE : IMS Service Enabler

Presence Server : Application Function

Presence Source : End-user Function

Watcher : End-user Function

IMS Core : Service Control Function

Aggregation Proxy : Application Function

XML Document Management Client : End-user Function

IMS in OMA : IMS Service Enabler

OMA XDM : IMS Service Enabler

Figure 1.12 Relationship and dependencies of XDM, IMS, and presence simple service enablers.



Instant Messaging Service of Bob : IMS Service

Shared XML Document Management Server : Application Function

IMS Service, Models, and Concepts 23

24


Glossary 3GPP API AS CSCF DSL GSM GUI HSS IETF iFC IMS IN INAP ISDN ISUP IT ITU NGN OMA OSE PSTN S-CSCF SIB SIP SIM SPT TISPAN UMTS WLAN XML TMF

3rd Generation Partnership Project application programming interface application server call state control functions digital subscriber line global system for mobile communications graphical user interface home subscriber server Internet Engineering Task Force initial filter criteria IP multimedia subsystem intelligent network intelligent network application protocol integrated services digital network ISDN user part information technology International Telecommunication Union Next-generation networks Open Mobile Alliance OMA service environment public switched telephone network serving call state control functions service independent building block session initiation protocol subscriber identity module service point trigger telecommunication and Internet converged services and protocols for advanced networking universal mobile telecommunications system wireless local area network extensible markup language TeleManagement Forum

References

1. Arbanowski, S. et al. 2004. I-centric communications: Personalization, ambient awareness, and adaptability for future mobile services. IEEE Communications Magazine 42(9):63–69.


25

2. Knightson, K., N. Morita, and T. Towle. 2005. NGN architecture: Generic principles, functional architecture, and implementation. IEEE Communications Magazine 43(10):49–56. 3. 3GPP. IP multimedia subsystem (IMS), TS 23.228. 4. Bertin, E., E. Bury, and P. Lesieur. 2003. Operator services deployment with SIP: Wireline feedback and 3GPP perspectives. ICIN 2003, Bordeaux, April 2003. 5. Schulzrinne, H., and J. Rosenberg. 1999. Internet telephony: Architecture and protocols—An IETF perspective. Computer Networks and ISDN Systems 31(3):237–255. 6. Tang, B. Y. C. 2005. Evolving to wireless and wireline convergence—An overview of IMS. Wireless and Optical Communications, 2005. 14th Annual WOCC 2005, 27, April 22–23. 7. Marquez, F. G., M. G. Rodriguez, T. R. Valladares, T. de Miguel, and L. A. Galindo. 2005. Interworking of IP multimedia core networks between 3GPP and WLAN. IEEE Wireless Communications 12(3):58–65. 8. Lin, F. J. 2005. A survey on wireless/wireline integration. Wireless and Optical Communications, 2005. 14th Annual WOCC 2005, 26, April 22–23. 9. 3GPP. IP multimedia session handling; IM call model, TS 23.218. 10. Schilit, B. N., D. M. Hilbert, and J. Trevor. 2002. Context-aware communication. IEEE Wireless Communications 9(5):46–54. 11. Raento, M., A. Oulasvirta, R. Petit, and H. Toivonen, H. 2005. ContextPhone: A prototyping platform for context-aware mobile applications. IEEE Pervasive Computing 4(2):51–59. 12. Bertin, E., E. Bury, and P. Lesieur. 2002. Next-generation architectures: Which roles for an incumbent operator? Proceedings of the Eurescom Summit 2002. 13. Bertin, E., E. Bury, and P. Lesieur. 2004. Intelligence distribution in next-generation networks, an architectural framework for multimedia services. IEEE International Conference on Communications, ICC 2004, Paris. 14. Gouya, A., N. Crespi, and E. Bertin. 2006. SCIM (service capability interaction manager). Implementation issues in IMS service architecture. IEEE International Conference on Communications, Istanbul. 15. Carugi, M., B. Hirschman, and A. Narita. 2005. Introduction to the ITU-T NGN focus group release 1: Target environment, services, and capabilities. IEEE Communications Magazine 43(10):42–48. 16. OMA. OMA service environment. Approved version 1.0.4, 01 Feb 2007, OMA-AD-Service-Environment-V1_0_4-20070201-A. 17. 3GPP. Presence service using the IP multimedia (IM) core network (CN) subsystem; TS 24.141. 18. 3GPP. Messaging using the IP multimedia (IM) core network (CN) subsystem; TS 24.247. 19. 3GPP. Conferencing using the IP multimedia (IM) core network (CN) subsystem; TS 24.147. 20. OMA. Dictionary for OMA specifications. Approved version 2.6, June 2007, OMA-ORG-Dictionary-V2_6-20070614-A. 21. Ben Yahia, I., E. Bertin, N. Crespi, and J. P. Deschrevel. 2006. Service definition for next-generation networks. International Conference on Networking. ICN 2006, Mauritius. 22. Lovelock, C. 2001. Services marketing, people, technology, strategy, 4th ed. Englewood Cliffs, NJ: Prentice Hall.

26


23. Grönroos, C. 2000. Service management and marketing: A customer relationship management approach, 2nd ed. Chichester, UK: John Wiley & Sons. 24. 3GPP. 2005. 3GPP definition, TR 21.905, V6.7.0. 25. TMF Forum. Shared information and data (SID) model. GB922 and addenda, release 7, January 2007. 26. Keck, D. O., and P. J. Kuehn. 1998. The feature and service interaction problem in telecommunications systems: A survey. IEEE Transactions on Software Engineering 24(10):779–796. 27. OMA. OMA push to talk over cellular (PoC). Approved enabler version 1.0.2, September 2007. 28. OMA. OMA XML document management. Approved enabler version 1.0.1, November 2006. 29. OMA. OMA presence simple. Approved enabler version 1.0.1, November 2006. 30. OMA. IMS in OMA. Approved enabler version 1.0, September 2005. 31. OMA. OMA device management. Approved enabler version 1.2, February 2007. 32. Ryu, S. et al. 2005. Research activities on next-generation mobile communications and services in Korea. IEEE Communications Magazine 43(9):122–131.

2 IMS—A Secure Architecture for All IP Networks Muhammad Sher and Thomas Magedanz

contents Introduction............................................................................................................ 28 IMS Architectural Overview................................................................................ 29 IMS Security Challenges and Potential Attacks................................................ 32 IMS Security Mechanisms and Security Associations..................................... 35 IMS Authentication, Key Management, and Secrecy....................................... 39 IMS Authentication and Key Management.............................................. 39 Encryption and Secrecy............................................................................... 41 Use of IPsec ESP for SIP Confidentiality and Integrity Protection............................................................................43 SIP Integrity and Confidentiality Procedure................................44 Interdomain Security............................................................................................ 45 Network Domain Security (NDS) Architecture....................................... 47 Use of IPsec in an NDS/IP Environment.................................................. 50 Public Key Infrastructure (PKI).................................................................. 53 PKI-Based NDS Authentication Framework............................................. 55 Security Management for HTTP-Based Services.............................................. 59 Generic Bootstrapping Architecture (GBA).............................................. 59 Bootstrapping Authentication Procedure................................................. 62 Bootstrapping Usage Procedure.................................................................64 Authentication Proxy Usage for Multimedia Services............................64 References............................................................................................................... 67

27

28


Introduction The fixed-mobile convergence (FMC) and voice-data networks have merged next-generation, value-added applications and integrated multimedia services, combining Web browsing, instant messaging, presence, voice over Internet protocol (VoIP), video conferencing, application sharing, telephony, unified messaging, multimedia content delivery, etc. on top of different network technologies. The 3GPP (3rd Generation Partnership Project) [1] and 3GPP2 [2] have developed the IP multimedia subsystem (IMS) [3] to provide a service delivery platform (SDP) for a converged communication paradigm. No doubt, the convergence of voice and data networks is a great achievement to maintain a single communication platform for all, but the greatest challenge is to maintain an adequate level of security in the heterogeneous network environment to protect multiple technologies and protocols and to provide data confidentiality and protection. Another important development in the converged networks paradigm is the introduction of IP as the network layer in the GPRS (general packet radio service) and in the UMTS (universal mobile telecommunication system) network domain. The IP-based network architecture provides open and flexible interfaces to deploy innovative services. In terms of security, this implies an array of new threats and risks inherited from the Internet world. The IMS is also vulnerable to different peer-to-peer attacks because users are always connected and online. The possible reasons for passive and active attacks in IMS are that an attacker could easily access a wireless link, launch a falsely based station, and redirect attacks to intercept and redirect a user’s confidential information somewhere else. IMS utilizes SIP (session initiation protocol) [4] for signaling, which is open architecture and vulnerable to different attacks, as discussed in Calhoun et al. [5]. The IMS core threats include flooding attacks, which ultimately keep the network resources busy, and, as a result, these sources are not available to legitimate users. The IMS application servers (ASs) are also valuable targets for intruders because they provide value-added services. Due to the textbased nature of SIP, the IMS and AS are vulnerable to attacks like spoofing, hijacking, and message tampering. Moreover, the AS may suffer from HTTPbased threats. Finally, intruders may launch denial of service (DoS) attacks against applications installed on the AS. In order to minimize the risk of theft of information and data from hackers, we have to focus on an independent security framework for IMS. According to 3GPP technical specifications and standards, IMS security provides two solutions at different levels of protection:

1. The early IMS security solution standardized in 3GPP release 5 provides limited security functionality and aims to protect early IMS deployment and offers less security. It provides authentication of

IMS—A Secure Architecture for All IP Networks

29

subscribers for services access and identity confidentiality on the radio interface. It also provides radio interface encryption.

2. The complete IMS security solution is standardized in 3GPP release 6 with full security functionality and builds on the early security solutions with the objective to improve them. It offers new security features and secures new services to protect networks and terminals with data protection.

This chapter presents an IMS overview and addresses IMS potential attacks. It presents an overview of IMS security architecture and security associations, as well as key authentication, key generation, and use of keys to provide confidentiality and integrity. Later, it discusses interdomain security and presents IMS HTTP-based services security. Finally, it presents security extension for new threats.

IMS Architectural Overview The IMS [3] provides SDP for mobile multimedia services provisioning, such as VoIP, video-telephony, multimedia conferencing, mobile content, and push-to-talk. It is based on Internet Engineering Task Force (IETF) protocols like SIP [4], DIAMETER [8], SDP, real-time transport protocol (RTP), and transfer control protocol (TCP)/IP protocol stack. The IMS is considered as the next-generation service delivery platform framework. It consists of a modular design with open interfaces and enables the flexibility for providing multimedia services over IP technology. The IMS does not standardize specific services but, rather, uses standard service enablers (e.g., presence) and inherently supports multimedia and VoIP. In the IMS architecture, the SIP protocol [4] is used as the standard signaling protocol that establishes, controls, modifies, and terminates voice, video, and messaging sessions between two or more participants. The related signaling servers in the architecture are referred to as call state control functions (CSCFs) and are distinguished by their specific functionalities. The functionality related to authentication, authorization, and accounting (AAA) within the IMS is based on the IETF DIAMETER protocol [6] and is implemented in the home subscriber system (HSS), CSCFs, and various other IMS components in order to allow charging functionality within the IMS. Instead of developing the protocol from scratch, DIAMETER is based on the Remote Authentication Dial-in-User Service (RADIUS) [7], which has previously been used to provide AAA services for dial-up and terminal servers across environments. The other protocol that is important for multimedia contents is real-time transport protocol (RTP) [8], which provides end-to-end delivery for real-time data. It also contains end-to-end delivery services like payload-type (codec)

30


SIP AS IMS Core

Parlay X GW

XDMS Presence Charging

Sh

HSS Cx

ISC

Cx

IMS Application Platform

Mw I-CSCF

Mw

Mw

S-CSCF

Mw Mw

P-CSCF

Signalling GW Media GW

Gm Media Server

Legacy networks GSM, PSTN

IMS Clients

Figure 2.1 IMS architecture.

identification, sequence numbering, time stamping, and delivering monitoring for real-time data. The RTP provides quality of service (QoS) monitoring using the RTP control protocol (RTCP) [9], which conveys information about media session participants. The IMS entities and key functionalities can be classified in six categories [10]: session management and routing family (CSCFs), databases (HSS, SLF), interworking elements (BGCF, MGCF, etc.), services (application server, MRCF, MRFP), support entities (THIG, security gateway [SEG], PDF), and charging. The most important components and parts of IMS architecture (shown in Figure 2.1) are described as follows: Proxy call state control function (P-CSCF) is the first contact point within the IP multimedia core network; all SIP signaling traffic from or to the user equipment (UE) traverse via the P-CSCF. Its address is discovered by the UE following the packet data protocol (PDP) context activation. The P-CSCF behaves like a proxy, accepting and forward-

IMS—A Secure Architecture for All IP Networks ing requests and responses. It performs functions like authorizing the bearer resources for the appropriate QoS level, emergency calls, monitoring, header (de)compression, and identification of I-CSCF. Interrogating call state control function (I-CSCF) is the first contact point within an operator’s network. It contacts the HSS to get the address of S-CSCF to serve the user for registration. It forwards SIP requests and responses to S-CSCF. It also performs network topology hiding functionality. Serving call state control function (S-CSCF) performs the session control services for the end point and maintains session state as needed by the network operator for support of the services. Within an operator’s network, different S-CSCFs may have different functionalities. The important functions performed by S-CSCF include user registration/interaction with service platforms for the support of services. The S-CSCF decides whether an AS is required to receive information related to an incoming SIP session request to ensure appropriate service handling. The decision at the S-CSCF is based on filter information received from the HSS [10]. This filter information is stored and conveyed on a per-application-server basis for each user. Home subscriber server (HSS) is the equivalent of the HLR (home location register) in 2G systems but extended with two DIAMETER-based reference points. It is the master database of an IMS that stores IMS user profiles, including individual filtering information, user status information, and application server profiles. Application server (AS) provides service platforms in IMS environments. It does not address how multimedia/value-added applications are programmed; only well defined signaling and administration interfaces (IMS service control [ISC] and Sh) and SIP and DIAMETER protocols are supported. This enables developers to use almost any programming paradigm within a SIP AS, such as legacy intelligent network servers (i.e., CAMEL support environments); open service access (OSA)/Parlay servers/gateways; or any proven VoIP SIP programming paradigm like SIP servlets, call programming language (CPL), and common gateway interface (CGI) scripts [11]. The SIP AS is triggered by the S-CSCF, which redirects certain sessions to the SIP AS based on the downloaded filter criteria or by requesting filter information from the HSS in a user-based paradigm. The SIP AS comprises filter rules to decide which of the applications deployed on the server should be selected for handling the session. During execution of service logic, it is also possible for the SIP AS to communicate with the HSS to get additional information about a subscriber or to be notified about changes in the profile of the subscriber [12]. Media resource function (MRF) can be split into media resource function controller (MRFC) and media resource function processor (MRFP).

31

32

IP Multimedia Subsystem (IMS) Handbook It provides media stream processing resources like media mixing, media announcements, media analysis, and media transcoding as well as speech [10]. The other three components are border gateway control function (BGCF), media gate control function (MGCF), and media gate (MG), which perform the bearer interworking between RTP/IP and the bearers used in the legacy networks.

IMS end-user system provides the necessary IMS protocol support, namely SIP, and the service-related media codecs for the multimedia applications in addition to the basic connectivity support (e.g., GPRS, wireless local area network [WLAN]).

IMS Security Challenges and Potential Attacks The security challenges facing IMS are threats from different domain protocols—for example, SIP signaling attacks, RTP media attacks, and IP domain attacks. Some of the potential IMS attacks are identified in reference 13. The IMS security challenges are DoS attacks, threats from open-based IP infrastructure, and SIP signaling and media flow attacks, as depicted in Figure 2.2. These threats are summarized as follows: Denial-of-service (DoS) attack: This jams radio signals and floods by authentication requests to P-CSCF and other devices. For example, in a REGISTER flooding attack, the attacker sends many REGISTER requests to the P-CSCF with fake or spoofed source addresses (e.g., SIP URI [uniform resource identifier]). In the case of distributed REGISTER flooding, the attacker generates multiple REGISTER requests with different spoofed and faked source addresses to overwhelm the IMS resources. It causes downfall of IMS resources and the legitimate users cannot get the services. Spoofing attack: The malicious node hides its presence in the network and intercepts traffic, and attackers tamper with messages. These nodes become trusted nodes in IMS. Man-in-the-middle attack: Hackers search the breaches and break the authentication process and integrity protection process in order to get IMS services for free. Impersonation: Impersonating a server causes misrouting of messages. The existing authentication processes are unable to differentiate between the intruder and the legitimate user. This way the attacker has free access to IMS services and the victim is charged for the attacker’s usage of services.

33


SIP Attacks Invite Flooding Register Flooding I/R Response Flooding SQL Injection Cancel Attack Refer Attack

RTP Attacks Open IP Multimedia Subsystem (IMS) Core

Jitter Attack Session Tear Down Session Modification Session Hijacking

Transport & IP Layers Attacks TCP SYN Flooding ACK Flooding Smurf Attack

Figure 2.2 IMS potential threats.

Eavesdropping: Hackers get session information if messages are sent in clear text and can easily launch a variety of hijacking attacks from session information. Password guessing attack: This is like a session hijacking attack with the objective to get user session information. Even if an intruder is not able to break the IMS authentication process, he or she can launch a password-guessing attack in order to misuse the legitimate accounts of users. The intruder launches this attack by sending many REGISTER requests to P-CSCF and receives 401-unauthorized messages from the IMS core. The attacker could get 200 OK responses in a successful attack. SQL injection: This is a type of message-tampering attack; the text-based nature of SIP messages provides an opportunity for message-tampering attacks in IMS. This attack not only targets data modification but also causes DoS by collapse of database services. The utilization of a Web interface for the provision of value-added services makes IMS more vulnerable to this kind of attack. The SQL injection could be launched simply by inserting an SQL statement when UE and P-CSCF start authentication procedures. The UE’s initial REGISTER request utilizes the HTTP digest [14] authorization header to transport users’ identities. When a malicious user tries to launch SQL injection in IMS, he or she spoofs the SIP message and inserts

34

IP Multimedia Subsystem (IMS) Handbook the malicious SQL code in its authorization header. When P-CSCF receives a SIP message with an infected authorization header, it generates and executes the illegitimate SQL statement, which may delete data in the database [15]. The existing solutions do not provide mitigation against this attack. The IMS also integrates the HTTP servlet container; therefore, an attacker can also utilize the HTTP message to launch the SQL injection attacks.

Media session termination attack: The BYE request is used to terminate an established session. An attacker could utilize the BYE request to tear down a session. The attacker sends a fake BYE message, which is forwarded from P-CSCF to UE1 and it assumes that it is from UE2, which wants to tear down the connection by sending the BYE message. As a result, UE1 stops the RTP flow immediately, while UE2 continues to send RTP packets to UE1 because UE2 has no notion that the connection should be terminated [16]. To launch this kind of attack, the attacker needs to learn all necessary session parameters. This can be accomplished either by sniffing the network or performing a man-in-the-middle attack to insert a BYE request into the session. CANCEL attack: The CANCEL terminates a pending request. The attacker could utilize the CANCEL method to cancel an INVITE request generated by a legitimate user. Before the final response is generated for an INVITE request, the attacker sends a fake CANCEL message to the P-CSCF, which assumes that it is from a legitimate user. The IMS core acknowledges the CANCEL message and ceases the processing of the INVITE request. A CANCEL request can only be used to cancel an INVITE request. Re-INVITE attack: The INVITE request establishes a session or dialog between two user devices (UE). The objective of the re-INVITE message is to modify the actual session information—for example, changing the addresses or ports, adding a media stream, or deleting a media stream [10]. Therefore, the attacker could launch a DoS attack by sending a forged re-INVITE message to modify the session. Repudiation: The user or network denies actions that have taken place. Nonrepudiation is a security service that counters the threats of repudiation. Masquerading: An intruder hoaxes as an authorized user to get confidential information and to get system services. IP multimedia services identity module (ISIM) cloning: This process changes the identity of one entity to that of an entity of the same type. The ISIM can be cloned by extracting the secret key (K) and international mobile subscriber identity (IMSI) from one ISIM and shifting to another ISIM using different attack techniques.


35

IMS Security Mechanisms and Security Associations The objective of the IMS security solutions is to develop an IMS security framework to ensure user privacy and network protection against misuses. Important security features and security services are provided by these solutions: User confidentiality provides user identity confidentiality, user location confidentiality, and user untraceability. To achieve these characteristics, the user is assigned a temporary identity so that the user’s permanent identity to which services are delivered cannot be eavesdropped on via the radio access link. In addition, user data and signaling that might reveal the user’s identity are ciphered on the radio access link. Entity authentication is based on user authentication and network authentication and should apply at connection setup between the user and the network. It involves an authentication mechanism using an authentication vector delivered by the user’s home environment (HE) to the serving network and a local authentication mechanism using the integrity key establishment between the user and the serving network. Data confidentiality provides confidentiality of user data and signaling data. It is achieved by using cipher algorithms and key agreement. Data integrity provides data integrity and origin authentication of signaling data. Data integrity is achieved by integrity algorithms and integrity key agreement. Network and services availability makes sure that network resources and services are available all the time to the users. To ensure the availability of services and resources, the network should be protected from DoS and distributed denial-of-service (DDoS) attacks. Fraud control protects the precious assets and value-added services from illegitimate users and hackers. In IMS, these services could be protected by securing ASs. The 3GPP and 3GPP2 have standardized IMS security in different releases and are based on early IMS security and complete IMS security: • The early IMS security solution standardized in 3GPP release 5 provides limited security functionality and aims to protect early IMS deployment and offer less security. It provides authentication of subscribers for service access and identity confidentiality on the radio interface. It also provides radio interface encryption. • A complete IMS security solution is standardized in 3GPP release 6 with full security functionality; it builds on the early security solutions with an objective to improve them. It offers new security features and secures new services to protect networks and

36


Authentication & Key Agreement

IMS Home Network

Inter-Domain Security

UE

Security Mechanism Integrity Protection

UMTS Access Security

IMS Visited Network

UMTS Access Network

Figure 2.3 IMS security mechanisms.

terminals with data protection. It consists of network domain security and access security that define SIP security in hop-byhop fashion. The end-to-end security is not supported. The overall security for IMS consists of the following mechanisms and is depicted in Figure 2.3: − authentication and key agreement between an IM subscriber and the home network; − security mechanism agreement between IM client and visited network; − integrity protection and confidentiality; − network domain security between different domains; and − existing GPRS/UMTS access security. The IMS security mechanisms are implemented by the following security associations: Security association 1 (SA1) provides mutual authentication of user and network (Figure 2.4). The HSS is responsible for generating keys and challenges and then delegates subscriber authentication to S-CSCF.

37


UE

SA6

ISIM

SA1

AP

SA6

AS

SA1

HSS

3 SA

SA 3

AKA

I-CSCF S-CSCF

SA 5

SA2

SA2

Access Networks UMTS, GPRS

NGN All IP Networks

SA4

7

SA

SA

P-CSCF

SA4

Home Network

UA

SA5

SA5

2

SA7

P-CSCF

Visited Network

Figure 2.4 IMS security associations.

The long-term key in ISIM and HSS is associated with the IP multimedia private identity (IMPI). The detailed process will be explained in a later section. Security association 2 (SA2) provides a secure link and a security association between UE and P-CSCF for protecting the Gm reference point (air contact). In IMS, network domain security (NDS)/IP is used to protect SIP signaling, but SIP communication at the Gm interface between UE and P-CSCF is outside the scope of network domain security/Internet protocol (NDS/IP) and needs additional measures for security. It will be explained in a later section. Security association 3 (SA3) provides security within the network domain internally for a Cx interface. The HSS stores subscriber and service data permanently. These centralized data are utilized by I-CSCF and S-CSCF when the user registers or receives sessions through the Cx interface and the selected management protocol is DIAMETER. DIAMETER messages over Cx and Dx interfaces make use of stream control transmission protocol (SCTP) [17] with IP security (IPsec) for secure communication.

38


Security association 4 (SA4) provides security between different networks for SIP-capable nodes and is only applicable when P-CSCF resides in the visited network (i.e., user is roaming). When P-CSCF resides in a visited network other than by virtue of authentication and key agreement (AKA) protocol, the shared secret is only accessible in the home network. This means that although authentication needs to take place in a visited network, certain delegation of responsibility needs to be assigned to P-CSCF because IPsec SAs exist between PCSCF and UE. Security association 5 (SA5) provides security within the network internally between SIP-capable nodes and also applies when P-CSCF resides in a home network. The IMS protects all IP traffic in a core network using NDS/IP [50], which provides confidentiality, data integrity, authentication, and antireplay protection for traffic using a combination of cryptographic security mechanisms and protocol security mechanisms applied is IPsec. The security procedure for SA4 and SA5 will be explained in a later section. Security association 6 (SA6): The protocols working across the Ut interface perform functionality to manage data traffic for HTTP-based applications. Thus, securing a Ut interface means achieving confidentiality and data integrity protection of HTTP-based traffic. The authentication and key agreement for the Ut interface are also based on AKA, which generates session keys. The IMS defines generic bootstrapping architecture (GBA) [51], which utilizes generic authentication architecture (GAA) [52] that performs mutual authentication before accessing services. The authentication in the Ut interface is performed by authentication proxy. Traffic in the Ut interface goes through the authentication proxy and is secured using the bootstrapped session key. The Ut interface employs the transport layer security (TLS) for both confidentiality and integrity protection. We will discuss the detailed procedure in a later section. Security association 7 (SA7) manages to protect the user and the user’s information on access networks (e.g., UMTS, global system for mobile communications (GSM), GPRS, WLAN, DSL, and VoIP). The security association takes place independently in either a circuit-switched (CS) or packet-switched (PS) service domain. For UMTS access networks, security management architecture consists of user service identity module (USIM), mobile equipment (ME), access network (AN), service network (SN), and HE [13]. USIM is required for accessing the PS domain in GPRS and identifies a particular subscriber. USIM contains security parameters for accessing the PS domain, IMSI, list of allowed access points, and multimedia message service (MMS)-related information. In the serving network, the serving GPRS support node (SGSN) links the radio access network (RAN) to the packet core network in the PS service domain. It is responsible for performing both

39

IMS—A Secure Architecture for All IP Networks control and traffic handling functions for the PS domain. The control parts deal with mobility management and session management. The SGSN also ensures appropriate QoS and generates charging information. In the CS service domain, the related part is the visitor location register (VLR). The authentication and key agreement procedure involves the authentication center (AUC) within HE, SGSN, or VLR and mobile station (MS) network entities [7].

IMS Authentication, Key Management, and Secrecy This section focuses on the generation and management of session keys for securing IP multimedia signaling and data. These keys include a confidentiality key and an integrity key, which are derived from the secret key stored in SIM/USIM. In order to get IP multimedia services, a user’s public identity, which is called IP multimedia public identity (IMPU), needs to be registered and his or her private identity, which is called IP multimedia private identity (IMPI), has to be authenticated by IMS. Authentication for IMS access is based on the AKA protocol. The K and AKA algorithms are stored in ISIM, which is normally embedded on a universal integrated circuit card (UICC) like a smart-card-based device. The IMS security is based on a long-term K shared between ISIM and the home network (HN) AUC. The AKA performs mutual authentication of ISIM and AUC and generates a cipher key (CK) and integrity key (IK) [7]. Later sections describe the key generation and distribution process during the authentication process and the confidentiality and integrity protection procedures. IMS Authentication and Key Management In this section we will explain the IMS AKA procedure for an unregistered IP multimedia client and successful mutual authentication with no synchronization error. For authentication purposes, the client sends SIP REGISTER requests to S-CSCF via P-CSCF and I-CSCF. This request contains the user IMPI and IMPU. After receiving this request, the S-CSCF sends an authentication vector request (AV-Req (IMPI, m)) to the HSS for getting an AV vector, and HSS generates and sends an n-ordered array of AVs to S-CSCF and a sequence number in AV-Req-Response. Each AV consists of CK, IK, RAND, XRES, and AUTHN, as given in the following equation:

AV = RANDAUTNXRESCKIK

(2.1)

Each AV is required for one authentication process and is selected on a first-in/first-out basis. The S-CSCF sends a SIP authentication challenge (Auth-Challenge) to P-CSCF via I-CSCF, and the P-CSCF stores the keys (IK,

40


CK) and forwards the remaining message (Auth-Challenge (IMPI, RAND, AUTN)) to the client. The network starts the authentication procedure by using an authentication request that contains a random challenge (RAND) and authentication token (AUTN). The AUTN is calculated as given:

AUTN = SQN + AK ⊕ AMF ⊕ MAC

(2.2)

where SQN is sequence number, ⊕ is XOR addition, and AMF is an authentication and key management field. AK = F5K (RAND); F5 is a key generating function. Upon receiving a challenge, the client takes AUTN, which includes MAC and SQN. The client calculates XMAC as given in Equation 2.3 and verifies that XMAC = MAC and SQN in correct range:

XMAC = F1K (SQN ⊕ RAN ⊕ AMF)

(2.3)

If both are all right, the client calculates Auth-Response, including RES and some other parameters, and sends it back to P-CSCF in a REG (IMPI, Auth-Response) message. The client also calculates the CK and IK keys at this stage as given in the following equation:

CK = F3K(RAND) & IK = F4K (RAND)

(2.4)

where F3 and F4 are key generating functions and RAND is a random value. The P-CSCF forwards this response to I-CSCF, which queries the HSS to find the address of S-CSCF; the I-CSCF forwards this response to the S-CSCF. The S-CSCF retrieves RES from the response and compares it with XRES 0. If verification is successful, the client has been authenticated and the user’s IMPU is registered in the S-CSCF. The complete procedure is explained in Figure 2.5. The ISIM verifies the AUTN for network authenticity. The ISIM and the HSS keep track of sequence numbers SQNISIM and SQNHSS, respectively, for each round of authentication procedures. If the ISIM detects an authentication whose sequence number is out of range, it aborts the authentication and reports back to the network with a synchronization failure message, including correct sequence number 0. This technique is used to provide for antireplay protection. The ISIM produces an authentication response (RES), as in Equation 2.5, from a secret key and random challenge (RAND) in respond to the network’s authentication request:

RES = F2K (RAND)

(2.5)

where F2 is a message authentication function. By this process the UE and home network have successfully authenticated and have established a secure communication channel. The device on which ISIM resides is tamper resistant, and physical access only is not sufficient to

41


P-CSCF

UE REG(IMPI, IMPU)

I-CSCF REG(IMPI, IMPU)

HSS

S-CSCF

CX-Selection REG(IMPI, IMPU)

CX-PUT AV-Req(IMPI, m) AV-Req-Resp(IMPI, AV(1…n))

Auth-Challenge(IMPI, RAND, AUTN, IK, CK)

Auth-Challenge(IMPI, RAND, AUTN) REG(IMPI, Auth-Resp)

REG(IMPI, Auth-Resp)


CX-Query REG(IMPI, Auth-Resp) CX-PUT CX-PULL

Auth OK

Auth OK

Auth OK

Figure 2.5 IMS authentication process.

result in exposing the secret key. It is further protected by the PIN code from unauthorized access. Thus, a combination of ownership of physical device USIM/ISIM and knowledge of the secret PIN code makes the security architecture of IMS more robust. Encryption and Secrecy The Gm reference point connects the user to the IP multimedia system core. It is used to transport all SIP [4] signaling messages between UE and P-CSCF. The protection of this interface is essential and, therefore, its security is considered very important. In IMS, NDS/IP is used to protect SIP signaling, but SIP communication at the Gm interface between UE and P-CSCF is outside the scope of NDS/IP and needs additional measures for security. The

42

IP Multimedia Subsystem (IMS) Handbook Unsecured Authentication

UE

Secured Authentication

S-CSCF

UE

Auth Req

P-CSCF Register

Unprotected

401 Unauthorized

Register

Auth Challenge

Port-UC

Register, RES OK

Register

Port-PS Protected by Integrity

Invite Verification

Port-US

Auth OK

180 Ringing

Port-PC Protected by Confidentiality

200 OK

Figure 2.6 Unsecured and secured authentication scenarios.

IMS in 3GPP releases 5 and 6 makes use of IPsec as the security mechanism between P-CSCF and the UE. The IPsec [55] is only one of several possible security mechanisms. The IMS was designed to allow alternative security mechanisms over the Gm interface as well. Allowing such openness usually creates backward compatibility problems because, for example, a release 6-compliant UE would not be able to understand any alternative security mechanism, although it could be attached to P-CSCF of higher release that would already support alternatives to IPsec [7]. Therefore, the SIP security mechanism agreement (Sip-Sec-Agree) [56] was introduced to allow UE and P-CSCF to negotiate a common security mechanism for use between them. For current releases, the only security mechanism is IPsec; however, it might be that some entities already support alternative mechanisms on a proprietary basis (Figure 2.6). During authentication of user, UE and IMS also negotiate security mechanisms for securing subsequent SIP traffic in Gm interface. The SIP protocol is used for this security agreement, and the UE and P-CSCF exchange their respective lists of supported security mechanisms; the highest commonly supported one is selected to provide data integrity protection. Once


43

the security mechanism has been selected and its use started, the previously exchanged list is replayed to the network in a secure fashion. This helps the network to verify that the security mechanism selection was correct and the security agreement was not tampered with. An example of an attack that would be possible without this feature is a bidding-down attack, where an attacker forces peers into selecting a known weak security mechanism. The IPsec encapsulated security payload (ESP) [57] provides confidentiality as well as data integrity and authentication, which are mandatory in IMS access security. AKA session keys are used as keys for the ESP SAs (i.e., IK is used as authentication key and CK as encryption key). The AKA protocol cannot run directly over IP and requires a vehicle to carry protocol messages between the UE and the home network. The SIP acts as a vehicle for the AKA protocol and it is tunneled inside SIP; therefore, IMS access is obviously to authenticate it. Use of IPsec ESP for SIP Confidentiality and Integrity Protection In order to provide the SIP integrity protection between UE and P-CSCF, the recommended protocol is IPsec ESP [7], which protects all SIP signaling messages at the IP layer. The use of ESP for integrity protection will be applied in transport mode. In this mode, the TCP header, payload, and padding fields are encrypted in the IP packet; a new ESP header, which contains information like the security parameter index (SPI), is added between IP header and encrypted data. Finally, the message authentication code (MAC) is calculated on all the data except the IP header. The receiver checks integrity protection by calculating the MAC and comparing it with the received MAC. The integrity algorithm is either hash message authentication code–message digest (HMAC-MD5-96) [58] or secure hash algorithm (HMAC-SHA-1-96) [59]. If the selected algorithm is HMAC-MD5-96, then the integrity key (IKESP) is calculated as follows (128 bits):

IKESP = IKIM

(2.6)

For the other algorithm (HMAC-SHA-1-96), the integrity key (IKESP) is calculated as follows to create a 160-bit key:

IKESP = IKIM  32 bits zeros string

(2.7)

In order to provide confidentiality to SIP signaling on the air interface, UE and P-CSCF agree on the specific encryption algorithm, mechanism, and encryption key. The IPsec ESP [60] in transport is recommended by 3GPP to provide confidential protection of SIP signaling at the Gm interface between IMS core and IMS client. The encryption algorithm is either data encryption standard–triple DES used in cipher block code (DES-EDE3-CBC) [61] or advance encryption standard in cipher block code (AES-CBC) [62] with a 128-bit key. The encryption key (CKESP) for DES-EDE3-CBC is calculated as

44

IP Multimedia Subsystem (IMS) Handbook CKESP = CKIM1  CKIM2  CKIM1

(2.8)

where CKIM1 (64 bits) and CKIM2 (64 bits) are derived from CKIM (128 bits) as

CKIM = CKIM1  CKIM2

(2.9)

If the selected algorithm is AES-CBC, then encryption key (CKESP) is:

KESP = CKIM

SIP Integrity and Confidentiality Procedure Now we discuss the procedure to set up security associations between the client (UE) and P-CSCF for the protection of the Gm interface. The client sends a security set-up message in the REG (Sec-Setup = SPI-U, Port-U, UE I & E Algorithms List) message as shown in Figure 2.7, where SPI-U = (SPI-UC, SPI-US), a pair of security parameter index values that the client selects; Port-U = (Port-UC, Port-US), a pair of protected port numbers of clients and server; and UE I & E Algorithms List = list of integrity and encryption algorithm identifiers that the client supports. Upon receipt of this message, P-CSCF stores security parameters along with the client’s IMPI, IMPU, and IP address and adds keys IKIM and CKIM received from S-CSCF. Next, the P-CSCF sends Auth-Challenge (Sec-Setup = SPI-P, Port-P,P-CSCF I & E Algorithms List) to the client, where SPI-P = (SPI-PC, SPI-PS), a pair of SPI values that P-CSCF selects; Port-P = (Port-PC, Port-PS), a pair of protected port numbers of clients and server; and P-CSCF I & E Algorithms List = list of integrity and encryption algorithm identifiers that P-CSCF supports. The client then sends a final security set-up message as REG (Sec-Setup = SPI-U, Port-U, SPI-P, Port-P, P-CSCF I & E Algorithms List) to P-CSCF and it checks whether these parameters are the same. If they match, registration is successful. Finally, P-CSCF sends REG (Integrity-Protection = Successful, Confidentiality-Protection = Successful, IMPI) to S-CSCF to inform that client messages are integrity and confidentiality protected [54].

45


P-CSCF

UE REG(IMPI, IMPU)

I-CSCF REG(IMPI, IMPU)

HSS

S-CSCF

CX-Selection

REG(Sec-Setup=SPI-U, Port-U, UE I & E Algorithms List)

REG(IMPI, IMPU)

CX-PUT AV-Req(IMPI, m) AV-Req-Resp(IMPI, AV(1…n))

Auth-Challenge(IMPI, RAND, AUTN)



Auth Challenge (Sec-Setup= SPI-P, Port-P, P-CSCF I & E Algorithms List) REG(IMPI, Auth-Resp)

REG(IMPI, Auth-Resp)

CX-Query REG(IMPI, Auth-Resp)

REG(Sec-Setup=SPI-U, Port-U, SPI-P, Port-P, P-CSCP I & E Algorithms List)

REG(Integrity-Protection=Successful, Confidentiality-Protection=Successful, IMP) CX-PUT CX-PULL

Auth OK

Auth OK

Auth OK

Figure 2.7 Authentication with integrity and confidentiality protection.

Interdomain Security The IMS supports communication between home network and visited network, creating two scenarios of whether the IMS terminal is in the home network or roaming. In the first scenario the UE’s first point of contact to IMS, called P-CSCF, is located in the home network, and in the second scenario the P-CSCF is located in the visited network (roaming), as depicted in

46


Visited Network

Home Network

ISC

AS

Gm

Sh

Cx

P-CSCF

Mw

S-CSCF

Cx

I-CSCF

HSS

IMS Client Figure 2.8 IMS roaming scenario.

Figure 2.8. The traffic between the visited and home networks is protected using NDS/IP at the IP layer [63]. The NDS/IP only protects traffic between network elements in an IP layer. A security domain is a network operated by a single administrative authority that implements a uniform security policy within that domain. As a result, the level of security will be the same within a security domain. For the most part, the security domain is related directly to an operator’s core network; however, it is possible to run several security domains making a subset of the operator’s entire core network. IMS protects all IP traffic in the core network using NDS/IP, which provides confidentiality, data integrity, authentication, and antireplay protection for traffic using a combination of cryptographic security mechanisms and protocol security mechanisms applied in IPsec. In the NDS/IP platform, the interfaces between elements inside the security domain are denoted by Zb and interfaces between different security domains are denoted by Za, as shown in Figure 2.9. Use of the Za interface is always mandatory between different security domains; use of the Zb interface is optional and up to the security domain’s administrator. Data authentication and integrity are mandatory for both interfaces, and use of encryption is recommended for Za and optional for Zb. The NDS/IP is used to protect the operator’s IMS core network as well as traffic between the visited and home networks. The fundamental idea of NDS/IP architecture is to provide hop-by-hop security, according to the chained-tunnels or hub-and-spoke models of operation. Utilizing hop-byhop security also makes it easy to maintain separate security policies internally and toward other external security domains. The network entities

47

IMS—A Secure Architecture for All IP Networks Domain C UE-A Visited Network

Domain A UE-A Home Network

Domain B UE-B Home Network

Za

Za

SEG-C

Zb

Zb

SEG-B

Zb

Zb

Zb SEG-A

Cx

Mw

I-CSCF Cx

S-SCF

ISC

Mw

S-CSCF

ISC

Cx

Mw

I-CSCF

Cx

P-CSCF

Gm

Gm

P-CSCF Sh

Sh

AS

HSS

AS

UE-A

HSS UE-B

Figure 2.9 Visited and home network scenarios.

(NEs) establish and maintain ESP SAs as needed toward an SEG or other NEs within the same security domain. All NDS/IP traffic from an NE in one security domain toward an NE in another security domain is routed via SEG and will receive hop-by-hop security protection toward the final destination [63]. The operators may decide to establish only one ESP SA between two communicating security domains, which will lead to coarse-grained security granularity. This has the benefit that a certain measure of protection against traffic flow analysis is given. However, the disadvantage is that it is not possible to differentiate the security protection provided between the communicating entities. This does not preclude negotiation of finer-grained security granularity at the discretion of the communicating entities. Network Domain Security (NDS) Architecture Network domain is a network controlled by a single operator or administrator authority to implement uniform security policy within the domain. Hence, the level of security and the available security services will be the same within a security domain. The domain security is applied on the border of an operator’s network and protected by SEGs [63], which are responsible for enforcing the security policy of the security domain toward other security domains’ SEGs. The NDS/IP is used to protect the operator’s IMS core network as well as the traffic between the visited and home networks. The fundamental idea of the NDS/IP architecture is to provide hop-by-hop security, according to the

48


chained-tunnels or hub-and-spoke models of operation. Utilizing hop-by-hop security helps to maintain separate security policies internally and toward other external security domains [64]. In NDS/IP, security gateways maintain IPsec-secure ESP SAs in tunnel mode between security domains. All NDS/ IP traffic from NEs of a security domain is routed via SEG to another security domain using hop-by-hop security protection to the end destination. Different entities and interfaces of network domain security architecture are given next. NDS interfaces. As we know, security between different domains is implemented by the NDS/IP protocol through SEGs. The interfaces between security domains are represented as Za and the interfaces within the security domain are represented as Zb. The Za interface covers all NDS/IP traffic between security domains. For the Za interface, authentication and data integrity protection are required and data encryption is recommended. These three security features are implemented by using the ESP protocol [57], and SEGs use IKE to negotiate, establish, and maintain a secure ESP tunnel between them for forwarding NDS/IP traffic between security domains. The security policy over the Xa interface depends upon the roaming agreement. For the Zb interface, authentication and data integrity protection are required and implemented by using the ESP protocol. Data encryption is optional on this interface and depends upon the decision of the security domain operator. Security gateways are network entities on the borders of IP security domains providing security to IP-based protocols and establishing the communication over the Za interface. All NDS/IP traffic goes through an SEG before entering or leaving the security domain. A security domain can have more than one SEG, depending upon the number of destinations, avoiding single point failure, traffic load balancing, etc. Each SEG is defined to handle NDS/ IP traffic by well-defined rules to reach IP security domain. When protecting interdomain IMS traffic, it is mandatory to provide confidentiality, data integrity, and authentication in the NDS/IP. The security gateways enforce the security policies for the interworking between networks. The security may include filtering policies as well as firewall functionality. The SEGs are responsible for security-sensitive operations and need to be physically secured. As we have discussed, the SEGs establish and maintain an IPsec-secured ESP SA in tunnel mode between security domains. The SEG will normally provide at least one IPsec tunnel at all times to a particular peer SEG. Each SEG is responsible for setting up and maintaining IPsec SAs with its peer SEGs. These SAs are negotiated using the IKE [65] protocol, where authentication is done using long-term keys stored in the SEGs. Each SEG maintains two SAs per connection: one for inbound traffic and another for outbound traffic. In addition, it maintains a single Internet security association and key management protocol (ISAKMP) SA [66] for key management. The

49

IMS—A Secure Architecture for All IP Networks Domain B

Domain A Za IKE Link ESP Link

SEG-A Zb

Zb

ISC

S-CSCF Gm

P-CSCF

Zb

Zb

Mw

ISC

Cx

P-CSCF

ISC

Sh

UE-A

AS

Cx

Zb

Zb

Mw

I-CSCF

Cx

SEG-B

Mw

S-CSCF

Cx

I-CSCF Gm

Sh

HSS

AS

HSS

UE-B

Figure 2.10 Security gateway architecture.

prerequisite for the ISAKMP SA is that the peers should be authenticated. In the NDS/IP, authentication is based on preshared secrets. The architecture for SEGs is presented in Figure 2.10. The SEG will maintain a logically separate security associations database and security policy database for each interface [63]. Their functionalities include: The security policy database (SPD) contains the policies by which all inbound and outbound traffic is categorized by security gateways. In general, packets are selected for one of three processing modes based on IP and transport layer header information matched against entries in the database (SPD). A packet is afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the selectors. The security associations database (SAD) is a container for all active SAs and related parameters. A set of selectors—IP layer and upper layer (e.g., TCP and UDP) protocol field values—is used by the SPD to map traffic to a specific SA. This relationship is represented by a set of information that can be considered as a contract between the SEGs. The information must be agreed upon and shared between all the SEGs, and all SEGs must adhere to the SA for secure communications to be possible. When accessing SA attributes, SEGs use a pointer or identifier referred to as the security parameter index (SPI) [63].

50


Use of IPsec in an NDS/IP Environment This section provides an overview of the features of IPsec that are used by NDS/IP and defines minimum sets of features that must be supported. The security services provided by NDS/IP are data integrity, data origin authentication, anti-replay protection and limited protection against traffic flow analysis, and confidentiality. IPsec provides security services at the IP layer by enabling a system to select the required security protocols, determine the algorithms to be use for the service, and provide the cryptographic keys required for the requested services. It can be used to protect one or more links between a pair of SEGs or between an SEG and a host. The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets, and confidentiality. Because these services are provided at the IP layer, they can be used by any higher-layer protocol. The components of the IPsec security architecture are security protocols, security associations, key management, and encryption and authentication algorithms. Security protocols. The IPsec uses two protocols to provide traffic security (i.e., authentication header [AH] and ESP). These protocols may be applied alone or in combination to provide a desired set of security services in Ipv4 and Ipv6. Each protocol supports two modes of use (i.e., transport mode and tunnel mode). In transport mode, the protocols provide protection primarily for upper-layer protocols. Tunnel mode is typically used to tunnel IP traffic between two SEGs. The difference is that in transport mode IPsec offers limited protection to IP headers, whereas in tunnel mode the full IP datagram is protected. The security protocol used in the NDS/IP for encryption, data integrity protection, and authentication is the IPsec ESP [57] in tunnel mode (i.e., the full IP datagram, including the IP header, is encapsulated in the ESP packet). The ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of security association establishment and on the placement of the implementation. The anti-replay service may be selected only if data origin authentication is selected, and its selection is solely at the discretion of the receiver [57]. The ESP is used to provide security services in IPv4 and IPv6. To process outbound traffic, a host or security gateway first uses a set of selectors in the SPD to determine the outbound SA used. It then follows a set of steps to process the outbound packet: • The entire original outbound IP datagram is encapsulated in an ESP payload field in tunnel mode. • Appropriate padding is added to the payload data. • The results are encrypted using an encryption key and an algorithm. • The sequence number is incremented as appropriate.


51

• If authentication is enabled, then the integrity check value (ICV) is calculated. • Possible fragmentation of the IP datagram is performed. On receiving an IP datagram, the recipient follows the following steps to process the packet: • Possible reassembly of the IP datagram is performed. • Using the SPI, security protocol, and destination IP address, an appropriate SA is looked up from the SAD. • If anti-replay protection is enabled, the sequence number is inspected. • If authentication is enabled, then the ICV is verified. • The packet is decrypted, padding is removed, and the original IP datagram is reconstructed. The ESP header is designed to provide a mix of security services in IPv4 and IPv6. The header is inserted before an encapsulated IP header in tunnel mode. Thus, the format of ESP packets for a given SA is fixed for the duration of the SA. The tunnel mode ESP is employed by the SEGs to protect transit traffic. The inner IP header carries the ultimate source and destination addresses, whereas an outer IP header may contain distinct IP addresses— usually addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header [66]. If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the authentication data field. This order of processing facilitates rapid detection and rejection of replayed or counterfeit packets by the receiver prior to decrypting the packet, potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver; hence, decryption can take place in parallel with authentication. Security association is a set of policy and keys used to protect information and is defined as the relationship between two SEGs that allows the protection of information communicated between them and that defines how they are going to use security services to secure their communications. It includes information on authentication or encryption algorithms, cryptographic keys, and key lengths as well as the initialization vectors (IVs) that are shared between the entities. An SA is unidirectional, so typically two SAs are needed for a bidirectional flow of traffic—one for inbound (read) traffic and one for outbound (write) traffic. Security protocols make use of SAs because they provide security services. This relationship includes a shared symmetric key and security attributes describing the relationship. It is uniquely identified by SPI [57] and destination IP address.

52


With regard to the use of IPsec security associations in the network domain of NDS/IP networks, the NDS/IP requires support for tunnel mode IPsec SAs and support for ESP SAs. The specification of IPsec SAs is available in RFC-2401 [55]. With regard to the use of ISAKMP security associations in the network domain of NDS/IP networks, the NDS/IP only requires support for ISAKMP SAs with preshared keys. The specification of ISAKMP SAs is available in RFC-2408 [66]. Key management. The process of distribution of cryptographic keys to be used with the security protocols (namely, the IKE) is called key management. In the IMS/UMTS network domain security architecture, the key distribution between SEGs is handled by the IKE protocol [66]. The main purpose of IKE is to negotiate, establish, and maintain SAs between network entities that are used to establish secure communications. The IKE automatically negotiates IPsec SAs and enables IPsec-secure communications [65]. There are two basic methods used to establish an authenticated key exchange: main mode and aggressive mode. Each mode generates authenticated keying material from an ephemeral Diffie–Hellman exchange. Main mode must be implemented and aggressive mode should be implemented. In addition, quick mode must be implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services; new group mode should be implemented as a mechanism to define private groups for Diffie–Hellman exchanges [60]. Specifically, IKE provides the following benefits: • It eliminates the need to specify manually all the IPsec security parameters in the crypto maps at both peers. • It allows specifying a lifetime for the IPsec security association. • It allows encryption keys to change during IPsec sessions. • It allows IPsec to provide anti-replay services. • It permits certification authority (CA) support for a manageable, scalable IPsec implementation. • It allows dynamic authentication of peers. The IKE protocol is used for negotiation of IPsec SAs, with the following additional requirement for intersecurity domain SA negotiations over the Za interface [67]. • IKE phase-1 (ISAKMP SA) • The use of preshared secrets for authentication will be supported [68]. • Only ISAKMP main mode will be used. • IP addresses and fully qualified domain names (FQDNs) will be supported for identification.


53

• Support of 3DES in CBC mode [69] will be mandatory for confidentiality. • Support of AES in CBC mode [62] will be mandatory for confidentiality. • Support of SHA-1 [59] will be mandatory for integrity/message authentication. • Support of Diffie–Hellman group 2 will be mandatory for the Diffie–Hellman exchange [70]. Phase-1 IKE SAs will be persistent with respect to the IPsec SAs (i.e., IKE SAs will have a lifetime for at least the same duration, as do the derived IPsec SAs). The IPsec SAs should be rekeyed proactively (i.e., a new SA should be established before the old SA expires [68]). • IKE phase-2 (IPsec SA) • Perfect forward secrecy is optional. • Only IP addresses or subnet identity types will be mandatory address types. • Support of notifications will be mandatory. • Support of Diffie–Hellman group 2 will be mandatory for the Diffie–Hellman exchange. Encryption and authentication algorithms. To implement the IMS interdomain security, 3GPP recommends encryption and the triple DES (3DES) [69] algorithm is mandatory, but for data integrity and authentication both MD5 [71] and SHA-1 [59] can be used. IPsec offers a set of confidentiality transform supports including ESP_NULL and ESP_DES transforms. However, the DES algorithm is no longer considered sufficiently strong in terms of cryptographic strength. It is mentioned by IESG in RFC 2407 [72] that the ESP_DES transform is likely to be deprecated in the near future. It is therefore explicitly recommended in NDS/IP that the ESP_3DES algorithm is mandatory instead of ESP_DES. Also, the support for the AES–CBC cipher algorithm [62] is mandatory with a key length of 128 bits. The IPsec offers data integrity transforms that compliant IPsec implementation is required to support, including the ESP_NULL, ESP_HMAC_MD5, and ESP_HMAC_SHA-1 transforms. For NDS/IP traffic, ESP will always be used to provide integrity, data origin authentication, and anti-replay services; thus, the ESP_NULL authentication algorithm is explicitly not allowed for use. ESP will support ESP_HMAC_SHA-1 algorithm in NDS/IP. Public Key Infrastructure (PKI) Public key cryptography, also known as asymmetric cryptography, utilizes a pair of keys—one private and the other public—that are mathematically.

54


related. Information is encrypted with the public key and can only be decrypted with the corresponding private key. In this system, the public keys of all users are published in an open directory, facilitating communications between all parties. The private key is not shared; only the public key is made public. Public key cryptography can also be used to create and verify digital signatures by changing the key order by encryption and decryption [70]. These can be appended to messages to provide proof of authentication, integrity, and nonrepudiation. The PKI Forum has provided PKI technical perspective [73] to use PKI technology in specific vendor environments, addressing the following issues [64]: • security policies that define the rules under which the cryptographic systems should operate; • procedures to generate, store, and manage the keys; and • procedures on how the keys and certificates are generated, distributed, and used. A PKI is a combination of policies and procedures, hardware and software. PKI is based on digital IDs known as “digital certificates” that bind the user’s digital signature to his or her public key. PKI consists of the following components. Security policy sets out and defines the top-level direction on information security as well as the processes and principles for the use of cryptography. Typically, it will include statements on how to handle keys and valuable information and will set the level of control required to match the levels of risk. Certification authority (CA) is the trust basis of a PKI because it manages public key certificates for their whole life cycle. The CA system performs the following tasks: • It issues certificates by binding the identity of a user or SEG to a public key with a digital signature. • It schedules expiry dates for certificates. • It ensures publishing certificate revocation lists (CRLs) to revoke certificates when necessary. The PKI must ensure that the CA’s private key is held in a tamper-resistant security module, and provision must be made for backup copies for disaster recovery purposes. Access to the CA and RA should be tightly controlled. All certificate requests should be digitally signed to detect and prevent hackers from deliberately generating counterfeit certificates. All significant events performed by the CA system should be recorded in a secure audit trail, where each entry is time/date stamped and signed to ensure that entries cannot be falsified. The trust relationship between two authorities is established by crosscertification. When CA A is cross-certified with CA B, this implies that A has chosen to trust certificates issued by B. The cross-certification process enables the users under both authorities to trust the other authority’s certifi-


55

cates. Trust in this context equals being able to authenticate. There are two types of cross-certification processes: Manual cross-certification. In manual cross-certification, mutual crosscertifications are established directly between the CAs. The authority makes decisions about trust locally. When CA A chooses to trust CA B, then A signs the certificate of the authority B and distributes the new certificate (B’s certificate signed by A) locally. The disadvantage of this approach is that it often results in scenarios where there need to be a large number of certificates available for the entities doing the trust decisions: A certificate must be signed by the local CA for each security domain that the local authority wishes to trust. However, all the certificates can be configured locally and are locally signed, so their management is often flexible. Bridge cross-certification. The bridge CA is a concept that reduces the number of certificates that need to be configured for the entity that does the certificate checking. When two authorities are mutually cross-certified with the bridge, the authorities do not need to know about each other. Authorities can still trust each other because the trust in this model is transitive (i.e., A trusts bridge and bridge trusts B; thus A trusts B and vice versa). The bridge CA acts like a bridge between the authorities and the two authorities also trust that the bridge CA is trusted and secure. Bridge CA style cross-certifications are useful in scenarios where all entities communicate a common trusted third party. If an authority needs to restrict the trust or access control derived from the bridge CA, it additionally needs to implement those restrictions [68]. PKI-Based NDS Authentication Framework This section explains the implementation of a PKI-based network domain security/authentication framework that uses a simple access control method (i.e., each element that is authenticated also provides a service). The architecture uses direct cross-certifications between the security domains, which enables easy policy configurations in the SEGs [68]. Each security domain has at least one local certificate authority (LCA) and one domain certificate authority (DCA), as shown in Figure 2.11. Their functionality is given as: • The LCA of the domain issues certificates to the SEGs in the domain that have interconnection with SEGs in other domains. • The DCA of the domain issues certificates to the LCAs of other domains with which the operator’s SEGs have interconnection. • All the certificates are based on the Internet X.509 certificate profile [74].

56

IP Multimedia Subsystem (IMS) Handbook Certificate Authority A

Certificate Authority B

LCA-A

REG-A2

REG-A1

DCA-A

CA-B

LCA-B

CA-C

REG-B2

REG-B1

DCA-B

CA-A

CA-C

Figure 2.11 Security gateways architecture.

The LCA issues certificates for SEGs that implement the Za interface. When the SEG of the security domain A establishes a secure connection with the SEG of the domain B, they are able to authenticate each other. The mutual authentication is checked using the certificates the LCAs issued for the SEGs. When a roaming agreement is established between the domains, the DCA cross-certifies the LCA of the peer operator. The created cross-certificates need only to be configured locally to each domain. The cross-certificates issued by DCA-A of security domain A for the LCA of security domain B will be available for the SEG of domain A, which implements the Za interface toward domain B. Similarly, the cross-certificates issued by DCA-B of security domain B for the LCA of security domain A will be available for the SEG of domain B, which implements the Za interface toward domain A. After cross-certification, the SEG-A is able to verify the following path (Figure 2.12):

SEG-B → LCA-B → DCA-A Similarly, the SEG-B is able to verify the path:

SEG-A → LCA-A → DCA-B

If the verification process is satisfied, then both domains A and B can trust each other and use the certificates for each other. The public key of the DCA is stored securely in each SEG within the operator’s domain. This allows the SEG to verify cross-certificates issued by its operator’s DCA. It is assumed that each operator domain could include 2–10 SEGs. An operator may decide to set up both LCA and DCA as a single CA (i.e., separation of CAs is not required). The NDS/AF is initially based on a simple trust model that avoids the introduction of transitive trust or.

57

IMS—A Secure Architecture for All IP Networks Domain A

Domain B

DCA-B

DCA-A

Local CRL-A

Local CRL-B

Local CR-A

Local CR-B

LCA-A

LCA-B

Public CRL-A

Public CRL-B

IKE Link Za Za ESP Link SEG-A

SEG-B

Figure 2.12 Distribution of certificates.

additional authorization information. The simple trust model implies manual cross-certification [68]. Now we discuss the design use cases of NDS/AF. Creating/terminating a roaming agreement. When a roaming agreement is required, the SEGs of two different domains establish the secure tunnel using cross-certificates issued by DCA of two domains. The creation of a roaming agreement only involves use of the private keys of the DCAs. There is no need for the operators to use the private keys of their respective LCAs in forming a roaming agreement. When creating the new cross-certificate, the DCA sets the path length to zero to initiate the new cross-certificate to be used in signing new CA certificates. When the new cross-certificate is available to the SEG, its information is configured in the SEG. The authentication can be done based on the created cross-certificates. When a roaming agreement is terminated or due to an urgent service termination need, all concerned SEG peers will remove the IPsec SAs using device-specific management methods. Each concerned operator will also list the cross-certificate created for the DCA of the terminated operator in his or her local CRL [68].

58


Creating a VPN tunnel. After establishing a roaming agreement and finishing the required certificate management operations, the operators configure their SEGs for SEG–SEG connection, and the SAs are established as specified by NDS/IP. In each connection configuration, the remote SEG DNS name or IP address is specified. Only the local DCA and LCA are configured as trusted CAs [68]. Because of the cross-certification, any operator whose LCA has been cross-certified can get access using this VPN connection configuration. Now we discuss the flow of connection negotiation, as mentioned in Karn, Metzger, and Simpson [69], from SEG-A, which is the initiator. The SEG-B, which is the responder, will perform the same function. During connection initiation, the initiating SEG-A provides its own SEG certificate and the corresponding digital signature in IKE main mode message 3: • SEG-A receives the remote SEG-B certificate and signature. • SEG-A validates the remote SEG-B signature. • SEG-A verifies the validity of the SEG-B certificate by a CRL check to both the operator A and operator B CRL databases. If an SEG cannot successfully perform both CRL checks, it assumes an error and aborts tunnel establishment. • SEG-A validates the SEG-B certificate using the cross-certificate for LCA-B by executing the following actions:

1. SEG-A verifies the validity of the cross-certificate for LCA-B by a CRL check to the DCA-A CRL database. If an SEG cannot successfully perform the CRL check, it will assume an error and abort tunnel establishment.

2. SEG-A validates the cross-certificate for LCA-B using its DCA certificate if DCA is not a top-level CA; otherwise, the DCA public key is implicitly trusted.

In this way, the IKE phase 1 SA is established and the phase-2 SA negotiation proceeds as described in NDS/IP with PSK authentication. Certificate profiles. Before fulfilling any signing certificate request, the LCA and DCA will make sure that the request meets the following certificate profile criteria: • Certificates of version 3 are in use according to RFC 3280 [75]. • Support of SHA-1 has an algorithm. • For DCA and LCA certificates, the RSA key length will be at least 2,048 bits. • For the SEG certificate, the RSA key length will be at least 1,024 bits. SEG certificate validation. During VPN tunnel establishment, each SEG has to verify the validity of its peer SEG certificate. SEG-A verifies the validity of the cross-certificate of LCA-B and the certificate of SEG-B, and it will be


59

able to fetch the cross-certificate of LCA-B. SEG-B performs the same process for the validity of SEG-A certificates. At this point, the VPN tunnel is not yet available; therefore, the CRL of the peering LCA will be accessible for SEG without utilizing the Za interface.

Security Management for HTTP-Based Services The Ut interface is the reference point between the UE and AS that enables users to manage and configure their network services–related information hosted on an AS securely. Users can use a Ut reference point to create public service identities, such as a resource list, and manage authorization policies that are used by the service. Examples of services that utilize the Ut reference point are presence and conferencing. The AS may need to provide security for the Ut reference point. HTTP is the chosen data protocol for the Ut reference point that performs the functionality to manage data traffic for HTTP-based applications. Thus, securing the Ut interface means to achieve confidentiality and data integrity protection of HTTP-based traffic. The authentication and key agreement for Ut interface are also based on AKA. The IMS defines GBA [51] as a part of GAA that performs mutual authentication between BSFs and the UE. The AKA generates session keys and enables further applications provided by the network application function (NAF) that issues subscriber certificates using an applications protocol secured by bootstrapped session keys. The authentication in Ut interface is performed by authentication proxy. In terms of GBA, the authentication proxy is another type of NAF. Traffic in Ut interface goes through authentication proxy and is secured using the bootstrapped session key. The Ut interface employs a TLS [52] for both confidentiality and integrity protection. It utilizes GBA to ensure that the request is coming from an authorized subscriber of the mobile network operator. When an HTTPS request is sent to AS through AP that performs UE authentication, the AP may insert the user identity when it forwards the request to the application server. Generic Bootstrapping Architecture (GBA) Different 3G multimedia services, including video conferencing, presence, push-to-talk, and messaging, have potential usage of GBA to distribute subscriber certificates. These certificates are used by mobile operators to authenticate the subscriber before accessing the multimedia services and applications. Now we discuss components, entities, and interfaces of GBA. The GBA consists of four entities: UE, NAF, BSF, and HSS, which are briefly explained next and are shown in Figure 2.13:

60

IP Multimedia Subsystem (IMS) Handbook BSF

HSS

Ub

Zh Zn

ME

UE

A. GBA Home Network Ua

UICC

NAF

UE

BSF ME

Zh

Ub

Home Network Zn1

UICC Ua

B. Visited Network Zn

NAF

HSS

Zn1

Untrusted Network

D-Proxy Visited Network

Figure 2.13 Network entities of GBA.

User equipment (UE) is a UICC containing USIM- or ISIM-related information that supports HTTP digest AKA- and NAF-specific protocols. A USIM is an application for UMTS mobile telephony running on a UICC smartcard inserted into a 3G mobile phone. It stores user subscriber information and authentication information and provides storage space for text messages. An ISIM is an application running on a UICC smartcard in a 3G telephone in the IMS. It contains parameters for identifying and authenticating the user to the IMS. The ISIM application can co-exist with SIM and USIM on the same UICC, making it possible to use the same smartcard in both GSM networks and earlier releases of UMTS. Network authentication function (NAF) has the functionality to locate and communicate securely with the subscriber’s BSF. It should be able to acquire shared key material established between the UE and the BSF during the run of the application-specific protocol. Bootstrapping server function (BSF) is hosted in a network element under the control of a mobile network operator. The BSFs, HSSs, and UE


61

participate in GBA, in which a shared secret is established between the network and a UE by running the bootstrapping procedure. The shared secret can be used between NAFs and UE, for example, for authentication purposes. A generic BSF and the UE will mutually authenticate using the AKA protocol and agree on session keys that are afterwards applied between UE and an NAF. The BSF will restrict the applicability of the key material to a specific NAF by using the key derivation procedure. This procedure may be used with multiple NAFs during the lifetime of the key material, which is set according to the local policy of the BSF. The BSF will be able to acquire the GBA user security settings (GUSSs) from the HSS [51]. The home subscriber server (HSS) stores GUSSs. The GUSS is defined in such a way that interworking of different operators for standardized application profiles is possible and also that profiles for operator-specific applications and extensions to existing application profiles are supported without need for standardization of these elements. The GUSS will be able to contain application-specific USSs that contain parameters that are related to key selection indication, identification, or authorization information of one or more applications hosted by one or more NAFs. Any other types of parameters are not allowed in the application-specific USS [51]. DIAMETER proxy. In the case where UE has contacted an NAF that is visited/operated in another network than the home network, this visited NAF will use a DIAMETER proxy (D-proxy) of the NAF’s network to communicate with the subscriber’s BSF (i.e., home BSF). General requirements for the functionality of D-proxy are: • D-proxy will be able to function as a proxy between the visited NAF and the subscriber’s home BSF and it will be able to locate the subscriber’s home BSF, and communicate with it over a secure channel. • The D-proxy will be able to validate that the visited NAF is authorized to participate in GBA and will be able to assert to the subscriber’s home BSF the visited NAF’s DNS name. • The D-proxy will also be able to assert to the BSF that the visited NAF is authorized to request the GBA specific user profiles contained in the NAF request [51]. GBA reference points. The reference point Ub is between the UE and the BSF and provides mutual authentication between them. It allows the UE to bootstrap the session keys based on 3GPP AKA infrastructure. The HTTP digest AKA protocol is used on the reference point Ub. It is based on the 3GPP AKA [13] protocol.

62


Ua: The reference point Ua carries the application protocol, which is secured using the key material agreed on between UE and BSF as a result of the run of HTTP digest AKA over reference point Ub. For instance, in the case of support for subscriber certificates, it is a protocol that allows the user to request certificates from the NAF. In this case, the NAF would be the PKI portal. Zh: The reference point Zh used between the BSF and the HSS allows the BSF to fetch the required authentication information and all GBA user security settings from the HSS. The interface to the 3G AUC is HSS internal, and it need not be standardized as part of this architecture. Zn: The reference point Zn is used by the NAF to fetch the key material agreed on during a previous HTTP digest AKA protocol run over the reference point Ub from the UE to the BSF. It is also used to fetch application-specific user security settings from the BSF, if requested by the NAF. Bootstrapping Authentication Procedure The UE and NAF have to decide whether to use GBA before the start of communication between them. When the UE wants to interact with the NAF, it starts communication with the NAF over the Ua interface without GBA parameters. If the NAF requires the use of shared keys obtained by means of the GBA, but the request from UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message [51]. When the UE wants to interact with an NAF and it knows that the bootstrapping procedure is needed, it will first perform a bootstrapping authentication, as shown in Figure 2.14. Otherwise, the UE will perform a bootstrapping authentication only when it has received a bootstrapping initiation required message or a bootstrapping negotiation indication from the NAF, or when the lifetime of the key in UE has expired. The UE sends an HTTP request to the BSF and the BSF retrieves the complete set of GBA user security settings and one authentication vector (AV) [54], as given in Equation 2.10 over the reference point Zh from the HSS. After that, BSF forwards the RAND and AUTN to the UE in the 401 message without the CK, IK, and XRES. This is to demand that the UE authenticate itself. The UE checks AUTN to verify that the challenge is from an authorized network; the UE also calculates CK, IK, and RES [54]. This will result in session keys IK and CK in both BSF and UE. The UE sends another HTTP request to the BSF containing the digest AKA response, which is calculated using RES. The BSF authenticates the UE by verifying the digest AKA response. The BSF generates key material Ks by concatenating CK and IK, and it also generates the B-TID (bootstrapping transaction identifier), which is used to bind the subscriber identity to the keying material in reference points Ua, Ub, and Zn. The BSF will send a 200 OK message, including a B-TID, to the UE to

63

IMS—A Secure Architecture for All IP Networks Ub UE

NAF Ua

BSF Zn

HSS Zh

Request Bootstrap Initiation Request

HTTP Request Get Authentication Vector

401 Message [AKA Challenge(RAND, AUTN etc.)] If AUTN is corrrect, the USIM computes RES, IK, and CK

Digest AKA Response

1. Compares XRES to the received RES 2. Ks = Ck || IK

200 OK Message [B-TID, TI]

Ks = Ck || IK Figure 2.14 Bootstrapping authentication procedure.

indicate the success of the authentication and the lifetime of the key Ks. The key material Ks is generated in UE by concatenating CK and IK. Both the UE and the BSF will use the Ks to derive the key material Ks-NAF, which will be used for securing the reference point Ua. The Ks-NAF is computed as:

Ks-NAF = fKD(Ks, “gba-me,” RAND, IMPI, NAF-ID)

(2.10)

where fKD is the key derivation function and will be implemented in the ME, and the key derivation parameters consist of the user’s IMPI, the NAF-ID, and RAND. The NAF-ID consists of the full DNS name of the NAF, concat-

64


enated with the Ua security protocol identifier. The UE and the BSF will store the key Ks with the associated B-TID for further use, until the lifetime of Ks has expired or until the key Ks is updated [51]. Bootstrapping Usage Procedure Before the start of communication between the UE and the NAF, the UE and the NAF first have to agree whether to use shared keys obtained by means of the GBA. If the UE does not know whether to use GBA with this NAF, it uses the initiation of the bootstrapping procedure. Once the UE and the NAF decide they want to use GBA, every time the UE wants to interact with NAF, the UE starts communication over reference point Ua with the NAF by supplying the B-TID to the NAF to allow the NAF to retrieve the corresponding keys from the BSF. The NAF starts communication over reference point Zn with BSF. The NAF requests key material corresponding to the B-TID supplied by the UE to the NAF over reference point Ua. With the key material request, the NAF will supply NAF’s public hostname that the UE has used to access NAF to BSF, and BSF will be able to verify that the NAF is authorized to use that hostname. The NAF may also request one or more applicationspecific USSs for the applications that the request received over Ua from UE may access. The BSF derives the keys required to protect the protocol used over reference point Ua from the key Ks and the key derivation parameters and supplies to the NAF the requested key Ks-NAF. The BSF also supplies the bootstrapping time and the lifetime of that key as well as the requested application-specific, and potentially NAF group-specific, USSs if they are available in the subscriber’s GUSS and if the NAF is authorized to receive the requested USSs. If the key identified by the B-TID supplied by the NAF is not available at the BSF, the BSF will indicate this in the reply to the NAF. The NAF then indicates a bootstrapping renegotiation request to the UE. The BSF may also send the private user identity (IMPI) and requested USSs to the NAF according to the BSF’s policy. The NAF continues with the protocol used over the reference point Ua with the UE. Once the run of the protocol used over reference point Ua is completed, the purpose of bootstrapping is fulfilled because it enabled the UE and NAF to use reference point Ua in a secure way (Figure 2.15). Authentication Proxy Usage for Multimedia Services The AP is like an NAF and performs the function of HTTP proxy for the UE. It is responsible for handling the TLS and implementing the secure HTTP channel between AP and UE, as shown in Figure 2.16. It utilizes the GBA to assure the ASs that the request is coming from an authorized subscriber of the mobile network operator. When the HTTPS request is sent to the AS through the AP, the AP performs UE authentication. The AP may insert the user identity when it forwards the request to the application server. The.

65

IMS—A Secure Architecture for All IP Networks Ub UE

BSF

NAF Ua

Zn B-TID, Ks Profile

B-TID, Ks

Request Bootstrap Initiation Request Key Derivation Ks Ks-NAF

App Req [B-TID, Msg] Auth Req [B-TID, NAF-Host] Stores Ks-NAF, Profile, Tb, Tk

Auth Ans [Ks-NAF, Profile, Tb, Tk]

App Answer

Figure 2.15 Bootstrapping application.

second part of Figure 2.16 presents the architecture view of using AP for different IMS SIP services (e.g., presence, messaging, conferencing). The UE will manipulate its own data, such as groups, through the Ua/Ut reference point [52]. The reference point Ut will be applicable to data manipulation of IMS-based SIP services, such as presence, messaging, and conferencing services. When the HTTP client starts communication via the Ua reference point with the NAF, it will establish a TLS tunnel with the NAF. The NAF is authenticated to the HTTP client by means of a public key certificate. The HTTP client will verify that the server certificate corresponds to the FQDN of the AP it established the tunnel with. We explain the procedure briefly. The HTTP client sends an HTTP request to NAF inside the TLS tunnel. In response to the HTTP request over the Ua interface, the AP will invoke the HTTP digest with the HTTP client in order

66

IP Multimedia Subsystem (IMS) Handbook AS1

AS2

AS3

ASn-1

ASn

BSF TLS Tunnel

Zn

Ua UF

HSS Zh

AP/NAF Messaging

Ut

Ut

Ut

Presence

Conferencing

Za/Zb Ut

UF

TLS Tunnel

BSF Zn

Ua

Other Services

HSS Zh

AP

Figure 2.16 Authentication proxy.

to perform client authentication using the shared keys. On the receipt of HTTP digest from the AP, the client will verify that the FDQN corresponds to the AP it established the TLS connection with. If not, the client will terminate the TLS connection with the AP. In this way, the UE and AP are mutually authenticated as the TLS tunnel endpoints. Now we discuss an example in which the application residing on the UICC may use TLS over HTTP in the GAA mechanism to secure its communication with AP. The GBA security association between a UICC-based application and AP can be established as the following. The ME executes the bootstrapping procedure with the BSF supporting the Ub reference point. The UICC, which hosts the HTTP client, runs the bootstrapping usage procedure with the AP supporting the Ua reference point [76]. Figure 2.17 shows the use of BIP (bearer independent protocol) to establish the HTTPS connection between the UICC and AP. When the UICC opens a channel with the

67

IMS—A Secure Architecture for All IP Networks UICC

AP/NAF ME

App

App HTTPS Request HTTPS Digest

HTTP

HTTP

HTTPS Response TLS

TLS Tunnel Endpoints

TLS

BIP Open Channel BIP

OK [Channel No]

BIP

Send Data

TCP/IP Packets (Send Data)

TCP/IP

TCP/IP TCP/IP Packets (Receive Data)

Figure 2.17 HTTPS and BIP (bearer independent protocol) procedures.

AP, as described in reference 77, an active TCP/IP connection is established between the UICC and the AP.

References

1. 3rd Generation Partnership Project Technical Specification Group Services and System Aspects, 3GPP, TS 23.228 V6.7.0 (2004-09), IP multimedia subsystems (IMS). 2. 3rd Generation Partnership Project (3GPP). http://www.3gpp.org/ 3. 3rd Generation Partnership Project 2 (3GPP2). http://www.3gpp2.org/ 4. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. 2002. SIP: Session initiation protocol, IETF RFC 3261 (June 2002).

68


5. Calhoun, P., J. Loughney, E. Guttman, G. Zorn, and J. Arkko. 2003. DIAMETER base protocol, IETF RFC 3588 (Sep. 2003). 6. Morelli, A. 2006. The role of a service delivery platform in the battle for new communication revenues. Outlook Point of View. 7. Poikselkae, M., G. Mayer, H. Khartabil, and A. Niemi. 2004. The IMS, IP multimedia concepts and services in the mobile domain. West Sussex, England: John Wiley & Sons Ltd. 8. Sher, M., F. Gouveia, and T. Magedanz. 2007. IP multimedia subsystem (IMS) for emerging all-IP networks. Encyclopedia of Internet Technologies and Applications. IGI Global, formerly Idea Group Inc. 9. ETSI TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking) WG. http://portal.etsi.org/tispan/ 10. UMTS Forum. http://www.umts-forum.org/ 11. DSL Forum. http://www.dslforum.org/ 12. Fixed-Mobile convergence (FMC) alliance. http://www.thefmca.com/ 13. ETSI Mobile Competence Center. 2003. Overview of 3GPP release 5, summary of all release 5 features. http://www.3gpp.org/specs/releases-contents.htm#3GRelease5 14. ETSI Mobile Competence Center. 2006. Overview of 3GPP release 6, summary of all release 6 features. http://www.3gpp.org/specs/releases-contents.htm#3GRelease6 15. Geneiatakis, D., T. Dagiuklas, G. Kambourakis, C. Lambbrinoudakis, S. Gritizalis, S. Ehlert, and D. Sisalem. 2006. Survey of security vulnerabilities in SIP protocol. IEEE Communication Surveys 8(3):68–81. 16. Magedanz, T., K. Knüttel, and D. Witszek. 2005. The IMS playground @ Fokus— An open testbed for next-generation network multimedia services. 1st International IFIP Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities (Tridentcom), 2–11. Trento, Italy, February 23–25. IEEE Computer Society Press, Los Alamitos, CA. 17. Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson. 2003. RFC 3550 RTP. A transport protocol for real-time applications. 18. Rescorla, E. 2000. HTTP over TLS. IEFT RFC 2818. 19. Klensin, J., ed. 2001. Simple mail transfer protocol, IETF RFC 2821. 20. IETF AAA Working Group. IETF Authentication, Authorization and Accounting (AAA) Working Group (accessed 2007). http://ch.tudelft.nl/~arthur/aaa/ links.html 21. Rigney, C., S. Willens, A. Rubens, and W. Simpson. 2000. Remote authentication dial-in user service (RADIUS), IETF RFC 2865. 22. Loughney, J. 2003. DIAMETER command codes for 3rd Generation Partnership Project (3GPP) release 5, RFC 3589. 23. Bellovin, S., J. Ioannidis, A. Keromytis, and R. Stewart. 2003. On the use of stream control transmission protocol (SCTP) with IPSec, IETF, RFC 3554. 24. Berners-Lee, T., R. Fielding, and L. Masinter. 2005. Uniform resource identifier (URI): Generic syntax, IETF RFC 3986. 25. 3rd Generation Partnership Project. Technical specification, 3GPP, TS 29.208, end-to-end quality of service (QoS) signaling flows. 26. Camarillo, G., and M. A. Garcia-Martin. 2006. The 3G IP multimedia subsystem (IMS)—Merging the Internet and the cellular worlds, 2nd ed. Chichester, England: John Wiley & Sons Ltd.


69

27. Magedanz, T., and M. Sher. 2006. IT-based open service delivery platforms for mobile networks—From CAMEL to the IP multimedia system. In Mobile Middleware, ed. P. Bellavista and A. Corradi. Boca Raton, FL: Chapman & Hall/CRC Press. 28. OSA/parlay parlay open service architecture. http://www.parlay.org/en/ index.asp 29. Magedanz, T., and R. Popescu-Zeletin. 1996. Intelligent networks—Basic technology, standards and evolution. London: International Thomson Computer Press. 30. Open Mobile Alliance. OMA: The leading industry forum for developing market-driven, interoperable mobile service enablers. http://www.openmobilealliance.org/ 31. 3rd Generation Partnership Project. Presence service, architecture and functional description (release 6), 3GPP TR 23.841, V6.0.0. (2002-07). 32. Blum, N., and T. Magedanz. 2005. Push-to-video as a platform for NGN services. 11th European Wireless 2005—Next Generation Wireless and Mobile Communications and Services. Nicosia, Cyprus, April 10–13. 33. Knuettel, K., T. Magedanz, and L. Xie. 2006. SIP servlet execution environment (SIPSEE)—An IMS/NGN SIP AS for converged applications. ICIN07 Conference, Bordeaux, France. 34. Magedanz, T. 2005. Tutorial IEEE ISCC. IEEE Symposium on Computer and Communications, Spain, 27 June. 35. Jain, R., J.-L. Bakker, and F. Anjum. 2005. Programming converged networks—Call control in Java, XML, and Parlay/OSA. Hoboken, NJ: John Wiley & Sons, Inc. 36. Bonica, R., D. Gan, D. Tappan, and C. Pignataro. 2007. Extended ICMP to support multi-part messages, IETF RFC 4884. 37. Wu, Y.-S., S. Bagchi, S. Garg, N. Singh, and T. Tsai. 2004. SCIDIVE: A stateful and cross protocol intrusion detection architecture for voice-over-IP environments. 38. Zhang, M., and Y. Fang. 2005. Security analysis and enhancement of 3GPP authentication and key agreement protocol. IEEE Transactions on Wireless Communication 4(2):1276–1536. 39. Low cost tools for secure and highly available VoIP communication services (SNOCER). 2005. A research project supported within the Sixth Framework Program of the EU Commission. http://www.snocer.org 40. Niemi, A., J. Arkko, and V. Torvinen. 2002. HTTP digest authentication using AKA, IETF RFC 3310. 41. Chen, E.Y. 2006. Detecting DoS attacks on SIP systems. IEEE Workshop on VoIP Management and Security, 53–58. 42. Sher, M., S. Wu, and T. Magedanz. 2006. Security threats and solutions for application server of IP multimedia subsystem (IMS-AS). IEEE/IST Workshop on Monitoring, Attack Detection and Mitigation. MonAM06 Proc. IEEE/IST, ISBN: 3-937201-02-5, ISSN: 1862-7803, Diadem Firewall Project (FP6 IST-2002-002154), 38–44, Tuebingen, Germany, September 28–29. http://www.diadem-firewall.org/workshop06/ 43. Sparks, R. 2004. The session initiation protocol (SIP) referred-by mechanism, IETF RFC 3892. 44. 3rd Generation Partnership Project. 2004. Technical specification group services and system aspects; 3G security; security architecture (release 6); 3GPP, TS 33.102 V6. 45. Gurbani, V., and A. Jeffrey. 2006. Draft-gurbani-sip-tls-use-00: The use of transport layer security (TLS) in the session initiation protocol (SIP).

70


46. Kent, S., and R. Atkinson. 1998. Security architecture for the Internet protocol, IETF RFC 2401. 47. Sher, M., and T. Magedanz. 2006. Development of IMS privacy and security management framework for FOKUS open IMS testbed. Journal of Mobile Multimedia 2(3):225–258. http://www.rintonpress.com/journals/jmm/ 48. 3rd Generation Partnership Project. Technical specification group services and system aspects, 3GPP, TS 33.210, network domain security (NDS); IP network layer security V6.5.0 (2004-06). 49. 3rd Generation Partnership Project. 2005. Technical specification group services and system aspects; generic authentication architecture (GAA); generic bootstrapping architecture (GBA) (release 7), 3GPP TS 33.220 V7. 50. 3rd Generation Partnership Project. 2005. Technical specification group services and system aspects; generic authentication architecture (GAA); access to network application functions using hypertext transfer protocol over transport layer security (HTTPS) (release 7), 3GPP TS 33.222 V7. 51. Giovanni, V. et al. 2003. A stateful intrusion detection system for World-Wide Web servers (WEBSTAT). 52. SIPSEE (SIP servlet execution environment) is the FOKUS development of a SIP application server (SIP AS) based on SIP Servlet Technology. 2006, http://www. fokus.fraunhofer.de/bereichsseiten/testbeds/ims_playground/components/ sipsee.php 53. Jetty, an open source, standards-based, full-featured Web server, http://jetty. mortbay.org/jetty/index.html 54. 3rd Generation Partnership Project. Technical specification group services and system aspects, 3G security; access security for IP-based services (release 6), 3GPP, TS 33.203 V6.4.0 (2004-09). 55. Kent, S., and K. Seo. 2005. Security architecture for the Internet protocol, IETF RFC 4301. 56. Arkko, J., V. Torvinen, G. Camarillo, A. Niemi, and T. Haukka. 2003. Security mechanism agreement for the session initiation protocol (SIP), IETF RFC 3329. 57. S. Kent, S. 2005. IP encapsulating security payload (ESP), IETF RFC 4303. 58. Madson, C., and R. Glenn. 1998. The use of HMAC-MD5-96 within ESP and AH, IETF RFC 2403. 59. Madson, C., and R. Glenn. 1998. The use of HMAC-SHA-1-96 within ESP and AH, IETF RFC 2404. 60. Niemi, V. and K. Nyberg. 2003. UMTS security. West Sussex, England: John Wiley & Sons Ltd. 61. Pereira, R., and R. Adams. 1998. The ESP CBC-mode cipher algorithms, IETF RFC 2451. 62. Frankel, S., R. Glenn, and S. Kelly. 2003. The AES-CBC cipher algorithm and its use with IPSec, IETF RFC 3602. 63. 3rd Generation Partnership Project. Technical specification group services and system aspects, 3GPP, TS 33.210, network domain security (NDS); IP network layer security V6.5.0 (2004-06). 64. Sher, M., T. Magedanz, and W. T. Walter. 2006. Interdomains security management (IDSM) model for IP multimedia subsystem (IMS). IEEE 1st International Conference on Availability, Reliability & Security, Vienna, Austria, 20–22. IEEE/ ARES2006 Proceedings ISBN 978-0-7695-2567-9, pp. 502–509, April 2006. 65. Kaufman, C., ed. 2005. Internet key exchange (IKEv2) protocol, IETF, RFC 4306.


71

66. Maughan, D., M. Schertler, M. Schneider, and J. Turner. 1992. ISAKMP: Internet security associations and key management protocol, IETF, RFC 2408. 67. Sher, M., and T. Magedanz. 2006. Developing network domain security (NDS) model for IP multimedia subsystem (IMS). Journal of Networks 1(6):10–17. 68. 3rd Generation Partnership Project. Technical specification, network domain security (NDS); authentication framework (AF) release 7 TS 33.310 V7.1.0 (2006-09). 69. Karn, P., P. Metzger, and W. Simpson. 1995. The ESP triple DES (3DES) transform, IETF, RFC 1851. 70. Stallings, W. 2005. Cryptography and network security, 4th ed. Upper Saddle River, NJ: Prentice Hall. 71. Rivest, R. 1992. MD5: Message digest algorithm, IETF RFC 1321. 72. Piper, D. 1998. The Internet IP security domain of interpretation for ISAKMP, IETF RFC 2407. 73. Kiran, S., P. Lareau, and S. Lloyad. 2002. PKI basics—A technical perspective. http://www.oasis-pki.org/pdfs/PKI_Basics-A_technical_perspective.pdf 74. Santesson, S., and R. Housley. 2005. IETF RFC 4325, Internet X.509 public key infrastructure authority information access certificate revocation list (CRL) extension 2005. 75. Housley, R., W. Polk, W. Ford, and D. Solo. 2002. IETF RFC 3280, Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile. 76. 3rd Generation Partnership Project. 2005. Technical specification, generic authentication architecture (GAA); early implementation of HTTPS connection between a universal integrated circuit card (UICC) and network application function (NAF) (release 7), 3GPP TR 33.918 V7. 77. 3rd Generation Partnership Project. 2005. Technical specification, universal subscriber identity module (USIM) application toolkit (USAT) (release 7), 3GPP TS 31.111 V7. 78. 3rd Generation Partnership Project. 2004. Technical specification, 3G security; specification of the MILENAGE algorithm set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; document 2: algorithm specification, 3GPP TS 35.206 V 6.0.0. 79. Open source IP multimedia subsystem (IMS) core. Official release in 2006. http://www.fokus.fraunhofer.de/ngni/topics/ims_core.php 80. Open IP multimedia subsystem (IMS) playground. 2003–2007, http://www. fokus.fraunhofer.de/ims/index.php?lang=en 81. SIP express router (SER). 2001–2007, http://www.iptel.org/ser/ 82. Linux overall system resources utilization. http://www.linuxjournal.com/ 83. Firewall protection using IP tables. 1999–2007. The Netfilter Webmaster. http:// www.netfilter.org/ 84. IMS client developed by UCT/FOKUS. 2006. http://uctimsclient.berlios.de/ 85. Open source SIP test tool. http://sipp.sourceforge.net/ 86. 3rd Generation Partnership Project technical specification. Sh Interface based on the DIAMETER protocol (release 7), 3GPP TS 29.329 V 7.3.0. (2006-09). 87. 3Gb national host third generation and beyond testbed. 2003. http://www. fokus.fraunhofer.de/bereichsseiten/testbeds/national_host/testbed/testbed. php?lang=en 88. Knuttel, K., T. Magedanz, and L. Xie. 2006. SIP servlet execution environment (SIPSEE)—An IMS/NGN SIP AS for converged application. International Conference on Intelligence in Networks, ICIN, Bordeaux, France.

72


89. Wu, Y.-S., S. Bagchi, S. Garg, N. Singh, and T. Tsai. 2004. SCIDIVE: A stateful and cross protocol intrusion detection architecture for voice-over-IP environments. 90. SIP forum test framework (SFTF), a testing software for SIP. January 2007. http://www.sipfoundry.org/sip-forum-test-framework/sip-forum-test-framework-sftf.html 91. The 3GPP TSG SA WG3 security. 2003. Proposed confidentiality for IMS, Sophia-Antipolis, France. 92. http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_27_Sophia_Antipolis/Docs/PDF/S3-030149.pdf 93. The University of Southern California and VeriSign. Building a security framework for delivery of next-generation network services. 2005. http://www.verisign.com/static/035478.pdf 94. Radu State. 2007. New frontier in VoIP security and building management and security solutions of tomorrow’s Internet. Madynes Research Project, INRIA Nancy Universités Centre de Recherché Grand Est., France. http://madynes.loria.fr/ 95. The Georgia Technology Information Security Center (GTISC). 2007. Emerging cyber threats report for 2008 USA, October 2007. http://www.gtisc.gatech.edu/ pdf/GTISC%20Cyber%20Threats%20Report.pdf 96. Sipera Technical Security Report. 2007. Protecting IMS networks from attacks: Operators need more than encryption and authentication. http://www.sipera. com 97. Verizon and Cisco. 2006. Advances to IP multimedia subsystem (AIMS) architecture, white paper, June 2006. http://www.voip-magazine. com/content/view/4212/ 98. Juniper Networks. Solution brief—How juniper networks enable intelligent, secure, and open IMS-FMC networks, September 2006, http://www.juniper. net/solutions/literature/solutionbriefs/351218.pdf 99. Acme Packet. 2007. DoS/DDoS Protection for IMS Core Elements, June 2007. http://www.acmepacket.com/html/page.asp?PageID=%7B51CB22C4-7243-. 43D1-9847-6253984B1671%7D 100. Fiedler, J., T. Kupka, S. Ehlert, T. Magedanz, and D. Sisalem. 2007. VoIP defender: Highly scalable SIP-based security architecture, IPTComm, New York. http://iptcomm.org/ 101. Fraunhofer FOKUS Open Research Communication Institute, Berlin, http:// www.fokus.fraunhofer.de/home/index.php?lang=en 102. Nokia Siemens Networks. 2007. IMS technical description and information, A50016-D3605-X20-1-7618, Id: 0900d80580129f8e. 103. Open source network and IP-based intrusion detection system. SNORT 2005– 2006. http://www.snort.org

3 Peer-to-Peer Features in the IP Multimedia Subsystem Adetola Oredope and Antonio Liotta

contents Introduction............................................................................................................ 73 Peer-to-Peer Technology....................................................................................... 75 Structured p2p Overlay Network............................................................... 75 Unstructured p2p Overlay Network..........................................................77 Mapping p2p Applications to the IMS....................................................... 78 Case Studies: Deploying p2p as an IMS Service...............................................80 Case Study I: p2p Overlays over the IMS..................................................80 Case Study II: p2p in the IMS Core............................................................ 81 Outlook and Conclusion.......................................................................................83 References...............................................................................................................84

Introduction The IP multimedia subsystem (IMS) is a service-centered architectural framework that aims to provide existing and future Internet services to both fixed and mobile end users over a multi-access, all-IP platform [1]. These Internet services include voice over IP (VoIP), instant messaging, push-to-talk, multimedia conferencing, peer-to-peer (p2p) applications, and online gaming, to mention a few. The IMS provides ways for integrating existing Internet services with future ones. It supports rich, personalized services to the end user, regardless of access network or terminal capabilities. The major enabler of the IMS is the Internet Engineering Task Force (IETF) standardized session initiation protocol (SIP) [2], which is the core of the IMS architectural framework, due to its simplicity and extensibility. The main purpose of SIP in the IMS is the creation, management, and termination of multimedia sessions, both within and outside the IMS. SIP is currently the

73

74


major platform for developing new and dynamic multimedia services over the Internet [1]. Thanks to these features of SIP, most of existing Internet applications can be easily and seamlessly deployed in the IMS with little or no modifications. However, from the performance and scalability viewpoints, not all applications will be able to benefit fully from the IMS. In this chapter, we look in particular at p2p applications, considering architectural and deployment issues. In contrast to client–server applications, p2p systems do not rely on any specific server and are characterized by signaling and data flows that cannot always be deterministically anticipated [3,4]. For instance, file-sharing applications based on the p2p paradigm maintain a dynamic data structure, which allows any terminal (or peer) to act as both data source (server) and sink (client). This model represents a fundamental clash if compared with the IMS architecture that is intrinsically client–server and aims at keeping the application under control. p2p applications are realized as overlay networks that operate independently from the underlying infrastructure and are not controlled by the network operator, a problem also known as “operator de-intermediation.” Despite not being ideal from the operator’s point of view, p2p applications cannot be ignored due to their popularity. Recent surveys have shown that p2p applications, including file-sharing and streaming services, are responsible for a large amount of Internet traffic [3]. We have therefore reached the point where it is reasonable to assume that p2p applications will soon have to be supported by the IMS, also. On the positive side, p2p services may be used by the operator as an opportunity to create a wealth of new telecom services that are inspired by existing p2p applications but incorporate the benefits of a secure, trusted environment. To realize this potential, the IMS must offer fundamental p2p functionality and expose p2p enabling capabilities. We envision two main approaches to the development of p2p services through the IMS. p2p applications may be realized as an overlay network built over the existing IMS architecture. Alternatively, a more radical approach would be to embark on the task of extending the IMS core to provide intrinsic p2p support. These two scenarios are presented by means of case studies that have been assessed in a laboratory testbed (“Case Studies” section). For the benefit of the nonspecialist reader, the next section gives an overview of p2p in terms of architectural approaches and how these map to both the Internet and the IMS architecture. An outlook for future developments is given in the last section, which discusses such issues as security, charging, and mobility and looks at how these may affect the deployment of p2p service in the IMS.

Peer-to-Peer Features in the IP Multimedia Subsystem

75

Peer-to-Peer Technology Peer-to-peer technology can be defined as a platform that allows distributed nodes with similar interests or motives to communicate and exchange information with each other without the intervention of a centralized system [3,5]. This is achieved by building logical connections between participating nodes at the application level to form an overlay network. The information shared between these nodes could be either data or node location. p2p technologies have been used in such services as VoIP, video conferencing, network management, and file sharing. The Internet architecture was initially designed based on a p2p approach, but as it grew, the use of centralized servers and services allowed Internet service providers to expand their networks in order to cope with the increased number of users. Over the years, p2p approaches have developed considerably, providing essential characteristics such as scalability and redundancy. These characteristics make p2p the ideal platform for the deployment of high-availability services at a lower cost than their client– server counterparts. In this section we discuss various p2p approaches under two broad categories: structured and unstructured p2p overlay networks. We then discuss the challenges faced in deploying p2p services over the IMS by mapping the discussed p2p overlay network to the IMS architecture. Structured p2p Overlay Network In this approach the p2p overlay network is built using keys generated from various hash algorithms. The data and nodes are usually hashed to provide unique keys. Each datum (e.g., file) in the system is mapped to a key; the key is then mapped to a node. Different implementations use various graph theories in retrieving the keys from these nodes [3]. The main limitation of this approach is that, due to its deterministic approach, only exact matches of searches, or queries, can be retrieved. Complex queries will be difficult to achieve, although significant ongoing research efforts are devoted to the development of algorithms that will solve complex queries [6,7]. Many of the most popular applications adopt the structured approach. Examples are Chord [8], content addressable network (CAN) [9], Kademlia [10], Tapestry [11], and Pastry [12]. Chord [8] uses consistent hashing based on the SHA-1 hash function to provide its unique keys. These keys are based on an m-bit identifier long enough to prevent duplication. It also provides each peer with an equal number of keys to balance the load in the system and allows only a little movement of keys when nodes join and leave the overlay. All the identifiers are arranged in an identifier circle of modulo 2*m, which is known as the chord ring. This allows the lookup cost in the overlay of N peers to be O(log N), allowing Chord to be a highly scalable platform. Chord has been used in

76


various applications such as cooperative mirroring (cooperative file system) [13], which allows data to be spread across various content providers for the purpose of load balancing. It is also used in Chord-Domain Name System (DNS) [14], which is similar to the Internet-based DNS for looking up hostnames from IP address. Another approach is proposed by content addressable networks (CANs) [9], designed to be highly scalable, fault tolerant, and self-organizing. It is based on a virtual, multidimensional Cartesian coordinate space on a multitorus in which each peer is given a unique, individual zone in the overall space. The peer’s point P on the coordinate space is made up of the key k and value v (i.e., {k,v} pair), whereby k is mapped onto P using a uniform hash function. Each peer also stores the IP address and coordinate values of its neighbors and then uses a greedy algorithm to route messages to them. CAN has its own DNS service [9] that allows peers joining the overlay to locate the bootstrap nodes closest to them. In order to implement redundancy and fault tolerance into CAN, each peer is mapped to different unique coordinates; this is known as reality [3]. CAN has been used in the implementation of large-scale storage management systems such as Oceanstore [15], Farsite [16], and Publius [17], which require efficient insertion and retrieval of large data volumes. Similarly, Tapestry [11] is self-organizing and fault tolerant and uses the approach of decentralized randomness to achieve load distribution and localized routing. It also provides high availability, scalability, and adaptability in the face of failures or attacks. This is achieved by including additional mechanisms to the distributed search technique of Plaxton, know as Plaxton mesh [11], which is based on a static, single root node where messages are routed in the overlay via the other peers. In Tapestry, multiple distributed root nodes are used to improve availability. A technique known as surrogate routing is also used to locate the root servers in case of failures. Redundancy is pursued via data replication. Tapestry has been deployed in applications such as OceanStore [15], a global storage application that finds the closest document replica based on the closest distance metric. It is used in Bayeux [18] for application-level multicast and in SpamWatch [19] to implement a decentralized spam filtering system. Pastry [12] is very similar to Tapestry because it is also built on the Plaxton’s mesh, but it is based on a 128-bit peer identifier. Nodes are placed in a circular nodeID space. Each node maintains a leaf set in addition to the neighborhood and routing sets that are maintained in Tapestry. Pastry has been implemented in Scribe [20] (for application-level multicasting), SplitStream [21] (for multicast cooperative environments), PAST [22] (for distributed storage), and Pastiches [37] (for inexpensive and distributed backup). The architecture of Kademlia [10] is based on a 160-bit key space in which it uses its novel XOR metric to compute the distance between different points in the key space. The {key, value} pairs are stored on peers that have their node IDs close to the key. Its main implementation is in Overnet [23], which


77

is the base protocol for various commercial file sharing applications such as eMule [24]. Unstructured p2p Overlay Network In this approach the peers are arranged in a random graph using either a flat or hierarchal model. In some cases, queries flood the entire overlay network. Alternatively, queries may be directed toward certain nodes (according to some criteria) or may even be fired at a random set of peers. Some implementations use an expanding ring of time-to-live packets to prevent queries from circling in loops. Resource discovery in unstructured overlays is inefficient, especially if the content to be located is rare [3]. Also, each peer visited by the query message needs to evaluate the queries, incurring unnecessary overhead. Although the lookup mechanisms of unstructured p2p overlays tend to be inefficient, they have the advantage of being able to resolve complex queries. The most common unstructured p2p overlay approaches are BitTorrent, FastTrack, Freenet, and Gnutella. BitTorrent [25] was designed mainly to discourage free riders in the overlay network. It is based on a tit-for-tat approach allowing peers with high upload speed to gain access to high download rates. It uses a tracker, which is like a centralized node, that manages user downloads and keeps track of the peers having a particular file. The tracker also responds to lookup queries connecting peers in the overlay. The main advantage of BitTorrent is that it breaks large files into smaller pieces, allowing peers to download different portions from various peers in parallel, which results in faster downloads. FastTrack is used by some of the most popular p2p file sharing applications, such as Kazaa [26], Grokster [27], and iMesh [28]. It has also been extended to VoiP services such as Skype [29] and multimedia services such as Joost [30]. The major advantage of FastTrack is that it supports metadata searching and is based on a hierarchal approach, using nodes with high bandwidth, disk space, and processing power as root nodes. These nodes, known as super nodes, are arranged as a structured overlay. Ordinary nodes publish metadata relating to their own files with super nodes. In this way, when other, ordinary nodes search for particular files, they can simply query the super nodes. If there are no results, the query is then extended to the structured overlay. Freenet [31] has the advantages of providing anonymity and being able to adapt to various network conditions. Each peer in the overlay maintains a dynamic routing table for the overlay and also uses hop-to-live (HTL) packets to prevent infinite chains. Freenet is implemented mostly in file sharing applications. Gnutella [32] is based on a flat topology in which the peers in the overlay can assume the role of either a server or a client. Bootstrap nodes are provided to new peers joining the overlay; once a node is connected, it then floods the network with broadcast messages to learn about its neighbors. Once its neighbors are known, the node periodically sends PING messages to discover other participating nodes. Queries are also made by flooding the overlay network. Although this approach is not scalable and generates

78


a lot of traffic, it makes the overlay highly redundant because only available nodes participate in the resource location process. This approach makes the network highly resilient because the continuous node “joins” and “leaves” hardly affect the lookup procedures. The latest version of Gnutella uses the notion of super-peer and ultra-peer, which are synonymous with the super nodes in FastTrack, as discussed earlier. The use of Gnutella is quite common in file sharing applications such as LimeWire [33]. It is used as the basic platform for PeerCast [34], a p2p multimedia streaming application. Mapping p2p Applications to the IMS The IMS is a standardized next-generation network (NGN) architectural framework defined by the 3rd Generation Partnership Project (3GPP) to bridge the traditional gap between circuit-switched and packet-switched networks and consolidate both sides into a single, all-IP network for all services. In this section, we look at the effects of mapping a generic p2p solution over the IMS, considering how this affects p2p properties such as scalability, resiliency, and redundancy. The IMS employs IETF-defined SIP [2] as its call control protocol. SIP is the general Internet signaling protocol for creating, modifying, and terminating multimedia sessions between two or more participants. As an end-to-end protocol, SIP messages are routed via SIP proxy from the original SIP entities to the target SIP entities. As discussed earlier, the IMS provides a converged platform for the deployment of both existing and future Internet services. Although most of these Internet services should work “straight out of the box” over an IMS platform, some services, such as p2p applications, do not follow this norm. This is due to various limitations, such as the architecture of the IMS platform, the effects of mobility on p2p applications, and the variations in the capabilities of the nodes in the IMS platform. The analysis of the issues arising when p2p interworks with the IMS is therefore important in view of the prominence of p2p services. The IMS relies on a highly centralized architecture in which various SIP servers are placed at different levels. These servers in the IMS core are also responsible for all forms of session and data management in the IMS. Furthermore, IMS clients access services via the IMS core. This gives to the IMS core full control of the platform. The main advantage of this approach is that the platform is highly secure and can more easily provide personalized services because all services are deployed via a centralized system. Although this works well for some Internet services, it serves as a bottleneck for p2p applications. As shown in Figure 3.1, p2p applications make logical connections of the participating peers at the application level with little or no regard for the underlying network architecture. The main problem is that all forms of p2p signaling and data still have to go via the IMS core, passing through the IMS servers. This generates a lot of traffic toward the IMS core, using up important resources that could potentially be dedicated to other

79


IMS Core Network

Overlay Network

Figure 3.1 Mapping p2p overlays to the IMS platform.

services. Another limitation of this approach arises if the p2p application spans across multiple IMS platforms. The construction and maintenance of p2p overlays over external networks would be potentially expensive due to the continuous exchange of p2p signaling information. The IMS is also seen as a multi-access platform deploying services to both fixed and wireless networks. This advantage allows a wide range of user equipment (UE) to connect to the IMS platform network. However, p2p applications, especially structured p2p applications, assume that all participating peers have equal capabilities and contribute equally in the construction and maintenance of the p2p overlay. This assumption limits the performance of p2p applications in the IMS because IMS terminals are typically of varied capability. Mobile terminals will have limited processing power, so they may not be suitable as p2p relays. What is worse, battery constraints and limited access network capability clash directly with the p2p model, which envisions that all terminals are virtually equal. The use of these mobile terminals in an overlay with fixed nodes will degrade the performance of the overall p2p system. Another issue that is not very apparent in conventional p2p but becomes critical in a mobile p2p system is linked to the dynamics of mobile terminals. User mobility and handover will typically generate intermittent connectivity, which is seen from the p2p overlay as continuous node joins and disjoins, leading to severe overlay instability.

80


Because the IMS is a converged platform that integrates fixed and mobile networks, this inevitable behavior of mobile nodes increases the signaling traffic generated by the overlay because the overlay never seems to stabilize. This limitation in return limits the scalability and redundancy properties of the p2p overlay, risking defying its original purpose: to support massive-scale systems where any terminal can seamlessly share resources and communicate with any other one. In the next section, we introduce two case studies that attempt to overcome some of the problems described so far.

Case Studies: Deploying p2p as an IMS Service Case Study I: p2p Overlays over the IMS Running ordinary p2p applications directly on top of a converged (fixed and mobile) network is not ideal. The overlay network not only maps poorly and inefficiently onto the physical network, but the application development cycle also is lengthy and costly. Existing p2p applications are based on proprietary solutions. Hence, each application will have to rely on its own set of p2p support functions, will be monolithic, and will not easily interoperate with other similar ones. An example is given by Skype [29], a popular p2p telephony application that does not interoperate with other VoIP applications. The same applies to Kazaa [26], a popular file sharing application. A first step toward interoperable p2p is to treat this class of applications just as any other IMS application. Following the IMS principle of service-centric networks, applications are built by composing reusable service components that are, in turn, supported by the framework and hide network heterogeneity. Such a scenario has been described in Liotta and Lin [35] and is depicted in Figure 3.2. The IMS service layer needs to be extended in order to provide the essential building blocks of p2p applications, as shown in the figure. In this way, the development of an IMS-compliant p2p application will be straightforward because critical mechanisms for the management of the overlay, the publication of resources, the discovery of data, and so forth will be made available by the IMS service layer. Having a common set of p2p reusable components will also facilitate application interoperability. The p2p–IMS concept has been demonstrated through a number of mobile p2p applications, including video conferencing, mobile blogging, instant messaging, and streaming [38–40]. An interesting lesson from this work is that p2p-over-IMS applications have a new potential in comparison to conventional p2p. Because it is in control of peers, the IMS can act as trusted entity; it can realize new charging schemes (tailored to p2p, such as incentive-based economic models) and protect the content against illegal distribution [41]. These important aspects are still under study, and we may see significant developments in the near future.

81

Peer-to-Peer Features in the IP Multimedia Subsystem IMS Appl.

P2P-IMS Applications Property Selling

Video Conference

Mobile Blog

Instant Messaging

P2P semantic publish/search

Semantic DB

P2P Group policy

P2P Overlay Management

P2P Group Management

P2P DRM

SIP

…

…

P2P P2P resource Charging sharing

…

…

Standard IMS service layer

P2P AAA Diameter Diameter

SIP

S-CSCF

SIP

SIP

SIP P-CSCF

HSS

SIP Diameter

Diameter

Network

I-CSCF

Operator 1

Diameter

Diameter

Network

SIP

Operator 2

SIP HSS

I-CSCF

SIP

S-CSCF SIP

SIP P-CSCF

ISP provider UMTS

P2P group A

SIP

WiFi/802.11x

P2P group B

P2P Overlay

GPRS

P2P group C

SIP

P2P group D

Figure 3.2 p2p IMS. (Expanded from Liotta, A. and L. Lin. IEEE Communications Magazine 45(7):76–83.)

Case Study II: p2p in the IMS Core In this case study, we describe an approach to support p2p–IMS applications at the IMS core level, through modifications of SIP. Appropriate SIP extensions known as peer-to-peer SIP (p2pSIP) are currently in the draft status in the IETF. p2pSIP is based on an approach that replaces the traditional SIP servers and message routing functions with a structured p2p overlay network or with distributed mechanisms that have external properties [36]. In other words, the p2pSIP approach proposes to provide a serverless platform for SIP services in which SIP messages are directed to a p2p overlay made up of various SIP clients instead of centralized SIP servers. Compared

82


IMS Core P2PSIP Overlay

P2PSIP Overlay

P2PSIP PCSCF

P2PSIP Overlay

P2PSIP Overlay

Figure 3.3 p2pSIP-enabled IMS core.

to conventional SIP approaches, p2pSIP has various advantages, such as its low cost in setup and maintenance, its provisions for localized services, and, most importantly, its ability to inherit the scalability and redundancy advantages of p2p overlay networks. The proposed p2pSIP approach is adopted for the deployment of p2p services in the IMS in this case study. This is achieved by extending the SIP implementation in the IMS core to support p2pSIP in order to allow p2p services to be easily integrated with other services in the IMS core (Figure 3.3). This solution also enables the IMS core to function in both conventional SIP and p2pSIP modes, providing backward compatibility with existing IMS services. This is based on a p2pSIP-enabled proxy call session control function (PCSCF) [1] that supports both SIP messages and IP packet routing. While supporting SIP message routing, the p2pSIP PCSCF functions as a SIP proxy and can support IMS clients that do not wish to be part of the p2p overlay. When functioning as an IP router, the p2pSIP PCSCF limits the amount of traffic that goes into the IMS core and routes most packets locally. The IP routing functionality of the p2pSIP also allows the clients in the overlay to be interconnected at the network layer and not just at the application layer. The p2pSIP-enabled PCSCF is also used as bootstrap node of the p2pSIP overlay network because of its responsibility of connecting nodes to the core IMS network. The p2pSIP extension proposed earlier can easily be achieved in the PCSCF because 3GPP standardizes functions rather than interfaces; this allows various functions to be deployed easily in a single node. The p2pSIPenabled PCSCF is also responsible for initiating the overlay and providing the overlay information to members wishing to join the overlay network. Once peers join the overlay network, they are allowed to host various p2p IMS services, allowing more nodes to connect. This minimizes the number of SIP messages flowing from the overlay network toward the IMS networks.


83

It also allows for easy service creation and integration. All forms of lookup (node, user, or service) or address resolution are performed using the preferred p2p approach in the overlay. We do not recommend any particular p2p approach because various p2p overlay implementations offer different advantages, and the search latency tends to vary based on different conditions. For operations such as overlay searches for users, nodes, or services, the necessary keys need to be computed locally (and passed to super nodes in the overlay, if available) using hash mechanisms. The computed keys are then forwarded to the p2p overlay to perform the searches; results are returned to the required nodes. Once the location information of a peer user is known, a SIP session can be set up using SIP in p2p mode. The deployment of this p2pSIP approach in the IMS provides various advantages such as security, authentication, and trust. Moreover, this particular approach still provides the network operator with a degree of control over the network, allowing for converged billing, service provisioning, and network management, while still gaining the benefits of a fully distributed system. One of the main advantages of this approach is that new services can easily be developed by the network operator or end users, allowing the IMS to really be a domain of services.

Outlook and Conclusion This chapter places ordinary p2p applications into a new perspective, highlighting the potential arising when p2p is realized just as any other IMS service. Before this vision can become a reality, though, a number of issues need to be tackled. p2p overlays do not map well onto physical networks because p2p systems optimize IT resources but neglect the network. There is a fundamental clash between current p2p and network architectures. p2p is designed to bypass the network operator, limiting its ability to control and influence the p2p application overlay. On the other hand, fundamental operations such as charging, security, quality control, and location management are hard to realize without the operator’s collaboration. p2p–IMS brings p2p into the operator’s realm, creating the preconditions for a richer p2p service. If placed in perspective, p2p–IMS has the potential to address problems that have remained unsolved so far. Current p2p systems are increasingly faced with the problem that they do not offer a sound digital rights management solution. Privacy and data retention legislation is also bound to curb the further development of current p2p systems. There is also the major issue of how to cater for national security requirements given that it is not currently possible to perform legal intercepts on p2p communications and data flows. The two case studies described in this chapter indicate a new avenue to address the aforementioned issues of p2p, while at the same time creating a

84


new perspective for network operators and service providers. p2p is now a high-demand service that requires an immediate, fundamental redesign. The IMS may be the next p2p provisioning platform, provided that the IMS itself evolves toward a more decentralized architecture. All in all, facilitating p2p services in the IMS will enable the deployment of new and exciting services, achieving what the IMS was initially designed for: a platform of services.

References

1. Camarillo, G., and M. A. Garcâia-Martâin. 2006. The 3G IP multimedia subsystem (IMS): Merging the Internet and the cellular worlds, 2nd ed. Chichester: John Wiley & Sons, xxvi; 427. 2. Rosenberg, J. et al. SIP: Session initiation protocol (IETF RFC 3261). 3. Eng Keong, L. et al. 2005. A survey and comparison of peer-to-peer overlay network schemes. IEEE Communications Surveys & Tutorials 7(2):72–93. 4. Sen, S., and W. Jia. 2004. Analyzing peer-to-peer traffic across large networks. IEEE/ACM Transactions on Networking 12(2):219–232. 5. Xiang, Z. et al. 2004. Peer-to-peer based multimedia distribution service. IEEE Transactions on Multimedia 6(2):343–355. 6. Triantafillou, P., and T. Pitoura. 2004. Towards a unifying framework for complex query processing over structured peer-to-peer data networks. In Databases, information systems, and peer-to-peer computing, Lecture Notes in Computer Systems. Springer Berlin/Heidelberg. 169–183. 7. Bin, L., L. Wang-Chien, and L. Dik Lun. 2005. Supporting complex multidimensional queries in p2p systems. In Proceedings of the 25th IEEE International Conference on Distributed Computing Systems (ICDCS’05)—Volume 00, IEEE Computer Society. 8. Stoica, I. et al. 2003. Chord: A scalable peer-to-peer lookup protocol for Internet applications. IEEE/ACM Transactions on Networking 11(1):17–32. 9. Sylvia, R. et al. 2001. A scalable content-addressable network. In Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications. San Diego, California. 10. Maymounkov, P., and D. Mazières. 2002. Kademlia: A peer-to-peer information system based on the XOR metric. In Peer-to-Peer Systems: First International Workshop, IPTPS 2002 Cambridge, MA, March 7–8, 2002. Revised papers, 53–65. 11. Zhao, B. Y. et al. 2004. Tapestry: A resilient global-scale overlay for service deployment. IEEE Journal on Selected Areas in Communications 22(1):41–53. 12. Antony, I. T. R., and D. Peter. 2001. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms. Heidelberg: Springer–Verlag. 13. Frank, D. et al. 2001. Wide-area cooperative storage with CFS. In Proceedings of the Eighteenth ACM Symposium on Operating Systems Principles. Alberta, Canada: ACM.

All Web site links were last checked on January 14, 2008.


85

14. Cox, R., A. Muthitacharoen, and R. T. Morris. 2002. Serving DNS using a peerto-peer lookup service. In Peer-to-peer systems: First international workshop, IPTPS. Cambridge, MA, March 7–8, 2002. Revised papers, 155–165. 15. John, K. et al. 2000. OceanStore: An architecture for global-scale persistent storage. ACM SIGPLAN Notes 35(11):190–201. 16. William, J. B. et al. 2000. Feasibility of a serverless distributed file system deployed on an existing set of desktop PCs. SIGMETRICS perform. Evaluation Reviews 28(1):34–43. 17. Marc, W., D. R. Aviel, and C. Lorrie Faith. 2000. Publius: A robust, tamper-evident, censorship-resistant web publishing system. In Proceedings of the 9th Conference on USENIX Security Symposium—Volume 9. Denver, CO: USENIX Association. 18. Shelley, Q. Z. et al. 2001. Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination. In Proceedings of the 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video. ACM: Port Jefferson, NY. 19. Zhou, F. et al. 2003. Approximate object location and spam filtering on peer-topeer systems. In Middleware 2003, Lecture Notes in Computer Science. Springer Berlin/Heidelberg. 997–998. 20. Castro, M. et al. 2002. Scribe: A large-scale and decentralized application-level multicast infrastructure. IEEE Journal on Selected Areas in Communications 20(8): 1489–1499. 21. Miguel, C. et al. 2003. SplitStream: High-bandwidth multicast in cooperative environments. In Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles. Bolton Landing, NY: ACM. 22. Antony, R., and D. Peter. 2001. Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility. SIGOPS Operating System Review 35(5):188–201. 23. Kutzner, K., and T. Fuhrmann. 2005. Measuring large overlay networks—The overnet example. In Kommunikation in Verteilten Systemen (KiVS), 193–204. 24. Emule, http://www.emule.com/ 25. Bittorrent, http://www.bittorrent.org/ 26. Kazaa, http://www.kazaa.com/ 27. Grokster, http://www.grokster.com/ 28. iMesh, http://www.imesh.com/ 29. Skype, http://www.skype.com 30. Joost, http://www.joost.com/ 31. Ian, C. et al. 2001. Freenet: A distributed anonymous information storage and retrieval system. In International Workshop on Designing Privacy Enhancing Technologies: Design Issues in Anonymity and Unobservability. New York: Springer–Verlag. 32. Ripeanu, M. 2001. Peer-to-peer architecture case study: Gnutella network. In Proceedings of the First International Conference on Peer-to-Peer Computing (p2p’01), IEEE Computer Society. 33. Limewire. http://www.limewire.com/ 34. PeerCast. http://www.peercast.org/ 35. Liotta, A., and L. Lin. 2007. The operator’s response to p2p service demand. IEEE Communications Magazine, special issue on the IP multimedia subsystem 45(7):76–83. 36. Peer-to-Peer SIP (p2pSIP). http://tools.ietf.org/wg/p2psip/

86


37. Cox, L. P. et al. 2002. Pastiche: Making backup cheap and easy. In Proceedings of Fifth USENIX Symposium on Operating Systems Design and Implementation, Boston, MA. 38. Liotta, A., and L. Lin. 2007. Managing p2p services via the IMS. In Proceedings of the 10th IFIP/IEEE International Symposium on Integrated Network Management. Munich, Germany, May 21–25. 39. Lin, L., and A. Liotta. 2007. Presence in the IP multimedia subsystem. Journal of Mobile Information Systems, special issue on improving quality of service in mobile information systems 3(3):187–202. 40. Liotta, A., M. Ballette, L. Lin, M. Gasparoni, P. Brick, and N. Papadoglou. 2005. Service-driven group management for mobile p2p services. Proceedings of the IFIP International Conference on Intelligence in Communication Systems (IntellComm’05), Montreal, Canada, Kluwer Academic Publishers, October 17–19. 41. Liotta, A., R. Motta, and L. Lin. 2006. A file protection method for peer-to-peer systems. Journal of Research in Computing Science 23:151–160.

4 On the Support of Media Functions within the IMS Jean-Charles Grégoire and Admela Jukan

contents Introduction............................................................................................................ 87 Background and Evolution................................................................................... 88 Media Functions within IMS...............................................................................90 IMS Core.........................................................................................................90 MRF.................................................................................................................90 The Media Gateway (MGW)....................................................................... 93 Streaming....................................................................................................... 94 H.248............................................................................................................... 94 QoS Issues............................................................................................................... 96 QoS Preconditions and Media Policy Models.......................................... 97 An Example............................................................................................................. 98 QoS and Media Functions within the Call Setup.................................... 98 Conferencing............................................................................................... 101 Functions into Boxes............................................................................................ 101 The Media Function................................................................................... 102 A Few Examples.......................................................................................... 102 Understanding the Market........................................................................ 105 Other Issues.......................................................................................................... 106 Network versus Terminal Centric............................................................ 106 Control Protocols for the Media Functions............................................. 107 Provisioning and Configuration............................................................... 108 Summary and Final Remarks............................................................................ 109 References............................................................................................................. 109

Introduction Although multimedia is fundamental to the IMS—the IP multimedia subsystem—and its operations, much of the focus of the IMS’s original work has 87

88


been on signaling issues rather than media processing. The media resource function (MRF), part of the IMS core architecture, is a collection of functions of varied nature, all required to support various telephony services in signaling and media planes. Over time, however, this function has generated more interest as manufacturers have positioned products to implement it and services have emerged that require support of more sophisticated media functions beyond what has been specified so far. Nevertheless, studies on the nature of the various media functions required for operations of IMS services or on the way they can be integrated in IMS operations have been few and far between. In this chapter, we review and analyze different perspectives on media functions, including a review of the relevant 3rd Generation Partnership Project (3GPP) standards. Further, we introduce an original view on the organization of the IMS media function to attempt to facilitate its integration into services. This chapter is structured as follows. The following section introduces the background of media processing in the legacy telephony universe. The third section presents the IMS perspective on the media function. The fourth section enriches the previous concepts with quality of service considerations. The fifth section illustrates the concepts introduced so far through an example. The sixth section analyzes the decomposition of the media function and presents a sample market view. The seventh section presents further related issues, such as provisioning and control protocols. The last section gives a summary and a few final remarks.

Background and Evolution Media functions in the IP universe are best traced to telephony. The original work on the session initiation protocol (SIP) done at the Internet Engineering Task Force (IETF) aimed at developing a signaling protocol more in line with the end-to-end model of the Internet than the infrastructure-based model of the International Telecommunication Union (ITU) H.320 families of standards. Over time, naturally, the need to interoperate with traditional telephony, as well as the necessity to support usual telephony services, led to the creation of new protocols associated with network nodes dedicated to specific media processing. We cover in this section the different forms of processing introduced in telephony; in the following section, we present how they are treated in IMS. Today’s telephony as we understand it is the evolution from the offer of a plain service (“plain old telephony system” [POTS]) to a set of value-added services supported by a combination of sophisticated signaling network (SS7) and other functions. We begin with a review of the predominant latter ones, focusing on the media dimension; we start with a refresher on key notions:

On the Support of Media Functions within the IMS

89

Service: Our notion of service is borrowed directly from telephony and denotes a commercial offering to a customer. Depending on the context (e.g., telephony, IMS), services may be built from features— a form of building blocks—or rest on enablers—support functions. It has actually been argued in some (SIP) circles that there is no consensus on what a service is; although this may be true from a protocol perspective, the customer perspective is clearer on that point. Signaling: Recall that signaling can be defined as a protocol exchange for the establishment and control of a connection and the management of the required resources. The signaling versus media (data) duality permeates this work because some IMS elements are on the signaling flows, whereas others are on the media flow. We shall see that, in some cases, the nature of the interaction between elements on either side will be blurred. Gateway: This function has the responsibility to provide support for transcoding—that is, to convert media representation (i.e., codecs) between heterogeneous networks (e.g., between wireless and wireline networks). A gateway will typically have media and signaling dimensions. Conferencing: This function is traditionally built around a bridge, a device that can accept calls from or possibly initiate a call to a number of participants. Conferences are created and monitored; users join and leave them. Control functions to decide who will be the main speaker (floor control) are also involved. Interactive voice response: IVR services allow a user to interact with a service without human intervention, and—for better or for worse— they have been quite successful. They differ from previous services in that they require an interaction between user and server, with an interpretation of the response. IVR can also be viewed as an enabler—that is, as a functionality reusable across different applications, such as voice mail or calling-card calls, although call centers probably are the predominant application. Note that such services present the challenge of mixing media and control and possibly signaling. Information decoded from the media stream is used to control operation, but also as media—for example, to record a message. The signaling dimension occurs when we use the media stream to set up a call. Finally, let us add that different technologies can be associated with this service, such as tone DTMF (Dual-tone multifrequency decoding), text-to-speech synthesis, speech recognition, and audio capture. Streaming: This function can be seen as a dimension of IVR or as a stand-alone service. Streaming is used to play media content, such as a voice-recorded message or text-to-speech (TTS)-generated messages.

90


Media Functions within IMS IMS is a substrate for media operations in an IP network. Because it was defined as part of the 3GPP for cellular telephony networks, it carries over from telephony the traditional notion of services and the use of media in that context. We briefly present in this section elements of the IMS architecture relevant for our exposé, while assuming that the reader is already aware of the use of the session initiation protocol [1] as the foundation for signaling in IMS as well as of the key nodes in the call session control function. IMS Core IMS requires a number of components, as defined in 3GPP TS23.228 [7], to allow a user to initiate, modify, and terminate media sessions. Figure 4.1 presents an overall view of the architecture and its key elements. It also highlights the reference points between function boxes, which are essentially support protocols; for example, the IMS service control (ISC) link between the call session control function (CSCF) and the application server (AS) is SIP based. The IMS core has the functionality required to support user-to-user media calls and all forms of telephony services. The CSCF handles the signaling, and the home subscriber server (HSS) will be the repository of authentication and user profile information; we concentrate here on media processing elements, specifically the MRF and the media gateway (MGW). Before investigating these functions in more detail, it is probably worthwhile to recall that, in the IMS architecture, some nodes will directly be in the signaling flow of the call or will be in a derived flow generated from a node on the call, such as an AS. In the case of media-related nodes, we shall see occurrences of both cases. MRF In the current IMS architecture, the MRF is broken up into two parts: a processor (MRFP) and a controller (MRFC). Together, they supply the resources that provide support for bearer-related services such as multiparty sessions, announcements to a user, or bearer transcoding. MRFC: As we see from Figure 4.2, the MRFC is on the signaling path; that is, session control messages are passed between the AS and the MRFC via the (serving) CSCF. Based on the information contained in the messages, it will direct the MRFP to act accordingly. For some

At the time of this writing, version 7 is frozen and is our reference; work on version 8 is ongoing.

Mb

Mb

Mb

Mp

IP Multimedia Media Gateway (IM-MGW)

CS

Media Resource Function Processor (MRFP)

Mb

Mn

Mj

Media Resource Function Controller (MRFC)

Mr

Mg

Breakout Gateway Control Function (BGCF)

Mk


Media Gateway Controller Function (MGCF)

CS

Mi

Mk

Proxy CSCF (P-CSCF)

Mw

Serving CSCF (S-CSCF)

Mw

Interrogating CSCF (I-CSCF)

Mm

Gm

Mm

Internet Multimedia Subsystem (IMS)

User End-device (UE)

Subscriber Location Function (SLF)

Home Subscriber Servers (HSS)

Application Servers (AS)

Legacy Mobile Signaling Networks

Figure 4.1 IMS reference architecture. (From 3rd Generation Partnership Project, IP multimedia subsystem (IMS); stage 2, 3GPP TS 23.228 V7.8.0, 2007-06.)

Mb

Mb

Circuit Switched Networks

IP Multimedia Networks

On the Support of Media Functions within the IMS 91

92


AS ISC S-CSCF

Mr

MRFC Mp

Mb

MRFP

Mb

Figure 4.2 Detail of the reference model for the MRF.

services, however, an AS is not necessary and the call will be routed to the MRFP directly from the serving CSCF (S-CSCF). MRFP: The tasks of the MRFP include the following: • controlling the bearer on the Mb reference point; • providing resources to be controlled by the MRFC; • mixing incoming media streams (e.g., for multiple parties); • originating media streams (for multimedia announcements); • processing media streams (e.g., audio transcoding, media analysis); • floor control (i.e., manage access rights to shared resources in a conferencing environment); and • generating calling data records (CDRs) for charging The Mp reference point: Mp specifies the interface between the controller and processor in the MRF. It is based on the H.248 [17] standard, which was originally created as media gateway control (MEGACO) [2]—or RFC 3015—within IETF to support IP telephony. Thanks to its package mechanism (see “H.248” section), this protocol is extendable and can be profiled for specific uses. The Mr reference point: Mr allows exchanges between the CSCF and the controller. It is based on SIP, with the 3GPP extensions. The MRF split: Breaking up the MRF function between controller and processor can have benefits for performance and scalability, but it is not a necessity. Manufacturers choose whether or not they want to separate the functions, and this statement actually applies to the IMS architecture as a whole. We further explore this important issue later.


93

The Media Gateway (MGW) The media gateway function is required to allow interoperability with landline and legacy networks. It is usually split between an IMS-side function (IMS–MGW) and a matching, typically circuit-switched (CS–MGW) counterpart. It will thus terminate a bearer channel from a switched circuit network and media streams from a packet (IP) network. As part of these operations, it will be necessary to support media conversion (transcoding), bearer control, and possibly also other forms of processing, such as echo cancellation. Although the MGW can be strongly related to the MRF, it serves a very specific purpose (interoperability) and is part of the core functions of IMS. It need not be controlled from an AS but, rather, will be in the signaling flow from the CSCF. As seen in Figure 4.1, the MGW also has a control function, the MGCF, which is in direct communication with the S-CSCF, but also with another node, the breakout gateway control function (BGCF). These nodes together bridge the IMS-to-PSTN signaling. MGCF: The MGCF is considered as a SIP endpoint, which means that it ends the SIP side of a call. It translates signaling messages from the PSTN side to SIP signaling on the IMS side and vice versa. BGCF: The S-CSCF requests the services of the BGCF when a SIP call cannot be routed in the packet domain and needs to be converted to a circuit-switched call. A BGCF will forward the call to another BGCF in the domain where the breakout—from IP to CS—can occur, possibly its own domain. The breakout BGCF will choose an MGCF in its domain to terminate the call. The Mn reference point: Within the IMS, the Mn reference point describes the interfaces between the MGCF and MGW. These are control interfaces that are fully compliant with the H.248 standard functions for IMS and PSTN/PLMN (Public Land Mobile Network) interworking. They are also required to support flexible connection handling to allow different call models and different media processing purposes, which are not restricted to H.323-related usage. The Mn reference point is required to include an open architecture where extension/package definitions may be carried out per interface. At Mn points, the dynamic sharing of MGW physical node resources should be allowed. In other words, a physical MGW node can be partitioned into logically separate virtual MGWs/domains, each consisting of a set of statically allocated terminations. Finally, the Mn reference point is required to allow dynamic sharing of transmission resources between the different domains because the MGW controls bearers and manages resources. The Mg reference point: The Mg reference point allows the MGCF to forward incoming session signaling (from the PSTN) to the CSCF for

94


the purpose of (signaling) interworking with landline telephony networks. The Mg reference point relies on the SIP [1] protocol, together with other relevant RFCs and additional enhancements introduced to support 3GPP’s needs. The Mi reference point: This reference point allows the Serving-CSCF to forward session signaling to the BGCF for the purpose of interworking to the PSTN networks. The Mi reference point is based on SIP, with the same proviso as for Mg. The Mj reference point: This reference point allows the BGCF to forward session signaling to the MGCF for the purpose of interworking to the PSTN networks. The Mj reference point is based on SIP, with the same proviso as for Mg. Note that Mi and Mj handle outgoing calls, whereas Mg deals with incoming calls. Streaming A streaming service (SS) has the ability to play over a network of continuous flows of synchronized media streams, typically audio and video but also text or still images. These flows are sent to one or multiple clients, although in the case of IMS, such a multicast is not considered. When a single client is involved, it is possible to add control functions to allow the user to pause, resume, fast forward, or rewind. Streaming services are a growing segment of the Internet, albeit still in a rather primitive form (e.g., with online video or podcasts). They have many applications, either on demand, such as news or music, or live, such as sports broadcast or television in general. In the IMS architecture, we can see from Figure 4.3 that these services are not integrated in the same signaling framework. Rather, we follow the IETF model of sending streaming requests through the Web protocol (HTTP) and use a control protocol. Because of these choices, in IMS’s packet-switched streaming service (PSS), the terminal’s complexity can be more limited than for conversational services because input devices and encoding are not required. Because we mention broadcasts, it is worth pointing out that SS architectures will include some form of technology to deploy and manage digital rights, although, at the time this is being written, this field is still in a state of flux. H.248 As mentioned earlier, the MEGACO (RFC 3015) protocol has also been published by ITU-T as H.248, and these two names are synonyms for all practical purposes. Based on a master–slave model, it has been designed to allow control of telephony gateway and terminals (IP phones). The master is a controller,

95


Streaming Client

Content Servers

Content Cache GERAN 3GPP Core Network SGSN

Streaming Client

UTRAN

IP Network

GGSN

User and Terminal Profiles

Portals

Figure 4.3 Streaming reference architecture in IMS. (From 3rd Generation Partnership Project, Transparent end-to-end packet-switched streaming service; 3GPP TS 22.233 V7.0.0, 2006-06, stage 1, release 7.) GERAN: GSM EDGE radio access network; UTRAN: UMTS terrestrial radio access network; SGSN, GGSN: service/gateway GPRS support node.

which will act as the central point of interaction for call signaling and maintain relevant state information from one or several slaves/media gateways. The gateway itself depends on commands—called actions—from the controller for any operations. It sends events to the controller as notifications. There is a fundamental difference between SIP and H.323 and media gateway control protocols. SIP and H.323 are signaling protocols that set up and manage calls, whereas a media gateway control protocol focuses on the establishment of the media flows themselves. (1) A connection model: The MEGACO architecture is based on three concepts: termination (point), context, and stream. Together, they orchestrate the establishment and manipulation of media flows. (a) Termination: Media flows are established between endpoints. Termination will identify such an endpoint, implement signals, and generate related events. A termination can appear in one context at most. It can represent a physical entity, such as a (carrier) technology (e.g., Frame Relay, ATM or TDM) or ephemeral UDP or TCP-based flows. (b) Context: A communication established between terminations is a context. Each context supports multiple streams and defines a topology over which communications will occur, as well as mixing/transcoding, if so required. (c) Stream: A context can have multiple streams, each typically for a medium (e.g., audio or video) organized according to the con-

96


Table 4.1 H.248 Commands Audit value

Determine the characteristics of an endpoint

Audit capabilities

Determine the capabilities of an endpoint

Add

Add a connection

Modify

Change a connection characteristic

Subtract

Tear down a connection

Move

Move an endpoint from one connection to another connection (call waiting)

text’s topology. The controller specifies which streams a given termination supports. (2) Commands, packages, and profiles: Table 4.1 lists the commands a controller can send to a gateway over MEGACO. In the other direction, a gateway will send notifications of events. Because it was not possible—or wise—to devise a protocol for any kind of media gateway, the decision was made to have a general mechanism and specialized sets of parameters, called packages, per application. A package is thus an extension mechanism defining properties, events, signals, and statistics required for some specific operation (e.g., DTMF signaling). Any such package is standardized, with distinct name and ID (Generic, g; Base Root, root, etc.). A global repository is managed by IANA, and a profile will list a number of packages that a standard requires for its use of MEGACO. (3) Some criticism: Although MEGACO has served its purpose well, it is not without limitations. The master–slave model, for one, forces many communication steps between gateway and controller. The signal-/event-based model is also limited in expressiveness. In essence, MEGACO was designed for “dumb” media session endpoints, which cannot be integrated into the signaling path. As we shall see later, several attempts have been made to improve on this model for advanced media control.

QoS Issues The IMS standard defines the type of SIP signaling messages exchanged between the user terminals and the core IMS infrastructure, their routing, and transfer between operators, and so, too, does the media function define the necessary quality of service (QoS) provisions and guarantees to


97

be exchanged within. In other words, the terminals negotiating the media parameters also determine the parameters of network resource reservation prior to the session ring event and media flow. Within the SIP call setup, the process of setting QoS preconditions, which require that the participant reserve network resources before starting the media flow, must be taken into consideration. QoS Preconditions and Media Policy Models A precondition is a set of parameters about the session that are necessary for network reservations when establishing a session between two parties. They are called “preconditions” because they are exchanged prior to the actual session setup (via SIP). Only if “preconditions are met” will the session setup proceed, and all the preconditions for a media stream must be met in order to complete session establishment. They are conveniently expressed within session description protocol (SDP) bodies, with media definitions themselves, and their status is modified during negotiation stages of the call setup phase. Many negotiated preconditions are specific to the operator and proprietary. As of today, there are no fully developed standards frameworks that specify the preconditions specific to any media (i.e., their handling and negotiation). Although most of the standards address preconditions in general terms (e.g., media=audio, QoS status current local), little is known about the conditions under which media can be rejected and whether and how the preconditions can be renegotiated. For example, if preconditions for video conferencing over wireless require 30 kb/s to be guaranteed over the radio bearer, the media may be rejected if less bandwidth is available despite the fact that the audio on that media may be acceptable, although video would not be, due to the insufficient wireless link capacity. It is also not possible to express tradeoffs, such as an implementation space, which could be exploited by relay boxes to attempt to best satisfy the users’ constraints. Preconditions are only part of the story. Although they allow satisfaction of the media flows’ requirements, the realization can be constrained by some policies, which capture what a user may or may not do based on a profile (e.g., service grade accessible) as well as the fact that resources are limited; hence, the network side may not be able to meet the user’s demands or the request is exceeding the user’s budget. The implementation of the precondition mechanisms may thus require an interface with a policy manager, along the lines of IETF’s common open policy service (COPS) architecture [4], which has been adopted within the 3GPP framework in the form of a policy and charging rules function (PCRF), which manages the rules, and a policy and charging enforcement function (PCEF), which enforces them. Once again, however,

Note that this requires access to the SDP body and has implications on security. Note, however, that these functions communicate via DIAMETER, rather than using the COPS protocol itself.

98


we are talking about a flexible, general-purpose mechanism and, although some policy tables have been proposed, including security and QoS, there is no general consensus on the proper use of such a mechanism. Also, it is not restricted to COPS as its implementation vehicle. A paper by Camarillo et al. [16] addresses a policy-based framework where characteristics of a session are inspected by the policy-based function as defined by the 3GPP R7. For example, if the session contains video requests in offer/answer exchanges and only voice is supported, it can be rejected. Usually, the IMS’s PCRF would inform the application function that the session under progress is not acceptable. The paper points to an important issue of the session setup termination due to the characteristics of the session and reveals that, in today’s systems, the network cannot inform users about the specific reasons for session terminations (for instance, the network cannot instruct users to “try another codec” or “buy missing credits”). Rewriting the SDP message, currently performed for both fixed and cellular users of IMS, would not help because every network operator domain would have to agree on the set of SDP extensions, which clearly would not scale. In that case, the idea of using policies may bring the IMS service offer to a more innovative stage. With policies, the network can inform the terminal about the whole list of codecs supported. Naturally, contacting a policy server induces an additional delay in the already delay-critical performance of the SIP session setup. According to Camarillo et al. [16], about 10 new messages must be added to the message flow for that purpose. Keeping SIP signaling delay low is therefore a challenge in IMS, due not only to the text-based nature of SIP but also to the complexity in system architecture required in IMS implementations. Any excess messages exacerbate the problem.

An Example To illustrate the previous concepts, we present here the salient points of QoS negotiation in a call setup and discuss further how it relates to a conference application. QoS and Media Functions within the Call Setup In Figure 4.4, we illustrate a case where three IMS subscribers would like to engage in a 3-way conference. The example network architecture is loosely based on 3GPP2 because it shows the inclusion of the packet data switching node (PDSN); by replacing the PDSN with the gateway GPRS support node (GGSN), a similar architecture can be considered within the 3GPP context. We assume that all users (user end-nodes, UE) have already had the conference uniform resource indicator (URI) communicated to them through.

Mb

Mb

Mb

Mp

IP Multimedia Media Gateway

CS

Media Resource Function Processor (MRFP)

Mb

Mj

Media Resource Function Controller (MRFC)

Mr

Mi

Mk

Mg


Breakout Gateway Control Function (BGCF) Mk

Media Gateway Controller Function Mn (BGCF)

CS

Figure 4.4 An example of conference call setup with QoS reservation and media functions.

Mb

Mb

Circuit Switched Networks

IP Multimedia Networks

Proxy CSCF (P-CSCF)

Mw

Serving CSCF (S-CSCF)

Mw Mw

Interrogating CSCF (I-CSCF)

Mm

Ut

Subscriber Location Function (SLF)

Home Subscriber Servers (HSS)

User End-device (UE)

Cx

ISC

Sh

Application Servers (AS)

C, D, Gc, Gr

Internet Multimedia Subsystem (IMS)

Gm

Dx

Cx

Mm

Legacy Mobile Signaling Networks

On the Support of Media Functions within the IMS 99

100


e-mail, http, etc. UE 1 uses the SIP INVITE message directed to the conference URI. The user’s S-CSCF forwards the INVITE message to the MRFC for processing. In step 2, the MRFC allocates the conference URI by checking local configurations and policies as well as other IMS elements (i.e., AS, etc.) and, if successful, uses H.248/MEGACO signaling to create a new conference at the MRFP (which acts as the media mixer). In this way, it creates a new MEGACO context for the conference and assigns resources for the request. Afterwards, in step 3, the session progress message is sent toward UE 1, passing through the proxy call state control function (P-CSCF). The P-CSCF triggers service authorization at this point toward the PCRF, which may query AS, S-CSCF, etc. for the user’s QoS profile to validate that the user is subscribed to the conferencing service with the requested QoS profile. The result of this signaling is communicated to the PDSN, which acts as the policy enforcement point in the data/media plane. Once authorized, the session progress message is passed to the UE 1 in step 6. UE 1 inspects the session-in-progress message, checks the codecs (i.e., the INVITE offer response) and confirms the result in the PRACK message in step 7. The UE may select one codec out of multiple accepted codecs in the session-in-progress message; in this case, it includes this in the PRACK message. In step 8, the radio-specific QoS flow reservation process is initiated and flows become ready to use from the radio link perspective at the end of this stage; however, the IP traffic cannot flow yet because the PDSN blocks it until the signaling exchange completes. In step 9, the MEGACO/ H.248 MODIFY command may be used to change the codec settings for the connection. In step 10, after the radio reservation has completed, the UE sends an UPDATE message informing the MRFC that the reservation on the radio side was successful. Any change here may result in another MODIFY operation to the MRFP (not shown in the figure). This triggers the MRFC to instruct the MRFP to connect the through-connection resources for UE 1 at step 11 (which may be done through the ADD command in MEGACO). In step 12, the PCSCF instructs the PDSN to allow the IP flow (i.e., open the gate). Finally, in steps 13 and 14, UE 1 sends the final ACK message and starts the media session. For UE 2 and UE 3, we have similar processes that run simultaneously with UE 1. It should be noted that the conference is only created by the arrival of the first user, and the rest of the users are simply added to it. This is reflected on the H.248/MEGACO ADD command sent to the MRFP to add UE 2 and UE 3 to the same context; thus, all users can “hear” each other. It should also be noted that standard IP QoS mechanisms may be applied to the media traffic targeted to the MRFP in the IP transport plane. Such mechanisms may include MPLS differentiated services (DiffServ), IP DiffServ, etc. This may allow efficient prioritizing voice and video packets directed to the respective MRFP servers.


101

Conferencing The basic services for the IMS, as defined in 3GPP TS 24.229, allow a user to initiate, modify, and terminate media sessions. As is, they certainly allow multiparty calls, end-to-end based; however, more sophisticated services for multiple parties—for example, conferencing—can be supported by the IMS infrastructure. The conferencing service provides the means for a user to create, manage, terminate, join, and leave conferences. It also provides the network with the ability to give information about these conferences to the involved parties. Conferencing applies to any kind of media stream by which users may want to communicate. This includes audio and video media streams but might as well include instant message-based conferences or gaming. On the media side, the conference service must be able to bridge the different media streams as well as provide other features, such as tone decoding for authentication and conference identification. This means practically that, if the bridge is MEGACO controlled, a certain number of packages will have to be supported. However, for the most part, we shall have a large number of interactions with the controller to support the calls. Note, however, that all these functions will be executed in the IP domain, even if calls are initiated or terminated in POTS. The conference bridge sees only IP calls, and IMS will take care of routing them into the telephony domain if necessary. Still, the bridge must support other protocols that may be related directly with media end-flows; that is, they do not follow the signaling path. Floor control, for example, uses a specific protocol called BFCP, which will help control which flow will be assigned to which applications. More details on signaling and conferencing can be found in references 2, 13, and 15.

Functions into Boxes Although IMS is a formal—that is, standardized—architecture, we can wonder how it can be translated into a practical implementation. Indeed, it is common for a manufacturer to “internalize” some interfaces into hybrid— that is, multifunction—boxes, rather than implementing them explicitly. In other cases, interfaces will be extended, or enriched, beyond the standard. This topic is too broad to be discussed here in all its generality. Nevertheless, we want to analyze what such considerations have to bear on the implementation of the media function and the choices we can find in the market. We should note, however, that this issue is not ignored in standards; in TS 24.147 (version 7), we find the following: As the functional split between the conferencing AS and the MRFC is out of scope of the present document, the procedures are described for a

102

IP Multimedia Subsystem (IMS) Handbook combined conferencing AS and MRFC. The AS and MRFC may either be collocated or interoperate using a proprietary protocol and a proprietary functional split.

The Media Function First recall that network applications that can be built by using the MRF are quite varied. This variety is reflected in commercial offerings. We find: • • • • • • •

transcoders; message servers/streamers; IVR; other specialized products, such as voice recognition; conference bridging; games; and unified messaging.

Beyond simple functional decomposition, another element to consider is the means used to configure or adapt such services to the needs of the users. We will explore this issue further in the next section. A Few Examples We present here a few products present on the market at the beginning of 2007. We start with products or manufacturers specializing in media processing and end with the products of major manufacturers. Note that this is meant to be a survey of the diversity of approaches to the IMS market rather than an endorsement of manufacturers. Cantata Technology: Cantata is born from the merger of Brooktrout Technologies and Excel Switching. The product line addresses the different media needs of the IMS—the MRF as well as the breakaway function: IMG 1010: This device is a media and signaling VoIP gateway. It provides connectivity with voice networks, enabling the delivery of SIP services into legacy telephony domains, as well as IP-to-IP transcoding (peering). SnowShore IP media server: This device combines the features of both MRFC and MRFP. It offers, among others functions, video, announcements, mixing, and dynamic content integration. Note that it is not specifically targeted at IMS but is meant to integrate easily into a SIP-based environment. Excel MSP 1010: This platform simultaneously supports advanced media and signaling processing, including:


103

− voice and video messaging; − personal ring-back tone; − prepaid services; − unified messaging; and − short messaging service. A family: Observe how these products can be used together. For example, the media server can act as a transcoder for a message announcement provided by the IMG 1010. Of course, an application server is required to perform overall control. IPunity–Glenayre: This company’s MRF product is presented as two components: a media server and an application server. The MS can perform a number of standard functions, including streaming video, tones or announcements, or bridging. The company offers a number of prepackaged services on top of its products aimed at the enterprise or carrier market, such as conferencing. It also includes MEGACO support. Radisys: Radisys’s Convedia media server family integrates all the functions of traditional (telephony) announcement servers, acting as support for IP telephony: interactive voice response (IVR/VRU) units, audio and video conference bridges, messaging, TTS, and speech recognition. It supports a SIP interface as well as an earlier version of MEGACO. Alcatel–Lucent: Alcatel–Lucent products are in line with the IMS architecture and support explicitly—and separately—the MRFC, MRFP, MGW, and SGW functions: Media gateway: The Alcatel–Lucent 7510 Media Gateway is a multiservice gateway in the media plane in the sense that it supports both the MGW and trunking MGW. In the control (signaling plane), it supports both the SGW and the I-BGF functions (again supporting both trunked and local VoIP media). It is also designed as scalable (“pay-as-you-grow support”). Network controller: This product line provides the MGW function and promotes a smooth migration to next-generation multimedia services. It can also optionally support the SGW function, or it can be provided as a stand-alone. Alcatel–Lucent also offers a feature server, which is essentially an SGW product that supports a wide range of legacy services, such as freephone, 800 numbers, and call back and call return, through its IN/AIN interface. This product also supports emergency services and legal interception functions. It also has a SIP interface that can be used to support IP Centrex applications. Media gateway controller: This product acts as the MGCF by controlling gateway products using MEGACO or SIP for both access and

104

IP Multimedia Subsystem (IMS) Handbook trunking functions. It also allows access to voice servers such as Centrex servers and can control IP MRFs to allow announcements and conferences, thus encompassing some MRFC functionality. Media resource function: This product supports both the MRFC and MRFP functions. It enables audio and video conferencing with a multiplicity of conferencing supporting functionalities, such as interacting with users before the conference, text insertion into the video streams, and voice and video messaging. This product is mostly suited for convergent environments (fixed and mobile). It also allows media processing functionality to be shared for other services like content-based video services and push-over cellular applications, thus allowing efficient utilization of the media processing functionality. The MRF product by Alcatel– Lucent also segregates the evolution paths for the MRFC and MRFP, thus allowing more scalability and redundancy.

Siemens: Siemens offers the product denoted as HiPath 8000, which supports SGW, MGW, conferencing, and text-to-speech functionalities. It also supports SIP signaling and MGCP generally, MGCP, etc. This product is known for its considerable interoperability features with other vendor products, such as Cisco, and its suitability for largescale deployments (i.e., thousands of users). Ericsson: Ericsson products support MGW, SGW, and MGCF functionalities within the products of: Media gateway: The Ericsson Media Gateway is based on the Ericsson product AXD 301 and performs the media gateway function, controlled by the H.248 protocol. It is designed to offer high scalability and availability. Access gateway: The Ericsson Access Gateway offers the SGW functionality by converting signaling between PSTN and ISDN into IP (i.e., ISDN user protocol [ISUP]). Ericsson telephony server: This product acts as the MGCF and supports ISUP, SIP-T, and H.323 signaling, allowing it to interface to a wide range of SGWs and MGWs. Because it is based on the AXE platforms, this product is also expected to offer high availability and scalability. Cisco: The Cisco product portfolio includes the support of MGW, SGW, and MGCF functions: Media gateway control: The Cisco PGW 2200 Softswitch product acts as the MGCF and supports a wide range of functionalities, such as mid-call redirection and legal interception. It also supports the BGCF function, which allows the selection of the MGCF that needs to handle the call. Advanced session border functionalities are on the road map of this product. This product is implemented on Sun platforms.


105

Media gateway: The MGX 8880 acts as the IMS–MGW and is most suited for large deployments. It supports a wide range of signaling protocols (MGCP, TGCP, H.248, H.323, and SIP), making it easy to deploy for both IMS and non-IMS applications. In addition and in line with the traditional Cisco offerings, this product supports most of the routing protocols (such as RIP, OSPF, or BGP) and also supports QoS through its MPLS DiffServ support. Signaling gateway: Finally, the product known as Cisco IP Transfer Point (ITP) acts as the SGW function to allow interconnectivity with the PSTN networks. It is implemented on the Cisco 2811 IP Transfer Point LinkExtender (ITP-L), Cisco 7204 and 7206, Cisco 7301, and Cisco 7600 Series. Understanding the Market We can summarize this short, informal survey with a list of issues. Again, our point is not to compare these products in terms of quality but, rather, to underline the different strategies chosen by manufacturers and expose the state of flux of the market. Also, we do not want to imply that other important manufacturers (e.g., Huawei, Nortel) do not have relevant quality products of their own. Are they targeted at IMS? We see that many products are essentially IP telephony products, either as softswitch support or for interworking with traditional telephony. There are certainly obvious reasons for this because that market predates IMS. Of course, because the same functions are present in IMS, any distinction with earlier generations may be blurred except for a couple of issues: which control interface is implemented and whether an application server is in the background to support service development. Do they distinguish media? Most products support the distinction between a telephony interworking media function and media support for IP telephony service deployment. Furthermore, streaming is mostly restricted to support for telephony, possibly extended to video telephony. Do they separate media and control? Some products integrate both functions under a single chassis while providing both forms of access (signaling, control) externally. Do they include AS? As mentioned earlier, having an AS in the background means that new services can be deployed in the IMS sphere. Many products presented previously are essentially offering classical telephony services—POTS or PABX inspired—in a built-in form. In the next section, we review some mechanisms provided to provision such services as well as alternative means to provide new services.

106


Is the market heading in a specific direction? We can observe early signs of consolidation in the market as small companies merge to offer a larger range of media processing/gateway products. At the same time, the link with the application remains weak because a large number of different, overlapping interfaces are supported and services are often prepackaged.

Other Issues The IMS architecture moves as interest and possible domains of deployment grow, as does the work at IETF, W3C, and other forums on related issues. We present here trends on a number of issues, starting with the discussion on network-centric and terminal-centric views, over control protocols for the media functions, up to provisioning. Network versus Terminal Centric We have so far explored the standards’ view of IMS. The reader may have noticed that this view is rather network centric or, better, operator centric. Terminals could even be seen as an emanation of the network. The drawback is that we then tend to see services as requiring support from the (IMS) network, whereas this does not need to be the case. We can distinguish three different cases:

1. terminal-to-terminal calls; 2. terminal-to-MRF (or MRF-to-terminal) calls, with variants with multiple endpoints (conferencing or call-back); and 3. terminal to terminal through the network.

The drawback of the network-centric model would be to see all calls as requiring AS support, which would lead to an increased load in the signaling plane. Although this is certainly a necessity for MRF-assisted calls, we must consider when terminal-to-terminal calls (case 1) should really use a relay (case 3). The issue is essentially related to the service that the user activates and whether or not the service enables him or her to add—and remove—features to the call. In the IMS architecture, as long as signaling is routed through an AS, it is possible to insert or remove an MRF on the call and notify the terminals of the change. Note also that this issue is not restricted to the media flow itself because it is possible for application-specific control channels to be set up, not unlike the floor control example mentioned earlier.


107

Such channels are actually part of the issue. If they are to be set up from end to end, then it will be the duty of the MRF to relay them to their destination. As an example, we could consider a terminal-based streaming function, which could require transcoding. If media control is done through the realtime streaming protocol (RTSP), it would either need to be relayed through the MRF or chance a loss of synchronization of the flows. This is actually an example of problems that may occur as we develop more terminal-based services rather than network-based services, which seems a natural trend because terminals’ computation capacity will increase. End-toend data transfer, companion to an instant-messaging service, and even peer to peer are also likely candidates. Terminal versus network services will likely evolve into a critical issue in the future, if the evolution of the Internet is any indication. The ability to install any application on a terminal, possibly via download, means that, eventually, operators may not be able to control the services that will be deployed on terminals and will have challenges integrating their support into their IMS platforms. Such considerations will likely be critical for the evolution of IMS. Control Protocols for the Media Functions We have presented MEGACO and SIP and mentioned MGCP, an ancestor of MEGACO still to be found on the market. There are debates whether SIP in itself is not sufficient to cover these different forms of signaling and whether MEGACO is required at all. Note that SIP can be used between a controller and a processor without necessarily putting the processor on the call flow (i.e., without relaying the call set up), but with a side call (IETF RFC 4240). There are, however, other alternatives to consider: MRCP: The media resource control protocol, standardized as RFC 4463 under the impulsion of Cisco and speech processing companies, is meant to control such resources as speech synthesizers and recognizers, signal generators, signal detectors, and fax servers. A newer version of the protocol ties it much more closely to SIP to reflect current trends in IP telephony. MRCP is not a “stand-alone” protocol; it relies on a session management protocol—that is, SIP or RTSP—to establish a control session between the client and the server, including negotiation of call parameters. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once the call is established, MRCP exchanges runs in parallel with the media and signaling session, allowing the client to control the media processing resources on the speech resource server. In the next section, we will see how this protocol can be used in conjunction with VoiceXML.

108


API: We have so far put a great emphasis on reference points and protocols, but they are only one, let us say telecom-oriented, perspective. The other, more programming-oriented, is to define an application programming interface. This model is quite popular with the Java programming language because it allows all potential users to share a common view of a service, or set of functions, across products from different manufacturers. As part of the Java community process, an initiative was started in 2007 to specify a media server control API, named JSR 309. This API would be in direct competition with MEGACO, but it is only in the early stages of specification. Nevertheless, it would help to support alternate implementation models for IMS components and further ease integration of media functions into applications. Provisioning and Configuration Another dimension is the creation or provisioning of services, especially in scripting form. For the past decade we have seen an explosion in the number of applications of the extended meta language (XML) for this purpose. We present here two examples related to media functions: VoiceXML: VoiceXML is a declarative programming language standardized by the W3C for creating speech-based telephony applications. VoiceXML supports dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of audio, basic telephony call control, and mixed initiative conversations. We can see now why MRCP, described previously, is a perfect companion for VoiceXML to remotely control a processing engine through VoiceXML scripts. VoiceXML is primarily a dialog language; it is designed to manage a voice or video dialog between a human and a computer. Although it does include some basic features for call transfer, these are redundant with the features provided by SIP. It was originally designed by W3C to be downloaded from a server to a client, in a typical Webbased development model, so that the client could directly control media processing resources as suited a voice user interface. Media server control markup language and protocol: Media server control markup language (MSCML; also RFC 4722) is a markup language used in conjunction with SIP to provide advanced conferencing and IVR functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP conferencing framework.


109

Summary and Final Remarks In this chapter, we have reviewed and analyzed different perspectives on media functions in IMS, including a survey of the relevant standards. Our exploration of media issues has been quite broad, and many points would certainly warrant deeper exploration. Our goal has been to expose the different forces at work in this quite dynamic, still in heavy turmoil, area. Beyond technological/technical alternatives, there are also political forces at work. We present a number of key issues likely to follow in the near future: SIP limitations: SIP has acknowledged [16] limitations in the identification and dynamic control of services. This will require further evolution to allow it to support a large set of services on a single terminal concurrently. Control of SIP: The previous point notwithstanding, SIP is an IETF protocol, but 3GPP is the major SIP user. With Telecoms and Internet Converged Services and Protocols for Advanced Networks (TISPAN) and PacketLabs now heavily interested in IMS, there are tensions to control the evolution path of the protocol according to “dominant interests.” Infrastructure versus services: Although IMS is an infrastructure, other bodies, such as the Open Mobile Alliance, worry more about services than the infrastructure itself. This attitude is more understandable when we realize that services—such as IP/TV—can be created and deployed fairly quickly over a dedicated infrastructure, but largescale deployment of IMS is still not foreseen along the mid- to longterm horizon. Media and service: Beyond the issue of how to implement the media function, we have the issue of creating services around it. Most of what we see at this point is still very much IP-telephony flavored and uses a large number of specialized languages and interfaces. More work is certainly warranted on that front. QoS model: A decent QoS model, more user centered, will be required in both the media and the signaling planes. Others: Of course, we have the usual issues of tracking resource consumption (i.e., accounting and billing) as well as providing security at many levels of interactions.

References

1. IETF. SIP: Session initiation protocol, RFC 3261. 2. IETF. 2002. MEGACO protocol version 1.0, RFC 3015.

110


3. IETF. 2002. Integration of resource management and session initiation protocol (SIP), RFC 3312. 4. IETF. 2000. The COPS (common open policy service) protocol, RFC 2748. 5. 3rd Generation Partnership Project. Transparent end-to-end packet-switched streaming service. 3GPP TS 22.233 V7.0.0 (2006-06) stage 1 (release 7). 6. 3rd Generation Partnership Project. Network architecture 3GPP TS 23.002 V7.2.0 (2007-06). 7. 3rd Generation Partnership Project. IP multimedia subsystem (IMS); stage 2, 3GPP TS 23.228 V7.8.0 (2007-06). 8. 3rd Generation Partnership Project. Resource function processor (MRFP) Mp interface: Procedure descriptions, 3GPP TS 23.333 V1.0.0 (2006-12). 9. 3rd Generation Partnership Project. Architectural enhancements for end-toend quality of service (QoS), 3GPP TR 23.802 V7.0.0 (2005-09). 10. 3rd Generation Partnership Project. Conferencing using the IP multimedia (IM) core network (CN) subsystem; stage 3 3GPP TS 24.147. 11. 3rd Generation Partnership Project. Internet protocol (IP) multimedia call control protocol based on session initiation protocol (SIP) and session description protocol (SDP); stage 3 3GPP TS 24.449. 12. 3rd Generation Partnership Project. Transparent end-to-end packet switched streaming service (PSS); general description (release 7); 3GPP TS 26.233 V7.0.0 (2007-06). 13. 3rd Generation Partnership Project. Specification group core network and terminals; interworking between the IP multimedia (IM) core network (CN) subsystem and circuit switched (CS) networks (release 7) 3GPP TS 29.163, version 1.0, version date: May 2007. 14. 3rd Generation Partnership Project. Media gateway control function (MGCF)? IM media gateway; 3GPP TS 29.332 V7.7.0 (2007-06); stage 3 (release 7). 15. 3GPP2 X.S0029-0. Conferencing using the IP multimedia (IM) core network (CN) subsystem version 1.0, version date: May 2007. 16. Camarillo, G. et al. 2007. Towards an innovation oriented IMS. IEEE Communications Magazine, 3, March 2007, pp 130–136. 17. ITU-T. Gateway control protocol: version 3 H.248.1, 09/2005.

Section 2

Technologies

5 The FOKUS Open IMS Core—A Global IMS Reference Implementation Peter Weik, Dragos Vingarzan, and Thomas Magedanz

contents Project Background.............................................................................................. 114 The Components.................................................................................................. 115 Requirements.............................................................................................. 117 The Call Session Control Functions......................................................... 118 SER IMS Extensions........................................................................ 119 Proxy-CSCF...................................................................................... 121 Interrogating CSCF......................................................................... 122 Serving CSCF................................................................................... 123 Home Subscriber Server............................................................................ 124 Working with the Open IMS Core..................................................................... 125 A Real Reference Implementation?................................................................... 127 Outlook.................................................................................................................. 129 References............................................................................................................. 130

Back in 2003, when we started our research work on the IP Multimedia Subsystem (IMS), we had the big challenge of finding a suitable solution that would enable us to route and process session initiation protocol (SIP) signaling in conformance with the IMS standards (at that time 3GPP release 5 [1]) at an affordable cost for a research and development (R&D) institution. Although we found many open source projects focused on Internet Engineering Task Force (IETF) SIP topics, we sadly did not find any with a specific emphasis and direction on IMS. Add to this the fact that we had a long legacy in developing SIP prototypes at Fraunhofer FOKUS, and we started doing our own development. This chapter should give the reader some perspective on the background of the project, the motivation to develop open source software for routing messages in an IMS core network, and how it can help not only rapid but 113

114


also efficient, flexible, and powerful design, development, and testing of Next-Generation Network (NGN) components and services. Although we can only outline some of the implementation details and main features of the four components of the open IMS core, we will try to compensate for this by pointing to how to obtain, work, and extend the software and where to get more information. Because the project outcome so far has been widely used as a reference implementation in the R&D domain as well as within the industry, at the end of the chapter we will summarize some prominent projects and users who make use of it.

Project Background The basis for starting this open source project came from the activities within the Open IMS Playground [2], a truly open, multivendor NGN testbed hosted at the Fraunhofer Institute FOKUS in Berlin, Germany. Initially funded by the German government for its research activities to develop IMS component prototypes to enable small and medium business services, the test-bed soon became self-supporting through its cooperation with industry partners interested in NGN architectures and applications. From the start of this test environment, there was the clear intention not just to label SIP traffic for conforming to IMS but, rather, to develop an extensive routing solution that would allow all the operator-centric features that an IMS network brings. Especially for generating the correct SIP formatting, this came naturally to us because we could base much of our work on the SIP Express Router (SER) [3], a well-respected SIP router also developed at FOKUS. The great maturity and modular structure of the SER allowed us to focus on building IMS functionality as an extension to it rather than to start from scratch. Another big factor in choosing SER as a base was the fact that today SER is regarded as a reference for SIP proxies. Almost all performance studies include it in evaluations, and, due to its flexibility, it is one of the most used SIP proxies in the world. Looking ahead, it is conceivable that an IMS core network based on SER could also be at least competitive, if not representative, for IMS networks’ performance and flexibility, just as SER is for voice over IP (VoIP) handling today. The first vendor interoperability tests in the Open IMS Playground started in 2003 and, from feedback from those industry partners and fellow researchers, the software evolved over the years along with the specifications for IMS. By working for a noncommercial organization, we could focus on implementing the essentially needed features in order to enable prototyping for IMS application development on service delivery platforms as well as on the client side, rather than cater to management-defined feature road maps. In 2005 we started working in the standardization group for IMS.

The FOKUS Open IMS Core—A Global IMS Reference Implementation

115

benchmarking [4], where the Open IMS Core served as a reference implementation for a system under test (SuT). Through the great feedback that we received from the participants, we managed to eliminate many performance bottlenecks from the software and to further align with the latest IMS standards (which were then also coming with requirements from the European Telecommunications Standards Institute (ETSI) Telecoms and Internet converged Services and Protocols for Advanced Networks (TISPAN) and other bodies). In November 2006, after more than 3 years of internal development and testing, we decided to release the software to the R&D community under the GNU General public license version 2 [5]. Coming from the R&D domain, the idea of the Open IMS Core Project therefore is to fill the void in the open source domain for IMS software and to provide an IMS core reference implementation for IMS technology testing and IMS application prototyping for research purposes, typically performed in IMS test-beds. Through this project, all potential IMS service developers (no matter whether they develop on SIP application servers; on an Open Service Architecture (OSA)/Parlay or Parlay X gateway, with Java APIs for integrated Networks [JAIN] service logic execution environment (SLEE) technology; or even on an Intelligent Network (IN) service that is connected to the IMS via an IMS Service Switching Function) should have a full 3rd Generation Partnership Project (3GPP) IMS-compliant IMS service control (ISC) interface at hand that allows them to make use of IMS routing features for building their services. However, also toward the access network layer, the Open IMS Core targets sparking the development of components and concepts that come with the attachment of various access networks to the overlay architecture IMS. Believing in the powerful innovation that open source brought in the Internet world, we wanted the IMS core routing functions to be fully and freely available to the public for extending them and making them adjustable to the various needs and requirements that small and medium enterprises, universities, or the R&D departments of operators and vendors alike will have to build, research, and develop.

The Components Although we looked for development of the components of the open IMS core always very closely linked to developments in the specifications of 3GPP, this was often not enough because other standardization bodies came up with requirements toward an IMS core network. We will try to outline how this network convergence on a standards level toward an NGN influenced our work, how the Open IMS Core components are structured, and what main features they had to support. At time of writing this chapter, the 3GPP, originally established in December 1998 with the scope of defining a globally applicable 3G mobile phone

116


system, still leads the specification of IMS concepts as a solution for a universal all-IP telecommunication network (currently with their work on release 8). Also, its partner organization, 3GPP2, embraced the IMS concepts from the start and adopted wide parts from the 3GPP. However, the focus of 3GPP2 is on supporting CDMA2000 technologies, whereas 3GPP was long concentrated on the mapping to a set of wireless technologies (like wideband code division multiple access (W-CDMA) or wireless local area network (WLAN) networks). Furthermore, ETSI is recognizing the value of IMS as a third organization with its body, the TISPAN, which has the scope of converging fixed line networks and the Internet. The TISPAN NGN standards are targeting network convergence by adopting and reusing IMS components with the additions to support xDSL technologies, but these were based on 3GPP’s release 6 and 3GPP2’s revision A. At the time of writing, work is ongoing for NGN Release 2. Additionally, the cable network industry started to adopt the IMS as their reference platform from delivering multimedia services in the PacketCable 2.0 specifications, which again build on 3GPP specifications but bring their own requirements and deltas with it. In order to avoid further divergence, starting from release 8, the 3GPP has announced the merging of all of these different “flavors” into one common IMS. Besides these main bodies, many other groups and organizations see the value of an IMS network for delivering services over an operator network and adopt concepts and interfaces from it (e.g., the MultiService Forum’s (MSF) release 3). With different standardization bodies all accepting the same core routing technologies (and standards), it is safe to state that the upcoming NGNs will also share the same IMS core components, which in turn may need to support some additions or options for specific access networks. Figure 5.1 illustrates this fact for fixed and mobile networks. After all, the NGN approach means for operators to get from stove pipes for service delivery to a layered model, which features an IP-supporting access layer plane, a session control layer plane, and the services layer plane. On the access layer plane, customers demand that the communication networks converge into a layer that allows seamless usage of any network technology to access services in a similar manner-wired or wireless networks that need not be different from the user’s perspective. On the service layer plane, the services (ranging from purely telco-centric services such as mailboxes or call-forwarding over IPTV play-out to mash-ups with services and enablers on the Internet) are decoupled from the access network and will have defined interfaces to the two lower planes and the user in the same way as enabler services like presence or the use of an XML Document Management Server (XDMS). The IMS with its core comes into play as a broker between the access networks and the services layer to support operator-specific needs like centralized user management, defined charging support, and features like single sign-on, security, or breakout to the PSTN (Public Switched Telephone Network) domain and other networks. This is also the angle from which we were looking at the NGN during the development of the Open IMS Core.


XDMS

Signaling Media

SIP AS

Parlay X Gateway

117

Presence Server

Application Layer HSS S-CSCF

I-CSCF

Signaling Gateway

P-CSCF NASS

A-RACS

PSTN

(S)PDF

Session Control Layer DSLAM

WAG

Media Server

BAS/ A=BFG

PDG GGSN

RAN Transport Layer

SGSN

Core I-BGF/ Network TrGW

Media Gateway

IPv4 Network IPv6 Network

Figure 5.1 The three layers of an NGN architecture.

Requirements Although the IMS relies upon IETF specifications like the SIP [6] or the Diameter [7] standard, the SIP protocol requires certain mandatory extensions, also specified in the IETF, for using it in an IMS network. The primary requirement for the Open IMS Core Project, therefore, was to provide a set of IMS-compliant components that would enable the best development of the other layers around them. Over the years there were some differences in the various bodies building on IMS as a reference architecture, especially for authentication methods and security toward clients; thus, there is no such thing as one common IMS standard (at least, not for now). Then the main scope was to obtain call session control functions (CSCFs) and a home subscriber server (HSS) that ideally comply with all of the parallel specifications. However, often enough this meant that at least all required functionality as indicated by 3GPP in its Release 6 (sometimes even Release 7) specifications should be implemented.

118


Another requirement specific to the CSCFs was to maintain, as much as possible, SER’s top performance. As SER obtained wide adoption in the SIP world, becoming almost a standard for performance, it can be assumed that the CSCFs, which shared such a large base with SIP routers, would have similar performance standards. Similar data structures, algorithms, and patterns have been used in the IMS extensions, maintaining the low resource consumption. To conclude, it was important for us to maintain this high-performance grade, especially because the Open IMS Core had to produce first-time answers for IMS scalability, distribution, and performance questions. The 3GPP represents still the main specification body for IMS. However, we saw many pre-IMS implementations cutting corners to achieve better running conditions while trying to be compliant with the specifications, and the Open IMS Core had to react to this by maintaining SER’s user scripting facilities, which enable full flexibility in exploitation and an easy configuration. The easy configuration requirement also holds true for the HSS, which had to make it as easy as possible to set up IMS service and user profiles. Of course, to power many IMS test-bed installations as a reference implementation often also requires achieving close to carrier-grade features with respect to performance, a certain security, and availability. However, these were not primary goals because our main interest was toward enabling an open community around the IMS core network. Commercial implementations will certainly provide all the features that we luckily did not have to take specific care of (e.g., the integration with specific operator operational or business support systems). Also, the Open IMS Core project is not set to compete with such implementations but, rather, to help the industry into R&D efforts to overcome challenges with setting up IMS networks and enabling the development of services that make use of the IMS core. Starting from plain SIP routers, the actual realization of an IMS core network from those proved to be a difficult task [8]. The main challenge was that it had to perform very well in terms of speed and functionality. It had to reduce the processing to the minimum while at the same time implementing all functionalities required in the various IMS specifications from the mentioned bodies. The scope was to get to a reference implementation by closely following the specifications and not compromising conformity for performance. Thus, the project Open IMS Core is, in the end, a combination of the three CSCFs defined for IMS that are complemented by an HSS (see Figure 5.2). The Call Session Control Functions At the functional core, the CSCFs are SIP proxies. This main functionality is complemented by registrar and back-to-back user agent (B2B-UA) capabilities. Because all three entities share much functionality, it made sense for them to use a common base system that is configured differently. The CSCFs


119

Sh

Cx

HSS

ISC

Cx

SIP AS

Mw

I-CSCF

S-CSCF Mw

IETF SIP

Mw

P-CSCF

VoIP Client

Gm

IMS Client

Figure 5.2 The four components of the Open IMS Core Project.

are built upon the SER, which can act as SIP registrar, proxy, or redirect server and is capable of handling many thousands of calls per second. Thanks to its modular structure, it was possible to make functionality additions. Each CSCF entity of the Open IMS Core is implemented as one main SER dynamically loadable module that adds the required operations to the SER so that it can act according to the specific technical specifications from 3GPP or others. Several secondary modules are also used to provide common functionality such as Diameter capabilities or database access. The modules are capable of parallel processing and can keep supplementary state information. There is a special focus toward scalability for both load distribution and memory footprint. SER IMS Extensions SER was designed to be a powerful SIP proxy/server and it also achieved a large deployment in commercial VoIP set ups, so it qualified as the first candidate for enabling the SIP functionality. Because it acts as its own open source project, we are following what the SER community is doing and are building on the latest version of the SER as well. However, to be usable in an IMS environment, it had to feature Diameter capabilities. This proved to be not as easy as integrating RADIUS client funtionalities into SER because

120


a Diameter node must have both client and server capabilities at the same time. With special concerns toward speed, using an external stack would not have yielded good results because of numerous context changes and data exchanges. However, the target was to have a low latency of just a few milliseconds for SIP transactions, so the Diameter requests had to be processed with even lower delays. The obvious solution was to add Diameter as an SER module. The integration of a custom-built Diameter stack, the C Diameter peer (cdp), proved to be the best solution performance-wise, making the open IMS core CSCFs foremost a Diameter-enhanced SER (Figure 5.3). Diameter peer processes run alongside SIP processes, providing cross-access to each other’s capabilities while still offering best performance. Due to its high parallelism grade, it is best to run these in a multiprocessor environment. The challenge for an S-CSCF compared to a pure SIP router is to enforce the rules from a centrally stored user profile employed in an IMS environment and stored in an HSS. This was done with the ISC module. Although existing user location, registrar, and authentication SER modules were already available, the data structures employed in IMS are more elaborate. Again, going for the simple solution of introducing these as generic additions to the existing modules would have not allowed for the best performance. The user location module required additions for keeping the extra user information employed in IMS, like the private/public identities, Proxy-CSCF (P-CSCF) path information, service profiles, and initial filter criteria. Replicating data into a database is not necessarily required because mechanisms for orderly moving users from one CSCF to another are already specified in IMS. The registrar must also implement the “reg” event subscriptions and notifications [9]. The P-CSCF employs a reversed registrar that must synchronize itself with the registrars on S-CSCFs. Regarding authentication, although authentication and key agreement (AKA) [10] mechanisms are mandatory in order to generate key material for the signaling security tunnels (IPSec) toward an IMS user with 3GPP, we had to offer support for several other

mysql SER

IT TM ...

pcscf

Proxy-CSCF

icscf

cdp

Interrogating-CSCF

scscf

isc

Serving-CSCF

Figure 5.3 The SER modules added for the open IMS core.


121

authentication methods as well (e.g., the digest authentication of the PacketCable 2.0 standard [11]). As the Open IMS Core was being adopted by more and more people and organizations, many of them started to use it alongside day-to-day exploitation environments for trials and comparison. From them came the requirement that the CSCFs and HSS had to be increasingly stable and offer at least a limited set of carrier-grade features in exploitation. As a result, the nodes have been complemented with a “persistency” feature that allows for immediate fault recovery or on-the-fly reconfiguration, practically extending the Open IMS Core’s reliability in the day-to-day hard usage. Proxy-CSCF In the current implementation of the Open IMS Core, the P-CSCF component can be configured to firewall the core network at the application level in an SBC manner: only registered endpoints are allowed to insert messages inside the IMS network and the P-CSCF asserts the identity of the users (Figure 5.4). For this, upon registration, the P-CSCF establishes secured channels individually for each user endpoint (UE) that it serves. Both IPSec and transport layer security (TLS) security associations can be negotiated with the UEs. In addition to the SBC functionality, the P-CSCF protects not only the network but also the clients from malicious signaling. To keep track of the registered users, it maintains an internal reversed registrar that is updated by intercepting the registration process and later by subscribing in user agent client (UAC) mode to the registration package at the S (serving)-CSCF and receiving notifications. The actual data are kept in hash tables to allow fast retrieval. For originating call signaling, it generates unique charging vectors and inserts network and path identifiers that are needed for the correct further processing of the SIP messages. UE-forged information that might lead to an attack is removed or corrected. After a successful registration process to an IMS home network, subsequent user messages are forwarded based on DNS (Domain Name System) information towards the requested IMS home network. Regarding network address translation (NAT) issues for the SIP signaling, in the outgoing direction, toward the user endpoints, it can act as a router by simply being active in both networks. Also, NAT traversal modules were adapted for the specific user location storage mechanisms. After user-specific security data (like cipher keys) have been eliminated, the SIP messages are forwarded directly to their destination. Filtering in this direction is needed because cipher material must not be sent over the potentially not-trusted connection between the UE and P-CSCF. The P-CSCF also implements a Diameter interface to support the exchange of the information needed to perform policy and charging control (PCC) [12] on the multimedia sessions being established in the access network as well as authentication features in network attachment subsystem (NASS) environments. Also, for the PCC-required functionality, the P-CSCF follows and

122


Home Network 2

Home Network 1

Visited Network

STOP

STOP

Proxy CSCF

STOP

IMS UE

IMS UE

IMS UE

SIP Signaling Secure Channel

Figure 5.4 The Proxy-CSCF functionality.

maintains all routed dialogs so that administrative updates and termination are possible. Interrogating CSCF The interrogating CSCF (I-CSCF) has the role of a rather stateless proxy that, by using the indicated public identities of the caller, queries the HSS and, based on responses, routes the message to the correct S-CSCF (Figure 5.5). It implements the Cx [13] (resp. [14]) interface of an I-CSCF to the HSS. Therefore, it supports the required Diameter commands to locate the user-assigned S-CSCF or to select, based on capabilities, a new S-CSCF and check identities and roaming authorizations. After receiving a successful answer for the Diameter query, the I-CSCF forwards the SIP messages in a transactional mode. It is optimized for speed and minimal state information is kept. To protect the home network, it has a firewalling capacity that allows only signaling messages coming from trusted networks through network domain security (NDS). Additionally, it can be used as a topology hiding gateway (THIG), which encrypts and decrypts sensitive SIP headers as a proxy for all inbound and outbound messages exchanged with networks that are not trusted.


123

HSS NDS Home Network S-CSCF Visited Network 1

Visited Network 2

THIG

Figure 5.5 The Interrogating CSCF functionality.

SIP Signaling Diameter

Serving CSCF The S-CSCF also communicates with the HSS using Diameter to retrieve authentication vectors, update registration information, and download the user profiles as specified in reference 11, 13, or 14 (Figure 5.6). To be truly convergent, it implements support for carrying out the 3GPP IMS Digest AKA version 1 [10] and version 2 [15], Digest MD5 in four different flavors (3GPP AKA MD5 adapted by FOKUS for MD5 only, CableLabs PacketCable 2.0 SIP-Digest [11], ETSI/TISPAN NGN Rel. 1 HTTP-Digest [14], 3GPP Rel.8 SIP-Digest [13,16]), and as well as 3GPP’s Early-IMS-Security [17] or ETSI TISPAN’s NASS-bundled authentication [14]. Rather than generating authentication vectors, the S-CSCF relies on the HSS for this task and compares these values to the ones calculated in the UE. For fast response times with minimal locking, the registrar of the S-CSCF has a complex structure based on hash tables. The information that is required to relate a user identity to a physical UE is stored here and used later on for call routing. It also accepts subscriptions to registration state events and notifies the subscribers about changes in the registrar. Dialogs are followed so that administrative termination is possible. For service triggering functionality, the S-CSCF can apply the user profile-based initial filter criteria (iFC) to enforce specific SIP routing rules on a per-user basis. The messages are then routed over the IMS service con-

124


Application Servers

HSS

I-CSCF

Network A

Network B

S-CSCF Network C

SIP Signaling Diameter

Figure 5.6 The Serving CSCF functionality.

trol (ISC) interface toward the application servers. The additional interfaces with media resource functions (MRFs), media gateways, or PSTN breakouts can also be easily enabled by modifying the SER routing script for the S-CSCF. Home Subscriber Server The Open IMS Core would be incomplete without a Home Subscriber Server (Figure 5.7). FOKUS developed its own prototype HSS, the FOKUS HSS (FHoSS), which is entirely written in Java and also based upon open source software. The user data are kept inside an external MySQL database. Its purpose in the Open IMS Core is that of a database, so the FHoSS is targeted mainly toward conformance, while keeping in mind performance. It is mostly glue between a database management system and the Diameter interfaces with the CSCFs and IMS application layer. Protocol checks and Diameter command logic are implemented in the HSS. Additionally, it allows the generation of authentication vectors [13] and notification of IMS-


Security Domain

BSF NAF

125

Application Servers

Zh

Sh

HSS Cx

Cx

Diameter

Figure 5.7 The HSS functionality.

based events to subscribed IMS application servers via the Sh reference point [18], and it offers support for the Zh interface [19] in authenticating users as part of a Generic Authentication Architecture. It provides a Web-based management interface for easy management of user profiles, authentication schemes, associated iFCs, etc. As we found [20], one of the main performance bottlenecks seems to be related to the HSS and database access. Thus, for evaluating the mere performance of the CSCFs, a very fast HSS was required because the implementation of replication, distribution, caching, or other optimization methods at the HSS is not efficient because the database management system is already implementing those. Therefore, a lightweight stateless HSS emulator that allows specific operations over the Cx interface [13] was implemented in C for carrying out some performance-related measurements. It runs on a multithreaded architecture and is capable of handling many clients and processing the requests through parallel workers. It does not keep any IMS state in memory but, rather, uses the same MySQL database for this purpose.

Working with the Open IMS Core The project’s Web site [21] contains detailed information on operating system (Linux), hardware (normal desktop PC), and software requirements; information on how to obtain the software; and, foremost, a step-by-step guide on how to install and update it. Thus, instead of describing those steps, we defer the interested reader to instructions in reference 21. Because we understand from user reports that even inexperienced users can do this in less than 20

126

IP Multimedia Subsystem (IMS) Handbook if (method==INVITE || method==SUBSCRIBE || method==MESSAGE) { (1.1) if (!P_is_registered(“open-ims.org”)){ (1.2) sl_send_reply(403,Forbidden You must register first); break; } P_add_P_Charging_Vector(); P_add_P_Visited_Network_ID(“open-ims.test”); }

Figure 5.8 CSCF configuration file excerpt.

minutes, we guess that we achieved the goal of providing a simple solution that is easy to set up. Further, ready-to-run full installations are offered as preconfigured virtual machine installation, thus reducing the installation time to almost zero. Users can customize the respective CSCF’s modules over a straightforward configuration file, which is aligned with SER’s configuration files. It lets users enable features (e.g., for supporting IMS clients using network address translation with setting mod-param(“pcscf,” “NAT_enable,” 1) in the configuration file of the P-CSCF) and the default CSCF behavior in a simple message routing scripting language (Figure 5.8). It should be noted that these routing scripts are merely examples to be used as a start-up for the network administrators, and no programming experience is required in order to enable features or add interfaces and routing rules. To edit IMS subscription information, application server settings, and user profiles, the HSS offers a protected Web console accessible with a normal Web browser (Figure 5.9). Additionally, there are many scripts provided, allowing for automatic manipulation of the databases with customized settings and users for IMS test environments different from the default one. Because we are a small group of core developers, we do not have the manpower to maintain different software package releases and extensive written documentation. That is why we opted to stay for the time being in a continuous state of development. This means that we reference for potential bug and feature requests received on the project’s various mailing lists only the latest revision on an SVN tree. The developer community found a solution for automating this challenge of having to keep up with developments in providing the previously mentioned virtual machine image that allows an automated setup and updates and logging of running installations, thus making it even easier for starters to develop around it. The same concept also works for the documentation. Here we provide Web sites that reflect the documented code and usage guidelines.


127

FHoSS Management Console - Mozilla Firefox

File Edit View

History

Bookmarks Tools Help http://127.0.0.1:8080/hss.web.console/

FOKUS testbeds FHoSS - The FOKUS Home Subscriber Server (Rel. 7) HOME USER IDENTITIES

SERVICES

NETWORK CONFIGURATION

STATISTICS

Services

Trigger Point - Search

• Service Profiles Search Create • Application Servers Search Create

(QWHU6HDUFK3DUDPHWHUV

ID Name

• Trigger Points Search Create

Search

• Initial Filter Criteria Search Create • Shared iFC Sets Search Create

Waiting for 127.0.0.1...

Open Notebook

Adblock

Figure 5.9 The HSS provisioning interface.

Also, for developers interested in contributing to the Open IMS Core, there is a flexible and open policy; we will provide a public development branch to any party who can justify that specific features are currently missing. Also due to this open nature and despite being real specialist software for the telecommunications domain, the project managed in its first year of public existence to create a worldwide vital developer community and a discussion forum for IMS-specific topics. The Open IMS Core team managed to merge all preexisting open source IMS efforts; today, several hundred developers are following the discussions on the mailing lists of the project, where usually one can find answers to any IMS-related questions for application server integration, IMS routing problems, or the like in a matter of hours or a day.

A Real Reference Implementation? What makes this software now a reference implementation? First, the fact that the Open IMS Core is available at no expense under an open source license has certainly helped to attract many R&D people. Also, commercially oriented companies like to complement their demonstrations for NGN scenarios with it. Although this aspect has certainly helped with the initial

128


distribution of the software, we received feedback that the maturity of the software with respect to standards compliance and performance and the continuous support from a core developer group let several hundred people a day visit the Web sites and monitor the mailing lists. A second important aspect is that, based on the requirements that came from the different industry partners of the Open IMS Playground and from the users of the software, the Open IMS Core caters to many current deltas that the specifications for IMS traffic routing (and especially with respect to authentication) offer in the fixed, mobile, and cable network domains. As such, with the latest feedback received, it seems that the standardizing organizations are also starting to regard the project as a reference and as the best experimentation playground for new and converged features. The development of the Open IMS Core [8,22,23] was supported by publicly funded R&D projects as well as other industry projects. Thus, we will try to outline the prominent ones of which we are aware in this section, but there are certainly many more projects in laboratories or on student computers that would deserve to be mentioned: • ETSI TISPAN IMS benchmarking standard. Within workgroup 6 of ETSI TISPAN, the open IMS core, from the beginning of the standardization of [24], served as the reference implementation for an SuT for the benchmarking of IMS core components. The standard defines for the first time the methodology, metrics, reports, and process of finding and attesting to the performance of NGN networks. • Use in NGN interoperability scenarios. There is a clear case for using the software in interoperability scenarios with several vendors or R&D partners. Any partner can use the software for in-house trials before going to an interoperability event. Especially for the commercially oriented IMS interoperability events, we have received some very positive feedback from lab personnel at the Interoperability Laboratory of the University of New Hampshire [25], which hosts the testing events for, for example, the IMS Forum or the MSF introduced previously. The Open IMS Core is part of their default setup for IMS networks. Also, the ETSI TISPAN WG6 relies on the Open IMS Core as one solution to be used in their IMS Plug Tests. • Use as a nucleus for enabling IMS test-beds and other open source projects. Although the Open IMS Core has, for a long time, enabled service creation and component developments as the central nucleus for the Open IMS Playground, there are also not purely IMS-related testbeds that can benefit from having it. One aspect is to act as a southbound foundation for research on new service delivery platforms that work on principles of a service-oriented architecture; another is to use it closely integrated with specific IPTV play-out scenarios and


129

applications to research and support future media distribution over IMS core networks. In addition to supporting FOKUS internal research, we received some very positive feedback from R&D projects, universities, and IMS component vendors. We know that the Open IMS Core is used in some of the FP6 projects of the European Union and that it enables many operator R&D departments’ NGN labs (e.g., Portugal Telecom Inovacao, Orange Labs, and Slovak Telekom) as well as joint industry IMS test labs [26]. Additionally, we received positive statements from universities and independent R&D centers that describe the use of the Open IMS Core as part of their everyday lab setups. Others are working with it as part of doctoral work, building master thesis topics around it, or using it as part of lectures to illustrate IMS concepts and to teach students about NGN technologies. As yet another side effect, the Open IMS Core has also sparked the development of open source projects in the IMS client domain [27,28]. It is clear that the Open IMS Core today is enabling different parties within the NGN research community to prototype, measure, or develop around it— whether they are services or components. Even though still half of the visitors to the Web site are from Europe, the interest for this specialist software is happening globally as we register hits from more than 120 countries. We hope that our further work on the software, together with the user feedback, patches, and bug-fixes coming from this community, will stimulate even more projects than it already has stimulated in its first few months of existence as a reference implementation for IMS core elements.

Outlook When we were releasing the Open IMS Core project in November 2006, the initial goal was to establish a small developer community and lower the skepticism that IMS is still facing within some parts of the VoIP industry. We wanted to show that IMS is not necessarily a walled garden but, rather, is and can be just as well an open standard for delivering services in NGN. We wanted to equip the R&D community with an easy-to-use solution for starting its own IMS developments; we did that by providing software that had been already validated in a multivendor IMS test lab as open source software for several years. Although many people are still not aware that there is a solution like the Open IMS Core available, we can say that we achieved this goal and that many of parties interested in IMS have started to make good use of the software. In this chapter, we tried to outline some of the use cases and why one can con

Both topics are currently under research at FOKUS.

130


sider the Open IMS Core as a reference implementation in this domain. Even though we are already experiencing a good community effect on the project’s mailing lists, with developers helping each other out, for the future months and years we are looking forward to seeing that community grow, especially because there is still a need for IMS prototyping and test-bed support in the IMS adoption phase with many operators and vendors worldwide.

References

1. 3GPP TS 24.228. Signaling flows for the IP multimedia call control based on session initiation protocol (SIP) and session description protocol (SDP) (release 5). 2. The FOKUS Open IMS Playground. http://www.open-ims.org 3. The SIP express router. http://www.iptel.org/ser 4. IMS Benchmarking Special Interest Group. http://www.fokus.fraunhofer. de/IMSBenchmarking/?lang-en 5. GNU general public licenses. http://www.gnu.org/licenses 6. Rosenberg, J., H. Schulzrinne et al. 2002. SIP: Session initiation protocol, RFC 3261. 7. Calhoun, P., J. Loughney, E. Guttman, G. Zorn, and J. Arkko. 2003. Diameter base protocol, RFC 3588. 8. Weik, P., D. Vingarzan, and T. Magedanz. 2005. Design and implementation of an open IMS core. Mobility Aware Technologies and Applications, Second International Workshop, MATA 2005, LNCS 3744, ISBN-10 3-540-29410-4. Berlin: Springer–Verlag. 9. Rosenberg, J., 2004. A session initiation protocol (SIP) event package for registrations, RFC 3680. 10. Niemi, A., J. Arkko, and V. Torvinen. 2002. Hypertext transfer protocol (HTTP) digest authentication using authentication and key agreement (AKA), RFC 3310. 11. PacketCable 2.0 PKT-SP-29.228-I02-070925. IMS delta specifications IP multimedia (IM) subsystem Cx and Dx interfaces: Signaling flows and message contents specification, 3GPP 29.228. 12. 3GPP TS 23.203. Policy and charging control architecture. 13. 3GPP TS 29.228. IP multimedia (IM) subsystem Cx and Dx interfaces: Signaling flows and message contents. 14. ETSI TS 183 033. IP multimedia–DIAMETER-based protocol for the interfaces between the call session control function and the user profile server function/ subscription locator function: Signaling flows and protocol details. 15. Torvinen, V., J. Arkko, and M. Naslund. 2005. Hypertext transfer protocol (HTTP) digest authentication using authentication and key agreement (AKA) version-2, RFC 4169. 16. Garcia-Martin, M., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, and K. Tammi. 2006. Diameter session initiation protocol (SIP) application, RFC 4740. 17. 3GPP TR 33.178. Security aspects of early IP multimedia subsystem (IMS). 18. 3GPP TS 29.328. IP multimedia (IM) subsystem Sh interface: Signaling flows and message contents.


131

19. 3GPP TS 29.109. Generic authentication architecture (GAA): Zh and Zn interfaces based on the Diameter protocol. 20. Vingarzan, D., and P. Weik. 2006. End-to-end performance of the IP multimedia subsystem over various wireless networks. IEEE Wireless Communications and Networking Conference 2006, Las Vegas, NV, April. 21. The FOKUS Open IMS Core project. http://www.openimscore.org 22. Weik, P., D. Vingarzan, and T. Magedanz. 2006. Towards an open source IMS core system enabling rapid prototyping of NGN services. NGNM06 3rd International Workshop on Next-Generation Networking Middleware, Coimbra, Portugal, 19 May 2006, 23–29, ISBN 972-95988-7-8. 23. Vingarzan, D., P. Weik, and T. Magedanz. 2007. Development of an open source IMS core for emerging IMS testbeds. Special issue on IMS. Journal on Mobile Multimedia (JMM) 2(3), 131–149. 24. ETSI TS 186 008. Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); IMS/NGN performance benchmark. 25. The University of New Hampshire. InterOperability Laboratory. http://www. iol.unh.edu 26. IMS Advanced Research Cluster for Services. http://www.ims-arcs.org 27. The UCT IMS client. http://uctimsclient.berlios.de 28. The IMS communicator. http://imscommunicator.berlios.de

6 Next-Generation Grid Support over the SIP/IMS Platform Vicente Olmedo, Antonio Cuevas, Victor Villagrá, and José I. Moreno

contents Introduction.......................................................................................................... 134 Advantages of Grid–IMS Interaction....................................................... 135 Architecting a New Grid Environment: Commercially Oriented with Dynamic and Mobile Services................................................ 136 Base Virtual Organization......................................................................... 137 Operational Virtual Organization............................................................ 138 Service Provider.......................................................................................... 140 Network Provider....................................................................................... 140 Integrating IMS’s SIP Infrastructure and Grids: Mobile and Dynamic Grid Environment............................................................ 141 Involved Protocols: SIP and SOAP........................................................... 141 Integrating SIP and SOAP......................................................................... 142 SIP Support for SOAP-Based Grid Services............................................ 144 Initialization.................................................................................... 144 Setting Up Sessions Involving Services Running in MTs......... 144 Disconnection and Reconnection of Terminals and Their Services; Mobility............................................................. 147 Accidental Disconnection.............................................................. 149 Changes in Services in the Terminals While the Session Is Running............................................................................. 149 Session Teardown........................................................................... 149 Integrating Grid Services and SIP-Controlled Audio/Video Calls..... 149 Integrating Grid with the Network Operator Infrastructure Reusing IMS-Defined Interfaces...................................................... 151 PDF/PCRF Interface to Grid Service Provider....................................... 152 Interfaces to the HSS and CDF for User Control.................................... 154 Conclusion............................................................................................................. 155 References............................................................................................................. 155

133

134


Introduction In the near future, network operators may lose their central position in the telecommunications business value chain and become mere “bit pipes.” That is why service platforms controlled by the operators, such as i-mode or the IP multimedia subsystem (IMS), are becoming so important. IMS is a welldesigned service platform, using open and standardized Internet protocols and respecting the Internet paradigm of data transport and application separation, yet still building links between these two layers [1]. Service platforms must entice users to employ them, offering a rich service environment. IMS is a promising service platform, but it targets only standardized initiation session (SIP) proxiable applications—that is, applications that use the SIP protocol and SIP proxies to help control the sessions between the participants. An example of these applications is audio and video conferencing. These peer-to-peer applications allow users, among others, to make the “traditional phone calls” that are, still today, the network operators’ main business. However, many of the applications with great user acceptance do not use the SIP protocol and thus are out of the IMS scope. Some examples are ring tone downloads, online games, and content sharing applications. These applications have a great commercial acceptance and represent an ever-increasing source of revenues for network providers. Efforts are being made to broaden the panoply of services that can fit under the IMS control framework. The Open Service Architecture (OSA)/Parlay consortium [2] developed and develops means for service providers to interact with network operators; integrating OSA/Parlay with IMS is one of the main efforts made to broaden the set of services available under the IMS platform. The Open Mobile Alliance (OMA) [3] is the leading actor in enriching the services offered over the IMS platform. In parallel to IMS, the traditional distributed computing community (finally evolved toward the Grid/Web services community) came up with solutions and concepts that could also be used for bundling services and, ultimately, building service platforms and rich service environments. A very important notion within the Grid framework is the notion of a Virtual Organization (VO). A VO is a temporary or permanent coalition of geographically dispersed individuals, groups, organizational units, or entire organizations that pool resources, capabilities, and information to contribute to the VO according to the established contracts. These contracts are typically driven by one or more business processes. VOs can provide services and thus participate as single entities in the formation of additional VOs. This enables the creation of recursive structures with multiple layers of “virtual” value-adding service providers. Many Grid environments are created using the Web Services Resource Framework (WSRF) [4] level and the Open Grid Services Architecture (OGSA) [5] services layers. All Grid resources, both logical and physical, are modeled as services on the basis of Web service implementations. For

Next-Generation Grid Support over the SIP/IMS Platform

135

the purposes of resource modeling in the Grid, the Web service interfaces must frequently allow for the manipulation of state—that is, data values that persist across and evolve as a result of Web service interactions. One of the main goals of the WSRF is to achieve this state control. The WSRF defines a family of specifications for accessing stateful resources using Web services. Note that communication services (e.g., voice calls) are also described using this framework. The Web services layer, together with the WSRF, provides a base infrastructure for the OGSA services layer providing the overall Grid management functionality. The basic motivation is to provide OGSA-specific services implemented through the WSRF. Advantages of Grid–IMS Interaction Grids offer a service composition and orchestration that is not as centralized as in the IMS, and they support a more heterogeneous range of devices and services than the IMS. In Grid environments we could even consider as services the capabilities of a user (such as a medical first-aid worker) logged into his or her device. However, we must bear in mind that these types of services are very dynamic because users (with their devices) may move, change the device they employ, or simply “disappear” (shut down the device or lose connectivity). This kind of dynamicity is better supported in IMS- and SIPbased environments than in Grid scenarios. Granting Grids mobility and dynamicity [6] is one of the rationales for integrating Grids and IMS. IMS is a service platform very targeted to the commercial world, whereas Grids are weaker in this point. Integrating Grids and IMS will provide the necessary mechanisms to bias the Grid world toward a commercial environment, if this is needed. IMS builds links between the application layer and the transport level to achieve, among other things, an integrated quality of service (QoS) coordinating these two layers. This is especially relevant for IMS “core” applications like user-to-user audio/video communications. Grid applications may not have such stringent QoS requests; thus, the Grid world does not care much about coordinating the QoS offered by the network operator for its data transport service and the QoS at application layer. Thus, integrating IMS and Grids will span the IMS-rich QoS control mechanisms to the Grid. In the approach described in this chapter, thanks to their interaction within the IMS service platform, Grid applications (using the Web services framework) will be able to: • establish a Grid session with a mobile/ubiquitous service without prior knowledge of its current location; • use the SIP mechanisms to manage sessions, like transfer a session, or perform third-party Grid session control. This includes integrating non-grid applications like SIP controlled voice calls;

136


• use the presence and context management mechanisms established by the SIP for Instant Messaging and Presence Leveraging Extensions (SIP SIMPLE) infrastructure; and • use IMS mechanisms to bill for the service and authenticate and authorize users. Figure 6.1 depicts the general architecture of a service environment composed of the IMS service platform and Grid services. Further sections will detail how this service environment is achieved. By integrating Grids and IMS, the IMS service platform is enriched to build a more complete and attractive service environment that will attract users. Integration of Grids (and more specifically, Web services) and IMS still falls into the research field. Solutions have been presented, such as those in reference 7. In this chapter we describe the solution provided within the Akogrimo project [8]. Following sections explain how this enhanced service platform is achieved in the Akogrimo project.

Architecting a New Grid Environment: Commercially Oriented with Dynamic and Mobile Services Grids are a collection of heterogeneous devices with different capabilities and services offered; they are interconnected and work together toward a.

Content Provider Travel Agency

Online German-Spanish Translation

SIP Session Control

Network Provider

User Control and Billing Service Discovery

First-aid Capabilities

Figure 6.1 An enhanced service environment: control elements from the IMS service platform and Grid services.

137


common goal. This set of devices is often called a Virtual Organization. Many grid environments are created using the WSRF level and the OGSA service layer. All Grid resources, both logical and physical, are modeled as services on the basis of Web service implementations. Web services are stateful, and one of the WSRF’s goals is to take this into account. Communication services (e.g., voice calls) are also described using this framework. Grids are often decentralized and they “build up” themselves and offer services in a rather dynamic way. However, normally, they are not commercially oriented; they are not user centric and do not consider that users (logged in to their devices) may offer services, like medical first aid. To integrate Grid organizations in the telecommunication business and support services offered by users, the following building blocks have been identified (Figure 6.2). Base Virtual Organization One of the main building blocks in Grid architectures is the Base Virtual Organization (BVO). Essentially, a BVO is a suite of Service Providers (SPs) Customer Domain

Base VO VO Management

User

Discovery

Context Manager

Identity

Accounting & Charging

User

Identity


OpVO Management

Composition

OpVO

Identity

Service Provider

Network Provider Network Management

Services

Discovery Identity


Execution Management

Services

Discovery

Data Management

Identity


Figure 6.2 Grid building blocks making possible its integration within IMS.

138


linked by a contract; in order to provide specific services, they work together under the terms of this contract stated in the Service Level Agreements (SLAs). This contract is signed and is settled on a quite static basis. For the Grid environment to meet the “semiwalled garden” business model (followed by the IMS), the SPs forming the BVO must also have a contractual. relationship with the Network Provider (NP). In the semiwalled garden business model this contract states, among other things, that the main part of the customer relationship is handled by the NP. The contracts linking the SPs between them inside the BVO and to the NP are settled in a static way. However, the subset of the BVO’s elements working together and offering a (billable) service to the customers is instantiated dynamically, forming the Operational VO (OpVO) that we will study later. Next we provide the details of the relationships established between the BVO and the other building blocks: • The NP supplies the network infrastructure to access the BVO. The BVO leverages on the trusted NP (which is a member of the BVO) to authenticate the identity of the incoming requests (essentially coming from customers or from SPs forming the BVO). • The customer will be allowed to perform two main actions inside a BVO: searching for services and creating OpVOs (detailed next). • The SP will be allowed to publish its services inside the BVO, and their use will be acquired by the customer through the BVO itself (by the instantiation of OpVOs). • The OpVO building block is a component internal to the BVO. The BVO interacts with the OpVO, creating it and configuring a dedicated subdomain for its execution. Figure 6.3 depicts the concept of BVO and compares it to Figure 6.4, which illustrates the concept of OpVO that we explain in the next section. Operational Virtual Organization The OpVO is a building block that assumes an important role at execution time when the application is actually delivered to the customer. The OpVO is the “run time environment” of some of the providers offering their services inside the BVO. In any case, the OpVO lives inside a BVO and several OpVOs can be instantiated in each BVO. The SP will be contacted by the OpVO in order to negotiate the instantiation of the services needed for the Grid environment execution. The success of this negotiation will lead to the dynamic establishment of a contract. Because this process is done within a BVO that

Next-Generation Grid Support over the SIP/IMS Platform Grid SP

Grid SP

139

Grid SP

Grid SP

Grid SP

Base VO

Network Provider

Figure 6.3 A BVO and its contract with the Network Provider; also, Network Provider contracts with the users.

Grid SP

Grid SP

Grid SP

Grid SP Grid SP

Base VO

Network Provider

Figure 6.4 Two OpVOs dynamically instantiated inside a BVO.

holds a “static” contract with the NP (among others), the NP may participate in the control of the services delivered over an OpVO. The customer will be allowed to perform some administrative actions on the OpVO (e.g., subscription of new users) because he or she is the owner of

140


the OpVO. Furthermore, the customer (or any other user delegated by the customer) can use (paying for it) the applications instantiated through an OpVO. Most important, users logged in to their devices can offer services and charge for them. These services exist in a very dynamic way because users (with their devices) may move, change the device they employ, switch it off, etc. On the other side, services by providers are far more stable. The existence of OpVOs allows integrating these two types of service provisioning scenarios. Because the OpVO is an instance inside the BVO and the BVO has relationships with the NP following the semiwalled garden business model, an integrated billing (controlled by the NP) is possible, despite the very different nature of services (Grid and non-Grid) offered in the OpVO. Service Provider Services that manage and supply resources and enforce policies and SLAs reside in the SP domain. The service offered by the SP will interact and cooperate within the OpVO, contributing to the global Grid service delivery. Thus, SPs must expose their services to the orchestration carried inside the OpVO. This includes advertising the services offered, registering them in the appropriate service index (this server will be a SIP registrar, the IMS’s S-CSCF, as we will detail later). This service index can also be queried by SPs to find needed services. Because Grids are to be integrated in a commercial environment (as the IMS is), a function that supports the metering of the resources that are being consumed during the execution of a service is located in every SP hosting a service for sale. Emulating the IMS behavior, the SP will send accounting data, at least, to some specialized nodes in the NP, aggregating and correlating accounting data coming from different sources. All services located in the SP domain are accompanied by a set of mechanisms targeted to establishing identity and negotiating authentication. They will depend on the authentication services, among others, offered by the network operator. Note that services offered by SPs run in the OpVOs and these are instances of the BVO, which has contracts with the NP. These contracts allow the SPs to employ the accounting, charging, and authentication services delivered by the NP. Network Provider All the related represented functions required to provide network services in a Grid-compliant manner reside in the NP domain, thus creating a new environment where Grids meet the semiwalled garden business model. The available accounting and charging activities on this domain are ready to account and charge for Grid services as well, which finally makes the network domain basically ready to deploy Grid services commercially on its infrastructure. Also, NP elements manage the identity of the users, authenti-


141

cating them and providing this authentication service to the BVO (and thus to the OpVOs and SPs).

Integrating IMS’s SIP Infrastructure and Grids: Mobile and Dynamic Grid Environment Involved Protocols: SIP and SOAP The SIP [9] is a protocol targeted to the establishment, modification, and termination of sessions. In the context of SIP, a session is understood as an association created between two or more participants to interchange some kind of data. SIP’s specification only defines the signaling messages and the operation of the protocol, decoupling it from the actual type of data to be exchanged once a session has been successfully established. Also, the parameters that characterize the session to be negotiated by the participants during the session setup are described using the Session Description Protocol (SDP) [10], which is transported as payload in SIP messages (Figure 6.5). Despite this decoupling, SIP has been traditionally used to manage multimedia sessions such as voice over IP (VoIP) telephone-like calls. Also, the SDP descriptions available mainly relate to this kind of multimedia session, describing, for instance, the media codecs to employ in the sessions. Considering that it is conceived to support any kinds of applications, SIP has been designed by the IETF to be used as a signaling framework in IP networks. Thanks to its inclusion in the IMS, SIP is currently the de facto standard for signaling in next-generation networks. SIP functionality makes it especially useful in mobile and ubiquitous environments. In such environments, users can move and change the terminal they are using to access the services. The SIP infrastructure tracks each user in order to keep the information about its (logical) location updated. The key signaling protocol for Grids and virtual organizations is the SOAP [11]. SOAP is a lightweight message-based protocol intended for exchanging structured information in a decentralized, distributed environment over a

GenericApplication

GenericApplication SIP_session_setup_negotiation Application_typically_multimedia_(RTP/RTCP)_but_can_be_any SIP_session_tear_down

Figure 6.5 SIP is decoupled from the application.

142


variety of underlying protocols. SOAP enables the binding and usage of discovered Web services by defining a message path for routing messages. We consider stateful (enabled by WSRF) and session-aware SOAP Grid services in this chapter. For the integration of SIP–IMS and stateless Grid services, the reader can check reference 7. Integrating SIP and SOAP As we discussed, making Grids mobile and dynamic is of great advantage. However, the SOAP protocol used by Web services (the framework used by Grids) is not as well prepared for this as SIP is. Besides, one of the goals is to involve users (logged to their devices) in service provision (like providing medical first aid during a disaster scenario) and integrating SIP controlled user-to-user communications. This is why the best approach is to keep SIP and integrate SOAP with it. Thanks to the SIP–SOAP interaction, SIP information such as the current location, as well as notifications about the status of mobile services being run by users previously registered in the SIP server, is propagated to the Grid layer and vice versa. In this way, the Grid layer can keep track of the mobile users and readjust to changes on the fly. SIP–SOAP interaction can be implemented in two ways: • A SIP Application Programming Interface (API) can be provided to the Grid applications. These applications will then issue SIP signaling messages directly to the appropriate SIP entities; that is, a SIP User Agent (SIP UA) is integrated in the Grid application. Once the session is set up using SIP, SOAP messages will be used during the session. This is just like other applications (such as VoIP) using SIP work. This approach is the cleanest one in terms of architecture but implies the modification of Grid applications in order for them to interact directly with the SIP infrastructure, instead of using SOAP messages. • Some intermediate entities will be provided; these will be invoked, using SOAP, by the Grid applications. These entities will issue the needed SIP methods (REGISTER, INVITE, BYE, …) on behalf of the Grid applications, even establishing Grid sessions on behalf of them. This approach will ease the implementation of the Grid applications because they will use regular SOAP messages (directed to the intermediary entities) even for SIP-related methods. Because SIP is used to negotiate the setup of Web services Grid sessions, the language describing the parameters to be negotiated (SDP) must be tailored to these kinds of applications. SDP (like SIP) was designed to support the definition of any kind of session (although the most common use is multimedia communications) by means of standardized extension mechanisms, so no special adaptation effort is needed to describe Grid sessions using SDP. We can call this description, for ease of understanding, “Grid ses-


143

sion description.” One of the main parameters to negotiate (described in the Grid session description) is the Web Service Description Language (WSDL) [12] file that describes each service involved. WSDL is used to describe the methods offered by a given service. WSDL files also contain the End Point Reference (EPR) of the service (i.e., where the service can be located in order to consume it). After the session setup negotiation, the Grid session participants will come to know the public methods and EPRs of every other service they are using in this session. To allow this interaction, a new SDP attribute (the “WSDL” attribute) is defined [13]. This attribute contains the URL where the service’s WSDL file can be retrieved. We will detail this negotiation later in this chapter. From a service provisioning point of view, an interface needs to be provided to Grid applications for the following methods: • At start-up phase, mobile/ubiquitous services will be associated with a certain SIP Uniform resource identifier (SIP URI), which has been previously registered in the SIP registrar (the S-CSCF) with the SIP REGISTER method. This SIP URI can simply be the URI of the user logged in to the Mobile Terminal (MT) where the services are running or a special URI representing the services. In any case, within the context of the SIP–SOAP synergies, we will refer to it as “service URI” from now on. • The Grid applications, instead of using EPRs, as stated in Web service addressing [4] for identifying resources, should use in the establishment phase SIP URIs for identifying mobile/ubiquitous services (EPRs are not suitable for identifying resources that change frequently in ubiquitous environments), so that they will send a SIP INVITE to the service URI. This SIP INVITE message will contain special values in its SDP payload so that it will be identified as a Grid session description by the recipient of the INVITE message. • In the SIP answer, again by means of an SDP-based Grid session description, the Grid application will get the needed Grid session information to start the Grid invocations (i.e., the WSDL file describing the service and its EPR). Also, Grid applications could include the adequate logic for • using further session management features provided by SIP such as session save/load/restore, useful also for session transfer. There are already some proposals for this feature (Web services continuity), like the approach presented in reference 14; and • reacting to context changes that are notified with SIP. The next section describes in a general way how the solution works. This description can be applied to any of the options listed before to achieve

144


SIP–SOAP interaction: patching the Grid applications to employ a SIP API or using intermediary entities. To show both solutions (that are conceptually similar), we assume that the Grid applications in the MTs have been patched to use SIP and that the Grid applications in the service providers employ an intermediary entity located in an independent node, the SIP–SOAP broker. The SIP–SOAP broker can be considered as an IMS AS (application server) that offers a Web services WS–SOAP interface to the Grid applications in the SP and a SIP interface to the IMS SIP infrastructure (the [S-CSCF]). For readability reasons, we consider that the MTs send/receive their SIP messages directly to/from the S-CSCF; actually, in the IMS, these messages first traverse the Proxy Call State Control Function (P-CSCF), which is the terminals’ contact point for SIP messages. SIP Support for SOAP-Based Grid Services Initialization During the MTs’ start-up, the Grid services and the SIP UA that will act on behalf of the Grid services running in the terminal are started following the depicted sequence (Figure 6.6; right side of picture). The SIP UA start-up involves a SIP registration and a SIP presence publication, in order to make visible the MT for other Grid services that could be interested in the Grid applications running on it. After the SIP UA starts, the MT will be ready to provide information about the grid services running on it. The service URI to be used will be the SIP URI used during the SIP registration. The SP must also register, but we must bear in mind that although the Grid services offered by users logged in to their devices are in an extremely dynamic environment (users move, change their terminals, disconnect, etc.), the services offered in Grid service providers are far more static. After the initialization, the Grid services will be ready to receive WSRF notifications. Setting Up Sessions Involving Services Running in MTs EPR is the way Grid and SOAP reference the services; in SIP this is done using URIs. The services (Grid or not) offered within the IMS service platform are indexed in the SIP registrar, a module of the IMS’s S-CSCF. The main result of the session setup negotiation, carried on using SIP and SDP, between Grid–SOAP nodes is that session participants will come to know the EPRs of the services they are using in this session as well as their public interfaces. Figure 6.7 illustrates this session setup. • When the Grid SP needs to know the EPR of a service running on an MT, it indicates which service it is interested in (ServiceID) and the SIP URI being used by the MT in which the service is expected

REGISTER_SIP(URI)

SIP_Presence-Agent

Figure 6.6 Registration of Grid services to the S-CSCF.

PUBLISH_SIP(Status)

SIP-SOAP_AS

WS_SUBSCRIBE_SOAP()

GRID_SP

S-CSCF

PUBLISH_SIP(Status)

GRID_Apli_Term

WS_SUBSCRIBE_API()

SIP_UA_Term

REGISTER_SIP(URI)

SIP_Registrar

Next-Generation Grid Support over the SIP/IMS Platform 145

SIP-SOAP_AS

ACK_SIP()

200-OK_SIP()

INVITE_SIP()

SIP_Presence-Agent

Figure 6.7 SIP-based Grid session establishment and service invocation.

WS_getConnectionDetailsReturn_API(WSDL_URL)

ACK_SIP()

200-OK_SIP()

WS_invokeServiceReturn_SOAP(Result)

GRID_Apli_Term

WS_getConnectionDetails_API()

SIP_UA_Term

INVITE_SIP()

SIP_Proxy

WS_invokeService_SOAP(EPR, method)

NOTIFY_SIP(Status)

SUBSCRIBE_SIP(URI)

WS_getConnectionDetailsReturn_SOAP(WSDL_URL)

WS_getConnectionDetails_SOAP(ServiceID, URI)

GRID_SP

S-CSCF



147

to be running. The Grid SP can also request all services running in a given terminal. • The SIP–SOAP AS starts a Grid session setup with the required MT. Finally, the required information (WSDL_URL) is returned to the Grid SP. This information is then used by the Grid SP to retrieve the WSDL file that describes the service, using HTTP or any other regular mechanism (this interaction is not depicted in the figure). • At this point, the Grid SP knows the EPR to be used in order to invoke the service or services it is interested in. • Additionally, the SIP–SOAP AS performs a subscription to the SIP presence information of the service SIP URI; in this way, it will be aware of the availability status of the whole terminal and may report changes to the Grid SP. Note that the terminal may also be interested in knowing the status of the services offered in the Grid SP, but the Grid SP status is very static compared to the services offered by the terminal. That is why the Grid SP subscribes to the terminal status but the opposite does not occur. Disconnection and Reconnection of Terminals and Their Services; Mobility Because the SIP–SOAP AS is aware of the terminal status, it can use this information—for example, to inform the Grid SP if the user disconnects from one location and then connects from a different one or with a different terminal (or if the user simply disconnects) [6]. Using this feature, the Grid SP can make an appropriate decision, like selecting different services or refreshing the information at the new service location. This is the behavior described in Figure 6.8. First, a controlled disconnection from terminal 1 occurs. From the point of view of the services SIP-based support, the most relevant steps are: • The SIP–SOAP AS informs the Grid SP about the SIP-based Grid session termination using the SOAP message WS_NOTIFY notification, indicating that all services running at the MT become unavailable. • The presence agent informs about changes on the presence status while the presence subscription done by the SIP–SOAP AS during the Grid session setup phase remains active. Then the service URI is used to connect again from another location. Thanks to the active presence subscription, the SIP–SOAP AS detects that the presence status of the associated service URI is online again and it can report on this to the Grid SP. Typically, the Grid SP will request the service details again at the new location, setting up a new Grid session as we saw in the previous section.

SIP-SOAP_AS

SIP_Proxy

200_OK

BYE_SIP()

Terminal1 GRID_Apli_Term

PUBLISH_SIP(Status)

REGISTER_SIP(URI)

WS_NOTIFY_API(ServiceStatus)

SIP_UA_Term

UNREGISTER_SIP(URI)

UNPUBLISH_SIP()

SIP_Registrar

S-CSCF

Figure 6.8 User disconnection and reconnection from another location.

WS_NOTIFY_SOAP(ServiceStatus)

NOTIFY_SIP(Status)

200_OK

BYE_SIP()

SIP_Presence-Agent

NOTIFY_SIP(Status)

WS_NOTIFY_SOAP(ServiceStatus)

GRID_SP

GRID_Apli_Term2

Terminal2

WS_SUBSCRIBE_API()

SIP_UA_Term2


149

Next-Generation Grid Support over the SIP/IMS Platform Accidental Disconnection

In the case of an accidental disconnection, the Grid SP will be aware of this situation because the SIP–SOAP AS will receive a SIP presence notification indicating that the presence status of the service URI has expired. This event will be interpreted as an incidental disconnection and the Grid SP will be informed about the complete services’ unavailability at the corresponding URI. Changes in Services in the Terminals While the Session Is Running The established SIP session will be used as the main mechanism to inform the Grid SP about changes on the MT grid services’ availability or EPRs. Thus, if the information related to some service changes, the MT’s SIP UA will send a reINVITE containing the new Grid session description. The Grid SP will be informed of this through a WS_NOTIFY_SOAP message, whose content indicates a change in the services. This sequence is depicted in Figure 6.9. Session Teardown When the services running on certain MTs are no longer needed, the Grid SP can terminate an existing SIP Grid session. In this case, the SIP presence subscription from the Grid SP to know the status of the terminal is also terminated. Integrating Grid Services and SIP-Controlled Audio/Video Calls For a third party to set up a SIP session (typically a voice call) between two other parties, two options are available: third-party call control (3PCC; described in reference 15) or using the SIP REFER method. We will concentrate on the latter in this section (Figure 6.10). S-CSCF GRID_SP

SIP-SOAP_AS

SIP_UA_Term

SIP_Proxy

GRID_Apli_Term

WS_NOTIFY_API(ServiceStatus) INVITE_SIP() INVITE_SIP() 200-OK_SIP() 200-OK_SIP() ACK_SIP() ACK_SIP() WS_NOTIFY_SOAP(ServiceStatus)

Figure 6.9 Change on services.

SIP-SOAP_AS

Figure 6.10 Grid-initiated calls using REFER.

WS_getConnectionDetailsReturn_SOAP(Success)

202-AC_SIP()

SIP_UA_Term 1

202-AC_SIP()

REFER(INVITE_2)

SIP_Proxy

NOTIFY_SIP(Status)

SIP_Registrar

S-CSCF

REFER(INVITE_2)

SIP_Presence-Agent

NOTIFY_SIP(Status)

WS_getConnectionDetails_SOAP(URI_1, URI_2)

GRID_SP VoIP 1

ACK_SIP()

200-OK_SIP()

INVITE_SIP()

Terminal 1

Terminal 2

AudioVideo-flows_RTP/RTCP()

AudioVideo-flows_RTP/RTCP()

SIP_UA_Term 2

VoIP_2



151

As part of the orchestrated execution of several services within a Grid environment, a call between two terminals may be needed. However, this voice call is not a Grid Web service but, rather, a multimedia application using the Real-Time Transport Protocol (RTP)/Real-Time Transfer Control Protocol (RTCP) and not the SOAP protocol. The solution to integrate this call in the Grid service environment is described as follows: • During a Grid service execution, a Grid application in the SP may receive the query to put in contact users 1 and 2. • After requesting the SIP URIs of the involved users, it sends a SIP REFER message to user 1 through the S-CSCF, indicating that a session with user 2 should be initiated. • The S-CSCF redirects the REFER to the MT or MTs where user 1 is logged in. • If the session setup is accepted on user 1 MT, it sends a “202 Accepted” response and starts a standard session setup process with user 2 MT. Note that SIP messages will follow the path “user 1 → P-CSCF → S-CSCF → P-CSCF → user 2”; for easy reading, we draw the SIP messages as going directly from user 1 to user 2. • The Grid SP is informed about the session progress via NOTIFY messages because the REFER method creates an implicit subscription to the status of users 1 and 2. • When the Grid SP is informed about the session establishment success, the process finishes.

Integrating Grid with the Network Operator Infrastructure Reusing IMS-Defined Interfaces Roughly speaking, IMS Call State Control Functions (CSCFs) are advanced SIP proxies controlling the application sessions between different entities. Those entities use SIP to set up their sessions and involve the IMS’s CSCFs in this session setup. One of the most prominent characteristics of the IMS is that it defines interfaces between the CSCFs and some nodes from the Universal Mobile Telecommunication System (UMTS) network. The first interface we consider is related to user control. The UMTS’s home subscriber system (HSS) performs user control and authentication; IMS defines an interface between CSCFs and HSS so that the CSCFs can delegate the user control to the operator’s HSS. Similarly, the Charging Gateway Function (CGF) is a network operator node performing accounting for network resources (e.g., bytes sent by the user). The IMS defines another interface between the CSCFs and the CGF. The IMS’s CSCFs will send to the CGF

152


accounting data related to the SIP sessions that the CSCFs control. These data may include, for instance, the type of the call between the users (audio or audio/video). Thus, CGF receives accounting data from different sources and from different levels (e.g., bytes sent/received and type of call between the users [audio or audio/video]). CGF is capable of correlating these two levels and producing an aggregated billing. The last interface we consider is that defined between the CSCFs, which know, for instance, that the users will employ a codec that requires 16 kbps for their voice call, and the network nodes that will transport this voice call. Thanks to this interface, the network nodes will be tailored to accommodate this voice call. The Grid SPs within the BVO (and thus with agreements with the NP) will be able to employ these three mentioned interfaces (with minimal modifications); see Figure 6.11. This will be done when an OpVO is instantiated within the BVO and the services of a service provider are needed within this Grid environment (the OpVO). In the next sections we will detail the three aforementioned interfaces. We must stress that because SIP support is included in the Grid environment and, as such, the Grid uses the IMS CSCFs, those CSCFs may tackle the three aspects mentioned earlier directly, as in pure IMS solutions. The approach where the Grid environment itself deals with these aspects using the three mentioned interfaces will streamline the process of Grid services provision. PDF/PCRF Interface to Grid Service Provider IMS’s CSCFs interact with the network Policy and Charging Enforcement Function (PCEF) (routers or, in UMTS networks, the Gateway General Packet

Service Provider

IMS Services’ SIP Sessions Control

Reuse these Protocols to Interface with the Service Providers

HSS, CGF, …

CSCFs

Open, Standardized “Internet” Protocols

UMTS. Data Transport Control. User Control (Authentication, Authorization, Accounting)

User Services (e.g., First-aid Capabilities) Figure 6.11 Reuse of IMS’s CSCF interfaces to UMTS network nodes. SPs access the network nodes.

153


Radio Service [GPRS] Support Node [GGSN]) via the Policy and Charging Rules Function (PCRF; Policy Decision Function [PDF] in older IMS releases). We plan to reuse the CSCF to PCRF interface for the interaction between the Grid SPs and the PCRF. The Grid SPs employ the SOAP protocol, and the mentioned interface is based on the DIAMETER protocol. Like the SIP–SOAP interaction explained in previous sections, two possibilities (illustrated in Figure 6.12) arise to make SOAP and DIAMETER cooperate: • An API is provided to the Grid SPs and their code is patched to use this API. When a Grid session is to be set up, by a call to this API, a DIAMETER message is sent to the PCRF to allow, subsequently, the user to make transport resource reservations to accommodate the flows of the Grid session. • An independent module is developed with a SOAP interface to the Grid SPs and a DIAMETER interface to the IMS’s PDF. This module exposes some of the functionality of the PDF as a Grid service (a Web service, actually), ready to be used by the Grid SPs. When they need to authorize the use of network resources for a subsequent Grid service, they will issue a SOAP request to this independent module. CSCFs

PDF/PCRF DIAMETER

IMS

Grid Service Provider Patched with API to Interact with PDF

PCEF (Router/GGSN)

Module Exposing PDF Functionality as a Web Service PDF/PCRF SOAP Grid Service Provider

Network

CSCFs IMS

Network

DIAMETER PCEF (Router/GGSN)

Figure 6.12 Possibilities for a Grid Web service to make resource reservation in IMS.

154

IP Multimedia Subsystem (IMS) Handbook This module will translate this request to a DIAMETER message sent to the IMS’s PCRF.

Because SIP support has been included in the Grid environment, this transport resource authorization can be tackled directly by the IMS SIP proxies, in particular by the P-CSCF. Also, because the P-CSCF may be located in the visited domain, roaming issues are solved. The preceding method will, however, streamline the Grid session creation process and, moreover, leave more control to Grid nodes over the needed transport resources. Taking into account that the Grid environment is especially dynamic (because of the mobile terminals), this is of great importance. Interfaces to the HSS and CDF for User Control In this section we detail aspects related to user control (authentication, authorization, accounting—AAA). Every SP has an accounting server collecting accounting data. With these data, the server will create accounting records; the most common protocol to transmit these records is DIAMETER, which is also used in IMS for these purposes. The Grid SP can send its accounting records to the IMS’s Charging Data Function (CDF); as in regular IMS sessions, the CDF will send accounting information to the operator’s CGF, which will aggregate this accounting information (at application level) with accounting information from the network level (e.g., bytes sent). However, so as not to overload the CDF with data coming from all the service providers, in each BVO an intermediate accounting node should be present. It will collect accounting information from the Grid service providers and send it, aggregated, to the CDF, as illustrated in Figure 6.13. Because the Grid SPs interact, using SIP, with the S-CSCF (as we saw in previous sections), the S-CSCF could also be in charge of sending these accounting data to the CDF, as is done in regular IMS scenarios. Even more, if we use an AS to achieve the SOAP (protocol used by the Grid SPs) with SIP interaction, it could be that this AS is the one sending the accounting data to Accounting Collection Module

CSCFs

CDF

DIAMETER DIAMETER

Grid Service Provider

Figure 6.13 Accounting for Grid Web services in IMS.

IMS

Network CGF


155

the CDF. Although this would require no further changes, it may overload the IMS more than the previous approach. With respect to user authentication and authorization, the same two possibilities exist: • The Grid SPs contact the network operator’s HSS directly. • Because the Grid has SIP support, this contact can be done by the IMS’s S-CSCF.

Conclusion IMS is a well-designed service platform that grants the network operator the role of service broker. Multimedia calls are a service inherent to IMS, but many more services should be developed on top of the IMS service platform to build a rich service environment enticing the users to employ it. Integrating the Grid/Web services environment into the IMS will broaden the possibilities to offer a rich service portfolio in the IMS. This integration is, however, not trivial because the IMS session control protocol is SIP, and Grid/Web services employ SOAP. Also, Grids were never biased into a commercial world. In this chapter we presented how to make this integration possible and the benefits that it will bring. This is one of the multiple steps to build a rich service environment based on the IMS.

References

1. Cuevas, A. et al. 2006. The IMS service platform, the key for next-generation network operators to be more than bit pipes. IEEE Communications Magazine 44(8), 75–81. 2. The Parlay Group. http://www.parlay.org 3. Open Mobile Alliance. http://www.openmobilealliance.org/ 4. Globus Alliance. The WS-resource framework. http://www.globus.org/wsrf/ 5. Globus Alliance. OGSA—The open grid services architecture. http://www.globus.org/ogsa/ 6. Waldburger, M. et al. 2006. Towards the mobile Grid: Service provisioning in a mobile dynamic virtual organization. 4th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA-06), Dubai, UAE, March. 7. Levenshteyn, R. et al. Mobile services interworking for IMS and XML Web services. 2006. IEEE Communications Magazine 44(9), 80–87. 8. The Akogrimo project. http://www.akogrimo.org 9. Rosenberg, J. et al. 2002. SIP: Session initiation protocol, IETF RFC 3261. 10. Handley, M. et al. 2006. SDP: Session description protocol, IETF RFC 4566.

156


11. World Wide Web Consortium (W3C). SOAP specifications. http://www. w3.org/TR/soap/ 12. World Wide Web Consortium (W3C). Web services description language (WSDL). http://www.w3.org/TR/wsdl/ 13. Olmedo, V. et al. 2007. The Session Description Protocol (SDP) WSDL attribute. IETF Internet draft (work in progress). 14. Dorn, C., and S. Dustdar. 2006. Achieving Web service continuity in ubiquitous mobile networks: The SRR-WS framework. 4th International Workshop on Ubiquitous Mobile Information and Collaboration Systems (UMICS), co-located with CAiSE 2006, June 5–6. 15. Rosenberg, J. et al. 2004. Best current practices for third-party call control (3pcc) in the session initiation protocol (SIP), IETF RFC 3725.

7 Policy-Based QoS Control for a Convergence Network Younghan Kim and Youngsuk Lee

contents Introduction.......................................................................................................... 157 Problem Statements............................................................................................. 159 Proposed Scheme................................................................................................. 160 IPFIX Header............................................................................................... 161 IPFIX Operation.......................................................................................... 161 Implementation and Demonstration Results................................................... 163 Implementation of IMS and DiffServ Core Network............................ 163 Demonstration and Experimental Results.............................................. 166 Conclusion............................................................................................................. 167 References............................................................................................................. 168

Introduction The cellular network and Internet have been the most successful networking paradigms during the last decades. The IP multimedia subsystem (IMS) [1] is one of the major efforts to combine the two networks. The cellular network, on one hand, allows users to have the capability of ubiquitous connectivity owing to the wireless and mobile manner. In the Internet, on the other hand, there already exist immense and useful services or applications that pervade the daily lives of huge numbers of users and are growing quickly as time goes by. In particular, multimedia services accelerate such phenomena. In both networks, therefore, supporting quality of service (QoS) is the key requirement of both user and service provider. There are several limitations to supporting QoS for multimedia services. These include difficulties in controlling (or reserving) resources from a source to a destination, designing acceptable QoS provisioning, identifying

157

158


reserved sessions (or classes), and others. To solve the limitations, the IMS has been designed by the 3rd Generation Partnership Project (3GPP) and European Telecommunications Standards Institute (ETSI) Telecoms and Internet Converged Services and Protocols for Advanced Networks (TISPAN) as a service platform [2]. In the IMS, multimedia sessions are handled by a set of network elements that were originally designed to support IP multimedia services in the universal mobile telecommunication system (UMTS) wireless network [3]. However, the current version of the standard (i.e., release 7) extends the capability to support multimedia services for both wired and wireless networks. In particular, the next-generation network (NGN) has adopted the IMS as the core function for session control. Two key elements of the IMS considered in this chapter are SIP (session initiation protocol) [4] and PDP (packet data protocol) [5]. SIP establishes a session and PDP is used for resource reservation to support QoS after the decision of the required resource is done by the PDF (policy decision function). Hence, a user of multimedia service necessarily resides in a UMTS network and the two protocols are required. However, to meet with future demands of the NGN, it is highly recommended that the IMS be capable of interoperability between heterogeneous access networks. That is, functionalities to support QoS should consider not only the the UMTS wireless network but also various wired and wireless networks. We suppose a simple scenario in which user equipment (UE) in UMTS tends to establish a session-required QoS support to a corresponding entity located in the conventional Internet. In this case, the UE in the UMTS is able to reserve network resources between SGSN (serving GPRS [general packet radio service] support node) and GGSN (gateway GPRS support node) that are enough to guarantee QoS requirements. However, the corresponding entity has no way to reserve any resource. As a result, the multimedia session can satisfy its QoS requirements partially (i.e., within the UMTS network). We note here that the current Internet is mostly regarded as a best-effort network even though several QoS models, such as IntServ and DiffServ, already exist. In this chapter, we discuss how to support QoS in an IMS-based convergence network. As an efficient solution, we propose a QoS control scheme called IPFIX, (class fixing in CP option header), which supports functionalities to identify the QoS user and to reserve network resources. IPFIX aims especially to satisfy the need of interoperability between a QoS-enabled UMTS network and a conventional Internet for the NGN. The scheme is much more efficient than commonly used schemes such as resource reservation protocol (RSVP) or PDP necessary to support QoS in UMTS. This is mainly due to the fact that IPFIX only utilizes the option field of the IP header in the absence of resource reservation protocol. As a result, IPFIX can reduce the number of processing steps in establishing a session, resulting in short call setup time.

159

Policy-Based QoS Control for a Convergence Network

Problem Statements Figure 7.1 illustrates a network model where we consider three different scenarios based on the capability to support QoS of the networks to which communication entities (i.e., A, B, C, and D) belong. We present a straightforward mechanism for each of the scenarios. Scenario 1: UMTS user A to UMTS user B. This scenario shows the case of utilizing functionalities of IMS to guarantee QoS for a session established between A and B. Both A and B are controlled by the policy decision function (PDF) specified by 3GPP because both UEs reside at the UMTS network, where we assume that the two communication peers are compatible with the functionalities specified by 3GPP. As a result, resources are properly reserved by the PDF and use PDP for the link control; thus, a multimedia session can be served well. Scenario 2: UMTS user A to IntServ user C. UE A is able to reserve network resources as discussed in scenario 1. Also, user C in the IntServ-enabled network can reserve resources by using RSVP [6]. Like scenario 1, a QoS session can be established under the requirement that there should be an edge router for interconnecting between the IntServ network and DiffServ core network [7].

HSS Diameter

IMS

S-CSCF

I-CSCF SIP P-CSCF

A

COPS Go

Gm

PDF

PDF

MGCF H.248

DSLAM

P-CSCF

Gm

COPS Go PEP

D

Remote Host

Internet

IMS MGW PEP PEP

UE SGSN

GGSN

UTRAN

B UE

Figure 7.1 Network model.

DiffServ Core

Edge Router

PEP

Edge Router

IntServ

WLAN Remote Host

C Remote Host

160


Scenario 3: UMTS user A to conventional Internet user D. In the case of the UMTS user A, the way to reserve resources is the same as in scenarios 1 and 2. The problem is for user D because he or she resides at the conventional Internet, where a resource reservation mechanism such as PDP or RSVP is not available. Thus, a session required for a specified QoS requirement cannot be established. In the following, we consider such an asymmetric QoS architecture (i.e., the third scenario). It is a highly difficult challenge in the Internet to support QoS as UMTS does, even though the user device is equipped with either RSVP or PDP. Therefore, we must focus on IMS user identification for resource reservation in a DiffServ core network rather than finding a network-wide solution. That is because the packets are marked and handled as a BE (best effort) class if there is no mechanism for preperformed user authorization or no way to identify the packet once the packet arrives at the DiffServ core network handled by the IMS. QoS requirements of packets cannot be guaranteed even in the UMTS network. Now we present the conceptual solution to the problem. The first solution is to use PDP for resource reservation. PDP is a straightforward solution for supporting user identification and interworking with the DiffServ core network. To do this, it is required to implement PDP on the device of user D residing in the conventional Internet. The second solution is to use RSVP for resource reservation. This way is similar to the first solution. The major limitation of the second solution is the requirement of implementation of RSVP on the device of user D. In addition to having RSVP, D is also required to be equipped with SIP for session control. The third solution is to use the extension of SIP described in Mehdi [8] for support of end-to-end QoS. The advantage of this solution over the previous solutions is that an additional reservation protocol such as PDP or RSVP is not necessary. Instead, L-PDF, which is used for resource control in an access network, and local policy decision function (L-Proxy), which is used for identification of QoS requester and resource reservation, are required. This solution also requires implementation of the SIP extension on the user D. As we described before, all solutions are required for complex implementation to reserve network resources. In particular, both PDP and RSVP were not originally designed for a user in the conventional Internet, but rather specified for UMTS and IntServ networks, respectively. It seems to be a better idea to use the third solution (i.e., using an extension of SIP) than the first or second solution. However, a limitation of installing additional network components, such as L-PDF and L-Proxy, still exists.

Proposed Scheme In this section, we propose the IPFIX scheme as an efficient resource reservation mechanism that allows a conventional Internet user to establish a


161

QoS-enabled session over a DiffServ core network. Moreover, as mentioned in the previous section, IPFIX does not require complex implementation for resource reservation of the Internet user. Instead, it uses the option field of IP header to exchange QoS information necessary for resource reservation. IPFIX Header The IP option header for IPFIX consists of four fields: Type, call admission control (CAC), DiffServ class, and Authorization token fields. The syntax and semantics of the fields are as follows: Type (1 bit): This field allows UE to distinguish whether the message received is a QoS request or response. If this field is set to one, it is used for a request of resource reservation. Otherwise, the message is used as a response to the QoS request. CAC (1 bit): This field indicates whether or not the QoS request is accepted. If the field is set to one, the QoS requirements of UE are accepted. DiffServ class (3 bits): UE records differentiated class information in this field according to the investigating results of parameters contained in session description protocol (SDP) extensions. Four different classes are specified by 3GPP. Authorization token (variable bits in size): This field contains the media authorization token. Contents of the field are directly mapped to the P-media-authorization header information in SIP. Hence, only a request message for resource reservation uses this field (i.e., it is not for response messages). IPFIX Operation Figure 7.2 shows a session setup procedure in the case of using IPFIX. UE1 sends an INVITE request message containing an initial SDP to the proxy call session control function (P-CSCF). Upon receiving the INVITE request, UE2 sends the 183 (session progress) response message back to UE1 via the P-CSCF with the accepted SDP. The UE1 receiving the 183 session progress message sends a PRACK (provisional response acknowledgment) request. At the same time, the UE1 sends an active PDP context message to the GGSN via SGSN. The UE1 associates the PDP context to the session by including the media authorization token information and the flow identifier information. Upon receiving the PRACK [9] request, the UE2 selects a class identifier according to parameters in SDP extensions, and UE2 sends the 200 OK response back to UE1, recoding the media authorization token and selected class information in the option field of the IP header. Upon receiving the 200 OK response message containing the option field of IP header, the edge router generates a common open policy service (COPS) request message according to the information that contains the media authorization token, type of QoS class, and source IP address and then sends it to

162


UE1

GGSN Invite(Initial SDP Offer)

P-CSCF PDF

S-SCSF

DiffServ Edge

P-CSCF PDF

Invite(Initial SDP Offer) Service Control Invite(Initial SDP Offer)

183 Session Progress


Invite(Initial SDP Offer) 183 Session Progress

Authorize QoS Resources 183 Session Progress PRACK PRACK Active PDP Req

PRACK

COPS Req

Authorize QoS Resources

COPS DEC Policy Enforcement Active PDP Acc

PRACK

COPS RPT

200OK 200OK

200OK

COPS Req

UPDATE

200OK

180 Ringing PRACK

180 Ringing

UPDATE

200OK 180 Ringing

COPS RPT UPDATE

200OK 180 Ringing

PRACK PRACK

PRACK 200OK

200OK 200OK 200OK ACK

ACK

Figure 7.2 Procedure of end-to-end call setup.

IP TOS : 110xxx Marking

COPS DEC Policy Enforcement

UPDATE

200OK

200OK

ACK

ACK

IP TOS : 101xxx Marking

UE2


163

the PDF. Thereafter, the edge router operates policy enforcement procedures. If the DiffServ edge route receives an IP packet (UPDATE [10]) destined for UE2, the edge route forwards the packet to UE2 after setting the CAC field of option field of the packet to one. UE2 decodes the option field of the IP header to investigate whether or not the request has been accepted. Then, UE2 sends a 200 OK message back to UE1 as a response to the UPDATE message. The last steps are followed by the IMS standard. Resource release procedures are triggered by a BYE message generated by UE2. Call setup is finally released by receiving a 200OK message as a response to the BYE message. To release resources in the Diffserv core network, the P-CSCF sends a COPS DEC message to the DiffServ edge router. IPFIX is essentially intended to support QoS for a user residing in the conventional Internet. It can be done by sending the media authorization information to the DiffServ edge router during the session setup phase. As we described earlier, IPFIX does not force a user in the Internet to be equipped with any resource reservation protocol, such as PDP or RSVP; instead, it uses the option field of the IP header. Consequently, IPFIX is more efficient than PDP or RSVP in terms of control overhead and time it takes to perform call setup.

Implementation and Demonstration Results Implementation of IMS and DiffServ Core Network We have developed the IMS on Linux computers. Further, to demonstrate the IMS, we have implemented the P-CSCF, serving call session control function (S-CSCF), DiffServ edge router (support IPFIX and PDP context), UE (support IPFIX), PDF, and PEP (policy enforcement point). The P-CSCF and S-CSCF have been implemented by modifying the source code of the SIP express router, which was developed by IPTEL [11] (not using FOKUS). • P-CSCF has been developed on laptop computers running on Linux kernel version 2.6.3 (Red Hat Linux Fedora Core 1). P-CSCF provides SIGCOMP (signaling compression), policy-based PDF, and functionalities to support the P-media-authorization header and P-extension header. • S-CSCF has also been developed on a laptop computer. S-CSCF operates as a service broker and includes functions for the IMS procedure, home subscriber service (HSS) database, and authentication and key agreement (AKA)-MD5v1. • The DiffServ edge router has been implemented by modifying modules in the Linux kernel, of which version was 2.4.20-8 provided by the Red Hat Linux version 9.0. The DiffServ edge router supports traffic control, differentiated service code point (DSCP) field marking, worst-case fair weighted queueing (WF2Q) scheduling, multifield classifying, and the policy-based PEP function.

164

IP Multimedia Subsystem (IMS) Handbook IMS Phone(UE)

P-CSCF

S-CSCF

Event Handler

Event Handler

Event Handler

Transaction Manager

Transaction Manager

Transaction Manager

IMS Module

IMS Module

IMS Module SIP Parser

PDP/IPFIX Module

VIO Module CODEC Module

SIP Parser

DiffServ Edge Router/PEP

SIP Parser

Service Broker

DiffServ Core Router

PEP Module

PDP/IPFIX Module

PDF Module

Traffic Control

Traffic Control

Management

MultiField Classifier

Traffic Conditioner

DSCP Marker/Scheduler

Management

SingleField Classifier

Scheduler

Figure 7.3 Module diagram of implementation.

• We have implemented an application for Windows XP systems called softphone that performs IPFIX UE. The UE is able to support the Pextension header, PRACK method, and UPDATE method. Also, it supports IPFIX and PDP context for resource reservation. Figure 7.3 shows generic diagrams of the implementation for both IMS and DiffServ core networks. Functional flow of the IMS signaling processing is shown in Figure 7.4. A callee sends the 183 (session progress) response message back to a caller via the P-CSCF2 with the accepted SDP. Upon receiving the 183 response, the P-CSCF2 executes a function of SIP parsing. Then the P-CSCF2 sends a DIAMETER request-based SDP parsing message and creates the policy rule. PDP creates an authorization token after DIAMETER parsing, and it sends the DIAMETER response to the P-CSCF2 with an authorization token. The P-CSCF2 stores the authorization token with user information (QoS profile), and the P-CSCF2 sends the 183 response to the S-CSCF. The S-CSCF sends the 183 response to the P-CSCF1. Upon receiving the 183 response, the P-CSCF1 executes the same process as P-CSCF1. However, the P-CSCF1 does not store the authorization token. Instead, the P-CSCF1 adds an authorization token at P-media-authorization, and then it sends the 183 session response to the UE. The UE receiving the 183 response sends a PRACK request. At the same time, the UE sends an active PDP context.

Figure 7.4 Process of IMS.

PDP Context/ IPFIX

PRACK Request

SIP Parsing

UE(Caller)

DB Access

PDP Context/ IPFIX

Filter Parsing

COPS Parsing

COPS Decision

Authorization Token & Session

GGSN/ Diffserv Edge Router

Setup Filter

COPS Request

COPS Parsing

Create Authorized Token

Filter Setup

S-CSCF

Diameter Parsing

Diameter Response

PDF

SIP Routing

Diameter Request

Diameter Parsing

PDF

Filter Setup

Diameter Response

Diameter Parsing

Setup Token

Service Trigger

Setup Token

SIP Parsing

SIP Routing

SDP Parsing

SIP Parsing

SIP Routing

Create Policy Rule

Create Authorized Token

Diameter Parsing

Diameter Request

Create Policy Rule

SIP Parsing

SDP Parsing

P-CSCF2

SDP Negotiation

SIP Response

UE(Callee)


P-CSCF1

Policy-Based QoS Control for a Convergence Network 165

166

IP Multimedia Subsystem (IMS) Handbook Internet

IMS/DiffServ

WCDMA

S-CSCF

P-CSCF

P-CSCF Congestion

SIP Hub

SIP

100M

10M

IPFIX Mechanism

SIP

100M DiffServ Core

DiffServ Edge

Go (COPS)

UE Go (COPS)

UE

SIP 100M

GGSN

Hub PDP Context

BG

BG Monitor

Monitor

-QoS Marking -Traffic Control -COPS Client

-SIP Proxy -QoS Authorization -COPS Server

-PHP -Priority Queuing

-Registrar -Priority Based Call Routing

Figure 7.5 Testbed architecture.

message with an authorization token to the GGSN. Upon receiving the active PDP context message, the GGSN sets up a filter based on the QoS profile, and it sends the COPS request message with authorization token, class of service, and flow ID. The PDF receives the COPS request message and compares the authorization token in the COPS request message with those in the saved authorization token. If the two authorization tokens are the same, PDF sends the COPS decision message to the GGSN with the accepted class of service. Demonstration and Experimental Results Figure 7.5 shows a simplified architecture of our testbed to demonstrate IPFIX. In the demonstration, we use the following scenario: • The UE in the conventional Internet tends to use multimedia streaming service. • Congestion is occurring at the DiffServ edge router (we have used background traffic for generating the congestion). • UE in Internet starts the procedure of the SIP session setup by using IMS. • During the procedure of the SIP session setup, UE utilizes IPFIX for resource reservation. • After the session setup procedures are followed by the IMS standard, the DiffServ edge router is able to provide differentiated QoS class with UE (see the results denoted by “Streaming A” and “Streaming B” in Figure 7.6).

167


ip/other 5000/udp 5001/udp 10000/udp (Streaming A) 10006/udp (Streaming B) icmp/ip

Traffic (Mbps)

8 6

Session Establishment by IMS

4 2 0 1780

1800

1820 Time (sec)

1840

1860

Figure 7.6 Demonstration result by using IPFIX.

We have evaluated the IPFIX module and the DiffServ core module. A demonstration result is given in Figure 7.6. In this figure, 5000/UDP (user datagram protocol) indicates background traffic that brings on congestion at the edge router; 10000/UDP and 10006/UDP indicate the streaming A and B, respectively. As shown in the graph (top of Figure 7.6), both streamings are handled as a BE class before the IMS session is established. However, the streaming A gets more bandwidth than the streaming B after 1,830 seconds, when we launched IMS software, so the quality of the streaming A is better than that of the streaming B (bottom of Figure 7.6).

Conclusion In this chapter, we have proposed IPFIX, which provides an efficient way to reserve network resources. The main advantage of the scheme is that it does

168


not require users the in Internet to be equipped with any resource reservation protocol such as PDP or RSVP. Consequently, we can avoid complex implementation to support QoS and reduce control overhead and the time it takes to perform call setup. In IPFIX, such procedures can be performed by recording the minimum information of QoS in the option field of the IP header. Our implementation result shows that IPFIX can support differentiated services well in a converged network scenario.

References

1. 3GPP TS 23.228, IP multimedia subsystem (IMS), December 2006. 2. 3GPP TS 23.002, Network architecture, March 2006. 3. 3GPP TS 23.221, Architecture requirements, March 2006. 4. Rosenberg, J. et al. 2002. SIP: Session initiation protocol, IETF RFC 3621. 5. 3GPP TS 29.060, General packet radio service (GPRS); GPRS tunneling protocol (GTP) across the Gn and Gp interface, December 2006. 6. Braden, R., L. Zhang, S. Berson, and S. Jamin. 1997. Resource reSerVation Protocol (RSVP), IETF RFC 2205. 7. Eunsook, K., and S.-G. Kang. 2004. QoS support based on IntServ/DiffServ for SIP-based applications. NOMS 2004, IEEE/IFIP, 131–144. 8. Mehdi, M. 2005. New QoS control mechanism based on extension to SIP for access to UMTS core network via different kinds of access networks. WiMob 2005, IEEE International Conference, 150–157, August. 9. Rosenberg, J. et al. 2002. Reliability of provisional responses in the session initiation protocol (SIP), IETF RFC 3262. 10. Rosenberg, J. et al. 2002. The session initiation protocol (SIP) UPDATE method, IETF RFC 3311. 11. The IPtel Web site. http://www.iptel.org/

8 OSA Service Capability Server—Parlay/Parlay X Moo Wan Kim and Ryozo Ito

contents Introduction.......................................................................................................... 170 OSA (Open Service Access)................................................................................ 171 Configuration of Open Service Access.................................................... 171 Basic Mechanisms in the OSA.................................................................. 171 Framework................................................................................................... 173 SCFs ....................................................................................................................... 174 Parlay X Web Service........................................................................................... 176 Third-Party Call.......................................................................................... 177 Network-Initiated Third-Party Call......................................................... 178 SMS............................................................................................................... 178 Multimedia Message.................................................................................. 178 Payment........................................................................................................ 179 Account Management................................................................................ 179 Terminal Status........................................................................................... 180 Terminal Location....................................................................................... 180 Audio Call.................................................................................................... 180 Call Handling.............................................................................................. 181 Multimedia Conferencing......................................................................... 181 Address List Management......................................................................... 181 Presence........................................................................................................ 182 Message Broadcast...................................................................................... 182 Geocoding.................................................................................................... 182 Web Service........................................................................................................... 183 WSDL ........................................................................................................... 183 SOAP ........................................................................................................... 187 References............................................................................................................. 189

169

170


Introduction In order to implement applications efficiently, the 3GPP (3rd Generation Partnership Project) has standardized OSA (open service access) as a flexible framework so that application developers would be able to implement various applications by making use of network functionalities in the CS (circuit switch), PS (packet switch), and IMS domains. Application developers could access network functionalities through the standardized OSA API (application programming interface) offered by the SCS (service capability server) (Figure 8.1). The 3GPP has standardized the Parlay API as the OSA API, which is based on the common object request broker architecture (CORBA). The Parlay API is independent of vendor-specific solutions, programming languages, and operating systems. The 3GPP has also standardized the Parlay X API. the Parlay X API is offered by the Web service gateway, which enables application developers to interact with network functionalities without detailed telecommunication knowledge. The Parlay X Web services gateway interfaces with the OSA service capability server through an OSA API. The applications can invoke a Parlay X Web service using a SOAP (simple object access protocol) request and response.

Application Server Parlay X API OSA Application Server

Web Service Gateway OSA API

OSA Service Capability Server

CS Domain Figure 8.1 OSA service capability server.

PS Domain

IMS Domain

OSA Service Capability Server—Parlay/Parlay X

171

OSA (Open Service Access) The OSA provides application developers with a flexible framework that enables them to develop new applications and to enhance the existing applications by making use of network functionalities. The SCF (service capability feature) in the SCS provides the functionality of network capabilities that is accessible to applications through the standardized OSA APIs. Configuration of Open Service Access The OSA consists of a framework and SCS. Authentication, registration, and discovery are examples of framework functions. Applications can access the SCF after the SCF has been registered in the framework. The authentication between the application and framework is necessary when an application is required to use the SCF. After the authentication is completed, the application can find out by the discovery function in the framework which SCFs are available and can access the SCFs via the methods defined in the OSA APIs (Figure 8.2). Examples of SCFs offered by the SCS are call control, user location, multimedia messaging, and charging. The SCSs that provide the OSA interfaces are functional entities that can be distributed across one or more physical nodes. For example, the user location and call control interfaces might be implemented on a single physical entity or distributed across different physical entities. Furthermore, the SCSs can be implemented on the same physical node as a network functional entity or in separate physical nodes. The SCS hides detailed implementation information and provides the application developer with a kind of abstract service of network. Thus, application developers can create the network service applications without detailed, specific knowledge about telecommunication networks (Figure 8.3). Basic Mechanisms in the OSA Basic mechanisms are executed in the OSA prior to offering and activating applications as follows:

1. Mechanisms between application and framework: • Authentication. Once an offline service agreement has been reached, the application can access the authentication function. The authentication model of OSA is a peer-to-peer model. The application must authenticate the framework and vice versa. The application must be authenticated before it is allowed to use any other OSA functions.

172

IP Multimedia Subsystem (IMS) Handbook Application Server Application

OSA-API Open Service Access

Framework

Service Capability Server

HSS

S-CSCF

…

Location

Figure 8.2 Configuration of OSA.

• Authorization. Authorization is the action of determining what a previously authenticated application is allowed to do. Once authenticated, an application is authorized to access certain SCFs. • Discovery. After successful authentication, the applications can obtain available framework functions and use the discovery function to obtain information on authorized SCFs. • Service agreement. Before any application can interact with an SCF, a service agreement must be established. A service agreement may consist of an offline and an online part. • Access control. The framework provides access control functions to authorize the API access from an application to SCFs with the specified security level.

2. Mechanism between framework and SCS: • Registration. SCFs offered by an SCS can be registered at the framework. After registration, the framework can inform the applications upon request about available SCFs. This mechanism is applied when installing or upgrading an SCS. A de-registered SCF is not available for an application.

3. Mechanisms between application server and SCS: • Request of event notification. This is applied when a user has subscribed to an application and that application needs to be invoked upon receipt of events from the network related to the user. For example, when a user subscribes to an incoming call

173

OSA Service Capability Server—Parlay/Parlay X OSA-API OSA-Gateway

SCS

HSS

SMS

…

Single SCS Configuration OSA-API SCS

HSS

SCS

SMS

SCS

OSA-Gateway

…

Distributed SCS Configuration OSA-API SCS HSS

SCS SMS

SCS …

SCS in the Existing Network Node Figure 8.3 Methods to implement SCS.

screening application, the application needs to be invoked when the user receives a call. Framework Prior to the application use of SCSs, the application is accessible to the security management function using the OSA API provided by the framework. Mutual authentication takes place between the OSA application server and the framework. The OSA API supports multiple authentication techniques; this covers cryptographic processes to provide confidentiality and digital signatures to ensure integrity. In order to use OSA SCFs, the application is required to establish a service agreement with the network. The application uses the discovery SCF to retrieve the ID of the SCF. The service agreement is signed digitally between the operator and the service provider.

174


An application needs to know the available SCSs provided by the SCS in order to access the network functionalities. For this purpose, SCSs have to be registered with the framework.

SCFs SCFs are provided to the applications by SCSs to enable access to the network resources. The 3GPP defines the following 10 SCFs.

1. Call control SCF. The call control SCF provides an application with CS domain call control, IP (Internet protocol) multimedia subsystem (IMS) session control, and call/session charging. The call control SCF supports the following functionalities: • management function for call/session (e.g., enabling or disabling call/session-related event notifications); and • call/session control (e.g., route or disconnect call/session).

The OSA API is mapped to the CAMEL (customized applications for mobile network enhanced logic) application part (CAP) protocol to control the gsmSSF (see Chapter 10) or mobile application part (MAP) protocol to access home location register (HLR) functions in the CS domain. The OSA API is also mapped to the IMS service control (ISC) interface to control the serving call session control function (S-CSCF) and media resource function controller (MRFC) in the IMS domain:

2. Data session control SCF. The data session control SCF provides an application with the PS domain session control. The data session control SCF supports the following functionalities: • management functions for data session (e.g., enabling or disabling data session-related event notifications); and • session control (e.g., route or disconnect data session).

3. Mobility SCF. The mobility SCF provides terminal location information and general terminal status monitoring based on network-related information. The mobility SCF supports the following functionalities: • user location requests; • requests for starting or stopping the generation by the network of periodic user location reports; • requests for starting or stopping the generation by the network of user location reports based on location changes; • report of location information; and • notification of location update.


175

4. Terminal capability SCF. The terminal capability SCF provides application information about the terminal capabilities of the user. Only WAP and MExE devices can provide terminal capabilities in 3GPP release 5.

5. User interaction SCF. The user interaction SCF provides an application with user interaction to retrieve user information. It supports the following functionalities: • user interaction with IMS domain user; and • user interaction with CS domain user.

6. Charging SCF. This SCF provides an application to access subscriber accounts maintained by the network and charge subscribers for service usage. It supports the following functionalities: • checking that the charge is covered by the subscriber’s account or credit limit; • reserving a charge in the subscriber’s account, which can be deducted from the account after service delivery; • deducting an amount from the subscriber’s account; • releasing a reservation acquired earlier; • adding nonmonetary units to a subscriber’s account; and • deducting nonmonetary units from a subscriber’s account.

7. Account management SCF. The account management SCF provides an application with the features to monitor a subscriber’s account. It supports the following functionalities: • retrieval of transaction history for a certain subscriber’s account; • query of the balance of the account of one or several subscribers; and • request of notifications on certain criteria for one or several subscribers.

8. Presence SCF. The presence SCF provides an application with access to presence capabilities within the network. Presence information is a set of attributes characterizing current properties of a presentity (an entity described by presence information). The presence SCF supports the following functionalities: • registering as a watcher to request a presentity’s presence information and to be notified of changes in the presence information; and • registering as a presentity to publish presence information.

9. Multimedia messaging SCF. The multimedia messaging SCF provides an application with multimedia messaging. It interacts with the SMS-C, MMS-C, WAP PUSH, and E-Mail server for providing

176

IP Multimedia Subsystem (IMS) Handbook multimedia messaging. In the case of MMS-C, the multimedia messaging SCF maps an OSA API to the MM7 interface. The multimedia messaging SCF supports the following functionalities: • sending and receiving messages in both session-based and single-shot messaging; • putting messages in the mailbox for storage or for sending by the messaging system; • canceling a message previously sent or querying the status of a message previously sent; • manipulating folders and messages in the mailbox (e.g., copy, move, delete); and • listing messages in the mailbox and retrieving complete messages, message headers, message body, or parts of the message body.

10. Policy management SCF. The policy management SCF provides an application with policy management and evaluation mechanisms. It creates, deletes, updates, and views operator-specific policies, including: • publishing policy events; • subscribing to policy events; • generating events; • obtaining statistics associated with the use of policies; and • evaluating policies.

Parlay X Web Service The Parlay APIs are designed to develop telecom applications and also telcomenabled IT applications. Detailed telecommunication knowledge is required to develop telecom-enabled IT applications. The Parlay X Web services are intended to develop telecom-enabled IT applications by IT application developers without requiring such expertise. The applications can invoke Parlay X Web services using an XML-based message exchange protocol (i.e., SOAP). A typical Parlay X Web service architecture is illustrated in Figure 8.4. This architecture shows the publication of Parlay X Web services through a Web service registry, making those Web services available for discovery. The applications use the Parlay X Web services access methods to interact with the Web service gateway that accesses network functionalities using the OSA Parlay API. The following describes the Parlay X Web services supported by 3GPP.

177

OSA Service Capability Server—Parlay/Parlay X Application Server

Find

Application

Web Service Registry Web Service Definition

Parlay X Web Service Gateway Parlay X Web Service

Publish

OSA Parlay-API Open Service Access Framework

Network Interfaces

SCS

Element

Element

Element

Figure 8.4 Parlay X Web service architecture.

Third-Party Call The third-party call Web service supports the functionality to create and manage a call initiated by an application (third-party call). The functionality provided is: • “Make a call” sets up a call between two addresses (makeACall). • “Get call information” gives information about how the call progressed in the network (getCallInformation). • “End call” will stop the call (endCall). • “Cancel call” allows the network to prevent call setup before completion (cancelCall).

178


Network-Initiated Third-Party Call The network-initiated third-party call supports event notification and handling of calls initiated by a subscriber in the network. A third-party application can determine how the call should be treated. The Web services allow the application to handle the following conditions occurring in the setup of a call: • destination busy (handleBusy); • address is not reachable (handleNotReachable); • destination is not answering (handleNoAnswer); • a specific number has been called by subscriber (handleCalledNumber); and • event notification (NotifyBusy, NotifyNotReachable, NotifyNoAnswer, NotifyCalledNumber). SMS The SMS Web service supports SMS for sending and receiving SMS messages. For receiving an SMS message from the network, the application uses notification mechanisms. For sending a message to the network, the application invokes the API to send it and subsequently polls for delivery status. The following functions are supported: • sending any SMS (sendSms); • sending a logo embodied in an SMS (sendSmsLogo); • sending a ring tone embodied in an SMS (sendSmsRingtone); • retrieving the delivery status of an SMS (getSmsDeliveryStatus); • requesting to be notified of received SMSs (notifySmsReception); • requesting to be notified of delivery receipt of a sent SMS (notifySmsDeliveryReport); and • retrieving SMS messages sent to an address (getReceivedSms). Multimedia Message The multimedia message Web service provides generic messaging features to send and receive messages. For receiving a multimedia message from the network, the application uses notification mechanisms. For sending a message to the network, the application invokes the API to send it and subsequently polls for delivery status. The following functions are supported: • sending a message to an address (sendMessage); • retrieving the delivery status of a message (getMessageDeliveryStatus);


179

• retrieving by polling for received messages (getReceivedMessage); • retrieving message parts by uniform resource identifier (URI) references (getMessageURIs); • retrieving whole messages as SOAP attachments (getMessage); • requesting to be notified of delivery receipt of a sent message (notifyMessageReception); and • notifying the application that a message has been received for a specific address (NotifyMessageDeliveryReceipt). Payment The payment Web service supports payment reservation, prepaid payments, and postpaid payments. The Web service supports charging of both volume and currency amounts. The following functions are supported: • charging or refunding to an account by a currency amount (chargeAmount, refundAmount); • charging or refunding to an account by volume (chargeVolume, refundVolume); • calculating a currency amount from a volume (getAmount); • reserving a currency amount on an account (reserveAmount, reserveAdditionalAmount); • charging a prior reservation to the account (chargeReservation); • releasing a reservation by returning to an account the amount remaining in a reservation (releaseReservation); and • reserving a volume amount of an account (reserveVolume, reserveAdditionalVolume). Account Management The account management Web service supports account querying, direct recharging, and recharging through vouchers. The following functions are supported: • returning the currency balance on an account (getBalance); • requesting the date the credit on an account is due to expire (getCreditExpiryDate); • updating the account balance on an account (balanceUpdate, voucherUpdate); • returning the transaction history on an account (getHistory);

180


• discovering the set of all possible balance types (e.g., voice, SMS, gaming) that are permitted for a specified end user (getBalanceType); and • requesting to be notified of account status changes (acountCharged, accountRecharged, accountLow). Terminal Status The terminal status Web service is used for getting terminal status or a group of terminal status information. The following functions are supported: • requesting a subscriber’s terminal status (getStatus); • requesting a group of subscribers’ terminal status (getStatusForGroup); and • requesting to be notified of terminal status change (statusNotification). Terminal Location The terminal location Web service is used for getting location information to develop location-aware applications. Location is expressed through latitude, longitude, altitude, and accuracy. The use of the Web service requires only knowledge of longitude and latitude. The following functions are supported: • requesting the location of one terminal device (getLocation); • requesting the locations of a set of terminal devices (getLocationFor. Group); • requesting the distance of a terminal from a location (getLocation. Distance); • requesting to be notified of terminal location change (locationNotification); and • requesting to be notified of a terminal device location on a periodic basis (periodicNotification). Audio Call The Parlay X audio call Web Service provides multimedia message delivery. The text message will be rendered using text-to-speech (TTS). The audio content will be rendered by an audio player. The VoiceXML script will be rendered using a VoiceXML browser. The following functions are supported: • playing audio contents (playTextMessage, playAudioMessage, playVoiceXmlMessage, playVideoMessage); • retrieving status (getMessageStatus); and • ending the call (endMessage).


181

Call Handling The call handling Web service enables call handling rules to be provisioned, allowing third-party applications to specify how to handle calls without requiring the application to handle the calls. The following functions are supported: • provisioning rules for accepting, blocking, forwarding, and answering calls for an address (setRules); • provisioning rules for accepting, blocking, forwarding, and answering calls for a group of addresses (setRulesForGroup); • querying rules associated with an address (getRules); and • removing rules for an address or group of addresses (clearRules). Multimedia Conferencing The multimedia conferencing Web service provides the creation of a multimedia conference and the dynamic management of the participants and the media involved. The following functions are supported: • creating a conference (createConference); • querying the conference status or participants (getConferenceInfo); • adding/deleting a participant (inviteParticipant, disconnect-Partici-. pant); • adding/deleting media for the participant (addMediaForParticipant, deleteMediaForParticipant); • querying the current status of the participant (getParticipantInfo); • querying the current status of each participant (getParticipants); and • ending the conference (endConference). Address List Management When a service has a requirement to support groups of address lists, the address list management Web service provides the dynamic management of groups and group members. A group URI contains a set of member URIs (list of URIs). The following two functions are supported: • managing groups (createGroup, deleteGroup, queryGroups, setAccess, and queryAccess); and • managing group members (addMember, addMembers, deleteMember, deleteMembers, queryMembers).

182


Presence The presence Web service allows for presence information to be obtained about one or more users. The service supports three interfaces: a watcher interface for requesting and subscribing presence data, a watcher notification interface in order to receive presence events, and a presentity interface for supplying presence data and managing subscriptions: • requests used by the watcher to obtain presence data—the watcher can select between a polling mode and a notification mode to receive the presence data; • requests to receive presence notifications; and • requests used by the presentity to supply presence data. Message Broadcast The message broadcast Web service allows for a text-based message to be broadcast to a designated area. The following functions are supported: • broadcasting a message to a designated area with frequency and interval; • retrieving the delivery status of a previous broadcast request; • canceling the previous broadcast request; and • requesting to be notified when the delivery has been completed or is impossible. Geocoding The geocoding Web service supports the functionality to access an additional level of the geographic coordinates, allowing the service developer to work with the location address. The following functions are supported: • requesting the location address of a terminal number (getAddress. OfTerminal); • requesting the location address of a group of terminals (getAddress-. OfTerminalForGroup); and • requesting the terminal numbers known to be at the specific location address (getTerminalsAtAddress).


183

Web Service The Web service is designed to support interoperable distributed service interaction using XML-based message exchange between clients and servers over networks. There are three core technologies: • SOAP: lightweight protocol for exchanging an XML-based message format; • WSDL (Web service description language): XML-based language for describing Web service interfaces; and • UDDI (universal description, discovery, and integration): publishing and discovering metadata of the Web service. WSDL The WSDL is an XML-based language that provides the capability to describe the Web service in a formal way by the sets of network ports, abstract operations, messages, and transport protocol in order to transfer messages. Main elements of the WSDL document described by WSDL are listed in Table 8.1. The following example shows the WSDL definition of the Parlay X Terminal location Web Service specified in 3GPP TS 29.199: parlayx _ terminal _ types _ 2 _ 2.xsd : parlayx _ terminal _ location _ 3 _ 0.wsdl


185

parlayx _ terminal _ service _ 3 _ 0.wsdl The following items explain the main items of the WSDL document described in the example:


187

1. Namespace declaration. The name of the Web service is defined by using the name attribute of WSDL. The URI of the WSDL document is indicated by the attribute of targetNamespace. The namespace declarations for the elements in the WSDL document are described as the specific syntax (e.g., xmlns: profix = “URL”) to be uniquely identified.

2. Type definition. The data type used in the messages should be defined. Any new data type can be defined by using the combination of the basic types (e.g., xsd:integer, xsd:datetime) defined in the XML schema, which can be found in the URL http://www. w3.org/2001/XMLSchema.

3. Message definition. The message is defined by using the data. The name of the message is indicated by the name attribute.

4. Operation definition. Operation in the WSDL means a kind of method in the Java programming language. A port type is defined as a set of operations available and the messages that will be used for each. For the request/response message pattern, a port will have an operation definition that contains a single input message, a single output message, and zero or more fault messages. WSDL has four transmission primitives that a port can support: • One-way: the port receives a message. • Request response: the port receives a message and sends a correlated message. • Solicited response: the port sends a message and receives a correlated message. • Notification: the port sends a message.

5. Protocol binding. The binding defines how the WSDL definitions are utilized in interacting with the network. The binding defines protocols and operational style—for example, SOAP over HTTP or SOAP over SMTP for protocols, and document or RPC (Remote Procedure Call) for style.

6. Service definition. Services define a port, though the address of the port specified in the definition is often replaced at runtime when the discovery step determines the actual location at which the service is hosted.

SOAP SOAP is a lightweight protocol for exchanging the request and response in the distributed environment. It is an XML-based protocol for transferring information between applications and Web services. SOAP consists of the protocol binding header, SOAP envelope, SOAP header, and SOAP body:

188


1. Protocol binding header. SOAP can be used with a variety of transport protocols (e.g., HTTP and SMTP). A protocol binding header is described based on the selected protocol to transfer the SOAP message. In the case of HTTP, the SOAP message is included in the body of the POST method. 2. SOAP envelope. The SOAP message consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. The envelope is the top element of the SOAP message and the element name is “envelope.” 3. SOAP header. The attributes included in the SOAP header are used to determine how a recipient of a SOAP message should process the message (e.g., authentication, transaction management, payment method). 4. SOAP body. The SOAP request and response message are expressed in this body. The request message includes the name of the operation and its parameters and includes the result of processing.

The following shows the example of SOAP request (i.e., getLocationRequest) and response (i.e., getLocationResponse) messages that are used for accessing the Parlay X terminal location Web service to retrieve the terminal location. SOAP getLocationRequest contains the terminal URI, requested accuracy (e.g., 25 m), acceptable accuracy (e.g, 300 m), and tolerance (NoDelay). SOAP getLocationResponse contains the location information of the terminal—that is, latitude, longitude, accuracy, and timestamp when this information has been obtained. getLocationRequest POST /TerminalLocationService/services/TerminalLocation HTTP/1.1 Host: localhost Content-Type: text/xml; charset=”utf-8” SOAPAction: “” Content-Length: nnnn SOAPAction: “” ” 0

Modify

Yes

Yes

>0

Remove

No

Yes

=0

firmed value to the PS user agent through a 200 OK message. Before the value of the Expires header field specified in the 200 OK message expires, the UA should retransmit a PUBLISH message to maintain the event state in the PS server. Otherwise, the event state will be deleted by the PS server after the lifetime is expired. The PUBLISH message for refreshing the event state must include a SIPIf-Match header field to specify which entity of the user should be updated. To save the network resource, the PUBLISH message for refreshing may contain an Expires header field, but it does not contain the message body. Like refreshing, the PUBLISH message for modifying the event state contains a SIP-If-Match header field. Unlike refreshing, this PUBLISH message includes the message body to update the event state. Before the user logs out of the presence service, the PS user agent should send a PUBLISH message with the SIP-If-Match and the Expires header fields to remove the event state. In this message, the value of the Expires header field is 0, indicating that the event state should be removed. Similar to the PUBLISH message for refreshing, this PUBLISH does not include a message body. Upon receipt of a PUBLISH message, the PS server replies with a 200 OK message to the UA. The 200 OK message contains the Expires header field to confirm the lifetime of the event state and a SIP-Etag header field. The PIDF format defined in RFC 3863 [13] includes basic status (i.e., open and closed) of a user. To provide extended status, the IETF SIMPLE working group defines other extended formats such as “rich presence extensions to the presence information data format” and “contact information for the presence information data format.” Readers can refer to RFC 4480 [12] and RFC 4482 [11] for more information. A PIDF example is given in Figure 15.3. The first line specifies that the format is based on XML (extensible markup language) version 1.0 and encoding scheme id UTF (UCS/unicode transformation format)-8. The element contains a namespace declaration (i.e., xmlns) to indicate the namespace on which the presence message body is based. For the presence document compliant to RFC 3863 [13], the namespace is “urn:ietf:params:xml:ns:pidf.” A presence tuple is carried by the element that consists of a mandatory element and one or more optional elements. In the example shown in Figure 15.3, the element is followed by an optional element, an optional element, and an optional element. The root of an “applica-

350

IP Multimedia Subsystem (IMS) Handbook 01 02 03 04 05

open

06

07

tel:+09012345678

08

Don’t Disturb Please!

09

2007-10-27T16:49:29Z

10

11 Figure 15.3 An example of the PIDF format.

tion/pidf+xml” object is a element (line 02) associated with the presence information namespace. The element must include an entity attribute. This attribute identifies the URL (universal resource locator) of the presentity that publishes this message. The element contains a unique identifier (i.e., the id attribute) to distinguish different elements in the same element. The element is a child element of the element. Within the element, a element contains the string “open,” which means that the presentity is available for receiving instant messages. On the other hand, if the string is closed, the presentity may not receive an instant message. The element contains a URL of the presentity’s contact address. The element has a priority attribute that represents a relative priority of this contact address. The value of the priority attribute is between 0 and 1, and the larger value represents the higher priority. The element provides the human readable comments identified by an attribute xml:lang. In this example, the value of xml:lang attribute is “en,” which means the comment is presented in English. The element contains the date and time when the state of this tuple is changed. The value of this element follows the date–time format defined in RFC 3339 [18]. In this example, 2007-10-27T16:49:29Z represents 49 minutes and 29 seconds after the 16th hour of October 27, 2007, in UTC (Pacific Standard Time). SIP SUBSCRIBE and NOTIFY messages are used to subscribe to and notify the state of the event packages between the users and the PS server. The PS server can be a stateless server or a stateful server. The stateless server does not store the users’ event states. Thus, every SUBSCRIBE message is directly

Instant Messaging and Presence Service (IMPS)

351

forwarded to the recipient PS UA. On the other hand, the stateful PS server caches the event states for users. The PS server will retrieve the states from its database and reply with NOTIFY messages if the states are found and not expired. In this chapter, we utilize the stateful PS server, for example. When a user attempts to subscribe to an event, the user’s PS UA sends a SUBSCRIBE message with Event and Expires header fields. The Event header field specifies the event state to which the user wants to subscribe. The Expires header field specifies the duration of subscription. After the PS server receives this message, it decides to accept this subscription or not. Then the PS server replies with a NOTIFY message with the SubscriptionState header field to inform the PS UA about the subscription results. Note that the admission of subscription is carried in the NOTIFY message instead of in a 200 OK message. The value of the Subscription-State header field can be active, pending, or terminated. The value “active” means the subscription is successful and the presence information (i.e., event state) is carried in the same NOTIFY message. The value “pending” represents that the subscription is still waiting for the user’s decision. The value “terminated” means the subscription is rejected and the reason for the rejection is also carried in the NOTIFY message. For example, value “noresource” in the event-reason-value parameter means the subscribed event does not exist. The subscription lifetime is confirmed by the PS server by using a 200 OK message with the Expires header field. The server can decrease or accept the lifetime value suggested by the PS UA sending the SUBSCRIBE message. Before the duration of the subscription (specified in the Expires header field) expires, the PS UA should retransmit a SUBSCRIBE message to refresh the subscription. The subscriber can cancel the subscription by sending a SUBSCRIBE message with the value 0 in the Expires header field. The subscribed PS UA (i.e., the presentity) can terminate the subscription by sending a NOTIFY message with the value “terminated” in the Subscription-State header field. Figure 15.4 demonstrates the message flows for presence service. In this example, the SIP URIs and domain names are the same as those in Figure 15.1. In addition, the SIP server is capable of the functions of a PS server. Assume that UA1 allows UA2 to subscribe to its event states. In this example, UA1 is offline and UA2 attempts to subscribe to the event state of UA1. The detailed procedures are described as follows: Step 1. UA2 sends a SUBSCRIBE message to obtain UA1’s state. Based on the Request-URI (i.e., [email protected]), this message is sent to the SIP server (i.e., the PS server). Upon receipt of the SUBSCRIBE message, the server replies with a 200 OK message to UA2 to indicate that the SUBSCRIBE message has been received successfully. Step 2. Because UA1 allows UA2 to subscribe to its event states, the server sends a NOTIFY message with UA1’s state (i.e., closed, which means offline) to UA2. Upon receipt of the NOTIFY message, UA2 replies with a 200 OK to the SIP server.

352

IP Multimedia Subsystem (IMS) Handbook UA1

SIP Server

UA2

1. SUBSCRIBE 1. 200 OK 2. NOTIFY 2. 200 OK 3. PUBLISH 3. 200 OK 4. NOTIFY 4. 200 OK 5. PUBLISH 5. 200 OK 6. PUBLISH 6. 200 OK

7. NOTIFY 7. 200 OK

Figure 15.4 An example of the message flow of presence service.

Step 3. UA1 logs in to the presence service and sends a PUBLISH message to change its state from closed (i.e., offline) to open (i.e., online). The SIP server replies with a 200 OK to acknowledge the receipt of the PUBLISH message. Step 4. The SIP server detects that the state of UA1 is changed and informs UA2 by sending a NOTIFY message. Upon receipt of the NOTIFY message, UA2 replies with a 200 OK message. Step 5. Assuming that the lifetime of publication is about to expire, UA1 sends a PUBLISH message to refresh its state. Note that this PUBLISH message does not include a message body. Upon receipt of the PUBLISH message, the SIP server replies with a 200 OK message to UA1. Because UA1’s event state is not changed, the SIP server does not notify UA2. Steps 6 and 7. UA1 logs out the presence service and sends a PUBLISH message with the value 0 in the Expires header field to the SIP server. The SIP server removes UA1’s event state, replies with a 200 OK message to UA1, and sends a NOTIFY message to UA2 to update the state from open to closed. UA2 then replies with a 200 OK to the PS server. Several examples for the messages mentioned in the preceding steps are described next.


353

01 SUBSCRIBE sip:[email protected] SIP/2.0 02 Via: SIP/2.0/TCP user2pc.domain.com;branch=z9hG4bKnashds7 03 To: 04 From: ;tag=12341234 05 Call-ID: [email protected] 06 Cseq: 1 SUBSCRIBE 07 Max-Forwards: 70 08 Expires: 3600 09 Event: presence 10 Contact: sip:[email protected] 11 Content-Length: 0

Figure 15.5 An example of the SUBSCRIBE message.

Figure 15.5 demonstrates the SUBSCRIBE message delivered in step 1 of Figure 15.4. In the start line, the Request-URI header field specifies the URI of the subscribed user agent (i.e., UA1). The Via header field records the domain name of UA2, which is used to forward the response message (e.g., 200 OK message). The To, From, and Call-ID header fields are used to identify the dialog. The CSeq header field indicates the message is SUBSCRIBE and sequence number is 1. The Max-Forwards header field (i.e., 70) limits the maximum hops in the forwarding path. The Expires header field indicates the duration (i.e., 3,600 seconds) of the subscription suggested by UA2. The Event header field identifies that the subscribed event state is the presence of UA1. The Contact header field contains the domain name of UA2. Because this SUBSCRIBE message does not contain any message body, the value of the Content-Length header field is 0. Figure 15.6 illustrates the NOTIFY message sent from the SIP server to UA2. The SIP server utilizes this message to notify UA2 of the subscription results. The Request-URI header field specifies that this NOTIFY message is sent to UA2. The Via header field is the domain name of the SIP server. The To and From header fields are UA2 and UA1, respectively. The Call-ID header field records the identifier of the SIP transaction. Note that the Call-ID header field (i.e., [email protected]) and the tag (i.e., 12341234) of the To header field in the NOTIFY message should match the Call-ID and the tag

354

IP Multimedia Subsystem (IMS) Handbook 01 NOTIFY sip:[email protected] SIP/2.0 02 Via: SIP/2.0/TCP domain.com;branch=z9hG4bK8sdf2 03 To: ;tag=12341234 04 From: ;tag=abcd1234 05 Call-ID: [email protected] 06 Cseq: 1 NOTIFY 07 Max-Forwards: 70 08 Event: presence 09 Subscription-State: active; expires=3599 10 Contact: sip: domain.com 11 Content-Type: application/pidf+xml 12 Content-Length: … 13 [PIDF document]

Figure 15.6 An example of the NOTIFY message.

of the From header field in the SUBSCRIBE message, which means these two messages are in the same dialog. The CSeq header field indicates the message is NOTIFY and the sequence number is 1. The Max-Forwards header field (i.e., 70) limits the maximum hops in the forwarding path. The Event header field identifies that the notified event state is UA1’s presence information. The Subscription-State header field indicates that the subscription is “active” and will expire after 3,599 seconds. The Contact header field is the domain name of the SIP server. The Content-Type header field specifies that the format of the message body is using PIDF, and the Content-Length header field presents the number of total characters in the message body. Figure 15.7 illustrates the PUBLISH message sent from UA1 to the SIP server. This message is sent when UA1 logs in to the presence service. Because this is an initial PUBLISH message, this message does not contain the SIP-IfMatch header field. Similar to REGISTER messages, UA1 fills its URI in the Request-URI header field and its domain name (i.e., user1pc.domain.com) in the Via header field. The To and From header fields are the same (i.e., UA1’s URI). The Call-ID header field specifies the transaction identifier, and the CSeq header field specifies that this message is a PUBLISH message and the sequence number is 1. The Max-Forwards header field (i.e., 70) limits the maximum hops in the forwarding path. The Expires header field indicates the


355

01 PUBLISH sip:[email protected] SIP/2.0 02 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK652hsge 03 To: 04 From: ;tag=1234wxyz 05 Call-ID: [email protected] 06 CSeq: 1 PUBLISH 07 Max-Forwards: 70 08 Expires: 3600 09 Event: presence 10 Content-Type: application/pidf+xml 11 Content-Length: … 12 [PIDF document] Figure 15.7 An example of the PUBLISH message.

suggested lifetime of the publication. In this example, the duration of this publication is 3,600 seconds. The Event header field specifies the modified event package. The Content-Type header field specifies that PIDF is the format of the message body, and the Content-Length header field presents the number of total characters in the message body. Figure 15.8 demonstrates the 200 OK message that is used to respond to the PUBLISH message. The start line identifies this message as a 200 OK message and CSeq specifies this message is acknowledged for the PUBLISH message with the sequence number 1. Based on the Via header field, the 200 OK message is forwarded to UA1. The To, From, and Call-ID header fields are copied from the PUBLISH message. The SIP-ETag header field specified by the SIP server records the identifier for the subsequent updates. The Expires header field specifies the duration of the event state. The duration is reduced from 3,600 seconds to 1,800 seconds, which means that the SIP server will remove the state after 1,800 seconds. The presence service in the 3GPP IMS adopts SIP extensions (e.g., MESSAGE, SUBSCRIBE, PUBLISH, and NOTIFY) as the signaling messages. To save the battery and wireless bandwidth, the 3GPP introduces two new components (i.e., the presence list server and the presence server) in the reference architecture of presence service. The architecture and message flow for 3GPP presence service are elaborated in the next section.

356


01 SIP/2.0 200 OK 02 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK652hsge; received=192.0.2.3 03 To: ;tag=1a2b3c4d 04 From: ;tag=1234wxyz 05 Call-ID: [email protected] 06 Cseq: 1 PUBLISH 07 SIP-Etag: dx200xyz 08 Expires: 1800 Figure 15.8 An example of the 200 OK message.

3GPP IMS Presence Service Figure 15.9 illustrates the reference architecture of the 3GPP IMS presence service. 3GPP presence service consists of seven elements, including the principals, the user equipment (UE), the presence list server, the watcher presence proxy, the presentity presence proxy, the presence server, and a home subscriber server (HSS). A principal (Figure 15.9; a,h) is a user in presence service. Based on the principal’s behavior, it can be a watcher or a presentity, or it can play both roles. For example, when a principal requests a subscription, it plays a role as a watcher. If the principal publishes the presence information, it plays a role as a presentity. The UE (Figure 15.9; b,i) is a principal’s equipment (e.g., a cellular phone or a PDA). The watcher application (Figure 15.9; c) and the presence user agent (Figure 15.9; j) are the applications running on the UE and are responsible for requesting the subscriptions and the publication of the presence information, respectively. The presence list server (Figure 15.9; g) maintains various lists (e.g., the buddy lists) for the principals. For example, with the presence list server, the principals can retrieve their buddy lists from the presence list server at any UE. Moreover, the presence list server can assist a UE in subscribing to all friends by using one SUBSCRIBE message. The watcher presence proxy (Figure 15.9; d) and the presentity presence proxy (Figure 15.9; k) consist of call session control functions (CSCFs) and reside in the watcher’s and the presentity’s home networks, respectively. A CSCF provides the SIP proxy functions for SIP message control. A CSCF can be a proxy CSCF (P-CSCF), an interrogating

357

Instant Messaging and Presence Service (IMPS) Home Network of Watcher

Pet 2

g Presence List Server 3 Pw

a Principal

b UE1 c Watcher Application

Pw 1

d Watcher Presence Proxy e P-CSCF f S-CSCF 4 Pw

9 Home Network of Presentity

h Principal

i UE2 j Presence User Agent

o HSS(HLR)

Pep 7 Peu 8

Px 5

k Presentity Presence Proxy 1 P-CSCF

m S-CSCF

n I-CSCF

6 Pwp p Presence Server

Figure 15.9 Reference architecture to support presence service in the 3GPP IMS.

CSCF (I-CSCF), or a serving CSCF (S-CSCF). The I-CSCF determines how to route incoming calls to the S-CSCF and then to the destination UE. That is, the I-CSCF serves as the contact point for the IMS network to hide the configuration, capacity, and topology of the IMS network from the outside world. The P-CSCF contains limited address translation functions to forward the requests to the I-CSCF. Authorization for bearer resources in the network (where the UE visits) is performed by the P-CSCF. By exercising the IMS registration, an S-CSCF is assigned to serve the UE. This S-CSCF supports the signaling interactions with the UE for call setup and supplementary service control (e.g., service request and authentication). The SCSCF also acts as a SIP registrar to store the contact addresses of the UE. In this example, the dialog is initialized by the watcher to the presentity. Therefore, the watcher presence proxy includes P-CSCF (Figure 15.9; e) and S-CSCF (Figure 15.9; f). The presentity presence proxy includes I-CSCF (Figure 15.9; n), S-CSCF (Figure 15.9; m), and P-CSCF (Figure 15.9; l). The home subscriber server (Figure 15.9; o) consists of the IMS functionality and is the master database containing all user-related subscription information. The presence server (Figure 15.9; p) stores and manages the presentity’s presence information. Upon receipt of a SUBSCRIBE message, the presence server will retrieve the presentity’s presence information from its database and check if the information is expired. If it is not,

358

IP Multimedia Subsystem (IMS) Handbook the presence server provides the presence information to the subscriber (i.e., the watcher). Moreover, the presence server supports the subscription authorization policy, which allows it to accept or reject a subscription from the specific watchers.

The preceding components are interconnected by several interfaces defined in the 3GPP specification TS 23.002 [14]. The Pw (Figure 15.9; 1,3,4), Pep (Figure 15.9; 7), and Pwp (Figure 15.9; 6) interfaces are implemented based on SIP and used for SIP SUBSCRIBE, NOTIFY, and PUBLISH message delivery. The Pet and Peu interfaces are the Ut interface, which is implemented based on hypertext transfer protocol (HTTP) and used to configure the presence list server and the presence server. The Px interface is the Cx interface, which is implemented based on the DIAMETER or mobile application part (MAP). The presentity presence proxy utilizes the Px interface to retrieve users’ information from the HSS. The message flow of presence service in IMS is different from that in SIP. Besides authentication procedures defined in IMS, there are two elements (i.e., the presence list server and the presence server) proposed in 3GPP presence service. The presence list server assists a watcher in subscribing to the presence information for the URIs of a buddy list, and the presence server assists a presentity in replying to the presence subscription. Figure 15.10 illustrates a message flow example for 3GPP presence service. In Figure 15.10, UE1 is a watcher and UE2 is a presentity. Assume that UE2 is in UE1’s buddy list (i.e., the URI is UE2@presence_server) and allows UE1 to subscribe to its presence information. UE1 and UE2 reside in different mobile networks. In the initialization, UE2 has published its information to the presence server. The detailed procedure is described as follows: Steps 1 and 2. UE1 sends a SUBSCRIBE message to the watcher presence proxy through the Pw interface. Upon receipt of the SUBSCRIBE message, the watcher presence proxy forwards this message to the presence list server. The presence list server stores the subscription request and replies with a 200 OK message to UE1 through the watcher presence proxy (i.e., P-CSCF and S-CSCF). Step 3. The watcher presence proxy then retrieves UE1’s buddy list from its database and sends the SUBSCRIBE messages to the URIs of the buddy list. In this example, the message is sent to UE2’s URI (i.e., UE2@presence_server). Because UE1 and UE2 reside in different mobile networks, this message is delivered to UE2’s presentity presence proxy (i.e., I-CSCF, S-CSCF, and P-CSCF) first. The presentity presence proxy then forwards the SUBSCRIBE message to the presence server. Upon receipt of the SUBSCRIBE message, the presence server replies with a 200 OK to the presence list server to acknowledge the receipt of the SUBSCRIBE message.

359

Instant Messaging and Presence Service (IMPS) Home Network of Watcher Watcher Presence Proxy

UE1

1 SUBSCRIBE 1 200 OK 2 NOTIFY 2 200 OK

Home Network of Presentity Presence List Server

UE2

2 NOTIFY 2 200 OK 3 SUBSCRIBE

3 200 OK

3 SUBSCRIBE 3 SUBSCRIBE 3 200 OK

3 200 OK

5 NOTIFY

4 NOTIFY 4 200 OK

5 200 OK 6 PUBLISH 6 200 OK 7 NOTIFY 7 200 OK

8 NOTIFY 8 200 OK

Presence Server

1 SUBSCRIBE 1 200 OK

4 NOTIFY 4 200 OK 5 NOTIFY 5 200 OK

Presentity Presence Proxy

8 NOTIFY

7 NOTIFY

6 PUBLISH 6 200 OK

7 200 OK

8 200 OK

Figure 15.10 A message flow of 3GPP presence service.

Step 4. The presence server retrieves UE2’s presence information from its database and checks if the lifetime of the information is expired. Assuming that the lifetime is not expired, the presence server sends UE2’s presence information to the presence list server by using a NOTIFY message. The presence list server then replies with a 200 OK to acknowledge the receipt of the NOTIFY message. Note that the presence list server has obtained UE2’s presence information. Step 5. To reduce power consumption, the presence list server may merge several NOTIFY messages into one message and send this integrated message to UE1. For simplification, in this example, the presence list server directly sends the NOTIFY message to UE1. This NOTIFY message is delivered to the watcher presence proxy and then to UE1. Upon receipt of the NOTIFY message, UE1 then replies with a 200 OK message to the presence list server. Step 6. Assume that UE2 changes the state of the presence information. UE2 sends a PUBLISH message to the presence server. The presence server stores the state into its database and replies with a 200 OK message to UE2.

360


Steps 7 and 8. The presence server detects that the presence information of UE2 has changed. The presence server invokes a NOTIFY message to UE1. The NOTIFY message is delivered to the presence list server, and then the presence list server forwards this message to UE1. Upon receipt of the NOTIFY message, UE1 is aware of the presence information of UE2 and replies with a 200 OK message. Note that in this example the presence list server and the presence server are stateful servers and handle the presence information for the watcher (UE1) and the presentity (UE2), respectively. With these two servers, both UEs will have longer battery life and less bandwidth consumption because the presence list server and the presence server assist UEs to process most messages instead of forwarding them to UEs.

Discussion and Conclusions The IMPS is one of the most popular services in all-IP networks. Original communication behaviors (e.g., telephone or e-mail) are changed by using the IMPS. IMPS users can be aware of the presence information of their friends and choose a proper way to reach their friends. However, the issues of the IMPS also arise. In VoIP services, SIP messages are used to exchange media information, including IP addresses, port numbers, and codecs. However, SIP-based instant messages utilize SIP messages to deliver the actual communication data. Therefore, the security issues for SIP-based instant services are greater than those of other SIP-based services (e.g., VoIP). To solve this problem, the IM users can use TLS (transport layer security) to set up a secure connection or S/MIME (security MIME) to encrypt the message body. Because TLS encrypts the whole SIP message, including the header fields and the message body, each SIP server should decrypt the SIP message and process the header fields. In other words, TLS is a hop-by-hop mechanism. If the IM user attempts to have end-to-end security, S/MIME should be used to encrypt the message body. Readers can refer to RFC 4346 [19], RFC3850 [20], and RFC 3851 [21] for more information about TLS and S/MIME. Based on the description in this chapter, the major issues for presence service are how to reduce the number of the presence messages delivered between a UE and IMS and how to reduce the bandwidth consumption. For the first question, several proposals [2,3] reduce the number of the SUBSCRIBE and the NOTIFY messages. For example, the soft-state subscription can be changed to the hard-state subscription by setting the value of the Expires header fields to 232. Moreover, the presence server can send the NOTIFY messages only when the presence information or state is changed. In other words, the presence server will not send a NOTIFY message when the lifetime of the presence information is updated.


361

The size of a simple PIDF document, which describes the state of a presentity, is about 200–500 bytes. For example, changing the state from open to closed requires 275 bytes. For the documents applied to the extension formats [11,12], the size of whole document may exceed 1,000 bytes. To solve this problem, the presence server or the UE can only notify or publish the changed parts of a document [4,7,8]. This will reduce the sizes of the NOTIFY and the PUBLISH messages. In summary, this chapter utilized examples to demonstrate the SIP extensions for instant messaging and presence service. Also, it introduced the reference architecture and the message flow of presence service for the 3GPP IMS. Readers can obtain background knowledge from the preceding sections. In the last section, this chapter pointed out the issues and several existing solutions; readers may study these issues further.

Acknowledgment The author would like to thank R.-H. Liou for his help in collecting the examples in this chapter. This work was sponsored in part by NSC 96-2218-E-197004, the NCHC project, and the MoE project.

References

1. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. 2002. SIP: Session initiation protocol. RFC 3261, IETF. 2. Khartabil, H., E. Leppanen, M. Lonnfors, and J. Costa-Requena. 2006. An extensible markup language (XML)-based format for event notification filtering, RFC 4661. 3. Khartabil, H., E. Leppanen, M. Lonnfors, and J. Costa-Requena. 2006. Functional description of event notification filtering, RFC 4660. 4. Lonnfors, M., J. Costa-Requena, E. Leppanen, and H. Khartabil. 2006. Session initiation protocol (SIP) extension for partial notification of presence information, draft—ietf-simple-partial-notify-08. 5. Lonnfors, M., E. Leppanen, H. Khartabil, and J. Urpalainen. 2006. Presence information data format (PIDF) extension for partial presence, draft-ietf-simple-partial-pidf-format-08. 6. Niemi, A. 2004. Session initiation protocol (SIP) extension for event state publication, RFC 3903. 7. Niemi, A. 2006. An extension to session initiation protocol (SIP) events for issuing conditional subscriptions, draft-niemi-sip-subnot-etags-02. 8. Niemi, A., M. Lonnfors, and E. Leppanen. 2007. Publication of partial presence information, draft-ietf-simple-partial-publish-06.

362


9. Roach, A. B. 2006. Session initiation protocol (SIP)-specific event notification, RFC notification extension for resource lists, RFC 4662. 10. Rosenberg, J. 2004. A presence event package for the session initiation protocol (SIP), RFC 3856. 11. Schulzrinne, H. 2006. CIPID: Contact information in presence information data format, RFC 4482. 12. Schulzrinne, H., V. Gurbani, P. Kyzivat, and J. Rosenberg. 2005. RPID: Rich presence extensions to the presence information data format (PIDF), RFC 4480. 13. Sugano, H., S. Fujimoto, G. Klyne, A. Bateman, W. Carr, and J. Peterson. 2004. Presence information data format PIDF, RFC 3863. 14. 3GPP TS 23.002. Network architecture. 15. 3GPP TS 23.141. Presence service; Architecture and functional description; stage 2. 16. 3GPP TS 23.228. IP multimedia subsystem (IMS); stage 2. 17. Campbell, B., J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. 2002. Session initiation protocol (SIP) extension for instant messaging, RFC 3428. 18. Klyne, G., and C. Newman. 2002. Date and time on the Internet: Timestamps, RFC 3339. 19. Dierks, T., and E. Rescorla. 2006. The transport layer security (TLS) protocol version 1.1, RFC 4346. 20. Ramsdell, B., Ed. 2004. Secure/multipurpose Internet mail extensions (S/ MIME) version 3.1 certificate handling, RFC 3850. 21. Ramsdell, B., Ed. 2004. Secure/multipurpose Internet mail extensions (S/ MIME) version 3.1 message specification, RFC 3851.

16 Multiparty Services in the IP Multimedia Subsystem Iván Vidal, Ignacio Soto, Francisco Valera, Jaime García, and Arturo Azcorra

contents Introduction.......................................................................................................... 363 Considerations about Multiparty Services in IMS..........................................364 Session Control Functionalities in Multiparty Scenarios.............................. 366 Session Establishment................................................................................ 367 Routing of SIP Signaling................................................................ 367 Negotiation of the Session Description....................................... 370 Configuration of the QoS-Enabled Multicast Delivery Service................................................................................ 374 Subscription to Multicast Groups in the Initiator UE................ 376 Concluding the Session Establishment........................................ 376 Notifying the Status of the Multiparty Multimedia Session.... 377 Cancellation of Session Establishment.................................................... 378 Session Release............................................................................................380 Conclusions........................................................................................................... 381 References............................................................................................................. 382

Introduction The development and deployment of the new third-generation (3G) cellular networks have introduced a new communication paradigm in the telecommunications market. New broadband access infrastructures are offered to end users, who are able to access a large variety of new services independently of their location. In this context, the IP plays a key role, supporting the transport of data in communications involving mobile user equipment (UE), which gets Internet access through the packet domain in the 3G network. Thus, the end user can access any service in the Internet as a user with fixed 363

364


broadband access (e.g., a Digital Subscriber Line, xDSL). Examples of those services are Web browsing, electronic mail, or content-downloading applications. In this way, the packet domain in 3G networks makes possible the convergence between the Internet and the cellular world. The data communication paradigm in 3G networks introduces the possibility of establishing direct IP communication between mobile devices. This functionality, already present in the Internet environment, opens new and exciting possibilities in the development of next-generation services and applications for the mobile communication domain. In particular, it enables peer-to-peer applications for communicating users in the mobile world. Additionally, the introduction of the IMS (IP multimedia subsystem) in the packet domain of the universal mode telecommunications system (UMTS) provides the control functionalities required to offer multimedia services with quality of service (QoS) requirements, services that traditionally have been offered through circuit-switched networks. On the other hand, several services that are currently being defined for UMTS networks involve the exchange of media not only between pairs of users but also among several users. In this chapter we will focus on these multiparty services. Examples are push-to-talk and conference services. Nevertheless, the specifications developed to date by the 3rd Generation Partnership Project (3GPP) do not provide a general mechanism to support the negotiation of these services because the currently presented solutions are specific for each service. Furthermore, in these solutions a unicast-based approach is considered to deliver the media in the user plane, typically by sending the information to a central node where it is replicated for each participant in the service. This solution, as we will show in this chapter, presents efficiency problems related to the use of bearer resources in the transport networks. The rest of this chapter is structured as follows. The following section details some general considerations about the current specification of the multiparty services that are developed within the scope of IMS. An alternative approach for the implementation of these services is described here, and the main advantages and drawbacks related to this solution are analyzed. “Session Control Functionalities in Multiparty Scenarios” specifies the session initiation protocol (SIP) signaling procedures that are necessary in the control plane for the implementation of the presented solution. Finally, the last section describes the main conclusions of this chapter.

Considerations about Multiparty Services in IMS The IMS architecture has been defined to provide the user with access to a wide range of services, which are implemented by means of application servers (ASs). In addition, session control functionalities support the establishment of multimedia sessions between UEs over which advanced peer-

Multiparty Services in the IP Multimedia Subsystem

365

to-peer services may be provided (e.g., telephony or videoconference). These services involve the direct transmission of media between the participant parties in the service in the data plane. On the other hand, some of the services that are envisioned in the future of 3G mobile networks involve the exchange of media between multiple participant parties. Typical examples of these services are push-to-talk and conference services. However, the specifications currently developed by the 3GPP for these services do not support the provision of a generic platform capable of efficiently providing those services to the end user. On the one hand, the specifications currently developed for the IMS do not consider session control functionalities for multimedia sessions that involve the exchange of information between multiple participants. Therefore, the IMS does not support the establishment of a multimedia session between multiple UEs, and typically the procedures associated with session control in multiparty services are dependent on the service. This fact results in an increment of the cost associated with the development of new multiparty services, which finally could affect the future deployment opportunities. On the other hand, the specifications developed by the 3GPP for multiparty services still consider a transmission schema based on unicast technologies for the media in the user plane. In this schema, data traffic is sent from each UE to a central node, where it is replicated and transmitted using a unicast transport to each participant UE in the service. This solution typically increases the traffic load in the network, providing less scalable solutions in terms of users and services. The development of new session control functionalities in the IMS to support the management of multimedia sessions among multiple UEs provides a flexible mechanism that facilitates the development of new multiparty services within the 3G mobile network environment. These new functionalities allow establishing a multimedia session among multiple UEs in the IMS. In this multimedia session, the multiparty service can be provided. This way, specific control procedures are no longer needed for each service, resulting in a cost-effective solution in terms of development. On the other hand, the problems related to the increment of traffic load in the network resulting from the replication of traffic to multiple destinations can be minimized using transmission technologies based on network level multicast. The introduction of these network-level multicast techniques has several advantages: • better transmission efficiency in the backbone networks that interconnect the different gateway GPRS (general packet radio service) support nodes (GGSNs) as well as in the UMTS core and radio access networks. By using network-level multicast, IP packets are properly distributed through the backbone networks, being replicated only if it is really necessary. In the UMTS core and radio access networks, the media could be transmitted from GGSNs to the UE by means of shared packet data protocol (PDP) contexts;

366


• better scalability, in terms of users and services, as a logical consequence of the previous point and due to the fact that in network-level multicast there is no central node receiving all the data traffic (which could become a bottleneck); • better fault tolerance. In the unicast approach, the data traffic is sent to a central node that replicates the media, so it becomes an isolated point of failure. In the network-level multicast-based approach, the data traffic is properly distributed through the backbone networks toward the GGSNs that serve the UE, serving as the multicast routing mechanism in charge of providing the necessary robustness to failures in nodes and links; and • compatibility with Internet services based on network-level multicast delivery technologies (these services could be directly delivered to the UE in the UMTS environment). Nevertheless, using network-level multicast delivery technologies for the transmission of data traffic in the user plane implies that the GGSNs must implement Internet group management protocol (IGMP) support [2], thus allowing the UE to indicate its disposition to receive the media corresponding to specific multicast groups, as well as some multicast routing mechanisms—for example, protocol independent multicast-sparse mode (PIM-SM) [3]. This may increase the processing load in each GGSN but in general decreases the traffic load received in a GGSN when it serves multiple UEs participating in the same service. Vidal et al. [4] propose extensions to the session control functionalities in the IMS to support a multiparty scenario and describes a generic session establishment procedure that allows a multimedia session to be established between multiple participants. In [4], the media are distributed in the user plane by means of network-level multicast delivery technologies. The next section shows an overview of this proposal and extends it with the rest of the session control functionalities that are necessary to manage multimedia sessions in the IMS involving multiple UEs.

Session Control Functionalities in Multiparty Scenarios This section covers the extensions to the session control procedures that are described in the 3GPP specifications for the IMS ([1] and [5]), so as to support the control of multimedia sessions where multiple UEs participate. These multimedia sessions support the implementation of peer-to-peer services (e.g., videoconference) where the data traffic is exchanged in the user plane, among the UEs participating in the service, by means of network-level multicast technologies. In this section we assume that a 3GPP IP connectiv-


367

ity access network (IP-CAN), with a UMTS terrestrial radio access network (UTRAN) and the UMTS packet domain, is used. In addition, it is assumed that each UE that participates in a multiparty multimedia session has established a dedicated signaling PDP context to support the exchange of SIP signaling messages between the UE and its corresponding proxy call session control function (P-CSCF). The rest of this section is organized as follows. In the next subsection, the extensions to the IMS control functionalities that are related to the establishment of multimedia session procedures are described. The following subsection indicates the procedures associated with the cancellation of the session establishment process—for instance, due to a lack of resources in the transport networks. Finally, “Session Release” covers the release procedures of the multimedia session initiated by the network or by the UE. Session Establishment This section describes procedures to extend the IMS control signaling to support the establishment of multimedia sessions among multiple users. As in a regular IMS session established between two UEs, the first thing the initiator UE must do to establish the multimedia session is to create a SIP dialogue. This dialogue is used to allow the execution of the proper session control procedures, providing a signaling relationship between the initiator UE and the rest of the UEs involved in the service. This signaling relationship will support the negotiation of the characteristics of the different media components that will be exchanged during the session. As it will be shown in this subsection, this will enable two fundamental procedures: • the reservation of QoS resources that are necessary in the user plane for the proper delivery of each media component; and • the configuration of the network-level multicast delivery service for each media component in the multiparty multimedia session. Figure 16.1 shows, from the point of view of the initiator UE, the SIP signaling corresponding to the session establishment functionalities that are described in this subsection. Figure 16.2 shows these procedures from the point of view of each destination UE. Routing of SIP Signaling To establish the SIP dialogue, the UE of the initiating user must send an INVITE request to the UEs that belong to the end users it wants to involve in the execution of the service (point 1 in Figures 16.1 and 16.2). This INVITE request will contain the list of SIP uniform resource identifiers (URIs) corresponding to the end users to be contacted. Each SIP URI is a public user identity in the IMS. The INVITE request contains also the SIP URI where

368

IP Multimedia Subsystem (IMS) Handbook UE (1)

P-CSCF INVITE

S-CSCF INVITE

AS

INVITE INVITE is replicated for each destination user INVITE

Send to each destination UE

INVITE

Sess. Progress Sess. Progress

(2)

Each destination UE answers with a S. Progress

Evaluation of SDP answer

(3)

Sess. Progress PRACK



PRACK is replicated for each destination user

PRACK

Resource reservation and subscription to multicast groups

OK


PRACK OK

(4)

Each destination UE answers with an OK


(5)

OK UPDATE

OK UPDATE

OK UPDATE UPDATE is replicated fopr each destination user UPDATE UPDATE OK OK

Send to each destination UE (6)

First OK answer received

(7)

First RINGING answer received

Evaluation of SDP payload in OK answer OK

OK

OK RINGING

RINGING

RINGING

RINGING

RINGING OK (INVITE) OK (INVITE)

(8)

First OK answer received to the INVITE request


OK (INVITE)

OK (INVITE)

NOTIFY

NOTIFY

(10)

ACK

(11)

OK

ACK OK

OK (INVITE) NOTIFY

(9)

ACK OK ACK is replicated for each destination user ACK

ACK


Figure 16.1 Session establishment, initiator side.

the initiator UE wants to be contacted for further requests in the dialogue; this SIP URI is indicated in the contact header of the request. The request is routed to the server call session control function (S-CSCF) assigned to the initiator user, passing through the P-CSCF, by means of the regular routing mechanisms in the IMS. The S-CSCF performs the procedures for service provisioning. These procedures consist of checking the content of the INVITE request against a set of

369

Multiparty Services in the IP Multimedia Subsystem I-CSCF INVITE Request Received Send to Initiator UE

INVITE Sess. Progress

Sess. Progress

PRACK Request Received Send to Initiator UE

S-CSCF

INVITE

PRACK

OK

OK

P-CSCF INVITE Sess. Progress

UE INVITE

(1)

Sess. Progress

(2)

PRACK

PRACK

(3)

OK

OK

(4) Resource Reservation

UPDATE Request Received

UPDATE

UPDATE

UPDATE

Send to Initiator UE

OK

OK

OK

Send to Initiator UE

RINGING

RINGING

RINGING

Send to Initiator UE Received ACK Request

OK (INVITE) ACK

OK (INVITE) ACK

OK (INVITE)

ACK

(5) (6) (7)

(10)

Destination UE Alerts the User The User Accepts the Session Establishment and UE Subscribes to the Corresponding Multicast Groups

(11)

Figure 16.2 Session establishment, destination side.

filtering criteria that are associated with the public user identity of the initiator user. As a result of this checking, the S-CSCF will verify that the INVITE request must be processed in an application server specific to multiparty applications: the multiparty application server (MAS). The filter criteria can be defined so as to check if the method of the request is INVITE, the session case is originating, and the INVITE request contains a list of SIP URIs. The MAS is a SIP back-to-back user agent (B2BUA), as defined in Rosenberg et al. [6]. It comprises by one user agent client (UAC) and one user agent server (UAS). Both UAs are connected by certain service-specific logic. Figure 16.3 shows the functional architecture of the B2BUA. After receiving the INVITE request, the B2BUA performs the following actions: • It generates a SIP URI that uniquely identifies the multiparty multimedia session. The contact header of the INVITE request is set to this SIP URI. • It assigns one multicast IP address to each media component defined in the session description protocol (SDP) offer. This way, each media component is assigned to a multicast group. This allows different destination user equipment with different capabilities to accept and to subscribe to the media components that it supports and is able to accept. Each multicast IP address will stay assigned to a media component while the multiparty multimedia session remains established.

370

IP Multimedia Subsystem (IMS) Handbook B2BUA Service Logic

UAC

SIP Request SIP Response

UAS

UAC

SIP Request SIP Response

UAS

Figure 16.3 B2BUA functional architecture.

• It replicates the INVITE request for each public user identity indicated in the SIP URI list. For each generated INVITE request, the destination URI (field Request-URI in the start line) is set to the SIP URI corresponding to the replica. Finally, each INVITE request is properly routed to its destination by means of the regular IMS routing procedures. When a destination UE receives the INVITE request, it answers with a SIP Session in Progress response. This response contains a contact header, indicating the SIP URI where the destination UE wants to be contacted for further requests in the dialogue. The Session in Progress response is routed back to the MAS by means of the IMS regular routing procedures. As will be explained later in this section, the MAS waits until it receives all the Session in Progress responses from the destination UEs. Each response received from one UE establishes one SIP dialogue between the MAS and the UEs. With all these responses, the MAS generates a single Session in Progress response, which is sent to the initiator UE. In this response, the contact header is set to the SIP URI that has previously been created for the multiparty multimedia session. This Session in Progress response in turn generates a SIP signaling dialogue between the MAS and the initiator UE. Therefore, the INVITE-Session in Progress exchange creates one SIP signaling dialogue between the MAS and each UE involved in the multiparty multimedia session. These dialogues will be used to route further SIP requests sent during the execution of the control procedures associated with the multiparty multimedia session. Negotiation of the Session Description During the session establishment procedure, the participating UE must reach an agreement on the description of the different media components that will be part of the multiparty multimedia session. For that purpose, the SDP [7] and the offer/answer model [8] of SDP are used in the IMS. In Vidal et al. [4], a proposal is described that, following the specifications contained

Multiparty Services in the IP Multimedia Subsystem Initiator UE

371

MAS

INVITE 1st SDP Offer

INVITE 1st SDP offer Session In Progress 1st SDP answer The MAS waits until it receives all the Session in Progess responses

To each destination UE First Session in Progress received

Session In Progress 1st Combined SDP Answer PRACK 2nd SDP Offer

PRACK 2nd SDP offer OK 2nd SDP answer

To each destination UE First OK received

The MAS waits until it receives enough OK responses so as to confirm every media component OK 2nd Combined SDP Answer

Figure 16.4 Session description negotiation.

in Rosenberg and Schulzrinne [8], supports the negotiation of the multiparty multimedia session. This proposal is briefly indicated next (an overview is shown in Figure 16.4): • The initiator UE includes an SDP offer in the INVITE request. The offer describes the media components that the initiator wants to exchange in the multiparty multimedia session. For each media component, the initiator UE includes, among other things, the list of supported formats (e.g., codecs), the bandwidth requirements, and addressing information (i.e., the transport port where the media component is to be transmitted). The SDP offer is modified by the MAS, which includes a multicast IP address for every media component. Finally, the modified SDP offer is included in every INVITE request sent to the destination UEs. • Each destination UE answers the SDP offer with an SDP answer, which is included in a SIP Session in Progress response. In this SDP answer, the destination UE can discard any media component (setting the transport port at zero). For each accepted media component,

372

IP Multimedia Subsystem (IMS) Handbook the destination UE indicates in the SDP answer the set of supported formats out of those that were present in the offer. Because the Session in Progress message is a SIP provisional response, it is not reliably sent according to the regular SIP procedures. To solve this problem, an extension to the SI protocol defined by the Internet Engineering Task Force (IETF) in Rosenberg and Schulzrinne [9] is used in the IMS. This way, the Session in Progress response is reliably sent to the destination UE.

• The Session in Progress responses are routed back to the MAS. When this functional entity receives all the responses, it generates a new Session in Progress response for the INVITE request received from the initiator UE. This SIP response contains an SDP answer, formed by the combination of the different SDP answers received from the destination UEs. This SDP answer is generated as follows: • For every media component included in the SDP offer, if any SDP answer accepts the media component, then it is discarded in the combined SDP answer. Otherwise, the media component is accepted. • For each accepted media component, the MAS derives the formats that will be indicated in the combined SDP answer. Only those formats that were accepted by all the user equipment that accepted the media component will be included in the answer. If there are no common formats for a media component, the component is discarded in the combined SDP answer. • Finally, the SDP answer includes, for each media component, the multicast IP address that was previously assigned by the MAS. The MAS waits up to some preconfigured time, Ts-prog, to receive all the Session in Progress responses. Upon timeout, the MAS generates the Session in Progress response with the SDP answers received up to that moment. If a Session in Progress response is not received from one destination UE, the UE is simply deleted from the list of participants in the multimedia multiparty session. • After receiving the Session in Progress response from the MAS (containing the combined SDP answer), the initiator UE generates a second SDP offer, according to the following procedures: • For each accepted media component in the combined SDP answer, a single format is selected out of those contained in the answer. Each of these media components is included in the second SDP offer with the selected format. The media component also includes information about the bandwidth requirements, the multicast IP address assigned by the MAS, and the port that was indicated in the first SDP offer.


373

• If a media component is discarded in the combined SDP answer, it is also discarded in the second SDP offer. According to Rosenberg and Schulzrinne [9], the reception of the Session in Progress response must be confirmed with a PRACK request (point 3 in Figures 16.1 and 16.2). This PRACK request is used to send the second SDP offer. Therefore, the selection of a single format for each media component involves a second SDP offer/answer exchange. This exchange is necessary because, if several formats were selected, the resource reservation would have to be done for the most restrictive one (the one demanding more resources), even if probably a less restrictive format is finally used in the session. • After receiving the PRACK request, the MAS generates a new PRACK request for each destination UE still participating in the multiparty session. Each PRACK request includes a second SDP offer, which is independently generated for each destination UE attending the following schema: • A media component will be proposed in the second SDP offer if it has been accepted by the destination UE in the first SDP answer and if it appears as proposed in the second SDP offer received from the initiator UE. The description of the media component is the one that was received from the initiator UE in the second SDP offer. • Otherwise, the media component is discarded in the second SDP offer. • Each destination UE receives the PRACK request containing the second SDP offer. Finally, each UE accepts this SDP offer and confirms it with a second SDP answer. This SDP answer is included in the SIP OK response to the PRACK request (point 4 in Figures 16.1 and 16.2). • Finally, the OK responses, each containing an SDP answer, are received in the MAS. The MAS will wait until it receives enough SDP answers to confirm that every media component that was previously accepted by the initiator UE in the second SDP offer is accepted by at least one destination UE. When this happens, the MAS generates a second combined SDP answer. This SDP answer accepts every media component that was previously proposed by the initiator UE in the second SDP offer. The description of each accepted media component is the one indicated by the initiator UE in that offer. • The MAS sends the combined SDP answer in a SIP OK response to the initiator UE. If, after some predefined timeout, Tok, the MAS has not received enough SDP answers to confirm all the media components, it is assumed that the communication path to the destination UEs that accepted that unconfirmed media components is no .

374

IP Multimedia Subsystem (IMS) Handbook longer available, and the combined SDP answer discards those components. In addition, this set of user equipment is deleted from the list of participating user equipment.

One improvement on this schema, in case there were no common formats for a specific media component among all the participating user equipment, would consist of selecting the set of formats that maximizes the number of destination UEs capable of exchanging the component. Another more complex solution could be to introduce transcoding facilities in the user plane. Configuration of the QoS-Enabled Multicast Delivery Service Once the session description negotiation has concluded, each participant’s UE has reached an agreement on the different parameters that describe the media components that are part of the multiparty multimedia session. Next, each UE needs to activate the necessary PDP contexts to transport the traffic associated with each media component it has agreed to exchange and to guarantee that the necessary QoS is provided to each of them. Thus, the activation of PDP contexts is a resource reservation process, which is initiated separately from each UE. Specifically, it will be started by the initiating UE after sending the PRACK request; similarly, it will be started by each destination UE after sending the OK response to the PRACK request. Each UE will activate up to two PDP contexts for each media component that it has agreed to exchange: • a secondary PDP context for the transmission of the traffic associated with the media component in the uplink direction (i.e., from the UE to the GGSN); and • a shared PDP context for the transmission of the data traffic associated with the media component in the downlink direction (i.e., from the GGSN to the UE). This PDP context will be shared among all the participating user equipment that, being served by the same GGSN, activates the PDP context. This way, the multicast traffic associated with a media component is efficiently distributed in the UMTS core and radio access networks. Thus, the proposed schema provides an efficient resource reservation for the multiparty multimedia session for the following reasons: • Each UE performs an independent resource reservation for each media component, based on the activation of PDP contexts. This way, the UE can reserve from the transport network the QoS resources that are strictly necessary for the proper delivery of the media components it has agreed to exchange.


375

• Each media component is assigned the QoS resources that are really necessary by means of (possibly) an uplink PDP context and a shared downlink PDP context. Nevertheless, the activation of a PDP context may fail, for example, due to a lack of resources in the radio access network. Therefore, the session establishment cannot be successfully completed until the resource reservation process has been properly concluded. In general, we can state that, in a multiparty service, the activation of the necessary PDP contexts must be successfully completed by the initiator UE and one destination UE before alerting the corresponding destination user of the incoming session. This restriction guarantees that an adequate end-to-end QoS reservation has already been performed when one user is alerted by its UE, thus ensuring that the session can be established between this and the initiator UE. In a regular one-to-one IMS session, this restriction is also imposed, and it is enforced by means of a SIP extension defined by the IETF in Camarillo, Marshall, and Rosenberg [10] and Camarillo and Kyzivat [11]. This extension permits integrating the resource reservation mechanisms in the execution of the SIP protocol. To do that, certain information, known as preconditions, is inserted in the SDP payloads of the SIP messages exchanged between the initiator and destination UEs. This information describes the QoS restrictions that must have been fulfilled previously to complete the session establishment. Therefore, the destination UE delays the alerting process of the destination user (and thus the session establishment) until all its preconditions and the preconditions indicated by the initiator UE are met. In the multiparty scenario, this precondition mechanism is also used following, among others, the procedures explained next: • The initiator UE includes preconditions in the SDP offer of the first INVITE request. These preconditions are left unchanged by the MAS when generating the INVITE request for each destination UE. • Each destination UE includes preconditions in the SDP answer contained in the Session in Progress response. In this response, each UE also indicates its desire to receive a confirmation from the initiator UE when completing the remote resource reservation procedure. The MAS leaves these preconditions unchanged in the first combined SDP answer. Finally, if the resource reservation concludes successfully on the initiator side, the initiator UE sends a new SDP offer, indicating that the preconditions for the multiparty multimedia session have been met on its side. This SDP offer is included in a SIP UPDATE request that is sent toward the MAS (point 5 in Figures 16.1 and 16.2). The MAS generates a new UPDATE request for each destination UE. The UPDATE request is, in turn, answered by each destination UE with a SIP OK response (point 6 in Figures 16.1 and 16.2), which

376


also contains an SDP answer indicating the status of the resource reservation on the destination side. The MAS sends an OK response to the UPDATE request sent by the initiator user once it receives the first OK response from a destination UE. When a destination user finishes its local resource reservation and once it receives the UPDATE request, it can resume the session establishment process. Subscription to Multicast Groups in the Initiator UE After sending the UPDATE request, the initiator UE can subscribe itself to the multicast groups associated with the media components that it has agreed to exchange. For that purpose, the initiator UE uses the IGMP protocol executed between the GGSN and the UE. The IGMP messages will be exchanged through the dedicated signaling PDP context. The GGSN, in turn, will have to execute some multicast routing protocol (e.g., PIM-SM) to request the reception of the media corresponding to the multicast groups whose subscription is requested by the served UEs. Concluding the Session Establishment Assuming that one destination UE has concluded its local resource reservation and has received the UPDATE request, it can continue with the session establishment procedure. At this point, the destination UE may optionally start altering the destination user (e.g., by playing some ringing tone in the UE). In that case, it sends a SIP RINGING response to the INVITE request toward the MAS (point 7 in Figures 16.1 and 16.2). The MAS, after receiving this SIP message, will generate a new RINGING response that will be sent toward the initiating UE. The reception of future RINGING responses from the destination UEs will not imply the generation of further SIP signaling messages in the MAS. Finally, when the session is accepted by a destination user, its UE performs the following actions: • It subscribes itself to the multicast groups associated with the media components that it has agreed to exchange. • It sends a SIP OK response to the INVITE request toward the MAS, indicating that the session has been established at the destination side (point 8 in Figures 16.1 and 16.2). After receiving the first SIP OK message, the MAS generates a new OK response that is sent to the initiating UE. Thus, from the point of view of the initiator UE, this response means that at least one destination has accepted the multiparty multimedia session and that the transmission of multicast media can be started in the user plane. Finally, the destination UE confirms


377

the reception of the OK response with a SIP ACK request (point 10 in Figures 16.1 and 16.2). Notifying the Status of the Multiparty Multimedia Session At this point, the multimedia session has been established between the initiator UE and one destination UE. The problem now is that the SIP OK response, received by the initiator UE, contains no SDP payload and thus no information about the media components that were accepted by the destination UE is available at this moment on the initiator side. To solve this problem, the SIP specific event notification framework is used (see Roach [12]). This mechanism allows one entity to subscribe to the status information associated with one resource. The entity that keeps track of the status of the resource sends a NOTIFY request containing the requested status information. If the status changes, a new NOTIFY request is sent to the subscribed entity. The status information conveyed in the NOTIFY request is defined in a document that is designated event package. Specifically, in Rosenberg, Schulzrinne, and Levin [13], an event package was defined for tightly coupled conferences, allowing an entity to subscribe to the status of these kinds of conferences. This event package is used in the proposed solution so as to communicate useful information about the session status to each participant in the multiparty multimedia session. This information includes the specification of the media components that have been agreed to by each UE that participates in the multiparty multimedia session. Therefore, the reception of the first OK response to an INVITE request in the MAS is an implicit subscription of the initiating UE and of the destination UE that sent the OK response to the status of the multiparty multimedia session, which will be notified by means of this event package. This way, once the OK response is received in the MAS, the MAS sends a SIP NOTIFY request (point 10 in Figures 16.1 and 16.2) containing the status of the multiparty multimedia session to the initiator UE and to the destination UE. Thus, the initiator and destination UEs are provided with information about the media components for which they can start transmitting media. Each NOTIFY request is confirmed by the receiver with an OK response (point 11 in Figures 16.1 and 16.2). Future OK responses to INVITE requests received in the MAS imply the implicit subscription of the destination UE that sent the response to the status of the multiparty multimedia session. Any change in this status—for instance, when one UE is incorporated into or leaves the session—is notified to the subscribed UEs that is always informed about the current status of the multimedia session. This way, the subscribed UEs are also able to start transmitting traffic associated with a paused media component, if any UE that has accepted the media component gets into the session. Similarly, they are able to stop transmitting traffic for a media component if no receivers are available at any point during the session.

378

IP Multimedia Subsystem (IMS) Handbook UE

(1)

S-CSCF

P-CSCF INVITE

AS

INVITE

INVITE INVITE is Replicated for Each Destination User INVITE

Send to Each Destination UE

INVITE

Sess. Progress Sess. Progress

(2)

Each Destination UE Answers with a S. Progress

Evaluation of SDP Answer

(3)




PRACK is Replicated for Each Destination User

PRACK Resource Reservation Failure

(4)

Send to Each Destination UE

PRACK

CANCEL OK

CANCEL OK

CANCEL OK

(5)

For Each Destination UE

CANCEL OK CANCEL

Send to a Destination UE OK Response Received for CANCEL

OK

487

(6)

ACK

First Response 487 Received for INVITE Send to Each Destination UE

487 ACK 487 487 487

(7)

ACK

ACK

OK

Figure 16.5 Session cancellation by the initiator UE.

Cancellation of Session Establishment In the previous subsection the session establishment procedures were described. This subsection covers the scenarios where the session cannot be established with one or all of the destination UEs—for instance, because there are not enough resources in the radio interface of the UE to cover the QoS demands for the multiparty multimedia session. Figure 16.5 shows the case where the initiator UE cannot continue with the establishment of the multimedia session due to a lack of QoS resources in the

379

Multiparty Services in the IP Multimedia Subsystem UE

P-CSCF

S-CSCF

AS (1)

400-699 ACK

(2)

400-699

Response Received from Destination UE To Destination UE

ACK

400-699 OK

400-699 ACK

400-699 ACK

(3)

If No Destination UEs Remain NOTIFY OK

NOTIFY OK

NOTIFY

(4) NOTIFY

OK

(5) To Each Destination UE that has Accepted the Session Establishment

If the Session is Established

Figure 16.6 Session rejection by destination UE.

radio access network. In this case, the session must be cancelled because the progress of the establishment process depends on the initiating UE. As can be seen from the figure, the initiator UE cancels the session establishment procedure by means of a SIP CANCEL request. This CANCEL request is confirmed with a SIP OK response hop by hop by each SIP proxy that receives the request. When the SIP CANCEL request reaches the MAS, it generates a new CANCEL request for each destination UE. When a destination UE receives the CANCEL request, it confirms the request with an OK response and answers the INVITE request with a 487 (request terminated) response. When the first 487 response is received in the MAS, it generates a new 487 response for the INVITE request received from the initiating UE and sends it there. The 487 response is confirmed hop by hop with an ACK request. Thus, the session establishment is cancelled. Figure 16.6 shows the case where the destination UE cannot accept the session establishment—for instance, because the user is not accessible in the UE or not enough resources are available in the radio access network. In this case, the destination UE answers the INVITE request with a SIP error response (status codes between 400 and 699). This response is confirmed hop by hop by an ACK request. When the error response reaches the MAS, its behavior depends on the session status. If the session has not been established between the initiating UE and any of the destination UEs, then if the initiating UE is the only remaining participating UE left in the session, the MAS should terminate the session establishment by sending an error response to the initiating UE (this error response can be selected among the set of error

380

IP Multimedia Subsystem (IMS) Handbook P-CSCF

UE

S-CSCF

AS

Case 1

BYE OK

NOTIFY OK

NOTIFY OK

NOTIFY

BYE

(1)

BYE Received from Destination UE

OK

To Destination UE (2) NOTIFY

OK

To Each Destination UE that has Accepted the (4) Session Establishment

Case 2 (1)

BYE OK

BYE OK

BYE OK

NOTIFY

(2)

To Each Destination UE that has Accepted the Session Establishment

Case 3 (1)

BYE OK

BYE OK

BYE OK

BYE

(2)

To Each Participant UE

Figure 16.7 Session release scenarios.

responses received from the destination UEs). Otherwise, if the session is currently established between the initiation UE and a set of destination UEs, then the MAS must notify the initiating UE and that set of destination UEs about the changes in the session status, but the established session can continue normally. Session Release This subsection briefly covers the session release scenarios that can occur while the multiparty multimedia session is established. These scenarios are shown in Figure 16.7. The first case corresponds to the scenario where one destination UE wants to leave the multiparty multimedia session. In this case, the destination UE sends a BYE request toward the MAS. Once the MAS receives this BYE request, it confirms it with a SIP OK response and notifies the initiating UE and the set of UE that has accepted the session establishment about the change in the session status. This way, a flexible session release procedure is


381

provided that is suitable for any multiparty application. After it receives the NOTIFY request, a destination UE will be able to decide whether it remains or not in the multiparty multimedia session. In the latter case, a new SIP BYE request will be sent to the MAS. The second case corresponds to the scenario where the initiating UE leaves the multiparty multimedia session. In this case, the initiating UE sends a BYE request to the MAS. After receiving the BYE request, the MAS confirms it with a SIP OK response and notifies the rest of the UEs that have accepted the session establishment about the change in the session status. It is possible that the multiparty application mandates to terminate the multiparty multimedia session when the initiating UE leaves the session (this happens, for instance, in the push-to-talk over cellular [PoC] service when ad hoc sessions are being established). The status information included in the body of the NOTIFY request contains enough information to determine if the UE leaving the session is the one that initiated its establishment. Therefore, the proposed solution is suited to cope with these kinds of applications. Finally, the last case corresponds to the scenario where a UE (not necessarily the initiating UE) leaves the session and the remaining participating user equipment has not yet accepted the session establishment. In this case, the MAS terminates the multiparty multimedia session by sending a SIP BYE request to each of the remaining participating user equipment elements.

Conclusions The IMS is an IP-based architecture designed to provide a set of essential functionalities that support the delivery of the next-generation multimedia services that are envisioned in the future of 3G networks. In this context, this chapter has introduced the issues associated with the provision of multiparty services within the scope of the IMS. The main drawbacks associated with the current specification of these services have been identified, and an alternative solution to the proposals presented by the 3GPP has been described. This solution consists of extending the session control functionalities in the IMS and delivering the service by means of network level multicast technologies in the user plane. This way, a generic platform is provided supporting the development of multiparty services in the IMS. The advantages and drawbacks of using network-level multicast as the delivery services have been analyzed. Finally, the chapter describes the main extensions defined in IMS control procedures for the multiparty session establishment, multiparty session establishment cancellation, and multiparty session release procedures. Note that although we have described the work in the context of the UMTS architecture, the control plane functionalities are also applicable to a fixed access with IMS support (next-generation network architecture).

382


References

1. 3rd Generation Partnership Project. 2006. 3GPP TS 23.228 version 7.5.0: Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); IP multimedia subsystem (IMS); stage 2. 2. Cain, B., S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan. 2002. Internet group management protocol, version 3. RFC 3376 (proposed standard). Updated by RFC 4604. 3. Estrin, D., D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. 1998. Protocol independent multicast-sparse mode (PIM-SM): Protocol specification. RFC 2362 (experimental). Made obsolete by RFC 4601. 4. Vidal, I., I. Soto, F. Valera, J. Garcia, and A. Azcorra. 2007. IMS signaling for multiparty services based on network level multicast. 3rd Eurongi Conference on Next Generation Internet Networks, 21–23 May, pp. 103–110, Trondheim, Norway. 5. 3rd Generation Partnership Project. 2006. 3GPP TS 24.229 v7.5.1: Technical specification group core network and terminals; IP multimedia call control protocol based on session initiation protocol (SIP) and session description protocol (SDP); stage 3 (release 7). 6. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. 2002. SIP: Session initiation protocol. RFC 3261 (proposed standard). Updated by RFCs 3265, 3853, and 4320. 7. Handley, M., V. Jacobson, and C. Perkins. 2006. SDP: Session description protocol. RFC 4566 (proposed standard). 8. Rosenberg, J., and H. Schulzrinne. An offer/answer model with session description protocol (SDP). RFC 3264 (proposed standard). 9. Rosenberg, J., and H. Schulzrinne. 2002. Reliability of provisional responses in session initiation protocol (SIP). RFC 3262 (proposed standard). 10. Camarillo, G., W. Marshall, and J. Rosenberg. 2002. Integration of resource management and session initiation protocol (SIP). RFC 3312 (proposed standard). Updated by RFC 4032. 11. Camarillo, G., and P. Kyzivat. 2005. Update to the session initiation protocol (SIP) preconditions framework. RFC 4032 (proposed standard). 12. Roach, A. B. 2002. Session initiation protocol (SIP)-specific event notification. RFC 3265 (proposed standard). 13. Rosenberg, J., H. Schulzrinne, and O. Levin. 2006. A session initiation protocol (SIP) event package for conference state. RFC 4575 (proposed standard).

17 IMS-Based Conferencing Services: An Engineering Approach

Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, and Simon Pietro Romano contents Introduction..........................................................................................................384 CONFIANCE: An Open Source IMS-Enabled Centralized Conferencing Architecture............................................................... 385 Toward an IMS-Compliant Distributed Conferencing Framework... 386 Centralized Conferencing Scenario......................................................... 386 Distributed Conferencing Scenario.......................................................... 388 DCON: A Distributed Conferencing Framework........................................... 389 Framework Requirements......................................................................... 390 Framework Design...................................................................................... 391 DCON and the IMS Architecture............................................................. 392 DCON Implementation....................................................................................... 392 Interfocus Interaction................................................................................. 394 Server Side........................................................................................ 394 Client Side........................................................................................ 395 DCON Scalability Analysis................................................................................ 397 Preliminary Considerations...................................................................... 397 Centralized Scenario.................................................................................. 398 Distributed Scenario...................................................................................400 Comparative Analysis, Considerations, and Comments......................406 Related Work.........................................................................................................406 Conclusions and Future Work........................................................................... 407 Acknowledgments...............................................................................................408 References.............................................................................................................408

In this chapter we present an actual implementation of a distributed conferencing framework compliant with the IP multimedia core network subsystem 383

384


specification. The architecture we describe has been realized by exploiting existing achievements in the field of conferencing. More precisely, starting from the Internet Engineering Task Force (IETF) centralized conferencing (XCON) framework and based on an open source XCON implementation provided by our research group, we devised a distributed conferencing solution that has been implemented as an overlay network of centralized conferencing clouds. The chapter aims at providing the reader with useful information about our experience with IP multimedia subsystem (IMS) implementation and deployment. To this purpose, we first describe our architecture from a high-level design perspective and subsequently analyze it in further detail by highlighting the most notable implementation choices. A scalability analysis of the proposed framework is also provided in the chapter.

Introduction The IMS is a standardized next-generation networking (NGN) architecture that has been conceived for telecom operators willing to provide advanced services on top of both mobile and fixed networks. It makes extended use of voice over IP (VoIP) technologies based on a 3rd Generation Partnership Project (3GPP) implementation of SIP (session initiation protocol). Heterogeneous devices are supported. Users have to be able to exploit the entire portfolio of available services ubiquitously, which entails support for roaming as well as for flexible and transparent adaptation to context changes. To achieve the aforementioned goals, IMS exploits open standard IP protocols. Under this perspective, it is a very good example of an effort aimed at merging the two main telecommunication agoras currently available: the Internet and the cellular telecommunication infrastructure. Due to its recent birth, the IMS architecture is currently far from reaching its steady state with respect to the complete definition of the overall infrastructure and related standards. Furthermore, to date, only a few early trials and deployments of the architecture are under way. This leaves space for a number of open issues that still have to be faced at the infrastructure and service levels. The goal of this chapter is to provide a contribution to the solution of some of the previously mentioned issues, with special regard to the need for actual implementations of IMS architectures and services. We will here focus on the implementation of a distributed conferencing framework compliant with the IMS specification and able to provide conferencing facilities in conjunction with session management and floor control. The architecture we present is the outcome of our latest efforts in the field of conferencing. As will be explained in the chapter, based on our previous work on centralized conferencing, in the last years we have worked on the management of conference

IMS-Based Conferencing Services: An Engineering Approach

385

information in a distributed environment. The distributed architecture we present has been conceived as an extension to a standard centralized conferencing framework [1], which has been defined inside the IETF XCON working group and basically envisages the construction of an overlay network acting as a glue among a number of centralized conferencing “islands.” We will discuss the ideas that have inspired our work and subsequently provide information about our design and implementation choices. The chapter is structured as follows. The first section provides the background of our work by introducing the reference context as well as by briefly describing our previous work and achievements in the field of centralized conferencing. The requirements for an IMS-compliant distributed architecture will be identified in the following section. The section after that describes our proposal for a distributed conferencing framework that has been conceived at the outset by taking into account the identified requirements. Implementation details are illustrated in the “DCON Implementation” section. We then move our focus, in the following section, to the assessment of performance in the previously mentioned framework. We will first determine the main performance figures characterizing the CONFIANCE centralized architecture. The results of this preliminary analysis are then used as a benchmark for the subsequent assessment of the performance improvement achievable in the distributed case, when two or more conferencing clouds cooperate. In the next-to-last section we deal with related work. Finally, we provide some concluding remarks, together with information about our future work.

CONFIANCE: An Open Source IMS-Enabled Centralized Conferencing Architecture We recently presented an open source conferencing framework, which we called CONFIANCE (conferencing IMS-enabled architecture for next-generation communication experience). This framework is compliant with the IMS specification by taking into account ongoing standardization efforts inside the various active international bodies (IETF, 3GPP, Open Mobile Alliance [OMA], etc.). As it will be explained in the next section, compatibility with the IMS architecture is being realized through a mapping between the logical IMS entities and several real-world components. To offer advanced conferencing capabilities, great efforts have been put into developing an actual implementation of the centralized conferencing framework as proposed by the IETF working group XCON, from which we took inspiration. We worked on both the server side (Focus) and the client side (participant and administrator) as well as on the communication protocols between them: namely the conference control protocol (CCP) and the binary floor control protocol (BFCP). CCP takes care of session management, whereas BFCP looks after.

386


moderation aspects of the framework to allow coordinated access to the set of resources it offers. Although BFCP has already been completely specified [2] by the XCON Working Group, no agreement has been found yet on a specific candidate for the conference control protocol. This led us to implement a new protocol (called XCON scheduler) to take care of the basic session management functionality the framework is supposed to provide (e.g., creating new conferences or getting information about them). The interested reader can refer to the official project’s Web page [3] to get information about our implementation choices. The framework currently provides many advanced conferencing features, with complete audio support and continuous presence video mixing.

Toward an IMS-Compliant Distributed Conferencing Framework In this section we try to help the reader position our work. For the sake of conciseness, we are not providing any detail about the standard IMS components because we assume that the reader is already familiar with the IMS architecture. Hence, in the following subsections we first provide some information about the proper mapping between our architecture components and the corresponding IMS logical entities in the centralized conferencing scenario. Afterwards, we move to the distributed scenario, which requires the introduction of a new logical IMS element able to spread conference information among several IMS core networks. For both the aforementioned scenarios, we also find out how to replace the identified logical entities with real-world components. Centralized Conferencing Scenario To date, the 3GPP has only specified the required functionality for a centralized conferencing framework within the IMS TS-24.147. The cited document defines the following conferencing logical entities: Conference participant. It must be implemented in the user equipment (UE), which has to be SIP-, CCP-, and BFCP compliant in order to support the floor participant or floor chair role correctly. All SIP messages involving the UE (in either direction) traverse the P-CSCF (proxy call session control function), which represents the access point to the IMS network. Focus, floor control server, conference notification service, conference policy server, and media policy server. All these elements are logically .

387


User Equipment

I-CSCF Application Server

IP Network AP

P-CSCF

User Equipment MGCF

BGCF

MRFP

MGW

MRFC

User Equipment

S-CSCF

PSTN/PLMN Cell

HSS

= Control plane = Media plane

Figure 17.1 Conferencing and IMS: proposed mapping.

co-located within a SIP AS/MRFC (application server/media resource function control) component. All SIP messages involving the UE traverse an allocated S-CSCF (serving call session control function). The S-CSCF inspects each message and determines the right AS to which it must be forwarded for further processing. In our scenario, such an AS will be a conference focus. The MRFC controls media stream resources in the MRFP (media resource function processing) using information coming from both the AS and the S-CSCF. Media mixer. This entity is hosted in the MRFP. According to the identified logical entities, we can replace the IMS elements with real-world components. In our architecture, some of these components have been provided by the open source community. Some other entities have been developed from scratch or are based on open source artifacts that have been appropriately extended in order to meet our architecture requirements. As described in Figure 17.1, we replaced the P-CSCF with a SIP proxy server called OpenSER [5]. The S-CSCF and HSS (home subscriber server) elements have also been realized by exploiting the OpenSER. The AS, instead, has been provided by an open source PBX called Asterisk [6], which actually provided us with many required IMS functions. In fact, the conferencing.

388


application needed for our scenario is realized in our architecture by an Asterisk component called MeetMe, natively able to manage conferences, which we enriched with the required additional functionality (moderation, video support, etc.). Furthermore, the roles of the MRFC and MRFP components are also played by a couple of ad hoc modified Asterisk modules providing media manipulation, streaming, and floor control. In addition to this, we implemented “from scratch” a media server component capable of mixing and transcoding video streams, which we called CONFIANCE VideoMixer. This component is exploited by our enhanced MeetMe conferencing application by means of a dedicated protocol. This work actually put the basis for our current efforts in the specification of the interfaces between the AS and the MRFC, which is envisaged in the IMS architecture and currently under definition in the IETF MEDIACTRL (media server control) working group. Finally, we replaced the UE with a couple of ad hoc modified SIP clients (e.g., Minisip [7] and Ekiga [8]) made capable of handling both CCP and BFCP protocol messages. In addition, we developed a new client, which we will discuss in a following section. Distributed Conferencing Scenario This section deals with the design and implementation of a novel architecture for distributed conferencing, which has been the main subject of our work since we completed the realization of the CONFIANCE centralized framework. Under the assumption that all conference participants refer to the focus in the home network of the conference initiator, the IMS centralized conferencing solution keeps on working also in the scenario where the conference participants belong to networks owned by different telecom operators. However, in a fully distributed scenario, the preceding case should be dealt with by providing each involved network with a specific focus managing the associated local users who subscribed to the conference. It is up to the focus in the conference initiator’s home network to provide all other focus entities with up-to-date conference information. Such foreign focus entities thus play a twofold role. On one hand, they act as a regular conference focus for the participants belonging to their underlying managed network; on the other, they appear as normal participants to the focus in the conference initiator’s home network. This requires that a dedicated communication channel exist among the distributed focus entities participating in the conference. This channel is used to exchange conference information as well as to manage synchronization issues. To make the preceding functionality available, we have modified the standard behavior of the IMS SIP-AS/MRFC component by providing it with the capability to manage the spreading of messages to neighboring IMS domains. Coming to the mapping process (sketched in Figure 17.2), we replaced the UE with an integrated client able to offer both media streaming and conference management/monitoring functionality. As we will explain in the next section, this client has been implemented by exploiting an open source

389

IMS-Based Conferencing Services: An Engineering Approach Client C – Spark/MiniSip

Access Network

IMS Core Network Client C Home Network

S2S Channel

S2S Channel

IP Backbone

IP Backbone

Client A – Spark/MiniSip

Access Network

Client D – Spark/MiniSip

S2S Channel

S2S Channel IMS Core Network Client A Home Network

Client B – Spark/MiniSip

Access Network

S2S Channel

IMS Core Network Client D Home Network

IP Backbone

Access Network

Access Network S2S Channel Client E – Spark/MiniSip

Figure 17.2 Distributed conferencing and IMS: proposed mapping.

XMPP (extensible messaging and presence protocol [9]) client called Spark [10], which we extended by (1) integrating an open source SIP stack called MjSip [11], (2) providing a JNI (Java native interface) wrapper of the BFCP library we developed ourselves [12], and (3) adding the ability to handle CCP protocol messages. We also replaced the standard IMS SIP-AS element with a component we implemented ourselves that is made of two parts. One part is the previously mentioned enhanced version of the Asterisk MeetMe application; the other is an ad hoc extended version of an instant messaging (IM) server called Openfire [13]. This latter entity plays a key role in the distributed scenario because it enables the effective management of the needed communication procedures among several IMS domains.

DCON: A Distributed Conferencing Framework The distributed conferencing architecture we defined has been conceived to be highly reliable and scalable. It has been called DCON (distributed conferencing) while at the same time explicitly recalling the previously mentioned XCON model. DCON is based on the idea that a distributed conference can be set up by appropriately orchestrating the operation of a set of XCON focus elements,

390


each in charge of managing a certain number of participants distributed across a geographic network. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas interfocus interaction has been completely defined and specified by us. We will here describe a set of protocols we identified that are complementary to the call signaling protocols and are needed for supporting advanced conferencing applications. Framework Requirements In order to build distributed conferencing on top of the already available centralized conferencing framework, we basically need to introduce additional functions: (1) a coordination level among conference focus entities, (2) a way to distribute conference state information effectively, (3) some means to get centralized protocols to work in a distributed environment, and (4) a mechanism to distribute the media mixing process. A more in-depth overview of these and other requirements is provided in the “Interfocus Interaction” section. The coordination level is needed in order to manage a distributed conference along its entire life cycle. For instance, once a user decides to create a new conference, the corresponding conference focus has to distribute conference information to all other foci to enable other potential participants to retrieve the needed data and possibly subscribe to the event. We assume that all the operations needed inside a single conference “realm” are managed via the XCON protocols and interfaces, as implemented in CONFIANCE. Hence, each single realm continues to be based on a star-topology graph for all that concerns the call signaling part. The various available stars are then connected through an upper-layer mesh-based topology providing interfocus communication. As to the second point mentioned before, it looks clear that a way to propagate information about conferences is needed when switching the view from a centralized to a distributed perspective. Indeed, whenever a new conference is created (or an active conference changes its state), such an event has to be communicated to all interested (or active) participants. Given the intrinsic nature of the distributed framework, the actual flow of information will always foresee the interaction among conference focus entities for both conference information exchanging and state change notifications. Conference state propagation can take place in a number of alternative ways. For instance, each focus might flood the received information across the interfocus communication mesh, thus guaranteeing that potential participants belonging to heterogeneous islands can be reached. In such cases, focus entities are stateful (i.e., each of them stores information about current sessions and forwards such information to all peering entities in order to bring them up to date with respect to available conference sessions). On the other hand, a distributed repository might be employed for the sake of storing conference information. Focus entities would access this.

391


XMPP (BFCP SIP (BFCP Enabled) Enabled)

S2S Server to Server Channel XMPP (BFCP Enabled) SIP (BFCP Enabled)

S2S Server to Server Channel

XMPP (BFCP Enabled)

S2S Server to Server Channel S2S Server to Server Channel

SIP (BFCP Enabled)

S2S Server to Server Channel

SIP (BFCP Enabled) XMPP (BFCP Enabled)

Figure 17.3 DCON design: the stateful approach.

repository both to publish (either upon creation of a new conference or to notify a change in the state of an active conference) and to retrieve information about active conferences (e.g., when a new participant wants to access the list of ongoing/scheduled conference sessions he or she might be interested in joining). In this latter case, focus entities are stateless. Additional mechanisms for interfocus interaction can be envisaged; the most interesting one is a pure peer-to-peer (P2P) approach. A study of such an approach in our architecture is currently being carried out. Framework Design DCON has been conceived as a large-scale evolution of our CONFIANCE framework. We deploy our architecture on top of a two-layer network topology (see Figure 17.3). The top layer is represented by an overlay network in which each node plays the role of the focus element of an XCON “island.” The lower layer, in turn, is characterized by a star topology (in which the central hub is represented by the focus element) and is fully compliant with the XCON specification. In the DCON scenario, communication among different islands becomes of paramount importance. To this purpose, we are adopting

392


the so-called S2S (server to server) module of the XMPP protocol. XMPP has been standardized by the IETF as the candidate protocol to support instant messaging, e-presence, and generic request–response services, and it looks to us to be the ideal communication means among DCON focus entities. In the following section we will present a prototype solution based on the stateful approach. A stateless implementation of the overall architecture is currently being carried out by our research group and is not the subject of this chapter. Furthermore, as already mentioned, we are also studying the possibility of exploiting P2P mechanisms (e.g., DHT [distributed hash table]). DCON and the IMS Architecture The SIP definitely represents one of the fundamental choices upon which the IMS architecture is based. In fact, it is taken for granted that any IMScompliant implementation of a service should rely on SIP for all that concerns the setup of a communication session. During the design phase of the DCON framework, we somehow departed from this guideline because we assumed that interaction between conferencing clients and the conference management entities can exploit either SIP or an alternative protocol. More precisely, we gave our clients the capability to interact with the framework by means of an instant messaging paradigm. Hence, a DCON conference can be created and managed through triggers issued either from an enhanced SIP client (i.e., a client supporting SIP as well as BFCP and a suitable conference control protocol) or from the integrated client we already mentioned and that will be described in more depth in a subsequent section.

DCON Implementation In this section we provide some useful information about the current implementation of the DCON framework. We will here focus on a prototype that implements the DCON basic functionality by assuming a stateful scenario. Source code and documentation of the presented prototype can be found at the official project’s Web page on sourceforge [14]. Figure 17.4 depicts the main implementation choices of the DCON architecture. The right side of the picture presents the logical view of the server, integrating our Asterisk-based CONFIANCE implementation of the XCON focus (upper box) with a new module specifically conceived for the spreading of conference events (which we called SPACE). SPACE has been realized as a plug-in for Openfire (lower box), a popular open source instant messaging server. We chose Openfire because it comes with a native implementation of the previously mentioned S2S channels. SPACE actually represents a key component of the architecture because it (1) enables interfocus communica-

393

IMS-Based Conferencing Services: An Engineering Approach DCON Focus

DCON Client Confiance MjSip

MeetMe & FCS BFCP Participant Scheduler

Scheduler Client

AMI

Gateway

Data Storage Space Client

XMPP

Spark DCON Enabled

SPACE

Database

Presence Manager

Dispatcher S2S Manager

Openfire DCON Enabled

Figure 17.4 Implementation of the DCON architecture.

tion through the exchanging of conference information and (2) forwards any natively centralized protocol message to all involved XCON clouds. In order to perform these two functions, the needed interaction between Openfire and Asterisk happens through the already available Asterisk manager interface (AMI) and an ad hoc protocol (called XDSP [XCON–DCON synchronization protocol]) [16]) that we developed “from scratch.” Inside DCON, communication between the legacy CONFIANCE modules and the newly created spreading components takes place on the basis of an asynchronous paradigm in which a number of events are generated by CONFIANCE modules whenever something relevant happens in the XCON island they are currently supervising (Figure 17.5). Furthermore, whenever a centralized protocol message is to be received by a different XCON cloud, it is forwarded from the CONFIANCE gateway module to the related DCON focus entity. The left side of Figure 17.4 presents a logical view of the DCON client. It has been designed as an integrated entity realized as a plug-in for Spark, an open source cross-platform client for the XMPP protocol that is able to interact with the framework by means of SIP (MjSIP in the figure) as well as BFCP (participant), CCP (scheduling client), and instant messaging (SpaceClient).

394


Local Event Storing

CONFIANCE Event Manager Interface

Event Notification

Asterisk

Database Active Focus entities

SPACE Openfire

Remote Event Storing

Incoming Session

S2S

Outgoing Session

Figure 17.5 The spreading of conference information.

Interfocus Interaction The SPACE module has been conceived to enable DCON functionality on both the server and the client sides. The following paragraphs will explain the respective roles in further detail. Server Side On the server side, according to Romano et al. [17], we had to introduce support for the following new features: Core functionality of the DCON focus. We concentrated our efforts on the integration between the Asterisk-based CONFIANCE server and the newly introduced DCON Openfire component. In order to offer a richer experience to users, we also implemented a direct communication channel with the CONFIANCE XCON scheduler for session management. Both of the previously mentioned features rely on the existence of a conference database, which we also implemented from scratch. The database contains relevant information regarding both active and registered DCON conferences. Focus discovery. We chose to implement this new feature based on a client-driven IM presence service. Whenever the first client becomes active in a DCON cloud, the related focus entity opens an S2S channel toward all other focus entities of which it is aware, thus triggering the spreading phase. Information sharing. Once the S2S channel has been set up as previously explained, the focus entities at both edges of the channel start sending each other their stored data. Data flowing along the S2S channel are generated by triggers coming from the associated CONFIANCE module. As depicted, whenever something relevant happens in an XCON cloud, CONFIANCE raises an event through the Asterisk manager interface. Such an event is then intercepted by the SPACE


395

plug-in, which—in addition to alerting all the associated clients— takes care of forwarding it across all established outgoing sessions. Distributed conference management. As already stated, in order to allow users access to remotely created conferences, we had to provide a mechanism enabling transparent management of both locally and remotely created conference instances. We carried out this task by assuming that all conferences registered at the same focus are characterized by a common prefix. In such a way, the gateway component of the focus is able to determine whether a request has to be processed locally or must be forwarded to the appropriate peer entity through the S2S channel. Centralized protocol routing and dispatching. Having in mind the previously mentioned assumption about conference prefixes, every time a centralized protocol message has to be dispatched, it is encapsulated in the payload of an ad hoc XMPP packet and sent to the appropriate focus entity over S2S channels. Natively centralized protocol messages include, but are not limited to, any protocol defined and specified in the XCON framework (e.g., CCP and BFCP). Distributed mixing. As soon as two or more centralized conferencing islands get connected in order to provide for a distributed conferencing scenario, we also cope with the issue of mixing media flows generated by the conference participants. In order to optimize the performance of the overall architecture, each focus is in charge of mixing the media streams of the island it supervises and subsequently sending it over an RTP trunk to all the other foci involved in the scenario. Client Side On the client side, we developed from scratch an integrated component that offers the following functionality: (1) retrieval and visualization of conference information, (2) creation of a new DCON conference, (3) joining (and unjoining) an existing DCON conference, and (4) support to moderation. In the following section we will briefly touch on all of the previously mentioned points. Regarding the visualization of conference information, we provided the Spark client with a dedicated panel showing the details (e.g., IP address of the reference focus, conference identification number, involved media, conference status) about both active and scheduled DCON conferences. Information shown to the user is retrieved through the exchanging of XMPP messages across a dedicated channel connecting the client to its reference focus. As described in the previous section, upon activation of the first connection in an XCON cloud, the focus opens the S2S channels toward the peering entities and immediately thereafter sends the retrieved conference information to the connecting client. Moreover, if an active connection

396

IP Multimedia Subsystem (IMS) Handbook SIP/IAX/H323/PSTN etc. DCON Client

Scheduling Protocol Binary Floor Control Protocol XMPP

DCON Focus

(1) Create Conference (2) Conference Created: “CONF-ID” (3) SIP call to number “CONF-ID” (to join conference “CONF-ID”) (4) IVR-based messages (Welcome, Muted Status, etc.) (5) SIP re-INVITE (BFCP info encapsulated in SDP body)

(6) Floor Request (7) Floor Request Status (Pending)

(10) Notify Chair Decision

(8) Forward the Request to the Chair (9) Chair Decision

. . Figure 17.6 Creation and joining of a DCON conference.

between the client and the focus is already in place, it is nonetheless possible for the client to asynchronously contact its reference focus in order to have up-to-date information about available conferences. As to the creation and joining of a new DCON conference, we show in Figure 17.6 the relevant information flow. The conference is created by sending a CCP message (message number 1 in the picture) to the CONFIANCE scheduler across a direct connection between the client and the CONFIANCE focus. Upon reception of such a message, the server’s scheduler component takes care of instantiating a new conference, whose information is sent back to the client (message number 2 in the picture). This information can be used by the MjSIP module to place the SIP call needed to join the newly created conference (message number 3). Once the subsequent re-invite message is received, the client makes use of the BFCP parameters contained there in order to create and show the BFCP participant user interface, thus enabling the required moderation features.

397

IMS-Based Conferencing Services: An Engineering Approach SIP/IAX/H323/PSTN etc. DCON Client

Scheduling Protocol Binary Floor Control Protocol XMPP

DCON Focus_1

XMPP

DCON Focus_2

(1) Query Conferences (Active/Registered) (2) Conferences: List of Conferences (3) SIP Call to Number “CONF-ID” (to join conference “CONF-ID”)

(6) IVR-based Messages (Welcome, Muted Status, etc.)

(4) Add User Message (5) User Added Message

(7) SIP re-INVITE (BFCP info encapsulated in SDP body) (8) Floor Request

(9) Dispatched Floor Request (10) Dispatched Floor Request Status (Pending)

(12) Floor Request Status (Pending)

(11) To the Chair (13) Chair Decision

(15) Notify Chair Decision

(14) Dispatched Chair Decision

. .

Figure 17.7 Joining of a remote DCON conference.

Obviously, the presented scenario is related to the joining of a (newly created) local conference. Otherwise, if a user wants to participate in a conference hosted by a remote focus, the message flow is quite different, as depicted in Figure 17.7. As already said, in this case the interaction between the client and its focus does not change. The only difference is in the fact that, behind the scenes, a number of messages are exchanged between the involved foci (i.e., the client’s reference focus on one side and the focus supervising the remote cloud where the conference was originally created on the other side) in order to effectively add the user to the conference and correctly generate the re-invite message.

DCON Scalability Analysis Preliminary Considerations The objective of this section is to demonstrate how the migration from a centralized platform to a distributed environment can improve the scalability of the overall architecture. The performance tests we carried out focused on

398


two aspects: (1) the number of users the system is able to manage and (2) the CPU load and hardware resource consumption, given a certain number of users in the system. In both cases we exploited the SIPp (http://sipp.sourceforge.net) tool, an open source performance testing tool for the SIP protocol that generates traffic according to a fully customizable XML scenario file. Although this tool includes some basic template files for the most common call scenarios, we nonetheless had to create our own in order to manage the re-invite message sent back from our CONFIANCE server together with the subsequent replies that constitute the second three-way handshake characterizing the joining of a conference. This re-invite and its consequent renegotiation always happen when a SIP client joins a conference because the BFCP data needed by the client (i.e., the transport address of the floor control server and the related identifiers) are encapsulated in the re-invite’s session description protocol (SDP) body as specified in Camarillo [22]. Another useful feature of SIPp is the possibility to send media traffic (both audio and video) through real-time transport protocol (RTP)/pcap replay, thus not limiting the tests only to call-signaling-related matters. Using SIPp, we were thus able to stress both the centralized and the distributed platform, as we will see in the next two subsections. Centralized Scenario Figure 17.8 illustrates the testbed configuration in the case of the centralized conferencing scenario. The SIPp console is used to control and coordinate a single test remotely by issuing commands to the call originating server (SIPp stresser in the figure). This server, in turn, creates and sends call requests to the CONFIANCE server in accordance with the SIPp console indications, thus emulating a real-world call profile. During a test lifetime, the logging database is continuously updated with information about the CONFIANCE server status. We then exploit the gathered information in order to perform offline analysis of the collected data and evaluate the results. We remark that all the machines used for the testbed (except the SIPp console, which in our case was a Sony Vaio laptop but might be any host equipped with a network interface) are hosting a Linux Fedora Core 6 operating system equipped with a 2.6.15 kernel. They have a 3.2-GHz Intel XEON CPU and 2-GB RAM. Bandwidth was not a limiting factor for the performance evaluation because we used a dedicated gigabit ethernet network for the campaign. The experimental campaign we conducted was based on the realization of a great number of tests for a single scenario. This was done in order to avoid basing our analysis on a potentially biased set of data. For each scenario, we here present a single result representative of the average case for that scenario. As already stated, we focused on two different aspects of scalability: total number of supported users on one side and resource consumption on the other. In the tests we present, when our target was to evaluate the number of users that could access the system, we did not make use of SIPp’s pcap replay function. This was done in order to guarantee that each client only generated


399

Centralized System Under Test SIPp Stresser

SIP Calls

Asterisk (Confiance)

SIPp Console

Test Result DB

Figure 17.8 Testbed configuration: centralized scenario.

signaling traffic without sending any RTP packet to the focus, even though it received the RTP packets resulting from the mixing operation from the focus itself. In this case, of course, the focus just forwarded silence (i.e., empty RTP streams) because there was no media flow to mix. Doing so, we were able to cut down the number of operations the focus had to carry out, such as transcoding and potentially dropping or mixing of packets according to the media floor status in the BFCP floor control server. We were thus able to point out an intrinsic limitation of the Asterisk server, which does not allow having more than 1,024 Zaptel (Jim Dixon’s open computer telephony hardware driver API used by Asterisk) pseudochannels open simultaneously. For the sake of completeness, we remark that in order to reach the previously mentioned limit, we had to modify the number of open file descriptors the operating system allows, setting it to its maximum value of 65,535. These Zaptel pseudochannels are needed by the MeetMe application module for creating a shared “bus” for the management and transport of the mixed audio related to the conference. Furthermore, they are also used for realizing so-called “listeners” exploited by users in order to get attached to the previously mentioned channel. These kinds of listeners are the same that MeetMe exploits to make audio recordings of running conferences when needed. Because of this limitation, and supposing that there is only one active conference with no active recording running in the background, it is not possible to have more than 1,022 users. In fact, as soon as a conference is created and

400

IP Multimedia Subsystem (IMS) Handbook 100 90 80

CPU Load (%)

70 60 50 40 30 20 10 0

0

50

100

150 Calls

200

250

300

Figure 17.9 CPU utilization in the centralized scenario.

becomes active, two channels are used by MeetMe itself; other channels are used when new users join the conference. On the other hand, when we decided to involve RTP traffic in our analysis work, we focused our attention on resource consumption. We found that the bottleneck is definitely represented by the CPU utilization level rather than other relevant hardware parameters, such as available RAM memory. In the following and in the next subsections as well, we will focus just on CPU as the key performance indicator. When dealing with the CPU performance evaluation, we made use of the pcap replay functionality so that each user sent both SIP and RTP traffic. This was done because both the media transcoding and the BFCP functionality require processing cycles and resources. Figure 17.9 shows that in the presence of only one active conference and 300 users who joined it, the CPU load of the focus managing that conference is about 99.42%. This value comes from a mean operation on all the numerous data collected. This result (i.e., 300 users as the peak value for the centralized scenario in the presence of media flows) will be used as a benchmarking parameter in the following section, which discusses the achievable performance improvement in the distributed case. Distributed Scenario Figure 17.10 illustrates the testbed configuration in the case of the distributed conferencing scenario with just two interconnected conferencing islands.


401

Distributed System Under Test Wildfire_1

Wildfire_2

S2S XMPP Channel

RTP Channel

SIPp stresser_1

Asterisk_1-main (Confiance)

Asterisk_2 (Confiance)

SIPp stresser_2

Test Result DB

SIPp Console

Figure 17.10 Testbed configuration: distributed scenario with just two XCON islands.

With respect to the centralized case, we now find the Openfire component mentioned in the “DCON: A Distributed Conferencing Framework” section, which is specifically dedicated to information spreading and protocol dispatching. We also notice that the SIPp console is now used to manage both of the available SIPp_stresser entities. In the following subsection we will present results obtained in the distributed scenario for an increasing number of interconnected islands. Namely, we will analyze in detail the results obtained, respectively, with two, three, and four conferencing clouds. We do not provide any illustration of the three- and four-element scenarios, which do not present any new features when compared to the previously depicted two-element case. With reference to the tests, we have already explained how all the users behind a remote focus are seen from the main focus. Although their signaling and control are managed through protocol dispatching and interfocus synchronization, their media (both audio and video) are locally mixed at the remote focus and then sent to the main focus as if they came from a single user. The same thing obviously happens for the media flowing from the main focus toward the remote foci as well. The main focus locally mixes

402

IP Multimedia Subsystem (IMS) Handbook 4500

4076

4000

Number of Users

3500

3060

3000 2500 2042

2000 1500 1000

1022

500 0

1

2 3 Number of Islands

4

Figure 17.11 Number of users supported in the four analyzed scenarios.

the media coming from its local users and from all the remote foci involved in the conference to which it forwards them. Thus, because only one RTP trunk per medium is needed between each remote focus and the main focus, we expected the maximum number of participants to grow linearly with the number of DCON islands. This statement was promptly confirmed by our tests in all cases (two-, three-, and four-island topologies). It is important to notice that each remote focus attached to the main focus means a new listener on the shared bus channel and thus one less available channel for local users. This last statement is true for both the main and the remote foci. Figure 17.11 summarizes the preceding considerations by showing the linear increase in the number of supported users in the four scenarios considered. From another point of view, we wanted to study how the CPU performance improved when moving from a centralized to a distributed environment while also increasing the distribution index (which substantially represents the number of islands). With this goal in mind, we performed several testing experiments, assuming, as in the centralized case, the presence of just one active conference with 300 participants. Specifically:

1. We first considered a two-island topology with 150 local users and 150 remote users.

2. We then moved to a three-island scenario with

a. 100 local users and 200 remote users, equally split between the two available remote foci; and

403

IMS-Based Conferencing Services: An Engineering Approach 100

Main focus Remote focus

90 80

CPU Load (%)

70 60 50 40 30 20 10 0 0

50

Local Calls

100

150

Figure 17.12 CPU utilization in the distributed scenario with two XCON islands: case 1.

b. 150 local and 150 remote users, equally split between the two available remote foci. 3. We finally considered a four-island scenario with

a. 75 local users and 225 remote users, equally split among the three available remote foci; and

b. 150 local and 150 remote users, equally split among the three available remote foci.

In the first scenario, the CPU load of the main focus was about 30.04%, whereas the remote focus was about 20.19%, as shown in Figure 17.12. In case 2a, the main-focus CPU level was about 20% and the remote foci were both loaded at about 18%. This is shown in Figure 17.13. In case 2b, the main focus took up 31.2% of the CPU, and the remote foci were almost unloaded (CPU utilization level at about 12%). This is witnessed in Figure 17.14. In the four-island scenario, case 3a is characterized by 12.66% CPU consumption at the main focus and 12% at the remote foci (see Figure 17.15). On the other hand, case 3b accounts for 32.4% CPU load at the main focus and 7.8% at the remote foci. This result is shown in Figure 17.16.

404

IP Multimedia Subsystem (IMS) Handbook 100

Main focus Remote focus 1 Remote focus 2

90 80

CPU Load (%)

70 60 50 40 30 20 10 0

0

10

20

30

40

50 60 Local Calls

70

80

90

100

Figure 17.13 CPU utilization in the distributed scenario with three XCON islands: case 2a. 100

Main focus Remote focus 1 Remote focus 2

90 80

CPU Load (%)

70 60 50 40 30 20 10 0

0

50

100 Local Calls

Figure 17.14 CPU utilization in the distributed scenario with three XCON islands: case 2b.

150

405

IMS-Based Conferencing Services: An Engineering Approach 100

Main focus Remote focus 1 Remote focus 2 Remote focus 3

90 80

CPU Load (%)

70 60 50 40 30 20 10 0

0

10

20

30

40 Local Calls

50

60

70

Figure 17.15 CPU utilization in the distributed scenario with four XCON islands: case 3a. 100

Main focus Remote focus 1 Remote focus 2 Remote focus 3

90 80

CPU Load (%)

70 60 50 40 30 20 10 0

0

50

100 Local Calls

Figure 17.16 CPU utilization in the distributed scenario with four XCON islands: case 3b.

150

406 Number of Number of Islands Local Users 1 300 2 150 3 100 3 150 4 75 4 150

IP Multimedia Subsystem (IMS) Handbook Number of Main Focus Remote Users CPU Load 99.4% 150 30.04% 200 (100/100) 20% 150 (75/75) 31.05% 225 (75/75/757) 12.66% 150 (50/50/50) 32.4%

Remote Focus 1 CPU Load 20.19% 18% 12% 12% 7.8%

Remote Focus 2 CPU Load 18% 12% 12% 7.8%

Remote Focus 3 CPU Load 12% 7.8%

Figure 17.17 A comparative table summarizing performance figures.

Comparative Analysis, Considerations, and Comments In this subsection, we analyze the results presented earlier, showing how the migration from a centralized to a distributed paradigm considerably improves the performance in terms of scalability (see Figure 17.17). We have already shown the linear growth in the number of users related to the number of involved DCON islands. What we want to remark on here is how our tests showed huge improvement in terms of CPU performance; in the centralized scenario examined, the CPU load was near 100%, but it reduced to about 30% in the two-islands case, 20% in the three-islands scenario, and about 12% in the four-islands scenario. Furthermore, we notice that the sum of the CPU loads of all the foci involved in the various scenarios was also lower than the load of the centralized platform. Finally, as shown by experiments presented in case 1, case 2b, and case 3b, we note how the distribution of the remote users behind different remote foci causes a small decrease in the performance of the main focus. This is reasonable because we know that the main focus must, in such cases, spread conference events to all the active foci on the server-to-server channels, thus becoming a potential bottleneck for the whole system. Thus, in order to reduce the computational load of the main focus and remembering that a DCON focus is conceived as an integration of an Asterisk-based CONFIANCE implementation and a SPACE module for the Openfire server, it looks feasible (and we have actually envisaged it since the design phase of our architecture) to detach these two components by deploying them to different machines.

Related Work The architecture we presented in this chapter focuses on two main aspects: (1) compatibility with the IMS framework and (2) capability to offer advanced conferencing functionality in a distributed scenario. Although there is a rich literature on each of these points, when considered alone, to the best of our knowledge, no integrated effort has been made to date that tries to provide


407

a real architecture by being IMS compliant and able to offer distributed conferencing functionality. This is mainly because no agreed-upon solution has been so far designated with respect to some crucial points, such as the choice of the most suitable paradigm for distributed conferencing, as well as its integration in the general IMS architecture. With respect to the first point, no official IETF activity, except our personal draft proposals [15–17], has started on the distributed scenario yet. Nonetheless, a few research works have already proposed moving from a centralized to a distributed perspective. This is the case, for example, of Cho et al. [18], who propose a model trying to extend the SIPPING (session initiation proposal investigation) approach to a distributed scenario. With respect to the cited work, we are proposing an implementation of the distributed framework based on an extension to the XCON approach. When compared to SIPPING, XCON can be considered a much more focused effort because it deals only with conferencing, for which it introduces advanced functionality such as floor control and the independence from the choice of SIP as the media signaling protocol. As a further remark, Cho et al. [18] do not provide any implementation of their proposed architecture. All information contained in their paper has been retrieved through simulations. Some contact points with our work can also be found in Yang, Huadong, and Zhang. [19], who propose a model for scalable videoconferencing based on the dynamic delegation of the management of conference services through an object-oriented approach. The cited paper still conforms to a centralized paradigm for what concerns session management functionality. Another remarkable research work is the one proposed by Wenjun et al. [20] that explores the possibility of using a service-oriented architecture in order to provide flexible and scalable conferencing facilities. However, the cited project does not seem to be oriented toward a future integration with the IMS architecture. On the IMS side, some efforts have already been devoted to the realization of testbeds, as in the case of Magedanz, Witaszek, and Knuettel [21]. Here, the authors propose a testbed for multimedia services support based on the IMS specification. Finally, it is worth citing the work of the IETF P2PSIP (peer-topeer session initiation protocol) working group. Nonetheless, the efforts of this group are not explicitly focused on conferencing itself but, rather, aim at leveraging the distributed nature of P2P to allow for distributed resource discovery in a SIP network, thus eliminating (or at least reducing) the need for centralized servers.

Conclusions and Future Work In this chapter we presented an IMS-compliant architecture aimed at offering a distributed conferencing service with enhanced functionality, such as

408


conference scheduling facilities, full audio and video support, and conference moderation. We have currently implemented a prototype capable of effectively supporting the creation and management of a distributed conference in a scenario involving a number of IMS-compliant core networks interconnected through an ad hoc created communication channel. However, many challenging issues still have to be faced. In fact, a further direction of work deals with the implementation of the stateless/P2P scenario for distributed conferencing as well as the continuation of the thorough experimental campaign aimed at evaluating the performance of the overall framework and identifying its potential bottlenecks (with special regard to scalability and reliability properties). Finally, a more accurate study upon the full interoperability between the IMS specification and our approach is in progress; this envisages the potential exploitation of additional experimental IMS core elements currently under specification (e.g., service capability interaction manager [SCIM]).

Acknowledgments This work has been carried out with the financial support of the European projects NetQoS, OneLab, and Content. Such projects are partially funded by the EU as part of the IST Program within the Sixth Framework Program. The authors of the chapter would also like to acknowledge Giovanni Saponetta for his invaluable psychological support. Giovanni is the author of the most romantic song ever written, “Love with a Married Man,” which does represent the ever-inspiring soundtrack of our work.

References

1. Barnes, M., C. Boulton, and O. Levin. 2008. A framework for centralized conferencing. draft-ietf-xcon-framework-10.txt 2. Camarillo, G., J. Ott, and K. Drage. 2006. The binary floor control protocol (BFCP). RFC4582. 3. CONFIANCE Project’s page (sourceforge). http://confiance.sourceforge.net 4. 3GPP. 2006. Conferencing using the IP multimedia (IM) core network (CN) subsystem; stage 3 (TS 24.147 7.1.0). Technical report. 5. OpenSER—the open source SIP server. http://www.openser.org 6. Asterisk—the open source PBX. http://www.asterisk.org 7. MiniSIP—an open source SIP user agent. http://www.minisip.org 8. Ekiga—an open source VoIP and video conferencing application. http://ekiga.org


409

9. Saint-Andre, P. 2004. Extensible messaging and presence protocol (XMPP): Core. RFC3920. 10. Spark—An open source, cross-platform instant messaging client. http://www. igniterealtime.org/projects/spark 11. MjSip—A complete Java-based implementation of a SIP stack. http://www. mjsip.org 12. libBFCP—An open source BFCP library written in C. http://sourceforge. net/projects/libbfcp 13. Openfire—A real time collaboration (RTC) server. http://www.igniterealtime. org/projects/openfire 14. DCON Project’s page (sourceforge). http://dcon.sourceforge.net 15. Romano, S. P., T. Castaldi, L. Miniero, and A. Buono. 2007. A framework for distributed conferencing. draft-romano-dcon-framework-01.txt 16. Romano, S. P., T. Castaldi, L. Miniero, and A. Buono. 2007. Requirements for the XCON–DCON synchronization protocol. draft-romano-dcon-xdsp-reqs-01.txt 17. Romano, S. P., T. Castaldi, L. Miniero, and A. Buono. 2007. Requirements for distributed conferencing. draft-romano-dcon-requirements-01.txt 18. Cho, Y., M. Jeong, J. Nah, W. Lee, and J. Park. 2005. Policy-based distributed management architecture for large-scale enterprise conferencing service using SIP. IEEE Journal on Selected Areas in Communications 23:1934–1949. 19. Yang, Z., M. Huadong, and J. Zhang. 2005. A dynamic scalable service model for SIP-based video conference. Proceedings of the 9th International Conference on Computer Supported Cooperative Work in Design, May 24–26, Coventry University, UK. 20. Wenjun, W., F. Geoffrey, B. Hasan, U. Ahmet, and H. Tao. 2006. Service-oriented architecture for VoIP conferencing. International Journal of Communication Systems 19:445–461. 21. Magedanz, T., D. Witaszek, and K. Knuettel. 2005. The IMS playground @ Fokus: An open testbed for next-generation network multimedia services. Proceedings of the First International Conference on Testbeds and Research Infrastructures for the Development of NeTworks and COMmunities (TRIDENTCOM05), February 21–25, Trento, Italy. 22. Camarillo, G. 2006. Session description protocol (SDP) format for binary floor control protocol (BFCP) streams. RFC4583, November 2006.

18 IMS-Based IPTV Oliver Friedrich, Stefan Arbanowski, Adel Al-Hezmi, and Robert Seeliger

contents Introduction.......................................................................................................... 412 Why Provide IPTV Services over NGN?................................................. 412 Related Work and Standardization Activities................................................. 413 Standard Development Organizations (SDOs)................................................ 414 ITU-T ........................................................................................................... 415 Focus Group on IPTV..................................................................... 415 FG IPTV Architecture Work.......................................................... 418 IPTV-GSI........................................................................................... 420 ETSI TISPAN................................................................................................ 420 IPTV Functions Supported by the IMS Subsystem.................... 421 Dedicated Subsystem for IPTV..................................................... 424 Home Gateway Initiative........................................................................... 426 ATIS IIF......................................................................................................... 427 Digital Video Broadcasting (DVB)............................................................ 429 Open IPTV Forum......................................................................................430 Summary and Conclusion.........................................................................430 A Real-World Testbed for IMS-Based IPTV..................................................... 431 FOKUS Media Interoperability Lab......................................................... 431 Introduction..................................................................................... 431 Media Interoperability Lab—A Prototype Infrastructure for IMS-Based IPTV......................................................... 432 Interactive and Personalized Service Scenarios......................... 435 Signaling Flows............................................................................... 436 Summary...................................................................................................... 439 References............................................................................................................. 439

411

412


Introduction “IPTV,” “next-generation TV,” “TV2.0,” “video over IP” (VoIP)—all these words become mandatory and part of the language used when getting in touch with a proposed new kind of media: television and corresponding premium services delivered over IP networks. The most common shortcut, IPTV, which means Internet Protocol Television, describes as a first step nothing more than the delivery of streaming services as live TV channels and video on demand (VoD) over an IP network. But what is so special about that? What makes all big players in the market—from the broadcasters through the IT and software industries and, above all, the telecom operators—so addicted to this technology? At first IPTV and the imaginable services that could be realized using this technology could also be seen as a new facet of the so-called interactive TV, which was mainly built around the multimedia home platform (MHP) in the late 1990s, struggling with slow and ugly user interfaces and disqualified by the missing, slow, or expensive back channel. With widely available broadband connections over xDSL, cable, or even mobile networks, the main drawback of this technology has disappeared. Powerful CE (consumer electronic) equipment, better video codecs, and new service delivery platforms are additional features that seem to make it worthwhile to start a second approach on interactive TV services. With these new and improved techniques in mind and the vision of the so-called fixed mobile broadcast convergence (FMBC) allowing the use of services across the borders of terminals offering personal mobility; the triple or quadruple play defining Internet, telephony services, and IPTV; and the quadruple play bringing the mobile issues back into this vision, a new understanding in the use and creation of services may become reality. Going one step beyond the multiplay characterizes a new vision of multiple services interaction by bringing also issues like mobility, interactivity, community services, and personalization into view. A general framework to provide these converging services is already there and has been already discussed intensively in preceding chapters: the IP multimedia subsystem (IMS). Originally defined by the 3rd Generation Partnership Project (3GPP) and then adapted by the European Telecommunications Standards Institute (ETSI), Telecoms and Internet Converged Services and Protocols for Advanced Networks (TISPAN) currently evolves toward a platform for the delivery of converged services over all kinds of access networks and makes it therefore an optimal technology also for the IPTV as one facet, or maybe killer application, in this context. Why Provide IPTV Services over NGN? One of the most important requirements supporting IPTV and corresponding streaming services is the guaranteed delivery of contents, which is com-

IMS-Based IPTV

413

posed of various multimedia contents, at least including video streams, in particular, over IP environments. Guaranteed delivery needs involvement of several significant network and service support capabilities, which should be provided by advanced capabilities in addition to the current IP-based besteffort networks, such as enough bandwidth to allow multiple TV channels simultaneously, including high-definition content with bandwidth requirements up to 20 Mbit/s per channel. In the case of providing broad bandwidth, several technologies have been developed based on xDSL that have now become popular access means. The development of fiber technology progressed well enough to initiate actual FTTH (fiber to the home), and some countries already have certain levels of deployments. Other broadband technologies also are being developed in mobile and wireless areas, possibly supporting TV program distributions like HSDPA, 3G Mobile, WiMAX (fixed and mobile), and DMB (terrestrial and satellite). Several features besides bandwidth are necessary to provide guaranteed delivery of IPTV contents. The contents of IPTV should be composed of different media, like video, voice, audio, graphic, and text, which request different treatments in terms of traffic, quality of service (QoS) and quality of experience (QoE), performance, security, interactivity, and reliability. The next-generation network (NGN) is being developed now to support these requirements focused on IP-based transport. Following one of the important features of NGN, separation of service from transport, will allow support of IPTV in a flexible way. Before the NGN, the IP layer mainly supported minimum capabilities called “best efforts.” This caused many difficulties in supporting various services—especially those needed for guaranteed delivery, using traditional IPbased network with limited bandwidth in transport. These difficulties will be overcome through the NGN with managed IP capabilities and enough broad bandwidth, which supports convergence environments among fixed, mobile, and wireless networks.

Related Work and Standardization Activities Although both the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) and the ETSI TISPAN are working on standardizing the architecture of the NGN, it is essentially about the convergence of various access networks toward an architecture that is based upon the Internet transport protocols. Both architectures present a generic multiservice, multiprotocol, multi-access IP-based framework that aims at becoming the reference model to achieve convergence between fixed and mobile networks based on the Internet protocol. This model is based upon the concept of cooperating subsystems sharing common components. This architecture.

414


enables smooth addition of new subsystems to cover new demands and service classes and ensures maximum common usage of network resources, applications, and user equipment (UE). Within this architecture the IMS is a central function that offers control capabilities for delivering multimedia services in a secure, controllable, QoS ensured and chargeable manner. The IMS is primarily specified by the 3GPP and 3GPP2, based on the Internet protocols and then adapted by the ITU-T, ETSI, and PacketCable 2.0 NGN architecture. Furthermore, the network attachment subsystem (NASS) or the network attachment control functions (NACFs) and the resource admission control subsystem (RACS) or the resource admission control function (RACF), specified in the TISPAN and the ITU-T NGN architecture, respectively, provide supporting functions on the transport stratum. The NASS/NACF is responsible for dynamic provision of IP address and user authentication, authorization, and location management. The RACS is in charge of QoS control and resource negotiation and allocation between service and transport strata. On the other hand, the TISPAN and the ITU-T, among others, are working currently on standardizing the architecture of an IPTV framework over the NGN; two approaches are followed: namely, a non-IMS-based and an IMS-based IPTV architecture. Though both architectures utilize the NGN components, the non-IMS-based IPTV framework does not make use of any IMS capabilities, compared to the IMS-based IPTV, which utilizes IMS basic functions for providing IPTV services. In spite of the fact that the IMS is built on a point-to-point communication (unicast) model, IMS services do not utilize from the multicast and broadcast capabilities offered by different access networks like the 3GPP multimedia broadcast/multicast services (MBMS) and the digital video broadcasting (DVB). Although both the IMS and MBMS have similar functions, such as authentication, authorization, and QoS procedures, the current specifications do not consider the integration of both subsystems. Because an IPTV session may serve hundred of thousands of users concurrently watching particular content (e.g., sporting event), multicast and broadcast mode are essential for efficient media delivery.

Standard Development Organizations (SDOs) This section will give an extended overview on standardization activities on IMS-based IPTV within the different bodies. Because the main focus currently lies on developing architectures and basic signaling principles for the delivery of streaming services over IMS networks, this section concentrates on the main bodies of ITU-T and ETSI TISPAN and a view to the delivery of these kinds of services to the end device by presenting the Home Gateway Initiatives approach for an IMS-based IPTV gateway.

IMS-Based IPTV

415

ITU-T Focus Group on IPTV Initial discussions on IPTV standardization in international telecommunication (ITU-T) started in April 2006 with a request of the ITU-T directorate to check the demand and potential relevance of IPTV for the involved parties. As a result of a consultation meeting, it was agreed to set up a new focus group (FG) on IPTV (FG IPTV). ITU-T’s study group 13 has been assigned as parent group of this FG. With more than 100 participants from all over the world, the support for this group was very strong from the beginning. The following scope of FG IPTV has been agreed to: “The mission of FG IPTV is to coordinate and promote the development of global IPTV standards taking into account the existing work of the ITU study groups as well as standards developing organizations, fora and consortia.” In addition, a set of goals has been agreed on: • definition of IPTV • identification of scenarios, drivers, and relationships with other services and networks • identification of requirements and definition of framework architecture; • review and gap analysis of existing standards and ongoing works • identification of opportunities for ITU-T • identification of activities that ITU-T would encourage other organizations to pursue; • coordination of existing standardization activities; • harmonization of the development of new standards; and • encouragement of interoperability with existing systems where possible. Based on the defined goals, an initial definition approach for IPTV has been defined by FG IPTV: IPTV is defined as multimedia services such as television/video/audio/text/ graphics/data delivered over IP-based networks managed to provide the required level of QoS/QoE, security, interactivity, and reliability. Focus groups are an instrument created by ITU-T that augment the study group work program by providing an alternative working environment for the quick development of specifications in their chosen areas. Standardization work is carried out by the technical study groups (SGs) in which representatives of the ITU-T membership develop recommendations (standards) for the various fields of international telecommunications. SG 13 is the lead study group for NGN and satellite matters.

416


FG IPTV structuring includes: WG1: architecture, requirements, and service scenarios; WG2: QoS and performance; WG3: service security and content protection; WG4: IPTV network control; WG5: end system and interoperability; and WG6: middleware, application, and content platforms. A set of documents has been created during the FG lifetime (Table 18.1): Document 1, the IPTV service scenarios document, provides a list of IPTV use cases that are informative illustrations of how IPTV services can be designed, deployed, and operated. From this perspective, use cases have been classified according to an IPTV service taxonomy that includes (but is not limited to) on-demand services, advertising services, and broadcast services. Document 2 describes the IPTV functional architecture intended to support IPTV services based on the IPTV service requirements and definitions. Starting from a basic description of IPTV roles and services, a high-level IPTV functional model is outlined. This model is then developed into a set of functional architectures that support NGN and non-NGN transport networks as well as operation modes with or without IMS. Document 3 describes IPTV service scenarios. Document 4, gap analysis, helps to determine how well the specification answers a set of requirements or use cases but has not been completed during the FG IPTV lifetime. Document 5 contains quality of experience requirements for IPTV services. Document 6 describes a set of traffic management mechanisms to facilitate the efficient support of IPTV services over the network infrastructure. Traffic management mechanisms for the home, access, and core networks are discussed. Document 7 describes specific mechanisms to prevent packet loss and the applicability of these mechanisms to IPTV services and network conditions. Document 8 is about performance measurements because this needs to be monitored at the customer premises, key aggregation points, and interconnect points between disparate network domains for successful deployments.

417

IMS-Based IPTV Table 18.1 FG IPTV Output documents WG

Documents 1

IPTV service requirements

1

2

Architecture document

3

Service scenario for IPTV

4

Gap analysis

5

Quality of experience requirements for 2 IPTV

6

Traffic management mechanism for support of IPTV services

7

Application layer error recovery mechanisms for IPTV

8

Performance monitoring for IPTV

9

IPTV security aspects

3

10

IPTV network control aspects

4

11

IPTV multicast framework

12

IPTV-related protocols

13

Aspects of IPTV end systems— terminal device

14

Aspects of home networks supporting IPTV services

15

IPTV middleware, applications, and content platforms

16

Toolbox for content coding

17

IPTV middleware

18

IPTV metadata

19

Standards for IPTV multimedia application platforms

20

Vocabulary of terms

Architecture, requirements, and service scenarios

QoS and performance

Service security and content protection

IPTV network control 5

End system and interoperability

6

Middleware, application, and content platforms

All

Document 9 specifies security aspects addressing threats, requirements, architecture, and mechanisms that pertain to security and protection aspects of IPTV content, services, networks, terminal devices, and subscribers (end users). Document 10 handles IPTV network control aspects to address control and signaling matters related to authentication and authorization, content delivery, consumer domain attachment and initialization, QoS, QoE, and security. Document 11 describes functional requirements and frameworks for supporting multicast capabilities in terms of IPTV network control.

418


Document 12 identifies protocols relevant to IPTV services and categorizes these protocols relative to their specific functions in relation to IPTV services. Documents 13 and 14 are guidelines for end device and home network issues. Document 15 presents potential middleware platform candidates. Document 16 is about content coding issues. Document 17 handles those aspects of architecture specific to IPTV middleware and describes the various functions with explanatory definitions where appropriate. Document 18 describes potential metadata formats used in the IPTV environment. Document 19 describes approaches for multimedia application platforms such as MHP and SVG. FG IPTV Architecture Work This section describes ITU-T’s architecture for the IPTV solution that was devised by the FG IPTV. It supports several architectural variants, depending on the use of an NGN base or the use of the IMS as a session control layer but contains large common areas among the three detailed variants. Because the scope of this handbook is limited to the IMS, just this variant will be discussed here. It is also depicted in Figure 18.1. In Table 18.2 the different architectural approaches of FG IPTV are listed. NGN IMS IPTV Architecture The proposed NGN IMS IPTV architecture provides an abstract framework for these kinds of services consisting of different building blocks. This includes: • session client functional block for IPTV session handling; • core IMS functions for IMS signaling; • service user profile functional block maintaining the user profile; • the application functions provide network side enablers such as: • IPTV application function; • SCP functions; • application profile functional block; and • application provisioning functional block • content preparation functions; • application client functions (e.g., the user agent) providing access to the IMS-enabled IPTV network; and • content delivery functions for providing network enablers for streaming media.

IPTV Application Functions

Service User Profile Functional Block

SCP Functions

Metadata

Network Attachment Control Functions (NACF)

Edge Functions

Content & Metadata

Application Profile Functional Block

Control Functions

Content Delivery & Storage Functions

Core Transport Functions

Transport Functions

NGN Transport Stratum Functions

Resource & Admission Control Functions (RACF)

Delivery Protocols

Content Distribution & Location Control Functions

Content Delivery Functions

Content Preparation Functions

Application Functions

Service Control Functions

Core IMS Functions

Access Network Functions

Authentication & Configuration Protocol

Session Protocol

NGN Service Stratum Functions

Service Support Functions

Transaction Protocol

Figure 18.1 NGN IMS IPTV architecture.

Delivery Network Gateway Functional Block

Home Network Functions

Session Client Functional Block

Content Delivery Client Functions

SCP Client Functions

Application Client Functions

ITF

End-User Functions

Transport Management Functional Block

End-User Device Management Functional Block

Content Delivery Management Functional Block

Service Control Management Functional Block

Application Management Functional Block

Management Functions

Content & Metadata Sources

Content Provider Functions

IMS-Based IPTV 419

420


Table 18.2 ITU-T FG IPTV Architecture Variant Full name IPTV architecture for non-NGN network components (including existing networks)

Short term Non-NGN IPTV

IPTV architecture based on the NGN architecture but not based on NGN non-IMS IPTV IMS IPTV architecture based on the NGN architecture and its IMS component

NGN IMS IPTV

IPTV-GSI FG IPTV was set up as a forum with a limited lifetime of 1 year, which was extended to the end of 2007. Thus, it was decided to continue work under the umbrella of a so-called ITU global standardization initiative (GSI) named IPTV-GSI. In accordance with decisions taken at the April 2007 meeting of Study Group 13, the work of the IPTV FG has ended and its documents have been transferred to the appropriate study groups via Study Group 13 for the development of draft recommendations based on the FG outputs as appropriate and for the continuation of the work on the unfinished topics. The ongoing work on the outputs from the IPTV FG will be done by the study groups (based on allocations developed by the IPTV-JCA) with coordinated planning of the activities and through co-located meetings of the involved rapporteur groups to move forward certain areas of the work as appropriate. As part of the establishment of the IPTV-GSI, the membership of the IPTVJCA is being extended to include other standards organizations involved with the ITU-T in the IPTV work stemming from the results of the IPTV FG. Also, an IPTV-GSI technical and strategic review (TSR) process has been set up. This will operate at every IPTV-GSI event (study group meetings and co-located rapporteur meetings) and will bring to the IPTV-JCA any issues requiring guidance or recommendations for action (e.g., concerning work allocation). Ghassem Koleyni (Nortel Networks, Canada) has been appointed as the TSR coordinator. ETSI TISPAN Building upon the work already done by the 3GPP in creating the standardized initiation session (SIP)-based IMS, TISPAN and the 3GPP are now working together to define a harmonized IMS-centric core for both wire

In contradiction to FGs, a GSI embraces different SGs to work jointly on a specific topic. The mandate of the IPTV-JCA has been to support Study Group 13 in its role as parent of the focus group and to ensure that a proper relationship is established and maintained between the focus group and the concerned study groups and that arrangements are put in place to ensure the smooth handover of the results of the focus group.

IMS-Based IPTV

421

less and wireline networks. This harmonized all-IP network has the potential to provide a completely new telecom business model for both fixed and mobile network operators. Access-independent IMS will be a key enabler for fixed/mobile convergence, reducing network installation and maintenance costs,and allowing new services to be developed and deployed rapidly to satisfy new market demands. NGN release 1 was launched by TISPAN in December 2005, providing the robust and open standards that industry can use as a reliable basis for the development and implementation of the first generation of NGN systems. TISPAN is now working on release 2, with a focus on enhanced mobility, new services, and content delivery with improved security and network management. One of these new services is IPTV delivered from NGN infrastructures. There are different views on how IPTV should be integrated into the NGN context, and at least two different approaches are currently under discussion within this body: • IPTV functions supported by the IMS subsystem; and • dedicated subsystem for IPTV. These two approaches differ especially in their view on reusing Core IMS entities and signaling approaches or not. As a basic foundation, both of them rely on work defined in reference 5 dealing with common architectural aspects used by both approaches to determine the impact on shared components independently of the architectural approach taken for delivering IPTV services. In addition, the document describes the use of existing common components (i.e., those defined in reference 3, e.g., UPSF/Home Subscriber Server [HSS]) and subsystems (RACS/ NASS) and new shared functional components. Table 18.3 presents an overview of all documents relevant for IPTV standardization within ETSI TISPAN. This includes Working Group 1 on services and applications, Working Group 2 on architectures, and Working Group 3 for protocol issues. In the following, the two different tracks with their specific views on IPTV in NGN environments will be presented. IPTV Functions Supported by the IMS Subsystem Reference 6, defined by ETSI TISPAN Working Group 2, describes architectures and functions of an IPTV system that makes use of the NGN IMS architecture and its features. This specification has taken IPTV solutions defined

The core IMS provides functionality for authentication, authorization, and signaling for the setup of the service provisioning and content delivery. It routes signaling messages to the appropriate application server or triggers the applications based on settings maintained in the UPSF. For resource reservation and admission control, this function interacts with the RACS.

422


Table 18.3 Relevant TISPAN Documents on IPTV Work item

Document

Title

1042

TS 181 014V0.0.14-9/2007

Requirements for network transport capabilities to support IPTV service

1044

TS 181 016V0.0.9-9/2007

Service layer requirements to integrate NGN services and IPTV

2049

DTS 02049TS 182 028V0.0.9-9/2007

Dedicated subsystem for IPTV functions in NGN

2048

TS 182 027V0.0.17-9/2007

Requirements for network transport capabilities to support IPTV services

2047

(MI)

IPTV common architectural aspects

3127

TS 183 063

NGN-R2—IMS-based IPTV stage 3 specification

3137

TS 183 064

NGN-R2—IPTV subsystem stage 3 specification

by other organizations (such as DVB and ATIS IIF) into account. It is completely based on an IMS-based architecture. With the drawing from Figure 18.2, ETSI TISPAN provides a high-level architecture for the delivery of these kinds of services. In addition to previously described components such as UE, the core IMS, and transport control functions (NASS and RACS), this includes the following functional entities: • Service Discovery and Selection Functions (SDFs and SSFs) for bootstrapping IPTV services and providing Electronic Program Guide (EPG) services; • IPTV Service Control Functions (SCFs) for IPTV session management; and • IPTV Media Control and Delivery Functions (MCFs and MDFs) for streaming media delivery. With this architecture fully specified till the end of summer 2007, ETSI TISPAN Working Group 3 on protocol issues has started specifying a subsequent follow-up document defining detailed functional inter-entity behavior for the different services provided, such as service discovery and selection, requesting live TV, and VoD content. The scope of this so-called stage 3 specification can be summarized as follows: The Stage 3 specification describes the Procedures on the Functional Entities and Call Flows for the protocols and their possible enhancements to support IPTV services based on the architecture and stage 2 information flows described in TS 182 027.

Xd

Xc

Gm

ISC

UPSF

Sh

SDF

SSF

Gq'

Application and IPTV Service ISC Functions y2

N-PVR-SCF

Transport Processing Functions

Transport Functions

RACS e4 Transport Control Functions

NASS

e2

Core IMS

Cx

Sh

BC-SCF

CoD-SCF

IPTV Service Control Functions

Figure 18.2 Architecture for IPTV functions supported by the IMS subsystem.

UE

Xa

Ut

Media Delivery, Distribution & Storage

N-PVR-MDF

BC-MDF

CoD-MDF

IPTV Media Delivery Functions

IPTV Media Functions

Xp

N-PVR-MCF

BC-MCF

CoD-MCF

IPTV Media Control Functions

IMS-Based IPTV 423

424

IP Multimedia Subsystem (IMS) Handbook UE

RACS

Core-IMS

BC-SCF

ECF/EFF

1. INVITE 2. Resources Reservation

3. INVITE 4. 200 OK

6. 200 OK

5. Resources Commit

7. ACK

8. ACK 9. Multicast Report - Join Media Stream

Figure 18.3 Signaling IPTV in IMS (live TV).

To limit the scope of this handbook, at this point only an example service flow for requesting a live TV channel through the IMS infrastructure will be presented (Figure 18.3). More details on session modification, requesting VoD sessions, and session termination can be found in reference 7. The steps for live TV session setup include:

1. UE selects content and sends initial INVITE for session setup;

2. resources reservation (RACS);

3. INVITE forwarded to broadcast service control function (IPTV AS);

4./5./6. 200 OK sent back to UE including resource commit;

7. UE joins multicast address (IGMP JOIN); and

8. live TV streaming to UE.

Dedicated Subsystem for IPTV As already pointed out in ETSI TISPAN, an in early stages also called nonIMS-based approach for IPTV is considered. The scope of the dedicated IPTV subsystem for NGN can be summarized as follows (Figure 18.4): … evolution of IPTV from a standalone deployment into a converged architecture with composite services across multiple subsystems take into account existing deployments as well as easy incorporation of new platforms regardless of implementation.

Editor’s note from Andrey Kisel (Alcatel–Lucent) Rapporteur for reference 9.

Xd

IPTV Control

Configuration & Authentication

Xc

Ss

Customer Facing IPTV Applications

SD&S

Figure 18.4 NGN IPTV functional architecture.

Delivery Network Gateway

Consumer Transport

UE

Ct2

Tr

UE & DRM Intr

NGN Application

DRM

NASS

e2 RACS

Gq’


e4

Media Delivery Function

Xp

Media Control Function

Sa

Media Acquisition

Media Distribution

Ud

IPTV UDF

Service Layer

Sh

UPSF

NGN UDAF

Ug

Transport Layer

NGN App UDF IPTV Applications Media Preparation Functions

IPTV Service Control and Delivery Functions

IPTV Subscriber Management

Intr NGN & CF IPTV Apps

NGN Applications Management Functions Media Management Charging

UE & NGN Apps Intr

IMS-Based IPTV 425

Content Provider Functions

426


As for the IMS-based approach, two working groups—namely, WG2 for the architecture and WG3 for converged services and protocols—are involved in creating a release 2 contribution for non-IMS-based IPTV. The corresponding WG3 document [9] describes the procedures on the functional entities and call flows for the protocols and their possible enhancements to support dedicated IPTV services based on the architecture and stage 2 information flows described in reference 8. NGN–IPTV Interaction In the dedicated IPTV subsystem, the IMS core is not aware of ongoing IPTV sessions (e.g., requested channels). In order to implement servicelevel interactions between IPTV and other NGN services, a common NGN application server function (ASF) can be used for interactions with other applications and services (e.g., between IPTV and the IMS). A common ASF can be used for delivering customized notifications from multiple service domains (notification sources)—for example, IMS-IM, IMS call alert, or emergency notification Home Gateway Initiative When speaking about IMS-based IPTV services, one of the most crucial points in means of standardization is the home network, with a need for clarification on how streaming will be distributed to the different consumer end devices in the local network. One of the most significant bodies in this context is the Home Gateway Initiative (HGI), with the overall goal to improve the interoperability of gateways with connected home devices. To resolve the open issues in the context of IMS and IPTV, the HGI rearranged its future work on its third specification document in mid-2007. The final document will be available in the last quarter of 2008. Key features addressed will be focused on designing the home gateway for IMS-based NGNs, including IPTV services. Figure 18.5 depicts a high-level overview of the HGI’s approach to enabling IMS services within the home network, including the home gateway as the local termination point for NGN services being able to communicate with the operator’s infrastructure. Current HGI specifications as the home gateway technical requirements document [10] already include a strong link toward NGN and IMS services offering at least IMS communication services support. This includes: • an IMS protocol stack as defined in 3GPP TS 24.229 and TISPAN ES 283 003 technical specifications to support basic signaling principles toward the IMS core;

http://www.homegatewayinitiative.org/index.html

427

IMS-Based IPTV

IMS Control Plane IMS Media Plane UPnP/DLNA NonUPnP

Home Mobile Gateway Devices

1. SIP “INVITE” (IMS Control Plane)

IMS Network

1. SIP “INVITE” 2. Session (IMS Media Plane) Remote Device

Figure 18.5 High-level IMS-based remote architecture: overview. (Source: HGI.)

• IMS telephony user agent to support IMS-based conversational services; • IMS interworking with non-IMS equipment within the home network by offering B2B user agent functionality; • local registration and local services to support one or more IP multimedia public identities (IMPUs) that can correspond to a family IMPU identity or several family member IMPUs and various rules for non-IMS SIP user agents (UAs); • support of call forking and call transfer inside the home network (HN), offering a configurable telephony comfort; and • NGN messaging services delivered and available transparently to any HN device. With the preceding requirements in mind, the architecture from Figure 18.6 has been drawn to allow an interworking of the operator’s core IMS infrastructure, the home gateway, the customer’s local network, and the different IMS, DLNA, and legacy devices attached. More technically, this includes IMS interworking and the ISIM module, identity management, device management, self-provisioning, security, location function, and remote access. Details can be found in the corresponding documents [10]. ATIS IIF The Alliance for Telecommunications Industry Solutions (ATIS) is a U.S.based body that is committed to developing and promoting technical and operations standards for the communications and related information technologies industries. Beginning in early 2006, ATIS established the socalled IPTV Interoperability Forum (IIF). IIF’s initial focus was the creation

428


Home Gateway

Self Provisioning

NGN Service Layer

Application

IMS Interworking

AS

NGN IP Transport Layer (Access & Core)

B2BUA

Ut RCEF, C-BGF Gm

ARF, NACF

Remote Access

SIP ??

Firewall Function

IP IP

IP Device

IP

Non IMS SIP Device

??

IP

IP Device

??

FXS IMS POTS Device ISDN

QoS Handling CAC

RACS

e4 NASS CNGCF(')

UPnP Device

Identity mngt

ISIM IMS Core P-CSCF

UI

Device mngt

e1

Security Location Function (LF) Access Authentication

Figure 18.6 IMS interworking sub-blocks.

of an industry overall reference architecture for IPTV, content delivery (quality of experience), digital rights management (DRM), interoperability standards and testing requirements for components, reliability and robustness of service components, and the establishment of user expectations. The scope of the work in the IIF includes: • Coordinate standards activities that relate to IPTV technologies. This includes providing a liaison function between the various SDOs and forums that are each working on important components for multimedia but may not have visibility to other aspects of the application. • Develop interoperability agreements, technical reports, or other types of ATIS standards where appropriate. • Provide a venue for interoperability activities. • Provide a venue for the assessment of IPTV issues in the context of NGN directions. ATIS IIF released several documents relevant for IPTV standardization and reused by several other bodies, especially when defining requirements on IPTV. Nevertheless, ATIS IIF’s focus on IMS is very limited.

IMS-Based IPTV

429

Digital Video Broadcasting (DVB) DVB standards have been designed for broadcasting digital TV services by the DVB project since 1993. DVB standards exist for all kinds of digital TV, such as cable, satellite, and terrestrial broadcasting. Standards for interactive TV can be found under the umbrella of the so-called Multimedia Home Platform (MHP). DVB-T (terrestrial) is mainly targeted for stationary receivers, so it is not suitable for mobile devices. To overcome this limitation, the DVB-H (handheld) was proposed. This adds extension on the physical and link layers of DVB-T to reduce power consumption and improve performance in urban indoor environments. It uses an IP for streaming and thus might support multicast transmission in addition to the initial broadcast mode. With the introduction of IP-based TV services, the DVB introduced the DVBIP standard for IPTV deployments. In late 2005 DVB released the world’s first standard for IPTV called DVB-IP Phase 1 [25]. This standard aimed at early deployment of services using MPEG-2 transport streams. Supported service profiles are live media broadcast with and without trick modes (pause, fast forward, etc.) and content on demand (i.e., VoD). The handbook specifies the interface on the home network end device, enabling access to services delivered via an IP-based access network. This standard has been identified as not being able to build an end-to-end solution around it because of various missing elements in this document. The following planned phase 2 was due to be ready in late 2006 but, from the authors’ perspective, work was slowed due to the missing link to the key players in the IPTV market, such as telecommunication manufacturers and operators. In early 2007 the DVB group approved the general separation of future phase 2 work into two larger blocks: • open Internet (more flexible solution): enhanced service discovery and selection (SD&S), search engine relation, QoS for TS less and new transport protocols, authentication, content protection, billing, BCG with robust transport, (Network Service Provider) NSP and phase II; and • operator controlled (more powerful solution—close approach to phase I): enhanced SD&S, advanced IPTV session management, QoS for TS less and new transport protocols, fast channel change, convergence of fixed and mobile networks (CFMN), integrated triple/quad play, interfaces to NGN/IMS, DVB-HN phase II, NSP and phase II. The following key issues will be solved within the scope of phase 2: • need to identify the requirements for new flexible streaming protocols, which would also have an impact on signaling; • need to identify the requirements for new session management; • need to identify the requirements for a fast channel change;

430


• need to identify requirements for new transport protocols based on peer-to-peer technologies for managed and unmanaged networks; standardized solution preferable; • CFMN (e.g., same service from the mobile device screen to the plasma screen); transparency means handover (e.g., from one A/V codec to the other, from one application to the other); • integrated triple/quad play (data/content/TV in an integrated way); common requirements are the fundamental part (e.g., for handover); IMS may not be in all systems but will be required in some of them; • extension of remote management, QoS/QoE metrics; and • service brokering: current focus in head end, not on interfaces. In general, it seems as if the DVB’s IPTV standards will not have any strong impact without strong cooperation with ETSI TISPAN or ITU-T because of the missing link toward NGN and IMS. Because both DVB and TISPAN produce ETSI standards, deeper cooperation and an exchange of knowledge should be considered. Open IPTV Forum Entering the battle on IPTV standardization very late, the Open IPTV Forum [26] whose founding members come from the telecommunications world on the one hand and from the CE industry on the other, addicted themselves very early to the approaches of ETSI TISPAN and FG IPTV on NGN-based approaches for IPTV. Active since March 2007, the Open IPTV Forum defines itself as a: pan-industry initiative with the purpose of producing end to end specifications for IPTV that will take the next generation of IPTV into the mass market. The Forum, which is fully open to participation from the communications, entertainment and other relevant industries, will focus on the development of open standards that will help streamline and accelerate deployments of IPTV technologies, and maximize the benefits of IPTV for consumers, network operators, content providers, service providers, consumer electronics manufacturers and home and network infrastructure providers.

In late 2007 and early 2008, respectively, the Open IPTV Forum released initial white papers. Specifications on architectural issues look very promising to push IPTV standardization to a new level with strong support from the different players in the market. Summary and Conclusion The preceding identified the different standard development organizations and their corresponding members’ views on the future of IPTV. As

IMS-Based IPTV

431

this overview shows, there is currently no chance for one worldwide standard because the SDOs’ approaches are extremely fragmented. Nevertheless, the central theme in most of the bodies’ requirements and architectures focuses on the integration and interaction between streaming services and telecommunication features. For this reason, the NGN approach is more or less the smallest denominator and allows combination of the different SDOs’ work. The future will show whether the IMS will dominate upcoming IPTV deployments. From the authors’ point of view, IPTV might become the still missing killer feature or application to push the still very retarded IMS deployment strategies of the Telcos worldwide. In the following section, the authors’ work on creating an IPTV ecosystem relying on the ideas discussed in the previous sections will be presented.

A Real-World Testbed for IMS-Based IPTV FOKUS Media Interoperability Lab This section presents a proof-of-concept infrastructure for the delivery of IMS-based IPTV services driven by the well-known IPTV-enabled FOKUS Open IMS Playground [20]. As described in the preceding sections, different SDOs, such as ITU-T and ETSI TISPAN, released initial frameworks for standardized IPTV by the end of 2007 or will do so soon. The so-called Fraunhofer FOKUS Media Interoperability Lab (MIL) [23] represents one of the world’s first real-world test beds for these kinds of services. This has been achieved by actively guiding the different SDOs’ work with a focus on ETSI TISPAN. On top of this framework, different personalized and interactive services have been implemented to show the predominance and advantages of IMS-based IPTV solutions compared to other, mainly blackbox approaches. Introduction With the advent of the first IPTV deployments, the question of a more generic solution based on worldwide standards—as they exist for digital television—has been raised throughout industry and academia. The year 2007 was driven by different SDOs working on guidelines, frameworks, and standards for IPTV. With respect to their different scopes, all of them worked on or recognized the need to integrate solutions following the approachs of NGNs and the IMS [11], respectively. Mainly, this includes the ITU-T Focus Group IPTV [13], ETSI TISPAN [12], DVB, ATIS IIF, and the HGI. With the availability of ETSI TISPAN release 2, a framework not only dealing with architectural issues but also detailing signaling and used data formats will be available to build IMS-based IPTV end-to-end solutions.

432


Third Party Access

Media Clients

Service Enablers

Xa, Ut(web services, HTTP, DVB-STP...)

1

IP Core

Access Network

Ma

Sh

ISC

HSS/UPSF Presence

Mw P-CSCF I-CSCF

2

IPTV Service Control Function (Session & Content Management)

Cx Gm

IPTV Service Provisioning (User Profile, Service Discovery & Selection)

S-CSCF

IPTV Interactivity Function 4 (Votings, Targeted Advertisements & Shopping)

3

XDMS

IPTV Service Personalization (Rating and Recommendation)

Mr/y2 User Side Content Creation, Management and Retrieval

Xc/Xd

IPTV Media Function Storage, Distribution and Delivery

Mb

Content Provider (Playout)

Figure 18.7 FOKUS MIL architecture.

In the following section, Fraunhofer FOKUS activities within the MIL set up a real-world implementation for IMS-based IPTV on top of the wellknown open IMS playground at Fraunhofer Institute FOKUS [20]. In addition, various personalized and interactive IPTV services, such as targeted advertisements and interactive shopping or a remote parental control service allowing a mobile user to grant access to content requested by a child at home, have been built on top to demonstrate the advantages of IPTV delivered over NGN infrastructures and will be discussed next. Related work on NGN IPTV solutions can be found in the corresponding draft standard documents provided by the different SDOs mentioned before and also with or without focus on IMS-based solutions in references 14–16. Media Interoperability Lab—A Prototype Infrastructure for IMS-Based IPTV A Basic Architecture for IMS-Based IPTV The key challenge in providing IMS-based multimedia services over fixed and mobile networks is the management of adaptability, mobility, interactivity, context awareness, and personalization. To enable this vision, a basic set of common service functions has been identified and integrated into the FOKUS Labs on top of the basic open IMS architecture. The key components of open IMS are depicted in the center of Figure 18.7. These service functions shaping an IMS-based ecosystem when used together can be distinguished into four categories:

IMS-Based IPTV

433

The IPTV service provisioning function offers information on service discovery by so-called entry points enabling the connected UE to find adequate service selection entities. These entities provide the EPGs, including information on available channels and video-on-demand feeds. The IPTV service control function is in charge of the whole life cycle of a service based on a defined business model. This includes session management, access control, service composition, personalization, charging, processing, and managing of the interactive application. The IPTV service personalization function actively gathers information on user behavior and generates (content) recommendations, also taking into account the user profile and manual user rating. Recommendations will be calculated by integrating collaborative approaches such as considering other users’ behavior. More information on the techniques engineered at Fraunhofer FOKUS can be found in reference 18. A set of IPTV media functions is responsible for content delivery to the end user as well as media processing and an efficient utilization of available network resources including QoS and mobility support. In addition to the preceding architectural components, several other players are involved within the value chain of provisioning multimedia services, such as the content provider, who creates, owns, or is licensed to sell content; the service provider, who places the contract with the customer for supplying personalized multimedia services based on the network capabilities of the network delivery system; the network delivery system, which is in charge of session management and media delivery; and the end user (consumer) domain, where multimedia services are consumed. Provisioning of end-to-end triple play multimedia services with mobility support and QoS requires a cooperative service framework for interworking all players involved in the delivery process. This implies new requirements on such a framework and raises new challenges. These players have to interact smoothly to fulfill the task to provide a whole new service experience to the end user. These requirements were derived from an abstract view to all these players [19]. IPTV Services Overview This section gives a short overview on the different types of services provided by the proposed infrastructure: IPTV features: plain streaming services such as live TV and video on demand controlled through the IMS infrastructure; NGN features: telecommunication services provided by the NGN infrastructure, including presence, VoIP telephony, and messaging; and

434


Figure 18.8 FOKUS MIL media client GUI.

IPTV-NGN interaction/cross-fertilization: interaction scenarios showing the combination of common NGN services with new IPTV services such as caller ID on TV screen, time shift mode for video on demand and live TV on accepted calls, and call forking to multiple devices, including the TV set. Figure 18.8 depicts the current MIL IPTV terminal graphical user interface (GUI) showing the different menus for VoD selection, a buddy list, and an incoming call in the upper right corner. Architecture Enhancements for Supporting Interactive Scenarios To enable interactive services, three different types of modifications were applied to the lab’s infrastructure. These included: modifications to the client middleware, application logic, and GUI to support incoming and outgoing interactive event handling; enhancements to the basic IPTV signaling; and extensions to the SCF to forward messages to the interactivity function and provide access to active user sessions. To host the different types of interactive applications, a service interactivity function as depicted in Figure 18.7 (as entity marked as 4) has been added to the architecture and acts as a generic application server (AS) to process the server-side logic for the scenarios presented in the next section. In future revisions, these services will be provided by different ASs in the service pro-

IMS-Based IPTV

435

vider domain or at the content provider side, which implies the need for open interfaces in this direction. These interfaces are currently out of scope and will be part of future work. Interactive and Personalized Service Scenarios The following section presents an analysis of a scenario to support personalized targeted advertisements to demonstrate that an IMS-based infrastructure is not just able to offer these kinds of services but also can be considered as superior compared to other approaches such as MHP [24]. Other services that have been implemented are a generic approach for all kinds of voting services (e.g., used for quiz shows) as well as a remote parental control service allowing the clearing of services for underage users at home via a mobile device. The basic hooks for the scenarios described are given by the underlying NGN infrastructure or by adding AS and client logic to the architecture already being integrated into the lab’s components. Personalized, Targeted Advertisements and Interactive Shopping This section will give an overview of the different scenarios that will be used in the MIL framework to place advertisements, beginning with an overview of traditional approaches and then presenting more sophisticated scenarios. Afterwards, the technical realization will be demonstrated by describing a basic signaling flow between the different network entities involved. More information and background on interactive advertisement scenarios can be found in reference 21. The dream to address single users or groups of them with the same interest with personalized or so-called targeted advertisements has always been on the wish lists of broadcasters and content providers. Different proprietary solutions, as described in reference 21, and standardized approaches from the TV-Anytime Forum [22], with definitions also useful for the transport of metadata and used for advertisement scenarios, have been developed in the past. However, they have not been successful until now, mainly because of missing large-scale iTV deployments. The classical way to present advertisements to consumers is based on placing spots between the content through so-called ad blocks, as depicted in Figure 18.9. Classical ad insertion. Of course, the old-fashioned way to insert advertisements is still supported by the MIL architecture, whereas all ads will be managed by a content management system. This implies that the infrastructure is also aware of nontargeted ads, which will be placed by a group policy (i.e., different ads may be placed for different states, cities, or counties or not). Telescoped advertisements. Telescoped advertisement enables the content or service providers to point to external resources containing additional advertisements and information, which will be made avail-

436


Program Block 1

Program Block 2

Ad-Block 1

Program Block 3

Ad-Block 2

Figure 18.9 Schema for classical advertisement.

able to the consumer. This may be Web-based information portals or hooks to special advertisement streams (Figure 18.10). Targeted advertisement blocks. The most sophisticated advertisement approach, also used for this prototype, is placing an advertisement based on the user’s profile, which contains information on age, sex, and other personal information enriched with information on personal viewing and consuming habits. Overlay advertisements (picture in picture). This feature is often used for so-called in-show sponsorship, putting a special focus on a specific item that is visible in the content. The presented banners may be enhanced with links to extended content or advertisements. Transaction capabilities (shopping). All described scenarios can be enriched by adding real interactivity to the advertisements by providing access to the products presented in the different spots. This allows the consumer to buy the presented or related products through his or her IPTV interface and be charged either through his or her service provider on a monthly bill or by credit card credentials also stored in the user profile. The shopping feature is depicted in Figure 18.11, showing a targeted advertisement for a beer company that allows the user to order a certain number of crates for home delivery. Of course, a mixture of nearly all the presented scenarios is possible, such as placing a targeted PIP advertisement, telescoped targeted ads, or mixing targeted and nontargeted advertisements. Signaling Flows To evaluate the proposed solution of the IMS-based interactive multimedia framework, a scenario for the injection of personalized advertisements has been selected to demonstrate the advantages of IMS-based media delivery. Figure 18.6 depicts a simplified message flow for this scenario. Details on how the ad injection is triggered from the outside and details on real-time streaming protocol (RTSP) signaling are out of scope of this description and

437

IMS-Based IPTV Targeted/Personalized Ad-Block

Ad-Block 1

Program Block 1

Program Block 2

Transaction Capability (shopping)

Telescoped Telescoping Ad to Long Form Ad

Program Block 2

Overlay Ad w/Transaction Capabilities

Figure 18.10 Advanced ad insertion schemes.

Figure 18.11 GUI enhancements for interactive shopping.

will be analyzed in one of our later papers focusing on the different personalized and interactive enhancements of our architecture. This scenario enables the end user to watch different live channels where personalized advertisements will be inserted by a managing entity based on the user profile. To simplify the tasks for the service provider, each user has been assigned to a specific group matching his or her behavior and target group. By selecting a specific channel via the UE’s remote control (i.e., selected a specific channel from the EPG), the setup of the multicast delivery for this service will be initiated (see messages 1–7 in Figure 18.12).

438

IP Multimedia Subsystem (IMS) Handbook P/I/SCSCF

UE 1. INVITE

4. 200 OK 5. ACK

SCF

MF #1

MF #2

2. INVITE 3. 200 OK

6. ACK 7. Multicast Report - Join RTP

12. INFO 13. 200 OK

11. INFO

8. INVITE 9. 200 OK 10. ACK

14. 200 OK

Switch Stream

RTSPConnection

Switch Stream

Figure 18.12 Signaling for targeted ad injection.

In detail, the user in front of the UE initiates a new SIP for this channel request by selecting a channel from the EPG, which will be signaled through the IMS core infrastructure beginning with the corresponding proxy call session control function (P-CSCF) and forwarded to the serving call session control function (S-CSCF). Based on predefined trigger points, this entity decides that all requests for a live TV channel will be forwarded to the SCF maintaining the different user requests for streaming content. This AS is also responsible for initiating or receiving commands for injecting personalized advertisements from a third-party provider. In the described demonstrator, a Web interface allows one to define and control this task. The SCF selects an appropriate media function for the advertisement play out (MF #2 in this case) and forwards this information to the UE (see messages 8–12). The UE’s application logic interprets the received SIP INFO (12) message and switches to the signaled RTSP connection. After the advertisement has been played

439

IMS-Based IPTV Table 18.4 MIL Services and Scenarios Technology

Application/feature

IPTV

High-definition TV; linear TV with personalized EPG; video on demand with recommendations; Web2.0 meshup services; home media integration; media bookmarking and search

IMS/NGN

Real-time contact list with IPTV presence information; messaging; telephony; community services

IPTV and NGN interaction

Pause/mute the TV stream while calling; video follow me; director and system information; remote parental control; targeted, personalized, and interactive advertisement; onscreen shopping; interactive voting

out by the client, the application logic switches back to the live stream. It may be noted that one major drawback of this scenario is that the user is missing content while receiving the personalized advertisement. However, because this is just an exampleof how the MIL infrastructure is used to signal this service, various scenario modifications could solve this problem: • The signaling approach may also be used to enable picture-in-picture advertisements blended on the UE screen. • The solution is also useful for VoD scenarios where the (paid) content is paused during the advertisement based on the business. Summary To summarize this section, Table 18.4 contains an overview of the living list of features and services supported by the MIL at FOKUS.

References

1. Morris, S., and A. Smith-Chaigneau. 2005. Interactive TV standards: A guide to MHP, OCAP, and JavaTV. Burlington, MA: Focal Press. 2. International Telecommunication Union Telecommunication Standardization Sector Focus Group on IPTV FG IPTV-DOC-0181. 3. ETSI RES 282 001 V0.1.3 (2007-09). Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); NGN functional architecture. 4. ETSI TS 181 016. Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); service layer requirements to integrate NGN services and IPTV.

440


5. Draft MI/TISPAN-02047-Tech V0.2.0; IPTV architecture: Common architectural aspects. 6. Draft ETSI TS 182 027 (WI2048) V0.0.16 (2007-09); Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); IPTV architecture; IPTV functions supported by the IMS subsystem. 7. Draft ETSI TS 183 063 V0.0.7 (2007-12); Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification. 8. Draft ETSI DTS 02049 V0.0.9 (2007-09); IPTV architecture: Dedicated subsystem for IPTV functions in NGN. 9. Draft ETSI TS WI-03137 V0.0.4 (2008-01); Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); dedicated IPTV subsystem stage 3 specification. 10. HGI, home gateway technical requirements version 1.0 14/12/2007. Available at http://www.homegatewayinitiative.org/publis/HGI_V1_Residential.pdf 11. 3GPP. TS 23.228. IP multimedia subsystem (stage 2). http://www.3gpp.org 12. ETSI ES 282 001: Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); NGN functional architecture release 2. 13. International Telecommunication Union. Focus group on IPTV Telecommunication Standardization Sector FG IPTV-DOC-0115; Working document: IPTV architecture. 14. Weldon. 2006. IMS and IPTV—Perfect together. http://ipcommunications.tmcnet.com/hot-topics/ims/articles/280-ims-iptv-perfect-together.htm 15. Cagenius, T., A. Fasbender, and Barriga. 2006. An IMS gateway for service convergence in connected homes. 45th Congress of the Federation of Telecommunications Engineers of the European Community (FITCE), August 30–September 2, Athens, Greece. 16. Cagenius, T., A. Fasbender, J. Hjelm, U. Horn, I. Más Ivars, and N. Selberg. 2006. Ericsson Review, no. 03. http://www.ericsson.com/ericsson/corpinfo/publications/review/2006_03/04.shtml 17. Thawani, A., S. Gopalan, and V. Sridhar. 2004. Context aware personalized ad insertion in an interactive TV environment. In 2004 Workshop on Personalization in Future TV (Eindhoven, 2004), 239–245. 18. Räck, C., S. Arbanowski, and S. Steglich. 2007. A generic multipurpose recommender system for contextual recommendations. 8th International Symposium on Autonomous Decentralized Systems (ISADS 2007), Sedona, Arizona, March 2007. 19. Al-Hezmi, A., O. Friedrich, S. Arbanowski, and T. Magedanz. 2007. Requirements for an IMS-based quadruple play service architecture. IEEE Network 21(2):28–33; digital object identifier 10.1109/MNET.2007.334309. 20. Vingarzan, D., P. Weik, and T. Magedanz. 2006. Development of an open source IMS core for emerging IMS testbeds. Journal on Mobile Multimedia (JMM), special issue on IMS 2, Rinton Press, Princeton, NJ, http://www.rintonpress.com/journals/jmm/ 21. Interactive Advertising Whitepaper. 2005. OpenTV Inc. San Francisco, CA. 22. TV-Anytime Forum Web site. http://www.tv-anytime.org/ 23. Fraunhofer FOKUS. Media Interoperability Lab. http://www.fokus.fraunhofer.. de/go/mil 24. ETSI TS 101 812 V1.3.1 MHP specifications: The multimedia home platform.

IMS-Based IPTV

441

25. ETSI TS 102 034. Digital video broadcasting (DVB); transport of MPEG2-based DVB services over IP-based networks. 26. Open IPTV Forum documents and specifications. http://www.openiptvforum. org/downloads.html

19 IPTV Modeling and Architecture over IMS David López, Eugen Mikoczy, José Ignacio Moreno, Antonio Cuevas, and Enrique Vázquez

contents Introduction..........................................................................................................444 Principles for Next-Generation Network Service Platforms.........................445 Axiomatic Design.......................................................................................446 The Independence Axiom.........................................................................446 IPTV Service Requirements End Service Modeling..............................447 IPTV Identification and Characterization...................................448 Identification of User’s Expectations............................................448 Quality Matrix for IPTV Services................................................. 450 IPTV Failure Mode and Effect Analysis...................................... 452 Users’ Influence on IMS-Based IPTV Service Requirements...............454 IPTV Standardization Overview....................................................................... 455 Migration Scenarios and Extensions toward IMS-Based IPTV..................... 458 General Architecture of Non-NGN-Based IPTV.................................... 458 Non-IMS-Based NGN IPTV Architecture............................................... 460 IMS-Based Functional Architecture for IPTV Services........................ 461 Core IP Multimedia Subsystem Overview............................................. 462 Service Discovery and Selection...............................................................463 IPTV Service Control Functions...............................................................464 IPTV Media Functions...............................................................................464 IMS-Based IPTV Protocol Model.......................................................................465 Future Evolution of NGN-Based IPTV............................................................. 468 Conclusions........................................................................................................... 469 References............................................................................................................. 470

443

444


Currently, network infrastructures and services are of critical importance to the entire society. It is widely accepted that current convergence of telecommunications technologies and infrastructures will be centered on Internet technology. This fact is supported by most telecom operators and service providers, which are moving progressively to IP infrastructure to support their businesses. This trend is driven by the reduction of CAPEX (capital expenditure) and OPEX (operation maintenance) and will eliminate the need to maintain multiple network platforms (e.g., SDH, ATM, FR, X.25) that currently coexist to support a wide variety of services over multiple platforms. In this chapter we concentrate on Internet protocol television (IPTV) service, one of the key services for future media distribution. The chapter is structured in two main parts. First we introduce a model for IPTV from a user perspective, identifying critical parameters of the service to guarantee quality of service (QoS). Then IPTV support over the IP multimedia subsystem (IMS) is introduced. This work is under standardization by the European Telecommunications Standard Institute Telecom and Internet Converged Services and Protocols for Advanced Networks (ETSI TISPAN) group and will provide a common standard to develop the IPTV service over the IMS platform. This will facilitate easy deployment of the service, taking into account the current update of the transport and service network toward the next-generation network (NGN) based on the IMS infrastructure.

Introduction The digital television has been evolving for several years. What started as terrestrial or satellite digital television can now be delivered over fixed and mobile broadband networks. The deployment of IPTV over different broadband access networks was made possible because of new types of broadband access networks and improved media coding algorithms. Following the deployment of the home Internet access services (DSL based), most of the major European telecom service providers have already started or planned to start providing triple play (telephone, Internet access, and IPTV) services. One service package with video, voice, and data services is to be provided via common IP-based networks. Although the IPTV standardization is still ongoing and initial standards have been already delivered as for example ETSI TISPAN Release 2 specifications published in the beginning of 2008 (see references). Therefore, we can just now expect that the first standard based NGN based IPTV solutions will be offered and deployed in the next few months/years and will allow the enhancemnt of previous “legacies” in the IPTV service offers (with more interactivity, personalization, and advance features). The current IPTV services are built on vendorspecific platforms without integration with NGN subsystems. The purpose

445

IPTV Modeling and Architecture over IMS Services

CATV

Data/IP Networks

PSTN/ISDN

Mobile Networks

Existing and Newly Emerging Services Service & Network Control (QoS, Security, IP Mobility) Multi-Service IP Backbone Wireless Access

Wireline Access

Vertical Access, Transport & Control Networks Silo per Service Figure 19.1 IMS-based NGN–IPTV from vertical to horizontal integration.

of the IPTV architecture over IMS is to integrate the IPTV in a unified, vendor-independent service platform to reduce the OPEX (operating costs) and CAPEX (investment costs). The IMS has been introduced by the 3GPP (3rd Generation Partnership Project) initiative as the architectural subsystem dedicated to controlling and providing multimedia services over packet-based core networks within the third-generation mobile networks in 3GPP releases 5, 6, and 7 [1] (although the IMS has also adopted the NGN standardizations). The concept of the NGN has been evolving for several years; the first real standardization activities were started by ITU-T (International Telecommunication Union) NGN focus group [2] and ETSI TISPAN [3]. ETSI TISPAN employs the IMS concept in its NGN release 1 (NGN R1) within the NGN architecture framework. IMS has been widely accepted as one of the key platforms for future NGN service composition, orchestration, and delivery. In the ongoing ETSI TISPAN NGN R2, IMS is also used to support IPTV services. ETSI TISPAN extends its NGN R1 architecture to include non-IMS- as well as IMS-based IPTV concepts in its NGN R2 specifications.

Principles for Next-Generation Network Service Platforms Paradoxically, the expected savings that the convergence of services into a single architecture will achieve leads to more complex management scenarios. The new paradigm of composite services consisting of atomic ones such as video, voice, and data challenges existing management procedures have

446


User’s Needs (CNs)

Functional Requirements (FRs)

Parameter Design (DPs)

Process Variables (PVs)

User’s Domain

Functional Domain

Physical Domain

Process Domain

Figure 19.2 Axiomatic process design.

so far dealt with independent services, provided with dedicated equipment and staff (Figure 19.1). This vertical model is no longer valid as far as end users are concerned. Whenever a user subscribes to an IPTV service, he or she expects the best experience during the whole life cycle of the process. As far as users are concerned, the variety of media contents and the flexibility to configure the interface according to their liking or cognitive requirements are important, as well as the quality of the media displayed on the screen. If a novel service is to succeed, it needs to adopt an enhanced perspective on what customers expect, and it has to do so before the service is provisioned. Unfortunately, the dynamics of new services rolled up in next-generation networks hinder a clear-cut approach to customer expectation modeling. Axiomatic Design The so-called axiomatic design [4,5] is an analytical approach to process and system design capable of incorporating high-level goals into the model and having them translated into technical specifications for subsequent processing at engineering areas. An important feature of this approach is that it relies heavily on sound engineering concepts such as stability and controllability, which in the end affect the capability of the solution to adapt to unforeseen service requirements. As far as axiomatic design is concerned, a general principle must be satisfied at all designing stages. This principle, denoted as the independence axiom, states that sections of the design should be separable so that changes in one have no, or as little as possible, effect on the other. The Independence Axiom As Figure 19.2 shows, process design can be segregated into four independent domains. The first one, user’s domain, deals with attributes that matter to end users. The last one, process domain, deals with concepts and elements belonging to engineering areas that, in the end, are responsible for the implementation. Given the disparity between customers’ beliefs and the technical concepts to implement them, axiomatic design defines another two intermediate domains to facilitate a gradual mapping. The functional domain is in charge of expressing subjective, user-expressed concepts into formal entities

447

IPTV Modeling and Architecture over IMS Consumer Domain Consumer

Content Provider

IPTV Service Provider NGN Service Provider

Content Domain

Service Domain

Transport Provider

Transport Domain

Figure 19.3 Business entities in IPTV-related services.

that constitute the starting point for further engineering efforts. The independence axiom promotes those implementations capable of satisfying each functional requirement without affecting other parameters. Designing next-generation infrastructures compliant with this axiom alleviates the problem of defining features for a service not yet completely characterized at initial stages. Also, if any change or feature should happen in the future, thanks to this independence principle, reconfigurations are kept to a minimum. IPTV Service Requirements End Service Modeling In addition to mobile service, IPTV constitutes one of the main services that telecommunications companies (telcos) will offer under IMS. IPTV service is adequate for the purpose of validating axiomatic design as a correct approach to service modeling for the following reasons: IPTV is a service that deals with end users, it is composed of several atomic services, and it spans multiple providers at the content, service, and network levels. Figure 19.3 represents the business entities involved in IPTV service delivery according to reference 6. As the diagram shows, four main entities need to collaborate: the comsumer of the IPYV service; the content provider; the service providers supporting several functionalities, such as payment or content search and acquisition; and transport providers that collaborate in order to have media content delivered across fixed and/or mobile networks. Furthermore, IPTV is a concept that contains several business cases, such as video on demand (VoD), interactive TV, and media downloading, to name a few. For every case a different combination of entities, technologies, and functionalities is required, thus increasing the complexity of service management [7,8]. A typical IPTV service, as we know it today, is part of a

448


triple play that operators offer, usually composed of the following services (audio, video, data): (1) broadband access • Internet access • e-mail service (2) audio and video streaming • TV channels • radio channels • interactive news (3) on-demand delivery • news on demand • music on demand (4) voice over IP (VoIP) As explained in previous sections, segregating the functionalities that a service is expected to deliver into independent entities improves service management and service adaptability. Therefore, to design next-generation services calls for an axiomatic-based approach. Four stages are defined: identification, characterization, parameterization, and supervision. As depicted in Figure 19.2, the first three deal with specifics of service delivery, whereas the fourth sustains achieved quality levels. This last stage is especially relevant in multimedia services that, contrary to other services such as Web surfing, are delivered over long periods of time. Due to the scope of this chapter, only the first two stages in IPTV modeling, identification and characterization, are developed. For further information regarding subsequent stages, please refer to reference 8. IPTV Identification and Characterization As far as the user is concerned, one single service entity exists, whether it is composed of video, voice, or data. This has two implications: that all of the atomic services have to deliver with high-quality levels to ensure consumer satisfaction and that it is impossible to define a single model capable of characterizing the way the user behaves according to technical parameters (unlike the ones existing in telephony, for instance). Furthermore, according to existing literature [9], the response of users retrieving multimedia content is highly nonlinear, multimodal, multiplicative, and content dependent. Therefore, alternative procedures are required to infer which functional parameters are the ones affecting users’ perceptions and expectations. Identification of User’s Expectations In order to establish the concepts and attributes influencing customers, a set of interviews was conducted during 2006 involving existing IPTV.

449

IPTV Modeling and Architecture over IMS Table 19.1 Considered Concepts Research method Purchasing process

Processes Personal interview Universe: interested customers Total interviews: 1,203; 2.9% error

Satisfaction

Personal interview Universe: existing customers Total interviews: 500; 4.5% error

Customer satisfaction

Personal interview Universe: new customers Total interviews: 100; 10% error Personal interview Universe: leaving customers Total interviews: 150; 8.16% error

Abandon while provisioning

Personal interview Universe: leaving customers Total interviews: 512; 4.37% error

consumers as well as those interested in potentially subscribing to it (Table 19.1). The study, carried out by the incumbent operator in Spain among its subscribers, represents a statistical sample representative of IPTV performance. According to the results of the opinion poll, several attributes play a key role; see Table 19.2 for a list of relevant attributes on a scale from 1 to 5 on ascending order of importance. Half of the interviewed customers (173) who intended to subscribe to the IPTV service were not able to do so because of technical limitations of the access network. Almost half of the customers who had been considering subscribing to IPTV services (407 interviewees) finally turned it down because the existing offer was not compelling enough. In relation to offered contents in IPTV, 42% of existing customers were satisfied with the existing offer; however, some of them (58%) expressed a desire for extra content—mainly cinema (46%) and documentaries (16%). Regarding video on demand, customers were especially concerned with image quality (4.5 out of 5), content variety (4.2 out of 5), novelty (4 out of 5), and price (3.9 out of 5). According to data from unsatisfied customers (118 interviewed), four aspects were identified as the main causes for disatisfaction: image blockiness (3.3 out of 5), loss of connectivity (3.1 out of 5), lack of information (2.8 out of 5), and sound distortion (2.2 out of 5). The main results can be summarized as follows:

1. Customers are willing to spend more for flexible services adapted to their liking.

2. Customers demand contents suitable for every family member.

450


Table 19.2 User Attributes in IPTV Services User attributes

Importance Potential customers

Existing customers

Recent customers

Channel variety

4.1

4.0

4.1

Best channels

4.2

4.0

4.3

Competitive prices

4.2

4.0

4.3

Installation process

4.1

3.8

4.

Brand

4.1

3.8

4.0

Customer care

4.2

3.8

4.5

Customer support

4.1

3.8

4.5

Appealing promotions

4.1

3.7

4.1

Innovative product

4.0

3.7

3.9

Product flexibility

3.9

3.6

3.9

Added services

—

3.6

3.9

Video club

3.6

3.3

4.0

Soccer league

3.3

2.9

3.2

Champions’ league

3.3

2.9

3.2

3. A single bill for all services is desired.

4. The access network becomes the main bottleneck for new subscriptions.

5. Quality, novelty, and variety are paramount in VoD services, mainly movies and documentaries.

6. Price matters on every service, whether it is voice, TV, or VoD.

7. Efficient and flexible service provisioning is key to a customer’s satisfaction.

Quality Matrix for IPTV Services As mentioned in previous sections, thanks to the quality matrix (house of quality [HoQ]), it is possible to perform quantitative analysis to model user response to functional service parameters. Being able to map user expectations into functional concepts arguably helps to better service development and market acceptance. As shown in Figure 19.4, the matrix relates users’ attributes, presented in rows, with functional concepts, presented in columns. An element in the matrix corresponds to the existing coupling level (strong, medium, weak) between a given user attribute and a functional one. The more coupled a functional attribute is with attributes affecting end users, the more relevant it becomes in the design process.

451

IPTV Modeling and Architecture over IMS Standard 9-3-1

O&M Personnel

VoDemand Service

VoIP Service

Storage Service

Service Provisioning and management

Customization

Service Documentation

Set Top Box

Coding Quality

Distribution Network

Attibute Importance

162

108

198

234

108

104

246

180

111

216

234

189

Provider 1

2

4

4

2

3

1

4

3

3

2

3

3

Provider 2

4

4

4

3

4

4

3

3

4

2

3

5

Provider 3

5

4

4

4

0

0

4

2

4

3

4

4

Importance for the Customer

Provisioning personnel

9.0 3.0 1.0

Access Network

Strong Moderate Weak

Improvement effort Fast and efficient incident handling Easy installation process

4.0 5.0

Channel variety

5.0

Competitive price

5.0

Availability of on demand services Service customization, prices and features

4.0

Single billing

4.0

Content customization

3.0

Service information

3.0

Usability

5.0

Content quality

4.0

Image quality

5.0

Movie mental cost

3.0

5.0

Figure 19.4 House of quality corresponding to IPTV services.

The quality matrix also provides a benchmark analysis between competitors. This helps engineers to prioritize improving efforts based not only on customer expectations but also on equivalent services provided in the market. It has to be pointed out that often customers judge products or services based on existing references; for instance, VoD is measured against existing terrestrial TV or DVD rental services. According to results presented, provisioning and service management are paramount because they affect the capability to offer personalized services, final price, and service availability. Video on demand is clearly a relevant factor for existing customers and a competitive advantage against alternative services such as terrestrial, cable, or satellite TV. Finally, the set-top box

452


First Stage

Second Stage

Subscription

Television

Provisioning

Service Availability Appealing Channels Sufficient Information

Third Stage

Search

Smooth Installation Technical Problems Internet Access Wiring

Menu not Available Search Time

Fourth Stage

Access Start Delay Image Quality Image Distortion Sound Quality Interactivity

Video on Demand Third Stage

Search

Menu not Available Search Time

Fourth Stage

Fifth Stage

Acquisition

Access

Service not Available Transaction Time

Start Delay Image Quality Image Distortion Sound Quality Interactivity

Figure 19.5 IPTV service life cycle.

is critical to service acceptance. Because it is the service interface to access the service, a wrong design will certainly hinder a user’s ability to make the most of the functionalities. IPTV Failure Mode and Effect Analysis At this point, failure mode and effect analysis (FMEA) analyzes the IPTV service life cycle so that, based on failure probability, actions can be adopted accordingly. Figure 19.5 details a typical scenario of IPTV service consumption along with potential causes of failure or service degradation. To do so, functional requirements are defined first, and then FMEA proceeds by identifying failure scenarios resulting from any discontinuity in the delivery of functional requirements. For every identified failure, the severity (SEV), occurrence probability (OCC), and visibility (DET) are determined. The specific value for each of these metrics is computed based on internal quality management procedures. Every industry (energy, transportation, telecom) may agree on a single schema to classify a given failure; otherwise, this consensus is established for internal use in a company. Once every failure has been identified, it is possible to define a metric quantifying the associated risk for any failure, the risk priority number (RPN), as follows:

{

} {

} {

∀Failurei ; RPN i = SEVi ∗ OCC i ∗ DETi

}

The results are presented in Table 19.3. Service subscribing. Whenever a new customer considers subscribing to IPTV, two factors can adversely affect the outcome of the provisioning process. The first one is technical, having to do with limitations in the access network

453

IPTV Modeling and Architecture over IMS Table 19.3 FMEA for IPTV Services ID stage description

SEV (1–8)a

OCC (1–10)b

DET (1–10)c

RPNd

1.1 Access network limitation

8

8

10

640

1.2 Lack of contents

8

5

10

400

2.1 Installation delay

5

6

7

210

2.2 Technical problems

6

6

8

288

4

3

5

60

6

6

6

216

3.1 ADSL down

7

1

3

21

3.2 Router down

7

2

5

70

4.1 Set-top box down

6

6

8

288

4.2 Directory service down

7

3

3

63

5.1 Search service down

5

3

3

45

5.2 Pay service down

7

3

3

63

6.1 Starting delay

4

6

8

192

6.2 Image issues (2 hours)

6

6

8

192

6.3 Audio issues (2 hours)

7

5

7

245

7.1 Sequence access delays

5

6

8

240

7.2 Language switch delays

4

6

8

192

1. Subscription

2. Provisioning

2.3 Existing Internet access . degradation 2.4 Wiring 3. Network access

4. Search and selection

5. Movie acquisition

6. Movie display

7. Interactivity

Severity. b Occurrence. c Visibility. d Risk priority number. a

due to DSL loop constraints. The second is due to a lack of contents appealing to customers. With regard to the latter, the solution lies in establishing agreements with content providers to extend the variety of offered contents further. The first limitation calls for improved transmission schemes such as VDSL (Very High Speed Digital Subscriber Line) or fiber to the curb. Service provisioning. According to obtained data, the provisioning process possesses more room for improvement. Arguably, any improvement oriented toward a better installation process would not only reduce associated.

454


provisioning costs but also minimize the chance of a customer’s turning down the subscription process. Service access and consumption. Given the fact that users expect quality levels at least comparable to the ones existing in terrestrial TV or DVD rental, it is critical to ensure an optimum content delivery for the duration. As FMEA reveals, content quality, both audio and video, is critical because it has a direct impact on users’ perceptions over large periods of time. Unlike previous limitations—for instance, appealing contents or provisioning—video and audio quality are not easily translated into single corrective actions such as better agreements with content providers. The process of converting functional concepts (video and audio quality) into technical ones is denoted as parameterization. Due to space limitations, we will not further explore how this parameterization could be performed; any interested reader may review references [8] and [10] for further information. Users’ Influence on IMS-Based IPTV Service Requirements According to the results presented in previous sections, IPTV consumers are especially concerned with the novelty of the offered contents (movies, soccer, documentaries, and so on). For IPTV service providers, delivering content capable of fulfilling customers’ expectations is just a matter of establishing agreements with relevant content providers and content producers. Customers are also keen on subscribing to flexible services adapted to their specific needs and favor single billing schemes. At this point and according to the service requirements to integrate NGN services and IPTV [14], several characteristics are associated with the capability to reconfigure and adapt the service as requested: • open solutions for IPTV services; • service logic downloading on end devices; • user-based (instead of device-based) authentication; • single subscription scheme to several services; • seamless mobility (devices and location); • reuse of existing NGN architecture and services (service control convergence); • associated metadata handling and processing; • personal service discovery; and • existence of user profiles. With regard to single billing and personalization, IMS will arguably provide a competitive advantage over alternative IPTV frameworks. It is expected that, by conforming to international standards, IMS will promote interoperability among service providers (content, transport, and billing) and thus foster the existence of IPTV-related ecosystems.

IPTV Modeling and Architecture over IMS

455

Similar to existing network services, customer support is paramount to a quality experience. According to presented results, the main interface between the user and the service is critical for the user’s adoption. At this point IMS-based IPTV services need to ensure ergonomic and usable interfaces (both hardware and software) for user interaction with the service. The most relevant service characteristics associated with usability are (according to definitions proposed in ETSI TS 181 016 V0.0.8 [14]): • service awareness at the network level to maximize users’ experience constrained to available resources; • terminal awareness to adapt according to terminal restrictions (access network, power, hardware); • service discovery (user based, location based, terminal based); • existence of user profiles; and • service internationalization. Contrary to other novel services, IPTV service competes against existing ones such as TDT (Terrestrial Digital Television) or DVD; for this reason, users expect at least a similar quality while watching IPTV content. IMSbased IPTV services have to provision sufficient resources and mechanisms to ensure unmatched quality of video and audio services. At this point it is expected that the advanced signaling mechanism that IMS provides will help IPTV providers deliver optimum multimedia services.

IPTV Standardization Overview In recent years, many efforts have been made on IPTV standardizations. We would like to mention the most significant ones to give readers an overview as well as references to the relevant documents. DVB over IP networks. DVB-IPI (digital video broadcasting—Internet protocol infrastructure) [12] provides a set of technical specifications that cover the delivery of DVB MPEG 2-based services over bidirectional IP networks, including specifications of the transport encapsulation of MPEG 2 services over IP and the protocols to access such services. Another important issue is the specification of the service discovery and selection (SD&S) mechanism for DVB MPEG 2-based audio/video (A/V) services over bidirectional IP networks to define the service discovery information, its data format, and the protocols. ITU-T FG IPTV. The ITU-T Focus Group IPTV [13] evaluates IPTV on various issues such as services, architecture, IPTV middleware, and security. It is expected that IPTV will be included in the ongoing ITU-T NGN R2 recommendations.

456


ETSI TISPAN IPTV. In TISPAN NGN R2 several specifications are addressing IPTV regarding service requirements [14] and architectures with nonIMS IPTV subsystems [15] as well as IMS-based IPTV [16]. We focus on ETSI TISPAN IMS-based IPTV architecture in this chapter. ATIS IPTV Interworking Forum. The ATIS (Alliance for Telecommunications Industry Solutions) initiates the IPTV Interoperability Forum (IIF) that develops standards to enable the interoperability, interconnection, and implementation of IPTV systems and services, including video on demand and interactive TV services. Within the IIF initiative, the ATIS analyzes several important aspects of IPTV and defines IPTV logical domains, IPTV reference architectures (IMS- and non-IMS-based IPTV, and their coexistence) [17], content delivery concepts with quality of experience, digital rights management (DRM) requirements, and interoperability standards, as well as testing requirements for components, reliability, and robustness of service components. 3GPP MBMS. The 3GPP specifies MBMS (multimedia multicast/broadcast services) specifications [18] mainly to define an efficient way to deliver and control multicast and broadcast services over third-generation (3G) networks. MBMS are limited at this moment to mobile TV channel bandwidth, which is usually up to 200 kbps. The advantage of MBMS in comparison with DVB-H is that the same IP-based common infrastructure is used as for 3G data services. OMA BCAST. The OMA (Open Mobile Alliance) introduced the concept of the mobile broadcast services enabler [19] to address functional issues common to many broadcast services that can be defined and implemented in a bearer-independent way. These functional issues are: service guide, file distribution, media stream distribution, service protection, content protection, service interaction, service provisioning, terminal provisioning and notification, etc. Generally, it is expected that mobile broadcast services should enable the distribution of rich, interactive, and bandwidth-consuming media content to a large number of mobile audiences. IETF. Finally, IPTV standards are using existing protocols defined by the IETF (Internet Engineering Task Force), such as session initiation protocol (SIP) for session control [20], real-time stream protocol (RTSP) [21] for media control of CoD (content on demand) services, and Internet group management protocol (IGMP) for IPv4 or multicast listener discovery (MLD) for IPv6 multicast-based services. The real-time transport protocol (RTP) is used for media delivery [22]. There exist also several Internet drafts regarding IPTV channel description to enable a unified IPTV service identification. IPTV Architecture Evolution toward NGN and IMS-Based NGN IPTV In this section the evolutional steps of IPTV architectures and extensions are presented. The migration toward NGN-based IPTV architecture can be defined as a four-step process, as shown in Figure 19.6: • Non-NGN-based IPTV architecture is the actual deployment of all available IPTV solutions on the market. It is possible to create some

457

IPTV Modeling and Architecture over IMS 1 Non-NGN IPTV

1st generation of IPTV Architectures including propietary IPTV head end and middleware platform without the NGN integration

2 NGN Non IMS IPTV Introduce interfaces to NASS, RACS and user profile

3 NGN IMS based IPTV 4 NGN Converged IPTV Combination of non-IMS and IMS based architecures

IPTV service control is based on IP Multimedia Subsystem

Figure 19.6 The potential IPTV evolution steps.

interworking between non-NGN-based IPTV with NGN subsystems, but generally a separate service control and application layer is used exclusively for IPTV services based on proprietary IPTV middleware. • NGN non-IMS-based IPTV architecture enables interaction and interworking over specified reference points between IPTV dedicated functions (such as IPTV control functions) and some existing NGN elements such as transport control elements for the resource admission and control subsystem (RACS) or the network attachment subsystem (NASS). In this step, a dedicated IPTV subsystem within NGN will be used to provide all necessary IPTV functionalities (e.g., IPTV control, user profiles, client facing functions) and to integrate IPTV components in the NGN architecture framework. • IMS-based IPTV architecture specifies IPTV functions based on the IMS subsystem and allows reusing of IMS functionalities and SIP-based service initiation and control mechanisms. Details of this architecture concept will be provided later in this chapter. • The NGN, non-IMS, and IMS converged IPTV architectures are a combination and convergence of non-IMS- and IMS-based IPTV architectures in a common configuration to provide converged types of IPTV services.

458


Migration Scenarios and Extensions toward IMS-Based IPTV Each evolutional step realizes additional functionalities and system features to provide new values for IPTV services—for example, to increase the quality of experience (QoE) for end users and to converge TV with other telecommunications and interactive multimedia services. A quick and easy introduction of new service features and reduction of the operating costs may be another important motivation to evolve the IPTV systems (as shown in Figure 19.6). In comparison with proprietary IPTV solutions (type 1), NGN-based IPTV (type 2) features standardized IPTV control and media delivery functions. The NGN-based IPTV subsystem enables integration with NGN user profiles and interfaces to NGN RACS and NASS subsystems to realize personalized value-added IPTV features and to use network resources more efficiently. The evolution to NGN IMS-based IPTV (type 3) or NGN IMS and non-IMS converged IPTV is based on the observation that IMS as a unified service control platform is increasingly important for future NGN services. Therefore, IMS-based IPTV can be inherently integrated in the NGN IMS-based service platforms. However, we cannot expect all NGN services in the future to be only IMS based. Thus, convergence and combination of IMS and nonIMS IPTV to become an NGN converged IPTV can be foreseen in the future (type 4). General Architecture of Non-NGN-Based IPTV The general triple play architecture usually consists of the following parts: • service platform domain; • IPTV middleware (non-NGN); • NGN dedicated IPTV platform (non-IMS-based NGN IPTV); • IMS-based IPTV platform (IMS-based NGN IPTV); • transport network; • access network; and • home network and CPEs (customer premise equipment). The service platform domain for providing triple play services usually contains several more or less independent parts of the complex triple play service architecture (Figure 19.7): • The content acquisition subsystem allows receiving, processing, and encoding content from external sources to defined media coding and encapsulation (receiver and decoder infrastructure, IPTV head end, VoD import and preprocessing).

459


Service Platform Domain

Transport Domain

Access Domain

Home Domain

PSTN VoIP Gateway PC/Internet

TV IPTV Platform VoD Platform

DSLAM

Multimedia

Application Platform Internet

Telephone

Figure 19.7 General IPTV architecture.

• The content distribution subsystem is responsible for retrieving, protecting, distributing, storing, and delivering content by a preferred way to the end user system (user equipment). • IPTV middleware contains application severs that control and manage the whole IPTV infrastructure (servers, databases, front end and back end systems, interfaces to external systems, e.g., the operational support system and the business support system), users, and services. Part of the application platform also could be additional IPTV applications or gateways allowing limited interaction with other systems (e.g., VoIP, NGN). • The service selection and discovery subsystem allows a user to browse and find, via a user TV portal, appropriate content or service information (metadata) that he or she would like to watch (could be part of IPTV middleware). • VoD, nPVR, or other subsystems constitute a specialized subsystem infrastructure required for dedicated services (VoD or networkbased personal video recording service). Because triple play contains three type of services—video, voice, and data— connection to Internet services and a voice service platform (e.g., over the VoIP gateway) is also required.

460


There is no single approach to IPTV service provisioning. Due to the huge costs involved in network equipment, telcos usually follow incremental approaches to network upgrading, always relying on existing premises and procedures. Therefore, the way a new NGN service is provisioned clearly depends on the history of the operator. For instance, some operators rely on a single point to generate, process, and distribute content (centralized content delivery architecture), or content may be distributed to regional points of presence where it is stored for further, more effective distribution (e.g., most frequently used VoD content provided from nearest point to user) by means of access networks (distributed content delivery architecture). However, the nature of the content to be delivered defines whether the service relies on multicast distribution networks (e.g., broadcast services) or on unicast distribution networks (e.g., VoD). Under this paradigm, by selecting the type of content, users subscribe to either multicast services or unicast ones. Non-IMS-Based NGN IPTV Architecture The NGN dedicated IPTV subsystem architectural approach considers adding a specialized IPTV subsystem as a functional area to TISPAN NGN R2 architecture. This is integrated into the NGN via standardized reference points and delivers service level requirements, while allowing internal implementation flexibility and extensions for new service types. We are not focused on non-IMS NGN architecture (also called NGN dedicated IPTV), but more information can be found in the TISPAN specification in reference 15. IMS-Based IPTV Architecture In this section, we present an IMS-based IPTV platform that is able to provide IPTV services controlled and handled by the IMS and to deliver IPTV services independently from underlying IP transport networks. The IMS-based IPTV has a number of advantages, such as support for mobility, interaction with NGN service enablers, service personalization, and media adaptation, as well as integration of voice, data, video, and mobile services as quadruple play services. Furthermore, by deploying and reusing existing IMS functionalities to support IPTV services, we can optimize and reuse NGN concepts for the following issues: • integrated user registration and authentication (e.g., for single signon, unified user identity); • user subscription management, user profile centralization, and flexible user policy and service personalization; • session management, routing, service trigger, numbering; • interaction with NGN service enablers (presence, messaging, group management, etc.); • roaming and nomadic support;


461

• QoS and bearer control; and • unified charging and billing. Furthermore, IMS-based IPTV enables the adaptation of the IPTV data stream to available network resources and the capabilities of user terminals. Thus, the user may access IPTV services not only at home but also on the move using a mobile terminal. Therefore, IMS-based IPTV enables the fixed and mobile converged IPTV. IMS-based IPTV also enables flexible control of IPTV services, thanks to SIP-based session control. For example, a user may use an IMS terminal to control the IPTV recorder remotely. Handovers of the active IPTV sessions between different screens—for example, from a laptop to a TV device—may be another interesting use of IMS-based IPTV services. IMS-Based Functional Architecture for IPTV Services The functional architecture of IMS-based IPTV presented [30] in this section contains main functions and reference points defined in ETSI TISPAN IMS-based IPTV concepts (including service control functions, media control functions, and media delivery functions). We enhance the short description in the TISPAN work item 2048 [23] and include our own extensions that have been contributed to TISPAN. Our IMS-based IPTV functional architecture, which is in line with the specification of TISPAN (Figure 19.8), has been implemented in the demonstrator of the ScaleNet project [24]. As shown in Figure 19.8, the user equipment (UE) can communicate with the IPTV application servers (including service control functions [SCFs]) over various interfaces for different purposes—namely, over the Gm interface via the IMS core for the session management purpose, directly over the Ut interface for the service profile configuration purpose, or over the Xa interface to interact with service selection functionalities. Each UE has at least four interfaces for media control over Xc and media delivery over Xd, as well as the Gm interface to IMS and virtual Xt interface to IPTV application servers. (In our prototype, described in the “IMS-Based IPTV Protocol Model” section, we have implemented service selection functions [SSFs], service discovery functions [SDFs], and SCFs in one IPTV application server, which implies that it is possible to merge interfaces Ut and Xa to one virtual Xt interface.) Ut and Gm interfaces should be fully compatible with 3GPP IMS specifications [25]. The IPTV application server functionalities use the ISC (IMS service control) interface to communicate with the IMS-based NGN service control functions. Media control functions (MCFs) can control media delivery functions (MDFs) over the Xp reference point that enables building a scalable and distributed media delivery infrastructure. External content can be imported from external media sources (e.g., the content providers or IPTV head end) via an external interface to MDF.

462


Ut

Xa

SSF SDF

Service Selection & Discovery Functions Sh Sh

Xt ISC UE Gm

UPSF

Service Control Functions SCF Application & IPTV Service Control Functions

Cx

ISC

IMS-based Session and Service Control (P-/S-/I-CSCF) e2 NASS

Gq´ e4

RACS

Xc

Transport Processing

Xd

Functions

y2

Media Delivery, Distribution & Storage IPTV Media Control Functions MCF Xp IPTV Media Delivery Functions MDF

Figure 19.8 Simplified TISPAN IMS-based IPTV functional architecture. (ETSI TS 182 027 V0.0.16 (2007-09).)

Core IP Multimedia Subsystem Overview The IMS [26,27] was introduced in the 3GPP [28] architecture release 5 and is being updated in releases 6 and 7. The IMS “service platform” is designed to assist and control (multimedia) sessions established between peers. Users willing to involve the IMS in their sessions will employ some of the IMS’s nodes as proxies for their session signaling. These IMS nodes (call service control functions [CSCFs]) only deal with the session signaling and control; they do not tackle the actual transport of data or media flows of the sessions. Indeed, these flows do not even traverse them. Still, the main characteristic of the IMS is that it can interact with the elements from universal mode telecommunications system (UMTS) networks—for instance, with the GGSN (gateway GPRS [general packet radio service] support node) routing the flows—and then, for example, influence the QoS that each flow will receive. This is done in a “graceful” way, respecting the Internet paradigm of transport and application separation. The fine QoS control achieved by IMS is of special relevance for applications with stringent QoS demands, such as A/V calls between users or IPTV. Main IMS elements are SIP proxies/servers, known in IMS as CSCF (Figure 19.9). To interact with these proxies, the user devices must implement

463

IPTV Modeling and Architecture over IMS S-CSCF P-CSCF

2

P-CSCF

3 IMS IPv6 Network

SIP Signaling

1

4

SIP Signaling

3G UMTS Network

User 1

GGSN

Voice, Video, ...

GGSN

User 2

Figure 19.9 IMS main blocks.

the functionality of a SIP user agent. The CSCFs handle all the SIP session signaling but they do not take part in and are not on the path of the application data [29]. Although the IMS offers control for many services by itself, it is also designed to interact with third-party service providers and its application servers (ASs). The ultimate goal is to build a very rich service environment that will attract users. One of the main services to be offered in this environment is IPTV. Many of the characteristics offered by the the IMS are just achieved by the use of the SIP. Any other service platform using SIP could provide the same results. However, the unique features offered by the IMS are achieved thanks to the IMS–network operator interaction. A rich service platform is achieved with features such as single sign-on; unified, nonduplicated billing; and a fine QoS control encompassing the different layers involved in the service delivery. The IMS aims to be the platform used by many services, and one of the most promising is IPTV. Service Discovery and Selection The SDF and the SSF provide the information necessary for a UE to select an IPTV service. The SDF is responsible for providing service attachment information about accessible IPTV services (personalized service discovery). In IMS-based IPTV, one or several SSFs are used to provide service information as well as personalized user preference information. In addition, information such as an electronic program guide (EPG) or a general service program

464


guide containing metadata, as well as information about media delivery sources, is also needed. IPTV Service Control Functions IPTV SCFs handle IPTV-related requests and execute service and session control for all IPTV services. These functions are also responsible for interworking with the IMS core on the service control layer. General tasks of SCF are summarized as follows: • session initiation and service control for IPTV services; • interaction with the IMS core and S-CSCF (serving CSCF) to receive, validate, and perform IPTV service requests from users; • service authorization and validation of user requests for selected contents based on the user profile information; • selection of the relevant IPTV media control/delivery functions; • customization of the user experience (e.g., TV channels presented to subscribers can be selected according to user profiles); and • credit control. IPTV Media Functions IPTV media functions include media control functions and media delivery functions. An important design principle for media functions is to realize flexible and hierarchical media delivery architecture for effective delivery of contents in a distributed environment. The main tasks of MCFs are summarized as follows: • selection of relevant MDFs; • propagation of contents to distribution networks and control of the asset (a package of contents) distribution to media delivery functions and user equipment; • applying policies of the content distribution and management; • storage management in the distribution and delivery networks; • mapping of content ID and content location to the corresponding MDF; • interaction with the UE (e.g., handling video-recorder-like RTSP commands); • control of network PVR (personal video recorder) and network time shift TV; • collection of statistical information about service usages; and • generation of billing information.


465

Media delivery functions are mainly responsible for the delivery of media (video, voice, and data) to the user equipment. Several additional functions are specified for MDFs: • handling media flow delivery; • storage of media (e.g., CoD assets) and service information; • storage of most frequently accessed contents or user-specific contents (e.g., recording PVR, time-shift TV, BC [broadcast] services with trick mode, and user-generated contents); • Processing, encoding, or transcoding (if required) media to various media formats (e.g., various TV resolutions depending on terminal capabilities or user preferences); • content protection (e.g., content encryption); • content ingestion of IPTV media; and • relaying of BC media streams to be multicast media streams. Media delivery functions can be distributed depending on service types (BC, CoD, PVR) or on specialized subfunctions composed of the following subcontents: metadata: describing contents/assets with SD&S data, EPG, or VoD catalog (it is expected that metadata will be used in standardized formats); and assets: a package of contents delivered to the user equipment; those assets were previously propagated by the SCFs to MDFs according to the availability, popularity, and regionalization of the contents.

IMS-Based IPTV Protocol Model This section provides a simplified model of IMS-based IPTV protocols and relations (Figure 19.10) [31]. First, it is necessary to start or boot a UE (such as a set-top box or any device with an IPTV client) and achieve network attachment to obtain network parameters (such as an IP address or proxy CSCF [P-CSCF] address). After that, the UE can initiate the IMS registration process with the IMS core and perform IPTV service attachment functions including service discovery to perform SDF tasks. The UE is then able to initiate the service selection process (using HTTP over Xa). The IMS IPTV user equipment needs to know this service selection information to establish an appropriate multimedia session by generating SIP INVITE messages during service initiation (over Gm towards home S-CSCF-Serving Call.

466

IP Multimedia Subsystem (IMS) Handbook Legend: IMS based IPTV model SIP RTP/RTCP Diameter RTSP HTTP

Ut Xa

SSF User & Service Data

Service Selection

SDF

Service Discovery

SCF Sh HSS

Service and ISC Session Control

Sh Cx

S-CSCFs Service Initiation and Session Control Gm UE

Xc Xd

Selection and Control of MCF

y2 MCF

User Controls of Media Streams


Xp

Control of MDF

MDF

Delivery of Media Streams to UE

Figure 19.10 IMS-based IPTV model.

Session Control Function-). The core IMS is able to initiate the resource reservation process for network resources needed by the IPTV stream according to the capabilities of the UE. The reservation is performed using standardized transport control functions of NGN RACS and NASS subsystems connected to the core IMS. After the successful session initiation, via the core IMS, the SCF informs the MCF in the media delivery platform (which contains media control and distributed media delivery functions), using the y2 interface, to start streaming the selected multimedia content. After establishment of the initial data stream, the user may control it over the Xc interface between the UE and the server performing media control functions. The RTSP protocol is used on this interface to control media delivery with features such as play assets, pause, forward or backward, or faster or slower, using an RTSP method such as PLAY or PAUSE. The MDF performs media delivery over the Xd interface based on RTP stream delivery. The following discussion provides more information about IMS-based IPTV model and protocol capabilities required from functional elements and related reference points. Usage of the SIP/session description protocol (SDP) protocol across the following reference points is described in clause 5 [31]:

467

IPTV Modeling and Architecture over IMS • reference points Gm, ISC, y2

• SIP/SDP-capable functional entities: UE, SCF, SDP, MCF, core IMS • SIP enhancement for IMS (ES 283 003) methods: IMS registration, session initiation, modification, and termination; additional SIP methods used in IMS-based IPTV: REGISTER, INVITE, UPDATE, PUBLISH, NOTIFY, MESSAGE, etc. Usage of the HTTP protocol across the following reference points is described in clause 6 [31]: • reference points Xa, Ut • HTTP-capable functional entities: UE, SCF, SSF Usage of the RTSP/SDP protocol across the following reference points is described in clause 7 [31]: • reference points Xc (over transport processing Di, Dj, Ds, or lz) • RTSP-capable functional entities: UE, MCF • The UE and MCF need to support several of the RTSP methods as summarized in annex H.3.1 [31]: −

PLAY, PAUSE, (mandatory)

−

OPTION (optional)

GET_PARAMETER,

SET_PARAMETER

• The UE and MCF need to support the following RTSP methods in case of method 2 used for CoD: −

DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN (mandatory)

Usage of the RTP/RTCP protocol across the following reference points is described in clause 8 [31]: • reference points Di, Dj, Ds, or Iz • RTP/RTCP-capable functional entities: UE, MDF Usage of the IGMP/MDL protocol across the following reference points is described in clause 8 [31]: • reference point Di • IGMP/MDL-capable functional entities: UE, transporting functions (ECF [Elementary Control Function]/EFF [elementary Forwarding Function]), MDF • If IPv4 is used for the transport, the UE should conform to RFC3376 (IGMPv3) • If IPv6 is used for the transport, the UE should conform to RFC3810 (MLDv2) Use of DIAMETER should comply with the following specifications: • TS 183 017 in case of the Gq′ reference point • ES 183 035 in case of the e2 reference point

468


• TS 183 033 in case of the Cx and Dx′ reference points • 3GPP TS 29 329 in case of the Sh and Dh reference points • DIAMETER-capable functional entities: core IMS, SCF, SDF Usage of the DVBSTP or FLUTE protocol across the following reference points is described in clause 9 or 10 [31]: • reference point Xa • DVBSTP- or FLUTE-capable functional entities (both optional): UE, SSF

Future Evolution of NGN-Based IPTV There are several topics beyond ETSI TISPAN release 2 and related IPTV specification. Several operators have already specified potential topics for release 3 work [32] and some of them will most likely become incorporated into release 3 IPTV specifications. Here, we summarize some of the main topics: • IPTV evolution, with particular focus on blended services, service interaction and content distribution, and evolution of QoS mechanisms • enhancement of the IPTV architecture with exposition of advanced capabilities, according to business roles proposed and accepted in TISPAN release 2 • migration scenarios for evolution of legacy IPTV systems to NGN-based IPTV architecture • blended services integrating or interacting between existing NGN services (e.g., communication services) and content/IPTV services • service enhancement, interaction, and openness • content distribution in IPTV architecture • Service Interaction Function: reference points and functions needed for service interaction in NGN-based IPTV networks and also for study in the separate subsystem context • new service capabilities for SCF • service continuity: not addressed by release 2 specification (A typical use case is when a user decides to transfer an existing session from one terminal to another without content delivery’s being interrupted.)


469

• enhanced mobility capabilities for IPTV services (cross-domain relation, roaming of IPTV services) • PVR evolution: release 2 specification covers network-PVR only. However, in some use cases a user may be willing to record contents on one of its terminal devices, possibly by sending a remote command from another terminal. A typical use case is when a user decides from his or her mobile terminal to record content in his or her fixed terminal. • user- or consumer-generated content: the release 2 specification covers the case where the contents are stored in the MF and does not make any assumptions on where these contents are generated. The increasing popularity of social networking services demonstrates a growing interest in user-generated contents. In order to support the case where contents are generated by a user and stored in a particular MF, procedures for triggering content recording from a UE will have to be defined. • mix between streaming and broadcast sessions: a typical use case is personalized ad insertion in a broadcast program • NNI for IPTV: reference points and functions needed to interconnect NGN-based IPTV networks between different IPTV service providers • third-party access for IPTV: reference points and functions needed to separate service control from network and session control in NGN-based IPTV networks • IPTV management • Management specifications (stages 1, 2, and 3) for the TISPAN IPTV solutions (IMS and non-IMS based) • IPTV security • Definition and investigation of security mechanisms for IPTV services and architecture

Conclusions According to the results presented in previous sections, IPTV consumers are especially concerned with the novelty of the offered contents (movies, soccer, documentaries, and so on). Customers are also keen on subscribing to flexible services adapted to their specific needs and favor single billing schemes. With regard to single billing and personalization, IMS will arguably provide a competitive advantage over alternative IPTV frameworks. It is expected

470


that by conforming to international standards, IMS will promote interoperability among service providers (content, transport, billing) and thus foster the existence of IPTV-related ecosystems. Because IPTV service providers could require smooth evolution paths from existing non-NGN solution toward NGN-based IPTV (in one or several steps), analyzing differences and similarities in architecture or protocols between actual IPTV and both NGN-based IPTV concepts (NGN-dedicated IPTV subsystem and IMS-based IPTV) can help operators and vendors to better assume optimal evolution scenarios toward IMS-based IPTV [33]. As in existing network services, customer support is paramount to the customer’s having a quality experience. According to presented results the main interface between the user and the service—that is, the decoder—is critical for a user’s adoption. At this point IMS-based IPTV services need to ensure ergonomic and usable interfaces (both hardware and software) for user interaction with the service. Contrary to other novel services, IPTV service competes against existing ones such as TDT or DVD; for this reason, users expect at least a similar quality while watching IPTV content. IMS-based IPTV services have to provision sufficient resources and mechanisms to ensure unmatched quality of video and audio services. At this point it is expected that the advanced signaling mechanism that IMS provides will help IPTV providers deliver optimum multimedia services.

References

1. 3GPP TS 23.228 V7.7.0 (2007-03). 2007. Technical specification, IP multimedia subsystem (IMS); stage 2. 2. ITU-T recommendation Y.2012. 2006. Functional requirements and architecture of the NGN. 3. ETSI ES 282 001 V1.1.1. 2005. TISPAN; NGN functional architecture release 1. 4. Suh, N. P. 1998. Axiomatic design theory for systems. Research in Engineering Design 10:189–209. 5. Suh, N. P. 2005. Complexity: Theory and applications. Oxford University Press. 6. Enthrone European Project. Overall system requirements and functional architecture specification. Deliverable 01. Available at http://www.ist-enthrone.org 7. Ramesh, J. 2005. I want my IPTV. IEEE MultiMedia 12(3):95–96. 8. Walko, J. 2005/2006. I love my IPTV. Communications Engineer 3(6):16–19. 8′. López, D. 2006. Quality of service characterization in telecommunication services. PhD dissertation, Technical University of Madrid (UPM), TESIS-06-018, November 2006. 9. Hands, D. S. 2004. A basic multimedia quality model. IEEE Transactions on Multimedia 6(6):806–816.


471

10. López, D., F. González, and L. Bellido. 2006. Delivering customer-oriented multimedia streaming services. Proceedings of IFIP Networking 2006. ISBN: 972-95988-6-9. 11. SCAMPI. European project. IST-2001-32404. http://www.ist-scampi.org 12. ETSI TS 102 034 V1.2.1 (2006-09). Technical specification, DVB; transport of MPEG 2-based DVB services over IP-based networks. 13. ITU-T Focus Group on IPTV. 2007. Working document IPTV-DOC-0084: IPTV architecture, 4th FG IPTV meeting, Bled, Slovenia, 2007. 14. ETSI TS 181 016 V2.0.8 (2007-11). 2007. Technical specification, TISPAN; service layer requirements to integrate NGN services and IPTV. 15. ETSI TS 182 028 V2.0.0 (2008-01). Technical specification TISPAN; IPTV architecture: Dedicated subsystem for IPTV functions, 2008. 16. ETSI TS 182 027 V2.0.0 (2008-02). Technical specification, TISPAN; IPTV architecture; IPTV functions supported by the IMS subsystem, 2008. 17. Alliance for Telecommunications Industry Solutions (ATIS). 2007. IPTV high-level architecture standard (ATIS-0800007), ATIS IPTV Interoperability Forum (IIF). 18. 3GPP TS 23.246 V8.0.0 (2007-09). 2007. Technical specification, multimedia broadcast/multicast service (MBMS); architecture and functional description, release 8. 19. Open Mobile Alliance. 2007. OMA BCAST, mobile broadcast services architecture, candidate version 1.0. 20. ETSI ES 283 003 V1.7.0 (2007-05). 2007. ETSI standard, TISPAN; IP multimedia call control protocol based on session initiation protocol (SIP) and session description protocol (SDP), stage 3. 21. Schulzrinne, H., A. Rao, and R. Lanphier. 1998. Real-time streaming protocol (RTSP), IETF RFC 2326. 22. Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson. 2003. RTP: A transport protocol for real-time applications, RFC 3550. 23. ETSI TS 182 027 V0.0.16 (2007-09). 2007. TISPAN; IPTV architecture; IPTV functions supported by the IMS subsystem, technical specification draft. 24. ScaleNet—The scalable and converged multi-access operator’s network from tomorrow. Project Internet site, http://scalenet.de 25. ETSI ES 282 007 V1.1.1 (2006-06). 2007. ETSI standard, TISPAN; IP multimedia subsystem (IMS); functional architecture. 26. Camarillo, G., and M.-A. Garcia-Martin. 2004. The 3G IP multimedia subsystem (IMS): Merging the Internet and the cellular worlds. New York: John Wiley & Sons. 27. Poikselkä, M. 2004. The IMS: IP multimedia concepts and services in the mobile domain. New York: John Wiley & Sons. 28. 3rd Generation Partnership Project. Available at http://www.3gpp.org 29. Cuevas, A., J. I. Moreno, P. Vidales, and H. Einsiedler. 2006. The IMS service platform: A solution for next-generation network operators to be more than bit pipes. IEEE Communications Magazine 44(8):75–81. 30. Mikoczy, E., D. Sivchenko, B. Xu, and J. I. Moreno. 2008. IPTV services over IMS—architecture and standardization. 31. ETSI TS 183 063 V2.0.0 (2008-03). IEEE Communications Magazine (May).TISPAN; IMS-based IPTV stage 3 specification, technical specification, 2008. 32. ETSI 16TD056r1. 2007. Operator priorities for Rel. 3, TISPAN #16 plenary meeting, Sophia Antipolis, 12–13 December, 2007. 33. E. Mikoczy. (2008). Next generation of multimedia services-NGN-based IPTV architecture, in 15th International Conference on Systems, Signals, and Image Processing IWSSIP, Bratislava, Slovak Republic, 25–28 June, 2008.

20 SIP-Based Prepaid Application Server Mario Weber

contents Preface.................................................................................................................... 473 Introduction.......................................................................................................... 474 Offline Charging.................................................................................................. 475 Offline Architecture................................................................................... 475 Online Charging.................................................................................................. 476 Online Architecture................................................................................... 476 Immediate Event Charging Example........................................... 477 Event Charging with Unit Reservation Example....................... 477 Session Charging with Unit Reservation.................................... 478 SIP-Based Prepaid AS Implementation............................................................. 479 Observed Shortcomings...................................................................................... 481 Dependency on End-User Terminals....................................................... 481 B2BUA Architecture................................................................................... 482 Failure Issues...............................................................................................483 Keep-Alive Mechanism.............................................................................. 486 SIP Stack Implementation.......................................................................... 486 Service State Machine................................................................................ 487 Charging for Usage of Supplementary Services.................................... 489 Conclusions........................................................................................................... 491 References............................................................................................................. 492

Preface As traditional communication networks move to IP-based protocols, session initiation protocol (SIP)-based applications have been rapidly introduced, bringing evolution to telecommunication services but also some new challenges. SIP is accepted by the 3rd Generation Partnership Project (3GPP) as a signaling protocol in the IP multimedia subsystem (IMS), an IP-based architecture that is expected to take over a main role from legacy signaling system 473

474


7 (SS7) networks. Services in the IMS are provided by application servers and while the number of services grows, it is essential to provide consistent and reliable charging mechanisms. This chapter aims to show challenges in implementing a SIP-based application server based on experiences collected while working on solutions for application servers that provide prepaid front-end functions, providing call control of prepaid sessions, allowing session-based charging with unit reservation as well as event-based charging, and other supporting prepaid functionalities such as self-care services for end users. Application servers (ASs) can be used to charge various prepaid services, but in this chapter we primarily analyze aspects of charging voice calls and usage of voice supplementary services. Several issues observed during the implementation and possible solutions are discussed. We will provide basic principles of offline and online charging as a background for examples shown in this chapter.

Introduction Incumbent telecom network operators are feeling the heat caused by the emergence of voice over IP (VoIP) telephony and are increasingly looking toward IP-based core networks because adapting is the sole path to survival. The real reason behind the drive to introduce IMS is a plain calculation: it is impossible to beat the price and scalability of packet transport, IP-based servers and services. However, ironically, just as in the circuit-switched world of yesterday, quality of service (QoS) and reliability require investments in ensuring redundant and highly available solutions. IMS will save money for the end user, but, at least for a foreseeable future, the user could lose the things he or she has taken for granted for the last 50 years: reliability and the simplicity of making a basic phone call. IMS relies completely on the SIP signalization protocol that was not planned with QoS and reliability in mind. This results in significant challenges faced by companies developing SIP application servers, network entities in charge of providing services to IMS users. The SIP is defined in RFC 3261 [1] as “an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.” The telecom industry had many expectations from this protocol, especially since, in November 2000, the SIP was accepted as a 3GPP signaling protocol in the IMS architecture [2]. The IMS is an IP-based architecture intended not only to replace circuitswitched with IP-based telephony but also to enable real convergence of services, such as voice, data, and video. With SIP, IMS brings an evolution of legacy telephony networks. In the legacy SS7 networks, call processing features were centralized; the SIP allows

SIP-Based Prepaid Application Server

475

advanced features to be moved to the network edge, embedded in end-user terminals. The SIP has evolved from the IP community rather than the telecom industry, and it is designed as a peer-to-peer protocol, where two endpoints can communicate without any network infrastructure. Furthermore, the SIP relies on the best-effort packet delivery principle, which is typical for IP networks. It does not provide the packet prioritization required for avoiding latencies in real-time services such as voice and video telephony, so implementation of such services relies heavily on the network capabilities. However, although these characteristics of the SIP may be acceptable in the Internet community, telecom providers need to keep control of services used in the network because they charge subscribers for the use of the services. The IMS provides an architecture that allows controlled telephony service by introducing proxy and registrar network elements in the core network (call session control layer). In the IMS, advanced features are provided by ASs located in the application network layer. With this approach, the IMS offers the ability to provide integrated services with expanded capabilities, whereas the network is unbundled into standardized components. As the IMS standards evolve and deployment of IMS networks worldwide accelerates, the SIP will probably need to evolve as well so that it can support integration and seamless flow of information among many elements of complex solutions. Experiences of integrators worldwide show the need to design individual protocol agents for the various SIP servers as opposed to the mistaken impression that one SIP implementation works for all.

Offline Charging Offline charging is a charging process that is used for no-real-time operations. Charging information is collected during the session but processed later. It is a traditional, legacy way of charging in which all network elements are collecting information while the service is active and the unit utilized by the user will not be scaled by the wallet’s user. At the end of the particular time period (e.g., 1 month), an invoice is generated (by charging data function) from the collected information. More information about offline charging can be found in reference 10. Offline Architecture Figure 20.1 depicts an offline charging architecture that is composed of the following nodes: • The charging trigger function (CTF) monitors service usage and, based on that, generates charging events.

476


CTF

Rf

CDF

Ga

CGF

Bx

Billing System

Figure 20.1 Offline charging architecture.

• The charging data function (CDF) generates CDRs (charging data records) based on events received from the CTF; it is also responsible for transferring CDRs to the CGF. • The charging gateway function (CGF) is responsible for collecting CDRs from many CDF entities and sending them to the billing system. • The billing system is responsible for processing received CDRs and generating final output (e.g., a customer invoice).

Online Charging Online charging is a process in which charging information is processed in real time (while the service is still running) and therefore directly communicates with session/service call control. The purpose of the online charging is to perform credit control before allowing a service to continue. All the services, prior to continuing, have to determine their value in units (money, time, volume) and deduct these units from the customer account or at least during the service usage. Online Architecture Figure 20.2 depicts an online charging system in a charging working framework architecture as defined in reference 10. There are some minor differences because the online charging system does not traverse the IMS gateway; rather, it is directly connected to the IMS core through the ISC interface. In online charging, two different charging models must be distinguished: • In direct debiting, the units are deducted from the customer account immediately in a single transaction. • In unit reservation, before allowing service to continue, an online charging system (OCS) reserves units on the customer account. This is mainly done because OCS does not know the duration of the service in advance. After service termination, a consumed unit will be deducted and if any unused units are left, they will be released and added to the customer account.

477


Online Charging System

S-CSCF

ISC

Session Charging Function

Rating Function

AS

Ro

MRCF SGSN

Event Charging Function

Correlation Function Account

Bearer Charging Function

CAP

Figure 20.2 Online charging architecture.

Three scenarios can be identified within these models: • immediate event charging (IEC) (direct debiting); • event charging with unit reservation (ECUR) (unit reservation); and • session charging with unit reservation (SCUR) (unit reservation) Immediate Event Charging Example In Figure 20.3, user equipment (UE) 1 sends a SIP MESSAGE to UE2. A triggering function calls the OCS to process the user request. The OCS calculates the amount needed for the service usage and checks the user account. After deducting the proper amount, service is allowed to continue. Event Charging with Unit Reservation Example Figure 20.4 depicts an ECUR example. The SIP message from UE1 is received by OCS. The OCS performs calculations against the user account to check whether the service can be allowed. If so, a unit will be reserved and service will continue; otherwise, service will be canceled. Upon receiving the 200 OK SIP response (which means that service is delivered successfully), the OCS deducts reserved units from the user account.

478


UE1

Network Element MESSAGE

OCS

UE2

MESSAGE Deduct Unit Credit from User Account

MESSAGE MESSAGE

Figure 20.3 Immediate event charging example.

UE1

Network Element MESSAGE

OCS

MESSAGE

MESSAGE MESSAGE 200 OK

200 OK

UE2

200 OK

Reserve Unit from User Account

200 OK Deduct Reserved Unit from User Account

Figure 20.4 Event charging with unit reservation example.

Session Charging with Unit Reservation A SCUR example is shown in Figure 20.5. The SIP INVITE message traverses the OCS system, which calculates the unit that needs to be reserved for the service to continue. If the user has enough money, units will be reserved and service will continue. During service runtime, OCS may perform more than one deduction of reserved duration and apply new reservations. Receiving the BYE message means the service is finished and calculation of the units from the last reservation until receiving the BYE message must be applied.

479


Network Element

UE1 INVITE

OCS

UE2

INVITE

INVITE

Reserve Unit from User Account

INVITE

BYE

BYE

BYE

BYE Deduct Consumed Unit from User Account

Figure 20.5 Session charging with unit reservation.

Consumed duration (not reserved if duration is shorter than reservation time) will be deducted from the user account and a message will be sent to the network.

SIP-Based Prepaid AS Implementation This chapter will discuss a project in which some interesting problems with implementation of a SIP-based prepaid application server have been encountered. The goal was to develop and integrate a prepaid application server in the IMS network with the role of call control for all call legs originating or terminating at prepaid IMS users. The prepaid AS uses a SIP ISC (IMS service control) interface for call control and for interaction with media resource servers for playing charging-related announcements, as well as for establishing calls to the prepaid self-care interactive voice response (IVR). During this project, we have been conducting front-end SIP ISC interface testing, and the purpose of this chapter is to present some of the experiences gathered throughout these tests and point out several shortcomings of the SIP ISC protocol observed, including those specific for the case when the application server is used to provide online charging capabilities in the network. The tests for the server have been conducted in an all-IP environment. A fully IMS-based core network combined with an IP-based access network ensures

480


Application Server

From: X To: Y Call ID: Z

SIP Dialog #1

SIP Dialog #1

From: P

SIP Dialog To: Q Call ID: R #2

S-CSCF

SIP Dialog #2

From: X To: Y Call ID: Z

From: P To: Q Call ID: R

Figure 20.6 Back-to-back functionality. (Diagram taken from 3GPP TS 23.218.)

that only SIP-aware VoIP terminals or legacy terminals connected through access devices can gain access to the network. A prepaid AS is required to enable real-time charging of the voice sessions established by prepaid subscribers. In order to achieve this, it has to maintain complete control of the call, allowing the system to disconnect the call if the subscriber has insufficient credit to fund the call. The control of the call is achieved by creating the system with back-to-back user agent (B2BUA) functionality. The SIP messages exchanged between two parties in the call are traversing through B2BUA, as shown in Figure 20.6. By mediating the endto-end call through a SIP server, the B2BUA enables management of a call from beginning to end, bringing class-5-type functionality to IP networks and enabling value-added services. Figure 20.6 depicts a call establishment procedure. After receiving a SIP request for a media session establishment, the prepaid AS opens a new connection toward the terminating party and ensures that all future messages pass through it by placing its address in the record-route SIP header [1], which provides it with the control of the call. Because it has connection to originating and terminating parties, the system is able to send the request for connection release at any time or reconnect sides to a new destination (e.g., to a media server for playing announcements). The call/session control function (CSCF) acts as a SIP proxy, routing the SIP requests to application servers based on subscriber information that it receives from the HSS (home subscriber server). The subscriber’s profile contains initial filter criteria (iFC) that define which application servers should be contacted for a particular service and in which order [3].


481

However, this solution is not entirely designed per IMS standards. Although prepaid charging is required, the overall solution design does not follow the IMS standard for charging [5]. Namely, the IMS charging identifier (ICID) is not shared between IMS network elements. The SCUR principle is used, but implementation is not based on DIAMETER [6]. This solution showed some shortcomings during the elaboration of the requirements and later in the process of development and testing. Testing with different end-user SIP devices available in the market showed that realization depends to a great extent on end devices and their capabilities. Due to the fact that intelligence is partially moved from the network to end-user devices, call control capabilities of the network are narrowed. The testing of the basic call established through multiple ASs in the IMS network showed that multiple sessions related to the same call are not correlated, which prevents design of features that may use such information and makes call tracking and error detection complicated. Separation of the signalization and the voice traffic channel may lead to a number of issues in case of failure of any of the many nodes and links involved in the session, showing the importance of redundancy and availability in the network. The SIP keep-alive mechanism showed an impractical way of detecting failure that occurred during the call in progress. In addition, during the system integration, the problem of the different implementations of the SIP standard was encountered. Also, some online charging-specific issues were observed during the design of the solution for charging the prepaid subscriber for usage of supplementary voice services such as call forwarding or call transfer.

Observed Shortcomings Dependency on End-User Terminals Moving from the circuit-switched world to a fully IMS-based core network solution induces a significant migration of intelligence from the core network to access devices. Diverse user agents or access devices (such as advanced VoIP terminals, access devices used to connect analog phones, and VoIP softphones) need to be configured properly to gain access to the IMS core. This is a significant change in philosophy from network-centric circuit-switched telecom networks, moving much closer to the organization of broadband Internet. Loosening the control over the network will inevitably lead to an increased demand for customer care and support. Another issue of concern is the loose standardization of SIP signalization that all heterogeneous SIP-enabled devices are sending. SIP messages originating at user agents can greatly differ in size (due to specific SIP headers used or capabilities exposed inside the session description protocol [SDP]),

482


giving less control to the core network over the SIP message transport. Messages larger in size (typically those of the more advanced terminals) than the MTU (Maximum Transmission Unit) of the backbone network cause router fragmentation, increasing the number of routing decisions the network routers will have to make. An even greater concern lies in the fact that messages within 200 bytes of the path MTU must be transported over a congestion-controlled transport protocol (such as a transfer control protocol [TCP]) [1], [8]. In practice, this means that SIP signalization for calls initiated on different terminals could use different layer-4 protocols. The tests have shown that the SIP stacks of many IMS equipment vendors can be very sensitive to the choice of transport protocol. Additionally, different treatment is required for UDP and TCP/stream control transmission protocol (SCTP) on proxy and application servers [4], so additional effort is needed to test the network with the most diverse user agents available. Another challenge for network design is service implementation on the terminals (e.g., ad hoc conferencing implementation on the terminal can be based on capabilities of terminals and thus fully transparent to the network, which could be unaware of the service and treat the conference as a set of basic calls). This can cause conflicts with any network-initiated announcements (e.g., low balance announcement for a prepaid user running out of funds) because the SIP AS can try to connect a user who is no longer in the call with the media server. Such is the case when a call is charged to the user who has transferred the call and this user is running out of money or, on the other hand, to play a warning to the user in the conference, resulting in all parties listening to the announcement. For this reason, any SIP AS implementation that does not have full visibility of the services invoked in the network or on user terminals should try to limit the call rerouting (e.g., to the media server for playing announcements) to only those scenarios where it has full control over the sides in a call. B2BUA Architecture The SIP was designed for session setup between two endpoints, called user agents (UAs), that make use of elements, called proxy servers, that help route requests. This media session would be established by only one SIP dialog between the SIP stack on the UA client and the UA server identified by a globally unique call identifier: a call-ID parameter shared on both sides of the call (among other SIP parameters; for details, see reference 1, section 4). However, each IMS network wanting to offer its end users more than just basic call establishment will have to rely on application servers providing voice features or network announcements. These application servers act as SIP UAs or, if they are performing third-party call control, they act as a back-to-back UA (B2BUA). A B2BUA is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests [1].

483


Dialog 1 Call-ID: abc

Dialog 5 Call-ID: mno

SIP Proxy

SIP Proxy

Voice Feature AS

Voice Feature AS

UAC

UAC

Dialog 1 Call-ID: abc

UAS

Dialog 2 Call-ID: cdf

SIP Proxy

Dialog 2 Call-ID: cdf

UAS

Dialog 3 Call-ID: ghi

Voice Feature AS

Voice Feature AS

UAC

UAC

Dialog 5 Call-ID: mno

UAS

Dialog 4 Call-ID: jkl

SIP Proxy

UAS

SIP Proxy

Dialog 3 Call-ID: ghi

Dialog 4 Call-ID: jkl

Figure 20.7 Basic call with five call-IDs.

The prepaid AS acts as a SIP B2BUA, terminating the SIP dialog toward the UA that started the call and acting as a UAC in generating a new SIP request toward the terminating side (Figure 20.7). Likewise, the IMS network environment of the prepaid AS also includes a voice feature AS providing voice services to IMS users while acting as a B2BUA. Figure 20.7 shows a simplified path of a voice call attempt between two prepaid IMS users. There are four B2BUAs on the signalization path of a call made between two prepaid users; consequently, five SIP dialogs are established when a single media session is started. These dialogs do not have a single parameter that would indicate that they are used to establish the same media session, which introduces difficulties in diagnostics. It also prevents application service logic to correlate multiple sessions that may be routed to the same AS as a result of different triggering conditions. If this correlation were possible, development of more complex voice services would be simpler. Failure Issues A large number of SIP dialogs established for each call makes another SIP deficiency even more critical: the lack of device failure detection. There is no mechanism in the SIP that would detect a failure of a SIP proxy or a user agent before a new request is sent to or through this device. Thus, a SIP dialog (which does not need and, in typical cases, does not have any in-call signalization between call setup and call release) can essentially be left hanging on an application server until the user’s registration expires. In the absence

484

IP Multimedia Subsystem (IMS) Handbook Call in Progress

Prepaid AS

UAC

Charging On

UAS

SIP Proxy Link Failure! Prepaid AS

UAC

Charging Continues!

UAS

User Disconnected! SIP Proxy

Figure 20.8 Overcharging problem in case of link failure.

of any call release messages, this would make the prepaid server believe that the call was still in progress (Figure 20.8). The consequence of this problem may not be only reliability and memory leak issues; it can also cause a server or a proxy to continue charging or executing some different logic for a call that has long before been released. To alleviate this issue, several possible mechanisms have considered how a B2BUA could discover whether the sides in the call and all servers in the path are still alive, such as periodically sending a SIP OPTIONS message (a request used for querying UA capabilities) to both sides and waiting for a response from them. A lack of a response or an error response would indicate a failure and should cause the call to be torn down. This approach, however, is not a common practice in SIPs and was dropped because it was considered too costly for performance because of the need to handle a large number of messages. It would not solve the main issue; if it were unable to detect a failure in real time, it would only speed up the detection process.

485


Signalization Voice

Figure 20.9 Voice and signalization links.

Separation of SIP signalization from the traffic, which is a packet stream of a voice call in our case, is inherent to IMS networks. As shown in Figure 20.9, the call setup (i.e., the signalization) passes through the IMS network elements (session border controllers, CSCF, application servers, etc.). After the end user accepts the call, the media channel is established using the shortest route to the user and thus bypasses the IMS network application servers. Because the connection between the end users is direct, the packet loss in the network is lessened and the end-to-end delays are shortened; the result of this is better quality of service. On the other hand, it could lead to another problem resulting with the inconsistent charging. Namely, the testing showed a possibility of signalization channel failure in which the voice communication would continue. Because the charging logic is based on the messages transferred over the signalization channel, the AS responsible for charging will stop the charging once user registration expires and the CSCF forces disconnection of the call. Still, if the voice channel is still up, the communication between two parties continues, and the operator will not be able to charge for that part of the call. It is also possible that the traffic channel carrying voice communication fails; if the end-user terminal does not have a built-in logic to detect this failure, it will not disconnect the session. As a result, the prepaid AS will not be aware that the actual call is released, and it will continue charging for the inactive session. Without receiving a release message, it is even possible that the prepaid user will run out of all account resources. These shortcomings lead to overcharging the user, which decreases satisfaction with the network and services provided, or to direct loss of revenue

486


for the operators. Generally, this could become a big problem in the commercial deployments of SIP-based telecommunications solutions. In the circuit-switched (CS) networks, separation of signalization and traffic channel is also used, but with the difference that network elements maintain full control of the call. In cases of signalization channel failure in CS networks, the voice communication also fails because both channels are routed over the same edge network elements. Circuit-switched networks are also designed with high availability and redundancy on all levels. When IMS networks are designed, in order to achieve the same quality of service as in CS networks, increased efforts should be made in extending availability of all involved elements as well as adding failover logic, which will be able to handle failure scenarios. Keep-Alive Mechanism The inherently built-in keep-alive mechanism in the SIP protocol showed similar deficiency to the one described in the previous section. In the IMS system, to be able to make or receive calls, the end-user terminal must be registered in the IMS network. The registration is performed by sending the SIP REGISTER message, which is periodically renewed (e.g., every 45 minutes) [7]. The existing mechanism is related to the signalization and takes care of it exclusively, but the described case of the voice channel failure is still possible. The registration by sending the SIP REGISTER messages proved to be an ineffective solution because it is still possible that only the end session fails. The other party remains hanging because the system does not realize that the connection has failed until the registration timeout expiration. When the system does not receive the keep-alive message, it will realize that the connection has failed and it will release the other party. The registration problem may be somewhat mitigated by sending SIP REGISTER messages more frequently, but then special attention to network dimensioning should be considered. For example, in a network with 1,000,000 users, if we assume that the keep-alive messages are sent every 2 minutes, every end-user terminal generates 30 messages per hour; with the response, it is 60 messages per hour per terminal. When this number of messages is multiplied with the number of users, we find that end-user terminals generate 60,000,000 messages per hour for keep-alive messages, causing significant overhead traffic. SIP Stack Implementation System integration with other IMS network elements showed that every application server vendor has its own SIP standard interpretation and its own SIP stack implementation. Every vendor followed the standard in some parts but also added several specificities into how its AS handles SIP messages. These proprietary extensions result in additional efforts when inte-

487


Service Layer

SIP State Machine

Response

Re

qu

es t

SIP Stack Re

qu es

t

Figure 20.10 PPFE architecture.

grating with other ASs, which may not be prepared to handle messages with nonstandard content. On the other hand, the simplicity of the SIP protocol, although it is a great advantage, proves to be a limitation when it is necessary to share call sessionspecific information among application servers that together provide the end user with full-service experience. Proprietary extensions may be required to solve integration issues in specific projects and for specific applications. In order to offer such complex solutions where the possibility to provide service could depend on how other ASs work, adjustments and cooperation among involved vendors are required. This delays deployment and requires additional resources that were not initially expected and planned for. The SIP standard is chosen for the ISC interface in the IMS network, which relies on the multiple ASs to offer network services. Thus, some modifications to the ISC interface may be required to standardize how ASs involved in the single session exchange session-related data. The SIP protocol is flexible enough to support such modifications. Service State Machine In order to work with a SIP protocol, a prepaid application server needs to have a service state machine on top of the SIP stack. Figure 20.10 depicts a simple prepaid application server architecture. It is composed of a SIP stack, SIP state machine, and service layer. As depicted in Figure 20.10, the SIP stack is responsible for receiving and sending SIP messages (request and response). Upon receiving a SIP message, the SIP stack delivers the message to the state machine. Based on the parameters from the SIP message or configuration parameters, the state machine delivers the message to the service layer. Not all

488


INVITE

Timeout

AS1

0O

20

S1

Cancel Prack

K

0O

20

S3

S4 K

te da Up Error

S5 Ack

Provisional 200 OK

AS2

AS3 BYE

S2

Timeout

AS5

AS6 AS7

BYE

Request

Ack

AS4

AS - Action State S - State

S6

Figure 20.11 Basic call setup state machine.

the messages are required to be handled by the service layer, so the state machine straight forwards these messages. All the charging is handled by the service layer, which represents the OCS but could contain account balance management function (ABMF) and rating function (RF) as well. The problem is in defining the state machine. If the state machine is not properly defined, some of the messages may be lost or, even worse, the service setup message chain may be broken, and that will cause failure. For instance, in a basic call setup, if the 200 OK message is lost, the call will not be established. The software architect should give special attention in designing a state machine. Many different scenarios must be covered. Also, which of the SIP messages should be sent to the service layer? Because all of them must be sent, the state machine should just forward the messages to the upper layer or only the one needed for the charging service. In each state, the state machine must know which message to expect and what to do with the message. Figure 20.11 depicts one state machine that covers a basic call setup scenario. At first glance, the state machine seems to be fine; all the messages that could traverse through the charging server are covered. However, a more careful look at state 1 reveals that it is obviously missing one very important message: 3xx redirect. There is no logic for handling a redirect message, creating a new request toward the redirected destination, and loop for all the servers listed in that request (if the first one is not reachable). In this case, upon receiving the 300 redirect request, the message chain is broken and the service setup fails.


489

One very important thing in the design phase is to define whether the SIP state machine is going to be service dependent or not. Service layers do not require all received messages, but the question is which one of the messages is to be delivered. The charging system requires initial messages (e.g., INVITE, re-INVITE, MESSAGE) and some responses (e.g., 200 OK), but some services may be combined with a charging system such as ring-back tone that requires a provisional response 180 ringing message. In this case, it is better to have all the messages forwarded to the service layer, keeping in mind that it will require a lot of processing. Also, by forwarding all the messages, part of the state logic is moved to the service layer. One of the solutions might be to have a list of the installed services with required messages. The state machine then knows which message to forward to the charging service and which to forward to the ring-back tone. As shown in Figure 20.11, the state machine is a very vulnerable point of the charging system if it is not defined properly. Each state and actions between states must cover all of the use case scenarios required by the services running in the service layer or possible services deployed in the future. Charging for Usage of Supplementary Services A prepaid solution is required to charge for the usage of supplementary services as well (i.e., call transfer, call forwarding, ad hoc conferencing, and similar services). In the network in which one prepaid AS was integrated, these services are provided by another SIP-based AS: voice feature AS. These services introduce a third party into the call, which in practice means that the voice feature AS needs to handle existing sessions and generate new sessions if required. Based on its internal service logic, the voice feature AS, issuing appropriate SIP requests, controls establishment of new sessions, cancels sessions that are no longer required, and updates existing sessions with new connection parameters. This implementation is sufficient in the network that does not require the prepaid AS to maintain control of all sessions related to online charging. With the introduction of prepaid functionality, this implementation shows some limitations, as explained in cases presented next. Charging for the call forwarding is a service in which the originator (user A) is normally charged for the call to the dialed destination (user B). If user B has call forwarding enabled, the call could be forwarded to a third party (user C). This decision is based on the user’s settings and made by the voice feature AS. Figure 20.12 presents an example of call forwarding on “no answer” (the proxy is left out for simplicity). A call between user A and user B is established, as shown in Figure 20.7. The voice feature AS detects that the terminating party fulfills criteria to forward the call to user C, and it simply issues a new SIP INVITE to user C, cancels the session to user B, and sends INVITE back to user A using the same call-ID but with updated parameters (replacing connection information of user B with user C). An INVITE request sent within an existing dialog is also known as a re-INVITE.

490

IP Multimedia Subsystem (IMS) Handbook Originating Party

1. Calling User B

Voice Feature AS

Prepaid AS

A´ UAC

A

UAS

B

UAC

UAS

B´

User A

C Terminating Party

2. Ringing

Voice Feature AS

UAC

E

UAS

C´

Prepaid AS

D

UAC

UAS

D´

User B

F

3. User B is not answering, forwarding to User C and reinviting User A

User C

Figure 20.12 Call forwarding.

The issue with such an implementation is that a prepaid AS needs to keep charging the A–B call as well as to start charging for the B–C call, but there is no initial SIP request for the call between user B and user C that could be used to trigger charging. Charging for that call in the same instance of B2BUA that charges for the A–B call seems feasible at the first, but taking into account that this instance is created only if user A is a prepaid subscriber, it is clear that this workaround will not cover all possible scenarios. The solution is in the fact that the user to be charged is user B, who was the terminating party in the original call, and if this user is a prepaid subscriber, the prepaid AS will receive SIP requests in the instance of B2BUA created for the terminating leg. Now, a new task is to find a way for the terminating instance to realize that call forwarding is in place. There are basically two ways to achieve this. The first is for re-INVITE to contain all necessary data required for charging—basically, an indication that re-INVITE is a result of a call forwarding action and the phone number of user C. The second option is for the voice feature AS to issue a SIP message 181—call is being forwarded—that has a tag indicating a new destination party. In either case, the prepaid AS will receive sufficient information to start charging user B for a call to user C; also, a flag indicating that call forwarding is in place could be used to apply call forward–specific rating. Call transfer is a service in which one user is involved in two simultaneous call sessions, one of which is on hold, and decides to transfer a party with whom he or she is communicating to the other, held party. Normally, charg-


491

ing is applied for both calls, always charging the user who originated the particular call. Assuming that all parties involved are prepaid users, both calls are established as shown in Figure 20.7. Whichever party is transferring the call must be subscribed to the call transfer service at the voice feature AS. When the user decides to perform call transfer, the terminal issues a SIP REFER message that reaches the voice feature AS. Service logic there continues by disconnecting the transferor from both calls and sending re-INVITE to the remaining two parties, updating them both with connection parameters of the other party and effectively connecting them to the new session. From the prepaid charging point of view, nothing has changed, and it can continue to charge both calls—for example, call A–B and call B–C if B was the transferor. However, if the operator wishes to apply a call transfer–specific rating, then re-INVITE requests issued to parties remaining in the call should contain tags indicating that call transfer is in place. Such additional information may then be used in the rating logic. It is important to emphasize that the configuration of the iFC influences the design of the prepaid charging logic that would be applicable for all call transfer scenarios. There is no standard that defines the order of triggering AS by server (S)-CSCF, so the possible order could be different from the one used in the presented examples (i.e., in the chain, the prepaid AS may be closer to the end user than the voice feature AS). In such cases, the SIP REFER would pass the prepaid AS before reaching the voice feature AS. Once the transferor is disconnected, the prepaid AS will also be disconnected from the chain and any call-charging logic started there will be stopped, which is not desired.

Conclusions The SIP protocol shortcomings described in this chapter were observed during development and testing of the prepaid application server; in our opinion, they represent major issues in development of application servers that need to integrate with the IMS core. These shortcomings represent challenges that should be considered when building an IMS AS as well as in further standardization of the SIP protocol and ISC interface. Because the IMS is based on standards avoiding costly proprietary solutions, it is expected that no network would be able to compete with implementation based on the SIP in the matter of price. Rather, introducing the QoS, satisfying data persistency, scalability, and high availability require additional clusters and backup servers in the networks based on a SIP protocol, which increases complexity and cost of the solution. This chapter aimed to show limitations of a SIP-based AS in providing advanced prepaid charging features in the IMS and to investigate possible solutions within such a framework. There are other solutions for prepaid

492


charging; most preferably, a solution can be sought in introducing OCS as proposed in 3GPP release 6 [10,11]. Implementation will still rely on ISC, but the IMS gateway function will be introduced as mediation between S-CSCF and OCS. The IMS gateway function will still need to address many of the issues observed and discussed in this chapter.

References

1. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. 2002. SIP: Session initiation protocol, RFC 3261. 2. 3GPP TS 23.228. 2006. IP multimedia subsystem (IMS); stage 2. 3. 3GPP TS 23.218. 2006. IP multimedia (IM) session handling; IM call model; stage 2. 4. 3GPP TS 24.229. 2006. Internet protocol (IP) multimedia call control protocol based on session initiation protocol (SIP) and session description protocol (SDP). 5. 3GPP TS 32.260. 2005. IP multimedia subsystem (IMS) charging (release 6). 6. 3GPP TS 32.299. 2007. DIAMETER charging applications (release 6). 7. 3GPP TS 24.228. 2003. Signaling flows for the IP multimedia call control based on SIP and SDP; stage 3. 8. Floyd, S. 2000. Congestion control principles, RFC 2914. 9. Camarillo, G., and M. A. Garcia-Martin. 2004. The 3G IP multimedia subsystem (IMS). New York: John Wiley & Sons. 10. 3GPP TS 32.240. 2005. Charging architecture and principles (release 6). 11. 3GPP TS 32.296. 2007. Online charging system (OCS): Applications and interfaces (release 8).

21 JAIN SLEE Platforms for IMS Application Servers Igor Vukomanović

contents Preface.................................................................................................................... 494 Introduction to JAIN and Related Technologies............................................. 494 History of JAIN........................................................................................... 494 JAIN SLEE Overview................................................................................. 495 Resource Adapters.......................................................................... 495 Events ............................................................................................ 495 Activities and Activity Contexts................................................... 496 Services and Service Building Blocks (SBBs).............................. 496 JAIN SLEE in the Context of IMS...................................................................... 496 IMS Application Servers—An Overview................................................ 496 SIP User Agent................................................................................. 498 SIP Proxy Server.............................................................................. 499 SIP Redirect Server......................................................................... 499 SIP B2BUA (Back-to-Back User Agent)......................................... 499 Analysis of JAIN SLEE-Driven IMS Application Server.......................500 Performance.....................................................................................500 Protocol Support.............................................................................500 Stability and Scalability................................................................. 501 Fault Tolerance................................................................................. 501 Case Study—Online Charging Application Server............................... 502 Solution Overview.......................................................................... 502 B2BUA Functionality...................................................................... 503 Charging Function.......................................................................... 505 Charging in Case of Back-End ABMF/RF Unavailability......... 505 Charging of Emergency Calls....................................................... 505 iFC Configuration........................................................................... 506 Dimensioning and Performance Observed................................ 506 Conclusion............................................................................................................. 507 References............................................................................................................. 507

493

494


Preface Many different standards, technologies, and vendors exist in the highly competitive market of service delivery platforms for next-generation networks. JAIN (Java application programming interfaces for integrated networks) SLEE (service logic execution environment) is one of these standards that has gained momentum very fast, with the commercial deployment count growing undisputedly during the last few years. It already has deployments in IMS (IP multimedia subsystem) networks as application servers, which is a theme explored throughout this chapter. First, a brief history of the JAIN initiative is given, explaining the reasoning behind open, Java-based network application programming interfaces (APIs). Then an overview of the JAIN SLEE standard is given, along with the description of its basic elements. IMS application servers are presented next, followed by the analysis of key factors to consider when implementing such an application server on a JAIN SLEE platform. Finally, a case study is presented with the description of an IMS online charging application server built on a commercial JAIN SLEE implementation.

Introduction to JAIN and Related Technologies History of JAIN JAIN is a technology initiative founded by Sun Microsystems in 1998. Its scope is to bring wireline, wireless, and IP communication interfaces into a set of industry standards based on Java technology. The telecommunications industry, especially in the domain of next-generation networks, expressed the need to change the market from proprietary systems to an open architecture on which services can be built. This was a direct consequence of the fact that service providers have become complex, their architectures vertically integrated and heterogeneous. Providers also tend to merge and introduce new technologies without using common and standardized interfaces. Introduction of new services thus becomes difficult because the complexity of the system becomes too great, and the maintenance issues grow as well. The JAIN initiative prepared an answer to this need and has defined a set of Java technology APIs for development of open, portable, and networkindependent products. They can be divided into Java application interfaces and Java application containers. Application interfaces provide a mapping of telecommunication protocols to Java programming language, and application containers provide an execution environment for telecommunication services. Today, JAIN is a community of more than 85 companies, including leading hardware providers, network equipment providers, and protocol and service providers. JAIN APIs are produced under JCP (Java community

JAIN SLEE Platforms for IMS Application Servers

495

process), which is a community-based process for developing Java specifications, reference implementations, and compatibility test suites. JAIN SLEE Overview JAIN SLEE is a standard that defines a container for telecommunications services providing a common runtime environment; work on it started in 1999 and the final release was produced in 2004. It is specified as a JCP Java specification request (JSR) 22 [1], specifically targeting high-frequency communications systems with its asynchronous, event-driven architecture. Today, two commercial and one open source implementations exist on the market. Basic elements of the SLEE container will be described next. These include resource adapters, events, activity contexts, and the runtime environment, which hosts service building blocks (SBBs). Resource Adapters A resource adapter allows a SLEE container to communicate with external entities, such as network devices, databases, or protocol stacks. It is a bridge between a SLEE enclosed system and the external world. This communication between external entities and a SLEE resource adapter is event based and bidirectional. One direction is network initiated: when an event is generated by the network, a resource adapter captures it and forwards the event to SLEE activity contexts, which are responsible for delivering the event to SLEE services. The alternate direction is SLEE initiated: the service fires an event that goes to the resource adapter and then to the native protocol stack. SLEE implementations today offer resource adapters covering a wide range of telecommunication protocols, such as SIP (session initiation protocol), INAP (intelligent network application part), CAP (configuration access protocol), TCAP (transaction capabilities application protocol), SMPP (short message peer-to-peer protocol), and DIAMETER, just to name a few. Events Events are objects that are responsible for transport of information among various SLEE entities and are represented by Java event objects. Usually, the event signifies an occurrence that requires processing by the SLEE service. Each event is assigned with the appropriate event type, which determines the routing of the event to other SLEE entities. Each service and resource adapter may declare which event types it is interested in receiving. The routing of events among SLEE entities themselves is handled by the internal SLEE component known as the event router. Examples of events are timerinitiated scheduled events, initial network events for establishing a call, and a change in the provisioned service data.

496


Activities and Activity Contexts In SLEE terminology, the concept of an activity is usually defined as a related stream of events, which can be interpreted as a session or a call. It is represented by a Java activity object, typically generated by resource adapters stimulated by various network events. Activity context, another SLEE concept, is the underlying activity in the SLEE that holds activity objects. It can be seen as a channel that carries messages between resource adapters and services. Services typically use the activity context interface, which is a Java representation of the activity context, to access some specific activity object and fire events on that object. In the opposite direction of information flow, when a resource adapter receives a network event, it creates an activity object and associates it with an activity context. After that, SLEE mechanisms are responsible for delivery of the event to the services. Services and Service Building Blocks (SBBs) In JAIN SLEE, services are manageable units composed of one or several SBBs. The platform administrator manages the deployment, undeployment, and upgrading of a service through management interfaces. An SBB is a software component that communicates via events and performs service business logic based on the received events. It is a reusable component that may be composed of several other child SBBs, in case more complex application logic is required. SLEE typically creates an instance of the SBB when a session or a call is to be established by initial network events. In JAIN SLEE terminology, this instance is called an SBB entity, and it is able to keep track of the session state. Examples of services are VPN (Virtual Private Network) and Find Me Follow Me.

JAIN SLEE in the Context of IMS IMS Application Servers—An Overview Logical architecture of the JAIN SLEE container, with examples of the elements previously described, is shown in Figure 21.1. One of the main ideas behind the IMS network is providing innovative services to end users, whether to the originating, terminating, or both call legs in the session. In the IMS architecture, services are provided by utilizing various kinds of application servers. Usually, many application servers coexist in the network, each responsible for a subset of services being delivered. Typically, application servers communicate with the S-CSCF (serving call/ session control function) node via the standardized SIP interface (ISC [IMS service control]). Optionally and under special circumstances, communication can be established with the HSS (home subscriber server) also, via the

497


Common SLEE Facilities

Alarms Timers

JMX Agent

Management Interfaces

SBB A (Service 1)

SBB B (Service 1)

Management Layer

Service Layer SBB C (Service 2) Activity Layer

Activity Context 1

Event Flow

Activity Context 2

Transactions Profiles Tracing

Resource Adapter 1 (Diameter)

Resource Adapter 2 (SIP)

JAIN APIs

Resource Adapter Layer

Network Resources

Figure 21.1 Logical architecture of the JAIN SLEE container.

DIAMETER-based (RFC 3588 [2], 3GPP TS 29.328 [3], 3GPP TS 29.329 [4]) Sh interface. If the service provided by an application server requires manual configuration by the end user, it may be possible for the server to implement additional interfaces, such as HTTP (RFC 2616) [5], WAP (wireless application protocol) [6], or XCAP (XML configuration access protocol) [7]. These protocols would then enable user-friendly interfaces for service configuration. According to the IMS specification [8], three different types of application servers are defined: • SIP application server; • OSA-SCS (open service access service capability server) application server; and • IM-SSF (IP multimedia service switching function) application server. The SIP application server is native to IMS; others act as gateways to the OSA and CAMEL services and will not be discussed here. When observed from a session point of view, SIP application servers can act in different ways [9]: • originating/terminating SIP user agent; • SIP proxy server;

498


Terminating SIP User Agent

2. INVITE

1. INVITE

4. OK

5. OK

6. OK

User Agent

3. INVITE

P-CSCF

S-CSCF

APP SERVER

APP SERVER

User Agent 2

11. OK

12. OK

P-CSCF

6. INVITE (B) 7. OK

9. OK 5. INVITE (B)

2. INVITE (A)

1. INVITE (A)

User Agent 1

10. OK

3. INVITE (A) 4. INVITE (B)

SIP B2BUA

8. OK

S-CSCF

P-CSCF

Figure 21.2 Some examples of SIP application server operational modes.

• SIP redirect server; and • SIP B2BUA (back-to-back user agent). Some of these scenarios are shown in a simplified form in Figure 21.2. Combinations are also possible when one application server acts in different ways depending on the service being executed (for example, it can sometimes act as a SIP user agent and sometimes as a SIP proxy server). The following sections describe each scenario in more detail. SIP User Agent An application server can act as a user agent in such manner that it terminates a SIP session, in which case it is known as a terminating SIP user


499

agent. Answering machines and IVR (interactive voice response) machines are some examples of services using this model. Another possibility is that an application server initiates a SIP session, in which case it is known as an originating SIP user agent. For example, a user can set up a video surveillance system connected with an application server, which would initiate a call when motion is detected. SIP Proxy Server As opposed to a SIP user agent scenario, the application server acting as a SIP proxy neither originates nor terminates a SIP session. It acts as an intermediary routing server. In this case, the CSCF node forwards the traffic to the SIP proxy node, which executes the service and forwards the traffic back to the CSCF. This is possible to achieve using SIP headers, which are allowed to be modified by the proxy server. Some of them are Route headers or RequestURI (uniform resource identifier) headers. A simple service that uses this scenario is call forwarding, implemented by an application server replacing the value of the Request-URI header field with the new destination URI. SIP Redirect Server An example of this scenario is CSCF forwarding the INVITE request to the redirect server, which generates a 302 (moved temporarily) response including a Contact header field with the information about the new URI to contact. This response is forwarded back to the originator, who initiates a new INVITE request with a new Request-URI. Essentially, this scenario is used to move the forwarding logic away from the operator, who is not interested in being part of the session being forwarded. SIP B2BUA (Back-to-Back User Agent) This is the most complex scenario; the application server is acting as two SIP user agents (originating and terminating) at the same time, with the service logic on top. There are similarities between a SIP proxy server and a B2BUA because, in both cases, the application server receives requests and forwards them and, at the same time, receives responses and forwards them. However, although the SIP proxy server’s actions regarding the session are limited, a B2BUA is allowed unlimited call control: it can change any SIP header, it can change the method in the SIP request as well as the session description protocol (SDP) content, and it can also generate new SIP requests and call legs. A prepaid application server is one example of this scenario. This kind of server may tear both originating and terminating sessions if the originating user runs out of credit, and it may reject the call setup if the calling user does not have enough credit for the call initiation.

500


Analysis of JAIN SLEE-Driven IMS Application Server When considering implementing an IMS application server on the JAIN SLEE platform, some of the key points of interest for analysis are performance, protocol support, stability and scalability, and fault tolerance. Performance There are several factors to outline when considering the requirements for a high-performance service execution platform: throughput, latency, and high availability, which will be briefly defined next. Throughput defines the number of operations that can be performed within some predefined time interval—for example, 50 calls per second. It is one of the critical requirements for carrier-grade services because rejecting the calls can cause a direct loss of revenue. Latency defines the time window from the moment the event enters the system until the moment processing is complete. Latency is important for user experience as well as for online charging systems. Telecom operators usually require call setup latency to be under 500 ms. High availability defines the time percentage when the system is operational. In other words, it is a requirement that ensures operational continuity in a time period measured. A typical example is “five nines” or 99.999% availability, which translates to less than 6 minutes of a nonoperational state in 1 year. When analyzing JAIN SLEE architecture compared to other related network technologies (J2EE, SIP Servlets, OSA Parlay, etc.), it can easily be seen that JAIN SLEE’s asynchronous paradigm is specifically designed for lowlatency and high-throughput telecom environments with a high availability designed to match the requirements. SLEE components communicate by exchanging events rather than by invoking synchronous APIs. This is the key advantage that leads to the conclusion that it can successfully be used as a business-critical application server in the IMS domain. Also, specialized communication functions such as OSA, SIP, presence, or online charging need to support applications designed using asynchronous event-driven components with transactional characteristics, low latency and high throughput, where JAIN SLEE again fits nicely into the concept. High availability is supported in today’s commercial implementations with the ability to perform a hot deploy and undeploy of the services on a SLEE node and also with the ability to replace online a platform in the cluster array without impact on the existing sessions. This reduces maintenance downtime significantly and thus provides a high degree of continuous availability. Protocol Support Support for all protocols required in the IMS (ISC, DIAMETER Sh, Ro, Rf, GSM MAP, CAP, etc.) should be available in a unified and consistent way,


501

as should support for multiple non-SIP protocols for legacy integration and future flexibility within a standard framework. The resource adapter framework in JAIN SLEE meets these requirements. SLEE implementations of today provide a wide array of resource adapters, supporting all of the previously mentioned protocols. Stability and Scalability Stability relates to the resilience of the system under extreme conditions, such as memory depletion, storage space depletion, or running faulty services. In the IMS environment, for many services this means soft switchlike performance. The JAIN SLEE service programming model supports system stability by strong typing and focusing on the business logic, leaving session state management under a responsibility of the platform. In this way, common application level programming errors are avoided. Also, the platform itself manages memory, transactions, process handling, and clustering. Scalability defines the ability of a system to increase its processing capacity with the increase of the installed hardware. The system can then be scaled vertically (adding hardware resources in a single node) or horizontally (adding more cluster nodes). However, scalable systems often demonstrate capacity thresholds after which additional hardware increase does not lead to proportional increase in processing capacity. This is why linear scalability is often a desired property of the system, which ensures that any increase in the hardware will always result in a proportional increase of the performance. JAIN SLEE is a multithreaded architecture that allows distributing processing between CPUs and concurrent service execution. Tests carried out on IBM BladeCenter-T hardware demonstrated linear vertical and horizontal scalability of commercial SLEE implementation. Fault Tolerance Fault tolerance is a system property that ensures a system will continue with normal operation, even when some of its components fail. IMS application servers typically ask for N-way active symmetric fault tolerance architecture, in which a session will not fail when a cluster node goes down. JAIN SLEE commercial implementations provide means to cope with this requirement through a carefully designed replication and redundancy model. Multiple identical system instances are replicated, with each instance sharing its internal state among other instances. This provides detection and management of component failures, as well as node failures. When a component fails, the effect of the failure is isolated from the other services and from the container that detected it. When a node fails, the sessions are processed by the remaining nodes in the cluster.

502


Case Study—Online Charging Application Server In this chapter a case study gathered from an experience of building an online charging application server in the IMS domain will be presented. The solution and its main functionalities will be described next, followed by a brief overview of dimensioning and the observed performance of the system. Solution Overview The online charging server, also known as the prepaid server, is responsible for charging prepaid corporate and residential subscribers for basic voice call sessions as well as for class-5 hosted voice and data features. The initial data service offered is simple Internet access. The solution described here is achieved using a commercial implementation of JAIN SLEE, on top of which a prepaid front-end server is built. This server is working as a B2BUA and data prepaid server. Communication with the IMS core is based on the IMS–ISC interface, and a proprietary prepaid API is used for communicating with the data infrastructure. The prepaid application server uses a backend account balance management function (ABMF) and rating function (RF) for managing and rating subscriber accounts. The following services are supported by the solution: • basic voice charging; • low-balance announcements; • call transfer; • call forwarding; • ad hoc conferencing; • meet-me/bridge conference; • voice mail; • short code activation of class-5 services; • data prepaid charging; and • self-care for prepaid subscribers via interactive voice response (IVR) and Web portal. Figure 21.3 shows the high-level architecture of the solution. The IMS prepaid voice service operates as a state machine that takes care of establishing, maintaining, releasing, and charging sessions to end users of the system. Voice over IP (VoIP) session charging is performed according to voice session duration (based on tariffs defined, concerning time of day, day of the week, destination of the call, etc.). Voice prepaid service also supports session charging to end users in case of call forwarding, call transfer, ad hoc conferencing, and meet-me bridging. The service receives network events from the SIP RA (initiated by incoming SIP messages to the application server), processes them, and, if necessary, initiates the communication toward.

503


IMDB

SLEE CONTAINER

Event 1 Event 4

VOICE PREPAID SBB Tree Event 3

Event 2

CDR

SLEE Event Router Event 4

ISC

SIP RA

Event 3

Event 2

ABMF/RF RA

Proprietary API

Event 1

ABMF/RF (back-end) S-CSCF Figure 21.3 High-level architecture of a JAIN SLEE-based IMS prepaid application server.

back-end ABMF/RF. The service does not have a direct connection with SIP RA or with ABMF/RF RA. The entire communication is performed by the exchange of events. This is significant for the future use of the business logic module because there is a possibility of developing resource adapters that enable connectivity with different rating servers by utilizing different protocols—for example, DIAMETER, RADIUS, or other proprietary protocols. B2BUA Functionality The prepaid front end provides B2BUA functionality as one of the operating scenarios of an IMS application server. Upon receiving an initial SIP INVITE request for establishing a connection, a prepaid application server creates a new SIP session and forwards SIP INVITE with a new call-ID of the new

504


Prepaid Application Server (JAIN SLEE) B2BUA A-B (orginating)

B2BUA A-B (terminating)

[2] [3]

[3] [4]

[1] CSCF

[1] [2] [4] [5]

Voice Feature Application Server

User A [5] Originating sessions Terminating sessions

User B Figure 21.4 Call flow with prepaid server included in originating and terminating sessions.

session back to the CSCF. This ensures that the SIP signalization flow goes through the prepaid server and that the prepaid server keeps control of both sessions. Figure 21.4 shows the call flow for a scenario where a prepaid subscriber (user A) initiates the call. In this case, the CSCF consults the originating initial filtering criteria (iFC) for subscriber A and sends a request (session 1) to the voice feature application server before routing the request to the prepaid application server (session 2). Upon receipt of the request, the instance of the B2BUA handling the call from user A to user B is created. At the prepaid server, the request is recognized as originating by finding the orig parameter in the Route header of the INVITE message. This instance of the B2BUA will be responsible for charging user A, based on session duration, origination and destination numbers, and, optionally, some other parameters required for rating. The prepaid application server is triggered again (session 3) for a terminating request because the called party is also a prepaid subscriber. At that moment, an instance of the terminating B2BUA for a call from user A to user B is created. The request is recognized as terminating because no orig parameter is found in the Route header of the INVITE message. This B2BUA will not apply charging for the call, but it will check if user B is allowed to receive the call.


505

The voice feature server is then called again (session 4) for the terminating request before the request is directed to the called party (session 5). Charging Function Back-end ABMF and RF ensure implementation of different rating options based on the session duration and other different parameters such as time of day, day of week, originating number, or destination number/zone. Charging logic is based on the assumption that the calling party is charged for originating the call. When a prepaid application server requests quota from the ABMF/RF, it will use all relevant rating parameters that could be extracted from incoming SIP INVITE and subsequent SIP messages. These could be originator and destination numbers and timestamp, as well as indication of specific events (call transfer/call forwarding), if detected by the prepaid front end. The application server will measure time, and when a quota threshold is exhausted, it will request a new quota. Once the call is terminated, the unused portion of the previously authorized quota from the ABMF/RF is returned to the subscriber’s account. ABMF/RF is requested to charge for used quota only. In the case of unsuccessful call setup, the entire unused quota will be returned to the subscriber’s account. Charging in Case of Back-End ABMF/RF Unavailability If back-end ABMF/RF servers are not available, the prepaid application server system will reject any service as default system behavior. This is controllable through the configurable parameter on the prepaid front end. If the service is allowed, the system uses the default number of units for the quota reservation, which is manageable through a configurable parameter. This is particularly interesting for the data prepaid charging function. In this case, the application server will generate a service detail record (SDR) with the outstanding charging information. An outstanding charging clearance procedure is implemented externally. Charging of Emergency Calls In general, the role of the prepaid charging application server is service authorization of service usage and charging of the chargeable services. Emergency calls are inherently free services accessible to all users under any circumstances. Therefore, the application server does not perform any additional service logic on the emergency calls. This solution implies that one of the two following options is implemented: • Emergency calls are not routed to the prepaid application server by the network. Filtering could be implemented on S-CSCF, with the iFC rule set on request URI of the emergency numbers.

506


• Emergency numbers are labeled as free numbers in back-end ABMF/ RF translation tables; for numbers with such a label, a dedicated tariff plan branch is added that results in free rate. iFC Configuration The S-CSCF forwards SIP requests to application servers based on iFC/shared configuration. The iFC could be configured to trigger a specific application server for both originating and terminating initial requests. The iFC configuration described in the following sections applies to prepaid subscribers only. Generally, a prepaid application server will generate a new instance of a B2BUA application for each initial SIP INVITE request received from the CSCF, whether it is an originating or a terminating request. Originating request. The profiles of prepaid subscribers include the prepaid application server in the list of application servers to which CSCF sends the request as a result of the iFC matching. This ensures creation of a B2BUA instance that will check if the prepaid subscriber is active and if he or she has enough balance on his or her account. The B2BUA instance will keep control of the call, and if the user runs out of balance, the call will be disconnected. Terminating request. In addition to handling an originating request, the prepaid application server should receive terminating requests to provide full prepaid functionality. The terminating request will be routed to the prepaid application server in situations where the called party is a prepaid subscriber. This will allow the application logic to check if the called party is allowed to take the call, because the subscriber’s prepaid account could be in a state in which incoming calls are not allowed—for example, when the account has expired. Additional iFC is required to support call forwarding scenarios. All prepaid users who use call forwarding should have this iFC defined at the end of the iFC loop. Dimensioning and Performance Observed The solution was achieved using two clusters of SUN Sunfire v490 hardware hosting a JAIN SLEE prepaid front-end application server. Under the initial assumptions of traffic load, the platform was dimensioned to accept an average load of more than 300 calls per second, with the average call duration of 240 seconds per call. Laboratory measurements have shown each cluster can support slightly more than 200 calls per second, whereas two combined clusters support an aggregate load of more than 400 calls per second, with system latency within 500 ms as required. This was fully within JAIN SLEE expected scalability, throughput, and latency, as discussed in previous chapters.


507

Conclusion By allowing Java applications a secure access to the network, new opportunities have emerged to leverage a large community of Java developers and create many innovative services, compared with only a few that currently exist. JAIN technologies are effectively changing the telecommunications world from proprietary systems to an open network architecture suitable for rapid deployment of new services. Convergence and openness are two challenges that the JAIN initiative addresses with much success. Large operators can also leverage JAIN SLEE to deploy new services in different countries, regardless of the network specifics of regional operators. In the field of IMS, the JAIN SLEE technology initiative enables the creation of carrier-grade performance asynchronous application servers, such as the prepaid application server presented in the case study. All the protocols required in the IMS domain, such as ISC or DIAMETER applications, are already fully integrated and supported by JAIN SLEE implementations. Of course, other solutions are more suitable for some specific purposes in telecommunications, but few are able to outperform JAIN SLEE design for the carrier-grade service delivery on one universal platform.

References

1. Sun Microsystems, Inc. 2002. JSR 22: JAIN SLEE API specification. http://jcp. org/en/jsr/detail?id=22 2. Calhoun, P., J. Loughney, E. Guttman, G. Zorn, and J. Arkko. 2003. DIAMETER base protocol, RFC 3588. 3. 3GPP TS 29.328. IP multimedia subsystem (IMS) Sh interface signaling flows and message contents. http://www.3gpp.org/ftp/Specs/html-info/29328.htm 4. 3GPP TS 29.329. Sh interface based on the DIAMETER protocol: Protocol details. http://www.3gpp.org/ftp/Specs/html-info/29329.htm 5. Fielding, R., J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach, and T. Berners-Lee. 1999. Hypertext transfer — HTTP/1.1, RFC 2616. http://www.ietf. org/rfc/rfc2616.txt 6. WAP Forum. 1998. Wireless application protocol architecture specification, WAP-100-WAPArch, WAP Forum specifications. http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html 7. Rosenberg, J. 2007. The extensible markup language (XML) configuration access protocol (XCAP), RFC 4825. http://www.ietf.org/rfc/rfc4825.txt 8. 3GPP TS 23.228. IP multimedia subsystem (IMS); stage 2. http://www.3gpp. org/ftp/Specs/html-info/23228.htm 9. Camarillo, G., and M. Garcia-Martin. 2004. The 3G IP multimedia subsystem (IMS): Merging the Internet and the cellular worlds. New York: John Wiley & Sons.

22 Role of OSS/BSS in the Success of IMS Jithesh Sathyan

contents Need of OSS/BSS for Success of IMS................................................................ 509 Basic Concepts...................................................................................................... 511 IMS . .............................................................................................................. 511 SDP . .............................................................................................................. 512 OSS/BSS......................................................................................................... 513 Converged SDP..................................................................................................... 515 OSS/BSS and NGOSS for IMS............................................................................ 517 NGOSS................................................................................................................... 519 Life Cycle and Methodologies.................................................................. 519 eTOM ........................................................................................................... 521 eTOM Overview.............................................................................. 521 eTOM Processes............................................................................... 522 The Verticals (Process Areas)........................................................ 522 The Horizontals (Functional Process Structures)...................... 524 Entities ............................................................................................ 524 SID ........................................................................................................... 524 TNA ........................................................................................................... 526 TAM ........................................................................................................... 528 Conclusion............................................................................................................. 530 Abbreviations....................................................................................................... 530

Need of OSS/BSS for Success of IMS The IP multimedia subsystem (IMS) is an open standard architecture that is the backbone for an all-IP network. It has been adopted by the ETSI (European Telecommunications Standards Institute), TISPAN (Telecoms and Internet Converged Services and Protocols for Advanced Networks), and packet cable multimedia. The IMS has resulted in an environment that offers new services to be introduced more quickly than ever before. The IMS is initially 509

510


triggered toward providing fixed mobile convergence and support for nextgeneration services. Another critical aspect to be considered for the success of IMS is the service management functionality that is necessary to turn the whole process to a billable service and to ensure that the IMS does not end up as just another silo. Without centralized operation support systems (OSSs) and business support systems (BSSs), service providers will not be able to manage the complex convergent services introduced by the IMS. Adoption of the IMS will be in phases and the migration will ensure support for legacy networks. What is required is a centralized service management interface that supports existing legacy services seamlessly and helps introduce new services from the IMS with ease. The centralized service management interface is intended to (1) support legacy services, (2) support new services introduced by IMS networks, (3) enable service to network abstraction for legacy and IMS domains, (4) provide a unified and federated set of user profiles with visibility of the range of services each customer can use and service attributes such as presence and location, and (5) enable orchestrating business and operational processes related to service creation, authentication, customer care, service upgrades, and other business/operational functions. The IMS introduces exciting new concepts, such as reusable service components and real time integration, but does not include specifications for service management and migration needed to introduce and materialize these concepts. To provide low cost for service creation and real-time service delivery to add or roll out services, the IMS needs to support a centralized service management framework. The IMS as a specification and concept describes the functioning of interaction between elements at the network level without details of how to operationalize these services or deliver them to the customer. The issues of service fulfillment in billing and ordering the services do not have a clear road map. This is a major gap for operators looking at implementing the IMS. To take advantage of IMS concepts for rapid service creation or to be able to utilize existing services and reuse them to roll out and build other services, standards for interaction between network elements are not enough. This can only be achieved by centralized OSS/BSS service management with network capabilities being plugged into the business. Although the IMS makes the network architecture simple and scalable, it adds significant complexity to service providers; with IMS, we have separate layers of network, service, and software to support them. This leads to a greater number of network and service elements within the IMS framework that need to be managed and populated with subscriber information. The result is additional complexity to the OSS/BSS infrastructure, including billing in a converged service environment. This chapter deals with the role of OSS/BSS in the success of the IMS. To detail this, we have covered the need for centralized service management in this introductory session. This is followed by a discussion of basic technologies that will be handled in this

Role of OSS/BSS in the Success of IMS

511

chapter. Then we discuss converged service delivery platforms (SDPs) and OSSs/BSSs for a converged SDP. The new-generation OSS (NGOSS; copyright TeleManagement Forum 2007) of the TM Forum is the best approach currently available that defines OSS/BSS principles for the IMS. The concepts of NGOSS are also discussed before we conclude the chapter.

Basic Concepts IMS The IMS defined by the 3rd Generation Partnership Project (3GPP) is a subsystem that enables the convergence of data, speech, and mobile network technology over an IP-based infrastructure. The IMS fills the gap between the existing traditional telecommunications technology and Internet technology, allowing operators to offer new, innovative, and compelling services. The IMS offers real-time multimedia mobile services such as rich voice services, video telephony, messaging, conferencing, and push services. The key features of IMS include: • a common platform for providing quick and easy service development; • decreased deployment and management costs; • converged services; and • consistent and open interfaces for third-party developers. The IMS represents a standardized, reusable platform that provides a better way to roll in/out, deploy, integrate, and expand consumer and enterprise voice and data services. Service deployment is effective and easy with a standardized ISC interface and Sh reference point, resulting in standardized interfaces for the integration of application servers into the IMS. There is an increased interest in the IMS due to its ability to revolutionize the end-user experience with new and innovative services. The mobile industry is transitioning from traditional voice and short message service to a variety of new and exciting multimedia services and applications. Voice and data messaging is complemented by next-generation applications such as push-to-talk sessions, real-time video sharing, multiplayer gaming, sharing of views and folders, voice messaging, and videoconferencing. The IMS also allows blending of services, such as sending a medium while talking or adding a multiplayer game during a push-to-talk session. It will also enable new services between mobile and fixed devices with TISPAN giving fixed mobile convergence. On the fixed side, many session initiation protocol (SIP) applications are already available, and developers are now working on SIP applications for the mobile environment.

512


Some of the benefits offered by the IMS include: • decreased time-to-market; • lower costs; • flexibility in choosing equipment from multiple vendors; • services that are easier to develop; • integrated and interoperable services; • rich media; • personalized services; and • mobile–fixed interworking. Before we conclude this section, we will briefly touch upon the standardizing bodies involved with the IMS. They are the 3GPP/3GPP2, which defines most of the infrastructure of the IMS; the Internet Engineering Task Force (IETF), which develops standards on SIP and base formats for presence information and list representation that will be exchanged between the core elements and the service enablers; and the Open Mobile Alliance (OMA), which defines applications that are built on top of the IMS infrastructure. SDP A service delivery platform is intended to enable rapid development and deployment of new converged multimedia services, from basic POTS (“plain old telephony system”) phone services to complex audio/video conferencing for multiplayer games. SDP provides (1) a tight integration of service to the operator’s business processes, (2) reuse of functionality, and (3) service lifecycle management. Elements of SDP include: • a service creation environment; • a service execution environment; • a service control environment; • a service orchestration environment; • a presence/location; • an integration; and • other low-level communications capabilities. The cost-saving success of IP-based systems as replacements for proprietary PBX systems and desktop phones has prompted a revolutionary shift in industry focus from proprietary systems to open standard technologies. This has led to the development of SDPs by new players in the telecom industry. Wikipedia offers some example applications that an SDP will offer:


513

• Users can see incoming phone calls (wireline or wireless), IM buddies (PC), or the locations of friends (GPS-enabled device) on their television screens. • Users can order VoD (video on demand) services from their mobile phones or watch streaming video that they have ordered as a video package for both home and mobile phones. • An airline customer can receive a text message from an automated system regarding a flight cancellation and then opt to use a voice self-service interface to reschedule. Features of the SDP include: • standards-based development environment; • automated partner management achieved with well-defined security and policy management mechanisms, thus enabling efficient management of partners and serving as a platform where services can be registered, provisioned, and managed; • reliable revenue-sharing model for content providers; • defined service interaction methodology because SDP defines service implementation and interaction and how they tie into operations and business support systems, which reduces operational complexity and expense while increasing operational agility; and • support of multiple underlying network architectures by allowing services to be developed once and then deployed over multiple underlying network architectures, which reduces development costs and improves revenues through more effective service scalability. Benefits of having a service delivery platform include: • shortened time to market for faster return on investment; • reduced costs; • lowered risk; and • better total customer experience. OSS/BSS Operations support systems include all systems used to support the daily operations of a telecommunication service provider. Support systems reduce operating expenses while increasing system performance, productivity, and availability. OSS is composed of three components: namely, the BSS, service OSS, and NMS (network management system). The service OSS is also referred to as OSS, thus making the usual terminology of reference for support systems above NMS as OSS/BSS.

514


BSS handles business operations and is customer centric, conducted by an operations team that reports to operations officers. OSS handles service-oriented OSSs like assurance and manages services reporting mostly to the IT department. NMS handles management of network resources, which is done by network engineers. High-level classifications of the OSS/BSS functionalities include: OSSs/BSSs enable operators to manage their customers—managing customer accounts, sales processes, billing processes, customer experiences, etc. OSSs/BSSs enable operators to manage their service offerings—defining the service level agreement (SLA), managing the order process, determining the quality of service, etc. OSSs/BSSs enable operators to manage their networks—installation, configuration, inventory and assignment, maintenance, etc. OSS becomes more critical to manage diversified services, support multiple network technologies, and meet customers’ expectations. OSSs remain a complex interconnection of a system, with the complexity driven by the customer management, resource management, and service management requirements. OSSs deal with a range of issues critical to an operator’s success. Some of these are discussed next to provide insight into the effectiveness of OSS/BSS for proper working of the telecom enterprise: • Order management systems allow operators to coordinate activities, including the process of configuring the network to complete an order from the customer. • Provisioning systems allow operators to activate services on the network/service infrastructure. • Inventory systems allow operators to track their network assets and assign those assets to customers. • Mediation systems allow operators to determine service usage. • Rating systems implement various billing models for service usage by the customer. • Network management systems allow operators to detect and isolate network failures and to restore service quickly. • Service assurance systems allow operators to correlate network performance with service quality requirements. • EAI systems allow operators to integrate diverse support systems and network elements.

515

Role of OSS/BSS in the Success of IMS New Services SDP 800

PPS VPN

IP TV

Legacy

PoC

IP CX

IMS

Figure 22.1 Current SDP.

Investment in OSSs is driven by • new revenue opportunities from emerging services; • new network technology; • credit models (prepay, postpay), bundles, regulations; • competitive advantage in time-to-market; • cost savings; • scalable architectures; • requirements for online customer care applications; and • employee productivity/flow-through.

Converged SDP The issues with current service delivery (Figure 22.1) include: • The current service delivery model results in high CAPEX and OPEX. • Services are network and vendor dependent, with no portability, and reuse between the operator’s networks. • A different service platform is used for each service. • Operators are not able to address the needs of niche markets. Migration to the IMS is going to be a staged approach and, for almost all operators, there will be a period during which old and new network architectures must coexist harmoniously. Converged SDP (Figure 22.2) is required to achieve seamless interoperability, creating an infrastructure for IMS deployment.

516

IP Multimedia Subsystem (IMS) Handbook Migrated Legacy Services

IMS Services

Converged SDP

Legacy

IMS

Figure 22.2 Converged SDP.

that can span multiple networks at the same time. The value of the IMS lies in its standardization of service capabilities as well as the standardization of network element features enabling the delivery of services. The IMS on its own does not deliver a framework for enabling and implementing the services. The IMS is designed to support the orchestration of interactions based on SIP with a framework for delivering and maintaining fixed–mobile service sessions. Converged SDP is a strategy that can bring out the full potential of the IMS with its integrating capabilities and ability of interoperability across multiple networks. Adopting converged SDP will enable operators to enjoy a fast-paced service environment and ensure seamless network convergence. SDP orchestrates IMS and legacy networks providing an “open,” horizontal, and integrating architecture. Converged SDP has the following features: • It standardizes the interfaces linking applications to network elements and the managing OSS/BSS infrastructure. • It creates a common set of reusable development tools. • It eases content developers’ activity of creation and deployment of value-added services. • It functions as the service’s integration layer across fixed and mobile networks. • It leverages the IMS and other network capabilities to build and deploy enhanced services. IMS architecture can best be understood as a set of layers. The core components of the IMS for call handling and subscriber information storage, such as call session control function (CSCF) and home subscriber server (HSS), reside in the control layer. Various access networks such as the radio access network (RAN) and PSTN/PLMN. in the access layer interact with the control layer. The application layer has application servers where the services reside. The service delivery platform also falls in the application layer.


517

Services Application Layer Service Delivery Platform Control Layer (IMS) Access Layer (WLAN, PSTN, RAN) Customer Equipment Figure 22.3 SDP layered with IMS.

(Figure 22.3). Web-based services and implementation of SOA-based SDP are also becoming popular in the current telecom industry. The advantages of converged SDP include: • decreased CAPEX and OPEX because operators can reuse the same service delivery infrastructure for the IMS and the existing networks; • ability to address the needs of the niche markets; • operators able to leverage their IMS investments fully and provide more value to their customers; • service continuity and seamless service migration; and • service innovation by enabling open business models.

OSS/BSS and NGOSS for IMS Certain requirements for OSS/BSS are needed to ensure the success of the IMS: • A layered approach to ensure focus on various aspects of the telecom domain similar to the layered architecture of the IMS–NGOSS eTOM (copyright TeleManagement Forum 2007) model is based on separation of the telecom environment into a set of process domains and functional areas to ensure sufficient depth of focus. The application map and shared information/data of NGOSS also derive the domains identified by eTOM. • Management of multiple services is necessary. Multiple services will interoperate in a converged environment. They need to be managed using OSS/BSS solutions that are not for a specific service alone.

518

IP Multimedia Subsystem (IMS) Handbook NGOSS builds the methodologies and models to support a converged service environment.

• A self-service portal and CRM (customer relationship management) are required. Next-generation OSS will need customer self-care strategies and integrated customer-centric management. Customer experience will be a key differentiating factor between service providers and will determine profitability. The TM Forum has a team dedicated to integrated customer-centric management (ICcM) • Also necessary are improved order handling to manage multichannel customer service, high volume of customer orders, order decomposition and enrichment from commercial to technical details, order feasibility checks, etc. The TM Forum telecom application map (TAM) (copyright TeleManagement Forum 2007) works on application modeling. It develops application decomposition similar to process decomposition of eTOM. A level-3 model of TAM on subprocess order handling is expected to address these issues. • Fast creation and deployment of services would include service activation on demand and rapid personalization of service. NGOSS is working on service life cycle management with SOA, which would make service introduction and management easy, resulting in rapid roll in/out of services as guaranteed by the IMS. • It is necessary to meet the E2E SLA and QoS guarantee. The next-generation OSS/BSS solution should be able to monitor quality of service (QoS) and quality of experience (QoE) and ensure that customer service-level agreements are met. In cases where the SLA is violated, the customer should be credited as compensation. • A shared information data model must exist. Contract data, product data, inventory data, and customer data need to be in a common format to support multivendor environments. NGOSS shared information and data (SID) (copyright TeleManagement Forum 2007) provides UML diagrams that help to build shared information and data paradigms required for the telecom industry. • Flexibility and scalability are necessary. The OSS/BSS solution is intended to span multiple domains and networks. For example, an order management application must support multiple services working on heterogeneous networks. NGOSS has defined standards for MTNM (multitechnology network management) and MTOSI (multitechnology operations system interface). • Open interfaces are required for ease in integration and better interoperability. Multiple vendors develop OSS solutions, and a service provider may want to have a security application from one vendor interoperate with an inventory application from another vendor. The integration of these OSS applications would be seamless if the interactions are based on open interfaces. The NGOSS OSS/J initia-

519


Control Layer (IMS) Access Layer (WLAN, PSTN, RAN)

OSS/BSS

Application Layer (Services)

Customer Equipment Figure 22.4 OSS/BSS for IMS.

tive (OSS through Java) provides industry-standard interface specifications (APIs) used to connect different OSS information systems together by using Java technologies (Figure 22.4).

NGOSS According to the TM Forum, its “new generation operations systems and software” initiative is a “comprehensive, integrated framework for developing, procuring and deploying operational and business support systems and software.” NGOSS currently provides the most comprehensive set of artifacts for satisfying the requirements of OSS/BSS for the success of IMS. Life Cycle and Methodologies The NGOSS telecom life cycle is divided into four segments (Figure 22.5). Vertical demarcation is achieved by considering a separate stage for service provider and service developer. Horizontal demarcation is achieved with a technology-neutral layer and technology-specific layer. This leads to four different views: (1) business view: service provider in technology-neutral layer; (2) system view: service developer in technology-neutral layer; (3) implementation view: service developer in technology-specific layer; and (4) deployment view: service provider in technology-specific layer. This telecom life cycle is in alignment with normal software life cycles. The business requirement comes in the business view. Based on the requirements, the architecture of the system is developed. This forms the system view. A technology is then selected to implement the architecture, and the implementation is performed in the implementation view. Integration of

520


NGOSS Life Cycle

Logical View

Business Capabilities, Constraints & Context

Physical View

System

Business

Deployment Deployment Capabilities, Constraints & Context Service Providers View

Knowledge Base Corporate Knowledge Shared Base

NGOSS Knowledge Base

System Capabilities, Constraints & Context

Implementation Implementation Capabilities, Constraints & Context Service Developers View

Figure 22.5 NGOSS life cycle.

implemented components and deployment take place in the deployment view. Thus, the artifacts in one stage are of much value in the next stage. A “view”-based approach helps to focus on specific issues and helps in having a staged approach in development. This life cycle is further used to derive a network management life cycle, to test a life cycle, and for other aspects of telecom that need a staged approach. NGOSS also defines a road map that can be used by current systems to align with the reference models defined by NGOSS. This is based on the SANRR methodology (Figure 22.6):

1. Scope involves identifying the area that needs to be aligned with NGOSS.

2. The identified area is analyzed using use cases and maps to have the current system clearly represented.

3. Normalizing changes the current view to the NGOSS vocabulary.

4. Rationalizing starts with examining the current view for changes needed (gap analysis, replication analysis, conflict analysis, etc.) and terminates when no more changes can be made on the current map.


521

Scope Analyze Normalize Rationalize Rectify Figure 22.6 SANRR methodology.

5. Rectifying is done by modifying, deleting, or adding functionality to align it with NGOSS.

Thus, the first step is to identify the area to align and then to analyze the area and change it to terms used in NGOSS for a clear understanding of how the process area being investigated deviates from the model specified by NGOSS. The current area should be rationalized and rectified. This leads to a new modified map of the area under investigation. The new map is again put to normalization and steps 3–5 are repeated until the identified area is best aligned with NGOSS. The other key principles of NGOSS are eTOM—business process map; SID—shared information and data model; TNA—technology-neutral architecture (copyright TeleManagement Forum 2007); and TAM—telecom application map. Other artifacts of the TM Forum are based on these key concepts. eTOM eTOM Overview eTOM is a business process model or framework that provides the enterprise processes required for the service provider (Figure 22.7). It is based on the telecom operations map (TOM). To service providers, eTOM serves as an industry standard framework for procuring software and equipment as well as to interface with other service providers in an increasingly complex network of business relationships. Features of eTOM include: • It provides the highest conceptual view of the business process framework. • It differentiates strategy and life cycle processes from operations processes. • It differentiates the key functional areas in five horizontal layers.

522

IP Multimedia Subsystem (IMS) Handbook Customer

Strategy, Infrastructure & Product

Operations

Market, Product and Customer Service Resource (Application, Computing and Network) Supplier/Partner Suppliers/Partners Enterprise Management Shareholders

Employees

Other Stakeholders

eTOM Business Process Framework - Level 0 Processes Figure 22.7 eTOM level-0 processes.

• It can be viewed as having three major areas of process. eTOM Processes The three major areas of the eTOM process are strategy infrastructure and product management, operations, and enterprise management. Strategy infrastructure and product management covers planning and life cycle management of the product (Figure 22.8). Operation covers the core of operational management. Enterprise management covers corporate or business support management. The four supporting functional process areas are marketing, product, and customer processes; service-related processes; resource-related processes; and supplier/partner processes. The Verticals (Process Areas) The core of operations is fulfillment, assurance, and billing (FAB). This forms activities that are performed at real time. Operations support and readiness is also part of “operations,” but it is separated from FAB. These are the activities to support proper functioning of real-time activities. Strategy, infrastructure, and product (SIP) encompass strategy and life cycle management processes in support of operations for a product. Production development will involve

523


Customer Strategy, Infrastructure & Product Strategy & Commit

Operations

Infrastructure Product Lifecycle Lifecycle Management Management

Operations Support & Readiness

Fulfillment

Assurance

Marketing & Office Management

Customer Relationship Management

Service Development & Management

Service Management & Operations

Resource Development & Management (Application, Computing and Network)

Resource Management & Operations (Application, Computing and Network)

Supply Chain Development & Management

Supplier/Partner Relationship Management

Billing

Enterprise Management Strategic & Enterprise Planning

Enterprise Risk Management

Financial & Asset Management

Enterprise Effectiveness Management

Stakeholder & External Relations Management

Knowledge & Research Management

Human Resources Management

eTOM Business Process Framework - Level 1 Processes Figure 22.8 eTOM level-1 processes.

processes on planning the product phase. This would also involve processes that take care of infrastructure required for the product as well as processes that directly relate to the product under consideration. This leads to strategy, infrastructure life cycle management, and product life cycle management. Any telecom company would have a set of processes common to an IT company. To represent this and to keep the definition of telecom separate, the enterprise management grouping was introduced. This grouping involves the knowledge of enterprise-level actions and needs and encompasses all business management processes necessary to support the rest of the enterprise. Enterprise management processes include processes for financial management, legal management, regulatory management, etc. This area also sets corporate strategies and directions and provides guidelines and targets for the rest of the business. These are sometimes considered as the “corporate” functions or processes. Enterprise management also includes strategic planning for the enterprise as well as information systems strategy development and management.

524


The Horizontals (Functional Process Structures) The process grouping of market, product, and customer processes deals with sales and channel management, marketing management, and product and offer management as well as operational processes such as managing the customer interface, ordering, problem handling, SLA management, and billing. The process grouping of service processes deals with service development and delivery of service capability, service configuration, service problem management, quality analysis, and rating. The process grouping of resource processes deals with development and delivery of a resource and its operational management such as provisioning, trouble management, and performance management. The process grouping of supplier/partner processes deals with the enterprise’s interaction with its suppliers and partners. It involves processes that develop and manage the supply chain as well as those that support the operational interface with its suppliers and partners. Entities The entities with which the processes interact are also represented in the TOM model: • customers to whom products are sold by the enterprise; • suppliers who provide resources or other capabilities bought and used by the enterprise directly or indirectly to support its business; • partners with whom the enterprise cooperates in a shared area of business; • employees who work for the enterprise to pursue its business goals; • shareholders who have invested in the enterprise and thus own stock; and • stakeholders who have a commitment to the enterprise other than through stock ownership. SID The NGOSS SID model provides a common vocabulary and set of information/data definitions and relationships for telecom OSS. The SID is an object model that uses UML to define entities and the relationships between them,as well as the attributes and processes that make up the entity or object. It is an information/data reference model from a business as well as a systems perspective. The SID provides business-oriented UML class models as well as design-oriented UML class models and sequence diagrams to provide a common view of the information and data. SID is used in combination with the eTOM business process and acts a bridge in mapping information/data for business concepts and their characteristics and relationships, described in an implementation-independent manner. The benefit of using the NGOSS

525

Role of OSS/BSS in the Success of IMS Market/Sales Market Strategy & Plan

Marketing Campaign

Contact/Lead/Prospect

Market Segment

Competitor

Sales Statistic

Product

Sales Channel

Product

Strategic Product Portfolio Plan

Product Performance

Product Specification

Product Offering

Product Usage Statistic

Customer

Customer Order

Customer Problem

Applied Customer Billing Rate

Customer Bill Collection

Customer Interaction

Customer Statistic

Customer SLA

Customer Bill

Customer Bill Inquiry

Service

Service Applications

Service Performance

Service Strategy & Plan

Service Specification

Service Configuration

Service Usage

Service Trouble

Resource

Resource Topology

Resource Performance

Resource Strategy & Plan

Resource Specification

Resource Configuration

Resource Usage

Resource Trouble

Supplier/Partner

S/P Interaction

S/P Order

S/P Plan

S/P Product

S/P SLA

Customer

Service

Resource

Supplier/Partner

Enterprise

Service Test

Resource Test

S/P Performance

S/P Bill

S/P Problem

S/P Inquiry

S/P Statistic

S/P Payment

Common Business (Under Construction)

Party

Business Interaction

Location

Policy

Agreement

SID Domains and Level-1 ABEs

Figure 22.9 SID domains and level-1 ABEs.

SID and its common information language is that it enables business benefits relating to cost, quality, timeliness, and adaptability of enterprise operations— thus allowing an enterprise to focus on value creation for its customers. SID creates use cases and contracts that are used to convey meaning to at least four main sets of constituents, as represented by the business, system, implementation, and deployment views of NGOSS. Building out the SID to support all four views fully is the vision for NGOSS. SID provides a knowledge base that is used to describe the behavior and structure of business entities as well as their collaborations and interactions. The SID level-1 framework is split into a set of domains based on eTOM (Figure 22.9). The business view domains include: • market/sales; • product; • customer; • service; • resource; • supplier/partner;

526

IP Multimedia Subsystem (IMS) Handbook NGOSS Framework Services Common Communications Vehicle Other Mandatory NGOSS Services

Business Services

Figure 22.10 High-level view of TNA.

• enterprise; and • common business. Within each domain, there is a high degree of cohesion between the identified business entities and loose coupling between different domains. This enables segmentation of the business problems and allows resources to be focused on a particular domain. Within each domain, partitioning of information is achieved using aggregate business entities. SID has both a business view and a system view. The SID system view is intended primarily for architects, designers, and implementers. As has been explained, the NGOSS business view makes use of the eTOM and the SID to focus on the concerns of the business goals, processes, entities, and interactions. SID adds detail to the artifacts identified in the business view as well as defines new artifacts to support the needs of this view. This, in turn, enables the business processes to be further refined; the contractual interfaces that represent the various business process boundaries can be identified and modeled. Collectively, these are used to define the inputs needed for the implementation view. TNA TNA is composed of three types of interoperating capabilities: • framework services supporting distribution and transparency; • mandatory services supporting decision, sequencing, and security; and • general business services being provided by the NGOSS solution. Underlying this high-level view (Figure 22.10) are a number of artifacts that make up technology-neutral architecture. TNA artifacts are classified as (1) core artifacts—basic units of composition in the architecture, and (2) container artifacts—those that encapsulate or package core artifacts. The essential concepts that collectively form the TNA as detailed in TMF053 include:


527

An NGOSS contract defines interoperability of the NGOSS architecture. An NGOSS contract provides a specification of NGOSS contract operations and behavior. It exposes functionality contained in an NGOSS component. NGOSS contract implementation is a technology-specific realization of the NGOSS contract. The implementation is based on requirements and specifications provided by the NGOSS business and system view. An NGOSS contract instance is a runtime manifestation of a contract implementation that provides one or more functions to other runtime entities. It represents the unit of binding. A contract instance must be manageable. An interface represents functionality provided by managed software elements that reside in a component. An operation is an interaction through a contract invocation. Operation happens between a client component and a server component that is either an interrogation or an announcement. An announcement is an invocation initiated by a client component instance that results in the conveyance of information from that client component instance to a server component instance, requesting a function to be performed by that server component instance. An interrogation is similar to an operation, except that it consists of two interactions, one initiated by a client component instance and the second initiated by the server component instance. An interface signature comprises a set of announcement and interrogation signatures, as appropriate—one for each operation type in the interface. An announcement signature is a definition of the name of the invocation and the number, names, and types of its parameters. An NGOSS component is defined as a software entity that is independently deployable, is built conforming to a component software model, and uses contracts to expose its functionality. An NGOSS application is a container artifact that provides an encapsulation of the requirements, specifications, and implementations of desired functionality from the perspective of service providers that is needed to support a specific business goal within their operating environments. An NGOSS service is created, deployed, managed, and torn down by one or more NGOSS contract operations. An NGOSS service can be either a customer facing service or a resource facing service. For further details on TNA, see TMF053 documents on technology-neutral architecture.

528 Campaign Management

Channel Sales Management

Product/Service Catalogue

Product Life Cycle Management

Market/Sales

Product

Customer Contact Management, Retention & Loyalty

Customer Management

Service Design/ Assign

Service Management

Resource Management

Customer Self Management

Resource Inventory Management

Resource Logistics

Service Configuration Management

Workforce Management

Resource Planning/ Optimization

Supplier/Partner

Enterprise Management

Service Performance Management

Resource Design/ Assign

Partner Management

Customer Service Account Problem Resolution

Service Quality Monitoring & Impact Analysis

Service Problem Management

Correlation & Root Cause Analysis

Resource Provisioning/ Configuration

Resource Status Monitoring

Resource Activation

HR Management

Customer QOS/SLA Management

Order Management

Resource Testing Management

Financial Management

Asset Management

Security Management

Customer Billing Management

Invoicing and Receivables Management

Revenue Service Rating Assurance /Discounting Management Management

Resource Performance Monitoring/ Management

Resource Data Mediation

Supply Chain Management

Fraud Management

Billing Data Mediation

Wholesale/ Interconnect Billing

Resource Problem Management

Arbitrage Management

Real-time Billing Management

Integration Infrastructure: Bus Technology/Middleware/Business Process Management


Knowledge Management

Figure 22.11 TAM.

TAM The telecom applications map (Figure 22.11) is intended as a frame of reference in order to evolve the set of applications that enable and automate operational processes within a telecom operator. According to the TM Forum document “TMFC5303 GB929 Telecom Applications Map,” there are benefits to using a common TAM: • It provides a common language for information exchange within the OSS industry, in particular between operators and system suppliers. • Investment risks and costs may be reduced by building or procuring systems technology that aligns with the rest of the industry using a well-defined, long-term architecture • The procurement process is made easier by using a common map component standardization in order to drive license prices down. There is a larger market for suppliers based on operators procuring from a standard applications model.


529

• Higher volumes of similar applications will allow volume economies of scale to suppliers. • Reuse of components reduces development costs. • Standard interfaces reduce development costs. • Applications become building blocks that can be added and replaced. • Use cases with partners and suppliers become easier to define. • Workflows become repeatable and easy to modify. • More standard applications may reduce operating costs and drive increased efficiency in operations. • Increased automation lowers OPEX. • Risk for errors is minimized. • Organizational and other changes become easier to adapt. • Defined frameworks are independent of organizational structures. • Acquisitions/mergers are easier to manage if common architectures are deployed. • A common TAM provides well-defined business–business interfaces between retail and wholesale service providers and network operators. The different layers under which applications are identified and grouped in the TAM are derived from the eTOM model. These layers include the: • market/sales process; • product process; • customer relationship management processes; • service management process; • resource management and operations processes; • supplier partner process; • enterprise management process; and • integration infrastructure process. The first release of the TAM only defines the layers and basic set of applications, with some level of detail on the resource management layer. Work on delivering a detailed analysis of the remaining layers is ongoing. With service-oriented architecture and integrated applications, the next level of applications detailed in the TAM is expected to span across layers. The TAM adds the required granularity of application level details required for NGOSS concepts in addition to the business process, information model, and technology-neutral architecture. Mapping of the TAM with the eTOM and SID is expected to be a future activity of the TM Forum. NGOSS thus gives a complete solution set for telecom OSS/BSS and enterprise management.

530


Conclusion For a smooth migration to the IMS and to ensure that the IMS does not end up as yet another silo, it is vital to have an OSS/BSS infrastructure that is ready to support the features of rapid service delivery offered by the IMS. This would require a rigid OSS/BSS system built over a converged service delivery platform. NGOSS provides the required comprehensive, integrated framework for achieving this goal. This chapter is intended to throw light on the need for OSS/BSS for the success of the IMS and to give basic understanding of current industry approaches in providing the infrastructure for introduction of the IMS.

Abbreviations 3GPP: 3rd Generation Partnership Project BSS business support system CAPEX capital expenditure eTOM enhanced telecom operations map ETSI European Telecommunications Standards Institute IMS IP multimedia subsystem NMS network management system OPEX operational expenditure OSS operation support system QoE quality of experience QoS quality of service SID shared information and data TAM telecom application map TISPAN Telecoms and Internet Converged Services and Protocols for. Advanced Networks TNA technology-neutral architecture

Index

A AAA provision, 204–205 Abstraction, network, 316–318 Access control layer, multimedia services, . 287–288 OSA, 172 Access service requests, 293–294 Account management Parlay X API services, 179–180 SCF, 175 Address list management, 181 Alcatel-Lucent, 103–104 Analyzed_Information TDP, 221 API (application programming interface), 108, 142 network abstraction, 316–318 Parlay X, 170, 176–182 Application enabler, IMS, 314–315 Architecture, IMS, 29–32, 73–74, 384–385, 462–463, 511–512 CAMEL, 217, 218 distributed, 256–259, 260 internetworking, 197 multimedia services and, 274–283 multiparty services and, 364–366 service delivery platform reference, 283–298 SOA-based, 308–311 3GPP network, 193–194, 311–313 Arming/disarming mechanisms, 219–220 Artifacts, TNA, 526–527 AS (application server), 7–9, 31, 105–106 IMS, 496–498 JAIN SLEE platforms for, 494–507 prepaid, 473–492 ASN (access service network), 195, 196 ASP (application service provider), 280–281 Associations, security, 35–39

ATIS (Alliance for Telecommunications Industry Solutions) IIF, 427–428, 456 Attacks, IMS security, 32–34 Audio call, Parlay X, 180 calls, SIP-controlled, 149–151 digital broadcasting, 299 Authentication algorithms, 53 entity, 35 key management and, 39–44, 45 OSA, 171 proxy usage for multimedia services, 64–67 user, 41–44, 45 Authorization, OSA, 172 Axiomatic design, 446–447

B Balance check requests, 294 B2BUA architecture, 482–483 JAIN SLEE platform, 499, 503–505 BCSM, CAMEL, 218–220 O-IM-BCSM model, 220–221, . 222–223 T-IM-BCSM model, 223, 224, 224–225 BFCP (binary floor control protocol), 385–389 BGCF (border gateway control function), 32 Bootstrapping, 59–64, 315–316 Boxes, multifunction, 101–106 BPML (business process modeling language), 321 Bridge cross-certification, 55 Broadcast, message, 182, 299–300 Brokerage, service, 320–321 BSF (bootstrapping server function), 60–61 531

532

Index

BSO (Base Virtual Organization), 137–138 Business model for third-party multimedia service provider, 273–274 BWA (broadband wireless access), 195, 196

C Call handling service, 181, 225 Call party, interaction with, 238, 239–242 CAMEL (customized applications for mobile network enhanced logic), 171, 215–216, 497 arming/disarming mechanisms, 219–220 BCSM, 218–220 control behavior of UE-originated sessions, 229–231, 232–235 of UE terminating session in IMSSF, 235, 236–237 GSM circuit switching network and, 216–217 interaction with call party, 238, 239–242, 240 O-IM-BCSM model, 220–221, 222–223 operation, 227–229 requests for event notification, 227–229, 233 route, 227 for service control, 227 send announcement, 237, 239 service architecture for IMS user, 217, 218 Si interface, 229, 233, 234 subscribe data, 223–226, 234, 235 T-IM-BCSM model, 223, 224, 224–225 CANCEL attack, 34 CANs (content addressable networks), 76 Cantata technology, 102–103 CAPEX, 515, 517 Catalogue menus, 292 CCP (conference control protocol), 385–389 CDF (Charging Data Function), 154–155 Centralized conferencing, 386–388

Certificate profiles, 58 validation, 58–59 Certification authority (CA), 54–55 CGF (Charging Gateway Function), 151–152 Charge user requests, 294 Charging back-end ABMF and RF and, 505 of emergency calls, 505–506 offline, 475–476 online, 476–479, 502–503 SCF, 175 with unit reservation, 477–479 for use of supplementary services, 489–491 Chord, 75–76 Cisco, 104–105 Client side, DCON, 395–397 Client-triggered reservation, 203 Collected_Info TDP, 221 Composition, service, 336–342 Conferencing services, 89, 101, 181 centralized, 386–388 CONFIANCE and, 385–386 DCON framework, 389–392 implementation, 392–397 scalability analysis, 397–406 IMS-compliant distributed framework for, 386–389 XCON, 384–386, 389–390, 399–407 CONFIANCE, 385–386. See also DCON (distributed conferencing) Confidentiality data, 35 SIP, 43–44, 45 user, 35 Conflict management, service, 330–336 Control behavior, IM-SSF of UE-originated session in, 229–231, 232–235 of UE terminating session, 235, 236–237 Converged SDP, 515–517 COPS (common open policy service), 161, 194, 201–202 Core function layer, multimedia services, 288–289 CPU utilization level, DCON, 400

533

Index CR (cognitive radio), 206, 211–212 Cryptography, public key, 53–55 CSCF (call state control function), 29, 193 B2BUA, 504–505 converged SDP and, 516 interrogating, 122 network operator infrastructure and grid services, 151–155 Open IMS Core project, 117–119 prepaid application server, 480–481 CSN (connectivity service network), 195, 196 Customer context in multimedia service design, 269–270

D DAB (digital audio broadcasting), 299 Data confidentiality, 35 DHT overlay network, 245–247 integrity, 35 replication in HSS DHT, 250 session control SCF, 174 DCA (domain certificate authority), 55–59 DCON (distributed conferencing) client side, 395–397 comparative analysis, considerations, and comments, 406 framework, 389–392 implementation, 392–397 scalability analysis, 397–406 server side, 394–395 Design, multimedia service, 268–274, 290–291, 298–302 DHT comparison, 260–261 distributed HSS (HSS DHT), . 247–252 distributed IMS architecture, 256–259, 260 distributed I/S-CSCF (I/S-CSCF DHT), 252–255, 256 overlay structure, 245–247 DIAMETER proxy, 29–31, 61, 194, 313 DHT and, 260–261 grid services support, 153–154 HSS and, 244, 250, 251, 255, 256 Open IMS Core, 120–122

quality of service issues, 164 DiffServe core network, 160–167 Disconnection and reconnection of terminal, 147–149 Discovery, OSA, 172 Dispatch content requests, 294 Distributed conferencing. See DCON (distributed conferencing) Distributed HSS (HSS DHT), 247–252, 255, 256 Distributed IMS architecture, 256–259, 260 Distributed I/S-CSCF (I/S-CSCF DHT), 252–255 DMB (digital multimedia broadcasting), 299 DoS (denial-of-service) attack, 32 DP (detection point), 218–220 DVB (digital video broadcasting), 429–430 -H (digital video broadcast for handheld), 299 over IP networks, 455

E Eavesdropping, 33 EDCF (enhanced distributed coordination function), 195 Enablers identity, 315–316, 325–326 IMS, 313–316 OMA, 9–12, 319 Telco Web 2.0, 324–325 Encryption and secrecy, 41–44, 45, 53 Enterprise management, 522, 523 Entity authentication, 35 Ericsson, 104 ETOM (telecom operations map), 521–524 ETSI TISPAN, 420–426, 456, 509 Event notification requests, CAMEL, 227–229, 233 Excel MSP 1010, 102–103

F FastTrack, 77 FIM (feature interaction manager), 334 FMC (fixed-mobile convergence), 28

534

Index

FMEA (failure mode and effect analysis), 452–454 Focus group on IPTV, 415–418, 419, . 420 Foundations of IMS services, 4–12 Fraud control, 35–36 Funds ok response, 294

G Gateway, media, 89, 93–94, 103–104, 103–105. See also Parlay X API transport function layer, 286–287 GBA (generic bootstrapping architecture), 59–64, 315–316 Geocoding, 182 GMSC (gateway MSC), 216 GPRS (general packet radio service), 28, 152–153 Grid services advantages of, 135–136 architecture, 136–141 Base Virtual Organization (BVO), 137–138 interfaces to HSS and CDF for user control, 154–155 mobile terminal (MT), 143–149 network operator infrastructure integration, 151–155 network provider, 140–141 Operational Virtual Organization (OpVO), 138–140 real-time transport protocol in, 151 service provider, 136–137, 140 SIP infrastructure integration integrating SIP and SOAP in, 142–144 integrating SIP-controlled audio/ video calls in, 149–151 SIP and SOAP protocol in, 141–142 SIP support for SOAP-based grid services in, 144–149 terminal mobility, 147–149 GSM (global system for mobile communications), 4–5, . 215–216 circuit switching network and CAMEL service, 216–217 HSS as evolution of home location register (HLR), 243–245

H H.248, 94–96 Home gateway initiative, 426–427 HSS (home subscriber server), 7, 29, 31, 61 arming/disarming mechanisms, 219–220 CAMEL subscribe data, 223–226 converged SDP and, 516 distributed, 247–252, 255, 256 as evolution of GSM home location register, 243–245 grid services integration, 151, 154–155 Open IMS Core project, 117–118, 124–125 scaling, 244 HTTP-based services, 286, 287 multimedia service interaction, 292–294, 295–296 physical operational model, 298 security management for, 59–67

I I-CSCF (interrogating call state control function), 31 Identification, IPTV, 448–450 Identity enabler, IMS, 315–316, . 325–326 IETF (Internet Engineering Task Force), 7, 73–74, 201, 313, 384, 456 IFC (initial filtering criteria), 7–8, 123 B2BUA configuration, 506 IKE protocol, 52–53 IM-CSI information, 229 IMG 1010, 102 IM (instant message), 346–348 Impersonation, 32 IMPI (private user identity), 245–249 IMPS (instant messaging and presence service), 345–346 bandwidth consumption, 360–361 instant messaging SIP protocol, 346–348 presence service SIP protocol, 348–355, 356 3GPP IMS presence service, 356–360 IMS (IP multimedia subsystem)

Index architecture, 29–32, 73–74, 384–385, 462–463, 511–512 authentication, key management, and secrecy, 39–44, 45 CAMEL service architecture for, 217, 218 conferencing services, 383–408 DiffServe core network and, 163–167 distributed, 243–261 enabler, 313–316 end-user system, 32 foundations of, 4–12 grid interaction, 134–136 architecture, 136–141 network operator infrastructure and, 151–155 SIP infrastructure and, 141–151 IPTV, 411–439, 465–468 JAIN SLEE platforms for, 494–507 link between services seen by the user, 13–14 media functions within, 90–109 multiparty services in, 363–381 network standards, 275–276 Open IMS Core Project, 114–130 OSS/BSS and, 509–530 peer-to-peer technology, 75–80 push-to-talk over cellular (PoC) services, 17–22 relationship between service and technical function in, 16–17 security, 28–29 challenges and potential attacks, 32–34 encryption, 41–44, 45 interdomain, 45–59 mechanisms and security associations, 35–39 service capabilities and OMA enablers, 9–12 composition management, 336–342 conflict management in, 330–336 model, 12–17 SOA-based SDP on top of, 308–311 technical functions, 14–17 3GPP network architecture, 193–194, 311–313, 356–360 transition from NGN to, 7–9

535 user service environment and, 22, 23 INAP (intelligent network application part) protocol, 4–5 IN (intelligent networks), 4–6 Integration service layer, multimedia services, 289–290 Integrity, data, 35, 43–44 Interdomain security, 45–47 network domain security (NDS) architecture, 47–49 Internetworking AAA provision, 204–205 architecture and levels, 197–200 core architecture based on IMS, 197 extensions of SIP related to, 200–206 IMS architecture for 3GPP networks, 193–194 levels, 198–200 message exchange, 209–210 modes, 197 QoS guarantee, 200–203 reconfigurable cognitive wireless network, 206–212 related problems and solutions, 209–212 resource management, 210–211 security, 205–206, 211–212 session negotiation level view, 192 Wimax technology, 195, 196 WLAN technology, 194–195 IPFIX module, 160–163, 167 IPsec, 50–52 IPTV architecture, 432–433, 434–435, 461 ATIS IIF, 427–428 axiomatic design, 446 core IP multimedia subsystem, 462–463 dedicated subsystem for, 424–426 digital video broadcasting, 429–430 failure mode and effect analysis, 452–454 functions supported by IMS subsystem, 421–424 future evolution of, 468–469 home gateway initiative, 426–427 identification and characterization, 448 of user’s expectations, 448–450 independence axiom, 446–447

536

Index

interactive and personalized service scenarios, 435–436 introduction of, 412, 444–445 media functions, 464–465 migration scenarios and extensions toward, 458–465 NGN and, 412–413, 433–435, 456–457 non-IMS-based NGN, 460–461 non-NGN, 456–460 open forum, 430 principles for next-generation network service platforms, 445–455 protocol model, 465–468 quality matrix for, 450–452 real-world testbed for, 431–439 related work and standardization activities, 413–414 service access and consumption, 454 control functions, 464 discovery and selection, 463–464 provisioning, 453–454 requirements end service modeling, 447–454 subscribing, 452–453 signaling flows, 436–439 standardization, 455–457 ETSI TISPAN, 420–426, 456 IPTV-GSI, 420 ITU-T, 415–418, 419, 420, 455 users’ influence on, 454–455 IPunity-Glenayre, 103 I/S-CSCF DHT, 252–255, 256 ISDN (integrated services digital network), 5 ISIM (IP multimedia services identity module) cloning, 34 IT-based SDP, 277–278 ITU-T focus group in IPTV, 415–418, 419, 420, 455 (ITU) Union Telecommunication Union, 5 IVR (interactive voice response), 89

J JAIN (Java application programming interfaces for integrated networks) SLEE

B2BUA functionality, 503–505 charging function, 505–506 in the context of IMS, 496–506 dimensioning and performance observed, 506 -driven IMS application server, 500–501 fault tolerance, 501 history of, 494–495 iFC configuration, 506 online charging application server, 502–506 overview, 495–496 stability and scalability, 501 JSR 309, 108

K Kademlia, 76–77 Key management, IMS, 39–44, 45, 52–53

L LCA (local certificate authority), 55–59 LDAP (lightweight directory access protocol), 201 Linux and IMS, 163–167

M Man-in-the-middle attack, 32 Manual cross-certification, 55 Market, multimedia, 105–106 MAS (master authentication server), 287 in multiparty services, 369–372 Masquerading, 34 Media. See Multimedia services Media session termination attack, 34 MEGACO protocol, 94–96, 107 Message services, 178–179 broadcast, 182, 299–300 exchange problems, 209–210 instant, 345–361 MGCF (media gate control function), 32 MGC (media gateway controller), 287–288 MGW (media gateway), 89, 93–94, 103–104, 103–105 MME (mobility management entity), 209 Mobility

537

Index management entity (MME), 209 SCF, 174 MRCP (media resource control protocol), 107 MRF (media resource function), 31–32, 88, 90–92, 104 CAMEL send announcement, 237, 239 interaction with call party, 238, 239–242, 240 MRFP (media resource function processor), 31–32, 90–92 MSCML (media server control markup language), 108 MSC (mobile switching center), 216 MS (mobile station), 216 MSS (mobile subscriber station), 195, 196 MT (Mobile Terminal), 143–149 Multicast delivery service, 374–376 Multimedia services access control layer, 287–288 authentication proxy usage for, . 64–67 availability and range of, 266–267 background and evolution of, 88–89 broadcast, 299–300 conferencing, 89, 101, 181 control protocols, 107–108 core function layer, 288–289 customer context in demand for, 269–270 design requirements, 268–274, 290–291 trends, 298–302 functions into boxes, 101–106 within IMS, 90–96 HTTP service interaction, 292–294 integration service layer, 289–290 IP multimedia subsystem (IMS), 275–276 market, 105–106 MEGACO protocol, 94–96 message, 178–179 multimodal interaction, 300–301 network versus terminal centric models, 106–107 operator motivation for service delivery platform, 270–273 OSS and BSS layer, 291

Parlay and Parlay X standards, 278–280 peer-to-peer services, 300 physical operational model, 296–298 policy models, 97–98 products, 102–105 provisioning and configuration of, 108 quality of service issues, 96–101, 157–158 reference frameworks and architectures in delivery of, 274–283, 283–298 SCF, 175–176 service delivery, 302–303 framework (SDF), 282–283 platform (SDP), 277–278, 283–298 service layer, 290–291 SIP service interaction, 294–296 software as a service (SaaS), 280–281 streaming, 89, 94 subsystem interaction, 291–292 third-party provider business model, 273–274 three-dimensional content, 301–302 transport function layer, 286–287 Multimodal interaction, multimedia services, 300–301 Multiparty services, 363–364 IMS architecture for, 364–366 notifying status of, 377 QoS-enabled multicast delivery service, 374–376 routing of SIP signaling in, 367–370 session cancellation, 378–381 establishment, 367–377 MVNO (mobile virtual network operator), 274

N NDS/IP, 46–49 PKI-based NDS authentication framework, 55–59 use of IPsec with, 50–52 Negotiation service, 332–333 session description, 370–374 Network

538

Index

abstraction, 316–318 authentication function (NAF), 60 DiffServe core, 160–167 domain security (NDS) architecture, 47–49 HSS DHT operation, 251–252 -initiated third-party call, 178 IP multimedia services standards, 275–276 operator infrastructure and grid services, 151–155 provider, grid services, 140–141 and services availability, 35 structured p2p overlay, 75–77 versus terminal centric IMS architecture, 106–107 unstructured p2p overlay, 77–78 NGN (next-generation network) architecture, 5–6 introduction of, 3–4 IPTV services provided over, 412– 413, 444–455, 456–457, 468–469 Open IMS Core project, 115–130 service orchestration in, 330, 342–343 SOA-based SDP for, 311–326 transition from IN to, 4–6 to IMS from, 7–9 NGOSS (New Generation Operations Software and Systems), 282, 322–323 eTOM and, 521–524 life cycle and methodologies, 519–521 OSS/BSS and, 517–519 SID model, 524–526 TAM and, 528–529 TNA and, 526–527 NP (Network Provider), 138

O Offline charging, 475–476 O-IM-BCSM, 220–221, 222–223 OMA (Open Mobile Alliance) service BCAST, 456 composition management, 338–339 enablers, 9–12 environment and policy evaluation, enforcement, and management, 318–320, 323–324

Online charging, 476–479 JAIN SLEE platform, 502–503 Ontology-based service composition management, 339–340 Open IMS Core call session control functions, 117–119 components, 115–116 customization, 126–127 development of, 128–129 home subscriber server, 124–125 interrogating CSCF, 122 as open source, 127–128 outlook for, 129–130 project background, 114–115 proxy-CSCF, 121–122 requirements, 117–118 SER IMS extensions, 119–121 serving CSCF, 123–124 software and hardware requirements, 125–126 working with, 125–127 Operational Virtual Organization (OpVO), 138–140 Operator motivation for service delivery platform, 270–273 OPEX, 515, 517 OSA (Open Service Access) basic mechanisms, 171–173 configuration, 171 framework, 173–174 Parley X API and, 170, 176–182, 183–189 SCFs, 171, 174–176 standardization, 170 web service core technologies, 183–189 OSE (OMA service environment), 318–320 OSS/BSS (operation support systems/ business support systems) defined, 513–514 effectiveness of, 514–515 eTOM and, 521–524 functionalities, 514 for IMS, 517–519 multimedia services layer, 291 NGOSS and, 517–529 SID model and, 524–526 TAM and, 528–529 TNA and, 526–527

539

Index P Parlay X API, 170, 176–182, 317–318 composition management, 339 multimedia services delivery, 278–280, 286–287 WSDL and, 183–187 Password guessing attack, 33 Pastry, 76 Payment accepted response, 294 Payment services, 179 PCEF (Policy and Charging Enforcement Function), 152–154 PCRF (Policy and Charging Rules Function), 153–154 P-CSCF (proxy call state control function), 30–31, 33–34 internetworking and, 200 IPFIX operation and, 161–163 Open IMS Core, 120–122 quality of service issues, 164 PDF (policy decision function) IPFIX scheme and, 161–163 /PRCF interface, 152–154 PDP (packet data protocol), 30–31, 161–163, 201–202 QoS-enabled multicast delivery service, 374–376 PEEM (policy evaluation, enforcement, and management), 319–320, 3. 21 Peer-to-peer technology multimedia, 300 structured p2p overlay network, 75–77 unstructured p2p overlay network, 77–78 PEPs (policy enforcement points), 201 PKI (public key infrastructure), 53–55 -based NDS authentication framework, 55–59 PlayAnnouncement operation, 237, 238 PME (policy management entity), 209 PoC (push-to-talk over cellular) service, 17–22 Policy models, media, 97–98 Preconfigured resources, 203 Prepaid application servers B2BUA architecture and, 482–483

charging for usage of supplementary services, 489–491 dependency on end-user terminals, 481–482 failure issues, 483–486 keep-alive mechanism, 486 offline charging, 475–476 online charging, 476–479 service state machine, 487–489 SIP-based, 473–475, 479–481 SIP stack implementation, 486–487 Presence Parlay X API service, 182 SCF, 175 server to I/S-CSCF DHT node, 254–255 service (PS), 348–355, 356 3GPP IMS service, 356–360 PromptAndCollectUserInformation operation, 238, 241–242 Proxy-CSCF. See P-CSCF (proxy call state control function) PS (presence service), 348–355, 356 Purchase confirmation requests, 294 Purchase content requests, 294 Push-to-talk over cellular (PoC), 17–22

Q QoS (quality of service) -enabled multicast delivery service, 374–376 implementation of IMS and DiffServ core network, 163–167 internetworking and, 200–203 IPFIX module, 160–163, 167 and media functions within call setup, 98–100 monitoring, 30, 31 multimedia and, 96–101, 109, 157–158 problem scenarios, 159–160 universal mobile telecommunication system, 158–160 Wimax technology, 195, 196

R Radisys, 103 RADIUS (Remote Authentication Dialin-User Service), 29

540

Index

Open IMS Core, 119–121 RAN (radio access network), 216, 516 RAT (radio access technology), 207–208 RCE (radio configuration entity), 209 Reconfigurable cognitive wireless network, 206–212 Redirection requests, 293 Reference points GBA, 61–62 media gateway, 93–94 MRF, 92 Registration, HSS DHT, 250, 251 Re-INVITE attack, 34 Repudiation, 34 Reservation, event charging with unit, 477–479 Resource management, internetworking, 210–211 Roaming agreements, 57–59 Route requests, CAMEL, 227 Route_Select_Failure TDP, 221 RSVP (resource reservation protocol), 158 RTP (real-time transport protocol), 29–32, 151 DCON and, 399–402

S SaaS (software as a service), 280–281 SAD (security associations database), 49 Scalability analysis, DCON, 397–406 JAIN SLEE, 501 SCF (service capability feature), OSA, 171, 174–176 SCIM (service capability interaction manager), 313, 340 SCP (service control point), 4–5 S-CSCF (serving call state control function), 7–9, 31, 496–497 CAMEL service, 217, 218 in multiparty services, 368–369 Open IMS Core, 123–124 quality of service issues, 163–167 SCS (service capability server), 170–173 SDF (service delivery framework), 282–283 SDP (service delivery platform), 267, 290–291, 302–303, 512–513

converged, 515–517 IT-based, 277–278 multimedia broadcasting, 299–300 multiparty services, 370–376 operator motivation for, 270–273 physical operational model, 296–298 reference architecture, 283–298 service-oriented architectures (SOA) based, 307–326 software as a service (Saas) versus, 281 three-dimensional visual content, 301–302 SDP (Session Description Protocol), 141, 142–143 SDRs (software-defined ratios), 206–208 Secrecy, IMS, 39–44, 45 Security identity enablers and, 315–316, 325–326 IMS, 28–29 challenges and potential attacks, 32–34 internetworking and, 205–206 management for HTTP-based services, 59–67 mechanisms and security associations, 35–39 interdomain, 45–59 internetworking, 205–206, 211–212 Select service requests, 292–293 Send announcement, CAMEL, 237, 239 SER (SIP Express Router), 114 IMS extensions, 119–121 Server side, DCON, 394–395 Service access and consumption, IPTV, 454 agreement, OSA, 172 brokerage, 320–321 composition management in IMS, 336–342 conflict management in IMS, 330–336 control requests, CAMEL, 227 layer, multimedia service design, 290–291 model, IMS, 12–17 negotiation, 332–333 provisioning, IPTV, 453–454 selection and price response, 294 subscribing, IPTV, 452–453

541

Index Service brokering, 320–321 Service-oriented architectures (SOA), 307–308 blueprint, 308–311 components and standards of, 311–326 IMS enabler, 313–316 integration of operations and business support systems, 322–323 network abstraction, 316–318 OMA service environment and PEEM, 318–320 service brokerage, 320–321 service exposure for web-based mash-ups, 323–326 3GPP IP multimedia subsystem and, 311–313 SIB (service independent building block), 5 SID model, NGOSS, 524–526 Siemens, 104 Signaling, 89 flows, IPTV, 436–439 prepaid application server, 485 Si interface, CAMEL, 229 SIPPING (session initiation proposal investigation), 407 SIP (session initiation protocol) proxy, 6, 7–9, 28, 29, 134, 473–474, 497–498 back-to-back user agent, 499 confidentiality, 43–44, 45 controlled audio/video calls, 149–151 DCON, 398–400 evolution of, 474–475 instant messaging and presence service, 345–348 integrating grid environment with, 141–151 internetworking extensions, 200–206 limitations, 109 multimedia interaction, 294–296 prepaid application server, 473–492 presence service, 345, 348–355, 356 proxy server, 499 quality of service control and, 158 redirect server, 499 register, 257–259 service

capability interaction manager (SCIM) and, 313 conflict avoidance, 332–336 state machine, 487–489 signaling routing, 367–370 SOAP protocol and, 141–149 stack implementation, 486–487 telephony services and, 88 terminal mobility and, 147–149 Uniform Resource Identifier (URI), 143 user agent, 498–499 SIP (strategy, infrastructure, and product), 522 SLAs (Service Level Agreements), 138 SLEE. See JAIN (Java application programming interfaces for integrated networks) SME (spectrum management entity), 208, 210–211 SMS (short messaging service), 178 SNMP (simple network management protocol), 209–210 SnowShore IP media server, 102 SOAP protocol, 141–149, 187–189 service brokers, 321 SPD (security policy database), 49 Spoofing attack, 32 SP (Service Provider), 136–137, 140 SQL injection, 33–34 SRM (service relationship management), 288 SS (streaming service), 89, 94 Stability, JAIN SLEE, 501 Streaming, 89, 94 Structured p2p overlay network, 75–77 Subscribe data, CAMEL, 223–226, 234, 235

T TAM (telecom applications map), 528–529 Tapestry, 76 TDM (Time Division Multiplexing) switch, 4 Technical functions IMS, 14–17 PoC services, 19–22 Telco Web 2.0 enabler, 324–325

542

Index

Telephony, 88–89 Parlay and Parlay X services, 279 service conflict management in, 330–336 third-party call service, 177–178 Terminal(s) capability SCF, 175 -centric model, 106–107 disconnection and reconnection of, 147–149 location, 180 mobile, 143–149 prepaid application server dependency on end-user, 481–482 status services, 180 THIG (topology hiding mechanism), 205 Third-party call service, 177–178 Three-dimensional visual content, 301–302 3GPP (3rd Generation Partnership Project) networks, 4, 9, 10, 88 IMS architecture for, 193–194 internetworking, 192–213 IP multimedia subsystem, 311–313 multiparty services in, 363–364 OSA standardization, 170 presence service, 356–360 QoS and media functions within call setup, 98–100 security, 28–29 service capability interaction manager (SCIM), 313 value-added applications and integrated multimedia, 28 T-IM-BCSM, 223, 224, 224–225 TNA (technology-neutral architecture), 526–527 Transport function layer, multimedia services, 286–287 TTS (text-to-speech), 89

U UE-originated session in IM-SSF, 229–231, 232–235 UMTS (universal mobile telecommunication system), 192–194 authentication, 211

internetworking and, 204–205, 211 IPFIX scheme, 160–163 quality of service problems, 158–160 Unit reservation, event charging with, 477, 478 Unstructured p2p overlay network, 77–78 User agent, SIP, 498–499 authentication, 41–44, 45 confidentiality, 35 equipment (UE), 60 expectation, IPTV, 448–450 influence on IMS-based IPTV, 454–455 interaction SCF, 175

V Video calls, SIP controlled, 149–151 digital broadcasting, 299 three-dimensional content, 301–302 Virtual Organizations Base, 137–138 Operational, 138–140 Visual content, three-dimensional, 301–302 VLR (visitor location register), 216 VoiceXML, 108, 180 VoIP (voice over Internet protocol), 28, 448, 474 VPN tunnels, 58–59

W WAP (wireless application protocol), 286, 287, 298 Wimax technology, 195, 196 internetworking architecture, 197–200 WLAN (wireless local access network), 192, 194–195 internetworking architecture, 197–200 WMAN (wireless metropolitan area networks), 195, 196 WSDL (Web Service Description Language), 143, 147 Parlay X API and, 183–187

543

Index X XCON, 384–386, 389–390, . 399–407 XDMC (XDM client), 19–22 XDM (XML document management), 19–22

XML (extended meta language) document management (XDM), 19–22, 116 multimedia services and, 108 SOAP, 141–149, 183–187 WSDL, 183–187

IP Multimedia Subsystem (IMS) Handbook

The IP Multimedia Subsystem (IMS)

The IMS: IP Multimedia Concepts and Services

The IMS: IP Multimedia Concepts and Services

The 3G IP multimedia subsystem (IMS): merging the Internet and the cellular worlds

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds, Second Edition

The IMS: IP Multimedia Concepts and Services in the Mobile Domain

The Multimedia Handbook

Multimedia Security Handbook

IP Integration Handbook

Multimedia Security Handbook

IP Telephony: Deploying VoIP Protocols and IMS Infrastructure, Second Edition

IP Telephony: Deploying VoIP Protocols and IMS Infrastructure

IP

Multimedia

IP

IP

IP

IP

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

IP

IP

ip

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

IP

IP

IP

Handbook of Research on Mobile Multimedia

Handbook of Digital and Multimedia Forensic Evidence

IP Multimedia Subsystem (IMS) Handbook

The IP Multimedia Subsystem (IMS)

The IMS: IP Multimedia Concepts and Services

The IMS: IP Multimedia Concepts and Services

The 3G IP multimedia subsystem (IMS): merging the Internet and the cellular worlds

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds, Second Edition

The IMS: IP Multimedia Concepts and Services in the Mobile Domain

The Multimedia Handbook

Multimedia Security Handbook

IP Integration Handbook

Multimedia Security Handbook

IP Telephony: Deploying VoIP Protocols and IMS Infrastructure, Second Edition

IP Telephony: Deploying VoIP Protocols and IMS Infrastructure

IP

Multimedia

IP

IP

IP

IP

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

IP

IP

ip

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

IP

IP

IP

Handbook of Research on Mobile Multimedia

Handbook of Digital and Multimedia Forensic Evidence

Recommend Documents