Presence service integration using interconnected IP Multimedia Core Networks (IM-CN)

Sebastian Schumann and Eugen Mikoczy

Slovak Technical University (STU) Department of Telecommunications, NGNlab Bratislava, Slovakia Email: {schumann,mikoczy}@ktl.elf.stuba.sk

Stephan Massner and Michael Maruschke

Hochschule f ur Telekommunikation Leipzig (HfTL) Institut f ur Telekommunikationsinformatik Leipzig, Germany Email: {stephan.massner,maruschke}@hft-leipzig.de

AbstractThis paper describes the integration of the presence management service into existing IP Multimedia Subsystem (IMS) laboratory infrastructures. Both laboratories NGNlab in Bratislava and the laboratory in Leipzig use the Fraunhofer OpenIMS as core components for their testing IMS environment (i.e. Call Session Control Functions (CSCF), Home Subscriber Server (HSS)). The virtualization of these components will be described in this paper. Furthermore, the layer 3 interconnection and hence the possibility to share different applications between the locations will be discussed. The presence management service has been deployed in a state where it is ready to be used with current IMS clients, for both presence information sharing via the Session Initiation Protocol (SIP) and user authorization via Extended Markup Language (XML) Conguration Access Protocol (XCAP).

I. I NTRODUCTION The advantages, Next Generation Networks (NGN) introduce into the business world, are various. From the business point of view, one major criterion for switching from Public Switched Telephone Network (PSTN) technology to All-IP is saving money. The technical equipment and hardware the network providers have to buy has gone simpler and thus cheaper. Business decisions for introducing NGN are inuenced by other key facts as well: Decrease of time to market for new services, important as the life cycle for new products decreases Simplication of the architecture (switch from horizontal to vertical approach) CAPEX/OPEX savings as introduction and maintenance of new services will be lower Those approaches and the technical progress in the area of NGN lead to the laboratory set-ups that will be explained within this paper. The NGNlab team of the Slovak Technical University [1] elaborates the ongoing standardization process in the area of IMS/NGN and is building up a network infrastructure from source-open components since 2007. The infrastructure has been virtualized to utilize the hardware resources in a better way. The congured components include all core network elements and are extended by applications and services continuously. The presence application (acc. [2]) on top of the open-source IMS components from FOKUS Fraunhofer [3] will be described and evaluated.

The Hochschule f ur Telekommunikation Leipzig (HfTL) established a NGN test and research laboratory as well. The Fraunhofer OpenIMS running on this network forms the testbed infrastructure for various NGN test scenarios. It is used in parallel for teaching projects on academical side. Having two deployments in different locations lead to the idea of extending the cooperation by interconnecting the two testbeds in Leipzig and Bratislava. One key concept of the IMS is the possibility to use applications from other IMS core networks. This paper will discuss the requirements for the interconnection between the IMS core network in Leipzig and Bratislava and the possibilities to share service deployments between the users of both networks. It focusses only on a very basic set-up not involving IMS interconnection scenarios from the standards yet. The IMS core from Leipzig will use an application server from the Bratislava domain. This will validate that the layer 3 interconnection works and that the application server deployment can handle multiple domains. The paper will close with future prospects how to utilize the existing interconnection further and discuss the ongoing standardization process within this area. Following papers with much deeper standardized interconnection scenarios and an extension of the test cases are planned. This paper should provide the base for such an interconnection. II. L ABORATORY OVERVIEW A. Virtualization This section will discuss the virtualization approach in the NGNlab. Due to the relatively low utilization of the laboratory environment, virtualization has been chosen to use the existing hardware in a better way. The environment was designed to allow easy management of the servers and also the virtualization itself. Virtualization is performed on Debian GNU/Linux servers running the Xen virtualization software. Most of the software used in testbed is open source, which offers exibility and extensibility for future development. When establishing the lab, four servers have been assigned, including the machines they should later run virtualized. The following design has been chosen:

