MARQUEZ LAYOUT
6/2/05
1:17 PM
Page 58
T O WA R D S E A M L E S S I N T E R N E T W O R K I N G O F W I R E L E S S LAN A N D C E L L U L A R N E T W O R K S
INTERWORKING OF IP MULTIMEDIA CORE NETWORKS BETWEEN 3GPP AND WLAN ’ MEZ RODRI’GUEZ, ÁGORA SYSTEMS, S. A. FERMI’N GALA’N MA’RQUEZ AND MIGUEL GO TOMA’S ROBLES VALLADARES AND TOMA’S DE MIGUEL, ENGINEERING TECHNICAL UNIVERSITY OF MADRID ’ NICA MO ’ VILES DE ESPAÑA, S. A. LUIS ÁNGEL GALINDO, TELEFO
UMTS charging and billing HSS
S-CSCF I-CSSCF P-CSCF
GGSN
The authors analyze how the interconnection of 3GPP and WLAN networks may be performed in order to support different levels of service interconnection.
This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.
58
ABSTRACT The 3GPP has specified the IP multimedia subsystem (IMS) for the provisioning of multimedia services in UMTS Release 5 and later. Interconnection at the service layer between 3GPP and LAN networks requires interworking between IMS and WLAN functionalities. Studying several interconnection scenarios and the main functionalities of IMS, this article analyzes how the interconnection of 3GPP and WLAN networks may be performed in order to support different levels of service interconnection. Special attention is paid to interconnection at the session negotiation level, using SIP (the base protocol of the IMS) to provide session negotiation with QoS and AAAC support.
real-time multimedia services in mobile networks. Interworking between SIP-based networks may present different problems caused by one of the main features of this protocol: extensibility. The SIP protocol used by the 3GPP has particular extensions that are not applicable to SIP as defined by the Internet Engineering Task Force (IETF). These differences will bring problems; most of them are presented in this article. The remainder of this article is organized as follows. We briefly describe the IMS architecture as defined by the 3GPP. We describe the main characteristics of SIP and WLAN, respectively. The interworking aspects are dealt with. Finally, we offer a discussion analyzing the problems identified in the previous sections and providing our main conclusions.
INTRODUCTION
IMS ARCHITECTURE FOR 3GPP NETWORKS
Mobile networks are evolving from traditional circuit-switched architectures to an “all-IP” paradigm. It is envisaged that these future mobile networks will be integrated by a high-bandwidth IP-based core network and a variety of heterogeneous wireless access technologies such as Universal Mobile Telecommunications System (UMTS) or wireless LAN (WLAN). Mobile terminals will be able to access bandwidth-demanding applications and advanced services while roaming across these different access technologies, and the wireless research community is investigating new ways to facilitate interworking between them. Thus, the Third Generation Partnership Project (3GPP) is developing a feasibility study on providing seamless service continuity between UMTS and WLAN [1]. Interworking can be seen from different points of view. However, the most important aspect is perhaps the session negotiation level, which provides service continuity from the user perspective. At this level, the protocol used by the 3GPP is Session Initiation Protocol (SIP) [2], which is the foundation of the IP multimedia subsystem (IMS) architecture defined to support
UMTS is being standardized by the 3GPP as the 3G system for Europe in several releases (Release 5 was finalized in June 2002, and Release 6 was frozen in 2004). Within the UMTS core network, the 3GPP defines the IMS as the component that must provide support for multimedia services (e.g., voice or video) based on packet switching with quality of service (QoS) and authenticaltion, authorization, and accounting (AAA) provisioning. Figure 1 shows a general view of the IMS architecture [3]. In this general architecture we may appreciate how the core network is organized in two networks: a signaling or control network and a data or transport network (based on General Packet Radio Service, GPRS). The signaling network is composed of a set of call session control function nodes (CSCFs). They are in essence signaling proxies whose task is to establish, modify, and release media sessions with guaranteed QoS and AAA and charging (AAAC) support. The tasks of the CSCFs include functionalities of SIP proxies, but are not limited to the above mentioned QoS and AAAC tasks. There are several types [4]: proxy
1536-1284/05/$20.00 © 2005 IEEE
IEEE Wireless Communications • June 2005
MARQUEZ LAYOUT
6/2/05
1:17 PM
Page 59
CSCF (P-CSCF, which acts on behalf of the mobile terminal in the IMS), serving CSCF (SCSCF, which implements user registration and session control), and interrogating CSCF (ICSCF, with proxy and topology hiding functions between operators). These proxies are defined as functional entities such that IMS implementations are free to combine or split such functionalities into different physical equipment. Other entities are the media gateway control function (MGCF), which interconnects with circuit-based networks through the corresponding IMS media gateway (IMS-MGW), and the media resource function controller (MRFC), which performs processing of media streams though the corresponding media resource function processor (MRFP). A key element of the UMTS network is the home subscriber server (HSS), similar to the home location register (HLR) in a GSM network: a centralized database that stores user authorization and profile information. In addition, application servers (ASs) can be connected to the IMS in order to provide advanced services. Note that user equipment (UE) gains access to the IMS via the UMTS terrestrial radio access network (UTRAN), which is responsible for providing access for mobile stations and managing terminal mobility (a detailed description of the UTRAN is beyond the scope of this article). SIP, COPS, and Diameter are the major protocols involved in this architecture, and will be introduced in the next section.
SIP BASIC FUNCTIONALITIES As can be seen in Fig. 1, SIP [2] is the core protocol chosen by the 3GPP to perform signaling tasks in the IMS. SIP is a general-purpose application layer protocol designed to establish, modify, and release sessions in IP networks. SIP is extensible: new methods and headers can be defined and easily integrated in the core protocol. Besides SIP, other protocols are used in the IMS for specific tasks, like Common Object Policy Service (COPS) [5], to perform local policybased admission control in the GPRS gateway support node (GGSN), Diameter to query HSS registry and to perform charging actions, and MEGACO/H.248 to control MRFP and IMSMGWs. These auxiliary protocols are coupled with SIP (messages in one protocol trigger messages in the other, and even some parameters are mapped from one to another). SIP is not a vertically integrated communications system. SIP is rather a component that needs to be used with other IETF protocols to build a complete multimedia architecture. Concerning QoS, SIP does not provide any specific support, and typical architectures include RealTime Transport Protocol (RTP) for real-time data transport, Real-Time Control Protocol (RTCP) to provide QoS feedback, and RealTime Streaming Protocol (RTSP) for streaming media delivery control. Finally, Session Description Protocol (SDP) [6] is used to describe sessions. SIP provides security services to prevent denial of service (DoS) attacks, authentication
IEEE Wireless Communications • June 2005
HSS Cx diameter
AS
Other operator IMS
I-CSCF P-CSCF
SIP
COPS Go
Gm
UTRAN
S-CSCF
MRFC
MGCF
H.248
H.248
Signaling network
Data network
MRFP IMS MGW
UE
GGSN
n Figure 1. UMTS-IMS general architecture. (both between two users and between user and proxy), integrity protection, and encryption and privacy of services. The basic security mechanism in SIP is based on the HTTP challenge–response model. This procedure may be used by a server for challenging a client or by the client for providing authentication information. Nevertheless, SIP is not an easy protocol to secure. The inclusion of intermediaries (proxies), its usage between elements with no trust relationship, and its end-to-end application do not facilitate the task of making it a secure protocol. SIP provides facilities to create, modify, and release multimedia sessions (conferences). It also allows inviting another participant to ongoing sessions. The protocol supports five basic aspects of multimedia sessions: user location, user availability, user capabilities, session negotiation and session management. SIP also supports transparent mapping of names and service addresses, which enables personal mobility. The base SIP specification defines several mechanisms through which the protocol can be extended. This allows designers to subsequently add new features, such as call transfer or message waiting indicator, as they become necessary. All SIP-compliant implementations need to support the core functionality, and then implement whichever feature extensions they intend to use. SIP can be extended in three major ways: • By defining new message body types • By defining new headers • By defining new message types These facilities have been used by 3GPP, as described later.
WLAN TECHNOLOGIES The WLAN objective is to provide functionality close to a LAN without fixed infrastructure using wireless radio technology. Although nowadays there are a wide range of WLAN systems (e.g., 802.11x IEEE standard, Bluetooth, HyperLAN, or WiMAX), the differences between them are mainly located in the physical and link layers (medium access technology, transmission frequencies, etc.); at the network layer they all transport IP datagrams and share the same basic
59
MARQUEZ LAYOUT
6/2/05
1:17 PM
WLANs are commonly used to transport IP packets. 3GPP WLAN interworking should thus be built on top of the IP Protocol, and not be limited to any specific WLAN technology.
Page 60
UMTS charging and billing HSS
WLAN
Signaling path Data path
WLAN access control
IMS S-CSCF Other IP multimedia networks
I-CSSCF
SIP proxy Access point
P-CSCF
GGSN
IP router
UTRAN
UE
n Figure 2. 3GPP- WLAN interworking reference model. characteristics. New services can be offered in WLAN environments (e.g., location-based or environment-aware services). There are two types of WLAN architectures: ad hoc and access-point-based. In the ad hoc architecture, the network is based on peerto-peer spontaneous associations between nodes, without using any additional infrastructure. Routing mechanisms enable packets to be sent between nodes with no need to provide direct connectivity. In the access-pointbased architecture, there is a special kind of node (the access point) that provides connection to the nodes within its range. Access points are interconnected, sometimes using a wired infrastructure. The main differences between WLAN and LAN technologies are due to the use of wireless transmission. Both kinds of technologies usually are able to interoperate. WLAN provides mobility to users, in the sense that they can change their location (even during an established data session) without breaking the connection or even changing the IP layer configuration. Several layers of mobility can be taken into consideration: picomobility (within the range of the same access point), micromobility (changing between access points, but within the same wireless network) and macromobility (beyond the range of the WLAN, requiring mobility mechanisms at upper levels, like Mobile IP). However, the wireless medium has some disadvantages. First, although throughput reached by WLANs is comparable to a usual LAN (up to tens of megabits per second with current systems), the provided QoS level (in terms of packet losses and bandwidth) is unstable and highly dependent on the transmission environment. Special QoS reservation mecha-
60
nisms that suit these problems need to be implemented. Second, the use of a broadcast medium that can be accessed by anyone with a convenient WLAN device implies a security risk higher than in other radio technologies (e.g., 3GPP UTRAN).
INTERWORKING MODEL AND SCENARIOS As described in the previous section, WLANs are commonly used to transport IP packets. 3GPP ⇔ WLAN interworking should thus be built on top of the IP Protocol, and not be limited to any specific WLAN technology. Figure 2 presents the interconnection reference model used in this article, showing the signaling and data interfaces between both networks. From the IMS interconnection point of view, only access-point-based WLANs make sense. The figure shows the I-CSCF proxy as the signaling entry point in the interconnection between IMS and WLAN, according to the 3GPP CSCF’s role definition in [4]. A generic interworking relationship is defined at [1] as a technical arrangement between two platforms for realizing the interworking functionality. This technical specification introduces five interconnection levels, described next.
INTERCONNECTION LEVELS Table 1 shows the five interconnections levels we take into consideration and the operational capabilities of each of them, based on the interconnection levels described in [1]. 3GPP has included the first three levels in Release 6, while the last two will be developed in future releases. In particular, the two first levels are addressed by the 3GPP in a specific document [7], paying special attention to basic
IEEE Wireless Communications • June 2005
MARQUEZ LAYOUT
6/2/05
1:17 PM
Levels:
Page 61
Service and operational capabilities:
Level 1: common billing and customer care
Level 2: 3GPP system-based access control and charging
Level 3: access to 3GPP system IMS-based services
Level 4: service continuity
Level 5: seamless services
Common billing
√
√
√
√
√
Common customer care
√
√
√
√
√
3GPP system-based access control
√
√
√
√
3GG system-based charging
√
√
√
√
√
√
√
√
√
Access to IMS services from WLAN Service continuity Seamless service continuity
√
n Table 1. Interconnection levels. UMTS AAAC issues. The first level is the simplest and includes common billing (the customer receives just one coordinated bill for usage of both 3GPP and WLAN services) and common customer care (the user will not have to bother about which platform has caused a need to consult customer service). The second level (3GPP system-based access control and charging) includes the usage of the 3GPP access procedures (including authentication and authorization) for WLAN users within the 3GPP domain. In addition, WLAN nodes use the UMTS charging systems for charging data records (CDR) generation. The third level extends the IMS services to the WLAN, although it is an implementation matter as to whether all services or just a subset of them are provided. This scenario lacks service continuity, so the user has to re-establish the session in the new access network. Continuity is considered in this context as the ability to maintain an active service session when moving from one access network to another (e.g., between WLAN and 3GPP UTRAN) at the signaling level, without considering transportlevel-related continuity issue like bandwidth or packet loss. The last two levels are not considered by the 3GPP in Release 6 and may be developed in future releases. The fourth level introduces service continuity, as described in the previous paragraph, although the handover process may be perceptible to the user (due to data losses or delays). The fifth scenario provides seamless continuity, with no noticeable service interruption greater than that perceived in intra-3GPP handovers. The need for seamless service provision could include transport-level-related issues in this level. The five levels are discussed in more detail later, when we describe the 3GPP SIP specific features and a comparison with standard IETF SIP.
IEEE Wireless Communications • June 2005
SIP 3GPP-IETF INTERWORKING As shown earlier, SIP is an extensible protocol. Due to this extensibility and the collaboration established between 3GPP and IETF, different extensions have been provided by the IETF upon request by the 3GPP in order to cover additional requirements imposed by IMS, not supported by SIP as defined in [2]. Although the aim of 3GPP is to incorporate Internet standards unchanged, the existing differences between mobile and fixed networks have necessitated additions or modifications such that the IETF specifications fulfill the needs of 3GPP. The development of this or any interworking standard is normally a lengthy process, so until such time as it is finished, engineering solutions that provided this interoperability are needed.
3GPP FUNCTIONALITIES In this subsection SIP extensions contained in the 3GPP specification will be analyzed. 3GPP extensions can be grouped into five categories: general, session operation, QoS, AAAC, and security. General Extensions — Due to policy control and service triggering, IMS requires that several CSCF proxies in the signaling path be traversed by all the SIP signaling messages. This requires a source-route facility, implemented by the SIP record-route basic mechanism and Path header extension. In addition, support for transparent roaming requires that the signaling path always be the same upon session establishment — even if proxies are located in different administrative domains. Finally, due to the scarce availability of bandwidth on radio interfaces, SIP compression (SigComp [8]) is used between UE and P-CSCF. Session Operation Extensions — Regarding localization, the P-Access-Network-Info SIP header [9]
61
MARQUEZ LAYOUT
6/2/05
1:17 PM
The IMS security goal is to provide integrity and confidentiality to signaling messages in a hop-by-hop basis between nodes. The key mechanism to achieve this purpose is the IPSec ESP. There should be no impact on SIP signaling; due to its nature as application layer protocol.
Page 62
is used to deliver the identity of the cell where the mobile user is accessing the network. Regarding user identification, each user has a private identity, used as an identifier from the network perspective, recorded in the IMS subscriber identity module (ISIM) of the mobile terminal and never provided to final users. One (or maybe several) public addresses (e.g., user@tme. es) can be used to establish communications between users. The SIP Authorization header fulfills the need for private identity delivery to the network during the registration process. There are other IMS functionalities related to user identification during session establishment (calling party identification, privacy solicitation, etc.) that impose additional requirements on SIP. Extension headers, like P-Asserted-Identity, have been introduced to fulfill them. QoS-Related Extensions — QoS negotiation between session peers (in order to determine which particular codec is used for each medium) is carried out using the SIP offer/answer model [10], in which each session peer offers its QoS capabilities using SDP [6] descriptions in the message body. The preconditions framework has to be used in order to avoid effective resource allocation before alerting the user (e.g., telephone ringing), reducing “ghost rings.” Note that SIP session signaling and effective QoS resource allocation (e.g., GPRS Packet Data Protocol, PDP, or diferentiated services, DiffServ) are independent. Filtering mechanisms based on SDP descriptions are possible, either local-policy-based (through the use of COPS [5]) or user-profile-based. AAAC Related Extensions — Since home networks must be able to validate the existence of roaming agreements when a user accesses from a visited network, the P-Visited-Network-ID SIP header [9] is provided, so the visited network identity is known during registration in the home network. In addition, SIP event notification [11] is used to allow the network to deregister users (e.g., due to maintenance operations or failure prevention) or force reregistration (e.g., due to charging thresholds) of mobile terminals. Regarding authorization, the P-Media-Authorization SIP header [12] is used on session establishment, in conjunction with COPS [5] between P-CSCF and GGSN (as shown in Fig. 1), to ensure resource control, avoiding unauthorized users using resources for which they are not paying. The AAAC Diameter protocol is used to record CDRs in the UMTS charging subsystem. In addition, the SIP P-Charging-Vector (to carry charging information) and P-Charging-FunctionAddress headers are used to distribute the IP addresses of the charging elements between IMS nodes [9]. Security Extensions — The IMS security goal is to provide integrity and confidentiality to signaling messages on a hop-by-hop basis between nodes. The key mechanism to achieve this purpose is the IPSec Encapsulated Security Payload (ESP) protocol [13]. There should be no impact on SIP
62
signaling due to its nature as an application-layer protocol. An additional security requirement is the provision of a topology hiding mechanism (THIG) for network operators that want to implement it. Hiding must include network structure and node IP addresses. This is performed with the I-CSCF acting as a SIP hiding proxy, obfuscating sensitive information.
COMPARISON Table 2 shows a comparison between basic SIP (as defined in [2]) and 3GPP SIP (SIP with the extensions that must be implemented according to 3GPP standards). Basic SIP capabilities were described earlier. Note that some IMS entities can take roles of either user agent (UA) or proxy (e.g., the S-CSCF behaves as a UA during registration and as a proxy in session establishment), while others are always UAs (e.g., the UE) or proxies (e.g., the I-CSCF).
DISCUSSION In this section we discuss how different interconnection levels may be reached using the IMS capabilities. SIP interworking in particular is analyzed, since it provides the basis for interworking IMS services between UMTS and WLAN according to the model of Fig. 2.
LEVEL 1: COMMON BILLING AND CUSTOMER CARE WLAN does not have a generally accepted charging model, but most of the charging approaches employed are based on the quantity of traffic exchanged during the session, while IMS charging and accounting is based on the services provided to the user. Both systems may work independently, unifying the charging into a single bill sent to the client. Customer care may also be centralized by administrative means with no technical implications on the networks.
LEVEL 2: 3GPP SYSTEM-BASED ACCESS CONTROL AND CHARGING At this level both such networks share the AAAC information of the UMTS networks by sharing the HSS and the charging and billing subsystem. No direct interworking regarding SIP negotiation occurs at this level, so there are no problems related to direct interworking between the SIP elements in both networks. 3GPP has taken the initiative to develop a cellular-WLAN interworking architecture as a complement to the existing 3GPP cellular system specification, described in 3GPP TS 23.234 [7]. This document defines two new procedures in the 3GPP system: • WLAN access, authentication, and authorization, which provides for access to the WLAN and the locally connected IP network to be authenticated and authorized through the 3GPP system • Access to external IP networks, which allows WLAN UEs to establish connectivity with external IP networks, such as 3G operator networks, corporate intranets, or the Internet, from a suitable IP network
IEEE Wireless Communications • June 2005
MARQUEZ LAYOUT
6/2/05
1:17 PM
Page 63
Basic SIP
3GPP SIP General features
End-to-end headers can be ciphered using S/MIME.
End-to-end headers cannot be ciphered using S/MIME, since intermediate proxies have to read them and act consequently.
S/MIME in order to cipher headers.
THIG in order to cipher header tokens.
End-to-end message bodies can be ciphered using S/MIME.
End-to-end message bodies can not be ciphered using S/MIME, since intermediate proxies have to read them (e.g., for SDP-based filtering) and act consequently.
UA–proxy authentication is optional.
UA–proxy authentication is forbidden. SIP transaction features
Proxies must not filter Record-Route or Route headers. In addition, record routing is optional.
P-CSCF filters the Record-Route and Route headers to the UE (in order to hide network topology details from users). In addition, record-routing is mandatory for CSCFs proxies.
Content-Length is not always mandatory (it depends on the transport layer being used).
Content-Length always mandatory.
UA address cannot be used in the To header field of messages sent by itself, except for REGISTER transactions.
The To header field is the UE address itself in event package subscriptions (SUBSCRIBE messages).
Extensions needed for session establishment must be specified in Require headers.
Mandatory extension 100rel (“Reliability of Provisional Responses,” RFC 3262) is not specified in the Require header.
A proxy must not initiate a session releasing procedure.
S-CSCF and P-CSCF must implement the session releasing procedure. Extension support (general)
P- headers are not mandatory.
P- headers are mandatory, for authentication, charging, location, etc.
Privacy Mechanism (RFC 3323) is optional.
Privacy Mechanism (RFC 3323) is mandatory. Extension support (UA)
Reliability of Provisional Responses (RFC 3262) is optional in session establishment.
Reliability of Provisional Responses (RFC 3262) is mandatory in session establishment.
Integration of Resource Management (RFC 3312) is optional in session establishment.
Integration of Resource Management (RFC 3312) is mandatory in session establishment.
Event notification (RFC 3265) is optional.
Event notification (RFC 3265) is mandatory for UE and S-CSCF. Notifier and subscriber roles are mandatory in certain entities (for example, the S-CSCF is always a notifier).
Header Field for Registering Non-Adjacent Contacts (RFC 3327) is optional.
Header Field for Registering Non-Adjacent Contacts (RFC 3327) is mandatory for UE and SCSCF.
Header Field for Service Route Discovery During Registration (RFC 2608) is optional.
Header Field for Service Route Discovery During Registration (RFC 2608) is mandatory for UE and S-CSCF.
SIP messaging (RFC 3428) is optional.
SIP messaging (RFC 3428) is mandatory for S-CSCF.
SIP compression (RFC 3320) is optional.
SIP compression (RFC 3320) is mandatory for UE.
Security Mechanism Agreement (RFC 3329) is optional.
Security Mechanism Agreement (RFC 3329) is mandatory for UE. Extension support (proxy)
Header Field for Registering Non-Adjacent Contacts (RFC 3327) is optional.
Header Field for Registering Non-Adjacent Contacts (RFC 3327) is mandatory for P-CSCF and I-CSCF.
Header Field for Service Route Discovery During Registration (RFC 2608) is optional.
Header Field for Service Route Discovery During Registration (RFC 2608) is mandatory for P-CSCF.
SIP messaging (RFC 3428) is optional.
SIP messaging (RFC 3428) is mandatory.
SIP compression (RFC 3320) is optional.
SIP compression (RFC 3320) is mandatory for P-CSCF.
Security Mechanism Agreement (RFC 3329) is optional.
Security Mechanism Agreement (RFC 3329) is mandatory for P-CSCF.
n Table 2. IETF SIP vs. 3GPP SIP.
IEEE Wireless Communications • June 2005
63
MARQUEZ LAYOUT
6/2/05
1:17 PM
The aim of this interworking model is to provide WLAN UAs the highest possible access level to IMS-based services, where a full seamless access would be the optimal achievement. Interworking of IMS and WLAN QoS mechanisms is essential in this interconnection level.
Page 64
3GPP TS 23.234 [7] also provides an interworking reference architecture for roaming and non-roaming scenarios, including suitable functionalities for supporting 3GPP charging models for interworking scenarios. This architecture reuses 3GPP subscription, network selection, 3GPP-system-based authentication, authorization, and security key agreement using a SIM/ USIM card, and end user charging. This standard, combined with other research activities focusing on specific elements of the general interworking problems, such as [14] which presents a general interworking architecture and [15] which focus on security aspects, provides all the pieces required for supporting this interworking level.
LEVEL 3: ACCESS TO 3GPP SYSTEM IMS-BASED SERVICES The aim of this interworking model is to provide WLAN UAs the highest possible access level to IMS-based services, where full seamless access would be the optimal achievement. Interworking of IMS and WLAN QoS mechanisms is essential at this interconnection level. Signaling interworking with the IMS requires that SIP elements of the WLAN understand the extensions defined by 3GPP (described earlier) in addition to level 2 requirements. Authentication and access control for IMS services use IMS AKA during SIP registration (similar to UMTS AKA as described before, but using ISIM instead of USIM), which provides mutual authentication between UE and network. Regarding integrity and confidentiality of user data, WLAN has to provide their own mechanisms, but interconnection with IMS elements has to be provided at three points: •Interworking between CSCFs and WLAN SIP proxies is not an easy task because of different SIP functionalities defined as mandatory for IETF and 3GPP recommendations, as shown earlier. Key problems refer to AAAC extensions defined as mandatory by 3GPP and modifications performed by CSCFs on the SIP messages that are not recommended by the IETF. •Interworking of the WLAN access control with the HSS and charging and billing system of UMTS, as in level 2. At this point it is especially important to coordinate billing and accounting procedures of the UMTS network for both IMS and WLAN providing the same service. •CDRs of 3GPP and WLAN networks may be independent, but when offering the same services records have to be correlated and coordinated in order to provide homogeneous service billing. In addition, HSS service profiles are shared by both networks. Finally, when UMTS operators offer specific services and define SIP extensions for such purposes, the WLAN proxies and UAs have to understand them in order to be able to access those services properly.
LEVEL 4: SERVICE CONTINUITY Service continuity requires interworking as defined by levels 2 and 3, and also includes not seamless service access. The main differences at this level from level 3 relate roaming and hand-
64
over. Basic SIP as defined by the IETF includes enough capabilities to deal with this service continuity. Problems to be solved at this level refer mainly to possible continuity losses caused by the transport network, and different mechanisms for QoS support in WLAN and UMTS networks, also related to the transport network.
LEVEL 5: SEAMLESS SERVICE CONTINUITY Level 5 is similar to level 4, but intends to provide service continuity with no impact on end-user service perception of IMS functionalities. This level is not covered by Release 6 and will be detailed by the 3GPP in the future; therefore, it is complicated to make assumptions about the specific difficulties that could appear. Regardless, it seems clear that the complexity of some of the IMS mechanisms and the dependence of these procedures on the underlying IP network parameters (e.g., the IP address of the mobile node) may interfere with reaching the objective of seamlessness. IMS architecture deployment and underlying transport network facilities are key elements in reducing or eliminating problems caused by the use of two different network technologies. Therefore, it seems difficult to reach this level of internetworking due to the lack of capabilities of today’s WLAN networks concerning critical QoS support. However, from the signaling point of view, session control performed by the IMS signaling part does not have a remarkable influence on this level, because all functional problems have been solved at level 4.
CONCLUSIONS SIP is the IMS key signaling protocol. Interworking between SIP elements of the WLAN and CSCFs of the IMS is a key issue in reaching a high level of interworking between WLAN and UMTS networks. As discussed in the previous section, SIP session negotiation is not required for interworking at levels 1 and 2. Level 3 involves heavy usage of SIP for session negotiation and control. This level cannot be reached if WLAN nodes do not perform IMS-compatible session negotiation. This article compares basic SIP as defined by IETF and mandatory extensions included in the 3GPP technical specifications, and it can be seen that interworking between these two versions is not easy. Furthermore, SIP and SDP may be freely extended by operators of each domain to support specific services, making it more difficult to interwork between UMTS and WLAN if different versions include incompatible extensions. Finally, levels 4 and 5 do not directly impact IMS signaling, because current SIP/SDP capabilities support service continuity requirements. Problems here focus on the underlying transport network and the performance aspects related to implementation and deployment of the final systems. It is also important to evaluate IMS implementation and deployment when dealing with level 5 regarding seamless service continuity.
ACKNOWLEDGMENTS The work presented in this article is based on the result of the Señalización Integrada para el soporte multimedia en el núcleo de red UMTS,
IEEE Wireless Communications • June 2005
MARQUEZ LAYOUT
6/2/05
1:17 PM
Page 65
Integrated Multimedia Signaling in the UMTS Core (SIUM) Project, a joint venture between Telefónica Móviles de España S. A., Agora Systems, S. A. and the Department of Telematic Systems (DIT) of the Engineering Technical University of Madrid (UPM). The authors would also like to thank Brendan McWilliams for his valuable suggestions in the language revision of this article.
REFERENCES [1] 3GPP TR 22.934, “Feasibility Study on 3GPP system to Wireless Local Area Network (WLAN) Interworking, v. 6.2.0, Sept. 2003. [2] J. Rosenberg et al., “SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002. [3] 3GPP TS 23.002, “Network Architecture,” v. 6.2.0, Sept. 2003. [4] 3GPP TS 23.228 “IP Multimedia Subsystem (IMS),” v. 6.5.0, Mar. 2004. [5] D. Durham et al., “The COPS (Common Open Policy Service) Protocol,” IETF RFC 2748, Jan. 2000. [6] M. Handley and V. Jacobson, “SDP: Session Description Protocol,” IETF RFC 2327, Apr. 1998. [7] 3GPP TS 23.234 “3GPP system to Wireless Local Area Network (WLAN) interworking; System Description,” v. 6.2.0, Sept. 2004. [8] R. Price et al., “Signaling Compression (SigComp),” IETF RFC 3320, Jan. 2003. [9] M. García-Martín et al., “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP),” RFC 3455, IETF, Jan. 2003. [10] J. Rosenberg and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP),” IETF RFC 3264, June 2002. [11] A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification,” IETF RFC 3265, June 2002. [12] W. Marshall, “Private Session Initiation Protocol (SIP) Extensions for Media Authorization,” IETF RFC 3313, Jan. 2003. [13] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP),” IETF RFC 2406, Nov. 1998. [14] A. K. Salkintzis, C. Fors, and R. Pazhyannur, “WLANGPRS Integration for Next -Generation Mobile Data Networks,” IEEE Wireless Commun, vol. 9, no. 5, Oct. 2002, pp. 112–24. [15] G. M. Køien and T. Haslestad, “Security Aspects of 3GWLAN Interworking,” IEEE Commun. Mag., vol. 41, no. 11, Nov. 2003, pp. 82–88.
IEEE Wireless Communications • June 2005
BIOGRAPHIES F ERMI’N G ALA’N M A’RQUEZ (
[email protected]) received his M.Sc. degree in telecommunications from the Technical University of Madrid (UPM), Spain, in 2002, and is working toward his Ph.D. at the same university. In September 2001 he began working on R&D tasks for the Telematic Systems Engineering Department at UPM. Since April 2003 he has worked for Agora Systems. His research interests include IPv6, OS virtualization, Internet signaling protocols, and P2P applications. TOMA’S ROBLES VALLADARES (
[email protected]) is an associated professor at Technical University of Madrid. His research focused on service provision, wireless networks and IPv6. He has been participating in several E.U. projects such as BRAIN/MIND concerning service provision over wireless networks and in the Euro6IX project in the development of new services using SIP. LUIS ÁNGEL GALINDO (
[email protected]) received his M.Sc. degree in telecommunications from the Technical University of Madrid (UPM), Spain, in 1994. From the beginning he has been involved in wireless networks, firstly in Motorola, and from July 1996 in Telefónica Móviles Spain. From his position, he analyses emerging technologies and coordinates deployments in the network. He also participates actively in several fora as 3GPP, ITU and GSMA. His research interests includes IMS related protocols, IPv6, Security in IP networks and QoS.
SIP is the IMS key signaling protocol. Interworking between SIP elements of the WLAN and CSCFs of the IMS is a key issue in order to reach a high level of interworking between WLAN and UMTS networks.
MIGUEL GO’MEZ (
[email protected]) received his M.Sc. degree in telecommunications from the Technical University of Madrid (UPM), Spain, in 2002, and is working towards his Ph.D. at the same university. In July 2001 he began working on R&D tasks for the Telematic Systems Engineering Department at UPM. Since October 2003 he has worked for Agora Systems. His research interests include collaborative environments, application signaling protocols, and IPv6. T OMA’S P. D E M IGUEL (
[email protected]) has a Ph.D. in telecommunications and has been an associate professor at the Telematics Engineering Department at UPM since 1987. His most recent R&D activities have been related to the design of advanced collaborative services, communication networks architectures, communication protocols, and Internet services. He actively participates in many research projects (NICE, LONG or Euro6IX) and has collaborated in the design of a flexible environment to define CSCW services (ISABEL). He works as a technical manager on the deployment of IPv6 at the Telecommunications Engineering School.
65
