`
`GONZALO CAMARILLO
`
`MIGUEL A. GARCIA-MARTIN
`
`THE3G
`
`.IP MULTIMEDIA
`SUBSYSTEM(IMS)
`
`MERGING THE INTERNET AND THE CELLULAR WORLDS
`
`I l
`
`i
`
`
`
`Page 1 of 28
`
`1
`
`HTC EXHIBIT 1016
`
`1
`
`HTC EXHIBIT 1016
`
`Page 1 of 28
`
`
`
`The 3G IP Multimedia
`
`Subsystem (IMS)
`
`
`
`
`
`Page 2 of 28
`
`2
`
`2
`
`Page 2 of 28
`
`
`
`'““1
`
`l
`
`The 3G IP
`
`F Multimedia
`
`Subsystem (IMS)
`
`Merging the Internet and the
`Cellular Worlds
`
`Second Edition
`
`Gonzalo Camarillo
`Ericsson, Finland
`
`Miguel A. Garcia-Martin
`Nokia Research Center, Finland
`
`John Wiley & Sons, Ltd
`
`
`
`Page 3 of 28
`
`3
`
`3
`
`Page 3 of 28
`
`
`
`Copyright © 2006
`
`John Wiley & Sons Ltd, The Atrium. Southern Gate, Chichester.
`West Sussex P019 SSQ. England
`Telephone
`(+44) 1243 779777
`Email (for orders and customer service enquiries): cs-books@wiley.co.uk
`Visit our Home Page on www.wiley.com
`
`Reprinted with corrections May 2006
`
`All Rights Reserved. No part of this publication may be reproduced. stored in a retrieval system or
`transmitted in an}.r form or by any means. electronic. mechanical. photocopying. recording. scanning or
`otherwise. except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of e
`licence issued by the Copyright Licensing AgenCy Ltd. 90 Totleehttm Com Road. London WIT 4LP.
`UK. without the permission in writing of the Publisher. Requests to the Publisher should be addressed to
`the Permissions Department, John Wiley 3: Sons Ltd. The Atrium. Southern Gate. Chichester. West
`Sussex POI‘J ESQ. England. or emailed to pennrcq®wiley.co.uk, or faxed to (+44] |243 770620.
`
`Designations used by companies to distinguish their products are often claimed as trademarks. All brand
`names and product names used in this book are trade names. service marks. trademarks or registered
`trademarks of their respective owners. The Publisher is not associated with anyr product or vendor
`mentioned in this book. This publication is designed to provide uccurttte and authoritative information in
`regard to the subject matter covered. It is sold on the understanding that the Publisher is not engaged in
`rendering professional services. 11' professional advice or other expert assistance is required. the services
`of a competent professional should be sought.
`Other Wiley Editorial Ofiices
`John Wiley & Sons Inc.. 111 River Street. Hoboken. NJ 07030, USA
`Jossey—Bass, 989 Market Street. San Francisco. CA 94103-1741, USA
`Wiley-VCH Verlag GmbH, Boschstr. 12. D—69469 Weinhcim, Germany
`John Wiley & Sons Australia Ltd. 42 McDougall Street, Milton, Queensland 4064, Australia
`John Wiley & Sons (Asia) Pte Ltd. 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809
`John Wiley & Sons Canada Ltd. 22 Worcester Road. Etobicoke. Ontario. Canada M9W 1L1
`Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
`not be available in electronic books.
`
`Library of Congress Cataloging-in-Publication Data
`Camarillo. Gonzalo.
`The 3G 1P multimedia subsystem (LMS) : merging the Internet and the cellular worlds / Gonzalo
`Camarillo. Miguel A. Garcia-Martin.—2nd ed.
`p. cm.
`Includes bibliographical references and index.
`ISBN-13: 978—0-470-01818-7 (cloth : alk. paper)
`ISBN—10: 0-470-01818-6 (cloth : alk. paper)
`
`1. Wireless communication systems. 2. Mobile communication systems. 3. Multimedia
`communications. 1. Garcia—Martin, Miguel A. II. Title.
`TK5103.2.C35 2006
`621.384—dc22
`
`2005026863
`
`British Library Cataloguing in Publication Data
`A catalogue record for this book is available from the British Library
`ISBN-13 978-0—470-0l818-7 (HB)
`ISBN—10 0-470—01818—6 (HB)
`
`Typeset by Sunrise Setting Ltd. Torquay. Devon. UK.
`Printed and bound in Great Britain by Antony Rowe Ltd. Chippenham. Wiltshire.
`This book is printed on acid-free paper responsibly manufactured from sustainable forestry in which at
`least two trees are planted for each one used for paper production.
`
`Page 4 of 28
`
`4
`
`Page 4 of 28
`
`
`
`THE IMS STANDARDIZATInm .
`
`i
`
`'—
`
`General Principles of the IMS
`
`Architecture
`
` Chapter 3
`
`In Chapter 1 we introduced the circuit-switched and the packet-switched domains and
`described why we need the IMS to provide rich Internet services. Chapter 2 introduced the
`players standardizing the EMS and defining its architecture.
`in this chapter we will describe
`the history of the circuit-switched and the packet-switched domains.
`In addition, we will
`introduce the design principles that lay behind the IMS architecture and its protocols. We will
`also tackle in this chapter the IMS network nodes and the different ways in which users are
`identified in the IMS.
`
`3.1 From Circuit-switched to Packet-switched
`Let us look at how cellular networks have evolved from circuit—switched networks to packet-
`switched networks and how the IMS is the next step in this evolution. We will start with a
`brief introduction to the history of the 3G circuit-switched and packet-switched domains.
`The Third Generation Partnership Project (3GPP) is chartered to develop specifications
`for the evolution of GSM. That is, 3GPP uses the GSM specifications as a design base for a
`third-generation mobile system.
`circuit-switched and packet-switched.
`GSM has two different modes of operation:
`The 3G circuit-switched and packet-switched domains are based on these GSM modes of
`operation.
`
`3.1.1 GSM Circuit-switched
`
`Not surprisingly, GSM circuit-switched uses circuit-switched technologies, which are also
`used in the PSTN (Public Switched Telephone Network). Circuit—switched networks have
`two different planes: the signaling plane and the media plane.
`The signaling plane includes the protocols used to establish a circuit-switched path
`between terminals. In addition, service invocation also occurs in the signaling plane.
`The media plane includes the data transmitted over the circuit—switched path between the
`terminals. The encoded voice exchanged between users belongs to the media plane.
`Signaling and media planes followed the same path in early circuit-switched networks.
`Nevertheless, at a certain point in time the PSTN started to differentiate the paths the signaling
`
`
`The JG IP Multimedia Subsyrlem (IMS) Second Edition Gonzalo Camarillo and Miguel A. Garcla—Martln
`© 2006 John Wiley & Sons. Ltd
`
`Page 5 of 28
`
`5
`
`Page 5 of 28
`
`
`
`24
`
`CHAPTER 3. GENERAL PRINCIPLES OF THE IMS ARCHITECTURE
`
`plane and the media plane follow. This differentiation was triggered by the introduction of
`services based on IN (Intelligent Network). Calls to toll-free numbers are an example of
`an IN service. The GSM version of IN services is known as CAMEL services (CustomiZed
`Applications for Mobile networks using Enhanced Logic).
`In both IN and CAMEL the signaling plane follows the media plane until a point where
`the call is temporarily suspended. At that point the signaling plane performs a database query
`(e.g., a query for a routing number for an 800 number) and receives a response. When the
`signaling plane receives the response to the query the call setup is resumed and both the
`signaling plane and the media plane follow the same path until they reach the destination.
`3GPP has gone a step further in the separation of signaling and media planes with the
`introduction of the split architecture for the MSC (Mobile Switching Center). The MSC is
`split into an MSC server and a media gateway. The MSC server handles the signaling plane
`and the media gateway handles the media plane. The split architecture was introduced in
`Release 4 of the SGPP specifications.
`We will see that the IMS also keeps signaling and media paths separate, but goes even
`further in this separation. The only nodes that need to handle both signaling and media are
`the IMS terminals; no network node needs to handle both.
`
`3.1.2 GSM Packet-switched
`
`The GSM packet—switched network, also known as GPRS (General Packet Radio Service,
`specified in 3GPP TS 23.060 [15]) was the base for the 3GPP Release 4 packet-switched
`domain. This domain allows users to connect to the Internet using native packet-switched
`technologies.
`Initially, there were three applications designed to boost the usage of the packet-switched
`domain.
`
`1. The Wireless Application Protocol (WAP) [233].
`
`2. Access to corporate networks.
`
`3. Access to the public Internet.
`
`Nevertheless, none of these applications was attracting enough customers to justify the
`enormous cost to deploy packet—switched mobile networks.
`
`3.2
`
`IMS Requirements
`
`The situation operators were facing right before the conception of the IMS was not
`encouraging at all. The circuit-switched voice market had become a commodity, and
`operators found it difficult to make a profit by only providing and charging for voice calls.
`On the other hand, packet-switched services had not taken off yet, so. operators were not
`making much money from them either.
`Thus, operators needed a way to provide more attractive packet—switched services to
`attract users to the packet-switched domain. That is. the mobile Internet needed to become
`more attractive to its users. In this way the IMS (IP Multimedia Subsystem) was born. With
`the vision described in Chapter 1 in mind, equipment vendors and operators started designing
`the IMS.
`
`
`
`Page 6 of 28
`
`6
`
`Page 6 of 28
`
`
`
`
`
`32, IMS REQUIREMENTS
`
`So, the IMS aims to:
`
`1, combine the latest trends in technology;
`
`25
`
`make the mobile Internet paradigm come true;
`
`create a common platform to develop diverse multimedia services;
`
`PP!“ create a mechanism to boost margins due to extra usage of mobile packet-switched
`
`networks.
`
`Let us look at me requirements that led to the design of the 3GPP IMS (captured in
`3GPP TS 22.228 [34] Release 5). In these requirements the IMS is defined as an architectural
`framework created for the purpose of delivering IP multimedia services to end—users. This
`framework needs to meet the following requirements.
`
`1. Support for establishing IP Multimedia Sessions.
`
`2. Support for a mechanism to negotiate Quality of Service (QoS).
`
`3. Support for interworking with the Internet and circuit-switched networks.
`
`4. Support for roaming.
`
`5. Support for strong control imposed by the operator with respect to the services
`
`delivered to the end—user.
`
`6. Support for rapid service creation without requiring standardization.
`
`The release 6 version of 3GPP TS 22.228 [34] added a new requirement to support access
`from networks other than GPRS. This is the so—called access independence of the IMS. since
`the IMS provides support for different access networks.
`
`3.2.]
`
`[P Multimedia Sessions
`
`The IMS can deliver a broad range of services. Still, there is one service of special importance
`for users: audio and video communications. This requirement stresses the need to support the
`main service to be delivered by the IMS: multimedia sessions over packet—switched networks.
`Multimedia refers to the simultaneous existence of several media types. The media types in
`this case are audio and video.
`
`Multimedia communications were already standardized in previous 3GPP releases, but
`those multimedia communications take place over the circuit-switched network rather than
`the packet-switched network.
`
`3.2.2
`
`903
`
`Continuing with the analysis of the requirements we find the requirement to negotiate a
`certain QoS (Quality of Service). This is a key component of the IMS.
`The QoS for a particular session is determined by a number of factors, such as the
`maximum bandwidth that can be allocated to the user based on the user’s subscription or
`the current state of the network. The IMS allows operators to control the Q08 a user gets, so
`that operators can differentiate certain groups of customers from others.
`
`4"1..
`
`_{
`
`'i
`
`I"
`
`. A...
`
`Page 7 of 28
`
`7
`
`7
`
`Page 7 of 28
`
`
`
`26
`
`CHAPTER 3. GENERAL PRINCIPLES OF THE IMS ARCHITECTURE
`
`3.2.3
`
`Interworking
`
`Support for interworking with the Internet is an obvious requirement, given that the Internet
`offers millions of potential destinations for multimedia sessions initiated in the IMS.
`By requiring interworking with the Internet the number of potential sources and destinations
`for multimedia sessions is dramatically expanded.
`The IMS is also required to interwork with Circuit-switched networks, such as the PSTN
`(Public Switched Telephone Network), or existing cellular networks. The first audio/video
`IMS terminals that will reach the market will be able to connect to both circuit-switched and
`
`packet-switched networks. So, when a user wants to call a phone in die PSTN or a cellular
`phone the IMS terminal chooses to use the circuit-switched domain.
`So,
`interworking with circuit-switched networks is not strictly required although,
`effectively, most of the IMS terminals will also support the circuit-switched domain.1 The
`requirement to support interworking with circuit-switched networks can be considered a long-
`term requirement. This requirement will be implemented when it is possible to build IMS
`terminals with packet-switched support only.
`
`3.2.4 Roaming
`
`Roaming support has been a general requirement since the second generation of cellular
`networks; users have to be able to roam to different networks (e.g., a user visiting a foreign
`country). Obviously the IMS inherits this requirement, so it should be possible for users to
`roam to different countries (subject to the existence of a roaming agreement signed between
`the home and the visited network).
`
`3. 2.5 Service Control
`
`Operators typically want to impose policies on the services delivered to the user. We can
`divide these policies into two categories.
`
`0 General policies applicable to all the users in the network.
`
`a Individual policies that apply to a particular user.
`
`The first type of policy comprises a set of restrictions that apply to all users in the network.
`For instance, operators may want to restrict the usage of high—bandwidth audio codecs, such
`as G.7ll (ITU-T Recommendation G.711 [131]), in their networks. Instead, they may want
`to promote lower bandwidth codecs like AMR (Adaptive Multi Rate, specified in 3GP? TS
`26.071 [5]).
`The second type of policy includes a set of policies which are tailored to each user. For
`instance, a user may have some subscription to use IMS services that do not include the use
`of video. The IMS terminal will most likely support video capabilities, but in case the user
`attempts to initiate a multimedia session that includes video the operator will prevent that
`session being set up. This policy is modeled on a user-by—user basis, as they are dependent
`on the terms of usage in the user’s subscription.
`
`lIMS terminals supporting audio capabilities are required to support the circuit-switched domain due to the
`inability of the IMS (at least in the first phases) to provide support for emergency calls. So, emergency calls are
`placed over the circuit-switched domain. Emergency calls are further analyzed in Seclion 5.10.
`
`
`
`Page 8 of 28
`
`8
`
`Page 8 of 28
`
`
`
` 3,3. OVERVIEW OF PROTOCOLS USED IN THE IMS
`
`3.2. 7 Multiple Access
`
`27
`
`3.2.6 Rapid Service Creation
`The requirement about service creation had a strong impact on the design of MS architecture.
`This requirement states that IMS services do not need to be standardized.
`This requirement represents a milestone in cellular design. because in the past. every
`single service was either standardized or had a proprietary implementation. Even when
`services were standardized there was no guarantee that the service would work when roaming
`to another Remark. The reader may already have experienced the lack of support for call
`diversion to voicemail in GSM networks when the user is visiting another country.
`The IMS aims to reduce the time it takes to introduce a new service.
`In the past the
`standardization of the service and interoperability tests caused a significant delay. The IMS
`reduces this delay by standardizing service capabilities instead of services.
`
`'
`
`_-
`I
`
`i.
`
`The multiple access requirement introduces other means of access than GPRS. The IMS is
`just an lP network and, like any other IP network. it is lower layer and access-independent.
`Any access network can in principle provide access to the IMS. For instance. the IMS can be
`accessed using a WLAN [Wireless Local Access Network). an ADSL (Asymmetric Digital
`Subscriber Line), an HFC (Hybrid Fiber Coax), or a Cable Modem.
`Still, SGPP, as a project committed to developing solutions for the evolution of GSM,
`has focused on GPRS access (both in GSM and UMTS, Universal Mobil Telecommunication
`System) for the first release of the IMS (i.c., Release 5). Future releases will study other
`accesses, such as WLAN.
`
`3.3 Overview of Protocols used in the IMS
`
`When the European Telecommunications Standard Institute (ETSI) developed the GSM
`standard, most of its protocols were specially designed for GSM (especially those dealing
`with the radio interface and with mobility management). ETSI reused only a few protocols
`developed by the International Telecommunication Union-Telecommunications (ITU-T).
`Most of the protocols were developed from scratch because there were no existing protocols
`to take as a base.
`
`A few years later, 3GPP began developing the IMS, a system based on IP protocols.
`which had been traditionally developed by the IETF (Internet Engineering Task Force). 3GPP
`analyzed the work done in the past by ETSI in developing its own protocols and decided
`to reuse protocols which had already been developed (or were under development at that
`time) in other Standards Development Organizations (SD05) such as the IETF or ITU-T.
`This way, 3GPP takes advantage of the experience of the IETF and the ITU-T in designing
`robust protocols, reducing at the same time standardization and development costs.
`
`3.3.1
`
`Session Control Protocol
`
`In circuit-
`The protocols that control the calls play a key role in any telephony system.
`switched networks the most common call control protocols are TUP (Telephony User Part,
`ITU-T Recommendation Q.721 [130]), ISUP (ISDN User Part, ITU-T Recommendation
`Q.761 [139]), and the more modern BICC (Bearer Independent Call Control,
`ITU-T
`Recommendation Q.1901 [140]). The protocols considered to be used as the session control
`protocol for the IMS were obviously all based on IP. The candidates were as follows.
`
`1,
`
`_
`
`Page 9 of 28
`
`9
`
`9
`
`Page 9 of 28
`
`
`
`l
`
`'
`
`1
`
`‘
`
`‘.
`
`I
`
`I
`i
`[.
`1.
`|
`
`J
`
`28
`
`CHAPTER 3. GENERAL PRINCIPLES OF THE IMS ARCHITECTURE
`
`Bearer Independent Call Control (BICC): BICC (specified in ITU-T Recommendation
`Q.1901 [140]) is an evolution of ISUP. Unlike ISUP. BICC separates the signaling
`plane from the media plane, so that signaling can traverse a separate set of nodes
`than the media plane. Additionally, BICC supports and can run over a different set
`of technologies, such as IP, SS7 (Signaling System No. 7, ITU—T Recommendation
`Q.700 [134]), or ATM (Asynchronous Transfer Mode).
`
`like BICC, H.323 (ITU-T Recommendation H.323 [145]) is an ITU-T protocol.
`H.323:
`H.323 defines a new protocol to establish multimedia sessions. Unlike BICC, H.323
`was designed from scratch to support I? technologies.
`In H.323. signaling and the
`media do not need to traverse the same set of hosts.
`
`SIP (Session Initiation Protocol, RFC 3261 [215]): specified by the IETF as a protocol
`to establish and manage multimedia sessions over IP networks, SIP was gaining
`momentum at the time 3GPP was choosing its session control protocol. SIP follows
`the well-known client—server model, so much used by many protocols developed by
`the IETF. SIP designers borrowed design principles from SMTP (Simple Mail Transfer
`Protocol, RFC 2821 [151]) and especially, from HTTP (Hypertext Transfer Protocol,
`RFC 2616 [101]). SIP inherits most of its characteristics from these two protocols.
`This is an important strength of SIP. because HTTP and SMTP are the most successful
`protocols on the Internet. SIP, unlike BICC and H.323, does not differentiate the User-
`to-Network Interface (UNI) from a Network-to-Network Interface (NNI). In SIP there
`is just a single protocol which works and to end. Unlike BICC and H.323, SIP is a
`text-based protocol. This means that it is easier to extend, debug, and use to build
`services.
`
`SIP was chosen as the session control protocol for the IMS. The fact that SIP makes it
`easy to create new services can'ied great weight in this decision. Since SIP is based on HTTP,
`SIP service developers can use all the service frameworks developed for HTTP, such as CGI
`(Common Gateway Interface) and Java servlets.
`
`3.3.2 The AAA Protocol
`
`In addition to the session control protocol there are a number of other protocols that play
`important roles in the IMS. Diameter (whose base protocol is specified in RFC 3588 [60])
`was chosen to be the AAA (Authentication, Authorization, and Accounting) protocol in the
`IMS.
`
`Diameter is an evolution of RADIUS (specified in RFC 2865 [195]), which is a protocol
`that is widely used on the Internet to perform AAA. For instance, when a user dials up to an
`Internet Service Provider (ISP) the network access server uses RADIUS to authenticate and
`authorize the user accessing the network.
`Diameter consists of a base protocol that is complemented with so-called Diameter
`Applications. Diameter applications are customizations or extensions to Diameter to suit
`a particular application in a given environment.
`The IMS uses Diameter in a number of interfaces, although not all the interfaces use the
`same Diameter application. For instance, the IMS defines a Diameter application to interact
`with SIP during session setup and another one to perform credit control accounting.
`
`Page 10 0f28
`
`10
`
`10
`
`Page 10 of 28
`
`
`
`
`
`3,4. OVERVIEW OF IMS ARCHITECTURE
`
`29
`
`3.3.3 Other Protocols
`
`In addition to SIP and Diameter there are other protocols that are used in the IMS. The COPS
`(Common Open Policy Service) protocol {specified in RFC 2748 [85]) is used to transfer
`policies between PDPs (Policy Decision Points) and PEPs (Policy Enforcement Points).
`H.248 (l’l’U-T Reconmicndetion H.248 [1431) and its packages are used by signaling
`nades to control nodes in the media plane (e.g., a media gateway controller controlling a
`media gateway). H.248 was jointly developed by ITU—T and IETF and is also referred to as
`the MEGACO (MEdia GAteway COntrol) protocol.
`RTP (Real-Time Transport Protocol, defined in RFC 3550 [225]) and RTCP (RTP Control
`Protocol, defined in RFC 3550 [225] as well) are used to transport real-time media, such as
`, video and audio.
`We have mentioned a few application—layer protocols used in the IMS. We will describe
`these in Parts 11 and III of this book, along with other application-layer Internet protocols that
`may be used in the IMS in the future, and other protocols that belong to other layers.
`
`3.4 Overview of IMS Architecture
`
`Before exploring the general architecture in the IMS we should keep in mind that 3GPP does
`not standardize nodes, but functions. This means that the IMS architecture is a collection of
`functions linked by standardized interfaces. Implementers are free to combine two functions
`into a single node (e.g., into a single physical box). Similarly, implementers can split a single
`function into two or more nodes.
`
`In general, most vendors follow the IMS architecture closely and implement each function
`into a single node. Still, it is possible to find nodes implementing more than one function and
`functions distributed over more than one node.
`
`Figure 3.1 depicts an overview of the IMS architecture as standardized by 3GPP.
`The figure shows most of the signaling interfaces in the IMS, typically referred to by a two—
`or three-letter code. We do not include all the interfaces defined in the IMS, but only the most
`relevant ones. The reader can refer to 3GPP TS 23.002 [28] to find a complete list of all the
`interfaces.
`
`On the left side of Figure 3.1 we can see the IMS mobile terminal, typically referred to as
`the User Equipment (UE). The IMS terminal attaches to a packet network, such as the GPRS
`network, through a radio link.
`Note that, although the figure shows an IMS terminal attaching to the network using a
`radio link, the IMS supports other types of devices and accesses. PDAs (Personal Digital
`Assistants) and computers are examples of devices that can connect to the IMS. Examples of
`alternative accesses are WLAN or ADSL.
`
`The remainder of Figure 3.1 shows the nodes included in the so-called IP Multimedia
`Core Network Subsystem. These nodes are:
`
`0 one or more user databases. called HSSs (Home Subscriber Servers) and SLFs
`(Subscriber Location Functions);
`
`in one or more SIP servers, collectively known as CSCFS (Call/Session Control Func-
`tions);
`
`0 one or more ASs (Application Servers);
`
`
`
`‘11—?)‘L—afi'fizfi‘
`
`"
`"
`
`I]
`
`Page 11 0f28
`
`11
`
`11
`
`Page 11 of 28
`
`
`
`._....-.-
`
`r—“fl-o
`
`30
`
`CHAPTER 3. GENERAL PRINCIPLES OF THE IMS ARCHITECTURE
`
`
`
`Figure 3.1: 3GPP IMS architecture overview
`
`0 one or more MRFs (Media Resource Functions), each one further divided into
`MRFC (Media Resource Function Controllers) and MRFP (Media Resource Function
`Processors);
`
`0 one or more BGCFs (Breakout Gateway Control Functions);
`
`0 one or more PSTN gateways, each one decomposed into an SGW (Signaling Gateway),
`an MGCF (Media Gateway Controller Function), and an MGW (Media Gateway).
`
`Note that Figure 3.1 does not contain a reference to charging collector functions. These
`are described in Section 7.4.
`
`3.4.]
`
`The Databases: the HSS and the SLF
`
`The Home Subscriber Server (HSS) is the central repository for user-related information.
`Technically, the HSS is an evolution of the HLR (Home Location Register), which is a GSM
`node. The HSS contains all the user-related subscription data required to handle multimedia
`sessions. These data include. among other items, location information, security information
`(including both authentication and authorization information). user profile information
`(including the services that the user is subscribed to), and the S—CSCF (Serving—CSCF)
`allocated to the user.
`
`A network may contain more than one HSS, in case the number of subscribers is too high
`to be handled by a single HSS. In any case. all the data related to a particular user are stored
`in a single Hss.2
`
`to avoid a single point of failure.
`redundant configuration.
`2The HSS is typically implemented using a
`Nevertheless, we consider a redundant configuration of H585 as a single logical node.
`
`
`
`Page 12 of 28
`
`12
`
`12
`
`Page 12 of 28
`
`
`
`
`
`3,4. OVERVEW OF IMS ARCHITECTURE
`
`31
`
`Networks with a single HSS do not need a Subscription Locator Function (SLF). On the
`other hand, networks with more than one HSS do require an SLF.
`The SLF is a simple database that maps users’ addresses to H883. A node that queries
`the sLF, with a user’s address as the input, obtains the HSS that contains all the information
`related to that user as the output.
`Both the HSS and the SLF implement the Diameter protocol (RFC 3588 [60]) with an
`IMS-specific Diameter application.
`
`3.4.2 The CSCF
`
`The. CSCF (Call/Session Control Function), which is a SIP server, is an essential node in
`the IMS. The CSCF processes SIP signaling in the IMS. There are three types of CSCFs,
`depending on the functionality they provide. All of them are collectively known as CSCFs,
`but any CSCF belongs to one of the following three categories.
`
`in P-CSCF (Proxy—CSCF).
`
`I I—CSCF (Interrogating-CSCF).
`
`a S-CSCF (Serving-CSCF).
`
`3.4.2.1 The P-CSCF
`
`The P-CSCF is the first point of contact (in the signaling plane) between the IMS terminal and
`the IMS network. From the SIP point of view the P—CSCF is acting as an outbound/inbound
`SIP proxy server. This means that all the requests initiated by the IMS terminal or destined
`for the IMS terminal traverse the P-CSCF. The P—CSCF forwards SIP requests and responses
`in the appropriate direction (i.e., toward the IMS terminal or toward the IMS network).
`The P—CSCF is allocated to the IMS terminal during IMS registration and does not change
`for the duration of the registration (i.e., the IMS terminal communicates with a single P-CSCF
`during the registration).
`The P—CSCF includes several functions, some of which are related to security. First. it
`establishes a number of IPsec security associations toward the IMS terminal. These IPsec
`security associations offer integrity protection (i.e., the ability to detect whether the contents
`of the message have changed since its creation).
`Once the P-CSCF authenticates the user (as part of security association establishment)
`the P-CSCF asserts the identity of the user to the rest of the nodes in the network. This way,
`other nodes do not need to further authenticate the user, because they trust the P-CSCF. The
`rest of the nodes in the network user’s identity (asserted by the P—CSCF) have a number of
`purposes, such as providing personalized services and generating account records.
`Additionally,
`the P-CSCF verifies the correctness of SIP requests sent by the IMS
`terminal. This verification keeps IMS terminals from creating SIP requests that are not built
`according to SIP rules.
`The P-CSCF also includes a compressor and a decompressor of SIP messages (IMS
`terminals include both as well). SIP messages can be large, given that SIP is a text-based
`protocol. While a SIP message can be transmitted over a broadband connection in a fairly
`short time, transmitting large SIP messages over a narrowband channel, such as some radio
`links, may take a few seconds. The mechanism used to reduce the time to transmit a SIP
`
`Page 13 of 28
`
`13
`
`13
`
`Page 13 of 28
`
`
`
`:5
`l'
`l
`'
`1
`I
`i
`
`l
`
`l
`
`32
`
`CHAPTER 3. GENERAL PRINCIPLES OF THE HMS ARCHITECTURE
`
`message is to compress the message, send it over the air interface, and decompress it at the
`other end.3
`The P-CSCF may include a PDF (Policy Decision Function). The PDF may be integrated
`with the P-CSCF or be implemented as a stand—alone unit. The PDF authorizes media plane
`resources and manages Quality of Service over the media plane.
`The P-CSCF also generates charging information toward a charging collection node.
`An IMS network usually includes a number of P-CSCFs for the sake of scalability and
`redundancy. Each P—CSCF serves a number of HVIS terminals, depending on the capacity of
`the node.
`
`3.4.2.2 P-CSCF Location
`
`The P-CSCF may be located either in the visited network or in the home network: In case
`the underlying packet network is based on GPRS. the P—CSCF is always located in the same
`network where the GGSN (Gateway GPRS Support Node) is located. So both P—CSCF and
`GGSN are either located in the visited network or in the home network. Due to current
`
`deployments of GPRS. it is expected that the first IMS networks will inherit this mode and
`will be configured with the GGSN and P—CSCF in the home network. It is also expected that
`once IMS reaches the mass market, operators will migrate the configuration and will locate
`the P—CSCF and the GGSN in the visited network.
`
`3.4.2.3 The I-CSCF
`
`The I-CSCF is a SIP proxy located at the edge of an administrative domain. The address of
`the I-CSCF is listed in the DNS (Domain Name System) records of the domain. When a SIP
`server follows SIP procedures (described in RFC 3263 [214]) to find the next SIP hop for a
`particular message the SIP server obtains the address of an l-CSCF of the destination domain.
`Besides the SIP proxy server functionality the I-CSCF has an interface to the SLF and
`the HSS. This interface is based on the Diameter protocol (RFC 3588 [60]). The I-CSCF
`retrieves user location information and routes the SIP request to the appropriate destination
`(typically an S-CSCF).
`Additionally,
`the I-CSCF may optionally encrypt the parts of the SIP messages that
`contain sensitive information about the domain, such as the number of servers in the domain,
`their DNS names, or their capacity. This functionality is referred to as THIG (Topology
`Hiding Inter-network Gateway). THIG functionality is optional and is not likely to be
`deployed by most networks.
`A network will include typically a number of I-CSCFs for the sake of scalability and
`redundancy.
`
`3.4.2.4
`
`I-CSCF Location
`
`The I—CSCF is usually located in the home network, although in some especial cases, such as
`an l-CSCF(THIG), it may be located in a visited network as well.
`
`3There is a misconception that compression between the IMS terminal and the P-CSCF is enabled just to save a
`few bytes over the air interface. This is not the motivation lying bchind compression. In particular.
`it is not worth
`saving a few bytes of signaling when the IMS terminal will be establishing a multimedia session (e.g., audio, Video)
`that will use much more bandwidth than the signaling. The main motivation for compression is to reduce the time to
`transmit SIP messages over the air interface.
`
`
`
`Page 14 0f28
`
`14
`
`14
`
`Page 14 of 28
`
`
`
` 3 4, OVERVIEW OF IMS ARCHITECTURE
`
`33
`
`3.4.2.5 The S-CSCF
`The s-CSCF is the central node of the sig