Wsn Programming

Programming WSNs: from Theory to Practice Luca Mottola (luca@sics.se) University of Trento, Italy Swedish Institute of Computer Science (SICS), Sweden Gian Pietro Picco (picco@dit.unitn.it) University of Trento, Italy Tutorial at the 6th European Conference on Wireless Sensor Networks (EWSN) Cork, Ireland – February 11th, 2009

Computing on the Internet Interaction between people and human-mediated data sources (e.g., people, Web services) #nodes ≈ #users The network enables Nodes are communication among resource-rich geographically distributed nodes Focus: human-centered interactive decision making Programming WSNs: From Theory to Practice 2 © 2008-2009 Luca Mottola and Gian Pietro Picco

An “Internet of Things” Interaction between people and #nodes >> #users the instrumented world (e.g., sensors, actuators) The network computes answers by fusing real-time Nodes are information from distributed resource-scarce nodes Focus: support human-supervised autonomous decision making Programming WSNs: From Theory to Practice 3 © 2008-2009 Luca Mottola and Gian Pietro Picco

Wireless Sensor Networks  Enabled by miniaturization of processing, communication, sensing and actuating devices  Distinctive feature: self-organizing topology with multi-hop communication  transmit power ≈ distance2  many cheap devices with short- range communication  more coverage with less energy (and no wires!) Programming WSNs: From Theory to Practice 4 © 2008-2009 Luca Mottola and Gian Pietro Picco

Example: Redwood Microclimate (adapted from D. Culler)  70% of H2O cycle is through trees, not ground  Can only observe top surface of the forest  Need to understand what happens within the trees Light, temperature, pressure, humidity sensors Programming WSNs: From Theory to Practice 6 © 2008-2009 Luca Mottola and Gian Pietro Picco

Example: TelosB/TMote Sky  TI MSP 430 (16 bit RISC)  8 MHz  10 KB RAM  48 KB code, 1MB flash  Chipcon CC2420 radio  IEEE 802.15.4 compliant  50 m. range indoor, 250 m. range outdoor  bandwidth 250 kbits/s  On-board antenna  Temperature, light, and humidity sensors built-in Programming WSNs: From Theory to Practice 9 © 2008-2009 Luca Mottola and Gian Pietro Picco

Some Mote Platforms CrossBow MoteIV Intel iMote2 Sun SPOT MICA2 TMote Sky CPU and clock ATmega128L TI MSP 430 Intel PXA271 ARM 920T 16 MHz 8 MHz 416 MHz 180 MHz Memory 4 KB, 128 KB, 10 KB, 48 KB, 256 KB, 32 MB, 512 KB (RAM, code, flash) 512 KB 1 MB 32 MB (data+code), 4 MB Radio chip Chipcon 1000 Chipcon 2420 Chipcon 2420 Chipcon 2420 Power 2 AA 2 AA 3 AAA 3.7V rechargeable Language C-based C-based C-based Java2ME Programming WSNs: From Theory to Practice 10 © 2008-2009 Luca Mottola and Gian Pietro Picco

WSNs: Challenges  Power consumption  devices are battery-powered, meant to operate unmanned for a long period of time  communication is typically the biggest energy drain  duty cycle is critical: nodes “sleep” for most of the time  communication ~mA, stand-by ~µA  TMote mote always on: ~8 days; 2% duty cycle (1.2s/min): 9 months  Reliability  wireless link quality fluctuates based on environment:  topology changes as the WSN operates!  nodes are often deployed in a “hostile” environment and may fail  the application/network must self-organize! Programming WSNs: From Theory to Practice 11 © 2008-2009 Luca Mottola and Gian Pietro Picco

The Woes of Wireless …  Non-isotropic range, asymmetric links  Collisions, hidden terminal problem  Link quality easily affected by environmental parameters  e.g., temperature, humidity, presence of people  “What-you-see-is-not-what-you-get” topologies  e.g., good connection to far nodes and bad to close ones Programming WSNs: From Theory to Practice 12 © 2008-2009 Luca Mottola and Gian Pietro Picco

The Main Challenge: Programming  According to market research firm ONWorld, the global market for WSNs will grow tenfold by 2011, however …  … they also identify ease of programming as the current hampering factor—and major technology enabler  Today, WSN programming is mostly done in ad-hoc fashion and directly at the OS level  the largest coding effort is devoted to communication and routing  requires specialized skills, beyond programming  distracts programmers from the application goal at hand  greatly hampers reuse: “porting” an application often requires substantial (if not complete) rewriting  Fundamental problem: the level of abstraction is too low Programming WSNs: From Theory to Practice 13 © 2008-2009 Luca Mottola and Gian Pietro Picco

Why This Tutorial?  The community is recognizing the lack of proper abstractions  many different approaches, no clear winner  Goals:  present a structured, concise state-of-the-art survey  get in contact with WSN technology  useful to researchers, early adopters, and practitioners  Outline:  WSN applications  Reference architecture  Programming approaches  Discussion and research directions Programming WSNs: From Theory to Practice 14 © 2008-2009 Luca Mottola and Gian Pietro Picco

Applications  Examples:  Wildlife monitoring  Glacier monitoring  Cattle herding  Ocean monitoring  Vineyard monitoring  Cold chain monitoring  Rescue of avalanche victims  Vital sign monitoring  Tracking vehicles  Sniper localization  Volcano monitoring  Tunnel monitoring and rescue Programming WSNs: From Theory to Practice 15 © 2008-2009 Luca Mottola and Gian Pietro Picco

