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

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


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


Problem Statement

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


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


Talk Outline

1. Motivation for Remote Management2. Basic Approach3. SRCP Design4. Software/Hardware Implementation5. Evaluation6. Related Work7. Conclusions


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:


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


SRCP Components

Three entities: Management Plane Agent:

• Control CPU, TinyOS-2.x

Data Plane Agent: • Main CPU, Linux

Basestation Agent: • Main CPU, Linux


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


Data Plane Agent

DTN for per-hop file transfer Transfer images from camera Issue SRCP commands Remote Debug Server


Tinynode

Data PlaneAgent

Gumstix

BasestationAgent

Data Plane

Management

Plane


Basestation Agent

Management Plane Ingress/Egress point Interactive control of nodes Display response messages DTN endpoint


Tinynode

Data PlaneAgent

Gumstix

BasestationAgent

Data Plane

Management

Plane


IP Tunneling

IP Proxy Implementation:• Avoid Wi-Fi: send low-bandwidth TCP/IP data via management

plane (GDB, Telnet)• IPComp header compression


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


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


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


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


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)



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



Extrapolation shows 50 hop network may be traversed in 2.5 seconds

Loss Rates for health updates

Observed latency with loss


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



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



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

latency


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


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


Questions?


Wireless JTAG

Proof of Concept JTAG Connection:


Safe-boot

Recover from main node kernel corruption

GPIODas-uBoot

kernel akernel b

Control Processor Main

Node

Boot“Clean” kernel

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

Documents

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