LOCATION BASED SERVICES FOR MOBILE DEVICES – A ...

LOCATION BASED SERVICES FOR MOBILE DEVICES – A PRACTICAL EVALUATION Thomas Krahmer1, Andreas Lang1, Jana Dittmann1, Christian Krätzer1, Claus Vielhauer1,2 1

Otto-von-Guericke University of Magdeburg ITI Research Group, Multimedia and Security Postfach 4120 39016 Magdeburg Germany ABSTRACT We reach an age where mobile devices are affordable for nearly everyone. The technology used within these small devices is evolving with every new generation of the devices and allows us, for example, to gain information about the place we are presently. In the example of location based services in museums the common way to provide information to a visitor is to equip him with a device bought and maintained by the museum. The idea from [6, 22] using the user’s mobile device, which he already knows is further developed in this paper from the software setup procedure. Today’s mobile devices offer different techniques and protocols of transmitting text and multimedia data between their users which allows us to bring the guide software directly to the visitors mobile device. In this paper, we discuss and compare different possibilities to offer location based services to the user by using different existing transmission techniques (Bluetooth [1], GPRS [2] and UMTS [2]) with their protocols (OBEX [3], MMS [4] and WAP [5]) in focus of a location based service like for example for a museum. Thereby, their pros and cons of transmitting a specific application or requested information to the users mobile phone are compared and discussed. The main goal of this paper is to describe how to transmit and install software for audio guides and to evaluate the interoperability of different devices regarding to the technology, which is needed for an audio guided tour with these devices. The practical work is based on the examination of three selected mobile devices from different vendors (Nokia, Samsung and Sony Ericsson). KEY WORDS Mobile multimedia, transport protocols

1. Introduction In the past, there were posters or signs to provide orientation and flyers to give additional information about an exhibition. Today, a lot of museums and exhibitions provide the information about exhibitions or navigation information to their visitors digitally. Different vendors offering specific electronic solutions for guide systems share a market for a more comfortable and more flexible way to provide access to larger amounts of data. The

2

Brandenburg University of Applied Sciences Department of Informatics and Media PSF 2132 14737 Brandenburg / Havel Germany

different guide systems available for museums or exhibitions can be divided into the four main categories [6]: devices with a keyboard, PDAs, mobile phones and devices for specific application scenarios. The devices with a keyboard are similar to a classical phone, where the user enters, for example, the object number of an exhibit in a museum to get information about the object. An automatic identification of the object number is uncommon in this class [7, 8]. For PDA’s a similar principle is used to identify an object number within a museum by entering this number via touch screen [9]. Current audio guides, who use the mobile phone of the visitor, offer a phone number which the user can call to get the requested information [10, 11]. Using such a system, customer’s accounting for the service is done via the user’s phone bill. There is also a system available, which offers the requested information via short message service (SMS) to the user’s mobile phone. The last category of audio guides for specific application scenarios are for example the guidePort or pickup-user guide [12, 13]. The provider of a location based service for mobile devices has the choice between either distributing dedicated hardware for the service (like in the case of the devices with a keyboard) or employing the users mobile devices for the execution of the service. In the first case a positive fact can be seen in the homogeneous hardware being provided. The software can be used on every mobile device provided by this vendor and there is no need of modification. As a downside the financial fact plays a big role. The soft- and hardware must be bought, maintained and supplied to the visitor which requires additional effort in the institution. In the second possible case, the employment of the user’s devices for the service is expensive for the user at the moment, but the idea is, to install a museum specific software on the users mobile device, which guides him within the museum. To control the software, on one hand, the keyboard could be used as known from [7, 8] or the microphone of the mobile device records the background noise or music, retrieves a digital watermark, which is used to identify the position of the user [22]. Motivated from this fact, in this paper we introduce and discuss an audio guide system, which uses the museum visitor’s own mobile device (here the user’s cellular

phone is considered) combined with a location based service offered by the museum to reduce the amount of costs. The aim is to introduce this audio guide system in form of especially developed software provided locally to the visitor. The Software needed for an audio guide must be able to provide: - visual information (text and images) - user interaction - audio playing techniques The increasing spectrum of technology embedded into mobile devices results in a new approach for distributing information. In nearly every recent mobile device found on the market we are able to run software from third parties. In view to a guide for a museum or exhibition this means, we just need to provide the software to the visitor and use the hardware he provides in the form of the users own mobile phone. In that way we achieve a cost minimization for the information providing institutions and ensure a priori that the user is familiar to the hardware. Using mobile devices for guided tours bring also some restrictions with it. As mentioned before, supplying the user with homogeneous hardware implicates no need of modification for the software, but if the hardware is brought along by the user, the software has to be adapted to the different kinds of these mobile devices. Limitations given for the mobile devices are for example: limited storage capacity, different supported executable formats, different operational systems and virtual machines, different supported audio formats (for audio guides). The problems which arise from the inhomogeneity of the devices are described in this paper in detail for mobile phones as an example of mobile devices. After the specification how to transmit and install the specific audio guide software, we want to replace common techniques of event driven information gaining by controlling the user’s mobile phone via digital watermarks for example embedded in background music of the museum. The paper is structures as follows. In section 2, the two major and supported programming languages for mobile phones are described briefly. Transport services and protocols used by the mobile phones are in section 3 introduced and discussed. In section 4, our test goals and test scenarios are presented, whereby in section 5 our test results are introduced and discussed. The paper closes in section 6 with a summary and future work.

