Design and Implementation of a Framework for Efficient and Programmable Sensor Networks

1
Design and Implementation of a Framework for
Efficient and Programmable Sensor Networks

• Athanassios Boulis, Chih-Chieh Han, and Mani B.
  Srivastava
• EE Dept., UCLA
• MobiSys 2003
• Wednesday, May 7th 2003

2
Wireless Ad hoc Sensor Networks
Collaborative processing among sensor nodes to
extract the needed information
The network provides information services
Multiple, transient users sharing the services
network
event
Different applications Different
distributed algorithms

• How does one program the network to provide the
  needed information services?

3
Approaches to Programmability

• Node level programmability
• usually done at pre-deployment phase (e.g.,
  TinyOS at Berkeley)
• Pre- deployment allows few algorithms running
  tunable by parameters, not flexible to
  accommodate all the users needs

Programmer

• Not suitable for post-deployment
• use local port to reprogram Nodes physically
  unreachable
• use network to reprogram High volume traffic,
  network not sharable.

4
Approaches to Programmability

• System level programmability

The user issues a query to the network and the
nodes are tasked autonomously.
Database model Network is seen as a distributed
database (e.g., TinyDB, Cougar) Active sensor
approaches adaptation of the AN idea (e.g.,
Maté, Smart Messages)
Intuitive - No control over the distributed
algorithm executed Expressive in terms of
distributed algorithms - Added responsibility to
specify distributed algorithm
Our approach
5
Differences of Active Sensor Frameworks

• Abstracting the run-time environment of the node
  has several conflicting choices

choice
Level of abstraction Virtual Machine Script
interpreter
-
-


impact
impact
impact
Memory footprint
Code compactness
Delay overhead

-

choice
Services provided Resources sharable Multi-user
support Expandable/portable
6
Our Framework SensorWare

• Focus sharable resources, multi-user support,
  expandable platform, code compactness.
• Choices scripting abstraction, rich set of
  expandable services
• Price memory footprint, not suitable for some
  devices at the lower end of the spectrum.

7
The Programming Model
A scripts code structure is event-based
a?
Zzz
c?
wait for event a or b or c
code
b?
Example
a?
Zzz
a?
Zzz
c?
b?
8
The Language
There are APIs for modules that are always there
Script Mobility API
The glue core The basic script interpreter
(stripped-down Tcl)
Timer API
Sensors API
Networking API
wait command
Actuator API
Optional GPS API
. . .
. . .
What about modules that depend on the platform?
Will the command set be expandable?
9
An Ecology of Platforms
Robots with iPaqs and cameras
Capabilities
Enhanced iPaqs
RSC nodes
MK-II node
motes
Size, power
10
Dealing with Capabilities Variability

• Define and support virtual devices
• Almost everything in SensorWare is a device
• Radio, Sensing(magnetometer, accelerometer)
• Battery, Timer service, mobility service in a
  robot
• Localization procedure, neighborhood discovery
• Devices are registered
• Unified interface presented to the scripts
• 4 commands act, query, createEventID,
  disposeEventID
• Number of arguments and parsing of arguments are
  defined for each device.

11
Device Operations

• act ltdevgt dev opts
• e.g., act radio tx_power 3, act camera angle 30
  150
• query ltdevgt dev opts
• e.g., query location 1cm, query neighbors
  hops 2
• createEventID ltnamegt ltdevgt dev opts
• e.g., createEventID e1 acoustic 3ms b 10
• createEventID e2 motor finished
• disposeEventID ltnamegt

12
Dealing with OS and HW Variability

• Find OS dependencies and abstract them
• Definition and creation of threads
• Support for non-polling message passing
• void Post_Queue(msg)
• msg Pend_Queue()
• Find hardware dependencies and abstract them
• Examples
• send/receive packets/bits
• set a real timer
• set the sampling rate of a sensor

13
Code Structure
Changed with platform capabilities
Never changed
Platform independent code
Device Definition code

• Register all devices
• Define functions for options parsing

Script manager
Tcl
APIs
Admission control
Device 1 code
Code dependency
Device 2 code
OS specific code

• Definition of threads
• Definition of msg passing

HW access code
Changed for porting
14
Example Periodic Estimation of Max

• replicate

In green procedures not defined here
15
Example Tracking a Local Max
Operation of previous example
Operation desired now

• At the user node having initial estimates on the
  max and its location execute spawn remote_node
  code estim max_loc
• set loc query location
• set neighbors query neighbor hop 1
  location_info
• while (1)
• replicate check_proximity max_loc neighbors
  estim max_loc
• if check_proximity max_loc loc break

Variable passing
initializations
main loop
16
Implementation Platforms
µC/OS-II
eCOS
Linux
Enhanced iPaqs
RSC nodes
future
Linux
µC/OS-II
Sensoria nodes
Medusa MK-II
17
Memory Overheads
Flash memory footprint
Dynamic memory allocation for empty script
4KBytes
OS code Linux (kernel) 609KB (pthread)
89KB µC/OS 20KB
18
Delay Overheads
19
Delay Overheads
20
Delay Overheads
21
Trade-offs in Scripting

• Why not native code? What do we get with scripts?
• Portability
• Code safety

Capabilities-related

• Slower execution
• 8 slowdown for a typical app.
• Compactness of code
• 209 bytes for a typical app (compressed)
• 764 bytes the equivalent native code (using
  external references to SensorWare services)

-
Energy-related

22
Experiences with SensorWare

• SensorWare used to build some applications

Sense presence with magnetometers
Monitor certain area Sense light
app1
app2
direct robot
point camera
Applications are built as a series of scripts
boot _agent
flooding.tcl x bytes (ascii)
all_route
sink
sensing.tcl x bytes (ascii)
relay
geo_location
getVideo.tcl x bytes (ascii)
all_flood
source
23
Experiences with SensorWare

