Context as a Service

Introduction Approach Evaluation Conclusions

Context as a Service

Michael WagnerDistributed Systems Group

University of Kassel

December 2010


Michael Wagner Distributed Systems Group University of Kassel 1


Outline

IntroductionMotivationQuality of context and cost of contextChallenges and objectives

ApproachContext model and ontologyContext Offering and Query LanguageDiscovery and matchingSelectionBinding

Evaluation

Conclusions




Introduction




Context provider

Light sensor

Proximity sensor

Accelerometer

Thermometer

GPS Sensor

Digital compass

Co

nte

xt s

en

sors




Context provider

Light sensor

Network based

Temperature

Activity

Reasoner

Calendar based

Position

Network based

PositionProximity sensor

Accelerometer

Thermometer

GPS Sensor Cell-ID based

Position

Digital compass

Co

nte

xt s

en

sors

Co

nte

xt reaso

ne

r




Context provider

Light sensor

Network based

Temperature

Activity

Reasoner

Calendar based

Position

Network based

PositionProximity sensor

Accelerometer

Thermometer

GPS Sensor Cell-ID based

Position

Digital compass

Co

nte

xt s

en

sors

Co

nte

xt reaso

ne

r

Similar type of context

information

Position

Temperature




Additional external context provider

WiFi

Positioning

GPS

WiFi

Positioning

GPS

WiFi

Positioning




Additional external context provider

WiFi

Positioning

GPS

WiFi

Positioning

GPS

WiFi

Positioning

RFID

Positioning

WiFi

Positioning




Using context in context-aware self-adaptiveapplications

Several types of context consumers:

� Application business logic: Context-information used withinthe actual application (e.g. navigation from the currentposition to another position)

� Adaptation reasoning: Selection of the “best” variant of theapplication with regard to the execution context

� Context reasoning and fusion:� Deducing high-level implicit context from low-level explicit

context� Checking the consistency of context� . . .




Various context providers and consumers

� Several context providers� internal and external� potentially providing the same type of information� but differing in quality and cost� and the representation of the information, quality and cost

data

� Several context consumers� internal and external� potentially requesting the same type of information� but differing in quality and cost preferences� and the requested representation of the information, quality

and cost data




Current solutions

� Most commonly: hard-linked references to context sensors andreasoners, but

� no support for dynamically appearing new context providers.

� Few approaches support the dynamic selection and discoveryof context sensors [CAS06, HM04], but

� developers have to know the data representations of thecontext provider,

� no support for activation and deactivation (and the resultingproblems) of context providers in order to save resources.

However, dynamic discovery, data interpretation and energy-savingare essential requirements in pervasive computing [SHB10].




Quality of Context

“Quality of Context (QoC) is any information thatdescribes the quality of information that is used ascontext information. Thus, QoC refers to informationand not to the process nor the hardware component thatpossibly provide the information.”

[BKS03]

Cost of Context

“Cost of Context (CoC) is a parameter associated to thecontext that indicates the resource consumption used tomeasure or calculate the piece of context information.”

[VRL+09]Context as a Service



Context providers differ in the provided QoC, required CoC and theprovided representation of the context information, QoC and CoC.

Problem

Selection and activation of one of the available context providersand thereby . . .

� estimating the QoC of deactivated context providers.

� taking into account the heterogeneous representations ofcontext information and the according QoC and CoC.

� trading off the provided QoC and required CoC against theQoC as requested by the consumer and his preferencesregarding cost.




Challenges, requirements and objectives

Local and remote context sensors and reasoners are abstracted ascontext services.

� Main challenges:� Dynamic selection of context providers based on QoC and

CoC� Activation and deactivation of context sensors

� Additional requirements and objectives:� Exchange and interpretation of heterogeneously represented

context information, QoC and CoC� Loose coupling of context providers and consumers� Dynamic discovery of external context services� Estimation of QoC of deactivated context providers based on

historical context values




Approach




Overview - Context model and ontology

Challenges and requirements:

� Exchange andinterpretation of contextinformation, QoC and CoC

Context model and ontology




Meta-model and Ontologyowl:Thing

ScopeEntityType Representation

is-a

hasRepresentation*characterizes*

Composite Representation Basic Representation

is-a

hasDimension*

