Ad hoc and Sensor Networks Chapter 2: Single node architecture

1
Ad hoc and Sensor NetworksChapter 2 Single node
architecture

• Holger Karl

2
Goals of this chapter

• Survey the main components of the composition of
  a node for a wireless sensor network
• Controller, radio modem, sensors, batteries
• Understand energy consumption aspects for these
  components
• Putting into perspective different operational
  modes and what different energy/power consumption
  means for protocol design
• Operating system support for sensor nodes
• Some example nodes
• Note The details of this chapter are quite
  specific to WSN energy consumption principles
  carry over to MANET as well

3
Outline

• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study TinyOS

4
Sensor node architecture

• Main components of a WSN node
• Controller
• Communication device(s)
• Sensors/actuators
• Memory
• Power supply

Memory
Sensor(s)/actuator(s)
Communicationdevice
Controller
Power supply
5
Ad hoc node architecture

• Core essentially the same
• But Much more additional equipment
• Hard disk, display, keyboard, voice interface,
  camera,
• Essentially a laptop-class device

6
Controller

• Main options
• Microcontroller general purpose processor,
  optimized for embedded applications, low power
  consumption
• DSPs optimized for signal processing tasks, not
  suitable here
• FPGAs may be good for testing
• ASICs only when peak performance is needed, no
  flexibility
• Example microcontrollers
• Texas Instruments MSP430
• 16-bit RISC core, up to 4 MHz, versions with 2-10
  kbytes RAM, several DACs, RT clock, prices start
  at 0.49 US
• Atmel ATMega
• 8-bit controller, larger memory than MSP430,
  slower

7
Custom single-purpose processor basic model
8
Example greatest common divisor

• First create algorithm
• Convert algorithm to complex state machine
• Known as FSMD finite-state machine with datapath
• Can use templates to perform such conversion

(c) state diagram
(b) desired functionality
0 int x, y 1 while (1) 2 while
(!go_i) 3 x x_i 4 y y_i 5 while
(x ! y) 6 if (x lt y) 7
y y - x else 8
x x - y 9 d_o x
9
State diagram templates
10
Creating the datapath

• Create a register for any declared variable
• Create a functional unit for each arithmetic
  operation
• Connect the ports, registers and functional units
• Based on reads and writes
• Use multiplexors for multiple sources
• Create unique identifier
• for each datapath component control input and
  output

11
Creating the controllers FSM

• Same structure as FSMD
• Replace complex actions/conditions with datapath
  configurations

12
Splitting into a controller and datapath
go_i
Controller
!1
1
0000
1
!(!go_i)
2
0001
!go_i
2-J
0010
x_sel 0 x_ld 1
3
0011
y_sel 0 y_ld 1
4
0100
x_neq_y0
5
0101
x_neq_y1
6
0110
x_lt_y1
x_lt_y0
y_sel 1 y_ld 1
x_sel 1 x_ld 1
7
8
0111
1000
6-J
1001
5-J
1010
d_ld 1
9
1011
1-J
1100
13
Controller state table for the GCD example
14
Completing the GCD custom single-purpose
processor design

• We finished the datapath
• We have a state table for the next state and
  control logic
• All thats left is combinational logic design
• This is not an optimized design, but we see the
  basic steps

15
Communication device

• Which transmission medium?
• Electromagnetic at radio frequencies?
• Electromagnetic, light?
• Ultrasound?
• Radio transceivers transmit a bit- or byte stream
  as radio wave
• Receive it, convert it back into bit-/byte stream

ü
16
Transceiver characteristics

• Capabilities
• Interface bit, byte, packet level?
• Supported frequency range?
• Typically, somewhere in 433 MHz 2.4 GHz, ISM
  band
• Multiple channels?
• Data rates?
• Range?
• Energy characteristics
• Power consumption to send/receive data?
• Time and energy consumption to change between
  different states?
• Transmission power control?
• Power efficiency (which percentage of consumed
  power is radiated?)

• Radio performance
• Modulation? (ASK, FSK, ?)
• Noise figure? NF SNRI/SNRO
• Gain? (signal amplification)
• Receiver sensitivity? (minimum S to achieve a
  given Eb/N0)
• Blocking performance (achieved BER in presence of
  frequency-offset interferer)
• Out of band emissions
• Carrier sensing RSSI characteristics
• Frequency stability (e.g., towards temperature
  changes)
• Voltage range

17
Transceiver states

• Transceivers can be put into different
  operational states, typically
• Transmit
• Receive
• Idle ready to receive, but not doing so
• Some functions in hardware can be switched off,
  reducing energy consumption a little
• Sleep significant parts of the transceiver are
  switched off
• Not able to immediately receive something
• Recovery time and startup energy to leave sleep
  state can be significant
• Research issue Wakeup receivers can be woken
  via radio when in sleep state (seeming
  contradiction!)

