Evaluation of the Fraunhofer Open Source IMS Core platform with special focus on the Call Session Control Function (CSCF)

Contents

Abstract

Kurzfassung

1. Purpose of this Thesis

2. Introduction

I UNDERSTANDINGIMS

3. Principles of the IP Multimedia Subsystem
3.1. What is the IP Multimedia Subsystem?
3.2. IMS Specification Bodies: 3GPP and IETF
3.3. High Level Requirements
3.3.1. Differences to RFC 3261 SIP
3.3.2. Registration
3.3.3. Session Setup & Control
3.4. Private Header Extensions to SIP for 3GPP
3.4.1. P-Access-Network-Info Header
3.4.2. P-Asserted-Identity Header
3.4.3. P-Associated-URI Header
3.4.4. P-Called-Party-ID Header
3.4.5. P-Charging-Function-Addresses Header
3.4.6. P-Charging-Vector Header
3.4.7. P-Media-Authorization Header
3.4.8. P-Preferred-Identity Header
3.4.9. P-Visited-Network-ID Header
3.4.10. Path Header
3.4.11. Security-Client Header
3.4.12. Security-Server Header
3.4.13. Security-Verify Header
3.4.14. Service-Route Header

4. The IP Multimedia Subsystem Architecture
4.1. Home Subscriber Server
4.1.1. Private User Identity
4.1.2. Public User Identity
4.2. Subscription Locator Function
4.3. Application Server
4.4. Media Gateway Control Function
4.5. IP Multimedia Subsystem Media Gateway
4.6. Signaling Gateway
4.7. Multimedia Resource Function
4.7.1. Multimedia Resource Function Controller
4.7.2. Multimedia Resource Function Processor
4.8. Breakout Gateway Control Function
4.9. IMS Application Layer Gateway
4.10. Transition Gateway

5. The Call Session Control Function
5.1. Proxy Call Session Control Function
5.1.1. P-CSCF Discovery
5.1.2. Discovery of I-CSCF in Home Network Domain
5.1.3. Confidentiality and Integrity Protection of SIP Signaling
5.1.4. Signaling Compression
5.1.5. Treatment for SIP Dialogs and Transactions
5.1.6. Bearer Authorization & Quality of Service Management
5.1.7. Subscription to reg event state at the S-CSCF
5.1.8. Charging
5.1.9. Emergency Services
5.2. Interrogating Call Session Control Function
5.2.1. User Location Query Procedure
5.2.2. User Registration Status Query
5.2.3. S-CSCF Assignment during IMS Registration
5.2.4. Topology Hiding Inter-network Gateway
5.2.5. Network Domain Security
5.2.6. IMS-Application Layer Gateway
5.2.7. Charging
5.3. Service Call Session Control Function
5.3.1. Subscriber Authentication
5.3.2. S-CSCF Registration Notification
5.3.3. Notification Server for “reg”-event
5.3.4. Treatment for SIP Dialogs and Transactions
5.3.5. Charging
5.3.6. Timer Supervision

II IMPLEMENTATION

6. Testbed Specification
6.1. Introduction
6.2. Architecture
6.3. Hardware and Software Components
6.4. Open Source IMS Core

7. Open IMS Core Installation
7.1. Prerequisites
7.2. SIP Express Router
7.3. Fraunhofer HSS

8. Open IMS Core Configuration
8.1. Domain Name Service
8.2. Proxy Call Session Control Function
8.3. Interrogating Call Session Control Function
8.4. Serving Call Session Control Function
8.5. Home Subscriber Server
8.6. User Endpoints
8.6.1. Snom Phone
8.6.2. eyeBeam Software Client
8.6.3. SIPp performance testing tool

9. The Open IMS Core CSCF Modules
9.1. The Proxy CSCF Module
9.1.1. REGISTER Request
9.1.2. REGISTER Response
9.1.3. NOTIFY Request
9.1.4. Mobile-Originating Request
9.1.5. Mobile-Terminating Request
9.2. The Interrogating CSCF Module
9.2.1. REGISTER Request
9.2.2. Initial Request
9.3. The Serving CSCF Module
9.3.1. REGISTER Request
9.3.2. SUBSCRIBE reg event Request
9.3.3. Mobile-Originating Request
9.3.4. Mobile-Terminating Request

III DISCUSSION

10. Conclusions

11. Future Work

IV APPENDICES

A. List of Figures

B. Abbreviations

C. References

D. Code Samples
D.1 P-CSCF
D.2 I-CSCF
D.3 S-CSCF
D.4 SIPp

Abstract

Given the increasing penetration of Internet Protocol (IP) technologies and the tremendous growth in wireless data traffic, the telecom industry is evolving towards All-IP based Next Generation Networks (NGN). The Third Generation Partnership Project (3GPP) has specified an IP Multimedia Subsystem (IMS) in 3GPP Release 5 to support converged multimedia applications across both wireless and wireline devices. IMS provides full packet call control capabilities by using the Session Initiation Protocol (SIP). SIP has been chosen by 3GPP as the signaling protocol to handle user registrations and multimedia session management in the IMS. Using IP protocols defined by the Internet Engineering Task Force (IETF), IMS will merge cellular networks and the internet, offering new service capabilities for rapid service creation and deployment of integrated IP multimedia applications.

