1

Recovery in the Mobile Wireless Environment Using Mobile Agents

S. Gadiraju, V. KumarPresented by Yamin Yu

2

Lecture Outline

IntroductionReference Architecture of Mobile Database System and Transaction ExecutionRecovery Problem SpecificationA Mobile Agent-Based Log Management SchemeForward StrategyPerformance StudyConclusion

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

IntroductionUse 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

Reference of Architecture of MDS and Transaction Execution

6

Reference of Architecture of MDS and Transaction Execution

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

Reference of Architecture of MDS and Transaction Execution

Mobile Transaction Model(Mobilaction) defined as Ti = {e1,e2,…en) where ei is an execution fragment. Ti is originated at MU, fragmented and executed at MU and DBSsNo fragment of Ti is sent to other MUs for executionA coordinator (CO) manages commit of Ti

BS is selected for housing CO module to coordinate transaction execution

8

Reference of Architecture of MDS and Transaction Execution

Static approach(BS remains selected until Ti commits) is used for management of COs to minimize wireless communication overhead and cost of control data dispatch to new COs.CO splits Ti – ei received from H-MU into ej’s, sends them to relevant DBSs for execution.

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

Recovery Problem SpecificationH-MU records events such as

The arrival of Ti

The Fragmentation of Ti

The assignment of a CO to a Ti

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

Recovery Problem SpecificationThis 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

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

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

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

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 HoAgThe communication of MU and BS is through HoAg and CoAg

16

A Mobile Agent-Based Log Management Scheme

Action of Agent when handoff occursDrAg 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

Forward StrategyRecovery 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 logsOrdered list of element

Each array element includes: BS_ID and BS_IDi(log_Sizei)

18

Forward StrategyEFT(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

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

Forward Notification SchemeAddress issue of time spent in getting the previous BS information from the HLRBased on high probability that MU will recover in same VLR or adjacent VLRs provided the Actual Failure Time is not too highAssume 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 failedVLR sends to adjacent VLRs information (VLR_ID, FAILED_MU_ID, ASSOCIATED_BS_ID)

21

Forward Notification SchemeAdjacent VLRs store this information until denotify message is receivedMU is recorded in these VLRs as “forwarded” flag

Case 1: MU reboots in same BSHoAg 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

Forward Notification SchemeCase 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 MUMU starts log unification from previous BSNew VLR change MU status from forwarded to normalPrevious VLR, upon receipt of recovered message, sends denotify message to all other adjacent VLR.

23

Forward Notification SchemeCase 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

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

Performance Study

26

Performance StudyPerformance is studied in terms of the following costs:

CH: Handoff log management cost – sum of message transfer cost between BSs and resulting control message

CR: cost of log retrieval or log unification, a measure of recovery cost as: CR = Cost for log requests + Cost for log transfers + Cost for log unification waiting

CF: Total cost of recovering from single failure

27

Performance Study

28

Performance StudySimulation result: handoff cost with handoff rate

•CH 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

Performance StudySimulation 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

Performance StudySimulation 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

ConclusionA mobile agent-based architecture is presented to support application recovery in a mobile, wireless environmentForward strategy is aimed to reduce recovery time when failure time is nontrivialThe simulation result shows forward scheme improves recovery time with fairly consistent behavior