18
Example radio transceivers

• Almost boundless variety available
• Some examples
• RFM TR1000 family
• 916 or 868 MHz
• 400 kHz bandwidth
• Up to 115,2 kbps
• On/off keying or ASK
• Dynamically tuneable output power
• Maximum power about 1.4 mW
• Low power consumption
• Chipcon CC1000
• Range 300 to 1000 MHz, programmable in 250 Hz
  steps
• FSK modulation
• Provides RSSI

• Chipcon CC 2400
• Implements 802.15.4
• 2.4 GHz, DSSS modem
• 250 kbps
• Higher power consumption than above transceivers
• Infineon TDA 525x family
• E.g., 5250 868 MHz
• ASK or FSK modulation
• RSSI, highly efficient power amplifier
• Intelligent power down, self-polling mechanism
• Excellent blocking performance

19
Example radio transceivers for ad hoc networks

• Ad hoc networks Usually, higher data rates are
  required
• Typical IEEE 802.11 b/g/a is considered
• Up to 54 MBit/s
• Relatively long distance (100s of meters
  possible, typical 10s of meters at higher data
  rates)
• Works reasonably well (but certainly not perfect)
  in mobile environments
• Problem expensive equipment, quite power hungry

20
Wakeup receivers

• Major energy problem RECEIVING
• Idling and being ready to receive consumes
  considerable amounts of power
• When to switch on a receiver is not clear
• Contention-based MAC protocols Receiver is
  always on
• TDMA-based MAC protocols Synchronization
  overhead, inflexible
• Desirable Receiver that can (only) check for
  incoming messages
• When signal detected, wake up main receiver for
  actual reception
• Ideally Wakeup receiver can already process
  simple addresses
• Not clear whether they can be actually built,
  however

21
Optical communication

• Optical communication can consume less energy
• Example passive readout via corner cube
  reflector
• Laser is reflected back directly to source if
  mirrors are at right angles
• Mirrors can be titled to stop reflecting
• ! Allows data to be sent back to laser source

22
Ultra-wideband communication

• Standard radio transceivers Modulate a signal
  onto a carrier wave
• Requires relatively small amount of bandwidth
• Alternative approach Use a large bandwidth, do
  not modulate, simply emit a burst of power
• Forms almost rectangular pulses
• Pulses are very short
• Information is encoded in the presence/absence of
  pulses
• Requires tight time synchronization of receiver
• Relatively short range (typically)
• Advantages
• Pretty resilient to multi-path propagation
• Very good ranging capabilities
• Good wall penetration

23
Sensors as such

• Main categories
• Any energy radiated? Passive vs. active sensors
• Sense of direction? Omidirectional?
• Passive, omnidirectional
• Examples light, thermometer, microphones,
  hygrometer,
• Passive, narrow-beam
• Example Camera
• Active sensors
• Example Radar
• Important parameter Area of coverage
• Which region is adequately covered by a given
  sensor?

24
Outline

• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study TinyOS

25
Energy supply of mobile/sensor nodes

• Goal provide as much energy as possible at
  smallest cost/volume/weight/recharge
  time/longevity
• In WSN, recharging may or may not be an option
• Options
• Primary batteries not rechargeable
• Secondary batteries rechargeable, only makes
  sense in combination with some form of energy
  harvesting
• Requirements include
• Low self-discharge
• Long shelf live
• Capacity under load
• Efficient recharging at low current
• Good relaxation properties (seeming
  self-recharging)
• Voltage stability (to avoid DC-DC conversion)

26
Battery examples

• Energy per volume (Joule per cubic centimeter)

Primary batteries Primary batteries Primary batteries Primary batteries
Chemistry Zinc-air Lithium Alkaline
Energy (J/cm3) 3780 2880 1200
Secondary batteries Secondary batteries Secondary batteries Secondary batteries
Chemistry Lithium NiMHd NiCd
Energy (J/cm3) 1080 860 650
27
Energy scavenging

• How to recharge a battery?
• A laptop easy, plug into wall socket in the
  evening
• A sensor node? Try to scavenge energy from
  environment
• Ambient energy sources
• Light ! solar cells between 10 ?W/cm2 and 15
  mW/cm2
• Temperature gradients 80 ? W/cm2 _at_ 1 V from 5K
  difference
• Vibrations between 0.1 and 10000 ? W/cm3
• Pressure variation (piezo-electric) 330 ? W/cm2
  from the heel of a shoe
• Air/liquid flow (MEMS gas turbines)

28
Energy scavenging overview
29
Energy consumption

• A back of the envelope estimation
• Number of instructions
• Energy per instruction 1 nJ
• Small battery (smart dust) 1 J 1 Ws
• Corresponds 109 instructions!
• Lifetime
• Or Require a single day operational lifetime
  246060 86400 s