2. Supported Programming Languages on Mobile Phones Currently there are two different major programming languages supported by today’s mobile phones for third party programs. The choice of the programming language is influenced by the addressed runtime environment; therefore these two programming languages are briefly introduced in the following:

C++ can be used for programming software on mobile phones for SymbianOS [14] and also for phones with Microsoft Windows mobile. There is a wide range of mobile phones based on SymbianOS including phones of vendors like Nokia, Samsung, Sony Ericsson or Panasonic. Recent discussions raised doubts about the security of Symbian based software. Security risks concerning the confidentiality, authenticity, integrity and non-repudiation of services and data (i.e. modify/delete content on the file system, doing disallowed calls, sending SMS) of Symbian based mobile phones were published. In regard to the intention of transmitting software to a user’s mobile phone, an evaluation of the security aspects is necessary to protect the user. o Java programs can be written for a lot of new mobile phones and are not restricted to certain operating systems. The common platform for java programs is J2ME [15]. J2ME’s concept is based on configurations and profiles. While a configuration provides some libraries and a virtual machine (CLDC [16]), a profile is the API, existing for that configuration (MIDP [17]). Java programs based on J2ME come with extension “jad” and “jar” and are called Midlets. Within this document tests are presented for transmitting a J2ME-based java program over different transport protocols to the mobile phones with the intention of installing the program. o

3. Transport Services and Protocols for Mobile Phones In this section the common transport techniques and protocols available for mobile phones are described and advantages as well as disadvantages in regard to location based services are discussed. The examination of IrDA [3] (Infrared data association) for transmitting data to a mobile phone is excluded because the actual generations of mobile phones do not support IrDA anymore. The following 5 protocols for transmitting data are supported by nearly every modern mobile phone found on the market. The first protocol, Bluetooth, can be used for short range transmission over a distance of up to 100 meters. Related to the mobile phone based audio guide in museums or exhibitions this transmission range is sufficient. An advantage of using Bluetooth is the fact that data transmission over this protocol is free of charge. A computer installed in the area can provide the whole service over Bluetooth, which means direct connection to the mobile phone without the usage of its principal protocol GSM (Global System for Mobile Communications). In the case of a Bluetooth transmission there is besides the storage size of the mobile phone no constraint for the data size to be transmitted.

