throbber
Second Edition
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket