Design and Implementation of an Integrated Contextual Data Management Platform for Context-Aware Applications

Transcription

1 Design and Implementation of an Integrated Contextual Data Management Platform for Context-Aware Applications Udana Bandara 1,2 Masateru Minami 1,3 Mikio Hasegawa 1 Masugi Inoue 1 Hiroyuki Morikawa 1,2 Tomonori Aoyama 2 1 Mobile Networking Group 2 The University of Tokyo 3 Shibaura Institute of Technology National Institute of Information and Communications Technology Hongo, Bunkyo-ku, Tokyo , Japan Othe Shibaura,Minato-ku,Tokyo Japan 3-4 Hikarino-oka, Yokosuka, Kanagawa , Japan [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Abstract With significant advancements in VLSI design and mass production, many ubiquitous computing services, which were once a dream, have become technically feasible. In light of this, context-awareness has become a fundamental concern. In order to provide context-aware services, a system should be able to identify contextual information, process it, and present it to context-aware applications. Thus in this paper, we present a contextual-data managing platform architecture, built specifically for this purpose. Recognizing the importance of providing an extensible world model, we propose a novel contextual managing and integrating architecture using components called Mappers. Having already implemented a prototype of this system in our laboratory, it is currently being used by researchers and visitors alike. Keywords Context Awareness, Contextual Data Management, Ubiquitous Computing, I. INTRODUCTION Introducing the vision of Ubiquitous Computing, Mark Wiser commented that, The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it. [1]. In recent years we have seen an increase in the number of research projects incorporating this idea. Indeed, Project Oxygen at MIT[3], Project STONE[8] at The University of Tokyo, and Project Cooltown[4] at Hewlett-Packard, could, among others, be given as examples of some of these efforts. Also, with significant advancements in the computer hardware industry and mass production, many ubiquitous computing services have finally become technically feasible. In light of this, contextawareness has become a fundamental concern. What is context-awareness? A.K. Dey [2] gives a comprehensive definition of context as follows: Context is any information that can be used to characterize the situation of an entity. An 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. According to this definition we can declare context awareness as the system s ability to use such context data to provide better services. One of the key applications where context-awareness could play a major role is communication. As an example it would be useful if the communication devices could understand our situation, and switch between , text messaging, voice over IP, video conference etc automatically. Then if the user is in a meeting his incoming VoIP call could be switch to a text massage according to his or her preference. Context-awareness will bring rich functions and more human friendliness to communication. There are many other types of applications that could benefit from context awareness. We can list some of the probable applications in a future ubiquitous computing environment as follows: 1. Personalization of Services For most of us time is highly valuable; in such a society personalization of services has great value. It reduces the time we spend learning or figuring out how to use new services or setting up service parameters according to the environments. With context aware support in applications, it is possible to present the user interface of his preference according to the situation. 2. Optimal Resource Utilization In a ubiquitous computing environment, available wireless network infrastructure, displays, keyboards, services, sensors, etc, varies from place to place. In such an environment the user s preference of necessary services or resources also varies according to the user s contextual state. In such an environment it is highly desirable to have a mechanism to optimize resource utilization using contextual data. 3. Distress Free Usage Contextual data could be used for distress free usage of services. As an example, consider a well known ubiquitous computing scenario: a mobile user comes near a plasma display whilst in a video phone session with his friend and wants to use the plasma display instead of the small display on his mobile device. To perform this task gracefully the system should know much contextual data; it should know users location, preferences, and the fact that he is in a video conference session. By integrating this data, the system is capable of providing distress free services. In order to provide context-aware services, the system should be able to identify the contextual information, process it, and present it to context-aware applications. Thus in this paper, we present a contextual-data managing platform architecture, built specifically for this purpose. The system is implemented as prototype in our laboratory, and it is currently being used by researchers and visitors alike. The rest of the paper is organized as follows. Section 2 introduces the design goals of the system. We then discuss the system architecture in section 3. Section 4 introduces the actual implementation and applications we developed on this platform. Finally conclusion is given in section 5. II. DESIGN GOALS Recently, we have seen research projects [6, 7] that focus on context-sensing with multi-sensor middleware based approaches. The middleware based approach is best suited for rapid developments and proliferation of context aware services. More specifically, in developing such a context-sensing platform, we have recognized the following basic design goals

2 for providing rich context-aware services in ubiquitous computing environments: Extensibility of the world model A reference model of the real world is needed by the system to provide context aware services. We call such a model a world model. The real world is prone to rapid changes and modifications. Extensibility of the world model is necessity to provide accurate data. High precision of contextual data Undoubtedly the most important characteristic of location sensing should be providing precise data. Here precision does not mean providing high resolution data, it instead represent the correctness of the data as a percentage. This is true for any type of contextual data. We need higher value of precision for providing context aware applications. As an example; the system wants to use a nearest fixed phone for routing a phone call to the user - in this case the system wants to know the location of the user with high precision. If he is not near any of the phones the system might transcode the message and send it to his PDA as an . Uncertainty preservation Even with our best efforts there will be some sort of uncertainty left in the sensed contextual data. If we inform the uncertainty to the applications then the application could handle according to the situation. This is a very important factor for development of better applications on a software platform. If the application is provided with uncertainty information then this data could be used with the contextual data to provide services more accurately. III. SYSTEM ARCHITECTURE Here, we introduce a contextual data management platform which has been designed with the design goals given in the previous chapter in mind. In this architecture we introduce a world model based on Mappers which supports extensibility, multi sensor sensing methods and data fusion for high precision of contextual data, and design considerations that concern uncertainty preservation. Our architecture is based on the layered model. Location data could be considered as the single most important piece of contextual data. On the other hand location itself could be used as an index for other contextual data management. Since we propose a system with the main focus on location information management, which may be represented as a 5 layer abstraction, as shown in Figure 1. The layers are: Sensor layer, Raw data layer, Fusion and Integration layer, Contextual Merging layer, and Interface and Privacy Control layer. However, we have not defined the inter-layer interfaces. A similar layered architecture has been proposed by Hightower et al at the university of Washington, but in their architecture higher layers are concerned with pattern recognizing and learning. However, we argue such functionality is not necessary for software middleware as this type of services could be supported at application level. Nevertheless, we believe privacy support and global distribution should be considered at the middleware level. Therefore the layer model presented here only gives an abstract idea of what should be done in each layer. In this system the location representation method is very important. We developed UPI (Uniform Position Identifier) for location representation which is a hybrid data representing format similar to the data representation used in [5]. The main advantage of UPI is the ability to represent logical data as well as coordinate data. It allows the application to know the logical naming of the place as well as the position. As a example we can represent a point in CRL Yokosuka premises as follows: UPI://crl/3f/301/(10735,2089,0), which denotes the (10735,2086,0) point at 3 rd floor 301 room. In the same way we can represent the 701 room as UPI://crl/7f/701/. The UPI set could be considered as a world model which is made only with the location data. On the other hand UPI supports the distributed context server architecture with its hierarchal naming scheme. Interface & Privacy Control Fusion & Integration Raw Data Contextual Merging Sensors Context Sensing Layers (non - -location) Figure 1: Layer model of the system The following discussion is focused on how we designed each layer to fulfil the design goals. Our main focus is on the Fusion & Integration Layer and Contextual Merging Layer. Sensor Layer The Sensor layer represents the sensor technologies and the basic daemons need for running the hardware. Each technology should have its own sensor daemon and pass the sensor data up to the raw data layer. Various types of sensors have been used to obtain high precision contextual data in this layer. Raw Data Layer This layer receives data from each sensor daemon through a standard interface. All data from each sensor technology is marked with a time stamp and stored in such a manner that the fusion layer can access the data for fusion and integration according to necessity. This layer is responsible for providing necessary raw data to the Fusion and Integration layer without delays. Fusion and Integration Layer The Fusion and Integration Layer receives data from the Raw Data layer and fuse the data to obtain high precision location data. In the process, it is necessary to preserve the uncertainty level information. With this in mind, we have designed the fusion / integration layer as follows so that flexible integration of location sensing methods is possible. Here we have used a component base architecture for data fusion and integration. Each fusion component calculates the location data separately and updates a partial result table. The partial result tables contains 4 pieces of information, which are location data, uncertainty level of the location data, time stamp and located objects ID. With this design, new location fusion algorithms can easily be introduced as Integration Components. This provides the ability to improve precision according to necessity. Figure 2 shows the design of the Fusion & Integration components.

3 Query Manager Interface and Privacy Control Layer Raw Location Data Integration Formatting Component Formatting #1 Component #1 Integration Formatting Component Formatting #2 Component #2 Formattiing Integration Component Formattiing #n Component #n Figure 2: Fusion Components Results Table #1 Partial data access Results Table #2 Results Table #n One of the main features of the architecture is uncertainly preservation. Each fusion component calculates the uncertainty of the partially fused data. It outputs the probable uncertainty level. This enables the applications to actually know the quality of data received and function according to the needs. Essentially, we are concerned with knowing the location of a certain ID (user) at any time. With this model there could be many partial results providing the same ID UPI relationship with different uncertainty levels. This could be quite useful from the application s perspectives. Let us consider an example; a user wants to receive a video phone call to the nearest terminal. In that case if we can not consider just the accuracy we have to know the uncertainty level of the data to provide a reliable data. The application might not handover the video phone session to a terminal if the uncertainty level is high. Thus, with our partial result tables we could choose the location data with least uncertainty level. Contextual Merging Layer This layer merges the processed location data with other contextual data. The non-location contextual data is received from the contextual sensing layers. When the data (location data and non-location contextual data) is presented in the contextual Merging layer, it combines the data to obtain higher contextual states. As an example this layer should combine the location data, brightness data, temperature data, and surrounding electrical appliances status to evaluate the user s state. Contextual Merging Layer should construct a world model which is a best abstraction of real world information to provide context aware services. A realistic world model should be updatable and extensible with the changing world in a timely manner. And on the other hand much contextual data that we deal with could be represented as a one to one correspondence. As examples, name-id, ID-status, etc. could be given. Thus, we argue that a Mapper based architecture would be best for representing an extensible world model, which could be represented in following components: Mappers, Mapper manager, Merged mappers. This design is illustrated as in Figure 3. Mappers: Each mapper maps a single contextual parameter to another single contextual parameter. Each mapper could be implemented as a separate software component, (using Linux shared library) thus adding and deleting them is possible. Mappers communicate with the Mapper manager and Merged Mappers. The Mappers also communicate with the location data fusion and integration layer and the sensor demons for contextual data update and mapping purposes. Mapper Manager Path list Mappers Location Fusion & Integration Layer Merged Mappers.... Sensor Data Contextual Merging Layer Figure 3: The contextual Merging Layer Mapper Manager: Mapper manager communicates with the Query Manager of the Interface and Privacy Control Layer. Mapper Manager holds a Path List which provides the necessary mappers to access and solve a query received from the Query Manager. When a new mapper is added or an existing mapper deleted from the Mapper Pool, the Mapper Manager updates the Path List. When each mapper is added the mapper manager constructs the Path List automatically. This algorithm could construct the entire path for sequential transformations. But, where many non sequential mappings exist, we use Merged Mappers for such transformations. Merged Mappers: Merged Mappers could be considered as predefined path lists that hold pointers and combining formulas of available Mappers. We need this feature because there are cases where we can not calculate certain contextual data by sequential methods. As an example consider a Mapper which calculates the sleeping status of each user. In other words the Mapper calculates whether a user is sleeping or not at a given time. In such a situation the Mappers you want to access might be IDto-UPI Mapper, UPI-to-temperature Mapper, and UPI-to- Brightness Mapper. As it can be seen, these Mappers don t have a sequential relationship. Thus, we have introduced predefined path lists as Merged Mappers. The overall system functions as follows: When a query is received from the query manager the Mapper manager searches for a query resolving path from the path list. If a path exists in the path list, the query is resolved by accessing the necessary Mappers and returning the results to the query manager through the Mapper manager. If not, the query manager accesses the merged mappers, and searches for a query resolving path and resolves the query according to that path. If the path list or the merged Mappers do not contains a query resolving path, the query manager is informed that the query is irresolvable. Since easy we implemented this model as an example in a Linux server with each Mapper implemented as a shared library function, easy addition and deletion Mappers is possible. This provides the ease of extensibility of the world model. Interface and Privacy Control Layer This layer supports several functionalities. Firstly, it provided the API for overlying applications. Secondly, this layer is responsible for distributed management of location servers so that users can have global coverage. Thirdly, it is responsible for managing the contextual data in a way that user s privacy is protected. The interface layer uses simple methods to communicate with the applications. The basic functionality of the methods can be denoted as follows using

4 some of the implemented methods. Here App denotes the application and LS denotes the API of the context aware platform. App Where(uID) Notify(UPI) LS 1 2 Figure 4: Notification of user s position to the application 1 Where() method is received from the application(app). If the request has no errors in it the location server (LS) replies with an. 2 The position of the user (the UPI) is calculated in the LS and sent to the App using the Notify() method. If the application received it without a problem Ok is sent back to the LS. Contextual Sensing Layers In this paper the functionality of these contextual sensing layers are not discussed. We recognize the need to have such layers and leave it for future explorations. IV. IMPLEMENTATION We have implemented a prototype system in our research center. Currently we use Active RFID readings, WiFi AP readings and floor sensor reading as the location sensor data. The sensor coverage WiFi AP s and RFID readers cover the whole premises, with the floor sensors covering a small portion (the Smart Space) of the entire coverage area. We fuse RFID Reader data with Floor sensor data to receive high precision location data with identity. In our prototype system each user of the system wears an RFID embedded name card and is given a PDA for interaction with the system. We have explored the usage of the platform in an office environment. Figure 6 shows a user using an application developed on the context aware platform. PDA App LS Subscribe (uid ) Notify(UPI ) Unsubscribe(uID) RFID TAG Figure 6: A User holding the PDA and wearing RFID TAG Currently two context aware applications have been implemented on the PDA. One is a navigator, the screen shots of which are shown in Figure 7. One use of this could be to guide unaccompanied visitors to a specific area in the premises. Figure 5: Continuous location update for tracking 1 Subscribe() method is received from the application(app). If the request has no errors in it the location server (LS) replies with an. 2 The UPI of the given uid is updated with Notify() until the Unsubscribe() is received. Each update is acknowledged with an from App. 3 The Unsubscribe() method is received from the Application when the update is not necessary. When the update is ended is sent to the App. Figure 7: Screenshots of the Navigator The navigator benefits from the different location systems connected to the platform. When the user is located in an area

5 Figure 8: The system in action: from left to right 1) user receive a PDA and a Name card at the receptions 2) User communicates with a another person using VoIP 3) User navigates through the corridors 4) User reach the destination where high density location data is available the Navigator represents the location with high accuracy. The smooth switching between different types of location data is supported with our middleware. The method calling for the location data remains the same in everywhere. Thus development of the Navigator was easy with the API provided from the platform compared to the situation where the platform does not exist. The second application we have developed is a communicator, combining VoIP, IM and functionalities in a single application, and switching between the methods of communication according to users preference and context. Screenshots of this are given in Figure 9. In this system users status is updated according to contextual information automatically. As an example let us consider a situation where a user tries to start a VoIP session with his colleague who is attending a meeting; automatically the user is informed of his colleague s status and IM use is proposed by the system. It is possible to provide employees schedule data to the Contextual Merging Layer through the non-location contextsensing layer. Combining this data with the location data provides a reliable source for deciding user situation. An Application scenario of this system could be described as in figure 8. When a guest visits our lab premises, at the receptions he or she receives a name card and a PDA. Then they can communicate with the person they are supposed to meet. By selecting the destination in the Navigator, the visitor finds their way to the meeting room within the lab premises with the help of the application. If a restricted area or wrong room is entered, the system can inform the user (Figure 7). V. CONCLUSION We have introduced a novel contextual data management platform for context-aware applications and discussed our easily extensible Mapper-based world model. Having developed two applications using the provided API, we have shown that it is possible to use the platform with ease of both use and deployment. We are currently working on privacy support, as well as trying to resolve scalability issues associated with this architecture. REFERENCES [1] M. Weiser. The computer of 21 st century. Scientific American, September 1991 [2] Anind K. Dey and Gregory D. Abowd.. Towards a Better Understanding of Context and Context-Awareness 2000 Conference on Human Factors in Computing Systems (CHI 2000), The Hague, The Netherlands, April 3, Also GVU Technical Report GIT-GVU [3] Oxygen Homepage, [4] HP Cooltown Homepage, [5] Changhao Jiang and Peter Steenkiste "A Hybrid Location Model with a Computable Location Identifier for Ubiquitous Computing"In Proceedings of Ubicomp 2002 [6] G.D. Abowd, et al, The Location Service: A framework for handling multiple location sensing technologies vice.pdf [7] J.Hightower, et al, "The Location Stack: A Layered Model for Location in Ubiquitous Computing," Proceedings of the 4th WMCSA2002. [8] STONE, Figure 9: Screenshots of the Communicator