Context as a Service - Requirements, Design and Middleware Support

Michael Wagner, Roland Reichle, Kurt GeihsDistributed Systems Group

University of KasselKassel, Germany

{wagner, reichle, geihs}@vs.uni-kassel.de

Abstract—Context-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.

Keywords-Context-aware services; Ubiquitous computing;Adaptive systems

I. INTRODUCTION

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 internalsensors, 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

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.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 provisioningprocess 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

8th IEEE International Workshop on Middleware and System Support for Pervasive Computing

978-1-61284-937-9/11/$26.00 ©2011 IEEE 220

represented context information in an ubiquitous computingenvironment.

The remainder of this paper is structured as follows: insection 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.

II. PROBLEM STATEMENT

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 ComputingEnvironments (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:

• 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.

• 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

taking into account provided and required quality ofcontext, required cost of context and the consumer’spreferences 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.

In addition to these two main research goals we have toconsider the following research issues:

• 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.

• 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 service’s logic and imple-mentation. Furthermore it allows to switch dynamicallybetween different context services as these are not hard-wired in the source code.

• 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

221

conversion between different data representations, asfor example the conversion of GPS Coordinates to astreet address.

• 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.

• 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.

III. SOLUTION APPROACH

Context Service 0..*Context Consumer 0..*

Discovery and Matching

Reasoner 0..*

ContextRequests C

ontextoffers

Selection

Binding

Selection Result

Converted Data

Matching Results

Context model and ontology

Selectionfunction

Inter RepresentationOperation

Data

Data

Figure 1. Overview of the Solution Approach.

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

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 contextservices 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 approachserve 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 potentially not up-to-date QoC data for the selection, e.g. an estimation of ahigh accuracy of a GPS sensor even if the mobile devicehas moved into a building in the meantime. Therefore,infeasible context services are removed from the selectionuntil a significant context change has happened, e.g. theuser has significantly changed his position. After that acorrespondence of estimated QoC and actual QoC afteractivation is more likely. For the actual selection, a utilityfunction is used to calculate the utility of the different con-text services in consideration of the provided and requiredQoC and CoC. Then afterwards the service with the highestutility is selected. If a context service does not providethe required representation but an according IRO (or moregeneral IRO chain) is available (already checked in theDiscovery and Matching approach), the aggregated cost ofthe IRO (chain) has to be taken into account, too. The resultof the Selection approach is used to establish communication

222

links to and to activate the corresponding context providersand optionally to compose the provider with an IRO (or IROchain) to provide the requested representation of the contextinformation.

Figure 2 shows an example for the matching and selectionof context query and context offers in order to further explainthe design principles of our context management approachfor open ubiquitous computing environments. A contextconsumer expresses by context query 1 his need for thecurrent position data of the user Paul presented in polarcoordinates. Potentially, three different context providerscan offer this information: a GPS sensor, a cell-ID basedlocation sensor and a position reasoner, which infers thecurrent position of the user by checking his calendar forappointments and then using the address book to find theaccording address. As depicted, the position reasoner is alsoa context consumer requesting for two additional contextinformation providers. Therefore, it has to be ensured thatthe context dependencies of this reasoner can be fulfilledbefore taking him into consideration for resolving the initialcontext query.

Legend

Query/Offer Constraint

Matching of Offerand Query

Selection

CONTEXT OFFER 1

Entity: UserScope: PositionRep: PolarCoordinates

Accuracy < 1 meter

BatteryCost < 0.5 mWh

GPS Sensor

Works only outside

CONTEXT OFFER 2

Entity: UserScope: PositionRep: CartesianCoordinates

Accuracy = 1 cell

BatteryCost < 0.1 mWh

Cell-ID based Location Sensor

No Matching: BatteryCost

Not selected: BatteryCost

Cellphone calendar

CONTEXT OFFER 3

Entity: UserScope: PositionRep: Address Accuracy <

40 feet

BatteryCost < 0.01 mWh

Position ReasonerCONTEXT QUERY 2

Entity: UserScope: CurrentAppointment Rep: iCal

CONTEXT QUERY 3

Entity: UserScope: CustomerAddress Rep: Address

CONTEXT QUERY 1

Entity: User | PaulScope: CurrentPositionRep: CartesianrCoordinates

Accuracy: ∆_longitude < 10 meter ᴧ

∆_latitude < 10 meter Memory <

0.5 MB

BatteryCost < 0.1 mWh

CONTEXT OFFER 5

Entity: UserScope: AddressbookRep: Address

Personal addressbook

No cost

CONTEXT OFFER 4

Entity: UserScope: CalendarRep: iCal

No cost

Figure 2. Example for Matching and Selection

However, these three context providers differ in the pro-vided representation of the information and also in qualityand cost of the information. Therefore, it has first to bechecked if IROs are available to transform the offeredinformation into the requested representation. Furthermore,as the context consumer has also restricted his context querywith several constraints, it has to be checked before theactual selection if the context provider can satisfy theseconstraints. As depicted, the context consumer requests thebattery consumption to be smaller than 0.1 mWh but theGPS sensor needs more resources. Thus, this context offeris excluded from the list of matching context offers. Thisconstraint checking can also involve the need for transfor-mation of representations of the constraints with the usage

of IROs, e.g. the context consumer requests the positioninformation with a difference of 10 meters in both longitudeand latitude at maximum but the context reasoner (contextoffer 3) provides the information in feet. This also showsthat an IRO can be more than a simple unit transformation,viz. a transformation by an IRO can require major structuraltransformations. Another example for complex constrainttransformations is the cell-ID based location sensor, whichexpresses his accuracy to be 1 cell. Thus, an IRO is requiredthat approximates the radius of that cell in order to reasonabout the constraint in the context query.

IV. ARCHITECTURE

Based on the design presented in the previous section,a novel context management middleware is currently underdevelopment. Figure 3 presents an overview of its archi-tecture and general infrastructure. As depicted in part a) amiddleware instance has to run on every device on whichat least one context consumer is executed. This instancecan be shared by all context consumers on that device.No middleware instance is necessary on the context serviceside. As depicted in part b), Context Service Consumers andContext Services register their context requests respectivelycontext offers at the Discovery Service. The DiscoveryService employs a local repository containing all registeredcontext offers and queries. For every new registration ofeither a query or offer, the Discovery Service triggers a newmatching process by the Matching Service. For calculatingthe Matching Results, the Matching Service accesses the on-tology with the help of the Ontology Manager, triggers IROsby the Mediation Engine where applicable and accesses therepository for context offers and queries provided by theDiscovery Service.