• 1 Ws / 86400s ¼ 11.5 ?W as max. sustained power
  consumption!
• Not feasible!

30
Multiple power consumption modes

• Way out Do not run sensor node at full operation
  all the time
• If nothing to do, switch to power safe mode
• Question When to throttle down? How to wake up
  again?
• Typical modes
• Controller Active, idle, sleep
• Radio mode Turn on/off transmitter/receiver,
  both
• Multiple modes possible, deeper sleep modes
• Strongly depends on hardware
• TI MSP 430, e.g. four different sleep modes
• Atmel ATMega six different modes

31
Some energy consumption figures

• Microcontroller
• TI MSP 430 (_at_ 1 MHz, 3V)
• Fully operation 1.2 mW
• Deepest sleep mode 0.3 ?W only woken up by
  external interrupts (not even timer is running
  any more)
• Atmel ATMega
• Operational mode 15 mW active, 6 mW idle
• Sleep mode 75 ?W

32
Switching between modes

• Simplest idea Greedily switch to lower mode
  whenever possible
• Problem Time and power consumption required to
  reach higher modes not negligible
• Introduces overhead
• Switching only pays off if Esaved gt Eoverhead
• Example Event-triggered wake up from sleep
  mode
• Scheduling problem with uncertainty (exercise)

33
Alternative Dynamic voltage scaling

• Switching modes complicated by uncertainty how
  long a sleep time is available
• Alternative Low supply voltage clock
• Dynamic voltage scaling (DVS)
• Rationale
• Power consumption P depends on
• Clock frequency
• Square of supply voltage
• P / f V2
• Lower clock allows lower supply voltage
• Easy to switch to higher clock
• But execution takes longer

34
Memory power consumption

• Crucial part FLASH memory
• Power for RAM almost negligible
• FLASH writing/erasing is expensive
• Example FLASH on Mica motes
• Reading ¼ 1.1 nAh per byte
• Writing ¼ 83.3 nAh per byte

35
Transmitter power/energy consumption for n bits

• Amplifier power Pamp ?amp ?amp Ptx
• Ptx radiated power
• ?amp, ?amp constants depending on model
• Highest efficiency (? Ptx / Pamp ) at maximum
  output power
• In addition transmitter electronics needs power
  PtxElec
• Time to transmit n bits n / (R Rcode)
• R nomial data rate, Rcode coding rate
• To leave sleep mode
• Time Tstart, average power Pstart
• ! Etx Tstart Pstart n / (R Rcode) (PtxElec
  ?amp ?amp Ptx)
• Simplification Modulation not considered

36
Receiver power/energy consumption for n bits

• Receiver also has startup costs
• Time Tstart, average power Pstart
• Time for n bits is the same n / (R Rcode)
• Receiver electronics needs PrxElec
• Plus energy to decode n bits EdecBits
• ! Erx Tstart Pstart n / (R Rcode) PrxElec
  EdecBits ( R )

37
Some transceiver numbers
38
Comparison GSM base station power consumption

• Overview
• Details
• (just to put things into perspective)

39
Controlling transceivers

• Similar to controller, low duty cycle is
  necessary
• Easy to do for transmitter similar problem to
  controller when is it worthwhile to switch off
• Difficult for receiver Not only time when to
  wake up not known, it also depends on remote
  partners
• ! Dependence between MAC protocols and power
  consumption is strong!
• Only limited applicability of techniques analogue
  to DVS
• Dynamic Modulation Scaling (DSM) Switch to
  modulation best suited to communication depends
  on channel gain
• Dynamic Coding Scaling vary coding rate
  according to channel gain
• Combinations

40
Computation vs. communication energy cost

• Tradeoff?
• Directly comparing computation/communication
  energy cost not possible
• But put them into perspective!
• Energy ratio of sending one bit vs. computing
  one instruction Anything between 220 and 2900
  in the literature
• To communicate (send receive) one kilobyte
  computing three million instructions!
• Hence try to compute instead of communicate
  whenever possible
• Key technique in WSN in-network processing!
• Exploit compression schemes, intelligent coding
  schemes,

41
WSN Platforms Hardware Software

• Murat Demirbas
• Lecture uses some slides from tutorials prepared
  by authors of these platforms

42
Why use a WSN?

• Ease of deployment
• Wireless communication means no need for a
  communication infrastructure setup
• Drop and play
• Low-cost of deployment
• Nodes are built using off-the-shelf cheap
  components
• Fine grain monitoring
• Feasible to deploy nodes densely for fine grain
  monitoring

43
Outline

• Hardware
• RFID, Spec
• Mica2, XSM, Telos
• Stargate
• Software
• TinyOS
• Simulation
• TOSSIM
• Prowler

44
Types of sensor platforms

