From Sensor Networks to Concurrent Systems Ciprian Teodorov, Damien Picard and Bernard Pottier Universit´e de Bretagne Occidentale Lab-STICC, CNRS UMR 3192, France {surname.name}@univ-brest.fr

Abstract. Large systems of processes are found in a lot of situations. They have particularities that make studies and developments difficult. On the particular case of sensor networks this paper shows the interests of a simple abstraction layer coupled to local behaviour descriptions: easy separation of topology and behaviours, abstraction of communication mechanisms, use of known set of algorithms, simulation supports. The work is achieved in a larger project that includes synthesis tools for fine and coarse grain reconfigurable devices, partly developped to address heterogeneous reconfigurable systems on chip.

1 Introduction Computing environments evolve, giving more and more importance to distributed system problems. Two factors contribute to these evolutions. First, wireless communication and possibility to build low cost integrated systems produce a proliferation of small communicating devices. Second, integrated architectures do not scale, and dominant tendencies are now at system level: multi-cores and System-on-Chips (SoC) that can be quite complex to design and control. These changes must be considered as the top level of investigations, before the local behaviour definition. This dimension of computing is of course not a novelty, considering the numerous contributions of the domain, as an example [53] provides a survey of problems and solutions. As distributed systems are becoming centric in application fields, it becomes attractive to study software development methods allowing to control either the distributed aspects, the local programming aspects, and possibly fast and secure ways for code generation. This is not the smallest of the practical problems, since we have a lot of programming tools and existing software to be used in applications. To address this situation, we are experimenting a design flow that follows the natural level of details found on practical case studies. Distributed System level is a specification of processes executing the application. Typically these processes are distributed and communicate by messages. Messages are transfered from memory to memory, the transfer mechanism being abstracted. Local level is a set of software or hardware processes transforming local data. These processes operate on physical memories, can have blocking operations between them and on communication ports,

Execution level whatever program code, or circuit that can transport or transform information. We have found this natural decomposition helpful to build development environment in several significant situations. Sensor networks can exhibit random organisations and communication capabilities. They can become faulty and necessitate robust algorithms to cooperate. This paper will provide a short survey of problems and solutions found in this domain, then will report the modelling and simulation produced using the design flow. Heterogeneous Reconfigurable SoC are new solutions investigated to match computing power and application needs while preserving programmability. An extensive work has been done in this domain to reach the execution level from local level, including scheduling of communications, logic synthesis and synthesis on reconfigurable data paths. Non CMOS nano-technologies similar to CMOL[77] or NASIC[57], expected to be fabricated from tiles of logic components. In this case, a major problem is the necessity to manage defects or floor planning constraints on wide surfaces. In this paper we propose an environment for designing and implementing parallel systems as process networks. The presented flow separates the network topology description from process behaviour description, enabling heterogeneous behaviour composition. An intermediate Control Data Flow Graph (CDFG) format supports algorithm expressions from different development languages and paradigms, including communicating processes. The multi-level simulation capabilities of the environment helps the designers to easily spot the eventual problems and help them understand subtle characteristics of the analysed systems. The multi-target code generation facilities enables the design and implementation of a wide range of solutions ranging from simple code generation (Occam) to FPGAs and reconfigurable systems on chip (rSoC). The paper will start providing a short survey on sensor networks focusing on cooperation problems. The second part of the paper will detail the organisation of the design flow to enable simulation of cooperation activities. In this case, simulation is achieved by executing and tracing generated Occam programs. However we also explain how circuits for local behaviours can be derived from the CDFG exchange format using the workbench tools.

2 Sensor Networks Overview In the recent years, the advances in micro-electro-mechanical systems (MEMS) technology, wireless communication and digital electronics have enabled the development of tiny, low-cost, low-power, networked sensors. These tiny sensors, collaborating together, offer numerous advantages over traditional networks, such as large-scale flexible architecture, high-quality of sensed data, application adaptative mechanisms. The wireless sensor networks, in 1999 [82], where heralded by Business Week as one of the 21 most important technologies for the 21st century.

Smart disposable micro-sensors can be deployed on the ground, in the air, under water, inside buildings, on vehicles, on bodies. They can be deployed in specific predetermined position or at random, this allowing the deployment in inaccessible areas.

Fig. 1. The components of a sensor node

Usually the sensor nodes have a hardware architecture like the one described in Figure 1: a sensing unit, a processing unit, a transceiver unit and a power unit. There are applications that need the addition of other components such as: location finding system (i.e. GPS), a power generator, a mobiliser, etc. Is not the simplicity of the hardware architecture of each node that makes the wireless sensor networks (WSNs) so powerful but the capacity to densely deploy them either inside the phenomenon or very close to it and the capacity of the nodes to collaborate. From a software engineering point of view the sensor networks (SN) should have certain distributed system characteristics like: transparency (to be perceived as a whole), scalability (to be able to accommodate changes in nodes and resources), fault tolerance, concurrency, resource sharing, openness (to be open to evolution and interactions with other systems). Distributed systems are very difficult to handle due to the large number of components and situations. For sensor networks the problems arising can be even more complicated due to the characteristics that are specific to these systems (i.e. unknown topology, the lack of an unique identifier for each node, weak internal and external connectivity). A large number of algorithms and techniques have been proposed to address these issues, and nowadays the researchers are striving to find solutions in order to help people benefit from the advances in technology. 2.1 Sensor Networks Applications Wireless sensor networks can be composed of many types of sensors such as: thermal, visual, infrared, seismic, magnetic, acoustic, radar. They can be used in many kinds of application. In [2] we can find a classification of wireless sensor networks based on application domain:

– Military application. Wireless sensor networks are well suited for military application as they are cheap, disposable, easy to deploy, self-organising, fault-tolerant. Some of the application are: monitoring friendly forces, battlefield surveillance, reconnaissance of opposing forces and terrain, targeting, battle damage assessment, nuclear, biological, chemical attack detection and reconnaissance. – Environmental monitoring. Some environmental applications of sensor networks includes tracking of movement of birds, small animals and insects; monitoring environmental conditions that affect crops and livestock; irrigation; chemical/biological detection, forest fire detection; flood detection (i.e. ALERT system[36]). – Health. Some health application for sensor networks are integrated patient monitoring; drug administration in hospitals, tracking and monitoring doctors and patients inside a hospital. – Home. Coupling sensor nodes with actuators inside home appliances, such as vacuum cleaner, micro-waves ovens, etc can provide a great framework for monitoring and managing home devices locally or remote (via Internet). Smart environments like ”Residential Laboratory” at Georgia Institute of Technology[17]. – Other commercial areas. like monitoring material fatigue; building virtual keyboards; inventory management; product quality monitoring; robot control; vehicle tracking and detection, etc. 2.2 Sensor Networks Design Considerations Sensor network design is influenced by a large number of factors, which include: scalability, fault tolerance, production price for a sensor node, hardware constraints, sensor network topology, environment, transmission media, power consumption, network dynamics. These factors are used as a guideline and as a comparison base to design a protocol or an algorithm for sensor networks. Scalability. The number of nodes in a sensor network deployed over an area may be in order of hundreds, thousands or more. The algorithms developed should be able to cope with such a large number of nodes. Fault Tolerance. At any moment in time some sensor nodes can fail due to lack of power, physical damage or environmental interference. The failure of sensor nodes should not affect the overall task of the sensor network. The topology change generated by such an event should be managed by MAC and routing protocols in order to keep the data flowing from the sensing nodes to the sink. Redundancy can be exploited to extend system lifetime and to improve network fault-tolerance. Price. Since wireless sensor networks consist of a large number of sensor nodes, the production cost of a single node is very important. If the cost of the wireless sensor network is bigger than the cost of deploying traditional sensors, then the use of wireless sensor network is not cost-justified. The cost of a sensor node should be much less than 1$ in order for the sensor network to be feasible[64].

Hardware Constraints. The size, energy consumption, autonomy, adaptability are some of the constraints imposed on the hardware components of wireless sensor networks. Topology. Sheer number of inaccessible and unattended sensor nodes, which are prone to frequent failures, make topology maintenance a challenging task[2]. Coping with frequent topology changes and very hard power consumption constraints requires special routing protocols. Environment. Sensor nodes are deployed very close or inside the monitored phenomenon. The working condition can be very harsh, the high pressure at the bottom of an ocean, in debris or a battlefield, under extreme heat and cold such as in the nozzle of an aircraft engine or in arctic regions, and in extremely noisy environment such as intentional jamming[2]. Transmission Media. Radio, infrared or optical media are the communication mediums for the wireless sensor networks. Power Consumption. Sensor node lifetime shows a strong dependence on the battery lifetime[34]. Sensor nodes can use up their limited energy supply performing computations and transmitting information in the environment. At the same time they need to save this energy in such a way that they will be able to operate for years in a remote, inaccessible location. The nodes in a sensor network are playing the double role of data senders and routers for transmitted data. The malfunctioning of some sender nodes due to power failure can cause significant topology changes and might require rerouting of packets and reorganisation of the network.

3 Wireless Sensor Networks Protocol Stack A typical sensor network architecture is presented in Figure 3. The sensor nodes are deployed over a sensor field. Each of these nodes senses the environment and are able to route data to the sink. Data are routed back to the end user using a multi-hop infrastructure architecture through the sink as shown in the Figure 3. The sink may communicate with the task manager node via Internet or Satellite. The protocol stack used by the sink and all the sensor nodes is given in Figure 3. This protocol stack combines power and routing awareness, integrates data with networking protocols, communicates power efficiently through the wireless medium. The protocol stack consist of the physical layer, data link layer, network layer, transport layer, application layer, power management plane, mobility management plane, and task management plane. The physical layer addresses the needs of a simple but robust modulation, transmission and receiving techniques. The data application layer must be able to cope with the noisy environment and the nodes mobility providing a power aware MAC protocol that minimise collisions. The network layer takes care of routing the data supplied by the transport layer. The transport layer may help to maintain

