1-1 Transport Layer

1-2 Motivation  What is expected out of a transport protocol for sensor networks ? Reliability, QoS (e.g., delay guarantees, priority delivery), Congestion and flow control, Energy efficiency, Fairness.

1-3 Transport-Layer Challenges in WSNs r Variety of communication models including many-to-one. r Wireless communications. r Energy constraints. r Data centric QoS. m Instead of source-destination specificic. m E.g., “provide to sink sufficient quality of information about an event”.

1-4 Motivation..cont’d. r Application specific. r Spectra for known constraints: Low data Rate High data Rate Power limitedNot Power limited Storage limitedNot Storage limited Bursty samples Periodic samples

1-5 Motivation..cont’d. In general, Low data Rate High data Rate Power limited Not power limited Storage limited Not storage limited Sink user

1-6 Trend r Departure from TCP-like model. m Relies almost exclusively on end-to-end involvement. r In general, proposed protocols engage intermediate nodes. m Transport layer? m Cross-layer approach.

1-7 Existing Solutions r Reliable delivery. r Congestion control. r Real-time scheduling.

1-8 Reliable Delivery

1-9 PSFQ r Pump Slowly, Fetch Quickly. r Wan et al., ACM WSNA 2002.

1-10 Motivation r Most sensor network applications do not need 100% reliability. m Sources => sink. r But applications like re-tasking of sensors need reliable delivery. m Sink => sources. r Current sensor networks are application specific and optimized for that purpose. r Future sensor networks may be general purpose to some extent – ability to re- program functionality.

1-11 Goals r Provide lossless delivery. r Minimize control overhead. r Provide delay guarantee for delivery to all intended nodes.

1-12 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

1-13 PSFQ’s Main Principle r “Slow” data propagation (pump). r Enough time for hop-by-hop error recovery (fetch).

1-14 Multi-hop packet forwarding When no link Loss – multi-hop forwarding takes place

1-15 Recovering from errors lost Recover 2 Error recovery messages are wasted

1-16 How PSFQ recovers from errors: “store and forward” lost Recover No waste of error recovery messages

1-17 PSFQ operation r Alternate between multi-hop forwarding when low error rates and store-and- forward when error rates are higher. r 3 functions: m Pump: message relaying. m Error recovery: fetch. m Status reporting: report.

1-18 PSFQ Pump Schedule If not duplicate and in-order and TTL not 0 then Cache and schedule for forwarding at time t (T min <t<T max ) T min T max T min T max t

1-19 “Fetch Quickly” Operation lost 2 3 T min T max TrTr Recover 2 TrTr 2 2 When loss detected, then fetch mode. Loss aggregation: try to recover a window of lost packets.

1-20 “Proactive Fetch” T proc 12 last-1 last

1-21 Report r Report aggregation. r Carries status information: node id, seq. #. r Triggered by user. m Inject data message with “report” bit set.

1-22 Performance evaluation r Compare with SRM (Scalable Reliable Multicast) r Performance Metrics m Average Delivery Ratio m Average Latency m Average Delivery Overhead

1-23 Experimental setup 2 Mbps CSMA/CA Channel Access T max = 100ms T min = 50ms T r = 20ms

1-24 Error tolerance

1-25 Average latency

1-26 Overhead

1-27 Conclusion - PSFQ r Light weight and energy efficient r Simple mechanism r Scalable and robust r Need to be tested for high bandwidth applications r Cache size limitation

1-28 RMST

1-29 RMST r Reliable Multi-Segment Transport. r Where to do reliability? m MAC. m Transport. m Application.

1-30 MAC reliability r m RTS/CTS, Data, Ack. m Basic stop-and-wait ARQ. m No ARQ when in broadcast or multicast modes. Random slot selection. r Options: m No ARQ. m AEQ always. m Selective ARQ.

1-31 MAC reliability (cont’d) r Without ARQ: m Use broadcast mode. m For unicast: address screening at routing layer. m +’s: no overhead. r With ARQ: m Unicast transmissions. m For broad- & multicast, use multiple unicast. m Number of retries is configurable. r Selective ARQ: m Unicast uses ARQ. m Broad- and multicast use no ARQ. E.g., route discovery.

1-32 Transport reliability r Strictly e2e. m Initiated by sink. r Local recovery. m Intermediate nodes trigger repair when loss is detected. m Nodes cache packets. r NACK-based.

1-33 Application-layer reliability r Directed-diffusion based. m Sink sends out request (“interest”). m When complete data received, sink removes request.

1-34 Question? r Benefits of lower-layer reliability? r Additional overhead?