Sense-Only vs. Sense-and-React  Early WSN applications were sense-only  nodes equipped only with sensors  main purpose: data collection  WSN are increasingly employed to “close the control loop”  sensed data is used to react to external stimuli and affect the behavior of the system at hand  reporting to a central manager is ineffective in terms of latency and resilience to faults  Wireless Sensor and Actuator Networks (WSANs)  the loop is closed in a decentralized fashion, by using wireless actuators and localized sensing Programming WSNs: From Theory to Practice 17 © 2008-2009 Luca Mottola and Gian Pietro Picco

Interaction Pattern  Today’s mainstream distributed computing is dominated by one-to-one interactions  e.g., client-server, based on unicast communication  Sensing involves many-to-one interactions  many sensing sources funnel data to a single sink  Control involves one-to-many interactions  e.g., to query for specific information, change sensing parameters, or operate a set of actuators  Many-to-many interactions are becoming common  especially in sense-and-react applications: multiple actuators gather data from overlapping sets of sensors Programming WSNs: From Theory to Practice 19 © 2008-2009 Luca Mottola and Gian Pietro Picco

Mobility  The WSN topology changes according to connectivity and sleeping patterns  In some applications there is greater dynamicity due to mobile components  Static: nodes and sink do not move once deployed  Mobile nodes: nodes attached to mobile entities (e.g., animals or robots) or able to move autonomously (e.g., XYZ nodes)  Mobile sinks: nodes are static, but the sink is mobile  data collection is performed opportunistically when the sink moves in proximity of the sensors Programming WSNs: From Theory to Practice 20 © 2008-2009 Luca Mottola and Gian Pietro Picco

Space and Time  The place where and time when processing occurs are fundamental issues  Space:  Global applications are concerned with data gathered throughout the entire area where the WSN is deployed  Local applications are concerned with a limited portion of the system  Time:  Periodic applications go through a sensing and processing cycle at regular intervals  Event-driven applications perform processing only when some environmental condition is met (e.g., a reading over threshold) Programming WSNs: From Theory to Practice 21 © 2008-2009 Luca Mottola and Gian Pietro Picco

In Practice, However …  Each component is often built separately  The programmer is forced to deal with low-level details instead of the application logic Programming WSNs: From Theory to Practice 24 © 2008-2009 Luca Mottola and Gian Pietro Picco

Operating Systems  OSs for WSNs different from mainstream ones  basic run-time support for application programs  no support for user interaction  Programs are cross-compiled and linked with the OS library: the resulting binary is deployed on the WSN node  TinyOS, Contiki, Mantis  Main differences: model of concurrency, support for dynamic linking Programming WSNs: From Theory to Practice 25 © 2008-2009 Luca Mottola and Gian Pietro Picco

nesC/TinyOS Overview  nesC provides the programming abstractions  component based programming  TinyOS (TOS) manages scheduling and interactions with the hardware  Split-phase execution  commands are executed, return value is returned asynchronously through an event  Tasks provide the unit of concurrency  typically spawned by events  can be pre-empted by another event Programming WSNs: From Theory to Practice 26 © 2008-2009 Luca Mottola and Gian Pietro Picco

Uses Send nesC/TinyOS Component Model sendDone() sendMsg(msg Signals Calls  Components encapsulate ) state and processing  use or provide interfaces  Interfaces list commands and events Provides Send  Configurations wire components together Function Commands Events calls Implement Using Call Command Event Handler Implement Providing Signal Event 27 Command Body