Fig. 2. Sensor network architecture

the flow of data if the application requires it. Different types of application can be built and used of the application layer. On the other hand the power, mobility, and task management plane monitor the power, movement, and task distribution over the sensor nodes. The utility of these planes come from the fact that the sensor nodes need to work together in a power efficient way, route data in a mobile sensor network and share resources between sensor nodes. Without them, each sensor node will just work individually.

Fig. 3. The sensor network protocol stack

In the following sections we will present each of the protocol layer, pointing the task they need to perform. 3.1 Physical Layer The physical layer is responsible for frequency selection, carrier frequency generation, signal detection, modulation, and data encryption.

3.2 Data Link Layer The data link layer is responsible for data streams multiplexing, data frame detection, medium access, and error control. The following sections will discuss some of the issues related to this layer and will present some of the proposed solutions. Medium access control. The MAC protocol in a wireless multi-hop self-organising sensor network must achieve two goals [2]: to create the network infrastructure and to ensure the fairness and efficiency of the communication resources sharing between sensor nodes. In [2], Akyildiz and al. showed some reasons why typical MAC schemes cannot be applied to wireless sensor networks. The basic idea is that all the existing MAC schemes are not designed for power efficiency, even though some of the devices using these schemes are mobile battery powered devices. Bleutooth’s and MANET’s MAC schemes are said to be the closest to what we need for sensor networks, but these strategies cannot be used directly due to the hard power constraints that characterise the wireless sensor networks. Pottie and al., in [62], believe that since radios must be turned off for power saving, the MAC scheme should be a variant of TDMA. Such a protocol is presented in [73]. In [85] a CSMA based medium access scheme is presented (the EAR algorithm). Other relevant papers are [6], the PicoRadio[92], S-MAC[89], STEM[67] and [69]. Power saving modes. Regardless of which type of medium access scheme is used for the sensor network, the power saving operations must be supported. The simplest power saving scheme can be to turn the transceiver off when idling. This approach can bring significant energy gains but care should be taken because the wireless sensor networks tend to use short packets for communication and that can mean that we need to turn on and off the transceiver very often. Following this scheme we can get to the situation in which we loose more energy by using this scheme than the energy lost if the transceiver was left open. In conclusion, operating in a power saving mode is energy efficient only if the time spent in that mode is greater than a certain threshold[2]. Sinha proposed, in [71], a dynamic power management scheme for wireless sensor networks with five power saving modes and transition policies from a mode to another. Error Control. Another important function of the data link layer is the error control of transmission data. Forward error correction (FEC) and automatic repeat request (ARQ) are two of the main error control techniques. The applicability of ARQ in wireless sensor networks is limited due to the cost and overhead of re-transmission. On the other hand FEC’s decoding complexity can also be prohibitive. Akyildiz and al. in [2], think that simple encoding techniques that enable easy decoding might present an energy efficient solution for sensor networks. 3.3 Network Layer Network layer share some commonalities with ad-hoc networking, but the more stringent requirements regarding scalability, energy efficiency and other factors presented before require new solutions.

Routing Protocols in WSN

Network Structure

Flat Networks Routing

Hierarchical Networks Routing

Protocol Operation QoS Coherent Location Negotiation Multi-Path Query Based Based Based Based Based Based Routing Routing Routing Routing Routing Routing

[37, 35, 41, 87] [34, 55, 78, 48] [37, 30, 46] [9, 66, 14, 29] [88, 45, 27] [86, 13, 91] [76, 40, 65] [35, 41] [12, 68, 16] [37, 10, 9] [73, 25] [37, 73, 13] [68, 22, 1] [4, 46, 3]

Fig. 4. Routing protocols in WSNs: A taxonomy [5]

According to [5] routing protocols in WSNs can be divided, depending on the network structure, into: Flat Protocols, Hierarchical Protocols, and Location-based Protocols. According to the protocol operation they can be classified into: Negotiation Based Routing, Multi-Path Based Routing, Query Based Routing, and Coherent Based Routing. In [5] the authors proposed a taxonomy presented in Figure 4 where the numbers indicate the references. 3.4 Transport Layer The transport layer for a wireless sensor network should have the following characteristic (according to Iyer and al.[38]): the transport layer should be independent of the application, network and MAC layer in order to be applicable for several deployment scenarios; it should support heterogeneous data flow; it’s reliability should be controllable and it should conserve energy at the nodes; it should have congestion detection and avoidance mechanisms to prevent packet retransmissions; the sink should perform the computation intensive task; it must be scalable since the wireless sensor networks can be composed of large number of nodes; it has to have built-in support for future enhancements and optimisations. In the paper already cited the authors presented STCP protocol, a generic, scalable and reliable protocol for sensor networks which implements the majority of its functionalities at the sink. Other transport layer protocols are presented by Stann and al. in [75], RMST being a protocol that’s designed to run in conjunction with directed diffusion network layer algorithm[37]; Event-to-Sink Reliable Transport (ESRT)[90] is designed for data-centric applications; Pump Slowly, Fetch Quickly (PSFQ)[80] is proposed for reliable reprogramming of nodes in a sensor network.

4 Programming and Modelling Sensor Networks Due to their tight integration with the physical world and the unique characteristics they have, sensor networks pose considerable impediments and make application development nontrivial. A middleware layer is a software infrastructure that glues together

the network hardware, operating systems, network stacks and applications. A complete middleware solution should contain a runtime environment that supports and coordinates multiple application and system services such as data aggregation, control and management policies adapting to target applications.

Fig. 5. WSNs programming models. Taxonomy

Programming sensor networks raises issues that fall into two broad classes: programming support and programming abstractions (see Figure 5). Programming support class is concerned with providing systems, services and runtime mechanisms such as reliable code distribution, safe code execution and application-specific services. The way a sensor network is perceived by the user is referred by the programming abstraction class. This class provides concepts and abstractions of sensor nodes and sensor data. Even though the sub-categories of these two classes differ one from another there is possible to find some common characteristics. In the following two sections these two classes are discussed presenting some application for each class sub-category, in the last section some tools helping to model and simulate the sensor networks are presented. 4.1 Programming support In the programming support class, five main middleware subclasses are identified (see Figure 5). These subclasses are: virtual machine based, modular programming based, database based, application driven, and message-oriented. Virtual Machines. This approach includes virtual machines, interpreters and mobile agents. Developers can write applications as separate, small modules that will be injected, by the system, into the network and distributed across the nodes. The virtual machine interprets the modules. This approach suffers from the overhead that the instructions introduce. The Mat´e[42] and MagnetOS[7] are using this approach. Modular programming (mobile agents). The idea of this approach is to make the applications as modular as possible to facilitate their injection and distribution through the network using mobile code. Some examples are Impala[50] and Agilla[28].

Database. This approach views the whole system as a distributed database system. It provides an easy-to-use interface that lets the user issue queries to the sensor network to extract the data of interest. The most representative database abstractions for sensor networks are Cougar[8] and Tiny-DB[54]. Another database approache is presented in [74], the SINA (System Information Network Architecture) kernel is based on a spreadsheet database for querying and monitoring. In [47] the authors present DsWare (Data Service Middleware) database-like abstraction approach tailored to sensor networks on the basis of event detection. Application Driven. This approach is especially interesting because it enables the programmers to finely tune the network on the basis of application requirements, thus providing a QoS advantage. Milan (Middleware Linking Applications and Networks)[26] and AutoSec (Automatic Service Composition)[33] are two examples. Message-Oriented. Message oriented middleware are based on the message-oriented communication model, using the publish-subscribe mechanism to facilitate message exchange between nodes and the sink nodes. This is a powerful paradigm since it, naturally, supports asynchronous communication, allowing a loose coupling between the sender and the receiver. In pervasive environments, such as wireless sensor networks this model, this approach is quite suitable, since most applications are based on events. Mires, presented in [19], proposes an adaptation of a message-oriented middleware for traditional fixed distributed systems. 4.2 Programming abstractions The class of programming abstractions is divided in two subclasses (see fig 5). The first focuses on the global behaviour of a distributed sensor network as a whole - also called macro-programming. The second deals with the local behaviour of the sensor nodes in a distributed computation. Macro-programming. The global behaviour subclass involves programming the sensor network as a whole, rather than writing low-level software to drive individual nodes. The WSNs global behaviour is programmed at a high-level specification, enabling automatically generated nodal behaviour. This enables the application developers to focus more on the application requirements and not on the low-level concerns related to each network node. Some projects adopting macro-programming model for programming wireless sensor networks are presented in [23, 58, 18, 21]. Local behaviour. In most sensor network application, the focus is more on the nature of the sensed data, which generally involves a group of sensor nodes in a specific region. Therefore the interest is on a specific location in a sensor network, for example the location where the temperature exceeds a certain value, rather than for an individual sensor reading. In this kind of data-centric sensor networks the nodes are addressed

