An Infrastructured-Architectural Model (IAM) for

Pervasive & Ubiquitous Computing

R. Gunasekaran

and V. Rhymend Uthariayaraj

Lecturer/CSE

Crescent Engineering College

Vandalur, Chennai-48

Assistant Professor

Ramanunjam computing center

Anna University, Chennai-25

Abstract. An extensible and modular architecture called IAM that addresses

this information-routing problem while leveraging significant existing work on

composable Internet services and adaptation for heterogeneous devices is

described here. IAM's central abstraction is the concept of a trigger, a self-

describing chunk of information bundled with the spatial and/or temporal

constraints that define the context in which the information should be delivered.

The IAM architecture manages triggers at a centralized infrastructure server and

arranges for the triggers to be distributed to pervasive computing devices that

can detect when the trigger conditions have been satisfied and alert the user

accordingly. The main contribution of the architecture is an infrastructure-

centric approach to the trigger management problem. We argue that pervasive

computing devices benefit from extensive support in the form of infrastructure

computing services in at least two ways. First, infrastructure adaptation services

can help manage communication among heterogeneous devices. Second, access

to public infrastructure services such as MapQuest and Yahoo can augment the

functionality of trigger management because they naturally support the time and

location dependent tasks typical of pervasive-computing users. We describe our

experience with a functional prototype implementation that exploits GPS to

simulate an AutoPC.

1 Introduction

The Internet-connected ScreenFridge [11] the Microwave Bank [4] and the new

AutoPC [6] appear to be primitive first steps in the direction of pervasive computing.

If these efforts sound a bit outlandish, there's a good reason: the devices are solutions

in search of a problem. Yet the devices do have something in common with Web

browsers, pagers, cell phones, grocery lists, and to-do notes stuck on the door. We are

in undated with information of all kinds, arriving over various media, and targeted for

various tasks do this tomorrow, check up on that when you're in the office, call me

back, and so on. This suggests that one natural target for pervasive computing is data

management-getting information into the temporal or spatial context in which it will

Gunasekaran R. and Rhymend Uthariayaraj V. (2005).

An Infrastructured-Architectural Model (IAM) for Pervasive & Ubiquitous Computing.

In Proceedings of the 2nd International Workshop on Ubiquitous Computing, pages 49-59

 SciTePress

be most useful, and using pervasive computing devices to accept or deliver it. It has

been argued [12] that pervasive computing will have succeeded when computers-

“disappear into the infrastructure" and we find ourselves using computer-assisted

task-specific devices, as opposed to computing devices per se. In particular, we

describe a simple pervasive computing architecture to address the above problem,

along with an implemented prototype using off-the-shelf PC's and pervasive

computing devices.

We take an infrastructure-centric point of view: like PDA's and handheld devices,

pervasive computing devices will be fundamentally dependent on infrastructure

“glue" in order to be truly useful. For PDA's, the original rationale behind this

assertion was the need for adaptation: since a primary application of the devices is

information retrieval from the Internet, infrastructure support is needed to adapt these

devices to a network infrastructure not designed for them [7]. The analogous

argument for pervasive computing is that humans receive and deal with information

in a variety of temporal and spatial contexts, and although pervasive computing

devices are useful as “end-unit" sensors and actuators to assist with information

management tasks, infrastructure support is needed to tie them together and address

the distributed information management problem.

1.1 A real-time situation

Considering the following scenario: Opening your refrigerator to take out a drink, you

notice that there is only one can left. You scan its UPC with the scanner attached to

your refrigerator. This action adds drink to your shopping list. You plan to have

guests over this weekend, and make a note on your ScreenFridge that you need to

replenish your supply of drinks by Friday. The next day, on your drive home from

work, you happen to approach a local supermarket. Your GPS-enabled AutoPC,

previously informed by your refrigerator that purchases need to be made, signals that

you are near a grocery store, and if it is convenient, that you should stop by the

supermarket on the way home. Suppose you do not act on the opportunity, and Friday

rolls around and you still have not visited the supermarket; in this case, a message to

buy drinks is sent to your pager, or an alarm is triggered in your PDA, or both. The

key observation that follows from the above example is that information is rarely

useful at the time and place it is generated. Rather, the information must be re-

presented later, where and when it can be acted on. That is, information is most useful

when it is delivered in the correct temporal or spatial context.

1.2 Ideal Infrastructure

This simple example illustrates two important ways in which pervasive computing

relies on infrastructure support. The first, and obvious, dependence is for

communication: items are added to the “shopping list" by your refrigerator but the list

itself needs to be accessible elsewhere. The information has to be transported between

