Convergence of IMS and Web Services: A Review and A Novel Thin Client Based Architecture Salekul Islam and Jean-Charles Gr´egoire Institut national de la recherche scientifique, Montreal, Canada {islam, gregoire}@emt.inrs.ca Abstract—Although the IP Multimedia Subsystem (IMS) and Web Services have been developed on the basis of different Service Delivery Platforms (SDP), opportunities for new services have emerged from converged access to IMS and Web Services. Researchers are focusing on finding means to develop converged access architectures for IMS and Web Services while preserving the benefits they provide and not overburdening the end users’ terminals. In this paper, we classify the existing converged access methods for IMS and Web Services into four categories, compare them and identify their drawbacks. To address these drawbacks, we have designed a hybrid thin client-based novel architecture for converged access to multimedia services provided by a combination of IMS and Web Services. The proposed solution limits the impact of platform heterogeneity and resources by relinquishing the complexity of signalling and session management to an intermediate virtualization server, which in turn acts as a client for network-based services. Index terms–IMS services, Web Services, converged architecture, thin client, SOAP, SIP.

I. I NTRODUCTION Recent advances in converged business models have blurred the distinction between service providers and network operators (i.e. Mobile Network Operator (MNO) and Internet Service Provider (ISP)). Convergence is happening not only in business models but also in access networks (convergence of fixed and mobile networks or the telephony and the Internet worlds) and service domains (convergence of the voice, video, data and text). In legacy communication services, usages are billed either on a per unit or in flat-rate fashions. However, due to the widespread use of the Web, new trends of ad-based revenue models is getting popular, enabled through widgets, add-ons, apps, etc. In the future, a network operator will have to adopt an open and more flexible infrastructure to provide [1]: • Multiple traffic types including voice, data and video. • Multiple access types including wired and wireless. • Various levels of Quality of Service (QoS). • New and emerging business models. In this study, we are focusing on the convergence of two popular but orthogonal Service Delivery Platforms: Web and IMS services. The model of Web Service developed from the evolution of the Internet. The wide scale deployment and availability of the Internet leverages the use of Web. On the contrary, IMS deployment is not getting the expected momentum although its benefits are well established. IMS is designed as an overlay network and the underlying IMS core network is not a lightweight infrastructure. IMS is facing

real challenges from many popular non-SIP (Session Initiation Protocol [2]) services (e.g. IP/TV, Web 2.0 applications, online gaming, etc.), which bring their own infrastructures and lead us back to pre-IMS, stovepipe-based service models. To attract operators and service providers IMS needs to demonstrate that it is indeed a multi–service architecture which can be used as the common service framework even for non-SIP services, and certainly at least for Web Services. It is also worthwhile to note that, instead of full IMS deployment, the operators are more likely to migrate in a piecemeal fashion. Hence, a smooth migration can be achieved by supporting Web applications. Convergence of IMS and Web Services will bring the advantages of IMS and the simplicity of Web Services under the same business model. Hence, many research efforts could be found in the literature with similar goals but different ways. In this paper, we review the existing efforts, classify them, critically compare them and list their shortcomings. Next, we present a novel converged access architecture for IMS and Web services, which is based on the virtual desktop computing model. The rest of the paper is organized as follows: section II compares the IMS and Web Service models, section III observes the motivations behind the convergence, section IV presents in depth review on related work, section V briefly describes the thin client based virtual desktop computing model and presents our proposed converged access architecture. Finally, section VI concludes the paper. II. C OMPARISON OF IMS AND W EB S ERVICES IMS [3] is a SIP-based generic architectural framework for delivering voice, video and data communication services to mobile and fixed users. IMS breaks the traditional isolated, dedicated, per-service architecture, and introduces the application-oriented horizontal solution. Figure 1 shows how the IMS middle layer (i.e. the control layer) separates the service layer from the transport layer for greater flexibility. Thereby, the benefits of IMS are to provide, through the middleware, access–independent, streamlined, common mechanisms for billing, authentication, security, QoS, etc. Web Services are derived from the traditional client–server computing model. They allow inter-operation and communication of different applications, which may run on a variety of platforms and/or frameworks. Web Services support machineto-machine interaction over a network (e.g. Internet) using a combination of tools such as XML [4], SOAP [5], WSDL [6], UDDI, etc. The conventional Web Services architecture is

Transport Layer

UE

IP network

Control Layer

S-CSCF

P-CSCF

Service Layer

