UMass Computer Science Department
Navin SharmaJeremy Gummeson
David IrwinPrashant Shenoy
SRCP: Simple Remote Control Protocol for
Perpetual High-Power Sensor Networks
2UMass Computer Science Department
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
3UMass Computer Science Department
Perpetual Sensor Networks, Perpetual Challenges
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
Node Power Consumption
40-Watt 2-Watt
550 USD
50 USD
4UMass Computer Science Department
Problem Statement
Problem: Design a system for flexible management that balances energy consumption, system availability, and form factor
5UMass Computer Science Department
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
6UMass Computer Science Department
Talk Outline
1. Motivation for Remote Management2. Basic Approach3. SRCP Design4. Software/Hardware Implementation5. Evaluation6. Related Work7. Conclusions
7UMass Computer Science Department
Remote Management Considerations
Management Requirements: Visibility
• State Knowledge Accessibility
• Alterable State Interactivity
• Visible + Accessible -> Low Latency
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
Control Primitives:
8UMass Computer Science Department
Using Primitives for Remote Control
Example: Periodic Image Capture
Main CPU
Controller
Basestation
Camera
Manager
Main CPU
Controller
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
1 12 23
345
12
9UMass Computer Science Department
SRCP Components
Three entities: Management Plane Agent:
• Control CPU, TinyOS-2.x
Data Plane Agent: • Main CPU, Linux
Basestation Agent: • Main CPU, Linux
10UMass Computer Science Department
Management Plane Agent
Interpret Control Primitives Routing K-retransmissions link reliability Monitor energy production/battery capacity Manage high-power system components
ManagementPlane Agent
Tinynode
Data PlaneAgent
Gumstix
BasestationAgent
Data Plane
Management
Plane
11UMass Computer Science Department
Data Plane Agent
DTN for per-hop file transfer Transfer images from camera Issue SRCP commands Remote Debug Server
ManagementPlane Agent
Tinynode
Data PlaneAgent
Gumstix
BasestationAgent
Data Plane
Management
Plane
12UMass Computer Science Department
Basestation Agent
Management Plane Ingress/Egress point Interactive control of nodes Display response messages DTN endpoint
ManagementPlane Agent
Tinynode
Data PlaneAgent
Gumstix
BasestationAgent
Data Plane
Management
Plane
13UMass Computer Science Department
IP Tunneling
IP Proxy Implementation:• Avoid Wi-Fi: send low-bandwidth TCP/IP data via management
plane (GDB, Telnet)• IPComp header compression
14UMass Computer Science Department
Why not 6LoWPAN ?
Tinynode
XE1205:16-byte buffer, 28 byte
MTU
6LoWPAN headers intended for 802.15.4
Optimization necessary
Connection data Opaque to intermediate nodes
15UMass Computer Science Department
Hardware Prototype
Main CPU/Radio: PXA270, 802.11bControl CPU/Radio: MSP430, XE1205Power Board: Fuel Gauge ICsBattery: 6.1-Ah Li-IonSolar Panel: 9V OCV, 350mA SCC, ~2WCamera: CMUCam3
16UMass Computer Science Department
Hardware Specs
Bandwidth Range (m)Sleep Power
(mW)Active Power
(mW)
XE1205 38kbps 800 0.6 47.3
802.11b 11Mbps 95 63 (PSM) 953
Communication
ComputationClock (MHz)
Sleep Power (mW)
Active Power (mW)
MSP430 8 .015 3
PXA270 400 4 462
20x8x
150x
17UMass Computer Science Department
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
18UMass Computer Science Department
Visibility Evaluation
Visibility is prerequisite for management• Energy required to diagnose is metric:
Primitive CommandPower
(uJ) Max
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 based on prototype battery capacity of 81,360 Joules)
19UMass Computer Science Department
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
20UMass Computer Science Department
Visibility Evaluation
Extrapolation shows 50 hop network may be traversed in 2.5 seconds
Loss Rates for health updates
Observed latency with loss
21UMass Computer Science Department
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
22UMass Computer Science Department
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
CommandLatencyIPComp
(Seconds)
LatencyNo IPComp(Seconds)
Break 3 7
Step 3 7
Continue 4 10
Next 3 7
Backtrace 2 8
Print 3 9
CommandIPCompBytes
No IPCompBytes
Break 328 952
Step 150 391
Continue 812 1102
Next 145 399
Backtrace 210 612
Print 428 1385
23UMass Computer Science Department
Interactivity Evaluation
GDB command latency scales with hop count• Extrapolation shows 30-Hop network achieves sub-10 second
latency
24UMass Computer Science Department
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
25UMass Computer Science Department
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
26UMass Computer Science Department
Questions?
27UMass Computer Science Department
Wireless JTAG
Proof of Concept JTAG Connection:
28UMass Computer Science Department
Safe-boot
Recover from main node kernel corruption
GPIODas-uBoot
kernel akernel b
Control Processor Main
Node
Boot“Clean” kernel
Top Related