A second possibility for offering a location based service is the usage of MMS (Multimedia Messaging Service) over the WAP protocol. WAP is based on the packet oriented GPRS protocol. Over GPRS a mobile phone opens a permanent connection to the remote station but only if data packets are sent the user has to pay for the service. In respect of the usability of the system, sending MMS to the user’s phone is quite simple. The mobile phone needs to be set up to allow receiving and sending of MMS. Receiving an MMS would be free of charge for the user but has to be paid by the location based service provider for every message sent. Another disadvantage is the limitation of the message size which can be sent within an MMS (dependent on the bearer; MMSC). This would not be a problem in an environment where just a small program needs to be provided, but in audio guides the transmitted data size would exceed the limit in most cases. Browsing over WAP (Wireless Application Protocol) is another way to transmit software to a mobile phone. Like MMS, WAP can also be transmitted over GPRS. The process can be compared with normal browser requests from a computer over HTTP [18]. Special WAP sites provide similar content like normal HTML [19] based websites but are optimized for mobile phones with their display, storage and bandwidth limitations. The used description language is called WML [20] (wireless markup language) which is xml based and can be distributed over conventional web servers. Regarding usability the user is the main actor in this scenario and has to be more familiar with his mobile phone than in other scenarios. To assist the user in getting the software it is possible to send him a WAP push SMS which includes a WAP address nested in the SMS. The user receives the message and if WAP is supported, the nested WAP address is called. This could be the address to the software to be provided to the user. The downside of the usage of this protocol is the occurrence of relatively high costs (compared to the other introduced approaches) for the user. At first it was only possible to visit WAP pages with a mobile phone, but by enhancing the capabilities of modern mobile phones it became possible to visit regular web pages using GPRS. According to the scenario of a museum it is possible to embed the software with the provided service directly on the website, which means there is no need to support WAP services. Most museums and exhibitions have a website and therefore there would be no additional costs for service providing. The costs regarding to the user are the same like in the WAP scenario. An even faster solution than GPRS is UMTS which provides an up to seven time’s higher bandwidth. The high bandwidth is the major advantage of UMTS because in the user guide scenario audio or video streaming becomes an interesting possibility which has to be

examined. In the near future UMTS flatrates might become more and more attractive, too. With GPRS or UMTS it would also be possible to distribute the software by email. A problem for the usage of this protocol is the still very low spread of UMTS capable devices.

4. Test Scenarios and Test Goals In this section, our test scenarios and test goals are presented. 4.1 Test Environment In the test environment we used a server (IBM Z60m with Bluetooth and LAN/WAN) running Debian Linux to provide data to the mobile phones. This server is called LBCP (LocationBasedContentProvider) in this paper. In the practical tests the three different mobile phones Nokia 6230, Sony Ericsson P900 and Samsung SDA are used with the intention to provide audio guides for a museum or exhibition on them. The software to be installed on the phones is based on the J2ME framework with minimum requirement of CLDC 1.0 and MIDP 2.0. We decided to use this framework due to the platform independency of the java programming language and the wide support on mobile phones. The software is called GuideIT which is a J2ME Midlet developed for Meisterhäuser Dessau (Germany, [21]), providing text and audio based information about the several points of interest. 4.2 Transmission Different ways for software transmission from the LBCP to the mobile phones are evaluated, in detail: Bluetooth, MMS, WAP, GPRS and UMTS. The aim is to find out which of these services is the most useful in case of museums or exhibitions location based services. Figure 1 shows our test scenario for the evaluation of the transmission via Bluetooth.

Bluetooth

Figure 1: Test Scenario for Bluetooth Transmission Our second test scenario, where we use the WAP and GPRS/UMTS protocols to stream the required data or to transmit MMS is shown in Figure 2.

INTERNET WAP-Gateway

