1. Context-Aware Dynamic Reconfiguration in Mobile Healthcare Hailiang Mei University of Twente, NL http://wwwhome.cs.utwente.nl/~meih/

2. 2/22 Outline Experiments Conclusion Mobile healthcare system system overview, problem & research approach MADE middleware to support automatic system reconfiguration Dynamic reconfiguration framework architecture reconfiguration steps reconfiguration cost

3. 3/22 mobile healthcare system

4. 4/22 System model

5. 5/22 Problems Problem in long-term patient monitoring due to patient’s mobility, a mismatch may occur between device resource and associated task demand Task redistribution-based adaptation benefit from distributed processing advantages: user requirement less compromised distributed resource better utilized 3 possible adaptation approaches* inform users resource reservation adjust demand *The many faces of adaptation, Satyanarayanan, M. 2004

6. 6/22 MADE middleware Monitoring application registration, context monitoring/discovery Analysis (#1) task assignment algorithm to identify optimal configurations Decision improved performance vs. reconfiguration cost Enforcement (#2) perform reconfiguration execution state transfer Support automatic system reconfiguration transparent to user

7. 7/22 #1 Task assignment algorithm A* based algorithm for the general form multiple objectives, e.g. battery lifetime, end-end delay & availability. DAG-DAG NP-hard problem in the general form Efficient algorithms exist for restricted cases simple objective function chain-chain, tree-star

8. 8/22 Outline Experiments Conclusion Mobile healthcare system system overview, problem & research approach MADE middleware to support automatic system reconfiguration Dynamic reconfiguration framework architecture 7-step reconfiguration plan reconfiguration cost

9. 9/22 Architecture

10. 10/22 BSPU lifecycle OSGi implementation platform industry standard compact design for resource constrained devices Introduce 2 new states to freeze the system for state transfer

11. 11/22 7-step reconfiguration plan Preparing: Coordinator installs and starts every relocated and newly added BSPU at the targeted new location Blocking: Coordinator blocks all source affected BSPU Waiting: Coordinator waits until system enters a safe-state Fetching: Coordinator fetches current execution state from relocated BSPU Setting: Coordinator copies the execution state to BSPU at new location Resuming: Coordinator unblocks all source affected BSPU Removing: Coordinator removes all outdated BSPU

12. 12/22 Reconfiguration Cost The execution of reconfiguration plan can be viewed as a combination of control communications between Coordinator and Facilitators and control actions on BSPUs applied by their hosting Facilitators. From the view point of Coordinator, we define Communication cost: c x (Facilitator) Action cost: c a (Facilitator, BSPU, action) Initially, some heuristic values can be used to determine these cost. During the execution, these values can be updated based on real measurements. It is possible to estimate the reconfiguration cost of a plan before its actual execution A reconfiguration plan can be automatically generated

13. 13/22 originaltarget b0d1 b1d0 b2d1d3 b3d3 b4d3 b5d3 t0d1d1-c2-d3 t1d1-c2-d3 t2d0-c0-d2-c3-d3 t3d1-c1-d2-c3-d3d3 t4d1-c1-d2-c3-d3d3 t5d3 t6d3 t7d3 To identify affected tasks! An example: “α” to “β” (1/5)

14. 14/22 originaltarget b0d1 b1d0 b2d1d3 b3d3 b4d3 b5d3 t0d1d1-c2-d3 t1d1-c2-d3 t2d0-c0-d2-c3-d3 t3d1-c1-d2-c3-d3d3 t4d1-c1-d2-c3-d3d3 t5d3 t6d3 t7d3 A transmission task is affected if it is added, relocated or removed. A processing task is affected if (1) it is added, relocated or removed or (2) any of its outgoing transmission tasks is affected. An example: “α” to “β” (2/5)

15. 15/22 An example: “α” to “β” (3/5)

16. 16/22 StepCost preparingc x (F@d3) + c a (F@d3, b2, install) + c a (F@d3, b2, resolve) + c a (F@d3, b2, start) blockingc x (F@d1) + c a (F@d1, b0, block) waitingc a (F@d1, b0, wait) + c a (F@d1, b2, wait) fetchingc x (F@d1) + c a (F@d1, b2, fetch) settingc x (F@d3) + c a (F@d3, b2, set) + c x (F@d1) + c a (F@d1, b0, set) resumingc x (F@d1) + c a (F@d1, b0, resume) removingc x (F@d1) + c a (F@d1, b2, stop) + c a (F@d1, b2, uninstall) + c x (F@d2) + c a (F@d2, t3*, stop) + c a (F@d2, t3*, uninstall) + c x (F@d2) + c a (F@d2, t4*, stop) + c a (F@d2, t4*, uninstall) An example: “α” to “β” (4/5) Detailed reconfiguration cost

17. 17/22 setting #1, All on the same machine setting #2, [Coordinator & F@d1] [F@d2 & F@d3] An example: “α” to “β” (5/5)

18. 18/22 Outline Experiments Conclusion Mobile healthcare system system overview, problem & research approach MADE middleware to support automatic system reconfiguration Dynamic reconfiguration framework Architecture Reconfiguration Plan Reconfiguration cost

19. 19/22 System setting – energy aware

20. 20/22 Scenario 1.Create a task DAG and a resource DAG (P, T, D, C) 2.Configure the system with an optimal task assignment, i.e. has a maximal system battery lifetime “T1” 3.Randomly select a channel in resource DAG and multiply its energy profile with a “context change ratio”, i.e. to simulate a context change 4.Re-estimate the system battery lifetime, “T2” decrease (static): (T1-T2)/T1 5.Calculate the optimal task assignment under the new situation and reconfigure the system accordingly. Estimate the new configuration’s battery lifetime as “T3” decrease (dynamic): (T1-T3)/T1 6.The improved battery lifetime can be calculated as: (T3-T2)/T2

21. 21/22 Experiment result Setting (P,T,D,C) Context change ratio decrease (static)decrease (dynamic) Improved lifetime (8, 10, 5, 6)210.8%4.5%9.4% (8, 10, 5, 6)523.9%12.9%30.8% (8, 10, 5, 6)1040.2%19.3%92.5% (8, 10, 5, 6)2053.5%18.4%246.5% (10, 12, 8, 10)27.6%2.5%7.1% (10, 12, 8, 10)532.3%14.5%53.5% (10, 12, 8, 10)1043.0%17.6%109.2% (10, 12, 8, 10)2039.6%7.5%217.6% The results prove a significant improvement on system battery lifetime if the system can be reconfigured according an optimal task assignment the more significant the context change, the better improvement can be expected

22. 22/22 Conclusions M-health system performance suffers from dynamic environment Questions & Comments? Proposed a model of reconfiguration cost Proposed a task-redistribution based middleware that can support automatic system reconfiguration Examined the effectiveness of our approach through simulation