Unit-5 Mobile Computing

8/3/2019 Unit-5 Mobile Computing

1/133

1


2/133

2

Mobile Database Systems (MDS)

MDS Issues Data Management

Hoarding

Data Caching

Adaptation

Transaction Management

Transaction processing

Query processing

Database recovery

To build a truly ubiquitous information processing

system by overcoming the inherent limitations of

wireless architecture.

Objective


3/133

3


A Reference Architecture (Client-Server model)

MSC MSC

DB DB HLR VLR

BSC BSC

DBS DBS

MUBS

MU

MU

BS

MU

BS

MU

Fixed host

Fixed host

PSTN


4/133

4


MDS Applications

Insurance companies

Emergencies services (Police, medical, etc.)

Traffic control

Taxi dispatch

E-commerce

Etc.


5/133

5


MDS Limitations

Limited wireless bandwidth

Wireless communication speed

Limited energy source (battery power)

Less secured

Vulnerable to physical activities

Hard to make theft proof.


6/133

6


MDS capabilities

Can physically move around without affecting data

availability

Can reach to the place data is stored

Can process special types of data efficiently

Not subjected to connection restrictions Very high reachability

Highly portable


7/133

7


8/133

8

hoarding - learning sequences

depth level 2

depth level 1

...

Starting

Page1

2

3 4

5 6 7

8 9

Web-based materials are

generally highly interlinkeda net of links

The user browsing path over a

web-based material can beviewed as a hierarchy structure

Depends on users learning

style, natural learning habitsand abilities

...


9/133

9

hoardingwhat is it? why we need it? Hoarding is a technique for selecting set of documents to be

uploaded and used when disconnected.

To allow any time, anywhere access to the learningmaterials

to support offline access of learning content

Often the memory available on the device is not large enoughto contain all material of a system

a decision should be made what to put on the device

To free the user from annoying procedures of pre-fetchingcontent

decide automatically what the user will need


10/133

10

the hoarding process1. Decide (predict) what material the learner will start from;

2. From the materials that are linked to this start pointgenerate a candidate set;

3. Predict which will be the learning sequence or set, that is ofinterest for the user at next depth level and discard the items

that are not of interest from the set (this step is calledpruning)loop until the deepest level;

4. Set priorities to the materials in the hoarding set, based ontheir predicted priority of importance for the next session(higher if the probability the object will be used soon is

high);5. Pre-fetch, starting from the beginning of the ordered list,

putting on the device those objects with bigger priority, untilavailable memory is filled in.


11/133

11

hoarding - the starting step Starting Point from site structure

Based on observations on all previous users the

system can estimate the average (or max.)

browsing depth and session length

Set of LO,

used by the student

in one session

Set of LO,

selected by the

hoarding algorithm

Set of LO, used by the

student in one session

Set of LO, selected by

the hoarding algorithm

Maximize the hit rateNumber of hits divided on number of uploaded

items

Minimize the miss ratepercentage of ineffective requests


12/133

12


13/133

13

Caching is an important technique in the computing world. Most of

us are familiar with cache used for a single processor computer, asillustrated in Figure

In distributed systems and network computing environments, cache

management schemes need to handle two different scenarios.


14/133

14

In the first scenario, the data in the shared memory or the server

can be read/written by different processors or clients concurrently,

as shown in Figure 15.2

In the second scenario the data is read-only for the clients, as

shown in Figure 15.3.


15/133

15

In these environments (distributed systems and network computing ),

when a client accesses a cached data item, the server or another client

could have just modified that data item. Hence, in distributed andnetwork computing environments, the most crucial problem for caching

is how to maintain data consistency among the clients and the servers?


16/133

16

To maintain cache consistency in distributed or network computing

environment, different approaches have been developed. These

approaches include polling-every-time, adaptive time-to-live (TTL) ,

invalidation based mechanisms.

Poll everytime


17/133

17

For the TTL-based caching strategy, every cached data item isassigned a TTL value, which can be estimated based on thedata items update history. For example, the adaptive TTLapproach in estimates TTL based on the age of a data item.When the user request arrives for a data item x, if data item xsresidence time has exceeded its TTL value, the client sends amessage to the server to ask if x has changed. Based on theservers response, the client may get a new copy of x from the

server (if the data item x has changed since the last time theclient cached x) or just use the cached copy to answer the user'srequest (if the data item x has not been modified since the lasttime the client received a copy of x).

For polling-every-time and TTL-based caching strategies, the client side

initiates the consistency verification: that is, the client is responsible for

verifying the data consistency before using it.


18/133

18

For the polling-every-time approach, every time the data is

requested, the clients need to send requests to the server to verify if

the cached data has changed. The polling-every-time caching

strategy can be thought of as a special type of TTL-based scheme,

with the TTL field equal to zero for every data item. Polling-every-

time and TTL-based approaches are used in many existing Web

caches.


19/133

19

On the other hand, for the invalidation-based strategies, the cache

consistency verification is initiated by the server. Invalidation-based