devices. The less obvious but more important dependence is on infrastructure

services. By these we refer to publicly-accessible interactive ser- vices that perform

on-demand computation over large datasets. In the context of the present work, an

infrastructure service is simply one that does not run on any of the pervasive

computing devices themselves it may run in the public Internet or in a private home-

area network. Infrastructure Ser- vices may be necessary for any of several reasons:

Data rapidly changing: Timely information, such as traffic reports, news, and stock

quotes, changes too rapidly to make continuous distribution practical for

intermittently connected users. Furthermore, devices such as PDA's and the AutoPC

may not have constant connectivity; therefore, such services require infrastructure

support.

Unwieldy datasets: One example of an unwieldy dataset is a UPC database. In the

example given in the previous section, the refrigerator may need to translate the UPC

to a product name so that the shopping list is readable by humans. Although the

refrigerator might cache the UPC's of frequently-purchased products, a general UPC

translation service would necessarily be infrastructural.

Computation: The computation required to generate a result may exceed the storage

or CPU resources available to a small device. For example, some online mapping

services such as MapQuest support queries of the form “Given a starting location,

find the geographically closest businesses of a given type."

Examples of Web-based infrastructure services that have the above properties include

mapping and driving directions services, zip code lookup, search engines and business

directories, upto-the-minute financial information, and online auctions. Several

aspects of our motivating example assume the ability to leverage such services:

translating UPC's to product names, locating a supermarket through a directory

service such as Yahoo!, converting the address to GPS coordinates (“geocoding")

through programmatic interfaces to mapping services such as MapQuest, and possibly

sending a text-based, on-demand notification to a pager or similar device through an

Internet gateway, such as Airtel. Recognizing the need for infrastructural support for

pervasive computing devices, we present IAM, a uniform architecture for addressing

the information management and infrastructure dependence issues exposed by the

example given in the previous section. In the following sections, we describe the IAM

architecture, discuss our prototype implementation in progress, and show how this

approach promises rapid deployment by leveraging other existing research, both in

design philosophy and implementation.

Fig. 1. Overall IAM Architecture

2 IAM Architecture

2.1 Triggers

The notion of a trigger is central to IAM. We use the term trigger to mean

information paired with its useful context. Conceptually, a trigger is some action that

should be taken when a previously stated condition is satisfied. The trigger is not

novel to IAM; it has been in use in the database community for years. However, IAM

extends the classical database notion of a trigger by allowing decentralized evaluation

of triggers. Triggers are pushed to end devices, such as DA's or AutoPC's, allowing

evaluation to occur at those devices. Although in some cases evaluation could occur

at a central location such as a server, in other cases the end device is the only

appropriate device to evaluate the trigger, because information such as location may

be local to the device and not known by others. IAM provides the ability to (a)

determine which devices should receive which triggers, (b) route the selected triggers

to the devices, and (c) possibly assist in determining when to fire them. The IAM

architecture is shown in Figure 1. The system is well-connected to the Internet

infrastructure and consists of several components. FrontEnds are used for input into a

Semantic Translator, which in turn interfaces with a Trigger Manager. Also, a Unit

Manager exists for each type of end-device and the function of each component is

described.

2.2 Managing Triggers

Conceptually, a trigger is composed of a condition and an action. When the condition

evaluates to true, some action should occur. Typically, the desired goal is the

completion of some high-level task. The high level task is translated by the system's

Semantic Translator to a corresponding set of triggers. Some tasks may be represented

as a single trigger, such as an alarm for a specific time. Others may be represented as

a combination of several triggers. In the supermarket example, the high-level task can

be mapped to two distinct triggers: 1) A trigger that is fired when a certain spatial

constraint is satisfied, or 2) a trigger that is fired when a certain temporal context is

met. A term is a primitive that evaluates to true when a particular spatial or temporal

constraint is satisfied. All triggers are stored in the IAM system; a subset is forwarded

to those devices that can evaluate the trigger's condition.

2.3 Example illustrated

Coming back to the example the chain of events in relation to the proposed

architecture:

I. A user scans the UPC of a bottle, and enters a requirement to buy drinks by Friday.

The scanner sends this information to the IAM FrontEnd designed for the scanner's

interface. In general, for every input format, there is a FrontEnd that collects

information about high-level tasks.

II. The FrontEnd then forwards the information to the Semantic Translator which

translates high-level tasks into sets of triggers. Since IAM is well-connected to the

Internet, it can retrieve pertinent information such as the location and hours of local

supermarkets using a publicly-accessible service such as Yahoo or MapQuest. Using

this information, the translator produces two triggers from the high-level task “Buy

drinks by Friday":