nesC/TinyOS Active Messages (AM)  1- hop communication  default no buffering, no reliability, no duty-cycling  AM ids are used to multiplex the radio across different components  analogous to UDP/TCP ports Ask the radio to send a message interface AMSend { command error_t send(am_addr_t addr,message_t* msg,uint8_t len); event void sendDone(message_t* msg,error_t error); // … Signal the } transmission completed Signal a interface Receive { message event message_t* receive(message_t* msg, receipt void* payload, uint8_t len); // … Programming WSNs: From Theory to Practice 28 © 2008 Luca Mottola and Gian Pietro Picco }

nesC/TinyOS Sensing Example  A tiny sensing application  one node senses humidity at every second  the other node turns red if humidity is above 50%, or green otherwise Programming WSNs: From Theory to Practice 30 © 2008-2009 Luca Mottola and Gian Pietro Picco

Soft vs. Hard State Traffic/Energy Accuracy Soft state   Hard    Soft-state solution state  the sensing node sends an “alert” message only when humidity > 50%  the other node turns red when receiving the message and sets a timeout to return to green  Hard-state solution  the sensing node sends periodic messages with the current humidity reading  the other node decides whether to turn red or green depending on the last message received Programming WSNs: From Theory to Practice 31 © 2008-2009 Luca Mottola and Gian Pietro Picco

Medium Access Control (MAC)  Only goals: avoid packet collisions and turn off the radio whenever possible [3]  Much simpler than conventional MACs  some features are demanded to application code CSMA  CSMA (Carrier Sense) with preamble sampling and TDMA (Time Division) are dominant  CSMA good for changing topologies, may suffer under heavy load  TDMA guarantees predictable performance, needs time synch CSMA TDMA Programming WSNs: From Theory to Practice 32 © 2008 Luca Mottola and Gian Pietro Picco

IEEE 802.15.4 and WSNs  IEEE 802.15.4 defines a CSMA MAC for Wireless Personal Area Networks (WPAN)  targets ultra-low cost, low-power radios  Supports two topologies, but all devices must be in range of the PAN coordinator (impractical in WSNs)  WSNs use 802.15.4-enabled radios and packet format without the actual MAC atop  which is instead provided as a software component  IEEE 802.15.4 ≠ ZigBee Programming WSNs: From Theory to Practice 33 © 2008-2009 Luca Mottola and Gian Pietro Picco

Why MAC is Important? “I do distributed programming, and I never cared about MAC… why should I care in WSNs?” Programming WSNs: From Theory to Practice 34 © 2008-2009 Luca Mottola and Gian Pietro Picco

Routing sink sink  Programming abstractions are worthless if not supported by an efficient routing  concern: energy consumption, i.e., use of the radio  WSN routing is intrinsically different: source source  conventional protocols based on addresses identifying the communication target (e.g., unicast or multicast IP addresses)  in a WSN nodes are rarely relevant per se: it is their (individual or collective) features that matter  many-to-one, one-to-many and many-to-many vs. one-to-one  Typically, “attribute-based” routing is used  message forwarding based on the nature of data  similar to content-based routing Programming WSNs: From Theory to Practice 35 © 2008-2009 Luca Mottola and Gian Pietro Picco

Time Synchronization  Often necessary to correlate the data to the time it was sampled  e.g., structural monitoring, earthquake detection  Nodes have different times  differences in clock quartzes and in their drifts  well-known problem in distributed systems (NTP): peculiarity here is wireless and energy-awareness  Several protocols available [4]  precision down to milliseconds  require periodic network-wide message exchanges Programming WSNs: From Theory to Practice 36 © 2008-2009 Luca Mottola and Gian Pietro Picco

Node Localization  It is often necessary to know the physical location of a node [5]  interpret sensed data, determine span of actuation  often determined at deployment time and known to both nodes and gateway  What if location is not known?  assume nodes are GPS-equipped  easy and precise but energy hungry  use radio-based localization  e.g., based on RSSI Programming WSNs: From Theory to Practice 37 © 2008-2009 Luca Mottola and Gian Pietro Picco

Reprogramming  WSN applications need maintenance  like any other software, but nodes cannot be reprogrammed individually, due to accessibility and system scale  The radio link can be used for reprogramming the network [31]  requirements: low-overhead, fast propagation, reliability, scalability  data dissemination protocols for WSN target smaller objects and different requirements: dedicated protocols are needed  Virtual machines for WSNs simplify reprogramming  compact bytecode, programs are tiny  but they complicate programming  example: Maté Programming WSNs: From Theory to Practice 38 © 2008-2009 Luca Mottola and Gian Pietro Picco

What’s the Right Abstraction Level?  WSN inherently foster cross-layer interactions  need to optimize resources  general-purpose layers are less important: the entire stack is deployed to support a single application  very different from mainstream distributed systems  Strong tension between the desire to shield the programmer from complexity and the need to enable cross-layer design Programming WSNs: From Theory to Practice 39 © 2008-2009 Luca Mottola and Gian Pietro Picco

Two Extremes  Common classification:  node-centric  code describes behavior of individual nodes  e.g., nesC  macro-programming  code describes behavior of the system as a whole  e.g., TinyDB  Captures only one of many relevant dimensions Programming WSNs: From Theory to Practice 40 © 2008-2009 Luca Mottola and Gian Pietro Picco

Communication Scope  The span of communication, from the point of view of the programmer  Physical neighborhood: directly mapped on the radio range  Multi-hop group: abstracts multiple nodes across multiple hops  Connected: any two nodes in the group Multi-hop must be connected via nodes that are Connected Group also part of the group  Non-connected: no assumptions on node positions  System-wide: all nodes involved Multi-hop Non-connected Group Programming WSNs: From Theory to Practice 42 © 2008-2009 Luca Mottola and Gian Pietro Picco

Physical Neighborhood: TeenyLIME  Tuple spaces proposed in the 80s (Linda) for parallel computation, later adapted (Lime) for mobile computing  In TeenyLIME, each node hosts a tuple space shared with the nodes within communication range  nodes can write, query the tuple space and react to tuple insertion out(t) in(p) rd(p) tuple space < Italy, Milano > < Belgium, Leuven> < Italy, Trento> Programming WSNs: From Theory to Practice 43 © 2008-2009 Luca Mottola and Gian Pietro Picco

TeenyLIME Features  Reactions allow for asynchronous notifications  useful for sense-and-react and event-driven applications  Capability tuples enable on-demand sensing  which spares the battery Programming WSNs: From Theory to Practice 44 © 2008-2009 Luca Mottola and Gian Pietro Picco

Software TeenyLime – Why Abstractions are Useful… bool pendingMsg; TOS_Msg sendMsg; Maintains an array of current interests event TOS_MsgPtr ReceiveInterestMsg.receive(TOS_MsgPtr m) { struct InterestMsg* payload = (struct InterestMsg*) m->data; if (isRecipient(payload, TOS_LOCAL_ADDRESS)) insertInterest(payload->sender, payload->type, payload->threshold, payload->timestamp); return m; } event result_t TemperatureSensor.dataReady(uint16_t reading){ Sends a message if at if (!pendingMsg && matchesInterest(reading)) { atomic { least one interest pendingMsg = TRUE; matches struct DataMsg* payload = (struct DataMsg*) sendMsg->data; msg->sender = TOS_LOCAL_ADDRESS; msg->type = TEMPERATURE_READING; Just outputs=areading; registered msg->value tuple, all reactions will be triggered if (call SendDataMsg.send(TOS_BCAST_ADDR,sizeof(struct AppMsg),&sendMsg)!= SUCCESS) pendingMsg = FALSE; } } return SUCCESS; Data filtering and addressing } performed in the application code event result_t TemperatureSensor.dataReady(uint16_t reading){ tuple<uint16_t, uint16_t> temperatureValue = newTuple( event result_t SendDataMsg.sendDone(TOS_MsgPtr msg, result_t success) { if (msg == sendMsg) actualField(TEMPERATURE_READING), pendingMsg = FALSE; actualField(reading)); return SUCCESS; call TupleSpace.out(FALSE,TL_LOCAL,&temperatureValue); } Programming Wireless Sensor Networks return SUCCESS; 45 } © 2008 Luca Mottola and Gian Pietro Picco

TeenyLIME Deployment  Torre Aquila, Castello del Buonconsiglio, Trento, Italy  contains a world-renowned fresco from 13th century  Sensors measure:  temperature, humidity  deformation (fiber optic)  acceleration  Collection, dissemination, time synchronization, tasking all atop TeenyLIME  99.995% of sensed data delivered  Running with 2 size C batteries since late August Programming WSNs: From Theory to Practice © 46 2008 Luca Mottola and Gian Pietro Picco

Multi-hop Connected: EnviroSuite  Mainly designed for object tracking  objects are physical phenomena  An OO language is used for:  conditions to create objects  operations to process the corresponding data  Supported by a dedicated environment (compiler and runtime support) targeting nesC 47

EnviroSuite Object Conditions and Management  An object condition is evaluated on each node  creates an object in each connected region (the object context) where the condition holds  object_condition = ferrous_object() && vehicle_sound()  Three kinds of objects exist:  event objects: for “mobile” phenomena  region objects: for phenomena in static/slowly moving areas  function objects: not mapped to an environmental element  An object maintenance protocol is defined for each one  how/when to form the object context, with what protocols, where to run the object code, how to compute object attributes  the compiler determines the object management strategy Programming WSNs: From Theory to Practice 48 © 2008-2009 Luca Mottola and Gian Pietro Picco

Multi-hop Non-connected: Abstract Regions  Abstract region: a set of nodes with a given property  examples: k-neighbors, planar graphs, spanning trees  a tuple space-like interface (put, get) to access the data provided by nodes in a region  Simplifies application programming, decouples concerns, fosters reusability  However:  the semantics determining which nodes belong to the abstract region must be hard-coded  more of a framework than a complete system  A tuning interface is also offered  enables tweaking of low-level parameters Programming WSNs: From Theory to Practice 49 49 © 2008-2009 Luca Mottola and Gian Pietro Picco

Abstract Regions Example: Object Tracking location = get_location(); Setup a region region = k_nearest_region.create(8); containing while (true) { the 8 nearest neighbors reading = get_sensor_reading(); Share sensed and region.putvar(reading_key, reading); processed data with region region.putvar(reg_x_key, reading * location.x); members region.putvar(reg_y_key, reading * location.y); if (reading > threshold) { max_id = region.reduce(OP_MAXID, reading_key); if (max_id == my_id) { 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); } Compute aggregates over } the region using reduce 50

System-wide: TinyDB  Declarative SQL-like interface  Avoid writing low-level C code  Limit programmers to handle only natively supported data types  extensions are possible, but the TinyDB code is quite complex  Can output data to standard DBMS, e.g., PostgreSQL Programming WSNs: From Theory to Practice 51 © 2008-2009 Luca Mottola and Gian Pietro Picco

TinyDB SELECT select-list [FROM table_name] WHERE where-clause Query Language [GROUP BY gb-list [HAVING having-list]] [TRIGGER ACTION command[(param)]]  Data stored in a sensors table [EPOCH DURATION integer]  SELECT, FROM, GROUP BY, HAVING are like in SQL  FROM can only list the sensors table  TRIGGER specifies the name of a nesC function to execute when some result is produced  the function implementation is left to the programmer, linking it to the TinyDB engine on motes is not trivial  EPOCH specifies the data rate  Not supported: nested queries, column renaming with AS, JOIN operator, OR and NOT operators, FROM with multiple tables, arithmetic expressions different from column-op-constant Programming WSNs: From Theory to Practice 52 © 2008-2009 Luca Mottola and Gian Pietro Picco

Addressing and Communication Awareness  Addressing dictates how the relevant nodes are identified  physical addressing uses (mostly) static ids  logical addressing identifies nodes based on application-level characteristics  e.g., all temperature sensors reading above 50° C  Communication can be explicit or implicit  explicit communication requires programmers to deal with scheduling, serialization, …  implicit communication hides these aspects under higher-level abstractions  Cougar, Abstract Regions, TeenyLIME Programming WSNs: From Theory to Practice 53 © 2008-2009 Luca Mottola and Gian Pietro Picco

Logical Addressing: Logical Neighborhoods  Replaces the physical neighborhood with a logical one  developers decide what part of the system a node is to address  Specified declaratively using the Spidey language  extension of existing WSN programming languages (e.g., nesC)  Simple broadcast-based communication API Programming WSNs: From Theory to Practice 54 © 2008-2009 Luca Mottola and Gian Pietro Picco

Logical Neighborhoods Nodes node template Sensor  (Logical) nodes are the static Function static Type application level static Location representation of a physical dynamic Reading dynamic BatteryPower device  a node template defines a Data node’s exported attributes Source  a logical node is instantiated from a node template by specifying the actual create node vs from Sensor Function as “sensor” source of data Type as “vibration” Location as “office1” Reading as getAccel() BatteryPower as getBattery() Programming WSNs: From Theory to Practice 55 © 2008-2009 Luca Mottola and Gian Pietro Picco

Logical Neighborhoods Neighborhoods “I want to address all vibration sensor in a given location…”  A (logical) neighborhood template neighborhood is the VibrationSens[ f ] with Function = “sensor” and set of nodes satisfying Type = “vibration” and Floor = f a predicate  encoded in a Data Scope neighborhood template  instantiation specifies where to evaluate the create neighborhood vb_my_location from VibrationSens[ f: “Floor1” ] predicate max hops 2 “…lying at a maximum distance of two hops”. 56

Logical Neighborhoods API The logical neighborhood id replaces the AM interface LNSend { address command error_t send(ln_id_t target_ln, void* data, uint8_t len, uint8_t credits); command error_t sendReply(uint16_t dest, void* msg, uint8_t len); // … rest as in AMSend }  Credits are an application- create node vs from Sensor defined measure of use cost 1/getBatteryPower() //… communication cost  Each node declares its own use cost in credits  Credits needed to send a message are evaluated as the sum of the use costs of each node involved in routing Give developers a “knob” to explore the trade-off between accuracy and resource consumption Programming WSNs: From Theory to Practice 57 © 2008-2009 Luca Mottola and Gian Pietro Picco

Logical Neighborhoods Example  Send a command to toggle blue to nodes sensing humidity above 50% neighborhood template Tutorial1[] with Type = "Humidity" and create node sn from Reading > 50 Sensor create neighborhood tut_ln1 use cost 1 from Tutorial1[] Type = “Humidity” 58 max hops 10 Reading as call …

Computation Scope  Defined by the span of influence of language constructs  The interplay of communication and computation is important in WSNs  e.g., energy savings enabled by local aggregation Programming WSNs: From Theory to Practice 59 © 2008-2009 Luca Mottola and Gian Pietro Picco

Group Computation: Regiment  Functional language, provides operations for:  processing of signals … Signals  readings, computation outputs, Region or aggregates of signals  … over regions  sets of nodes generating spatially correlated signals  The runtime provides core support to the primitives  e.g., spanning trees for disseminating queries and gathering results  The compiler takes care of converting the program into “deglobalized” code, to be deployed on the individual nodes smap :: (αβ), Signal(α) Signal(β) rmap :: (αβ), Region(α) Region(β) rfilter :: (αbool), Region(α) Region(α) rfold :: (α,ββ), β, Region(α) Signal(β) khood:: Int, Node Region(()) Programming WSNs: From Theory to Practice 60 © 2008-2009 Luca Mottola and Gian Pietro Picco

Regiment Example: Plume Monitoring  Goal: detect a plume in a large area  To minimize false positives:  a node reports its measurement only if above threshold  sum of all “high” readings reported only if above threshold fun abovethresh(t) {t > CHEM_THRESHOLD} Aggregates all fun read(n) {sense (“conc”, n)} values in region fun sum(r) {rfold((+), 0, r)} r detects = rfilter(abovethresh, rmap(read, world)); hoods = rmap(fun(t,nd){khood(1,nd)}, detects); sums = rmap(sum, hoods); rfilter(fun(t){t > CLUSTER_THRESH}, sums) BASE Filters the outliers Expands the Computes the sum region by 1 hop Filters the outliers over 61 each of these regions

Programming Idiom  Imperative approaches are most common  sequential (e.g., Pleiades) vs. event-driven (e.g., nesC) semantics  Declarative approaches are compact, often applicable only in specific application domains  database (e.g., Cougar) vs. rule-based (e.g., FACTS)  Functional approaches are very concise  e.g., Regiment, snBench  Hybrid approaches also exist  e.g., ATaG expresses communication declaratively, and computation with an imperative language Programming WSNs: From Theory to Practice 62 © 2008-2009 Luca Mottola and Gian Pietro Picco

Imperative-Sequential: Pleiades  The program contains a single, sequential thread of control  the language is an extension of C  The key construct cfor allows for concurrent iteration on the network nodes  two scopes provided: entire network and 1-hop neighborhood  program variables can be annotated as local, otherwise they are globally accessible  the execution is guaranteed to be serialized across the system  The complexity is pushed on the underlying system  the compiler determines how to split and deploy the code  to optimize communication  the run-time takes care of implementing the concurrent semantics Programming WSNs: From Theory to Practice 63 © 2008-2009 Luca Mottola and Gian Pietro Picco

Pleiades Example: A Parking Application boolean nodelocal isfree=TRUE; nodeset nodelocal neighbors; node nodelocal nb; void reserve(pos dst) { boolean reserved=FALSE; node i,reservedNode=NULL; node n=closest_node(dst); nodeset loose nToExamine= add_node(n, empty_nodeset()); nodeset loose nExamined=empty_nodeset(); if(isfree@n) { reserved=TRUE; reservedNode=n; isfree@n=FALSE; return; } while(!reserved && !empty(nToExamine)){ cfor(i=get_first(nToExamine); i!=NULL; i= get_next(nToExamine)){ neighbors@i=get_neighbors(i); for(nb@i=get_first(neighbors@i);nb@i!=NULL; nb@i=get_next(neighbors@i)){ if(!member(nb@i,nExamined)) add_node(nb@i,nToExamine); } if(isfree@i){ if(!reserved){ reserved=TRUE; reservedNode=i; isfree@i=FALSE; break; } } remove_node(i,nToExamine); add_node(i,nExamined); }}} 64

Hybrid: ATaG  Mixed declarative/imperative approach  The application is described declaratively by an abstract task graph  tasks represent the processing of one or more data items, the information  abstract channels describe input/output relationships by interconnecting tasks and data items  the deployment of tasks over nodes can be controlled, along with the scope of channels  The behavior of a task is described with an imperative language  the effect of an instruction is limited to the node where the task is deployed Programming WSNs: From Theory to Practice 65 © 2008-2009 Luca Mottola and Gian Pietro Picco

ATaG Srijan for deployment- specific aspects Tool-chain - SunSPOT Design of the declarative part Any Java IDE for Programming WSNs: From Theory to Practice © 2008 Luca Mottola and Gian Pietro Picco the imperative part 67

Data Access Model  In database approaches, distribution is masked through the DB schema  nodes can be selected as table fields  In data sharing approaches, nodes exchange data through remotely accessible variables or tuples  e.g., Pleiades, TeenyLIME, Abstract Regions  Others rely on variations of message passing  e.g., the publish-subscribe facility of DSWare  A few even exploit forms of mobile code  e.g., SensorWare and Agilla Programming WSNs: From Theory to Practice 68 © 2008-2009 Luca Mottola and Gian Pietro Picco

Programming WSNs: A Taxonomy Architectural Issues  We concentrated on what the various approaches provide to programmers  Hereafter, we focus on the implications on the design and development of WSN applications Programming WSNs: From Theory to Practice 69 © 2008-2009 Luca Mottola and Gian Pietro Picco

Programming Support  Most existing approaches are holistic solutions fully supporting the programmer  e.g., TinyDB, ATaG, …  A few approaches, however, focus on a specific problem and provide a building-block, to be complemented by other constructs  e.g., Logical Neighborhoods, Generic Role Assignment Programming WSNs: From Theory to Practice 70 © 2008-2009 Luca Mottola and Gian Pietro Picco

Building-block: GRA  Configuration of a WSN is a complex task, which involves assigning roles to some nodes  e.g., coverage, clustering, in-network data aggregation  typically handled case by case  Goal: devise a (declarative) abstraction Role for generic role assignment Specification  Run-time support:  a role-assignment distributed algorithm propagates node properties and their evaluation  a role compiler customizes the role specification and generates the code for the role-assignment algorithm Programming WSNs: From Theory to Practice 71 © 2008-2009 Luca Mottola and Gian Pietro Picco 71

GRA Clustering Example A node becomes clusterhead if none of its neighbors is; it becomes gateway if it connects two clusterheads for which there is not a gateway CH :: { count (1 hop) { role == CH ch slave gw } == 0} GW :: { clusterheads = retrieve (1 hop, 2) { role == CH } && count (2 hops) { role == GW && clusterheads == super.clusterheads clustering } == 0 } SLAVE :: else Programming WSNs: From Theory to Practice 72 72 © 2008-2009 Luca Mottola and Gian Pietro Picco

Layer Focus  Some approaches are meant to be used only by the application programmer  similar to “middleware” in mainstream computing  e.g., Pleiades, TinyDB  Others are meant to program also system services, spanning vertically the entire stack  nesC, Hood, TeenyLime Programming WSNs: From Theory to Practice 73 © 2008-2009 Luca Mottola and Gian Pietro Picco

Vertical Solution: Hood  Goal: collect and share data in a 1-hop neighborhood  Neighborhoods defined by node attributes, periodically broadcast  Attribute values from neighbors are cached at a node based on neighborhood definitions  the decision to cache rests entirely with the node  multiple neighborhoods may be active at a node  neighborhood relationships may be asymmetric  for each neighbor, a mirror (reflection) of its state is allocated generate attribute LightAttribute from int; generate neighborhood LightHood { wire filter LightThreshold; set max_neighbors to 5; reflection LightRefl from LightAttribute; } Programming WSNs: From Theory to Practice 74 74 © 2008-2009 Luca Mottola and Gian Pietro Picco

Hood Application Structure Bootstrap command to trigger data push, pull command also provided Scribbles are local annotations (e.g., aggregations) Determines how attribute values to the state of a are sent (e.g., neighbor period) Filters are boolean functions encoding neighborhood membership rules Data marshalling layer, takes care of the actual communication 75 75

Low-level Configuration  How much the programmer is allowed to “tinker” with the lower levels of the stack  e.g., controlling radio parameters  may enable cross-layer optimizations  Typically, these low-level configuration aspects are fixed by the implementation, and not available to the programmer  In other cases, a proper interface is provided  e.g., MiLAN, Abstract Regions Programming WSNs: From Theory to Practice 76 © 2008-2009 Luca Mottola and Gian Pietro Picco

Low-level Interface: MiLAN  Applications should not need to keep track of sensor availability, properties, and energy: rather, they should influence how the network is configured over time  MiLAN (Middleware Linking Applications and Networks):  takes input from  the application (requirements and sensor performance definitions)  the network (physical constraints and cost)  determines a network configuration matching requirements, by finding feasible sets of sensors from those available  dynamically reconfigures the network to satisfy the application goals and to tradeoff performance for cost  Application testbed: health monitor  body-worn sensors in a personal area network Programming WSNs: From Theory to Practice 77 77 © 2008-2009 Luca Mottola and Gian Pietro Picco

MiLAN Feasible Sensor Sets S3 S4 Sensor QoS Application requirement S1 Set # Sensors S2 1 Blood flow, Respiration 2 Blood flow, ECG (3 leads) 3 Pulse Oxygen, Blood pressure, ECG (1 lead), Respiration S5 S6 4 Pulse Oxygen, Blood pressure, ECG (1 lead), Respiration 5 Oxygen, Blood pressure, ECG (1 lead), Respiration 6 Oxygen, Blood pressure, ECG (3 leads)  MiLAN automatically determines the best among the feasible sets, optimizing resource consumption  feasible sets = {S ,S }, {S ,S ,S }, {S ,S ,S } 1 2 1 5 6 2 3 4  applying {S ,S ,S } followed by {S ,S ,S } may double lifetime w.r.t. {S ,S } 1 5 6 2 3 4 1 2 Programming WSNs: From Theory to Practice 78 © 2008-2009 Luca Mottola and Gian Pietro Picco 78

Execution Environment  Not all of the available systems are immediately applicable to real hardware  Some have been implemented and evaluated only on a simulator  Avrora, Cooja, TOSSIM  good as a proof-of-concept, but the gap to real implementation is significant  critical races are not an issue in TOSSIM  link quality and RSSI are difficult to test via simulation Programming WSNs: From Theory to Practice 79 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Language Aspects  Making communication implicit is a common design choice to raise the abstraction level  no need to deal with serialization, message parsing, and the like  systems that require explicit management of communication rely on message passing…  … but not all message passing systems require explicit management (e.g., DSWare) Programming WSNs: From Theory to Practice 80 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Language Aspects  The communication scope “implies” the data access model  all systems providing system-wide communication scope adopt a database model  systems supporting multi-hop groups often rely on a data sharing model  except Logical Neighborhoods  motivated by the desire to abstract away as much as possible  instead, Logical Neighborhood is a building block  The reverse does not necessarily hold  data sharing often used in the physical neighborhood  Hood, Pleiades, TeenyLime Programming WSNs: From Theory to Practice 81 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion A Note About “Macroprogramming”  The previous observations are not captured by the common notion of macroprogramming  or by the distinction into node-, group-, network- level programming  The above do not distinguish the computation and communication aspects  Systems with rather different characteristics are classified under the same umbrella  e.g., Pleiades and Regiment, or Abstract Regions and Hood Programming WSNs: From Theory to Practice 82 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Language Aspects  The computation scope affects the programming idiom  at one extreme, systems with global computation adopt a declarative approach  at the other end, local computation is usually specified with imperative approaches  although declarative ones exist (e.g., GRA) Programming WSNs: From Theory to Practice 83 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Architectural Aspects  Very few systems designed as building-blocks  GRA, Hood, Logical Neighborhoods  a potential hampering factor for the development of the field  General wisdom: WSNs require cross-layer solutions  fact: very few systems provide some (primitive) mechanism to manipulate the lower layers Programming WSNs: From Theory to Practice 84 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Language and Architecture Are Not Independent!  All the systems supporting “vertical” development have a local computation scope  low-level mechanisms (e.g., routing) require control of individual nodes, which can’t “disappear” into a higher-level abstraction  Dually, none of the global computation ones features hooks into the lower levels  it would be a mismatch w.r.t. the abstraction level Programming WSNs: From Theory to Practice 85 © 2008-2009 Luca Mottola and Gian Pietro Picco

What About Applications? Programming Goal Interaction Pattern Space Time Abstraction Abstract Regions SO Depends on region Local Periodic/Event-driven ATaG SR Many-to-many Local Periodic EnviroSuite SO Many-to-one Local Event-driven Generic Role Assignment SO Many-to-many Global Periodic/Event-driven Hood SO Many-to-many Local Periodic Logical Neighborhoods SR One-to-many Local Periodic/Event-driven MiLAN SO Many-to-one Global Periodic nesC SO Many-to-many Local Periodic/Event-driven Pleiades SO Many-to-many Global Periodic/Event-driven Regiment SO Many-to-one Local Event-driven TeenyLime SR Many-to-many Local Periodic/Event-driven TinyDB SO Many-to-one Global Periodic Programming WSNs: From Theory to Practice 86 © 2008-2009 Luca Mottola and Gian Pietro Picco

Discussion Programming Solutions vs. Applications  Only a few systems are designed with sense- and-react applications in mind  most focus on data collection  event-based applications privilege localized interactions  None of the systems support mobile sensors  despite a large body of work in the area  peculiar requirements about location-centric and delay-tolerant communication Programming WSNs: From Theory to Practice 87 © 2008-2009 Luca Mottola and Gian Pietro Picco

Conclusion  Wireless sensor networks are predicted to grow dramatically in the next few years  Programming WSN applications is still an art:  powerful and efficient programming abstractions are required to support domain experts  We provided a systematic treatment of the state-of-the-art, with significant examples  hopefully will inspire researchers and practitioners Programming WSNs: From Theory to Practice 88 © 2008-2009 Luca Mottola and Gian Pietro Picco

Some Items for a Research Agenda  Failure tolerance: little or no support provided to programmers to deal with node failures and/or erroneous data  Testing and validation: a few debugging papers, state-of-the-art still quite primitive  Evaluation methodology: how do we decide that one system is better than another?  Need for real-world experiences: most deployments reported in the literature are still based directly on the OS layer Programming WSNs: From Theory to Practice 89 © 2008-2009 Luca Mottola and Gian Pietro Picco

References 1. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, “System architecture directions for networked sensors,” in ASPLOS-IX: Proc. of the 9th Int. Conf. on Architectural Support for Programming Languages and Operating Systems, 2000. 2. D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, “The nesC language: A holistic approach to networked embedded systems,” in Proc. of the ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI), 2003. 3. P. Naik and K. Sivalingam, “A survey of mac protocols for sensor networks,” Wireless sensor networks, 2004. 4. B. Sundararaman, U. Buy, and A. D. Kshemkalyani, “Clock synchronization for wireless sensor networks: A survey,” Ad Hoc Networks, vol. 3, no. 3, 2005. 5. K. Langendoen and N. Reijers, “Distributed localization in wireless sensor networks: A quantitative comparison,” Computer Networks, vol. 43, no. 4, 2003. 6. S. Madden, M.J. Franklin, J.M. Hellerstein, and W. Hong, “TinyDB: an acquisitional query processing system for sensor networks,” ACM Trans. Database Syst., vol. 30, no. 1, 2005. 7. P. Costa, L. Mottola, A. L. Murphy, and G. P. Picco, “Programming wireless sensor networks with the TeenyLime middleware,” in Proc. of the 8th ACM/USENIX Int. Middleware Conf., 2007. 8. K. Whitehouse, C. Sharp, E. Brewer, and D. Culler, “Hood: a neighborhood abstraction for sensor networks,” in Proc. of 2nd Int. Conf. on Mobile Systems, Applications, and Services (MOBISYS), 2004. 9. L. Luo, T. F. Abdelzaher, T. He, and J. A. Stankovic, “EnviroSuite: An environmentally immersive programming framework for sensor networks,” Trans. on Embedded Computing Sys., vol. 5, no. 3, 2006. 10. M. Welsh and G. Mainland, “Programming sensor networks using abstract regions,” in Proc. of 1st Symp. on Networked Systems Design and Implementation (NSDI), 2004. Programming WSNs: From Theory to Practice 90 © 2008-2009 Luca Mottola and Gian Pietro Picco

References 1. L. Mottola and G. P. Picco, “Logical Neighborhoods: A programming abstraction for wireless sensor networks,” in Proc. of the 2nd Int. Conf. on Distributed Computing on Sensor Systems (DCOSS), 2006. 2. N. Kothari, R. Gummadi, T. Millstein, and R. Govindan, “Reliable and efficient programming abstractions for wireless sensor networks,” in Proc. of the ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI), 2007. 3. A. Bakshi, V. K. Prasanna, J. Reich, and D. Larner, “The Abstract Task Graph: A methodology for architecture-independent programming of networked sensor systems,” in Workshop on End-to-end Sense-and-respond Systems (EESR), 2005. 4. L. Mottola, A. Pathak, A. Bakshi, G. P. Picco, and V. K. Prasanna, “Enabling scope-based interactions in sensor network macroprogramming,” in Proc. of the the 4th Int. Conf. on Mobile Ad- Hoc and Sensor Systems (MASS), 2007. 5. R. Newton, G. Morrisett, and M. Welsh, “The Regiment Macroprogramming System,” in Proc. of the 6th Int. Conf. on Information Processing in Sensor Networks (IPSN), 2007. 6. Y. Yao and J. Gehrke, “The Cougar approach to in-network query processing in sensor networks,” SIGMOD Rec., vol. 31, no. 3, 2002. 7. K. Terfloth, G. Wittenburg, and J. Schiller, “Facts - a rule-based middleware architecture for wireless sensor networks,” in Proc. of the 1st Int. Conf. on Communication System Software and Middleware (COMSWARE), 2006. 8. M. J. Ocean, A. Bestavros, and A. J. Kfoury, “snBench: Programming and virtualization framework for distributed multitasking sensor networks,” in Proc. of the 2nd Int. Conf. on Virtual Execution Environments (VEE), 2006. 9. S. Li, Y. Lin, S.H. Son, J.A. Stankovic, and Y. Wei, “Event detection services using data service middleware in distributed sensor networks,” Telecommunication Systems, vol. 26, no. 2, 2004. 10. A. Boulis, C.-C. Han, R. Shea, and M. B. Srivastava, “Sensorware: Programming sensor networks beyond code update and querying,” Pervasive Mob. Comput., vol. 3, no. 4, 2007. Programming WSNs: From Theory to Practice 91 © 2008-2009 Luca Mottola and Gian Pietro Picco

