IMS interworking using IBCF

R. Vargica, M. Krhlaa, S. Schumannb, I. Kotuliaka Slovak University of Technology in Bratislava, Slovakia b Slovak Telekom, a. s., Slovakia {Matej.Krhla,Radoslav.Vargic,Ivan.Kotuliak}@stuba.sk sebastian.schumann@t-com.sk
was linked to the wireless access UMTS Terrestrial Radio Access Network (UTRAN). In 3GPP Release 6, the IMS core has been made independent of access technology. The IMS is also standardized by 3GPP2 [3] recommendations. ETSI Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) [4] as the ETSI technical committee responsible for standardizing Next Generation Networks (NGN) adds the ability to interface IMS with the fixed network access technologies. TISPAN uses the 3GPP IMS as core architecture but also enhances existing IMS standards with fixed network access (e.g. xDSL) in addition to wireless specific parts. Therefore, the TISPAN NGN architecture outlined in [5] is referenced in this article. One of the widely discussed issues in IMS standardization is the interconnection between IMS networks. Based on the operators preference, the border control functions can be applied between two IMS networks or between an IMS network and other

Abstract
This article focuses on the Interconnection Border Control Function (IBCF) entity in the current IP Multimedia Subsystem (IMS) architecture. Based on the analysis of various types of IMS interconnection scenarios, we describe our proof-of concept solution. We evaluate the signaling in several interconnected IMS domains using Open Sip Express Router (OpenSER) based prototype of IBCF.

1. Introduction
In last years, the IMS [1] is widely accepted as main convergence architecture of the choice. It supports the provisioning of variety multimedia services including VoIP, conferencing, instant messaging or video streaming. The IMS was introduced in 3GPP [2] Release 5, and

Gm/Mw

IWF P-CSCF I/S-CSCF BGCF

Mx Ib Mx

Iw

Mm

IBCF
Gq'

Ic

Mg/Mi
Signalling Bearer

Mx

RACS
Ia

I-BGF
IMS network

Iz

IP Multimedia network

Figure 1: IMS interworking reference architecture [7]

Cor e IM S (vi si t ed) P-CSCF Mx IBCF IBCF Mx

Core IMS (home) I-CSCF Mw S-CSCF

Ic

Domains boundary

Figure 2: IMS registration between Visited and Home network [12]

Cor e IMS P-CSCF Mw S-CSCF Mx IBCF IBCF

Cor e I MS I-CSCF Mx Mw S-CSCF

Ic

Domains boundary

Figure 3: IMS session between two Home networks [12]

Cor e I MS (vi si t ed) P-CSCF Mx Or i gi nat i ng Vi si t ed Net w or k IBCF IBCF

Cor e IMS (home) S-CSCF Mx Or i gi nat i ng Hom e Net wor k To/from terminating home network

Ic

Domains boundary

Figure 4: IMS session between two Home networks, with originating party roaming [12] SIP based multimedia network. The interconnection at the Service layer is performed using the IBCF and possibly by the IWF (see Figure 1). An IBCF is a device that provides the set of functions needed at the border of an operators domain. At the transport layer is the interconnection performed using the IBGF (Interconnection Border Gateway Function). Till 3GPP release 6, I-CSCF was responsible for border functions, most widely mentioned was THIG functionality. In release 7, the IBCF was introduced and border control functions were transferred to it. IBCF is involved (except for cases deliberately configured by operators) in each signaling flow that goes beyond the domain boundaries. In our research [16][17], we faced the problem of SIP signaling interconnection between two IMS domains [18]. Consequently, we have designed the concept suitable for our needs and we have proved it on prototype implementation. Our approach is described in this article in details. The rest of the article is organized as follows: Section 2 analyzes of the IBCF and its role in the IMS interconnections and summarizes the scenarios of IBCF deployment. Section 3 describes our concept of

IMS signaling interconnections. Finally, Section 4 concludes with achieved results and provides axes for future research.

2.1 IBCF usage scenarios

This part describes examples of interconnection scenarios at SIP signaling level, when border control concepts are applied and IBCFs are used. For details see [13]. From subscribers point of view, networks can be divided to the: 1. Home network - network, in which the subscriber is subscribed 2. Visited network subscriber is roaming in this IMS network 3. External network other network Figure 2 illustrates an interconnection scenario for a registration where a subscriber is roaming in a Visited network and Visited network contacts Home network for registration procedure. When the IBCF of the Visited network receives signaling session from PCSCF via Mx reference point, it resolves destination domains SIP entry point (IBCF of the Home network) via DNS query based on information taken from the Table 1: IBCF related Specifications Placement of the IBCF in IMS architecture: ES 282 001 [12], ES 282 007 [13] Reference points: ES 282 007 [13], TS 183 021 [7] Concepts of border control: TS 182 006 (3GPP 23.228 endorsement) [6] ALG functionality: TS 183 021 [7], ES 283 003 (3GPP 24.229 endorsement) [8] THIG functionality: ES 283 003 (3GPP 24.229 endorsement) [8] TS 133 203 [9] Transport plane control: TS 183 017 [10] IWF: TS 182 006 (3GPP 23.228 endorsement) [6] ES 283 003 (3GPP 24.229 endorsement) [8] SIP screening: TS 182 006 (3GPP 23.228 endorsement) [6] SIP URI. The session then continues towards resolved IBCF of the Home network via Ic reference point. This home IBCF then forwards session to the I-CSCF, because Register requests do not have Route header.

