Converging Web and IMS services: stakes and solution proposals

Transcription

1 Converging Web and IMS services: stakes and solution proposals Karim Sbata Houda Khrouf Sabine Zander ge-ftgroup.com Monique Becker Télécom ParisSud 9, rue Charles Fourier Evry ABSTRACT operators will be facing during the next few years. Indeed, recent evolutions like smartphones' enhanced web-browsing capabilities (e.g. IPhone) and the technical incursion of Web2.0 main actors in the Telco world (e.g. Android) points out that this convergence is necessary and unavoidable. As converging Web and Telco consists mainly on converging Web2.0 and IMS services, this paper will focus on this point. We will first provide an overview of the involved technologies and the convergence stakes. Thus we will present the different solutions that have been proposed so far and finally expose TEWCOP (stands for TElco and Web COnverging Protocol), our proposition, through a set of significant use cases. Keywords Web-Telco convergence, Web2.0, IMS 1. INTRODUCTION Converging Web and Telco is a key challenge for the next few years. Technically, it consists mainly on converging Web2.0 and IMS services. IMS is an IP-based architecture that has been defined to increase the ability of Telco operators to provide valueadded services. It provides a significant enhancement to Telco users' experience but, as it does not interact natively with Web services, it does not allow these users to benefit from the rich Web2.0 service offer. And the same stands for Web2.0. It is then necessary to create some correlation between the huge number of Telco and Web services, and take profit from the user experience through the interaction of Web 2.0 and IMS architecture. Several solutions have been studied and proposed so far to achieve this Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MEDES 2009, October 27-30, 2009, Lyon, France. Copyright ACM ACM /09/0010.$ /08/0003.$5.00. convergence, providing variable capabilities with variable impacts on the existing technical ecosystem. This paper will try to give a classified overview of what has been done so far and present an alternative solution TEWCOP (stands for TElco and Web COnverging Protocol) - based on a convergent protocol whose objective is to provide a deeper convergence to potentially open more opportunities. 2. INVOLVED TECHNOLOGIES For a better understanding of the next sections of this article, we provide hereafter a brief description of the two main technologies that are involved in the Web-Telco convergence: Web2.0 and IMS. 2.1 Web 2.0 services "Web 2.0" refers to a second generation of web development and design, that facilitates communication, secure information sharing, interoperability, and collaboration on the World Wide Web. Web 2.0 concepts have led to the development and evolution of web-based communities, hosted services, and applications such as social-networking sites, video-sharing sites, wikis, blogs, mashup and folksonomies. Web 2.0 websites allow users to do more than just retrieve information. They can build on the interactive facilities of "Web 1.0" to provide "Network as platform" computing, allowing users to run software-applications entirely through a browser. Users can own the data on a Web 2.0 site and exercise control over that data. These sites may have an "Architecture of participation" that encourages users to add value to the application as they use it. This stands in contrast to traditional websites, the sort that limited visitors to viewing and whose content only the site's owner could modify. Web 2.0 sites often feature a rich, user-friendly interface based on Ajax and similar client-side interactivity frameworks, or full client-server application frameworks such as OpenLaszlo, Flex, and the ZK framework. 2.2 IMS The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision

