Introduction to Wireless Sensor Networks

1

• Introduction to Wireless Sensor Networks

Base Station Has external power supply Can
program the base node Used with base node to
communicate with the Wireless Sensor Network (WSN)
Base Node Node connected to Base Station Provides
processing capability to the Base Station Can
send/ receive radio signals to/from the WSN
2
Inter-Node Communication

• General idea
• Sender
• Receiver

Determine when message buffer can be reused
Fill message buffer with data
Specify Recipients
Pass buffer to OS
OS obtains free buffer to store next message
OS Buffers incoming message in a free buffer
Signal application with new message
3
Multi-Hop Communication

• Tree-based routing
• Intra-network routing
• Broadcast and epidemic protocols
• Common abstraction layers
• Multi-hop broadcast
• Tree-based routing

4
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
5
A Multihop Routing Example
6
How Things Connect
motes
e.g. your application
Port
Serial Forwarder
e.g. REM
USB conn.
Trawler
Base station Programming Board
Internet
Trawler is a client of the serial forwarded
server (makes sensor network data available to
higher level applications)
you
7
Wireless Sensor Networks Convergence of
Technologies
Wireless communications optical and RF
communications enable networking between nodes
Embedded computing Small and low-cost processors
that are networked together facilitate
collaboration through information and resource
sharing
Sensors Miniaturization and micromachining makes
tiny and low-cost sensors available commercially
Wireless sensor networks
Need OS for the embedded computing
8
Think Back Mote Subsystems
9
Mote Characteristics

• Event-driven
• Ex message arrival, sensor acquisition
• Concurrency-intensive operation
• Multiple flows, not wait-command-respond
• Unattended Operation
• Reduce run-time errors
• Limited resources
• Restricted by mote size, cost and power
  consumption
• Diversity in design and usage
• Application specific, not general purpose

10
Operating System Requirements

• Small physical size and low power consumption
• Devices have limited memory and power resources
• Concurrency intensive operation
• Need to be able to service packets on-the-fly in
  real-time
• Limited hardware parallelism and controller
  hierarchy
• Limited number, and capability of controllers
• Unsophisticated processor-memory-switch level
  interconnect
• Diversity in design and usage
• Provide a high degree of software modularity for
  application specific sensors
• Robust Operation
• OS should be reliable, and assist applications in
  surviving individual device failures

11
Approach

• Modular Architecture
• OS composed of components
• Components implement very specific function.
• Leads to small image
• Reusable components

12
Information System Architecture
Application
App1
App2
App3
Power Management
Algorithms
Modules
Services
Virtual Machine
Middleware
Middleware management
System Threads Address space Files
Transport
Operating System
Network
Data Link
Physical
Hardware Drivers
Sensor Driver
Hardware
Hardware
Sensor
13
Design goals

• Simple framework for resource constrained
  concurrency
• Single stack
• Flexible hardware/software and system boundary
• Expressive enough to build sophisticated,
  application specific system structures
• Avoid arbitrary constraints on optimization
• Communication is integral to execution
• Asynchrony is first class
• Promote robustness
• Modular
• Static allocation
• Explicit success/fail at all interfaces
• Reuse
• Ease of interpositioning

14
Design Rationale

• Main board requirements
• Easy to program and debug
• Need an easy access to most signals in the system
• Need standard interfaces
• Basic self-monitoring and maintenance capability
• Ability to reprogram remotely
• Ability to control radio cell size
• Ability to monitor signal strength
• Other self monitoring added on sensor packs
• Sensor requirements
• Digital serial interfaces
• Analog sensor support
• Ability to control on/off state of individual
  sensors

15
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!

16
The Solution TinyOS

• A microthreaded OS that draws on previous work
  done for 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

17
TinyOS
Main
Routing Layer
Messaging Layer
clocks
Other Layers
18
Class of networking abstractions

• General widely used, TinyOS provides
  mechanisms/policy
• ex active messages networking abstraction,
  multi-hop broadcast, tree-based routing.
• Specialized widely used, TinyOS provides
  mechanism.
• Application-specific policy
• Ex power management, time synchronization.
• IN flux without any consensus on the
  abstraction.
• Absence
• They appear widely in the literature , but are
  scarcely used in the application.

19
Real Performance of TinyOS Packet Loss
Better
Worse
Increasing Transmission Frequency
Shane Erickson, SUPERB
20
TinyOS is a tiny OS !

• Operating System for Motes.
• Supports well defined programming model
• Provides frequently used functionality
• Networking
• Scheduling
• Other components interfaces (clock, sensor.)
• component-based operating system in which
  components interact through typed interfaces.
