rd party service provisioning in SIP-based UMTS network Jatta Rantala Supervisor: Prof. Jorma Jormakka Instructor: Kai Väänänen, M.Sc.

Background and Research Problem Research Methods What is IMS? Session Initiation Protocol IMS Service Architecture Service Provisioning in IMS Service Provisioning Architecture IMS Service Capabilities and OMA Service Enablers Challenges in 3 rd Party Service Provisioning 3rd Party Service Provisioning Technologies Vendor Views Results Conclusions and topics for future studies Contents

Background and Research Problem IMS that defines architecture for the usage of Session Initiation Protocol enables real-time and non-real-time IP Multimedia services for the wireless environment and is evidently being deployed in mobile operators’ networks in the near future. Until recently predominantly network operators alone have developed the services to mobile subscribers – lacking often innovative, new ideas - utilizing network capabilities traditionally only available to them. -> service development too slow and costly process that also requires specialized knowledge of the underlying network protocols. The investment in IMS will be justified more probably, if the interfaces to IMS Capabilities and Service Enablers are opened to third parties with open, standardized and secure environments and APIs -> Which third party service provisioning technology with associated API is most applicable for IMS environment considering: –The capabilities of the functionalities offered by the third party service provisioning technology in answering to the challenges set by the SIP-based IMS environment in addition to the network agnostic challenges

Research Methods Literature study: –Specifications of 3GPP and OMA –Researches and studies of different academic sources –Discussions with experts of the study topic Semi-structured Vendor Interviews: –Conducted for two big Telecommunication equipment vendors

What is IMS? IP Multimedia Subsystem is a SIP-based IP Multimedia infrastructure that provides a complete architecture and framework for providing real-time and non-real-time IP multimedia services on top of Packet Switched (PS) core while still preserving the legacy Circuit Switched (CS) telephony services. IMS provides the necessary IMS Capabilities: service control, security functions (e.g. authentication, authorization), charging, routing, registration, SIP compression and QoS support. First time introduced in 3GPP Release 5 as “IMS Phase 1”, while in 3GPP Release 6 - “IMS Phase 2” – IMS is further enhanced with e.g. Presence, Messaging and Group Management. IMS is also expected to bring the strengths of wireless and fixed-line worlds together. In 3GPP’s words: “The IMS should enable the convergence of, and access to, voice, video, messaging, data and web-based technologies for the wireless user, and combine the growth of the Internet with the growth in mobile communications.”

Session Initiation Protocol (SIP) 3GPP has chosen SIP for signalling between UE and the IMS as well as between the components of IMS in order to facilitate maximum interoperability with existing (fixed and mobile) Internet systems, devices, and protocols SIP is application-layer control protocol based on request-response paradigm for creating, modifying and terminating multimedia sessions with one or more participants. Defined in IETF RFC 3261 with numerous extension RFCs for e.g. Presence, and Instant Messaging Works over UDP and TCP Basically there are four types of logical entities in a SIP network, namely User Agents (UAs), proxy servers, redirect servers and registrars. As IMS is an application of SIP Architecture CSCFs and HSS implement these functions.

IMS Service Architecture IMS Service Architecture combines three service platforms: SIP, OSA and CAMEL S-CSCF is in a central role acting as a contact point to the Application Servers, controlling the sessions and detecting if and how to involve a service logic to provide value-added services SIP AS hosts and executes native SIP services that are programmable through a variety of technologies including SIP servlets, Call Processing Language (CPL) script, SIP Common Gateway Interface (CGI) and Java APIs for Integrated Networks (JAIN). OSA SCS provides a standardized, extensible, scalable and secure interface to enable third parties to access SCFs implemented by means of SIP for developing value added services. IM-SSF is a interworking module between SIP and CAMEL supporting legacy IN-type services. HSS is a centralized data-base containing subscription-related information such as user identification, numbering, addressing, security, location management and user profile information to support network entities handling sessions.

Service Provisioning in IMS Service Provisioning Architecture Service provisioning in IMS is based on service control residing on home network (I.e. all the messages are routed through home operator S-CSCF) S-CSCF directs SIP messages to the right AS according the triggers downloaded from the HSS

IMS Service Capabilities and OMA Service Enablers IMS offers IMS Service Capabilities that can be used as building blocks for Service Enablers and services –Session management, user data access, event subscription and notification, messaging, data manipulation, conferencing OMA and 3GPP define SIP-based Service Enablers that are nor necessarily end-to-end services, but but capabilities that value added services are built on. –IMS Messaging, Presence, Push-to-Talk over Cellular (PoC), IMS Group Management, IMS Conferencing, IMS Charging

Challenges in Third Party Service Provisioning Network agnostic challengesIMS-specific challenges Security Ability to expose the full functionality of SIP ‑ enabled networks on the API. Hiding the network topology and exposing the service enablers so that they can be discovered in automat able and repeatable manner. Existence of applicable interfaces to SIP ‑ specific functionalities and services (i.e. IMS Service Capabilities and Service Enablers). Firewall Traversal Adding both manually and dynamically service triggers to the IMS system under operator supervision for third party service provider Performance Level of abstraction offered by the API that should be open and standardized. Third party not having to establish new relationships with many operators for the usage of Service Enablers that it might want to utilize. Maturity of the technology.