This diploma thesis provides an insight into the IP Multimedia Core Network, specifically focusing on its key element, the Call Session Control Function (CSCF). The CSCF serves as control point to manage all IMS sessions in the network, whether they are voice, video, data, messaging, gaming, or any other service. Moreover, this paper discusses the requirements identified by 3GPP to support SIP in cellular networks, and the extensions to the SIP protocol suite in order to fulfill them.

The practical part of the thesis evaluates the Open Source IMS Core platform of the Fraunhofer Institute FOKUS with respect to the CSCF which is based on the SIP Express Router (SER). The analysis describes the new modules and advanced functions of SER, required to cope with the extended version of SIP and to act as a CSCF for IMS purposes.

Kurzfassung

Die zunehmende Penetration von Internet Protocol (IP) Technologien und der wachsende Datenverkehr in Mobilfunknetzen veranlasst die Telekommunikationsindustrie, sich in Richtung rein IP-basierter „Next Generation Networks (NGN)“ zu entwickeln. Das „Third Generation Partnership Project (3GPP)“ spezifizierte in 3GPP Release 5 das „IP Multimedia Subsystem (IMS)“, um konvergente Multimedia-Applikationen über mobile und stationäre Endgeräte anzubieten. IMS erlaubt die Steuerung und Kontrolle der Datenpakete aufgrund der Verwendung von „Session Initiation Protocol (SIP)“. SIP wurde von 3GPP als Signalisierungsprotokoll für Teilnehmer Registrierungen und dem Management von Multimedia Sessions im IMS ausgewählt. Der Einsatz von IP Protokollen der „Internet Engineering Task Force (IETF)“ wird IMS zellbasierte Netzwerke und das Internet verschmelzen. Dies ermöglicht Internet Service Plattformen, den IMS Betreibern integrierte IP Multimedia Applikationen zur Verfügung zu stellen. Immer mehr neue, innovative Dienste werden so in kürzerer Entwicklungszeit angeboten werden.

Diese Diplomarbeit bietet einen Einblick in das „IP Multimedia Core Network“, mit speziellen Fokus auf dessen zentraler Funktion, die Call Session Control Function (CSCF). Die CSCF fungiert als Kontrollpunkt, um alle IMS Sessions im Netzwerk zu überwachen - unabhängig davon, ob diese Sprache, Video, Nachrichtenaustausch, Onlinespiele oder ein anderes Service verwenden. Darüber hinaus werden in der Arbeit die 3GPP Anforderungen zum Einsatz von SIP in zellularen Netzwerken behandelt, sowie die entsprechenden SIP-Erweiterungen, um die 3GPP Voraussetzungen zu erfüllen.

Der praktische Teil dieser Diplomarbeit evaluiert die Open Source IMS Core Plattform des Fraunhofer Instituts FOKUS in Hinblick auf die CSCF, welche auf dem SIP Express Router (SER) basiert. Die Analyse beschreibt die neuen Module und weiterentwickelte Funktionen des SER, die erforderlich wurden, um die erweiterte Version von SIP zu unterstützen und somit als CSCF für IMS Zwecke zu fungieren.

1. Purpose of this Thesis

Modern information society offers enormous opportunities to enrich everyone's life. We can communicate with the other side of the world almost as easily as we speak to our next-door neighbor. Our children take for granted what their PC or mobile phone will do. New technology is affecting our work, our leisure time, and our entertainment needs. Today, communication services can be delivered over multiple technology platforms and received via a range of terminals using fixed and mobile, terrestrial and satellite systems. With this increasing convergence and integration, it is expected that the telecommunications services of the future will be delivered seamlessly over the most appropriate access network, with users roaming between domains and networks unaware of the underlying mechanisms that enable them to do so.

Next Generation Networks (NGN) define the new network model which is based on the extensive use of Internet Protocols (IP). These, in turn, are designed to accommodate the diversity of applications inherent in emerging broadband technologies. NGNs consist of a shared core network for all access and service types, packet-based transport technologies, open standardized interfaces between the different network layers (transport, control and services), support for user adaptable interfaces and variable access network capacity and type. The common packet core network communicates in the same IP language with any of the proliferating access technologies. The “last-mile” access technologies (Wi-Fi, WiMAX, cellular, DSL, cable, etc.) are like access ramps, all of which lead to the same highway.

This diploma thesis focuses on the IP Multimedia Subsystem (IMS), considered THE universal Service Delivery Platform for NGNs, which also supports Fixed Mobile Convergence (FMC). IMS should mainly be considered a service enabler, signifying that no real IMS services are standardized. For the development of services, the Open Services Architecture¹ has been standardized to open the business to third party organizations. The overall objective of the thesis is to evaluate the Open Source IMS Core (OSIMS) [64] platform of the Fraunhofer Institute FOKUS and to analyze IMS specific modules and functions of the SIP Express Router (SER) [66] to act as a CSCF.