• OS is written in nesC
• Design Philosophy sleep as much as possible, and
  only wake up to react to events
• Event-driven
• Main()

21
Example Memory Allocation
22
TinyOS

• Event driven, modular operating environment for a
  wireless network of deeply embedded sensors.
• The problem
• Limited computational ability and energy supply
• High levels of concurrency required
• Diversity in design usage
• Application-specific requirements
• Robust operation is required
• Objective
• Support composition of diverse HW/ SW
• Provide a natural paradigm for supporting
  interaction with the physical world.
• Minimize resources required.

23
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

24
Energy Usage in A Typical Data Collection Scenario

• Each mote collects 1 sample of (light,humidity)
  data every 10 seconds, forwards it
• Each mote can hear 10 other motes
• Process
• Wake up, collect samples ( 1 second)
• Listen to radio for messages to forward (1
  second)
• Forward data

25
Typical Operational Mode

• Major External Events
• Trigger collection of small processing steps
  (tasks and events)
• May have interval of hard real time sampling
• Radio
• Sensor
• Interleaved with moderate amount of processing in
  small chunks at various levels
• Periods of sleep
• Interspersed with timer mgmt

26
Hardware Features

• 3 Sleep Modes that can shut off the processor and
  other components not required for wake up.
• Radio can transfer data at up to 19 Kbps, with no
  data buffering.
• Sensor consumes about 19.5 mA at peak load, and
  10 µA when inactive.
• A 575 mAh battery can power a sensor for 30 hours
  at peak load, or for over a year when inactive.

Image courtesy Jason Hill et al
27
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
28
Programming Mote

• Downloading binary image into device
• Connect to programmer
• Run programming software

29
Declarative Queries

• Programming Apps is Hard
• Limited power budget
• Lossy, low bandwidth communication
• Require long-lived, zero admin deployments
• Distributed Algorithms
• Limited tools, debugging interfaces
• Queries abstract away much of the complexity
• Burden on the database developers
• Users get
• Safe, optimizable programs
• Freedom to think about apps instead of details

30
TinyOS Motivation and Design

• Component Architecture
• Application logic
• Hardware wrappers
• Soft Real Time OS
• Tasks
• Run to Completion and do not preempt other tasks
  
• Split Phase Operation
• Caller Post -gt Run Task -gt Notify Caller Task is
  Complete
• All non-blocking
• Events
• Run to completion but may preempt other tasks or
  events
• Triggered by completion of task or external event
  (i.e., interrupt)
• Resource Contention
• What if some Task is already busy? Reject
  subsequent requests or queue.
• No Deadlocks

31
Operating System Design
Design Requirements
Component-Based Model
Execution-Model

• Fault tolerance
• Small foot-print
• Low-power consumption
• Support for reconfigurable computing.
• Distributed system support
• Scalability
• Support for inter-satellite link communications

Thread-based model
Event-based model
Component library

• Tasks perform computations
• Tasks are implemented as finite state machines
• States of tasks are transitioned through events

• The system uses a main thread, which hands off
  tasks to individual task-handling threads
• High context switch overhead

Conclusion The component-based structural model
provides flexibility, reusability and is suitable
for distributed systems design while the
event-based behavioural model provides speed, low
power and memory efficiency.
32
Programming Model

• Components
• .comp specification
• .C behaviour
• .desc select and wire
• specification
• accepts commands
• uses commands
• signals events
• handles events

comp2 .desc
application .desc
33
OS for tiny devices

• Programs are built out of components
• Written in nesC
• Each component is specified by an interface
• Provides hooks for wiring components together
• Components are statically wired together based on
  their interfaces
• Increases runtime efficiency

34
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)

35
TOS

• components communicate through narrow interfaces.
• Code reuse Allows limited code and data memory
  on sensor network nodes.
• Its component model is designed to minimize
  application code size by linking only needed
  functionality and to speed development through
  code reuse.

36
TinyOS Basics

• Components can be easily developed and reused.
• Adaptable to many application domains
• Components can be easily replaced
• Components can be hardware or software
• Allows boundaries to change unknown to
  programmer.
• Hardware has internal concurrency
• Software need to be able to have it as well.
• Hardware is non-blocking
• Software should be too.

37
Tiny OS Concepts

• Scheduler Graph of Components
• constrained two-level scheduling model tasks
  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 can signal events

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
TX_packet_done (success)
init
RX_packet_done (buffer)
38
TinyOS

• Component-Based
• Separate construction and composition
• Application are sets of components
• Components are connected by wiring interface user
  to interface provider