2. Analysis
IBCF is control plane entity, inserted on the SIP signaling path between x-CSCF/BGCF and external IP multimedia networks. The functions of the IBCF include: IMS-Application Level Gateway (ALG) [7] network configuration hiding THIG [8, 9] transport plane control QoS [10] inclusion of an IWF if appropriate [8, 11] screening of SIP signaling [8] Definition of the behavior of the IBCF is spread among multiple TISPAN and 3GPP specifications, which are summarized in Table 1. The IBCF is the single point for all incoming SIP signaling sessions destined for particular IMS domain. Therefore its address records and port numbers have to be listed in the DNS in the form of the Service Records (SRV) to ensure that entry point of the particular domain can be resolved. When border control concepts are applied, routing of SIP messages inside IMS core has to change and particular core entities have to be aware of new forwarding rules which are summed up in the following: - Visiting users: Involved P-CSCF forwards all requests from visiting user towards IBCF instead of directly resolving destination via DNS. P-CSCF also forwards requests destined for other domains originated at P-CSCF to the IBCF, e.g. Reg-event Notify messages. - Roaming users: Incoming requests from other domains (e.g. requests from users roaming in other networks) are received by IBCF as it is listed in DNS as entry point. Requests without Route set are forwarded to I-CSCF. I-CSCF will then select corresponding S-CSCF - Home users: Outgoing requests from home network towards other domains are routed to IBCF from S-CSCF. S-CSCF does not resolve destination via DNS.

Cx Cx Cx

Cx

M M w w M

w M

Figure 6: Test network topology Figure 3 illustrates an interconnection scenario for a session setup, where the originating party is located in one Home network and the destination party is located in other Home network. The IBCF of the originating network receives signaling session from callers SCSCF via Mx reference point. Destination domains entry point is then resolved via DNS query based on information taken from the SIP URI. Afterwards, session is forwarded to resolved entry point (IBCF of the terminating network) via Ic reference point. This IBCF then forwards session towards I-CSCF as the session does not have predefined Route header (via Mx reference point.) Figure 4 illustrates an interconnection scenario for a session setup, where the originating party is roaming in
IBCF configuration script

a Visited network. The originating and the terminating party of an IM session belong to different home networks. When the IBCF of the Visited network receives signaling session from P-CSCF via Mx reference point, it forwards session to the IBCF of the Home network via Ic reference point according to Route header composed by UE, based on ServiceRoute header received at registration procedure. This home IBCF forwards session further to the S-CSCF according Route header via Mx reference point. Further scenarios for interconnection towards PSTN networks or towards other IP multimedia networks (e.g. H.323 network) can be found in [12].

3. Proof of concept
Our implemented proof of concept of the IBCF is based the OpenSER [14] server with custom designed configuration file. The prototype was designed to route incoming and outgoing SIP messages for given IMS core network according to specifications. Furthermore, SIP screening [8] and network domain security functions [8] were implemented. The DIAMETER interface Gq for an interaction with the Service Policy Decision Function (SPDF) was simulated using the local loop inside the server. The servers architecture is shown on Figure 5.

OpenSER
SDP SIP TCP or UDP IP Layer 1, 2 SDP SIP TCP or UDP IP Layer 1, 2

modules

Debian Linux (Kernel 2.6)

Figure 5: OpenSER based IBCF

domain: core2.test
192.168.0.100:4060 P-CSCF 192.168.0.100:5061 bob@open-ims.test
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 REGISTER sip:open-ims.test REGISTER sip:open-ims.test

domain: open-ims.test
192.168.0.101:5060 I-CSCF 192.168.0.101:6060 S-CSCF

192.168.0.100:7060 IBCF

REGISTER sip:open-ims.test REGISTER sip:open-ims.test 401 Unauthorized - Challenging the UE (0 bindings) 401 Unauthorized - Challenging the UE (0 bindings) 401 Unauthorized - Challenging the UE (0 bindings) 401 Unauthorized - Challenging the UE (0 bindings) REGISTER sip:open-ims.test REGISTER sip:open-ims.test REGISTER sip:open-ims.test REGISTER sip:open-ims.test 200 OK - SAR succesful and registrar saved (1 bindings) 200 OK - SAR succesful and registrar saved (1 bindings) 200 OK - SAR succesful and registrar saved (1 bindings) 200 OK - SAR succesful and registrar saved (1 bindings)

