Adaptive middleware of context aware application in smart homes

Adaptive middleware of context aware application in smart homes

• 1.
  Adaptive middleware forcontext-aware applications in smart-homes Markus C. Huebscher Julie A. McCann DSE Group, Department of Computing DSE Group, Department of Computing Imperial College London Imperial College London [email protected] [email protected] ABSTRACT being the Context Toolkit [3]. We extend the notion of middle- We propose an adaptive middleware design for context-aware ap- ware layer for context-aware applications, and design a middle- plications that abstracts the applications from the sensors that pro- ware that exhibits autonomic properties. In particular, we consider vide context. Further, we use application-specific utility functions situations where multiple sources may be available for the same to choose, given multiple alternatives for providing a specific con- type of context and introduce an adaptation engine that chooses text, one alternative at any time that provides the context for all one provider of context that is most appropriate among the cur- applications, whilst maximising the applications’ total “satisfac- rently available ones. In fact, we go one step further and assume tion” with the quality of context from the chosen provider. Our that context acquisition is a costly operation, such that given differ- middleware also implements autonomic properties, such as self- ent alternatives for acquiring one specific context, it is preferable configuration and resilience to failures, in the provision of context at any time to use only one alternative for all applications inter- information to context-aware applications. ested in that context1 . Our adaptive middleware uses utility func- tions to determine—given the Quality of Context (QoC) require- ments of applications and the QoC of alternative means of context Categories and Subject Descriptors acquisition—which alternative should be used at any time. The C.2.4 [Distributed Systems]: Distributed applications—evaluat- proposed solution can also be generalised to the case where more ing alternative service providers than one context provider can be used simultaneously among the applications and we need to choose for each application the best provider of context. General Terms One of our major goals in the design of our middleware has been Adaptive distributed service provision, context-awareness to provide adaptation with good performance, i.e. a change in con- text provision is detected quickly and adaptation occurs swiftly. This is particularly important in health-related applications that mon- 1. INTRODUCTION itor a person with health problems, as these usually require prompt Smart-home projects envision the home of the future as being responses to changes in the health condition of the person. filled with sensors that can determine various types of contexts of Section 2 explains the notion of context-awareness and describes its inhabitants—such as location and activity—while applications common metrics to specify the quality of context. Section 3 looks in the home use this information to provide context-sensitive ser- at the structure of our middleware, in particular context acquisition vices to the inhabitants and for context-aware home automation. from sensors and delivery to applications, while Section 4 describes For example, applications of smart-home technologies and context- the adaptation component of our middleware. Section 5 looks at awareness include supporting people with health problems, such as the issue of trust between components in the middleware. We then elderly living alone at home, or general lifestyle improvement, e.g. describe related work in Section 6 and conclude with Section 7. a smart fridge that monitors its contents and warns the user of prod- ucts that are expiring or finishing. 2. CONTEXT-AWARENESS Because any specific context can often be provided by a variety of different types of sensors and used by different applications, a Context-awareness is the ability of an application to adapt itself number of middleware projects have emerged in which the mid- to the context of its user(s). A user’s context can be defined broadly dleware layer provides context information to applications whilst as the circumstances or situations in which a computing task takes abstracting from the sensors and context logic that are used to ac- place [6]. One of the most common contexts is the location of quire and process that information, the most well-known project the user (or of objects of interest). In smart-homes, location can be obtained using a variety of different alternative sensor types, including ultrasonic badges, RFID-tags, video cameras and even pressure sensors in the floor [5]. The quality (which is quantita- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are tively application-specific) of the location information acquired by not made or distributed for profit or commercial advantage and that copies different sensors will however be different. For instance, ultrasonic bear this notice and the full citation on the first page. To copy otherwise, to 1 republish, to post on servers or to redistribute to lists, requires prior specific Whether this is true can certainly be debated and we agree that it permission and/or a fee. does not hold for all types of sensors. Wireless sensor network and 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing sensors that are battery-powered or share a low-bandwidth commu- Toronto, Canada nication channel, however, are examples where sensor data acqui- Copyright 2004 ACM 1-58113-951-9 ...$5.00. sition does come at a cost.
