1. Sensor Network Programming Ryo Sugihara ryo@ucsd.edu 2009/11/05 for CSE237B

2. Research Exam: Ryo Sugihara22006/06/22 About today’s talk I’ll talk about programming models for sensor networks –High-level overview –NOT about hands-on experience or development tips Based on the presentation for my research exam –in 2006 For more details, see –Ryo Sugihara and Rajesh K. Gupta, "Programming Models for Sensor Networks: A Survey" in ACM Transactions on Sensor Networks, vol.4, issue 2, Mar. 2008

3. Programming Models for Sensor Networks Ryo Sugihara Computer Science and Engineering UC San Diego ryo@ucsd.edu Research Exam: 2006/06/22

4. Research Exam: Ryo Sugihara42006/06/22 Network of tiny sensors with processing capabilities Emerging field with huge application area –Environmental monitoring –Structural monitoring –Target localization –... and more... but difficult to program –Embedded & distributed system –and moreover, Unreliable communication Faulty nodes Scarce energy Insufficient development environment... and more Wireless Sensor Networks (WSNs) Tmote Sky MSP430 microcontroller (16bit RISC, 8MHz, 10kB RAM, 48kB Flash) 250kbps radio, 1Mb ext storage Humidity, Temperature, and Light sensors

5. Research Exam: Ryo Sugihara52006/06/22 Programming Models “Programming models” –An abstraction of the target machine that a programmer uses to write applications Represented in programming languages / language extension Why are programming models important for WSNs? –Programmers need software support Too many things to care about: efficiency, unreliableness.. Appropriate PM can let programmers focus on application needs, rather than mechanisms to specify and implement them –New algorithms for sensor network applications Due to unique assumptions and requirements Appropriate PM can facilitate implementing them

6. Research Exam: Ryo Sugihara62006/06/22 In this talk, we... Analyze WSN applications –to figure out their requirements and implications to PMs Give a taxonomy of programming models for WSNs –No clear taxonomy before –Categorize them into three major types Evaluate each type of programming models –in terms of applications’ requirements Discuss future research directions

7. Research Exam: Ryo Sugihara72006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

8. Research Exam: Ryo Sugihara82006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

9. Research Exam: Ryo Sugihara92006/06/22 “Data Collection” Applications “Data collection” type –Collect data to the center –Users are interested in sensor data itself Great Duck Island (2002-) Habitat monitoring ZebraNet (2002-) Habitat monitoring GlacsWeb (2003-) Glacial movement Wisden (2004-) Structural Health Monitoring

10. Research Exam: Ryo Sugihara102006/06/22 “Collaborative Info. Processing” Applications “Collaborative information processing” type –Extract high-level info by processing data from multiple sensors i.e. “sensor fusion” –Users are more interested in processed data Data processing often happens inside the network PinPtr (2004-) Countersniper system Vehicle monitoring (2006) IDSQ (2001) Information-driven sensor querying VigilNet (2004-) Surveillance Trilateration proximity sensor target “Tracking” appl

11. Research Exam: Ryo Sugihara112006/06/22 Requirements from WSN applications Energy-efficiency –Nodes must run for months only with battery Failure-resilience –Appls should be functional even after failures (node, sensors, communication,..) Collaboration –Appls often need collaborative info. processing –Also applicable to data collection applications In-network aggregation / summarization /... and their implications to programming models PMs should be accompanied with compilers/tools that generate efficient code PMs should provide ways to control energy-performance trade-off PMs should provide ways to handle failures gracefully PMs should provide ways to describe collaboration easily

12. Research Exam: Ryo Sugihara122006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

13. Research Exam: Ryo Sugihara132006/06/22 Towards a taxonomy of PM for WSNs Motivation –A number of PMs have been proposed –Lack of comprehensive taxonomy Strategy: Classify PMs by “level of abstraction” –Three levels: “Node”, “Group”, and “Whole network” –Consider the highest level of abstraction Higher level abstractions are usually accompanied with lower level tools / runtime environments –Every program needs to be compiled into node-level code, after all Highest level of abstraction is the programming interface –that a PM exposes to programmers –thus it’s what matters for programmers

