1. 1 Recovery in the Mobile Wireless Environment Using Mobile Agents S. Gadiraju, V. Kumar Presented by Yamin Yu

2. 2 Lecture Outline Introduction Reference Architecture of Mobile Database System and Transaction Execution Recovery Problem Specification A Mobile Agent-Based Log Management Scheme Forward Strategy Performance Study Conclusion

3. 3 Introduction Mobile Database System(MDS) is PCM or GSM architecture based information processing system MDS is essentially a distributed client/server system, but different from the conventional one MDS may require different transaction schemes, logging schemes, caching schemes

4. 4 Introduction Use of log management scheme to enhance application availability by recovering the execution state of application through MAs Application recovery is more complex in MDS Unique processing demands of mobile units Existence of random handoffs Presence of operations in connected, disconnected, intermittent modes Unreliable log storage in one location and inefficient retrieval This paper present an efficient logging scheme to manage of application recovery within MDS constraints

5. 5 Reference of Architecture of MDS and Transaction Execution

6. 6 A DBS provides full database services and it communicates with MUs only through a BS DBSs are created as separate nodes on the wired network, able to be reached by any BS at any time

7. 7 Reference of Architecture of MDS and Transaction Execution Mobile Transaction Model(Mobilaction) defined as T i = {e 1,e 2,…e n ) where e i is an execution fragment. T i is originated at MU, fragmented and executed at MU and DBSs No fragment of T i is sent to other MUs for execution A coordinator (CO) manages commit of T i BS is selected for housing CO module to coordinate transaction execution

8. 8 Reference of Architecture of MDS and Transaction Execution Static approach(BS remains selected until T i commits) is used for management of COs to minimize wireless communication overhead and cost of control data dispatch to new COs. CO splits T i – e i received from H-MU into e j ’s, sends them to relevant DBSs for execution.

9. 9 Recovery Problem Specification MDS recovery process is more complex: MU stability is vulnerable Limited wireless bandwidth Random Handoff Efficient recovery scheme requires the log management must consume minimum system resources and recreate the execution environment as soon as possible after MU reboots Log of events are built by H-MU and server.

10. 10 Recovery Problem Specification H-MU records events such as The arrival of T i The Fragmentation of T i The assignment of a CO to a T i The mobility history of H-MU Dispatch of updates to the DBSs The nature of possible failure of MU requires that log information be store at stable location, like BS

11. 11 Recovery Problem Specification This paper uses mobile agent to manage application log for efficient application recovery in order to utilize MA’s unique processing capability and achieve the following: Communication overhead is low Recovery time is minimal Easy deployment of recovery schemes in network

12. 12 A Mobile Agent-Based Log Management Scheme Mobile agent is an autonomous program that can move from machine to machine in heterogeneous network under its own control with following advantages: Protocol Encapsulation Robustness and Fault Tolerance Asynchronous and Autonomous Execution

13. 13 A Mobile Agent-Based Log Management Scheme In mobile-agent architecture, code necessary for recovery and coordination can be embedded in the mobile agent CO modeled as mobile agent Agent in BS can clone itself and new replica migrate to other BS automatically if needed Quick population of BSs with new protocols

14. 14 A Mobile Agent-Based Log Management Scheme The Mobile Agent-based Architecture supports independent logging mechanism, consisting following agents: Bootstrap agents(BsAg)-addressing BS failure Base Agent(BaAg)-decide logging scheme Home Agent(HoAg)-handles Mobilactions for each H- MU, responsible for maintaining and recovery information on behalf of H-MU

15. 15 A Mobile Agent-Based Log Management Scheme Coordinator Agent(CoAg)-residing at each BS Event Agent(EvAg)-interface for the BS to the agent framework for dissemination of event information Driver Agent(DrAg)-handles the migration of mobile agent during a handoff Interaction of CoAg and HoAg The communication of MU and BS is through HoAg and CoAg

16. 16 A Mobile Agent-Based Log Management Scheme Action of Agent when handoff occurs DrAg is sent to along with necessary log information to the new BS with main function to check if the HoAg code present in new BS. If yes, resident BaAg is requested to create instance of HoAg, otherwise it request the BaAg in previous BS to close HoAg and new replica sent to new BS The log information after MU moves out of BS is not deleted automatically unless otherwise notified.

