[IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Context as a service - Requirements, design and middleware support

Download [IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Context as a service - Requirements, design and middleware support

Post on 14-Apr-2017

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>Context as a Service - Requirements, Design and Middleware Support</p><p>Michael Wagner, Roland Reichle, Kurt GeihsDistributed Systems Group</p><p>University of KasselKassel, Germany</p><p>{wagner, reichle, geihs}@vs.uni-kassel.de</p><p>AbstractContext-aware self-adaptive applications monitorand exploit knowledge about external operating conditions andadapt to changes in the execution context. Modern smart-phones are equipped with several sensors, like GPS sensoror accelerometer. Additionally, context reasoners and externalcontext providers exist. Thus, it is possible that several contextproviders offer information of the same type (e.g. location)but differ in quality levels (e.g. accuracy), representations (e.g.position represented in coordinates and as an address) andcost (e.g. battery consumption) for providing the information.In this paper, we provide a comprehensive approach and anaccording middleware architecture to support the selection andactivation of dynamically appearing context providers accord-ing to specific context requests. Local context providers areactivated dynamically on demand in order to save resources.Furthermore we provide support to overcome heterogeneousrepresentations of dynamically discovered context informationand their metadata.</p><p>Keywords-Context-aware services; Ubiquitous computing;Adaptive systems</p><p>I. INTRODUCTION</p><p>Context awareness has attracted a lot of attention in recentyears, especially in the realms of mobile and ubiquitouscomputing. Context-aware applications are capable of mon-itoring and exploiting knowledge about external operatingconditions. Typically, such systems are also self-adaptive inthe sense that they can dynamically adapt as a response tochanges in the execution context. Context management inubiquitous computing environments must reflect the specificcharacteristics of these environments, e.g. distribution, mo-bility, resource-constrained devices, dynamic discovery ofcontext sources, and heterogeneity of context information.Modern mobile devices are equipped with several internal</p><p>sensors, like sensors for GPS-based location, device acceler-ation, and device orientation. Additionally, external contextsources and context reasoners may be available as part ofthe ubiquitous computing environment. Hence, it may be thecase that several context sources offer the same informationtype. For example, a modern smart phone can retrievethe location via a GPS sensor or can use a WLAN-basedlocalization. Additionally, an external location service canbe provided in a building. In order to ease the developmentof context-aware self-adaptive applications,that utilize thefull potential of such environments, the developer should</p><p>be able to transparently access context information withoutbothering with the underlying context accessing techniquesand the distribution aspects.Context sources can differ in their quality levels (e.g.</p><p>accuracy) and representations (e.g. position represented incoordinates and as an address) of the offered information,and costs (e.g. battery consumption) for providing the infor-mation. Therefore a resource-aware middleware for context-aware self-adaptive applications has to provide support forselecting and activating one of the available context services.(On a mobile device unused context providers should bedeactivated in order to save resources.) Thereby the mid-dleware has to trade the provided quality of context andrequired costs of the context service off against the qualityof context requested by the context consumer.Even if the concept of abstracting the context provisioning</p><p>process through components or services is well known,e.g. the Context Toolkit [1] already introduced this in theyear 2000, our concept goes one step further towards theseamless and dynamic integration of independently devel-oped context services. Existing approaches have neglectedimportant aspects like heterogeneous representation also ofcontext metadata, dynamic selection and (de-)activation ofcontext services, even if these aspects have an importantimpact on the general approach. Especially with respect tothe abstraction levels and the associated selection strategies,there are big differences in the related work. The ContextToolkit, for example, provides support for the abstrac-tion of context providers but leaves the selection to theapplication developer. In contrast, the Nexus project [2]fuses all available context information into one consistentworld model and thus does not need a selection process.However, this implies that context providers have to runall the time and that Nexus does not explicitly deactivatecontext providers that are currently not required in orderto save resources. In this paper we present a middleware-based solution providing comprehensive context manage-ment support according to the SOA principles [3] such asloose coupling, abstraction, reusability and discoverability ofcontext sources. This enables developers to abstract contextsensors, context reasoners and external context providersas context services. Thereby our approach stands out, asit supports the exchange and selection of heterogeneously</p><p>8th IEEE International Workshop on Middleware and System Support for Pervasive Computing</p><p>978-1-61284-937-9/11/$26.00 2011 IEEE 220</p></li><li><p>represented context information in an ubiquitous computingenvironment.The remainder of this paper is structured as follows: in</p><p>section II the general objectives and requirements of thiswork are discussed, afterwards our solution approach isintroduced in section III, and an appropriate architecture forthe middleware is presented in section IV. Section V givesan overview about the related work. Section VI providesconclusive remarks.</p><p>II. PROBLEM STATEMENT</p><p>The general objective of this work is a comprehensiveapproach for exchanging and selecting heterogeneously rep-resented context information in an ubiquitous computingenvironment. Therefore, context sensors, reasoners and ex-ternal context providers are abstracted as context services.These can be dynamically selected, bound and activatedbased on the requirements of a context consumer. Offers andrequests are matched taking Quality of Context (QoC)[4],Cost of Context (CoC)[5], and the required transformationsbetween representations of context information and metadatainto account. An additional research goal is the transparentintegration of inter-representation transformations for het-erogeneous context data and meta-data.The results of the Mobile Users in Ubiquitous Computing</p><p>Environments (MUSIC) project [6] serve as a starting pointfor our work. MUSIC offers a solution for the developmentof self-adaptive context-aware applications in ubiquitous en-vironments and explores an advanced kind of compositionaladaptation by considering dynamically discovered servicesas possible replacements for application components. Fur-thermore the platform offers extensible support for access-ing context data. Therefore context access is encapsulatedinto so-called context plug-ins which can be transparentlyaccessed by context consumers using a new context querylanguage. The MUSIC context management system has leftopen several research questions that lead to the work planfor our contribution:</p><p> Activation and deactivation of local context services:Mobile devices are limited in their computing capabil-ities and resources. Thus, software on a mobile deviceshould work as energy saving as possible. Especiallysensors are known as very resource consuming. There-fore, local context providers should be activated anddeactivated on demand.</p><p> Dynamic selection of context services based on QoCand CoC: Context services in mobile and ubiquitouscomputing scenarios can appear and disappear. Thus, itis possible that several context services exist providingthe same type of information. However, they can differin quality levels, cost for providing the information,and in representations of quality levels, cost and contextinformation. Therefore, a mechanism is required for se-lecting one of the available context services and thereby</p><p>taking into account provided and required quality ofcontext, required cost of context and the consumerspreferences regarding cost. Additionally, the middle-ware must handle heterogeneously represented contextinformation and metadata during the selection, andthe challenge of activation and deactivation of contextservices. Dynamic (de-) activation impacts the accuracyof the QoC data for the selection. For instance, theprovided QoC of a selected provider can be muchworse after the activation than its previous QoC andalso worse than the current QoC of other providers.This would result in a deactivation and a new run ofthe selection algorithm. Therefore appropriate selectionstrategies are needed that avoid the selection of theseservices.</p><p>In addition to these two main research goals we have toconsider the following research issues:</p><p> Semantic discovery and integration of independentlydeveloped context services and consumers: In anubiquitous environment it is impossible to know alldevices and services at design-time. Therefore, run-timemechanisms are required to discover context servicesand consumers, reason about and perform the mediationtasks that are needed to bridge the heterogeneity issuesarising from the independent development of contextservices.</p><p> Loose coupling of context providers and consumers:The principle of loose coupling is adopted from theSOA principles. It promotes the independent designand evolution of a context services logic and imple-mentation. Furthermore it allows to switch dynamicallybetween different context services as these are not hard-wired in the source code.</p><p> Exchange and interpretation of heterogeneously rep-resented context information: Independent develop-ment of context providers and consumers implies thateach development team utilizes the most suitable plat-form and technology for its task, but also it names andrepresents the data and metadata according to its needs.Even if platform-independent data exchange formatslike XML are used, this results in naming conflicts andin heterogeneous representations of the data and themetadata to be exchanged. For example, the locationof the user in an ubiquitous computing environmentmay be given in GPS Coordinates or as Room Numberof a Building. Additionally, the accuracy of the locationmay be specified as radius around that position inmeter or as value ranges for the GPS coordinates. Acommon vocabulary has to be defined that allows tosemantically interpret the meaning and representationof the data and metadata. This is a prerequisite forreasoning about the needed mediation tasks to achieveinteroperability. In particular, this also comprises the</p><p>221</p></li><li><p>conversion between different data representations, asfor example the conversion of GPS Coordinates to astreet address.</p><p> Expressing context offers and needs: In order toestablish communication links between context con-sumers and providers in a dynamic fashion, contextoffers and needs have to be expressed based on acommon vocabulary. Language support is required toallow elaborate specification of context needs, to filterout inappropriate context offers and to establish onlycommunication links that provide the information ac-tually needed.</p><p> Minimizing resource consumption of used contextservices: Several context consumers may request thesame type of context information with slightly differentrequirements. In order to minimize the resource con-sumption, appropriate support has to be provided toselect and activate context services by merging contextrequests.</p><p>III. SOLUTION APPROACH</p><p>Context Service 0..*Context Consumer 0..*</p><p>Discovery and Matching</p><p>Reasoner 0..*</p><p>ContextRequests C</p><p>ontextoffers</p><p>Selection</p><p>Binding</p><p>Selection Result</p><p>Converted Data</p><p>Matching Results</p><p>Context model and ontology</p><p>Selectionfunction</p><p>Inter RepresentationOperation</p><p>Data</p><p>Data</p><p>Figure 1. Overview of the Solution Approach.</p><p>Figure 1 provides an overview of our proposed approach.The baseline is a context model and ontology, specified inOWL, which define the semantic concepts of Entity types,Scopes and Representations. An entity is a physical orlogical entity of the world that is described by the contextinformation, e.g. a PDA or a person. The scope refers to thetype of the provided information, e.g. the location. Meta-dataare also considered as scopes. Representation describes howthe context information is internally structured. The contextontology is used to provide a common vocabulary to bridgesemantic differences by defining the semantic concepts forentity (types), scopes and representations. Furthermore theontology captures the relationships between the definedconcepts. The internal structuring of context informationand metadata is defined as representations in the ontology.By providing Inter-Representation-Operations (IROs) [7],we allow the conversion between different representations.But in difference to [7], our work goes further due to a</p><p>more elaborate support for the transformation of metadatarepresentation. With the help of these concepts a commonvocabulary is established that allows to interpret the meaningand representation of the exchanged data.As highlighted in the previous section, several context</p><p>services and consumers can exist in parallel. The requiredand offered context information is specified on the commonvocabulary defined by the ontology using our new ContextOffering and Query Language (COQL). The COQL providessupport for complex filters and conditions in order to pre-cisely define context offers and request. The correspondingsemantic definitions serve as input for the Discovery andMatching step. Matching of context offers and request in-cludes the reasoning on potentially required mediation tasksin form of IROs to overcome mismatches in the providedand required representations of the context information aswell as in the corresponding context meta data. Here it hasto be highlighted that the mediation reasoning can end withthe result that not only a single IRO is necessary but rather acomplete chain of IROs. This is especially the case for thesemetadata which are already influenced by an IRO used onthe actual context information and which has additionallyto be transfered into another representation. For instance, anIRO transforming an WGS84 coordinate into an address cansignificantly decrease the accuracy of the information if noaddress for the coordinate is available but rather an addressnear the coordinate. Additionally, the context provider mayhave expressed the accuracy in meters while the contextconsumer has specified it in feet. Thus two IROs have tobe applied.The results of the Discovery and Matching approach</p><p>serve as input for the Selection approach. Before the actualselection, the discovery and matching results have to besearched for temporally infeasible context services: the QoCinformation of a context service does not necessarily reflectits actual QoC, as the service might currently be deactivated.This results in using estimated and po...</p></li></ul>