• 2.
  Application PDA, Health monitoring Home gateway Wall screen component to hospital devices allow. These data are passed up one level in the framework level to the context providers. Context provision Context providers (CPs) are components (software or hardware) Context Context adaptation Service 1 Service 2 that aggregate and interpret the sensor data to produce some higher- level context, e.g. location, identity, type of activity, health condi- Context provision Context Context Context Context tion of a person. As illustrated in the figure, more than one CP (aggregation may access the same group of sensors. Similarly, it is possible Provider Provider Provider Provider & interpretation for one CP to use sensor data from a group of sensors, as data re- of raw sensor data) dundancy often improves the total reliability of the derived con- Sensors Sensors1 Sensors2 Sensors3 Sensors4 text. This is rather more general than the typical approach in the Context Toolkit, where one sensor typically maps exactly to one Figure 1: Layers of context provision in our middleware context widget, and separate components called aggregators and interpreters collect and differentiate the sensor data. However, as an example, we could imagine the Context Toolkit being used to badges can determine location with a precision of up to 3 cm, while implement the context provision layer of the middleware. In any RF lateration is limited to 1–3 m. Thus, we can define properties case, we image CPs to be often divided into sub-components with which we call Quality of Context (QoC) attributes that characterise reusable capabilities. the quality of the context data received. QoC is, as we will see in Moving up one level, we have context services (CSs). These con- Section 4.3, essential to our middleware in choosing the best al- nect below to different context providers that provide the same type ternative among the available ones for delivering a specific type of of context, e.g. location, but implemented using different underly- context. ing sensors, and above connect to the applications. They allow an 2.1 Quality of Context application to use a type of context whilst abstracting from the ac- While different types of contexts will have QoC attributes spe- tual instance of a context provider. An application can poll for con- cific to them, there are certain attributes which will be common to text information or subscribe for notification when a certain condi- most contexts. Based on [2], we identify the following common tion on the context information or QoC values is met, e.g. when the attributes: temperature exceeds 26◦ C or when Alice enters the kitchen. Certain CPs and applications may use context information from a Precision measures how accurately the context information de- CS to provide higher-level context. For instance, a CS may provide scribes reality, e.g. location precision. location in the form of 2D or 3D coordinates in the home. A CP may then use this information to determine the room in the home Probability of correctness measures the probability that a piece this location maps to. Again, this higher-level context would be of context information is correct. For instance, determin- delivered through a context service2 . ing the current posture of a person (sitting, standing, lying CSs execute adaptation in the system. This means switching on the floor in distress) using a video camera has a different between available CPs, e.g. when the QoC of the currently used probability of correctness than using pressure sensors in the provider deteriorates excessively or the QoC of an unused but avail- furniture. able provider improves greatly (self-optimising). It also handles Resolution denotes the granularity of information. This can for automatic failure recovery (self-healing) when the currently used example mean spacial coverage. For instance, in a kitchen provider is unable to deliver context, e.g. because of excessive sen- there can be hot-spots with high temperature (oven, cooker, sor failure, and automatic upgrade to newly installed sensors and toaster) which may not be picked up by temperature sensors context providers (self-configuring). Thus, our framework imple- in the room if spacial coverage is low. ments adaptation through the basic use of a proxy abstraction layer. In the next section, we describe how this adaptation process is Up-to-dateness specifies the age of context information. Also of decided and executed. interest is how likely the measurement is still accurately de- scribing the present. 4. ADAPTATION ENGINE Refresh rate is related to up-to-dateness, and describes how often We start by describing service discovery in our middleware in it is possible or desired to receive a new measurement. Section 4.1. While service discovery is necessary in any service- oriented distributed environment, we tailor the service discovery QoC differs from QoS, because context information has quality protocol (SDP) to provide efficient monitoring of CPs for the pur- metrics even when it is not provided as a service to any clients. In pose of adaptation. This includes rapidly discovering failure of CPs our middleware, context providers need to specify QoC attributes and updating the QoC of each CP. Section 4.2 mentions how adap- for the context information they deliver. These attributes may vary tation is triggered, while Sections 4.3 to 4.5 explain how the adap- over time and therefore must be updated regularly. tation engine determines the new CP to switch to. 3. STRUCTURE OF OUR MIDDLEWARE 4.1 Service discovery Figure 1 shows the layers in context provision in our middle- To allow context services to find relevant context providers, a ware (the adaptation part is not shown and is introduced only in directory service (DS) is used. When CPs enter the network, they Section 4). advertise their presence to the DS, supplying it with descriptive at- At the bottom are sensors that deliver raw sensor data. These tributes for the service they provide, i.e. the context type and QoC could be wireless sensor networks, ultrasonic badges for location, 2 Also in object oriented programming it is not unusual to always RFID tags for identification, video cameras for tracking, or others. abstract an implementation through an interface, even when it is These produce raw sensor data, often preprocessed for saving com- unlikely that there will be more than one implementation of the munication cost as much as the (often power-constrained) sensor interface.