SIP-AS

HSS

UE

IMS Core

Fig. 1.

Simplified IMS architecture

composed of service provider, service consumer and directory service. A service provider publishes its services through a directory service using WSDL. A consumer knows about the service by querying the directory and then receives the service from the service provider. Given that all communications between a consumer and a provider are expressed in XML, Web services are not tied to any specific operating system or programming language. Although the traditional definition of Web Services requires the use of WSDL and SOAP for accessing data and services, some of the world’s most popular web services (e.g. Flickr, Twitter, Facebook) no longer depend on WSDL or SOAP. Hence, any service that provides an endpoint or endpoints for the retrieval and/or addition of data through a standard format over the HTTP(S) protocol may be considered as Web Services. We have summarized and also compared the service models for IMS and Web Services in Table I. III. M OTIVATION FOR CONVERGENCE The need for convergence of IMS and Web Services is a reality for a variety of reasons: in essence media communications do not exist in isolation. A communication can be associated with another service (e.g. eCommerce), require browsing (content, contact, etc.) or be embedded in a more generic application (e.g. universal messaging). Over the past few years, the IMS and Web Services have emerged as leading technologies within the telecommunications and IT industries, respectively. Hence, convergence of these two will bring many benefits. In the following, we have mentioned the important reasons for the convergence: a) Connectivity: Convergence will help to overcome the multi-device, multi-access challenges. In the era of hyperconnectivity, where anything that can be connected will be connected to the Internet and could be used for accessing or supporting services, the boundary between IMS and Web Services will disappear. Convergence will create a unique environment, where using the same User Equipment (UE) and IP connectivity, users will access indistinguishably services assembled from IMS and Web services. b) New business models: IMS operators can build new partnerships with the Web Services providers. Hence, Web Services could be offered to existing and potential IMS users. It will help IMS operators to attract the billions of customers who mainly depend on the Internet for accessing services right now.

c) Reusing legacy/existing services: Service providers are always keen to reuse their legacy/existing implementations for better returns on investment. Opening a window from the IMS network to the existing Web services can reduce the upfront cost and the time-to-market associated with bringing a new service offering to market. d) Enhanced user experience: Web services are consumed by the end user through web browsers. Hence, they are considered as user-centric services, which allow users to communicate and collaborate with greater ease, flexibility and efficiency. Future IMS services, by blending with Web services will provide enhanced user experience while being delivered through browsers and Web pages (e.g. Web-based softphone) instead of running separate SIP/IMS clients in the UE. e) Benefits through IMS core: IMS provides unified common mechanisms for authentications, QoS, billing, etc. New innovative applications that do not use SIP but would benefit from the capabilities of an IMS control infrastructure could be developed. Moreover, Web services could use many IMS facilities and reuse the IMS infrastructure, including the call identification, presence, mobile location information. IV. R ELATED WORK Service Oriented Architecture (SOA) is the established state-of-the-art for Service Delivery Platforms (SDP) and Web Services are the preferred standards-based way to realize SOA. The evolution of SOA concepts (e.g. Web Services) in telecommunications services is explained in [7]. Different proposals for convergence between the Web and telecommunication services (e.g. SIP and IMS services) have been proposed in the literature. We have classified the related work into four broad categories depending on the convergence architectures they have proposed. A. Combined Web and SIP services The generic approach of this method is implementing both SOAP and SIP clients at the UE and each client will access its specific services independently. Following this method, a framework has been proposed for the mobile peer-to-peer (P2P) Web services, which enables the creation of P2P Web applications using the mobile devices and within the IMS infrastructure [8]. Another combined implementation could be found in the parallel use of SIP and SOAP, where SIP is used for signalling in the control plane and SOAP is responsible for data transmission in the user plane. A unique Web Service ID is agreed upon between the two user terminals through the Service Description Protocol (SDP) [9] during session establishment. Similar use of SIP (for signalling) and SOAP (for exchanging application data) can also be found in the Akogrimo1 project [10], which focuses in scenarios where mobile dynamic virtual organizations require the ability to access data and compute intensive services from distributed, sometimes even mobile resources. In this approach, applications use SIP for session management, mobility, locating resources, 1 http://www.akogrimo.org/

TABLE I C OMPARISON OF IMS/SIP SERVICES AND W EB SERVICES Criteria

IMS

Web services

Definition

An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.

A networked application that is able to interact using standard application-to-application Web protocols over well-defined interfaces and which is described using a standard functional description language.

