SensorWare: A Framework for Efficient and Programmable Sensor Networks

SensorWare:A Framework for Efficient and Programmable Sensor Networks Athanassios Boulis, Chih-Chieh Han, Mani B. Srivastava EE Dept. UCLA Presented by Jia Xu CS Dept. UVa Nov 11, 2003

Outline • Contributions • Introduction • Problem • SensorWare’s approach to address this problem • SensorWare Details • Language • Run-time Environment • Portability & Expandability • Addressing & Routing • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

Roadmap • Contributions • Introduction • SensorWare Details • Code Examples • Implementation & Evaluation • Comparison & Related work • Conclusion

Contributions • A script environment for dynamic programming WSNs in a proactive and efficient way • Code mobility through script replication & migration • Good support for portability and extensibility • Admission Control & Policing of Resource Usage to make scripts stay under their resource contract

Wireless Ad-hoc Sensor Network

Programming Paradigms for WSNs • How to write/debug/test/reuse programs on WSNs? • Challenges: • Constraints (energy, computation, storage, bandwidth) • Individuals are trivial, programming as an aggregate • The aggregate is often a changing set • Dynamically deploy algorithms • Meet real-time, security, reliability requirements How does one dynamically deploy different algorithms into the network?

Workarounds • Hard-coded algorithms tunable through the transmission of parameters • Not applicable to the wide variety of possible apps. • Download executable images into the nodes • Nodes could be physically unreachable or reachable at a very high cost. • Transfer the executable images into nodes • Energy inefficient (communication cost) • Cannot allow the sharing of the WSN by multiple users.

Basic questions • How to express the algorithms? • How to dynamically deploy them? SensorWare employs lightweight and mobile control scripts that are autonomously populated in sensor nodes after a triggering user injection.

Scriptable Environment Define: Basic Building Blocks Basic commands Examples : Send packet to the radio Get data from sensing device

Examples: Flow control Variable support Expression evaluation Scriptable Environment How do you bind many basic commands into an algorithm? You need a language core! (glue commands)

Scriptable Environment Send packet • Access radio • Find route • Check energy • Queue packet Abstracted high-level description of an algorithm Low-level tasks performed by our system

Make Scripts Mobile Script can populate/migrate Scripts move NOT due to explicit user instructions, but due to node’s state and algorithmic instructions Language + Run-time Environment = SensorWare

User can inject script Architecture Message exchanging Apps, Services Apps, Services Scripts Scripts Code migration SensorWare SensorWare OS OS HW abstraction layer HW abstraction layer Hardware Hardware Sensor node 1 Sensor node 2

SensorWare vs Mate • They share the same goal: make a WSN dynamically programmable in an efficient manner • Both are two-level abstraction • Both support code mobility Question: what are the similarities so far?

SensorWare vs Mate • Mate is for motes, e.g., 128KB PM, 4KB RAM; while SensorWare targets richer platforms like 1MB PM, 128K RAM • Mate is on TinyOS; SensorWare is on Linux • Mate is a stack-based architecture with ultra-compact instruction set; SensorWare builds scripts based on basic blocks • No concurrent apps in one mote; SensorWare supports multi-tasking • SensorWare’s scripts are more powerful than Mate’s capsules Question: what are the differences so far?

Language Extensions to the core The glue core The basic script interpreter (stripped-down Tcl) Radio API Timer API Sensor 1 API Mobility API waitcommand idcommand Sensor 2 API GPS API Optional modules  . . . . . .

Script Mobility API • spawn <node_list> <script> {variable_name}* • replicate < node_list > {variable_name}* • migrate < node_list > {variable_name}* < node_list > : destination node addresses variable_name : a variable name to be passed along with its value to the new script. An advantage over Mate: it supports both replicateand migrate There is a question Mate doesn’t answer: how the nodes cooperate in code population and how does this process end?

Replicate • First, the parent is assumed to already have the code for the script • Second, send out “intention to replicate” • Third, if the same script already exists, choose: • Not to transfer the code • Initiate a second script of the same type • “add-user” for this script if supporting multi-user • In addition, you need to explicitly specify the replication node list If you leave node list empty, what happens? Flooding? When does it ends?

Initialization Exit code Event handler a Event handler b Event handler a Event handler c Event-based Programming a? Zzz c? wait for event a or b or c code b? Example a? Zzz a? Zzz c? b?

Event-based Programming • Achieved through the wait command • Examples of events: • Reception of a message of a given format • Traversal of a threshold for a given sensing device reading • Filling of a buffer with sensing data of a given sampling rate • Expiration of several timers More events supported than Mate • Is it implemented by the OS or by SensorWare? • When an event handler is running, can the system respond to another event? • Should the system idle or can go on with the event handler running aside as another thread?