• RFID equipped sensors
• Smart-dust tags
• typically act as data-collectors or trip-wires
• limited processing and communications
• Mote/Stargate-scale nodes
• more flexible processing and communications
• More powerful gateway nodes, potentially using
  wall power

45
Popular Nodes Overview
46
Grain-sized nodes

• Powered by inductive coupling to a transmission
  from a reader device to transmit a message back
• Available commercially at very low prices
• Computation power is severely limited
• Can only trasmit stored unique id and variable
• Hard to add any interesting sensing capability

47
Spec Mote (3/6/2003)

• size 2x2.5mm, AVR RISC core, 3KB memory, FSK
  radio (CC1000), encrypted communication hardware
  support, memory-mapped active messages

48
Matchbox-sized nodes

• Mica series, XSM node, Telos
• 8-bit microprocessor, 4MHz CPU
• ATMEGA 128, ATMEL 8535, or Motorola HCS08
• 4Kb RAM
• holds run-time state (values of the variables) of
  the program
• 128Kb programmable Flash memory
• holds the application program
• Downloaded via a programmer-board or wirelessly
• Additional Flash memory storage space up to
  512Kb.

49
Mica2 and Mica2Dot

• ATmega128 CPU
• Self-programming
• Chipcon CC1000
• FSK
• Manchester encoding
• Tunable frequency
• Low power consumption
• 2 AA battery 3V

1 inch
50
Basic Sensor Board

• Light (Photo)
• Temperature
• Prototyping space for new hardware designs

51
Mica Sensor Board

• Light (Photo)
• Temperature
• Acceleration
• 2 axis
• Resolution 2mg
• Magnetometer
• Resolution 134mG
• Microphone
• Tone Detector
• Sounder
• 4.5kHz

52
PNI Magnetometer/Compass

• Resolution 400 mGauss
• Three axis, under 15 in large quantities

53
Ultrasonic Transceiver

• Used for ranging
• Up to 2.5m range
• 6cm accuracy
• Dedicated microprocessor
• 25kHz element

54
Mica Weather Board

• Total Solar Radiation
• Photosynthetically Active Radiation
• Resolution 0.3A/W
• Relative Humidity
• Accuracy 2
• Barometric Pressure
• Accuracy 1.5mbar
• Temperature
• Accuracy 0.01oC
• Acceleration
• 2 axis
• Resolution 2mg
• Designed by UCB w/ Crossbow and UCLA

Revision 1.5
Revision 1.0
55
MicaDot Sensor Boards
Dot sensorboards (1diameter) HoneyDot
Magnetometer Resolution 134 mGauss Ultrasonic
Transceiver Weather Station
56
XSM node platform

• Derived from Mica2 mote
• Better sensor actuator range
• 4 Passive Infrared 25m for SUV
• Sounder 10m
• Microphone 50m for ATV
• Magnetometer 7m for SUV
• Better radio range 30m
• Other features
• Grenade timer
• Wakeup circuits (Mic, PIR)
• Adjustable frequency sounder
• Integrated Mag Set/Reset

57
Telos Platform

• Low Power
• Minimal port leakage
• Hardware isolation and buffering
• Robust
• Hardware flash write protection
• Integrated antenna (50m-125m)
• Standard IDC connectors
• Standards Based
• USB
• IEEE 802.15.4 (CC2420 radio)
• High Performance
• 10kB RAM, 16-bit core, extensive double buffering
• 12-bit ADC and DAC (200ksamples/sec)
• DMA transfers while CPU off

58
TelosMeeting the Low Power Goal
All values measured at room temperature
(approximately 25oC) at 3V supply voltage Source
Telos Enabling Low Power Wireless Sensor
Network ResearchTo appear, IPSN/SPOTS, April
2005
59
Telos Performance

• 200ksamples/sec sampling rate, DMA transfers, DAC
• Increased performance functionality over
  existing designs
• New link quality indicator predicts average
  packet loss

Flat field range test _at_ 4 off ground (125m _at_ 1m
elevation)
60
Brick-sized node Stargate

• Mini Linux computers communicating via 802.11
  radios
• Computationally powerful
• High bandwidth
• Requires more energy (AA infeasible)
• Used as a gateway between the Internet and WSN

61
Stargate
62
Manufacturers of Sensor Nodes

• Crossbow (www.xbow.com)
• Mica2 mote, Micaz, Dot mote and Stargate Platform
• Intel Research
• Stargate, iMote
• Moteiv Telos Mote
• Dust Inc
• Smart Dust
• Cogent Computer (www.cogcomp.com)
• XYZ Node (CSB502) in collaboration with
  ENALAB_at_Yale
• Sensoria Corporation (www.sensoria.com)
• WINS NG Nodes
• Millenial Net (www.millenial.com)
• iBean sensor nodes
• Ember (www.ember.com)
• Integrated IEEE 802.15.4 stack and radio on a
  single chip

63
Challenges in sensor networks

