From Home to World - Supporting Context-aware Applications through World Models

Othmar Lehmann Georgia Institute of Technology USA [email protected] Abstract

In the vision of pervasive computing smart everyday objects communicate and cooperate to provide services and information to users. Interoperability between devices and applications not only requires common protocols but also common context management. In this paper we discuss requirements on the context management based on the Georgia Techs Aware Home environment and the global context management perspective of the Nexus project. Our experiences with integrating the Aware Home Spatial Service into the Nexus platform show how federation concepts and a common context model can provide applications with uniform context information in different administrative and application domains.

Martin Bauer, Christian Becker, Daniela Nicklas Universitt Stuttgart Germany bauer|becker|[email protected]
platform where applications can seamlessly share their context. Two approaches for such platforms are presented. One addresses the context management in the scope of a smart home environment based on the Georgia Tech's Aware Home project [2] while the other approach addresses global context management from the perspective of the Nexus project [8]. We have integrated both approaches and discuss our experiences regarding the context representation. Crucial to the integration of both approaches is a common context model and a federation concept for the local context management. The paper is structured as follows. In Section 2 we motivate the requirements on context management to achieve interoperability based on typical applications in a smart home environment. In Section 3 the related work is presented. In Section 4 and Section 5, we describe the context management for the Aware Home and the Nexus platform. An assessment of context modeling and the platform integration is given in Section 6 based on the integration of the Aware Home Spatial Service into the Nexus platform. In Section 7 we close with a summary and outline future work.

1. Introduction
Pervasive computing has drawn increasing attention of researchers in the past years. As a result, a multitude of applications has been developed. These applications cover different domains, such as tourist guides [1][2], indoor information systems [3][4] and smart environments, e.g. the Georgia Tech Aware Home [5], to name a few. A variety of supporting infrastructures have been proposed, which facilitate the development of applications. However, these infrastructures mostly address a distinct application domain, such as context processing based on sensors [6] or providing application-specic context [7][1]. However, one cannot deploy any of the above-mentioned applications and expect them to cooperate or share resources. Also, when new services, hardware or environmental information such as maps become available to an application, other existing applications can not automatically use them. Interaction between different applications based on their context, e.g. identity, location, or state, is not possible if they do not rely on a common representation of this context. In this paper we discuss the requirements on application-independent context management in order to provide a

2. Requirements
In this section we derive requirements based on a scenario and discuss what follows from that for context modeling.

2.1.

Scenario

Consider the following scenario: You have a home that can sense what its inhabitants are doing, adapt to them and support them with their task; e.g. the Smart Intercom allows you to reach every other person in the house regardless of where he or she is located. So if you are in the basement, it is possible to say House, I want to talk to Thomas. The house then would localize Thomas, check if it is currently acceptable to contact him or if he is occupied otherwise, and then create an audio connection to him

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

using the closest available audio interface device. This could be the phone on his desk or the speakers and microphones in the room. Now you want to add another application to your home: A smart doorbell. Depending on whom a visitor is here to see, the Smart Bell nds the respective person and noties her that a visitor is waiting at the door. Then it routes a video feed from the entrance area to the wall display closest to that position. Now you can decide whether the visitor should be let in. It is also possible to identify the visitor and to register him with the intercom system and other systems of the house. Also, you want to add a smart alarm system. Because the house knows the identities and the locations of its inhabitants, it can continuously monitor whether unauthorized persons are in the house and notify the authorities accordingly. Then it would provide the authorities with information about the situation within your house e.g. the layout of the house, where the inhabitants and where the intruders are located. In the remainder of this section, we discuss requirements for the data model of these applications and for the infrastructure that supports them.

Consistency: The information about people, house and resources, e.g. as gathered through sensor systems in the infrastructure, has to be maintained and kept consistent among all applications. If real world objects or resources are moved or removed, the information in the infrastructure has to be updated. Abstraction from Resources: The variety of possible information sources and services, such as sensors, actuators, and user interfaces, should be transparent to applications. A layer of abstraction should be provided to facilitate the easy change of resources, such as upgrading a positioning system. Newly integrated resources should be made available to applications. Interoperability: One of the main requirements for the infrastructure is interoperability in three dimensions. First, interoperability between resources, e.g. the audio speakers should be able to work with the TV to display the video feed of the Smart Doorbell. Secondly, applications that communicate using information or resources: e.g. the Smart Doorbell inserts a new person into the house and the Smart Intercom should be able to use this information. Thirdly, the interoperability between applications: e.g. the Smart Doorbell noties the Smart Intercom that it has to use the audio speakers to signal into the room.

