Context-Awareness on Mobile Devices - the Hydrogen Approach Thomas Hofer, Wieland Schwinger, Mario Pichler, Gerhard Leonhartsberger, Josef Altmann (Software Competence Center, Hagenberg, Austria) Werner Retschitzegger (Johannes Kepler University, Linz, Austria) 36th Annual Hawaii International Conference on System Sciences (2003) Summarized & presented by Babar Tareen, IDS Lab., Seoul National University

Copyright  2008 by CEBT Introduction  Mobile devices lack resources Computing power Memory Power Supply / Battery Life Not permanently connected to a network  But mobile devices are Much more personal (One device for one user) Move with their users (User ‘s location is that of the device) 2

Copyright  2008 by CEBT Related Work  Context Toolkit Context can come from many distributed machines Widgets read sensors Dynamic detection of remote sensors in not supported  GeoNotes Users can create notes and stick those to geographic locations Considers location context only  CampusSpace exploits the signal strength of roaming client devices registered at WLAN access points  Nord et al. Reading the location information with peer-to-peer position sharing 3

Copyright  2008 by CEBT Req. for C.A. Framework on Mobile Devices  Lightweightness Consider limited processing power  Extensibility Support connections to remote sensors  Robustness Has to be robust against disconnections of remote sensors  Meta-Information – Distance of the device to the sensor – Preciseness of the sensor – And more…  Context-Sharing Mechanism to share sensed context with other devices 4

Copyright  2008 by CEBT Hydrogen Context-Framework  Three layered architecture Application Layer Management Layer – Context server stores all context data – Context server can share context data with other devices – Provides methods to access context – Context can be pulled or pushed Adaptor Layer – Gets information from sensors – Abstracts sensed data – Solves problem of simultaneous access  All three layers reside on one device 5

Copyright  2008 by CEBT Benefits of the Framework  No network disconnections Applications communicates only with local context server  Drops historical context data management  Context sharing on peer-to-peer basis 6

Copyright  2008 by CEBT Implementation  Prototype implemented in Platform: PersonalJava (Jeode VM, J2ME J9) Device: iPAQs (3660 and 3870) OS: MS PocketPC 2002 Processor: 206 MHz Resolution: 240 x 320 RAM: 64MB IR Port: 115 Kbps 7 iPAQ 3660iPAQ 3870

Copyright  2008 by CEBT Implementation 8

Context  Supported types Time Location Device User Network  Other context types can be added 9

Copyright  2008 by CEBT Other Components  Context Server Java Executable Accessible through a port Communication possible via XML and Java objects  Adaptors and Applications ContextClient deals with all communication issues 10

Copyright  2008 by CEBT Exemplary Application  Context-aware Postbox Sends and receives multimedia data – Images – Text – Business cards Adopts images according to device capabilities 11

Copyright  2008 by CEBT Future Work  Using XML Schema for validation  Context Sharing Sharing available information between devices Security and Reliability User’s control over context sharing Handling contradictory information 12

Copyright  2008 by CEBT About the Paper  Good, Why ? Looked into previous available frameworks and come up with a new design Very simple framework design suggested  Bad, Why ? Details about sharing context are missing (Authors have highlighted that sharing context is an open issue) Prototype application not good enough to demonstrate usefulness of the framework When application was about to receive the data, user should have been asked if he needs Good quality or Avg. quality image 13

Copyright  2008 by CEBT Discussion  Context Server acts as a repository it just stores the data does not care about the context type  Authentication between framework components Poor architecture from security perspective What if I replace the Context Server with my own code which acts like normal context server but sends all context data to a 3 rd person??  NOTE (Good or Bad ??): No Ontologies used No reasoning engines used 14