Key protocols

SIP—for session establishment, management and termination. Diameter—for AAA and mobility, Session Description Protocol (SDP)—for defining and negotiating media streams

XML—for exchanging data, SOAP—for providing messaging framework, WSDL—for describing public interfaces, protocol binding rules, etc. HTTP—for transporting SOAP.

Data/Media transport

RTP over UDP, MSRP over TCP for text and data.

SOAP allows text only. Multimedia streaming in Web services is still an open issue. At present, depends on MIME, SOAP with Attachments (SwA), XML-binary Optimized Packaging (XOP), etc.

Statefullness, Synchronous

SIP sessions are always stateful. Based on out–of–band signalling.

Stateless—each invocation contains all the information required to process a request. Based on query–response type synchronous communications.

Security

IMS-AKA for authentication, NDS/IP for inter-domain and intra-domain security.

Authentication by SAML/SSL/TLS, confidentiality and integrity by XML encryption/SSL/TLS, authorization by XACML, federation by WS-Federation, Liberty IDFF, etc.

Benefits

Security (symmetric), QoS, presence, billing, legacy integration, negotiation, fast deployment of new services.

Service discovery, mash up/new applications, reusability, loosely coupled, firewall friendly.

Drawbacks

Deployment cost is high: overlay architecture and the IMS core must be implemented.

No event/notification and negotiation (although proposals exist), no provision for QoS, security threats (SOAP over HTTP).

getting additional details about availability/status, etc. Once the session is established SOAP is used for exchanging service requests and responses. An instant group communication application, which is composed of both Web and IMS services, is implemented as a use case of finding technical challenges in developing converged Web and IMS services [11]. The advantage of this approach is better user and operator experience. It also showed how Web services and IMS services could enhance each other. B. SOAP over SIP UE SIP/SOAP client SIP / SIP(SOAP)

IMS App

Web App SOAP

SIP / SIP(SOAP) Network AS S-CSCF SIP P-CSCF

IMS Core

HTTP [12] is the most widely deployed protocol for transporting SOAP messages. However, the similarities between HTTP and SIP establish the eligibility of SIP as being an alternate SOAP transport protocol. An Internet Draft [13] explaining this idea was written, which proposed a new SIP method, called SERVICE. This method can carry a SOAP message as a SIP payload. Moreover, it is possible to map WSDL messages to Session Description Protocol (SDP) bodies and vice-versa. By exploiting this, idea a framework could be developed (which is shown in Figure 2) for accessing Web services through IMS connectivity and SIP signalling. In Figure 2, SIP and SOAP clients are implemented as a single client, which executes both IMS and Web applications. While invoking Web applications, SOAP messages will be sent inside SIP messages (denoted as SIP(SOAP) here). The border CSCF at the IMS core receives both SIP and SIP(SOAP) messages and forwards the SIP(SOAP) messages to a SOAP client, which is located at the edge of the IMS core. The SOAP client will extract the SOAP message and send it to the appropriate SOAP services using HTTP. The use of SOAP over SIP can be found in the Akogrimo project [10], which automatically adds session management mechanism, localization and security (privacy) handling to SOAP. C. SOAP-SIP Gateway (GW)

SIP(SOAP) HTTP

SOAP client SOAP HTTP

Fig. 2.

SOAP services

Accessing Web services through SOAP over SIP transportation

Figure 3 shows a SOAP↔SIP Gateway (GW) based architecture for invoking Web services within the IMS domain [14]. The UE is equipped with a SOAP client and is not aware of SIP. All the messages exchanged between the UE and the IMS domain should go through the GW. The GW receives

IMS P-CSCF

S-CSCF

HSS

UE SOAP client

SOAP over HTTP

SOAP stack SIP stack AS

SOAP over HTTP

SIP

SOAP

SIP GW

Fig. 3. Accessing services within the IMS domain through SOAP↔SIP GW [14]

SOAP messages (over HTTP) from the UE and generates corresponding SIP messages and vice-versa. There is no notion of session in Web Services. However, SIP messages are always exchanged within a session. Therefore, the GW also maintains a session mapping table, which stores the state of the particular session by parsing incoming messages. In [14], other possible use cases have been presented, where the mapping entity is implemented by modifying the client protocol stacks to support both SOAP and SIP clients. This is particularly advantageous, as it does not require the deployment of additional network nodes (i.e. GWs).