2.2.

Derived requirements 2.3. Context modeling

The information model as discussed in Section 2.2 is concerned with context data. A number of different denitions for context exist, e.g. [9][10]. Our view on context is similar to the denition presented in [10]: Context is the information which can be used to characterize the situation of an entity. Entities are people, locations, or objects which are considered to be relevant for the behavior of an application. The entity itself is regarded as part of its context. When context is stored in a context model it is necessary that applications can access it. As the examples have shown, applications typically consider information about a distinct location or an entity, e.g. a user or object. Hence, such a model must allow for access to context information based on location and the identity of objects. Additionally, context models can incorporate the time dimension, i.e. capture history or provide a prognosis. In general, a combination of either identity and time or location and time is needed to access context information in a meaningful way. However, time can also be dened implicitly as the current point in time. Based on the selection of objects via identity, location, and time further information, such as the activity of a user or the state of an object, can be derived. Using location as index imposes new challenges on the representation of the index and its processing. The underlying spatial structure has to be reected in the index. A variety of different location models exist, which can

Based on the scenario we derive requirements regarding the information model, information access, consistency, the abstraction from resources, and interoperability. Information Model: The applications in the scenario need certain information to fulll their tasks. Mobile objects, such as users with their identity and position, and stationary objects, such as furniture or input/output devices, are relevant for context-aware applications. These objects have to be managed with respect to their spatial environment, e.g. the oor plan of a smart house or the layout of a city center. Additional attributes of these objects, such as user preferences or a functionality description, can be used by applications. The information model should be easily extensible, since new applications are likely to require additional or specialized objects. Information Access: Applications access the information in the information model through queries, predicates, and functions operating on the information model. Queries are used to access objects via their identity or their current location, e.g. a range or a neighborhood. The interpretation of a range or a neighborhood requires spatial knowledge which has to be provided by the underlying information model. Spatial predicates are constantly evaluated and signal distinct correlations between mobile and stationary objects to an application, e.g. a user entering a room or a certain user meeting another user. Applications can modify information in the information model via updates.

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

be classied as topographical, topological, or hybrid models. Topographical models use geometry to model space. They model the spatial entities as geometric shapes that are placed within a coordinate system. The relations between the entities, e.g. which entities are next to each other, are implicitly dened by their location. Topological models describe the relations between spatial objects explicitly without localizing them in a coordinate system. Hybrid models combine the localization of the spatial entities within a coordinate system with the explicit modeling of their relations. The complexity of the models differs widely, e.g. regarding the level of detail and the available functionality. Common tasks are querying for objects within a distinct area as well as determining the nearest object with respect to a given position. Hence, the context model requires a spatial structure. Since our context models take the spatial structure of the real world as their basis, we also call them world models.

3. Related work
Context-aware applications have attracted the interest of researchers over the past years. A number of different applications have been developed exploring different application domains. Tourist guides, e.g. Guide [1] or CyBARguide [2], provide information to mobile users about typically stationary objects in their vicinity, such as distinct sights. Indoor information systems, e.g. Cyberguide [2], ETH World [11], or conference room reservation [4], provide similar services in the indoor domain. Another class of pervasive computing applications presents location-dependent information to users. Virtual Information Towers [12] provide information for a distinct area through posters, while Stick E-Notes [13] and GeoNotes [14] offer a Post-It metaphor allowing users to leave messages at a distinct location. These systems typically are not concerned with the relations between different mobile objects, e.g. users, and they only require simple spatial models. Abstraction from resources is typically not necessary, since the information is not captured via sensors and actuators are not supported. Interoperability is typically not an issue in such systems. For another class of applications, an underlying spatial model is required. The Teleporting project [15] requires a spatial model in order to redirect output to the devices that are closest to users. Similar to that, the Family Intercom [16] also requires spatial knowledge. While the Family Intercom does not intend to share its spatial model, the Teleporting project has developed a platform which provides a data model linked to locations obtained via negrained location and spatial monitoring systems. This platform already meets some of our requirements, but its scalability is targeted at larger buildings. There is no given