a) Signaling core: The rst server includes all IMS core components (all CSCFs). Also a legacy SIP server is deployed. Mainly all core applications that are involved in major signaling (i.e. that can result in outbound calls) are deployed here. b) Support systems: This server contains database cluster for NGNlab support (user database, web application database), HSS and also the XML Document Management Server (XDMS). c) Application layer: On this server are all applications. Those virtualized instances communicate mainly with the IMS core or provide additional functionality. d) Student server: This virtualization server runs all student projects in the area of Next Generation Networks. They have their own IMS core running, but can also be interconnected with the signaling core components. All components are running behind a proxy server with restrictive permission settings for the network trafc. They are interconnected using different Virtual Local Area Networks (VLAN) (see g. 1). The proxy has rewall rules deployed that allow only explicitly permitted trafc to reach the servers.
Application layer NGN ASF (presence) NGN ASF (IPTV) NGN ASF (conf.) NGN ASF (voice) NGN ASF

the core components. He can modify the existing application servers; however he is only able to connect to the main control functions through the network and not via the virtualized host itself. All virtualization servers and also the virtualized servers can be reached separately via a management interface. This interface is not depicted in gure 1. B. Interconnection As described in the standards, an interconnection scenario includes some additional components: Located in the transport layer, an Interconnection Border Gateway Function (IBGF) is needed. In the signaling layer, an Interconnection Border Control Function (IBCF) with co-located Interworking Function (IWF) are used. The main functions in the transport layer are trafc control, Topology Hiding (THIG) and Bearer Control (BC). The IBCF uses THIG for signaling information and controls the IBGF through the Service based Policy Decision Function (SPDF). This SPDF performs a coordination function acting as Policy Decision Point for Service-based Policy control (see also [4]). It makes policy decisions depending on service policy rules dened by the network operator. Furthermore, the underlying network technology will be hidden from applications. The authorization of transport control service requests from application functions is based on a process, which involves the check of these requests against the given policy. The IBCF and IBGF control each session including signaling data and media data, as all trafc will be routed through these two components. Acting as entry point, both entities are congured to forward the signaling data to the I-CSCF for new sessions and to the P/S-CSCF for existing sessions. Media data will be routed to an Access Network Gateway Function (ANGF) or Media Gateway Function (MGF) for established connections. Outgoing trafc should be forwarded to an IBCF connected to the target domain for signaling information and media data to the corresponding IBGF. As rst steps to interconnect the testbeds in Leipzig and Bratislava, an interconnection without all the entities as described in standards has been established (g. 2). This is seen as rst and simplest approach to show, that servers of both testbeds can communicate although the difference of the environments1 and that the standard compliant interconnection has a solid base. All required steps for an gradeful changing of the actual running conguration to a standardized interconnection in the future are shown in (g. 3). The current set-up allows sharing of Application Servers (AS), which are located in different domains. Using the presence service, two different interfaces were shared and forwarded between the testbeds. ISC/Ma is the rst interface. It will be used to exchange information between the Serving (S)-CSCF and the Presence-AS. The latter interconnection is established on the Ut interface, used by a User Agent (UA)
1 E.g. rewalls (managed and also unmanaged by lab staff) or different virtualizations

Signaling core

Support systems HSS XDMS

S-CSCF

P-CSCF

I-CSCF

SIP

Proxy

Fig. 1.

Virtualization of signaling components

All required Domain Name System (DNS) settings to reach the internal infrastructure are deployed on the DNS server. Starting with the basic conguration of the OpenIMS components, DNS Service Pointer (SRV) and Name Authority Pointer (NAPTR) have been created pointing to the Interrogating (I)-CSCF. This is important for the later interconnection (see section II-B). The Proxy (P)-CSCF is reachable from the public internet as well. As the set-up must use Network Address Translation (NAT) due to the lack of available public IP addresses, the proxy is responsible to forward the trafc on dedicated ports to the respective internal virtual machine. The overall set-up is very realistic for many universities or institutions that want to deploy a testbed but do not have the necessary amount of public IP addresses. The presented virtualization concept assures that the administrator of the application servers can never interfere with

IMS Testbed HfTL

IMS Testbed STU

Ut

AS
AS VPN Tunel Application Data AS Sh ISC/Ma ISC/Ma

Core IMS
Core IMS #A GW Public Internet GW Core IMS #B

SCSCF
Cx Mw Mw

HSS
Cx

