Update Log Dissemination in Mobile Ad Hoc Networks

Update Log Dissemination in Mobile Ad Hoc Networks

Hideki HAYASHIHitachi, Ltd., Central Research Laboratory

(Grad. School of Info. Science and Tech., Osaka University)

Takahiro HARA Shojiro NISHIOGrad. School of Info. Science and Tech., Osaka University

Abstract

Replication to improve data accessibility is important.

MH cannot verify whether own replica is same version as original due to network partitions.– Tentatively accesses replicas– Verifies access validity from update logs.

Our methods improve data accessibility and reduce time for verifying access validity.

Update log dissemination methods• Mobile host (MH) can efficiently verify the validity

of tentative accesses to replicas.

Contents Background and motivation Update log dissemination methods Performance evaluation Conclusions

Background Recent advances in radio communication and

computer technologies– Development of mobile computing environments

Mobile ad hoc networks– Every MH plays a role of a router and communicates

with each other.

1

Data Access

Request 1

Data sharing applications Collaborative works (Ex. Rescue activity)

– Mobile users share their work information for efficient work.

Inter-vehicle communication– Vehicles share traffic information for safe

driving.

Motivation Network partition frequently occurs due to

host mobility.– Data accessibility becomes lower.

1

1

Replica

Replication improves data accessibility.

Disconnection

Original

Research issue (1/2) Replica allocation in ad hoc networks [Hara01]

– Assume that data items are not updated.– Consider access frequencies and network topology.

Real environment: data items are updated.– MH cannot verify whether own replica is same version

as original due to network partitions.• Tentatively accesses replica.

• Verifies access validity from update logs when connecting to original holder (MH holding original).

Research issue (2/2) MHs cannot necessarily connect to original holders.

– Cannot verify the access validity.Low data accessibility.

– Verify after long time even if connecting.Long time for verifying access validity.

[Goal]– MHs efficiently verify the validity of tentative

accesses to replicas.

[Approach]– Manage access logs and update logs.– Send update logs to other hosts as needed.

Assumptions (1/2) Data item is updated by original holder.

– After data item is updated, its replicas become invalid.

MH queries data item with flooding when requesting.– Original: Request immediately succeeds.– Replica: MH tentatively accesses.

1

OriginalQuery

Request 1

2

Replica

ReplyAccess

Data request host

Assumptions (1/2)

1 Query

Reply

TentativeAccess

Request 2

2

Original Replica

Data request host

Data item is updated by original holder.– After data item is updated, its replicas become invalid.

MH queries data item with flooding when requesting.– Original: Request immediately succeeds.– Replica: MH tentatively accesses.

Assumptions (2/2) After tentative accesses, MH refers to update

logs and verifies access validity.– Tentative access is valid (successful):

MH accessed replica with same version as original at time MH accessed the replica.

– MHs time out tentative accesses if it cannot verify within certain period.

Valid

Current145

Time

Update(80)

Update(120)

Access(95, 80)

Access(130, 80)

Invalid（ TS: Time stamp ）

（ Access time, TS ）

Valid

Access(110, 80)

Update log dissemination methods Management of access logs and update logs.

– Access log: when & which version MH accesses.– Update log: when MH updates data item.

Dissemination by original holderULD-DA (Update Log Dissemination on Data Access)

• Original holder sends update logs to data request host.ULD-DA+

• Data request host sends update logs to nearby hosts.

Dissemination by other hostsULD-C (ULD on Connection)

• When newly connected, MHs send update logs to originally connected MHs.

Management of access logs MH records access log when tentatively

accessing replica.

