02-11-2012, 02:35 PM
Rover Technology: Enabling Scalable Location-Aware Computing
Rover Technology.pdf (Size: 597 KB / Downloads: 32)
Location-aware computing.doc (Size: 74 KB / Downloads: 46)
Rover Services.docx (Size: 429.7 KB / Downloads: 35)
Rover Technology Enabling.docx (Size: 90.32 KB / Downloads: 36)
Aware Computing.ppt (Size: 1.2 MB / Downloads: 44)
Abstract
Location-aware computing involves the automatic tailoring of information and services based on the current
location of the user. We have designed and implemented Rover, a system that enables location-based
services, as well as the traditional time-aware, user-aware and device-aware services. To achieve system
scalability to very large client sets, Rover servers are implemented in an “action-based” concurrent software
architecture that enables fine-grained application-specific scheduling of tasks. We have demonstrated
feasability through implementations for both outdoor and indoor environments on multiple platforms.
Introduction
A user is shopping in a mall. On entering a store, he pulls out a PDA and browses through detailed information
about the products on display. Satisfied with the information, through the PDA, he makes an online purchase
of the items of interest, that will be subsequently shipped to his home directly. As he walks on to the next store,
which happens to be a video rental store, information on newly-released movies in his favorite categories are
downloaded automatically into his PDA, along with their availability information. He chooses a couple of these
movies and indicates that he will pick them up at the storefront. His membership discounts are applied to the
bill, and he confirms the charge to his credit card.
The intriguing aspect of this scenario is the automatic tailoring of information and services based on the
current location of the user. We refer to this paradigm as location-aware computing. The different technology
components needed to realize location-aware computing are present today, powered by the increasing capabilities
of mobile personal computing devices and the increasing deployment of wireless connectivity (IEEE
802.11 wireless LANs [7], Bluetooth [1], Infra-red [2], Cellular services, etc.)
Rover Services
The services provided by Rover to its users can be classified as follows:
Basic data services: Rover enables a basic set of data services in different media formats, including text,
graphics, audio, and video. Users can subscribe to specific data components dynamically through the
device user interface. Depending on the capabilities of the user’s device, only a select subset of media
formats may be available to the user. This data service primarily involves one-way interaction; depending
on user subscriptions, appropriate data is served by the Rover system to the client devices.
Transactional services: These services have commit semantics that require coordination of state between
the clients and the Rover servers. A typical example is e-commerce interactions.
Rover Architecture
A Rover system, depicted in Figure 1, consists of the following entities:
End-users of the system. Rover maintains a user profile for each end-user, that defines specific interests
of the user and is used to customize the content served.
Rover-clients are the client devices through which users interact with Rover. They are typically small
wireless handheld units with great diversity of capabilities in regard to processing, memory and storage,
graphics and display, and network interface. Rover maintains a device profile for each device, identifying
its capabilities and thus, the functionality available at that device.
Action model
In order to achieve fine-grained real-time application-specific scheduling, the Rover controller is built according
to a concurrent software architecture we call the action model. In this model, scheduling is done in “atomic”
units called actions. An action is a “small” piece of code that does not have any intervening I/O operations.
Once an action begins execution, it cannot be pre-empted by another action. Consequently, given a specific
server platform, it is easy to accurately bound the execution time of an action. The actions are executed in a
controlled manner by an Action Controller.
We use the term server operation to refer to a transaction, either client- or administrator-initiated, that
interacts with the Rover controller; examples in the museum scenario would be registerDevice, getRoute and
locateUser. A server operation consists of a sequence (or more precisely, a partial order) of actions interleaved
by asynchronous I/O events. Each server operation has exactly one “response handling” action for handling all
I/O event responses for the operation; i.e., the action is eligible to execute whenever an I/O response is received.
Rover Clients
The client devices in Rover are handheld units of varying form factors, ranging from powerful laptops to simple
cellular phones. They are categorized by the Rover controller based on attributes identified in the device
profiles, such as display properties—screen size and color capabilities, text and graphics capabilities, processing
capabilities — ability to handle vector representations and image compression, audio and video delivery
capabilities and user interfaces. The Rover controller uses these attributes to provide responses to clients in the
most compatible formats.
For the wireless interface of client devices, we have currently considered two link layer technologies —
IEEE 802.11 Wireless LAN and Bluetooth. Bluetooth is power efficient and is therefore better at conserving
client battery power. According to current standards, it can provide bandwidths of upto 2 Mbps. In contrast,
IEEE 802.11 wireless is less power-efficient but is widely deployed and can currently provide bandwidths of
upto 11 Mbps.
Rover Database
The database in Rover consists of two components, which together decouple client-level information from the
content that is served.
One component of the database is the user infobase, which maintains user and device information of all
active users and devices in the system. It contains all client-specific contexts of the users and devices, namely
profiles and preferences, client location, and triggers set by the clients. This information changes at a fairly
regular rate due to client activities, e.g. the client location alters with movements. The Rover controller has
the most updated copy of this information and periodically commits this information to the database. For many
of these data items (e.g. client location), the Rover controller lazily updates the database. These are termed
as volatile data since any change to these data items are not guaranteed to be accurately reflected by the system
across system crashes. For some others, (e.g. new client registration) the Rover controller commits this
information to the database before completing the operation. These are termed as non-volatile data. The Rover
controller, identifies some parts of the data to be volatile, so as to avoid very frequent database transactions.
The Rover controller does not guarantee perfect accuracy of the volatile data, and thus trades off accuracy with
efficiency for these data components.
Multi-Rover System
A single Rover system comprises of a single Rover controller, other server devices (e.g., Rover database and
Rover streaming media unit), and a set of Rover clients. A single system is sufficient for management of Roverclients
in a zone of single administrative control. For example, consider a Rover system in a single museum. All
artifacts and objects on display in the museum are managed by a single administrative entity. There is a single
content provider for this system and a single Rover system is appropriate to serve all visitors to this museum.
However, each separate museum has its independent administrative authority. Therefore, we can have a
separate Rover system for each of the different museums that are administered separately by each museum authority.
This allows a decentralized administration of the independent Rover systems, locally by each museum
authority. However, it is important to provide a seamless experience to visitors as they roam from museum
to museum. A multi-Rover system is a collection of independent Rover systems that peer with each other to
provide this seamless connectivity to the user population.
Rover Technology.pdf (Size: 597 KB / Downloads: 32)
Location-aware computing.doc (Size: 74 KB / Downloads: 46)
Rover Services.docx (Size: 429.7 KB / Downloads: 35)
Rover Technology Enabling.docx (Size: 90.32 KB / Downloads: 36)
Aware Computing.ppt (Size: 1.2 MB / Downloads: 44)
Abstract
Location-aware computing involves the automatic tailoring of information and services based on the current
location of the user. We have designed and implemented Rover, a system that enables location-based
services, as well as the traditional time-aware, user-aware and device-aware services. To achieve system
scalability to very large client sets, Rover servers are implemented in an “action-based” concurrent software
architecture that enables fine-grained application-specific scheduling of tasks. We have demonstrated
feasability through implementations for both outdoor and indoor environments on multiple platforms.
Introduction
A user is shopping in a mall. On entering a store, he pulls out a PDA and browses through detailed information
about the products on display. Satisfied with the information, through the PDA, he makes an online purchase
of the items of interest, that will be subsequently shipped to his home directly. As he walks on to the next store,
which happens to be a video rental store, information on newly-released movies in his favorite categories are
downloaded automatically into his PDA, along with their availability information. He chooses a couple of these
movies and indicates that he will pick them up at the storefront. His membership discounts are applied to the
bill, and he confirms the charge to his credit card.
The intriguing aspect of this scenario is the automatic tailoring of information and services based on the
current location of the user. We refer to this paradigm as location-aware computing. The different technology
components needed to realize location-aware computing are present today, powered by the increasing capabilities
of mobile personal computing devices and the increasing deployment of wireless connectivity (IEEE
802.11 wireless LANs [7], Bluetooth [1], Infra-red [2], Cellular services, etc.)
Rover Services
The services provided by Rover to its users can be classified as follows:
Basic data services: Rover enables a basic set of data services in different media formats, including text,
graphics, audio, and video. Users can subscribe to specific data components dynamically through the
device user interface. Depending on the capabilities of the user’s device, only a select subset of media
formats may be available to the user. This data service primarily involves one-way interaction; depending
on user subscriptions, appropriate data is served by the Rover system to the client devices.
Transactional services: These services have commit semantics that require coordination of state between
the clients and the Rover servers. A typical example is e-commerce interactions.
Rover Architecture
A Rover system, depicted in Figure 1, consists of the following entities:
End-users of the system. Rover maintains a user profile for each end-user, that defines specific interests
of the user and is used to customize the content served.
Rover-clients are the client devices through which users interact with Rover. They are typically small
wireless handheld units with great diversity of capabilities in regard to processing, memory and storage,
graphics and display, and network interface. Rover maintains a device profile for each device, identifying
its capabilities and thus, the functionality available at that device.
Action model
In order to achieve fine-grained real-time application-specific scheduling, the Rover controller is built according
to a concurrent software architecture we call the action model. In this model, scheduling is done in “atomic”
units called actions. An action is a “small” piece of code that does not have any intervening I/O operations.
Once an action begins execution, it cannot be pre-empted by another action. Consequently, given a specific
server platform, it is easy to accurately bound the execution time of an action. The actions are executed in a
controlled manner by an Action Controller.
We use the term server operation to refer to a transaction, either client- or administrator-initiated, that
interacts with the Rover controller; examples in the museum scenario would be registerDevice, getRoute and
locateUser. A server operation consists of a sequence (or more precisely, a partial order) of actions interleaved
by asynchronous I/O events. Each server operation has exactly one “response handling” action for handling all
I/O event responses for the operation; i.e., the action is eligible to execute whenever an I/O response is received.
Rover Clients
The client devices in Rover are handheld units of varying form factors, ranging from powerful laptops to simple
cellular phones. They are categorized by the Rover controller based on attributes identified in the device
profiles, such as display properties—screen size and color capabilities, text and graphics capabilities, processing
capabilities — ability to handle vector representations and image compression, audio and video delivery
capabilities and user interfaces. The Rover controller uses these attributes to provide responses to clients in the
most compatible formats.
For the wireless interface of client devices, we have currently considered two link layer technologies —
IEEE 802.11 Wireless LAN and Bluetooth. Bluetooth is power efficient and is therefore better at conserving
client battery power. According to current standards, it can provide bandwidths of upto 2 Mbps. In contrast,
IEEE 802.11 wireless is less power-efficient but is widely deployed and can currently provide bandwidths of
upto 11 Mbps.
Rover Database
The database in Rover consists of two components, which together decouple client-level information from the
content that is served.
One component of the database is the user infobase, which maintains user and device information of all
active users and devices in the system. It contains all client-specific contexts of the users and devices, namely
profiles and preferences, client location, and triggers set by the clients. This information changes at a fairly
regular rate due to client activities, e.g. the client location alters with movements. The Rover controller has
the most updated copy of this information and periodically commits this information to the database. For many
of these data items (e.g. client location), the Rover controller lazily updates the database. These are termed
as volatile data since any change to these data items are not guaranteed to be accurately reflected by the system
across system crashes. For some others, (e.g. new client registration) the Rover controller commits this
information to the database before completing the operation. These are termed as non-volatile data. The Rover
controller, identifies some parts of the data to be volatile, so as to avoid very frequent database transactions.
The Rover controller does not guarantee perfect accuracy of the volatile data, and thus trades off accuracy with
efficiency for these data components.
Multi-Rover System
A single Rover system comprises of a single Rover controller, other server devices (e.g., Rover database and
Rover streaming media unit), and a set of Rover clients. A single system is sufficient for management of Roverclients
in a zone of single administrative control. For example, consider a Rover system in a single museum. All
artifacts and objects on display in the museum are managed by a single administrative entity. There is a single
content provider for this system and a single Rover system is appropriate to serve all visitors to this museum.
However, each separate museum has its independent administrative authority. Therefore, we can have a
separate Rover system for each of the different museums that are administered separately by each museum authority.
This allows a decentralized administration of the independent Rover systems, locally by each museum
authority. However, it is important to provide a seamless experience to visitors as they roam from museum
to museum. A multi-Rover system is a collection of independent Rover systems that peer with each other to
provide this seamless connectivity to the user population.