UE

Media Data

Signalling Data

UE Gm Mw

UE
Legend: AS Application Server HfTL Hochschule fr Telekommunikation Leipzig (Germany) STU Slovak University of Technology, Bratislava (Slovakia) UE User Equipment GW Gateway (for Interconnection) Legend: SIP

PCSCF

ICSCF

Fig. 2.

Interconnection scheme

DIAMETER HTTP/XCAP/...

AS Application Server UE User Equipment CSCF Call Session Control Function P/I/S Proxy/ Interrogating/ Serving HSS Home Subscriber Server

Steps from plain to standardized Interconnection

Step 1) Establisment of a shared VPNInter connection between two different and separate located IMSbased multimedia networks.
VPN Tunel Application

Fig. 4.

Standardized IMS core network components and interfaces

AS Core IMS Core Transport Network

Data

GW

Media Data

Signalling Data

A. P-CSCF
VPN Tunel

Step 2) Establishment of a standardized inter connection in the signalling layer using the IBCF to connect two IMS based Multimedia networks. Step 3) Establishment of a standardized inter connection in the signalling layer using the IBCF and in the transport layer using the IBGF to connect two IMSbased Multimedia networks. Legend: AS IBCF SPDF IBGF

Application

AS Core IMS Core Transport Network IBCF

Data

GW

Media Data

Signalling Data

VPN Tunel Application

AS Core IMS IBCF

Data

GW

SPDF Core Transport Network

Signalling Data Media Data

The Proxy-CSCF acts as strict outbound proxy for IMS User Equipment (IMS-UE), i.e. all messages sent by IMS-UE have to go through the P-CSCF at rst. In addition, IMS-UEs should not accept any requests and responses not sourced at the PCSCF. The P-CSCF represents a security gateway for IMS signaling with IMS-UEs using secured communication channels given by the Gm interface. Checking and enforcing the signaling policies for SIP requests (service routes, dialog routes) and responses (via nodes) will be done by the P-CSCF as well. B. I-CSCF This entity represents the entry point in the home domain. Using the Home Subscriber Server (HSS), the InterrogatingCSCF provides location services like user location or registration point location. Depending on capabilities of further entities inside the IMS core network, the I-CSCF forwards messages to responsible S-CSCFs to terminate the request in the home network or to Interconnection Border Control Functions (IBCF) to terminate the request in a foreign network. C. S-CSCF The major functionality of the Serving-CSCF is grounded in registration of users by authentication, storing contact locations and user subscription information, resolving public identities into contact addresses and adding routes as indicated in path headers. These tasks require the interworking between the S-CSCF and the HSS, as the S-CSCF must get authentication vectors and IMS service proles for its serving users. If an expiration of a user authorization time is detected by the HSS, the S-CSCF has to terminate the registration. This action is pushed by the HSS. Furthermore, the dialog state has to be held on S-CSCF side. According this state, a triggering on initial lter criteria has to be done. D. HSS The central database of an IMS core network is named HSS and it contains subscription related information to support

IBGF

Application Server Interconnection Border Control Function Servicebased Policy Decision Fcuntion Interconnection Border Gateway Function

Fig. 3.

Steps towards standardized interconnection

located inside a User Equipment (UE) to communicate with the Presence-AS. Two different protocols are needed on these interfaces. One of them is the Session Initiation Protocol (SIP) on the ISC/Ma interface and the other one is XCAP on the Ut interface. For the realization of the interconnection, a secure infrastructure was needed. As the public internet is used to forward data between the entry points of these testbeds, a secure concept had to be established. After implementing a Public Key Infrastructure (PKI) it was possible to initiate a secured connection using a Virtual Private Network (VPN) tunnel from one gateway to another and vice versa. The gateways are located at the border of each network. III. IMS CORE NETWORK To understand the main components, which are involved to access the service, the core network will be briey described in the following. The relationship between the components and all dened interfaces are shown in gure 4, see also [5] and [6].