• Energy constraint
• Unreliable communication
• Unreliable sensors
• Ad hoc deployment
• Large scale networks
• Limited computation power
• Distributed execution

• Nodes are battery powered
• Radio broadcast, limited bandwidth, bursty
  traffic
• False positives
• Pre-configuration inapplicable
• Algorithms should scale well
• Centralized algorithms inapplicable
• Difficult to debug get it right

64
Opportunities in sensor networks

• Precise clock at each node
• Atomic broadcast primitive
• Geometry
• New applications

• Timers, synchronized clocks
• All recipients hear the same message at the same
  time
• Dense nodes over 2D plane
• Tracking, spatial querying, geographic routing,
  localization, network reprogramming, etc.

65
Outline

• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study TinyOS

66
Operating system challenges in WSN

• Usual operating system goals
• Make access to device resources abstract
  (virtualization)
• Protect resources from concurrent access
• Usual means
• Protected operation modes of the CPU hardware
  access only in these modes
• Process with separate address spaces
• Support by a memory management unit
• Problem These are not available in
  microcontrollers
• No separate protection modes, no memory
  management unit
• Would make devices more expensive, more
  power-hungry
• ! ???

67
Operating system challenges in WSN

• Possible options
• Try to implement as close to an operating
  system on WSN nodes
• In particular, try to provide a known programming
  interface
• Namely support for processes!
• Sacrifice protection of different processes from
  each other
• ! Possible, but relatively high overhead
• Do (more or less) away with operating system
• After all, there is only a single application
  running on a WSN node
• No need to protect malicious software parts from
  each other
• Direct hardware control by application might
  improve efficiency
• Currently popular verdict no OS, just a simple
  run-time environment
• Enough to abstract away hardware access details
• Biggest impact Unusual programming model

68
Main issue How to support concurrency

• Simplest option No concurrency, sequential
  processing of tasks
• Not satisfactory Risk of missing data (e.g.,
  from transceiver) when processing data, etc.
• ! Interrupts/asynchronous operation has to be
  supported
• Why concurrency is needed
• Sensor nodes CPU has to service the radio modem,
  the actual sensors, perform computation for
  application, execute communication protocol
  software, etc.

69
Traditional concurrency Processes

• Traditional OS processes/threads
• Based on interrupts, context switching
• But not available memory overhead, execution
  overhead
• But concurrency mismatch
• One process per protocol entails too many context
  switches
• Many tasks in WSN small with respect to context
  switching overhead
• And protection between processes not needed in
  WSN
• Only one application anyway

70
Event-based concurrency

• Alternative Switch to event-based programming
  model
• Perform regular processing or be idle
• React to events when they happen immediately
• Basically interrupt handler
• Problem must not remain in interrupt handler too
  long
• Danger of loosing events
• Only save data, post information that event has
  happened, then return
• ! Run-to-completion principle
• Two contexts one for handlers, one for regular
  execution

71
Components instead of processes

• Need an abstraction to group functionality
• Replacing processes for this purpose
• E.g. individual functions of a networking
  protocol
• One option Components
• Here In the sense of TinyOS
• Typically fulfill only a single, well-defined
  function
• Main difference to processes
• Component does not have an execution
• Components access same address space, no
  protection against each other
• NOT to be confused with component-based
  programming!

72
API to an event-based protocol stack

• Usual networking API sockets
• Issue blocking calls to receive data
• Ill-matched to event-based OS
• Also networking semantics in WSNs not
  necessarily well matched to/by socket semantics
• API is therefore also event-based
• E.g. Tell some component that some other
  component wants to be informed if and when data
  has arrived
• Component will be posted an event once this
  condition is met
• Details see TinyOS example discussion below

73
Dynamic power management

• Exploiting multiple operation modes is promising
• Question When to switch in power-safe mode?
• Problem Time energy overhead associated with
  wakeup greedy sleeping is not beneficial (see
  exercise)
• Scheduling approach
• Question How to control dynamic voltage scaling?
• More aggressive stepping up voltage/frequency is
  easier
• Deadlines usually bound the required speed form
  below
• Or Trading off fidelity vs. energy consumption!
• If more energy is available, compute more
  accurate results
• Example Polynomial approximation
• Start from high or low exponents depending where
  the polynomial is to be evaluated

74
Outline

• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study TinyOS

75
Case study embedded OS TinyOS nesC

• TinyOS developed by UC Berkely as runtime
  environment for their motes
• nesC as adjunct programming language
• Goal Small memory footprint
• Sacrifices made e.g. in ease of use, portability
• Portability somewhat improved in newer version
• Most important design aspects
• Component-based system
• Components interact by exchanging asynchronous
  events
• Components form a program by wiring them together
  (akin to VHDL hardware description language)

76
TinyOS components