2 for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line. The IMS core is divided into 3 main layers: Common IP core, Common Service Capabilities and Service layer. It is characterized by the usage of the SIP protocol for signalling and control functions. The following figure illustrates the evolution of service networks architecture from a vertical to horizontal layering. Figure 1. IMS architecture 3. CONVERGENCE STAKES operators will be facing during the next few years. Indeed, recent evolutions like smartphones' enhanced web-browsing capabilities (e.g. IPhone) and the technical incursion of Web2.0 main actors in the Telco world (e.g. Android) points out that both worlds will benefit from this convergence. Telco operators will enhance their position and role in a global service ecosystem, evolving from simple data carriers providing dumb pipes to service providers offering smart pipes and thus gaining control of the extended value chain. Whereas Web and IT actors will improve their service offer by enhancing existing IT services with Telco assets, mainly customers' knowledge (user profile and usage context) and network improved functionalities like signalling control, adapted QoS, reliable authentication and charging functionalities. 4. RELATED WORKS Several solutions have been proposed already. We try to present the most relevant subset of them in this section. They are classified according to their level of impact on the Web/IMS systems, i.e. the architecture and cost effort to deploy them within an IMS Core. 4.1 Low level of integration The solutions mentioned here work on the top of IMS at application layer and do not require changes of the Core. They could be referred to as convergent Application servers (default B2BUA) with SIP south bound interface and a protocol transported over HTTP in the north bound interface. Acting as Telco services or network enablers, they could be used by Web consumers through web APIs (e.g. Orange APIs [1]) or through a service delivery platform (e.g. Ribbit [2]). Examples of convergent AS are the Orange Instant Location API or the Orange Personal Profile API. WIMS 2.0 [3], a solution developed by Telefónica, is another example of low-level integration. It provides access to IMS capabilities through open APIs in addition to added value services such as a tool named Portable Service Elements to be integrated in Web2.0 sites to ease the interactions between third parties and operators, an optimized content and information management to allow downloading, adapting and transmitting contents and events from Web 2.0 services to IMS users and vice versa. Another approach consists on using service composition and orchestration. The Orange Broadband Multimedia Service architecture [4] uses both Telco services and Web services to build new rich services that can be exposed through SOAP APIs to 3rd party developers. BMS service adds an orchestration layer over the IMS architecture which is responsible to manage the service logic and delegate to specific enablers the actions to perform. At last, there are also initiatives which facilitate the network service delivery to Web terminals such as Flash/SIP solutions proposed by Telco vendors like Nexcom[5] or Dilithium[6], based on introducing IMS capabilities in a Web gateway while the user application is embedded in a standard Web page. 4.2 Moderated level of integration The following solutions imply a moderated level of integration as they introduce new entities and interfaces within the IMS core network. Amongst them, the WSC (Web Session Controller) initiative [7] introduces a new entity at the border of the IMS network called WCF (Web Control Function) that controls the communications between IMS and Web through a new entity in charge of the media flows: the WMG (Web Media Gateway). The IMS 2.0 architecture [8] is another example of moderated level of convergence. It introduces two new elements to the IMS architecture: the IMS/Web 2.0 gateway and IMS/web 2.0 service broker. The first one is used as a border point between the Web and IMS, mainly used to translate HTTP to SIP and vice versa. It provides access to IMS services/enablers through REST APIs for Web clients and to registered web services for IMS entities. The IMS/web 2.0 service broker is an intelligent entity hosted in the IMS domain, which is responsible for registering, orchestrating and hosting common IMS 2.0 resources. It is positioned on the signalling path of network IMS entities (between CSCF and AS) and has an interface towards the HSS. However this solution has no direct control of the media plan. 4.3 High level of integration This section concerns solutions that impact strongly the existing architecture (IMS Core and Web), mainly at the protocol level (SIP and/or HTTP evolutions). They try to address the convergence issue from the basis by converging/merging both Web and IMS protocols, providing thus a higher level of convergence for a larger set of use cases. Currently, very few converging solutions belong to this category, cost and time issues often discouraging researchers from exploring further this alternative in spite of the perspectives it might offer. Indeed, communication systems and human languages are very much alike: the highest is the level of integration, the richer are the