according to the sensed data, for example: to detect a target having the shape of “tank”, in military applications. Abstract regions[83], EnviroTrack[24], Hood[84] and Generic role assignment[20] are some projects adopting the local-nodal-behaviour model. 4.3 Modelling sensor networks A model is a theoretical construct that represents something, with a set of variables and a set of logical and quantitative relationships between them. Models in this sense are constructed to enable reasoning within an idealized logical framework about these processes and are an important component of scientific theories. Idealized here means that the model may make explicit assumptions that are known to be false (or incomplete) in some detail. Such assumptions may be justified on the grounds that they simplify the model while, at the same time, allowing the production of acceptably accurate solutions. In order to validate a specific model mainly two techniques are used: formal verification and simulation. The first verifies the properties of the system using assertion techniques, such as invariant assertion (a property of the system state, that is always true for a given system). The simulations try to prove that the simulated model behaves like a model that is known to be valid. Given the difficulties faced by the sensor network designers some models and frameworks have been proposed in the literature. Some of these are presented in the following sections. Formal Verification. Formal models and verification techniques can be used to design and analyse many kinds of systems. However there are few formal models for verification and analysis of wireless sensor networks in the literature. That might be because of the challenges posed by such kind of systems such as modelling probabilistic and real-time behaviour, novel forms of communication and analysing both correctness and performance. Some of the existent models are presented in the following paragraphs. Calculus for Sensor Networks (CSN)[51] focuses on providing a formal model that can serve as basis for the development of robust and provably correct implementations of high-level languages for sensor networks. The introduced calculus is based on process calculi and on object calculus to introduce state in sensor networks. It provides a set of primitives for programming sensor networks that support code deployment, communication and local processing. It comprises also a static typed system that enables compile time program checking. And, as the authors say, it will also support correctness proving of programs. Now, the project focus is on supporting hardware sensor networks. Real-Time Maude[59]. Olveczky and Thorvaldsen propose the use of Real-Time Maude (the real time extension of rewriting logic-based Maude) to formally model, simulate and analyse WSNs algorithms. The authors describe a way to model typical WSNs features as location, broadcast communication, probabilistic behaviour, etc in Real-Time Maude.

Petri Nets are a powerful formal model that serves for describing many kinds of systems. In [52], the authors advocate the usage of Space Time Petri Net as a base for a formal model for SNs, a formal model that allows verification techniques. In the same paper a graphical simulation system for sensor networks, based on this model, is also presented.

In [11], Chiasserini et al. present an analytical model for wireless sensor networks based on Markov chains. The model has three building blocks that are described and validated separately: 1) the sensor model, 2) the network model and 3) the channel contention model. According to the authors the model is accurate by comparing analytical and simulation results.

Simulation. Development of the right simulation tools has been a key step in systems research progress for several areas. In general, simulations can provide a way to study system design alternatives in a controlled environment, helping the developers explore system configuration that are hard to realize in real world and observe interaction that are difficult to capture in live systems. In the literature, one can find different approaches all intended to pursue the search of the right abstraction capable to both conserve the most important characteristics, of the simulated system, and facilitate the developer system interactions. The sensor networks, these complex non-deterministic systems are a kind of systems that can benefit a lot from simulations. TOSSIM[44, 43] is one of the most known simulation tools for sensor network. Tossim is a discrete-event simulator for Tiny-OS wireless sensor networks. The project goals are achieving scalability, the simulator must be able to handle large networks of thousands of nodes, completeness, covering as many system interactions as possible, the possibility to simulate complete applications, fidelity, a fine grain capturing of the network behaviour, bridging, allowing developers to simulate the exact same code that will run on the real hardware. The approach taken, by the Berkeley team, was to exploit the modularity of Tiny-OS system. So by changing some of the low level (hardware based) systems of Tiny-OS and replacing them with a number of abstractions (e.g. the hardware interrupts are replaced by simulator events) they have managed to create a powerful simulation environment. However, the power consumption of sensor networks cannot be captured using TOSSIM. PowerTOSSIM[70], is a TOSSIM extension able to capture also the power consumption. Other sensor network simulation environments include PROWLER[32], TOSSF[61] (based on SWAN[49]), SensorSim[60] (not publicly available), SENS[79], EmSim[31], J-Sim[72], OmNet++[81]. Each of these systems provides different levels of scalability and realism, depending on the goals for the simulation environment. In some cases, the goal is to work at a very abstract level, while in others, the goal is to accurately simulate the behaviour of sensor nodes. Few of these simulation environments have considered power consumption. SensorSim[60] and SENS[79] incorporate simple power usage and battery models.

5 Concurrent System Modelling of Sensor Networks As we mentioned earlier sensor networks should have certain distributed system characteristics like: transparency, scalability, fault tolerance, concurrency, resource sharing, openness. The main difficulty in programming these networks comes from the huge number of devices needing to communicate to realize a cooperative task. The unknown topology, and the weak internal and external connectivity render the application development for sensor networks a very difficult task. A simple scheme for studying algorithms and protocols for sensor networks can be to isolate the topology of a network from the local behaviours of the nodes and use composition mechanism to automatically realize a virtual network capable of simulating the system according to a specific cooperation mode (synchronous or asynchronous).

ExTopology Topology Node3_ProcN3 proto proto Node2_ProcN2

proto proto

proto proto

proto

Gateway1_ProcGW proto

Node1_ProcN1

Fig. 6. Example network topology

5.1 Simple Example At any point in time a sensor network is a set of nodes and the connectivity between them. We can represent such a network using a directed graph like the one in Figure 5. In this figure we have a simple network having four nodes, from which one is the sink (Gateway1). Associated with each node we have the name of a procedure (ProcNode1, ProcGateway), representing the identifier of the behaviour running on that node. The links between the nodes represent the connectivity of the network (Node1 can send messages to Node2 and Node3 and it can receive messages from Node2 and Gateway1).

Node1 {Node2 , Node3 } ProcNode1 Node2 {Node1 , Gateway1 } ProcNode2 Node3 { Node2 } ProcNode3 Gateway1 { Node1 , Node2 } P r o c G a t e w a y

Listing 1.1. Example topology description

The topology can be specified easily using the language presented in Listing 1.1, where each node specifies its fan-out in a list of processes as well as the behaviour it will execute. Such descriptions can also be produced automatically by computing a random distribution of sensors on a surface, and a connectivity based on the wireless communication capabilities of the nodes. The behaviour associated with each node can be implemented using Occam[15] procedures multiple behaviours can be bundled in a library from which we will call them according to the topology specification. Using this scheme we implemented three routing algorithms (RIP, AODV, DSDV) and used them for the first simulations. In Listing 1.2 we can see the Occam[15] protocol used for the AODV routing algorithm. The messages circulating in the network are: – – – – – –

RREQ - for requesting routing information; RREP - for answering a RREP message; RERR - for signalling the nodes that a route became unusable; HELLO - is a special message of RREQ type used to detect the neighbourhood; route - is a message containing the routing table of a node update - is a message containing information for updating a specific route in the network.

PROTOCOL someNetwork .AODV CASE r r e q ; RREQ r r e p ; RREP r e r r ; RERR p a q u e t ; PAQUET h e l l o ; HELLO r o u t e ; [ max . t a b l e ]AODV. ROUTE u p d a t e ; AODV. ROUTE : PROC AODV. r o u t e r (VAL INT i d , [ ]CHAN OF someNetwork .AODV i n ? , [ ]CHAN OF someNetwork .AODV o u t ! )

Listing 1.2. AODV protocol and procedure header

In the next section we are presenting a complete environment developed around this simple scheme, capable of: – representing hierarchical networks; – composing heterogeneous behaviours expressed in different programming languages (Smalltalk, SyNe, Occam, etc); – simulating the systems at different levels; – generating code for wide variety of targets.

6 Avel-SyNe: Process Network Modelling In this section a flow to study algorithms and protocols for wireless sensor networks and a framework using this flow are presented. The aim of this approach is to provide an infrastructure for analysing the issues arising while developing regular or irregular network architectures. To validate a network architecture, the presented approach is taking in account two proof techniques: formal validation and simulation. The formal validation aspect is particularly important knowing that, in the literature, only a few projects take this proof method into account, due to the complexity of the analysed systems. Regarding the network simulation, we can easily find a large set of network simulators, but none of them (as far as we know) is trying to synthesise hardware architectures for simulation purposes, thus we believe that this approach needs, also, to be investigated. The model proposed is the following: the sensor nodes are seen as a set of nodes in a graph where links represent the connectivity between two sensor nodes. The behaviour of each node is seen as a state machine that is changing its state, starting from a start state, according to the messages received (from the other nodes) and the current internal state. Topology (Avel)

Avel object model

Behaviours (SyNe)

Object model builder

SyNe object model

Object model Connectivity + Behaviours

CDFG model

CDFG builder

Complete CDFG Scheduling

Code generator

Simulator

OCCAM Program Execution

Chronograms Execution trace

Synthesis tools

Fig. 7. Generation of a CDFG from an Avel-SyNe specification.

Using this model an integrated environment (see Figure 7) was developed. The main idea is to separate the topology description from the node behaviour description. By doing this, the framework, enable the user to use the same node behaviour and see how the algorithm adapt to the topology changes. Or using the same topology the user can observe the comportment of different distributed algorithms on this topology.