� Entity: Physical or logical entity of the world that is describedby the information, e.g. PDA

� Scope: Refers to the type of the provided information, e.g.Location; meta-data are also considered as scopes

� Representation: Describes how the information is internallystructured, e.g. GPS data




Meta-model and Ontology

� Ontology is used to provide a common vocabulary to bridgesemantic differences

� Defines semantic concepts for entity (types), scopes andrepresentations

� Captures relationships between the defined concepts� Information can be represented as individuals of ontological

concepts/classes� Data structures may be semantically annotated by references

to the ontology




Meta-model and Ontology� Ontology defines entity types, scopes, representations and

their relationships� Arbitrary number of representations for scopes

RepresentationScope

DateTimeInfo

is-a is-a

hasRepresentation*

LocationInfo LocationRepDateTimeRep

LocationWGS84

LocationAddress

DateTimeDefaultRep

DateTimeCustomRep

LocationInfo_Indv1

LocationInfo_Indv2

DateTimeInfo_Indv1

DateTimeInfo_Indv2

Day = 14

Month = Januar

Year = 1981

Date = 14011981

Street = Königstor

Number = 12

City = Kassel

Latitute = 52.686

Longitude = -2.193

is-a is-a

is-a

is-a

is-a

is-aio

io

io

io

io

io

io

io

hasRepresentation

hasRepresentation

hasRepresentation

hasRepresentation

hasRepresentation*

hasRepresentation*




Meta-model and Ontology

� Internal structuring of context information is defined asrepresentations in the ontology

� Inter-Representation-Operations (IROs) allow conversionbetween different representations

� Simple conversions, e.g. of units, defined in the ontology itself� Grounding to methods in libraries or to a conversion service

� More details of the context model and ontology in[RWK+08a, Rei10, Pas09]




Overview - Context provider and consumer


� Exchange and interpretationof context information, QoCand CoC

� Loose coupling

Context Provider 0..*Context Consumer 0..*

Reasoner 0..*





Context Offering and Query Language

� Aligned with the context meta-model and the ontology

� Simple EMF/XML based language based on the MUSICContext Query Language (CQL) [RWK+08b] and theInformation Offer and Request Language (IORL) [Rei10]

� In difference to the CQL also support for context offers

� Support for complex filters and conditions similar to the IORL

� In difference to the IORL also support for the differentmetadata representations and for context selection




Context Offering and Query Language

We can query for or offer context information

� corresponding to a certain scope

� characterizing a certain entity

� having a certain representation




Context Offering and Query Language - Overview

Context Offer/Request

Sub-Offer/Sub-Request

Scope Representation

SourceFrequency

Subscription

SourceType

Constraints

*

*

ScopeProperty or ScopeID Operator Value Delta

Metadata Constraint

Metadata class Operator Value Delta

Scope Constraint

Characterized Entity *

*

Entity Recursive Negotiable

Entity Constraint

*

*

*

Selection Function

Utility

Significant change spec.

Representation




COQL - Example

1 <c o q l : COQLDocument xmi : v e r s i o n = [ . . . ]2 <C o n t e x t Q u e r i e s query ID=” query1 ”3 scope=” P o s i t i o n ”4 r e p r e s e n t a t i o n=” P o l a r C o o r d i n a t e ”5 s u b s c r i p t i o n M o d e=”ONCHANGE”6 f r e q u e n c y=” 100 ”>7 <E n t i t i e s e n t i t y R e f=” User | Aragorn ”/>8 </C o n t e x t Q u e r i e s>9 </ c o q l : COQLDocument>




Overview - Discovery and matching



� Loose coupling

� Dynamic discovery

� Estimation of QoC


Discovery and Matching

Reasoner 0..*

Co

nte

xt

Re

qu

es

ts Co

nte

xt o

ffers





Matching problem

� Combination of ontology reasoning and constraint matching� Usually, Constraint Satisfaction Problems (CSPs) are

NP-complete.� However, CSPs try to find an assignment of values to all the

variables so that none of the constraints is violated,� but we are only interested in the satisfiability in general.→ Most of the solutions for CSPs are too heavy-weight.→ Light-weight solution currently in research.




Example for matching process

CONTEXT QUERY 1

Entity: User | Paul

Scope: Position

Rep: CartesianCoordinates

