Transport Protocol in Wireless Sensor Networks

Motivation  What is expected out of a “transport” protocol for sensor networks ? Reliability, congestion control, mux/demux,……  Why can’t we use the existing protocols ? Resource constraints – power, storage, computation complexity, data rates, …  Are these constraints common for all sensor networks ? No, they are application specific.

Motivation..contd. ► Any application can have a union of the constraints that we know or yet to figure out ► Any application can have a union of the constraints that we know or yet to figure out ► Spectra for known constraints: Low data Rate High data Rate Power limitedNot Power limited Storage limitedNot Storage limited Bursty samples Periodic samples

Motivation..contd. General notion for sensor networks Low data Rate High data Rate Power limited Not power limited Storage limited Not storage limited Sink user

Motivation..contd. Radar application: Range of Transport protocols is yet to be explored ESRT, PSFQ, CODA …….……!!!!………..TRABOL ESRT, PSFQ, CODA …….……!!!!………..TRABOL Low data Rate High data Rate Power limited Not Power limited Storage limited Not storage limited High data Rate Not Power limited Not Storage limited

Two Issues in Transport First look at resource-constrained sensors ► What is the proper reliability notion for wireless sensor networks?  ESRT as an example ► How to achieve reliable end-to-end delivery in a less wasteful way?  PSFQ as an example

Main Design Guidelines ► Application driven  Application-oriented notions such as reliability, loss recovery, delay ► Filling in the “gray area”, Different from the Internet  Expose application semantics ► E.g., the concept of “application level framing” here ► “End to end” versus “region-based”  Other extreme: Hop by hop?

References for This PPT ► ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks ► PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks

Event-to-Sink Reliable Transport (ESRT) for Wireless Sensor Networks Features: ► Event-to-sink reliability ► Self-configuration ► Energy awareness [low power consumption requirement!] ► Congestion Control ► Variation in complexity at source and sink. [computation complexity] S

ESRT: Overview ► Focus on events, not individual pieces of data  Reflect application/user’s viewpoint ► Application-driven  Application defines what its desired event reporting rate should be ► Includes a congestion-control element ► Runs mainly on the sink ► Main goal: Adjust reporting rate of sources to achieve optimal reliability requirements

Problem Definition ► Assumption:  Detection of an event is related to the number of packets received during a specific interval ► Reliability is measured in terms of the number of packets received. Or reporting frequency i.e., number of packets/decision interval. ► Observed event reliability r i :  # of packets received in decision interval I ► Desired event reliability R:  # of packets required for reliable event detection  Application-specific ► Normalized reliability = observed/desired. ► Goal: configure the reporting rate of nodes  Achieve required event detection  Minimize energy consumption

Reliability vs Reporting frequency ► Initially, reliability increases linearly with reporting frequency ► There is an optimal reporting frequency (f max ), after which congestion occurs ► F max decreases when the # of nodes increases

Characteristic Regions ► n: normalized reliability indicator ► (NC,LR): No congestion, Low reliability  f < fmax, n < 1-e ► (NC, HR): No congestion, High reliability  f <= fmax, n < 1+e ► (C, HR): Congestion, High reliability  f > fmax, n > 1 ► (C, LR): Congestion, Low reliability  f < fmax, n <= 1 ► OOR: Optimal Operating Region  f < fmax, 1-e <= n <= 1+e

Characteristic Regions

ESRT Requirements ► Sink is powerful enough to reach all source nodes ► Nodes must listen to the sink broadcast at the end of each decision interval and update their reporting rates ► A congestion-detection mechanism is required

Congestion Detection and Reliability Level ► Both done at the sink ► Congestion:  Nodes monitor their buffer queues and inform the sink if overflow occurs ► Reliability Level  Calculated by the sink at the end of each interval based on packets received

Algorithm for ESRT ► If congestion and low reliability: decrease reporting frequency aggressively. (exponential decrease) ► If congestion and high reliability: decrease reporting to relieve congestion. No compromise on reliability (multiplicative decrease) ► If no congestion and low reliability: increase reporting frequency aggressively (multiplicative increase) ► If no congestion and high reliability: decrease reporting slowing (half the slope)

Components of ESRT ► In sink:  Normalized reliability computation  A congestion detection mechanism ► In source:  Listen to sink broadcast  Overhead free local congestion detection mechanism E.g., buffer level monitoring, CN – Congestion Notification

ESRT Protocol Operation ► (NC, LR): ► (NC, HR): ► (C, HR): ► (C, LR):

