Cours programming Wireless Sensor Networks, tutoriel & guide de travaux pratiques en pdf.

REFERENCE ARCHITECTURE

The boundaries between programming abstractions and the rest of the software ex-ecuting on a WSN node is often blurred. The scarce computing and communication resources available in WSNs, along with their application-speci c nature, foster a cross-layer design where the application is often intertwined with system-level ser-vices. In addition, programming abstractions are intimately related with a number of other issues in WSNs. These include application and services (e.g., routing) built on top of the abstractions, down to the hardware and operating system the abstractions are built upon.
To help delimit clearly what is|and especially what is not|in the scope of our work, we introduce here a reference architecture, shown1 in Figure 4. In the following we describe each of its constituents, thus establishing a context for our taxonomy of WSN programming approaches.
Hardware. Figure 5 illustrates a very abstract view of the hardware in a typical WSN node. A plethora of WSN platforms exist both as commercial products and research prototypes [Crossbow Tech. ; MoteIV ; Body Sensor Network Nodes ; BTNode ; Eyes WSN Nodes ; Project SunSPOT ; MeshNetics Tech. ; ScatterWeb Inc. ; Aduino Sensor Node Platform ]. However, the individual components used do not di er drastically. Many platforms use a 16-bit Texas Instruments MSP430 micro-controller or a 8/16-bit chip of the Atmel ATMega family. Notable exceptions are the IMote2 and SunSPOT platforms, based on the more powerful Intel PXA and ARM920T chips, respectively. Typical amounts of volatile memory range from 2 KB to 512 KB. This is used to store run-time data during program execution. The binary program code is stored in a dedicated memory whose size is typically between 32 KB and 128 KB. In addition, nodes are often equipped with separate, external storage devices (e.g., ash memory) whose size may vary from 128 KB to several gigabytes. Their use depends on the speci c application. As for radio hard-ware, most platforms work in the 2.4 GHz ISM band, and feature IEEE 802.15.4-compliant [Baronti et al. 2007] radio chips, e.g., the ChipCon 2420. Alternative so-lutions operate in the 868/916 MHz band, e.g., using the ChipCon 1000 transceiver, or rely on Bluetooth interfaces. The speci c type of sensing and actuating device is largely application-speci c, and often custom-integrated.
Medium Access Control (MAC). MAC protocols for WSNs must guarantee ef-cient access to the communication media while carefully managing the energy budget allotted to the node. The latter goal is typically achieved by switching the radio to a low-power mode based on the current transmission schedule. In contrast to other wireless platforms where the MAC functionality is realized in hardware, a WSN MAC protocol is typically implemented mostly in software, using the low-level language associated with the operating system.
Most of the existing protocols fall in two categories. Contention-based proto-cols [Ye et al. 2002; Polastre et al. 2004; van Dam and Langendoen 2003] regulate the access to the physical layer opportunistically, based on the current transmission requests. Conversely, time-slotted protocols assign the nodes with prede ned time- slots to schedule their transmissions over time [Rajendran et al. 2003; 2006]. The former class of protocols is easier to implement and better tolerates nodes joining or leaving. Instead, the latter enables higher reliability and greater energy savings, but with the additional requirement of tight time synchronization among the nodes in some k-hop neighborhood.
Operating system. In contrast to mainstream computing, in WSNs the operating system is essentially a library, linked with the application code to produce a binary for execution. The operating system usually supports a companion programming language, which is typically C or a WSN-speci c dialect (e.g., nesC [Gay et al. 2003] for the TinyOS [Hill et al. 2000] operating system). A low-level communi-cation facility is also commonly provided, e.g., the Active Message [Culler et al. 2001] interface of TinyOS. Such companion language and communication primi-tives de ne the lowest level abstraction available to programmers. In a sense, they resemble the use of the C language and sockets in mainstream computing as the core programming abstractions provided by the operating system.
Several operating systems for WSNs have been proposed so far, the most common being the aforementioned TinyOS. Alternatives include Contiki [Dunkels et al. 2004], SOS [Han et al. 2005], Mantis [Abrach et al. 2003], RETOS [Cha et al. 2007], LiteOS [Cao et al. 2008], t-Kernel [Gu and Stankovic 2006], and NANO-rk [Eswaran et al. 2005]. The concurrency model employed varies from event-driven approaches [Hill et al. 2000] to preemptive, time-sliced multi-threading [Abrach et al. 2003; Cha et al. 2007; Cao et al. 2008], cooperative multi-threading [Dunkels et al. 2006], and asynchronous message passing [Han et al. 2005]. Some of the above operating systems (e.g., SOS, LiteOS, and Contiki) also provide dynamic linking capabilities, i.e., new code modules can be added at run-time to the application running on a node. Dynamic linking is particularly important in supporting wireless reprogramming of the WSN, one of the system services described next.
System services. While applications deliver useful data directly to the end user, system services are typically useful in support of applications. Examples are lo-calization mechanisms [Langendoen and Reijers 2003], time synchronization pro-tocols [Elson and Roemer 2003; Sundararaman et al. 2005], distributed storage services [Ratnasamy et al. 2002; Luo et al. 2007], code deployment and reprogram-ming functionality [Wang et al. 2006], and routing protocols [Al-Karaki and Kamal 2004]. Notably, some approaches in routing play at border between system services and programming abstractions. For instance, in Directed Di usion [Intanagonwi-wat et al. 2003] programmers specify the characteristics of the data required using attribute-value pairs. The emphasis of these approaches, however, is mostly on routing and communication issues. As a consequence, unlike the systems surveyed in the rest of the paper, they feature only very limited expressiveness as they do not provide a well-de ned, structured programming abstraction.
System services are built atop the core functionality provided by the operating system, by using either the operating system language (e.g., nesC) or some of the programming abstractions we discuss in this paper. For instance, localization and  routing have been implemented successfully in Hood [Whitehouse et al. 2004]. In our survey, we distinguish between programming approaches suitable also to the development of system services, and those geared only towards applications.