14. Research Exam: Ryo Sugihara142006/06/22 Taxonomy of PMs for WSNs Mate/ASVM VMStar Impala SensorWare SOS TML Abstract Regions Hood Directed Diffusion EnviroTrack Regiment Kairos Spatial Programming SpatialViews DRN Semantic Streams Cougar TinyDB SINA MiLAN DSWare TinyOS/nesC SNACK TinyGALS T2 OSM Liu et al. (State-centric) Three major approaches –Node-level programming –Group-level programming –“Macroprogramming”

15. Research Exam: Ryo Sugihara152006/06/22 Taxonomy of PMs for WSNs “Program a node” “Program a group” “Program the whole” Different viewpoint

16. Research Exam: Ryo Sugihara162006/06/22 1. Node-level Programming Node-level programming –Program each node’s behavior Assumption: Node efficiency is the top priority –Low overhead Maté/ASVM VMStar Impala SensorWare SOS TML TinyOS/nesC SNACK TinyGALS T2 OSM

17. Research Exam: Ryo Sugihara172006/06/22 1-1. Node-level Language Earliest and still prevalent approach Examples –Event-driven component-based programming nesC [Gay et al., 2003] / TinyOS [Hill et al., 2000] –Some enhancements on nesC / TinyOS Easier concurrency management –TinyGALS [Cheong et al., 2003] Reusable service library –SNACK [Greenstein et al., 2004], T2 [Levis et al., 2005] (TinyOS ver.2) Features +Flexible +Efficient –Complex Little support from programming models You can do anything as long as you are an excellent programmer