• Components
• Frame state information
• Tasks normal execution program
• Command handlers
• Event handlers
• Handlers
• Must run to completion
• Form a components interface
• Understand and emits commands events
• Hierarchically arranged
• Events pass upward from hardware to higher-level
  components
• Commands are passed downward

77
Handlers versus tasks

• Command handlers and events must run to
  completion
• Must not wait an indeterminate amount of time
• Only a request to perform some action
• Tasks, on the other hand, can perform arbitrary,
  long computation
• Also have to be run to completion since no
  non-cooperative multi-tasking is implemented
• But can be interrupted by handlers
• ! No need for stack management, tasks are atomic
  with respect to each other

78
Split-phase programming

• Handler/task characteristics and separation has
  consequences on programming model
• How to implement a blocking call to another
  component?
• Example Order another component to send a packet
• Blocking function calls are not an option
• ! Split-phase programming
• First phase Issue the command to another
  component
• Receiving command handler will only receive the
  command, post it to a task for actual execution
  and returns immediately
• Returning from a command invocation does not mean
  that the command has been executed!
• Second phase Invoked component notifies invoker
  by event that command has been executed
• Consequences e.g. for buffer handling
• Buffers can only be freed when completion event
  is received

79
Structuring commands/events into interfaces

• Many commands/events can add up
• nesC solution Structure corresponding
  commands/events into interface types
• Example Structure timer into three interfaces
• StdCtrl
• Timer
• Clock

• Build configurations by wiring together
  corresponding interfaces

80
Building components out of simpler ones

• Wire together components to form more complex
  components out of simpler ones
• New interfaces for the complex component

81
Defining modules and components in nesC
82
Wiring components to form a configuration
83
TinyOS

• most popular operating system for WSN
• developed by UC Berkeley
• features a component-based architecture
• software is written in modular pieces called
  components
• Each component denotes the interfaces that it
  provides
• An interface declares a set of functions called
  commands that the interface provider implements
  and another set of functions called events that
  the interface user should be ready to handle
• Easy to link components together by wiring
  their interfaces to form larger components
• similar to using Lego blocks

84
TinyOS

• provides a component library that includes
  network protocols, services, and sensor drivers
• An application consists of
• a component written by the application developer
  and
• the library components that are used by the
  components in (1)
• An application developer writes only the
  application component that describes the sensors
  used in the application, the middleware services
  configured with the appropriate parameters based
  on the needs of the application

85
Benefits of using TinyOS

• Separation of concerns
• TinyOS provides a proper networking stack for
  wireless communication that abstracts away the
  underlying problems and complexity of message
  transfer from the application developer
• E.g., MAC layer
• Concurrency control
• TinyOS provides a scheduler that achieves
  efficient concurrency control
• An interrupt-driven execution model is needed to
  achieve a quick response time for the events and
  capture the data
• For example, a message transmission may take up
  to 100msec, and without an interrupt-driven
  approach the node would miss sensing and
  processing of interesting data in this period
• Scheduler takes care of the intricacies of
  interrupt-driven execution and provides
  concurrency in a safe manner by scheduling the
  execution in small threads.

86
Benefits of TinyOS

• Modularity
• TinyOSs component model facilitates reuse and
  reconfigurability since software is written in
  small functional modules. Several middleware
  services are available as well-documented
  components
• Over 500 research groups and companies are using
  TinyOS and numerous groups are actively
  contributing code to the public domain

87
TinyOS

• Microthreaded OS (lightweight thread support) and
  efficient network interfaces
• Two level scheduling structure
• Long running tasks that can be interrupted by
  hardware events
• Small, tightly integrated design that allows
  crossover of software components into hardware

88
TinyOS Concepts

• Scheduler Graph of Components
• constrained two-level scheduling model threads
  events
• Component
• Commands
• Event Handlers
• Frame (storage)
• Tasks (concurrency)
• Constrained Storage Model
• frame per component, shared stack, no heap
• Very lean multithreading
• Efficient Layering

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
init
RX_packet_done (buffer)
TX_packet_done (success)
89
Application Graph of Components
Route map
Router
Sensor Appln
application
Active Messages
Example ad hoc, multi-hop routing of photo
sensor readings
Serial Packet
Radio Packet
packet
Temp
Photo
SW
3450 B code 226 B data
HW
UART
Radio byte
ADC
byte
clock
RFM
bit
Graph of cooperating state machines on shared
stack
90
TOS Execution Model

• commands request action
• ack/nack at every boundary
• call command or post task
• events notify occurrence
• HW interrupt at lowest level
• may signal events
• call commands
• post tasks
• tasks provide logical concurrency
• preempted by events

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
91
Event-Driven Sensor Access Pattern
command result_t StdControl.start() return
call Timer.start(TIMER_REPEAT, 200) event
result_t Timer.fired() return call
sensor.getData() event result_t
sensor.dataReady(uint16_t data)
display(data) return SUCCESS
SENSE
LED
Photo
Timer

