Berkley Motes and TinyOS CS851 Presentation

1
Berkley Motes and TinyOSCS851 Presentation

• Chenyang Lu
• chenyang_at_cs.virginia.edu
• September 5, 2001

2
Organization

• Hardware constraints
• Mote
• Software requirements
• TinyOS
• Analysis and evaluation
• Applications
• Critique

3
Hardware Constraints

• Power, size, and cost constrained
• These are translated to
• Slow clock cycles of microcontroller
• Small memory
• Small number of hardware controllers

4
MOTE

• Two Board Sandwich
• CPU/Radio board
• Sensor Board temperature, light
• Size
• Mote 1?1 in
• Pocket PC 5.2?3.1 in
• CPU
• Mote 4 MHz, 8 bit
• Pocket PC 133 MHz, 32 bit
• Memory
• Mote 512 B RAM 8K ROM
• Pocket PC 32 MB RAM 16 MB ROM
• Radio
• 900 Hz, 19.2 kbps
• Bluetooth 433.8 kbps (symmetric)

• Lifetime (Power)
• Mote 3-65 days
• Pocket PC 8 hrs
• Cost
• Mote 100
• Pocket PC 400

5
Software challenges

• Power efficient
• Efficient modularity
• Small memory footprint
• Application specific
• Concurrency-intensive operations
• Multiple, high-rate data flows (radio, sensor,
  actuator)
• TinyOS must process bit every 100 µs
• Real-time
• Real-time query and feedback control of physical
  world
• Little memory for buffering data must be
  processed on the fly
• TinyOS No buffering in radio hw missed deadline
  ? lost data
• Yet TinyOS provides NO real-time guarantees!

6
How about a regular OS?

• General purpose, open platform
• MANY functionalities programming APIs
• Protection between untrusted applications and
  kernel
• Overhead for crossing kernel/user boundary
  interrupt handling
• Multi-threaded architecture
• Large number of threads ? large memory
• context switch overhead
• I/O model
• Blocking I/O waste memory on blocked threads
• Polling (non-blocking I/O) waste CPU cycles and
  power
• Need a new paradigm of OS architecture!

7
TinyOS Overview

• Application scheduler graph of components
• Compiled into one executable
• Event-driven architecture
• Single shared stack
• No kernel/user space differentiation

Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Communication
Hardware Abstractions
8
TinyOS component model

• Component has
• Frame (storage)
• Tasks computation
• Interface
• Command
• Event
• Frame static storage model - compile time memory
  allocation (efficiency)
• Command and events are function calls (efficiency)

9
TOS Component

• //AM.comp//
• TOS_MODULE AM
• ACCEPTS
• char AM_SEND_MSG(char addr, char type, char
  data)
• void AM_POWER(char mode)
• char AM_INIT()
• SIGNALS
• char AM_MSG_REC(char type, char
  data)
• char AM_MSG_SEND_DONE(char success)
• HANDLES
• char AM_TX_PACKET_DONE(char success)
• char AM_RX_PACKET_DONE(char packet)
• USES
• char AM_SUB_TX_PACKET(char data)
• void AM_SUB_POWER(char mode)
• char AM_SUB_INIT()

AM_SEND_MSG
AM_INIT
AM_POWER
AM_MSG_SEND_DONE
AM_MSG_REC
Messaging Component
Internal State
Internal Tasks
AM_SUB_POWER
AM_TX_PACKET_DONE
AM_SUB_TX_PACKET
AM_RX_PACKET_DONE
AM_SUB_INIT
Commands
Events
10
TinyOS Two-level Scheduling

• Tasks do computations
• Unpreemptable FIFO scheduling
• Bounded number of pending tasks
• Events handle concurrent dataflows
• Interrupts trigger lowest level events
• Events prempt tasks, tasks do not
• Events can signal events, call commands, or post
  tasks

11
How to handle multiple data flows?

• Data are handled by
• A sequence of non-blocking event/command
  (function calls) through the component graph
• Post tasks for computations that are not
  emergent
