A Framework for Real-Time Context Provision in ... - CiteSeerX

A Framework for Real-Time Context Provision in Ubiquitous Sensing Environments Mark Roantree Paolo Cappellari Adel Shaeib School of Computing School of Computing School of Computing Dublin City University Dublin City University Dublin City University Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—In many ubiquitous computing environments, where applications and systems are required to determine the location of individuals, context information is necessary to support decision making. In practical terms, this requires a hybrid query interface where the user can query live streaming data (to confirm their location) while also using more traditional database expressions to query or mine context repositories. The research presented in this paper describes our approach to developing a framework to support this form of hybrid query application. Our industry collaborator provides a real-world application in which spaces that are equipped with ubiquitous sensing environments are prone to frequent change, requiring a flexible approach to the management of context information. Keywords-Ubiquitous Computing, Streaming, Query, Sensors.

(type M). For queries of type M, historical data is generated automatically from previous location tracking. TABLE I: Query Classifications Type L L C C C C C M M M

Query What is X’s Current Location? How many people are in this location? What products are available in Zone Z? Given current direction, what is next Zone? Given current direction, what are next 3 Zones? How many Zones in this Space? What is the largest Zone? How long has X been in this Space? What is the most popular product for this Zone? Top-N products Today?

I. I NTRODUCTION Research in Wireless Sensor Networks (WSNs) now focus primarily on data management [1]. In the ubiquitous scenario, information management is integrated into everyday objects and activities, providing the bridge between the physical world and a digital representation of this world. One aspect of ubiquitous computing is the smart building that uses embedded sensors to monitor and control the environment within a building. In this research, we have an industrial collaborator with a requirement for context-aware location services inside their buildings. Buildings generally have a number of large rooms which are divided into zones (for location purposes) and inside zones various products and services are made available. It is the zones, products and services that provide the context for location-based queries and is typical of mobile applications where location-dependant context is required [5]. To complicate matters however, rooms must be rezoned on regular occasions and often rooms may be rearranged to move products and services around. This requires a more abstract model of context information to facilitate the flexible and volatile nature of zones and their contents. A. Motivation and Contribution Given the flexible requirements outlined, more precise requirements are identified by the analysis of the types of queries involved. We classify these requirements as depicted, with the support of sample queries, in Tab. I. Such queries require three separate information sources: a live stream emitting location information (type L); a live stream and a database with context data (type C); an archive of historical information

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

Our research contribution is in the provision of a framework to manage streaming, contextual and data mining queries, effectively providing a hybrid query interface. As part of this framework, we developed a metamodel to facilitate rezoning within buildings and include new sensing devices as they become available. For an evaluation of our approach, we developed the UbiQuSE (Ubiquitous Queries for Sensing Environments) system to assess the speeds that could be expected, given the potential of three levels of interaction for some user queries. As mining queries are currently performed offline, we do not assess the times required to process these queries. The structure of this paper is as follows. §II, provides an overview of existing research; §III, presents the architecture of our hybrid framework; §IV discusses and analyses the experiments. Finally, in §V we present our conclusions. II. R ELATED R ESEARCH Prominent works such as Cougar [7], TinyDB [8] and others [6], [9] focus on live data. Our framework proposes an hybrid system to query both live and historical series of enriched data. Storage of sensor data historical series has been addressed in ELF [10] and PRESTO [11]. While both these works rely on local (flash) storage systems, we rely on a centralised DBMS for both contextual and historical series, which allow us to tune repositories performance to enhance query response times. Works [2], [4], [12] are examples of approaches trying to exploit the Semantic Web and reasoning techniques. In [2] authors adopt SWRL rules to process context information and possibly discover new information. In [4] authors try to exploit

1078

User Live Sensor Data

Query Interface Acquisition

Structure

Enrichment

Live Query Interface Context Query Interface Mining Query interface

Context

Warehouse

Repository

Fig. 1: UbiQuSE Query Architecture