structure of data objects though, leading to reduced interoperability. The Context Information Service (CIS [17]) of the Aura project [18] also aims at providing context information. The underlying location model is based on a mapping onto geometric coordinates [19] thus not allowing purely symbolic coordinates. The information model is targeted at technical information of the network and its entities, such as printers or bandwidth, and reects their properties via meta data. The location of people is also provided. This centralized architecture is limited to building size scalability although caching techniques provide improved performance. Other kinds of infrastructure are targeted at distinct domains. The Context Toolkit [6] provides abstractions to integrate various sensor devices and facilitates sensor fusion. Guide [1] also provides an infrastructure which enables classes of applications from the navigation or outdoor domain to rely on an extensible data model. However, the location model is cell-based and depends on the communication infrastructure. Most of the above-mentioned approaches do not allow for exible integration of different spatial models. Such spatial information is represented by location models, reects application requirements, and depends on the modeled environment [20]. Easy Living [21] is targeted at the indoor domain and provides an infrastructure for spatial access to information similar to QoSDream [22]. Abstractions of hardware providing context information or a common data model are not addressed by either approach. As we have seen, there are a variety of different approaches which address some of the requirements derived in Section 2. A comprehensive solution is still missing. In particular, the scalability of the infrastructure and interoperability of applications are still open research questions. The answers to these questions are crucial to provide users with applications which operate in varying environments.

4. AHSS - A local architecture

We have designed and implemented a context management infrastructure, the Aware Home Spatial Service (AHSS), at the Georgia Tech Aware Home, based on the requirements presented in Section 2 and the feedback from the developers at the Aware Home. One of their main requirements for developing applications was exibility. As their research environment is very dynamic, they did not want to be obstructed by too inexible frameworks and standards, preferring direct interaction and agreement between developers instead. Scalability, on the other hand, is not such a big issue for prototype applications in the Aware Home. Therefore, the Aware Home Spatial Service

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

Figure 1. AHSS conceptual view is targeted at small to mid-size smart home environments. The intelligence in such settings is usually not concentrated in mobile devices like PDAs, cellular phones or wearable computers. It is typically in stationary systems in the house that serve the area of the house. In the smart home we are considering, a variety of platforms are in use. The main language for most systems in our setting is Java. Some application areas like computer vision necessitate the use of other languages like C or C++. fact be very far apart. Also, locations are organized within levels of detail (LOD) that structure the spatial model hierarchically. This is important because not every application needs to deal with the model on the same level of detail. One application might only need the coordinates of a house, while another application might need more detailed information, e.g. the layout of the rooms in the house. Figure 2 illustrates this. On every Location, it is possible to generalize (get the equivalent Location on a lower LOD) or specialize (get the gateway Location on a higher LOD). For example, generalizing the kitchen would yield the rst oor, specializing the rst oor could yield the staircase.

4.1.

Spatial model

The AHSS spatial model denes and implements a standardized way to model context information structured along the dimension of space. This spatial model is topological, similar to the one proposed in [20] that we have adapted and extended by topographic aspects. As shown in Figure 1, the spatial model represents context information from the real world. All applications can use the same spatial model. The model consists of a graph, with locations as vertices and relations as edges. Locations describe relevant spatial objects, rooms, furniture or even people. An AHSS Location has an ID that is unique within the spatial model, a type that is associated with it, some standard attributes and an optional spatial attribute. This spatial attribute can be a point, a line, a polygon or any other geometry type specied in the OpenGIS standard [23]. It represents the topographic aspect of the model. For example, it is possible to attach the shape of a room (i.e. its geometry) to the Location representing it. Spatial attributes provide a variety of spatial operations like union, intersection etc. Furthermore, Locations are extensible. Applications can add arbitrary attributes with application-specic semantics. Locations are connected by relations, to allow modeling of explicit spatial relations. They have a type and a weight that can be used to model distances that are not geometric: two rooms might be very close from a geometric point of view, but if there is a wall between them, or a door that can only be used in case of an emergency, they may in