Figure 2: Test Scenario for Transmission via WAP For both test scenarios, the following characteristics are examined: the cost effectiveness for both provider and user, the ease of installation to provide the transmission service, the possibility of device specific software support and the support for the services on the different mobile phones. 4.3 Installation Process The next step of the practical work is to examine the installation process. In consideration of the usability the software installation on the mobile phone is examined. To do this, the J2ME Midlet is transmitted over one of the previously described protocols and an examination of the steps used for the software installation procedure is performed. 4.4 Audio Support and Storage With the intention to provide audio guides as location based services, an evaluation of the mobile phones according to their support for different audio codec’s and audio playing features becomes necessary. If a mobile phone includes an embedded player for audio files supporting different codec’s like MP3, WAV, AMR or others, this does not imply that software from third parties can provide the same support. Also the storage space and the possibility of streaming the audio data play a role in the evaluation of different phones. In practice the support of several audio codec’s on the different mobile phones is evaluated.

5. Test Results In this section the test results regarding to the different transmission possibilities with their installation strategies for a specific application to the mobile phones are presented. 5.1 Bluetooth – Setup, Transmission and Installation Process At first the transmission of GuideIT via Bluetooth to the three chosen mobile phones is examined. During setup, on every phone the activation of Bluetooth is required and thereby the device needs to become visible to other Bluetooth devices in order to connect to it from the

LBCP. For users who are not familiar to their phones, the steps have to be described in detail for every phone. The LBCP provides a web server and using a browser an operator can select the mobile phone from a list of recognized devices. After selecting the mobile phone and confirming to the transmission, the LBPC tries to connect to the given mobile phone. On each mobile phone the connection from the LBCP has to be accepted. After this procedure of generating mutual acceptance, the LBCP connects to the mobile phone and transmits the software. This transmission was successful for all three tested phones. Providing adapted software for different mobile phones requires knowledge of the mobiles phone type. One possible way to determine the device type is by sending AT-commands to the phone over Bluetooth. If the phone supports AT-commands we can send a type request as follows in Table 1. Table 1: AT-Commands for device information AT-Command Description AT+GMI AT+GMM AT+GMR

Request Manufacturer Identification Request Model Identification Request Revision Identification

This was tested on the Nokia 6230 and the results for the transmitted AT-Commands are shown in Table 2. Table 2: AT-Command result for Nokia6230 AT-Command Result for Nokia 6230 AT+GMI AT+GMM AT+GMR

Nokia Nokia 6230 V 04.28 24-06-04 RH-12 GSM P1.1 (c) NMP.

An interesting information is also the MIDP and CLDC version of the J2RE embedded in the mobile phone for distributing hardware-specific software, but this information could not be gained via AT-commands. In practise disadvantages for the usage of Bluetooth were found in the usage of different Bluetooth stacks. The evaluated mobile phones could be connected with our service providing host LBPC, but while analyzing Bluetooth for transmitting data we realized that there are often problems with the different stacks available. For our transmission we used OBEX (OBject EXchange) protocol which originally comes from IrDA. Another disadvantage is the installation of the submitted program were i.e. the tested Nokia 6230 could not recognize the transmitted file type and an installation was only possible by using a proprietary software suite provided by Nokia on the LBPC. In case of the SDA, the installation process can also not be considered user friendly, because after transmission of the GuideIT the installation process is not intuitive and has to be described in detail for end users.

