Network Reprogramming &Programming Abstractions

2

Network reprogramming

• XNP: wireless reprogramming tool

• Mate: Virtual machine for WSN

3

Over NW Programming Wireless Sensors

• In-System Programming

A sensor node is plugged to the serial / parallel port

But, it can program only one sensor node at a time

• Network Programming

Delivers the program code to multiple nodes over the air with a single transmission

Saves the efforts of programming each individual node

Host Machine

ProgramCode

Sensor Node

ParallelCable

Host Machine

ProgramCode

Sensor Node

RadioChannel

Sensor Node Sensor Node…

In-system programming Network programming

4

Network Programming for TinyOS (XNP)

• Has been available since release 1.1

• Originally made by Crossbow and modified by UCB

• Provides basic network programming capability

• Has some limitations

No support of multi-hop delivery

No support of incremental update

5

Background – Mechanisms of XNP

(1) Host: sends program code as download msgs

(2) Sensor node: stores the msgs in the external flash

(3) Sensor node: calls the boot loader. The boot loader copies the program code to the program memory.

User appSREC file

ExternalFlash

NetworkProgrammingHost Program

Bootloader User

ApplicationSection

Program

Memory

Boot loaderSection

Network

ProgrammingModule

RadioPackets

Host Machine Sensor Node

(2)

(3)(1)

6

Network reprogramming

• XNP: wireless reprogramming tool

• Mate: Virtual machine for WSN

7

Mate: A Virtual Machine for WSNs

Why VM?

• Large number (100’s to 1000’s) of nodes in a coverage area

• Some nodes will fail during operation

• Change of function during the mission

Related Work

PicoJava : assumes Java bytecode execution hardware

K Virtual Machine : requires 160 – 512 KB of memory

XML : too complex and not enough RAM

Scylla : VM for mobile embedded system

8

Mate features

• Small (16KB instruction memory, 1KB RAM)

• Concise (limited memory & bandwidth)

• Resilience(memory protection)

• Efficient (bandwidth)

• Tailorable (user defined instructions)

9

Mate in a nutshell (capsule?)

• Stack architecture

• Three concurrent execution contexts (clock, send, receive)

• Execution triggered by predefined events

• Tiny code capsules; self-propagate into network

• Built in communication and sensing instructions

10

When is Mate Preferable?

• For small number of executions

Bytecode version is preferable for a program running < 5 days

The energy saved in communicating new program via Mate compensates for the energy wasted due to running virtual machine bytecode interpreter

• In energy constrained domains

• Use Mate capsule as a general RPC engine, memory protection, virtualization

11

Mate Architecture

0 1 2 3

Subroutines

Clo

ck

Sen

d

Receiv

e

Events

gets/sets

0 1 2 3

Subroutines

Clo

ck

Sen

d

Receiv

e

Events

gets/sets

Co

de

OperandStack

ReturnStack

PC

Co

de

OperandStack

ReturnStack

PC

Stack based architecture

Single shared variable

• gets/sets

Three events:

• Clock timer

• Message reception

• Message send

Hides asynchrony

• Simplifies programming

• Less prone to bugs

12

Instruction Set

One byte per instruction

Three classes: basic, s-type, x-type

• basic: arithmetic, halting, LED operation

• s-type: messaging system

• x-type: pushc, blez

8 instructions reserved for users to define

Instruction polymorphism

• e.g. add(data, message, sensing)

13

Code Example

• Display Counter to LED

gets # Push heap variable on stackpushc 1 # Push 1 on stackadd # Pop twice, add, push resultcopy # Copy top of stacksets # Pop, set heappushc 7 # Push 0x0007 onto stackand # Take bottom 3 bits of valueputled # Pop, set LEDs to bit patternhalt #

14

Code Capsules

• One capsule = 24 instructions

• Fits into single TOS packet

• Atomic reception

• Code Capsule

Type and version information

Type: send, receive, timer, subroutine

15

Viral Code

• Capsule transmission: forw

Forwarding other installed capsule: forwo (use within clock capsule)

• Mate checks on version number on reception of a capsule

-> if it is newer, install it

• Versioning: 32bit counter

• Disseminates new code over the network

16

Component Breakdown

• Mate runs on mica with 7286 bytes code, 603 bytes RAM

17

Network Infection Rate

• 42 node network in 3 by

14 grid

• Radio transmission: 3 hop

network

• Cell size: 15 to 30 motes

• Every mote runs its clock

capsule every 20 seconds

• Self-forwarding clock

capsule

18

Bytecodes vs. Native Code

• Mate IPS: ~10,000

