CPSC 689: Discrete Algorithms for Mobile and Wireless Systems

1
CPSC 689 Discrete Algorithms for Mobile and
Wireless Systems

• Spring 2009
• Prof. Jennifer Welch

2
Lecture 17

• Topic
• Location services
• Sources
• Awerbuch Peleg
• Li, Janotti, DeCouto, Karger, Morris
• Abraham, Dolev, Malkhi
• MIT 6.885 Fall 2008 slides
• CPSC 689 Spring 2006 slides by Sai Siddarth

3
Location Services

• Maintain location information about mobile
  devices.
• Generally support operations
• MOVE(i)
• A mobile device i may move from one location to
  another in a network.
• FIND(i)
• Anyone anywhere in the network can try to locate
  any mobile device i anywhere in the network.
• Typically used to obtain an address, which can be
  used, perhaps repeatedly, for communicating with
  the target node i.

4
Location Service Example
are the location servers of
5
Location Service Example
are the location servers of
wants to communicate with . It communicates
with to get s information.
6
Location Service Example
are the location servers of
7
Location Services

• Three papers
• Awerbuch, Peleg 91 A classical paper,
  presenting a location service for mobile users
  traveling around a fixed, wired network.
• Li et al. 00 The GRID paper, presenting a
  location service (GLS) for mobile ad hoc
  networks, good behavior in relatively static
  cases.
• Abraham, Dolev, Malkhi 04 LLS, improved
  handling of node mobility.

8
Awerbuch, Peleg Overview

• A location service for mobile devices (users)
  traveling around a fixed network, modeled as an
  undirected graph.
• Operations supported
• MOVE(?,s,t)
• User ? jumps from node (location) s to node t in
  the network.
• Not necessarily along graph edges.
• FIND(?,v)
• User at node v in the network tries to get a
  message to user ?.
• Q How could these results apply in wireless
  settings?
• Goals
• Make both kinds of operations fast and
  communication-efficient (polylog in the number of
  nodes in the network).
• Keep only polylog information per user at each
  node.
• Main idea Implement the location service over a
  hierarchical directory service.

9
Directory Services

• Single-level directory provides operations
• INSERT(?, s) Insert ?, associated with location
  s.
• DELETE(?, s) Delete association of ? with
  location s.
• FIND(?, v) Starting from v, try to find an
  associated location for ? may return a location
  or may fail.
• Hierarchical directory service consists of a
  series of directory services, each associated
  with successively larger radii (successive
  doubling).
• Directory service associated with a certain
  radius m is guaranteed to return an answer for a
  FIND for any node that is within distance m of
  the location v at which the FIND is invoked.

10
Directory Services and Location Services

• Implementing location service over hierarchical
  directory service
• Directories dont always maintain current
  locations for users low-level directories
  (small radii) are kept more current, while
  higher-level directories may lag further behind.
• If a directory entry for user ? is old, it points
  to a previous location v for ?, which has a
  forwarding pointer to a more recent location for
  ?.
• By following forwarding pointers, FIND query
  reaches ?.

11
Directory Services and Location Services

• More specifically
• If a level i directory entry for ? indicates node
  v, then v has a forwarding pointer to the same
  node w that the level i-1 directory contains for
  ? .
• That should be closer to ?.
• Length of chain of pointers kept low (logarithmic
  bound).
• Implementing the hierarchical directory service
• By a distributed read/write quorum system
  algorithm.
• Assume all MOVE and FIND operations are
  sequential give some ideas about extensions to
  allow concurrency.

12
The Network Model

• Undirected graph G (V,E), n nodes.
• Bidirectional communication channels.
• Edges have weights, used to define a path cost
  measure (sum of weights).
• For now, assume each edge has weight 1---so just
  consider hop counts.
• dist(u,v) length of shortest path (hops).
• D, network diameter
• Nodes may communicate directly only with
  neighbors in the graph.
• Sometimes, nodes communicate with non-neighboring
  nodes assume efficient routing is available
  (approximately shortest path).

13
The Problem

• Each user ?, at each time, is located at some
  node Addr(?) of G.
• A location service is a global service providing
  operations
• MOVE(?, s, t)
• Invoked at node s Addr(?).
• User ? moves from node s to node t.
• FIND(?,v)
• Invoked at node v.
• Delivers a message submitted (by external client)
  at node v, to Addr(?). Guaranteed.