A SIP endpoint is composed of a SIP User Agent (UA) and a SIP application (which is built on top of the SIP UA). A SIP UA communicates with other SIP UAs through SIP signalling, and thus handles low level call control and media communications. The UA exposes a set of APIs to the SIP application, which interacts with the end users. A number of researchers have proposed different ways of accessing SIP services through SIP APIs from a Web client. The basic idea is shown in Figure 4. There should be a SIP exposure or wrapper layer, which will publish the SIP APIs as Web services. Therefore, a SOAP node will be created between the Web application and the SIP application. In the following we briefly discuss work building on this approach. SOAP node SOAP

Web Application

SIP exposure API SIP UA

Fig. 4.

Service

UA_A

UA_B

INVITE offer1 200 answer1 ACK

Session A1 INVITE 200 OK offer2

Session B

INVITE offer2' 200 answer2'

D. SIP API based

SOAP client Web Application

case study based on an instant group communication has been developed following two different approaches: Web portal and Web services API. In the Web portal approach, the communication between the Web-based applications and the IMS services was accomplished through Java Remote Method Invocation (RMI) technology. While, in the Web services API approach, an automatic SOAP API generator was used to generate Web services APIs for corresponding IMS services. The main advantage of these case studies is to show how IMS services could be accessed seamlessly even from legacy devices that only provides HTTP communication. WSIP (Web services SIP) [15] exposes the SIP UA as a SOAP node in the word of Web services without affecting the SIP protocol. It uses a Wrapper Layer Controller (WLC) to wrap the SIP UA’s API functions into XML and exposes them as Web services. The WSIP terminal, which sits in between a remote SIP UA and the Web application, adopts the event notification mechanism proposed in WS-Base Notification [16] to receive the SIP UA events.

SIP

SIP Application API SIP UA

Accessing SIP services from a SOAP client through SIP APIs

In [11], the IMS services have been exposed as Web services so that any HTTP-capable handset without SIP signalling ability can access IMS services just like usual Web services. A

Session A2

Fig. 5.

ACK answer2 ACK

RTP Media

SIP messaging sequence for a synchronous MakeCall service [17]

A Web Services–based architecture for delivering communication services (i.e. SIP services) as synchronous Web services is proposed in [17]. Figure 5 shows how an asynchronous SIP service, such as MakeCall could be converted to synchronous Web services. Using the MakeCall service, a Web application can initiate a call between two SIP UAs. The Service in Figure 5 acts as an abstraction between SIP and Web services, and it interacts synchronously with Web applications and at the same time asynchronously with SIP UAs. The WIMS 2.0 (Web 2.0 and IMS) [18] project2 focuses on the convergence of telecommunication networks with Web 2.0 by exposing the IMS capabilities through open Web APIs. Unlike the other approaches, WIMS 2.0 is not SOAP-specific, but rather it follows the Representational State Transfer (REST) [19] architectural guidelines. REST is not a protocol and works with freely defined information elements, known as resources, which are always individually identified by a specific URI. WIMS 2.0 also focuses on Portable Service Elements, User Generated Content publication and distribution in real-time, 2 http://www.wims20.org

IMS exposure layer

Web 2.0 user

IMS user

1. HTTP POST (URI MMTel Collection) 201 Created (Session URI)

2. SIP INVITE

3. HTTP GET (Session URI) HTTP 304 Not Modified

4. SIP 180 Ringing

5. HTTP GET (Session URI) HTTP 200 OK (Resource Modified)

6. SIP 200 OK

7. HTTP GET (Session URI)

SIP ACK

V. H YBRID THIN CLIENT BASED CONVERGENCE

HTTP 200 OK (Resource Modified) Session established 8. HTTP PUT (Session URI) HTTP 200 OK (Resource Modified)

9. SIP UPDATE SIP 200 OK 10. SIP UPDATE

11. HTTP GET (Session URI)

SIP 200 OK

HTTP 200 OK (Resource Modified) 12. HTTP DELETE (Session URI)

13. SIP BYE

200 OK

200 OK

Fig. 6.

network or implementing a new protocol stack) might be required. 4) Add node en-route: Processing of messages (e.g. passing through a GW or a translator) might be required on the way of the access network. 5) Transport protocol: It depends on tunnelling (if implemented), and the capabilities of the UE and the access network. 6) Other comments: In addition to the above mentioned criteria, specific benefits or drawbacks of the approaches are listed.

API operation for WIMS 2.0 [18]

