IMPROVING MULTIPLE MOBILE APPLICATION INTERACTION WITH UNIFIED SESSION MANAGEMENT

Transcription

1 IMPROVING MULTIPLE MOBILE APPLICATION INTERACTION WITH UNIFIED SESSION MANAGEMENT Jussi Ala-Kurikka Juuso Ohtonen Erkki Harjula Mika Ylianttila University of Oulu University of Oulu University of Oulu University of Oulu Finland Finland Finland Finland ABSTRACT This paper presents a novel mobile application interaction concept using Application Supernetworking. With efficient use of middleware, the use of resources can be optimized through so called Supersessions, which is an important factor especially in mobile devices. By implementing application co-operation, the user s awareness of available services can be increased while decreasing the amount of needed user input. Measurement results based on our Plug-and-Play Application Platform prototype with Application Supernetworking show the feasibility of the approach. I. INTRODUCTION Current trends suggest that mobile services should be developed at an ever-faster pace, which can be enabled by the use of different kinds of application frameworks, platforms and middleware, noted also in [1]. One additional advantage in using middleware can include optimizing the use of scarce resources of a mobile device. At best, user friendliness can also be raised with efficient application co-operation through the middleware. The vast possibilities make middleware an interesting research area. In this paper, we expand the concept of Application Supernetworking (AS) introduced in [2]. We continue the development of our novel middleware platform called the Plug-and-Play Application Platform (PnPAP) presented in [3] with new features for Application Supernetworking. Chapter 2 introduces PnPAP shortly. Chapter 3 concentrates on specifying the concepts of Application Supernetworking and Supersession in more detail, and discusses implementing them in practice. In Chapter 4, we present our currently implemented middleware and application prototypes including Navigation Application [4], a concrete example of a Supernetworked PnPAP application. We show the collaboration of Navigation Application with another application, File Sharing. Chapter 5 illustrates measurement results of the prototypes and Chapter 6 discusses the results. Future work is also depicted, and Chapter 7 summarizes the paper. II. PNPAP IN BRIEF PnPAP presented in [3] is a context-aware middleware platform targeted especially for mobile devices. It provides communication services to applications. Examples of peer-topeer (P2P) oriented functionalities provided by the PnPAP API include creating and joining a P2P peer group, searching, sharing and downloading of files inside a peer group and sending chat messages. An application can e.g. join a peer group, search for a file and download a file with only three method calls. By abstracting services behind the API, PnPAP enables run-time optimization of e.g. the used P2P protocols and connectivities. The optimization can be based on many criteria: bandwidth usage, cost, speed, interoperability etc. III. SUPERNETWORKING A. Definition Application Supernetworking (AS) was first presented in [2]. By definition, AS includes: Multisessions and/or rich calls Plug-and-play interactions between sessions and applications Holistic connectivity management Middleware plays a central role in AS: it is the coordinator of resources. B. Local Supernetworking Model As the number of services increases, navigating between them inside an application and between different applications becomes more difficult especially in mobile devices. For the user, even knowing what services are available can become difficult. Through operating system or middleware, applications can co-operate so that applications can list and trigger functionalities provided by other applications. That can provide the user with useful shortcuts because when interacting with a peer, the user might want to continue working with the same peer with another functionality. To accomplish efficient co-operation of applications and the services they provide, we introduce the terms Service Producer and Service Consumer. The Producers are applications that accomplish a specific task, such as browsing or downloading of files. They thereby produce services that other applications, the Consumers, can trigger. We call the triggering the creation of a local Supersession between the Producer and the Consumer. Fig. 1 shows the whole sequence of application cooperation via AS. The Producer registers the services that it wishes to provide to other applications locally. In the simplest scenario, the registration can just include a textual description of the service, and the description is stored to the Middleware with the path of the Producer executable. The description can be provided in different languages for localisation. A Consumer can then request a list of available services from the Middleware. The request can include a remote peer name as a parameter, if the Consumer wishes to include only the services that are supported by the peer. Then, the services returned by the Middleware can be found from Y in (1), where L is the locally supported service space and R is the service space supported by the remote peer, and F is a filtering function /06/$ IEEE

