GARUDA Achieving Effective Reliability for Downstream Communication in Wireless Sensor Networks Park et. al Presented by Ghada Abdelmoumin CS6204 Fall 2008/ Prof. Ing-Ray Chen

Reliable Data Delivery (RDD): Topics Introduction; Background Information –Basic Assumption –Challenges –RDD Fundamental Problems –Related Work Problem of Downstream Reliability –Definition and Key Goal. –Diverse Reliability or Reliability Semantics –Challenges RDD Proposed Solution – GARUDA –Claims –Design Elements –Assumptions –Proposed Framework Approach –Reliability Variant. –Performance & Analysis

Reliable Data Delivery (RDD): Assumptions Inherent properties of WSNs such as redundancy increase the degree of Reliability, but can not guarantee Reliability Semantics. Reliability in WSNs depends on the type of application, e.g., in security critical application any message from source has to reach the sensors reliably. In a security critical application the source may send the following three classes of messages: Control Code, Query-Response-data, and Query-Request- information.

Reliable Data Delivery (RDD): Challenges The problem of RDD has been addressed in MANET. MANET Proposed Approaches do not directly apply to the environment of WSN because of the three unique challenges imposed by: –Environment Considerations: substantially limited sensor lifetime, limited bandwidth, and limited energy. – Message Considerations: mostly small size messages/queries; What kind of loss recovery scheme can be employed? –Reliability Considerations: different notion of reliability; default  only a subregion  partial probabilistic reliability.

Reliable Data Delivery (RDD): Fundamental Prob. Redundancy can not guarantee any Reliability  Why? Parameters: Message Size = 100 packets; Packet Size = 1 kb; NW = 650 m X 650 m grid, Nodes = 100 Wireless Random Channel Errors Congestion and Contention Broadcast Storm WSNs requires diverse reliability semantics. Separate Reliability Mechanism is needed!

Reliable Data Delivery (RDD): Related Work #RDD Mechanism/ApproachMultihop WN/ WiredWSNs 1.Reliable Mutlicast approachAddress-centric & Global Unique Node ID N/A; data-centric & no Global ID 2.Forward Error Correction (FEC)/Physical Layer Prevent feedback implosion, little benefit for subcasting vs. multicasting. Inherently support local subcasting; thus benefit is minimal 3.Probability-based, area- based, and neighbor-based flooding Improve success rateCan not guarantee any strict reliability semantics 4.Pump Slowly, Fetch Quickly (PSFQ)/Transport Layer Minimize latency, and retransmission rate; Target large- scale networks, and provide simplest form of reliability semantics. N/E; doesn’t guarantee reliability semantics, doesn’t provide any reliability for single-packet messages, uses NACK-based scheme and in- sequence forwarding. 5.Reliable Transport LayerProvide some level or reliability by controlling reporting rate and having multiple path between sensor and source; concerned with upstream RDD N/E; doesn’t guarantee reliability semantics; and doesn’t address downstream RDD 5.TinyDBMinimize power consumption and increase query result accuracy N/E; it focuses on energy consumption rather than Reliability

Downstream Reliability: Problem Definition Problem Name: Reliable sink-to-sensors downstream data delivery. Problem Scope: Includes tackling the diverse reliability semantics required in WSNs. Goal: Achieving reliability while minimizing bandwidth usage, energy consumption, and latency.

Downstream Reliability: Diverse Reliability Semantics Char 1: Reconfigure Char 2: Location-dependent Char 3: Redundancy Deployment Char 4: Resolution Scoping

Downstream Reliability: Challenges (1) Environment Constraint: –Minimize the number of retransmission overheads to ensure reliability and hence address energy and bandwidth constraints. –Topology Construction Mechanism: In case of node failure don’t rely on static construction mechanism, but use dynamic construction mechanism. Trade off: dynamic mechanisms that periodically refresh any constructions are not desirable. –Inherent characteristics such as spatial reuse to achieve best capacity and hence delay may be severely limited by a specific loss recovery mechanism. Reliability Semantics: –Any reliability solution should support all types of semantics unique to WSNs.

Downstream Reliability: Challenges (2) Acknowledgment Paradox (ACK/NACK): –Stems from the constraints imposed by the typical sizes of messages; diverse message sizes (large-to-small). –NACK is an effective loss advertisement mechanisms, but it can not handle the unique case of all-packets-lost problem at a particular node; node is not aware that a message is expected. ACK scheme would address all-packet-lost problem, but ACK implosion is problematic. –NACK scheme inherently require in-sequence forwarding of data by nodes to prevent NACK implosion; in-sequence forwarding limit spatial reuse.

