Service Based Task Migration in Ubiquitous Environment

Jari Porras

5th Workshop on Applications of Wireless

Communications

Lappeenranta, August 15th, 2007

Outline

- PeerHood- Motivation- Approaches- Cases

- operation migration- service based task execution

- Future steps- Conclusions

PeerHood

• Middleware that follows the device’s ”neighborhood”

• Active scans of devices and services– Daemon for background

scanning– Through library access

to the up-to-date information of the neighborhood

PeerHood

Networking

Bluetooth WLAN GPRS

MaintainSearch Monitor

Networking

Bluetooth WLAN GPRS

MaintainSearch Monitor

Applications

Use of environment

Motivation for task migration

• Mobile devices have limited resources such as processing power, memory, battery life..

• Task can be migrated to overcome these limitations

• Remote execution also enable use of many services that are not implemented to mobile platforms

Approaches

- Divided into three approaches- operation migration

- Migrate some part of the (internal) operations to another resource

- service based task execution- Execute some special task independently

- computational service- Divide the task for several resources

(Seti@home)

Case: Remote image analysis

• Mobile phone’s camera is used to take pictures of barcodes• A computer is equipped with a program which can analyze

images for barcodes• PeerHood is used to find and use the service

Measurement Communication Computation

Data

Information

Case: Remote image analysis

PeerHood is used:- Service discovery- Connection

management between our wireless device and server

Case: Remote monitoring in PeerHood

AP

AP AP

AP

PTD PAN

Case: Remote monitoring in PeerHood

Client – Server approach• Client looks for ”rmon” service from the devices

in its neighborhood (from the daemon database). – Possible to have ”devices under control” list.

Changes in those devices triggers an update– After connection to rmon service the client’s

daemon is set to idle -state

Case: Remote monitoring in PeerHood

• Rmon service look at its callback interface

– Daemon that follows the neighborhood (Bluetooth, WLAN, GPRS) informs through this callback the service of the changes

– If the change affects some speciel client, an update is started

– Timer is used to update all clients periodically

Case: Remote monitoring in PeerHood

1

2

34

1) Server sends ”UPDATE” to the client

2) Client acknowledges with ”OK”

3) Client informs Daemon to send D_GET_NEIGHINFO to the server Daemon.

4) Client Daemon contacts server Daemon

5) Server Daemon updates neighborhood info of the client daemon (D_GET_NEIGHINFO)

6) Client is informed if the update was successful

5

6

Case: computational service

1. Application requests MVM for the possibility of initiating a parallel session

2. MVM queries PeerHood in order to get information of the nearby devices

3. MVM uses PeerHood to distribute the work

4. MVM and PeerHood work together to handle changes in the environment

5. Remote devices/resources return partial results to MVM

6. MVM combines the results and forwards it to the application

Use of several resources at the same time

Future ideas

• Service definitions for the remote execution tasks– Now the algorithm is inside the service – Use of parameters

• Better support for ”interests” in operation migration

• Computational service is still under construction although it was one of the first ideas

Conclusions

- The work is still under construction so not too many conclusion so far …

- Remote task execution and operation migration is working well in implemented cases

- Service based approach is suitable for PeerHood (PeerHood is based on services)

Acknowledgements

PeerHood has been defined and implemented by many students. The work presented in this slide set has been strongly influenced by – Arto Hämäläinen– Tommi Kallonen– Jani Wunsch