cache strategies are further classified into stateless and stateful

approaches


20/133

20

In a stateless approach, the server does not maintain information

about the cache contents of the clients (i.e., the server does not

know what data is cached or how long it has been cached by a

particular client). The stateless-based approach can be further

categorized into synchronous and asynchronous approach. In the

asynchronous approach, invalidation reports are sent out upon datamodification. In the synchronous approach, the server periodically

sends out invalidation reports, which may overlap with the previous

invalidation.

EX: State less synchronous approaches are (namely TS (time

stamps), AT (amnesic terminals) ,and SIG (signatures)


21/133

21

The AT (amnesic terminals) approach is similar to theTS approach, but the invalidation reports are the data itemIDs that have changed since the last invalidation report.

Similarly in the SIG (signatures) method, the differenceis that the server periodically broadcasts the signatures of thedata items.

In the TS (time stamps) approach, the server periodically

broadcasts the invalidation reports, which consist of data item IDs and

their last update times during the last w (where w is the invalidationwindow size) seconds. Then, based on the invalidation reports, the MH

will purge the data item from its cache or update the data items time

stamp. The MH also maintains a variable to record the last time it

received a report. If the difference between the current report time stamp

and this variable is greater than w, the MH should drop the entire cache.


22/133

22

In case of the stateful approach, the server keeps track of theinformation of the cache contents. These approaches can

also be categorized into synchronous and asynchronousapproaches. There are hardly any schemes in the statefulsynchronous category. One example for statefulasynchronous approach is proposed is AS algorithm. In that

approach, a Home Location Cache (HLC) is maintained forevery client and is used to record the data items cached bythat client and their last modification time. Based on theinformation, the server can generate invalidation reportsdedicated to a particular client cache.


23/133

23

Server is stateless (noinformation about client

cache is maintained) Invalidation reports sentregardless of whether clientshave any data in cache.

Invalidation reports sent

periodically at rate L(synchronous).

Average cache latency is L/2plus network queuing delay.

Traffic on the network is

bursty as queries areaggregated for a period oftime L.

Mobility is supported byassuming a replication ofdata across all stationarynodes (not scalable)

TS/AT

Server is stateful (HLC maintained)

Invalidation report broadcast only if

any client has valid data in cache.

Invalidation reports sent as and

when data changes (asynchronous)

Latency is governed only by the

queuing delay on the network

Queries are answered as they aregenerated

Mobility can be transparently

supported by using a mobility aware

network layer ex: mobileIP

AS


24/133

24


25/133

25


26/133

26

A Glimpse of the Future

Imagine you are a tourist in Paris

with a wearable computer

wireless access to remote services

unobtrusive heads-up display, microphone,earphones

speech for computer interactions

online language translation


27/133

27

What Makes This Science Fiction?

Lack of hardware?

No! We have what we need.

Lack of applications?

Nope - we have those too.

Need a system capable of coping with the problems of mobility

Odyssey to the rescue...

P bl i h M bili


28/133

28

Problems with Mobility

Mobile elements are resource-poor

relative to static elements of same era

weight, power, size constraints

Mobility leads to communication uncertainty

enormous variation in bandwidth & latency

intermittent connectivity

Power management is a concern

actions may have to be slowed or deferred

communication costs energy

need to rely on resources of remote servers,

but may not be able to reach them!


29/133

29

Adaptation is Key

Highly dynamic environmentadaptationkey to good performance

Who adapts?

System?

take advantage of good times

Behave ok during bad times

CODA

This paper: applications also must adapt

Change expectations depending on surrounding state

End to end argument?


30/133

30

Client Adaptation

Make mobile clients more robust by offeringadaptation

rely on servers when possible

function autonomously if needed

monitor and adjust to current conditionsChange application expectations


31/133

31

Adaptive Applications

applications consume resourcesnetwork bandwidth, CPU cycles, battery power, disk space,

$$$

resources are variable

so

applications adapt use of resources as resource

quality changes


32/133

32

Who Controls Adaptation

The Operating System?

Individual applications?

Both!

Application-Aware Adaptation


33/133

33

Application-Aware Adaptation

Application only (laissez faire)

What if different applications compete for the

resources?

OS only (application-transparent)

Does not differentiate between applications (student

viewing a video of a lecture vs. a video teleconference)

Joint responsibility in Odyssey (application-aware)

Several ways to divide the functionalityodyssey only

one


34/133

34

OdysseyA Platform for adaptive mobile data access

Built a prototype for Un*x as OS extension

Provides a small API to the application

Implementation: Need a central component for resource monitoring

and management (Viceroy)

Need data aware components that offer fidelitychoices (Wardens)


35/133

35

Odyssey Architecture

Upcalls

Interceptor

Odyssey runtime

Application

kernelTsop,

request

Video

warden

WebWarden

viceroy

Sys calls

Odyssey calls


36/133

36

Operational Model Control loop:

Select fidelity

(application)

Place request

(system call)

Detect change

Notify application


37/133

37

Agility

An Odyssey client must estimate the quality ofnetwork paths used by various applications.

Odyssey records:

Round-trip time

Throughput

Odyssey updates its estimates of latency andbandwidth once every half second.

Aside, Nobles group followed up with agility

estimation work for ad hoc networks


38/133

38

Agility (cont.)


39/133

39

Agility (cont.)


40/133

40

Stability Pursuing agility while completely

sacrificing stability can be

counterproductive.

Rapidly switching

Low-fidelity

Variable latency

Stability is properly incorporated byindividual application.

When notifying an application , the viceroy

can include information about the expected


41/133

41


42/133

42

Context-aware Computing

Beyond application-aware adaptation

Instead of adapting only to resource levels,

adapt to contexts

Context:

Enumeration-based (categories)

Role-based (roles of context in building mobileapplications)


43/133

43

Types of Context

Computing context includes network connectivity,communication costs, communication bandwidth, and localresources, such as printers, displays, and workstations

User context includes user profiles, location, and people in

the vicinity of the user Physical context includes lighting and noise levels, traffic

conditions, and temperature

Temporal context includes time of day, week, month, and

season of the year Context historyis the recording of computing, user, and

physical context over time


44/133

44

The 5 Ws

Who is the user? Who are the people with whichthe user is interacting, or who is nearby?

What is the user doing?

Where is the user? Home? Work? Bathroom?Familiar coffee shop?

When? What time is it?

Why? Why is the user performing a certain task?What is the tasks priority in the grand scheme?

Low-level vs. High-level details


45/133

45

Context Overview


46/133

46

Context-aware Requirements

Contextual sensing

detection of environmental states

Contextual adaptation

capability of the system to adapt its behavior by using contextual

information

Contextual resource discovery capability to discover available resources in an environment

Contextual augmentation

capability to associate contextual information with some digitaldata

Example: association of a particular meeting place and attendeeswith a set of minutes

Example: association of a digital photo with a specific location


47/133

47

Designing CA Applications

Build list of relevant contexts

e.g., home, office, traveling, sleeping,

Specify context-aware behaviors

Presentation of context-sensitive information

Automatic discovery of relevant objects (e.g., nearbypeople for transmission of business cards)

Modification of the physical and digital environments

Integration of application with methods forsensing context


48/133

48

Simple Example: stick-e notes Context-aware Post-it notes

Build list of relevant contexts Based on location (latitude/longitude via GPS)

Temperature, whatever else can be sensed

Specify context-aware behaviors stick-e notes pop up on a PDA when contextual info is

appropriate

Reminder to return a library book when near the library

Reminder to buy a new winter jacket when temperature dropsbelow 60F

Integration of application with methods for sensing context Most difficult part

Ubiquitous sensing of environmental characteristics, such aslocation, temperature, number of human beings nearby, the cat isnear, not widespread


49/133

49

Where Does Context Come From?

Returning to the difficulty point on the previousslide

Environmental sensors Temperature, humidity, location, noise, motion

Cat sensor

Potential need for multiple types of sensors

GPS vs. indoor location sensors

History

Recording user actions and previous contexts

Users personal computing environment Schedules, notes, address books, financial info

Need real-time analysis to provide context


50/133

50

Example: Location

Indoor locating systems

e.g., infrared or ultrasound

Wireless nanocell communication activity

Association with short-range base stations

GPS

Associations with nearby computers

Motion sensors and cameras, computer vision

Ask the user!


51/133

51

Service-oriented Architecture

Provide services to context-aware applications

Context subscription and delivery service Delivers contextual information as available

Context query service Delivers contextual information on-demand

Context transformation and synthesis services Transforms low-level contextual information (location,

temperature, lighting levels) into high-level (YOURE IN THECLOSET IN YOUR BEDROOM)

Service discovery Discovery of nearby services

Well examine service discovery protocols next!


52/133

52


53/133

53

MDS Transaction Management

A Database transaction is defined as unit of processes which

change a database from one consistent state to another

consistent state. Normally a flat transaction follows the basic

properties named as ACID (Atomicity, Consistence,

Isolation, Durability) properties. In the case of MobileTransactions, to cope with the problems of mobile

environment like handoffs, disconnections etc, ACID

properties are generally relaxed. A basic way to relax the

ACID property is to divide the transaction into various sub

transactions which can be further nested.

Transaction fragments for distribution


54/133

54

MSC MSC

DB DB HLR VLR

BSC BSC

DBS DBS

MUBS

MU

MU

BS

MU

BS

MU

Fixed host

Fixed host

PSTN

Transaction fragments for distribution.

Execution scenario: User issues transactions from his/her MU and

the final results comes back to the same MU. The user transaction

may not be completely executed at the MU so it is fragmented and

distributed among database servers for execution. This creates a

Distributed mobile execution.

D fi i i A bil i i i f


55/133

55

Definition: A mobile transaction is a transaction of

nondeterministic lifetime submitted from a mobile capable node in

a mobile environment. The mobile transaction, in general, can be

considered to consist of two components a MU component anda fixed network component. The fixed network component of the

mobile transaction may have to be partially or completely relocated

as the MU moves.

Mobile environments can be considered to be similar to highly

distributed environments in many respects. But unlike in

distributed environments, locations of some hosts are not

permanent in mobile environments. This along with the low

communication bandwidth, frequent disconnections, and high

vulnerability throws up many challenges to researchers


56/133

56

A mobile transaction (MT) can be defined as

Tiis a triple ; where

F= {e1, e2,, en}is a set of execution fragments,

L = {l1, l2,, ln}is a set of locations, and

FLM = {flm1, flm2, , flmn} is a set of fragment location

mapping where j, flmi(ei)= li

A li bl T ti M d l


57/133

57

Applicable Transaction Models

I. Open Nested Transactions

II. Split transactionsIII. Saga compensating transactions

I. Open Nested Transactions

Open Nested Transaction Model is designed for long duration

activities. These transactions typically consist of a set of sub

transactions, which can be structured as a transaction tree. The

Open Nested Transaction Model provides better support for

long duration activities. These are also ideally suited forconversational transactions.

Ex: a. Reporting and Co-Transactions approach

b. The Clustering Model etc..


58/133

58

a). Reporting and Co-Transactions: The parent transaction

