Message Efficient Termination Detection in Wireless Sensor Networks

1. Message Efficient Termination Detection in Wireless Sensor Networks Sandip Bapat Anish Arora The Samraksh Company The Ohio State University

2. Evolution of WSN systems • Scaling of physical sizes and scales • in 2004, ExScal spanned 250,000 sq.m with 1000+ nodes • indoor testbeds and installations of hundreds of nodes (Kansei, Motelab, etc.) • Scaling of software complexity • application requirements outgrow WSN mote resources • sensing, signal processing, routing, localization, reliable transport, network reprogramming, power management, health monitoring, … • sensor networks as reconfigurable fabrics • multiple applications sharing the same physical network • applications spanning multiple fabrics connected via the Internet as envisioned in GENI • Autonomous management support for wireless sensor network applications is critical

3. Need for Termination Detection • Detecting convergence of WSN protocols • gossip-based protocols like Deluge “run” forever, yet manager needs to know when new program is downloaded on all nodes • Detecting phase termination in multi-phase applications • phase: logical grouping of application tasks executable on a node • in-order requirement: next phase may depend on completion of previous phase • all phases depend on reprogramming • atomicity requirement: all nodes must complete before switching • phases may not be backward compatible • better performance if phase transitions are synchronized

4. Termination Detection in WSNs • Classical definition: safety and liveness requirements • detection  terminated • terminated detection • What’s new?: reactive computation model • energy is critical for low power WSNs • nodes do not compute forever, only in response to external events • WSN application protocol model: • idle active: receive (first) protocol message • active active: receive at least one protocol message every T seconds • active  terminated: no messages received for last T seconds • Energy efficiency • low communication overhead • Composability • reusable with different protocols • no dependence on protocol specifics

5. Existing Solutions • PIF (query) based protocols (SNMS, TinyDB) • build query-collection tree • periodically query entire network for termination status • simple optimization: set-up one time query (trigger) to respond upon termination • Drawbacks • inefficient • require separate spanning structure to be constructed and maintained • require response from every node • prone to message loss • create message burst when application protocol terminates, increasing contention and interference losses

6. The Reporter Protocol (1/3) BS: is_reporter = 1 1,2: seen_reporter = 1; parent = BS 1: is_reporter = 0 3,4: seen_reporter = 0; parent = 1 4: is_reporter = 1 3,5,6,7: seen_reporter = 1 5,6,7: parent = 4 BS 1 2 3 4 5 • Property 1: Reporter Set is a Dominating Set (DS) over nodes sending application messages • ideal solution: Reporter set is a • Minimum DS • MDS is NP-hard Reporter selection rule: during an application message send, a node becomes a reporter if no reporters have been heard from. 6 7

7. The Reporter Protocol (2/3) • Report collection • autonomous, efficient structure creation: exploit application traffic • parent = sender of first received application protocol message • similar to Dijkstra-Scholten’s algorithm • Property 2: Constructed structure is a spanning tree • simple, per-hop reliability: acks, buffering & retransmission • Local termination detection • reporters snoop application messages over broadcast channel • quiescent interval T  termination in one hop neighborhood • Property 3: Local termination detection by all reporters is sufficient to satisfy safety and liveness requirements

8. The Reporter Protocol (3/3) • Detecting global termination • Technique 1: use network localization data • compute terminated regions based on known reporter locations • conservative yet safe approach • Technique 2: learn reporter set • nodes notify manager when they elect themselves reporter • manager matches received reports to reporter set • requires twice as many messages • Composability • minimal knowledge of application protocols required • message type: used to overhear relevant application messages • maximum communication delay: used to compute T • Efficiency • maximally exploit application traffic to reduce messaging overhead

9. Case Study For Evaluation:Network Reprogramming • Reprogramming is a core WSN service • termination detection is critical before switching to new program • 2 popular reprogramming protocols • Deluge: unstructured, flooding based • nodes periodically advertise own program version number • nodes request & receive newer versions from neighbors • randomized transmission to avoid duplicate sends • some nodes acquire new program by simply overhearing • Sprinkler: structured, TDMA based • exploits topology to construct backbone structure • backbone is within O(1) of MCDS • backbone nodes locally compute TDMA schedule for dissemination • although quite different in operation, both protocols satisfy the reactive WSN model

10. Evaluation (1/3) • Overhead • per sent/received message: 2 extra checks • per protocol invocation: 2 extra assignments • per message: 1 extra bit • ~50 bytes of mote RAM • Performance evaluation • Kansei testbed experiments using XSM motes • 105 nodes in a 15 x 7 grid topology • different network densities simulated by changing transmission power levels • nodes logged all important protocol execution data locally • exfiltrated offline using reliable, ethernet backchannel • compare logged data to Reporter output to measure reliability

11. Evaluation (2/3) • Efficiency of Reporter selection • Results • Even at lowest density, only 4-7% nodes become reporters • comparable to MDS of these networks • Despite completely different dissemination patterns for Deluge and Sprinkler, Reporter achieves comparable performance

12. Evaluation (3/3) • Spatial distribution of reporters • Results • selected reporters are uniformly distributed • better load balancing • PIF queries create traffic burst over whole network • existing protocols achieve 50-90% reliability • for reduced (~5%), uniformly distributed load of Reporter, we achieved 98% end-to-end reliability with per-hop acks.

13. Conclusions • Reporter • provides reliable, efficient termination detection by exploiting reactive WSN model • only requires about 5% of nodes to respond compared to PIF-based approaches • is fully autonomous • creates its own collection structure and detects termination locally • can be composed with a large class of application protocols • does not assume knowledge of application protocol specifics • reprogramming study used same Reporter code for both protocols • only difference was instantiation of message type & communication delay parameters

14. Thank you! Questions/Comments Email: sandip.bapat@samraksh.com