References 1. C.-L. Fok, G.-C. Roman, and C. Lu, “Rapid development and flexible deployment of adaptive wireless sensor network applications,” in Proc. of the 25th Int. Conf. on Distributed Computing Systems (ICDCS), 2005. 2. C. Frank and K. Römer, “Algorithms for generic role assignment in wireless sensor networks,” in Proc. of the 3rd ACM Conf. on Embedded Networked Sensor Systems (SENSYS), 2005. 3. W. B. Heinzelman, A. L. Murphy, H. S. Carvalho, and M. A. Perillo, “Middleware linking applications and networks,” IEEE Network, vol. 18, 2004. 4. D. Gay, P. Levis and D. Culler, “Software Design Patterns for TinyOS,” in ACM Transactions on Embedded Computing Systems (TECS), vol. 6, no. 4, 2007. 5. P. Ciciriello, L. Mottola, and G.P. Picco, “Building virtual sensors and actuator over Logical Neighborhoods,” in Proc. of the 1st ACM Int. Wkshp. on Middleware for Sensor Networks (MidSens06 - colocated with ACM/USENIX Middleware), 2006. 6. N. Cooprider, W. Archer, E. Eide, D. Gay and J. Regehr, “Efficient Memory Safety for TinyOS,” in Proc. of the 5th ACM International Conference on Embedded Networked Sensor Systems (SENSYS), 2007. 7. N. Ramanathan, K. Chang, R. Kapur, L. Girod, and E. Kohler, “Sympathy for the Sensor Network Debugger,” in Proc. of the 3rd ACM Conf. on Embedded Networked Sensor Systems (SENSYS), 2005. 8. K Whitehouse et al. ,“Marionette: Using RPC for Interactive Development and Debugging of Wireless Embedded Networks,” in Proc. of the 5th Int. Conf. on Information Processing in Sensor Networks (IPSN), 2006. 9. J. Yang, M. L. Soffa, and K. Whitehouse, “Effective source-level debugging of wireless sensor networks,” in Proc. of the 5th ACM International Conference on Embedded Networked Sensor Systems (SENSYS), 2007. 10. M. Ringwald , K. Römer,, and A. Vitaletti, “Passive Inspection of Sensor Networks”, in Proc. of the 2nd Int. Conf. on Distributed Computing on Sensor Systems (DCOSS), 2006. Programming WSNs: From Theory to Practice 92 © 2008-2009 Luca Mottola and Gian Pietro Picco

Wsn Programming

0 comments

Notes on slide 1

Favorites, Groups & Events

Wsn Programming - Presentation Transcript

More by user

More info about this document

Categories

Wsn Programming

0 comments

Notes on slide 1

Favorites, Groups & Events

Wsn Programming - Presentation Transcript

Related Presentations

More by user

More info about this document

Categories