[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) - High level context query processing: An experience report

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) - High level context query processing: An experience report

Post on 11-Mar-2017




1 download


<ul><li><p>High Level Context Query Processing: An Experience Report</p><p>Cristina Fr, Massimo Valla Strategy &amp; Innovation Telecom Italia S.p.A. </p><p>Torino, Italy {cristina.fra, massimo.valla}@telecomitalia.it </p><p>Nearchos Paspallis Department of Computer Science </p><p>University of Cyprus Nicosia, Cyprus </p><p>nearchos@cs.ucy.ac.cy </p><p>Abstract Pervasive applications want to describe in simple ways which context information they need about users, and be notified when low level context matches specified constraints defined by semantic expressions. In this paper we report our experience while implementing our Context Query Language and using it in a real context framework to support mobile context-aware applications in two European-funded projects. Our experience has shown that both the language design and its implementation are suitable to support complex asynchronous high-level context notification requirements from applications. </p><p>Keywords- context awareness; context query processing; CQL; experience; implementation; context models; context management </p><p>I. INTRODUCTION Pervasive applications need to access heterogeneous </p><p>context information about users and their devices in simple ways, without dealing with details about how raw sensor data was collected and how higher level context data has been derived from it. In addition, since context changes are asynchronous by nature, applications are interested to be notified when context matches specified constraints, often expressed at a semantic level, without knowing or specifying the equivalent constraints on raw sensor data. </p><p>In the past years, starting from a set of requirements and an analysis of related work on query languages for context data [1], we have proposed and implemented a new Context Query Language (CQL) [2] that allows applications to request and subscribe for notification of context information specifying a set of constraints on context values or using semantic expressions. </p><p>The CQL language design offers advanced features such as: (a) filters and constraints to subscribe to asynchronous context change events, on both context data and metadata; (b) a set of logical operators to combine elementary conditions into more complex ones; (c) access to current and past context informationraw or derived from other informationenabling the retrieval of a set of context elements using a single query; (d) programming language and system independent: access to context data is provided through high level APIs; (e) ability to formulate queries that </p><p>incorporate semantic reasoning and aggregation functions (e.g. average network speed is below 1.0 Mbps). </p><p>In this paper we report on our experience with both implementing the Context Query Language within our context framework and with applying it to a set of use cases related to context-aware applications for mobile users. In our approach, context is first collected by sensors on mobile phones and then delivered to a context management server, which notifies applications that have subscribed to it using CQL queries [4]. </p><p>To describe how our implementation works, in the rest of the paper we will follow a specific technical use case: an application is interested to be notified when a user is at home. In a simple implementation, the user device could update regularly its GPS position to a server to compare with the coordinates of what the user has specified as home in his user profile. There are two main disadvantages to this simple approach: first, the position of the user can be of interest to several services but the device cannot continuously update its position to all of them. Second, the energy consumption implied by the continuous transmission of GPS position can be significant for mobile devices. A layered context architecture (which includes sensing &amp; triggering, context management, context reasoning, query &amp; notification) is thus needed to decouple applications requiring context notifications from device sensing. Furthermore, for privacy reasons the user may not want applications to know the exact coordinates of his home location, but may be willing to notify them when he reaches home. In a more complex scenario, users may associate the concept of home to several locations (regular home, vacation home, etc.) and context reasoning is needed to notify applications in all cases, regardless of the specific location of each users home. </p><p>The technical use case presented here may be a component for applications interested in knowing when a user is in a specific place type without knowing his exact location: a telecommunication operator could for example apply different mobile phone rates when the user is at home or in the office; advertising applications may deliver contextualized advertising messages when users are with friends and at the mall. The use case involves the translation of a high level query (user is at home) into </p><p>8th IEEE Workshop on Context Modeling and Reasoning</p><p>978-1-61284-937-9/11/$26.00 2011 IEEE 421</p></li><li><p>constraints on raw context data (GPS position) and the provision of monitoring conditions called triggers on the user device. In the following we describe the process from the reception of the high level query from an application, to the provision of triggers and finally to the notification sent to the application about matched context condition. </p><p>This paper aims at presenting our experience in the implementation of context query processing functionality on a real context framework. In fact, the implementation described here has been applied successfully in extensive application scenarios within two European projects: IST-MUSIC [11] and ICT-CCAST [12], which will be summarized in the evaluation section. In particular, our experience has shown that: (a) our CQL is expressive enough to support applications context requirements, yet it is simple to define and aggregate context conditions, thus reducing application complexity; (b) runtime performance is improved as conditions on context data are processed according to triggers deployed on mobile node sensors, avoiding unnecessary data transmission and reducing the number of notifications to be processed; (c) since semantic relations and concepts can be included in the queries, applications can remain at a more abstract layer without dealing with how raw context data is collected in practice from device sensors and how the conditions are verified. </p><p>In this paper Section II describes related work about context query languages; Section III briefly summarizes our context model and the design of the CQL to better understand the subsequent context query examples; Section IV describes the software architecture of the context framework; Section V details context processing and involved steps; Section VI gives details about the implementation and provides an evaluation; finally Section VII summarizes our conclusions. </p><p>II. RELATED WORK Several approaches have been proposed to express </p><p>context queries. An analysis of existing approaches has been already proposed [1] [2]; in this section we briefly describe works most relevant to our solution, paying attention to their context query processing features. </p><p>In PACE [5] the context management system provides aggregation and storage of context information and performs query evaluation. It contains a distributed set of context repositories where each repository manages a collection of context models, defined using CML - Context Modeling Language, and mapped to relational data schemes; context queries are internally mapped to SQL. PACE supports asynchronous programming by providing a trigger mechanism and an event-condition-action (ECA) model. Since context information is spread over several tables, a number of joins may be necessary in quite complex queries, in particular when performing context reasoning. The programming API of CML does not address the retrieval of context information with heterogeneous representations and inclusion of complex preprocessing functions is not supported. Another difference with the programming API of CML is that the CQL presented in this paper provides the </p><p>possibility to specify context queries in a platform and programming language independent way. </p><p>The Nexus project [6] has implemented servers for different classes of context data and a very flexible federation middleware for integrating them. Typical context information requests use either the object ID or the position to select a set of context objects, and then filter the attributes of the selected objects. For example, "all persons in 100m radius (selection: position), give me just the name (filter: name)). To be part of the Nexus platform, a context server has to implement a certain interface: accept simple spatial queries and return results in specified XML languages called Augmented World Query Language (AWQL) and Augmented World Modeling Language (AWML). AWQL allows for spatial predicates like overlaps or within (range queries) and supports selections of the n objects nearest to a given position (nearest neighbor queries). </p><p>The CARE middleware [7] supports asynchronous notifications to applications using a triggering mechanism. Triggers are derived from requested context conditions set by applications (called monitoring specifications) and, similarly to our solution, triggers are communicated (using a socket protocol) to a light server module resident on the users device. Context triggers are derived from monitoring specification in an optimized way, to minimize unnecessary context updates. </p><p>III. CONTEXT MODEL AND QUERY LANGUAGE For context modeling we chose a simple but highly </p><p>extensible approach [3] based on XML where context information is represented in terms of context elements. Every context element contains a set of context values (represented as key-value pairs) belonging to the same domain (e.g. position, civil address, environment, etc.). We refer to a specific domain as a context scope; for example the scope position is composed by a couple of geographical coordinates (latitude and longitude) and optionally an accuracy estimation. An entity refers to a concrete object in the world (e.g. user, device, room, etc.) and is the subject the context data refer to. According to this model, every context element refers to a specific entity-scope couple. </p><p> The Context Query Language (CQL) was defined as an XML-based language, strongly related to the underlying context model. It allows applications to submit complex queries by specifying a set of constraints representing query filters. Every query is about an entityor a set of entities belonging to the same typeand also about a context scope. Simple queries may not have conditions while more complex queries can have one or more conditions containing constraints connected with logical operators (potentially with unlimited nesting). </p><p>CQL supports semantic references obtained through an ontology and used to describe concepts and relationships between entities. In this paper we assume that an ontology describing all the concepts involved in the query examples was available at a specific URL (for example: </p><p>422</p></li><li><p>http://www.example.com/ontology.xml). This URL, which would be normally used as the prefix of the various entity/scope designations, is omitted in the following examples to avoid cluttering. </p><p>The language allows applications to submit synchronous (SELECT) or asynchronous (SUBSCRIBE) queries to the system. For example an application that needs to be notified every time a user is in Turin can submit the following query: * </p><p>The query is a subscription (specified by the action tag) related to all users in the system (identified by the wildcard * in the entity tag). The condition specifies a type and a constraint that is on the value of a specific scope attribute. The scope under constraint is civilAddress and specifically the constraint is on its attribute city that must be equal to Turin. Attributes ontConcept are used to identify the semantic concepts involved in the query. </p><p>IV. SOFTWARE ARCHITECTURE The use case presented is enabled by a general client-</p><p>server Context Framework [8] illustrated in Figure 1. On the client side a Local Context Broker (LCB) collects data from different sensors. In the example used in this paper the following context sensors are installed on the mobile device: GPS and Wi-Fi, but other sensors can be installed. According to some energy saving policies and to applications needs, context data is updated using HTTP to the Context Broker (CB) server that makes this information available to applications through a set of web APIs. In our framework, context information is represented using ContextML [9] [10], a XML-based binding of our context model, and exchanged between components using HTTP. The Context Broker can also communicate with the LCB of registered mobile devices by sending commands using XMPP RPC extensions [13]: this enables a server-to-device channel to allow control by the server of context update policies on the device. For example the Context Broker, based on current applications needs, can send a command on the device to activate/deactivate a context sensor. In our use case, the Context Broker sends commands using XMPP to provision on the device a context trigger containing conditions: when the context conditions are matched by sensors, context is updated by LCB to the server. </p><p>The Context Broker acts as an aggregator of raw context data related to the same entity coming from different sources and exploits other components in order to infer higher level context information. These components (in the following we refer to them as Context Providers - CP) are easily pluggable in the architecture since the CB offers an API that a Context Provider can invoke to register itself and to announce its capabilities in terms of entities and scopes. </p><p>ContextML data</p><p>LocalContextBroker(LCB)</p><p>ContextBroker(CB)</p><p>ContextApplication</p><p>mobilenetwork</p><p>1.query</p><p>ContextQuery</p><p>Processor</p><p>7.notification</p><p>3.triggersactivation(viaXMPP)</p><p>5.contextupdate</p><p>CQLmessages</p><p>2.triggerscreation</p><p>4.triggersevaluation</p><p>6.conditionevaluation</p><p>ActiveQueryDB</p><p>WebAPIs</p><p>sensors</p><p>LocationProvider</p><p>WeatherProvider ...</p><p> Figure 1. Overall system architecture and query processing steps. </p><p> For example consider two CP plugged on the system, the first one able to translate the users position in the corresponding civil address and the second one able to retrieve the weather condition in a specific city. An application can ask for the weather conditions in the city where the user is currently located. If the users device sends the GPS position to the CB, it invokes these two backend components first to translate the geographical coordinates in the corresponding civil address and then to retrieve the related weather forecast. </p><p>More complex Context Providers can announce their capabilities in terms of semantic concepts. For example Figure 1 shows the Location Provider (LP), a CP that during its registration phase an...</p></li></ul>


View more >