3 possibilities it might offer and the easier is its usage (simplified integration). Using translators might be very useful (and sometimes unavoidable) but speaking a common language has always been the better way to communicate. 5.OUR APPROACH We focused our investigation on how we could provide the highest level of integration at the lowest cost and the maximal backward compatibility. We figured out that an efficient solution should bet to define a new protocol, TEWCOP (stands for TElco and Web COnverging Protocol), that covers both Web and IMS communications requirements and still able to communicate with legacy components. 5.1Comparing Web and IMS communications Prior to defining the new converging protocol, we have first to study and compare both Web and IMS main service protocols: HTTP and SIP. The objective is to identify their overlapping features and their differences and try to figure out the better way to make use of them Similarities First of all, SIP and HTTP are both TCP/IP protocols and belong to the same layer. Their main roles are thus similar in terms of layer functionalities. This is an obvious prerequisite to any type of convergence. Moreover, the fact that both protocols belong to the same model (TCP/IP) implies that a converging protocol might be possible using a common transport protocol (more likely TCP) for both standard and legacy requests. Moreover, SIP has been defined on an HTTP basis. Their structure and syntax are thus close enough to consider a converging protocol based on the same model. This point is crucial for backward compatibility. Indeed, using a unique model does not prevent backward compatibility but only raises some issues that could be resolved Differences HTTP and SIP are very close in terms of syntax and role but they are quite different in terms of functioning. Indeed, HTTP has been defined initially for static resource handling and evolved to manage dynamic resources and services whereas SIP is Telcooriented as it has been introduced for conversational session initiation. As a consequence, HTTP and SIP differ on at least three points: media flows, session management and synchronism. Indeed, HTTP is resource oriented and does not separate signalling from media flow, whereas SIP deals mainly with signalling, except for some specific applications (e.g. Instant Messaging using SIMPLE). Concerning session management, Web services using HTTP are typically stateless, meaning that each invocation contains all the information it needs to process the request. The Web service provider does not keep any information about its Web service consumers. However, in some particular contexts, Web services have to be stateful, introducing a need from session management. To solve this issue, HTTP manages sessions either via cookies or by adding session information (e.g. session_id, user identity) in extended HTTP headers. On the other hand, SIP is natively stateful, capable of maintaining the state of a process or transaction when two parties negotiate a session. It manages natively the session attributes like the state of the session (ringing, terminating, etc), the session type (Voice, IM) using headers and SDP protocol. Last but not least, HTTP communications are synchronous whereas SIP supports asynchronous exchanges. Indeed, HTTP works in a strict client/server mode (Web servers can not initiate a communication with Web clients) whereas SIP user agents may work in both modes simultaneously (e.g. SUBSCRIBE / mechanism for Presence applications). As far as HTTP was used for resource download, its synchronism was not problematic. But in a Web 2.0 context, it became an issue, often solved using polling. 5.2Issues and solutions As mentioned above, HTTP and SIP are very close technically but present several functional differences that TEWCOP should overcome Backward compatibility TEWCOP should be backward compatible with both SIP and HTTP protocols. This means that: (a) HTTP or SIP clients should be able to communicate with TEWCOP servers; (b) TEWCOP clients should be able to communicate with SIP and HTTP servers. This compatibility imposes that both HTTP and SIP should be a subset of TEWCOP. As a consequence, TEWCOP should support all the methods defined by both protocols:, POST, HEAD, PUT,, OPTIONS, SUBSCRIBE,, ACK, BYE, REGISTER, etc. As for HTTP and SIP, TEWCOP may define a set of extended methods and headers. Moreover, to ensure (a), TEWCOP needs a specific version management. Requests using HTTP methods should use versions in the form of TEWCOP/x.y or HTTP/x.y and requests using SIP methods should use versions in the form of TEWCOP/x.y or SIP/x.y. Ensuring (b) is a little more complex. TEWCOP clients need to know what kind of server they are requesting. This can be achieved through a specific OPTIONS query using a TEWCOP version prior to any query to a new server. In case the server is a legacy server, TEWCOP clients will use the standard "Unsupported protocol" error messages to determine whether the server supports HTTP or SIP. In case the server supports TEWCOP, the response should be a TEWCOP "200 OK", containing eventually information about the server's capabilities and extensions support Session management TEWCOP should support both stateful and stateless modes for all its methods. For methods inherited from HTTP, the stateless mode should be used with legacy clients and the stateful mode with TEWCOP clients. For methods inherited from SIP, the stateful mode should be used for legacy while TEWCOP clients may use both modes. In a stateful mode, the session should be managed like it is in SIP, using specific headers such as the SIP Call-id which insures that all messages are related to a single call and the SIP Cseq which is used to match a response to its specific request

