Transport Layer Issues for Ad hoc WSN

1. Transport Layer Issues for Ad hoc WSN Ideas for Today and Tomorrow Faisal Karim Shaikh DEEDS, TU Darmstadt, Germany fkarim@deeds.informatik.tu-darmstadt.de

2. Vision Statement • Reliable and Robust bi-directional (sink to sensors and sensors to sink) transport protocol for Ad-hoc Wireless Sensor Networks

3. To the knowledge … • Up to this point Reliability and Robustness has been ignored; • Possible reason: -- WSN is low-cost; -- Not necessary (due to redundant data) -- and also difficult. • But … • We require reliability … • Disaster Recovery • Military Applications etc

4. Focus • To achieve reliability • Reliable Transport Layer • No packet loss • Bi-directional Reliability Figure from Akyildiz et al, “Wireless Sensor Networks: A Survey”, Computer Networks, 38(4):393-422, 2002.

5. Is it challenging ? • Limitations of sensor nodes • Application specific requirements Objectives • Reliable Transport • Flow Control • Congestion Control • Self Configuration • Energy Awareness

6. Types of data • Single Packet • Block of packets • Stream of Packets

7. Today’s Situation Downstream Reliability: from Sink to Sensors • Reliability semantics are different • 100% (on cost of scarce resources?) • PSFQ (Block of packets data) • MOAP (Block of packets data) • GARUDA (Block of packets data) (Single Packet)

8. Pump Slowly, Fetch Quickly (PSFQ) • pace the data from a source node at a relatively low speed • to allow intermediate nodes to fetch missing data segments from their neighbors, • Assumption: no congestion, losses due only to poor link quality • hop-by-hop recovery Goals • Recover from losses locally. • Ensure data delivery with minimum support from transport infrastructure • Minimize signaling overhead for detection/recovery operations • Operate correctly in poor link quality environments • Provide loose delay bounds for data delivery to all intended receivers • Three basic operations: pump, fetch, and report • Alternate between multi-hop forwarding when low error rates and store-and-forward when error rates are higher.

9. PSFQPUMP OPERATION If not duplicate and in-order and TTL not 0 Cache and Schedule for Forwarding at time t (Tmin< t < Tmax) 1 2 1 t Tmin 1 Tmax Tmin 1 Tmax

10. PSFQFETCH MODE (Recovery from Errors) 3 1 2 4 1 1 2 2 lost 1 3 Recover 2 2 2 2 3 3

11. PSFQFetch Quickly 1 2 1 1 2 2 lost 3 Recover 2 Tr Tr 2 Tmin 2 Tmax

12. PFSQREPORT • Used to provide feedback data of delivery status to source nodes • To minimize the number of messages, the protocol is designed so that a report message travels back from a target node to the source nodes intermediate nodes can also piggyback their report messages in an aggregated manner Simulation and experimental evaluation • When compared to a previously proposed similar protocol (Scalable Reliable Multicast) the simulation results show that the PFSQ protocol has a better performance in terms of error tolerance, communications overhead, and delivery latency • The experimental results were obtained by using the TinyOS platform on RENE motes. The performance results were much poorer than the simulation results. The discrepancy is attributed to the simulation experiment being unable to accurately model the wireless channel and the computational demands on the sensor node processor

13. PSFQ - Conclusions • Light weight and energy efficient • Simple mechanism • Scalable and robust • Need to be tested for high bandwidth applications • Cache size limitation • Does not address congestion control

14. GARUDA • It incorporates an efficient pulsing based solution, which informs the sensor nodes about an impending reliable short-message delivery by transmitting a specific series of pulses at a certain amplitude and period. • A virtual infrastructure called the core that approximates a near optimal assignment of local designated servers is instantaneously constructed during the course of a single packet flood. • In case of a packet loss detected by a core node via an out-of-sequence packet reception, a core node initiates a two-stage NAK based packet recovery process that performs out-of-sequence forwarding to assure the reliable delivery of the original message.

15. GARUDA • Packet forwarding • Out-of-sequence forwarding for better spatial reuse • Loss detection • NACK to avoid ACK implosion • Loss recovery • Local, designated scheme to decrease contention with packet forwarding

16. GARUDA WFP (Wait-for-First-Packet) pulses • Used only for first packet reliability • Short duration pulses • Single radio • Advertisement of incoming packet • Negative ACK • Simple energy detection Different types of WFP • Forced pulses • Carrier sensing pulses • Piggybacked pulses

17. GARUDA • A sink sends WFP pulses periodically Before it sends the first packet For a deterministic period • A sensor sends WFP pulses periodically After it receives WFP pulses Until it receives the first packet • WFP merits Prevents ACK implosion with small overhead Addresses the single or all packet lost problem Less energy consumption Robust to wireless errors or contentions

18. GARUDA • Core Construction • Distributed MDS • Two phase Loss Recovery • A-map

