update log dissemination in mobile ad hoc networks
DESCRIPTION
Update Log Dissemination in Mobile Ad Hoc Networks. Hideki HAYASHI Hitachi, Ltd., Central Research Laboratory (Grad. School of Info. Science and Tech., Osaka University) Takahiro HARA Shojiro NISHIO Grad. School of Info. Science and Tech., Osaka University. Abstract. - PowerPoint PPT PresentationTRANSCRIPT
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