2. Introduction

This diploma thesis is divided into five main parts: Part “I UNDERSTANDING IMS” covers the theoretical background of the new technology. Section “II IMPLEMENTATION” shows how IMS works in practice, and part “III DISCUSSION” summarizes the results of the thesis. Section “IV APPENDICES” includes a list of figures, references and the detailed configuration files from the testbed implementation in the thesis.

Chapter “3. Principles” provides an overview of the history of IMS, its requirements and the relevant organizations driving the development of (new) specifications. Also, certain extensions to the SIP protocol needed for use in an IMS environment are discussed.

Section “4. The IP Multimedia Subsystem Architecture” describes the actual concept of IMS by giving an overview about the functional entities of the IP Multimedia (IM) Core Network (CN). The emphasis of this thesis is on the Call Session Control Functions (CSCF). Most of the technical information in this thesis is based on literature from 3GPP Technical Specifications (TS)² and IETF documents in form Request For Comments (RFC)³.

The second part of the thesis deals with IMS in practice by implementing the Open Source IMS Core project⁴ of the Fraunhofer Institute FOKUS [64].

Chapter 6 covers the planning of the Open IMS Core test environment and relevant considerations to build up the infrastructure. It describes the Open IMS Core implementation itself, i.e. specifying the hardware and software components used and relevant requirements to be considered before installing the platform.

Chapter “7. Open IMS Core Installation” describes the installation process of Open IMS Core and depending software packages, while the subsequent Chapter “8. Open IMS Core Configuration” explains the setup of the relevant components in the environment..

The main part of the implementation is discussed in chapter “9. The Open IMS Core CSCF Modules”, which describe the IMS specific modules of the SER and which address aspects such as how the internal routing logic of the CSCF, is implemented.

Finally, part “III DISCUSSION“ contains the conclusions drawn from the evaluation of the testbed implementation, as well as an outlook for any future work. It informs about the results of the implementation and provides a summary by the author about the experiences gained from the Open IMS Core platform.

I UNDERSTANDINGIMS

3. Principles of the IP Multimedia Subsystem

3.1. What is the IP Multimedia Subsystem?

With the rapid growth of mobile communications and broadband technologies, it is becoming increasingly apparent that fixed and mobile telecommunications are likely to converge on technically similar core network and service platforms. The Internet Protocol Multimedia Subsystem (IMS) is an internationally standardized service delivery framework that enables operators to deploy new real-time and multimedia applications using the Session Initiation Protocol (SIP) (RFC 3261 [26]) for signaling over an IP network. IMS was developed by the Third Generation Partnership Project⁵ (3GPP) in collaboration with the Internet Engineering Task Force⁶ (IETF). IMS is IP end-to-end, so that advanced applications and services can be supported seamlessly across all networks. Since SIP-based IMS is at the heart of both 3GPP (GSM evolved) and 3GPP2 (CDMA evolved) networks, it thus represents a global view - which means that tomorrow’s entire multimedia mobile world is likely to be IMS-based. IMS is the technology that will merge the internet with the cellular world. It combines the quality and interoperability of telecoms with the quick and innovative development of the internet. There is no doubt that IMS will become the common technology dominator for converged fixed, mobile and cable networks for providing seamless triple and quadruple play services.

SIP is also at the heart of the internet, particularly for the support of interactive multimedia sessions, and offers inherently advanced features such as Presence Management, Instant Messaging and Group Communications Management. Therefore, there is an obvious economic benefit to be gained in creating a truly converged mass market based on IMS platforms, with potentially enormous economies of scale.

3.2. IMS Specification Bodies: 3GPP and IETF

3GPP is a collaboration agreement formed in 1998 to produce international specifications for third-generation wireless networks. The IMS was designed for delivering IP multimedia services to end users. It is part of the evolution of the core network infrastructure beyond GSM from its circuit-switched (CS) and voice-centric infrastructure towards an All-IP based network backbone providing multimedia services to subscribers across roaming boundaries and over multiple access technologies. To facilitate the integration with the internet, 3GPP specified in IMS to use as far as possible IETF protocols such as SIP. The focus is not to standardize applications within the IMS, but rather to provide the access to multimedia applications across wireless and wireline terminals, i.e. a form of Fixed Mobile Convergence (FMC).

illustration not visible in this excerpt

Fig. 1: 3GPP Releases

Fig. 1 gives an overview of 3GPP specifications that are grouped into different Releases [60]. Initially, IMS was known as All-IP and should be part of Release 4. But the development of IMS could not be completed so 3GPP decided to shift it to Release 5. In 3GPP R4 the MSC Server Gateway concept was introduced and IP as transport protocol within the core network was defined.

The IMS architecture was first introduced in 3GPP Release 5. The functional content was frozen in March 2002 so many features were postponed to 3GPP Release 6.

