The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'06)
IMPROVING MULTIPLE MOBILE APPLICATION INTERACTION WITH
UNIFIED SESSION MANAGEMENT
Jussi Ala-Kurikka
University of Oulu
Finland
Juuso Ohtonen
University of Oulu
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
1-4244-0330-8/06/$20.002006 IEEE
Erkki Harjula
University of Oulu
Finland
Mika Ylianttila
University of Oulu
Finland
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.
The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'06)
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 6680.
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
The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'06)
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.
V. MEASUREMENTS
A. User Input
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
The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'06)
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
Key presses, lower limit
Key presses, upper limit
Time (s), lower limit
Traditional
11
30
26
Supernetworking
3
13
10
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
The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'06)
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. 16-24.
[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. 6369.
[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 2005.
[7] P. Korpipää, E.-J. Malm, I. Salminen, T. Rantakokko, V. Kyllönen, I.
Känsälä, ”Context Management for End user Development of ContextAware Applications”, Proceedings of the 6th international conference
on Mobile data management, Ayia Napa, Cyprus, 2005, pp. 304-308.
[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. 51-59.
[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. 327-329.