ESRT Summary ► Reliability notion is application-based  No delivery guarantees for individual packets ► Reliability and congestion control achieved by changing the reporting rate of nodes ► Pushes all complexity to the sink ► Single-hop operation only

PSFQ: Overview ► Key ideas  Slow data distribution (pump slowly)  Quick error recovery (fetch quickly)  NACK-based  Data caching guarantees ordered delivery  Assumption: no congestion, losses due only to poor link quality ► Goals  Ensure data delivery in poor link quality case  Minimize signaling overhead for detection/recovery operations  Provide loose delay bounds for data delivery to all intended receivers ► Operations  Pump  Fetch  Report

Probability of successful delivery using End to End Model 1 2 n-1 n (1-p) (1-p) n-1 (1-p) n p is the error rate of wireless link between two hops

End-to-end considered harmful ? ► Probability of reception degrades exponentially over multiple hops  Not an issue in the Internet  Serious problem if error rates are considerable ► ACKs/NACKs are also affected

Proposed solution: Hop-by-Hop error recovery ► Intermediate nodes now responsible for error detection and recovery  NACK-based loss detection probability is now constant ► Not affected by network size (scalability) ► Exponential decrease in end-to-end ► Cost: Keeping state on each node  Potentially not as bad as it sounds! ► Cluster/group based communication ► Intermediates are usually receivers as well

Multi-Hop Packet Forwarding When No Link Loss – Multi-Hop Forwarding takes place

Issue: Recovering from Errors lost Recover 2 Error Recovery Control Messages are wasted

How PSFQ Recovers from Errors “Store and Forward” lost Recover No wastage of the Error Recovery control messages

Pump operation ► Node broadcasts a packet to its neighbors every Tmin  Data cache used for duplicate suppression ► Receiver checks for gaps in sequence numbers ► If all is fine, it decrements TTL and schedules a transmission  Tmin < Ttransmit < Tmax  By delaying transmission, quick fetch operations are possible  Reduce redundant transmissions (don’t transmit if 4 or more nodes have forwarded the packet already)  Tmax can provide a loose delay bound for the last hop ► D(n)=Tmax * (# of fragments) * (# of hops)

PSFQ Pump Schedule If not duplicate and in-order and TTL not 0 Cache and Schedule for Forwarding at time t (T min <t<T max ) T min T max T min T max t

Fetch operation ► Sequence number gap is detected  Node will send a NACK message upstream ► ‘Window’ specifies range of sequence numbers missing ► NACK receivers will randomize their transmissions to reduce redundancy  It will NOT forward any packets downstream  NACK scope is 1 hop  NACKs are generated every Tr if there are still gaps ► Tr < Tmin  This is the pump/fetch ratio ► NACKs can be cancelled if neighbors have sent similar NACKs

“Fetch Quickly” Operation lost 2 3 T min T max TrTr Recover 2 TrTr 2 2

Proactive Fetch ► Last segments of a file can get lost  Loss detection impossible; no ‘next’ segment exists! ► Solution: timeouts  Node enters ‘proactive fetch’ mode if last segment hasn’t been received and no packet has been delivered after Tpro  Timing must be right ► Too early: wasted control messages ► Too late: increased delivery latency for the entire file  Tpro = a * (Smax - Smin) * Tmax ► A node will wait long enough until all upstream nodes have received all segments  If data cache isn’t infinite ► Tpro = a * k * Tmax(Tpro is proportional to cache size)

“Proactive Fetch” T proc 12 last-1 last

Report Operation ► Used as a feedback/monitoring mechanism ► Only the last hop will respond immediately (create a new packet)  Other nodes will piggyback their state info when they receive the report reply  If there is no space left in the message, a new one will be created

Experimental results ► Tmax = 0.3s, Tr = 0.1s ► byte packets sent ► Exponential increase in delay happens at 11% loss rate or higher

PSFQ Summary ► Slow data dissemination, fast data recovery  All transmissions are broadcast ► NACK-based, hop-by-hop recovery  End-to-end behaves poorly in lossy environments  NACKs are superior to ACKs in terms of energy savings ► No out-of-order delivery allowed  Uses data caching extensively ► Several timers and duplicate suppression mechanisms  Implementing any of those on motes is challenging (non-preemptive FIFO scheduler)

What more can be done at “transport” ► Robust “transport”  Now rely on end to end based approach: slow  Possible new way: Location-based, rather than node- based design ► Application perspective  Support aggregation ► reliability & rate control & semantic aggregation  Look at what application you have ► Tradeoff of different metrics & requirements