TAXONOMY OVERVIEW

The focus of our work is on high-level language constructs allowing programmers to express various forms of distributed processing among the WSN nodes.
In this eld, the only characterizing dimension that hitherto received some at-tention is the one of node-centric programming vs. macroprogramming [Gummadi et al. 2005]. The former generally refers to programming abstractions used to ex-press the application processing from the point of view of the individual nodes. The overall system behavior must therefore be described in terms of pairwise interac-tions between nodes within radio range. Macroprogramming solutions, instead, are usually characterized by higher-level abstractions that focus mainly on the behavior of the entire network, rather than on the individual nodes.
Nonetheless, under many respects the above distinction falls short of expectation in capturing the essence of currently available programming approaches. As a result, solutions o ering radically di erent abstraction levels are considered under the same umbrella, ultimately rendering the distinction ine ective. For instance, both TinyDB [Madden et al. 2005] and Kairos [Gummadi et al. 2005] are commonly regarded as macroprogramming solutions. However, the former provides an SQL-like interface where the entire network is abstracted as a relational table. Therefore, inter-node interactions are completely hidden from the programmer. The latter, on the other hand, is an imperative programming language where constructs are provided to iterate through the neighbors of a given node and communication occurs by reading or writing shared variables at speci c nodes. Therefore, unlike TinyDB, in Kairos the application processing is still mostly expressed as pairwise interactions between neighboring nodes, and yet the level of abstraction is very di erent from node-centric programming approaches.
These considerations have been our motivation for de ning a taxonomy of pro-gramming approaches that goes beyond the traditional dichotomy between node-centric and macroprogramming, and examines a wider set of concepts. Our taxon-omy is structured along two main dimensions, each contained in a separate section of this paper:
|In Section 5, we study the language aspects of available WSN programming ap-proaches. These are analyzed to understand the primitives provided to program-mers for expressing communication and computation, and the peculiarities of the programming model.
|In Section 6, we consider the architectural aspects related with existing WSN pro-gramming solutions, by analyzing features such as their intended use, their reach into the low-level layers of the architecture, and their execution environment.
Our objective is to provide the reader with an understanding of the expressive power of the various approaches in the rst part, while in the second part we intend to explore how these approaches can be used in application development, and what is their relationship with the rest of the architecture depicted in Figure 4.