• Overhead: Every instruction executed as separate TOS task

19

Customizing Mate

• Mate is general architecture; user can build customized VM

Bombilla in TinyOS for querying Agilla (over Bombilla) for mobile agents in WSNs

• User can select bytecodes and execution events

• Issues:

Flexibility vs. Efficiency

Customizing increases efficiency w/ cost of changing requirements

Java’s solution:

General computational VM + class libraries

Mate’s approach:

More customizable solution -> let user decide

20

Programming abstractions

Macro-programming approaches

• Hood abstraction

• Region streams

• Kairos

21

Macroprogramming

• Program sensornet as a whole

Easier than programming at the level of individual nodes

e.g) Matrix multiplicationMatrix notation vs. Parallel program in MPI

Compile into node-level programs

• Non CS researchers shall be able to program without worrying about distributed execution details

Abstract away the details of concurrency and communication

22

Taxonomy of Macroprogramming

Macro-programming

Abstractions Support

Globalbehavior

LocalBehavior

Composition Distribution& Safe

Execution

AutomaticOptimization

Node-independent• TAG, Cougar• DFuseNode-dependent• Kairos• Regiment• Split-C

Data-Centric• EIP, State-spaceGeometric• Regions, Hood

SensorwareSNACK Mate

TofuTrickleDeluge

Impala

23

Hood (UC Berkeley)

• Neighborhood

A neighborhood in Hood is defined by a set of criteria for choosing neighbors and a set of variables to be shared.

A node can define multiple neighborhoods with different variables shared over each of them.

• Captures the essence of the neighborhood concepts needed by many existing applications

• Defines the relationship between several concepts fundamental to neighborhoods

membership, data sharing, data caching, and messaging. decouples data sharing and caching Integrate neighbor lists and caching with messaging Mirror & filter

• Explicitly proposes the neighborhood-oriented programming

24

Region streams (Harvard)

• Purely functional macroprogramming language for sensornet

• Basic data abstraction: region streams

A time-varying collection of node state e.g., “All sensor nodes within area R” form a region The set of their periodic data samples form a region stream

• Example: tracking moving vehicle

• A region stream is created that represents the value of the proximity sensor on every node in the network• Each value is also annotated with the location of the corresponding sensor. • Data items that fall below the threshold are filtered out.• The spatial centroid of the remaining collection of sensor values is computed to determine the approximate location of the object that generated the readings

25

Region streams (Harvard)

• Regiment: Functional Macroprogramming Language

Based on functional reactive programming concepts Functional languages: “pure”, no input no output cannot manipulate program state allows the compiler to decide how and where the program state is kept in

the volatile mesh of sensor nodes

26

Market Based Macroprogramming (Harvard)

• Basic model:

Nodes act as agents that sell goods (such as sensor readings or routed msgs) Each good is produced by an associated action that produces it Nodes attempt to maximize their profit, subject to energy constraints

• Each good has an associated price

Network is “programmed” by setting prices for each good

• Each action has an associated energy cost

e.g., Cost to sample a sensor << Cost to transmit a radio message

material from Matt Welsh

27

How to program in MBM? • First step: Set the price(s)

use one of many efficient dissemination protocols update prices as need by the overall application goal

• Nodes select actions based on a utility function

• Utility depends on:

Price

Advertised by base station Energy availability

Taking an action must stay within energy budget Other dependencies

Cannot aggregate data until multiple samples have been received

Cannot transmit if nothing in local buffer

material from Matt Welsh

28

Kairos (USC)

• In Kairos, a programmer writes a single sequential program using a simple centralized memory model

Threadof

control

Sequential Program Read/write

Centralized Sensor State mapped from Sensors

29

Advantage

• Centralized sequential programs easier to specify, code, understand and debug than hand-coded distributed versions

Reuse “textbook” algorithms for sophisticated tasks Ignoring latency and energy considerations, a dumb but obviously trivial

“distributed” implementation always possible, by shipping sensor nodes’ state to and from a central location

30

Kairos Features

• Three constructs with which to write programs

node (a first-class datatype) and node_list (iterator on nodes) that facilitate topology independent programming

get_neighbors() to obtain current one-hop neighbors of a node var@node to synchronously access data and program state of node’s

• These constructs are language-agnostic

• They can be implemented in the preprocessor stage of compilation

31

Eventual Consistency

• Synchronization model called Loose Synchrony

• Useful when there is relatively static node state

• Did not work well for a dynamic vehicle tracking scenario

• Implemented a tighter semantic called Loop-level Synchrony

• Long term, we are exploring temporal abstractions as a fourth construct that can capture this requirement completely