Universal User Interface for IMS clients

Universal User Interface for IMS clients Do Van Thanh a, Ivar Jørstad b, Pål Løkstad c, Dao van Tran d & Do Van Thuan e a thanh-van.do@telenor.com Telenor R&D NTNU - Snarøyveien 30, NO-1331 Fornebu Norway b ivar@ubisafe.no Ubisafe - Gamleveien 252, NO-2624 Lillehammer Norway c pal.lokstad@telenor.com Telenor R&D - Snarøyveien 30, NO-1331 Fornebu Norway d dao.van.tran@telenor.com Telenor R&D - Snarøyveien 30, NO-1331 Fornebu Norway e t.do@linus.no Linus - Martin Lingesvei 15-25, NO-1367 Snarøya Norway Abstract This paper presents a solution that provides a uniform user experience over a large set of heterogeneous IMS client devices. The idea is to remove IMS client UI from the user IMS device and place it in a network server accessible everywhere in the world. The paper starts with a description of the state-of-the art IMS clients. Next, the proposed solution will be presented and the benefits in terms of flexibility and user-friendliness will be analysed carefully. The additional security features are also explained. Last but not least, a proof-of-concept implementation will be described. Keywords: IMS client, IMS client User Interface, Uniform user experience 1 Introduction One of the key success factors of IMS (IP Multimedia Subsystem) [1] is not only the availability of the IMS clients but also the user experience that the clients offer. To deploy IMS in fixed-mobile convergent environments requires a larger range of usable IMS clients for both fixed and mobile devices. The challenge lies in the fact that the diversity in terms of dimensions (e.g. display size, resolution, key board, etc.), capabilities (e.g. processing, storage, battery life, etc.) and technologies (Wireless, wired, etc.) poses serious problems for the construction of good IMS clients. In addition, it is difficult to provide a uniform user experience across a large set of heterogeneous devices. This paper presents a solution called Universal User Interface that overcomes all the mentioned issues by separating the user interface from the IMS client and moving it to a network server. The paper starts with a description of the state-of-the art IMS clients. Next, the proposed solution will be presented and the benefits in terms of flexibility and user-friendliness will be analysed carefully. The additional security features are also explained. Last but not least, a proof-of-concept implementation will be described. 2 State-of-the art IMS client Although there is no universal standard for IMS clients there are currently many activities focusing in the specification of IMS client such as the Java Community Process JSR-281 [2], Open Mobile Terminal Platform (OMTP) IMS Functional Requirements work item [3], Eurescom study P1656 Definition of an open and extendible IMS Client Framework and they all result to a quite identical architecture for the IMS client framework. Non-IMS (e.g. Browsing) Non IMS API Non-IMS Service Enablers Non-IMS Related Prot Combined Non-IMS &IMS IMS Client Framework Non-Standard (e.g. IMS based Game) Core APIs Combined (e.g.ims base Game + PoC) IMS Core (Session, QoS Mgmt, Basic Messaging, Registration & Authentication) Services APIs Standard (e.g. PoC, IM) IMS Service Enablers (Presence, IM, PoC, XDM) IMS Related Protocols & Stacks (RTP, SIP, SDP, XCAP) APIs OS Level Hardware Platform Figure 1 Architecture of an IMS enabled mobile phone proposed by Eurescom P1656 As shown in Figure 1, the IMS client framework architecture (proposed by Eurescom P1656) is structured in four main layers: Hardware Platform: This layer comprises all the hardware elements (e.g. Camera, Display, UICC (Universal Integrated Circuit Card), etc.) available on the device. OS Level: This layer gathers all the software modules built on top of the hardware platform. Its main responsibility is implementing the functionality needed in order to offer mobile services. This level includes also the IMS Service Enablers that offers functionality to the end-to-end services. APIs: The API layer exposes the functionality implemented in the OS Level via a programmatic interface that makes possible application development. Although the API layer has been represented as a single module for the sake of the