Figure 7: Registration procedure call flow

To evaluate the prototyped IBCF, the test network (see. Figure 6) consisting of two independent IMS cores based on the OpenIMSCore project [15] was used. For test purposes there is no need for high performance solution, so all components of single OpenIMSCore run on single PC. Configuration of one IMS core was modified and IBCF was integrated. For the second IMS core, the standard configuration was used. The settings of the DNS system were modified to ensure that the IBCF is listed in the DNS as the entry point for the particular domain, instead of the I-CSCF. All three interconnection scenarios shown on the Figures 2, 3 and 4 were successfully accomplished, tested and results were evaluated. The resulting message flows were automatically captured (by tshark) and checked. For further visualization were the SIP traces transformed into vector graphic based call flows. One example of such call flow is in Figure 7, which shows the registration of roaming user to his home network. The flow shows a user bob@open-ims.test roaming in the core2.test domain sending first Register request which correctly passes via P-CSCF and IBCF

in the core2.test domain and through I-CSCF to the SCSCF at open-ims.test domain. The S-CSCF responds with 401-Unauthorized response which takes the same path in the reverse order. The second Register request passes the same path as the first Register request. This time, S-CSCF accepts security credentials calculated over information given in the 401 reply, and it responds with positive 200 OK response, which also passes the same path as Register request, but in the reverse order.

4. Conclusion
In this article, we have focused on the IMS interconnections particularly on the IBCF element allowing the SIP signaling interconnection. Based on the analysis of the recommendations, we have designed a prototype of the IBCF and have proved correctness of our implementation on the selected scenarios. The implemented IBCF prototype performs SIP proxy function. It is listed in the DNS as the entry point for IMS domain and can classify messages as

entry/exit messages. The domain security functions were implemented on the entry to the domain. In real life implementation considering (carrier grade traffic) the IBCF should run on the dedicated server. The configuration script for the OpenSER server should be optimized to minimize message processing time. Our future research will focus mainly on the IBCF functionalities like IMS-ALG, THIG or Gq interface as well as on the transport layer interconnections using IBGF element.

[6] ETSI - TISPAN: IP Multimedia Subsystem (IMS) - Stage 2 description. ETSI TR 182 006. Ver. 1.1.1. March 2006. [7] ETSI - TISPAN: NGN Release 1 - Endorsement of 3GPP TS 29.162 Interworking between IM CN Sub-system and IP networks. ETSI TS 183 021. Ver. 1.2.0. June 2008. [8] ETSI - TISPAN: IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3. ETSI ES 283 003. Ver. 1.8.0. September 2007. [9] ETSI - TISPAN: Universal Mobile Telecommunications System (UMTS) - 3G security - Access security for IP-based services. ETSI TS 133 203. Ver. 7.7.0. October 2007 [10] ETSI - TISPAN: Resource and Admission Control: DIAMETER protocol for session based policy set-up information exchange between the Application Function (AF) and the Service Policy Decision Function (SPDF) - Protocol specification. ETSI TS 183 017. Ver. 1.4.0. August 2007. [11] ETSI - TISPAN: IP Multimedia Subsystem (IMS) Stage 2 description. ETSI TS 182 006. Ver. 1.1.1. March 2006. [12] ETSI - TISPAN: NGN Functional architecture. ETSI ES 282 001. Ver. 1.1.1. ETSI, August 2005. [13] ETSI - TISPAN: IP Multimedia Subsystem (IMS) Functional architecture. ETSI ES 282 007. Ver. 1.1.1. June 2006. [14] Open SIP Express Router project: www.openser.org, July 2007 [15] OpenIMS Core project: www.openimscore.org [16] A. Vrbel, F. Husk: Security of Multimedia Services Using WLAN Access Technology, In Proceeding of IWSSIP 2008, Bratislava, Slovakia, June 2008.

5. Acknowledgement
This paper presents the research results and acquired experience of the authors obtained within the following research projects: Convergence of ICT networks and services in the Slovak communication infrastructure (national research project), VEGA No. 1/3094/06 (national basic research project) and VEGA 1/4084/07 Applied research project grant in cooperation with Sitronics Telecom Solutions Slovakia under no.AV 4/0019/07

6. References
[1] IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS
23.228, V7.12.0, June 2008 [2] 3rd Generation Partnership Project: www.3gpp.org [3] 3rd Generation Partnership Project 2: www.3gpp2.org [4] European Telecommunications Standards Institute, Telecoms & Internet converged Services & Protocols for Advanced Networks Technical Committee: http://www.etsi.org/tispan/ [5] ETSI - TISPAN: NGN Release 1 - Release definition. ETSI TR 180 001. Ver. 1.1.1, March 2006.

[17] S. Massner: Dynamic expansion of IBCF entities in IMS interconnection scenarios, In Proceeding of
IWSSIP 2008, Bratislava, Slovakia, June 2008.

[18] NGN Lab Initiative, www.ngnlab.eu