• 3.
  attributes. Then, aCP must regularly send a heartbeat to the DS, a short message that implicitly tells the DS that this CP is still alive and informs it of updated values for those QoC attributes that Auto update (self-configuring) change over time. Thus, through the heartbeat, the DS is able to Application Application monitor the QoC of CPs and quickly detect CP failure, provided that the negotiated maximum time interval between heartbeats is kept short. We believe that this scales reasonable well within a Context 3. switch smart-home if the heartbeat is limited to a simple message that can Service Adaptation Engine be processed quickly3 . In comparison, Jini4 has a recommended 2. generate event minimum leasing time of 120 seconds, and UPnP5 a minimum rec- 4. ommended advertisement time of 30 minutes. These times would Context New 1. advertise be inadequate for reacting and adapting promptly to failures. Provider Context Directory Service The DS also takes care of initialising the CSs. When the first Provider CP for a particular context type advertises itself to the DS, a corre- CP CS currently used CP sponding CS is created. Conversely, when no more CPs are listed CP CS unused but available CP Sensors Sensors in the DS for a particular context, the CS terminates (possibly af- (a) Self-configuring ter notifying interested applications that this context is no longer available). Failure recovery (self-healing) 4.2 Triggering adaptation Application Application As we already mentioned earlier, the context services execute adaptation by switching between different context providers. How- Context 3. switch Adaptation Engine ever, they do not decide adaptation, i.e. when to switch and which Service CP to switch to. Instead, adaptation is decided externally by an 2. generate event 4. event-triggered adaptation engine (see Figure 2). The DS moni- failure tors the status of CPs and can fire events to the adaptation engine. Context Context 1. no heartbeat Events that are of interest for adaptation purposes include notifica- Provider Provider Directory Service tion of CP failure, that a new CP has appeared, or of changes to QoC in available CPs, in particular degradation of provider in use or improvement of unused but available provider. Given the event, Sensors Sensors the adaptation engine decides whether an adaptation should occur (b) Self-healing based on the current QoC of the available alternatives and, in the affirmative case, which CP the CS should switch to. Figure 2 shows Adapting to QoC change (self-optimising) some adaptation scenarios. We envisage the DS and the adaptation engine to share a database (or tuplespace) in which QoC values are Application Application stored by the DS and accessed for adaptation by the adaptation en- gine. The database can also be used to create a history of QoC and Context 3. switch delivered context information. How the adaptation engine chooses Adaptation Engine Service the new CP to switch to is described in the next section. 2. generate event 4. 4.3 Choosing the best CP Context Context When an application is interested in acquiring context informa- Provider Provider 1. heartbeat Directory Service tion from our middleware, it looks up in the DS the location in the with QoC network of the context service (CS) for the context type of inter- degradation est. Then, it contacts the CS and informs it of the QoC it wishes to Sensors Sensors receive. This information is then relayed to the adaptation engine. When it is then time for an adaptation, the adaptation engine uses Application Application the applications’ wishes to determine which CP is currently the best choice, i.e. which maximises the applications’ “satisfaction” with 3. switch Context the delivered context information. Service Adaptation Engine It seems most convenient and flexible to define an application’s 2. generate event satisfaction for a particular CP as a utility function that maps the 4. CP’s QoC attributes to a value that quantifies the application’s sat- isfaction (where values ≥ 0 mean the application is satisfied with Context Context Provider Provider 1. heartbeat Directory Service this CP and values < 0 mean the application is not satisfied, e.g. with QoC the service the application provides to the user suffers from the bad improvement 3 Sensors Sensors In a deployment environment larger than a home, the centralised nature of the DS can certainly become a problem. Federating the (c) Self-optimising DS, similarly to Jini, could solve this problem. 4 Sun Microsystems’ service discovery protocol built on Java. Figure 2: Adaptation scenarios. URL: http://wwws.sun.com/software/jini/ 5 Universal Plug and Play, a service discovery protocol based on web services. URL: http://www.upnp.org
• 4.
  QoC of thisCP). An application can deliver its utility to the CS The utility functions mentioned above are already predefined in in the form of a function written, for instance, in a functional pro- the middleware, so that an application on a resource-constrained gramming language such as Haskell, ML or Lisp. device (e.g. a PDA or a mobile phone) need only select a prede- Given each application’s idea of CP utility, the adaptation engine fined function and pass the appropriate input parameters instead of can them apply each application’s utility function to each CP and sending an entire utility function to define its QoC wishes. for every CP sum the applications’ satisfaction value, thus obtain- One issue remaining is how to choose the scaling factor. In prin- ing for each CP the total perceived satisfaction. ciple, we could determine the scaling factor by choosing a sensible The utility function could, for example, use linear distance (1- scaling factor for each QoC attribute, based on an interval of likely norm), Euclidean distance (2-norm), or return the maximum dis- values. However, this is tedious and subjective. We believe that a tance (max-norm) between a CP’s provided QoC and an applica- better way is to use a special case of the Mahalanobis distance6 , tion’s QoC expectation. However, as we are combining numeri- where we measure for every QoC attribute the standard deviation cal distance values of different properties, e.g. location precision in over all available values from CPs, and then express application metres with refresh rate in Hz, we need to define a standard scale distances, i.e. c − a, as multiples of the standard deviation for that for all dimensions. The simplest way to do this is to introduce a attribute. In other words, given the standard deviation vector σ, scaling factor for each QoC attribute. That is, if a particular con- where σi is the standard deviation of the i-th QoC attribute over all text type has n QoC attributes and let the application’s wishes for CPs, the scaling factor becomes s = 1/σ. This distance has the ad- this context be a = (a1 , . . . , an ) (where we use ai = to indicate vantage of being independent of the scale used in the dimensions, an application’s indifference to the i-th QoC attribute), a CP’s QoC i.e. using centimetres instead of metres to measure precision will c = (c1 , . . . , cn ) (where we use ci = to indicate a CP’s inability not affect the numerical value of the distance. However, the range to provide a quantitative value for the i-th QoC attribute) and the of values of the available CPs will affect the scaling factor of each scaling factors for the QoC attributes s = (s1 , . . . , sn ), then we QoC attribute. have: Simple utility functions could set independent thresholds on a Using d = (c − a) · s certain number of QoC attributes, e.g. a certain amount of preci- sion with a certain refresh rate is desired. However, more complex |d| = |d1 | + |d2 | + . . . + |dn | (1-norm) utility functions could use dependence between QoC attributes. For instance, for location, an application may be interested in a certain d 2 = |d1 |2 + |d2 |2 + . . . + |dn |2 (2-norm) amount of precision. However, if refresh rate is good, then lower precision is also acceptable. This can be modelled as a decision tree, which will be useful in the next section7 . Also, applications d ∞ = max{|d1 |, |d2 |, . . . , |dn |} (max-norm) can send updated utility functions at run-time, e.g. in response to where ci − ai = 0 for ai = context change or user input. and ci − ai = o(ai ) for ci = . o(.) determines an application’s satisfaction (or dissatisfaction) when 4.4 Application weights and the role of au- the CP is unable to provide an estimate of a QoC attribute, given thentication the value wished for by the application. Given each application’s “perception” of the quality of the avail- Actually, the various norms won’t usually be applied directly as able CPs, it makes sense to introduce application priorities, such described above, but one also considers the sign (satisfaction (+) that an application’s satisfaction will be weighed more heavily than vs. dissatisfaction (-)) of each dimension and also of the final dis- others. For instance, when delivering location information in the tance. For instance, it may only makes sense to add positive terms smart home of an individual suffering from a heart condition, a in the distance if there are no negative ones, i.e. extra quality in one health-monitoring application’s satisfaction should weigh more than dimension does not counteract the lack of quality in another dimen- that of a light control system. To prevent all applications from se- sion. In general, this definition implies that an application prefers lecting a high priority, the priority levels should be assigned by the it when it gets better QoC than it asked for, i.e. ci − ai > 0 po- middleware. One way to do this is for applications to authenti- tentially contributes to an application’s satisfaction. For instance, cate themselves to the middleware to prove that they belong to a an application that finds objects for a forgetful user will work bet- particular priority class (with predefined weight). This approach ter as precision of location information improves. However, there seems reasonable, since we want to anyway protect the user’s con- are cases where an application does not need and cannot use better text information, which can represent very sensitive data about a QoC than it asked for, e.g. location precision in the case of a light person’s private life, from unrestricted access by malicious appli- control system that turns on and off lights when an individuals enter cations, and therefore application authentication is a necessary as- and leave rooms. In that case, di should be redefined as pect of the middleware for access control to context information8 . (ci − ai ) · si if ci − ai < 0 di = ∀ i = 1, . . . , n 6 The standard Mahalanobis distance (also known as statisti- 0 otherwise cal distance) between two vectors x and y is dM (x, y) = In other words, an application is satisfied (i.e. di = 0) when the (x − y)t S −1 (x − y), where S −1 is the inverse of the covari- i-th QoC attribute is at least as good as it wishes it to be and the ance matrix (the variance, i.e. the squared standard deviation, of distance of this attribute can only affect the total distance when the variables is on the diagonal of the matrix). Compared to our there is dissatisfaction (i.e. di < 0). special case, the use of the covariance matrix means that it also Furthermore, up to now we have assumed that each QoC attribute takes into account the correlation between variables. 7 is equally important. Since this is not generally the case, e.g. pre- In a functional programming language, it can be implemented us- ing boolean guards. cision may be more important than refresh rate, applications may 8 set weights w = (w1 , . . . , wn ) to the n QoC attributes. Thus, we Actually, protecting sensitive data also requires encryption in ad- dition to authentication. The same infrastructure, e.g. PKI, used for perform d ← d · w before computing the final p-norm distance (or authentication could also be used to establish symmetric keys for any form of distance). encryption, if necessary.