18. Research Exam: Ryo Sugihara182006/06/22 nesC (1/2) C-based language –Component-based programming –Event-based execution model Two types of components –“module” functional unit –“configuration” set of modules wired together [Gay, Levis, von Behren, Welsh, Brewer & Culler, 2003] StdControlTimer TimerM Clock module TimerM { provides { interface StdControl; interface Timer; } uses interface Clock; }... implementation {... command result_t StdControl.init() {... }... } Module definition interface StdControl { command result_t init(); } interface Timer { command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); } interface Clock {... configuration TimerC { provides { interface StdControl; interface Timer; } implementation { components TimerM, HWClock; StdControl = TimerM.StdControl; Timer = TimerM.Timer; TimerM.Clock -> HWClock.Clock; } StdControlTimer TimerM Clock HWClock Clock StdControlTimer TimerC Configuration definition

19. Research Exam: Ryo Sugihara192006/06/22 nesC (2/2) Advantages –Modular programming –Flexible boundary of HW/SW Same functionality can be implemented either on HW or SW –Compile-time analysis of concurrency Compiler can detect most potential race conditions Disadvantages –Complex Rigorously event-driven programming style “Split-phase operations” –No blocking operations: Request / Completion –e.g.) getData() → requestGetData(), eventDataAvailable(), –Lack of reusability Configurations are not parameterizable Module has parameters specific to application

20. Research Exam: Ryo Sugihara202006/06/22 SNACK (1/4) [Greenstein, Kohler, & Estrin, 2004] Sensor Network Application Construction Kit –Configuration language –Reusable service library –Compiler

21. Research Exam: Ryo Sugihara212006/06/22 SNACK (2/4) tree1, tree2 :: my RoutingTree(period < 20000); SenseLight(period [collect] tree1; SenseTemp(period [collect] tree2; “services” Combine parameterized “services” –Similar to nesC configuration –Ranged parameter to facilitate “service weaving” (later) Application programming in SNACK

22. Research Exam: Ryo Sugihara222006/06/22 SNACK (3/4) tree1, tree2 :: my RoutingTree(period < 20000); SenseLight(period [collect] tree1; SenseTemp(period [collect] tree2; service RoutingTree (period: max uint32_t $p = 5000) { dispatch :: my TreeDispatch16; nf :: my NullForwarder16; in [collect] -> dispatch -> [collect] out; dispatch [fromChild] -> nf; nf [toRoot] -> dispatch; dispatch [subtreeReady] -> nf; dispatch [lookup] -> TreeBuilder(period = $p); }; service TreeDispatch16(qsize: min uint8_t $q = 8){... };... Expansion into Components Generic services are provided by SNACK library Separation of “application programmers” and “service programmers”

23. Research Exam: Ryo Sugihara232006/06/22 SNACK (4/4) “Service weaving” –Merge compatible components Automatically by SNACK compiler –Reduce the size of code

24. Research Exam: Ryo Sugihara242006/06/22 1-2. Virtual Machines Idea: Run a virtual machine on each sensor node –Programs are described as intermediate code for VM Mainly for reprogrammability –Dissemminate and install code on-the-fly –Not possible in TinyOS only Examples –Application-specific VM Maté / ASVM [Levis et al., 2002, 2005], VMStar [Koshy & Pandey, 2005] –For richer platforms SensorWare [Boulis et al., 2003] –Update native code SOS [Han et al., 2005]

25. Research Exam: Ryo Sugihara252006/06/22 Maté / ASVM Application specific virtual machine –Expose new programming primitives by using application- specific opcodes Each VM supports only limited instruction set –Complete generality is not necessary for a given network Assumption: each sensor deployment is for a specific application Mainly for –Efficient dynamic reprogramming Smaller code size by reducing the size of instruction set –Safety –(Not for portability as in JVM) [Levis & Culler, 2002], [Levis, Gay & Culler, 2005]

26. Research Exam: Ryo Sugihara262006/06/22 Maté Build Process Appl-specific VM Compile code to custom instruction set Users select these three things From Philip Levis, "Rapid and Safe Programming of In-situ Sensor Networks“, Qualifying examination proposal, Jan 2004. Appl program in “tscript” etc.

27. Research Exam: Ryo Sugihara272006/06/22 Evaluation of Node-level PM Energy-efficiency Failure-resilience Collaboration –Exposed to programmers, with little support Everything is possible, but needs to be implemented by programmers Reusable service libraries (SNACK, T2) can be helpful VM-approach has a different goal –Reprogrammability

28. Research Exam: Ryo Sugihara282006/06/22 2. Group-level Programming Group-level programming –Define a group of nodes and program it Assumption: Need support for collaboration –Building block for applications / higher level abstractions Abstract Regions Hood EnviroTrack Liu et al. (State-centric)

29. Research Exam: Ryo Sugihara292006/06/22 2-1. Neighborhood-based group Locally-defined group –Consists of a node and its neighboring nodes Examples –Abstract Regions [Welsh & Mainland, 2004] Topological (N-hop neighbor) Geographical –Hood [Whitehouse et al., 2004] One-hop neighbor Good balance of efficiency and usefulness –Captures broadcasting nature of wireless communication –Intuitive definition, easy to use for programmers –Suitable for describing collaboration d topologicalgeographical

30. Research Exam: Ryo Sugihara302006/06/22 Abstract Regions Efficient communication primitives within group (= “region”) Region definition –Topological: N-hop –Geographical: within radius d, k-nearest neighbor –Others: planar mesh, spanning tree Provide interface for –Neighborhood discovery Create a region –Enumeration Get a set of nodes in the region –Data sharing Linda-like tuplespace interface: “Get” and “Put” –(key, value) tuple is put into shared tuplespace –Anyone who specifies the same key obtains the associated value –Reduction MPI-like reduction operations –Collect data to one node while applying some operations (avg, sum,...) [Welsh & Mainland, 2004]

31. Research Exam: Ryo Sugihara312006/06/22 ex.) Tracking appl. in Abstract Regions location = get_location(); /* Get 8 nearest neighbors */ region = k_nearest_region.create(8); while (true) { reading = get_sensor_reading(); /* Store local data as shared variables */ region.putvar(reading_key, reading); region.putvar(reg_x_key, reading * location.x); region.putvar(reg_y_key, reading * location.y); if (reading > threshold) { /* ID of the node with the max value */ max_id = region.reduce(OP_MAXID, reading_key); /* If I am the leader node... */ if (max_id == my_id) { /* Perform reductions and compute centroid */ sum = region.reduce(OP_SUM, reading_key); sum_x = region.reduce(OP_SUM, reg_x_key); sum_y = region.reduce(OP_SUM, reg_y_key); centroid.x = sum_x / sum; centroid.y = sum_y / sum; send_to_basestation(centroid); } sleep(periodic_delay); } No need for explicitly describing communication among sensor nodes within a region Create a region Put data as shared variables Choose leader node Compute centroid as an estimate of target location Read proximity sensor

32. Research Exam: Ryo Sugihara322006/06/22 2-2. Logical Group Defined according to high-level logical properties –Not only topological/geographical proximity –e.g.) sensor input Example –EnviroTrack [Abdelzaher et al., 2004] Data-centric group definition for tracking application –cf.) Node-centric group definition in Abstract Region / Hood Group of sensors that detected the same event Closer to application’s logic than system’s logic –Data-centric approach target “Group” target cf.) Abstract Regions

33. Research Exam: Ryo Sugihara332006/06/22 Evaluation of Group-level Programming Energy-efficiency –Mostly hidden Easy to achieve: broadcasting nature of wireless comm. Abstract Regions also exposes low-level control knobs Failure-resilience –Exposed, with support Node enumeration Collaboration –Exposed, with support Predefined mechanisms: data sharing, reduction Users can implement collaborative algorithms using them

34. Research Exam: Ryo Sugihara342006/06/22 3. Macroprogramming “Macroprogramming” –Program sensor network as a whole, regarding it as a single abstract machine Assumption: Focus on application-side requirements –DB: Ease-of-use –Macroprogramming Lang.: Expressiveness Regiment Kairos Spatial Programming SpatialViews DRN Cougar TinyDB SINA MiLAN DSWare Semantic Streams

35. Research Exam: Ryo Sugihara352006/06/22 3-1. Database Intuitive metaphor, earliest work in high-level PM Examples –SQL-based interface COUGAR [Bonnet et al., 2000] TinyDB [Madden et al., 2003, 2005] –plus imperative language for tasking SINA [Srisathapornphat et al., 2000] –Specialized in event detection DSWare [Li et al., 2003] –QoS feature MiLAN [Heinzelman et al., 2004] Features +Easy-to-use +Easy for the end-users (nontechnical people, non-CS researchers) –Narrow coverage of application Only for applications that query

36. Research Exam: Ryo Sugihara362006/06/22 TinyDB SQL-based interface –Supports selection, join, projection Supports in-network aggregation –SUM, AVG, MAX,... Supports continuous sampling –“SAMPLE PERIOD” clause –“LIFETIME” clause Specify the lifetime Estimate the lifetime and adjust sampling rate accordingly [Madden, Franklin, Hellerstein, & Hong, 2003] SELECT AVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold SAMPLE PERIOD 30s Monitor the occupancy of the conference rooms –on the 6-th floor of a building –by using microphone sensors Report all rooms where the average volume is over the threshold Deliver updates every 30 seconds

37. Research Exam: Ryo Sugihara372006/06/22 3-2. Macroprogramming Language Expressiveness in application’s context –Just like manipulating spatially distributed data points Focus & examples –Description of global behavior Regiment [Newton & Welsh, 2004] Kairos [Gummadi et al., 2005] –Resource naming Focus on space-awareness –Spatial Programming [Borcea et al., 2004] –SpatialViews [Ni et al., 2005] plus declarative predicates –DRN [Intanagonwiwat et al., 2005] Features +Broader coverage of applications than DB-approach –Require effort on compilers To produce efficient code

38. Research Exam: Ryo Sugihara382006/06/22 Regiment Purely functional macroprogramming language –No direct manipulation of program state –Benefit: Easier to extract parallelism Idea –Individual nodes are represented as data “streams” Change continuously over time –“Regions” are groupings of these streams Correspond to “continuous data from group of nodes” –Program operates over these streams and regions Translated into node-level actions Example: Tracking Object [Newton & Welsh, 2004][Newton, Morrisett, Welsh, 2007] A region is created that represents the value of the proximity sensor on every node in the network Each value is also annotated with the location of the corresponding sensor. Data items that fall below the threshold are filtered out from the region. The spatial centroid of the remaining collection of sensor values is computed to determine the approximate location of the object that generated the readings let aboveThresh (p,x) = p > threshold read node = (read_sensor PROXIMITY node, get_location node) in centroid (afilter aboveThresh (amap read world))

39. Research Exam: Ryo Sugihara392006/06/22 SpatialViews Space-aware programming language –Extension to Java –Programming = defining “SpatialViews” and “Spatial View Iterators” “SpatialView” –= Collection of “virtual nodes” indicated by services and locations –“Virtual nodes” = programming abstraction for a physical node Bound to a physical node within a “space x time” region Single physical node can be multiple virtual nodes in different space/time “Spatial View Iterator” –To discover/access virtual nodes in the SpatialView –Program is migrated to each node and executed [Ni, Kremer, Stere, & Iftode, 2005] spatialview sv1 = Camera @ CampusB % 100; visiteach x : sv1 { Picture p=x.getPicture();... } Spatial View Iterator SpatialView definition Rectangle CampusB = new Rectangle(...); public interface Camera { public Picture getPicture();... } Service definition Location definition Space granularity

40. Research Exam: Ryo Sugihara402006/06/22 Evaluation of Macroprogramming Energy-efficiency –DB: Hidden Achieved by query processor –Lang: Hidden Not easy to realize (by compilers) –Programmers can describe arbitrary collaborations (diff. from Group-level) Failure-resilience –DB: Hidden Query processor handles failure silently Users don’t have ways to add failure-resilience mechanism –Lang: Exposed, with support Iterator access, dynamic binding Programmers can describe how to handle failures Collaboration –DB: Hidden Query processor uses collaboration in execution plans –Lang: Exposed, with support Naming schemes provided Programmers can describe arbitrary collaborations

41. Research Exam: Ryo Sugihara412006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

42. Research Exam: Ryo Sugihara422006/06/22 Evaluation (Summary) In terms of the applications’ requirements –Efficiency –Failure-resilience –Collaboration Level of abstractionEfficiencyFailure-resilienceCollaboration Node-level Exposed with limited support Exposed with limited support Exposed with no support Group-level Mostly hidden Exposed with support Exposed with support Macro- programming DBHidden

43. Research Exam: Ryo Sugihara432006/06/22 Evaluation (per Application) Per each type of programming models Evaluate aptitude for each type of applications Level of abstraction Type of Applications ProCon Data Collection Collaborative Info. Proc. Node-level +- Most flexibleComplex Group-level +++ Better handling of collaboration Macro- programming ++ Suitable for general applications Hard to realize efficiency DB ++- Ease of use Narrow coverage of applications

44. Research Exam: Ryo Sugihara442006/06/22 Evaluation (per Application) Data Collection appl. +Database approach is most suitable and simple Provides easy-to-use interface +Others are OK, too Sufficient for simple data collection Level of abstraction Type of Applications ProCon Data Collection Collaborative Info. Proc. Node-level +- Most flexibleComplex Group-level +++ Better handling of collaboration Macro- programming ++ Suitable for general applications Hard to realize efficiency DB ++- Ease of use Narrow coverage of applications

45. Research Exam: Ryo Sugihara452006/06/22 Evaluation (per Application) Collaborative Information Processing appl. +Group-level abstraction is good Good balance of usefulness and efficiency +Macroprogramming lang is OK Can be problematic when efficiency requirement is tight –Node-level PM leads to complexity No support for communication –DB lacks flexibility to implement arbitrary collaboration algorithms Limited kinds of collaboration –e.g.) Aggregation Level of abstraction Type of Applications ProCon Data Collection Collaborative Info. Proc. Node-level +- Most flexibleComplex Group-level +++ Better handling of collaboration Macro- programming ++ Suitable for general applications Hard to realize efficiency DB ++- Ease of use Narrow coverage of applications ex.) Tracking appl. (based on centroid) –Node-level 369 lines in nesC [*] –Group-level 134 lines in Abstract Regions [*] –Macroprogramming 6 lines in Regiment [**] [*] [Welsh & Mainland, 2004] [**] [Newton & Welsh, 2004] Simpler Simpler, but with efficiency concern

