1. 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

2. 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.

3. Contents Background and motivation Update log dissemination methods Performance evaluation Conclusions

4. 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

5. 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.

6. Motivation Network partition frequently occurs due to host mobility. –Data accessibility becomes lower. 1 1 Replica Replication improves data accessibility. Disconnection Original

7. 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).

8. 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.

9. 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 Original Query Request 1 2 Replica Reply Access Data request host

10. Assumptions (1/2) 1 Query Reply Tentative Access 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.

11. 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 Current 145 Time Update (80) Update (120) Access (95, 80) Access (130, 80) Invalid （ TS: Time stamp ） （ Access time, TS ） Valid Access (110, 80)

12. 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 holder  ULD-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 hosts  ULD-C (ULD on Connection) When newly connected, MHs send update logs to originally connected MHs.

13. Management of access logs MH records access log when tentatively accessing replica. Data IDAccess log (access time, TS, # of update times) 1 110, 90, 3137, 90, 3185, 90, 3 … 2 95, 80, 2123, 80, 2130, 80, 2 … …… Access history table

14. Dissemination by original holders MH records update log when updating original. Data IDUpdate log (TS, # of update times) 1 35, 170, 290, 3128, 4169, 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

15. ULD-DA method Original holder sends to data request host. 1 Update history Access history Data IDUpdate log (TS, # of update times) A135, 170, 290, 3128, 4169, 5192, 6 Data ID Access log (access time, TS, # of update times ） E195, 90, 3131, 90, 3145, 90, 3183, 169, 5 ABCDEG Update log request Update log Data ID Access log (access time, TS, # of update times ） E195, 90, 3131, 90, 3145, 90, 3183, 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

16. N DA =1 Data request host sends to MHs within N DA hops. ULD-DA+ method Data IDAccess log (access time, TS, # of update times) D1 E195, 90, 3131, 90, 3145, 90, 3183, 169, 5 F1104, 90, 3145, 90, 3190, 90, 3 G1150, 169, 5198, 169, 5 Data IDAccess log (access time, TS, # of update times) D1 E195, 90, 3131, 90, 3145, 90, 3183, 169, 5 F1104, 90, 3145, 90, 3190, 90, 3 G1150, 169, 5198, 169, 5 Data IDAccess log (access time, TS, # of update times) D1 E195, 90, 3131, 90, 3145, 90, 3183, 169, 5 F1104, 90, 3145, 90, 3190, 90, 3 G1150, 169, 5198, 169, 5 1 ABCDEFG Update log request Update log Update history Access history Data IDUpdate log (TS, # of update times) A135, 170, 290, 3128, 4169, 5192, 6 Shorter time for verification than ULD-DA Original

17. 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 N C hops. –ULD-C is used together with ULD-DA/DA+.

18. N C =1 Data IDUpdate log (TS, # of update times) D135, 170, 2128, 4169, 5192, 6 E135, 170, 290, 3128, 4192, 6 Update history ULD-C method Newly connected MHs compare update history tables. –Send inserted update logs to MHs within N C hops. Update log {169, 5} {90, 3} Update history table ABCDEG Connection F Large traffic because of sending update history tables. Large traffic because of sending update history tables. Data IDUpdate log (TS, # of update times) D135, 170, 2128, 4169, 5192, 6 E135, 170, 290, 3128, 4169, 5192, 6 Data IDUpdate log (TS, # of update times) D135, 170, 290, 3128, 4169, 5192, 6 E135, 170, 290, 3128, 4169, 5192, 6

19. 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 IDUpdate log (TS, # of update times)TS agg. D135, 170, 2128, 4169, 5192, 6594 E135, 170, 290, 3128, 4192, 6515 N C =1 TS agg. ABCDEG Connection F Update history request Update history

20. 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: N DA = 2, N C = 2

21. 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.

22. Effects of average update period (1/3) Good ULD-DA: Only original holders ULD-DA+: Original holders + data request hosts ULD-C: Newly connected MHs

23. Effects of average update period (2/3) Good ULD-DA: Only original holders ULD-DA+: Original holders + data request hosts ULD-C: Newly connected MHs

24. Effects of average update period (3/3) Good ULD-DA: Only original holders ULD-DA+: Original holders + data request hosts ULD-C: Newly connected MHs

25. 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

26. 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