GARUDA: Claims Provides Reliable point-to-multipoint data delivery from sink to sensors. Scalable w.r.t network size, message characteristics, loss rate, and reliability semantics. Reduce the size of the protocol inside each sensor node; provide services (Design Elements) with one framework.

GARUDA: Assumptions Downstream Reliability –The algorithm limits reliability scope to source/sink-to-sensors only. Communication and Node Failure: –The algorithms handles both link and node failure. 100% Reliable Message Delivery/RMD: –Initially focuses on 100% reliability to all sensors –Extends focus to all other reliability semantics. Message: –The message size consists of one or more packets. Metrics: –Latency, retransmission overhead, and energy consumption. Network Model: –The source/sink and sensors in the NW remains static. –Exactly one sink coordinating the sensors.

GARUDA: Design Elements Pulsing-based solution – For reliable message delivery. Core/Virtual infrastructure: –It is a loss recovery infrastructure. –It is an approximation of the minimum dominating set (MDS) of the NW subgraph to which reliable message delivery is desired; optimal loss recovery designation servers  Optimization. – Instantaneously constructed during the course of a single packet flood. Two-stage NACK-based recovery process –Minimizes retransmission process overhead. –Performs out-of-sequence forwarding to leverage spatial reuse. Candidacy based solution –To support diverse reliability semantics.

GARUDA: Core Rationale When a Packet is sent from a source to sensors: –It is not possible that all nodes receives the packet without any error. –For any two packets broadcast, the set of node that has not received each packet can be different. –The set of nodes that have not received the packet can request for retransmission from any of the neighbor who received the packet successfully. –The retransmission by neighbor is sufficient to recover the loss of the same packet of all neighbors around it. The Optimal Loss Recovery Server Designation Problem: –Tries to minimize the set of retransmitting nodes. –Can be abstracted to one of a Minimum Set Cover (MSC) to determine the recovery server set that covers the base set. –Recovery Server Set: The set of nodes that have received the packet successfully. –Base Set: The set of nodes that have not received the packet successfully. MSC is NP-complete, but MDS is NP-hard. MDS Problem is equivalent to MSC problem using L-reduction.

GARUDA: Instantaneous Core Construction The core is constructed using the first packet delivery. The reliable delivery of the first packet determines the hop_count of each node. If a node hasn’t heard from any other node and its hop_count is a multiple of 3 can elect it self as a core node. To approximate the MDS problem select a node at 3i hop distance because it can cover the other nodes at 3i+1 and 3i-1.

GARUDA: Loss Recovery Process Out-of-Sequence Forwarding with A-Map Propagation –In-sequence forwarding suppress the forwarding of higher sequence number packet. –Out-of-sequence forwarding allow nodes with lost packets to continue to forward any higher (or lower) sequence number packets they might have received. –A-Map (Availability Map) propagation is used to address NACK implosion. –Any downstream core node initiates a request for a missing packet only if it receives an A-map from an upstream core node. –The core nodes initiate requests only when they are sure of an upstream core node having a particular packet. –There are two-stage loss recovery: Loss recovery for core nodes and Loss recovery for noncore node.

GARUDA: Diverse Reliability Semantics Instance of reliability semantics require delivery to subset Gs of the nodes in the underlying graph G. Gs consists of K components. K components are connected but are not connected with each other. GARUDA uses an approximation of the shortest path tree (SPT) to connect the components to the sink. Nodes employ a candidacy check before participating in a the core construction algorithm. Upon receiving the first packet the nodes determine whether or not they belong in Gs. Node outside Gs that is required for Core construction are inducted in the core construction using a forced candidacy algorithm. GARUDA Solution: Find MDS within each partition Connect MDS to the sink

GARUDA: Reliable Delivery of First Packet GARUDA user ACK-based scheme instead of NACK-scheme GARUDA uses the Wait-for-First-Packet (WFP) pulse to deliver the first packet reliably. WFP addressed the ACK implosion problem. WFP is a finite series of short duration pulses. Pulse amplitude is larger than a regular data transmission, but its duration is smaller than that of a regular data transmission. Any node irrespective of whether it is idle or receiving a packet can sense the pulse.