other network entities in handling actually sessions. Other included parts are the mapping between SIP-Uniform Resource Identier (URI) and E.164 telephone numbers and the generation of security information according to users. For service enabling, the HSS provides user related information to application servers. E. IFC The Initial Filter Criteria (IFC) enable routing to various application servers to provide user specic services. A user service prole could include different lters sorted by different priority as described in [7]. The following description is summarized in g. 5.
User Profile
Service Profile Indicator: registered/unregistered/independend

other direction, the S-CSCF processes responses on the ISC interface. IV. A PPLICATION INTEGRATION A. Presence server 1) Set-up within CN: As already discussed, the IMS follows the approach of a layered architecture. Each deployed service will be offered by one common transport plane, providing IP access to various xed and mobile devices. This plane provides transparent access to all kinds of devices and allows the connection to the next layer: The control plane. As this plane is described in section III, the focus is now on how the third plane can be accessed. The IMS interaction with services is triggered at the S-CSCF. The network operator has to set up IFC at the S-CSCF. Based on these criteria the controller can determine which messages it has to forward to which service. The set IFC for the presence service in both domains are shown in g. 6.
User Profile domain.de

Filter:

Trigger Point + AS Information SIPURI

Logical expression: CNF: ( A or B ) and C DNF: ( A and B ) or C Service Point Trigger: Requested URI Method header Session case SDP line equals/ matches/ is one of

Proceedings if AS isnt available

Service Profile Presence Filter: Trigger Point + AS Information CNF: ( A or B )

Indicator: registered

presence1.domain.sk (IPAddress) Proceeding if AS isnt available: Forward to:

Service Point Trigger: SIPHeader: Event SIPHeader Content: .*presence* Service Point Trigger: SIPHeader: Event SIPHeader Content: .presence*

presence2.domain.de

User Profile domain.sk

Fig. 5.

Prole denition within the HSS

Service Profile Presence Filter: Trigger Point + AS Information CNF: ( A or B )

Indicator: registered

One of the lters contains a logical expression named trigger point (TP), which has to be applied on an initial request and also application server (AS) information like SIP-URI and proceedings if the AS is not reachable. The TP can be varied into two types: Conjunctive normal form (CNF) like (A or B) and (C or D) Disjunctive normal form (DNF) like (A and B) or (C and D) The atoms A, B, C... are called Service Point Trigger (SPT). The SPTs can be divided into typically ve types: Request-URI equals . . . Method matches . . . Header . . . is present or matches . . . Session case is . . . SDP line matches. . . Session cases are for example originating, terminating or terminating to unregistered user. Depending on registration status, certain lter criteria can be applied only if the user is registered or unregistered. Other lter criteria are irrespective to the registration status. By triggering an IFC, the S-CSCF checks if lter expressions matches an initial request for a dialog created method or standalone requests is given. In case of a match, the message will be forwarded to the indicated AS on the ISC interface. In the

presence1.domain.sk (IPAddress) Proceeding if AS isnt available: Forward to:

Service Point Trigger: SIPHeader: Event SIPHeader Content: .*presence* Service Point Trigger: SIPHeader: Event SIPHeader Content: .presence*

presence2.domain.de

Fig. 6.

Presence prole denition within the HSS

Assuming every user has the presence IFC set and activated, all SIP SIMPLE2 /PUBLISH messages whose Event is determined for the presence server (see g. 6) are now forwarded there. The event catches not only normal subscriptions (e.g. event package presence, [8]), but includes also the event template-packages (e.g. event template-package presence.winfo, [9]). 2) Deployment: For the presence server itself, the opensource SIP server implementation OpenSIPS [10] in its current stable version (1.4) has been deployed. The open-source software is a fork of the well-known OpenSER. Within the source directory, the OpenSIPS Makele has to be modied to include the mysql, presence, presence xml and xcap client module. This modication enables the MySQL database Application Programming Interface (API) for accessing the application data later. Moreover, the required modules
2 SIP

For Instant Messaging And Presence Leveraging Extensions