46. Research Exam: Ryo Sugihara462006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

47. Research Exam: Ryo Sugihara472006/06/22 Future directions Heterogeneity Strict QoS support Support for multiple applications / users

48. Research Exam: Ryo Sugihara482006/06/22 Heterogeneity More and more heterogeneity Need PMs to exploit heterogeneity –Macroprogramming languages Resource naming scheme –cf.) Generic role assignment [Frank & Römer, 2005] Using declarative role specification language Separate role assignment and programming Multiple types of sensors Sensor-actuator networks Hierarchical architecture Logical heterogeneity HW SW

49. Research Exam: Ryo Sugihara492006/06/22 Generic Role Assignment Enables automatic assignment of –Special functions/roles to nodes in the network –Using programmer-specified rules for assignment In declarative specification language Partly address logical heterogeneity –No support for “programming” stage, currently [Frank & Römer, 2005] Coverage on off Clustering chslave gw Aggregation srcsink agg (Figures courtesy of C. Frank) CLUSTERHEAD :: { battery >= 60% && count(1 hop) { role == CLUSTERHEAD } == 0 } GATEWAY :: { chs == retrieve(1 hop, 2) { role == CLUSTERHEAD } && count(2 hops) { role == GATEWAY && chs == super.chs } == 0 } SLAVE :: else Role specifications No other clusterhead within 1-hop from clusterhead Two clusterheads within 1-hop from gateway