14
Full Information Strategy

• Every node keeps a complete table of where all
  the users are.
• Every time a user moves, immediately communicates
  with all nodes to update their information.
• FIND(?,v) operations are cheap---route message
  directly to user ?.
• MOVE operations are very expensive (e.g., amount
  of communication).
• Useful only in settings where MOVEs are
  infrequent.

?
15
Other Strategies

• No-information strategy
• No information maintained anywhere.
• MOVEs are very cheap.
• FINDs are very expensive involve a global
  search.
• Useful only in settings where FINDs are
  infrequent (occasional location queries).
• Complete chain of forwarding pointers
• When user moves, leave a pointer from the
  previous node to the new one.
• MOVEs cheap, but FIND can involve following a
  length-n chain of pointers.
• They want some intermediate partial information
  strategy, in which both MOVE and FIND operations
  are cheap, for any sequence of MOVE and FIND
  operations.

16
Cost Measures

• MOVEs to nearby locations, and FINDs for nearby
  users, should cost less than long-distance MOVEs
  and FINDs.
• Measure communication cost, for each FIND and
  MOVE, in terms of number of hops that messages
  traverse in the implementation.
• (Actually, weighted costs. And charge based on
  number of bits in the message. Ignore these for
  now.)
• Compare actual costs to ideal costs, where full
  info is available for free. These are the ideal
  costs
• FIND(?, v) dist(v,Addr(?)), the distance
  (hops), from the location v at which the
  operation is invoked to the actual location of ?.
  
• MOVE(?, s, t) dist(s,t)
• Measure is amortized, over a sequence of MOVE and
  FIND operations.
• FIND-stretch Ratio of the sum of the actual
  costs of all the FIND operations to the sum of
  the ideal costs for the same FIND operations.
• MOVE-stretch Similar.

17
Main Result

