1-1 CMPE 259 Sensor Networks Katia Obraczka Winter 2005 Transport Protocols

1-2 Announcements r Projects posted. r Some projects will be presented/discussed at the end of class today. r Proposals due by Friday,

1-3

1-4 Motivation  What is expected out of a transport protocol for sensor networks ? Reliability, congestion control.  Why can’t we use the existing protocols ? Resource constraints – power, storage, computation complexity, data rates, …

1-5 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-6 Motivation..cont’d. In general, Low data Rate High data Rate Power limited Not power limited Storage limited Not storage limited Sink user

1-7 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-8 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-9 SWSP overview

1-10 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-11 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-12 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-13 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-14 Event-to-Sink Reliable Transport (ESRT) for Wireless Sensor Networks Salient Features: 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-15 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-16 ESRT problem definition Determine reporting frequency of source nodes to achieve required reliability at sink with minimum resource consumption.

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

1-18 ESRT operation

1-19 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-20 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-21 Performance results (based on simulations) r Starting with no congestion and low reliability:

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

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

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

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

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

1-27 PSFQ

1-28 Motivation r Most sensor network applications do not need reliability? m Sources => sink. r New applications like re-tasking of sensors need reliable transport. 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-29 Goals r Simplicity. r Robustness. r Scalability. r Customizability.

1-30 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-31 Goals of PSFQ: Pump Slowly and Fetch Quickly r Recover from losses locally. r Minimum signaling. r Operate correctly in lossy environments. r Independent of underlying routing infrastructure.

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

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

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

1-35 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-36 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-37 “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-38 “Proactive Fetch” T proc 12 last-1 last

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

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

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

1-42 Error tolerance

1-43 Average latency

1-44 Overhead

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