(workflow) is represented in terms of reporting and co-

transactions which can execute anywhere. A reporting

transaction can share its partial results with the parent transaction

anytime and can commit independently. A co-transaction is a

special class of reporting transaction, which can be forced to wait

by other transaction.

b). Clustering: A mobile transaction is decomposed into a set of

weak and strict transactions. The decomposition is done based

on the consistency requirement. The read and write operationsare also classified as weak and strict.


59/133

59

II. Split Transactions

Split transactions or dynamically restructured transactions split a

transaction into two independent serializable transactions. The

transactions could be committed or aborted independent of each

other. The operation split-transaction can be used to split atransaction into two. The split transactions are combined together

by an inverse operation termed Join Transaction. Split transactions

are mainly designed for user controlled open-ended transactions.

Ex: Kangaroo Transaction model


60/133

60

Split Transaction Semantics

Split transaction the split-transaction operation is used to split a

transaction into a set of independent entities. It takes theread and writesets as the input and produces a split:

split-transaction ( Read(A), Write(A), Read(B), Write(B) )

Join transactionthe join-transaction operation is the inverse of thesplit-transaction operation. It takes the target transaction to which the

current transaction is to be joined as the input. Let T be the current

transaction to be joined with S. The operation join-transaction(S) joins

T with S. All data items of T are available to S after this operation. Tmay be committed or aborted depending on the fate ( Commit Or

abort) of S. The join transaction can also be extended so that the join is

