Cross Layer Design in Wireless Ad Hoc Networks with Multiple Antennas
Transport Layer Issues for Ad hoc WSN
description
Transcript of Transport Layer Issues for Ad hoc WSN
Transport Layer Issues for Ad hoc WSNIdeas for Today and Tomorrow
Faisal Karim ShaikhDEEDS, TU Darmstadt, [email protected]
DEEDS
Vision Statement
Reliable and Robust bi-directional (sink to sensors and sensors to sink) transport protocol for Ad-hoc Wireless Sensor Networks
DEEDS
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
DEEDS
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.
DEEDS
Is it challenging ? Limitations of sensor nodes Application specific requirements
Objectives Reliable Transport Flow Control Congestion Control Self Configuration Energy Awareness
DEEDS
Types of data
Single Packet Block of packets Stream of Packets
DEEDS
Today’s SituationDownstream 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)
DEEDS
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 recoveryGoals• 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.
DEEDS
PSFQPUMP OPERATION
If not duplicate and in-order and TTL not 0Cache and Schedule for Forwarding at time t (Tmin< t < Tmax)
Tmin
Tmax Tmin
Tmax
1
1
1
t
1 2
DEEDS
PSFQFETCH MODE (Recovery from Errors)
2 lost
Recover 2
1
2
3
2
1 2 3 4
1
1
22
33
DEEDS
PSFQFetch Quickly
1
1
2 lost
2
3
Tmin
Tmax
Tr
Recover 2Tr
2
2
1 2
DEEDS
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
DEEDS
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
DEEDS
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.
DEEDS
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
GARUDA
DEEDS
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
GARUDA
DEEDS
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
GARUDA
DEEDS
Core Construction Distributed MDS
Two phase Loss Recovery A-map
GARUDA
DEEDS
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.
DEEDS
GARUDA
DEEDS
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
DEEDS
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
MOAP
DEEDS
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
MOAP
DEEDS
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
MOAP
DEEDS
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!
MOAP
DEEDS
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
MOAP
DEEDS
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
DEEDS
Upstream Reliability: from sensors to Sink
Today’s Situation
New notion Event to Sink
RMST (Block of packets data) CODA ESRT (Streaming data)
DEEDS
Reliable Multi-Segment Transport (RMST)
SinkSink
RMST Node
Source Node
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 packetIn-network caching brings significant overhead in terms of power and processingRelies on Directed Diffusion Scheme
DEEDS
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
DEEDS
Placement of reliability for data transport
RMST considers 3 layers MAC Transport Application
Focus is on MAC and Transport
RMST
DEEDS
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
RMST
DEEDS
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
RMST
DEEDS
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
RMST
DEEDS
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
DEEDS
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
DEEDS
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
DEEDS
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.
DEEDS
Energy efficient congestion control scheme Three mechanisms are involved
Congestion Detection Open-loop hop-by-hop backpressure Closed-loop multi-source regulation
Congestion Detection and Avoidance (CODA)
DEEDS
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
CODA
DEEDS
Open-Loop Hop-by-Hop Backpressure
CODA
Congestion detected
1 2 3
4
5
2
DEEDS
Closed Loop Multi-Source Regulation
1,2,3
ACK
4,5,6
Congestion detected
7,8
Regulate bit is set
ACK
1 2
CODA
DEEDS
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
DEEDS
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
DEEDS
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 ri based 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
ESRT
DEEDS
ESRTr versus f based on simulation results
n = number of source nodes
r incre
ases w
ith th
e
source
reportin
g rate f
for f > fmax the reliability drops because of network congestion
DEEDS
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
DEEDS
ESRT – Network States
(No congestion, Low reliability)
(Congestion, Low reliability)
(Congestion, High reliability)
(No congestion, High reliability)
Optimal Operating Region
DEEDS
ESRT – Frequency Update
State f update Action(NC, LR) Multiplicative increase f to achieve
required reliability as soon as possible(NC, HR) Decrease f conservatively, reduce
energy consumption and not lose reliability
(C, HR) Aggressively decrease f to relieve congestion as soon as possible
(C, LR) Exponential decrease. k is the number of successive decision intervals spent in state (C, LR)
OOR Unchanged
i
ii
ff
1
121
i
ii
ff
1
i
ii
ff
1
)(1
kiii ff
ii ff 1
DEEDS
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
DEEDS
How Did We Get Here?Protocol Error
RecoveryReliability Direction
Congestion Ctrl
MAC/Routing Requirement
Sim OS Purpose Metrics
PSFQ h-h sink to sensors
-- Broadcast ns2 tos compare SRM
avg delivery ratio/overhead/
latency
GARUDA h-h/e-e sink to sensors
-- Broadcast ns2 -- loss recovery
Latency/energy consumption
MOAP h-h sink to sensors
-- broadcast/uni-cast
EmStar
tos Code Updates
Latency/energy consumption
RMST h-h/e-e event to sink -- DF ns2 -- evaluate tradeoffs
total bytes
ESRT -- collectiveevent to sink
event report frequency
CSMA/CA ns2 -- parameter tuning
convergence to OOR
CODA -- collective event to sink
event report frequency
CSMA ns2 tos parameter tuning
energy taxfidelity penalty
h-h = hop by hope-e = end to endDF = Directed Diffusiontos = Tiny OS
DEEDS
OVERALL VIEW
Wireless TCP variants are NOT suitable for WSN(resource constraints – power, storage, computational complexity, data rates)
Different notion of end-to-end reliability Huge buffering requirements ACKing is energy draining
DEEDS
Clusters ? Address reliable transport of concurrent multiple events in the sensor field Explore possible reliability metrics Develop unified transport layer protocols for bi-directional reliable transport in
WSN Integration of WSN domain into Internet
Adaptive Transport Protocols for WSN-Ad Hoc environments
What we looking for
DEEDS
References C.-Y. Wan, A. T. Campbell, “PSFQ: A reliable transport protocol for wireless sensor networks,” In
Proceedings of ACM WSNA’ 02, Sep. 28, 2002, Atlanta, USA.
F. Stann and J. Heidemann, “RMST: Reliable Data Transport in Sensor Networks,” In Proc. IEEE SNPA’03, May 2003, Anchorage, Alaska, USA
Y. Sankarasubramaniam, O. B. Akan, and I. F. Akyidiz, “ESRT: Event-to-sink reliable transport in wireless sensor networks,” In Proceedings of ACM Mobihoc’ 03, June 1-3, 2003, Annapolis, USA.
Thanos Stathopoulos et al, "A Remote Code Update Mechanism for Wireless Sensor Networks". Technical Report CENS-TR-30, University of California, Los Angeles, Center for Embedded Networked Computing, November 2003.
C.-Y. Wan, S. B. Eisenman, and A. T. Campbell, “CODA: CongestionDetection and Avoidance in Sensor Networks,” in Proc. ACM SENSYS 2003, November 2003.
S. J. Park, R.Vedantham, R. Sivakumar and I. F. Akyildiz, A Scalable “Approach for Reliable Downstream Data Delivery (GARUDA),” ACM MobiHoc’04 Conference, Japan, June 2004.