Transcript Context-Awareness on Mobile Devices

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)
2008. 10. 13.
Summarized & presented by Babar Tareen, IDS Lab., Seoul National University
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)
Copyright  2008 by CEBT
2
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
Copyright  2008 by CEBT
3
Req. for C.A. Framework on Mobile Devices

Lightweightness


Extensibility



Support connections to remote sensors
Robustness


Consider limited processing power
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
Copyright  2008 by CEBT
4
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
Copyright  2008 by CEBT
5
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
Copyright  2008 by CEBT
6
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
iPAQ 3660
Copyright  2008 by CEBT
iPAQ 3870
7
Implementation
Copyright  2008 by CEBT
8
Context
 Supported types

Time

Location

Device

User

Network
 Other context types can be added
Copyright  2008 by CEBT
9
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
Copyright  2008 by CEBT
10
Exemplary Application
 Context-aware Postbox


Sends and receives multimedia data
–
Images
–
Text
–
Business cards
Adopts images according to device capabilities
Copyright  2008 by CEBT
11
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
Copyright  2008 by CEBT
12
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
Copyright  2008 by CEBT
13
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 3rd
person??
NOTE (Good or Bad ??):

No Ontologies used

No reasoning engines used
Copyright  2008 by CEBT
14