3GPP Release 6 fixes shortcomings of Release 5 but also defines new features to the IMS. The interworking to the CS Domain and other packet networks was introduced. IMS was extended to support WLAN and Unlicensed Mobile Access (UMA) as access networks.

3GPP Release 7 enhances IMS in terms of allowing fixed broadband access (TISPAN), End-to-end Quality of Service (QoS), packet switched emergency calls over IMS, Voice Call Continuity (VCC), and Policy Control Evolution and Charging.

3.3. High Level Requirements

The high-level service requirements are defined in 3GPP TS 22.228 [3] and include the following functions to be supported for IP multimedia applications:

- Negotiation of QoS and Service Capabilities
- Roaming
- Operator Policy Control for IP multimedia applications
- Interworking with CS networks, i.e. Public Switched Telephone Network (PSTN)
- Support for legacy networks (USIM)
- Multimedia sessions supporting different media types (e.g. audio, video)
- Topology Hiding Inter-network Gateway (THIG)
- Secure Communication
- Charging
- IP-Connectivity Access Network (CAN) Access Independence (3GPP R6)
- Emergency Services (3GPP R7)

3.3.1. Differences to RFC 3261 SIP

Initially, IMS was designed based on RFC 3261 [26]. The CSCF is basically also a SIP server. But the specification of IMS includes much more. Additional functions were added to the IMS and defined in the IETF, such as:

- UPDATE (RFC 3311 [32])
- Preconditions (RFC 4032 [54])
- PRACK (RFC 3262 [27])
- Offer/Answer (RFC 3264 [29])
- QoS/Media Authorization (RFC 3313 [33])
- Event Notification (RFC 3265 [30])
- Tel-URIs (RFC 3966 [51])
- 3GPP P-Headers (Ö 3.4 Private Header Extensions to SIP for 3GPP)
- Service-Route (RFC 3608 [48]) and Path header (RFC 3327 [39])
- Asserted ID (RFC 3325 [38])
· DNS-Support (RFC 3263 [28]) and ENUM (RFC 3761 [50])
- SigComp (RFC 3320 [35], RFC 3485 [44], RFC 3486 [45])
- Security-Mechanism-Agreement (RFC 3329 [40]) and Digest AKA (RFC 3310 [31])

3.3.2. Registration

The registration of an IMS user is needed in order to authenticate the subscriber once against the network. The lifetime of the registration will be valid for a pre-determined time value and must be refreshed before it expires. The re-authentication is depending on the operator’s security policy. Once the user is registered to the IMS, the P-CSCF and the User Endpoint (UE) will communicate over a secure channel that is protected by Security Associations (SA). Chapter “5.1.3.1. Security Association Establishment during IMS Registration” describes this procedure in more detail.

The key benefit of this mechanism is that there will not be any further authentication for dialog-initiating or standalone requests of the user because the authentication was already performed during the registration.

3.3.3. Session Setup & Control

After the user is registered and authenticated within the IMS he or she is ready to establish a multimedia session with another user. The session setup is needed to negotiate the capabilities between the two endpoints such as session components (e.g. audio, video), codecs (e.g. Adaptive Multi Rate, H.263), port numbers etc.

Within the IP Multimedia (IM) Core Network (CN), the relevant CSCF involved in the session setup will reserve network resources by validation of QoS preconditions. The IMS will then determine where to route the session setup request, e.g. either to another IMS subscriber or towards the Breakout Gateway Control Function (BGCF) in case the B-Party belongs to the PSTN / CS-domain.

The IMS is able to control services for its users. In case that predefined Filter Criteria match the request of a users (i.e. the calling and/or the called user), the S-CSCF in the home network may invoke Application Servers to trigger the execution of originating- and/or terminating IMS services.

3.4. Private Header Extensions to SIP for 3GPP

SIP has been selected by 3GPP as the protocol used to establish, modify and tear down multimedia sessions in IMS. Although SIP almost satisfies the functionality needed there are some additional requirements (RFC 4083 [55]) for SIP to completely cover IMS capabilities. The result was that a set of private SIP headers have been defined in RFC 3455 [43] to address those requirements.

3.4.1. P-Access-Network-Info Header

This section describes the P-Access-Network-Info header. This header is useful in SIP-based networks that also provide layer 2/3 connectivity through different access technologies. SIP User Agents (UA) may use this header to relay information about the access technology to proxies that are providing services. The serving proxy may then use this information to optimize services for the User Agent. For example, a 3GPP UE may use this header to pass information about the access network such as radio access technology and radio cell identity to its home service provider.

Some services are more or less suitable depending on the access type, and some services are of more value to subscribers if the access network details are known by the SIP proxy which provides the user with services.

A proxy that provides services to the user, the proxy typically located in the home network, and therefore trusted, must delete the header when the SIP signaling is forwarded to a SIP server located in a non-trusted administrative network domain. The SIP server providing services to the UA uses the access network information that is of no interest to other proxies located in different administrative domains. RFC 3455 [43]