inter-link between data to infer additional information. ES3N [12] links sensor data to an ontology in order to allow more complex queries to be specified. Our approach is different in that context information is well defined and structured; it is exposed as a catalogue in a relational database, making it easy to access and to modify without the need of having to modify the system implementation or logic. Moreover, we store historical series, and we report on query response times which are not described in such works. III. DATA M ANAGEMENT A RCHITECTURE In this section we describe our framework for gathering data and expressing hybrid queries. Fig. 1 sketches the architecture of the framework by showing three components: Data-Gathering, Repository and Query-Interface. A. UbiQuSE Data-Gathering The Data-Gathering component is composed of three subcomponents in which live data from the sensors flow sequentially. Sub-component Acquisition is responsible for the initial processing of the raw data from the sensors. The format in which raw data are provided in the stream depends on the sensor system and its configuration. Sub-component Acquisition connects to the sensing server and process the data stream in order to identify and isolate processable unit of data. In our case, a processable unit of data contains: the identifier of the data source (an object in the space), its location in the three dimensional space, the time in which the information has been generated. Sub-component Structure semantically enriches values from the raw sensor data by wrapping them into XML tags with their corresponding attributes names. The main advantage is in having self-describing data in an interoperable format such as XML for which a standard query language exists (XQuery).

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

Finally, sub-component Enrichment is responsible for enriching live data with information from the context in which data is generated. For instance, in a smart building application scenario, the live data representing the spatial position of an object in an area is enriched with the application specific information of such an area. Information of an area include the name, the description and what is available nearby (services, products or other). Which information to load from the context and which to add to the live data is selected from the metadata repository on the basis of the live data itself – e.g. location of the tracked object. For instance, the XML snippet1 below shows an example of the final output from the Data-Gathering. 3 0 / 1 1 / 2 0 0 9 15 : 2 7 : 4 6 1 9 . 0 4 3 1 0 . 9 1 0 2 1 . 2 1 3 3 2 Zone 3−2

P015 < s e r v i c e l i s t />

By storing all the events for all of the tracked objects of interest in the smart building application scenario, we create a semantically enriched repository. B. The UbiQuSE Repository The repository component comprises two main subcomponents: the data warehouse and the metadata (or context) database. In the Smart Building scenario, a Space is divided into one or more Zones and these zones have associated services or products. In our current implementation, the context database is implemented as a relational database. What is important to observe is that context information is exposed and de-coupled from the system implementation: modifying the context does not require any changes to the system, which simplifies the task of the Space administrators as they can limit their attention to the space partition and product or service allocation. The data warehouse stores information as processed from the Enrichment component. It contains the historical data of tracking entities in their interaction with the sensing environment, enriched with the semantic information from the context. Such semantically enriched information enables data warehouse users to ask sophisticated queries. C. UbiQuSE Interface The Query-Interface component is responsible for accessing data. As illustrated in Fig. 1, it has three sub-components, one for each category of queries. The live query interface component is responsible for processing queries relevant to the live data only, queries of type L in our classification. This is managed by processing live data as it comes out of the XML wrapping process. The context query interface processes 1 Business

partner’s data has been replaced for privacy reasons.

1079

queries that “mix” live and context data, queries of type C in our classification. The context describes the configuration of the smart building application scenario. Examples are: “What is the largest zone?” “What services are available in the current area?” While queries on the (static) environment configuration retrieve information only from the context database (plain SQL), queries that involve live data need to retrieve data from the context and mix it with the current live information. This is realised by combining on-the-fly the information from the live data with the information stored in the repository. From the live data the parameter of interest is extracted by means of an XQuery expression; such parameters feed into an SQL query that is then run on the context database. Ideally, the SQL query is predefined so that the process can be automated. The mining query interface is responsible for retrieving data from the data warehouse. Historical data in the data warehouse contains data enriched with context and sensor related information. The user has to decide which dimension to explore from those introduced by the data enrichment. IV. C ASE S TUDY In our experimental setup, it was necessary to model the requirements of our industry collaborator in the laboratory. The discussion remains abstract for reasons of intellectual property but there is sufficient detail to understand the capabilities of the framework and relative performance. The laboratory Space is divided into Zones, each of which is delimited by coordinates. The laboratory is equipped with four Ubisense Cells installed at each corner, part of the Ubisense Platform [3] deployment which is in charge of tracking the objects in the space and providing access to the streams of live data. In our implementation, the Ubisense platform is paired with: a 2.66GHz Intel(R) Core(TM) 2 Duo server with 3.25GB RAM running PostgreSQL on Windows XP; a 2.40GHz Intel(R) Core(TM) 2 Duo server with 4.86GB RAM running MonetDB on Ubuntu 9.04. A. Tracking Accuracy We tested the UbiQuSE accuracy and the result is that Ubisense has a critical area of up to 20cm where an accuracy varies and has a margin of uncertainty. Above 20cm we definitively have absolute measurement precision, which suite our application scenario. B. Query Performance The first query we report on simply retrieves (tracks) the location of an object in the space (the first query in Tab. I). This query is straightforward (it just returns the location of an Ubi-tag) and demonstrates if there is any significant overhead introduced by the XML wrapping mechanism of our architecture. In general, the overall response time for tracking queries was less 205ms, which is in the same order as the standard Ubisense response time [3]. The second query we examine, a context query, is an extension of the third query in Tab. I. It tracks the movements of a Ubi-tag while returning the products and services available

