1. A STUDY OF RECOVERY OF APPLICATION IN MOBILE
WIRELESS ENVIRONMENT USING MOBILE AGENTS
Miss.T.Priya1, Mrs.R.Renuka M.E.2
1. II year M.E. (computer science and Engineering)
{tpriya_vlb@rediffmail.com, haripriya_vlb@yahoomail.com}
2. Lecturer, Department of CSE, KSRCT
Abstract-The geographical mobility of the mobile devices makes the application recovery
complex which needs to store application log for the recovery of the application.
This paper focuses the application log management using the mobile agents.
Index Terms-MDS, mobile agents, PCS, coordinators, log unification, application recovery
1 INTRODUCTION
Wireless communication through PCS transaction to nodes, transaction
execution, and updation of results from
(Personal Communication Systems) or
clients to server. The recovery recreates
GSM (Global System for mobile
the module to the prior failure execution
Communications) has become the
state of the application.
essentials of day-to-day life. Today all
Application recovery is complex than
telecommunication companies improve
the database recovery due to the
the communication quality, availability,
following reasons:
reliability, security to add the data
1. Presence of multiple application
management capabilities in the MDS
states
(Mobile Database Systems).MDS is a
2. Absence of last consistent state.
database system which reach the data
3. Large no of application required to
location and perform the processing and
manage database processing.
deliver the results since each mobile units
This becomes more complex in MDS
will have high work load so these MDS
due to
will be a useful resource to perform
1. Processing demands of mobile units.
transactions.
2. Existence of random handoffs.
To perform the system-level functions
3. Presence of operations connected,
MDS may require different transaction
disconnected, intermittent connected
management techniques (concurrency
modes.
control, database recovery, query
In this logging scheme we store,
processing), different caching schemes
retrieve, unify fragments of application
etc.
log for recovery with in the constraints of
Application recovery includes number
the MDS.
activities like transaction arrival,
fragmentation and distribution of

2. 2 REFERENCE ARCHITECTURE OF Fig. 1 shows the reference architecture of
MOBILE DATABASE SYSTEM AND MDS which is based on PCS or GSM.
TRANSACTION EXECUTION
Fig. 1 shows the reference architecture of The mobile transaction model is
MDS which is based on PCS or GSM. referred to as “mobilaction”. Mobil
action is defined as Ti= {e1, e2.., en}
where a transaction Ti is requested at MU
is called as H-MU (home MU) and is
fragmented and are execute at MU. In the
When the H-MU suffers handoff means
the CO also changes this increases the
time to commit. So the CO module can
be housed either in BS, MU, DBS, and
MSC. But selection of MU is not a good
choice due to the following limitations:
1. Limited storage.
2. Limited power supply.
3. Unpredictable handoffs.
4. Limited availability.
3 RECOVERY PROBLEM
SPECIFICATION
MDS recovery is complex due to the
following reasons:
1. MU’s stability: The MU may
Fig. 1 Reference architecture of MDS encounter some of the following
failures limited battery power, run
A set of general purpose computers are out of disk space, user physically
categorized as fixed hosts and BS (Base drop the MU. So any of these
Station).one or more BS are connected to events may affect the MU
the BSC (Base Station Controller).BSC functionality and recovery
coordinates operations commanded by algorithm must take all these in to
the MSC (Mobile Switching Center). consideration.
The size of the cell depends on the 2. Limited wireless bandwidth:
power of the BS and also the bandwidth During the recovery MU have to
of wireless communication channels.. A communicate with the BS or with
DBS provides full database services it other MU so in that time if there are
communicates with MU through the BS no free channels it affects the
and it is installed in either BS or FH.A communication quality.
MU cannot provide a reliable storage so 3. Random Handoff: This affects the
for recovery it relies on either BS or FH. recovery since the location of the
But to support these activities BS has to MU is not available immediately
be entirely modified so we create DBS as for the communication.
separate nodes in wired network that 3.1 Application Log Management
could be reached by any BS at any time. An efficient recovery scheme should
consume minimized resources and

3. recreate the execution environment as have registered with it. When the
soon as possible after MU reboots. agents are started they read the
Messages that change the contents of log information created and act
the log are called write events. The H- accordingly.
MU records the events like • Base Agent (BaAg): This agent
1. The arrival of Ti decides which logging scheme to
2. Fragmentation of Ti be used for the current
3. Assignment of CO to a Ti environment. The BA creates an
4. Mobility history of H-MU. instance of an agent to handle
5. Dispatch of the updates to the DBS. recovery of mobilactions for each
The objective of using mobile agents MU.
with the MDS is to • Home Agent (HoAg): This agent
1. Reduce communication overhead. handles Mobilactions for each H-
2. Recovery time should be minimal. MU. It is responsible for
3. Easy implementation of recovery maintaining log and recovery of
schemes. H-MU.
4 A MOBILE AGENT-BASED LOG • Coordinator Agent (CoAg):
MANAGEMENT SCHEME This is a coordinator residing in
A Mobile agent is an autonomous BS.
program that suspend the execution at • Event Agent (EvAg): There are
any point and resume execution from various events taking place like
where is stopped in the new machine. An registration of a MU, failure of
agent carries both code and the MU, handoff of MU etc. When
application state. Some of the advantages any MU suffers from handoff it
of the mobile agents are: can be known by the HoAg
1. Protocol Encapsulation: Mobile through this EvAg only to take
agents contain own protocols in their necessary action.
code itself. • Driver Agent (DrAg): During
2. Robustness and Fault Tolerance: the migration of the mobile agents
When failures are detected host we need to transfer the code and
system can easily dispatch the agents actual data this increases the
to the other hosts for the recovery. overhead to manage this we use
3. Asynchronous and Autonomous driver agent (DrAg).
Execution: Once agents are 4.1 Action of Agents When Handoff
dispatched they can make the Occurs
decisions independently. The HoAg moves along with the MU to the
These agents do have disadvantages new BS instead of sending all its code we
where high migration leads to machine send driver agent when handoff occurs. The
overhead. So this must be minimized. DrAg checks whether the code for the HoAg
In this architecture we have the following is present in new BS or not .If code is present
agents and their logical functions: it requests the BaAg in new BS to create an
instance of HoAg for this MU. If it is not
• Bootstrap Agent (BsAg): This
present DrAg sends request to previous BS’s
agent addresses a BS failure. BaAg to take clone of HoAg and send the
When a BS fails it registers in copy to the new BS to continue its operation.
bootstrap agent. Once loaded this
agent starts all the agents that

