Service Based Task Migration in Ubiquitous Environment Jari Porras

1. Service Based Task Migration in Ubiquitous Environment • Jari Porras • 5th Workshop on Applications of Wireless Communications • Lappeenranta, August 15th, 2007

2. Outline • PeerHood • Motivation • Approaches • Cases • operation migration • service based task execution • Future steps • Conclusions

3. 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

4. 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

5. 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)

6. 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

7. Case: Remote image analysis • PeerHood is used: • Service discovery • Connection management between our wireless device and server

8. Case: Remote monitoring in PeerHood PAN PTD AP AP AP AP

9. 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

10. 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

11. Case: Remote monitoring in PeerHood Server sends ”UPDATE” to the client Client acknowledges with ”OK” Client informs Daemon to send D_GET_NEIGHINFO to the server Daemon. Client Daemon contacts server Daemon Server Daemon updates neighborhood info of the client daemon (D_GET_NEIGHINFO) Client is informed if the update was successful 1 2 3 6 4 5

12. Application requests MVM for the possibility of initiating a parallel session MVM queries PeerHood in order to get information of the nearby devices MVM uses PeerHood to distribute the work MVM and PeerHood work together to handle changes in the environment Remote devices/resources return partial results to MVM MVM combines the results and forwards it to the application Case: computational service Use of several resources at the same time

13. 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

14. 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)

15. 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