done only if the target agrees on the operation too.


61/133

61

ex: Kangaroo Transaction: It is requested at a MU but processed

at DBMS on the fixed network. The management of the

transaction moves with MU. Each transaction is divided into

subtransactions. Two types of processing modes are allowed,

one ensuring overall atomicity by requiring compensating

transactions at the subtransaction level.


62/133

62

III. Sagas

Sagas are defined as a set of relatively independent transactions.

The transactions in a saga are termed as component transactions.

Each component transaction has a dual termed compensatingtransaction. A predefined order can be defined for the execution

of the saga. The transactions belonging to different sagas can be

interleaved in any fashion.


63/133

63

A h t M bil T ti M d l


64/133

64

Approaches to Mobile Transaction Models

Reporting and cotransaction

Clustering

Kangaroo

MDSTPM

Pro-Motion

Prewrite Semantic

Time-based Mobile Transaction

Two-Tier Replication

IOT Bayou

New Transaction Management System


65/133

65


66/133

66


67/133

67

Snapshot vs. Continuous Query


68/133

68

Continuous Queries

DataQuery

p Q y

Processing

Traditional (Snapshot) Queries

Data

Query

Answer

Query

Answer

Data


69/133

69


MDS Query processing

Query types

Location dependent query

Location aware query

Location independent query

Variety of Location aware Queries


70/133

70

Variety of Location-aware Queries

Query: Stationary

Object: Moving

Continuously report the number of cars in the freeway

Type: Range query

Time: Present

Duration: ContinuousWhat are my nearest McDonalds for the next hour?

Type: Nearest-Neighbor query

Time: Future

Duration: Continuous

Query: Moving Object: Stationary

Send E-coupons to all cars that I am their nearest gas station

Type: Reverse NN query

Time: Present Duration: Snapshot

Query: Stationary

Object: Moving

What was the closest dist. between Taxi A & me yesterday?

Type: Closest-point query

Time: Past

Duration: Snapshot

Query: Moving

Object: Moving


71/133

71

Location dependent query

A query whose result depends on thegeographical location of the origin of the query.

Example

What is the distance of Pune railway station

from here?

The result of this query is correct only for here.

Situation: Person traveling in the car desires to know his progress

and continuously asks the same question. However, every time theanswer is different but correct.