Data ID Access log (access time, TS, # of update times)

1 110, 90, 3

137, 90, 3

185, 90, 3

…

2 95, 80, 2

123, 80, 2

130, 80, 2

…

… …

Access history table

Dissemination by original holders

MH records update log when updating original.

Data ID Update log (TS, # of update times)

1 35, 1

70, 2

90, 3

128, 4

169, 5

…

… … Original holder sends to data request host.

– Data request host requests to original holder when detecting connection to original holder by flooding.

ULD-DA (Update Log Dissemination on Data Access)

• Original holder sends to data request host. ULD-DA+

• Data request hosts send to nearby MHs.

Update history table

ULD-DA method Original holder sends to data request host.

1

Update history

Access history

Data ID Update log (TS, # of update times)

A 1 35, 1 70, 2 90, 3 128, 4 169, 5 192, 6

Data ID Access log (access time, TS, # of update times ）E 1 95, 90, 3 131, 90, 3 145, 90, 3 183, 169, 5

A

B

C

D E

G

Update log request

Update log

Data ID Access log (access time, TS, # of update times ）E 1 95, 90, 3 131, 90, 3 145, 90, 3 183, 169, 5

F

MHs cannot verify if not requesting data item.

Long time for verifying access validity.

MHs cannot verify if not requesting data item.

Long time for verifying access validity.

Original

NDA=1

Data request host sends to MHs within NDA hops.

ULD-DA+ method

Data ID Access log (access time, TS, # of update times)

D 1

E1 95, 90,

3131, 90, 3 145, 90, 3 183, 169, 5

F 1 104, 90, 3 145, 90, 3 190, 90, 3G 1 150, 169, 5 198, 169, 5

Data ID Access log (access time, TS, # of update times)

D 1

E1 95, 90,

3131, 90, 3 145, 90, 3 183, 169, 5

F 1 104, 90, 3 145, 90, 3 190, 90, 3G 1 150, 169, 5 198, 169, 5

Data ID Access log (access time, TS, # of update times)

D 1

E1 95, 90,

3131, 90, 3 145, 90, 3 183, 169, 5

F 1 104, 90, 3 145, 90, 3 190, 90, 3G 1 150, 169, 5 198, 169, 5

1A

B

C

D E

F

G

Update log request

Update log

Update history

Access history

Data ID Update log (TS, # of update times)

A 1 35, 1 70, 2 90, 3 128, 4 169, 5 192, 6

Shorter time for verification than ULD-DAShorter time for verification than ULD-DA

Original

Dissemination by other hosts MH cannot necessarily connect to original

holder.– In ULD-DA/DA+, not necessarily verify access

validity.

manages update logs of any data items. ULD-C (Update Log Dissemination on Connection)

– Newly connected MHs compare update history tables and insert update logs.

• Send inserted update logs to MHs within NC hops.

– ULD-C is used together with ULD-DA/DA+.

NC=1

Data ID Update log (TS, # of update times)

D1 35,

170, 2

128, 4

169, 5 192, 6

E1 35,

170, 2

90, 3 128, 4 192, 6

Update history

ULD-C method Newly connected MHs compare update history

tables.– Send inserted update logs to MHs within NC hops.

Update log{169, 5}

{90, 3}

{90, 3}

Update history table

A

B

C

D E

G

Connection

F

Large traffic because of sending update

history tables.

Large traffic because of sending update

history tables.

Data ID Update log (TS, # of update times)

D1 35,

170, 2

128, 4

169, 5 192, 6

E1 35,

170, 2

90, 3

128, 4 169, 5

192, 6

Data ID Update log (TS, # of update times)

D1 35,

170, 2

90, 3 128, 4 169, 5

192, 6

E1 35,

170, 2

90, 3 128, 4 169, 5

192, 6

Traffic reduction in ULD-C method One of newly connected MHs sends sum of TSs

(TS aggregation) in update logs for data item. The other host requests update history whose TS agg.

is different from its calculated value.

Data ID

Update log (TS, # of update times) TS agg.

D 1 35, 1

70, 2

128, 4

169, 5 192, 6 594

E 1 35, 1

70, 2

90, 3

128, 4 192, 6 515

NC=1 TS agg.

A

B

C

D E

G

Connection

F

Update history request

Update history

Performance evaluation (1/2) Simulation environments

– Area size: 500[m] x 500[m]– Number of MHs: 40

• Mobility model: random way point– Speed: 0~1[m/sec], Pause time: 0~1,000[sec]

• Radio communication range: 70[m]• Enough memory space for all data items

– Number of data items: 40 (Size: 1[MB])

– System parameters: NDA=2, NC=2

Performance evaluation (2/2) Performance metrics

– Data accessibility• Rate of number of successful accesses to number

of all requests.

– Average waiting time• Average time for verifying access validity.

– Traffic• Product of total hop counts to send update logs

and sizes.

Effects of average update period (1/3)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 500 1000 1500 2000 2500 3000 3500 4000Average Update Period [sec]

Dat

a Ac

cess

ibili

ty

ULD-DAULD-DA+ULD-C(DA)ULD-C(DA,Agg)ULD-C(DA+)ULD-C(DA+,Agg)No Rep

Good

ULD-DA: Only original holdersULD-DA+: Original holders + data request hostsULD-C: Newly connected MHs

0

200

400

600

800

1000

1200

0 500 1000 1500 2000 2500 3000 3500 4000Average Update Period [sec]

Ave

rage

Wai

ting

Tim

e [s

ec]

ULD-DAULD-DA+ULD-C(DA)ULD-C(DA,Agg)ULD-C(DA+)ULD-C(DA+,Agg)No Rep

Effects of average update period (2/3)

Good

ULD-DA: Only original holdersULD-DA+: Original holders + data request hostsULD-C: Newly connected MHs

0.0E+00

5.0E+07

1.0E+08

1.5E+08

2.0E+08

2.5E+08

0 500 1000 1500 2000 2500 3000 3500 4000

Average Update Period [sec]

Tra

ffic

ULD-DAULD-DA+ULD-C(DA)ULD-C(DA,Agg)ULD-C(DA+)ULD-C(DA+,Agg)No Rep

Effects of average update period (3/3)

Good

ULD-DA: Only original holdersULD-DA+: Original holders + data request hostsULD-C: Newly connected MHs

Considerations from results Combination of ULD-C and DA+ methods

– High data accessibility.– Short time for verifying access validity.

Suitable for improving work efficiency in collaborative work.

ULD-DA / DA+ method– Small traffic

Suitable for low battery capacity

Conclusions Update log dissemination methods Simulation experiment

– Our methods improve data accessibility and reduce time for verifying access validity.

[Future work]– Extend ULD-C method for reducing traffic