An Infrastructure to Provide Context-Aware Information and Services to Mobile Users

Transcription

1 An Infrastructure to Provide Context-Aware Information and Services to Mobile Users Pablo Curiel and Ana B. Lago Deusto Institute of Technology - DeustoTech MORElab Envisioning Future Internet University of Deusto, Avda. Universidades 24, Bilbao, Spain {pcuriel,anabelen.lago}@deusto.es Abstract. Mobile devices have undergone great changes in the last few years, turning into powerful hand-held computers. This, together with the numerous information sources they have access to, both in form of physical sensors and applications with access to the Internet and large amounts of personal data, make them an ideal platform for the deployment of context-aware applications. In this paper we present a context management infrastructure for mobile environments, responsible for dealing with the context information which will enable mobile application and services to adapt their behaviour to meet user needs. This infrastructure relies on semantic technologies to improve interoperability, and is based on a central element, the context manager. This element acts as a central context repository and takes most of the computational burden derived from dealing with this kind of information, thus relieving from these tasks to more resource-scarce devices in the system. Keywords: context management, semantic technologies, pervasive computing, mobile computing, context-aware services. 1 Introduction Nowadays mobile devices play a prominent role in our lives, being around 6 cellular subscriptions for every 7 people in the world [7]. At the same time, with the emergence of the new and powerful mobile phone models, the smartphones, the capabilities of these devices have outstandingly increased. This way, smartphones are not only equipped with an equivalent hardware to desktop computers from a few years ago, but they also include other key features like permanent network connectivity, ability to execute a great diversity of applications and integrate numerous sensors. With these characteristics, latest mobile devices are able to provide richer and better context information than ever before, and therefore are a great platform for the deployment of context-aware applications. By context we mean any information that can be used to characterize the situation of an entity (where entity is a person, place, or object) that is considered relevant to the interaction between a user and an application, including the user and applications themselves, J. Bravo, D. López-de-Ipiña, and F. Moya (Eds.): UCAmI 2012, LNCS 7656, pp , c Springer-Verlag Berlin Heidelberg 2012

2 234 P. Curiel and A.B. Lago and thereby a context-aware system is considered so if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user s task [1]. In this paper we present an infrastructure which manages the context information in mobile environments and makes it available for the rest of the entities in the environment, enabling the provision of relevant information and services to end-users. In order to improve the interoperability between the heterogeneous devices present in these environments, the infrastructure makes use of semantic technologies. Indeed, as dealing with these kind of technologies is computationally demanding, a blackboard approach [6] is adopted with the inclusion of a central element, the context manager. This element takes most of the computational burden derived from dealing with this kind of information and acts as a central context repository for the more resource-scarce devices in the system like mobile devices. The remaining of this paper is structured as follows. In Section 2 related work is reviewed. Then in Section 3 the context management infrastructure is described. Next, in Section 4 the implemented prototype is explained along with the validation scenario designed and the performance tests carried out. Finally, in Section 5 discussion and future work is exposed. 2 Related Work Numerous context-aware systems for mobile environments have been developed in the last years. The work in [9], proposes a Context Managing Framework whose aim is to provide context information to mobile applications in order to adapt their behaviour according to that context. As our system, it uses a blackboard approach, based on a central context server, to decouple source and consumer communication. But in contrast to our solution, it places this central server inside the mobile phone and limits the context information usage to each mobile phone s own applications. CoBrA project [3] proposes an architecture for supporting context-aware systems in smart spaces. It is based in a central agent, a broker which maintains a shared model of the context representing all the entities in a given space. It also uses a policy language to allow users to define rules to control the use and the sharing of their private contextual information. However, the system is not explicitly designed to operate in mobile environments. In [5], CASS, a middleware for context-aware mobile applications is introduced. Its main goal is to give service to devices with low processing capabilities, like mobile phones. For this purpose, as we do in our system, it delegates demanding tasks regarding context processing to external entities in the network. It also resembles our solution in making usage of a central context repository. But whereas we adopt a semantic representation for that central repository, which enables a more flexible context processing and sharing, CASS uses a database for this purpose, which follows no semantic representation and relies mainly on a rule-based engine to process that context.

3 An Infrastructure to Provide Context-Aware Information and Services 235 Finally, the MOBE architecture by Coppola et al [4] intends to send applications to mobile devices depending on the context the user is in. MOBE differs from our solution in that it delegates most of the computing burden in the mobile phones, making them responsible for both gathering and processing context information, as well as deciding which applications to request in each case. It also restricts context information usage to select and adapt mobile applications, while in our system both mobile applications and applications executed in the network take advantage of this information. 3 The Context Management Infrastructure In this section we present the Context Management Infrastructure, describing all the elements that comprise it along with the requirements they must comply with and the tasks they carry out. 3.1 Context Source Context sources are those entities which provide context information, and can be of a great diversity of types: physical sensors, end-user mobile devices, social networks, mobile services, etc. Should be noted that sources must perform this context information provision according to a semantic representation model previously established and shared by the rest of the entities of the system. More precisely, ontologies are used for this purpose, as they are considered the best solution for context modelling in ubiquitous computing applications [12], due to their ability to deal with uncertainty, flexibility to integrate data coming from different sources and reasoning capabilities among other reasons. 3.2 Context Consumer A context consumer is whichever entity that requires context information to correctly perform its tasks. In our case, most common consumers are mobile application and services, which make use of context information to adapt their functioning to meet the needs of end-users. To enable flexible consumer scenarios, both pull and push context information access is supported by the proposed system. At the same time, considering the computational limitations of mobile devices, a data-centric approach is used for the context information requests. This enables consumers to only care about what information they need, not where to retrieve it from. 3.3 Context Manager The Context Manager is the central element of the context management infrastructure. It acts as a central repository, which stores the context information retrieved from the sources and allows consumers to access it. As said, mobile devices, even if its processing power has noticeably increased in the last years,