The Matching Service stores all matching results in alocal repository. For every new matching result, it triggersa selection process by the Selection Service. Therefore,the Selection Service accesses the repository for matchingresults provided by the Matching Service and the repositoryfor the details of context offers and queries provided bythe Discovery Service. Context services can also query forcontext information. Therefore the selection process has toensure before the selection if also for these queries at leastone matching result is available to resolve the dependencies.After selecting a context offer for a certain context query,the Selection Service triggers the binding of offer and queryby the Binding Service.

This service leverages again the Mediation Engine totrigger IROs, where applicable, and triggers the monitor-ing process by the QoC and CoC Monitor. The monitorcontrolles the context data provided by the context provideraccording to their context offers and updates the offers whereapplicable. This update may trigger then a new matchingprocess. Furthermore the QoC and CoC Monitor stores allcontext data in a Context Repository, which is used e.g. for

223

the updates of context offers or for context fusion. Contextfusion is provided by the Context Engine and is optionallytriggerd by the Mediation Engine in order to e.g. increasethe reliability of context information. The details of contextfusion are beyond the scope of this paper. The reader isreferred to the thesis of Reichle [8] for a detailed treatmentof this subject.

Device 2 Device mDevice 1

OntologyReasoner

MediationEngine

Fusion Engine

BindingService

SelectionService

QoC & CoCMonitor

ContextServiceConsumer

ContextService

ContextRepository

Context Data

Register

Trigger Matching

Use

TriggerSelection

AccessRepository

Trigger IRO

Trigger Binding

TriggerFusion

Update Offer

TriggerIRO

AccessRepository Access

Repository

Data Push/Pull

AccessOntology

Access Ontology

AccessRepository

MatchingService

MatchingResults

OntologyManager

Ontology

DiscoveryService

Context Offers & Queries

Access Repository

Trigger Monitoring

AccessRepository

MiddlewareInstance 1

Application 1

CQ

Sensor 1

CO

Reasoner 1

CO CQ

Application 2

CQ

Sensor 3

CO

Sensor 4

CO

Sensor 5

CO

Application 4

CQ

Application 3

CQ

Sensor 2

CO

MiddlewareInstance 2