and the Thin Clients to provide virtual terminal representations and ubiquitous access from any point of the Internet. Figure 6 shows the basic API operation for establishing communications between a Web 2.0 user and an IMS user. The operation of the API assumes that the actions on the resources and their attributes are translated into SIP procedures on the IMS side of the Exposure Layer, and vice versa. The Web 2.0 client first needs to select the collection associated to the service it wants to initiate, which is a Multimedia Telephony call in this example. This is performed by retrieving the users Service Document and selecting the appropriate collections URI. E. Summary of different approaches The summary of the existing work is presented in Table II. Instead of comparing all of them individually, we are considering the four different approaches that we have categorized in the prior section. The six following criteria have been chosen to characterize the comparisons: 1) UE implication: The convergence may introduce complexities at the users’ end (e.g. implementing more than one clients inside the UE). 2) Dominant service: Tunnelling is a popular means of accessing non-supported services (e.g. SIP services) through another available service platform (e.g. Web services). In case of tunnelling, the dominant service will be the one which is natively supported. Presumably, it is considered as widely deployed and easily available even in the future. 3) Effect on network: On the network end, additional implementation (e.g. adding a GW at the edge of IMS core

If we analyze the summary presented in the previous section, the following drawbacks of the existing methods are observed: 1) The existing converged architectures fail to treat both IMS and Web services equally as dominating services. 2) They are unable to distribute the implementation and the computing loads among the user end (i.e. UE), intermediate nodes and the terminating network end. 3) In many cases, one core protocol—either SIP or SOAP—is tunnelled, and hence loses its full functionalities. 4) Some of the solutions are based on the programming experiences of the researchers in different implementation related problems. The authors are keen to explain various difficulties (e.g. incompatibilities of open source implementations) they have faced while implementing the solution instead of presenting the problem from a researcher’s point of view and looking for an implementation–independent solution. 5) The existing methods mostly focus on designing a converged control plane for SIP and SOAP messages. However, how media (specially bulk media such as audio/video streaming) would be delivered under a SOAP foundation is not studied. While proposing a converged access architecture, we must follow a balanced way by dealing with both IMS and Web services with equal importance. Moreover, the challenge we address here is to find a way to achieve service integration closer to the user, in a flexible way while yet having a limited impact on the user’s platform. In the following we briefly explain the virtual desktop computing model first, and then establish how virtualization concepts could be exploited to achieve our design goals. A. Virtual desktop computing by thin client In the last decade, virtual desktop computing has been emerged as a solution for the increasing Total Cost of Ownership (TCO) and management cost, which also provides a centralized and secured storage for sensitive data. Virtual desktop computing avails the continued improvements in network bandwidth, cost, and ubiquity to return a cost effective, secured, and easy to manage computing strategy. Examples of popular virtual desktop solutions include Citrix Metaframe [20], Virtual Network Computing (VNC) and Sun Ray. The

TABLE II C OMPARISON AMONG DIFFERENT CONVERGENCE APPROACHES Criteria

Combined Web and IMS

SOAP over SIP

SOAP↔SIP GW

SIP API based

Dominant service

Limited to Web services only. SIP clients inside the UEs are implemented for providing mobility and session management to the Web services, and not for accessing IMS services.

End user receives SIP/IMS services as a regular service connecting to IMS network. Web services are dealt as third-party services and are tunneled through SIP signalling.

Limited for accessing Web services within the IMS network only.

Could access both services, although Web is the dominant one. Designed for accessing IMS services in the fashion of Web services.

UE implication

The UE implements both SIP and SOAP clients. Moreover, it maintains both SIP and SOAP sessions.

Although both SIP and SOAP clients are implemented in the UE, only SIP sessions are maintained by the UE.

No significant implication on the UE is required. UE is a standard SOAP client.

No significant implication on the UE is required. UE is a standard SOAP client

Effect on network

Minimal effect at the network end.

A dispatcher is implemented at the incoming edge of the IMS network to sort out SIP and SIP(SOAP messages). A SOAP client is also implemented at the outgoing edge of IMS network.

Web services are hosted as Application Server (AS) within the IMS network, and the SOAP stack is implemented on top of the SIP stack.

Minimal effect at the network end when the IMS/SIP exposure layer is implemented outside the network.

Add node en-route

Nothing has been added on the path.

Nothing has been added on the path.