Location Based Services (LBS) can be offered based on the P-Access-Network-Info header, e.g. to provide information customers with information about the nearest restaurant or petrol station. Some regulatory requirements exist mandating whenever an emergency call is established the radio cell identity is made available to emergency authorities.

illustration not visible in this excerpt

Fig. 2: P-Access-Network-Info header

3.4.2. P-Asserted-Identity Header

The IM CN subsystem defines a trust domain that consists of the functional entities that belong to the same operator’s domain (P-CSCF, I-CSCF, S-CSCF, BGCF, MGCF, MRFC and ASs that are not provided by 3rd party service providers). SIP functional entities that belong to a network for which there is an interconnect agreement are also part of the trust domain. A trust domain means theses nodes are trusted to exchange network asserted identity information.

Once the user is authenticated, the P-CSCF will use the P-Asserted-Identity header to assert the identity of the user (Ö Fig. 3). The other nodes in the trust domain will trust SIP messages with this header. This anticipates that they do not have to authenticate the user again. The P-Asserted-Identity header must be removed when SIP signaling crosses the boundary of the trust domain, i.e. the request is forwarded to a non-trusted domain entity. RFC 3325 [38]

illustration not visible in this excerpt

Fig. 3: P-CSCF asserts identity of the UE towards the Trust Domain

illustration not visible in this excerpt

Fig. 4: P-Asserted-Identity header

3.4.3. P-Associated-URI Header

This extension is used by the registrar (i.e. the S-CSCF) to return a set of associated Uniform Resource Identifiers (URI) for a registered address-of-record (AoR) in the 200 (OK) response to a REGISTER request. The header field value contains a comma-separated list containing zero or more SIP or SIPS URIs associated to the address-of-record. RFC 3455 [43]

illustration not visible in this excerpt

Fig. 5: P-Associated-URI header

3.4.4. P-Called-Party-ID Header

In IMS, users may get one or several SIP URIs (i.e. address-of-records) to identify the users. For instance, a user may use a business SIP URI that is used for communication with co­workers and a personal SIP URI that he makes available for family members. When the user registers within the IMS CN both IMS subscriptions are active and may receive incoming session requests. The user should now be aware of which of the several registered SIP URIs the request was sent to.

Typically, the S-CSCF inserts the P-Called-Party-ID header prior to retargeting the Request-URI in the SIP request. The header value is populated with the contents of Request-URI, prior to replacing it with the Contact address. RFC 3455 [43]

illustration not visible in this excerpt

Fig. 6: P-Called-Party-ID header

3.4.5. P-Charging-Function-Addresses Header

Each IM CN entity involved in a transaction needs to be informed about the common charging functional entities to receive the generated charging records or charging events. The solution provided by 3GPP is to define two types of charging functional entities: Charging Collection Function (CCF) and Event Charging Function (ECF). CCF is used for off-line charging (e.g., for postpaid account charging). ECF is used for on-line charging (e.g., for pre-paid account charging).

As described in chapter “5.3.5. Charging”, the S-CSCF will include the P-Charging-Function-Addresses header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. Only one instance of the header must be present in a particular request or response. The header value contains one or more parameters that contain the hostnames or IP addresses of the nodes that are willing to receive charging information.

The P-Charging-Function-Addresses header is applicable within a single private administrative domain where coordination of charging is required. If the next hop for the message is within the administrative domain of the proxy, then the proxy should include the P-Charging-Function-Addresses header in the outbound message. However, if the next hop for the message is outside the administrative domain of the proxy, then the proxy must remove the P-Charging-Function-Addresses header. RFC 3455 [43]

illustration not visible in this excerpt

Fig. 7: P-Charging-Function-Addresses header

3.4.6. P-Charging-Vector Header

A charging vector is defined as a collection of charging information, correlating charging records generated from different entities that are related to the same session. The charging vector may be filled in during the establishment of a dialog or standalone transaction outside a dialog. The information inside the charging vector may be filled in by multiple network entities (including SIP proxies) and retrieved by multiple network entities. There are three types of correlation information to be transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifiers (IOI).

ICID is a charging value that identifies a dialog or a transaction outside a dialog. It is used to correlate charging records. The ICID must be a globally unique value and is generated by the first proxy (i.e. the originating P-CSCF) processing the initial request for a dialog.

The IOI identifies both the originating and terminating networks involved in a SIP dialog or transaction outside a dialog. There may an IOI generated from each side of the dialog to identify the network associated with each side.

A proxy may include the P-Charging-Vector header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. Only one instance of the header must be present in a particular request or response.

The P-Charging-Vector header is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains. If the next hop for the message is within the trusted domain, then the proxy should include the P-Charging-Vector header in the outbound message. If the next hop for the message is outside the trusted domain, then the proxy may remove the P-Charging-Function-Addresses header. RFC 3455 [43]

illustration not visible in this excerpt

Fig. 8: P-Charging-Vector header

3.4.7. P-Media-Authorization Header