The basic flow, presented in Figure 7, is to start from the abstract description of the topology and nodes’ behaviour (the same behaviour for all nodes or different behaviour), generate an internal representation of the network (a representation that may be formally validated) and from this internal representation produce a runnable target code (Occam, Handel-C, etc). The network simulation is done by running the generated code. The traces produced are, then analysed in the framework, and the user is presented the results (graphs, UI state changes, etc). The prototype framework was developed using the Smalltalk object-oriented programming language. At the moment the framework uses only the synchronous communication model, but in the future other communication models might be implemented too. In the following sections the most important aspects of the framework are described. The description flow will follow the Figure 7, so we will start with the topology and behaviour specification, then we will present the process architecture model. Starting from this internal representation we will show how the target code/architecture gets generated. The Occam simulation is the last aspect discussed in this section. This section will end presenting some of the results obtained using this framework. 6.1 Topology and Behaviours Description of Process Networks This section presents the concept and the syntax of the coordination language Avel. Then the way of describing behaviours and the syntax for creating libraries are detailed with an emphasis on the behavioural description language named SyNe. The Avel Coordination Language. Avel stands for A Very Easy Language and aims at simplifying the composition of processing units by the specification of hierarchical processes viewed as components. This kind of organisation abstracts the complexity of system composed of several sub-systems. The Avel framework enables to model distributed applications and then generate a representation of applications in an intermediate format: a Control Data Flow Graph. For a detailed description of the CDFG model the reader can refer to [63]. In later stages the CDFG is taken as input of a simulator for behavioural verification and also of back-end tools such as code generators or synthesisers for targeting hardware. An Avel description specifies only the interconnections between the processing units resulting in a network of empty boxes. The basic entity is the process which is considered as a possibly hierarchical component defining a set of input and output ports. Channels establishing a link between two ports perform the communications between processes. Behaviours are contained in external libraries and linked to atomic black-box processes so-called primitive processes. This kind of process represents the leaf of the hierarchical model. The declaration of a primitive process is given by listing 1.3. The process name is used as an identifier in the network. To simplify connections between nodes, only output’s destinations are declared. A connection is specified by the names of the destination process and the number of its input port. The order of the connections is important because the position in the list determined the number of the output port used. Behaviour is linked to a process by the specification of its name

Process Name { O ut put C onnect i ons }[ Behaviour ( arguments ) ]

Listing 1.3. Declaration of a primitive process. The behaviour is linked by its name and optional arguments can be passed.

enabling to retrieve it in the corresponding library. If it is necessary arguments can also be passed similarly to a classical function call. For describing hierarchical processes the syntax remains exactly the same except that the behaviour is replaced by the description of a sub-network. To manage the input and output ports of a hierarchy only the first encapsulated process is connected to the input and similarly only the last process is connected to the output. That is, the distribution of the input data of a hierarchy and the merging of the outputs of the sub-network has to be done by specific processes. To reuse predefined network of processes and to factorise complex description a process can be declared outside the main process and further reused just by a link to its name. Using alias processes as declared in the listing 1.4 does this.

Process Name ( pr oces s name ) { O ut put C onnect i ons }

Listing 1.4. Declaration of an alias process.

Only the process aliased is specified by its name as well as the output connections of this new process. Obviously alias process shows a great interest for reusing hierarchical processes. The following example described in listing 1.5 shows a complete topology specified in Avel. Basically, a network of processes is encapsulated in a main hierarchy, which is NetworkExample1 here. At the first level of hierarchy the system is composed of five processes: NodeX, NodeY are atomic processes and hierA, hierB, hierC are hierarchical. The process hierA is an alias on hierZ process declared outside the main hierarchy. It is also possible to reuse directly definitions declared inside the same level of hierarchy. Unlike hierZ in this case the scope is limited to a hierarchical level, for example hierC reuses the declaration of hierB. A graphical representation of the network described above is given by figure 8. Figure 8 represents the concrete network of processes produced from the Avel description. As you can see only the processes declared in the main hierarchy, which is always the last in the description (here NetworkExample), are taken into account. We can also notice that hierB and hierC are equal since the latter is an alias on the first. Describing libraries of behaviours. The behaviours associated to atomic processes can be specified in different formalisms (e.g. Smalltalk, SyNe), giving the possibility to

#IMPORT b e h a v i o u r s h i e r Z {} [ Node1 {Node2@1} [ p r o c 1 ( 2 , 4 ) ] Node2 {} [ p r o c 2 ( ) ] ] NetworkExample {} [ NodeX {NodeA@1 NodeB@1} [ procX ( ) ] h i e r A ( h i e r Z ) { Join@1 } h i e r B { hierC@1 } [ NodeA {NodeB@1} [ procA ( ) ] NodeB {} [ procB ( ) ] ] h i e r C ( h i e r B ) {NodeY@2} NodeY {} [ procY ( ) ] ]

Listing 1.5. Example of topology.

NetworkExample NodeX

hierA

hierB

Node1

NodeA

Node2

NodeB

hierC NodeA

NodeB

NodeY

Fig. 8. Graphical representation of the hierarchical process network described in listing 1.5.

choose the best way to express the task performed by the set of processes. For example a given network might be dedicated to the control of computing processes according to a specific model of computation e.g. the Synchronous Model, as we will detail in the sequel. An imperative language such Smalltalk or C can express the computations, however only a subset of such a language is available. The reason of this is to take advantage of the expressiveness of the syntax, but not give access to unsuited features for this context e.g. allowing side-effects by the use of global variables. Also the computation can be expressed using SyNe language, a behavioural description language that permits automaton composition without side-effects (dead-locks, shared variables, etc). The behavioural code is encapsulated in a structure similar to the declaration of a function. Behaviours are declared in a separate file and have to respect the format defined in listing 1.6.

Behaviour name ( arguments ) ( i n p u t p o r t s ) ( output p o r t s ) ( f o r m a l i s m t y p e ) { ” s o u r c e c o d e o r f i l e name ”}

Listing 1.6. Declaration of a behaviour in a library.

A name is associated to each behaviour in order to retrieve it from an Avel description. It also declares the input and output ports which are reused in the behavioural code for sending and receiving values. Currently the formalism types take into account are Smalltalk, SyNe and STEP. SyNe is a specific programming language that is targeted for control operations. The interested reader can find more details about SyNe in the following section. SyNe: Behaviour Description Language. The purpose of this section is to describe the SyNe behaviour description language, a language based on the automaton description used in the synchronous network model[53]. This model is used because it is a simple model with a high level of abstraction that is able to describe complex behaviours. Also, some formal verification methods, like invariant assertions, can be used in conjunction with this model in order to validate or invalidate certain assumptions about the system being developed. Another advantage of this language is that it takes out the communication aspect of a process. Thus the behaviour programmer can concentrate only on the automaton description leaving the communication aspects to the underlying system. This language can be used to describe, for example, a distributed controller for coordinating processes or distributed debug facilities. Automaton Description Model. This model states that each process is composed formally of the following components: – states, a (not necessarily finite) set of states; – start, a state from states set known as start state; – msg func, a message generation function mapping states states x out-nbrs to elements of M ∪ null, out-nbrs denotes the outgoing neighbours of the node, that is,

the links from the node to its neighbours, M is a fixed message alphabet used for the inter-process communication; – trans func , a state transition function mapping states and vectors (indexed by innbrs ) of elements of M ∪ null to statesi , in-nbrs represents the incoming neighbours of the node, that is, those links going from the neighbours of node to the node itself, M is a fixed message alphabet used for the inter-process communication. So basically, each process has a set of states, among which is distinguished a start state. The fact that the set of states need not to be finite is particularly important since it permits to model unbounded data structures such as counters. The message function specifies, for each state and neighbour, the message that is going to be sent by the process i to the indicated neighbour. The state transition function specifies, for each state and collection of incoming messages, the new state to which the process i is moving. This model has an important characteristic, the composition of such automatons led to a deterministic way of evolution at the network level. Basically from a given set of start states associated with the network processes, applying the msg func and trans func, the computations unfold in a unique way. For more details on this model, or on extensions of this model, the interested reader is directed to look in [53].

I n i t i a l i s a t i o n block execution while ( t r u e ){ parallel { send messages t o n e i g h b o r s r e c e i v e m e s s a g e s from n e i g h b o r s } Message G e n e r a t i o n b l o c k e x e c u t i o n T r a n s it io n Function block execution }

Listing 1.7. SyNe execution mechanism

The execution of a SyNe process starts with the execution of the initialisation block, which initialise the process automaton to the start state. Afterward the process enters an infinite cycle composed of, mainly, 3 tasks: communication with the neighbours, execution of the message generation block, and execution of the transition function block. This three task can, eventually, be executed in pipeline, in order to speed up the system. The execution pattern for a SyNe program is depicted in the Listing 1.7. Example of process description. In Listing 1.8 the SyNe implementation of the LCR leader election algorithm[53] is shown. And we can easily see the name of the behaviour is Leader, we have the channel left as input and the channel right as output, we expect an integer constant, idIn, as UID. Afterward we can identify the state description part (along with the initialisations), the message generation part and the transition part pre-

L e a d e r ( i n t i d I n ) ( c h a n i n t l e f t ) ( c h a n i n t r i g h t ) ( SyNe ) { [ declaration ] bool l e a d e r := f a l s e . i n t send . in t id . [ initialization ] id := i dI n . send := i d I n . [ messageGeneration ] r i g h t a t : 1 put : send . [ transitionFunction ] | var1 | s e n d := −1. var1 := l e f t a t : 1. ( v a r 1 ˜ = −1) ifTrue : [ var1 > i d i f T r u e : [ send := var1 ] . var1 = id i f T r u e : [ l e a d e r := t r u e ] ] . }

Listing 1.8. SyNe implementation of LCR algorithm

sented in the formal algorithm. The Avel program presented in Listing 1.9 composes 4 instances of this automaton in a ring structure.

#IMPORT L e a d e r Leader Election P r o c 1 { Proc2@1 } P r o c 2 { Proc3@1 } P r o c 3 { Proc4@1 } P r o c 4 { Proc1@1 } ]

