Pervasive Computing: What is it good for? Andrew C. Huang, Benjamin C. Ling, Shankar Ponnekanti, Armando Fox Stanford University

MobiDE - Seattle, WA August 20, 1999 “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 - Also informs you that drinks are on sale - Deadline-based reminder sent to your pager

MobiDE - Seattle, WA August 20, 1999 “Buy drinks by Friday”

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 context- sensitive 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., product pricing) –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 context- sensitive 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  T 1 )  (t  T 2 ) 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 Rome Architecture Frontend: handles the entering of triggers into the system Unit Manager: acts as a permanent representative of a device Trigger Manager: accepts, stores, and forwards triggers

MobiDE - Seattle, WA August 20, 1999 Rome Architecture Trigger Acceptor: accepts triggers from the Unit Manager Trigger Handler: evaluates trigger conditions and executes appropriate data handlers

MobiDE - Seattle, WA August 20, 1999 Rome Architecture GPS- enbaled AutoPC Bar-code scanner

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

Andrew C. Huang, Benjamin C. Ling, Shankar Ponnekanti, Armando Fox