simplicity it is also possible to have different API sets (e.g. Java, C++, etc.) using a single OS Level Framework. This layer includes IMS Core APIs, IMS service APIs and also non-ims APIs. : This layer comprises all the applications available on the device in order to offer a service to end-user (e.g. a game, an Instant Messaging Client, etc.). The user interface is also included in this layer. There is no doubt that the proposed IMS client framework will alleviate the construction of IMS client since all the necessary IMS functions are made available through the standardised IMS Core APIs and IMS service APIs. In addition, the portability of the clients is considerably improved but some modifications are still required to adapt the user interface to the specific physical dimension of the devices like screen size, resolution, keyboard, pointing device, etc. With the diversity of IMS devices this can be a tedious task. 3 The Universal user interface solution The most direct way to circumvent the problem of user interface is to remove it completely from the IMS user device. Indeed, we propose to move the user interface of the IMS client to a network server. Browser Non IMS API Non-IMS Service Enablers Non-IMS Prot IMS Core API IMS Core http App. level IMS Service Enablers IMS Related Protocols & Stacks Hardware Platform User Mobile phones PCs Services APIs OS level Internet IP Network IMS Client User Interface Web Server IMS Service Enabler Server IMS CORE Figure 2 Overall architecture of the Universal user interface IMS API As shown in Figure 2, there will be no IMS client application offering interface to the user. Instead, a regular browser e.g. Opera, Internet explorer, Mozilla, Nokia, etc. is used to communicate with an IMS Client User Interface Server. After proper login and authentication, the Client User Interface Server will generate IMS Client Web pages that are tailored to fit both the browser in use and the preferences of the user. In fact, the IMS Client Web pages are acting as an intelligent IMS Client which is capable to adapt itself. The customisation for the user can be done according to: o The functionality of the IMS Client o The look and feel of the IMS Client 3.1 Dynamic User Interface To achieve high level of dynamicity, JSP (Java Server Page)[6] is used to match cascading style sheets (CSS) [7] to different user agents or browsers. The style and layout information of a document is specified according to CSS rules and stored in a separate document called style sheet. To change the look and feel of a document in a browser, one just needs to alter the CSS style sheet or preferably use another style sheet. This feature is very useful in the mobile world where mobile phones have very varied characteristics such as screen size, resolution, etc. To obtain best presentation of a given content on a mobile device, a CSS style sheet is made for it. To illustrate how JSP matches CSS style sheet for a browser let us consider three browsers: Nokia's mobile phone browsers, Sony Ericsson's mobile phone browsers and desktop Web browsers The CSS style sheet for Nokia is as follows: h1 { font-weight: normal; text-align: center For Sony Ericsson the heading should be displayed in bold type and aligned left as follows: h1 { font-weight: bold; text-align: left As desktop computers have large screens, the text shall be displayed in extra large as follows: size.body { font-size: x-large The sample JSP code demonstrating how to match CSS cascading style sheets to different client browsers by detecting the user agent when the XHTML document is requested is shown in Figure 3. The following sequence of actions has been executed: 1. The user-agent HTTP header value is obtained and is assigned to the variable uaheader. String uaheader = request.getheader("useragent"); 2. The variable uaheader is checked to see whether it contains the words "Nokia", "SonyEricsson" or "Mozilla". The indexof(string str) method of the

String object returns the index of the first occurrence of the str substring. If str is not found, -1 is returned by the indexof(string str) method. In other words, if str is found, the return value will not be -1. If the variable uaheader contains "Nokia", it means the user agent is a Nokia mobile phone browser and the URL of the external cascading style sheet is changed to nokia.css. <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/dtd/xhtmlmobile10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> String uaheader = request.getheader("user-agent"); if (uaheader.indexof("nokia")!= -1){ <link href="nokia.css" else if (uaheader.indexof("sonyericsson")!= -1){ <link href="sonyericsson.css" else if (uaheader.indexof("mozilla")!= - 1){ <link href="webbrowser.css" <title>ims CLIENT PROTOTYPE</title> </head> <body> <h1>hello, welcome to our IMS Client.</h1> <hr/> <p> Function Menu:<br/> IMS Function 1<br/> IMS Function 2<br/> IMS Function 3<br/> </p> </body> </html> Figure 3 Sample of JSP code to match CSS cascading style sheets to different client browsers if (uaheader.indexof("nokia")!= -1){ <link href="nokia.css" Otherwise if the variable uaheader contains "SonyEricsson", it means the user agent is a Sony Ericsson mobile phone browser and the URL of the external cascading style sheet is changed to sonyericsson.css. else if (uaheader.indexof("sonyericsson")!= -1){ <link href="sonyericsson.css" Otherwise if the variable uaheader contains "Mozilla", it means the user agent is a desktop web browser (like IE, Firefox and Mozilla) and the URL of the external cascading style sheet is changed to webbrowser.css. else if (uaheader.indexof("mozilla")!= - 1){ <link href="webbrowser.css" Note that we have to check for the word "Mozilla" in the last "else if" statement since the user-agent header value of some mobile phone browsers may contain the word "Mozilla" and this can lead to a wrong identification. 3.2 Interfacing with IMS The IMS Client User Interface server is communicating to the IMS Service Enabler Server on the network side via IMS APIs which are implemented as a Web service APIs (Application Programme Interface). This interface enables the establishment of IMS sessions by enabling the invocation of appropriate IMS methods upon the user s request. The following IMS APIs are implemented:

o o o Call Handling: o makecall: This operation requests to setup a voice call between two addresses, calling Party and called Party, provided that the invoking application is allowed to connect them. o getcallinformation: This operation retrieves the current status, call Information of the call identified by CallIdentifier. o endcall: This operation terminates the call identified by callidentifier. o cancelcall: This operation cancels the previously requested call identified by callidentifier. Presence Handling: o publishpresence: This operation provides presence information to the Presence server o subscribepresence: This operation enables a watcher to subscribe and receive presence information state changes of a presentity Push to Talk: o initializepttservice: This operation initializes the PTT service o PTTcalling: This operation allows to make a PTT call to a PTT contact o addcontact: This operation adds the name and phone number of a contact. An invitation to join the PTT contact will be sent and once the invitation is accepted, the invited person joins the PTT contacts of the inviting person and vice versa. o Messaging: o sendmessage: This operation sends a message to a phone number. Although rather simple the offered APIs are quite powerful and enable the construction of a plurality of IMS clients with different functionalities offering different flavour of rich communications. 3.3 Interacting with the terminal device In the proposed solution, for each IMS request, it is the IMS Client User Interface server and not the user s terminal device that is initiating a session between the user s device and the callee s device. On both the user s device and the callee s device, the communicating user agent could be an IMS client, a generic IETF SIP agent or a GSM voice application. In order to be able to establish the session, the IMS Client User Interface will need to have an identifier to address both the user s device and the one s of the callee. The identification of user s device is done at login and authentication to the IMS Client User Interface server, which is based on the SIM card. For a regular GSM phone, the MSISDN, i.e. mobile phone number will be used in the establishment of the session. For a device with an IMS client the IMPI (IMS private identity) will be used while for a device with native IETF SIP agent, it could be an IP address or a PDP (Packet Data Protocol) context. 3.4 Additional security features In terms of security, the 3GPP has only specified the registration, authentication and authorisation of the IMS client using the ISIM/USIM [5]. Now that the browser is used as user interface to the IMS, it is necessary to have new registration and authentication mechanisms. It is also crucial that these mechanisms are both sufficiently secure and user friendly. Again, the diversity of devices creates problem since one mechanism may not fit to some devices due to physical limitations. It is necessary to have several authentication mechanisms and for the Universal User Interface there are proposed three as follows: Generic Bootstrapping Architecture (GBA) [8] for 3G phones: This standard 3GPP authentication scheme will use the USIM/ISIM to authenticate the user accessing IMS Client User Interface server using the browser on the mobile phone. SIM Strong Authentication over SMS [9] for 2G phones: In the case of a regular GSM phone with browser, the authentication is done using the EAP- SIM (Extensible Authentication Protocol SIM) [10] using the SIM card and SMS (Short Message Service) as bearer. SIM strong Authentication for PC: When the user is using a PC the authentication is done using a SIM dongle (i.e. a USB dongle hosting a SIM card), a PCMCIA card with mounted SIM, a SIM installed in the embedded SIM slot on the PC or a mobile phone communicating with the PC via Bluetooth. The protocol used is the EAP-SIM over Ethernet. 4 The benefits of the solution The proposed Universal user interface solution has many advantages compared to the current IMS clients in many respects. 4.1 Universal accessibility As per today the biggest hindrance for the full commercial deployment is the availability of IMS mobile terminals. The few current samples from major handset manufacturers are rather poor in terms of functionality and quality. In addition, they are not

interoperable and do not offer a uniform experience to the user. This has motivated a group of key operators, infrastructure and device vendors comprised of Orange, Telecom Italia, Telefónica, TeliaSonera, Ericsson, Nokia Siemens Networks, Nokia, Sony Ericsson and Samsung, to initiate the Rich Communication Suite initiative in February 2008. With the Universal user interface solution, a universal IMS client will be available and accessible on any fixed or mobile terminal devices having a Web browser. By providing such a broad availability the Universal user interface solution will contribute to the promotion and success of IMS. 4.2 Adaptability to a wide range of terminals As shown in earlier sections, the Universal user interface solution can provide adaptation and optimization for any terminal device, fixed or mobile in a quite simple way. The solution can support both devices equipped with IMS client and devices with only native voice telephony e.g. GSM voice. contact list at device replacement. The proposed solution provides a centralised contact list which is device independent and accessible from anywhere. 5 Proof-of-concept implementation A proof-of-concept implementation of the Universal User Interface has been completed by Telenor, Gemalto, Ubisafe, Linus and Oslo University College in collaboration with Alcatel Lucent Technologies and Ulticom. The implementation is carried out within the scope of the EUREKA Mobicome project. A demonstration of the Universal User Interface was shown at the Mobile World Congress in Barcelona, Spain, February 2008. 4.3 Flexibility for introduction of new functionality The proposed solution alleviates to the development of new IMS clients with new functionality and different flavours of rich communication. The deployment of new IMS clients is both simple and fast since it requires only installation at the operator s server. On the other hand, the solution will reach all the devices, fixed or mobile, old or new. 4.4 Operator customisation In a way, the Universal user interface solution proposes a centralised networked IMS client hosted on an operator s server. The operator will hence have the opportunity to customise and tailor different IMS clients to different customer segments. The customisation can include both functionality and look and feel. Figure 4 Example of an IMS Client UI on Internet Explorer 4.5 User personalisation To meet the user s needs and expectations, the proposed solution enables also user personalisation of the IMS client in terms of both functionality and presentation. The user can then have his own IMS client that can be accessible anytime anywhere on any device having a Web browser. 4.6 Sharing of contact list One obvious advantage of the Universal user interface is the possibility to have a centralised contact list. Currently, people have different contact lists on different devices, e.g. mobile phone, PDA, PC, etc. and there is a need for a content synchronisation of these dispersed contact lists. This task is as cumbersome and time consuming as it is unreliable and inconsistent. Furthermore, there is a need of recovering the old Figure 5 Example of IMS UI on mobile phone Since it is only a proof-of-concept only VoiP is implemented and the user is only allowed to make phone calls by accessing IMS Client User Interface server. The other services like PoC, Presence, IM, Video sharing, etc. will be gradually introduced in later versions.

The user personalisation of the IMS client is also experimented and the results are quite promising. The most challenging issue is to reduce the number clicks that require to navigate and login to the IMS Client User Interface server. Currently, it requires 9 clicks, which is too much. The best solution is to have a soft-key on the desktop screen allowing direct jump to the IMS Client User Interface server. A second challenge is to reduce the time needed to establish sessions to the same level as for current calls. Figure 4 and Figure 5 illustrate example of GUI for a user on PCs and mobile phones. 6 Conclusion In this paper, an innovative IMS client implementation, called Universal user interface is introduced. With this implementation, the IMS client UI is removed from the handset and moved to an IMS Client User Interface Server on the network. The solution enables the support and provision of IMS clients for a wide range of both fixed and mobile terminal devices at the same time as operator customisation and user personalisation are offered. The solution has proven to be feasible by the realisation of a proof-of-concept. The most challenging issue is still how to provide a good and uniform user experience over all the devices. The implemented prototype shows that it takes many clicks to navigate and login to the IMS Client User Interface Server and a little bit long time to establish a call. Further works will hence be focused on finding remedies for the mentioned issues. In addition, the other IMS services like PoC, Presence, IM, video sharing will also be introduced to enable the realisation of rich communications. [7] W3C: Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification - W3C Candidate Recommendation 19 July 2007 [8] 3rd Generation Partnership Project: 3GPP TR 33.920 V7.4.0 (2008-01) Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); SIM card based Generic Bootstrapping Architecture (GBA); Early implementation feature (3GPP TR 33.920 version 7.4.0 Release 7) [9] Do Van Thanh, Tore Jønvik, Do Van Thuan & Ivar Jørstad: Enhancing Internet service security using GSM SIM authentication, Proceedings of the IEEE Globecom 2006 conference ISBN 1-4244-0357-X San Francisco, USA, Nov 27 - Dec 1, 2006 [10] IETF (2006), RFC4186: Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) 7 References [1] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 8) - 3GPP TS 23.228 V8.3.0 (2007-12) [2] Java community Process: JSR-000281 IMS Services API 0.95 Proposed Final Draft for Documentation [3] Open Mobile Terminal Platform: OMTP IMS Functional Requirements - Version: 1.0-16 May 2007 [4] Eurescom study P1656 Definition of an open and extendible IMS Client Framework http://www.eurescom.eu/public/projects/p1600- series/p1656/default.asp [5] 3rd Generation Partnership Project- Technical Specification Group Services and System Aspects: Technical Report Security aspects of early IP Multimedia Subsystem (IMS) (Release 7) 3GPP TR 33.978 V7.0.0 (2007-06) [6] Java Community Process: Java Specification Requests JSR 245: JavaServerTM Pages 2.1-11 May, 2006