Location Directory Services

Vivek Sharma

9/26/2001

CS851: Large Scale Deeply

Embedded Networks

Overview

Problem Statement Related work Design Issues Papers we shall discuss today

– Grid’s Location Service (GLS)– Randomized Database Groups (RDG)

Comparison and Issues Conclusion

Problem Statement

A directory service for a sensor network where nodes can lookup the geographical location of other nodes. The service implementation should be– Distributed among the nodes– Resilient to node failures– Scalable to a large number of nodes– Should have low memory and communication/power

overheads

Related Work

Location Management in Mobile Systems– tracking mobility of users to route calls efficiently– the network has fixed nodes with much more resources– most of the architectures are hierarchical and thus not fault tolerant

Ad Hoc Networks– conditions closest to a typical sensor network (no fixed

infrastructure)– additional power, communication and scalability issues apply

Smart Spaces – locating people and equipment in an office like environment– relative to a fixed set of wireless receivers

Related Work

Peer-to-Peer Applications– a distributed service to locate nodes with particular data items – no resource limitations or mobility in the system

Resource Location Problems – spatial gossip algorithms

Design Issues

Proactive vs. Reactive(maintaining location (on demand determination)

information continuously)

Deterministic vs. Non-Deterministic(e.g., hashing or ID mapping) (randomized approaches in

choosing location servers)

Hierarchical vs. Flat distributed set of

arrangement of location servers location servers

Deterministic vs. Non-deterministic approaches

Non-deterministic approaches as opposed to deterministic approaches are usually inherently resilient and are capable of handling large degrees of node failure and mobility

The main problem while using a random approach is to control the randomization to provide desired behavior and to reduce the overheads of a random approach

In deterministic approaches, one has to especially work towards providing fault-tolerance. Generally, its extra work to ensure that a system is resilient to failures

Papers to be covered

Grid’s Location Service (GLS)– A scalable location service for geographic ad hoc routing –

Jannotti et al (MIT)– a location service based on selecting location servers based

on node ID hash values

Randomized Database Groups (RDG)– Ad-hoc mobility management with Randomized Database

Groups - Haas and Liang (Cornell)– a non-deterministic approach towards maintaining location

information

Grid’s Location Service (GLS)

GLS Overview

The location service is used to enable geographical

ad-hoc routing The network is divided into ordered grids or squares

and each node is aware of the divisions Each node determines its geographic position using a

mechanism such as GPS Every node maintains a table of its current neighbor’s

identities and locations (each node broadcasts periodic HELLO packets)

GLS Overview

Location Servers: Every node selects a group of nodes (location servers for that node) distributed throughout the network, where it maintains its current location.

Routing: the location of the destination is determined by performing a location query and routing is then done using Geographic Forwarding.

Geographic Forwarding: When a node needs to send a packet towards location P, the node forwards the packet to the node amongst its neighbors which is closest to P.

Example

90

70

38

37

6291

1

5

50

51

35

39

45

11

19

26

4414

23

2

63

B:17

41 72

28 10

31

98 6143

6 21

76

20

84Order 1

Order 3

Order 2 B’s location

servers

Selecting and Querying Location Servers

Selection: A node recruits other nodes with IDs close to its own ID as its location servers. Location servers are selected in each sibling of a square that contains the node.

Querying: A sends a request to the least node greater than B for which it has information. That node forwards the query in the same way. Eventually the query will reach a location server of B which will forward the query to B itself. B can now respond directly.

Querying Location Servers: Example

90

70

38

37

6291

1

5

50

51

35

39

45

11

19

26

4414

23

2

63

B:17

41 72

28 10

31

98 6143

6 21

A:76

20

84

Updating Location Information

A node updates its order-2 location servers every time it moves a threshold distance d, its order-3 servers when it moves a threshold distance 2d, and so on. So, a node sends out updates proportional to its speed and updates are sent to distant servers less often than to local servers

Forwarding Pointers are used at the order 1 grid to let farther nodes route correctly when a node moves out of its square

Simulation Scenario

Monarch – CMU’s wireless extensions for ns. 802.11 Radio

– Bandwidth:1Mbps – Radio range: 250m.

100 nodes/km2

Order-1 square side – 250 m Mobility – “random waypoint” model Network of 600 nodes – the scale of a campus or city

Results