Besides the mentioned disadvantages providing location based services via Bluetooth is free of charge for the user and cost-effective for the provider, because only a server with Bluetooth hardware is required. 5.2 MMS – Setup, Transmission and Installation To receive a MM (Multimedia Message) on a mobile phone the setup of the MMSC on this phone is required; otherwise no software could be retrieved. For the three tested phones exist services of their vendors or of the Mobile Provider, which can be used to transmit the MMS settings to the mobile phone by entering the mobile number on their website. On the LBPC a GPRS modem has to be installed which is able to send MM’s to the phones after the user registered his mobile phone on the LBPC’s website. The scenario was simulated in the tests performed by sending the software between two mobile phones. The tested phones were all able to retrieve MMS with nested software and the installation finished without problems. Considering the user and provider costs, the service is free for the user and the provider pays the given fee of his mobile provider for every MM sent which may be expensive for a large number of visitors. 5.3 WAP – Setup, Transmission and Installation All three mobile phones tested support WAP for sending data to and receive data from the Internet. The LBCP therefore was connected to the Internet and provides the software over a web server. The web server must have support for WAP specific content types like WML (Wireless Markup Language), the software is then provided over the WAP-page. The transmission over WAP was successful on all phones and the installation after transmission is considered very user friendly (it started after well described installation steps). Another advantage of using WAP is the possibility to identify the phone which is connected to the WAP-web service. This allows providing adapted software for specific device types. For identification of different mobile phone types the User Agent can be used, which is sent from a WAP browser to the web service while requesting information. The following device specific information could be gained in our test scenario: Table 3: User Agent sent by a WAP browser Handytyp

SE P900 Nokia 6230 SDA

User-Agent

SonyEricssonP900/R102 Profile/MIDP-2.0 Configuration/CLDC-1.0 Nokia6230/2.0 (04.28) Profile/MIDP-2.0 Configuration/CLDC-1.1 Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; Smartphone; SDA/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1)

As shown in Table 3 the browser also transmits the supported CLDC and MIDP of the J2ME of the phone. The information can be used to provide extra services to a mobile phone which supports newer versions of the profiles and configurations.

The costs for a user depend on the traffic generated, because WAP is charged by traffic volume. The user has to be informed that he possibly has to pay for the transmitted data which might be expensive in case of audio guides. The service provider needs to maintain a WAP supporting web server. 5.4 GPRS/UMTS – Setup, Transmission and Installation Connecting the phones to a normal web service can be compared with the WAP-scenario described before but without the need of supporting special WAP content types by the LBPC’s. The user also has to setup his mobile phone to be able to connect to the Internet via GPRS/UMTS and there are also services provided from the different vendors which help with the configuration of these protocols. The tested phones only support GPRS which has a lower bandwidth than UMTS. The installation process was as easy as in the WAP scenario which means the software was easy to install after the download finished. Like for WAP, the traffic over GPRS/UMTS is charged by volume. 5.5 Tested Audio support In order to provide an audio guide like GuideIT to the different mobile phones, we examined the supported codec’s for the three tested phones. An overview can be seen in Table 4. Table 4: Supported content types on the tested phones Nokia Supported Content Types SE P900 SDA 6230 audio/x-tone-seq audio/wav audio/basic audio/x-wav audio/rmf audio/mp3 audio/x-mp3 audio/x-imelody audio/iMelody audio/midi audio/sp-midi

X X X X X X X X X X

X

X X X

X X

X

Table 4 shows that there are only two audio codec’s (marked with light gray) which are supported by all 3 phones, but these two codes are not practicable for human speech. Considering also other phones this means that the content provider has to provide different audio files for different phones based on their capabilities. In case of the Nokia 6230 there is no audio codec supported which allows us to play an audio file containing human speech with the installed J2ME based GuideIT. While in the first part of the audio tests the audio files were nested in the submitted software, the storage size exceeded in case of one phone the available capacities. A possible solution which therefore had to be examined, was the ability to stream audio files over GPRS/UMTS.

For this case the phones had to be examined for their HTTP-connection support which can be seen in Table 5. Table 5: Supported protocols of tested phones Supported Protocols file https http

SE P900

X

Nokia 6230

X

SDA X X X

It can be seen in Table 5 that all three tested phones have support for opening a HTTP connection but after detailed tests only the SDA and the P900 were able to stream audio files with GuideIT which is a result of the limited audio support of the Nokia phone.