rd Party Service Provisioning Technologies Parlay/OSA: –A set of APIs that enable operators and third parties to make use of network functionality securely through open, and standardized interfaces defined by Joint API Group –Aim to progress from today’s single-service networks to multi-service networks, where the same service can be offered independent of the underlying connectivity and access networks. –Offers set of Service Enablers that in Parlay/OSA are called Service Capability Features for Applications’ use Call Control, User Interaction, Mobility, Terminal Capabilities, Data Session Control, Generic Messaging, Connectivity Manager, Account Management, Charging, Policy Management, Presence and Availability Management –The Parlay/OSA API relies on middleware technologies for the remote invocation of Parlay/OSA API method. There exist three technology realizations for this middleware transport technology in Parlay/OSA specifications. These are IDL for CORBA middleware, WSDL for SOAP over HTTP transport and JAIN Service Provider Access (SPA) for e.g. JAVA Remote Method Invocation (RMI).

rd Party Service Provisioning Technologies Web Services -Provides a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks even over the Internet. It also focuses in the external business-to-business integration -Initiatives in Parlay Web Services WG, Parlay X Work Group and OMA -Relies on Web Services technologies used in already in IT industry (XML, SOAP, WSDL and UDDI)

rd Party Service Provisioning Technologies SIP –In addition to Parlay/OSA, IMS environment offers SIP Application Server for provisioning of IP Multimedia services. IETF has proposed a view SIP Service APIs and scripts allowing the creation of SIP-based services –In the 3GPP specifications it is assumed that the SIP Application Server resides inside the operator domain (ISC ‑ interface is intra-operator interface), which means that in the case of third party service provisioning the service would have to be developed by trusted third parties and hosted by the operator –In case desiring the business model of Parlay/OSA for third party hosting its application external to the operator domain, an additional entity implementing the necessary Authentication, Authorization, and Accounting (AAA) mechanisms and service level agreements would have to be presented. –One solution could be adding a SIP AS Gateway in the middle acting the role of Presence Server. The Service Enablers would register themselves to the SIP AS and 3 rd parties could find those by subscribing the presence of all the presentities registered in the SIP AS gateway.

Vendor views: Vendor A

Vendor views: Vendor A in general Parlay/OSA with CORBA and SIP would be applicable for internal service providers offering call related services, while Parlay X could be offered for trusted third parties offering the same kind of services with limited functionality. Web Services Gateway then would be most applicable to value adding data applications and Internet-based data applications provided by both trusted and “untrusted” third parties.

Vendor views: Vendor B Vendor B sees that SIP offers limited functionalities to enable business model to open Telecom network to “untrusted” entities. Therefore vendor B assumes that SIP AS is within operator controlled environment. Otherwise, the IMS environment would need to be completed by additional firewalls or trust management enforcement systems in addition to Business-to-Business framework, which are not specified in standards. The technology that shall be provided depends on the type of application, time of deployment, expected characteristics, used operator business model and finally used capabilities and services.

Some Results Parlay/OSA –The mapping of OSA to SIP has not been properly described -> Mapping only for Call Control exists at the moment. –If the mappings will drive changes to the APIs, the target of Parlay/OSA of being network agnostic will break down. Then the same API could not be used for different networks, i.e. fixed, mobile or IMS. Therefore the Parlay/OSA being network agnostic is its strength and weakness. –Additional SCFs should be introduced to cover the service opportunities offered by IMS (e.g. Group Management, PoC) –CORBA-middleware creates problems when crossing enterprise and service provider firewalls -> OSA/Parlay used in most cases within the operator domain rather than as network opening mechanism Web Services –Is directed to wider Web development community –Performance, security pitfalls –Standardization of Web Services has been slow in the Telecommunications industry –Parlay-X doesn’t provide AAA, SLA and other specific capabilities -> if Parlay-X is to be provided to 3 rd parties outside operator domain, these functions should be provided by other means SIP –With SIP Service APIs and scripts one can generate all the parts of the SIP message -> complete mapping exists –Application Developer has to be expert on SIP protocol –The solution suggested is not standardized –It is claimed that service creation for new data services with SIP is faster than with OSA/Parlay

Conclusions and topics for future studies Parlay/OSA, Web Services and 3GPP IMS/SIP are not directly comparable, since they are focusing on different levels in the value chain of service providers. Therefore these technologies cannot be seen to replace each other, but rather complement each other. There is a challenge to find the right balance between the “bottom ‑ up” (capabilities first) and “top-down” approaches (use cases first) and choosing the best API-type and programming paradigms (i.e. CORBA, Java, SIP, WEB-tools) for each type of enabler. Future study should concentrate on finding the mapping of Presence to SIP and to find out whether PoC can be made available through Parlay/OSA Call Control Also the SIP-based third party service provisioning solution should be studied from the perspective of security

The Nordic and Baltic telecommunications leader Questions? Thank you for your attention!