Trigger 1:

- Condition: (location € R) ^ (t > T1) ^ (t <

T2)

- Data: “Since you are driving home from

work and passing by a grocery store at location R, you could stop to buy drinks for

Friday."

Trigger 2:

- Condition: (t = T)

- Data: “Buy drinks today."

Note that the condition in Trigger 1 is composed of three terms: (location €

R),

(t > T1), (t < T2). The time terms represent the period of time associated with the

user's drive home from work. In general, a condition can be composed of an arbitrary

number of terms, connected by logical operators.

III. IAM then inspects its list of accessible end-devices; each of the end-devices and

its corresponding properties were made known to IAM, by previous registration.

Hence IAM is aware of information such as processing power and connectivity of

each end-device, and is capable of distributing triggers to end-devices. The first

trigger above is be routed to an AutoPC equipped with GPS, and the second trigger

routed to a PDA.

IV. Each end-device stores the trigger(s) assigned to it, and when the appropriate

context is satisfied, renders the data to the user. For example, when the AutoPC nears

a supermarket during open hours, the user is informed of the event, perhaps by the

AutoPC's text-to-speech facility. Because IAM knows each device's capabilities, it

can ensure that each device only receives data that it can suitably render.

V. When the event is acted on, the user will indicate that the high-level task has been

accomplished to the AutoPC, which will in turn inform IAM. Because the AutoPC is

weakly connected, it can notify IAM via email that the task has been acted on. IAM

can then proceed to cancel other triggers that were created from the same high-level

task, as they are now unnecessary. The next time other devices communicate with

IAM, extraneous triggers will be deleted from those devices as well.

3 Model Implementation

3.1 Overview

Triggers are the mechanism by which reminders are produced in a context where the

information is useful. A trigger object contains trigger data, condition, and an optional

special handler, which replaces the default handler if special actions are to be taken.

The user directly enters trigger information into the IAM System, which determines

which devices are capable of processing specific triggers and distributes the triggers

accordingly. We use the term Mobile Information Appliance (MIA) to refer

generically to a device that can act as the endpoint of a trigger.

IAM comprises the following components:

The Frontend provides an interface through which the user can enter trigger

information-conditions to be met for the trigger to go off and the actions that need to

be taken when the trigger goes off. Although the prototype supports only Web form

entry of trigger conditions directly (eliminating the need for a Semantic Translator),

keeping the frontend separate from the Trigger Manager allows incremental addition

of more sophisticated input mechanisms, e.g. a simulated ScreenFridge.

The Trigger Manager runs in the infrastructure and stores all the triggers entered by

the user. This component must be up and accessible all the time. This forwards the

triggers to the appropriate end-points upon request using the various unit mangers.

The Unit Manager is an MIA specific component residing in the infrastructure. It

hides the peculiarities of each type of MIA from the Trigger Manager and helps in

transferring triggers from the Trigger Manager to the MIA's.

The Trigger Acceptor resides on the MIA and communicates with the appropriate

unit manager in the infrastructure to download triggers if and when necessary.

The Trigger Handler resides on the MIA and is responsible for evaluating the trigger

condition and executing the appropriate handler. The Trigger Handler consists of

three elements. Term Evaluators interface with the device clock or GPS receiver to

evaluate the temporal and spatial terms in the condition; when a term changes in

value, a callback is sent to the Condition Evaluator. The Condition Evaluator re-

evaluates the Boolean expression of terms each time a callback from the Term

Evaluator is received; when the expression evaluates to true, the Data Handler is

invoked to renders the trigger's data to the user using whatever notification

mechanism is appropriate to the MIA (window popup, text-to-speech conversion,

alarm sound, etc.)

3.2 Details of Implementation

We have leveraged several existing “off the shelf" software tools and technologies for

putting together the system: Ninja [8], TeleType software [13] (for GPS), and

Microsoft Windows CE. We are using a GPS enabled Philips Nino (running WinCE),

which we expect to replace with an AutoPC in actual use. In the current

implementation, the MIA (Nino) communicates with the Unit Manager using the

standard Windows CE serial cradle. The Trigger Acceptor, a piece of native WinCE

code that runs on the Nino, initiates a connection to the Unit Manager, a Ninja

ISPACE service running in the infrastructure. Triggers are transferred between the

Trigger Acceptor and the Unit Manager using a simple TCP-based serialization

protocol. In a real implementation, we expect to use a two-way wireless connection

rather than the cradle and allow for the possibility of proactively pushing triggers to

an MIA capable of asynchronous receiving (rather than waiting for an explicit request

from the MIA). The Unit Manager gets the triggers from the Trigger Manager,