2 Y = F( L R). (1) R can be found for example by implementing [5] which presents a P2P SIP based intercommunication method for ASenabled middleware. However, using ACPC [6], even services not currently installed in the remote peer could be listed. The Consumer can e.g. show the list of services directly to the user. If the user selected a service, the Consumer would call the StartService(Service, Peer) method of the Middleware. The Middleware would then start the correct Producer application executable if it was not already running and call its corresponding callback method to set it to the correct state (e.g. to show the files of the selected remote peer). If registrations included more specific service discovery information, also context based methods in e.g. [7, 8] could be applied to launch Supersessions. In addition, the filtering function F could be based on context. The details are out of scope of this paper, however. Figure 1: Co-operation of Applications by Application Supernetworking. C. Example The Producer could be a File Sharing application, whereas the Consumer can be an Instant Messaging (IM) application, for example. During a chat, the user may want to see a list of files the other user has shared. The IM application can show buttons on the GUI related to file sharing even though it does not include the needed functionality itself. The File Sharing application provides those services instead. With AS, the IM application finds local services including the browsing of files using the Middleware and renders buttons for those services to the UI. Now, with a click of a button, the user can trigger the launching of the File Sharing application which is the start of a Supersession. IM provides the selected service and the name of the other user to the Middleware. The Middleware forwards the data to the File Sharing application which can then directly show the other user s files without any further user input. Actually, there is no reason why an application could not be both a Producer and a Consumer. The IM application could also produce message sending service for other applications. D. Advantages of Supernetworking We expect Supersessions to increase usability in all user skill levels. For the expert user, Supersessions provide a shortcut to another application. It has already been shown that even simple shortcut approaches can save the mobile device user a considerable amount of key presses [9]. For the beginner, the list also acts as a tool in finding available services. Supernetworking-based middleware helps the user in switching between different roles, e.g. family member, student and researcher, and maintaining consistency between applications. Instead of joining different peer groups with different applications, the middleware could share the same peer group session between applications. If the user joined the home peer group with one application, the state of the middleware would change, so the home peer group members would also be seen in all other applications running on the middleware. When multiple applications are used simultaneously, memory and processing power can be used more effectively. Protocols and connectivities can be controlled in a centralized manner by the middleware and e.g. only one occurrence of a protocol and a connectivity module may need to be loaded into memory. Then, bandwidth usage is optimized in that only one protocol instance has to do a handshake. Many of these optimization schemes are even more crucial when resources are scarce, such as in mobile devices. It must be noted, however, that the middleware complexity should not rise too high making cost greater than the benefit. The benefits of middleware and AS are broader than just optimising resources, though. Supersessions resemble some existing technologies including Microsoft s Object Linking and Embedding (OLE) and shared views of the Symbian OS in which the application may have to be designed for optimal co-operation with specific applications. The user might also get confused by different applications using same views. With Supersessions, applications are separate and the Provider is switched to foreground when one of its services is triggered. Also, applications are enforced to fulfil the AS specification which guarantees interoperability. IV. CURRENT PROTOTYPES A. Implementation Environment We have implemented prototypes of Application Supernetworking-enabled middleware with Supersessions and applications to prove the feasibility of our approach. The prototypes are currently implemented for the Symbian OS 8.0a and Nokia Series 60 2nd Edition, Feature Pack 2 enabled mobile phones with native C++ object oriented programming. Supported phones include the Nokia 6630 and B. PnPAP We have implemented AS in our PnPAP middleware which is built on the Symbian client-server architecture. Differing from frequently used terminology both the client and server run on the same mobile device. Applications use the PnPAP

3 client for easy access to the PnPAP server which is the controller of the middleware. Currently, AS service registration is based on application specific service description files. When an application is installed, the installer SIS copies a service description text file to a directory under the PnPAP middleware directory. The text file contains tokens separated by line feeds, each token corresponding to a service. PnPAP can then read files under that directory to get a complete listing of the locally available services. An application s service description file name equals that of the executable, so whenever a service of an application is selected, PnPAP can launch the executable. After the application has started and connected to PnPAP via the client, PnPAP can forward the selected text to the Producer application so that the Producer can switch to the proper view and state. Thus, applications do not need to be run once for PnPAP to find the services they provide. Furthermore, an application does not need to be running to be able to trigger its services. C. File Sharing Application File Sharing application provides peer-to-peer (P2P) functionalities including creating, joining and leaving peer groups. File sharing, searching, downloading and uploading functionalities inside peer groups are supported. File Sharing is built on top of PnPAP, so it does not implement any P2P protocols or connectivities. File Sharing is a Producer application for Application Supernetworking. D. Navigation Application Navigation Application is a context-aware mobile navigation application with similar peer group related functionalities as File Sharing. Navigation Application is also built on PnPAP middleware. PnPAP is able to find the user s own location e.g. via Bluetooth GPS, and Navigation Application can get the location information from PnPAP. In addition to the user s own location, the members of the currently joined peer group(s) are shown on the map by using [5] to share context information of peers. Supersessions can be started by selecting a peer on the map view or from a list. Navigation Application is a Service Consumer. The application could also produce a show peer on the map service. E. Example of Supernetworking An example sequence of creating a Supersession between Navigation Application and File Sharing is depicted in Fig. 2. File Sharing application registers a service for browsing peers files. When the user selects one of the current peer group members on the map in Navigation Application, the application forms a dynamic menu according to the results of a DiscoverServices() method call. The menu includes the option File Sharing: Browse files. The user selects it and Navigation Application requests a Supersession start-up from PnPAP by calling the StartService() method. PnPAP starts the File Sharing executable if necessary and forwards the Supersession request to it. File Sharing then opens the correct view automatically and uses PnPAP to get a list of the selected peer s files. Figure 2: Example sequence of Supersession startup. A. User Input V. MEASUREMENTS 1) Test Setup To measure the feasibility of Supersessions, usability tests should be performed; however that is future work. Instead, to get an estimate of whether Supersessions help the user in practice, we measured differences in the user input needed in both the traditional and the Supersession enabled case. We measured the amount of user input needed, but it must be noted that we did not directly measure usability. The test case was to start the File Sharing application and access the list of a peer s files. The quantities we measured were the number of needed key presses and the time used in making them. The phone in our tests was the Nokia 6680 with PnPAP, File Sharing and Navigation Application installed. Both of the measured quantities represent only estimates, though. For example, the main menu of the 6680 is altered by customization and the amount of installed applications thus affecting the number of needed key presses. Also, the time it takes to perform each key press can vary significantly between users and contexts. 2) Traditional Case Initially, the Navigation Application is on and the map view is selected (Navigation Application (NA) map view). The user sees his friend on the map and wants to see the files he has shared. The user has to press the menu button (phone menu), browse to the desired application icon, start the application (File Sharing (FS) main menu), join peer group (FS manage peer groups), select browsing files (FS main menu 2), browse to the specific peer, and select the peer (FS browse files). We estimate that the desired application icon is