• Algorithm that guarantees
• FIND-stretch O(log2(n)) (counting log(n) for
  each message with unit cost, may be just
  O(log(n)).
• MOVE-stretch O( log D log n (log D)2 / (log n)
  ).
• Low communication.

18
Hierarchical Directory Service

• Hierarchy of regional directories, RDi, i
  1,..., log D.
• RDi enables a searcher at any location v to find
  any user residing within distance 2i of location
  v.
• Each RDi is a single-level global directory data
  structure.
• It maintains (conceptually) some global state,
  which is a set of (user, address) pairs (?, s).
• Call s the level i regional address of ?.
• RDi provides operations
• INSERT(?, s) Invoked from location s.
  Associates ? with s.
• DELETE(?, s) Invoked from location s, where ?
  is associated with s. Deletes the association of
  ? with s.
• FIND(?, v) Starting from v, try to find the
  location associated with ?. May return a
  location or may fail. Guaranteed to succeed if ?
  has an associated location s with dist(v,s) 2i.

19
Implementing Location Service Over a Hierarchical
Directory Service

• Suppose we have a hierarchical directory service
  (see later how to implement it, with a
  distributed algorithm).
• How to use it to implement a location service?
• Each RDi maintains associations between users and
  locations (regional addresses).
• Ideally, these would be kept up-to-date, so when
  a MOVE(?, s, t) occurs, all directories would be
  updated to remove (?, s) and add (?, t).
• Too costly.
• Instead, store forwarding pointers at some
  nodes of the network.
• Pointers of the form forward(?).
• Outside the directory service.
• The node s at which a user ? currently resides
  knows it is there represented by setting
  forward(?) at s to s itself.

20
FIND(?,v) Implementation

• Using (global) hierarchical directory and
  (distributed) forwarding pointers.
• FIND queries RD1, RD2,... about ?, until it gets
  some location s as an answer from some regional
  directory RDi.
• That will eventually happen, because it's
  guaranteed at the top level, directory Rlog D.
• Then FIND goes to node s, sees if user ? is
  there if not, FIND follows forwarding pointers
  from node to node until it reaches ?s current
  location.
• Forwarding pointers and RDi directories are not
  changed by FIND operations, just during MOVEs.

21
MOVE (?, s, t) Implementation

• Modifies some of the RDi entries for ? to contain
  the new location t.
• Definitely modifies lowest-level directory, RD1.
• Possibly some higher-level directories also.
• If any directory is updated, so are all the
  lower-level ones.
• To determine which directories to update,
  maintain cumulative counts of how far ? has moved
  (in all its MOVEs) since last updating each
  directory.
• When ? has moved distance 2i-1 or greater,
  regional address RDi(?) is guaranteed to be
  updated.
• Let i denote the highest-level directory that is
  updated.
• Then, if i is not the top-level directory, set a
  forwarding pointer forward(?) t at the node
  associated with ? in RDi1.

22
Reachability Invariant

• Expresses an interesting relationship between
  regional addresses for ? stored in the regional
  directories, and forwarding pointers for ?
• If i ? 2, RDi(?) s, and RDi-1(?) t, then
  forward(?) at node s contains t.
• Thus, if location s is the regional address of ?
  at some level i of the directory hierarchy, then
  following the forwarding pointer forward(?) from
  s leads to the same location t that would be
  obtained from level i-1 of the directory
  hierarchy.
• So, following a path of forward(?) pointers
  starting from any regional address for ? in the
  directory hierarchy, is the same as stepping
  through all the successively lower-level regional
  addresses for forward(?).

23
Proximity Invariant

• Says that directory entries are updated
  sufficiently often
• For any i, the total distance traveled by user ?
  since the last time RDi(?) was updated (to its
  exact location) is 2i-1 -1.
• This use of powers of 2 yields the logarithmic
  bounds.
• Analysis LTTR (not in the paper).

24
Implementing a Hierarchical Directory Service

• Implement each level separately.
• For each level, use a kind of quorum
  configuration
• Define m-regional-matching, or m-quorum-configurat
  ion, where m is a distance (nonnegative real)
• Assigns to each node v in the graph, two sets of
  nodes, Read(v) and Write(v).
• If dist(v,w) m, then Read(v) ? Write(w) ? ?.
• Thus, if two operations are performed, one
  involving all the nodes in Read(v), and the other
  involving all the nodes in Write(w), for nearby
  nodes v and w, they would encounter at least one
  node in common.
• E.g., if a write-quorum is used to write an
  update to several copies of a directory, then
  accessing a read-quorum from a nearby node is
  guaranteed to get an up-to-date copy of the
  directory.

25
Implementing a Hierarchical Directory Service

• Theorem 4.1 says that certain efficient
  m-regional matchings exist
• Small size read-quorums and write-quorums.
• Short distance between v and each member of
  Read(v) and Write(v).
• Measure is normalized by dividing by distance
  parameter m.
• Thus, larger m are allowed to have proportionally
  larger distances between quorum nodes, without
  penalty.

26
Implementing Regional Directory RDi

• Use a 2i-regional matching.
• Information being kept in RDi for node v is
  copied at all nodes in Write(v).
• To read the information starting from node w,
  read from all copies at all nodes in Read(w).
• If dist(v,w) 2i, this is guaranteed to return
  the last value written in the directory at v.
• More specifically, in terms of actual directory
  operations
• INSERT(?, s) Implemented using writes to copies
  at the nodes in Write(s).
• DELETE(?, s) Same
• FIND(?, v) Implemented using reads of the nodes
  in Read(v).

27
Find Example AP
28
Move (x4 to x5) Example AP
x5
29
Extensions to Allow Concurrency

• Some concurrency isnt a problem
• Concurrency between different users doesnt
  matter.
• Can assume MOVEs for the same user ? are
  sequential can coordinate at ?s location.
• Concurrent FINDs for ? don't interfere.
• The real problem
• When a FIND for ? proceeds concurrently with a
  MOVE of ?.
• Would like to guarantee, under reasonable
  conditions, that the FIND will succeed in
  tracking down the moving user.

30
Extensions to Allow Concurrency

• No definitive solution, but some ideas
• Slow down ?'s moves to ensure that concurrent
  FINDs can catch it.
• Require stronger conditions for quorum systems,
  so that a Read set is guaranteed to intersect all
  relevant Write sets, for nodes within the
  distance that could be covered by concurrent
  MOVEs.
• Coordinate using synchronized clocks.

31
The GRID Location Service (GLS) LJCKM

• For mobile ad hoc networks.
• Node addresses are 2D geographical coordinates,
  not graph nodes.
• GLS supports operations
• FIND(y)
• A mobile node x anywhere in 2D space may submit a
  FIND(y) request, asking for the address
  (coordinates) of any other mobile node y.
• GLS should respond to x with reasonably
  up-to-date coordinates for y.
• MOVE(y)

32
The GRID Location Service (GLS)

• GLS can be combined with a geographical routing
  algorithm, which sends a message to the vicinity
  of a target geographical location
• x looks up the address of y using GLS, then use
  geographical routing to send an actual data
  message to y.
• Also, the GLS implementation uses geographical
  routing as part of the processing of FIND
  operations.

33
Key Ideas in GLS

• Three structures
• Static, hierarchical subdivision of the plane
  into nested squares.
• Static assignment of unique ids to mobile nodes,
  from a circularly-ordered set of node ids.
• Dynamic assignment of a table consisting of
  particular (node-id, address) pairs to each
  mobile node.
• The pairs in the tables should contain relatively
  up-to-date coordinates must be maintained in the
  face of mobility.
• Selection of which pairs reside in each table
  depends on current locations of mobile nodes in
  the plane, with respect to the hierarchical
  subdivision.

34
Key Ideas

• The selection of which pairs reside in each table
  is adapted from a consistent hashing technique of
  Karger and others.
• Here, the selection is designed to
• Load-balance, keep tables at different nodes of
  similar sizes.
• Support efficient FIND operation, which follows a
  greedy strategy, repeatedly moving to the node
  whose id is closest to that of the target,
  among those whose coordinates appear in the local
  table.

35
Targeted Complexity

• Overall table organization is designed to ensure
  that the number of steps performed during each
  FIND is proportional to the log of the Euclidean
  distance from source to target.
• Moreover
• The number of hops for the first such step (using
  geographical routing) is proportional to the
  distance between the source and target.
• The number of hops for each successive step is
  approximately half of the number for the previous
  step.
• Thus, the total number of total hops used by a
  FIND is proportional to the geographical distance
  between source and target.
• Queries for locations of nearby nodes are
  satisfied with correspondingly local
  communication.
• Experiments show
• Scalability, tolerance to failures, recoveries,
  motion.
• Main emphasis is on scalability (to a large
  metropolitan area).
• Analyze correctness and efficiency (in static
  case).

36
Node Identifiers

• Mobile nodes have unique ids, chosen from a
  discrete circularly-ordered set, e.g., integers
  mod k, for some k.
• Consider the ids as increasing in clockwise
  direction around a circle.
• The node closest to node with id x in some
  nonempty set X of ids
• Means the one in X whose id is first encountered,
  starting from x and moving in the clockwise
  direction.
• If x is in X, the result is x itself.

37
Example of Identifiers

• Blue nodes are in X
• Node closest to 6 is 7
• Node closest to 8 is 1
• Node closest to 4 is 4

0
8
1
7
2
6
3
5
4
38
The Planar Subdivision

• Nested squares, of order 1, 2, ..., k.
• Order-1 squares are the basic unit squares.
• Overall square is an order-k square, consisting
  of 2k-1 ? 2k-1 order 1 squares.
• In general, an order-(i1) square is composed of
  four order-i squares.
• Assume that every mobile node, at any time, is at
  some location in the overall square.

• In only one square at any time.
• Use a tiebreaker for boundaries, or ignore cases
  where the nodes reside exactly on the boundaries.
  

39
Order 1 Squares
40
Order 2 Squares

• 4 order n squares make up an order n1 square

41
Order 3 Squares

• 4 order n squares make up an order n1 square

42
Constraint

• Every node can only be in one square of each size.

43
Placement of Location Servers
Host Location Server
44
The Tables

• Describe for static case, where mobile nodes
  dont move.
• Namely, for each node x at geographical location
  l, and each node y, put (x, l) in y's table if
  one of the following hold
• x and y are in the same order-1 square.
• For some i, 1 i k-1
• x and y are in the same order-(i1) square but in
  different order-i squares, and
• y's id is the closest to x's id (clockwise
  order), among nodes in y's order-i square.
• That is, there is no y' in the same order-i
  square as y such that x lt y' lt y.
• Thus, a single (x, l) could appear in
• Tables of all the nodes in the same order-1
  square as x, plus
• 3(k-1) tables, 3 for each order (each order-i
  square has 3 sibling order-i squares within the
  same order-(i1) square).

45
The Tables

• Each entry in node ys table corresponds to some
  level.
• Entries for lower levels are for nodes that are
  closer geographically to y.
• Not clear whether y has more entries for higher
  levels
• The load of potential nodes x for which y could
  have an entry is larger for higher levels.
• However, for each potential node x at a higher
  level, it is less likely that y is the chosen
  node, since y has many other neighbors to share
  the load.

46
Example
39
90
38
37
45
50
70
11
91
51
62
5
19
35
1
27
63
41
23
72
44
17
2
20
14
28
87
10
83
55
61
6
32
98
21
31
81
43
12
76
84
47
FIND Protocol

• Suppose that FIND(t) is invoked at node s.
• Then
• Node s sends a query message to the node x whose
  id is closest to that of t, among those whose
  coordinates appear in s's local table.
• If node w ? t receives a query message intended
  for t, then w sends the query message to the node
  x whose id is closest to that of t among those
  whose coordinates appear in w's local table.
• If node t receives a query message intended for
  itself, then t sends (using geographical routing)
  its own coordinates back to the site s that
  initiated the FIND.

48
FIND Protocol Example
39
90
38
37
45
50
70
11
91
51
62
5
19
35
1
27
63
41
23
72
44
2
14
17
28
87
10
83
20
55
61
6
32
98
21
31
81
43
12
76
84
49
Termination and Complexity Bound for FIND

• The key is an invariant that holds after any
  number j of steps of the FIND algorithm (invoked
  from s for target t)
• After at most j steps of FIND, 1 j k, the
  query is at the closest node to t, from among
  those in the order-j square containing s.
• Thus, the query progresses systematically,
  finding the closest node to t in successively
  larger squares containing s.
• So when j k, the query is at the closest node
  to t in the entire square, which is t itself.
• Proof is inductive. (See p. 125 the heart of the
  paper.)

50
Inductive Proof of FIND Behavior Basis

• After at most j 1 step, the query has reached
  the closest node to t from among those in the
  order-1 square containing s.
• If s is itself the best, then we're done after 0
  steps.
• If not, then recall that s knows about everyone
  in its order-1 square.
• So in 1 step, it can certainly route the query to
  the best one, say u.
• Potential problem suppose that s happened to
  have something else in its table, say v, that
  isn't in the same order-1 square, but that is
  closer to t than u is (in id-space)

51
Inductive Proof of FIND Behavior Basis

• Potential problem suppose that s happened to
  have something else in its table, say v, that
  isn't in the same order-1 square, but that is
  closer to t than u is (in id-space)
• Id order (t, v, u, s)
• Argue that s would not have such v in its table
• If v were in s's table, it would mean that s is
  the closest node to v among the nodes in some
  square (of some order)---that's why s was chosen
  to hold v's location information.
• But u is in the same order-1 square as s, and has
  an id between v and s---so u would have been a
  better choice than s, and s would not have been
  chosen.
• QED for base case.

52
Inductive Step

• Similar to the base case.
• Now suppose that the query is at the closest
  node, s', to t among those in the order-j square
  containing s.
• We want to show that within 0 or 1 more steps, it
  reaches the closest node to t from among those in
  the order-(j1) square containing s.
• If s' is the closest, we're done, with 0 more
  steps.
• If not, then we claim that
• 1. s' has, in its table, the closest node, u, to
  t in the order-(j1) square, and
• 2. s' does not have any other node that is
  closer to t than u.
• Prove these two claims in the next two slides, to
  show we get to right node u in one more step

s?
u
53
Inductive Step

• Show s' has, in its table, the closest node, u,
  to t in the order-(j1) square
• s' has u in its table because s' is closest node
  to u in the order-j square of s'.
• Why is s? the closest node to u in this square?
• Ids ordered (t, u, s?), since u is closer to t
  than s' is.
• There is nothing else between u and s' in the
  order-j square of s', since then it would be
  closer to t than s' is, contradicting our
  assumption about s'.

s?
u
54
Inductive Step

• Show s' does not have any other node that is
  closer to t than u
• Suppose s' had something else in its table, say
  v, that isn't in the same order-(j1) square, but
  nevertheless is closer to t than u is.
• Ordering (t, v, u, s?)
• But s' would not have v in its table.
• For, if it did, then s' would be the closest node
  to v among the nodes in some square (of order ?
  j1)---that's why s' was chosen to hold v's
  location information.
• But u is in the same order-(j1) square as s',
  and has an id between v and s'---so u would have
  been a better choice than s'.
• QED for inductive step

v
55
Remarks

• Proof shows After at most 1 step of FIND, the
  query is at the closest node to t, from among
  those in the order-1 square containing s.
• Yields termination in time O(k), in the static
  case.
• Algorithm relies on tables not to contain certain
  elements.
• Precludes solutions whereby we include extra
  location information as we discover it (by
  overhearing, e.g., in promiscuous mode).
• Q What would go wrong if we allowed this?
• We'd still get termination.
• But now we might have long paths---taking more
  steps than necessary (example ?), and sending the
  query to greater distances than necessary.

56
Remarks

• So far, the algorithm is presented in terms of
  static structures it should be adapted to
  dynamic settings.
• Give some ideas, but more work is needed.

57
Initializing the Tables

• See p. 123-124.
• Suppose the network is static, tables are empty.
• Filling them appropriately sounds very expensive
• Every node x must send its location information
  to many other nodes, chosen as the closest ones
  in certain squares.
• Sounds like it could involve searching through
  entire squares to find the closest one.
• But its not that bad
• Can fill the tables efficiently---without global
  searches, flooding, etc.
• Table-filling procedure similar to FIND
  procedure.

58
Initializing the Tables

• Works level by level, low to high, filling levels
  synchronously.
• First, each node sends its location info to all
  other nodes in its order-1 square.
• Using local broadcast, or simple local flood.
• Then, for each level i in turn, i 1, ..., k-1
• Assume every nodes info is already at the right
  servers in its order-i square.
• So, every node already has all its entries for
  nodes within its order-i square.
• Purpose of next phase is for every x to get its
  info to the 3 desired servers in xs order-(i1)
  square that aren't in xs order-i square.
• E.g, suppose node x wants to find the right
  server in a particular order-i sibling square Si
  within its order-(i1) square.
• Then x sends its location info to Si, using
  geographic routing.
• Someone in Si should get it, say node y.
• Then y begins a PSEUDO-FIND(x), which proceeds
  just like FIND(x).
• That PSEUDO-FIND remains within Si, and
  eventually locates the closest node to x in Si
  this is the desired server.
• This works because all the nodes within Si
  already have their table entries set up for the
  other nodes within Si.

59
Maintaining the Tables

• Changes nodes may join, leave, move.
• We would like
• (At least) the tables should revert to their
  correct states if the changes ever stop.
• (If possible) everything should work even during
  changes.
• Several ideas for maintenance, see Section 5
• Updating location servers when a node moves
• Not every time---too much communication.
• Rather, use Awerbuch-Peleg idea Update
  order-i servers when you've moved 2i-1 Euclidean
  distance.
• Thus, updates are sent more often to local
  servers than distant ones.
• Invalidating location table entries
• Each table entry has a timeout value.
• Each node periodically sends its location to its
  servers, in order to refresh the location info
  (even when it doesnt move).

60
Forwarding Pointers

• Suppose a node y acting as a server moves away
  from its location.
• If someone then forwards a packet intended for
  some target t to node y, it will get lost!
• Idea y leaves forwarding pointers at all nodes
  in its old order-1 square, pointing to its new
  order-1 square.
• Conceptually, can think of the forwarding
  pointers as being located in the square instead
  of at the nodes.
• So, as nodes enter and leave a square, they
  acquire and discard the squares forwarding
  pointer information (use a gossip protocol).
• Thus, the information can persist beyond the time
  when any particular node remains in the square.
• Q But how do these get maintained? We don't
  want to set up long chains of forwarding
  pointers...
• Q Could y pass on its routing table
  information, rather than a pointer?

61
Remarks

• Interesting algorithm.
• Works very well in static case (analysis).
• Works well in some dynamic cases (simulations,
  based on random motion).
• Dynamic case deserves more study, e.g., to get
  guarantees for arbitrary motion patterns.