another Ninja ISPACE service that maintains a database of trigger objects in an

XML-like serialized form. The Trigger Handler on the WinCE device converts from

the internal representation of the trigger to a C++ trigger object. The term evaluators

in the Trigger Handler access the GPS data and register for time-based notifications

via the WinCE API. Although primitive, the prototype demonstrates the feasibility of

the IAM system. We implemented the motivating example scenario using this

prototype: the user enters a trigger through the frontend asking the system to remind

him if he is near the supermarket in a specified time interval, and when the GPS

coordinates indicate that the user is close to the supermarket and the current time is

within the specified limits, a window pops up on the Nino.

Fig. 2. IAM system

The high degree of modularity of the prototype should allow us to improve it by

incrementally adding more sophisticated user input mechanisms and incorporating

new devices.

4 Related Works

4.1 Pervasive Computing

In The Design of Everyday Things [14], Donald Norman advocates moving

information “into the world" as a sound design technique for everyday objects.

Pervasive computing using the IAM architecture is a concrete instantiation of this

principle: at the moment a useful piece of information is created, it can be routed to an

information management system whose responsibility is to ultimately deliver it into

the physical context in which it will be useful. In Weiser and Want's seminal Tab

system , the wearable devices called Tabs relied on extensive infrastructure support

to provide functionality such as tracking a user around a building, automatically

opening doors for her, forwarding her calls to the phone nearest her current location,

and having a terminal retrieve her preferences when she sits down to use it. We

believe the intimate connection between truly pervasive computing and strong

infrastructure support, as demonstrated in the Tab system, is fundamental ”hence our

strategy of combining a flexible and robust framework for “programming the

infrastructure", i.e. Ninja, with a novel data-management architecture whose central

whose central abstraction is the context-sensitive trigger and whose primary

responsibility is the creation, management, and routing of triggers, with infrastructure

support. Steve Mann's head-mounted augmented reality system [9] allows a

computer-generated image to be super- posed with the “real" image that is seen

through the glasses. Among other things, the overlaid image can be used to annotate

the virtual counterparts of real-life objects; for example, a virtual “buy drink" sign

hung on the supermarket can be seen as the user passes by the supermarket while

wearing the glasses. By treating the glasses as a device capable of instantiating a

location-based trigger, IAM provides a unified framework for supporting such reality

augmentation devices.

IAM can enhance the “smartness" of smart spaces by coupling automatic actuation

with the correct context; for example, your alarm clock might go off half an hour

earlier than usual, based on its knowledge of a meeting you have scheduled and the

report of an accident on your route to work.

4.2 Infrastructure Computing

The UC Berkeley TACC [5] framework enables the creation of interactive Internet

applications by composing modules that either implement new functionality or

leverage the functionality of another already-deployed remote service. For example,

an early TACC application was a “meta-search" engine that queried various existing

search engines and ranked the collated results; this application could be composed

with a thin-client browser adaptor [10] to deliver an efficient multi-engine search

service to a handheld PDA device with a limited user interface. In this sense, TACC

was a primitive attempt to provide a framework for programming the Internet using

existing services as building blocks. The Java-based Ninja [8] framework improves

on TACC by providing strongly-typed composable programmatic interfaces for

service modules and providing a core set of services and primitives for building and

composing modules. We used Ninja as a starting point for building IAM. The need

for interoperability among diverse devices and heterogeneous networks has been

extensively addressed via work on transformational and other adaptation proxies

TACC demonstrated the value of putting transformation services into the

infrastructure; since the IAM Trigger Manager already acts as a centralized resource

in our pervasive computing architecture, it is a natural place to collocate

transformation capability.

4.3 Triggers

Triggers have been in use in the relational database community since at least SQL

version 3 [14]. In that context, a trigger is a specification of some actions to take

whenever a modification to a database table results in some constraint on the relation

being met. We have extended the basic trigger in two ways. First, recognizing that

dynamic attributes such as location and time are fundamental to our task of moving

information to the right context, we have provided the ability to instantiate triggers

based on these attributes. We rely on the specific abilities of pervasive-computing

devices to accomplish this. Second, we allow partial and distributed evaluation of

triggers. Specifically, we look for affinities between terms in the trigger condition and

the specific abilities of each device.

5 Issues addressed

5.1 Handling multiple users

Most information transmitted to and from pervasive devices is likely to be private by

default. How- ever, we believe many users will prefer to avoid the complexity of

operating a Home Base in their home, delegating this instead to an Internet data

center or comparable infrastructure installation. Note that many people already use

public infrastructure for email and gatewaying messages to pagers, so the idea of