• clock event handler initiates data collection
• sensor signals data ready event
• data event handler calls output command
• device sleeps or handles other activity while
  waiting
• conservative send/ack at component boundary

92
TinyOS Commands and Events
... status call CmdName(args) ...
command CmdName(args) ... return status
event EvtName(args) ... return status
... status signal EvtName(args) ...
93
TinyOS Execution Contexts

• Events generated by interrupts preempt tasks
• Tasks do not preempt tasks
• Both essential process state transitions

94
Tasks

• provide concurrency internal to a component
• longer running operations
• are preempted by events
• able to perform operations beyond event context
• may call commands
• may signal events
• not preempted by tasks

... post TskName() ...
task void TskName ...
95
Typical Application Use of Tasks

• event driven data acquisition
• schedule task to do computational portion

event result_t sensor.dataReady(uint16_t data)
putdata(data) post processData()
return SUCCESS task void processData()
int16_t i, sum0 for (i0 i maxdata
i) sum (rdatai 7)
display(sum shiftdata)
96
Task Scheduling

• Currently simple fifo scheduler
• Bounded number of pending tasks
• When idle, shuts down node except clock
• Uses non-blocking task queue data structure
• Simple event-driven structure control over
  complete application/system graph
• instead of complex task priorities

97
Maintaining Scheduling Agility

• Need logical concurrency at many levels of the
  graph
• While meeting hard timing constraints
• sample the radio in every bit window
• Retain event-driven structure throughout
  application
• Tasks extend processing outside event window
• All operations are non-blocking

98
The Complete Application
SenseToRfm
generic comm
IntToRfm
AMStandard
RadioCRCPacket
UARTnoCRCPacket
packet
noCRCPacket
photo
Timer
MicaHighSpeedRadioM
phototemp
SecDedEncode
SW
byte
RandomLFSR
SPIByteFIFO
HW
ADC
UART
ClockC
bit
SlavePin
99
Programming Syntax

• TinyOS 2.0 is written in an extension of C,
  called nesC
• Applications are too
• just additional components composed with OS
  components
• Provides syntax for TinyOS concurrency and
  storage model
• commands, events, tasks
• local frame variable
• Compositional support
• separation of definition and linkage
• robustness through narrow interfaces and reuse
• Interpositioning
• Whole system analysis and optimization

100
Components

• A component specifies a set of interfaces by
  which it is connected to other components
• provides a set of interfaces to others
• uses a set of interfaces provided by others
• Interfaces are bidirectional
• include commands and events
• Interface methods are the external namespace of
  the component

provides
StdControl
Timer
provides interface StdControl interface
Timer uses interface Clock
Timer Component
Clock
uses
101
Component Interface

• logically related set of commands and events

StdControl.nc interface StdControl
command result_t init() command result_t
start() command result_t stop()
Clock.nc interface Clock command result_t
setRate(char interval, char scale) event
result_t fire()
102
Component Types

• Configurations
• link together components to compose new component
• configurations can be nested
• complete main application is always a
  configuration
• Modules
• provides code that implements one or more
  interfaces and internal behavior

103
Example1

• Blink application

Blink
Main
configuration Blink implementation
components Main, BlinkM, TimerC, LedsC
Main.StdControl -gt TimerC.StdControl
Main.StdControl -gt BlinkM.StdControl
BlinkM.Timer -gt TimerC.Timerunique("Timer")
BlinkM.Leds -gt LedsC
BlinkM
Blink.nc
TimerC
LedsC
104
Example1

• BlinkM module

module BlinkM provides interface
StdControl uses interface Timer uses
interface Leds implementation command
result_t StdControl.init() call Leds.init()
return SUCCESS

• command result_t StdControl.start()
• return call Timer.start(TIMER_REPEAT,
  1000)
• command result_t StdControl.stop()
• return call Timer.stop()
• event result_t Clock.fire()
• call Leds.redToggle()
• return SUCCESS

