Context management in context-aware applications manages contexts obtained from various sensors and services related to users and environments. However, most of the previous context management mainly focuses on single user or single application. In this paper, we propose Context Manager that resolves conflicts among multiple users and multiple services for contextaware application in smart home environments. In such environments, the proposed Context Manager resolves conflicts among users by assigning priority to each user based on their context. In addition, it adjusts weights of the context by applying Bayesian theory to conflict history of users and applications. Furthermore, Context Manager detects and resolves conflicts among services by utilizing preferences of users and properties of the services. During experiments on ubiHome, a smart home test-bed, the proposed Context Manager resolved conflicts among users more accurately than resolution method having fixedpriority. The Conflict Manager also resolved conflicts among ubiServices. We expect the proposed method can play a vital role in context-aware applications for offering personalized services to users by resolving service conflicts among applications as well as users.
The aim of ubiquitous computing is to provide users with intelligent services based
on the information obtained from distributed but invisible computing resources.
These services do not require any cumbersome interface or leaning procedures for
users to use them [
Over the last decade, most research, aimed on resolving conflicts, has been done
on smart home and intelligent office. Reactive Behavioral System (ReBa) supports
conflict resolution among devices in office environment such as, between electric
lamps, display devices, and telephones [
However, context management techniques in the previous research have various
limitations when they are applied to multi-user environment with various applications.
In the case of ReBa, it is difficult to provide to each user with particular services
because ReBa focuses on the service for grouped users by inferring main activities
from the environment [
In this paper, we propose Context Manager to resolve conflicts caused by use of services among multiple users and limited resources among multiple services. In order to resolve the conflicts, the proposed context manager consists of four components: Context Preprocessor, Context Database, Conflict Manager and Final Context Deliverer. Context preprocessor carries out filtering and converting context. Context Database keeps track of several kinds of context. Conflict Manager resolves conflicts among services and among users. Final Context Deliverer sends the conflict-resolved context to applications.
The proposed Context Manager has following advantages. Firstly, it resolves the conflicts among users by assigning priority to users based on their contexts, such as users’ identity, time, location and behaviors. Secondly, the Context Manager adjusts weight of context by applying Bayesian probability to conflict history of users. Consequently, it can reflect the change of users’ preference and their environment. Thirdly, the Context Manager detects and resolves conflicts among applications by utilizing their properties and relationship between them. Therefore, applications provide users with personalized services by resolving conflicts not only among applications, but also among users.
This paper is composed as follows. In Chapter 2, we introduces unified contextaware application model for ubiquitous computing environments. Chapter 3 describes the architecture of Context Manager and Chapter 4 explains the conflict resolution method to resolve conflicts among services and among users. Experimental setup and results are discussed in Chapter 5. Finally, we conclude in Chapter 6. 2
In order to provide the personalized service, we represent context information as
5W1H (Who, What, Where, When, How, Why). 5W1H contains comprehensive
information about user and his surrounding environment. We defined it as unified
context [
ubiService
Service Provider trreeUCC’ SCCC/oSnStext MFCanager trIepn ContextFICn/ItCegrator UCC FC/PC Self Configuration Manager
PC/FC FC
PC Self Configuration Manager Preliminary Context Generator
Signal processing
A sensor
FC’
FC: Final Context PC: Preliminary Context IC: Integrated Context SCC: Service Conditional context SC: Service Status UCC: User Conditional context ubiService
PC/FC FC PC ubiSensor Preliminary Context (PC): A unified context which describes current situation of a user and his environment, and includes all or part of 5W1H. It is generated by ubiSensors Integrated Context (IC): A unified context which describes current situation of a user and his/her environment, and includes all of the 5W1H. It is generated by Context Integrator User Conditional Context (UCC): A unified context which expresses an action and parameters of a service and related user condition. It is used for generating User Conditional Context’. User conditional Context’ is generated by Profile Manger. User Conditional Context’ (UCC’): A unified context which expresses an action and parameters of a service and related user condition. It is used for matching Integrated Context. User conditional Context’ is generated by Interpreter. Service Conditional Context (SCC): A unified context which expresses an action and parameters of a service and related user condition. It is used for matching Integrated Context. Service conditional Context is generated by Service provider. Final Context (FC): A unified context which describes a user, his environments, and service action and parameters. It is used for triggering a service. It is generated by Context Manager.
An ubiSensor is composed of a physical sensor, Signal Processing module, Preliminary Context Generation module and Self Configuration Manager. The physical sensor perceives a change related to a user and his environment. Signal processing module extracts feature information from the sensed signal. Preliminary Context Generation module generates a preliminary context from the feature information. The ubiSensor delivers this context to ubiServices located within a working area through a multicast group established by Self Configuration Manager. A ubiService is composed of Context Integrator, Context Manager, Interpreter and Service Provider. Context Integrator collects preliminary contexts created by various ubiSensors located within a working area during given time interval. It classifies the preliminary contexts to each sub-element and analyzes the sub-elements by applying a decision making technique. Context Integrator generates an integrated context of each user and delivers integrated contexts based on Context Manager. Context Manager searches conditional context from a Hash-table, which manages specific service action and condition, corresponding for each integrated context. It generates a final context to be used by applications after resolving conflicts among users and services. Finally, Service Provider executes appropriate action with parameters described in the final context. This utilizes application-specified methods which are programmed by application developers.
In ubiquitous computing environments, computers with limited memory and
processing power are embedded in objects or appliances. In the limited and distributed
computing environments, Context Manager maintains only small amount of information,
unlike the centrally managed systems that keep all the information [
Final context
Context
Integrator
Integrated context User conditional context
Interpreter
Service
Provider Service Information
C o n t e x t P r e P r o c e s s o r
F D ian ilvee lonC r re txe t
Final Context
Service Provider In addition, short-term memory in Context Manager manages the history of users and services to resolve conflicts dynamically. To deal with the conflicts in a dynamic way, Context Manager preprocesses context, resolve conflicts with history management, and generates final context. Figure 2 illustrates an overall architecture of the Context Manager.
Context Database Fig. 2. Context Manager. It consists of Context Preprocessor, Conflict Manager, Final Context Deliverer, and Context Database
As shown in Figure 2, Context Preprocessor receives final contexts and integrated contexts from Context Integrator. It also receives conditional contexts from Interpreter and Service Provider. Then, it stores the resulting contexts to Context Database. The Context Database keeps track of the contexts and maintains conflict history of users and services to resolve conflicts among users and services. Final Context Deliverer builds a final context after resolving conflicts among users and services, and then delivers it to Service Provider and Network module.
Context Preprocessor carries out pre-treatment of several kinds of contexts, such as integrated context, conditional context, and final context. Figure 3 shows context processing in Context Preprocessor.
Conditional context database
From users 5W1H
5W1H From a registered service 5W1H
Default User 1 - -
User N Conditional Context
Preprocessing If there is a user conditional context table, then add conditional context to the table. Conditional Othercwoinsea,ticorneaaltecoantneexwttthaeblteabalned add Context
Integrated contexts User 1 5W1H User 2 5W1H User 3 5W1H Integrated Context
Preprocessing
If integrated context matches userspecified or default conditional context, then Context Preprocessor build
matched context User1 User3
Matched user context Who What When Where How Why Who What When Where How Why
Conditional context database
Hash table
Default User 1 - -
User N Conditional
Context
As shown in Figure 3, Context Preprocessor inserts user conditional contexts and service conditional contexts to Hash table. In the case of integrated contexts, Context Preprocessor yields a matched user context after matching integrated context to conditional context. Context matching is archived in two ways: by matching integrated context with user-specified conditional context and matching it with default conditional context. In each step, if integrated context matches a conditional context, Context Preprocessor builds a matched user context by combining ‘What’ field of the conditional context and ‘Who, When, Where, How and Why’ fields of the integrated context. Furthermore, Context Preprocessor collects and filters the final contexts from other services within working area.
Context Database keeps necessary contexts and related information in order to support generation of final context. It contains several kinds of context such as conditional context, final and user context within a service area, and conflict history of users and a registered service. Conditional context table stores conditional contexts generated by users and a service developer. User context table keeps context of the users who are currently related to a service. The user context table is used to select one user when users leave the service area. The final context table storing final contexts of other services is used to confirm whether conflicts are caused within the service area.
Final Context Deliverer offers the final context, which has service action and information about its user, to Service Provider and Network module. Therefore, Final Context Deliverer performs two kinds of works: context generation and context delivery. In context generation, it makes a final context which has unique information of the service and doesn't cause conflict. Next, Final Context Deliverer provides the context with Service Provider. It also confirms whether the context is reflected to the service by utilizing service status information coming from Service Provider. With the result, Final Context Deliverer notifies the change of the service to other services if the result is true. Otherwise, it tries to again send the final context, if the service did not work on the final context. 4
Conflicts of context-aware applications occur not only due to multiple users who access services at the same time, but also due to services trying to share resources in their surrounding. To solve conflict among users, Conflict Manager assigns priority to users and chooses the user given the highest priority. In addition, to deal with conflict among services, Conflict Manager detects and resolves conflicts, based on the properties of services and relationship between them. Meanwhile, priority of users and services are not fixed, but adapts to user's preference and behaviors. Therefore, Conflict Manager not only resolves conflicts among users and among services, but also dynamically assigns priority to users and services.
User conflict Manager resolves conflicts caused by users who try to use services
within a service area. To resolve the conflict, User Conflict Manager manipulates user
contexts in two steps: building a user conflict list and selecting a proper user from it.
User Conflict Manager makes a conflict list of matched user context on users who are
expected to cause conflict among users, including those who are currently using the
service. In this process, users who leave the service area are excluded from the list
because we assume they do not want to use the service any more. In addition, user’s
feedback is also delivered to Conflict History Manager. The context is considered as
user feedback if there is user implicit context such as a remote controller or Tangible
Media Controller (TMC) [
Matched user context User1 5W1H User2 5W1H
Build A conflict list
(b)
User context User 1 5W1H
User conflict list Selected user context User2 5W1H
Choose A user context
Users’ Feedback C o n lif c t H i s t o r
Context query an g e r Context priority Television Television Service
Sitcom
Available contents -News -Drama -Sitcom
Today’s news (a)
Drama User 3 User 1
User 2
As shown in Figure 4(a), there is a television service providing user 1 with sitcom program in a service area. Simultaneously two users, user 2 and user 3, are trying to use the service. In this scenario, we assume that user 2 usually uses the service when conflicts cause among them. Therefore, a service conflict arises due to use of television services by the three users. In this conflict situation, User Conflict Manager, shown in Figure 4(b), detects the conflict and builds a conflict list consisting of contexts of user 1, user 2 and user 3. Based on the conflict list, it then queries priority of each user from Conflict History Manager. User Conflict Manager obtains the priority of users within the service area. Finally, it selects user 2 having the highest priority.
Service Conflict Manager resolves conflicts caused by multiple ubiServices trying to share resource in a service area. It deals with conflict in two ways: inward conflict resolution and outward conflict resolution. In inward conflict resolution, it resolves conflicts caused by other services within a service area. Service Conflict Manager creates a context which contains information about the service and a stop command for it, if resources involved in other services are the same as those of the service itself. As a result, the application responds to changes of other services which cause conflict, using final contexts coming from other services. In case of outward conflict resolution, Service Conflict Manager prevents the registered service causing conflict with other services. To detect possible conflicts, it checks to see if there are any services using the same resource before delivering the context. Service Conflict Manager compares priority of the service contexts calculated from Conflict History Manager if there are conflict services within a service area. Finally, it sends the conflict-resolved context to Final Context Deliverer when there aren’t any services related to the same resource. In addition, Service Conflict Manager just sends the resolved context to Conflict History Manager to notify the result of conflict resolution. Figure 5 shows a conflict situation among ubiServices and a resolution procedure on it. FC of Telephone
service
User 1 5W1H Service contexts Light service 5W1H
Conflict-resolved User1 5W1H context
Inward Conflict Outward conflict Bully Selector (b)
Selected user context 5W1H User 1
C o n User’s Feedback liftc
H cCoonntfelixctt Qcounetreyxt itrsyoM Context priority aan g e r Resources
-light Audio P:70 Music Service Resources -sound P:60
Electric Light P:50
Light Service (a)
Telephone
P:90 Telephone Service Resources -sound Movie Service
TeSleervviiscieoPn:80 --Rlsieogsuhontudrces
Television -display
As shown in Figure 5, there are four devices: eclectic light, audio player, television and telephone. Audio provides music service, electric light provides light service, telephone provides telephone service and television provides movie and television services. These services also utilize specific resources of each device. In this situation, the telephone service causes a conflict with television service due to the sound resource. Therefore, Service Conflict Manager detects the conflict in inward conflict resolution. It then builds a final context containing a stop command for the registered service. Afterward, Service Conflict Manager compares the priority of the registered service with the priority of telephone service. According to the priority, it selects the context of the telephone service.
Service Conflict Manager also deals with the situation when multiple services want
to use resources at the same time. This is because services can respond to the same
condition. In the case of this conflict, several services want to use the same resource.
For example, television and movie services can be triggered at the same time when a
user enters home. To deal with this situation, we adopt bully algorithm that elects a
leader among processes in distributed computing environment. The algorithm chooses
a coordinator with the highest priority [
Conflict History Manager takes charge of maintaining conflict history and
determining priority of conflicting context. To efficiently use the limited storage, it only
maintains conflict history for a short period of time. In addition, to reflect user preference,
Conflict History Manager calculates the priority of conflicting contexts based on
Bayes theory which is widely used for classification or prediction [
Conflict Manager
Conflict history Manager Feedback context Conflict context Context Query Context Priority
CCoonntetexxtt SSeel elecctitoionn Weight Table
PPriroiorirtiyty CCaalclcuul alatitoionn
Conflict history feature vectors
User 1 - -
User N
CCoonntetexxtt
AAccccuummuul alatitoionn User 1 - - User N
Weighted history
Conflict history
of a user WWeei gighhtt CCaalclcuulalatitoionn
WWeei gighhtt
MMaasskkiningg
As shown in Figure 6, Conflict History Manager receives feedbacks and conflicting contexts of users from Conflict Manager. Based on the contexts, Conflict History Manager builds feature vectors containing information about the conflict situation. Each feature vector is represented in the Table 1. Afterwards, the feature vector is stored in a history file so that it can be retrieved when required. Then, Conflict History Manager loads the feature vectors, related to a specific user, from conflict history. Conflict History Manager manipulates weights of conflicting contexts used for priority calculation of users. Therefore, it recalculates weights of conflicting contexts based on feature vectors of a user. In order to obtain the weight, Conflict History Manager applies Bayesian theory to the feature vectors.
Equation (1) shows Bayesian theory. In the equation, feature vector X is composed of (x1, x2, x3, x4, x5, x6). Each element of X is mapped to the value of SVC (Service Type), L(location), T(Time), G(Gesture), S(Stress), and WC(Who_conflict) in table 1. The result of conflict resolution Hj, which is represented by (H1, H2) indicates the SC which is Target class. Consequently, we obtain probability P(H1|X), for allowing the current user of a service to continue using the service when conflict arises, by multiplying posteriori probability (X|H1) and prior probability P(H1).
P ( H j | X ) =
P ( X | H j ) P ( H j )
P ( X ) (1)
According to the equation, we assume that current user of a service will continue using the service in case of a conflict when posteriori priority P(H1|X) is greater then P(H2|X). Otherwise, another user uses the service. So, priority of context is the difference between maximized posteriori probability of P(X|H1)(H1) and P(X|H2)(H2). Therefore, weight of each feature is expressed by priori probability of the feature P(xk|Hj)=skj/sj. skj is the number of conflicting contexts having a specific value of sk within the class Hj class. sj is the sum of values of conflicting contexts belonging to Hj. Conflict History Manager calculates weights of conflicting contexts of users based on the weight table. The calculated results are updated in hash-table and a weight file for future search.
Conflict History Manager also provides priority of the conflicting context based on the weight table when Conflict Manager requests priority for a conflicting context. Conflict History Manager retrieves weights of the user, identified by ‘Who’ context of conflicting context, from the hash-table. Afterwards, it applies the weights to the conflicting context to Equation (2) to calculate posteriori probability. The Conflict History Manager calculates posteriori probability P(Xi|H1) when current user will continue using the service, and posteriori probability as P(Xi|H2) when other user will use it.
n P ( X i | H j ) = ∏ P ( xk | H j ) (2)
k =1
Finally, Conflict History Manager calculates priority of the conflicting context. Equation (3) shows the priority of conflicting context. In the equation, P(X|H1)P(H1) is the maximized probability of the current user to continue using the service. P(X|H2)P(H2) is the maximized probability of another user to use the service. Conflict History Manager delivers the difference of these two probabilities to Conflict Manager as a priority of the conflicting context.
Priority (Xi) = P(Xi |H1)P( H1)– P(Xi|H2)P( H2) (3)
Based on the two modules, Conflict History Manager adjusts the weight of conflicting context by using conflict history of users after conflicts are resolved. It also assigns a priority to conflicting contexts of users based on the weight table when conflicts arise
We have evaluated the effectiveness of the conflict resolution method based on the ubiHome test-bed. The proposed conflict resolution method chooses one among several users when multiple users attempt to access a registered service. In addition, it decides to start the service when priority of the service is higher than other services located within a service area. We also compared accuracy of the proposed method with fixed priority method in each service. Furthermore, we surveyed on how much of the family members conflict with each other in daily activities. Finally, we conducted a survey on the usefulness of the conflict resolution method to family members.
The proposed Context Manager was implemented with J2SDK 1.4TM so that it can be
applied to various applications. As shown in Figure 7, we tested Context Manager in
ubiHome, a smart home test-bed [
To set up the condition of each ubiService, we conducted a survey on service preferences of users about their home environment. The survey was conducted for the home appliances frequently used in living room. Seventy persons, (40 parents / 30 children), were asked the following questions.
Question 1: What kind of services or appliances do you use frequently in your home? Question 2: When do you usually use the services answered in the Question 1?
As a result, we found that parents usually spend their time watching television
around 9 P.M. Especially, they prefer to watch news to get social or weather
information through the television. However, children usually consume their time by
watching movie and listening to music. They also enjoy watching sitcom or comic
programs through television. Based on their preference and time, we assigned
conditional context of each user to each service in ubiHome. Furthermore, for the
experiment, the number of members in family was four: two parents and two children. This
is the average number of members in Korean family system [
In order to measure the accuracy of resolution method of the proposed Context Manager, we experimented on user conflict in two ways: a resolution method based on the Bayesian theory and a resolution methods having fixed priority. The proposed resolution method assigns priority to conflict contexts and then chooses one user having the highest priority when conflict occurs. On the other hand, resolution method having fixed priority chooses one user which belongs to the eldest user in the conflict situation. To test two methods, we employed television service that users use most in a Users Father Mother
Son Daughter
Users Father Mother
Son Daughter home environment. While using the television service, family members cause conflicts due to their preferences and its broadcasts. In our experiment, the television service selects a preferred broadcast channel of a user. It decided a specific channel of the user who has the highest priority according to each selection strategy when conflicts occurred. The service gathered feedback of users in pre-defined amount of time and judged the accuracy on the selection. The television service counts the number of "incorrectness" and "correctness" of the selection. Based on the selection result, we have built confusion matrix to know how well it works. First of all, we tested user conflict with fixed resolution method. We did the experiment from 18:00 to 24:00 in two weeks. Table 2 shows confusion matrix of conflict resolution method using fixed priority. As shown in the table 2, the resolution method provided the service to only a specific user because the conflict solution method selects one user according to the fixed priority of users when conflict occurred. Therefore, the higher priority users have, the more services the users have. In the case of father, the rate of correct selection reached to 100% since he has the highest priority among family member. However, the daughter hardly used the television service based on her context due to her lowest priority. Furthermore, the method cannot encompass the changes of preference or behaviors of users in their home environment. This shows how the resolution method is inappropriate to context-aware applications. On the other hand, resolution method, based on the Bayesian theory, reflected these changes. Table 3 shows the experimental results of the proposed conflict resolution method.
As shown in the table 3, the resolution method gave the television service to other users who have lower priority in the conflict resolution having fixed priority. This is because conflict resolution method assigned priorities to users based on their context. In addition, the accuracy of the resolution method was relatively higher than the fixed resolution method. The improvement of accuracy is due to the fact the resolution method reflected the changes of their preference and resolution policy. Therefore, conflict solution resolved conflicts caused by use of services among multiple users. In addition, we configured properties of ubiServices to deal with conflict among services. In the experiment, all the ubiServices were in the same area. Especially, television, movie and Internet services were operated on the same computer. Table 4 shows the properties given to each ubiService.
As shown in the table 4, each ubiService has its own set of required resources, such as sound, display and light, according to the resources it uses. Therefore, services which require the same resource cannot be executed simultaneously. Such service can start after stopping other services. For example, the television service uses sound, display and light resources and Internet service needs display resources. In this situation, those two services cannot be executed at the same time, because they share the display resource. Then, we monitored the services in ubiHome in order to observe resource conflicts among services. Table 5 shows the amount of service conflicts found during the observation.
In case of television service, most of the conflicts are related to Music service. The rest of the conflicts are associated with movie service. Movie service, which shares sound, light, and display resource, is related to all the services. In particular, conflicts with Movie service are mostly due to television service which is accessed by users frequently. Besides, Movie service also conflicts with electric light service since the services use light resource. Music service was related to television and movie service using sound and display resources. Finally, conflicts of the electric light service are caused by movie and television services which share light resource. Therefore, conflicts between these services depend on users and their pattern of using services in home environments.
Finally, we questioned 70 volunteers in ages from 10 to 60 who had experienced context-aware service supporting conflict resolution, in order to estimate the conflict in home environment. They were asked to answer the following questions. Question 1: Who is the most related to you when you are trying to use television service.
As shown in Table 6, the conflicts appeared high in the viewpoint of parents when they were using the service with their children. In the case of children, they showed high conflict when they spend their time on using the service with other brother or sisters. This result implies that conflicts are occurred because the preferences of each family member are different in using services in home environment. Moreover, each member feels a service conflict differently. This is because the persons who are together are different with each others, when they spent their time on using the services in the living room.
Furthermore, to evaluate the effectiveness of the proposed conflict resolution method, we asked them to answer following question.
Question 2: What do you think of context-aware services that choose a proper user when several members try to use them at the same time? 80 ) 70 (%60 ion50 t fca40 sa30 r se20 U10 0 10~19 20~29The age of Users 30~39 40~49
50~59
As shown in Figure 8, the respondent showed a satisfaction rate to correspond to average 62%. 10s and 40s of the users showed a high satisfaction rate on the survey. Especially, the teenagers showed relatively higher satisfaction then other ages. This is because they have a lot of curiosities with the services, and adhere to use the services. In case of 40s, they showed higher satisfaction rate on using the services too. This is because they want to use their service although there is more than one member. On the other hand, in case of 20s and 30s, lower satisfaction rate appeared. In the case of 30s, their families were comprised of only a few members of family. Most of 20s are live alone. Therefore, we found that satisfaction rate of usefulness of the service resolving conflicts are related to users and their environment.
In this paper, we proposed the Context Manager to resolve conflicts that arise when multiple users access various context-aware applications and when the applications are trying to share resources in ubiquitous computing environments. In order to resolve conflicts among users, the proposed Context Manager maintained the conflict history of users, calculated the weight of context with Bayes theory, and then selected one having the highest priority among users. In addition, Context Manager detected conflicts among services based on the resource properties of each service. These conflicts were resolved with the priority so that the services are exclusively executed. Through the experiment, we have shown the effectiveness of the proposed method. In our future works, however, we will employ additional services to deal with the conflicts. We will also observe user’s behaviors over longer periods. These remaining works will be done step by step in the near future.
The authors would like to thank Seiie Jang for his valuable input and useful discussion about conflicts in context-aware applications