Pervasive Computing:
What is it good for?
Andrew C. Huang et all
Stanford University
Presented by
Kalpana Banerjee
“Buy drinks by
Friday”
- Take out the last can of soda
- Swipe the can’s UPC label,
which adds soda to your
shopping list
- Make a note that you need
soda for the guests you are
having over this weekend
MobiDE - Seattle, WA
August 20, 1999
“Buy drinks by
Friday”
- Approach a local supermarket
- AutoPC informs you that
you are near a supermarket
- Opportunistic reminder: “If it
is convenient, stop by to buy
drinks.”
MobiDE - Seattle, WA
August 20, 1999
“Buy drinks by
Friday”
- Friday rolls around and
you have not bought
drinks
- Deadline-based reminder
sent to your pager
MobiDE - Seattle, WA
August 20, 1999
Screen Fridge
Screen Fridge provides:
Email, video messages, web surfing, food management, TV, radio,
virtual key board, digital cook book, surveillance camera
MobiDE - Seattle, WA
August 20, 1999
Auto PC
Provides driver with navigation and traffic information (GPS)
Voice interface
Audio system, voice memo recorder,
MobiDE - Seattle, WA
August 20, 1999
What do we do with
all this information?
• We are constantly receiving information
• The problem:
– Information is only received once or twice
– It is not received when and where we need it
• A possible solution:
– Place information into the context in which it
will be most useful
– Devices accept and/or deliver information
MobiDE - Seattle, WA
August 20, 1999
Rome manages the
information
• The devices are available
• What is missing is the software framework
• Rome is an architecture that addresses the
information management problem
– Incorporates pervasive computing devices into
the system as information managers
– Introduces an abstraction to describe contextsensitive information
MobiDE - Seattle, WA
August 20, 1999
Incorporating devices
into the network
• Enables communication among devices
• Gives devices access to Internet services
– Unwieldy datasets (e.g., UPC database)
– Rapidly-changing data (e.g., traffic reports)
– Computationally intensive (e.g., mapping)
• Must deal with device heterogeneity
– Limitations: connectivity, computation, UI, etc.
– Devices have a permanent representative
MobiDE - Seattle, WA
August 20, 1999
Describing contextsensitive information
• A trigger is a piece of data bundled with
contextual information
– Conceptually, it is an action that is taken when
a certain condition is satisfied
• Condition: (location  R)  (t  T1)  (t  T2)
• Data: “You are passing a grocery store at R. You
might want to buy drinks for Friday.”
• Note: similar to database triggers
– Difference: trigger management is
decentralized
MobiDE - Seattle, WA
August 20, 1999
Frontend:
handles the
entering of
triggers into
the system
Rome Architecture
Trigger Manager:
accepts, stores, and
forwards triggers
Unit Manager:
acts as a
permanent
representative
of a device
MobiDE - Seattle, WA
August 20, 1999
Trigger Handler:
Rome Architecture
evaluates trigger
conditions and
executes appropriate
data handlers
Trigger Acceptor:
accepts triggers
from the Unit
Manager
MobiDE - Seattle, WA
August 20, 1999
Rome Architecture
Bar-code
scanner
GPSenbaled
AutoPC
MobiDE - Seattle, WA
August 20, 1999
Open Questions
• Trigger consistency
– Deleting triggers once a high-level task is
accomplished
• User interface and semantic translation
– Translating high-level requests into triggers
• Multiple users
– Sharing the system in the public infrastructure
– Adding a trigger to be seen by another user
MobiDE - Seattle, WA
August 20, 1999
Summary
• Information management applications are a
natural target for pervasive computing
• Rome provides an extensible framework
and some basic building blocks
– Communication
– Leveraging Internet services
– Triggers abstraction
MobiDE - Seattle, WA
August 20, 1999
My Conclusions
• Information management/ triggers – simple
concept, utilized well
• Rome infrastructure deployment is unclear
– service?, personalized setup?
• Drawback – other applications?
– Problem is there is no problem
MobiDE - Seattle, WA
August 20, 1999