• Components can call another components command,
  and provide event handler
• Two-way communication
• As specified by the interface
• Two kinds of components
• Module implements behavior
• Configuration specifies wiring

39
Components

• A nesC application consists of one or more
  components linked together to form an executable.
• A component provides and uses interfaces.
• An interface declares a set of functions called
  commands and another set of functions called
  events.
• Modules provide application code, implementing
  one or more interface.
• Configurations are used to assemble other
  components together, connecting interfaces used
  by components to interfaces provided by others.
• This is called wiring.

40
Programming TinyOs

• A component provides and uses interfaces.
• A interface defines a logically related set of
  commands and events.
• Components implement the events they use and the
  commands they provide
• There are two types of components in nesC
• Modules. It implements application code.
• Configurations. It assemble other components
  together, called wiring
• A component does not care if another component is
  a module or configuration
• A component may be composed of other components
  via configurations

41
nesC / tinyOS Have Three Computational
Abstractions

• command (call)
• Do something for me and then tell me when youre
  done
• Request to a component to perform some service
• Analogous to OS downcall
• Returns immediately
• event (signal)
• Im done with what you asked or possibly Hey,
  something happened
• Signals completion of service call-ed in 1
• External stimulus (i.e., hardware interrupt)
• Analogous to OS upcall
• task (task, post)
• Do something for me when you get some free time
• Some function executed by the tinyOS scheduler
• FIFO, non-preemptive

42
TinyOS Commands and Events
... status call CmdName(args) ...
command CmdName(args) ... return status
event EvtName)(args) ... return status
... status signal EvtName(args) ...
43
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
44
Configuration

• A configuration is a particular TinyOS component
  that wires together other components.
• Connects interfaces used by components to
  interfaces provided by others.
• Allows for hiding the implementation of a single
  service implemented with multiple interconnected
  components.
• e.g. a communication service that needs to be
  wired to timers, random generators and
  low-level hardware facilities can be exported by
  means of a single configuration

45
Components
Component
Module Application Code Implement One or more
Interfaces
Configuration Wires together modules
46
Modules

• Modules provide the implementation of one or more
  interfaces
• They may consume(use) other interfaces to do so
• module MyComponentP
• provides interface SplitControl
• uses interface Receive
• uses interface Leds as BlinkingLights
• implementation

47
Modules

• Implementation block may contain
• Variable declarations
• Helper functions
• Tasks
• Event handlers
• Command implemenations

48
Component Syntax - Module

• 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

module ForwarderM provides
interface StdControl uses
interface StdControl as CommControl
interface ReceiveMsg interface
SendMsg interface Leds
implementation // code implementing all
provided commands and used events
49
Composition

• 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 bi-directional
• 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
50
Interface Syntax- interface StdControl

• Look in lttosgt/tos/interfaces/StdControl.nc
• Multiple components may provide and use this
  interface
• Every component should provide this interface
• This is good programming technique, it is not a
  language specification

interface StdControl // Initialize the
component and its subcomponents. command
result_t init() // Start the component and its
subcomponents. command result_t start() //
Stop the component and pertinent
subcomponents command result_t stop()
51
Component implementation
module ForwarderM //interface
declaration implementation command result_t
StdControl.init() call CommControl.init()
call Leds.init() return SUCCESS
command result_t StdControl.start()
command result_t StdControl.stop()
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
call Leds.yellowToggle() call
SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m)
return m event result_t
SendMsg.sendDone(TOS_MsgPtr msg, bool success)
call Leds.greenToggle() return
success
Command implementation (interface provided)
Event implementation (interface used)
52
INTERFACE logically related set of commands and
events

• interface StdControl//booting and power
  mangement
• command result_t init()
• command result_t start()
• command result_t stop()
• interface ADC // data collection
• command result_t getData()
• command result_t getContinuousData()
• event result_t dataReady (uint16_t data)
• interface SendMsg // single-hop networking
• command result_t send(uint16_t addr, uint8_t
  len,
• TOS_MsgPtr msg)
• event result_t sendDone (TOS_MsgPtr msg,
  result_t success)
• interface ReceiveMsg//single-hop networking
• event TOS_MsgPtr receive(TOS_MsgPtr m)

53
Background

• Building a TinyOS application involves connecting
  the interfaces of components together.
• Interfaces are bidirectional
• Call a user can make (commands)
• Call that a provider can make on a user (events)
• Sending a packet command
• Receiving a packet event.

54
Programming the Processor

• Program the runtime memory image into a flash
• No loader, no dynamic linker
• Programming steps
• Extract the code and data segments from an
  executable into an SREC file