50. Research Exam: Ryo Sugihara502006/06/22 Strict QoS Support QoS is prevalent –Trade-off between energy-efficiency and various qualities such as Accuracy, Latency, Error rate etc. –... and energy is precious QoS is an integral element in WSN appls –Poor QoS can ruin the appls e.g.) Detect an earthquake and warn for Tsunami.......latency? PMs should support QoS –Abstract Regions: low-level control knobs Indirect, not in applications’ context: e.g.) #retransmission –MiLAN, DSWare: explicit QoS support Subjective and/or qualitative definition of QoS –Need for more objective, quantitative QoS support Controllable in each application’s context

51. Research Exam: Ryo Sugihara512006/06/22 cf.) Accuracy-aware Data Gathering Approximate data gathering with user-specified accuracy –Using planes and “explicit points” Fit planes to approximate the data “Explicit points” = Data points not approximated by planes Efficient –Distributed algorithm to construct the representation Exploits energy-efficiency trade-off –Smaller data size when accuracy requirement is loose Works as a general mechanism for strict QoS support –Not requiring any assumptions on statistical property of data Accuracy requirement Loose requirement 12 Planes 49 Explicit points Data size: 392.57 byte 4 Planes 13 Explicit points Data size: 119.82 byte (Sensor #: 155) Tight requirement Accuracy requirement Temperature (K) [Sugihara & Chien, 2005, 2006]

52. Research Exam: Ryo Sugihara522006/06/22 Multiple Applications / Users Increasing need for accommodating multiple applications / users simultaneously –Single sensor can provide multiple info e.g.) Breakbeam: detect vehicle, measure speed,... –Users’ interests can be diverse e.g.) Traffic count, control speeding,... by using same/overlapping set of sensors Implication to PM: Isolation vs. integration –Isolation for security –Integration for efficiency SNACK: “Service weaving” –SNACK compiler merges duplicate nesC components to reduce the size of compiled code But more dynamically cf.) Sensor-actuator networks –Multiple appls may issue contradicting requests to (shared) actuators e.g.) room temperature control: heat or cool –Appls may need to compromise to each other by relaxing the requirements –CAhoot [Lin, Gupta, 2009], Hotline [Lin et al., 2009] Programming support Appls can specify the actions in case there is a conflict with other appls