4.2.

System architecture

If multiple applications are concurrently using the same spatial model, the model has to be kept consistent among those applications. The AHSS uses a centralized approach to accomplish this the Spatial Server, that stores the current spatial model (see Figure 3). This centralization allows us to keep the architecture of the system

Figure 2. Levels of detail in the AHSS spatial model

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

Figure 3. Architecture of the AHSS relatively simple. However, it should be noted that a centralized design is not required by our spatial model. Sharing and consistency of our model could also be provided by a distributed infrastructure. The spatial server has to store a potentially large amount of information that has a spatial component in a persistent way. Instead of implementing a proprietary data storage, we rely on a database system. As we have seen in Section 2.3, the information we are dealing with is structured by space. Therefore, the AHSS spatial server uses a spatially-enabled database. This allows us to model the spatial components of our data much more naturally. It also improves query performance because many spatial data-

bases support spatial indexing. There is a variety of commercial spatially-enabled databases available (e.g. IBMs Spatial Extender for DB2 or Oracle Locator), but those products tend to have a large footprint and are generally expensive. We decided to use the open source database PostGIS [24], a spatially enabled version of PostgreSQL. The communication between the spatial server and its clients utilizes IIOP. This allows Java clients the access via RMI/IIOP, while other clients, e.g. written in C++, can use CORBA. Using RMI-IIOP callbacks, the infrastructure also offers an event concept. Applications can dene events on locations in the spatial model. Other applications can then subscribe to those events, and get notied when the events are triggered.

4.3.

Experiences

The Aware Home Spatial Service provides a simple infrastructure to model context information that is structured along the dimension of space. It allows us to store spatial information in a central infrastructure and to reuse it across multiple applications. Applications can exchange information through the spatial model and they can notify each other using events. As shown in Table 1 AHSS meets our requirements as they were introduced in Section 2.

Table 1. Requirements Requirement Information Model Information Access Consistency Realization Support for location and identity as indexes allows queries for stationary and mobile objects based on the spatial layout of the smart home. The spatial layout of the AHSS allows the calculation of spatial relations, e.g. the distance between two objects. Querying and updating of information is supported by the database. The centralized architecture of the AHSS provides a consistent view on the modeled information. Since applications only rely on the information stored in the AHSS the information source, e.g. a sensor device or a fusion of sensor data, as provided by the Context Toolkit [6], is shielded from the information consumer. Resource discovery is automatically provided by processing queries on the database which is constantly updated. Applications sharing information stored in the AHSS rely on the same information model and thus become interoperable. However, the AHSS does not define any interoperability protocol between applications themselves. However, the AHSS is a suitable platform for local context management. In the next section we discuss a global context management architecture. A common context model allows the integration of different local context models into a federated, global context management platform. In Section 6 we show how AHSS can be integrated into such a global context model.

Abstraction from Resources

Interoperability

Although all of our requirements are met, there are some issues worth noting. The AHSS does not rely on an explicit model of the context information that is managed. Different instances of an AHSS, as they can occur in different administrative settings, will therefore not automatically become interoperable. Hence, the interoperability of application gets restricted to a distinct information model of the underlying AHSS.

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

Figure 4. Augmented areas

5. Nexus - A global architecture

If we want to extend the scope of interoperable, context-aware applications beyond a closed environment like a single home, we need a common context model that is suitable for a wide range of context-aware applications. To achieve this goal, we need to address two major challenges: modeling standards (how can A understand what B models) and infrastructure (how can such a huge model be managed efciently). Since no single person or corporation will model the entire world in detail, our approach in the Nexus project at the University of Stuttgart is to investigate how contextaware applications can be supported by the federation of local context models. Hence, the infrastructure should allow for the integration of context models from different providers. The federation of different context models from a variety of providers requires a common information model which states the type and structure of information objects as well as the access to the objects, i.e. a unied model of object identities and the location model. For the Nexus platform, the information model is called Augmented World Model. The Augmented World Model is a global object-based ontology that denes how context information can be shared between applications and data providers. It contains real world objects like rooms, sensors, streets or persons as well as virtual objects like Virtual Information Towers (VIT) [12] or virtual PostIts [13] that are used to represent digital information in the world. The Augmented World Model is not stored explicitly. Instead, it is a federated, global view on all compliant local context models. Those local models are called augmented areas (AA) (see Figure 4). An AA has a certain extent that describes the geographical area in which its objects reside. There is no restriction on the size or the number of objects an AA can host. AAs can overlap or model the same real world entity. The Augmented World Model is the federated, global view on all Augmented

