Recovery in the Mobile
Wireless Environment
Using Mobile Agents
S. Gadiraju, V. Kumar
Presented by Yamin Yu
1
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
2
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
3
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
4
Reference of Architecture of
MDS and Transaction Execution
5
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
6
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
7
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.
8
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.
9
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
10
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
11
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
12
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
13
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 HMU, responsible for maintaining and recovery
information on behalf of H-MU
14
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
15
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.
16
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)
17
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
18
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
19
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)
20
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
21
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.
22
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
23
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
24
Performance Study
25
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
26
Performance Study
27
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
28
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
29
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
30
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
31