Requirements: Continuous monitoring of the longitude and latitude

of the origin of the query. GPS can do this.

Query Translation Steps in LDQ Processing


72/133

72

1. Determine the validity (and type) of the query and request the

location service to provide a location to which the LDQ is to be

bound.

2. Find the appropriate level of the location granularity, which

will be used by the target content provider, and convert the

query into the correct format.

3. If needed, decompose the query for different servers and send

each to the target server for processing.

4. Receive the query results and perform any needed filtering toreduce the result set size.

5. Combine results from multiple servers and put into a format

desired by user.


73/133

73


74/133

74

Agenda

Introducing fundamentals of databaserecovery and conventional recovery

protocols

Identifying those aspects of a mobile

database system which affect recovery

process

Discussing recovery approaches which

have appeared in the literature

Agenda (Cont )


75/133

75

Agenda (Cont.)

Similar to other areas such as transaction

modeling, concurrency control, etc.,

database recovery is also in thedevelopment stage, so the coverage here

is mostly limited to state-of-the art

research and little on commercialproducts

Introduction


76/133

76

Introduction

Database recovery protocols recover adatabase from transaction or system

failures

They store the database to a consistent state

from where transaction processing resumes

These failures may occur due to anumber of reasons

Addressing error , wrong input, RAM failure,

etc.

Introduction (Cont.)


77/133

77

( )

In a concurrent execution environment when a failure

occurs then a transaction may be

Active

Blocked

Being rolled back

In the middle of a commit

The task of a recovery protocol is to identify the right

operation for each transaction

1. Roll forward or Redo

2. Roll backward or Undo



78/133

78

To implement these operations, Transaction log is required

This log file is generated and maintained by the system The log contains

Committed values of data items (Before Image - BFIM)

Modified values of data items (After Image - AFIM)

The log is a crucial document for recovery

It is generated and maintained by a protocol called

Write Ahead LoggingWAL

The protocol guarantees that the content of a log is

reliable and can be used for Undo and Redo operations


79/133

79


After a failure the database system

reboots and, by using log, applies Redo

and Undo operations on transactionswhich where in the system when it failed

A Redo completes the commit operation

for a transaction, and an Undo rolls back

a transaction to maintain atomicity


80/133

80

Four different recovery protocols

Undo - Redo

This protocol applies Redo and Undo to recover the

database systems

During transaction execution it can write to the

database intermediate values of its data items

If the transaction was active when the system fails, then

the transaction is Undone

It is Redone if the transaction was ready to commit

Undo - No Redo

Does not support Redo and recovers the database by

applying Undo operation only

diff l


81/133

81

Four different recovery protocols

(Cont.) No UndoRedo

Makes sure that no intermediate results of a transaction

are installed in the database

No UndoNo Redo

This protocol does not apply Redo and Undo and

recovers the database by using the shadow copy of data

items

During execution a transaction creates a show copy of

data items it modified


82/133

82

Recovery is a time-consuming and resource-intensive

operation.

The most expensive operation is managing the log

This operation is essential for recovery

AMobile Database System (MDS) is a distributed system

based on client server paradigm, but it functions differently

than conventional centralized or distributed systems.


83/133

83

In any database management system, distributed or

centralized, the database is recovered in a similar manner

and the recovery module is as an integral part of the

database system. Database recovery protocols, are not tampered with

user level applications.

A system which executes applications, in addition to

database recovery protocol, requires efficient schemes forApplication recovery.


84/133

84

Application recovery is relatively more

complex than database recovery becauseof

The large numbers of applications required to

manage database processingPresence of multiple application states

The absence of the notion of the last consistent

state


85/133

85

This gets more complex in MDS because of

Unique processing demands of mobile units

The existence of random handoffs

the presence of operations in connected, disconnected,

and intermittent connected modes

Location-dependent logging

The presence of different types of failure.

There are types of failures

Hard failure (Can not be easily repaired)

Soft failure (Recoverable)


86/133

86

An application can be in any execution state

blocked, executing, receiving data slowly, and so on

The application may be under execution

on stationary units (base station or database server) or

on mobile units or on both

These processing units(especially the mobile unit), may be

Going through a handoff

Disconnected

In a doze mode

Turned off completely


87/133

87

The application may be processing a

mobilaction or reading some data or

committing a fragment, and so on

If a failure occurs during any of these

tasks, the recovery system must bring theapplication execution back to the point of

resumption


88/133

88

In application recovery, unlike data consistency, the

question of application consistency does not arise because

the application cannot execute correctly in the presence of

any error The most important task for facilitating application

recovery is the management of log

What is needed is an efficient logging scheme


89/133

89

Log management in mobile database

systems

Log is a sequential file where

information necessary for recovery is

recorded Each log recordrepresents a unit of

information

The position of a record in the logidentifies the relative order of the

occurrence of the event the record

re resents


90/133

90


systems (Cont.)

In legacy systems (centralized or

distributed) the log resides at fixed

locations which survive system crashes This persistence property of log is

