Proceedings of the Postgraduate Annual Research Seminar 2005 301 Canalization and Personalization in Mobile Wireless Application Herman Department of Computer System & Communication Faculty of Computer Science and Information System, Universiti Teknologi Malaysia herman@siswa.utm.my ABSTRACT This paper proposes a concept of single web based application to serve various platforms of client, especially mobile wireless platform such as WAP and i-mode. The application is designed to be able to recognize capacities and capabilities of mobile device and mobile network in order to generate response according to the device and network. Furthermore user behaviours and user preferences also consider to optimizing mobile consumer satisfaction. KEYWORDS Wireless application protocol, mobile wireless services, user agent profile, markup language technologies. 1. Introduction Mobile services have two selling points, those are mobility and personalization. User can access information anytime and anywhere [3]. Services aslo can be given more specific to user requirement, including capacities and capabilities of mobile device and mobile network, user preferences and behaviors, user locations, time of service, etc. Currently, mobile devices and mobile networks have several constrains, as shown in the table 1. [6], [13]. Device constraints Less CPU Less memory Limit of power supply Small display Uncomfortable input devices Network constraints Less bandwidth Less predictable availability Less connection stability Table 1: Mobile Device and Network Constraints In addition to those constraints, the capacities and capabilities of devices and networks are also various, for example the size of display, start from only can render three rows dot matrix texts up to 60.000s pixel displays that have 16 bit color deep. Although technology of mobile wireless network has been going to third generation (3G), many mobile network operators still use 2G or 2.5G technologies, such as GSM and GPRS. When designing mobile wireless web application, ideally application can serve as many as possible consumers with optimal quality of service, whatever their mobile device and network [1]. Unfortunately, problem of limitation and variousness in device and network halt achieving the ideal condition. For example in image presentation, if application use JPEG format, hence client that not supported the format can not be served. On the contrary, if image made in WBMP format, the high-end client can not get benefit of wider and high resolution display. Existing standard made by some platform of mobile wireless system, like Open Mobile Alliance (former WAP Forum) and l-mode can relatively overcome the limitation and variousness problem [8], [9]. Every platform has particular standard and specification, including: User agent Bearer network Protocol and network element Content type Presentation language
Proceedings of the Postgraduate Annual Research Seminar 2005 302 Mobile wireless application can be made in accordance with specification of certain platform. The application is designed to be used by client that supports the platform. For Example, an application that is made based on WAP 1.x platform uses WML as presentation language, WBMP image, and no table. Targeted clients for this platform have characteristic, monochrome display, WML micro browser, not support, and use GSM or GPRS technology as bearer. To serve different platform clients were required several separate applications [4], [5], [11]. This concept has weakness from content provider point of view and consumer also. Content provider requires more works and resources in order to server broad range of various clients. On the contrary, if provider only provide one application for certain platform consumer from other platform cannot be served. Even if provider has made separate applications for several platforms, service to consumer still less be optimal, because every application will generalize clients based on their platform standard. For example two clients that support WML 2.0 platform, but the first client use wider network bandwidth than the second one. Because application only differentiate client due to their platform, hence quality of content that they are accepted cannot be differentiated, except the first client can download content quickly from the second one. 2. Single Origin Server Multiplatform Clients The design of this concept focuses to application level of mobile wireless system. Figure 2 shows an origin server publish service and content trough internet by standard protocol. WAP GATEWAY/PROXY WDP/Bearer WP- internet ORIGIN SERVER I-mode CENTER WP- This protocol functions as single gate for all of clients from several platforms that support by application. If the client have supported, hence client-server communication can be conducted directly, but if not yet, it was needed gateway as protocol intermediary between of and protocol suite that supported by client [10]. 3. Canalization Canalization is initial stage of personalization in context of capacities and capabilities of mobile device and mobile network. When client - server connection is established, application will identify content format that is supported by client. Identification is done by check the header of request if the client connects to server for pull service or by recognizes the MSISDN for push service [12]. Then the client is grouped into certain canal together with other clients which support same content format. Application has some canals depend on how much type of content format that supported. For example Handheld Markup Language (HDML), Wireless Markup Language (WML), Compact Hypertext Markup Language (c), or Extensible Hypertext Markup Language - Mobile Profile (X-MP) [6]. Implicitly these canals would be grouped clients according to their platform. Besides to determine content format the canal is also used to define frame of service which can be accepted by client as general. This frame will become such path to lead client to get service according to each canal respectively. Path of the service can be differentiated and designed to every canal, because basically content format supported by client reflect capacities and capabilities of device. For example, client that support content format X-MP have better capacities and capabilities than that support WML. Table 2 shows the relationship between canal and client platform. Canal Platform WML WAP version 1.x X-MP WAP version 2.0 c i-mode Conventional Web Platform: WAP Platform: Conventional Web Platform: I-mode Table 2: Canal and client platform relationship Figure 1: Protocol Intermediary
Proceedings of the Postgraduate Annual Research Seminar 2005 303 4. Personalization Canalization stage is continued with the personalization process to achieve more optimal service to each client. In this process, application identify client more specific. Beside capacity and capability mobile device and mobile network, application identify user behaviors and preferences. Personalization process use Composite Capabilities / Preferences Profile (CC/PP) [7]. CC/PP represents a high level framework that is formulated by W3C. Application adopts this framework to define information about capacities and capability of device and network including user behaviors and preferences. The information that called CP/PP profile is made of Resource Description Framework (RDF) - a subset of XML -. A CC/PP profile is organized in some attributes. Each attribute defines specific information about client. Some corresponding attributes are classified into a component that represents certain characteristic of client. Table 3 depicts some components and their attributes. Component Hardware Software Network User Agent Attribute Screen size, bit per pixel, color capable, image capable, keyboard type, Input Character set, sound output capability, vendor, etc Accept downloadable software, java enable, java Platform, OS Name, OS Version, etc Security system, supported bearers, supported data communication., etc Browser name, CC/PP accept char set, frames capable, tables capable, etc Table 3: Component and attribute of CC/PP CC/PP framework also defines arrangement for transmission of the information and how to exchange it among mobile device, intermediate network point, and origin server. In general CC/PP profile of a client is transmitted trough extension header of request that sent by client to web server. This transmission is controlled by application protocol that used by client and server. As a single server for several client platforms, server use HTTP version 1.1 as its application protocol. Request and response always based for HTTP (HTTP or Wireless-HTTP) [14]. For example client, that has WAP 1x platform using WSP as its application protocol. In order to establish communication between server and client that not support HTTP, a special gateway needed. This gateway used to translate the non-http request to HTTP request. The same mechanism also used in reverse flow from server to client. This concept is in line with concept of single origin servermultiplatform client. Detail Implementation of CC/PP profile is various and depend on application protocol used by client and how the scheme that implemented by intermediate network point (gateway or proxy) for transmit the profile. Problem like caching mechanism and updating the profile is some important issue related to detail implementation. Applications that run on server basically do not take as problem of how profile implementation on client. Application only accept HTTP request from client. If that request contains profile information hence the application will process the request by personal feature. But otherwise if does not contain profile information the request remain be processed by application, but without personal feature. Request only goes trough canalization without personalization. Implementation of profile in HTTP request uses two kind of expression [9]. There are: a) Direct description (lexical inline). With this expression, attributes is expressed one by one in pair of namevalue like the following example: <ccpp:component> <rdf:description rdf:about="http://www.example.c om/profile#terminalhardware"> <rdf:type rdf:resource="http:/www.exampl e.com/schema#hardwareplatform" /> <ex:displaywidth>320</ex:displ aywidth> <ex:displayheight>200</ex:disp layheight> </rdf:description> </ccpp:component>
Proceedings of the Postgraduate Annual Research Seminar 2005 304 b) Indirect reference. Attributes are grouped in their component (Component Description Block) externally in profile repository server. XML TXT STYLE VIDE IMAGE XSL <ccpp:component> <rdf:description rdf:about="http://www.example.c om/profile#terminalhardware"> <rdf:type rdf:resource="http:/www.exampl e.com/schema#hardwareplatform" /> <ccpp:defaults rdf:resource="http:/ www.example.com/hardwareprofil #HWDefault"/> </rdf:description> </ccpp:component> Combination of lexical inline and indirect reference can overcome constraint of mobile wireless network. Most of profiles that have default value are expressed by indirect reference (Default Component Description Block). This block can be accessed by application through conventional internet network whose relatively wide bandwidth. Lexical inline is potential to enlarge size of request. This expression is used only if needed to change the attributes of default component that is expressed with indirect references. Thereby total size of request can be reduced as minimum as possible. 5. Implementation To implement canalization and personalization concept, application generate response using XML approach. With this approach application can dispatch content simultaneously to various clients from different platforms. Most contents that are in text based are prepared in XML format. When these contents are needed to generate response, application will transform these contents by XSLT style sheet into content format that is appropriate for client based on its canal. Other content objects that are not based on text, like image, animation, audio, or video are added by style sheet script into response package in form of references. Figure 2 show this mechanism. X-MP WML AUDIO Figure 2: XML approach in Response Generation Content or service that is generated by application as response to client split up to two types. Those are generic and personal content. Generic content only take advantage of canalization process. The display of content is same to each client which same platform. For personal content, application must consider client/ user personally, for example to determine how length of ideal text is needed checking of size of device screen. To send special image like map or animation, application must check optimal format that supported by client. The same manner applied for multimedia content, streaming, etc. Important issue which is always had to consider is total size of every response. The size must be rational with capacities of network. 6. General Scenario C When application accept first request from a client, the application will identify content format that supported by client in order to canalize it. If a device support more than one content format, personal module will consider network constrain of the client to determine optimal canal to it. Application then will build a session object for the client. This session will be retained during clientserver relationship is exist. The session will be ended when client exit from application or time out setting exceeded. Furthermore application will parse profile header that brought by the first request. After all attributes both for lexical inline and also indirect reference collected successfully, application keep all of information about client profile as variable of session object. ASP
Proceedings of the Postgraduate Annual Research Seminar 2005 305 These variables will be used by application as reference to generate response personally to every client / user. 7. Conclusion Canalization and personalization in mobile wireless application that proposed in this paper is an alternative solution to bridge platform difference of mobile wireless system. This concept only requires single application to serve client from several platforms. Usage of XML approach to implement this concept is in effort to make application as simple as possible to serve various content formats. In the future work, personalization technique should be exploring more deeply because there are a large number of parameters can be incorporated, especially parameter of user behaviors and preferences. 8. Acknowledgements The author would like to thank to DR. Muhammad Shafie B. Hj. Abd Latiff as supervisor in this Master Work. References [1] B. Ozen, et al. "Highly personalized information delivery to mobile clients". Journal of Wireless Network. 2004. (10(6). pp. 665-683. [2] Bodic G. L. Mobile Messaging Technologies and Services: SMS, EMS, MMS. West Sussex, England: John Wiley & Sons Ltd. 2003. [3] C. Bennet. Practical WAP: Developing Applications for the Wireless web. Cambridge, UK: Cambridge University Press. 1995. [4] C. Panayiotou, G. Samaras. "mpersona: personalized portals for the wireless user: An agent approach". Mobile Networks and Applications Journal. 2004. 9(6). pp. 663-667. [5] C.R. Anderson. A Machine Learning Approach to Web Personalization Ph.D. thesis. University of Washington, Department of Computer Science and Engineering. 2002. [6]. GPRS and 3G Wireless Applications: professional developer s Guide. New York, USA: John Wiley & Sons, Inc. 2001 [7] Nokia, Inc. Nokia WAP Phone Characteristics, Version 1.8 Forum Nokia. 2002. [8] Open Market, Inc. Personalization Strategies: Building the Customer Experience to Meet Business Objectives. Open Market Business White Paper. 2000. [9] Open Mobile Alliance, Ltd. User Agent Profile 1.1. OMA Specification Document. 2002. [10] R. Hagen, H. Manning, and R. Souza. Smart Personalization in The Forrester Report July 1999. Cambridge, MA, USA: Forrester Research, Inc. 1999. [11] S. Wright. Personalisation: How a computer can know you better than yourself. Prodeeding of the Multimedia Systems Conference. 2002. [12] Scherp. A,and Boll, S. "Generic support for personalized mobile multimedia tourist applications". Proceedings of the 12th annual ACM international conference on Multimedia. 2004. pp 1178-179. [13] T. Capin. Mobile SVG Profiles: SVG Tiny and SVG Basic. W3C Recommendation. 2003. [14] W. Stallings. Data and Computer Communications, Jew Jersey USA: Prentice Hall. 1999.