• Preempting tasks to handle new data

12
A Complete Application
sensing application
application
Routing Layer
routing
Messaging Layer
messaging
Radio Packet
packet
Radio byte (MAC)
Temp
byte
photo
SW
HW
RFM
i2c
ADC
bit
clocks
13
Receiving a message

• Timing diagram of event propagation
• How to make sure all the events/tasks are
  processed in time?

14
How should network msg be handled?

• Socket/TCP/IP?
• Too much memory for buffering and threads
• Data are buffered in network stack until
  application threads read it
• Application threads blocked until data is
  available
• Transmit too many bits (sequence , ack,
  re-transmission)
• Tied with multi-threaded architecture
• TinyOS solution active messages

15
Active Message

• Every message contains the name of an event
  handler
• Sender
• Declaring buffer storage in a frame
• Naming a handler
• Requesting Transmission
• Done completion signal
• Receiver
• The event handler is fired automatically in a
  target node
• No blocked or waiting threads on the receiver
• Behaves like any other events
• Single buffering

16
Send Message
char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int
val) int_to_led_msg message
(int_to_led_msg)VAR(msg).data if
(!VAR(pending)) message-gtval val if
(TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAS
T, AM_MSG(INT_READING), VAR(msg)))
VAR(pending) 1 return 1 return
0
msg buffer
17
Analysis and Evaluation

• Lets take apart Space, Power and Time

18
Space Breakdown
Code size for ad hoc networking application
Scheduler 144 Bytes code Totals 3430 Bytes
code 226 Bytes data
19
Power Breakdown

• Lithium Battery runs for 35 hours at peak load
  and years at minimum load!
• Thats three orders of magnitude difference!
• A one byte transmission uses the same energy as
  approx 11000 cycles of computation.

20
Time Breakdown

• 50 cycle thread overhead (6 byte copies)
• 10 cycle event overhead (1.25 byte copes)

21
Power optimization

• Energy is your most valuable resource
• All components must support low power modes
  (sleep)
• Get job done quickly and go to sleep!

22
Sample tradeoffs
23
Applications

• Multi-hop routing
• Temperature/light monitoring
• Active badge
• Vehicle sensing
• Air-to-ground communication

24
Routing

• Each node needs to determine its parent and its
  depth in the tree
• Each node broadcasts out ltidentity, depth, datagt
  when parent is known
• At start, Base Station knows it is at depth 0
• It send out ltBase ID, 0, gt
• Individuals listen for minimum depth parent

0
Base
25
Active badge

• 16 motes deployed on 4th floor Soda Hall
• 10 round motes as office landmarks
• 2 base stations around corners of the building
• 4 Rene motes as active badges for location
  tracking
• AA batteries (3 weeks)
• Tracking precision /- one office

http//nighthawk.cs.berkeley.edu8080/tracking
26
Vehicle sensoring

• Unmanned airplane dropped motes from an unmanned
  airplane
• Motes automatically forms a network
• Motes detect passing vehicles through magnetic
  sensors
• Unmanned airplane sends a query to motes to get
  the passing time of the vehicle

27
Grading TinyOS

• Small memory footprint ?
• Non-preemptable FIFO task scheduling
• Power efficient ?
• Put microcontroller and radio to sleep
• Efficient modularity ?
• Function call (event, command) interface between
  components
• Concurrency-intensive operations ?
• Event-driven architecture
• Efficient interrupts/events handling (function
  calls, no user/kernel boundary)
• Real-time ?
• Non-preemptable FIFO task scheduling
• NO real-time guarantees or overload protection

28
What should be added to TinyOS?

• Preemptable, priority-based scheduling (RM)?
• Time-triggered scheduling (EDF)?
• ID-less routing?
• Zero-copy TCP/IP stack?
• Multi-cast and group management?

29
Readings for next class

• TinyOS boot camp talks boot1.ppt, boot2.ppt,
  boot3.ppt, boot4.ppt, boot5.ppt
• Sample source code of TinyOS