The SOAP↔SIP GW is implemented en-route and all the signalling messages must pass through the GW. However, the GW might be implemented at the edge of the access network

An IMS/SIP exposure is implemented in between the SOAPenabled UE and the IMS network. All the signalling messages must pass through this exposure layer.

Transport protocol

SIP for signalling and SOAP for data transfer.

Given that SIP has no suitable method to transport SOAP messages, an extension to SIP would be needed.

SOAP over HTTP for communication between the UE and the GW and SIP for communication between the GW and the IMS network.

HTTP for communication between the UE and the exposure layer and SIP for communication between the exposure layer and the IMS network.

Other comments

Need SIP-aware (also known as sippifying application) Web services.

Transport of large SOAP messages can lead to problems for SIP. Many messages might be required due to the typical use of UDP transport layer, unless other support like MSRP is used. SIP will be deviated from its design goal. It will be departed from the intent of being a lightweight application layer protocol that separates signalling from media.

Nothing specific has been discussed for accessing SIP services. Even if the SIP session could be established using the GW, the transmission of media would have to be solved separately.

In case of RESTful implementation, the solution will not be dependent on SOAP. Synchronous exposure APIs should be built from asynchronous SIP messages.

virtual desktop computing is based on the thin client/server computing model, where a thin client might be a software client hosted from a terminal device (e.g. PC, PDA, cell phone, etc.) or it might be the hardware device itself (e.g. a console without permanent storage and processing capability). The thin server, which is connected to multiple back-end application servers, acts as a proxy server for those application servers and is responsible for all the processing, management, deployment, and support. The thin client and the thin server communicate using a Remote Display Protocol (RDP) (e.g. RDP from Microsoft3 ). The RDP creates the virtual image of the desktop at the clients’ end and transmits the user inputs (which are given through mouse, key strokes, etc) to the server. B. Proposed architecture Thin clients are cost effective for corporate use, e.g. for employees in offices or users of labs in schools, and they are currently being developed for large setups. Still, in our 3 http://support.microsoft.com/kb/186607

research, we consider that one of the major potential target groups are personal users who will use their terminal devices for person-to-person communications, group communications, social interactions, entertainment, etc. In this study, we are focusing on the converged access of Web and SIP-based services with minimum effect on the deployment at user end (e.g. avoid using special hardware for the user device or implementing new client software). Thin clients are being used for accessing Web sites through PDAs and other hand-held devices [21], and they could even be used in mobile wireless networks. However, accessing SIP/IMS services through thin clients has not been explored yet. Although the term “thin client” is used in some studies (e.g. in [22]) that target to access SIP/IMS services, they are not based on a standard thin client computing model. Rather, thin client refers to a client with limited capability. Hence, we are excluding those types of efforts (i.e. [22]) from our study. Unlike earlier solutions presented in the literature, which appear to have been based on the extension of an existing

AS ISC

Remote Server PDA

Cell phone

Local storage

IMS Core

Mobile access (2G / 3G / WiFi) P-CSCF

Fixed access (LAN, DSL, etc.)

S-CSCF

Gm IMS Client

Laptop

I-CSCF PC

Web

HSS

SIP Mr

Hybrid thin client RTP/RTCP/RTSP

Mp Media MRFP server

MRFC

MRF

Fig. 7.

Hybrid thin client based converged architecture

software base, we propose here a “greenfield” approach, independent of any specific technology. The thin client–based architecture we propose to provide converged access to HTTPbased and SIP-based services is shown in Figure 7. The access network may be wireline (e.g. LAN, DSL, etc.) or wireless (e.g. 3G or WiFi). Although we are interested in deploying thin clients to provide a converged access of IMS and Web services, our model is not similar to desktop virtualization. Given that the target users and the goals of desktop virtualization and our converged model are different, the traditional thin client computing model is not directly applicable in our solution. Our proposed architecture is a hybrid of thin client computing and traditional PC-based service model (which is also referred as thick client). However, due to its close proximity to the thin client computing model, we are referring it “hybrid thin client” in the rest of the paper. Our hybrid thin client solution proposes five major extensions to the existing thin client model: 1) Enhanced thin client: Pure (hardware-based) thin clients have many limitations, including very limited processing power, no audio or video encoding, no permanent data storage, etc. In our solution, a pure thin client would not be able to transport a wide range of data types, including voice, video and image that would be required for providing personal communications facilities. Therefore, a hybrid, lightweight, software-based, thin client will be designed for our solution. 2) Applications hosted at the remote server: In our model, the server never hosts the OS processes and it only executes different client-server applications. For example, for providing access to SIP services, a SIP client application is being hosted at the server. We must insist here on the fact that this server is the “compute server” of the thin client model, not a, say, Web “application server”. We distinguish the “remote server” of the thin client computing model from the “application server” of an Internet-based application client-server model. 3) A Web-based client: The existing RDP is restricted to keyboard/video/mouse (KVM) interactions whereas it should be possible to put more intelligence into the client, which however requires more flexible signalling. Therefore, the pro-

