Context-Based Coordination for Pervasive Computing Applications

Verena Tuttlies Universitlit Mannheim, 68131 Mannheim, Germany

verena. tuttlies@uni-mannheim.de

Abstract-Pervasive computing applications should assist their user in aU situations of the daily life. These applications are able to interact with their environment, called context, in both ways. On one hand they are aware of their environment and can use this information in configuration decisions. On the other hand they actively modify the context. Existing ap­proaches only manage the use of shared resources like available functionalities and devices. However, they do not coordinate the interaction with context although context itself can be seen as a shared resource. Therefore, we present an approach to coordinate pervasive computing applications in multi-user environments explicitly considering context interactions.

I. INTRODUCTION

Pervasive computing envisions a ubiquitous presence of information processing devices. In cooperation these devices provide functionalities to their users supporting them in their every day life. Functionalities are typically realized as pervasive computing applications. Such applications are distributed and make use of resources and capabilities of various devices. They are context-interactive in the sense that they are context-aware and context-altering at the same time. Context-awareness refers to the ability of an application to identify its current context and to incorporate the context in­formation into configuration decisions. On a context change, an application can decide to reconfigure itself to provide the best possible configuration for the given environment. Context-altering denotes the capability of an application to modify the context itself. This can be realized by the use of actuators like a light switch or specific resources, e.g., the use of speakers to output audio.

Different approaches like Gaia [1], Aura [2] and iROS [3] exist which address the realization of pervasive computing applications. In the context of our 3PC project we have developed the BASE [4] / PCOM [5] system. BASE is a middleware which has been specifically designed for per­vasive computing. It allows communicating devices to cope with the dynamic availability of communication technology. PCOM is a component system which builds on top of BASE. It assembles applications from components which are available at runtime.

The problem that we identified in all approaches is that shared access to resources and functionalities is coordinated in all systems. However, the access to context which is

Thanks to my advisor Christian Becker and Gregor Schiele who have contributed to this work.

978-1-4244-5328-3/10/$26.00 ©201O IEEE 853

also shared by all applications is not considered. Especially in multi-user environments this may lead to problems due to the context-interactiveness of applications. Consider the following example: User A is in the meeting room executing his presentation application. In order to use the projector, the presentation application has turned off the light. After some time user B enters the room executing an ebook reader application. As the ebook reader requires a bright environ­ment, the application turns on the light. This forces the presentation application to react to the context change as the projection becomes hardly visible. Depending on the logic of the application, the reaction may result in an application reconfiguration or the modification of the context by turning off the light again. The problem can be reduced to the fact that every application changes the context according to its needs, disregarding other applications which are executed at the same time. As a consequence, a pervasive computing application can directly impact other applications.

The goal of our research is to address this problem by coordinating the access to context of pervasive computing applications. The coordination solves unobvious but unin­tended dependencies between executed applications.

II. ApPLICATION COORDINATION

The realization of application coordination basically re­quires two steps. At first, applications have to explicitly state how they depend on the context and how they modify the context in a certain configuration. This allows to determine if a context modification triggers an application reaction. Thus, we extend the notion of an application configuration (Section II-A). Based on this information we can develop algorithms for application coordination in a second step (Section II-B).

A. Extended configuration notation The basic idea of the extended configuration notation

is the explicit specification of how an application depends on the context and how it modifies the context itself. For this purpose, we have added two new components - the context goals CG and the context influences CJ - to the original configuration notation which consisted of resources Rand functionalities F. The resulting configuration is a quadruple ConjApp = (R,F,CG,CJ). The context goals state the dependencies which an application has on its context. The context influences denote the context which is produced by the application. Both elements depend on the

set of functionalities and resources which are used by the application. As an example consider the two configurations Conf�pp and Conf'J.pp of a navigation application:

Conf�pp = ({speakers, memory}, {navigation, audio_out}, audio_volume::; 2Odb, audio_volume = 60db )

Connpp = ({display, memory}, {navigation, visual_presenation}, 0 , 0 )