The P-Media-Authorization header was defined as an extension to SIP to support a media authorization scheme. In this architecture, a QoS enabled SIP proxy (i.e. the P-CSCF) supplies the UA with one or more authorization tokens which are to be used in QoS requests. This SIP extension allows network QoS resources to be authorized by the QoS enabled SIP proxy.

The P-Media-Authorization header field contains one or more media authorization tokens which are to be included in subsequent resource reservations for the media flows associated with the session. The media authorization tokens are used for authorizing QoS for the media stream(s). The P-Media-Authorization header field can be used only in SIP requests or responses that can carry a SIP offer or answer. RFC 3313 [33]

illustration not visible in this excerpt

Fig. 9: P-Media-Authorization header

3.4.8. P-Preferred-Identity Header

The P-Preferred-Identity header field is used in SIP messages from the User Agent to a trusted proxy. It carries the identity the originating user wishes to be used for the P-Asserted-Header field value. RFC 3325 [38]

This header is optional and when present, it should include a registered Public User Identity of the user. The P-CSCF will check whether the URI in the header is a currently registered Public User Identity of the user who sent the request. If the URI is valid the P-CSCF will replace the Preferred-Identity header with a P-Asserted-Identity header that includes the same content. (Ö 3.4.2 P-Asserted-Identity Header)

In case the URI in the Preferred-Identity header is currently not registered for that user, or if there is no Preferred-Identity header included in the request, the P-CSCF will add a P-Asserted-Identity header that contains the default Public User Identity of the user.

illustration not visible in this excerpt

Fig. 10: P-Preferred-Identity header

3.4.9. P-Visited-Network-ID Header

3GPP networks are composed of so called home networks and visited networks. An operator of a home network may have roaming agreements with one or more visited networks. 3GPP User Agents always register in their home network. In case of an existing roaming agreement the User Endpoint can use resources provided by the visited network.

REGISTER requests or any other dialog-initiating requests (e.g. INVITE) traverse one or more proxies located in the visited network towards the home network. The visited network includes the P-Visited-Network-ID header that globally unique identifies the administrative domain of the visited network. The home network may use this identification to verify the existence of a roaming agreement with the visited network, and to authorize the registration through that visited network. RFC 3455 [43]

P-Visited-Network-ID: "Visited Network Number 1"

Fig. 11: P-Visited-Network-ID header

3.4.10. Path Header

The introduction of the Path extension header is based on a 3GPP requirement for discovering intermediate proxies during SIP registration. Eventually, an inbound proxy (i.e. the S-CSCF serving as the terminal point for routing an address-of-record) will receive a request destined for a 3GPP UE. It needs to know which proxies must be transited by that request in order to get back to the IMS terminal.

The Path extension header field allows accumulating and transmitting the list of proxies between UE and S-CSCF. This mechanism is in many ways similar to the operation of Record-Route in dialog-initiating requests. The difference between Path and Record-Route is that Path applies to a REGISTER request and its 200 (OK) response. Record-Route does not, and can not be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs.

When a proxy processing a REGISTER request wishes to be on the path for future requests toward the UE originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost value in the Path header field (or inserts a new topmost Path header) before proxying that request.

The Path header field accumulates information in a hop-by-hop manner during REGISTER processing. The return information is essentially end-to-end, that is, it is not altered by intermediate proxies. The S-CSCF stores the Path header field value and uses the information to create a Route Header for terminating requests that will then be forwarded to the indicated (terminating) P-CSCF. RFC 3327 [39]

illustration not visible in this excerpt

Fig. 12: Path header

3.4.11. Security-Client Header

The Security-Client header extension is described in chapter “5.1.3.1. Security Association Establishment during IMS Registration”.

illustration not visible in this excerpt

Fig. 13: Security-Client header

3.4.12. Security-Server Header

The Security-Server header extension is described in chapter “5.1.3.1. Security Association Establishment during IMS Registration”.

illustration not visible in this excerpt

Fig. 14: Security-Server header

3.4.13. Security-Verify Header

The Security-Verify header extension is described in chapter “5.1.3.1. Security Association Establishment during IMS Registration”.

illustration not visible in this excerpt

Fig. 15: Security-Verify header

3.4.14. Service-Route Header

3GPP networks dynamically assign a service proxy from the home network domain (i.e. the S-CSCF) to each IMS user. During the registration procedure of the UE, the registrar will return the SIP URI of the S-CSCF in the new defined Service-Route header field (Ö Fig. 16) of the 200 (OK) response to each successful REGISTER request. The new header can contain a route vector with zero or more entries. The values are stored by the UE as a “preloaded route” that will be inserted into the Route header of future initial requests. In case there is more than one Service-Route header field or header field value the UE must preserve the order, specified as top-down, meaning the topmost entry will be visited first.

The Service-Route header will force each initial request from the UE to pass the S-CSCF that has been allocated during the registration of this user. The S-CSCF may then provide outbound services as described in chapter “5.3.4.1. Mobile-Originating”. So the routing established by the Service-Route mechanism applies only to mobile-originated requests from the IMS terminal, and not to mobile-terminated requests. RFC 3608 [48]

