SRCP: Simple Remote Control Protocol for Perpetual High-Power Sensor Networks

1. SRCP: Simple Remote Control Protocol for Perpetual High-Power Sensor Networks Navin Sharma Jeremy Gummeson David Irwin Prashant Shenoy

2. Remote Management Perpetual WSNs need remote management Software updates Debugging Reconfiguration Focus on High-Power WSNs: High-Bandwidth Communication High-Power Sensors Fort RiverAmherst, Massachusetts

3. Perpetual Sensor Networks, Perpetual Challenges Node Power Consumption • Achieve perpetual operation via energy harvesting, but: • Power-Hungry components exceed harvested power, drain energy buffer • Aggressively duty cycle, lose availability • May over-provision, but: • Nodes become physically large • Expensive Solar Panels • Wasteful when system demand low • Meraki-Solar: 40W-panel for New England 2-Watt 40-Watt 50 USD 550 USD

4. Problem Statement Problem: Design a system for flexible management that balances energy consumption, system availability, and form factor

5. Our Approach • Basic Idea: • Low-Power CPU/Radio: Management Plane • High-Power CPU/Radio:Data Plane • Best of both worlds: • Low-overhead, available control • High-bandwidth data System Architecture

6. Talk Outline • Motivation for Remote Management • Basic Approach • SRCP Design • Software/Hardware Implementation • Evaluation • Related Work • Conclusions

7. Remote Management Considerations Management Requirements: • Visibility • State Knowledge • Accessibility • Alterable State • Interactivity • Visible + Accessible -> Low Latency Control Primitives:

8. Main CPU Main CPU Controller Controller Using Primitives for Remote Control Example: Periodic Image Capture Basestation 4 3 5 1 2 3 1 2 2 1 Camera Manager • Set Conditional: Capture Image every 5 minutes • Set Conditional: Wakeup every hour & run script • Execution: Wakeup Intermediate Node Main CPU • Execution: Shutdown Camera Node Main CPU • Execution: Shutdown Intermediate Node Main CPU

9. SRCP Components Three entities: • Management Plane Agent: • Control CPU, TinyOS-2.x • Data Plane Agent: • Main CPU, Linux • Basestation Agent: • Main CPU, Linux

10. Management Plane Agent • Interpret Control Primitives • Routing • K-retransmissions link reliability • Monitor energy production/battery capacity • Manage high-power system components Gumstix Data PlaneAgent Data Plane Basestation Agent ManagementPlane ManagementPlane Agent Tinynode

11. Data Plane Agent • DTN for per-hop file transfer • Transfer images from camera • Issue SRCP commands • Remote Debug Server Gumstix Data PlaneAgent Data Plane Basestation Agent ManagementPlane ManagementPlane Agent Tinynode

12. Basestation Agent • Management Plane Ingress/Egress point • Interactive control of nodes • Display response messages • DTN endpoint Gumstix Data PlaneAgent Data Plane Basestation Agent ManagementPlane ManagementPlane Agent Tinynode

13. IP Tunneling • IP Proxy Implementation: • Avoid Wi-Fi: send low-bandwidth TCP/IP data via management plane (GDB, Telnet) • IPComp header compression

14. Tinynode Why not 6LoWPAN ? XE1205:16-byte buffer, 28 byte MTU • 6LoWPAN headers intended for 802.15.4 • Optimization necessary • Connection data Opaque to intermediate nodes

15. Hardware Prototype Main CPU/Radio: PXA270, 802.11bControl CPU/Radio: MSP430, XE1205 Power Board: Fuel Gauge ICs Battery: 6.1-Ah Li-Ion Solar Panel: 9V OCV, 350mA SCC, ~2W Camera: CMUCam3

16. Hardware Specs Communication 8x 20x Computation 150x

17. SRCP Evaluation • Evaluation via case studies that quantify performance along two axes: • Visibility: knowledge of state, availability of state • Interactivity: management achievable with tolerable latency

18. Visibility is prerequisite for management Energy required to diagnose is metric: Visibility Evaluation (Max based on prototype battery capacity of 81,360 Joules)

19. Visibility Evaluation • Management plane constrained by networkbandwidth • Show reasonable send rate achievable withoutsizeable delay • Evaluate using 5-node chain topology • Report battery capacity at fixed interval • Observe loss rates and resulting latency

20. Visibility Evaluation • Extrapolation shows 50 hop network may be traversed in 2.5 seconds Observed latency with loss Loss Rates for health updates

21. Interactivity Evaluation • Metric used to evaluate interactivity is latency • Network operators need to diagnose and repair problems in data plane • Evaluation looks at representative GDB session • GDB session runs over management plane using IP Tunnel

22. Interactivity Evaluation GDB Command Latency GDB Bytes Sent • Worst case GDB command latency is <= 4 seconds via management plane w/ header compression • Header compression significantly reduces bytes sent

23. Interactivity Evaluation • GDB command latency scales with hop count • Extrapolation shows 30-Hop network achieves sub-10 second latency

24. Related Work • In-band Management: • Sympathy, PCP, Node MD – Fault Detection, Diagnosis • Clairvoyant, Marionette – Interactive Debugging • Trickle, Deluge – Software Updates • Out-of-band Management: • MoteLab, Trio – Testbed Scheduling • Deployment Support Network (DSN) – Bluetooth back channel; provides functionality useful for testbeds • Leap – Fine-grained task allocation, minimize energy consumption • Our Goal: • Provide flexible management protocol for perpetual deployments

25. Final Thoughts • Presented SRCP: A lightweight, flexible protocol for perpetual sensor platforms • SRCP allows remote access and control of many system components • Future work: long term deployment at riverbed http://lass.cs.umass.edu

26. Questions?

27. Wireless JTAG Proof of Concept JTAG Connection:

28. Safe-boot • Recover from main node kernel corruption Control Processor Main Node Boot“Clean” kernel kernel a kernel b Das-uBoot GPIO