19. GARUDA GARUDA also supports other reliability semantics that might be required for sink-to-sensors communication such as • reliable delivery to all nodes within a sub-region of the sensor network; • reliable delivery to minimal number of sensors required to cover entire sensing area; and • reliable delivery to a probabilistic subset of the sensor nodes in the network.

20. GARUDA

21. MOAP: Overview • Code distribution mechanism specifically targeted for Mica2 motes • Full binary updates • Multi-hop operation achieved through recursive single-hop broadcasts • Energy and memory efficient

22. MOAP Ripple Dissemination • Transfer data neighborhood-by-neighborhood (Ripple) • Single-hop • Recursively extended to multi-hop • Very few sources at each neighborhood • Preferably, only one • Receivers attempt to become sources when they have the entire image • Publish-subscribe interface prevents nodes from becoming sources if another source is present • Leverage the broadcast medium • If data transmission is in progress, a source will always be one hop away! • Allows local repairs • Increased latency

23. MOAP Reliability Mechanism • Loss responsibility lies on receiver • Only one node to keep track of (sender) • NACK-based • In line with IP multicast and WSN reliability schemes • Local scope • No need to route NACKs • Energy and complexity savings • All nodes will eventually have the same image

24. MOAP Retransmission Policies • Unicast RREQ, single reply • Smallest probability of successful reception • Highest efficiency • Simple • Complexity increases if source fails • Zero latency • High latency if source fails

25. MOAP Segment Management • Sliding window • Bitmap of up to w segments kept in RAM • Starting point: last segment received in order • RAM lookup • Limited out-of-order tolerance!

26. MOAP Current Mote implementation • Using Ripple-sliding window with unicast retransmission policy • User builds code on the PC • Packetizer creates segments out of binary • Mote attached to PC becomes original source and sends PUBLISH message • Receivers 1 hop away will subscribe, if version number is greater than their own • When a receiver gets the full image, it will send a PUBLISH message • If it doesn’t receive any subscriptions for some time, it will COMMIT the new code and invoke the bootloader • If a subscription is received, node becomes a source • Eventually, sources will also commit • Retransmissions have higher priority than data packets • Duplicate requests are suppressed • Nodes keep track of their sources’ activity with a keepalive timer • Solves NACK ‘last packet’ problem • If the source dies, the keepalive expiration will trigger a broadcast repair request • Late joiner mechanism allows motes that have just recovered from failure to participate in code transfer • Requires all nodes to periodically advertise their version • Footprint • 700 bytes RAM • 4.5K bytes ROM

27. MOAP: Conclusion • Full binary updates over multiple hops • Ripple dissemination reduces energy consumption significantly • Sliding window method and unicast retransmission policy also reduce energy consumption and complexity • Successful updates of images up to 30K in size

28. Today’s Situation Upstream Reliability: from sensors to Sink • New notion • Event to Sink • RMST (Block of packets data) • CODA • ESRT (Streaming data)

29. Sink Reliable Multi-Segment Transport (RMST) • End-to-end data-packet transfer reliability • Each RMST node caches the packets • When a packet is not received before the so- called WATCHDOG timer expires, a NAK is sent backward • The first RMST node that has the required packet along the path retransmits the packet • In-network caching brings significant overhead in terms of power and processing • Relies on Directed Diffusion Scheme RMST Node Source Node

30. RMST: Overview • A transport layer protocol • Uses diffusion for routing • Selective NACK-based • Provides • Guaranteed delivery of all fragments • In-order delivery not guaranteed • Fragmentation/reassembly

31. RMST Placement of reliability for data transport • RMST considers 3 layers • MAC • Transport • Application • Focus is on MAC and Transport

32. RMST MAC Layer Choices • No ARQ • All transmissions are broadcast • No RTS/CTS or ACK • Reliability deferred to upper layers • Benefits: no control overhead, no erroneous path selection • ARQ always • All transmissions are unicast • RTS/CTS and ACKs used • One-to-many communication done via multiple unicasts • Benefits: packets traveling on established paths have high probability of delivery • Selective ARQ • Use broadcast for one-to-many and unicast for one-to-one • Data and control packets traveling on established paths are unicast • Route discovery uses broadcast

33. RMST Transport Layer Choices • End-to-End Selective Request NACK • Loss detection happens only at sinks (endpoints) • Repair requests travel on reverse (multihop) path from sinks to sources • Hop-by-Hop Selective Request NACK • Each node along the path caches data • Loss detection happens at each node along the path • Repair requests sent to immediate neighbors • If data isn’t found in the caches, NACKs are forwarded to next hop towards source

34. RMST Application Layer Choices • End-to-End Positive ACK • Sink requests a large data entity • Source fragments data • Sink keeps sending interests until all fragments have been received • Used only as a baseline