{} [ [ Leader ( 5 ) ] [ Leader ( 1 ) ] [ Leader ( 2 ) ] [ Leader ( 3 ) ]

Listing 1.9. Avel Ring with 4 Processes executing LCR algorithm

6.2 Code Generation and Simulation This section details the way programs specified using Avel formalism could be analysed, tested or compiled to target architectures. Firstly the CDFG model is briefly presented in the next section, and, afterward, a CDFG simulator is presented. We developed a compiler for Avel programs that generate compilable Occam code, which will be presented in a later section. For the MORPHEUS project1 a synthesis system was 1

http://morpheus-ist.org

developed being able to generate hardware from CDFG specifications so the CDFG generated from Avel specifications can be translated into hardware components, but that is out of the scope of this paper. CDFG model. The CDFG model definition and tools development have been initiated thanks to the MORPHEUS Integrated Project. One objective of the project is to produce a consistent, reproducible set of tools allowing programming a complex heterogeneous architecture from high-level methodologies, ensuring efficiency of the execution and portability of the created development environments.

Fig. 9. CDFG example showing two processes communicating through channels.

Algorithms to be mapped on the accelerators and synthesis techniques are based on an intermediate format for Control Data Flow Graph (CDFG). The CDFG representation is obtained from a high-level language description of the CDFG using some specific APIs. The supported languages are Java, Smalltalk and C++. The CDFG model captures the control, the data flow, and the program structure due to hierarchical nodes. The structure of the algorithm is reflected from conditional statements, loops, function call, etc. Concurrency appears at two levels: application process nodes and a control structure inside the CDFG (ParallelNode). In more details, this CDFG gives support for:

– Hierarchies: the ability to define graph hierarchies such as Processes. – Concurrency: with sub nodes that contain sub CDFGs to be executed in parallel. – Communication: nodes defined to represent data exchanges with implicit synchronisation, this is implemented via processes communicating via channels (CSP like formalism): sendNode and ReceiveNode. – Computation operation: to cope with the computations performed by the application: the generic ComputeNode in which we specify the operation to implement. – Control operations: dynamic (do while and while do), static for loops, tests (if then else) and switch (case). – Function calls. – Memory operations: reading and writing data from and to arrays. – Data types: many types are supported to ease the CDFG specification; int, bool, float, collection, enum, etc. In Figure 9, two processes are represented by two hierarchical nodes named Process Node n. They each hold a finite loop represented by the hierarchical nodes FixedLoopNode n. These nodes hold a sub-hierarchy corresponding to their loop bodies that encapsulate compute nodes. Communication nodes are ReceiveNode n for receiving and SendNode n for sending values. Communications are performed through communication channels, which are channel68 and channel35. Channels implement a rendezvous semantic, as defined in the CSP model. In Figure 10 we can see the CDFG generated from the SyNe code in Listing 1.8. The communications are embedded into a ParallelNode. The ports presented in the figure represent the composition elements, such that when composing two behaviours we will actually identify and connect the ports with channels. The communications, message generation function and the state transition function are embedded into a ParallelNode in order to execute them in pipeline. CDFG Generation. Figure 7 depicts the Avel-SyNe flow producing a compliant CDFG for simulation and code generation. The entry point is the Avel-SyNe description of the processes topology and the basic behaviours available. From this description an object model is built holding the information about the connectivity of the processes and the behaviours linked to each atomic process. As described in the section describing the Avel language the CDFG is used as a common representation for all the behavioural descriptions that can be defined by different syntax. At this stage each behaviour is represented by a corresponding unconnected CDFG generated from the textual description. Further, the CDFG builder connects the CDFGs to each other according to the connectivity information specified in the object model. It enables to connect all the channels and as a result to produce a complete graph representing the concurrent system. CDFG Simulation. In order to obtain a running system from an Avel-SyNe description a CDFG simulator is used (see Figure 11). The simulation of a concurrent system is based on the interpretation of multi-processes CDFGs by an event-driven simulator. All the processing elements of the CDFGs such as processes, operators, control structures

Fig. 10. The CDFG representation of the behaviour presented in Listing 1.8.

leader

Memory

false

1

INT BOOL Memory

Memory

INT

WriteMemoryNode_43

INT INT

Memory

Memory Memory

Memory

Initialisations

BOOL

WriteMemoryNode_39

1

INT Memory

SequentialNode

Memory Memory Memory

Memory

Memory Memory

INT

idIn

Memory

left

Memory

Memory

Memory

Memory

Memory

1

Memory

Memory

Memory Memory

Memory

Memory Memory

true

Memory

Memory INT INT

1

Memory

INT

Memory

INT

INT Memory

INT INT

INT

BOOL

INT

INT

INT

INT

INT

BOOL

~=

INT INT

INT INT

SequentialNode

INT INT

INT INT

-1

INT

INT

State transition function

BOOL

INT

1

SequentialNode

Memory

Memory INT

LoadMemory_Node_183

TestNode

=

Merge_Node_197

BOOL

WriteMemoryNode_192

BOOL

Merge_Node_202

1

BOOL Memory INT

true

SequentialNode

Memory

Memory

Memory Memory

Memory

SequentialNode

WhileLoopNode

LoadMemory_Node_126

Memory

Memory

BOOL

INT

INT

INT

INT

INT

>

INT INT

INT

LoadMemory_Node_157

Memory

SequentialNode 1

Memory

INT

INT

TestNode

SequentialNode

TestNode

SequentialNode

SequentialNode

SequentialNode

Local memories (variables)

INT

Merge_Node_171

INT

WriteMemoryNode_167

Memory

SequentialNode

Memory

Memory

Memory Memory

System Process_Node_2

-1 INT INT Memory

INT

WriteMemoryNode_118

1

INT

INT

1

INT

INT

Memory

INT

INT

WriteMemoryNode_107

INT

Memory

Memory

Memory

Memory Memory

LoadMemory_Node_105

INT

1

SequentialNode

SequentialNode

INT

INT

LoadMemory_Node_77

INT

INT

Memory

INT

INT

SequentialNode

INT

ParallelNode_82

Memory

send

INT

INT

INT

WriteMemoryNode_89

Memory

INT

ReceiveNode_Node_88_left1

Memory

Memory Memory

INT Memory

1

SequentialNode

SendNode_Node_79_right1

INT

INT

ParallelNode_71

Communications

Memory

INT

INT

INT

Memory INT ParallelNode_66

Memory

Memory

Memory

Memory

left1

MemoryINT

1

id

Memory

Memory

INT Memory

Memory INT

Memory

Memory INT Memory

Memory INT

right1

Ports

Message generation function

Memory

INT Memory

right

Memory

Memory

and the communication channels are emulated by corresponding discrete events. The simulation is driven according to the scheduling imposed by the sequencing nodes as well as the dynamic synchronisations performed by the rendezvous semantic of the communications. As a result, simulating enables a complete execution of the Avel-SyNe concurrent system and provides a mean for behavioural verification by the production of chronograms. Interpretation of a CDFG enables to perform behavioural verifications through generated chronograms depicting the execution of each node. The interpreter takes into account three kinds of CDFG nodes: operator nodes such as arithmetic operations, communication and sequencing nodes (parallel/sequential nodes). From a software engineering point of view, it is based on the visitor design pattern, which visits recursively the hierarchy of the CDFG. During the visit events are queued according to the node type encountered. This section describes the three interpretation techniques performed by the interpreter in order to handle the CDFG’s elements. At the lower hierarchical level of the CDFG the operators are atomic nodes such as additions, multiplications, memory accesses. To emulate the execution of each operator a latency value is associated to each node. This value characterised the duration of the simulation event created for the execution of the corresponding node. The execution of an operator is illustrated by the Smalltalk code in the listing 1.10.

Listing 1.10. Execution of a CDFG operator by the creation of a delay in the simulation. s i m u l a t i o n d e l a y F o r : ( s i m u l a t i o n g e t L a t e n c y F o r : aNode ) .

The object simulation is the kernel of simulation providing the methods for handling events. For example imposing delays on the simulation or scheduling event for a precise date. The message delayFor: performed a wait operation lasting the number of time units specified by the argument. Here the latency value is retrieved in a hash table associating the node identity and the latency value. The control instructions are directly mapped to Smalltalk constructions. For example a fixedLoopNode, which is a hierarchical node representing a loop with a fixed number of iterations, is executed as shown in the listing 1.11.

Listing 1.11. Execution of a loop. ( f i x e d L o o p N o d e s t a r t ) t o : ( f i x e d L o o p N o d e end ) do : [ : i | f i x e d L o o p N o d e s u b O p e r a t o r s do : [ : op | op e x e c u t e ] ]

The information about the number of iterations are extracted from the CDFG node and used for executing the sub-operators of the loop. The same method is used for the conditional loops and if-then-else instructions with the evaluation of the conditions.

Fig. 11. Chronogram generated by the simulation of a CDFG for an Avel-SyNe process network.

The communication node might be considered as a special kind of atomic node. Indeed, unlike the operator node, described above, whose latency is statically defined, the latency of a communication node is determined at runtime by rendezvous synchronisations. The communications between the send and receives nodes are effectively performed by the use of channels implemented as simulation objects. That is, the channel send and receive operations use implicitly the methods defined by the simulation kernel in order to apply delays. The control flow of the interpretation of the CDFG is partly driven by the semantic of the parallel and sequential node added by the scheduling stage (the control instructions are described above). These nodes are hierarchical and imposed static synchronisations to their sub-operators unlike the channels of communication which induced dynamic synchronisations. The interpreter defines two different behaviours for the sequential and parallel hierarchical nodes. The former contains an ordered collection of parallel nodes. This collection is read sequentially and each parallel node is fired one by one. The latter contains a collection of atomic or sequential nodes and starts simultaneously its sub-operators then waits for the completion of all the operators. The execution of a sequential node can be simply described in Smalltalk, as in the listing 1.12. The sub-operators of the sequential node sequentialNode are executed one by one in an iterative loop. If op is hierarchical the interpretation continues in the next level of hierarchy and so on. At the previous level of hierarchy there is no distinction between

Listing 1.12. Execution of a sequential node. s e q u e n t i a l N o d e s u b O p e r a t o r s do : [ : op | op e x e c u t e ]

an atomic and a hierarchical node. Concerning the parallel the algorithm is given the listing 1.13.

Listing 1.13. Execution of a parallel node. nbOps : = p a r a l l e l N o d e s u b O p e r a t o r s s i z e . sem : = Semaphore new . currentTime := s i m u l a t i o n time . ” Scheduling ” p a r a l l e l N o d e s u b O p e r a t o r s do : [ : op | s i m u l a t i o n s c h e d u l e : [ op e x e c u t e . sem s i g n a l . ] at : currentTime ] . ” Synchronization ba r r i e r ” nbOps t i m e s R e p e a t : [ sem w a i t ] .

As you can see the algorithm is divided into two parts. The first one corresponds to the scheduling of the sub-operators at the current virtual time given by simulation time. The creation and the addition of an event in the queue is performed by the message schedule:at:. It takes as inputs a Smalltalk block which is a delayed function and a starting time. The block executes its assigned sub-operator and sends a signal to a semaphore shared by all the scheduled blocks. This semaphore is used to implement a synchronisation barrier in the second part of the algorithm. That is, once every blocks are scheduled the interpreter waits for a signal of termination from each sub-operator ensuring the complete termination of the parallel node. Occam code generator. To implement the network model using Occam, concurrent sequential processes model we represented each network node as a process and the links between them as channels (for the synchronous communication model) or even processes (for the asynchronous communication model). The generation of Occam code can be divided in two parts: concurrent system synthesis and behaviour synthesis. The first one deals with the emission of the code representing the topology specifications, while, the second one deals with the emission of the Occam procedures representing the node’s local behaviour. Concurrent System Synthesis. The network architecture is represented by the Occam “main” procedure, where the connectivity declaration and the network nodes’ parallel execution will start.

PROC ExTopology (CHAN OF BYTE kyb , s c r , e r r ) [ n r N o d e s ] CHAN OF p r o t o dummyScreen : −− C h a n n e l d e c l a r a t i o n s CHAN OF p r o t o Node2.Node1 : CHAN OF p r o t o Node2.Gateway1 : CHAN OF p r o t o Node2.Node3 : CHAN OF p r o t o Node1.Node2 : CHAN OF p r o t o Node1.Node3 : CHAN OF p r o t o Node3.Node2 : CHAN OF p r o t o Node3.Gateway1 : CHAN OF p r o t o Gateway1.Node1 : −− C h a n n e l t a b l e d e c l a r a t i o n f o r n o d e s N o d e 2 . i n IS [ Node1.Node2 , Node3.Node2 ] : N o d e 1 . o u t IS [ Node1.Node2 , Node1.Node3 ] : N o d e 3 . i n IS [ Node2.Node3 , Node1.Node3 ] : N o d e 2 . o u t IS [ Node2.Node1 , Node2.Gateway1 , Node2.Node3 ] : G a t e w a y 1 . i n IS [ Node2.Gateway1 , Node3.Gateway1 ] : N o d e 3 . o u t IS [ Node3.Node2 , Node3.Gateway1 ] : G a t e w a y 1 . o u t IS [ Gateway1.Node1 ] : N o d e 1 . i n IS [ Node2.Node1 , Gateway1.Node1 ] : −−Program body PAR E x T o p o l o g y r i n g S c r e e n ( dummyScreen , s c r ) ProcN2 ( 1 , N o d e 2 . i n , N o d e 2 . o u t ) ProcN1 ( 2 , N o d e 1 . i n , N o d e 1 . o u t ) ProcN3 ( 3 , N o d e 3 . i n , N o d e 3 . o u t ) ProcGW ( 4 , G a t e w a y 1 . i n , G a t e w a y 1 . o u t ) −− End o f program body :

Listing 1.14. Occam topology declaration

Behaviour synthesis. The developed, object oriented, framework is used to translate the CDFG representation of the behaviour into Occam code. The processes executed at each node are represented, as was said before, by Occam procedures. For example, the generated procedure for the leader election algorithm that was presented earlier (see section 6.1) is presented in Listing 1.15.

−− P r o c e d u r e d e f i n i t i o n s PROC L e a d e r (VAL INT i n . i d , [ ]CHAN OF p r o t o i n , [ ]CHAN OF p r o t o out ) −− m e s s a g e s d e c l a r a t i o n T e s t [ 1 ] INT i n M e s s a g e s : [ 1 ] INT o u t M e s s a g e s : −− s t a t e v a r i a b l e s d e c l a r a t i o n L e a d e r INT i d , n e w . i d : INT send , n e w . s e n d : BOOL s t a t u s , n e w . s t a t u s : −− Code o f p r o c e d u r e L e a d e r SEQ −− s t a t e v a r i a b l e s i n i t i a l i z a t i o n L e a d e r id := i n . i d send := i n . i d s t a t u s : = FALSE WHILE TRUE SEQ PAR PAR i =0 FOR SIZE i n i n [ i ] ? inMessages [ i ] PAR j =0 FOR SIZE o u t out [ j ] ! outMessages [ j ] SEQ PAR outMessages := L eader. messageGenerati on ( i d , send , s t a t u s , i n M e s s a g e s ) new.id , new.send , n e w . s t a t u s := L e a d e r . t r a n s i t i o n ( i d , send , s t a t u s ) i d , send , s t a t u s : = n e w . i d , n e w . s e n d , n e w . s t a t u s :

Listing 1.15. Occam code for the Leader behaviour

This procedure calls two occam functions Leader.messageGeneration and Leader.transition that represent the message generation function and, respectively, state transition function described earlier on. The generated Occam functions are presented in Listing 1.16 and Listing 1.17.

INT FUNCTION L e a d e r . m e s s a g e G e n e r a t i o n (VAL INT a i d , VAL INT send , VAL BOOL s t a t u s ) INT o u t p u t V a l u e : VALOF SEQ SEQ out put V al ue := send RESULT o u t p u t V a l u e :

Listing 1.16. Occam code generated for the message generation function

6.3 Process Network Modelling for Sensor Networks

Sensor network model

Topology generator

Topology (Avel)

Behaviours (SyNe)

Object model builder

Avel object model

SyNe object model

Object model Connectivity + Behaviours CDFG model

Topology viewer

CDFG builder Complete CDFG Scheduling

Code generator

Simulator

OCCAM Program Chronograms Execution trace Execution

Synthesis tools

Trace viewer

Avel−SyNe Trace analysis

Executable code

System execution

Fig. 12. Avel-SyNe support for sensor networks

In the last section we described a development environment for modelling distributed applications as a set of communicating processes. A generic retargetable backend enables the generation of executable systems on different targets (Occam, FPGA, etc). To help the algorithm development for sensor networks a small number of tools had to be added around the Avel-SyNe environment. These tools are identified in Figure 12.

INT , INT ,BOOL FUNCTION L e a d e r . t r a n s i t i o n (VAL INT a i d , VAL INT a s e n d , VAL BOOL a s t a t u s , VAL INT a n I n p u t ) INT i d : INT s e n d : BOOL s t a t u s : BOOL v a r 2 : BOOL v a r 4 : BOOL v a r 6 : VALOF SEQ id := aid send := asend s t a t u s := a s t a t u s SEQ s e n d : = ( −1) SEQ v a r 2 : = ( a n I n p u t <>(−1) ) IF var2 SEQ SEQ v a r 4 : = ( a n I n p u t >a i d ) IF var4 SEQ SEQ send := a n I n p u t SEQ TRUE SKIP SEQ var6 := ( anInput = aid ) IF var6 SEQ SEQ s t a t u s : = TRUE SEQ send := a i d SEQ TRUE SKIP TRUE SKIP RESULT i d , send , s t a t u s :

Listing 1.17. Occam code generated for the state transition function

A sensor network model enables the automatic topology generation according to different configuration of the sensor systems (sensor field area, number of sensor, number of sinks, etc). The trace analysis tools permits to observe the evolution of the sensor network, sending a different signal to the trace viewer and topology viewer. Events like the network congestion, power failures, etc, can be easily detected using this tool. After implementing the nodes behaviour the user of the system can simply use the visual interface to generate and simulate different sensor field configurations. The system generates the Occam code equivalent to the system. This code contains software probes and a routine that multiplex the signals from the probes to the trace analysis tool. In the Figure 13 we can see the framework running. It generated 150 sensor nodes, from which 50% gateways, scattered over a 2000x2000 meters area. The connectivity between the nodes is calculated taking in account their signal power (which, for the moment, is equal with the radius of the area that can be sensed) 150m for normal nodes (blue dots) and 200m for gateways (green dots). The white zones in the picture represent the zones that are not covered by this node distribution. The routing algorithm that is executed on the network nodes is RIP. In the bottom part of the screen we are seeing the messages received by the gateways. These messages represent the sensed data sent by the sensor nodes. We implemented a set of routing protocols (i.e. RIP, AODV, DSDV) and we tested these algorithms using multiple topologies generated by the framework. The time needed for topology description coding was reduced from several minutes (for a simple topology) to seconds using the framework. For the behaviours implemented using the framework we observed, with great satisfaction, the fact that the formal description of the state machines associated to the behaviours is almost the same as our description. This fact is helping, the developers using our framework, by reducing the number of errors due to implementation issues. We, also, could easily correct the implementation errors in the implemented routing protocol using the simulator part of the framework.

7 Conclusions and Future Work In this paper we have presented a comprehensive survey on wireless sensor network, giving some historical information in the development of this field. Additionally design issues, that need to be taken into account when developing wireless sensor networks, were presented. The state of the art regarding middleware applications for sensor networks was presented in section 4.1. Formal models and existing validation tools were described in section 4.3. We ended our discussion on wireless sensor network presenting a framework developed by us that intend to ease the development of sensor networks protocols and algorithms. Sensor networks have been addressed in a structured way separating process topology from local behaviours. This separation is based on a simple model binding processes together and binding processes to their behaviour. This mechanism enables simulation of distributed model by interpretation, or by code synthesis. We have experi-

Fig. 13. Simulator showing a random sensor field, and states of routing processes from the RIP algorithm

mented automatic code synthesis from a formalism close to N. Lynch[53] synchronous model automata based on CDFGs. Regarding the presented framework, the intention is to extend the framework to up-to-date targets such as multi-cores and hardware architectures (FPGAs). There are intensive developments in the direction of heterogeneous reconfigurable SoC platforms such as the European project MORPHEUS2 . Furthermore, we plan to include formal validation techniques [56, 39] to ensure the validity of cooperative and system behaviours.

References 1. K. Akkaya and M. Younis. A Survey of Routing Protocols in Wireless Sensor Networks. Elsevier Ad Hoc Network Journal, 3/3:325–349, 2005. 2. I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. Wireless Sensor Networks: a Survey. Computer Networks, 38(4):393–422, 2002. 2

http://morpheus-ist.org

3. Jamal N. Al-Karaki and A.E. Kamal. On the Correlated Data Gathering Problem in Wireless Sensor Networks. Proceedings of the Ninth IEEE Symposium on Computers and Communications, 2004. 4. Jamal N. Al-Karaki, Raza Ul-Mustafa, and Ahmed E. Kamal. Data Aggregation in Wireless Sensor Networks - Exact and Approximate Algorithms. Proceedings of IEEE Workshop on High Performance Switching and Routing (HPSR), 2004. 5. J.N. Al-Karaki and A.E. Kamal. Routing Techniques in Wireless Sensor Networks: a Survey. IEEE Wireless Communications, 11(6):6–28, 2004. 6. L. Bao and J.J. Garcia-Luna-Aceves. A New Approach to Channel Access Scheduling for Ad-hoc Networks. in Proceeding of the 7th Annual International Conference on Mobile Computing and Networking, pages 210–220, 2001. 7. Rimon Barr, John C. Bicket, Daniel S. Dantas, Bowei Du, T.W. Danny Kim, Bing Zhou, and Emin Gun Sirer. On the Need for System-Level Support for Ad hoc and Sensor Networks. ACM SIGOPS Operating Systems Review, 36(2):1–5, April 2002. 8. P. Bonnet, J. Gehrke, and P. Seshadri. Towards Sensor Database Systems. Proc. 2nd International Conference Mobile Data Management (MDM 01), 2001. 9. David Braginsky and Deborah Estrin. Rumor routing algorithm for sensor networks. WSNA, 2002. 10. N. Bulusu, J. Heidemann, and D.Estrin. GPS-less low cost outdoor localization for very small devices. Technical Report 00-729, Computer Science Departament, University of Southern California, 2000. 11. C.-F.Chiasserini and M. Garetto. An Analytical Model for Wireless Sensor Networks with Sleeping Nodes. Mobile Computing, IEEE Transactions on, 5, december 2006. 12. J.-H. Chang and L. Tassiulas. Maximum Lifetime Routing in Wireless Sensor Networks. Proceedings Advanced Telecommunications and Information Distribution Research Program (ATIRP2000), 2000. 13. B. Chen, K. Jamieson, H. Balakrishnan, and R. Morris. SPAN: an Energy-efficient Coordination Algorithm for Topology Maintenance in Ad-hoc Wireless Networks. Wireless Networks, 8:481–494, 2002. 14. M. Chu, H. Haussecker, and F. Zhao. Scalable Information-Driven Sensor Querying and Routing for ad hoc Heterogeneous Sensor Networks. The International Journal of High Performance Computing Applications, 16, 2002. 15. Inmos Corporation. Occam 2 reference manual. Prentice Hall, 1988. 16. S. Dulman, T. Nieberg, J. Wu, and P. Havinga. Trade-Off between Traffic Overhead and Reliability in Multipath Routing for Wireless Sensor Networks. WCNC Workshop, 2003. 17. I.A. Essa. Ubiquitous Sensing for Smart and Aware Environments. IEEE Personal Communications, pages 47–49, October 2000. 18. A. Bakshi et al. The Abstract Task Graph: A Methodology for Architecture-Independent Programming of Networked Sensor Systems. Proc. 2005 Workshop Ent-to-end, Sense-andRespond Systems, Applications and Services (EESR 05), USENIX, pages 19–24, 2005. 19. E. Souto et al. A Message-Oriented Middleware for Sensor Networks. Proc. 2nd International Workshop Middleware for Pervasive and Ad-Hoc Computing (MPAC 04) ACM Press, pages 127–134, 2004. 20. K. Romer et al. Generic Role Assignment for Wireless Sensor Networks. Proc. ACM SIGOPS European Workshop, pages 7–12, 2004. 21. K. Whitehouse et al. Semantic Streams: A Framework for Declarative Queries and Automatic Data Interpretation. tech. report MSR-TR-2005-45, Microsoft Research, 2005. 22. N. Sadagopan et al. The ACQUIRE mechanism for efficient querying in sensor networks. in the Proceedings of the First International Workshop on Sensor Network Protocol and Applications, 2003.

23. R. Gummadi et al. Macro-programming Wireless Sensor Networks Using Kairos. Proc. International Conference Distributed Computing in Sensor Systems (DCOSS 05), pages 126– 140, 2005. 24. T. Abdelzaher et al. EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Networks. Proc. 24th Int’l Conf. Distributed Computing Systems (ICDCS 04), IEEE Press, pages 582–589, 2004. 25. T. He et al. SPEED: A stateless protocol for real-time communication in sensor networks. in the Proceedings of International Conference on Distributed Computing Systems, 2003. 26. W.B Heinzelman et al. Middleware to Support Sensor Network Applications. IEEE Network, 18:6–14, 2004. 27. Q. Fang, F. Zhao, and L. Guibas. Lightweight Sensing and Communication Protocols for Target Enumeration and Aggregation. Proceedings of the 4th ACM International Symposium on Mobile Ad-hoc Networking and Computing (MOBIHOC), pages 165–176, 2003. 28. C.-L. Fok, G.-C. Roman, and C. Lu. Mobile Agent Middleware for Sensor Networks: An Application Case Study. In Proc. of the 4th Int. Conf. on Information Processing in Sensor Networks (IPSN’05), pages 382–387. IEEE, April 2005. 29. F.Ye, A. Chen, S. Liu, and L. Zhang. A Scalable Solution to Minimum Cost Forwarding in Large Sensor Networks. Proceedings of the tenth International Conference on Computer Communications and Networks(ICCCN), pages 304–309, 2001. 30. D. Ganesan, R. Govidan, S. Shenker, and D. Estrin. Highly-resilient, Energy Efficient Multipath Routing in Wireless Sensor Networks. ACM SIGMOBILE Mobile Computing and Communications Review, 5:1125, 2001. 31. L. Girod, T. Stathopoulos, N. Ramanathan, J. Elson, D. Estrin, E. Osterweil, and T. Schoellhammer. A System for Simulation, Emulation, and Deployment of Heterogeneous Sensor Networks. Proc. of SenSys 2004, 2004. 32. G.Simon, P. Volgyesi, M. Maroti, and A. Ledeczi. Simulation-based Optimization of Communication Protocols for Large-scale Wireless Sensor Networks. Proc. 2003 IEEE Aerospace Conference, Big Sky, MT, march 2003. 33. Q. Han and N. Venkatasubramanian. Autosec: An Integrated Middleware Framework for Dynamic Service Brokering. IEEE Distributed Systems Online, 2, 2001. 34. W. Heinzelman, A. Chandrakasan, and H. Balakrishnan. Energy-Efficient Communication Protocol for Wireless Microsensor Networks. Proceedings of the 33rd Hawaii Internation Conference on System Sciences(HICSS ’00), January 2000. 35. W. Heinzelman, J. Kulik, and H. Balakrishnan. Adaptative Protocols for Information Dissemination in Wireless Sensor Networks. Proc. 5th ACM/IEEE Mobicom Conference (MobiCom ’99), Seattle, WA, pages 174–85, 1999. 36. http://www.alertsystems.org. 37. Chalermek Intanagonwiwat, Ramesh Govindan, and Deborah Estrin. Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks. Mobicom, 2000. 38. Y. Iyer, S. Gandham, and S. Venkatesan. A Generic Transport Layer Protocol for Sensor Networks. Proceedings of 14th IEEE International Conference on Computer Communications and Networks, 2005. 39. K.M.Chandy and J.Misra. Proof of Distributed Algorithms : an Exercise. Developments in Concurrency and Communication, 1990. 40. F. Kuhn, R. Wattenhofer, and A. Zollinger. Worst-Case Optimal and Average-case Efficient Geometric Ad-hoc Routing. Proceedings of the 4th ACM International Conference on Mobile Computing and Networking, pages 267–278, 2003. 41. J. Kulik, W. Heinzelman, and H. Balakrishnan. Negotiation-Based Protocols for Dissemination Information in Wireless Sensor Networks. Wireless Networks, 8:169–185, 2002.

42. Philip Levis and David Culler. Mat´e: A Tiny Virtual Machine for Sensor Networks. Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS X), 2002. 43. Philip Levis and Nelson Lee. TOSSIM: A Simulator for TinyOS Networks, 2003. 44. Philip Levis, Nelson Lee, Matt Welsh, and David Culler. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications. Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys 2003), 2003. 45. L. Li and J.Y. Halpern. Minimum-Energy Mobile Wireless Networks Revisited. IEEE International Conference on Communications (ICC), 1:278–283, 2001. 46. Q. Li, J. Aslam, and D. Rus. Hierarchical Power-Aware Routing in Sensor Networks. in Proceedings of the DIMACS Workshop on Pervasive Networking, 2001. 47. S. Li, S. Son, and J. Stankovic. Event Detection Services Using Data Service Middleware in Distributed Sensor Networks. Proc. 2nd International Workshop Information Processing in Sensor Networks (IPSN 03), pages 502–517, 2003. 48. S. Lindsey and C. Raghavendra. PEGASIS: Power-Efficient Gathering in Sensor Information Systems. IEEE Aerospace Conference Proceedings, 3:1125–1130, 2002. 49. J. Liu, D. Nicol, F. Perrone, M. Liljenstam, C. Elliot, and D. Pearson. Simulation Modeling of Large-scale Ad-hoc Sensor Networks. Proc. European Interoperability Workshop 2001, 2001. 50. T. Liu and M. Martonosi. Impala: A Middleware System for Managing Autonomoc Parallel Sensor Systems. Proc. ACM SIGPLAN Symp. Principles and Practice of Parallel Programming (PPoPP 03), pages 107–118, 2003. 51. L. Lopes, F. Martins, M. S. Silva, and J. Barros. A Formal Model for Programming Wireless Sensor Networks. in International Conference on Distributed Computing in Sensor Systems, DCOSS’07, Springer-Verlag, 2007, june 2007. 52. Yan Luo and Jeffrey J.P. Tsai. A Graphical Simulation System for Modeling and Analysis of Sensor Networks. Proceedings of the 7th IEEE International Symphosium on Multimedia (ISM ’05), 2005. 53. Nancy A. Lynch. Distributed Algorithms. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1996. 54. Sam Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong. TinyDB: An Acqusitional Query Processing System for Sensor Networks. ACM Trans. Database System, 2005. 55. A. Manjeshwar and D.P. Agarwal. TEEN: a Routing Protocol for Enhanced Efficiency in Wireless Sensor Networks. 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing, 2001. 56. D. May. Use of Formal Methods by a Silicon Manufacturer, journal = Developments in Concurrency and Communication, editor= C.A.R. Hoare, publisher= Addison-Wesley, year = 1990. 57. Pritish Narayanan, Michael Leuchtenburg, Teng Wang, and Csaba Andras Moritz. CMOS Control Enabled Single-Type FET NASIC. IEEE Computer Society Annual Symposium on VLSI 2008, 2008. 58. R. Newton and M. Welsh. Region Streams: Functional Macroprogramming for Sensor Networks. Proc. 1st Int’l Workshop Data Management for Sensor Networks (DMSN ’04), ACM Press, pages 78–87, 2004. 59. P.C. Olveczky and S. Thorvaldsen. Formal Modeling and Analysis of Wireless Sensor Network Algorithms in Real-Time Maude. Parallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International, pages 25–29, 2006. 60. S. Park, A. Savvides, and M. B. Srivastava. SensorSim: A Simulation Framework for Sensor Networks. In the Proceedings of MSWiM 2000, 2000.