Configuration Conf�pp uses audio to guide its user employing the built-in speakers. Thus, the application uses speakers and memory as resources and a navigation and audio output functionality. The context goal states that the configuration requires the environment to be below a certain volume level in order for the navigation voice to be heard by the user. Furthermore, the application modifies the context by increasing the noise level to 60 db specified as context influences. Configuration Conf'J.pp in contrast uses a visual output to guide its user. It neither has goals towards the context nor does it modify the context in this configuration.

Context influences and context goals have to be provided by the application developer. Context influences must be specified for each resource that can be bound by an applica­tion, e.g., audio volume for speakers. The specific value like the actual audio volume is determined at runtime. Further­more, the application developer must define context goals for all possible application configurations. A refinement of these goals by the application user is conceivable.

B. Coordination Strategies The specification of context goals and context influences

forms the basis for application coordination. Consequently, suitable coordination strategies have to be developed in the next step. Coordination is required every time a new applica­tion becomes active or an existing application reconfigures itself as context goals and influences may have changed. The coordination is achieved through adaptation of involved applications. Currently, our system provides two types of adaptation, structural and behavioral adaptation. Using a structural adaptation the application must reconfigure itself by selecting another set of resources and or functionalities to change its context influences or context goals. An example is a navigation application that is asked to use a visual representation instead of guiding the user via speech. The second adaptation type is the behavioral adaptation. Here, the application has to change the context it produces, i.e., its context influences. An example is a context that is produced with a certain intensity like the audio level. If loud music violates a context goal but soft music is acceptable the application could be asked to turn down the music.

III. CURRENT AND FUTURE WORK

A centralized realization of our approach is shown in Figure 1. We have realized an application coordinator as a service of a smart environment (SE). Every application

854

� ------------------------------------------------------- , lj lj ;--------------, I c: c: I I .Q.-4 .Q'" I . ->- ->- ' I � 01 � 0'1 I

CI CG , ·-2 ·-2' : � � � � : I 0 (J) 0 U1 I . U U I L _____________ J

SE: ,

CI/CG � : ��: adapt : , , ,

Application Coordinator

CI/CG

B: -- ,

------+ App n I '--__________ --' adapt :

Figure l. Centralized Application Coordination

that enters the environment must register at the applica­tion coordinator by adding its context influences (CI) and context goals (CG). As the application coordinator holds this information from every application it can determine if context goals are violated by context influences and thus if a coordination is required. If this is the case, it selects a set of applications according to a coordination strategy and induces an adaptation process.

The centralized approach has been realized as a first step towards application coordination. Our current system supports a coordination using a last-come first-adapt strategy where applications must adapt which have last changed their context influences or goals. Moreover, we analyze application selection criteria to provide further coordination strategies. For future work we are planning to develop a distributed approach to be independent of an infrastructure.

IV. CONCLUSION

We have presented an approach for the coordination of pervasive computing applications. We allow to explicitly specify how applications depend on the context and how they modify it. This provides the necessary information to enable application coordination in multi-user environments. With the increasing number of pervasive computing applications in our life context-based coordination will become more and more relevant for a convenient usage of such applications.

REFERENCES

[1] M. Roman, C. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell, and K. Nahrstedt, "A Middleware Infrastructure for Active Spaces," IEEE Pervasive Computing, vol. 1, no. 4, pp. 74-83, 2002.

[2] D. Garlan, D. Siewiorek, A. Smailagic, and P. Steenkiste, "Project Aura: Toward Distraction-Free Pervasive Computing," IEEE Pervasive Computing, vol. 1, no. 2, pp. 22-31,2002.

[3] B. Johanson, A. Fox, and T. Winograd, "The interactive workspaces project: Experiences with ubiquitous computing rooms," IEEE Pervasive Computing, vol. 1, no. 2, pp. 67-74, 2002.

[4] c. Becker, G. Schiele, H. Gubbels, and K. Rothermel, "BASE­A Micro-broker-based Middleware For Pervasive Computing," PerCom 2003.

[5] c. Becker, M. Handte, G. Schiele, and K. Rothermel, "PCOM - A Component System for Pervasive Computing," in PerCom 2004.