achieved through the protocol called

Write Ahead Logging (WAL) The logging becomes complex because

the system must follow the WAL

rotocol while lo in records at various

i bil d b


91/133

91


systems (Cont.)

An efficient application recovery scheme

for MDS requires that

The log management must consume minimumsystem resources

Must recreate the execution environment as

soon as possible after MU reboots

The mobile units and the servers must

build a log of the events that change the

execution states ofmobilaction

L i bil d b


92/133

92


systems (Cont.)

The exact write events dependon the

application type

the mobile unit records events likeThe arrival of a mobilaction

The fragmentation ofmobilaction

The assignment of a coordinator formobilaction

The mobility history of the mobile unit

(handoffs, current status of the log, its storage


93/133

93

Where to Save the Log?

Schemes that provide recovery in the

PCS (Personal Communication System),

saves the log at the BS where the mobile

unit currently resides

Managing log for PCS failure is relatively

easy because it does not support

transaction processing

The concept can be used to develop

efficient lo in schemes for MDS


94/133

94

Where to Save the Log? (Cont.)

There are three places the log can be

saved:

(a) MSC (Mobile Switching Center)(b) Base Station (BS)

(c) Mobile Unit (MU)

The reliability and availability of mobileunits, make it a less desirable place to

save the log

MSC and BS are suitable laces


95/133

95


An MSC may control a large number of

BSs

in the event of a failure, accessing andprocessing the log for specific transaction

may be time-consuming

An MSC is not directly connected todatabase servers

BSs, are directly connected to DBSs and


96/133

96



97/133

97


From connectivity and availability

aspects, BSs are comparatively better

candidates for saving an application log

Under this setup a mobile unit can save

log at the current BS and the BS then canarchive it on DBSs


98/133

98

Effect of Mobility on Logging

In conventional database systems, the log

generation and its manipulation are

predefined and fixed A mobiluction may be executed at a

combination of mobile units, base stations

and fixed hosts If a fragment ofmobilaction happens to

visit more than one mobile unit, then its log

may be scattered at more than one base


99/133

99

Logging schemes

Centralized logging-Saving of log at a

designated site

A base station is designated as logging site

where all mobile units from all data regions

save their log

Since the logging location is fixed and known

in advance, and the entire log is stored at oneplace, its management (access, deletion, etc.)

becomes easier

This scheme works, but it has the following


100/133

100

Logging schemes (Cont.)

Homelogging

Every mobile unit stores its log at the base station it

initially registers

This scheme has the following limitations:

Under this scheme the entire log ofmobiluction may be

scattered over a number of base stations if its fragments

are processed by different mobile units with differentbase stations

It may not work for spatial replicas (location-dependent

data)


101/133

101


At a designated base station

Under this scheme a mobile unit locally composes the

log and, at some predefined intervals, saves it at the

designated base station At the time of saving the log a mobile unit may be in

the cell of the designated base station or at a remote

base station

In the second case, the log must travel through achain of base stations, ending up at the designated

base station

This will work as long as there is no communication

failure anywhere in the chain of base stations


102/133

102


At all visited base stations

In this scheme a mobile unit saves the log at the base

station of the cell it is currently visiting

The entire application log is stored in multiple basestations, and at the time of recovery all log portions are

unified to create the complete log

It is possible that two or more portions of the entire log

may be stored at one base station if the mobile unitrevisits the station


103/133

103

Logging schemes (Lazy Scheme)

In lazy scheme, logs are stored on the current base station

and if the mobile unit moves to a new base station, a

pointer to the old base station is stored in the new base

station These pointers are used to unify the log distributed over

several base stations

This scheme has the advantage that it incurs relatively less

network overhead during handoff as no log informationneeds to be transferred

This scheme has a large recovery time because it requires

unification of log portions (disadvantage)

Logging schemes (Lazy Scheme


104/133

104

Logging schemes (Lazy Scheme

log unification)

a) distance-based scheme

the log unification is initiated as soon as

the mobile unit covers the predefineddistance

b) frequency-based scheme

log unification is performed when thenumber of handoffs suffered by the MU

increases above a predefined value

After unif in the lo the distance or

