Upload
sebastian-schumann
View
352
Download
3
Embed Size (px)
DESCRIPTION
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.
Citation preview
IMS interworking using IBCF
R. Vargica, M. Krhlaa, S. Schumannb, I. Kotuliaka aSlovak University of Technology in Bratislava, Slovakia
bSlovak Telekom, a. s., Slovakia {Matej.Krhla,Radoslav.Vargic,Ivan.Kotuliak}@stuba.sk
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
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 operator’s preference, the border control functions can be applied between two IMS networks or between an IMS network and other
BGCF
Signalling
Bearer
P-CSCFGm/Mw
IBCF
RACSGq'
Ia
I-BGF Iz
I/S-CSCFIc
IWF Iw
IPMultimedianetwork
IMS network
MxIb
Mx
Mx
Mm
Mg/Mi
Figure 1: IMS interworking reference architecture [7]
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 operator’s 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
S-CSCFP-CSCF IBCF I-CSCFIBCF
Mx Mx MwIc
)emoh(SMIeroC)detisiv(SMIeroC
Domains boundary
Figure 2: IMS registration between Visited and Home network [12]
S-CSCF IBCF I-CSCFIBCF
Mx Mx Mw
P-CSCF
Mw Ic
SMIeroCSMIeroC
S-CSCF
Domainsboundary
Figure 3: IMS session between two Home networks [12]
S-CSCFP-CSCF IBCFIBCF
Mx MxIc
)emoh(SMIeroC)detisiv(SMIeroC
Domains boundary
To/fromterminatinghome network
krowteNemoHgnitanigirOkrowteNdetisiVgnitanigirO
Figure 4: IMS session between two Home networks, with originating party roaming [12]
IMS signaling interconnections. Finally, Section 4 concludes with achieved results and provides axes for future research. 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.
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 subscriber’s 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 P-CSCF via Mx reference point, it resolves destination domain’s SIP entry point (IBCF of the Home network) via DNS query based on information taken from the
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.
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]
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 caller’s S-CSCF via Mx reference point. Destination domain’s 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
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 Service-Route 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 server’s architecture is shown on Figure 5.
OpenSER
modules
IBCFconfiguration script
Layer 1, 2IP
TCP or UDPSIPSDP
Layer 1, 2IP
TCP or UDPSIPSDP
Debian – Linux (Kernel 2.6)
Figure 5: OpenSER based IBCF
Mw Mw
Cx Cx
Mw Mw
Cx Cx
Figure 6: Test network topology
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 [email protected] 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 S-CSCF 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
192.168.0.100:5061 [email protected]
192.168.0.100:4060 P-CSCF
192.168.0.100:7060 IBCF
192.168.0.101:5060 I-CSCF
192.168.0.101:6060 S-CSCF
1 REGISTER sip:open-ims.test
2 REGISTER sip:open-ims.test
3 REGISTER sip:open-ims.test
4 REGISTER sip:open-ims.test
5 401 Unauthorized - Challenging the UE (0 bindings)
6 401 Unauthorized - Challenging the UE (0 bindings)
7 401 Unauthorized - Challenging the UE (0 bindings)
8 401 Unauthorized - Challenging the UE (0 bindings)
9 REGISTER sip:open-ims.test
10 REGISTER sip:open-ims.test
11 REGISTER sip:open-ims.test
12 REGISTER sip:open-ims.test
13 200 OK - SAR succesful and registrar saved (1 bindings)
14 200 OK - SAR succesful and registrar saved (1 bindings)
15 200 OK - SAR succesful and registrar saved (1 bindings)
16 200 OK - SAR succesful and registrar saved (1 bindings)
domain: core2.test domain: open-ims.test
Figure 7: Registration procedure call flow
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.
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.
[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. Vrábel, F. Husák: Security of Multimedia Services Using WLAN Access Technology, In Proceeding of IWSSIP 2008, Bratislava, Slovakia, June 2008. [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