Blink.nc
Blink.nc
105
Example2
configuration SenseToRfm implementation
components Main, SenseToInt, IntToRfm, TimerC,
Photo as Sensor Main.StdControl -gt
SenseToInt Main.StdControl -gt IntToRfm
SenseToInt.Timer -gt TimerC.TimeruniqueTimer
SenseToInt.ADC -gt Sensor SenseToInt.ADCControl
-gt Sensor SenseToInt.IntOutput -gt IntToRfm
Main
StdControl
SenseToInt
ADCControl
IntOutput
ADC
Timer
106
Nested Configuration
includes IntMsg configuration IntToRfm
provides interface IntOutput interface
StdControl implementation components
IntToRfmM, GenericComm as Comm IntOutput
IntToRfmM StdControl IntToRfmM
IntToRfmM.Send -gt Comm.SendMsgAM_INTMSG
IntToRfmM.SubControl -gt Comm
StdControl
IntOutput
IntToRfmM
SendMsgAM_INTMSG
SubControl
GenericComm
107
IntToRfm Module
command result_t StdControl.start() return
call SubControl.start() command result_t
StdControl.stop() return call
SubControl.stop() command result_t
IntOutput.output(uint16_t value) ...
if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg),
data) return SUCCESS ... event
result_t Send.sendDone(TOS_MsgPtr msg, result_t
success) ...
includes IntMsg module IntToRfmM uses
interface StdControl as SubControl
interface SendMsg as Send provides
interface IntOutput interface StdControl
implementation bool pending struct
TOS_Msg data command result_t
StdControl.init() pending FALSE
return call SubControl.init()
108
Atomicity Support in nesC

• Split phase operations require care to deal with
  pending operations
• Race conditions may occur when shared state is
  accessed by premptible executions, e.g. when an
  event accesses a shared state, or when a task
  updates state (premptible by an event which then
  uses that state)
• nesC supports atomic block
• implemented by turning of interrupts
• for efficiency, no calls are allowed in block
• access to shared variable outside atomic block is
  not allowed

109
Supporting HW Evolution

• Distribution broken into
• apps top-level applications
• tos
• lib shared application components
• system hardware independent system components
• platform hardware dependent system components
• includes HPLs and hardware.h
• interfaces
• tools development support tools
• contrib
• beta
• Component design so HW and SW look the same
• example temp component
• may abstract particular channel of ADC on the
  microcontroller
• may be a SW I2C protocol to a sensor board with
  digital sensor or ADC
• HW/SW boundary can move up and down with minimal
  changes

110
Sending a Message

• Refuses to accept command if buffer is still
  full or network refuses to accept send command
• User component provide structured msg storage

111
Send done Event
event result_t IntOutput.sendDone(TOS_MsgPtr
msg, result_t success) if (pending msg
data) pending FALSE signal
IntOutput.outputComplete(success)
return SUCCESS

• Send done event fans out to all potential senders
• Originator determined by match
• free buffer on success, retry or fail on failure
• Others use the event to schedule pending
  communication

112
Receive Event
event TOS_MsgPtr ReceiveIntMsg.receive(TOS_MsgPtr
m) IntMsg message (IntMsg )m-gtdata
call IntOutput.output(message-gtval)
return m

• Active message automatically dispatched to
  associated handler
• knows format, no run-time parsing
• performs action on message event
• Must return free buffer to the system
• typically the incoming buffer if processing
  complete

113
Tiny Active Messages

• Sending
• declare buffer storage in a frame
• request transmission
• name a handler
• handle completion signal
• Receiving
• declare a handler
• firing a handler automatic
• Buffer management
• strict ownership exchange
• tx send done event ? reuse
• rx must return a buffer

114
Tasks in Low-level Operation

• transmit packet
• send command schedules task to calculate CRC
• task initiates byte-level data pump
• events keep the pump flowing
• receive packet
• receive event schedules task to check CRC
• task signals packet ready if OK
• byte-level tx/rx
• task scheduled to encode/decode each complete
  byte
• must take less time that byte data transfer

115
TinyOS tools

• TOSSIM a simulator for tinyos programs
• ListenRaw, SerialForwarder java tools to receive
  raw packets on PC from base node
• Oscilloscope java tool to visualize (sensor)
  data in real time
• Memory usage breaks down memory usage per
  component (in contrib)
• Peacekeeper detect RAM corruption due to stack
  overflows (in lib)
• Stopwatch tool to measure execution time of code
  block by timestamping at entry and exit (in osu
  CVS server)
• Makedoc and graphviz generate and visualize
  component hierarchy
• Surge, Deluge, SNMS, TinyDB

116
TinyOS Limitations

• Static allocation allows for compile-time
  analysis, but can make programming harder
• No support for heterogeneity
• Support for other platforms (e.g. stargate)
• Support for high data rate apps (e.g. acoustic
  beamforming)
• Interoperability with other software frameworks
  and languages
• Limited visibility
• Debugging
• Intra-node fault tolerance
• Robustness solved in the details of
  implementation
• nesC offers only some types of checking

117
Summary

• For WSN, the need to build cheap, low-energy,
  (small) devices has various consequences for
  system design
• Radio frontends and controllers are much simpler
  than in conventional mobile networks
• Energy supply and scavenging are still (and for
  the foreseeable future) a premium resource
• Power management (switching off or throttling
  down devices) crucial
• Unique programming challenges of embedded systems
• Concurrency without support, protection
• De facto standard TinyOS

118
Acknowledgements

• Notes on TinyOS rely heavily on Murat Demirbas
  course CSE 646 Wireless Sensor Networks Suny
  Buffalo