6. Conclusion and Further Work In this paper we describe the problems of existing technologies for providing audio guides in museums or exhibitions. The major disadvantages of existing audio guides are identified and a possible solution is presented by distributing audio guide software to visitors mobile phones. The different possibilities of transmitting the example audio guide software GuideIT are discussed in terms of feasibility, usability and cost effects for the visitors and the providers. The future work is to find a standardized way to transmit and install audio guide software to mobile phones and increase the support of audio codec’s. It can be summarized that Bluetooth is the most attractive way to provide software for audio guides in a museum or exhibition, because it is a cost effective way to transmit data for both, visitor and service provider. The transmission range fulfills the requirements of a location based service. The only disadvantage is the usability due to the installation process, but we expect that there will be a standardized way of combined transmission and installation process for software from third parties in the future. It is conceivable to combine Bluetooth with other mentioned transmission protocols to increase the interoperability for different mobile phones. The future work of this project will be the examination of how to provide specific information of a point of interest in a museum by using digital watermarks embedded in background playing audio data.

Acknowledgement The work in this paper has been supported in part by the European Commission through the IST Programme under Contract IST-2002-507932 ECRYPT. The information in this document is provided as is, and no guarantee or warranty is given or implied that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

References [1] Bluetooth.com | The Official Bluetooth Technology Info Site, http://www.bluetooth.com/, 06.12.2007

[2] 3GPP Specifications Home Page, http://www.3gpp.org/specs/specs.htm, 06.12.2007 [3] Welcome to IrDA, http://www.irda.org, 06.12.2007 [4] 3GPP specification: 23.140, http://www.3gpp.org/ftp/Specs/html-info/23140.htm, 06.12.2007 [5] WAP Forum Specifications, http://www.wapforum.org/what/technical.htm, 06.12.2007 [6] Sandra Gebbensleben, Jana Dittmann, Claus Vielhauer, Sicherheitsaspekte eines mobilen Multimedia-User-Guides, D-A-CH Security 2006: Bestandsaufnahme, Konzepte, Anwendungen, Perspektiven; syssec, Patrick Horster, pp. 445-457, ISBN 3-00-071866-0, 2006 [7] MEG – Museum Exhibit Guide, http://www.absoluterealtime.com/resume/meg.html, 23.10.2007 [8] Antenna Audio, “X-plorer”, http://www.antennaaudio.com/xp.shtml, 06.12.2007 [9] cool IT GmbH, coolMuseum, http://www.coolit.ch, 23.10.2007 [10] BeyondGuide - Your personal audio guide on your mobile phone, http://tinyurl.com/2ehc8s, last requested 23.10.2007 [11] Rocky Mountain Audio Guide, LLC, http://www.rmaguides.com/, 23.10.2007 [12] Sennheiser, guidePORT – Exhibits come to life, http://www.guideport.de/, 23.10.2005 [13] dataton, PICKUP-UserGuideVer1.2, http://www.dataton.com/pickup, 08.09.2005 [14] Symbian OS: the open mobile operating system, http://www.symbian.com/, 06.12.2007 [15] Java Platform 2, Micro Edition, http://java.sun.com/javame/index.jsp, 06.12.2007 [16] Connected Limited Device Configuration (CLDC), http://java.sun.com/products/cldc/, 06.12.2007 [17] Mobile Information Device Profile (MIDP), http://java.sun.com/products/midp/, 06.12.2007 [18] RFC 1945 Hypertext Transfer Protocol -- HTTP/1.0, http://tools.ietf.org/html/rfc1945, 06.12.2007 [19] Hypertext Markup Language - 2.0, http://www.w3.org/TR/WD-html2/, 06.12.2007 [20] Wireless Markup Language Version 2.0,http://www.openmobilealliance.org/tech/affiliates /wap/wap-238-wml-20010911-a.pdf, Version 11Sep-2001 [21] Meisterhäuser/Masters' Houses in Dessau , http://www.meisterhaeuser.de/, 2008 [22] Sandra Gebbensleben, Jana Dittmann, Claus Vielhauer, Multimodal Audio Guide for Museums and Exhibitions, Proceedings of SPIE Electronic Imaging - Multimedia on Mobile Devices II, vol 6074, 2006