Context-Aware Dynamic Reconfiguration in Mobile Healthcare

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

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

3. mobile healthcare system

4. System model

5. 3 possible adaptation approaches* • inform users • resource reservation • adjust demand *The many faces of adaptation, Satyanarayanan, M. 2004 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

6. MADE middleware • Support automatic system reconfiguration • transparent to user • 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

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

8. Outline • 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 • Experiments • Conclusion

9. Architecture

10. 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. 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. Reconfiguration Cost • A reconfiguration plan can be automatically generated • 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: cx(Facilitator) • Action cost: ca(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

13. To identify affected tasks! An example: “α” to “β” (1/5)

14. An example: “α” to “β” (2/5) • 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.

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

16. An example: “α” to “β” (4/5) • Detailed reconfiguration cost

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

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

19. System setting – energy aware

20. Scenario • Create a task DAG and a resource DAG (P, T, D, C) • Configure the system with an optimal task assignment, i.e. has a maximal system battery lifetime “T1” • Randomly select a channel in resource DAG and multiply its energy profile with a “context change ratio”, i.e. to simulate a context change • Re-estimate the system battery lifetime, “T2” • decrease (static): (T1-T2)/T1 • 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 • The improved battery lifetime can be calculated as: • (T3-T2)/T2

21. Experiment result • 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. Conclusions • M-health system performance suffers from dynamic environment • Proposed a task-redistribution based middleware that can support automatic system reconfiguration • Proposed a model of reconfiguration cost • Examined the effectiveness of our approach through simulation • Questions & Comments?