4 5.2.3Routing Whereas HTTP communications relies only on IP routing, SIP defines a set of headers dedicated to an additional routing mechanism: Via, Route and Record-Route. TEWCOP should inherit these headers and use them for all its methods. It may open perspectives in terms of service composition and orchestration Synchronism Actually, synchronism does not raise specific issues but opens more perspective to Web-oriented applications using TEWCOP. SUBSCRIBE and mechanisms should replace polling workarounds Identity and security issues Both IMS and the Web have defined several authentication mechanisms especially in a mobile context. Mobile IMS users are authenticated thanks to the Authentication Key Agreement (AKA) protocol where a long-term secret key is shared between the ISIM (smart card) and the AuC (Authentication center). For mobile Web users, 3GPP has defined a Generic Bootstrapping Architecture (GBA) [14] that uses a shared secret key between a client and application, and it is based on AKA and Digest mechanisms. It generates a hashed password computed with the key stored in the USIM and a random value sent by the server. Currently, TEWCOP does not specify any specific authentication mechanism. It is part of the prospective work that need to be done. 5.3Significant use cases To illustrate our approach, several use cases have been studied. Three of them are detailed below Content sharing The first use case is related to a live content sharing application, as illustrated by figure 3. User A User B Data Server Subscribe Notify POST Notify Figure 3. Content sharing call flow The scenario of this use case is the following: - User A subscribes to User B's updates - User B is notified and accepts (or rejects) the subscription - User B posts some content on the data server - User A receives a notification of a new submission by User B - User A downloads the new content This use case can be by a social network application where users may need to notify instantly their friends about their updates. This use case is completely stateful. Session headers should be included in every message, even for methods inherited from HTTP Seamless client switching The second use case deals with multi-terminal management through the example of a user switching from its computer to its mobile while connected to a game server: - User A initiates a session with the game server on their computer, downloads the game client components and starts playing (sending data to the server) - User A decides to get out but they still want to continue the game. From their computer, they send a REFER request to their mobile phone. - User A initiates a session on their mobile phone while the computer application receives notifications about the status of the new session. - Once the new session is OK, the computer terminates its session by sending a BYE request. - User A continues the game from their mobile. The call flow is illustrated by figure 4. User A (PC) POST (game info) REFER (to A Mobile) 202 Accepted BYE User A (Mobile) (game info) 5.3.3Enhanced communication The third use case is related to enhanced communications that allows end users to access resources and services during a call. An application of this use case might be document sharing during a conference call, sending "Terms and Conditions" and asking for approval during a commercial call. The scenario of this use case is the following: Game Server Figure 4. Seamless client switching

5 - User A calls User B and starts to talk (RTP session) - User B asks User A to request a specific resource or service from the server using a REFER request - User A accepts and gets the resource from the server - User A notifies User B that the request has been processed Figure 5 illustrates the call flow of this use case. Call (RTP session) User A User B Server 180 Ringing ACK RTP REFER 202 Accepted BYE Figure 5. Enhanced communication 6.CONCLUSION AND PROSPECTS operators will be facing during the next few years. In this paper, we provided an overview of the involved technologies (IMS and Web) and the convergence stakes. We presented and compared then the different solutions that have been proposed so far. At last, we introduced TEWCOP, our proposition of converging protocol and illustrated it through a set of significant use cases. TEWCOP s objective is to ensure the highest level of convergence possible without sacrifiying the compatibility with the legacy networks or avoiding cost and time issues. Concerning our future works, TEWCOP is still under specification. Its main features has been identifed but they need further deepening. Besides, there are still some issues to be treated (e.g. authentication). Once the specifications are mature enough, we plan to protoype TEWCOP and test it through the implementation of a global communication testbed made of new component and legacy components from both IMS and Web worlds. In parallel, a standardization effort should be done. As TEWCOP inherits from both SIP and HTTP, it seems relevant to submit its specifications to the standardization process of the IETF. 7.ACKNOWLEDGMENTS This work is supported by SERVERY[9], a European project of the Celtic Initiative, whose goal is to enable a Service Market Place that bridges the Internet and Telco worlds by merging the flexibility and openness of the former with the trustworthiness and reliability of the latter. 8.REFERENCES [1] Orange APIs, [2] Ribbit Service Platform, [3] Lozano, D. Luis A, G and Luis, G WIMS 2.0: Converging IMS and Web 2.0. Designing REST APIs for the exposure of session-based IMS capabilities. [4] Sauvage, F, "Broadband Multimedia Service". [5] Nexpresso Flash Gateway, [6] Dilithium Flash/SIP, s_news_2008/ _vivas_flash.asp [7] Forestier, F and Zakhama, N Web Session Controller: an opportunity for IMS/Web convergence. France Telecom R&D. [8] Jain, M and Prokopi, M The IMS 2.0 Service Architecture. France Telecom R&D UK Ltd. [9] Fodor, S., , Advanced Service Architecture and Service Delivery Environment, [10] SIP : Session Initiation Protocol, RFC 3261, [11] Hypertext Transfer Protocol, RFC 2616, [12] HTTP: Basic and Digest Access Authentication, RFC 2617, [13] HTTP Digest Authentication Using AKA, RFC [14] Generic Authentication Architecture (GAA); Generic bootstrapping architecture (GBA) TS GPP