posed hybrid thin client uses HTTP to communicate with the remote server. HTTP is the most widely used, client-server based, application layer protocol. The HTTP client will be implemented inside the UEs and a Web-based user interface could be used to communication with the remote server. 4) Local data storage: In the thin computing model, the client side never (or hardly ever) stores any state or user information. For a corporate office or school environment this is a logical data model. However, for personal solutions, where users like to keep their personal information secret and sometimes carry (inside his hand-held device or laptop) all the time. Unlike pure thin clients, our model allows limited personal data storage inside the end user’s terminal device. There is here also a need for some middle ground between local and server-based storage. For example, users may want to leave agendas and contacts on a server rather than having to copy this information to multiple devices. On the other hand, they may not feel comfortable leaving confidential or copyrighted material (e.g. their music) on a remote server. 5) Direct media delivery to the client: The limitation of the thin client computing model tends to be the KVM-oriented protocols they use. Since the client receives a bitmap, we could not expect for smooth rendering of every kind of media (e.g. live video-streaming) at the thin client end. Ongoing research projects are looking for better solutions for realtime bulk-data transfer (e.g. multimedia streaming and interactive gaming) [23]. Using our enhanced thin clients, A/V media type data will be directly delivered to the thin client, which will be equipped with suitable codecs. C. Benefits through hybrid thin clients We expect to derive from the proposed access architecture the following benefits: 1) Converged access: The end user will benefit from converged access of all popular services from a single client. The hybrid thin client based architecture is not limited to IMS and Web services only. The modular design makes provision for future extensions by focusing the addition of new applications

at the remote server. For example, this service model could be used for Peer-to-Peer (P2P) file sharing systems, where the P2P client will be implemented inside the remote server and the collected data will be downloaded directly to the end user’s device. 2) Lightweight UE: The UE is free from the burden of supporting IMS clients even though it is enjoying all the benefits of IMS services. This will also apply to future extensions of our model to other services, where most of the complexity (e.g. implementing an IMS client) will be transferred to the remote server’s machine. Hence, a lightweight UE that is equipped with necessary resources to consume services (e.g. multimedia services) is sufficient to operate in our solution. 3) Network access mode agnosticism: Although IMS service availability should not be affected by the underlying network access method, IMS relies on the ISIM (IMS Subscriber Identity Module) application for completing registration through IMS AKA (Authentication and Key Agreement). The proposed solution depends on the remote server for registration and thus works without ISIM and independently of the network access method. The only network connectivity required is the reliable transmission of HTTP messages between the UE and the remote server. ISIM, or something equivalently robust will be implemented inside the remote server. 4) Multiplexing IMS registrations: The proposed model creates the opportunity of sharing a single IMS registration among multiple users. IMS supports multiple IM Public user Identities (IMPU) attached to a single IM Private user Identity (IMPI). An IMPU is assigned by the home network operator. IMS also supports IMPU-specific Service Profile, which is a collection of service and user related data. Moreover, a Globally Routable User Agent URI (GRUU) identity could be used to identify a unique combination of IMPU and UE instance that allows to address a SIP request to a specific combination of IMPU and UE. 5) Faster access to bulk media: Given that media will be delivered directly to the UE rather than coming through the remote server, faster access to bulk media and improved user experience will be attainable. VI. C ONCLUSION The thin client based converged model demonstrated in this paper is not limited to IMS and Web services. Rather similar concepts could be used for any other services where the implementation and signalling complexities could be offloaded to an intermediate remote server as demonstrated by our proposed solution. Specifically, for mobile networks, where the mobile device is expected to be equipped with limited resources, a hybrid thin client based architecture will be most attractive. In future work, we would like to implement our converged access architecture for a use case of IMS application. The remote server is the focal point of computing and processing in our solution. Hence, its performance should be measured through a simulation study. Finally, the end-to-end media negotiation and resource reservation between a UE and the