illustration not visible in this excerpt

Fig. 16: Service-Route header

4. The IP Multimedia Subsystem Architecture

The service requirements of the 3GPP IMS are specified in 3GPP TS 22.228 [3]. The technical details are described in 3GPP TS 23.228 [10]. The IMS provides all the network entities and procedures to support real-time voice and multimedia IP applications. It uses SIP to support signaling and session control for real-time services. 3GPP did not specify nodes but specific functions. These functional entities can be implemented in different equipments or gathered. In any case, exchanges of data occur between these entities over the standardized interfaces. The modular architecture allows IMS operators to leverage each element in the network across many services. The functional separation of components is a key factor that supports rapid and flexible network growth and scalability. IMS takes the concept of layered architecture one step further by defining a horizontal architecture, having a control layer that isolates the access network from the service layer (Ö Fig. 17). This facilitates for the operator to provide multiple services to the user and maximizing equipment re-use through horizontal layers. The horizontal structure provides common supervision and control of services in the IMS network, management and routing of sessions, as well as supporting the authorization and manipulation of media in the network.

illustration not visible in this excerpt

Fig. 17: Horizontal Layered Architecture in IMS (3GPP Release 5)

4.1. Home Subscriber Server

The Home Subscriber Server (HSS) is the central database that maintains all subscriber and service-related data of the IMS. It contains all permanent subscriber data and all relevant temporary subscriber data to support the call control and session management entities of the different domains and subsystems.

The HSS manages subscriber identification and authentication, access authorization, mobility management (i.e. keeping track of which session control entity is serving the user), fraud prevention, billing and the IMS session establishment. It has a Diameter Cx-interface towards the CSCF. When a user registers in the IMS domain, the user profile is downloaded from the HSS to the CSCF. For session establishment, the HSS provides information on which CSCF currently serves the user. Furthermore, the HSS holds relevant data for provisioning and authorization of IMS application services. For backwards compatibility with legacy networks, the HSS provides Home Location Register and Authentication Center (HLR/AUC) functionality to support network architectures prior to 3GPP Release 5, i.e. Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) as entities of packet-switched (PS) domains and Mobile Switching Centre (MSC) of circuit-switched (CS) domains.

3GPP TS 23.228 [10] defines two types of entities that may be associated with an IMS user. Network operators assign one (or more) Public User Identity and a Private User Identity to each IMS subscriber. This allows each subscriber to register multiple users for individual purposes, e.g. a subscriber may have a SIP URI for business communication with co­workers and a personal SIP URI available for family members while both identities are associated with the same Private User Identity and using only one terminal for multiple accounts.

As illustrated in Fig. 18, Public User Identities may be shared across multiple Private User Identities within the same IMS subscription. Hence, a particular Public User Identity may be simultaneously registered from multiple UEs that use different Private User Identities and different contact addresses (i.e. IMS terminals).

The HSS may hold information about an implicitly registered Public User Identity set. This is a set of Public User Identities, which are registered and de-registered simultaneously when any of the Public User Identities belonging to that set is registered or de-registered. The P- CSCF is informed about implicitly registered Public User Identities after the subscription to the registration-state information of the user. This procedure is described in chapter “5.1.7. Subscription to reg event state at the S-CSCF”.

illustration not visible in this excerpt

Fig. 18: Shared Public User Identities (3GPP Release 6)

4.1.1. Private User Identity

The IM Private User Identity (IMPI) is a unique global identity defined by the home network operator. It is used for identification of user subscriptions and for authentication purposes. The HSS and the IM Services Identity Module (ISIM) share a long-term key associated with the IMPI. The functionality is similar to those of an International Mobile Subscriber Identity (IMSI) in GSM/UMTS. The subscriber does not need to know the Private User Identity which is securely stored on the ISIM application.

The Private User Identity represents permanent subscriber data and is stored in HSS and S-CSCF. It is not used for routing, but is included in all registration requests, authentication procedures, as well as in Charging Data Records (CDR).

The identity has the form of a Network Access Identifier (NAI), i.e. username@realm. The realm part identifies the home network domain of the subscriber. 3GPP TS 23.003 [5]

illustration not visible in this excerpt

Example: user@ims-network.com RFC 4282 [58]

4.1.2. Public User Identity

Each IMS user has one (or more) IM Public User Identity (IMPU). This identity is used to communicate with other users. As IMS is independent from the access network the Public User Identity may have different formats. For instance, when a PSTN user wants to call an IMS subscriber he can only dial digits so the Private User Identity has to be compliant to E.164 numbers. For internet sessions it must conform to internet naming, i.e. the representation in an URI format. In IMS, Public User Identities are used for routing purposes. This is similar to the Mobile Subscriber ISDN Number (MSISDN) in GSM/UMTS.