4 within 10 key presses in the phone menu and to select the correct peer, the number of key presses was estimated to range from 0 to 10. Measured limits (both lower and upper for the number of key presses, only lower for time) per each GUI state transition are presented in Fig. 3. FS main menu 2. In this transition, PnPAP connects to the network and a number of dialogs are shown. In the Supernetworked case, these phases have already been done during the use of the Navigation Application. Therefore, our measurements are in part biased in the favour of the Supersession case. However, because of the significant differences between the two cases, no fair measurements can be achieved. Table 1: Comparison of results in total. Quantity Traditional Supernetworking Key presses, lower limit 11 3 Key presses, upper limit Time (s), lower limit One additional benefit of the Supersession case is that Navigation Application shows the list of peers and services much earlier on. In the traditional case, the user must take nearly all the steps described in Fig. 3 to be able to observe that a peer or service is in fact unavailable. B. Use of Resources Figure 3: Start browsing files without Supernetworking. 3) Supersession Case Initially, the Navigation Application is on and the map view is open (Navigation application (NA) map view). The user now only has to choose the specific peer, open the menu, and select browsing files. File browsing is then started (FS browse files). The measured limits are presented in Fig. 4. Figure 4: Start browsing files with Supernetworking. 4) Comparison Table 1 shows that AS reduces the number of required key presses. Also, the lower limit for the needed time was reduced, whereas the upper limit was too hard even to estimate. The most time-consuming task in the traditional case is the state transition from FS manage peer groups to 1) Test Setup The use of resources is an important factor in mobile environments where resources are scarce. Thus, we measured the amount of used RAM at run-time both in the traditional and AS case. We wanted to measure the total difference including needed DLLs in both cases. Therefore, to measure the use of RAM, we used DevMan v2.50 software in the Nokia 6630 device to find the free memory of the whole platform. Because we could not stop all other processes from running on the 6630, they had minor random effects on the results. However, reproducible results were obtained with averaging. Generally speaking, the method was to read the free RAM both before and after starting functionalities to obtain a difference which we interpreted as the memory consumption. We excluded the effect of the GUI components on the memory consumption, as we approximate that that is near to equal in both cases. For the traditional case, we measured the amount of memory required when loading and using our native DC++ protocol and GPRS connectivity polymorphic DLLs (Thumb builds). Since different applications probably use their own protocol and connectivity libraries on top of the libraries provided by the operating system, we calculate that each application s networking components running simultaneously add to the memory consumption approximately by this amount. In the AS case, we measured the amount of memory required by both PnPAP client and server with AS support plus DC++ and GPRS DLLs. With AS the number of loaded protocols and connectivities can remain unchanged when the number of applications increases, so the effect of each application equals the memory required by PnPAP to support the additional application. We first measured the amount of RAM PnPAP uses when started by the first application. We then measured the consumed RAM when another application