17. 17 Forward Strategy Recovery may not be instant after a failure if MU crash in one BS and recover in another BS. The log is unified periodically when the number of handoffs occurred crosses a predefined handoff-threshold. Trace information records BSs storing MU logs Ordered list of element Each array element includes: BS_ID and BS_ID i (log_Size i )

18. 18 Forward Strategy EFT(Expected failure Time) is estimated by HoAg as EFT = (K1 * Recorded_EFT)+(K2 * EFT) where K1 + K2 = 1 K1 can be given more weight for stable failure occurrence K2 can be given more weight for variant failure occurrence Garbage collection is used to delete unnecessary records in the log through Trace Information to improve storage utilization

19. 19 Forward Log Unification Scheme The ELUT(Estimated Log Unification Time) is estimated by HoAg using the Trace Info: Max{Bsi_Log_Size / Network link Speed + Propagation Delay} Depends on other factors: same VLR or different, querying delay etc. If * ELUT <= EFT, log unification is started, otherwise deferred until recovery call is heard

20. 20 Forward Notification Scheme Address issue of time spent in getting the previous BS information from the HLR Based on high probability that MU will recover in same VLR or adjacent VLRs provided the Actual Failure Time is not too high Assume each VLR stores MU’s status information(normal, failed, forwarded) Action of system when a MU fails: HoAg informs VLR, VLR updates status information to failed VLR sends to adjacent VLRs information (VLR_ID, FAILED_MU_ID, ASSOCIATED_BS_ID)

21. 21 Forward Notification Scheme Adjacent VLRs store this information until denotify message is received MU is recorded in these VLRs as “forwarded” flag Case 1: MU reboots in same BS HoAg informs VLR, VLR sends adjacent VLRs denotify message that forward notification information is no longer valid. VLR changes MU status back to normal Case 2: MU reboots in a different BS but same VLR MU registers at BS, with reg.message logged on VLR VLR identifies MU status as failed and go to Case 1

22. 22 Forward Notification Scheme Case 3: MU reboots in different BS and VLR MU request registration. New VLR identifies MU as forward notified, returns PRE_BS_ID and VLR_ID to HoAg of MU in recovered BS, sends recovered message to previous VLR and registration message to HLR regarding MU MU starts log unification from previous BS New VLR change MU status from forwarded to normal Previous VLR, upon receipt of recovered message, sends denotify message to all other adjacent VLR.

23. 23 Forward Notification Scheme Case 4: MU reboots in nonadjacent VLR The new BS has to get previous BS info from HLR Forward Notification Scheme has advantages: If MU suffers failures with a very small EFT, it is most likely the MU recovers in same BS, therefore Forward Notification and denotification generates overhead. Solution: HoAg waits for a buffer time before sending the notification message to VLR of failed status of MU

24. 24 Performance Study Performance of scheme is compared against lazy and pessimistic and the frequency-based movement scheme Simulation model is assumed as an MDS structure with 6 x 6 BSs arranged in a grid fashion with each cross point in the grid representing a BS

25. 25 Performance Study

26. 26 Performance Study Performance is studied in terms of the following costs: C H : Handoff log management cost – sum of message transfer cost between BSs and resulting control message C R : cost of log retrieval or log unification, a measure of recovery cost as: C R = Cost for log requests + Cost for log transfers + Cost for log unification waiting C F : Total cost of recovering from single failure

27. 27 Performance Study

28. 28 Performance Study Simulation result: handoff cost with handoff rate C H increases with handoff rate due to distributed nature of mobilaction. Lowest for Lazy scheme due to no log or trace info carried Worst for pessimistic scheme due to whole log carried Movement and forward nearly same but movement is better due to additional log size info carried in forward scheme

29. 29 Performance Study Simulation result: Cost of log retrieval with handoff rate Lazy scheme is worst Pessimistic is best because log is transferred at handoff Movement is is better than Lazy due to periodic log unification Forward is better than Movement due to forward unification and notification helping reduce recovery cost

30. 30 Performance Study Simulation result: Cost of failure with handoff Pessimistic scheme is worst due to complete log transfer at each handoff Lazy better than Pessimistic due to its log unification only on failure Movement performs best due to periodic log unification Forward is slightly worse than Movement due to forward notification/denotification overhead

31. 31 Conclusion A mobile agent-based architecture is presented to support application recovery in a mobile, wireless environment Forward strategy is aimed to reduce recovery time when failure time is nontrivial The simulation result shows forward scheme improves recovery time with fairly consistent behavior