210 likes | 335 Views
Robcast: A singlehop reliable broadcast protocol for WSNs. Murat Demirbas Srivats Balachandran University at Buffalo, SUNY. Singlehop reliable (?) broadcast. Reliable broadcast is important
E N D
Robcast: A singlehop reliable broadcast protocol for WSNs Murat Demirbas Srivats Balachandran University at Buffalo, SUNY
Singlehop reliable(?) broadcast • Reliable broadcast is important • Safety (consistency) reasons: Sensor/actuator devices coordinating regulator valves should take consistent decisions to prevent a malfunction • Performance (goodput) reasons: Unreliable broadcast wastes the bandwidth • Hidden terminal problem may account for loss of 50% of traffic • Hidden terminal problem occurs when two senders are not in range of each other (carrier sensing fails), but are in range of a common receiver
RTS-CTS achieves reliable unicast • Sender transmits a Request to Send (RTS) • Destination node replies with a Clear To Send (CTS) • Any other node receiving the CTS frame should refrain from sending data for a given time (solves hidden terminal) • RTS/CTS provides virtual carrier sensing
RTS-CTS fails for broadcast • Direct application sacrifices reliability • CTSs collide at the initiator making it impossible to know if all neighbors are ready to receive • CTS from any neighbor is used as sufficient for data transmission (BSMA) • Reliable application sacrifices efficiency • Individual RTS-CTS handshake is performed with each neighbor before data is transmitted (BMMM)
Our contribution: Robcast • Robcast addresses the singlehop broadcast problem both efficiently and reliably • Robcast uses bandwidth efficiently • Bandwidth is not statically allocated among nodes as in TDMA • Robcast is an on-demand access protocol, nodes contend for the channel • Robcast is useful for standardization efforts in WSNs • SP focuses on singlehop broadcast as narrow-waist for standardization • Two main ideas are: • Collision detection at the receiver-side is employed for feedback collection • Although positive feedback do not compose, negative feedback compose
Receiver-side collision detection (RCD) • Carrier sensing at the transmitter-side is impossible • Carrier sensing at the receiver-side is feasible and is widely used for CSMA • RCD is achievable using the same basic techniques as CSMA • Channel activity can be differentiated from noise
RCD using CC2420 radio • Received Signal Strength Indicator (RSSI) based collision detection • requires additional processing on the processor, unreliable • Cyclic Redundancy Check (CRC) based collision detection • reliable, but only works when preamble and packet frame are received • Clear Channel Assessment (CCA) based collision detection • can detect collisions even when the preambles are not detected • CCA signal is generated only after a transmission is scheduled to the radio, so we manipulate the radio to perform CCA also in the idle state
Robcast protocol • Nodes are synchronized to maintain rounds with 3 phases • This structure facilitates RCD-based feedback collection by providing context • A collision at the RTS phase means multiple initiators are trying to transmit • A collision at the NCTS phase means multiple nodes are reporting conflicts • Robcast avoids any collisions in the DATA phase • Positive feedback (CTS) do not compose, yet negative feedback (NCTS) do compose nicely j RTS NCTS DATA k l
INITIATOR Bcast (RTS) Listen for NCTS or collision If no NCTS or collision Bcast (DATA) Else backoff for some rounds RECEIVERS Listen for RTS or collision If collision Bcast(NCTS) Listen for DATA if any Robcast protocol… RTS NCTS DATA
Scenario 1: success Scenario 2: deferral DATA RTS NCTS RTS NCTS RTS Phase: NCTS Phase: RTS Phase: RTS Phase: DATA Robcast protocol… A B C A B C Phase: DATA Phase: NCTS
Extensions… • Reducing idle listening • Sleep through the rest of the round if no activity is scheduled • Data phase may account for around 90% of the total time • Multiple round-length packets • Explained in the paper
B C A Our previous work on BEMA • BTMA • Use a control channel for signaling busy for ongoing transmissions • Separate radio infeasible for WSNs • BEMA • Synchronized rounds, leader is elected based on duration of BUSY signals • Double power transmissions during CONTROL phase • Locked nodes always transmit BUSY signals • Requires a more finer-granularity RCD • Eliminates hidden terminals • DATA collisions still occur due to equal length of BUSY signal • Susceptible to obstacle arrangements
Simulations • Prowler • A MATLAB-based, event driven simulator for WSNs • Simulates a Rician fading model • Setup • 5x5 grid of motes • With varying number of nodes transmitting data
Goodput Goodput= data/ settling time
Concluding remarks • Reliable broadcast is significant for many applications • Robcast achieves lightweight reliable broadcast assuming synchronized rounds • RCD is used for singlehop collaborative feedback collection • Future work is to investigate synchronization free solutions to reliable broadcast
iComp www.cse.buffalo.edu/~demirbas
Our ongoing work:Lightweight singlehop collaboration • The idea is to use receiver-side collision detection (RCD) for lightweight singlehop collaborative feedback • Applications in filtering false-positives, leader election, clustering, etc… • Pollcast: Does P hold for the neighborhood? • Nodes where P holds answer simultaneously • Initiator uses RCD to detect whether there are answers • Initiator can followup with a broadcast
Generalization to counting • Initiator uses pollcasts to approximate # of nodes P holds • Each node has a 0.5 probability of voting at each round & they only vote once in their lifetime • Expected number of voters is halved in each round • Expected number of such rounds for n nodes is logn • Bayesian inference is useful for categorizing the result • Applications in in-network classification of intruders: soldier, car, tank
Assurance ? • poll + vote is enough for best-effort primitives, but how do we achieve reliable (or eventually reliable) primitives • in the absence of synchronization, how do we decide whether poll is heard by all nodes in the neighborhood ? • poll + veto + vote approach where a veto is sent following any RCD leads to veto storms • channel reservation based approaches may be useful for reliability • Or, is it better to use the lightweight primitive and build assurance on top of this primitive ? • if you stand back fast enough, no one notices you fell down