SRCP: Simple Remote Control
Protocol for Perpetual HighPower Sensor Networks
Navin Sharma
Jeremy Gummeson
David Irwin
Prashant Shenoy
UMass Computer Science Department
Remote Management
 Perpetual WSNs need remote
management
Fort River
Amherst, Massachusetts
• Software updates
• Debugging
• Reconfiguration
 Focus on High-Power WSNs:
• High-Bandwidth Communication
• High-Power Sensors
UMass Computer Science Department
2
Perpetual Sensor Networks, Perpetual Challenges
 Achieve perpetual operation
via energy harvesting, but:
Node Power Consumption
• 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
UMass Computer Science Department
40-Watt
2-Watt
50 USD
550 USD
3
Problem Statement
Problem: Design a system for flexible management that balances
energy consumption, system availability, and form factor
UMass Computer Science Department
4
Our Approach
 Basic Idea:
• Low-Power CPU/Radio:
Management Plane
• High-Power CPU/Radio:
Data Plane
System Architecture
 Best of both worlds:
• Low-overhead, available
control
• High-bandwidth data
UMass Computer Science Department
5
Talk Outline
1.
2.
3.
4.
5.
6.
7.
Motivation for Remote Management
Basic Approach
SRCP Design
Software/Hardware Implementation
Evaluation
Related Work
Conclusions
UMass Computer Science Department
6
Remote Management Considerations
Management Requirements:

Visibility
•

Accessibility
•

State Knowledge
Alterable State
Interactivity
•
Visible + Accessible -> Low Latency
Control Primitives:
Primitive:
Description:
Example:
State
Read/Write Node State
Read Battery Capacity
Execution
perform action
Power On Main CPU
Conditional
Timed/environment trigger
Periodic Image Capture
Connection
basestation<->main node session
UMass Computer Science Department
7
Using Primitives for Remote Control
Example: Periodic Image Capture
Main CPU
Basestation
2
1
1
2
Controller
Main CPU
5
1
2
3
Controller
4
3
Camera
Manager
1.
Set Conditional: Capture Image every 5 minutes
2.
Set Conditional: Wakeup every hour & run script
3.
Execution: Wakeup Intermediate Node Main CPU
4.
Execution: Shutdown Camera Node Main CPU
5.
Execution: Shutdown Intermediate Node Main CPU
UMass Computer Science Department
8
SRCP Components
Three entities:
 Management Plane Agent:
• Control CPU, TinyOS-2.x
 Data Plane Agent:
• Main CPU, Linux
 Basestation Agent:
• Main CPU, Linux
UMass Computer Science Department
9
Management Plane Agent





Interpret Control Primitives
Routing
K-retransmissions link reliability
Monitor energy production/battery capacity
Manage high-power system components
Gumstix
Data Plane
Basestation
Agent
Data Plane
Agent
Management
Plane
Management
Plane Agent
Tinynode
UMass Computer Science Department
10
Data Plane Agent




DTN for per-hop file transfer
Transfer images from camera
Issue SRCP commands
Remote Debug Server
Gumstix
Data Plane
Basestation
Agent
Data Plane
Agent
Management
Plane
Management
Plane Agent
Tinynode
UMass Computer Science Department
11
Basestation Agent




Management Plane Ingress/Egress point
Interactive control of nodes
Display response messages
DTN endpoint
Gumstix
Data Plane
Basestation
Agent
Data Plane
Agent
Management
Plane
Management
Plane Agent
Tinynode
UMass Computer Science Department
12
IP Tunneling
 IP Proxy Implementation:
• Avoid Wi-Fi: send low-bandwidth TCP/IP data via
management plane (GDB, Telnet)
• IPComp header compression
UMass Computer Science Department
13
Why not 6LoWPAN ?
XE1205:
16-byte buffer, 28 byte MTU
Tinynode
6LoWPAN headers intended for 802.15.4
Optimization necessary
Connection data Opaque to intermediate nodes
UMass Computer Science Department
14
Hardware Prototype
Main CPU/Radio:
Control CPU/Radio:
Power Board:
Battery:
Solar Panel:
Camera:
UMass Computer Science Department
PXA270, 802.11b
MSP430, XE1205
Fuel Gauge ICs
6.1-Ah Li-Ion
9V OCV, 350mA SCC, ~2W
CMUCam3
15
Hardware Specs
Communication
Bandwidth
XE1205
38kbps
802.11b
11Mbps
Range (m)
Sleep Power
(mW)
Active Power
(mW)
800
0.6
47.3
95
63 (PSM)
8x
20x
953
Computation
Clock
(MHz)
Sleep Power
(mW)
Active Power (mW)
MSP430
8
.015
3
PXA270
400
4
UMass Computer Science Department
150x
462
16
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
UMass Computer Science Department
17
Visibility Evaluation
 Visibility is prerequisite for management
• Energy required to diagnose is metric:
Primitive
Command
Power
(uJ)
Execution
Wakeup Gumstix
.551
1.47e11
Set
Conditional
Wakeup Gumstix in 5 mins
.580
1.40e11
Read State
Sensing rate
13.92
5.84e9
Write State
Sensing rate
13.97
5.82e9
Connection
Transmit 28 byte packet
.560
1.45e11
Max
(Max based on prototype battery capacity of 81,360 Joules)
UMass Computer Science Department
18
Visibility Evaluation
 Management plane constrained by network
bandwidth
• Show reasonable send rate achievable without
sizeable delay
 Evaluate using 5-node chain topology
• Report battery capacity at fixed interval
• Observe loss rates and resulting latency
UMass Computer Science Department
19
Visibility Evaluation
 Extrapolation shows 50 hop network may be
traversed in 2.5 seconds
Loss Rates for health updates
UMass Computer Science Department
Observed latency with loss
20
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
UMass Computer Science Department
21
Interactivity Evaluation
GDB Command Latency
Latency
IPComp
(Seconds)
Latency
No IPComp
(Seconds)
Break
3
7
Step
3
7
Continue
4
10
Next
3
7
Backtrace
2
Print
3
Command
GDB Bytes Sent
Command
IPComp
Bytes
No IPComp
Bytes
Break
328
952
Step
150
391
Continue
812
1102
Next
145
399
8
Backtrace
210
612
9
Print
428
1385
 Worst case GDB command latency is <= 4 seconds via
management plane w/ header compression
 Header compression significantly reduces bytes sent
UMass Computer Science Department
22
Interactivity Evaluation
 GDB command latency scales with hop count
• Extrapolation shows 30-Hop network achieves sub-10 second
latency
UMass Computer Science Department
23
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
UMass Computer Science Department
24
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
UMass Computer Science Department
25
Questions?
UMass Computer Science Department
26
Wireless JTAG
Proof of Concept JTAG Connection:
UMass Computer Science Department
27
Safe-boot
 Recover from main node kernel corruption
Control
Processor
Main Node
Boot
“Clean” kernel
kernel a kernel b
GPIO
UMass Computer Science Department
Das-uBoot
28