Memory < 0.5 MB

BatteryCost < 0.1 mWh

CONTEXT OFFER 2

Entity: User

Scope: Position

Rep: CartesianCoordinatesAccuracy =

1 cell


Cell-ID based Location Sensor

CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor

Accuracy: ∆_longitude < 10 m ᴧ

∆_latitude < 10 m





CONTEXT QUERY 1

Entity: User | Paul

Scope: Position


Memory < 0.5 MB


CONTEXT OFFER 2

Entity: User

Scope: Position


1 cell



CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor


∆_latitude < 10 m

1. Scope and scopeconstraints

2. Representation

3. Entity and entityconstraints

4. Metadata constraints

Conditions: Scopeq = Scopeo or Scopeq is a generalization of Scopeoor Scopeq = nested scope of Scopeo and scopeConstraint holds!





CONTEXT QUERY 1

Entity: User | Paul

Scope: Position


Memory < 0.5 MB


CONTEXT OFFER 2

Entity: User

Scope: Position


1 cell



CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor


∆_latitude < 10 m


2. Representation



Conditions: Repq = Repo or Repq is a generalization of Repo orRepo can be transformed to Repq by an IRO





CONTEXT QUERY 1

Entity: User | Paul

Scope: Position


Memory < 0.5 MB


CONTEXT OFFER 2

Entity: User

Scope: Position


1 cell



CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor


∆_latitude < 10 m


2. Representation



Conditions: (Entityq = Entityo or Entityq is a generalization ofEntityo) and entityConstraint holds!




Example for matching processCONTEXT QUERY 1

Entity: User | Paul

Scope: Position


Memory < 0.5 MB


CONTEXT OFFER 2

Entity: User

Scope: Position


1 cell



CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor


∆_latitude < 10 m


2. Representation



1. Metadataq = Metadatao or Metadataq is a generalization of Metadatao2. Repq = Repo or Repq is a generalization of Repo or Repo can be

transformed to Repo by a IRO3. Constraintq ∧ Constrainto satisfiable!




Example for matching process - Result

CONTEXT QUERY 1

Entity: User | Paul

Scope: Position


Memory < 0.5 MB


No Matching: BatteryCost

CONTEXT OFFER 2

Entity: User

Scope: Position


1 cell



CONTEXT OFFER 1

Entity: User

Scope: Position

Rep: WGS84

Accuracy < 1 km


GPS Sensor


∆_latitude < 10 m




Overview - Selection



� Loose coupling



� Dynamic selection



Reasoner 0..*

Co

nte

xt

Re

qu

es

ts Co

nte

xt o

ffers

Selection

Matching Results


Selection

function




Input for the selection: matching results




Problems during the selection

� General approach: Calculation of an utility for each providerby an utility function taking into account QoC and CoC andselection of the provider with highest utility.

� However, several additional problems to be handled in theselection, because . . .

� the selection algorithm has to use predefined QoC values fordeactivated context providers.

� these predefined properties do not noteworthy reflect thestatus of the provider after its activation.





After activation, QoC values are much worse than predefinedQoC.

Solution:

� Update of the predefined QoC values based on historicalvalues → Good result if QoC properties reflect malfunction ofthe provider. Otherwise no improvement.

� Ignoring the malfunctioned provider until a significant contextchange has happened.





Additional optional requirement: Cost minimization

Same type of context information requested by differentconsumers and with slightly different criteria.

Solution:

1. Check if intersection of matched context offers is nonemptyand if so

2. select context provider with the least cost.




Overview - Binding



� Loose coupling



� Dynamic selection

� Activation anddeactivation



Reasoner 0..*

Co

nte

xt

Re

qu

es

ts Co

nte

xt o

ffers

Selection

Binding

Selection Result

Converted Data

Matching Results


Selection

function

Inter Representation

OperationData

Data




Evaluation




Demonstrator Meet-U

Planning Offline Navigation At Event




Demonstrator - Context dependencies

� Adaptation decision� based on position, current activity and connectivity status.

� Application Business Logic� Navigation mode requires precise position.� Planning mode requires information about current activity,

activity preferences and on current location of friends.




Demonstrator - Context services� Build-in context providers:

