applications, approaches are needed to avoid conflicts at runtime. In this .... to talk hands-free, the phone call application uses the microphone and a speaker ..... of the Fifth IEEE International Conference on Pervasive Computing and Commu-.
COMITY - Conflict Avoidance in Pervasive Computing Environments Verena Tuttlies, Gregor Schiele, and Christian Becker Universit¨ at Mannheim Schloss, 68131 Mannheim, Germany {verena.tuttlies,gregor.schiele,christian.becker}@uni-mannheim.de
Abstract. Pervasive Computing leads to novel challenges of application coordination. Applications may interfere with each other since they affect and share the same physical environment. A user that executes a navigation application utilizing a loudspeaker as output may annoy a user listening to music. To ensure a conflict-free execution of multiple applications, approaches are needed to avoid conflicts at runtime. In this paper we identify typical conflicts arising in Pervasive Computing. We propose how to detect potential conflicts by requiring applications to communicate their effects on the physical environment. After the detection, a suitable strategy is applied resolving the potential conflict. As a practical validation, we discuss how to model and avoid conflicts using our component-based software system PCOM.
1
Introduction
Pervasive Computing aims at the ubiquitous provision of context-aware services. Distributed applications are executed on devices present in a specific environment, offering functionality to users. In case the context changes, applications adapt to the modified environment, e.g., by adjusting the data presented to the user or by reselecting used devices. When multiple applications are executed in the same environment, they can interfere with each other as they affect and share the same physical environment. A prominent example are mobile phones that interfere with nearly every other application and user, e.g., in meetings, concerts, dinners, etc. Vice versa, a person on a mobile phone may feel disturbed by a user passing by, utilizing loudspeakers for his music application. To handle such conflicts, applications must be able to detect conflicts before they actually occur. Thus, they can coordinate themselves to avoid the conflicting situation. Our goal is to provide a middleware that enables applications to avoid conflicts by detecting and resolving potential conflicts. In earlier work [1] we discussed this problem space and gave initial directions to address it. In this paper, we propose an extension to component/service-based Pervasive Computing infrastructures that requires applications to specify their influence on the physical environment and allows them to define context situations they consider to be conflicts. Based on this information, potential conflicts can be R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM 2007 Ws, Part II, LNCS 4806, pp. 763–772, 2007. c Springer-Verlag Berlin Heidelberg 2007
764
V. Tuttlies, G. Schiele, and C. Becker
detected by the system and a negotiation between conflicting applications can be induced. Finally, we propose an integration into PCOM, our component model for Pervasive Computing. The paper is structured as follows. In Section 2 we introduce our system model. Conflicts and their avoidance are discussed in Section 3. Our conflict avoidance middleware is presented in Section 4. After a discussion on related work in Section 5, we give a short conclusion and an outlook on future work in Section 6.
2
System Model
We assume a Pervasive Computing environment to consist of a number of instrumented spaces. Such spaces combine stationary and mobile devices as well as embedded devices such as sensors and actuators. Applications can make use of the functionality provided by a space. Instrumented spaces can be realized by smart peer groups or smart environments possibly employing different operating systems. For the management of an office building, for instance, we assume that all – potentially competing – companies will provide their own infrastructure. Even in common areas, such as foyers or shared meeting rooms, a diversity of systems will exist. To add to this diversity, visitors will be roaming through such environments with their devices, e.g., mobile phones, navigation systems, PDAs, etc. As a consequence, conflict avoidance has to be conducted among a number of instrumented spaces. With respect to conflict detection and resolution, we assume a cooperative behavior of applications. For this purpose, applications are not bound to a specific application model, e.g., component- or task-based, or a common service specification. The only requirement we have for applications is that they specify their side effects on the physical environment by using a contract model. This can be done at different levels of granularity. A fine grained model would specify the effects for each individual part of an application, e.g., each component or object, while coarse grain models would specify the side effects for each participating node or only for the complete application. Later, we will see that an integration of our approach into a fine grained model can provide means for adaptation to conflicts based on the available mechanisms of the platform. However, in general, we only assume that an application is aware of its side effects and that some means for conflict resolution will be provided.
3
Conflict Avoidance in Pervasive Computing Environments
In this chapter we define conflicts and discuss their characteristics. Subsequently, we analyze the system components required for the detection of potential conflicts and sketch our approach.
COMITY - Conflict Avoidance in Pervasive Computing Environments
3.1
765
Conflicts
The execution of an application in Pervasive Computing may affect its physical environment, namely its context. For example, a music application playing music influences its context by changing the audio level in the surrounding area. When multiple applications are executed simultaneously, their effects on the context may interfere. The influence of two music applications, each playing a different CD in the same room, will obviously cause a conflict for both applications. In this paper we denote a conflict as follows: A conflict occurs for an application or a user, if a context change – caused by an application – leads to a state of the environment which is considered inadmissible by the application or user1 . Consider the following scenario of a phone call and a simple “follow-me” application. User Bob is in the living room, talking on his phone. As Bob likes to talk hands-free, the phone call application uses the microphone and a speaker installed in the living room. Meanwhile, user Anne listens to music provided by her “follow-me” application. As she moves from the bedroom to the living room, her application automatically detects the changes in its context. It discovers an unoccupied speaker in the living room, adapts to the output device and plays the music in the living room. As the resource requirements of both – the “follow-me” and the phone call application – are satisfied, the two applications can be executed. However, Bob feels disturbed by Anne’s application, because the music interferes with his phone call. As he considers the situation to be inadmissible, a conflict for Bob has occurred. In contrast, Anne may not consider Bob’s phone call to be disturbing while listening to music. This example shows that conflicts are not necessarily symmetric. In general, the existence of a conflict depends on the preferences of the respective user. Thus, for conflict avoidance, conflicts need to be defined by applications and users. In the subsequent section we discuss how conflicts can be specified and which components are needed to avoid conflicts at runtime. 3.2
Conflict Avoidance
In an open dynamic system environment – as addressed in this paper – the number of applications which will be executed in parallel is unknown. In order to ensure a conflict-free execution, conflicts need to be detected before they actually happen. However, the consideration of arbitrary context changes in order to predict conflicts, can be very complex and resource consuming. Instead, we require every application to state how it will affect the context in order to be executed. Based on this information, the system can reliably and efficiently “predict” potential conflicts. In this section we describe the basic idea of conflict avoidance in Pervasive Computing in detail. We discuss necessary system components and show how they interact at runtime. 1
Note, that a change of the context, e.g., by a user entering a room requires an application, for instance a personal tracking service, in order to affect the context.
766
V. Tuttlies, G. Schiele, and C. Becker
domain
Application 1 Application 2
... Application n
context influences
context updates
context influences
context
Conflict Manager
context influences
Context Model
conflict specifications
conflict specifications
Conflict Specifications conflict specifications
user
Fig. 1. General Approach
Figure 1 depicts our approach. The system consists of applications, domains, a conflict manager, a context model and a conflict specification database, which we describe in the following: Applications may be executed by arbitrary – possibly different – operating systems in a given domain. A domain refers to a spatial area of the physical environment. Consequently, the domain of an applications is defined by the physical environment in which its user is located and whose devices are utilized by the application, e.g., speakers, displays, etc. Each domain is associated with a conflict management component, the so-called conflict manager. This component is responsible for the detection of potential conflicts and their resolution. In order to detect potential conflicts, the conflict management component relies on the information stored in the context model and the conflict specification database. The context model holds information on how the physical environment is currently affected by active applications. The conflict specification database contains descriptions of situations that are considered a conflict by some application or user in the domain. Both, context modifications as well as conflict specifications, are provided by applications, using suitable specification languages. In addition, conflicts may be specified by users independent of an application. As an example, a user may configure a living room to respect siesta. To realize the restriction, a conflict specification would be added to the database, stating that no audio output above a given level is allowed between 12 a.m. and 2 p.m. Before an application is executed, it communicates its effects on the context to the conflict manager. The conflict manager then determines, if the defined effect will lead to a conflict. For this purpose, it alters the current context model by the specified context change and compares the result with the set of conflict specifications. In case a specification matches, a potential conflict has been
COMITY - Conflict Avoidance in Pervasive Computing Environments
767
detected. The application is informed that its execution will cause a conflict and a conflict resolution is induced. If the effect does not lead to a conflict, the application can be executed and the context model is modified by the application effects. In case a conflict has been detected, the system should try to resolve the conflict automatically. A simple approach to resolve the conflict could be to prohibit the execution of the respective application. A more sophisticated resolution strategy is the adaption of the applications encountering and causing the conflict. An alternative application configuration could be inferred enabling all applications to be executed conflict-free. In Section 4.2 we will show that the integration into our component system PCOM will automatically provide means for such an adaptation. Note that due to contradicting user preferences automatic conflict resolution may be impossible. Users requiring different levels of brightness in a room will always be in conflict with each other. In such cases, the users must be notified to resolve the conflict manually. Clearly, other resolution strategies are conceivable and are subject to future work. In the next section we present the realization of the proposed approach as an extension of our previous work in Pervasive Computing system software, the PCOM system [2]. First, we give an introduction to PCOM and then present the additions to enable conflict avoidance in our system.
4
COMITY
This section describes the COMITY system, our realization of conflict avoidance in Pervasive Computing environments. Although our discussion focuses on COMITY as an extension of PCOM, applications running on other platforms can also participate in the conflict avoidance by specifying their influences and conflict specifications. First, we briefly sketch the application model and automatic adaptation mechanisms of PCOM. After that, the extension of PCOM’s contract model for conflict management is presented. 4.1
PCOM
PCOM is a minimal component system that is designed specifically for Pervasive Computing systems with resource restricted devices. It provides a componentbased application model that allows to specify semantically enriched contracts between components. Using this model, PCOM is able to compose applications dynamically from currently available components and to adapt them automatically to changing environments, e.g., fluctuating resource and device availability. In this section we give a brief overview of the features of PCOM that are needed to understand the integration of conflict avoidance into the system. More details about PCOM can be found, e.g., in [2]. The basic building block of an application in PCOM is a component. Components are atomic with respect to their distribution and provide a contract model
768
V. Tuttlies, G. Schiele, and C. Becker
root component
Application Application
UI UI (audio) (audio)
contract
Storage Storage
component
Microphone Microphone
Speaker Speaker
Fig. 2. PCOM Application Tree
that specifies i) the functionality offered to other components, ii) the functionality required from other components, and iii) the resources required from the local execution platform, such as needed memory or a special sensor. An application is modeled as a tree of components, as depicted in Figure 2 where a designated component – the root – identifies the application’s life cycle. In order to execute the application, the system searches candidates for every dependency, i.e., for each required component, starting top down. Once a complete configuration is found, the application can be executed. If a component becomes unavailable or the contract changes due to resource constraints, the application must be adapted. To do so, the component container is notified. The container provides a runtime environment for components and manages their life cycles. Upon notification, the container pauses the application and starts searching for an appropriate replacement. If it is successful, it resumes the application. Otherwise the container also marks the component needing the replacement as unavailable and repeats the process for its parent component. If the root component is reached and no configuration could be found, the container may abort the application. To manage the available resources in the system, the container relies on socalled resource managers. Each manager is responsible for monitoring a specific resource and for coordinating components accessing it. As an example, if a resource manager for energy detects that the battery on a given device is running low, it adapts the contracts of all components that requested a certain level of energy to work. Consequently, contracts may become invalid and applications need to adapt to the changes. 4.2
PCOM Extensions
In Section 3.1 we discussed how an application can state its influence on and its requirements towards the physical environment using so-called influence and conflict specifications. Based on this information, a Conflict Manager can determine if the execution of an application will lead to a conflict in the environment.
COMITY - Conflict Avoidance in Pervasive Computing Environments
769
In order to realize this approach with PCOM, two steps must be taken. At first, the influence and conflict specifications of an application have to be integrated into PCOM and an interface to the Conflict Manager has to be defined. For this purpose, we model both kinds of specifications as extensions of PCOM’s contract model, creating so-called context contracts. In the second step, the Conflict Manager itself needs to be realized. The Conflict Manager is responsible for negotiating the context contracts. In consideration of the state of the physical environment and a set of relevant conflict specifications, the Conflict Manager must determine, if the execution of an application will lead to a conflict in the environment. Context Contract. The basic idea of the integration of the context contract in PCOM is to model the physical environment as a set of resources. Each resource abstracts a certain aspect of the physical environment that can be affected by applications, e.g. light or audio level. A classification of such aspects can be found in [3]. In order to be executed, an application has to acquire the context resource which reflects the impact it will have on the physical environment. The application shown in Figure 2, for example, outputs audio to the environment using a speaker. Thus, it must specify that it requires the context resource “AudioOutput” in its contract, indicating how it will affect the environment if executed. As applications are built from components in PCOM, the effect on the physical environment depends on the current component composition. For example, if the speaker cannot be bound at runtime, the application could adapt to a set of headphones. Using the headphones will not affect the physical environment. Thus, context resources are not allocated to the application but to the component which is responsible for the impact on the physical environment. We specify conflicts using first order predicate logic. Every expression may address the state of one or more context resources. Conflict specifications can be defined in any component contract in the application tree. The interface between the context contracts and the Conflict Manager is realized by so-called Context Resource Managers. As discussed before, PCOM automatically forwards a resource requirement to the local resource manager that is responsible for the respective resource type at runtime. If the manager grants the resource, the component can be executed. Otherwise PCOM searches for alternative application configurations. To reuse this mechanism, we include special resource managers for context resources on every device, the Context Resource Managers. If a Context Resource Manager receives a context contract, it forwards the request to the Conflict Manager responsible for the current domain. The Conflict Manager then checks if the allocation of the required context resource will lead to a conflict. In case a conflict is detected, the Context Resource Manager is notified that it cannot allocate the resource. It denies the context resource to the component and the conflict is automatically avoided by searching for an alternative configuration. Conflict Manager. The avoidance of conflicts in PCOM is the task of the Conflict Manager. It is responsible for managing conflicts for a given domain
770
V. Tuttlies, G. Schiele, and C. Becker
PCOM Container
Resource Manager Context Resource Manager
Context Manager
Conflict Specification Manager
Conflict Manager Interface
device
...
Context Contract
...
component
device
Resource Manager
device PCOM Container
device
Fig. 3. Conflict Management with COMITY
and is automatically discovered by the Context Resource Managers using the PCOM discovery service. As depicted in Figure 3, the Conflict Manager consists of three PCOM components, the Conflict Manager Interface, the Conflict Specification Manager, and the Context Manager. The Conflict Manager Interface acts as the interface between the Conflict Manager and the remote Context Resource Managers. It receives context contracts, extracts the context influences and conflict specifications, and forwards them to the Conflict Specification Manager and the Context Manager respectively. In addition, it handles concurrent requests from several Context Resource Managers to ensure a consistent system state, e.g., by serializing incoming requests. The Conflict Specification Manager manages the set of conflict specifications for an administrative domain. It keeps the set of conflict specifications of currently active applications and components updated. If a contract becomes valid, it adds the contained conflict specifications to the set and removes them if the contract is terminated. The Conflict Specification Manager uses a soft state approach to be notified if a device becomes unavailable. This is necessary as we cannot assume that devices will always be able to unsubscribe from the system. The Context Manager is responsible for administrating the context resources and grants Context Resource Managers permits to allocate them to components at runtime. It monitors, how context resources are distributed among the applications and which resources are not in use. The state of the entire set of context resources is referred to as the state of the physical environment. Based on this information and the current set of conflict specifications, the Context Resource Manager determines if a context resource can be allocated to a requesting component. For this purpose, two different checks have to be performed. In case a component requests a context resource, the Context Resource Manager checks if the application’s specified context modifications will cause a conflict for another application in the environment. In case the test is negative, it checks if the execution of the application will lead to a conflict for the application itself. If the second
COMITY - Conflict Avoidance in Pervasive Computing Environments
771
test proves to be negative as well, the Context Resource Manager allocates the required context resource to the component. However, in case the execution of an application will cause a conflict in the environment, the respective resource is denied. As a consequence, the application cannot be executed, as the requirement towards the context resource cannot be satisfied. Thus, the unavailability of the resource induces the application to adapt. This process resolves the conflict before an actual interference of the two applications happens. However, the resolution through adaptation as presented, implies a first come – first served strategy. This is not always desirable, as priorities of applications or a compromise between applications are conceivable, for example. The development of suitable resolution strategies is subject to future work.
5
Related Work
Conflicts and their detection and resolution have been examined in a number of research projects. In Gaia, conflicts can be detected based on a set of space-level policies [4]. This set has to be defined by an administrator, and enables the detection of conflicts based on the state and the context of the environment. Park et al. [5] consider conflicts as actions of services which have contradictory effects on context attributes and service state variables. Based on action semantics, they determine if two actions have encountered a conflict and resolve the conflict by using a resolution policy. These approaches concentrate on the detection of occurred conflicts. In contrast to this, we aim at the detection of conflicts before they actually occur and try to avoid them. Further approaches addressing conflicts exclusively focus on the resolution of conflicts. Shin et al. [6] assume a prior detection of conflicts and discuss different resolution strategies for conflicts. Similarly, CARISMA [7] solves existing conflicts by using a micro-economic approach based on a sealed-bid auction. Most similar to our approach, Syukur et al. discuss conflict detection and avoidance strategies assuming a policy-based application model in [8]. Such policies are used to explicitly control the behavior of an application. In contrast to this, our approach is independent of a specific application model.
6
Conclusion and Future Work
In this paper we presented an approach to avoiding conflicts in Pervasive Computing environments. The general idea of our approach is that applications specify their intended influence on the physical context before they can be executed. Based on this information, a set of conflict specifications and the current state of the environment the system is able to detect potential conflicts at runtime. In order to avoid the actual conflict, the potential conflict is resolved using a suitable strategy. Subsequent, we showed how to integrate the proposed approach into our component system PCOM.
772
V. Tuttlies, G. Schiele, and C. Becker
Currently we are developing our specification languages for conflicts and are implementing the necessary extensions for PCOM. In addition, we are working on an extended definition of conflicts in order to factor in context changes that are not caused by applications. In future work we will examine different resolution strategies in more detail. Finally, we plan to extend our system to handle nonexclusive context resources.
References 1. Schiele, G., Handte, M., Becker, C.: Good Manners for Pervasive Computing–An Approach Based on the Ambient Calculus. In: PERCOMW 2007: In: Proceedings of the Fifth IEEE International Conference on Pervasive Computing and Communications Workshops, White Plains, USA (2007) 2. Becker, C., Handte, M., Schiele, G., Rothermel, K.: PCOM - A Component System for Pervasive Computing. In: Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications (PerCom 2004), Orlando, USA (2004) 3. Korpip¨ aa ¨, P., M¨ antyj¨ arvi, J., Kela, J., Ker¨ anen, H., Malm, E.J.: Managing Context Information in Mobile Devices. IEEE Pervasive Computing 02(3), 42–51 (2003) 4. Ranganathan, A., Chetan, S., Al-Muhtadi, J., Campbell, R.H., Mickunas, M.D.: Olympus: A High-Level Programming Model for Pervasive Computing Environments. In: International Conference on Pervasive Computing and Communications (PerCom 2005), Kauai Island, Hawaii (2005) 5. Park, I., Lee, D., Hyun, S.J.: A Dynamic Context-Conflict Management Scheme for Group-Aware Ubiquitous Computing Environments. In: Proceedings of the 29th Annual International Computer Software and Applications Conference (COMPSAC 2005), Edinburgh, Scotland (2005) 6. Shin, C., Woo, W.: Conflict Resolution Method utilizing Context History for Context-Aware Applications. In: Proceedings of ECHISE 2005 - 1st International Workshop on Exploiting Context Histories in Smart Environments, Munich, Germany (2005) 7. Capra, L., Emmerich, W., Mascolo, C.: CARISMA: Context-Aware Reflective mIddleware System for Mobile Applications. IEEE Transactions on Software Engineering 29(10), 929–945 (2003) 8. Syukur, E., Loke, S.W., Stanski, P.: Methods for Policy Conflict Detection and Resolution in Pervasive Computing Environments. In: Policy Management for the Web Workshop in conjunction with the 14th International World Wide Web Conference, Chiba, Japan (2005)