• Difficulties, Inconveniences, Problems
• Not many services exist write scripts
• Modularity many scripts
  difficulty in same-node script interaction (e.g.
  shared local memory desired)
• Not elegant for a script to carry a lot of state
  (e.g. other scripts with their variables)
• Immediate next steps
• Implement common services.
• Fix, enhance the SensorWare API
• Create a GUI and an additional higher level of
  abstraction for easier creation of scripts.

24
Conclusions

• Proposed a active sensor framework to program
  SN
• Focus on expandability, sharability, code
  compactness
• Scripting mechanism to build an event-driven
  model to manage many different resident services
  exposed to the programmer.
• Define and expose new services in a uniform way.
• Low overheads in delay and energy.
• Initial experience building applications
• It is there, download it test it!

25
Thank you!

• All material in
• http//nesl.ee.ucla.edu/projects/sensorware
• Questions ?

26
The rest are back up slides
27
Mobility Implementation

• int Tcl_SwSpawn_Cmd()
• Compute total size including script, variable
  names, and variable values
• Serialize all above.
• If dest net addr self, create new thread
• Else send to the network
• Once arrived at destination, create new thread
• void swAgentThread(void arg)
• Create APIs
• Set variables
• Evaluate script through Tcl Engine

28
Design choices Coordination/Mobility

• Coordination model based on client server notion
• scripts are tightly collaborating
• no need for spatial-temporal decoupling
• simple, lightweight
• Weak mobility model
• basically supporting diffusion of the algorithm
• no need for partial computation between nodes
• predefined entry points
• explicit state transfer
• lightweight

29
Design choices Code Safety
Solutions dealing with a. Interpreted
nature 1, 2 b. each script different 1, 2
interpreter, different thread c. interpreter
altered to 1, 2 operate within limits
of given stack d. no cmds to access 1, 2, 3
global state or resources e. scripts declare
interest 3 in resources f. Resource
Management 3, 4
Problems 1. Info leakage 2. Info tampering 3.
Resource stealing 4. Antagonism
30
Profile-based Resource Management
sensors
radio
CPU
battery

• Managing the energy usage need to know when and
  for how long was each module used by the script
• Profile of the modules usage
• The profile of a script is measured in real-time.
• Having all profiles one can calculate the effect
  of evicting some scripts.

31
Related Work

• Active networking (e.g. PLAN at UPenn)
• Similarities scripting abstraction, weak
  mobility
• packet-driven vs. event-driven
• resource management through language design vs.
  through run-time mechanism
• Reactive Sensor Networks (at PSU)
• no scripting abstraction
• code mobility is download oriented, no proactive
• Sensor Querying and Tasking Language (Delaware)
• no provisions for efficient algorithms
• no diverse mobility rules
• no code modularity
• support for multi-user scripts
• no resource management

32
Security

• Malicious agent attacks the host
• Authentication
• Encryption
• Problem is key distribution
• Device/Resource misuses
• Denial of service (network bandwidth misuse)
• Leaky bucket may help
• Actuator misuse
• Authentication on critical actuator
• Sensor data stealing (eavesdropping)
• Encryption

33
Life Cycle of an Interest to an Event

• typedef struct
• signed char idx // index
• SwAddress addrPtr // scripts
  queue
• char namePtr // name
• struct SwDeviceOp_ opPtr // dev op
• void devParamPtr // dev data
• SwInterestState state // state
• SwInterest
• createEventID(interp, argc, argv, void devData)
• activate(SwInterest )
• deactivate(SwInterest )
• disposeEventID(void devData)

Disposed
interest
dispose
deactivated
wait on
event occurs
activated
34
Script Mobility API

• spawn options ltnodes_listgt ltscriptgt
  variable_name
• replicate options lt nodes_list gt
  variable_name
• migrate options lt nodes_list gt variable_name
• options switches to affect
• the actual transfer of code
• the type of the return values of the command
• lt nodes_list gt nodes to receive the script
• variable_name a variable name to be passed
  along with its value to the new script

35
Magnetic Sensor (magsensor)

• Tcl syntax
• createEventID ltnamegt magsensor ltperiodgt
• -b buffer_size 1
• -w wakeup_period buffer_size period
• -t threshold 0
• wait ltnamegt
• Implementation
• The same layout as Timer
• One additional thread for reading device

36
Network Device

• Tcl syntax
• send ltmailing addrgt ltmessagegt
• (act radio1 ltmailing addrgt ltmessagegt)
• wait anyRadioPkt
• Possible option
• act radio1 setpower ltvaluegt
• Predefined eventID anyRadioPkt for all agents
• Handle fragmentation/de-fragmentation
• Compress/decompress all outbound/inbound packets

37
Our Approach (1st step)
Make the node environment scriptable
Define Basic Building Blocks Basic commands
Examples
Send packet to the radio
Get data from sensing device
38
Our Approach (1st step)
Make the node environment scriptable
How do you bind many basic commands into an
algorithm?
You need a language core! (glue commands)
39
Our Approach (1st step)
Make the node environment scriptable
Send packet

• Access radio
• Find route
• Check energy
• Queue packet

Abstracted high-level description of an algorithm
Low-level tasks performed by our system
40
Our Approach (2nd step)
Make scripts mobile
Script can populate/migrate
Scripts move NOT due to explicit user
instructions, but due to the physical process and
algorithmic instructions
Language Run-time Environment SensorWare
41
The Run-Time Environment
device related
permanent
script related
Resource metering info
Admission control
Script Manager
event
interest in event
Radio
system msg.
Radio
Script 1
OS thread
. . .
Sensing
Sensor
HW access code
Script n
Timer Service
Timers cpu ctrl
42
(No Transcript)