Areas. An application does not need to know from which AA the context information comes, and it can use data that is combined from different AAs. This federation is only possible because the AAs rely on a common data schema called the Standard Class Schema (SCS). The SCS denes the types and attributes of objects of the Augmented World. These are ordered in a hierarchical is-a relationship (inheritance). In Figure 5, you can see an excerpt from the top levels of the SCS: dataobject is the root that denes a unique object identier and locator for each object called the Nexus Object Locator (NOL). Objects of the type spatialobject all have a geographical position and optionally an extent. Because the spatial context is our primary index and therefore is crucial to performance, we distinguish between static and mobile objects. While static objects seldom change their location and therefore can be managed in a single AA, mobile objects move around and cross the borders of AAs which leads to handovers. In total, the SCS denes about 250 classes or types for context-aware data objects. We have designed that model by doing a use case analysis on different applications [25]. An AA provides the attribute, the type and the

Figure 5. Excerpt from the top part of the Standard Class Schema

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

federation tier integrates the AAs and supports value added services on the Augmented World Model. Applications are located in the application tier and use the services of the federation. 5.1.1. Spatial model servers. Spatial Model Servers (SpaSes) host Augmented Areas. Objects are modeled in AWML (Augmented World Modeling Language) and queried using a simple spatial query language called AWQL (Augmented World Query Language), which is used to specify the objects of interest and to lter the attributes. AWQL supports spatial predicates (overlaps, inside) and nearest neighbor queries as well as data manipulation (insert, update, delete). AWML and AWQL are both XML languages. Note that AWQL is not an XML query language like XQuery AWQL is suitable for spatial objects, not for hierarchical XML documents. Depending on what kind of context information a SpaSe provides, the implementation of the spatial server which processes the AWQL/AWML can differ to a large degree. For static objects and large-scale spatial models, we use a full-grown database with a spatial extension (IBM DB2 7.1 + Spatial Extender). AWQL can be easily transformed to SQL by an XSLT style sheet. Mobile objects are managed by the Location Service [26]. Because position data is highly dynamic and does not need to be persistent, main memory data structures are better suited for this task. The Location Service consists of hierarchically structured servers that manage objects within a certain area. When the object moves out of this area, handovers are performed. 5.1.2. Nexus nodes. The Nexus nodes in Figure 7 mediate between Nexus applications and Nexus services. They are responsible for distributing queries to different data providers and for composing the results, thus providing the Augmented World Model for the applications. The

Figure 6. Standard and extended class schemas meaning of the attributes of its objects. To provide extensibility, any data provider can dene an Extended Class Schema (ECS). The classes of the ECS are derived from appropriate classes of the SCS. For example, if somebody wants to integrate LivingRoom objects into an AA, then she can extend the SCS type Room with the necessary additional attributes (see Figure 6). An advanced LivingRoom application can now access this information, whereas normal applications knowing only the SCS could treat the object as its parent class Room.

5.1.

Platform architecture

As we have seen, a global context model like the Augmented World Model is feasible if independent providers can build their local models based on a exible standard and make them available to a federation that integrates all local models into a global view. Now we will describe an open infrastructure that is able to manage the Nexus Augmented World Model. As depicted in Figure 7, the Nexus Platform is built in three tiers: the service tier contains data and service providers for Augmented Area models. The

Figure 7. Architecture of the Nexus platform

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