for the presence service will be included in the compilation process. Within the source directory, the les can be nally compiled and installed now3 . The following changes on in the OpenSIPS conguration are necessary to make it t into the laboratory deployment as application server: Handle subscriptions and publications User authentication via P-Asserted-Identity headers Accept only trusted sources (S-CSCF of Bratislava and Leipzig testbed) as nal packet source The MySQL server will be used as user prole storage. It is assumed the server is up and running. Its installation and set-up are out of the scope of this paper. 3) UE authentication: The user authentication in the deployed IMS is made against the user database of the HSS. The presence server, however, has its own application database and hence a separate user and password management would be required, if the UE should be challenged. As the usage of two separate databases does not scale, and more important the IMS guidelines recommend another approach, the deployed solution make use of the private extension headers (esp. P-Asserted-Identity, [11])4 . The privacy header of the SUBSCRIBE and PUBLISH messages are checked by the presence server. Only if the P-Asserted-Identity header has been added by the SCSCF and the message has been received from this trusted node the SIP message is processed. The privacy header username and domain are examined and treaded as if those parameters would have been successfully challenged. The P-Asserted-Identity URI must match the SIP From: URI B. XCAP server At current state, the presence server would be able to handle all SIP subscriptions and publications properly. OpenSIPS allows using the presence server in a so-called forcedauthorization mode. In this mode, all subscriptions are considered to be authorized. This is of course not intended: In real-world scenarios, the users are responsible to authorize their presence states. The dened standard for exactly those authorizations is XCAP (see [12]). The deployed XCAP server/XDMS is OpenXCAP [13] from AG Projects. The software is source-open as well. It has been designed to work together with OpenSIPS. This is important because the XCAP server must communicate with the presence server. The OpenXCAP server is an application written in Python and using most of the currently available standards. The Application Usage IDs (AUID), the server supports, are pidf-manipulation
installation will only work, if all required libaries and development les are installed on the system. 4 As the XCAP server requires user credentials currently, the data is still kept within the database.
3 The

xcap-caps resource-lists pres-rules, org.openmobilealliance.pres-rules rls-services watchers (proprietary) The server has been installed by Debian package management according [13]. No further steps besides proper conguration were necessary. OpenXCAP uses the management interface from OpenSIPS to authorize users. The user authorization state is written in the database of OpenSIPS. For authorization, the presence server database is accessed directly. The XCAP data is also stored in the database. For authorization, OpenXCAP must modify the parameter according which OpenSIPS decides whether the NOTIFY body will be lled with presence information or not. Instead of accessing the database directly for this purpose, the XCAP server uses the XML Remote Procedure Calls (XMLRPC) interface to authorize the users. The XCAP documents for these purposes, however, are stored via normal MySQL access in the database. The nal communication and deployment of the service and its consisting two AS is shown in gure 7.

MySQL DB
XCAP

NGN ASF Presence Server (OpenSIPS)

SIP SIMPLE

XDMS (OpenXCAP)
XMLRPC

Core IMS SCSCF

SIP SIMPLE

SIP SIMPLE

UE

PCSCF

Legend: SIP SIP SIMPLE XCAP XMLRPC Other AS Application Server UE User Equipment CSCF Call Session Control Function P/S Proxy/ Serving

Fig. 7.

Detailed connection of presence and XCAP servers

The SIP interface is exposed towards the IMS core components, the XCAP interface is exposed towards the proxy server. It is responsible to use NAT to make the respective port available throughout the internet. The DNS name for the XCAP server must point towards the proxy from external requests and towards the XCAP server for internal requests. As the testbeds in Leipzig and Bratislava use different domains, OpenSIPS and OpenXCAP are both congured for multi-domain support. V. F UTURE USE CASES According to the described interconnection using a VPN connection between the two gateways, the next steps are divided as follows:

Establishment of an interconnection using the IBCF in the signaling layer (Ic Interface) by providing THIG in SIP signaling. The prototyping of an IBCF is in progress now. b) Usage of different services like presence, calendar, video on demand, provided by several AS and located in separated IP multimedia networks. In this scenario any S-CSCF related to an AS is located in one of many IP multimedia networks and enables these services using the Mw Interface. Note: In difference to the usage described in this paper, an interconnection of an S-CSCF and an AS using the ISC/Ma Interface through the VPN connection is not longer supported. All signaling messages will be exchanged using the IBCF in the signaling layer. c) Support of roaming by using the HSS located in the home network in addition with different service proles depending on location information. d) Prototyping of the SPDF and manipulation of Session Description Protocol (SDP) data related to SIP signaling information of each session depending on the network capabilities (simulated). e) Interconnection of IP multimedia networks using the Ic Interface in the signaling layer and the Iz Interface in the transport layer provided by the IBCF and IBGF. The possible interconnection scenario in the future is shown in g. 8. The displayed components are all connected according the existing standards as [14].
IMS Testbed HfTL IMS Testbed STU