MRF will have to be solved using SDP request/response protocol. R EFERENCES [1] G. Dorbes and H. Amoss´e, “Combining Web 2.0 and IMS: The Road to New Services and Business Models,” Enriching Communications, vol. 2, no. 1, 2008. [2] J. Rosenberg, et al., “SIP: Session Initiation Protocol,” RFC 3261, Jun. 2002. [3] “3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS), Stage 2”. 3GPP TS 23.228 V8.5.0, Jun. 2008. [4] “Extensible Markup Language (XML) 1.0 (Fifth Edition)”. W3C Recommendation, Nov. 2008. [Online]. Available: http://www.w3.org/TR/REC-xml [5] “SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)”. W3C Recommendation, Apr. 2007. [Online]. Available: http://www.w3.org/TR/soap12-part1 [6] “Web Services Description Language (WSDL) 1.1”. W3C Note, Mar. 2001. [Online]. Available: http://www.w3.org/TR/wsdl [7] T. Magedanz, N. Blum, and S. Dutkowski, “Evolution of SOA Concepts in Telecommunications,” IEEE Computer Magazine, pp. 46–50, nov 2007. [8] G. Gehlen, et al., “Mobile P2P Web Services using SIP,” Mobile Information Systems, vol. 3, pp. 165–185, 2007. [9] M. Handley, et al., “SDP: Session Description Protocol,” RFC 4566, Jul. 2006. [10] “Overall Network Middleware Requirements Report, Version 1.1,” Akogrimo Deliverable D.4.2.1, avaialble at http://www.akogrimo.org/download/Deliverables/Akogrimo D.4.2.1 v1.1.pdf, 2005. [11] D. Mansutti, et al., “Study Case on the convergence of Web Services and IM,” in Proc. of 11th International Conference on Intelligence in service delivery Networks, France, Oct. 2007. [12] R. Fielding, et al., “Hypertext Transfer Protocol – HTTP/1.1,” RFC 2616, Jun. 1999. [13] N. Deason. (2000) “SIP and SOAP”. Internet Draft, Work in progress. [Online]. Available: http://tools.ietf.org/id/draft-deason-sip-soap-00.txt [14] R. Levenshteyn and I. Fikouras, “Mobile services interworking for IMS and XML Web Services,” IEEE Communications Magazine, pp. 80–87, Sep. 2006. [15] F. Liu, et al., “WSIP - Web Service SIP Endpoint for Converged Multimedia/Multimodal Communication over IP,” in Proc. of IEEE International Conference on Web Services, San Diego, California, Jun. 2004, p. 690. [16] S. Graham, et. al. (2004) “Web Services Base Notification (WS-Base Notification) Version 1.0”. [Online]. Available: http://www.ibm.com/developerworks/library/specification/wsnotification/ [17] K. Rezabeigi, A. Vafaei, and N. Movahhedinia, “A Web Services based Architecture for NGN Services Delivery,” World Academy of Science, Engineering and Technology, vol. 43, pp. 472–476, Jul. 2008. [18] D. Lozano, L.A. Galindo, and L. Garcia, “WIMS 2.0: Converging IMS and Web 2.0. Designing REST APIs for the exposure of session-based IMS capabilities,” in Proc. of The Second International Conference on Next Generation Mobile Applications, Services, and Technologies. [19] R.T. Fielding and R.N. Taylor, “Principled Design of the Modern Web Architecture,” in Proc. of the 22nd International Conference on Software Engineering, Ireland, Jun. 2000, pp. 407–416. [20] “Citrix MetaFrame 1.8 Backgrounder,” Citrix White Paper, Citrix Systems, Jun. 1998. [21] A.M. Lai, et. al, “Improving Web Browsing on Wireless PDAs Using Thin-Client Computing,” in Proc. of the 13th international conference on World Wide Web, New York, NY, USA, 2004, pp. 143–154. [22] X. Zheng, V. Oleshchuk, and H. Jiao, “A System Architecture for SIP/IMS-based Multimedia Services,” T. Sobh, et al. (eds.), Novel Algorithms and Techniques In Telecommunications, Automation and Industrial Electronics, pp. 543–548, 2008. [23] D. De Winter, et. al, “A Hybrid Thin-Client protocol for Multimedia Streaming and Interactive Gaming Applications,” in Proc. the International Workshop on Network and Operating Systems Support for Digital Audio and Video, Newport, Rhode Island, 2006.