35. RMST details • Implemented as a Diffusion Filter • Takes advantage of Diffusion mechanisms for • Routing • Path recovery and repair • Adds • Fragmentation/reassembly management • Guaranteed delivery • Receivers responsible for fragment retransmission • Receivers aren’t necessarily end points • Caching or non-caching mode determines classification of node

36. RMST Details (cont’d) • NACKs triggered by • Sequence number gaps • Watchdog timer inspects fragment map periodically for holes that have aged for too long • Transmission timeouts • ‘Last fragment’ problem • NACKs propagate from sinks to sources • Unicast transmission • NACK is forwarded only if segment not found in local cache • Back-channel required to deliver NACKs to upstream neighbors

37. RMST: Conclusion • ARQ helps with unicast control and data packets • In high error-rate environments, routes cannot be established without ARQ • Route discovery packets shouldn’t use ARQ • Erroneous path selection can occur • RMST combines a NACK-based transport layer protocol with S-ARQ to achieve the best results

38. Congestion Detection and Avoidance (CODA) CODA mainly aims to detect and avoids CONGESTION on the forward path via • receiver-based congestion detection, • open-loop hop-by-hop backpressure • signaling to inform the source about the congestion, • closed-loop multi-source regulation for persistent and larger-scale congestion conditions. • Simulation results show that CODA can increase the network performance by congestion avoidance. • However, the CODA protocol does not address the reliable event transport in the sensor networks. • On the contrary, it has been observed in the experiments that the congestion control performed at the sensor nodes without considering the reliability impairs the end-to-end reliability.

39. Congestion Detection and Avoidance (CODA) • Energy efficient congestion control scheme • Three mechanisms are involved • Congestion Detection • Open-loop hop-by-hop backpressure • Closed-loop multi-source regulation

40. CODA Congestion Detection • Accurate and efficient congestion detection is important • Buffer queue length or Buffer occupancy – not a good measure of the congestion. • Channel loading – sample channel at appropriate time to detect congestion. • Report rate/Fidelity measurement – slow, observed over a longer period

41. 1 2 3 4 Congestion detected 5 2 CODA Open-Loop Hop-by-Hop Backpressure

42. 1 2 Regulate bit is set 1,2,3 ACK 4,5,6 Congestion detected 7,8 ACK CODA Closed Loop Multi-Source Regulation

43. CODA Performance – Cost Metrics • Average Energy Tax = Total Packets dropped in sensor NW / Total Packets received at Sink • Average Fidelity Penalty = Measures difference between average number of packets delivered at a sink using CODA and using ideal congestion scheme Conclusion • CODA is a energy efficient protocol • Can deal with Persistent and Transient Hotspots

44. Event-to-Sink Reliable Transport (ESRT) • In a typical sensor network application the sink node is only interested in the collective information of the sensor nodes within the region of an event and not in any individual sensor data • What is needed is a measure of the accuracy of the information received at the sink, i.e. and event-to-sink reliability

45. ESRT • The basic assumption is that the sink does all the reliability evaluation using parameters that are application dependent • One such parameter is the decision time interval τ • At the end of the decision interval the sink derives a reliability indicator ribased on the reports received from the sensor nodes • ri is the number of packets received in the decision interval • If R is the number of packets required for reliable event detection then ri > R is needed for reliable event detection • There is no need to identify individual sensor nodes but instead there is the need to have an event ID • The reporting rate, f, of a sensor node is the number of packets sent out per unit time by that node • The ESRT protocol aims to dynamically adjust the reporting rate to achieve the required detection reliability R at the sink

46. r versus f based on simulation results ESRT n = number of source nodes for f > fmax the reliability drops because of network congestion r increases with the source reporting rate f

47. ESRT – Protocol Overview • The algorithms mainly run on the sink • Sensor nodes: • Listen to sink broadcasts and update their reporting rates accordingly • Have a simple congestion detection mechanism and report to the sink • The sink: • Computes a normalized reliability measure ηi = ri /R • Updates f based on ηi and if f > fmax or < fmax in order to achieve the desired reliability • Performs congestion decisions based on feedback reports from the source nodes • Congestion detection: • Uses local buffer level monitoring in sensor nodes • When a routing buffer overflows the node informs the sink by setting the congestion notification bit in the header packets traveling downstream

48. ESRT – Network States Optimal Operating Region (Congestion, High reliability) (No congestion, High reliability) (Congestion, Low reliability) (No congestion, Low reliability)

49. ESRT – Frequency Update

50. ESRT – Summary and Conclusions • Sensor networks are more interested in event to sink reliability than on individual end-to-end reliability • The congestion control mechanism results in energy savings • Analytical performance evaluation and simulation results show that the system converges to the state OOR regardless of the initial state • This self configuration property of the protocol is very valuable for random and dynamic topologies • Issues still to be addressed are: • Extension to handle concurrent multiple events • Development of a bi-directional reliable protocol that includes the sink-to-sensor transport