1-35 RMST overview r Functions: m Fragmentation/reassembly. m Guaranteed delivery. r Unique identifiers: m “No fragments”. m Fragment id’s and number of fragments. r Loss detection and repair: m Sequence # holes and timers. m Loss detection at either sinks or intermediate nodes. m NACKs.

1-36 Preliminary analysis r Demonstrate the benefits of hop-by-hop reliability.

1-37 RMST evaluation r MAC-only reliability. r Local recovery. m With and without MAC reliability. r End-to-end reliability. m With and without MAC reliability.

1-38 Observations r When there is no transport reliability: m MAC reliability critical in lossy links. r Hop-by-hop transport reliability: m Adds little to reliable MAC. m But, hop-by-hop transport reliability only more efficient than adding MAC reliability. MAC ARQ overhead incurred in every packet. r E2E transport reliability: m When no MAC reliability is used, simulation does not terminate: hop-by-hop recovery is critical. m If MAC reliability used, hop-by-hop and e2e transport reliability are equivalent.

1-39 Observations (cont’d) r Experiments with high error rates: m Hop-by-hop transport reliability without MAC reliability. m Hop-by-hop transport reliability+Sel. ARQ. m E2e transport reliability+ Sel. ARQ. r Hbh transport reliability without ARQ breaks down at high error rates. m Routing has hard time establishing routes.

1-40 SWSP r Simple Wireless Sensor Protocol. r Design challenges: m Limited capabilities. r Assumptions: m “Fixed network” topology. m Access points as data collectors.

1-41 Why not TCP? r Too heavy-duty. r Congestion control and wireless links. m Disable congestion control? m Low bandwidth. r Buffer size. m Small windows. r Multiple connections. m Single connection.

1-42 SWSP overview

1-43 SWSP overview Disconnected Connecting Disconnecting Ack wait Connected Requested Power off On Ack received Data request Data sent Leave Ack rec’d Data sent

1-44 Observations r Sensor registers with an AP. m Listens for RR messages. m Sends registration. m Waits for ACK => “connected” state. r Window size? r Periodic KA from sensors. r Data retransmitted after 3 retries. r ACKS piggybacked onto RR messages. r Data piggybacked onto KA messages.

1-45 SWSP evaluation r Methodology: m Platform: PC with Linux Simulated different sensors as different processes. AP simulated using another PC. Wireless communication. m Metrics: Throughput: # of bytes received by AP/time. Delay: time(ACK-recv’d) – time(data-sent).

1-46 SWSP evaluation (cont’d) r Throughput increases up to certain number of sensors; then decreases as sink gets overrun. r Delay increases substantially beyond a given number of sensors. r Solutions?

1-47 Congestion Control r Limited bandwidth. r Congestion is likely, e.g., when an event is detected.

1-48 Event-to-Sink Reliable Transport (ESRT) for Wireless Sensor Networks r Akyildiz et al., ACM Mobihoc 2003 r Event-to-sink reliability. r Self-adjusting. r Energy awareness [low power consumption requirement!]. r Congestion control. r Different complexity at source and sink. S

1-49 ESRT’s definition of reliability r Reliability is measured in terms of the number of packets received. Or reporting frequency i.e., number of packets/decision interval. r Observed reliability: number of received data packets in decision interval at the sink. r Desired reliability: number of packets required for reliable event detection. r Reporting rate: number of packets sent by sensor over time interval. r Normalized reliability: observed/desired.

1-50 ESRT problem definition Determine reporting frequency of source nodes to achieve required reliability at sink with minimum resource consumption.

1-51 Preliminary observations: r Reliability increases as reporting frequency increases up to a certain threshold. r Why?

1-52 ESRT operation

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

1-54 Components of ESRT r In sink: m Normalized reliability computation. m Congestion detection mechanism. r In source: m Listen to sink broadcast m Overhead free local congestion detection mechanism E.g., buffer level monitoring, CN – Congestion Notification

1-55 Performance results (based on simulations) r Starting with no congestion and low reliability:

1-56 Performance results cont’d r Starting with no congestion and high reliability:

1-57 Performance results cont’d r Starting with congestion and high reliability:

1-58 Performance results cont’d r Starting with congestion and low reliability:

1-59 Performance results cont’d r Average power consumption while starting with no congestion and high reliability:

1-60 Challenges with ESRT r Multiple concurrent events. r Is there a way to slow down the nodes causing the congestion ? r Others?

1-61 CODA

1-62 COngestion Detection and Avoidance r Importance of congestion control.

1-63 What is CODA ? r Energy efficient congestion control. r Three mechanisms are involved: m Congestion detection m Open-loop hop-by-hop backpressure. m Closed-loop multi-source regulation.