61. L. F. Perrone and D. M. Nicol. A Scalable Simulator for TinyOS Applications. Proc. the 2002 Winter Simulation Conference, 2002. 62. G.J. Pottie and W.J. Kaiser. Wireless Integrated Network Sensors. Communication of the ACM 43 (5), pages 551–558, 2000. 63. Bernard Pottier, Jalil Boukhobza, and Thierry Goubier. An Integrated Platform For Heterogeneous Reconfigurable Computing. ERSA’2007, Las Vegas, 2007. 64. J. Rabaey, J. Ammer, J.L. da Silva Jr., and D. Patel. Pico-Radio: Ad-hoc Wireless Networking of Ubiquitous Low-energy Sensor/Monitor Nodes. Proceedings of the IEEE Computer Society Annual Workshop on VLSI (WVLSI’00), Orlanda, Florida, 2000. 65. V. Rodoplu and T.H. Meng. Minimum Energy Mobile Wireless Networks. IEEE Journal Selected Areas in Communications, 7:133–344, 1999. 66. C. Schurgers and M.B. Srivastava. Energy Efficient Routing in Wireless Sensor Networks. in the MILCOM Proceedings on Communications for Network-Centric Operations: Creating the Information Force, McLean, 2001. 67. C. Schurgers, V. Tsiatsis, S. Ganeriwal, and M.B. Srivastava. Optimizing Sensor Networks in the Energy-Latency-Density Design Space. IEEE Transactions on Mobile Computing, 2002. 68. R.C. Shah and J. Rabaey. Energy Aware Routing for Low Energy Ad-hoc Sensor Networks. IEEE Wireless Communications and Networking Conference (WCNC), 1:350–355, 2002. 69. Xiaolei Shi and G. Stromberg. SyncWUF: An Ultra Low-Power MAC Protocol for Wireless Sensor Networks. Mobile Computing, IEEE Transactions on, 6:115–125, January 2007. 70. Victor Shnayder, Mark Hempstead, Bor rong Chen, Geoff Werner-Allen, and Matt Welsh. Simulating the Power Consumption of Large-Scale Sensor Network Applications. In Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys’04), Baltimore, november 2004. 71. A. Sinha and A. Chandrakasan. Dynamic Power Management in Wireless Sensor Networks. IEEE Design and Test of Computers, 2001. 72. Ahmed Sobeih, Wei-Peng Chen, Jennifer C. Hou, Lu-Chuan Kung, Ning Li, Hyuk Lim, Hung-Ying Tyan, and Honghai Zhang. J-Sim: A simulation and emulation environment for wireless sensor networks. 73. K. Sohrabi and J. Pottie. Protocols for Self-organization of a Wireless Sensor Network. IEEE Personal Communications, 7:16–27, 2000. 74. C. Srisathapornphat, C. Jaikaeo, and C. Shen. Sensor Information Networking Architecture. Proc. International Workshop Parallel Processing, IEEE CS Press, pages 22–30, 2000. 75. F. Stann and J. Heidemann. RMST: Reliable Data Transport in Sensor Networks. Proceedings of SNPA, Achorage, Alaska, 2003. 76. I. Stojmenovic and X. Lin. GEDIR: Loop-Free Location Based Routing in Wireless Networks. In International Conference on Parallel and Distributed Computing and Systems, 1999. 77. Dmitri B. Strukov and Konstantin K Likharev. CMOL FPGA: a Reconfigurable Architecture for Hybrid Digital Circuits with Two-Terminal Nanodevices. Nanotechnology, 16(6):888– 900, 2005. 78. L. Subramanian and R.H. Katz. An Architecture for Building Self Configurable Systems. In Proceedings of IEEE/ACM Workshop on Mobile Ad Hoc Networking and Computing, Boston, MA, 2000. 79. S. Sundresh, W.-Y. Kim, and G. Agha. SENS: A sensor, environment and network simulator. Proc. 37 Annual Simulation Symphosium (ANSS ’2004), 2004. 80. C. Wan, A. Campbell, and L. Krishnamurty. PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks. in Proceedings of WSNA02, Atlanta, Georgia, USA, 2002.