Public User Identities take the form of either a SIP Uniform Resource Identifier (URI) “sip:user@domain” or a telephone URI format “tel:<e.164 number>”. A tel URI can also be converted to a SIP URI by placing the entire telephone-subscriber portion of the tel URI into the userinfo part of the SIP URI. 3GPP TS 23.003 [5]

Example: sip:user@ims-network.com RFC 3261 [26]

illustration not visible in this excerpt

tel:+436761234567 RFC 3966 [51]

4.2. Subscription Locator Function

Depending on the size of the IMS network and the number of subscribers there may be multiple HSS but a specific subscriber can only be handled by a single HSS. When more than one HSS is deployed in the network, a Subscriber Location Function (SLF) is needed to locate the HSS that holds the subscription data for a given user. The SLF contains a Diameter redirect agent functionality so whenever the SLF receives a query with a given user address it will return the related HSS where all its subscriber data are stored. 3GPP TS 23.228 [10]

4.3. Application Server

SIP Application Servers (AS) may host and execute services in order to influence and impact the IMS session on behalf of the services. There are 3 types of Application Servers as specified in 3GPP TS 23.002 [4]:

- SIP Application Server;
- CAMEL IP Multimedia Service Switching Function (IM-SSF);
- Open Service Access (OSA) Application Server

They all interface the S-CSCF via the IMS Service Control Interface (ISC) which is based on the SIP protocol, and the HSS over the Sh/Si-interface using the Diameter protocol (RFC 3588 [47]). Application Servers reside in the operators’ home network or in a third-party location. They may operate as a SIP User Agent or SIP B2BUA as specified in RFC 3261 [26].

4.4. Media Gateway Control Function

The Media Gateway Control Function (MGCF) takes care of the signaling conversion between SIP and ISDN User Part (ISUP) / Bearer Independent Call Control (BICC), in case of voice calls to and from destinations within the PSTN or the circuit-switched domain in general. In addition, the MGCF controls the entire behavior and processing of one (or more) IMS-Media Gateway(s), using the H.248/MEGACO protocol (RFC 3525 [46]) for this purpose. 3GPP TS 23.002 [4], 3GPP TS 24.229 [13]

4.5. IP Multimedia Subsystem Media Gateway

The IMS-Media Gateway (IMS-MGW) is responsible for interworking with the PSTN and the CS domain in the user plane. It may terminate bearer channels from a circuit switched network and media streams from a packet network (e.g., RTP streams in an IP network). The IMS-MGW may also support bearer control and media conversion, e.g. transcoding from Adaptive Multi Rate (AMR) in 3GPP based IMS networks to G.711 used in the PSTN. Every IMS-MGW is controlled by exactly one MGCF. 3GPP TS 23.002 [4]

4.6. Signaling Gateway

The Signaling Gateway (SGW) performs the signaling conversion (both ways) at transport level between legacy networks based on Signaling System No. 7 (SS7) Message Transfer Part (MTP), and the IP-based transport of signaling possibly used in networks using Stream Control Transmission Protocol (SCTP) over IP. It does not interpret the application layer (e.g. MAP, BICC, ISUP, etc.). 3GPP TS 23.002 [4]

4.7. Multimedia Resource Function

The architecture of the Multimedia Resource Function (MRF) is split into Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP). 3GPP TS 23.228 [10]

4.7.1. Multimedia Resource Function Controller

The Multimedia Resource Function Controller controls the media stream resources in the Multimedia Resource Function Processor. The Mp-interface to the MRFP is based on MEGACO. Towards the S-CSCF it acts as a SIP User Agent and uses the SIP protocol on the Mr-interface. The MRFC is needed to support bearer-related services such as conferencing, announcements or bearer transcoding. It is also able to perform accounting and generate CDRs. 3GPP TS 23.002 [4]

4.7.2. Multimedia Resource Function Processor

The Multimedia Resource Function Processor represents a source of media resources (e.g. tones, announcements) that are controlled by the MRFC. It may also operate as a mixer for data streams (e.g. audio) or perform floor control in case of conferences and multiparty sessions. In special cases of lawful interception, the MRFP may be added as an invisible User Agent to every session established by a user observed by legal authorities. 3GPP TS 23.002 [4]

4.8. Breakout Gateway Control Function

In case of an IMS originating session to the PSTN or CS domain, the Breakout Gateway Control Function (BGCF) selects the breakout point to the other domain. As a result of the selection, the breakout may happen in the same network in which the BGCF is located, or another network. In case of the same network the BGCF selects a suitable MGCF responsible for the interworking with the PSTN / CS domain as the next hop to handle the session further. If the breakout happens in another network, the BGCF has to identify the BGCF of the foreign network where the session is forwarded to. As the BGCF is in the signaling path of the session, it may also be used for billing purposes, i.e. generating CDRs for the session or provide statistics. 3GPP TS 23.002 [4], 3GPP TS 23.228 [10]

[...]

---

¹ http://www.parlay.org/

² http://www.3gpp.org/specs/numbering.htm

³ http://rfc-editor.org/

⁴ http://www.openims.org

⁵ http://www.3gpp.org/

⁶ http://www.ietf.org/