978-1-4244-7755-5/10/$26.00 ©2010 IEEE

in the zone and surrounding zones of the Ubi-tag’s location. An extract of the execution for such a query is shown in the following listing. As soon as the person wearing the tag moves (enters a zone), the system seeks to verify their location and potential paths, and also executes a context query to determine what is available at that location. In example, 16ms were required to deliver this information to the user. Tag 20000007106 i n Zone 2−2. C o n t e n t s a r e P r o d u c t P027 . ========================================= R i g h t z o n e c o n t e x t i s Wall . R i g h t z o n e C o n t e n t s a r e None ========================================= L e f t z o n e c o n t e x t i s Zone 3−2. L e f t z o n e C o n t e n t s a r e P r o d u c t P015 ========================================= F r o n t z o n e c o n t e x t i s Zone 2−3. F r o n t z o n e C o n t e n t s a r e P r o d u c t P022 ========================================= Back z o n e c o n t e x t i s 2−1. Back z o n e C o n t e n t s a r e None ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ q u e r i e s p r o c e s s e d i n : 1 6 . 0 ms .

V. C ONCLUSIONS In this paper, we described our framework for real-time tracking and service provision based on smart spaces of variable size and layout. Our metadata approach ensures that we can deploy our system in any of the scenarios we have currently encountered and our hybrid query mechanism does not place any significant overhead as demonstrated by our experimental results. Future work will address and examine the effects of scaling on our system, as we employed only a limited number of tracking tags in our experiments. R EFERENCES [1] Aberer K. Swiss Experiment: From Wireless Sensor Networks to EScience. Proceedings of the 6th Workshop on Data Management for Sensor Networks, 2009. [2] KeBler, C., Raubal, M., and Wosniok, C. In: Semantic Rules for ContextAware Geographical Information Retrieval. In: 4th European Conference on Smart Sensing and Context, pp. 77-92, LNCS 5741, Springer, 2009. [3] Ubisense English Site. http://www.ubisense.net/ [4] Wei, W., and Barnaghi, P. Semantic Annotation and Reasoning for Sensor Data. In: 4th European Conference on Smart Sensing and Context, pp. 66-76, LNCS 5741, Springer, 2009. [5] Zhang, J., Zhu, M., Papadias, D., Tao, Y., and Lee, D. L. 2003. Locationbased spatial queries. In Proceedings of International Conference on Management of Data, SIGMOD, 2003. [6] Intanagonwiwat, C., Govindan, R. and Estrin D. Directed diffusion: a scalable and robust communication paradigm for sensor networks. In Proceedings of MOBICOM, 2000. [7] Yao, Y. and Gehrke, J. The Cougar Approach to In-Network Query Processing in Sensor Networks. In Proceedings of International Conference on Management of Data, SIGMOD, 2002. [8] Madden, S., Franklin, M.J., Hellerstein, J.M. and Hong, W. TinyDB: an acquisitional query processing system for sensor networks. ACM Trans. Database Syst., 2005 [9] Deshpande, A., Guestrin, C., Madden, S., Hellerstein, J.M., and Hong, W. Model-Driven Data Acquisition in Sensor Networks. Proceedings of the Thirtieth International Conference on Very Large Data Bases, 2004. [10] Dai, H., Neufeld, M., and Han,R. ELF: an efficient log-structured flash file system for micro sensor nodes, Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, 2004 [11] Li, M., Ganesan, D., and Shenoy, P.J. PRESTO: feedback-driven data management in sensor networks. IEEE/ACM Trans. Netw. 2009 [12] Lewis, M., Cameron, D., Xie, S., Arpinar, B. ES3N: A Semantic Approach to Data Management in Sensor Networks. Semantic Sensor network workshop, 5th International Semantic Web Conference, 2006.

1080