nodes do not store persistent data, a fact that allows replicating them for load balancing. For query distribution and service discovery, a Nexus node uses the Area Service Register (ASR). This service is a directory of the available augmented areas and stores the address of the server, the available object types and the extent to the AA. The Nexus node computes the targeted region and the object types of the application query and queries the ASR to nd out which Spatial Model Servers cover the requested region and store objects of the requested types. Then the node distributes the query to the relevant data providers named by the ASR and merges their results. More details about the federation tier can be found in [27]. 5.1.3. Value added services. In addition to the query functionality, every Nexus node supports valueadded services. They use the federated context model to implement advanced services and have their own interface. In Figure 7, you can see three different value-added services of the Nexus platform: the event service monitors spatial events, combining basic events into more complex events. This allows the processing of spatial predicates, such as two of my friends meet. The map service provides maps based on a selected area and the navigation service provides a navigation route from a starting point to an endpoint. 5.1.4. The NexusScout application. In this section we briey describe NexusScout, a location-based application that runs on the Nexus platform. It is based on the Virtual Information Tower application [12]. We have added several advanced functionalities that show the power of the platform and are useful for mobile, context-aware applications. NexusScout runs on a notebook and we have also just ported it to a PDA. It uses WLAN for wireless communication. Outdoor positioning is done via GPS, while indoor positioning uses infrared beacons. The NexusScout provides maps to users showing their position. Virtual Information Towers (VIT) provide information (web pages) that is relevant at the given location. Based on the Nexus Augmented World Model nearestneighbor queries for objects, e.g. restaurants, are possible. The integration of the navigation and map services allows to use the Neuxs as navigation system as well as register spatial predicates, e.g. notify me when my colleague enters the building.

Figure 8. Screenshot of the NexusScout develop and evaluate prototype applications, and where developers can easily interact and agree on the modeling. However, if we have applications for which the context is to be shared over larger areas and possibly multiple administrative domains, e.g. multiple aware homes, the AHSS is no longer sufcient, as it does not provide the necessary scalability and agreements between developers on how the world should be modeled. Our approach to mitigate this problem is to integrate AHSS into our Augmented World Model.

6.1.

Conceptual integration

We decided to integrate AHSS into Nexus as a spatial server. This way, an area which is served by AHSS appears to be an Augmented Area to the Nexus federation. The major challenge is to integrate the concepts of Nexus and AHSS. The integration does not have to be complete: While AHSS needs to support all the concepts of Nexus in order to function as part of an Nexus federation, the reverse is not necessary. In our approach, we map Nexus objects to AHSS Locations. Basic attributes of Nexus attributes like the object id and the type are mapped to their AHSS counterparts. Nexus attributes that have no standardized AHSS counterpart are mapped to extended AHSS attributes. We are now going to describe the changes we have made to AHSS in order to integrate it into Nexus.

6.2.

Technical integration

6. AHSS in Nexus
As we have seen in Section 4.3, a local context model like AHSS is suitable for small- to mid-size home environments, where exibility is very important to quickly

To work as part of a federation, the AHSS spatial server has to perform several tasks. First, it needs to register with the Nexus Area Service Register to give the federation the information it needs to dispatch the queries. It has to specify which area the spatial server covers, and which

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

Area Service Register Nexus Application

registers

Java application AHSS client library RMI-IIOP IIOP IIOP AHSS Spatial Server SQL C++ application CORBA

Nexus Node query Nexus Spatial Model Server Nexus

query AWQL interface

CS interpreter

Spatially enabled Database AHSS