4. When MU moves out the BS its unification of the log. This is called as
information are not deleted automatically Estimated Log Unification Time (ELUT)
until it is notified by the agents of the MU. Max{BSi-LogSize/network link
speed+propagation Delay}
5 FORWARD STRATEGY It also depends on the factors like
The time duration between the MU whether BS is located in the same or
failing and rebooting is called as different VLR.
Expected Failure Time (EFT). When a 5.2 Forward Notification Scheme
MU suffers from a handoff the This calculates the time spent in getting
communication with the last BS is BS information from the HLR. Each
disconnected only after the connection VLR stores MU’s status information
with the new BS so this allows the MDS (normal, failed, forwarded).when a MU
to detect the failure of the MU. MU is fails the BS informs the VLR.VLR
monitored by the BS and any change in changes the status of the MU in database
the situation of the MU is registered in from normal to failed. The VLR sends
EvAg this makes the EFT value the information to all adjacent VLR they
appropriate. When the new BS does not store the message until they receive the
know the location of old Bs it is obtained denotify messages.
from the HLR. If the HLR is far away it Case 1: The MU reboots in the same BS
is obtained from the VLR if both BS fall where it failed.
same under the control of VLR.If VLR issues denotify message to
different VLR then HLR should be all VLRs.
queried. If a MU crashes then the Case 2: The MU reboots in a different BS
recovery of different BS needs the new but in same VLR.
BS to wait until the log unification in the MU register in Bs and notified to
old BS finishes. VLR.
In this we provide two schemes to Case 3: The MU reboots in a different BS
and a Different VLR.
reduce the recovery time by unifying the
log information periodically when the The MU requests for the
number handoffs occurred crosses a registration then the VLR returns the
predefined handoff threshold .when a identity of the previous BS and the
handoff occurs the trace is transferred identity of the VLR to the HoAg of the
from old BS to new B. The trace contains MU in recovered BS. The BS perform
BS_ID of the new BS and log size. The log unification from the previous BS and
log size updated when MU presents a new VLR sends recovery message to
information. previous VLR and registration message
The another scheme is to store the EFT of the MU in the new location to the old
value in a variable when a MU fails it HLR. After receiving recovered message
intimates the agent framework through VLR sends denotify message to all
the event agent interface which starts adjacent VLRs except the MU recovered
EFT clock and stopped to get recovery and removes its registration.
time.
5.1 Forward Log Unification Scheme
When a MU fails the trace information 6 CONCLUSION
contains the log size stored in different In this paper we present the application
BS’s. The HoAg based on the log size it recovery using mobile agents. Forward
calculates the time needed for the

5. strategy reduces the recovery time with
consistent behavior in all parameters.
REFERENCES
[1 ] A.Acharya and B.R.
Badrinath,”Checkpointing Distributed
Applications on mobile
computers.”Proc. Third Int’l conf.
parallel and Distributed Information
Systems, pp. 73-80,1994.
[2] J.Kiniry and D.Zimmerman,”A Hands-
on Look at Java Mobile Agents,”IEEE
Internet computing,vol. 1,no. 4,pp.
21-30,1997.
[3] D.B.Lange and M.Oshima,”Seben Good
reasons for Mobile Agents,”comm..
ACM,vol. 42,no. 3,1999.
[4] C.Perkins,”Mobile Networking through
Mobile IP,”IEEE Internet Computing,pp.
58-69,Jan.1998.
[5] P. Krishna,N.H.Vaidya,and
D.K.Pradhan,”Recovery in Distributed
Mobile Environments,”proc.IEEE
workshop Advances in parallel and
Distributed Systems,Oct.1993.

6. A STUDY OF RECOVERY OF APPLICATION IN MOBILE
WIRELESS ENVIRONMENT USING MOBILE AGENTS
Paper Submitted By
T.Priya B.Tech
II year M.E. (Computer Science and Engineering)
K.S.Rangasamy College of Technology,
Tiruchengode,
TamilNadu
Guided By
Mrs.R.Renuka M.E.
Lecturer, KSRCT,
Tiruchengode,
TamilNadu