Recovery in the Mobile Wireless Environment Using Mobile Agents

1
Recovery in the Mobile Wireless Environment Using
Mobile Agents

• S. Gadiraju, V. Kumar
• Presented by Yamin Yu

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
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
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
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 DBSs
• No fragment of Ti is sent to other MUs for
  execution
• A 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 ejs,
  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 Specification

• H-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 Specification

• This paper uses mobile agent to manage
  application log for efficient application
  recovery in order to utilize MAs 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 HoAg
• The communication of MU and BS is through HoAg
  and CoAg

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
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_IDi(log_Sizei)

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
Forward Log Unification Scheme

• The ELUT(Estimated Log Unification Time) is
  estimated by HoAg using the Trace Info
• MaxBsi_Log_Size / Network link Speed
  Propagation Delay
• Depends on other factors same VLR or different,
  querying delay etc.
• If ELUT lt EFT, log unification is started,
  otherwise deferred until recovery call is heard

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 MUs 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
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
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
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
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 Study

• Performance 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 Study

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