53. Research Exam: Ryo Sugihara532006/06/22 Outline Background Requirements from Applications Programming Models for Sensor Networks –Taxonomy –Approach 1: Node-level programming –Approach 2: Group-level programming –Approach 3: Macroprogramming Evaluation Future Research Directions Conclusion

54. Research Exam: Ryo Sugihara542006/06/22 Conclusion Analyzed WSN applications to figure out their requirements and implications to PMs –Energy-efficiency –Failure-resilience –Collaboration Built a taxonomy of PMs according to the level of abstraction –Node-level –Group-level –Macroprogramming Evaluated each type of PMs –in terms of the applications’ requirements Discussed future direction of research in PMs for WSNs

55. Research Exam: Ryo Sugihara552006/06/22 BACKUP

56. Research Exam: Ryo Sugihara562006/06/22 Directed Diffusion Communication among group of nodes that share interest –i.e. “Data-centric dissemination” –Sink (base-station) publishes “interests” –Source (sensor) publishes “event” –Propagation is facilitated when gradient is large Gradient is assigned to each edge Reinforcement-based adaptation –Successful paths are reinforced Realizes energy-efficient & robust dissemination [Intanagonwiwat, Govindan & Estrin, 2000]

57. Research Exam: Ryo Sugihara572006/06/22 Group-level PM vs. Macroprogramming Group-level PMMacroprogramming Local groupViewWhole network Bottom-up “Me and my neighbor” Def. of group Top-down (“Node A and its neighbor”) Macroprogramming may contain Group-level PM –e.g.) Kairos provides “get_neighbor()” operation