• Erase the current contents of the flash
• Reset the processor
• Download the program
• Serial download protocol
• Each download command contains the address, and
  the contents of to be stored
• 10 ms delay per byte of code
• Verify the program read the flash, match it
  against the source image
• After reset, start executing C runtime
• No ability to write the flash on the fly
• Requires a coprocessor for reprogramming

55
Memory
Flash
registers
RAM
scratch
stack
56
Interface Syntax- interface SendMsg

• Look in lttosgt/tos/interfaces/SendMsg.nc
• Includes both command and event.
• Split the task of sending a message into two
  parts, send and sendDone.

includes AM // includes AM.h located in
lttosgt\tos\types\ interface SendMsg // send a
message command result_t send(uint16_t address,
uint8_t length, TOS_MsgPtr msg) // an event
indicating the previous message was sent event
result_t sendDone(TOS_MsgPtr msg, result_t
success)
57
Concurrency Model

• There are two threads of execution
• tasks and hardware event handlers.
• Tasks
• functions whose execution is deferred.
• Once scheduled, they run to completion and do not
  preempt one another
• Hardware event handlers
• are executed in response to a hardware interrupt
  and also runs to completion,
• but may preempt the execution of a task or other
  hardware event handler.
• Using async keyword.

58
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

59
TinyOS Concurrency

• Tasks run to completion (do not preempt)
• while(1) runNextTaskOrSleep()
• Two kinds of function
• Synchronous can only run in a task (main)
  Asynchronous can run in a task or interrupt
• Can preempt
• Compile-time race condition detection
• Posting is how you go from async to sync

60
TinyOs Concurrency Model

• TinyOS executes only one program consisting of a
  set of components.
• Two type threads
• Task
• Hardware event handler
• Tasks
• Time flexible
• Longer background processing jobs
• Atomic with respect to other tasks (single
  threaded)
• Preempted by event
• Hardware event handlers
• Time critical
• Shorter duration (hand off to task if need be)
• Interrupts task and other hardware handler.
• Last-in first-out semantics (no priority among
  events)
• executed in response to a hardware interrupt

61
Concurrency in nesC / tinyOS

• Code is divided into two parts
• Synchronous Code (SC) code (functions, commands,
  events, tasks) that is only reachable from tasks.
• Asynchronous Code (AC) code that is reachable
  from at least one interrupt handler.

M1 Complete
NonInterrupt Trigger
Interrupt Trigger Event
M1
Call to M2 Cmd
Event
M2
M3 Complete
Call to M3 Cmd
Call to M3 Task T1
M3
Task M3.T1 Runs in FIFO
Time
62
Concurrency

• Synchronous code (SC)
• Only reachable from tasks
• Asynchronous code (AC)
• Reachable from at least one interrupt handler
• Can run in a task or interrupt
• SC is atomic with respect to each other
• Ex. Only one task runs at any time
• Any update to variables shared with AC is
  potentially a race condition
• What to do

63
Compiling and Running a Program
Send it over the network to a VM
VM-specific binary code
Write programs in the scripter
64
Tasks

• Another TinyOS execution thread model beside
  events
• Provide concurrency internal to a component
• Tasks are scheduled to run in the future
• Different from events
• Suitable for non time-critical functions
• May call commands and signal events
• Not preempted by another task
• Only one task runs at any time
• A task can post itself
• Can be preempted by an event

65
TinyOS Execution Contexts

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

66
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)

• 128 Hz sampling rate
• simple FIR filter
• dynamic software tuning for centering the
  magnetometer signal (1208 bytes)
• digital control of analog, not DSP
• ADC (196 bytes)

67
Tasks Example

• task void readSensor()
• if (sensor.getData() ! SUCCESS)
• post readSensor() // Retries until success
• event void Boot.booted()
• call Timer.startOneShot(200)
• event void Timer.fired()
• post readSensor() //Posts a task
• event void sensor.readDone(error_t error,
  uint16_t data)
• if (error SUCCESS)
• writeToFlash(data)
• call Timer.startOneShot(200)
• else
• post readSensor() // Retries until success
• ...
• Extending previous event-driven example to
  handle failed events

68
TinyOS Execution Contexts

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

69
Application Graph of Components
Route map
router
sensor appln
application
Active Messages
Radio Packet
Serial Packet
packet
Temp
photo
SW
Example ad hoc, multi-hop routing of photo
sensor readings
HW
UART
Radio byte
ADC
byte
3450 B code 226 B data
clocks
RFM
bit
Graph of cooperating state machines on shared
stack Execution driven by interrupts
70
Component Syntax - Configuration
Forwarder
71
TOS Execution Model

