Wireless Reprogramming HW2 To be assigned tomorrow (Thursday) - - PDF document

Chenyang Lu CSE 467S 1

HW2

• To be assigned tomorrow (Thursday)
• Due on 3/16 (Wed), 2:30pm

Chenyang Lu CSE 467S 2

Wireless Reprogramming

• Maté: mobile code
• Agilla: mobile agent

Chenyang Lu CSE 467S 3

Motivation for Mobile Code

• Need to reprogram sensors after deployment
• Change parameters
• Change/add/remove modules, e.g., filters, fusion

algorithms

• Change whole program
• Manual installation on a large number of nodes

is impractical

Chenyang Lu CSE 467S 4

XNP and Deluge

• Transmit native binary code
• Re-flashes the instruction memory
• Large code size code dissemination
• is slow
• is unreliable
• has high communication and energy cost

Chenyang Lu CSE 467S 5

Maté

• Byte code are disseminated through

wireless network

• Virtual machine interprets mobile byte

code

• Like mobile Java code

Chenyang Lu CSE 467S 6

Requirements

• Instruction Set
• Expressive: supports most sensing applications
• Concise: utilizes the least amount of network

bandwidth

• Tailorable: can be modified for special operations
• Virtual Machine
• Small footprint: fits in rene2 (1KB data, 16KB code)
• Resilient: cannot crash the mote
• Efficient execution: energy conserving

Chenyang Lu CSE 467S 7

Instruction Set

• One-byte instruction (i=instruction, x=argument)
• Basic

00iiiiii arithmetic, sensing, halt, LED

• s-class

01iiixxx executed within send/receive contexts

• x-class

1ixxxxxx push, blez

• 8 user-definable (default to no-op)
• 3 variable types: values, sensors readings, messages

Chenyang Lu CSE 467S 8

Simulate an operand stack

pushc 3 # put the value (3) on the operand stack pushc 2 # put the value (2) on the operand stack add # add the two operand values together # and place the result (5) on the # operand stack halt # stop execution

Chenyang Lu CSE 467S 9

Sample Program

Clock Capsule: 00: pushc 0 01: sense # get light sensor reading 02: swap # keep counter on top 03: pushc 1 04: add # increment the counter 05: copy 06: inv 07: pushc 4 08: add 09: blez 11 # if cnt > 4, then ave 10: halt 11: pop # pop off counter 12: add 13: add 14: add # add up all four readings 15: pushc 2 16: shiftr # divide by 4 (rt shift 2) 17: pushm 18: clear # clear out message buffer 19: add # put reading in buffer 20: send # send packet out 21: pushc 0 # reset counter to zero 22: halt

Chenyang Lu CSE 467S 10

Capsules

• Code is divided into 24 byte capsules
• Each capsule fits in a single TinyOS packet
• Larger code can include up to 4 subroutine capsules
• Types of capsules
• Subroutine capsule
• Message send capsule: start in response to packet sent
• Message receive capsule: start in response to packet received
• Timer capsule: start in response to a timer interrupt

Chenyang Lu CSE 467S 11

Virtual Machine

• 3 contexts: receive, send, clock
• Instructions from 3 contexts can interleave
• Each context has
• Operand stack (data operations – depth of 16)
• Return stack (subroutine invocations – depth of 8)
• PC
• One-word persistent heap (global variable

accessible from all contexts)

Chenyang Lu CSE 467S 12

Multiple Contexts

TinyOS

heap

Receive Context Clock Context Send Context

Chenyang Lu CSE 467S 13

A Context

heap

Operand Stack Return Stack Byte Code PC

• Post a new task to execute each instruction
• Expensive for simple instructions
• No race condition possible

Chenyang Lu CSE 467S 14

Maté Evaluation

• Implementation of BLESS routing

protocol

• Performance measured
• Acquisition of data while radio was off
• IPS (instructions per second) measured

was using loop counts

Chenyang Lu CSE 467S 15

Execution Overhead

• Maté introduces quite a bit of overhead

(33 to 1 at worst case)

• 1/3 of overhead is due to each Maté

instruction running as a separate task

Operation Mate Clock Cycles Native Clock Cycles Cost Simple (and) 469 14 33.5 Downcall (rand) 435 45 9.7 Quick Split (sense) 1342 396 3.4 Long Split (sendr) 20,685 20,000 1.0

Chenyang Lu CSE 467S 16

Energy Tradeoff byte code vs. binary image

• Byte code is more energy efficient than

native code when frequent reprogramming is needed

• Byte codes requires less energy for dissemination
• Byte code is smaller than binary images
• gdi-comm: 19 B vs. 7130 B
• Byte code consumes more energy to execute
• Byte code has longer execution times
• For GDI, Maté was more efficient for new

installations every first five days

Chenyang Lu CSE 467S 17

Code Safety

• Avoid race condition
• All instructions executed in tasks
• Maté cannot corrupt TinyOS
• A “user/kernel” boundary
• Maté code cannot preempt event/command
• Memory protection: a context cannot

access the states of another context

Chenyang Lu CSE 467S 18

Requirements Revisited

• Instruction Set
• Expressive???
• Concise: utilizes the least amount of network

bandwidth

• Tailorable: can be modified for special operations
• Virtual Machine
• Small footprint: fits in rene2 (1KB data, 16KB code)
• Resilient: cannot crash the mote
• Efficient: energy conserving (tradeoff)
• Code dissemination (“viral infection”): a forw

instruction causes capsule be re-broadcasted

Chenyang Lu CSE 467S 19

Limitations of (Just) Mobile Code

• Whole network runs one application
• Cannot adapt to changes in
• Goals
• Environment
• Network
• Lack coordination among nodes

Chenyang Lu CSE 467S 20

Optional Readings

• P. Levis and D. Culler, “Maté: a Virtual Machine for

Tiny Networked Sensors.” ASPLOS, Dec 2002.

• C.-L. Fok, G.-C. Roman, and C. Lu, "Rapid Development

and Flexible Deployment of Adaptive Wireless Sensor Network Applications," ICDCS, June 2005.

• Agilla:

http://www.cs.wustl.edu/mobilab/projects/agilla/