Reasoner 2

COCQ

ApplicationReasoning 1

CQ

Context ServiceConsumer

Middleware

Context Services

CO Context Offer CQ Context QuerySynchronous or asynchronouscommunication of context information

Middleware

a) Context Service Infrastructure

b) Context Service Middleware Architecure

Figure 3. Infrastructure and architecture

The implementation of the middleware is ongoing work.It is based on Java and OSGi. The different componentsdescribed in the previous section on the architecture arerealized as OSGi bundles. Similar to Paspallis [9], alsocontext providers are implemented leveraging the OSGIcomponent specification. However, we have extended thegeneral OSGi lifecyle as the context services can have addi-tional context dependencies. The context providers for thesedependencies change dynamically as new services appear ordisappear and as new applications are started or stopped.To overcome this limitation, the context plug-in lifecycleis amended with three context middleware specific states:C INSTALLED, C RESOLVED and C ACTIVE. A newlyinstalled context service is registered as C INSTALLED. Ifall context dependencies are resolved, this service is movedto C RESOLVED. Context sensors without additional con-text dependencies are directly moved to C RESOLVED afterthe registration. For context reasoners, a matching processis triggered for all of its context queries. Only if these

matching processes result in nonempty matching results,the reasoner is moved to C RESOLVED. These states arenot controlled by the OSGi framework, but rather by thecontext middleware. The Context Query and Offer Language(COQL) is implemented with the help of the Eclipse Mod-elling Framework (EMF). This has the advantage, that notonly the complete JAVA data structures can be automaticallygenerated from the model but also (de-)serialization methodsand a graphical editor.

V. RELATED WORK

Our work is related to several research areas, but due tolack of space we cannot present a detailed discussion of allthe related work here. Instead, we focus on those contextmanagement systems which are closest to our approach.Note that, some specific details including related workdiscussions have already been published, e.g. context modeland ontology [10] and context query language [11].

One of the first approaches abstracting context providersby components is the Context Toolkit [1]. Its main objectiveis to simplify the development of context-aware applica-tions by allowing the reuse of specialized components,which include widgets, aggregators, interpreters, servicesand discoverers. Even if the Context Toolkit facilitates thediscovery of widgets, aggregators, interpreters and servicesand enables easy integration via the HTTP protocol and Webstandards, heterogeneity issues like different representationsof context information due to independent development arenot considered. Furthermore the Toolkit leaves the dynamicselection of a context provider to the application developer.

Chantzara et al. present an approach for the evaluation andselection of context information [12]. Even if their approachof context selection is generally similar to our approach,the authors don’t provide support for heterogeneous rep-resentations of context information and more importantly,they don’t address the activation/deactivation of contextproviders, which we consider a crucial practical requirementfor resource-constrained devices.

Huebscher and McCann also presented a middlewarefor context-aware applications, which exhibits autonomicproperties and can choose one of several context providersoffering the same type of context according to the require-ments of the applications [13]. The adaptive middleware usesutility functions to determine - given the QoC requirementsof the applications and the QoC of alternative means ofcontext acquisition - which alternative should be used atany time. Like Chantzara et al. this approach is similiarto our selection concept. However, Huebscher and McCanndo not address the dynamic activation and deactivation ofcontext sensors and the related tasks (e.g. calculation of theQoC of an deactivated context source). Furthermore, theirconcept does not provide any support for heterogeneousrepresentations of context data and their metadata.

224

The Nexus project [2] aims at context management forhighly dynamic and complex context information in largescale environments. Federation nodes are used to combinecontext information into one global context model. Byintegrating the provided information into a spatial worldmodel, Nexus tries to remove inconsistencies which areunavoidable when several different sensors are monitoringthe same environment. However, context providers are onlyselected based on spatial restrictions [14] and not basedon other requirements of the consumer, e.g. the requestedaccuracy. Furthermore the project does not provide supportfor the dynamic activation of context providers, so it is notpossible to minimize the resource consumptions based onthe selection.

To the best of our knowledge, no comprehensive approachis currently available that solves all the challenges mentionedabove and explicitly targets the heterogeneity issues andprovides support for activation / deactivation of contextproviders.

VI. CONCLUSIONS