• commands request action
• ack/nack at every boundary
• call cmd or post task
• events notify occurrence
• HW intrpt at lowest level
• may signal events
• call cmds
• post tasks
• Tasks provide logical concurrency
• preempted by events
• Migration of HW/SW boundary

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
72
Program Development Cycle
73
Programming TinyOS - nesC

• Provides syntax for TinyOS concurrency and
  storage model
• commands, events, tasks
• local frame variables
• Rich Compositional Support
• separation of definition and linkage
• robustness through narrow interfaces and reuse
• interpositioning
• Whole system analysis and optimization

74
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)

• 128 Hz sampling rate
• simple FIR filter
• dynamic software tuning for centering the
  magnetometer signal (1208 bytes)
• digital control of analog, not DSP
• ADC (196 bytes)

75
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 ...
76
Tasks in low-level operation

• transmit packet
• send command schedules task to calculate CRC
• task initiated 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
• i2c component
• i2c bus has long suspensive operations
• tasks used to create split-phase interface
• events can procede during bus transactions
• Timer
• Post task in-critical section, signal event when
  current task complete

Make SW look like HW
77
A Complete Application
SenseToRfm
generic comm
IntToRfm
AMStandard
RadioPacket
UARTPacket
packet
noCRCPacket
photo
Timer
MicaHighSpeedRadioM
phototemp
SecDedEncode
SW
byte
RandomLFSR
SPIByteFIFO
HW
ADC
UART
ClockC
bit
SlavePin
Mica2 stack Interpostioning ChipCon
78
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
• behaves like any other event
• Buffer management
• strict ownership exchange
• tx done event gt reuse
• rx must rtn a buffer

79
TOS Active Messages

• Message is active because it contains the
  destination address, group ID, and type.
• group group IDs create a virtual network
• an 8 bit value specified in lttosgt/apps/Makelocal
• The address is a 16-bit value specified by make
• make install.ltidgt mica2
• length specifies the size of the message .
• crc is the check sum

typedef struct TOS_Msg // the following are
transmitted uint16_t addr uint8_t
type uint8_t group uint8_t length int8_t
dataTOSH_DATA_LENGTH uint16_t crc // the
following are not transmitted uint16_t
strength uint8_t ack uint16_t time uint8_t
sendSecurityMode uint8_t receiveSecurityMode
TOS_Msg
80
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

81
Sending a message

• Define the message format
• Define a unique active message number
• How does TOS know the AM number?

configuration Forwarder implementation
ForwarderM.SendMsg -gt Comm.SendMsgAM_INTMSG
ForwarderM.ReceiveMsg -gt Comm.ReceiveMsgAM_INTMSG

82
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 the format, no run-time parsing
• performs action on message event
• Must return free buffer to the system
• typically the incoming buffer if processing
  complete

83
Receiving a message

• Define the message format
• Define a unique active message number
• How does TOS know the AM number?

configuration Forwarder implementation
ForwarderM.SendMsg -gt Comm.SendMsgAM_INTMSG
ForwarderM.ReceiveMsg -gt Comm.ReceiveMsgAM_INTMSG

84

• Deployment
• Final stage of application implementation on
  Field motes
• Performed after repetitive tests on simulator and
  hardware to meet loss threshold

• Experimental Setup

• Design or Development
• Failures must be anticipated during the design of
  the application and debug messages provided for
  evaluation.
• Several areas of the code can be tested
  simultaneously.

• Experimentation
• Experimentation is done with Hardware motes and
  Simulation iteratively to isolate errors
• Testing is performed to determine if application
  is suitable for deployment

85
Characteristics of Network Sensors

• Small physical size and low power consumption
• Concurrency-intensive operation
• multiple flows, not wait-command-respond
• Limited Physical Parallelism and Controller
  Hierarchy
• primitive direct-to-device interface
• Asynchronous and synchronous devices
• Diversity in Design and Usage
• application specific, not general purpose
• huge device variation
• gt efficient modularity
• gt migration across HW/SW boundary
• Robust Operation
• numerous, unattended, critical
• gt narrow interfaces

86
Conclusions

• TinyOS is a highly modular software environment
  tailored to the requirements of Network Sensors,
  stressing efficiency, modularity, and
  concurrency.
• TinyOS should be able to support new sensor
  devices as they evolve.
• Running an application on TinyOS can help reveal
  the impact of architectural changes in the
  underlying hardware, making it easier to design
  hardware that is optimized for a particular
  application.

87
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