� Cell-id based location sensor (Low cost, low accuracy)� WiFi based location sensor (Medium cost, medium

accuracy)� GPS based location sensor (High cost, high accuracy)� Connectivity status reasoner� Activity reasoner estimating the activity based on position

and calendar data (Low costs, low accuracy)� Activity reasoner estimating the activity based on

microphone, accelerometers. calendar and position. (Highcost, medium accuracy)

� External context provider:� Bluetooth-based location service (Medium costs, high acc.)� RFID-based location service (Low costs, high accuracy)




Evaluation criteria

Questions

� Does the approach meet the requirements?� Discovery and matching of context providers� Support for heterogeneous context information� Selection of context providers

� Performance and scalability test in a simulator




Conclusions and future work




Conclusions

� Abstraction of dynamically appearing and disappearing localand remote context sensors and reasoners as context services.

� Middleware for context-aware self-adaptive applicationssupporting the selection of different context services based onQoC and CoC criteria

� Semantic interpretation of heterogeneously representedcontext information, QoC and CoC

� Flexible access of information in the required representationand automatic conversions

� Support for estimation of QoC of deactivated contextproviders




Future work

Very broad research topic with a lot of remaining open issues, e.g.

� Privacy and security support (e.g. offering different contextlevels based on privacy preferences)

� Support for different discovery mechanisms and protocols

� MDD support for context providers, consumers and reasoners

� . . .




Thank you!

Thank you for your interest!

Questions?

Michael WagnerUniversity of KasselT. +49-(0)561-804-6281

eMail: [email protected]: http://www.vs.uni-kassel.de/



Literature I

Thomas Buchholz, Axel Kupper, and Michael Schiffers.

Quality of context information: What it is and why we need it.In In Proceedings of the 10th HP-OVUA Workshop, 2003, Geneva, Switzerland, Juli 2003.

Maria Chantzara, Miltiades Anagnostou, and Efstathios Sykas.

Designing a quality-aware discovery mechanism for acquiring context information.In AINA ’06: Proceedings of the 20th International Conference on Advanced Information Networking andApplications, pages 211–216, Washington, DC, USA, 2006. IEEE Computer Society.

Markus C. Huebscher and Julie A. McCann.

Adaptive middleware for context-aware applications in smart-homes.In MPAC ’04: Proceedings of the 2nd workshop on Middleware for pervasive and ad-hoc computing, pages111–116, New York, NY, USA, 2004. ACM.

Nearchos Paspallis.

Middleware-based development of context-aware applications with reusable components.PhD thesis, Department of Computer Science, University of Cyprus, Nicosia, Cyprus, 2009.

Roland Reichle.

Information Exchange and Fusion in Dynamic and Heterogeneous Distributed Environments.PhD thesis, Distributed Systems Group, University of Kassel, Kassel, Germany, July 2010.



Literature II

Roland Reichle, Michael Wagner, Mohammad Khan, Kurt Geihs, Jorge Lorenzo, Massimo Valla, Cristina

Fra, Nearchos Paspallis, and George Papadopoulos.A comprehensive context modeling framework for pervasive computing systems.In Distributed Applications and Interoperable Systems, pages 281–295, 2008.

Roland Reichle, Michael Wagner, Mohammad Ullah Khan, Kurt Geihs, Massimo Valla, Cristina Fra,

Nearchos Paspallis, and George A. Papadopoulos.A context query language for pervasive computing environments.In CoMoRea, pages 434–440, Hong Kong, Mar 2008. IEEE Computer Society Press.

Gregor Schiele, Marcus Handte, and Christian Becker.

Pervasive computing middleware.In Hideyuki Nakashima, Hamid Aghajan, and Juan Carlos Augusto, editors, Handbook of AmbientIntelligence and Smart Environments, pages 201–227. Springer US, 2010.

Claudia Villalonga, Daniel Roggen, Clemens Lombriser, Piero Zappi, and Gerhard Troster.

Bringing quality of context into wearable human activity recognition systems.In Kurt Rothermel, Dieter Fritsch, Wolfgang Blochinger, and Frank Durr, editors, First InternationalWorkshop on Quality of Context (QuaCon 2009), volume 5786 of LNCS, pages 164–173, Stuttgart, June2009. Springer-Verlag.



Context as a Service

Technology

Transcript of Context as a Service