5 starts using PnPAP and estimate that PnPAP requires the same amount for all subsequent applications. 2) Results We found that DC++ protocol and GPRS connectivity require 136 kilobytes of memory. That number was interpreted as the approximation of the amount of RAM that each traditional application requires to implement a similar set of networking features. Thus, for comparison, each simultaneously running application increases the use of RAM by 136 kb. In the AS case, we found that PnPAP takes 224 kb to start (incl. DC++ and GPRS on the server side). The PnPAP client DLL consumes additional 40 kb. The first application starting PnPAP thereby requires 264 kb of RAM. The client side PnPAP object and the server side objectsequal 12 kb, so additional clients increase the total RAM consumption by 52 kb. 3) Comparison Fig. 5 shows that the memory consumption lines cross at about 2.5 simultaneous applications. One or two traditional applications use less memory than in the AS-enabled case. With three applications or more, the Supernetworked case is lighter in terms of memory consumption. Thus, AS could help to save memory at least in the case of mobile power-users but not necessarily with beginners. We note, however, that in practice applications using DC++ and GPRS would most likely need to implement added functionalities that were present only in PnPAP in our measurements. PnPAP, on the other hand, included an unnecessarily rich set of services for the tests. Therefore, the results are biased to the traditional case s advantage. Figure 5: Comparison of memory consumption. VI. DISCUSSION AND FUTURE WORK The measurement results show that even though we have done hardly any optimization of the source code, our AS prototype can still save memory in the case of many simultaneously running applications. There are also other resources whose usage need optimization. E.g. a rich set of connectivities is a common feature in latest mobile devices. Using them optimally is challenging, and middleware can provide a flexible solution to cut down on e.g. cost and bandwidth and power usage. By sharing Supersessions between applications AS minimizes the need of bandwidth. However, depending on the Supersession, applications might not be able to use the services simultaneously with just one protocol instance. Thus, AS could provide an optimal compromise between bandwidth usage and the needed amount of protocol instances based on applications needs. The required amount of processing is also an important aspect to consider. We also showed that usability can be improved by Supersessions because of decreased need of user input. True evaluation of usability requires end-user tests, however. We will continue to evaluate the benefits of PnPAP with AS in more detail from both technical performance and usability points of view. VII. SUMMARY We have presented and extended the concept of Application Supernetworking and defined concrete examples of its use with our novel PnPAP middleware for mobile devices. Through preliminary measurements, we found that with Application Supernetworking, the use of resources can be optimised while increasing user friendliness by lowering the amount of needed interaction. However, more work is needed to further evaluate the feasibility of the concept. REFERENCES [1] K. Raatikainen, H.B. Christensen, T. Nakajima, Application Requirements for Middleware for Mobile and Pervasive Systems, ACM SIGMOBILE Mobile Computing and Communications Review, vol. 6, issue 4, October 2002, pp [2] J. Ala-Kurikka, M. Ylianttila, E. Harjula, O. Kassinen, Empirical aspects on implementing application supernetworking, Proc. of the Nordic Radio Symposium (NRS) 2004 incl. the Finnish Wireless Communications Workshop (FWCW) 2004, Oulu, Finland. [3] E. Harjula, M. Ylianttila, J. Ala-Kurikka, J. Riekki, J. Sauvola, Plugand-play application platform: towards mobile peer-to-peer, Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia MUM '04, College Park, Maryland, 2004, pp [4] J. Ohtonen, O. Kassinen, M. Ylianttila, Feasibility Study of a Mobile Peer-to-Peer Navigation Application, Proc. of the 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications Conference (PIMRC2006), Helsinki, Finland. [5] E. Harjula, J. Ala-Kurikka, D. Howie, M. Ylianttila, Analysis of Peerto-Peer SIP in a Distributed Mobile Middleware System, to appear in Proc. of IEEE Global Telecommunications Conference 2006 (GLOBECOM 06). [6] O. Kassinen, T. Koskela, E. Harjula, J. Ala-Kurikka, P. Pohjanen, M. Ylianttila, "Group-Based Content Push with Dynamic Session Startup", Proc. of the 4th International conference on Mobile and Ubiquitous Multimedia (MUM2005), The University of Canterbury, Christchurch, New Zealand, December [7] P. Korpipää, E.-J. Malm, I. Salminen, T. Rantakokko, V. Kyllönen, I. Känsälä, Context Management for End user Development of Context- Aware Applications, Proceedings of the 6th international conference on Mobile data management, Ayia Napa, Cyprus, 2005, pp [8] M. Raento, A. Oulasvirta, R. Petit, H. Toivonen, ContextPhone: a prototyping platform for context-aware mobile applications, IEEE Pervasive Computing, vol. 4, issue 2, Jan.-March 2005, pp [9] R. Bridle, E. McCreath, Inducing shortcuts on a mobile phone interface, Proceedings of the 11th international conference on Intelligent user interfaces, Sydney, Australia, 2006, pp