In this paper we presented a comprehensive contextmanagement solution that specifically addresses the charac-teristics of open, dynamic, heterogeneous ubiquitous com-puting environments based on a ”context as a service”abstraction. Our concept and implementation support thedynamic selection of context providers based on QoC andCoC criteria. Context sensors are activated and deactivatedby the middleware on demand. By providing a solution forthe semantic interpretation and transformation of hetero-geneously represented context information, QoC and CoC,we enable flexible access to information in heterogeneousrepresentations.

Besides the realization and evaluation of the contextmiddleware, our future work will focus on issues of inconsis-tency, security, privacy and trust for context sources. Theseare crucial requirements for context-aware systems wherelarge amounts of user-related data are collected, stored, andprocessed. To address the issue of inconsistency, the Nexusproject follows an interesting idea by providing an integratedconsistent context model. This idea seems to be easilycombinable with our approach by allowing the selection ofmore than one context provider and to fuse the providedinformation before forwarding them to the consumer.

REFERENCES

[1] A. K. Dey, “Providing architectural support for buildingcontext-aware applications,” Ph.D. dissertation, Georgia In-stitute of Technology, Atlanta, GA, USA, 2000.

[2] D. Nicklas and B. Mitschang, “On building location awareapplications using an open platform based on the nexusaugmented world model,” Software and Systems Modeling,vol. 3, pp. 303–313, 2004.

[3] T. Erl, SOA Principles of Service Design (The Prentice HallService-Oriented Computing Series from Thomas Erl). UpperSaddle River, NJ, USA: Prentice Hall PTR, 2007.

[4] T. Buchholz, A. Kupper, and M. Schiffers, “Quality of contextinformation: What it is and why we need it,” in Proc. of the10th HP-OVUA Workshop, 2003, Geneva, Switzerland, Juli2003.

[5] C. Villalonga, D. Roggen, C. Lombriser, P. Zappi, andG. Troster, “Bringing quality of context into wearable humanactivity recognition systems,” in Proc. of the Workshop onQuality of Context (QuaCon 2009), ser. LNCS, vol. 5786.Stuttgart: Springer, June 2009, pp. 164–173.

[6] “Mobile users in ubiquitous computing environments(MUSIC).” [Online]. Available: http://www.ist-music.eu

[7] T. Strang, C. Linnhoff-Popien, and K. Frank, “CoOL: a con-text ontology language to enable contextual interoperability,”in Proc. of the Distributed Applications and InteroperableSystems, 2003, pp. 236–247.

[8] R. Reichle, “Information exchange and fusion in dynamic andheterogeneous distributed environments,” Ph.D. dissertation,Distributed Systems Group, University of Kassel, Kassel,Germany, July 2010.

[9] N. Paspallis, “Middleware-based development of context-aware applications with reusable components,” Ph.D. disserta-tion, Department of Computer Science, University of Cyprus,Nicosia, Cyprus, 2009.

[10] R. Reichle, M. Wagner, M. Khan, K. Geihs, J. Lorenzo,M. Valla, C. Fra, N. Paspallis, and G. Papadopoulos, “Acomprehensive context modeling framework for pervasivecomputing systems,” in Proc. of the Distributed Applicationsand Interoperable Systems, 2008, pp. 281–295.

[11] R. Reichle, M. Wagner, M. U. Khan, K. Geihs, M. Valla,C. Fra, N. Paspallis, and G. A. Papadopoulos, “A contextquery language for pervasive computing environments,” inProc. of the Workshop on Context Modeling and Reasoning(CoMoRea). Hong Kong: IEEE Computer Society, Mar2008, pp. 434–440.

[12] M. Chantzara, M. Anagnostou, and E. Sykas, “Designinga quality-aware discovery mechanism for acquiring contextinformation,” in Proc. of the Conference on Advanced Infor-mation Networking and Applications (AINA). Washington,DC, USA: IEEE Computer Society, 2006, pp. 211–216.

[13] M. C. Huebscher and J. A. McCann, “Adaptive middlewarefor context-aware applications in smart-homes,” in Proc.of the Workshop on Middleware for pervasive and ad-hoccomputing (MPAC). New York, NY, USA: ACM, 2004, pp.111–116.

[14] R. Lange, N. Cipriani, L. Geiger, M. Großmann, H. Wein-schrott, A. Brodt, M. Wieland, S. Rizou, and K. Rothermel,“Making the World Wide Space Happen: New Challengesfor the Nexus Context Platform,” in Proc. of the Conferenceon Pervasive Computing and Communications (PerCom ’09).IEEE Computer Society, March 2009, pp. 1–4.

225