Logging schemes (Pessimistic


105/133

105

Logging schemes (Pessimistic

scheme) The entire log is transferred at each

handoff from old to new base station

This scheme, combines logging and logunification

The recovery is fast, but each handoff

requires large volumes of data transfer

M bil D b R S h (A Th Ph


106/133

106

Mobile Database Recovery Schemes (A Three-Phase

Hybrid Recovery Scheme )

All base stations use coordinated checkpointing

communication-based checkpointing is used between

mobile units and base stations

Following steps briefly describe the working of thealgorithm

The algorithm uses mobile unitsMU1,MU2,MU3, and

MU4, as well as base stationsMSS1.MSS2, andMSS3,

for describing message traffic

M bil D t b R S h (A Th Ph


107/133

107



Initially, a coordinator (base station)MSS1broadcasts a request

message with a checkpoint index toMSS2 andMSS3

EachMSS sets up a timer Tlazy. It uses a lazy coordination scheme to

reduce the number of messages, therefore, it is especially suitable for

mobile database systems. In this approach, infrequent snapshots aretaken which only occasionally impose high checkpoint overheads of

coordinated snapshots on the low-bandwidth network connecting all

mobile units. This approach also prevents the global snapshot from

getting out of date; as a result, the amount of computation for recovery

from failure is minimized Mobile unitMU2 orMU3, whichever is active, takes a checkpoint

before message m2 or m3 arrives fromMSS2 orMSS3 during Tlazy



108/133

108



MU1 orMU4 takes a checkpoint when Tlazy has expired,

and it receives a checkpoint request fromMSS1orMSS3

MSS2 andMSS3 responds (send a response message) to

MSS1

MSS1 broadcasts a commit message to allMSSs after

receiving response messages from other base stations

MU3 migrates fromMSS3 toMSS2 and sends a message to

wakeMU4 if it is in doze mode MU2 takes a checkpoint before it disconnects itself from

the network. IfMU2 is already in disconnected mode, then

it does not take any checkpoint



109/133

109



In caseMU1 fails, it stops executing and sends a recovery

message toMSS1

MSS1 broadcasts a recovery messages to allMSSs

EachMSS sends recovery message to all itsMUs . These

MUs roll back to their last consistent state

A Mobile Agent Based Log


110/133

110

A Mobile Agent-Based Log

Management Scheme

A mobile agent is an autonomous program that can move

from machine to machine in a heterogeneous network

under its own control

It can suspend its execution at any point, transport itself toa new machine, and resume execution from the point it

stopped execution

An agent carries both the code and the application state

Actually a mobile agent paradigm is an extension of theclient/server architecture with code mobility

A Mobile Agent Based Log


111/133

111


Management Scheme (Cont.)

Some of the advantages of mobile agents:

Protocol Encapsulation Mobile agents can incorporate their own protocols in their code

instead of depending on the legacy code provided by the hosts

Robustness and fault-tolerance When failures are detected, host systems can easily dispatch agents to

other hosts

Asynchronous and autonomous execution Once the agents are dispatched from a host, they can make decisions



112/133

112



Agents do have disadvantages, and the

one which is likely to affect the logging

scheme is its high migration and machineload overhead

The present scheme uses agent services

with the only when needed approach It is not possible to develop a scheme,

which optimizes the performance at all

levels and in all different situations



113/133

113



Recovery schemes improve the

performance by targeting toMinimize the communication overhead

Minimize the total recovery time

Optimizing storage space

So on

A Mobile Agent-Based LogManagement Scheme (Cont.)


114/133

114


In MDS, the coordinator module resides in the

base station

It splits mobilaction into fragments if

necessary, and it sends some of them to a set of

DBSs

Mobilactian initiated by mobile unit may use

different kinds of commit protocols like 2-

phase commit or 3-phase commit or TCOT(Transaction Commit on Timeout)

The coordinator module needs to support all of

these



115/133

115



Some recovery schemes specify that the logs move along

with the mobile unit through a multitude of base stations

The new base stations should be able to handle the logs in

the same way as the previous one did or log inconsistencymight result

The code which are necessary for recovery and

coordination can be embedded in the mobile agents



116/133

116



The coordinator can be modeled as a mobile agent

and can be initiated by the mobile unit itself if

necessary

If during a handoff the new base station does not

support a specific logging scheme, then the agent

in the previous base station which supports this

can clone itself and the new replica can migrate tothe current base station without any manual

intervention

Architecture of Agent-Based Logging


117/133

117


Scheme

An architecture is presented where

mobile agents are used to provide a

platform for managing logging The architecture supports the

independent logging mechanisms

It is assumed that each base stationsupports the functionality of mobile

agents



118/133

118

Architecture of Agent Based Logging

SchemeThe main components of the architecture are:

Bootstrap agent (BsAg):

Any agent that wishes to recover should register with

the bootstrap agent

The base station initiates the bootstrap agent

Once loaded, this agent starts all the agents that have

registered with it

Base Agent (BaAg): This agent decides which logging scheme to use in the

current environment

Such functionality can be decided by its own

intelligence or can be given as an input



119/133

119


Scheme (Cont.)

Home Agent (HoAg):

This agent handles mobilactions for each mobile unit

It is responsible for maintaining log and recovery

information on behalf of the mobile unit The mobile unit sends log events to this agent

The HoAg is a base station interface to the mobile unit

forMobilactions

Coordinator Agent (CoAg):

This agent resides at base station and acts as the

coordinator for all mobilactions



120/133

120


Scheme (Cont.)

Event Agent (EvAg):

registration of a mobile unit

failure of a mobile unit

handoff of a mobile unit

This approach abstracts away the core base station

functions from application recovery support

Driver Agent (DrAg):

The migration of a mobile agent during a handoff

involves the movement of its code and the actual data

This might generate considerable overhead, even if the

actual log transfer is not much

Interaction Among Agents for Log


121/133

121


Management

Interaction of CoAg and HoAg

An MU sends Mobilaction to its HoAg, which forwards

it to the corresponding CoAg. If the CoAg needs to

contact the MU, it does so through the MUS

corresponding HoAg. When CoAg sends a write eventto the HoAg, it stores it in its local store before sending

it to the MU.

If any events come to the MU through user input, MU

sends the corresponding log messages to the HoAg.



122/133

122


Management (Cont.)

Action of agents when handoff occurs

The HoAg moves along with the mobile unit to the new base

station in a handoff

When a handoff occurs, a driver agent (DrAg) is sent along with

the necessary log information to the new base station instead of the

whole HoAg with all its intelligence for log unification

The DrAg has a very light code whose main function is to see

whether the code for HoAg is present in the new base station

If so, it requests the resident BaAg in the new base station to

create an instance of the HoAg for the mobile unit

If any compatible code is not present, then the DrAg sends a

request to the previous base stations BaAg, which clones the

necessary HoAg and sends the copy to the new base station

Forward Log Unification


123/133

123


Scheme Since the trace information contains the size of the log

stored at different base stations, the HoAg can estimate the

time for log unification based on the network link speed

and the total log size (Estimated Log Unification Time -ELUT)

This scheme concentrates on such scenarios where the EFT

is not so trivial that the recovery occurs instantaneously

Base station detects the failure of a mobile unit and agentsdo not play any part in such detection



124/133

124

o wa d og U cat o

Scheme (Cont.)

Log unification is started if(* ELUT)

EFT

The Unification factor describes whatfraction of the log unification will be

done by the time the failure time of the

mobile unit comes to an end The default value can be kept as 1

F d N tifi ti S h


125/133

125

Forward Notification Scheme

This scheme addresses the issue of time spent

in getting the previous base station information

from the HLR

To minimize this time, a scheme involving

forward notifications is proposed

When a mobile unit fails in a particular base

station and if the actual failure time is not too

high, then there is a high probability that the

mobile unit will recover in the same VLR or in

a BS that is in adjacent VLRs

Forward Notification Scheme


126/133

126

(Cont.) If the mobile unit happens to restart in a non-adjacent

VLR, then it must have been extremely mobile and most of

the recovery schemes are not designed for such unrealistic

situation It is likely that the coordinator could have decided to abort

the mobilaction

When a mobile unit fails, its corresponding HoAg informs

the VLR about this failure


127/133

127

The VLR first changes the status of the

mobile unit in its database from normal

to failed The VLR then issues a message

containing its own identity

The adjacent VLRs store these messagesuntil explicit denotify messages are

received


128/133

128

Case 1-The mobile unit reboots in the

same base station where it crashed :

In this scenario, the HoAg informs the VLRthat the mobile unit has recovered

The VLR then issues a denotify message to all

the adjacent VLRs indicating that the forward

notification information is no longer valid

The status of the mobile unit is changed back to

normal from failed


129/133

129

Case 2-The mobile unit reboots in a different base station

but in the same VLR:

First the mobile unit registers with the base station and

the registration message is logged on to thecorresponding VLR

This VLR identifies the status of the mobile unit as

failed, and then it proceeds as in case 1 and sends

denotify messages to the adjacent VLRs The status of the mobile unit is changed back to normal

from failed

The new base station then proceeds to perform log

unification from the previous base station

Case 3-The mobile unit reboots in a different base stationand a different VLR:

The mobile unit requests for registration


130/133

130

The mobile unit requests for registration

The corresponding VLR identifies the mobile unit as a

forward notified mobile unit and returns the identity ofthe previous base station and the identity of the VLR to

the HoAg of the mobile unit in the recovered base

station

The base station then proceeds to perform logunification from the previous base station

Simultaneously, the new VLR sends a recovered

message to the previous VLR regarding the recovered

status of the mobile unit and also sends a registrationmessage to the HLR regarding the registration of the

mobile unit in the new location

The status of the mobile unit is changed to normal from

forwarded in the new VLR

U i i h d h i


131/133

131

Upon receiving the recovered message, the previous

VLR sends a denotify message to all adjacent VLRs

except the one in which the mobile unit recovered andremoves the registration of the mobile unit from itself

as well

In the situation where the mobile unit recovers in a

nonadjacent VLR that has not received the forwardnotifications, the new base station has to get the

previous base station information from the HLR and

then send the previous VLR a recovered message

Upon receiving this message, the previous VLR actssimilar to the previous VLR of case2

The forward notification scheme is unsuitable if the

mobile unit suffers failures with a very smallEFT

SUMMARY


132/133

132

the entire process of chekpointing andlogging for recovery are comparatively

complex than conventional database

recovery There are still quite a few research

problems need innovative solutions

Until they are resolved the mobiledatabase system will continue to remain

in research domain


133/133

Unit-5 Mobile Computing

Documents

Transcript of Unit-5 Mobile Computing