Presence service integration using interconnected IP Multimedia Core s (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ür Telekommunikation Leipzig (HfTL) Institut für Telekommunikationsinformatik Leipzig, Germany Email: {stephan.massner,maruschke}@hft-leipzig.de Abstract This 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) Configuration Access Protocol (XCAP). I. INTRODUCTION The advantages, Next Generation s (NGN) introduce into the business world, are various. From the business point of view, one major criterion for switching from Public Switched Telephone (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 influenced by other key facts as well: Decrease of time to market for new services, important as the life cycle for new products decreases Simplification 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 configured 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ür 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. A. Virtualization II. LABORATORY OVERVIEW 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 flexibility 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 first 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) 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 s. 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 traffic. They are interconnected using different Virtual Local Area s (VLAN) (see fig. 1). The proxy has firewall rules deployed that allow only explicitly permitted traffic to reach the servers. layer NGN F (presence) Signaling core P-CSCF S-CSCF Fig. 1. NGN NGN NGN NGN F F F F (IPTV) (conf.) (voice) I-CSCF SIP Proxy Support systems HSS XDMS 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 configuration 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 Address Translation (NAT) due to the lack of available public IP addresses, the proxy is responsible to forward the traffic 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 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 figure 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 () with co-located Interworking Function (IWF) are used. The main functions in the transport layer are traffic control, Topology Hiding (THIG) and Bearer Control (BC). The 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 defined 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 and IBGF control each session including signaling data and media data, as all traffic will be routed through these two components. Acting as entry point, both entities are configured to forward the signaling data to the I-CSCF for new sessions and to the P/S-CSCF for existing sessions. data will be routed to an Access Gateway Function (ANGF) or Gateway Function (MGF) for established connections. Outgoing traffic should be forwarded to an connected to the target domain for signaling information and media data to the corresponding IBGF. As first steps to interconnect the testbeds in Leipzig and Bratislava, an interconnection without all the entities as described in standards has been established (fig. 2). This is seen as first and simplest approach to show, that servers of both testbeds can communicate although the difference of the environments 1 and that the standard compliant interconnection has a solid base. All required steps for an gradeful changing of the actual running configuration to a standardized interconnection in the future are shown in (fig. 3). The current set-up allows sharing of Servers (), which are located in different domains. Using the presence service, two different interfaces were shared and forwarded between the testbeds. ISC/Ma is the first interface. It will be used to exchange information between the Serving (S)-CSCF and the Presence-. The latter interconnection is established on the Ut interface, used by a User Agent (UA) 1 E.g. firewalls (managed and also unmanaged by lab staff) or different virtualizations
IMS Testbed HfTL IMS Testbed STU Ut ISC/Ma ISC/Ma Sh #A Public Internet #B S CSCF HSS Cx Server HfTL Hochschule für Telekommunikation Leipzig (Germany) User Equipment STU Slovak University of Technology, Bratislava (Slovakia) Gateway (for Interconnection) Fig. 2. Interconnection scheme SIP DIAMETER HTTP/XCAP/... Mw Mw Gm Mw P CSCF I CSCF Server User Equipment CSCF Call Session Control Function P /I /S Proxy/ Interrogating/ Serving HSS Home Subscriber Server Cx Step 1) Establisment of a shared VPN Inter connection between two different and separate located IMS based multimedia networks. Step 2) Establishment of a standardized inter connection in the signalling layer using the to connect two IMS based Multimedia networks. Step 3) Establishment of a standardized inter connection in the signalling layer using the and in the transport layer using the IBGF to connect two IMS based Multimedia networks. Steps from plain to standardized Interconnection Core Transport Core Transport Core Transport Server SPDF IBGF Interconnection Border Control Function SPDF Service based Policy Decision Fcuntion IBGF Interconnection Border Gateway Function Fig. 3. Steps towards standardized interconnection located inside a User Equipment () to communicate with the Presence-. 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 (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 briefly described in the following. The relationship between the components and all defined interfaces are shown in figure 4, see also [5] and [6]. Fig. 4. A. P-CSCF Standardized IMS core network components and interfaces The Proxy-CSCF acts as strict outbound proxy for IMS User Equipment (IMS-), i.e. all messages sent by IMS- have to go through the P-CSCF at first. In addition, IMS-s should not accept any requests and responses not sourced at the P- CSCF. The P-CSCF represents a security gateway for IMS signaling with IMS-s 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 Interrogating- CSCF 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 () 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 profiles 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 filter 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
other network entities in handling actually sessions. Other included parts are the mapping between SIP-Uniform Resource Identifier (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 specific services. A user service profile could include different filters sorted by different priority as described in [7]. The following description is summarized in fig. 5. User Profile Service Profile Indicator: registered/unregistered/independend Filter: Trigger Point + Information other direction, the S-CSCF processes responses on the ISC interface. A. Presence server IV. APPLICATION INTEGRATION 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 fixed 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 fig. 6. Logical expression: CNF: ( A or B ) and C DNF: ( A and B ) or C Requested URI Method header Session case SDP line equals/ matches/ is one of SIP URI Proceedings if isn t available User Profile domain.de Service Profile Presence Filter: Trigger Point + Information CNF: ( A or B ) SIP Header Content:.*presence* SIP Header Content:.presence* presence1.domain.sk (IP Address) Proceeding if isn t available: Forward to: Indicator: registered presence2.domain.de Fig. 5. Profile definition within the HSS User Profile domain.sk Service Profile Presence Filter: Trigger Point + Information Indicator: registered One of the filters contains a logical expression named trigger point (TP), which has to be applied on an initial request and also application server () information like SIP-URI and proceedings if the 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 five 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 filter criteria can be applied only if the user is registered or unregistered. Other filter criteria are irrespective to the registration status. By triggering an IFC, the S-CSCF checks if filter 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 on the ISC interface. In the CNF: ( A or B ) SIP Header Content:.*presence* SIP Header Content:.presence* Fig. 6. presence1.domain.sk (IP Address) Proceeding if isn t available: Forward to: presence2.domain.de Presence profile definition within the HSS Assuming every user has the presence IFC set and activated, all 2 /PUBLISH messages whose Event is determined for the presence server (see fig. 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 Makefile has to be modified to include the mysql, presence, presence xml and xcap client module. This modification enables the MySQL database 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 files can be finally compiled and installed now 3. The following changes on in the OpenSIPS configuration are necessary to make it fit 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 final packet source The MySQL server will be used as user profile storage. It is assumed the server is up and running. Its installation and set-up are out of the scope of this paper. 3) 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 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 S- CSCF 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 defined 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 Usage IDs (AUID), the server supports, are pidf-manipulation 3 The installation will only work, if all required libaries and development files are installed on the system. 4 As the XCAP server requires user credentials currently, the data is still kept within the database. 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 configuration 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 filled 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 final communication and deployment of the service and its consisting two is shown in figure 7. Fig. 7. XCAP SIP XCAP XMLRPC Other NGN F Presence Server (OpenSIPS) S CSCF P CSCF MySQL DB Server User Equipment XMLRPC CSCF Call Session Control Function P /S Proxy/ Serving XDMS (OpenXCAP) 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 configured for multi-domain support. V. FUTURE USE CES According to the described interconnection using a VPN connection between the two gateways, the next steps are divided as follows:
a) Establishment of an interconnection using the in the signaling layer (Ic Interface) by providing THIG in SIP signaling. The prototyping of an is in progress now. b) Usage of different services like presence, calendar, video on demand, provided by several and located in separated IP multimedia networks. In this scenario any S-CSCF related to an 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 using the ISC/Ma Interface through the VPN connection is not longer supported. All signaling messages will be exchanged using the in the signaling layer. c) Support of roaming by using the HSS located in the home network in addition with different service profiles 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 and IBGF. The possible interconnection scenario in the future is shown in fig. 8. The displayed components are all connected according the existing standards as [14]. IMS Testbed HfTL x Ut Gm P CSCF ANGF NS Server User Equipment RACS IP Transport IBGF P CSCF Proxy Call Session Control Function Interconnection Border Gateway Function ANGF Access Gateway Function IBGF Interconnection Border Gateway Function NS Attachment Subsystem RACS Ressource and Admission Control Subsystem Fig. 8. x Iz Ic IBGF RACS IMS Testbed STU NS IP Transport Future interconnection possibilities VI. CONCLUSION P CSCF ANGF Ut Gm x The physical interconnection through the VPN and the use of an application deployed in one network (Bratislava) by the other network (Leipzig) was the first 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 realtime 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 certification of professionals in the InCert and Train2Cert projects. ACKNOWLEDGMENT STU and HfT are working together on common topics in the area of Next Generation s 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. REFERENCES [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 Specification, 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 Sub- System (RACS): Functional Architecture [5] ETSI TISPAN TS 123 002 v7.5.0 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); 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 s [12] RFC 4825, The Extensible Markup Language (XML) Configuration 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 Protocols Professionals certification in InCert, International Certificates of Excellence in Selected Areas of ICT, http://incert.eu [17] Train2Cert, Vocational Training for Certification in ICT, http://train2cert. eu