Scalability of GLS

Results

Performance of GLS in

the presence of mobility

Results

Performance of GLS

with node failures

Pros and Cons

Pros– Each node has to maintain a small amount of state– The querying technique is not paralyzed by failure of location

servers Cons

– Prone to performance degradation due to node failures and high degrees of mobility

– Fixed size squares; nodes in high density areas have to maintain more state information so there is much more stress on these nodes in terms of power

– The nodes should know the GRID structure beforehand

Randomized Database Groups (RDG)

RDG Overview

A set of location databases form a virtual backbone, which is dynamically formed and distributed among the nodes.

Location update – a node writes its location to a randomly chosen group of k databases

Location lookup – A randomly chosen group of k databases is queried.

The destination node location is provided to the source by the databases at the intersection of the queried database group and the group last written to by the destination node.

The virtual backbone

Formation: During initial setup, network flooding could be used to find the set of nodes that best serve as the backbone (e.g. uniformly distributed)

Maintenance: When a backbone node is detached from the network, a nearby non-backbone node is recruited to take its place

Randomized Database Groups

Given a virtual backbone with n location databases, any combination of k databases forms a RDG

When a node needs to update its location information, it uses any “accessible” RDG out of the nCk possible. Same for location query

k could be different for different nodes depending on the node’s traffic and mobility patterns

With appropriately chosen k, the probability of non-intersection between the set of databases queried and the set of databases updates can be made sufficiently small

Example

B

1

23

4

5 6

A

Virtual Backbone and the Location Databases

n = 6 databases

e.g. of RDG:

all combinations of size k=3:

{{1,2,3},{1,2,4},{1,2,5},….}

A node accesses the set of

databases through the database

nearest to it.

Mobile Location Updates

Call-origination update: the querying node writes its current location into the queried databases.

Location-change update: When a node changes location, it updates its new location in a RDG.

Periodic Update: Apart from the above, a node sends location information at every interval.

Mobility Management Costs

pe = probability that a database is inaccessible at any time instant. fo(t) = PDF for the length of time between any two consecutive call originations fm(t) = PDF for the length of time between any two consecutive location

change updates. Tp = Periodic update interval cu = expected cost of accessing a database cl = expected miss penalty.

Cupdate = k cu

Closs = cl X Expected number of lost calls per unit time

dtttfdtttfT mop )(

1

)(

11

Optimal RDG size determination

We can see that even for high pe, optimal cost is achieved with low k due to the tradeoff in the cost metric

Pros and Cons

Pros– Allows tuning of performance based on expected parameter values

for the system– Expected to handle large degrees of node failures well– Can be made adaptive to each node’s traffic and mobility patterns

Cons– Communication overheads could be significant with respect to other

approaches due to maintaining redundant location info– Greater load on the location databases – so life time could be low

for those nodes (although these nodes need not be “on” all the time)– Analytical results, a lot of assumptions. Unfortunately no simulations

to get an idea of performance in scenarios

Comparison

GLS Deterministic ID based technique

to select location servers Scalability

– State maintenance overheads are low

– Location information is spread out on all nodes (Asm: density)

Reasonably resilient to node failures due to less state info and robust querying method

Performance degradation in the presence of a high degree of mobility and node switch-offs could be significant

RDG Non-deterministic selection of

location databases Scalability

– k is likely to be high implying storing more state information

– Location servers are especially marked out and hence greater load on them (power)

Inherently fault resilient due to the random approach

Expected to handle high degrees of node mobility and node switch-offs better (though maybe at a higher cost?)

Conclusions

A randomized approach is attractive because of its inherent capacity to handle high degrees of mobility and provide high degrees of resilience

But some of these advantages could be offset by the amount of overheads due to redundancy in the state information maintained

The GLS technique uses techniques similar to hashing to distribute location information evenly on the set of nodes and uses intelligent heuristics to provide a robust location querying service

Some Issues

The implementation of a location directory service could impose significant overheads on the system

Questions to ask -– Do we really need a location directory service?

ID-less routing, Directed Diffusion Is the value added more than the costs?

It might not sound feasible or necessary to have a global location service for sensor networks. One could consider having

– a higher level directory service to map Data or Tasks to locations, and – a lower level directory service to map node-IDs to locations within

groups

Thanks!!

Vivek Sharma