81. S. Wang, K.Z.Liu, and F.P. Hu. Simulation of Wireless Sensor Networks Localization with OMNeT. Mobile Technology, Applications and Systems, 2005 2nd International Conference on, pages 15–17, 2005. 82. Business Week. 21 ideas for the 21 century. Issue august 30, pages 78–167, 1999. 83. M. Welsh and G. Mainland. Programming Sensor Networks using Abstract Regions. Proc. 1st Usenix/ACM Symp. Networked Systems Design and Implementation (NSDI 04), pages 29–42, 2004. 84. Kamin Whitehouse, Cory Sharp, Eric Brewer, and David Culler. Hood: a Neighborhood Abstraction for Sensor Networks. Proceedings of ACM International Conference on Mobile Systems, Applications, and Services (MobiSys ’04), june 2004. 85. A. Woo and D. Culler. A Transmission Control Scheme for Media Access in Sensor Networks. Proceedings of the ACM MobiCom ’01, Rome, pages 221–235, 2001. 86. Y. Xu, J. Heidemann, and D. Estrin. Geographicaly-informed Energy Conservation for Adhoc Routing. In Proceedings of the Seventh Annual ACM/IEEE International Conference on Mobile Computing and Networking, pages 70–84, 2001. 87. Y. Yao and J. Gehrke. The COUGAR Approach to In-network Query Processing in Sensor Networks. in SIGMOD Record, 2002. 88. Fan Ye, Haiyun Luo, Jerry Cheng, Songwu Lu, and Lixia Zhang. A Two-tier Data Dissemination Model for Large-scale Wireless Sensor Networks. Mobicom, 2002. 89. W. Ye, J. Heidemann, and D. Estrin. An Energy-efficient MAC Protocol for Wireless Sensor Networks. in Proceedings of IEEE Infocom, 2002. 90. S. Yogesh, O.B. Akan, and Ian F. Akyildiz. ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks. Proceedings of MobiHoc03, Annapolis, Maryland, USA, 2003. 91. Y. Yu, D. Estrin, and R. Govindan. Geographical and Energy-Aware Routing: A Recursive Data Dissemination Protocol for Wireless Sensor Networks. UCLA Computer Science Department Technical Report, UCLA-CSD TR-01-0023, 2001. 92. L. Charlie Zhong, R.C. Shah, C. Guo, and J.M. Rabaey. An Ultra-Low Power and Distributed Access Protocol for Broadband Wireless Sensor Networks. IEEE Broadband Wireless Summit, Las Vegas, NV, 2001.