Testing and demonstrating context aware services can be difficult. Context aware services inherently need information such as the position of their users, but it is complicated to gather and supply services with such kinds of information. Obviously, one needs to do this when the service is up and running, but while developing, or for demonstration purposes, it may help to simulate the context information. Even though the simulated context information is not real, the service and the routines that gather and receive the context information can be. This enables systems to be developed with less regard for constraints that stem from using real sensor technology while still keeping the core functionality of services separate and ready for real-world deployment.
One can image two types of simulation tools: those that simulate a set of values as a part of a test suite, and those that allow you to interactively test services in semi-realistic circumstances. We have chosen that latter approach as it has the added advantage of allowing us to demonstrate services.
QuakeSim is a tool that interactively simulates context information in real time. It simulates the real three dimensional (3D) world and different kinds of context information. With QuakeSim, it is possible to test and demonstrate context aware services without requiring users or objects to actually be in and move around the real world.
Requirements. In order to serve as a development and demonstration tool, we found that the following requirements should be placed on a context simulator.
It should provide a realistic looking simulation of real world environments, complete with people and other complex objects (e.g. buildings, animals, and water).
Multiple users, represented by avatars, should be able to share an environment and interact with each other.
It should be possible to create and equip the simulator with new environments, avatars, and objects.
Tools for building environments, avatars, and objects should be available.
Sensors that register information about for example the position and altitude of individual users should be simulated.
Surveying available tools for implementing a simulator, we found that the 3D game Quake III Arena1 directly provides functionality that meets requirement 1-4. The game engine of Quake is capable of rendering 3D environments with satisfying realism. It allows multiple users to interact in a shared environment via a network, and tools for authoring environments and designing objects and avatars are available for free. Requirement 5, that sensors for registering position and altitude should be simulated, can be achieved by modifying Quake.
An alternative to using Quake III Arena, besides implementing the simulator from scratch, would be to build on for example Web3D2 browsers for VRML (Virtual Reality Modeling Language) and the like. However, our survey showed that such tools generally display less realistic simulations while not providing any more support for simulating sensors than Quake does.
Modifications to Quake. For the purpose of implementing a context simulator, Quake III Arena can be seen as being composed of two main parts: one game engine that renders environments and avatars, and one part that controls how objects should behave within the environment. The game engine is proprietary and not open for modification. The second part however, has been made freely available for modification on a source code level. This allows us to extract information about for example the position and altitude of each user. Information about the speed and bearing of users as well as indications on whether users are swimming or flying can also be extracted. This information can in turn be used to simulate different kinds of sensors.
Context Toolkit. Let us consider a bit further the relationship of sensors, context information, and services.
Sensor information and context information is not the same thing. Sensor information is raw data and as such it is not particularly useful to any service (or human for that matter). It is when the data is interpreted and made available as context information that it suddenly becomes useful. Clearly, data may be interpreted in numerous ways; for example, a temperature reading may be interpreted simply as the temperature of some location. However, if you add to the interpretation an extra layer, for example the significance of an extremely high value, it may be used to indicate the presence of fire.
Furthermore, context information, to be useful, must be accessible to services. It is quite possible that several services will be interested in the same context information. And one service may very well make use of several different pieces of context information. It thus seems like a good idea to streamline the method for services to access context information.
For the purpose of gathering, aggregating, interpreting, and publishing sensor and context information we therefore use the Context Toolkit . The Context Toolkit models each piece of sensor information as a “widget” that encapsulates sensor specific details of gathering the information, and provides a common interface towards services that make use of the information. A widget also provides functions for communication with clients, updating of sensor data, polling of data, subscription to state changes, etc. In effect, the Context Toolkit serves as an abstraction and interpretation layer between sensors and services and can thus provide context information.
In QuakeSim we have encapsulated the modified version of Quake as a sensor in a Context Toolkit widget (see b in Figure 1). A client can therefore connect to the widget and through the widget’s API make use of the data that Quake provides. It is also possible to interpret the data provided by Quake in a number of different ways. Similarly to the temperature example above, a location value may be interpreted simply as a location but also as signifying presence in a certain room (mimicking an IR-beacon) by correlating the location to a floor plan with coordinates for all the rooms.
The Context Toolkit also makes it possible to combine real and simulated sensors. One of our first applications of the simulator was to demonstrate and test a service in a family context. The home of the family was easily modeled in a room equipped with actual sensors and actuators (e.g. a door lock). The outdoor context of the family, such as the children’s playground, was more difficult to model. We therefore simulated it as a world in QuakeSim. The actual application that was demonstrated used input and generated output to the real sensors and actuators, as well as to the simulated ones.
One of the most interesting pieces of context information, and also one of the most readily available using current technologies, is the user’s location. A person’s location may be deduced by any number of means: a personal Global Positioning System (GPS) device, network based Global System for Mobile Communications (GSM) positioning, infrared beacons, radio receivers, etc.
In the GeoNotes  system users annotate their present location with virtual Post-It™-like notes. For example, to post a note in GeoNotes, a user enters the note text and his or her name or alias. The service then associates the note with the user’s present location in physical space. As another user passes this physical location (perhaps at a later time), the system retrieves and presents the note to the other user.
To test GeoNotes, we configured it to receive its positioning data from QuakeSim via a Context Toolkit widget (see b in Figure 1). To receive data from a real position data source the QuakeSim widget can be transparently replaced by a widget representing the real sensor (see d in Figure 1). The Context Toolkit Server (see e in Figure 1) enables us to aggregate several sources of sensory information. The GeoNotes system (see c in Figure 1) implements a generic interface for acquiring position information which makes it easy to switch from one data source to another.
Figure 2 and Figure 3 illustrate the use of QuakeSim and GeoNotes in conjunction. The location of the user is simulated by QuakeSim (Figure 3) and fed to the GeoNotes service. In this example, the user is presented with a selection of three notes (Figure 2) that have been placed in the introduction room of the first Quake III Arena game level.
The GeoNotes example illustrates the usefulness of QuakeSim; with QuakeSim we were able to test and demonstrate the GeoNotes system from a desktop PC in our office. For usability testing, and for full-scale system tests, it is obviously necessary to use the real system deployed in its real setting. However, for demonstration purposes, and for small scale testing during the development process, QuakeSim serves its purpose well.
 A. K. Dey and G. D. Abowd, “The Context Toolkit: Aiding the Development of Context-Aware Applications,” presented at Workshop on Software Engineering for Wearable and Pervasive Computing, Limerick, Ireland, 2000.
 F. Espinoza, P. Persson, A. Sandin, H. Nyström, E. Cacciatore, and M. Bylund, “GeoNotes: Social Filtering of Position-Based Information,” presented at Ubicomp'2001 (formerly Handheld and Ubiquitous Computing - HUC), Atlanta, GA, 2001.