(Size: 823.5 KB / Downloads: 17)
Rover technology adds a user's location to other dimensions of system awareness, such as time, user preferences, and client device capabilities. The software architecture of Rover systems is designed to scale to large user populations.
Consider a group touring the museums in Washington, D.C. The group arrives at a registration point, where each person receives a handheld device with audio, video, and wireless communication capabilities. an off-the-shelf PDA available in the market today. A wireless-based system tracks the location of these devices and presents relevant information about displayed objects as the user moves through the museum. Users can query their devices for maps and optimal routes to objects of interest. They can also use the devices to reserve and purchase tickets to museum events later in the day. The group leader can send messages to coordinate group activities.
Rover technology tracks the location of system users and dynamically configures application-level information to different link-layer technologies and client-device capabilities. A Rover system represents a single domain of administrative control, managed and moderated by a Rover controller. Figure 1_ shows a large application domain partitioned into multiple administrative domains, each with its own Rover system - much like the Internet's Domain Name System" 2
Rover offers two kinds of services to its users' basic data services and transactional services.
Basic data services use text, graphics, audio, and video formats. Users can subscribe dynamically to specific data components through the device user interface. Rover filters the available media formats according to the device's capabilities. The basic data service involves primarily one-way interaction.
Transactional services have commit semantics that require coordinating state between the clients and Rover servers. E-commerce interactions are examples of this service class.
Location is an important attribute of all objects in Rover. Several techniques exist for estimating an object's location, including the GPS and radio-frequency techniques based on signal strength or signal propagation delays. The choice of technique significantly affects the granularity and accuracy of the location information. Rover therefore uses a tuple of value, error, and time stamp to identify an object's location1. The value is an estimate of the object's location (either absolute or relative to some well-known location). The error identifies the uncertainty in the estimate. The time stamp identifies when the estimate was made.
The accuracy required of location information depends on the context of its use. For example, an accuracy of 4 meters is adequate to provide walking directions from the user's current location to another location about 500 meters away. However, it is inadequate for locating a particular painting on a museum wall directly in front of the user. Obviously, the accuracy of location information improves significantly with direct user input. For example, the user can directly input a location on a map displayed on his or her device.
Rover includes support for operations to filter, zoom, and translate map display. Filter operations are keyed to a set of attributes that identify certain properties of map objects. Rover generates the filters based on the user's context. The filters select and map the appropriate object subset for display. For example, one user may be interested only in the restaurants in a specific area, while another wants to view only museum and exhibition locations.
Two potential bottlenecks can hinder the system's scalability. One is the server system, which must handle a large number of client requests with tight real-time constraints. The other is the wireless access points, which have limited bandwidth.
To handle the large volume of real-time requests that users generated, we developed the action model, a fine-grained, real-time, application-specific architecture that allows Rover systems to scale to large user populations. To make its implementation more efficient, we divided the Rover server components into two classes based on the user request volumes they handle:
Primary servers the Rover controller, location server, and streaming media unit which communicate with the clients directly and therefore handle large volumes of user requests, and
Secondary servers the Rover database and logger which communicate only with primary servers to provide back-end system capabilities.
Actions versus threads
There are several ways to implement the Rover controller using a thread model. For example, each server operation could have a separate thread, or each user could have a separate thread handling all its operations. Both of these approaches imply a large number of simultaneously active threads as we scale to large user populations, resulting in large overheads for thread switching.
A more sensible approach is to create a small set of "operator" threads that execute all operations for example, one thread for all register Device operations, one for all locateUser operations, and so on.
This approach reduces the thread-switching overhead, but there are drawbacks. For one, the threads package restricts the ability to optimize scheduling, especially in time-based scheduling. More importantly, each operator thread executes its set of operations in sequence, which severely limits the ability to optimally schedule the eligible actions within an operation and across operations. Of course, each thread could keep track of all its eligible actions and do scheduling at the action level, but this essentially re-creates the action model within each thread.
For the wireless interface to client devices, we considered two link-layer technologies: IEEE 802.11 and Bluetooth. Bluetooth is power efficient and therefore better at conserving client battery power. According to current standards, Bluetooth can provide bandwidths up to 2 Mbps.
In contrast, IEEE 802.11 is less power efficient but widely deployed and currently provides bandwidths up to 11 Mbps. In areas where these high-bandwidth alternatives are not available, Rover client devices will use the lower bandwidth interfaces that cellular wireless technologies provide.
Figure 3 shows how Rover's controller interacts with other parts of the system and with the external world. The controller uses the location interface to query the location service about the positions of client devices and the transport interface to identify data formats and interaction protocols for communicating with the clients.
Rover is currently available as a deployable system using specified technologies, both indoors and outdoors. Ultimately, our goal is to provide a completely integrated system that uses different technologies and allows a seamless experience of location-aware computing to clients as they move through the system. With this in mind, we have various short- and long-term projects:
Experiment with a wider range of client devices, both those with limited text and graphics display capabilities and those that can support richer functionality, such as location-aware streaming video services.
Integrate more wireless air interfaces with the Rover system. Bluetooth is a logical next technology to experiment with. In the longer term, we expect to work with cellular providers to define and implement mechanisms that will let Rover clients interact over the cellular interface.
Implement more location-determination techniques. We are experimenting with new mechanisms for better location estimation, including a signal propagation delay-based technique, called PinPoint Technology, developed at the University of Maryland.