Transport Protocols for Sensor Networks

1. Transport Protocols for Sensor Networks Nischal M. Piratla Sangeetha L. Bangolae Tarun Banka Computer Networking Research Laboratory Colorado State University

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

3. Motivation ..contd. • 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 limited Not Power limited Storage limited Not Storage limited Bursty samples Periodic samples

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

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

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

7. ESRT’s Definition of Reliability • Reliability is measured in terms of the number of packets received. Or reporting frequency i.e., number of packets/decision interval. • Observed reliability: number of received data packets in decision interval at the sink. • Desired reliability: number of packets required for reliable event detection. • Normalized reliability = observed/desired.

8. ESRT operation

9. 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 increase) • If no congestion and low reliability: increase reporting frequency aggressively (multiplicative increase) • If no congestion and high reliability: decrease reporting slowing (half the slope)

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

11. Analytical Results Analytical results (intuitive yet useful) .. We will skip this slide • Starting from no congestion, high reliability and with linear reliability behavior when the network is not congested, the network state remains unchanged until ESRT converges • Starting from no congestion, high reliability, and with linear reliability behavior when the network is congested, ESRT converges to optimum operating range in t[log2((-1)/)] • With linear reliability behavior when the network is not congested, the network state transition from congestion, high reliability to no congestion, low reliability.

12. Performance Results (based on simulations) please refer to the paper for graphs .. They may not be legible here • Starting with no congestion and low reliability:

13. Performance Resultscontd…(based on simulations) • Starting with no congestion and high reliability:

14. Performance Resultscontd…(based on simulations) please refer to the paper for graphs • Starting with congestion and high reliability:

15. Performance Resultscontd…(based on simulations) please refer to the paper for graphs • Starting with congestion and low reliability:

16. Performance Resultscontd…(based on simulations) please refer to the paper for graphs • Average power consumption while starting with no congestion and high reliability:

17. Challenges with ESRT • Multiple concurrent events. • Congestion may be due to all sensor nodes. Can there be a better way to slow down the nodes causing the congestion ? • Buffer occupancy and congestion. We will now move to TRABOL.

18. Gigabit Networking: Digitized Radar Data Transfer and BeyondSangeetha L.Bangolae, Anura P. Jayasumana, V. Chandrasekar Sangeetha L. Bangolae (Sang) Computer Networking Research Lab Colorado State University

19. Motivation • Present a new class of high-bandwidth (64 – 384 Mbps) application – VCHILL radar • Discuss the transport protocols to satisfy real-time radar data transfer over high-speed links • Congestion Control to be TCP-friendly * VCHILL – Virtual CHILL

20. Gigabit Networking Applications • Digital Earth • Bio-medical Tele Immersion • NASA • Virtual MechanoSynthesis • Digital Sky • VCHILL

21. VCHILL Radar Application • AIM • Transfer and Display of Digitized Radar Signals in real-time over the NGI (Next Generation Internet) • Remote Control of the radar

22. VCHILL Radar Application CHARACTERISTICS • High-bandwidth requirement for best operation; A high responsiveness to available bandwidth. • Satisfactory operation with a minimum bandwidth threshold possible; Yet increase in bandwidth provides a better display image. • Tolerance to losses and end-to-end delay high, compared to audio and video streaming media. • Smoothness (delay jitter) not critical for proper functioning.

23. CSU-CHILL Doppler Radar 11 cm wavelength Dual-polarization Radar

24. Real-time video TCP Server Remote Client Signal Processing Radar Display Shared Memory RDP(TRABOL) Server Internet Digitized Radar Signal End User Application High Speed Link 400/800 Mbps Multicast Server Current Status Display: PPI/RHI (Plan Position Indicator/Range Height Indicator) End stations: Sun Solaris based Signal Processing: DSP Software based

25. Gate1 VVI(1)VVQ(1) VVI(2)VVQ(2) VVI(3)VVQ(3) VVI(4)VVQ(4) HHI(1)VVQ(1) HHI(2)VVQ(2) HHI(3)HHQ(3) HHI(4)HHQ(4) Gate2 VVI(1)VVQ(1) VVI(2)VVQ(2) VVI(3)VVQ(3) VVI(4)VVQ(4) HHI(1)VVQ(1) HHI(2)VVQ(2) HHI(3)HHQ(3) HHI(4)HHQ(4) Gate3 VVI(1)VVQ(1) VVI(2)VVQ(2) VVI(3)VVQ(3) VVI(4)VVQ(4) HHI(1)VVQ(1) HHI(2)VVQ(2) HHI(3)HHQ(3) HHI(4)HHQ(4) | | | | | | | | Gate1000 VVI(1)VVQ(1) VVI(2)VVQ(2) VVI(3)VVQ(3) VVI(4)VVQ(4) HHI(1)VVQ(1) HHI(2)VVQ(2) HHI(3)HHQ(3) HHI(4)HHQ(4) Radar Data Format One Ray of DRS Data 2nd Sample 3rd Sample 4st Sample 1st Sample Each Sample size: 16000 bytes

26. Radar Parameter Display Image UDP-based (RDP) DRS Transfer with no losses * RDP: Radar Data transfer Protocol

27. Radar Parameter Display Image UDP-based (RDP) DRS Transfer with 90% losses

28. Transport protocols and Congestion Control • VCHILL Application • TCP – too conservative, not suitable for real-time • UDP – Suitable for real-time, but No congestion control, flow control • Require a transport protocol for real-time data transfer - With Congestion control!

29. DRS Server DRS Client Radar DISPLAY 64 – 384 Mbps Data Congestion Parameter Acquisition Manager Estimation Data Feedback Feedback Data Transmission Manager Application Sender Reception Layer D ata Control Transport NGI/I2 Layer (UDP) VCHILL UDP-based DRS Transfer Architecture

30. TRABOL: TCP-friendly Rate Adaptation Based On Loss • Source-based Rate Control based on AIMD • If (Congestion) • Decrease sending rate to MIN_RATE • If (No Congestion) • Increase sending rate towards TARGET_RATE in steps • Congestion policies based on feedback from receiver

31. Feedback Mechanism

32. Datagram size = 32 KB Performance Evaluation Sending rate (Mbps) and Loss rate (%) for Radar Application without rate control

33. Performance Evaluation (contd…) Sending rate (Mbps) and Loss rate (%) for Radar Application with memory-based TRABOL

34. Summary • VCHILL as a NGI application • Current Status of the Project • Transport protocols for the application • UDP-based Radar data transfer protocol • Need for congestion Control • TRABOL and Performance Evaluation

35. Thank youQuestions!