58. Research Exam: Ryo Sugihara582006/06/22 4. Tools Related to PM –Help development –Complementary to programming models Tools –Simulators TOSSIM [Levis et al., 2003] –Runs TinyOS code Avrora [Titzer et al., 2005] –Software environment Suite of library, tool, services –EmStar [Girod et al., 2004] Runtime debugging support –Sympathy [Ramanathan et al., 2005] »Diagnosis tool to localize the failure source at runtime –Marionette [Whitehouse et al., 2006] »Allow debugger access to node at runtime »Seamlessly span a program between PC and sensor node TOSSIM Avrora EmStar Marionette Sympathy

59. Research Exam: Ryo Sugihara592006/06/22 TinyOS Implemented by nesC Event-based programming model Set of components –Rather than monolithic OS –Abstract hardware –Layering of components: “Command” and “Event” Services provided such as: –RF messaging –Periodic timer events –Asynchronous access to UART data transfers –Mechanism for static, persistent storage [Hill, Szewczyk, Woo, Hollar, Culler & Pister, 2000]

60. Research Exam: Ryo Sugihara602006/06/22 OLD SLIDES

61. Research Exam: Ryo Sugihara612006/06/22 Programming Models “Programming models” –“An abstract conceptual view of the structure and operation of a computing system” (from “Getting Up To Speed: The Future Of Supercomputing”, National Academic Press, 2005) –Our interpretation: “Sophisticated view/method/framework that facilitates design and program WSN applications and underlying software” –Programming constructs, abstractions Represented in programming languages / language extension Why are programming models important for WSNs? –Programmers need software support Too many things to care about: efficiency, unreliableness.. Appropriate PM can let programmers focus on application logic –Many new algorithms for sensor network applications Due to unique assumptions and requirements Appropriate PM can facilitate implementing them

62. Research Exam: Ryo Sugihara622006/06/22 Requirements from WSN applications Energy-efficiency –Nodes must run for months only with battery Failure-resilience –Appls should be functional even after failures (node, sensors, communication,..) Collaboration –Appls often need collaborative info. processing –“Localized algorithms” [Estrin et al., 1999] preferred = Info. processing inside the network Also applicable to data collection applications –In-network aggregation / summarization /... and their implications to programming models PMs should be accompanied with compilers/tools that generate efficient code PMs should provide ways to control energy-efficiency PMs should provide ways to handle failures gracefully PMs should provide ways to describe localized algorithms easily

63. Research Exam: Ryo Sugihara632006/06/22 Taxonomy of PMs for WSNs Mate/ASVM VMStar Impala SensorWare SOS TML Abstract Regions Hood Directed Diffusion EnviroTrack Regiment Kairos Spatial Programming SpatialViews DRN Semantic Streams Cougar TinyDB SINA MiLAN DSWare TinyOS/nesC SNACK TinyGALS T2 OSM Liu et al. (State-centric) TOSSIM Avrora EmStar Marionette Sympathy Three major approaches –Node-level programming model –Group-level abstraction –Macroprogramming

64. Research Exam: Ryo Sugihara642006/06/22 1-1. OS / Node-level Language Earliest and still prevalent approach Event-driven component-based programming –nesC [Gay et al., 2003] / TinyOS [Hill et al., 2000] de facto standard –Some enhancements on nesC / TinyOS Easier concurrency management –TinyGALS [Cheong et al., 2003] Reusable service library –SNACK [Greenstein et al., 2004], T2 [Levis et al., 2005] (TinyOS ver.2) State machine –OSM (Object State Model) [Kasten & Römer, 2005] Different action for a single event according to the current state

65. Research Exam: Ryo Sugihara652006/06/22 Summary of Node-level PM OS / Node-level programming languages +Flexible +Low overhead –Complex Not for end-users –nontechnical people –non-CS researchers Virtual Machines +Reprogrammable on runtime –Performance issue interpreter-based

