Update Log Dissemination in Mobile Ad Hoc Networks

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 • Update log dissemination methods • Mobile host (MH) can efficiently verify the validity of tentative accesses to replicas. • Replication to improve data accessibility is important. • MHcannot 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.

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

4. Data Access 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. 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. Replica Disconnection Original Replication improves data accessibility.

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

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

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

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. Access history table

14. Dissemination by original holders • MH records update log when updating original. Update history table • 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.

15. Update log request A B C D E G F Update log ULD-DA method MHs cannot verify if not requesting data item. Long time for verifying access validity. • Original holder sends to data request host. Original Update history Access history

16. Update log request Update log A B C D E F G ULD-DA+ method Shorter time for verification than ULD-DA • Data request host sends to MHs within NDA hops. NDA=1 Original Update history Access history

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 NC hops. • ULD-C is used together with ULD-DA/DA+.

18. Update history table A G E D C F B {90, 3} ULD-C method Large traffic because of sending update history tables. • Newly connected MHs compare update history tables. • Send inserted update logs to MHs within NC hops. NC=1 Connection Update log {169, 5} {90, 3} Update history

19. TS agg. A B C D E G F Update history request 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. NC=1 Connection 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: NDA=2, NC=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) ULD-DA: Only original holders ULD-DA+: Original holders + data request hosts ULD-C: Newly connected MHs Good

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

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

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