GARUDA Framework: Reliable Delivery of First Packet (RDFP) RDFP consist of three modes: –Advertisement  Notifies FP to all node using forced WFP pulses. –Delivery  Sends FP packet using forwarding. –Recovery  sends NACK using WFP to request retransmission. Loss Recovery Optimization –Piggyback NACK info inside the packet. –NACK = Sequence # of the last msg. ID the node received successfully. –Any neighbor aware of a greater msg. ID and has the FP retransmit the FP. Latency: TC is proportional to the node hop distance

GARUDA Framework: Core Construction Core Construction Procedure: –When the sink sends the FP it stamps the FP with its band ID (bId =0). –When the sensor receives the FP, it increments its bId by 1 and sets the resulting value as its own bId (i.e., bId=2) –Only sensors located at 3i band can elect themselves as core nodes. –Every core node in the 3(i+1) band knows of t least one core in 3i. –Every Packet carries the previously visited node bId and A-map. Concentric Circle –The FP delivery establishes band-IDs for node based on hop distance. –All nodes with the same ID form a band with a certain ID. –3i [Hear=>elects self or receives solicitation message]  3(i+1) [Check=> knows or elects]  3(i+2) [forwards then elects].

GARUDA Framework: Loss Recovery Core Recovery –Loss Detection  when a core node receives an out-of-sequence, it sends a request to an upstream core node only if notified through an A- map the missing packet is available at upstream core node. –Loss Recovery  When a core node receives a unicast request from a downstream core node it performs a unicast retransmission for the request. Noncore Recovery –Noncore node snoops all retransmission form its core node. –It initiates a retransmission request to its core node. –If it doesn’t hear from its core node for a core presence time, it sends an explicit request and the core node respond with its current A-map Opt: Core Node Packet (C id, A-map, bId, vFlag)  Forward Noncore Node Packet (C id, NC id, A-map, bId, vFlag)  Forward Noncore Node Packet (C id, C id, C id, A-map, bId, Null)  Forward Core Node 2-Local A-maps (myBM, totBM), Core Node A-map (inBM)  Receive Core Node (A-map has P*)  Request (A-map*); Update (totBM); Set (Timer) Core Node (A-map*)  Receive ; Update (myBM, totBM) Core Node (Timer Expire, Hear Not)  Request (A-map*, default Upstream Core Node) Default Upstream Core Node (A-map current)  Send

GARUDA Framework: Diverse Reliability Semantics Reliability Variants: –Reliable Delivery to all nodes within a subregion –Reliable delivery to the minimal number of sensors required to cover entire sensing area. –Reliable delivery to p percent of the nodes. Candidacy Problem: –Only a subset of the nodes in the network requires reliable delivery. –Which subset of nodes receives the message delivery? –FP is delivered to all nodes, but all subsequent packets are delivered based on candidacy. –FP carries info to identify eligibility of nodes for candidacy; i.e., coordinate-based description of the subregion. –Core nodes are the default candidates. –Each component on the candidate subgraph Gs has its own core node. –Forced candidacy to connect cores to sink and force non-candidate nodes in 3i band on the path from core nodes to sink to participate to ensure connectivity. –Downstream candidate core node requests explicitly from an upstream non-candidate core node to become a candidate if it hasn’t heard from any other candidate upstream node.

GARUDA Framework: Diverse Reliability Semantics Reliable Delivery Within Subregion(1): –Subregion can be specified in the form of coordinates. –Subregion can either be contiguous or noncontiguous. –Subregion coordinates are piggybacked on the First Packet delivered. –Each sensor receiving the packet can locally determine whether it is a candidate or not. –A sensor doesn’t elect itself as a core node if it is not a candidate. Reliable Delivery to Cover Sensing Field(2): –Reliable delivery needs to be performed by a minimal subset of sensors such that the entire sensing field is covered. –Assume the sensing range S is always ≤ transmission range R. –Coordination between nodes is required to eliminate sensors covering a region that is already covered. –Core node perform coordination; it is adjacent to all noncore nodes and at distance 2R at least from the nearest core node. –Core nodes keep track of the region covered by 2(S+T). –Noncore nodes seek permission from coordinator and coordinator grants permission only if the node can cover an area that is not already covered by 2(S+T). Reliable Delivery to Probabilistic Subset(3): –Useful when the sink intends to perform scoped sensing. –Candidacy is determined locally. –When receiving the FP, a sensor elects itself as a candidate with a probability P. –A sensor in a 3i band doesn’t elect itself as a candidate if it decides already not to be a noncore node.

GARUDA Framework: Analysis and Evaluation