1-64 Congestion detection r Accurate and efficient congestion detection is important m Channel loading – sample channel at appropriate rate to detect congestion.

1-65 Open-loop h-by-h backpressure Congestion detected Upstream node decides to propagate backpressure or not.

1-66 Closed loop multi-source regulation 12 1,2,3 ACK 4,5,6 Congestio n detected 7,8 Regulate bit is set ACK

1-67 Congestion detection schemes r Buffer occupancy. m Not reliable in CSMA networks. r Channel loading. m Good for the immediate neighborhood. m Energy considerations. r Report rate. m Report rate goes down, congestion. m Detection based on report rate needs to react on longer time scale.

1-68 CODA overview r Combination of backpressure (fast time scale) with closed-loop congestion control. r Backpressure targets “local” congestion, whereas closed-loop regulation targets persistent congestion. r Backpressure is cheaper/simpler since it’s open loop. r Congestion control requires a feedback loop. m Uses ACK from sink to self-clock.

1-69 CODA performance metrics r Average Energy Tax = Total packets dropped in network / Total packets received at sink r Average Fidelity Penalty = Difference between average number of packets delivered at sink using CODA and using ideal congestion scheme.

1-70 Simulation Setup r Random network topologies with network size from 30 to 120 nodes. r 2Mbps IEEE MAC (RTS/CTS are disabled). r Directed diffusion is used as routing core. r Fixed work load, 6 sources and 3 sinks. r Source generate data at different rates. r Event packet is 64 bytes and interest packet is 36 bytes.

1-71 Simulation Results (Case 1: Dense Source, High Rate)

1-72 Simulation Results (Case 2: Sparse Sources, Low Rate)

1-73 Simulation Results Case 2: Sparse Source, Low Rate

1-74 Simulation Results (Case 3: Sparse Sources, High Rate) Network Size (#no of nodes)

1-75 Conclusion r CODA’s energy efficiency. r CODA’s ability to handle persistent and transient congestion.

1-76 Real-Time Scheduling r Some mission-critical applications may impose strict deadline delivery. r E.g., control and actuation, emergency response, surveillance. r Goal shifts from delivery reliability to minimizing packet deadline miss ratio.

1-77 Velocity Monotonic Scheduling r VMS is packet scheduling mechanism that schedules forwarding of packets based on: m Time until packet deadline expiration (t). m Physical distance (d) between current node and destination. m Required velocity v = d/t. m Packet priority directly proportional to its velocity.

1-78 VMS: Observations r Implementation via priority queues or separate FIFO queues. r Drop discipline: drop packets that have missed their deadline. r Cross-layer approach for packet scheduling: m Control random backoff at the MAC layer. m Packets with higher priority use smaller backoff.

1-79 Transport protocols: summary

1-80 Pump Slow Fetch Quickly PSFQ r For sink-to- source communication (e.g. network reprogramming) r Reliability via retransmissions r Sequence-driven loss detection C.Y. Wan, A.T. Campbell, and L. Krishnamurthy. PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks. WSNA'02, September 28, 2002, Atlanta, Georgia, USA.

1-81 RMST r End-to-end or hop-by-hop repair (the latter is generally better) r Suggests that repair could be done at either MAC layer (ARQ retransmissions) or Transport Layer (requests based on fragment numbers etc.) r Timer-driven loss detection and local data caches r Fits with the Directed Diffusion API F. Stann and J. Heidemann. RMST: Reliable Data Transport in Sensor Networks. IEEE SNPA'03.

1-82 ESRT r Aim for overall quality of service rather than node-to-node reliability Sankarasubramaniam, Y., Akan, O.B., and Akyildiz, I.F., "ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks ", In Proc. ACM MobiHoc`03

1-83 CODA Sankarasubramaniam, Y., Akan, O.B., and Akyildiz, I.F., "ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks ", In Proc. ACM MobiHoc`03 r Receiver based congestion detection r Open loop hop-by-hop backpressure r Closed-Loop multi-source regulation

1-84 Summarizing Transport Issues r Because of harsh conditions and severe constraints, it may be better to implement reliability in a hop-by-hop rather than end-to-end manner at either the MAC or transport layer r For energy efficiency, it is best to avoid congestion entirely, or have packet losses occur close to the source. Back pressure is a useful technique. r Where possible, scheduled solutions are preferable. s

1-85 WSN Transport: Considerations r Departure from TCP-like model. r Application dictates needed functionality. r Hop-by-hop reliability. r Why have a transport layer? r Transport protocol suite or flexible protocol which can be customized? r What kind of functionality? m E.g., for reliability, would link-layer error recovery suffice?