a)

time applications that require Quality of Service (QoS) between both networks. Especially services like IPTV or video conferencing require resource reservation mechanisms and secure IMS testbed interconnection, which will be able to provide secured end-to-end QoS transport for media and signaling. The presented testbed interconnection can be used for research or education purposes. The STU uses the described testbed in several international projects like European Celtic project, NetLab orthe Leonardo da Vinci project. It is also used for NGN protocols certication of professionals in the InCert and Train2Cert projects. ACKNOWLEDGMENT STU and HfT are working together on common topics in the area of Next Generation Networks since 2006 and participate in ongoing projects involving their core network interconnection. This paper also presents some of the results and acquired experience from various research project such as NGNlab project [1], European Celtic-EURECA project Netlab [15], Leonardo da Vinci projects InCert [16] and Train2Cert [17], AV project: Converged technologies for next generation networks (NGN), Slovak National basic research projects VEGA No. 1/3094/06 and VEGA 1/4084/07. R EFERENCES
[1] NGNlab - NGN laboratory at Slovak University of Technology in Bratislava, http://www.ngnlab.eu [2] 3GPP TS 23.141 v7.3.0 (2007-09), Technical Specication, Presence Service; Architecture and functional description; Stage 2, 2007 [3] Fraunhofer Institute for Open Communication Systems Open IMS Core implementation, http://www.openimscore.org [4] ETSI TISPAN ES 282 003 v2.0.0 Resource and Admission Control SubSystem (RACS): Functional Architecture [5] ETSI TISPAN TS 123 002 v7.5.0 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Network architecture (3GPP TS 23.002 version 7.5.0 Release 7) [6] ETSI TISPAN TS 123 228 v7.13.0 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.13.0 Release 7) [7] ETSI TISPAN TS 123218 v7.9.0 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia (IM) session handling; IM call model [8] RFC 3856, A Presence Event Package for the Session Initiation Protocol (SIP) [9] RFC 3857, A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) [10] OpenSIPS - OpenSIPS (Open SIP Server) is a mature Open Source implementation of a SIP server, http://www.opensips.org [11] RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks [12] RFC 4825, The Extensible Markup Language (XML) Conguration Access Protocol (XCAP) [13] OpenXCAP - OpenXCAP is an open source fully featured XCAP server, http://www.openxcap.org [14] ETSI TISPAN ES 282001 v2.0.0 NGN Functional Architecture [15] NetLab - Use Cases for Interconnected Testbeds and Living Labs, http: //www.celtic-initiative.org/Projects/NETLAB/ [16] InCert Next Generation Network Protocols Professionals certication in InCert, International Certicates of Excellence in Selected Areas of ICT, http://incert.eu [17] Train2Cert, Vocational Training for Certication in ICT, http://train2cert. eu

Ut

AS

Application Data x

AS

Ut

Gm UE P CSCF Core IMS Ic IBCF Signalling Data Iz IBGF Media Data Legend: AS Application Server UE User Equipment PCSCF Proxy Call Session Control Function IBCF Interconnection Border Gateway Function ANGF Access Network Gateway Function IBGF Interconnection Border Gateway Function NASS Network Attachment Subsystem RACS Ressource and Admission Control Subsystem IBGF IBCF Core IMS P CSCF

Gm UE

NASS x ANGF

RACS

RACS

NASS ANGF x

IP Transport Network

IP Transport Network

Fig. 8.

Future interconnection possibilities

VI. C ONCLUSION The physical interconnection through the VPN and the use of an application deployed in one network (Bratislava) by the other network (Leipzig) was the rst step towards the standard compliant interconnection both laboratories plan to achieve. As expected, all components can be used through the VPN. The only restriction for further tests, involving the actual core IMS interconnection and application sharing, are real-