66. Research Exam: Ryo Sugihara662006/06/22 2-2. Logical Group Defined according to high-level logical properties –Not only topological/geographical proximity –e.g.) interests of node, sensor input Examples –Directed Diffusion [Intanagonwiwat et al., 2000] Data-centric dissemination mechanism Communication within a group of nodes that share interests –EnviroTrack [Abdelzaher et al., 2004] Data-centric group definition for tracking application –cf.) Node-centric group definition in Abstract Region / Hood Group of sensors that detected the same event Closer to application’s logic than system’s logic –Data-centric approach target “Group” target cf.) Abstract Regions

67. Research Exam: Ryo Sugihara672006/06/22 Summary of Group-level abstraction Neighborhood-based group +Suitable for implementing “localized algorithms” +Good balance of efficiency & usefulness Logical group +Closer to application logic

68. Research Exam: Ryo Sugihara682006/06/22 Summary of Macroprogramming Database +Intuitive, easy-to-use –Limited coverage of applications Applicable to the appls that query Not expressive enough to describe collaboration Macroprogramming language +Broader coverage of applications –More burden on compiler Especially problematic when efficiency requirement is tight

69. Research Exam: Ryo Sugihara692006/06/22 Energy-efficiency Node-level –Mostly exposed, with limited support Implementation totally left to programmers –Some support efficient code generation SNACK: service weaving VMStar: incremental linking Group-level, macroprogramming –Mostly hidden Achieved by runtime environments –Some explicitly allow fine-grained tunings Abstract Regions: low-level control knobs (e.g. #retransmission, timeout, etc.) BBQ [Deshpande et al., 2004] : tolerable errors and confidence in SQL query Level of abstractionEfficiencyFailure-resilienceCollaboration Node-level Exposed with limited support Exposed with limited support Exposed with no support Group-level Mostly hidden Exposed with support Exposed with support Macro- programming DBHidden

70. Research Exam: Ryo Sugihara702006/06/22 Failure-resilience Node-level –Exposed, with limited support Implementation totally left to programmers –Node failures are difficult to handle Group-level, macroprogramming (except DB) –Exposed, with support Abstract Regions, Hood: caching other nodes’ data SpatialViews, DRN: iterator access to nodes Database –Hidden MiLAN, DSWare: incorporate failures into quality calculation Level of abstractionEfficiencyFailure-resilienceCollaboration Node-level Exposed with limited support Exposed with limited support Exposed with no support Group-level Mostly hidden Exposed with support Exposed with support Macro- programming DBHidden

71. Research Exam: Ryo Sugihara712006/06/22 Collaboration Node-level –Exposed, with no support Usually difficult to implement Group-level, macroprogramming (except DB) –Exposed, with support Abstract Regions: data sharing, reduction Database –Hidden Declarative queries only Query processors devise collaborative execution plans Level of abstractionEfficiencyFailure-resilienceCollaboration Node-level Exposed with limited support Exposed with limited support Exposed with no support Group-level Mostly hidden Exposed with support Exposed with support Macro- programming DBHidden

72. Research Exam: Ryo Sugihara722006/06/22 Future directions Applications’ viewpoint –Heterogeneity –Interactiveness –Strict QoS support Systems’ viewpoint –Support for multiple applications / users –Ubiquitous deployment Software engineering viewpoint –“Refinement”

73. Research Exam: Ryo Sugihara732006/06/22 Interactiveness More dynamic interaction needed –Collect preliminary data and later modify sensor behavior –Closer look of interesting phenomena –Unexpected events requiring human decision Need two things for interactiveness –Low-latency communication –Reprogrammability VM-based approach PMs should provide a way to specify the requirements for latency and other constraints

74. Research Exam: Ryo Sugihara742006/06/22 Ubiquitous deployment Sensors are installed in advance –For more general use on-demand Shared infrastructure –Not for specific application Need –Resource allocation scheme Resource request –Resource specification Naming scheme Implications to PMs –Reprogrammability –Declarative approach Automatically figure out necessary set of resources according to the application’s objective

75. Research Exam: Ryo Sugihara752006/06/22 “Refinement” For iterative development Repeat –Prototyping –Refine the logic and parameters Need PMs to allow refinement –OSM Hierarchical composing of state machine –SNACK, T2 Reusable services for rapid prototyping –VM-based approach Reprogrammability VMStar: incremental linking