1 / 45

CMPE 259

CMPE 259. Sensor Networks Katia Obraczka Winter 2005 Transport Protocols. Announcements. Projects posted. Some projects will be presented/discussed at the end of class today. Proposals due by Friday, 01.21. Motivation. What is expected out of a transport protocol for sensor networks ?

joan-barr
Télécharger la présentation

CMPE 259

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. Motivation ..cont’d. • Application specific. • Spectra for known constraints: Low data Rate High data Rate Power limited Not Power limited Storage limited Not Storage limited Bursty samples Periodic samples

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

  6. SWSP • Simple Wireless Sensor Protocol. • Design challenges: • Limited capabilities. • Assumptions: • “Fixed network” topology. • Access points as data collectors.

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

  8. SWSP overview

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

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

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

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

  13. S Event-to-Sink Reliable Transport (ESRT) for Wireless Sensor Networks Salient Features: • Event-to-sink reliability. • Self-adjusting. • Energy awareness [low power consumption requirement!]. • Congestion control. • Different complexity at source and sink.

  14. 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. • Reporting rate: number of packets sent by sensor over time interval. • Normalized reliability: observed/desired.

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

  16. Preliminary observations: • Reliability increases as reporting frequency increases up to a certain threshold. • Why?

  17. ESRT operation

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

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

  20. Performance results (based on simulations) • Starting with no congestion and low reliability:

  21. Performance results cont’d • Starting with no congestion and high reliability:

  22. Performance results cont’d • Starting with congestion and high reliability:

  23. Performance results cont’d • Starting with congestion and low reliability:

  24. Performance results cont’d • Average power consumption while starting with no congestion and high reliability:

  25. Challenges with ESRT • Multiple concurrent events. • Is there a way to slow down the nodes causing the congestion ? • Others?

  26. PSFQ

  27. Motivation • Most sensor network applications do not need reliability? • Sources => sink. • New applications like re-tasking of sensors need reliable transport. • Sink => sources. • Current sensor networks are application specific and optimized for that purpose. • Future sensor networks may be general purpose to some extent – ability to re-program functionality.

  28. Goals • Simplicity. • Robustness. • Scalability. • Customizability.

  29. Probability of successful delivery using end-to-end model 1 (1-p) 2 n-1 (1-p)n-1 n (1-p)n p is the error rate of wireless link between two hops

  30. Goals of PSFQ: Pump Slowly and Fetch Quickly • Recover from losses locally. • Minimum signaling. • Operate correctly in lossy environments. • Independent of underlying routing infrastructure.

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

  32. 1 3 4 2 1 1 1 2 lost 3 3 Recover 2 3 Recover 2 Recover 2 Recovering from errors Error recovery messages are wasted

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

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

  35. 1 2 1 t Tmin 1 Tmax Tmin 1 Tmax PSFQ Pump Schedule If not duplicate and in-order and TTL not 0 then Cache and schedule for forwarding at time t (Tmin<t<Tmax)

  36. 1 2 1 1 2 2 lost 3 Tr Tr Recover 2 2 Tmin 2 Tmax “Fetch Quickly” Operation When loss detected, then fetch mode. Loss aggregation: try to recover a window of lost packets.

  37. 1 2 last-1 last Tproc last “Proactive Fetch”

  38. Report • Report aggregation. • Carries status information: node id, seq. #. • Triggered by user. • Inject data message with “report” bit set.

  39. Performance evaluation • Compare with SRM (Scalable Reliable Multicast) • Performance Metrics • Average Delivery Ratio • Average Latency • Average Delivery Overhead

  40. Experimental setup 2 Mbps CSMA/CA Channel Access Tmax = 100ms Tmin = 50ms Tr = 20ms

  41. Error tolerance

  42. Average latency

  43. Overhead

  44. Conclusion - PSFQ • Light weight and energy efficient • Simple mechanism • Scalable and robust • Need to be tested for high bandwidth applications • Cache size limitation

More Related