using public infrastructure for private data is not without precedent. We intend to

build IAM as a shared infrastructure for private data, but leave open the possibility to

extend the system to support group-accessible triggers.

5.2 Trigger Consistency and User Interface

In the initial prototype, triggers are entered using a Web-form interface. If IAM is to

be widely accepted, other interfaces must be designed to make it easy for users enter

trigger information. As the motivating example suggests, one possible interface is the

UPC scanner on the ScreenFridge; this interface is an easy way to enter “shopping-

list" reminders, but it is clearly limited to the particular context. Therefore,

architecture is designed so that any number of such interfaces modules, or Frontends,

can easily be added.

5.3 Semantic translation

When easier-to-use interfaces are integrated into the system, there must be a

mechanism to translate high-level “requests" such as scanning an item on a UPC

scanner into a set of primitive triggers. In many cases, a user-preferences file will aid

the translation; such a file could include locations of interest (e.g., grocery stores

within a certain radius of a user's home), the user's default schedule, and a link to the

user's actual schedule. In keeping with the composable applications philosophy, we

are making this translation mechanism separable from and composable with the

Trigger Manager to allow maximum flexibility for future work in this area.

5.4 Multiterm conditions

Since certain condition parameters, such as those that depend on rapidly-changing

information, are best evaluated in the infrastructure, there may exist conditions where

some terms should be on the device and some terms should be evaluated at the IAM

trigger manager. As was the case with trigger consistency, this problem is

complicated by the fact that some devices are only intermittently connected.

6 Conclusions

The architecture described in the previous sections brings coherence to a number of

other problems whose relationships to each other were previously not obvious. It

provides a framework that naturally accommodates such diverse devices as the

AutoPC, the ScreenFridge, and augmented reality glasses.

References

1, Christopher K. Hess, Manuel Roman, and Roy H. Campbell. “Building Applications for

Ubiquitous computing Environments”. International Conference on Pervasive Computing

(Pervasive 2002), August 2002.

2. Krzysztof Gajos, Luke Weisman, and Howard Shrobe. “Design Principles for Resource

management Systems for Intelligent Spaces”. Second International Workshop on Self-

Adaptive Software (IWSAS'01), 2001.

3. Voelker, G.M., Bershad, B.N. Mobisaic:”An Information System for a Mobile Wireless

Computing Environment”. In Proceedings of the Workshop on Mobile Computing Systems

and Applications. Santa Cruz, CA, December, 1994.

4. NCR Corp. “NCR microwave bank announcement”,1999.http://www.wired.com/news/

news/technology/story/14949.html.

5. Armando Fox. The Case for TACC: “Scalable Servers for Transformation, Aggregation,

Caching and Customization”.UC Berkeley Computer Science Division.

http://www.cs.berkeley.edu/~fox/papers/quals.ps,April 1997.

6. ClarionCorp.AutoPCannouncement”,1999. http://www.autopc.com/walkthrough/

communication/.

7. Armando Fox, Steven D. Gribble, Yatin Chawathe, and Eric A. Brewer. “Adapting to

network and client variation using active proxies” Lessons and perspectives. IEEE Personal

Communications (invited submission), Aug 1998. Special issue on adapting to network and

client variability.

8. Steven D. Gribble, Matt Welsh, Eric A. Brewer, and David E. Culler. “The multispace: An

evolutionary approach to internet-scale services”. In Second USENIX Symposium on

Internet Technologies and Systems (USITS 99), Aug 1999.

9. Todd D. Hodes and Randy H. Katz. Enabling “smart spaces:" entity description and user

interface generation for a heterogeneous component-based distributed system. In

DARPA/NIST Smart Spaces Workshop, Gaithersburg, MD, July 1998.

10. Armando Fox, Ian Goldberg, Steven D. Gribble, Anthony Polito, and David C. Lee.

Experience with Top Gun Wingman: “A proxy- based graphical web browser for the Palm

Pilot PDA”. In IFIP International Conference on Distributed Systems Platforms and Open

Distributed Processing (Middleware '98), Lake District, UK, September 15{18 1998.

11. Electrolux Inc. “Electrolux screen fridge (news article)”, 1999. http://www.wired.

Com/news/news/email/explode-infobeat/ technology/story/%17894.html.

12. Donald A. Norman. “The Invisible Computer: Why Good Products Can Fail, The Personal

Computer Is So Complex, and Information Appliances Are the Solution”. MIT Press, 1998.

13. TeleType Corp. “TeleType GPS receiver and software”. http://www.teletype.com.

14. Donald A. Norman. “The Design of Everyday Things”. Doubleday, 1990