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

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

3. 1-3

4. 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, …

5. 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

6. 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

7. 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.

8. 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.

9. 1-9 SWSP overview

10. 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

11. 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.

12. 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).

13. 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?

14. 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

15. 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.

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

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

18. 1-18 ESRT operation

19. 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).

20. 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

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

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

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

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

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

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

27. 1-27 PSFQ

28. 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.

29. 1-29 Goals r Simplicity. r Robustness. r Scalability. r Customizability.

30. 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

31. 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.

32. 1-32 Multi-hop packet forwarding 1234 1 1 1 2 2 2 3 3 3 When no link Loss – multi-hop forwarding takes place

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

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

35. 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.

36. 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 21 1 1 1 t

37. 1-37 “Fetch Quickly” Operation 21 1 1 2 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.

38. 1-38 “Proactive Fetch” T proc 12 last-1 last

39. 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.

40. 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

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

42. 1-42 Error tolerance

43. 1-43 Average latency

44. 1-44 Overhead

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