Figure 9. The extended AHSS architecture AHSS interfaces are still available, so local applications Nexus object types it provides. The Nexus federation quecan access AHSS either through the local interfaces or ries the spatial servers by using AWQL. Thus we had to through the Nexus AWQL interface. implement an AWQL interface to Nexus which processes This approach makes it possible to use simple, specialthe query and update operations against the AHSS data. ized infrastructures to support local applications, while Also, the Nexus Federation expects the replies in AWML using the Nexus federation to support greater scalability format. Therefore the AWQL interface has to map the needs. The context model of each specialized infrastructure AHSS Locations to Nexus objects, and then has to serialize has to support topographic modeling and has to be exible them into AWML. AWQL queries specify the class scheenough to store the attributes which are required by Nexus. mata the client understands. The replies have to contain only objects that conform to these class schemata. Also, if a Nexus client queries e.g. for BuildingElements, objects 7. Conclusion and future work of descendants of BuildingElement that match the query In this paper we have shown that shared context modhave to be returned. So it is necessary for AHSS to know els are a suitable basis for building context-aware applicathe Augmented World Model (AWM), the Standard Class tions that operate in the same environment and rely on the Schema plus appropriate Extended Class Schemas, which same context information. We have presented the Aware are both modeled in XML. We have therefore added an Home Spatial Service (AHSS) that was designed for a sinAWM interpreter which reads the appropriate AWM specigle smart home environment. For context management on ed in the query. It then handles the AWM inheritance a global scale, we have developed the Nexus platform that hierarchy issues of the query and strips the resulting AHSS federates different context models based on a common Locations of all attributes which are not part of the class standard for modeling objects and a topographic modeling schema. If a Nexus application is interested in getting all of space. Finally, we have shown how an existing local the spatial objects with all their attributes from the infrastructure, it can specify that the results should conform to spatial model like AHSS can be integrated into the Nexus the Generic class schema. Then all AHSS Location platform. attributes are returned. Figure 9 gives an overview of the The current version of the extensible Nexus standard necessary changes to the AHSS architecture. class schema is only the rst step towards dening a common standard for context models in general. The integration of further application models currently used in smart 6.3. Experiences environments will lead to a better understanding of world The integration of AHSS into the Nexus federation models and how to build them. To support further classes provides various advantages. First of all, AHSS becomes of applications we have to go beyond modeling sensor part of the Nexus federated world model. Nexus applicainformation as model data and integrate hardware abstractions can then use context information that is stored within tions and discovery mechanisms into our model, e.g. prothe AHSS. This makes it possible to use existing Nexus vide access to standardized interfaces for complex applications with the AHSS. For example, the NexusScout actuators and sensors like cameras. So far the Nexus platcan use AHSS without any modications. Also, Nexus form has focused on providing efcient and scalable access applications can store their context information into the to two dimensional topographical world models. In the AHSS. This information can further enrich the context future, we will investigate complex three dimensional model which AHSS applications can access. The local models and also full-edged support for topological mod-

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE

els. Federating different models modeling the same real world objects ensures internal consistency of the model information. Consistency between the model and the real world is also an important focus of our future research. For a more widespread use of world models in smart environments tools for creating such models have to be developed. Having larger smart environments allows more useful evaluations in real world situations. We plan to investigate security, privacy and acceptability issues in such settings.

Acknowledgements
We would like to thank Gregory Abowd for supervising the Aware Home Spatial Service Project. The Nexus project was funded 1999-2002 by the German Research Association (DFG) the under grant 200989 and is now continued as Center of Excellence (SFB) 627.

8. References
[1] Cheverst,K., Davies, N., Mitchell, K.,Friday, A., Efstratiou, C.: Developing a Context-aware Electronic Tourist Guide: Some Issues and Experiences. Proc. of CHI 2000, Netherlands (2000) [2] Abowd, G., Atkeson, C., Hong, J., Long, S., Kooper, R., Pinkerton, M.: Cyberguide: A mobile context-aware tour guide. Wireless Networks 3(5) (1997) 421-433 [3] Cooltown, <http://www.cooltown.com/cooltownhome/ index.asp> [4] Conner, W.S., Krishnamurthy, L., Want, R.: Making Everyday Life Easier Using Dense Sensor Networks. Proc. of UBICOMP 2001, Atlanta, USA (2001) [5] Kidd,C., Orr, R., Abowd, G., Atkeson, C., Essa, I., MacIntyre,B., Mynatt, E.,Starner, T., Newstetter, W.: The Aware Home: A Living Laboratory for Ubiquitous Computing Research. Proc. of 2nd International Workshop on Cooperative Buildings CoBuild (1999) [6] Salber, D., Dey, A., Abowd, G.: The Context Toolkit: Aiding the Development of Context-Enabled Applications. Proceedings of CHI (1999) [7] Schmidt, A., Takaluoma, A., Mntyjrvi, J.: Context-aware telephony over WAP. In: Personal Techonlogies 4 (4) (2000) 225229 [8] Hohl, F., Kubach, U., Leonhardi, A., Rothermel, K., Schwehm, M.: Next Century Challenges: Nexus - An Open Global Infrastructure for Spatial-Aware Applications, Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom99), Seattle, Washington, ACM Press, 1999 [9] Chen, G., Kotz, D.: A Survey of Context-Aware Mobile Computing Research. Dartmouth Computer Science Technical Report TR2000-381, Dartmouth College (2000) [10] Dey, A., Abowd, G.: Towards a better understanding of context and context-awareness. Georgia Tech GVU Technical Report, GIT-GVU-99-22 (1999) [11] ETH World, <http://www.ethworld.ethz.ch>

