LORD is a locality-based distributed data search system proposed for large-scale, highly mobile wireless networks. It divides the network area into geographic regions and uses region-based geographic routing for data publishing and querying. Each region is managed by a landmark node. LORD employs parallel file fetching, back-tracking on node mobility, and coloring-based partial replication of metadata to achieve scalability, mobility resilience, and low overhead. Evaluation shows LORD outperforms other approaches in success rate, path length, and overhead.

1. WELCOME
1

2. ALEESHA NOUSHAD
ROLL NO : 6
S7 CSE
CEMP
2

3. CONTENT
 Introduction
 LORD Data Search System
 File Querying in LORD
 Area Partition
 Region Based Data Publishing and Querying
 Region Based Geographic Routing
 Parallel File Fetching algorithm
 Back-Tracking Algorithm
 Colouring Based Partial Replication
 Performance Evaluation
 Conclusion
 References
3

4. INTRODUCTION
• Recent technical advancements have enabled the
development of large scale wireless network.
 An important issue in recent wireless networks is
data search.
 To build a scalable and mobility-resilient distributed
data search system for large scale highly mobile and
dense wireless networks,we propose
 A LOcality based distRibuted Data Search System
(LORD).
4

5. LORD Data Search System
 LORD divides the entire wireless network area into
number of geographic regions.
 LORD has a Region-based Geographic Routing
(RGR) protocol for data publishing and querying.
 LORD uses
* Parallel File Fetching Algorithm.
* A Back-Tracking Algorithm.
* Coloring Based Partial Replication Algorithm.
5

6. File Querying in LORD
Steps of File Querying in LORD
1. Metadata Publishing.
2. Metadata Querying.
3. Metadata Replying.
4. File Querying.
5. File Replying.
6

7. File Querying in LORD
7

8. Area Partition
• LORD divides the entire area into a number of
regions.
• A Region is the neighboring zone in transmission
range of a landmark and centered by the landmark.
• Each region is identified by an assigned integer
number.
• Number of landmark is determined by
a) Transmission Range.
b) Size of entire area.
8

9. Region Based Data Publishing
and Querying
• LORD uses Hash function to hash a file to store the
metadata.
• A file’s keywords can be its file name.
• A File host publishes the metadata to the mapped
Region.
• To query a file , it calculates the co-ordinate of the
file’s metadata and sent request to destination.
9

10.  Data Mapping Update And Location Update
• A Node conducts updates only when it moves from
one region to another.
• It drops all old region’s metadata.
• Accquire all metadata in the new region from new
neighbor.
• Conducts location updates by sending message to
mapped regions of it’s file’s metadata.
10

11. Region Based Geographic
Routing
 LORD propose Region Based Geographic
Routing(RGR) to forward messages to their
destination.
 RGR Routes the message along a shortest path
 RGR only needs Angle Of Arrival(AOA),which will be
the tight bound of message transmission.
 A landmark always located in the center of region.
11

12.  Ri -Source region.
 Rj -Destination region.
 Angle between leftmost vertex
of Ri to the leftmost and
rightmost vertices of Rj is
leftside angle range[α,β]
 Angle between rightmost
vertex of Ri to the leftmost and
rightmost vertices of Rj is
rightside angle range[θ,τ]
12

13.  Routing to destination region.
• When a node initiates or receives a message ,it
calculate its region’s LR and RR.
• If the node is left of the landmark.
• It choose the farthest node within the [α,β] as next
hop.
• If the node is right of the landmark.
• It choose the farthest node within the [θ,τ] as next
hop.
13

14.  Routing in destination region.
• If the message is
- metadata query :- continously forwarded.
-metadata publishing :- broadcast to all nodes.
-metadata reply :- target to only file requester.
-file query :- target the file host.
14

15. Parallel File Fetching Algorithm
 This algorithm transmits different file segments
simultaneously from one file holders to file requester.
 Transmitting segment wise reduces the transmission
latency.
 File requester choose the geographically close file
holders.
 Ask each file holder to transmit a segment of the file.
15

16. Back-Tracking Algorithm
 To keep track of the requester’s movement.
 If a requester moves out its current region before
receiving the response , it sends a back-tracking
message to source region.
 Message is piggybacked on the “hello” message
between neighbour nodes.
 Thus each node in the source region keeps a
backtracking message of the requester.
16

17.  Pseudo-code for metadata request replying.
1. // Sending a back-tracking message;
2. while have not received the metadata reply do
3. if it moves to a new region then
4. Send a back-tracking message to its old region
5. end if
6. end while
7. // Receiving a back-tracking message;
8. if receive a back-tracking message then
9. Add the message to its back-tracking message list
10. Broadcast the message to its neighbors in the region
11. end if
17