• 5.
  In fact, policiescould determine the type of information that appli- function to compute the satisfaction value and could therefore just cations with different access rights have access to. Further, QoC as well pass its utility function to the middleware in the first place, attributes could be used to control the quality of data received, e.g. without requiring the middleware to learn it. applications with lower access rights might only receive location information every hour. 5. THE PROBLEM OF TRUST An issue we wish to address next is that of trust. Up to now, 4.5 Learning an application’s satisfaction we have assumed that all components external to the middleware When deciding the best CP based on applications’ QoC wishes “play along”. In particular, the context providers provide accurate and satisfaction of the available CPs, we would also like to consider and reliable QoC values for the context information they deliver the case where the application is unable or unwilling to provide a and expeditiously send heartbeats with updates when these val- utility function to the middleware describing its notion of CP sat- ues are outdated. Moreover, correct and fast adaptation relies on isfaction. In this case, the middleware learns to predict whether an this assumption. However, we believe we must also investigate the application will be satisfied with a particular CP. case where this assumption is violated. For example, wireless sen- Learning usually involves some form of feedback from the en- sor nodes of a particular manufacturer may advertise lower QoC tity whose behaviour we wish to understand and predict. In our than they’re actually capable of, so that the middleware will not case, an application that does not provide its utility must however switch to them often as a source of raw sensor data for context in- be able to tell the middleware whether a CP satisfies its “wishes9 ”. formation, thereby prolonging the battery lifetime of these sensor With this feedback, the middleware can build a decision tree that nodes, which may give them an unfair advantage compared to a classifies CPs into satisfying and unsatisfying CPs. We believe that competitor’s sensor nodes (perhaps installed in the same middle- decision trees are sufficient to model effectively applications’ QoC ware). Moreover, a non-malicious video camera’s trustworthiness wishes and have the advantage of being simple to create, i.e. they may depend on the amount of ambient light. That is, the CP may can be created without much overhead. For instance, applications not be advertising wrong QoC attributes on purpose, it may simply that set independent thresholds on the QoC attributes can be eas- be unable to estimate accurate QoC attributes because of current ily modelled (with a tree that has one node at every depth), but environmental conditions. This makes the problem all the more also applications that set conditional thresholds between attributes. important. Because the QoC attributes are not discrete, but continuous, the To counter this problem, we introduce a special QoC attribute: decision-tree learning algorithm must find split points, i.e. thresh- trustworthiness (already introduced by Buchholz et al. in [2], on olds, for branching the tree on numerical attributes. Various ap- which we based our QoC attributes in Section 2.1). It determines proaches have been suggested to accurately and efficiently solve how likely it is that the information provided is correct. This is this problem [4]. similar to probability of correctness, however while probability of Thus, in the event of an adaptation, the middleware uses deci- correctness is provided by the CP, trustworthiness is provided by sion trees to predict acceptance of the various CPs for applications an entity external to the CP. By introducing this property, we can that did not provide utility function and thus to choose the new CP select a CP based also on its trustworthiness. Notice that it is up to to switch to. After the adaptation, the middleware can ask the ap- the applications to choose how much trustworthiness affects their plication whether its prediction was correct. The reason for not utility function, i.e. how much risk they are willing to take in the asking the application in the first place instead of relying on error- hopes of receiving good QoC. prone prediction is a matter of performance: we want adaptation The problem that now arises is how we determine the value of to occur rapidly, and therefore delays caused by communication trustworthiness. When we allow more than one CP to be in use at with remote entities on the network become unacceptable, delays any time, the CS can analyse the context information from multiple that can become very high for portable devices on low-bandwidth sources to determine the most likely correct value and reduce the wireless links, e.g. Bluetooth. Also, if we assume that the applica- trustworthiness of CPs that deviates too much from the QoC they tions use a utility model similar to a decision tree, the middleware advertise (as far as this is possible). But, in the special case where can learn to predict accurately an application’s acceptance of CPs only one CP is used at any time, this is not possible. In this case, fairly quickly. In particular, if we can assume that of all the avail- it is up to the applications to affect a CP’s trustworthiness. This able QoC attributes describing the context information, the appli- can be done through complaints and praises. If an application re- cation is likely to only use a subset of them in its decision, then ceiving information from a CP can determine that the information using a relevance-based decision-tree learning (RBDTL) algorithm is incorrect and deviates from the advertised utility, it sends a com- enables faster accurate predictions with fewer examples10 [8]: it plaint to the CS indicating the received and expected values. The first identifies a minimal set of relevant attributes and then passes CS can then forward the complaint to the adaptation engine to ad- this set to the decision tree algorithm for learning. just this CP’s trustworthiness. Of course, the application needs to It would seem that an extension to this could be to allow the know the current CP’s utility to be able to tell whether a complaint middleware to learn the the application’s utility function altogether, is necessary, or whether the current CP has bad QoC and advertises i.e. the numerical value of satisfaction for a particular CP. However, this correctly. This utility can be piggybacked by the CS on context this typically requires more complex feedback, because now the delivery when necessary. application must return for a given CP its numerical satisfaction, in The application could use explicit user feedback to determine order to train the middleware’s learning model. If the application the correct context, or implicit user reaction to context-sensitive can do this, however, it seems likely that it will have some utility application adaptation. For example, if a PDA adapts its display 9 to show a remote control for the TV because it received informa- We prefer the word “wish” to requirement because we believe that the application must be able (or at least try) to cope with context tion that the user is located on the sofa in front of the TV, but the information that has lower quality than its specified requirements. refrigerator senses that it is being opened by the user and notifies 10 RBDTL biases towards a minimal number of attributes to cor- interested parties (including the PDA), and furthermore the user rectly predict the training data. When all available attributes are manually switches the PDA to display an inventory of the contents relevant to the decision, RBDTL shows no advantage. of the refrigerator, we can safely say that the location information