4 236 P. Curiel and A.B. Lago are yet more computationally-limited than conventional computers, and thus have greater limitations to carry out demanding tasks with context information. Therefore, the context manager is introduced, as an element that provides a centralized access to context information and which takes most of the computational burden of dealing with this kind of information, and so alleviating this problem. Additionally, the presence of this central element enables the mentioned datacentric approach, as consumers request the information they need to the context manager, which has previously got it from the sources, and thereby also favours independence between context source and consumers. However, the context manager is not an atomic entity that carries out all the context management tasks itself, but its comprised of various independent components in charge of performing different tasks. This does not only favour reuse, but also scalability, as each entity can be physically operating on different machines. These components are the following. Current Context. This element stores the context information which is valid in each moment, that is, the one that represents the current status of the entities which are considered to be part of the context. This information is stored following the ontological model shared by the whole system, so the access to it must be ruled by this model too. Context History. In contrast to the current context, which only stores currently valid information, the context history keeps track of the changes taken place in the context information. Depending the strategy followed for the historical information storage, this entity could require a great amount of space. Hence, several policies have been established, such as number of entries to store, information time-to-life, which entities should be stored and which not,... so as to enable different configurations for each specific scenario. Context Broker. This component is responsible for managing both access to current and history context repositories. This way, it stores in the current context the context information received from the sources, moves outdated information from the current context to the context history, and attends consumers requests querying these two repositories. At the same time, in order to comply with consumers requirement to support both pull and push access modes, it has two subcomponents: the Query Manager, which deals with pull or synchronous queries, and the Subscription Manager, responsible for registering consumers asynchronously subscriptions for context information changes and notifying them in push mode when those changes occur. Despite this multi-entity composition of the context manager, regarding the interaction with the rest of the system it exposes a unique entry point to its functionality, the context manager API. This also enables supporting different communication protocols to interact with the context manager, as this API is merely an access layer, belonging the operation logic to the internal components. The context management API exposes several methods that enable context source

5 An Infrastructure to Provide Context-Aware Information and Services 237 and consumers to work with context information. Among those, the following can be emphasized as being some of the most relevant ones: Add Context Info. This method enables a context source to add or update context information in the current context space. Query. By calling this method, a context consumer can synchronously access the current context space using SPARQL queries. Subscribe/Notify. TheSubscribe method enables a context consumer to asynchronously access the current context space. The consumer provides an SPARQL query, which the context manager will register, as well as a callback address which the second will use to notify the first when the query is matched using the Notify method. 4 Implementation and Evaluation In this section we describe the implementation of the system which follows the design detailed in the previous section and the tests carried out to evaluate its performance. The prototype involves a fully functional context manager developed in Java and using the OSGi [10] component framework. To work with semanticized context information we use the semantic web toolkit Jena [2] and Jenabean [8], which offers a POJO-to-RDF mapping which eases the interaction between Java objects and the Jena RDF graphs. The context manager API is exposed as a RESTful [11] interface, which has gained popularity in the last years due to its simplicity an lower overhead compared to other approaches like SOA. As a first validation step, a demonstration scenario was implemented. This scenario involves a contextual service and a end-user Android application interacting with the context manager. An ontology was also designed to represent the context of this scenario. This ontology models information about Users (their personal data, preferences, current location and current activity) and Alerts (which are sent to users) among others. The purpose of the scenario is to suggest available users to meet their nearby friends. This way, the contextual service monitors users Twitter accounts to infer their availability, and at the same time registers a subscription in the context manager to know when various users are nearby. So, when it detects two or more available friends next to each other, it sends them an alert. Meanwhile, the end user application tracks users location and keeps the context manager up to date of its changes. It also queries the context manager seeking for alerts sent to its users. Besides, starting from this scenario, a series of tests where carried out to assess the performance of the context manager. In these tests, the contextual service acts as context source, periodically (every 5 seconds) adding alerts for the enduser application, which acts as consumer. This end-user application, depending on the test, either queries periodically (every 1 second) for these alerts or registers an asynchronous subscription to receive them. In each of these tests the number of context source and consumers interacting with the context manager varies, in order to observe how these changes influence its performance. The context