[12] Leonhardi, A., Kubach, U., Rothermel, K.: Virtual Information Towers - A metaphor for intuitive, location-aware information access in a mobile environment. Proc. of third International Symposium on Wearable Computers, San Francisco, CA (1999) 15-20 [13] Pascoe, J.: The Stick-e note architecture: Extending the interface beyond the user. Proceedings of the 1997 International Conference on Intelligent User Interfaces (1997) 261-264 [14] Espinoza, F., Person, P., Sandin, A., Nystrm, H., Cacciatore, E., Bylund, M.: GeoNotes: Social and Navigational Aspects. Proc. of UBICOMP 2001, Atlanta, USA (2001) [15] Harter, A., Hopper, A., Steggles, P., Ward, A., Webster, P.: The anatomy of a context-aware application. Proc. of fifth annual International Conference on Mobile Computing and Networking, Seattle, WA, ACM Press (1999) 59-68 [16] Nagel, K., Kidd, C. D., O'Connell, T., Dey, A., Abowd, G. D.: The Family Intercom: Developing a Context-Aware Audio Communication System (pdf) G. D. Abowd, B. Brumitt, S. A. N. Shafer (Eds): Ubicomp 2001, LNCS 2201, Springer-Verlag Berlin Heidelberg (2001), 176-183 [17] Judd, G., Steenkiste, P.: Providing Contextual Information to Pervasive Computing Applications, IEEE PerCom, Fort Worth (2003) [18] Garlan, D., Siewiorek, D., Smailagic, A., Steenkiste, P.: Project Aura: Towards Distraction-Free Pervasive Computing. IEEE Pervasive Computing, special issue on Integrated Pervasive Computing Environments, Volume 1, Number 2, (AprJun 2002) 22-31 [19] Jiang,C., Steenkiste, P.: A Hybrid Location Model with a Computable Location Identifier for Ubiquitous Computing. Proc. of UBICOMP 2002, Goteborg, Sweden (2002) [20] Bauer, M., Becker, C., Rothermel, K.: Location Models from the Perspective of Context-Aware Applications and Mobile Ad Hoc Networks. Personal and Ubiquitous Computing. Vol. 6(5-6). S. 322-328, London: Springer-Verlag (2002) [21] Brumitt, B., Meyers, B., Krumm, J., Kern, A., Shafer, S.: EasyLiving: Technologies for Intelligent Environments. Handheld and Ubiquitous Computing (Sept 2000) [22] Naguib, H., Coulouris, G.: Location Information Managment. Proc. of UBICOMP 2001, Atlanta, USA (2001) [23] Open GIS Consortium Inc.: OpenGIS Simple Features Specification for SQL, <http://www.opengis.org/techno/specs/99049.pdf> [24] PostGIS, <http://postgis.refractions.net> [25] Nicklas, D., Mitschang, B.: The Nexus Augmented World Model: An Extensible Approach for Mobile, Spatially-Aware Applications. Proc. of the 7th Int. Conf. on Object-Oriented Information Systems (2001) [26] Leonhardi, A., Rothermel, K.: Architecture of a Large-scale Location Service. Proc. of the 22nd Int. Conf. on Distributed Computing Systems (ICDCS 2002), Vienna, Austria (2002) 465466 [27] Nicklas, D., Gromann, M., Schwarz, T., Volz, S., Mitschang, B.: A Model-Based, Open Architecture for Mobile, Spatially Aware Applications. Proc. of Symp. on Spatial and Temporal Databases, Los Angeles (2001)

Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM04) 0-7695-2090-1/04 $ 20.00 2004 IEEE