Download Routing and Clustering

Document related concepts

RapidIO wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Computer network wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Distributed operating system wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

CAN bus wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Backpressure routing wikipedia , lookup

Airborne Networking wikipedia , lookup

Dijkstra's algorithm wikipedia , lookup

IEEE 1355 wikipedia , lookup

Kademlia wikipedia , lookup

Everything2 wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Routing wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Transcript
Taming the Underlying Challenges
of Reliable Multihop Routing in
Sensor Networks
Alec Woo, Terence Tong, David
Culler
SenSys 2003
Key Observations
• Many wireless links are lossy
• Loss rate may change dynamically
– Environmental factors
– Highly correlated behavior of an application
• Routing should consider these underlying
factors
– A lot of existing work on routing are based on
abstract MAC & physical layer model
– Simply assume 802.11 takes care of MAC layer
issues
Contributions
• Empirical link quality observation
• Connectivity analysis
– Likelihood of the success of a communication
– Distance, residual energy, congestion, channel
contention,…
– Link quality estimation
• Neighborhood management
• Routing for periodic data collection
applications
Empirical Observation of Link Characteristics
• Measure loss rates between many different
pairs of nodes at different distances
– Starting point for development of a practical
topology formation and routing
– A sequence of linearly arranged sensor nodes with
a spacing of 2 feet
– One transmitter sends packets 200 packets at the
rate of 8 packets/sec
– Remaining nodes counts the number of successfully
received packets
– Environment? Indoor? Outdoor? Obstacles??
Empirical Results
• A simple probabilistic means can be used to
capture the link behavior in simulations
– Connected region
– Transitional region: link probability with mean &
variance from the empirical data
– Disconnected region
References
• Spherical radio range assumption in current research
– Localization, Sensing Coverage, Topology Control
• Radio Irregularity
– Deepak Ganesan, etc., “Complex Behavior at Scale: An Experimental
Study of Low-Power Wireless Sensor Networks” , UCLA/CSD-TR 020013, 2002
– Alberto Cerpa, etc., “SCALE: A Tool for Simple Connectivity
Assessment in Lossy Environments”, CENS-TR 03-0021, 2003
– Jerry Y. Zhao, etc., “Understanding Packet Delivery Performance in
Dense Wireless Sensor Network”, ACM SenSys, 2003
– Alec Woo, etc., “Taming the Underlying Challenges of Reliable Multihop
Routing in Sensor Networks”, ACM SenSys, 2003
• DOI Concept
– Tian He, etc., “Range-Free Localization Schemes in Large Scale Sensor
Networks”, MobiCom, 2003
Link Estimation
• Individual nodes estimate link quality by
observing packet success and loss events
• Use the estimated link quality as the cost
metric for routing
• Good estimator should:
– React quickly to potentially large changes in link
quality
– Stable
– Small memory footprint
– Simple, lightweight computation
WMEWMA
• Snooping
– Track the sequence numbers of the packets from
each source to infer losses
• Window mean with EWMA
– WMEWMA(t, a) = (#packets received in t) /
max(#packets expected in t, packets received in t)
– t, a: tuning parameters
• t: #message opportunities
– Take average in a window
– Take EWMA of the average
WMEWA (t =30, a =0.6)
Neighborhood Management
• Neighborhood table
– Record information about nodes from which it receives packets
– MAC address, routing cost, parent address, child flag, reception
(inbound) link quality, send (outbound) link quality, link estimator
data structures
– Propagate back to the neighbors as the outbound rather than
inbound link quality is needed for cost-based routing
– The receiving node may update its own table based on the received
information possibly indicating topology changes  Distance-vector
based routing
• How does a node determine which nodes it should keep in the
table?
• Keep a sufficient number of good neighbors in the table
• Similar to cache management
Background: Distance vector routing
• Link state routing algorithm
– Assume knowledge of the network topology and all link costs
– Apply Dijkstra algorithm to find the shortest path from one
source to all the other nodes
– Implemented via link state broadcast [Perlmann 1999]
• Distance vector routing
– Iterative, distributed, asynchronous algorithm
– Receive from immediate neighbors
– Perform a calculation and broadcast the result back to the
neighbors
– Also called Bellman-Ford algorithm
– For example, look up http://en.wikipedia.org/wiki/Distancevector_routing_protocol
Management Policies
• Insertion
– Heard from a non-resident source
– Adaptive down-sampling technique
– Probability of insertion = N/T = neighbor table size
/ #distinct neighbors
• At most N messages can be inserted for every
T messages
• Eviction
– FIFO, Least-Recently Heard, CLOCK, Frequency
#Good neighbors maintainable (table size 40)
• Frequency Algorithm
– Keep a frequency count
for each entry in the
table
– Reinforce a node by
incrementing its count
– A new node will be
inserted if there is an
entry with a zero count
– Otherwise, decrement
the count of all entries
and drop the new
candidate
Cost-based routing
• Key ideas
– Minimize the cost that is abstract measure of distance
• Could be #hops, #retransmissions, etc.
– Minimize #retransmissions: A longer path with fewer
#retransmission could be better than a shorter path with more
retransmissions!
• Distance-vector based approach implemented by the parent
selection component
– Periodically run parent selection to identify one of the neighbors
for routing
– May also locally broadcast a route message including parent address,
estimated routing cost to the sink, and a list of reception link
estimations of neighbors
– A receiving node may update the neighbor table based on the
received info or drop it
– Flag a child in the table to avoid a cycle
– When a cycle is detected trigger parent selection without the
current parent
Routing Framework
Underlying Issues
• Parent selection
– If connectivity to the current parent is lost, a node disjoins
from the tree, and sets its routing cost to infinity 
Reselect a parent
• Rate of parent change
– Periodic: Parent selection for every route update msg from
neighbors incurs a domino effect of route changes
• Parent snooping
– For example, quickly learn routing info
• Cycles
– Monitor forwarding traffic and snoop on the parent address
in each neighbor’s msg -> Identify child nodes and don’t
consider them as potential parents
Underlying Issues
• Duplicate packet elimination
– Use sender address & sequence number
• Queue management
– Give priority to originating traffic assuming originating data rate is
lower than forwarding rate
– General fair queuing is not considered in this paper
• Relation to link estimation
– Link failure detection based on a fixed number of consecutive
xmission failures can be ineffective over semi-lossy links
– Link quality estimation can be a better judgment of link failure
– Bidirectional link estimations can avoid routing over asymmetric
links
– Stability and agility of link estimators can significantly affect
routing
• Final tuning must be done while observing its effect on routing
performance
Cost metric
• MT (Minimum Transmission) metric:
– Expected number of transmissions along the path
– For each link, MT cost is estimated by 1/(Forward link quality)
* 1/(Backward link quality)
– Inherently non-linear
– For MT, a substantial noise margin should be used in parent
select to enhance stability
• Reliability
– Another cost metric
– Product of link qualities along the path
– Not explored in this paper
Performance Evaluation: Tested Routing
Algorithms
• Shortest Path
– Conventional distance-vector approach
– Each node picks a minimum hop-count neighbor as
the parent and set its own hop-count to one
greater than its parent
– Two variations for performance analysis
• SP: A node is a neighbor if a packet is received from it
• SP(t): A node is a neighbor if its link quality exceeds the
threshold t
– t = 70%: only consider the links in the effective
region
– t = 40%: also consider good links in the transitional
region
Performance Evaluation: Tested Routing
Algorithms
• Minimum Transmission (MT)
– Use the expected #transmissions as the cost metric
– Use a new path if the new cost is lesser by a noise margin
• MTTM
– Assume a neighbor table can maintain only 20 entries
• Broadcast
– Root periodically floods the network
– A node chooses a parent that forwards the flooded msg to
itself first in each epoch
– Use the reverse path to reach the root
Performance Evaluation: Tested Routing
Algorithms
• Destination Sequence Distance Vector (DSDV)
– Choose a parent based on the freshest sequence
number from the root to avoid a cycle
– Maintain a minimum hop count when possible
– Ignore link quality: Consider a node a neighbor
once heard from it
– Periodically reevaluate
Packet level simulations
• Built a discrete time, event-driven simulator in Matlab
• Network of 400 nodes: 20 * 20 grid with 8 feet spacing
• Sink is placed at a corner to maximize the network depth
Packet level simulation
Hop Distribution
Path reliability over distance
Packet level simulation
Empirical study of a sensor field
• Evaluate SP(40%), SP(70%), MT
• 50 Berkeley motes inside a building
• 5 * 10 grid w/ 8 foot spacing
– 90% link quality in 8 feet
• 3 inches above the ground
Hop Distribution
-SP(70) failed to
construct a routing
tree
Link Quality of MT
-Vary around 70%
-SP(70) may suffer
- MT congested: Triple the data origination and route update rate
E2E success rate
Stability
Irregular Indoor Network
• 30 nodes scattered around an indoor office of
1000ft2
E2E Success Rate
Link Estimation of a node
to its neighbors over time
Conclusions
• Link quality estimation and neighborhood
management are essential to reliable routing
– WMEWMA is a simple, memory efficient estimator
that reacts quickly yet relatively stable
• MT (Minimum Transmissions) is an effective
metric for cost-based routing
• The combinations of these techniques can
yield high E2E success rates
Beacon Vector Routing: Scalable Pointto-Point Routing in Wireless Sensornets
R. Fonseca et al.
NSDI ’05
Motivation
• Most existing protocols only support basic
many-to-one or one-to-many routing
primitives (e.g., Directed diffusion, TAG, …)
• More point-to-point routing protocols have
recently been proposed
– Applications: Pursuer-evader game, spatial queries,
reactive tasking, multi-dimensional range queries,
data centric storage, …
• No practical and broadly applicable
implementation of point-to-point routing in
WSNs
Design Goals
• Develop & implement a point-point routing
protocol:
– Simple with minimal complexity
– Make minimal assumptions about radio quality,
presence of GPS, …
– Use TinyOS tree construction prtocol
Key Ideas
• Randomly select a few beacon nodes
• Construct trees from the beacons to every
other node
• Every node knows its distance (#hops) to
every beacon by using the standard reverse
path tree construction
– These beacon vectors serve as coordinates
• Apply simple greedy, geographic forwarding
Approach
• Nodes periodically send a local broadcast to announce
their coordinates
• A node q’s position P(q) = <q1, q2, …, qr> where qi is
#hops from node q to beacon i
• Distance function δ(p, d) to measure how good p would
be as a next hop to reach the destination d
– Choose a node whose coordinates are more to the sink’s
• Move towards a beacon when the destination is closer
to the beacon than the current node
• Move away from a beacon when the destination is
further from the beacon than the current node
Fallback mode
• If a node cannot make a progress towards the
destination itself, it forwards the packet to
the parent in the corresponding beacon tree
• A parent does the same thing
– First try to apply greed forwarding
– If it doesn’t work, rely on the fallback mode
• If the closest beacon still cannot find the
destination, it does scoped flooding
Beacon maintenance
• Route based on the beacons the source and
destination have in common
– Does not require perfect beacon info.
• Each entry in the beacon vector has a
sequence number
– Periodically updated by the corresponding beacon
– Timeout
• If the #beacons < r, non-beacon nodes
nominate themselves as beacons
Location directory
• Depending on the application, a source may first have
to look up the destination coordinates by name
• Use beacons as storage
– Hashing H: nodeid → beaconid [14]
• Each node k that wants to be a destination
periodically publishes its coordinates to its
corresponding beacon bk = H(k)
• When a node wants to route to node k, it sends a
lookup request to bk
• Cache the coordinates
Simulation Results
• Assumptions for high level simulation
– Fixed circular radio range
– Ignore the network capacity and congestion
– Ignore packet losses
• Place nodes uniformly at random in a square planner
region
– 3200 nodes uniformly distributed in a 200 * 200 unit area
– Radio range is 8 units
– Average node degree is 16
• Vary #total beacons and #routing beacons
Greedy success rate
Success ratio given 10 routing beacons
On-demand two hop neighbor acquisition
• At lower densities, each node has fewer immediate neighbors
– The performance of greedy routing drops
– Add a neighbor’s neighbors to the routing table, if greedy
forwarding is impossible
#beacons required to achieve less than 5%
scoped floods
On-demand two hop neighbor acquistion
-Start with one hop neighbors
-Fetch neigbor’s neigbors when there’s a void
Performance under obstacles
• Place horizontal & vertical walls with lengths
of 10 or 20 units when the radio range is 8
units
Prototype evaluation
• Office-Net: 42 mica2dot motes in a 20m *
50m office
• Univ-Net: 74 mica2dot motes deployed across
multiple student offices on a single floor in a
UC Berkeley building
Link quality vs. distance
• Orthogonal! (in Office-Net)
– Contradicts to circular radio assumptions made by geographic
routing protocols
– BVR is connectivity based
Routing performance in Office-Net
- Success rate > 98%
-1.2% of the reqeusts resulted in scoped flooding
- average scope of 2 hops
- Contention drops < 0.1%
Routing performance in Univ-Net
- Success rate > 98%
- 5.5% of the reqeusts resulted in scoped flooding
- average scope of 2 hops
- Contention drops < 0.1%
Office-Net success rate
Beacon failure
•
•
•
•
TOSSIM – TinyOS simulator
100 motes with 8 beacons
Expected node degree of 12
TOSSIM’s lossy link generator
– Based on empirical data to simulate lossy and asymmetric
connectivity
Related Work
• DSDV computes the shortest path between all
possible pair of source and destination
– Scalibility problem
• On-demand route discovery
– Poor performance when many source-destination pair want to
communicate
• Landmark routing
– Hierarchical set of landmark nodes periodically send scoped
route discovery messages
–  Each node self-configures its address: concatenation of
the closest landmark at each level of the hierarchy
–  Landmark maintenance
–  How to tune the landmark scope?
• Geographic routing
– GPSR
•  Highly scalable
– O(1) route discovery
– O(1) routing table
– Local planarization
– Path lengths are close to the shortest path
•  Unit graph assumption
•  Each node should node its geographic coordinates
•  Greedy forwarding can be suboptimal because it does
not use real connectivity info.
Questions?