6 238 P. Curiel and A.B. Lago Fig. 1. CPU usage adding instances Fig. 2. Memory usage adding instances Fig. 3. Instance adding times Fig. 4. Synchronous query times manager was executing in a PC with a Intel Core 2 Duo at 2.26GHz and with 4GB of memory, running Widows 7 Professional Edition and JDK 1.6. The CPU and memory usage statistics were collected using the JConsole utility provided by the JDK. From these tests several conclusions were extracted. First of all, in Fig. 1 it can be observed how an increase in the number of concurrent sources interacting with the context manager greatly impacts the system performance. This way, with only one concurrent source adding context information, the CPU demand is very subtle until the ontological instance count in the context manager exceeds 100 units, and reaches the 100% with almost 200 units. In contrast, having five concurrent sources interacting with the context manager, CPU demand is significantly higher even when there is a low number of instances in the current context, reaching a 100% CPU demand with about 50 instances. Finally, with ten concurrent sources, the CPU demand is even higher, reaching 100% with about 20 instances in the current context. At the same time, Fig. 1 states what Fig. 2, 3 and 4 also do, that the number of instances in the context space has a huge impact in the system performance too. Therefore, apart from increasing the processing power needed, Fig. 2 shows that memory consumption follows a linear increase as a function of the instance number. Concerning the instance adding time (Fig. 3) and query times (Fig. 4), they follow a similar pattern, increasing according to an exponential function.

7 An Infrastructure to Provide Context-Aware Information and Services 239 Fig. 5. CPU loads with and without consumers On to other matters, the presence of context consumers has a significantly lower impact on the system performance. On the one hand, comparing Fig. 3 and 4, it can be seen that the synchronous query operations is remarkably faster than the context adding one (around 20 times faster). On the other hand, an increase in number of context subscribers harms the system performance noticeably less than an increase in the number of concurrent sources. This way, as Fig. 2 points out, memory usage is only a slightly higher when context subscribers are present comparing to when they are not. Regarding processor load and context adding times, Fig. 5 and 3 show that an increase in the number of subscribers is not as bad for system performance as an increase in the number of sources, although it adds some overload, specially as the number of instances in the context space increases. This is due to the subscription checking being part of the context adding operation, and therefore the separation of this two tasks should be considered to improve system performance. Fig. 6. System performance with and without Jenabean Finally, an excessive system overload was observed when the instance number in the context space increases, so some checks were made. This led to the conclusion that working with Jenabean is both more processor and memory demanding that working directly with Jena, as Fig. 6 shows. Must be noted that this test was not carried out removing Jenabean completely from the prototype, as it is deeply integrated in the implementation, but only interacting directly with Jena to perform the instance adding operation. Thus, reimplementing the prototype without depending on Jenabean could improve system performance to a greater extent that what Fig. 6 shows.

8 240 P. Curiel and A.B. Lago 5 Conclusion In this article we have presented a context management infrastructure for mobile environments. This proposal revolves around the role of the context manager, a central context repository which relieves the more power-limited devices, such as mobile phones, from carrying out demanding tasks with context information. The implemented prototype and the tests carried out have shown a functional system which complies with the defined requirements. However, performance issues were observed when the context space held by the context manager increases, in great extent due to the usage of Jenabean, an object to RDF mapping library. As it was find out, this library noticeably increases both the processing power and memory needs comparing to working directly with Jena. Therefore, our next working steps will involve either removing Jenabean and directly working with Jena or replacing it with a similar library that offers better performance. References 1. Abowd, G.D., Dey, A.K., Brown, P.J., Davies, N., Smith, M., Steggles, P.: Towards a Better Understanding of Context and Context-Awareness. In: Gellersen, H.-W. (ed.) HUC LNCS, vol. 1707, pp Springer, Heidelberg (1999) 2. Apache Jena: Java semantic web framework, 3. Chen, H., Finin, T., Joshi, A.: An intelligent broker for context-aware systems. In: Proc. of Ubicomp, Seattle, Washington, USA, pp (2003) 4. Coppola, P., Della Mea, V., Di Gaspero, L., Mizzaro, S., Scagnetto, I., Selva, A., Vassena, L., Rizi, P.: MoBe: context-aware mobile applications on mobile devices for mobile users. In: Proc. International Workshop on Exploiting Context Histories in Smart Environments, ECHISE, Munich (2005) 5. Fahy, P., Clarke, S.: CASS-a middleware for mobile context-aware applications. In: Proc. Workshop on Context Awareness, MobiSys, pp (2004) 6. Hayes-Roth, B.: A blackboard architecture for control. Artificial Intelligence 26(3), (1985) 7. ITU: Key global telecom indicators for the world telecommunication service sector, 8. jenabean: A library for persisting java beans to rdf, 9. Korpip, P., Mantyjarvi, J., Kela, J., Keranen, H., Malm, E.: Managing context information in mobile devices 2(3), (2003) 10. OSGi Alliance: The open services gateway initiative, Richardson, L., Ruby, S.: RESTful web services. O Reilly Media (2007) 12. Strang, T., Linnhoff-Popien, C.: A context modeling survey. In: Proc. Workshop on Advanced Context Modelling, Reasoning and Management, Nottingham, England