Run-time Environment: Tasks Resource Abstraction & Resource Metering Tasks Fixed tasks Platform specific Radio/Networking Timer service Script Manager (script state keeping, spawns new scripts) Sensor 1 Sensor 2 Admission Control & Policing of Resource Usage Paging radio . . .

Special Tasks • Script Manager • Accepts spawning requests • Forwards the request to the Admission Control • If pass, initiates a new thread/task running a script interpreter for the new script • Keeps script-related state info • Admission Control & Policing • Make sure that the scripts stay under their resource contract, and checks the overall energy consumption How the Admission Control is implemented is in another paper [4].

Resource Abstraction & Metering Tasks • Every platform is assumed to have at least one radio and a timer service • Radio • Accepts requests from the scripts about the format of network messages • Dispatches messages to appropriate scripts • Measure the radio utilization for each script • Timer • Provides many virtual timers relying on one timer provided by the system

Queue Run-Time Environment Resource metering info Device related permanent Script related Admission control Script Manager event interest in event Radio thread system msg. Radio Script 1 OS thread . . . Sensing Sensor HW access code Script n Timer Service

Portability and Expandability • Capabilities variability, i.e., having different modules, such as sensing devices, GPS • HW/SW variability, i.e., having different OS and/or specifics of hardware devices

Dealing with Capabilities Variability Define and support virtual devices • Almost everything in SensorWare is a device • Radio, Sensing(magnetometer, accelerometer) • Battery, Timer service • Localization procedure, neighborhood discovery • Devices are registered • Unified interface presented to the scripts • 4 commands: act,query, createEventID, disposeEventID

Dealing with HW/SW variability • Abstract Wrapper Functions • Find OS dependencies and abstract them • Definition and creation of threads • Support for non-polling message passing • Find hardware dependencies and abstract them • send/receive packets/bits • set a real timer • set the sampling rate of a sensor

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

Addressing • Generic format: • [nodes_specification.script_name.userID.appID] • For now, nodes_specification = node ID • Script_name: • Level_0_name.Level_1_name….Level_n_name • UserID • AppID • Denote the application that the particular instance of a script belongs to

Routing • Need to support multiple and new routing protocols at SensorWare compile time • To achieve this • Define routing protocols as devices • Define a special device that gives scripts the ability to handle system-kept routing table to support application-level routing

Code Example: multi-user aggregation The first command tries to replicatethe script to all the neighbors, declaring that this is a multi-userscript. The nodes that the script wasspawned or an “add user” messagewas sent are returned and addedto the need_reply_from variable. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

Code Example: multi-user aggregation The second command reads thecurrent value from the sensingdevice and sets the maxvaluevariable with it. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

Code Example: multi-user aggregation If there are no nodes to return areply the script sends the maxvalueto the parent and exits. Otherwise the parent node is addedto the list return_reply_to and the loop begins. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

Code Example: multi-user aggregation Each time a packet is received wecheck if it is a data reply or an “adduser” message and modify our listsand maxvalue accordingly. For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

Code Example: Porting to a platform • First, create a virtual device for the sensing device • Create_device(char* name, int (*query)(), int (*act)(), void* (*createEventID)(), int (*disposeEventID)(), void* (*task)()) • Second, define the OS-specific code to create threads and use mailboxes/queues

Implementation: Platform • iPAQ 3670 • Intel StrongARM 1110 rev 8 32bit at 206Mhz • 16Mbytes flash mem • 64Mbytes RAM mem • OS: v0.5 Linux StrongARM, kernel 2.4.18-rmk3 • Compiler: gcc • Radio: wavelan card • Sensing: Honeywell HMR-2300 Magnetometer

Implementation: Memory Size Linux + TinyTcl = 80%

Implementation: Delay measurement spawn(one hop) < spawn(local) + send (one hop) Lefttop: commands with less than 0.06 ms delay Righttop:most time consuming commands Leftbottom: delays of other special commands Overhead of real-time measurements: 0.25ms

Tradeoffs: native code vs. scripts 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 • 764 bytes the equivalent native code • Transmitting and Executing native code is not beneficial overall - Energy-related + How about the Linux and Tcl code?

Comparison (1)

Comparison (2)

Other 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

Conclusion • Is it truly a programming paradigm? Not really in terms of programming abstraction, just a scriptable environment. • Does it meet all the WSN constraints? It can’t support mote-like equipments • Does it implement programming an aggregate which is a changing set? Yes. It supports proactive programming and code population • Can it meet real-time, security, reliability requirements? Code safety is supported. Real-time can be supported in a roughly way. Reliability is an open issue.

Open Questions • How to define the scope of basic building blocks? (Efficiency vs Abstraction) • Is SensorWare appropriate for real-time applications? Security applications? • Is “general-purpose” programming paradigm really desirable?

SensorWare: A Framework for Efficient and Programmable Sensor Networks