View
213
Download
0
Category
Preview:
Citation preview
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
Recommended