18. 12. // Receiving a metadata reply;
13. if receive a metadata reply with its region as destination then
14. if its back-tracking message list contains the message from
the requester then
15. forward the reply to the requester’s current region
16. flood a message in its region to delete the back-tracking
message for this reply
17. else
18. if the requester is its neighbor
19. send the metadata to the neighbor
20. else
21. broadcast the metadata to its neighbors
22. end if
23. end if
24. end if
18

19. Colouring-based Partial
Replication
 Colouring based partial replication(CBPR)
solves the problem with storage of metadata.
 CBPR aims to prohibit two neighbouring nodes holds the
metadata for a node.
 Because of mobility, neighbouring
relationship between nodes change.
 To maintain the colouring status,each
node in a region needs to check its neighbour.
19

20.  Pseudocode for the coloring-based partial
replication algorithm for each node
1. // ensuring that at least one neighbor has metafile;
2. if it does not have metafile then
3. for each “hello” message from its neighbor ni do
4. if ni is a replica node then
5. Record ni in its replica node list
6. end if
7. end for
8. if none of its neighbors is a replica node then
9. Randomly select a neighbor nj
10. send a metadata request to nj with TTL
11. end if
12. end if 20

21. 13.// Handling received metafile request;
14. if received a metafile request from nj then
15. if it is not a replica node then
16. if it has no neighbor which is a replica node then
17. forward the request to a randomly selected neighbor
18. else
19. forward the request to its neighbor that is replica
node
20. end if
21. else
22. send a metafile to nj
23. end if
24. end if
21

22. 25. // Handling received metafile
26. if received a metafile then
27. if it is not the metafile requester then
28. Send metadata to the previous request sender
29. end if
30. end if
22

23. Replica Management in node mobility.
• Nodes need to transfer replica when they move in or out
of a region.
• Node join :- when a node moves into a region,it checks
whether any of the neighbour has a metafile.
• If not ,send a metafile request.
• Node departure:- when a node moves out of its region,if
it is a replica node it transfers its metafile to a node in
the region.
• Otherwise no need to notify any node
23

24.  Pseudocode for metafile replication in node
mobility
1. // when node ni moves into region Ri
2. if ni has neighbors in region Ri then
3. if no neighbor has a metafile then
4. Request a metafile from a randomly selected neighbor
5. end if
6. else
7. send a metafile request to region Ri using RGR
8. end if
9. // when node ni moves out of its region;
10. if ni is a replica node then
11. if ni has neighbors in region Ri then
24

25. 12. send its metafile to a randomly selected neighbor
13. delete its metafile and leave
14. else
15. send a metafile transfer request to region Ri
16. end if
17. if ni receives a metafile transfer response from nj then
18. if ni is not a replica node in Rj then
19. send metafile to nj
20. end if
21. ni deletes its metafile and leave
22. end if
23. end if
25

26. Performance Evaluation
 To evaluate the performance of LORD,we compare it
with Geographic Hash Table(GHT),Global Locating
System(GLS),Ad-hoc On Demand Vector(AODV).
 We evaluate the
* Average success rate :- It is the ratio of number
of received files to the number of initiated file queries.
* Average path length :- It is the number of hops for
routing the query metadata query.
* Overhead :- It is the total number of all traversed
hops in metadata responding,mapping,updating. 26

27. Performance Evaluation
• Higher success rate,shorter path length and lower
overhead of LORD indicates its high scalability.
-Due to fewer mapping updates ,timely mapping
updates and back tracking LORD has higher success
rate.
- RGR in the LORD generates the shortest path.
-Colouring based partial replication provide low
overhead to LORD.
• Backtracking algorithm and redundant replica helps to
achive high mobility resilience to LORD.
• LORD provide high congestion resilience due to back
tracking algorithm. 27

28. Performance Evaluation
28

29. Conclusion
 LORD is an efficient data search system for a large
scale highly mobile wireless network.
 It consists region based data publishing and
querying.
 It divides the network into regions.
 It stores the metadata in multiple nodes and back-
tracking algorithm in region for mobility resilient.
29

30. Conclusion
 It uses RGR for forwarding data to destination.
 It uses parallel file fetching algorithm to minimize the
file fetching latency.
 It uses coloring based partial replication that reduces
replication in a region.
 It also works for an unbalanced wireless network
with sparse region.
30

31. References
 [1] Haiying Shen, Ze Li and Kang Chen, IEEE
transactions on parallel and distributed systems.
 [2] S. Guo, Y. Gu, B. Jiang, and T. He, ‘‘Opportunistic
Flooding in Low-Duty-Cycle Wireless Sensor
Networks With Unreliable Links,’’
31

32. THANK YOU…
32

33. ANY QUERIES???
33