• 6.
  was inaccurate andthat because of that, the PDA made an incorrect plementation of the application, and therefore cannot be statically context-based adaptation. assumed in advance, as with network delivery properties, but must The example shows that, while trustworthiness can be inferred be either provided by the application or learned through applica- to some degree externally to the CP, it is by no means easy to im- tion feedback. An interesting design aspect in their middleware is plement and can require the cooperation of multiple applications how they engineer their utility function to prevent state-flapping, (when the refrigerator senses that it is being opened, this informa- i.e. the situation where the network QoS state is near a utility func- tion contributes to validate a location CP’s delivered information, tion’s threshold, causing the middleware to continuously flap be- even if the refrigerator itself is not interested in the user’s location), tween two adaptation states. and if possible also other CPs of the same context type for cross- validation. This however introduces another trust problem: can we 7. CONCLUSIONS trust the applications’ and the other CPs’ feedback? Our goal was to introduce notions of autonomic computing in a We are currently trying to solve this problem using Bayesian middleware for context-aware applications. While there has been parameter learning, where we feed application complaints/praises much research on autonomic computing, it has not been specifi- into a beta distribution to evaluate probabilistically a CP’s trustwor- cally applied to middleware for context-aware applications. Yet, thiness. Details must be omitted for lack of space. particularly in a smart-home environment, self-management of the system is important because we cannot assume that there will be a 6. RELATED WORK technical administrator present round the clock to solve problems Our work was inspired by the Context Toolkit [3]. The Con- that may arise and fine-tune the system. text Toolkit is a framework aimed at facilitating the development In our proposed solution we have assumed that CPs are able to and deployment of context-aware applications. It abstracts context estimate their QoC (or at least most of them). It remains to be seen services, e.g. a location service, from the sensors that acquire the in practice how well this assumption holds. necessary data to deliver the service. Thus, in a different deploy- Although our middleware was designed in the context of smart- ment environment, the provider of a context type can be exchanged home application scenarios and context-awareness, it can be gener- with another provider that may use a fundamentally different type alised to the case where there are multiple service providers for the of sensors, yet the application does not need to be modified to ac- same service, e.g. printing services, and based on the applications’ cess this different source of the same context. However, there is wishes we choose the optimal service provider for each applica- no mechanism that allows context services to adapt and react to tion, e.g. nearest printer, best-quality printer. Then, if the currently failure or degradation of the underlying sensor infrastructure, e.g. used service (e.g. a printer) should fail (e.g. paper jam, no toner) by switching to an alternative means of acquiring the same type of the middleware can automatically switch to the best available alter- context. In fact, the situation where multiple means of acquiring native. In general, we believe utility functions to be better suited the same context may be dynamically present in the system is not to adaptive service provision than query-based service discovery, considered. We started with this assumption and then addressed the as they rank all available alternatives by their utility and allow the issues of self-management and adaptation. middleware to autonomously determine the best alternative on cur- There have also been other middleware approaches to context- rent service failure. awareness middleware. For instance, [7] describes an infrastruc- ture that provides context-awareness support to applications. It uses 8. REFERENCES first order logic predicates to model contexts and allows deduction of higher-level contexts using rule-based approaches. Effectively, [1] S. N. Bhatti and G. Knight. Enabling QoS adaptation the application can delegate context-awareness to the infrastruc- decisions for Internet applications. Computer Networks, ture, which takes care of obtaining the context, evaluating the rules 31(7):669–692, 1999. (provided by the application) and calling the actions. In contrast, [2] T. Buchholz, A. K¨ pper, and M. Schiffers. Quality of context: u in our solution applications delegate to the middleware the choice What it is and why we need it. In Proceedings of the of most appropriate context provider. Workshop of the HP OpenView University Association 2003 As to adaptation in middleware, Bhatti and Knight [1] have pro- (HPOVUA 2003), Geneva, 2003. posed a QoS middleware for multimedia distribution in the Internet [3] A. K. Dey and G. D. Abowd. A conceptual framework and a that also uses a utility function for determining the best alternative toolkit for supporting the rapid prototyping of context-aware for delivering the media to the application, for instance choosing applications. Human-Computer Interaction, 16:97–166, 2001. the most appropriate codec for audio delivery considering the cur- [4] E. Frank and I. H. Witten. Selecting multiway splits in rent properties of the network, i.e. bandwidth and latency. How- decision trees. ever, the adaptation context of their middleware is quite different. [5] J. Hightower and G. Borriello. Location systems for QoS middleware typically address the issue of adapting the deliv- ubiquitous computing. Computer, IEEE, 34(8):57–66, Aug. ery of data across the network in response to changes in network 2001. properties. In our case, we are choosing the source of the data [6] S. Meyer and A. Rakotonirainy. A survey of research on given various alternatives with varying quality (where quality is context-aware homes. In Proceedings of the Australasian quantitatively an application-specific concept). Furthermore, our information security workshop conference on ACSW frontiers alternatives are not fixed, but are dynamically determined by the 2003, pages 159–168. Australian Computer Society, Inc., currently available context providers in the network and their (pos- 2003. sibly dynamic) QoC attributes. This requires a service discovery [7] A. Ranganathan and R. H. Campbell. An infrastructure for protocol that reacts quickly to changes in the providers, so that the context-awareness based on first order logic. Personal adaptation engine has an accurate view of the providers. More- Ubiquitous Comput., 7(6):353–364, 2003. over, while Bhatti and Knight describe a fixed utility function for [8] S. Russel and P. Norvig. Artificial Intelligence: A Modern deciding adaptation, we use application-specific utility functions, Approach. Prentice Hall, 2nd edition, 2003. as an application’s QoC wishes are specific to the purpose and im-